need help writing answer 1 and 2

ACS-3911-002 Computer NetworksUniversity of Winnipeg. Lecturer: Dr. Beck
Assignment Sheet #2
Important Dates
Start of assignment period: October 3nd, 2023
Deadline for submission: October 24rd, 2023
IMPORTANT: You have to submit your solutions via Nexus. Your submission must clearly indicate
your name in each file you submit. Your submitted filenames must also clearly indicate to which
assignment they belong. For example, “Michael_Beck_A1-1.pdf”.
Keep an eye on Nexus for clarifications/corrections of this assignment.
The final result of your assignment will be available once our Teaching Assistant has marked it.
NO late submissions
Assignment 2.1
The following questions are based on the textbook’s section “2.2.5 Web Caching”. Check the
infrastructure given in the image below. We have a 10Gbps LAN institutional network that shares an
access link to the internet with X Mbps bandwidth.
In the textbook and the presentation slides we were satisfied by denoting the time until a request is
satisfied as “negligible”. In this exercise we will take a closer look.
We define two quantities that will help us to determine the average time it takes to deliver a
message of size 𝐿. The first quantity you should know already: It is just the time it takes to deliver an
individual message of length 𝐿 over a link with transmission rate 𝑅:
𝐷𝑖𝑛𝑑 = 𝐿/𝑅
The second quantity we need is the average number of messages per second that must be
transmitted, let us call this quantity 𝐵. Making some assumptions (which we do not go into the
details of here) we can write down the following formula for the average time it takes to deliver one
specific message:
𝐷𝑎𝑣𝑔 =
1
⋅𝐷
1 − 𝐷𝑖𝑛𝑑 ⋅ 𝐵 𝑖𝑛𝑑
(You might want to convince yourself that the above formula gives indeed a quantity of
seconds/message)
We can now apply this formula to give a more detailed description of the delay until we receive a
message from a webserver. When not using a cache, the delay consists of three parts we must sum
up:
1) The average time to deliver the message through the institutional LAN. We compute it by
calculating 𝐷𝑎𝑣𝑔 for the LAN’s speed of 10 Gbps (this is the “LAN delay”).
2) The average time it takes to receive the message through the access link. We compute it
again by calculating 𝐷𝑎𝑣𝑔 , but this time for the access link’s speed (this is the “Access delay”).
3) The “internet-delay”, that means the time it takes for the request and response to leave and
come back to the access link. For simplicity we assume this one to be the same for each
packet: 2 seconds.
Assume the following values for 𝐿, 𝑋, and 𝐵:
•
•
•
•
𝐿 = the fourth-last digit of your student number 200 in Kilobits. Use 0 as 10. It represents the
average length of messages.
𝑋 = the third-last digit of your student number times 10 in Megabits/seconds. Use 0 as 10. It
represents the access link speed.
𝛼 =the second-last digit of your student number times 0.1. Use 0, 1, 2, 3 as 0.3 and 7, 8, 9 as
0.7. This represents the hit rate of the web cache (needed for Question 2)
𝐵 = the last digit of your student number in Messages/seconds + 5 Messages/seconds. It
represents the average number of messages per second that must be transmitted.
For example, if your student ID is 3480904, you would have: B=9 messages/s, X= 90 Mb/s, and
L=2000 Kb. The hit rate 𝛼 in this example is 0.3.
Question 1 (on Nexus): Calculate the average delay until receiving a message when no cache is
used. For this, on Nexus, you will be asked to calculate “LAN delay” and “access delay” separately.
Finally, you will be asked to sum the three delays mentioned above.
Now, let us introduce a web cache to the institutional network and see how it affects the average
delay. We assume a hit rate of 𝛼. Thus, 𝛼 represents the portion of messages that can be served by
the institutional cache directly and only need to be transmitted over the institutional LAN. These
messages do not use the access link and we do not have to wait the 2 second round-trip time
internet-delay.
Question 2 (on Nexus): Taking the cache into account what is the new 𝐷𝑎𝑣𝑔 for the access link, i.e.,
the “access delay”?
Question 3 (on Nexus): What is the average delay until receiving a message when a cache is used,
i.e., the sum of Internet Delay, “access delay”, and “LAN delay”?
Hint for question 3: The average delay is:
𝛼 ⋅ (“delay when we hit the cache”) + (1 − 𝛼) ⋅(“delay when we not hit the cache”)
Question 4 (on Nexus): Can we achieve the same lower delay of Question 3, by increasing the
access link’s bandwidth instead of implementing a cache? If yes: What would be the new access
link’s bandwidth? If no: Explain why!
Assignment 2.2
Nearly every modern browser has a way to display “development tools”. Often these can be opened
by hitting the F12 key. Here is a screenshot on how the dev-tools look in Firefox:
Do the following:
•
•
•
•
•
•
Open a browser of your choice and its dev-tools.
Select the “network” tab in the dev-tools.
With the dev-tools open put the following url into your address bar:
https://en.wikipedia.org/wiki/M/M/1_queue#Response_time and visit the site
Select the first line in the list of messages
Check its Request-headers and response headers
Take a screenshot of the request headers (fully readable) and the response headers (fully
readable). You will be asked to upload these screenshots to Nexus.
Hint: In the video I recorded I go through the motions to see the request/response headers for the
first message in Firefox and Microsoft Edge. It works very similar for other browsers!
Questions: You will be asked the following questions on Nexus. Indicate where in your screenshot
you have found the answers (the exact placement where the critical information is displayed varies
from browser to browser):
•
•
•
•
•
What is the path of the document requested by the browser?
What is the IP address of the host on which the browser is running?
What HTTP version is being used?
What encodings are being accepted?
How many cookies did your browser sent in the request?
•
•
•
At which date was the response given?
When was the page last modified?
How many bytes are in the document returned?
Assignment 2.3
Download the file “wireshark_assignment2.pdf” provided in week 6 on Nexus and read it carefully.
Answer the questions given in it. You must use your own wireshark-traces for this. If you cannot
create your own wireshark-traces contact Dr. Beck.
Upload the wireshark-trace from which you derived your solutions together with your solutions to
Nexus for this assignment.
Wireshark Lab:
HTTP and DNS v8.1
Supplement to Computer Networking: A Top-Down
Approach, 8th ed., J.F. Kurose and K.W. Ross
“Tell me and I forget. Show me and I remember. Involve me
and I understand.” Chinese proverb
© 2005-2021, J.F Kurose and K.W. Ross, All Rights Reserved
Modified by Dr. Beck for ACS-3911-002
HTTP
Having gotten our feet wet with the Wireshark packet sniffer in the introductory lab,
we’re now ready to use Wireshark to investigate protocols in operation. In this lab, we’ll
explore several aspects of the HTTP protocol: the basic GET/response interaction, HTTP
message formats, retrieving large HTML files, retrieving HTML files with embedded
objects, and HTTP authentication and security. Before beginning these labs, you might
want to review Section 2.2 of the text.1
1. The Basic HTTP GET/response interaction
Let’s begin our exploration of HTTP by downloading a very simple HTML file – one that
is very short, and contains no embedded objects. Do the following:
1. Start up your web browser.
2. Start up the Wireshark packet sniffer, as described in the Introductory lab (but
don’t yet begin packet capture). Enter “http” (just the letters, not the quotation
marks, and in lower case) in the display-filter-specification window, so that only
captured HTTP messages will be displayed later in the packet-listing window.
(We’re only interested in the HTTP protocol here, and don’t want to see the
clutter of all captured packets).
3. Wait a bit more than one minute (we’ll see why shortly), and then begin
Wireshark packet capture.
4. Enter the following to your browser
http://gaia.cs.umass.edu/wireshark-labs/HTTP-wireshark-file1.html
Your browser should display the very simple, one-line HTML file.
5. Stop Wireshark packet capture.
1
References to figures and sections are for the 8th edition of our text, Computer Networks, A Top-down
Approach, 8h ed., J.F. Kurose and K.W. Ross, Addison-Wesley/Pearson, 2020. Our authors’ website for
this book is http://gaia.cs.umass.edu/kurose_ross You’ll find lots of interesting open material there.
Your Wireshark window should look similar to the window shown in Figure 1. If you’re
unable to run Wireshark on a live network connection, you can download a packet trace
that was created when the steps above were followed.2
Figure 1: Wireshark Display after http://gaia.cs.umass.edu/wireshark-labs/ HTTPwireshark-file1.html has been retrieved by your browser
The example in Figure 1 shows in the packet-listing window that two HTTP messages
were captured: the GET message (from your browser to the gaia.cs.umass.edu web
server) and the response message from the server to your browser. The packet-contents
window shows details of the selected message (in this case the HTTP OK message,
which is highlighted in the packet-listing window). Recall that since the HTTP message
was carried inside a TCP segment, which was carried inside an IP datagram, which was
carried within an Ethernet frame, Wireshark displays the Frame, Ethernet, IP, and TCP
packet information as well. We want to minimize the amount of non-HTTP data
displayed (we’re interested in HTTP here, and will be investigating these other protocols
is later labs), so make sure the boxes at the far left of the Frame, Ethernet, IP and TCP
information have a plus sign or a right-pointing triangle (which means there is hidden,
2
You can download the zip file http://gaia.cs.umass.edu/wireshark-labs/wireshark-traces-8.1.zip and
extract the trace file http-wireshark-trace1-1. These trace files can be used to answer these Wireshark lab
questions without actually capturing packets on your own. Each trace was made using Wireshark running
on one of the author’s computers, while performing the steps indicated in the Wireshark lab. Once you’ve
downloaded a trace file, you can load it into Wireshark and view the trace using the File pull down menu,
choosing Open, and then selecting the trace file name. The resulting display should look similar to Figure
1 (for the http-wireshark-trace1-1 trace file for this HTTP lab). The Wireshark user interface displays just a
bit differently on different operating systems, and in different versions of Wireshark.
undisplayed information), and the HTTP line has a minus sign or a down-pointing
triangle (which means that all information about the HTTP message is displayed).
(Note: You should ignore any HTTP GET and response for favicon.ico. If you see a reference to
this file, it is your browser automatically asking the server if it (the server) has a small icon file
that should be displayed next to the displayed URL in your browser. We’ll ignore references to
this pesky file in this lab.).
2. The HTTP CONDITIONAL GET/response interaction
Recall from Section 2.2.5 of the text, that most web browsers perform object caching and
thus often perform a conditional GET when retrieving an HTTP object. Before
performing the steps below, make sure your browser’s cache is empty3. Now do the
following:
• Start up your web browser, and make sure your browser’s cache is cleared, as
discussed above.
• Start up the Wireshark packet sniffer
• Enter the following URL into your browser
http://gaia.cs.umass.edu/wireshark-labs/HTTP-wireshark-file2.html
Your browser should display a very simple five-line HTML file.
• Quickly enter the same URL into your browser again (or simply select the refresh
button on your browser)
• Stop Wireshark packet capture, and enter “http” (again, in lower case without the
quotation marks) in the display-filter-specification window, so that only captured
HTTP messages will be displayed later in the packet-listing window.
• Make sure to save your wireshark trace. You will be asked to upload it to Nexus.
If you’re unable to run Wireshark on a live network connection (or unable to get your
browser to issue an If-Modified-Since field on the second HTTP GET request), contact
Dr. Beck. Prepare answers for the following questions which Nexus will ask you about:
1. Inspect the contents of the first HTTP GET request from your browser to the
server. Do you see an “IF-MODIFIED-SINCE” line in the HTTP GET?
2. Inspect the contents of the server response. Did the server explicitly return
the contents of the file? How can you tell?
3. Now inspect the contents of the second HTTP GET request from your
browser to the server. Do you see an “IF-MODIFIED-SINCE:” line in the
HTTP GET4? If so, what information follows the “IF-MODIFIED-SINCE:”
header?
3
See https://www.howtogeek.com/304218/how-to-clear-your-history-in-any-browser/ for instructions on
clearing your browser cache.
4
Hint: ideally, you should see an If-Modified-Since header since you’ve just downloaded this page a few
seconds ago. However, depending on the browser you’re using, and the format of the server’s earlier
response to your initial GET, your browser may not include an If-Modified-Since even if the document has
been downloaded and caches. The Chrome browser is pretty good at regularly using If-Modified-Since.
But Safari and Firefox are much more finicky about when to use If-Modified-Since. Life isn’t always as
easy in practice as it is in theory! Comment by Dr. Beck: On my system Microsoft Edge worked, while
Firefox did not.
4. What is the HTTP status code and phrase returned from the server in
response to this second HTTP GET? Did the server explicitly return the
contents of the file? Explain.
3. Retrieving Long Documents
In our examples thus far, the documents retrieved have been simple and short HTML
files. Let’s next see what happens when we download a long HTML file. Do the
following:
• Start up your web browser, and make sure your browser’s cache is cleared, as
discussed above.
• Start up the Wireshark packet sniffer
• Enter the following URL into your browser
http://gaia.cs.umass.edu/wireshark-labs/HTTP-wireshark-file3.html
Your browser should display the rather lengthy US Bill of Rights.
• Stop Wireshark packet capture, and enter “http” in the display-filter-specification
window, so that only captured HTTP messages will be displayed.
• Make sure to save your wireshark trace. You will be asked to upload it to Nexus.
In the packet-listing window, you should see your HTTP GET message, followed by a
multiple-packet TCP response to your HTTP GET request. Make sure you your
Wireshark display filter is cleared so that the multi-packet TCP response will be
displayed in the packet listing.
This multiple-packet response deserves a bit of explanation. Recall from Section 2.2 (see
Figure 2.9 in the text) that the HTTP response message consists of a status line, followed
by header lines, followed by a blank line, followed by the entity body. In the case of our
HTTP GET, the entity body in the response is the entire requested HTML file. In our
case here, the HTML file is rather long, and at 4500 bytes is too large to fit in one TCP
packet. The single HTTP response message is thus broken into several pieces by TCP,
with each piece being contained within a separate TCP segment (see Figure 1.24 in the
text). In recent versions of Wireshark, Wireshark indicates each TCP segment as a
separate packet, and the fact that the single HTTP response was fragmented across
multiple TCP packets is indicated by the “TCP segment of a reassembled PDU” in the
Info column of the Wireshark display.
Prepare answers to the following questions5 which Nexus will ask you about:
5. How many HTTP GET request messages did your browser send? Which
packet number in the trace contains the GET message for the Bill or Rights?
6. Which packet number in the trace contains the status code and phrase
associated with the response to the HTTP GET request?
7. What is the status code and phrase in the response?
5
If you are unable to run Wireshark and capture a trace file contact Dr. Beck.
8. How many data-containing TCP segments were needed to carry the single
HTTP response and the text of the Bill of Rights?
DNS
As described in Section 2.4 of the text6, the Domain Name System (DNS) translates
hostnames to IP addresses, fulfilling a critical role in the Internet infrastructure. In this
lab, we’ll take a closer look at the client side of DNS. Recall that the client’s role in the
DNS is relatively simple – a client sends a query to its local DNS server, and receives a
response back. As shown in Figures 2.19 and 2.20 in the textbook, much can go on
“under the covers,” invisible to a DNS client, as the hierarchical DNS servers
communicate with each other to either recursively or iteratively resolve the client’s DNS
query. From the DNS client’s standpoint, however, the protocol is quite simple – a query
is formulated to the local DNS server and a response is received from that server.
Before beginning this lab, you’ll probably want to review DNS by reading Section 2.4 of
the text. In particular, you may want to review the material on local DNS servers, DNS
caching, DNS records and messages, and the TYPE field in the DNS record.
1. nslookup
Let’s start our investigation of the DNS by examining the nslookup command, which
will invoke the underlying DNS services to implement its functionality. The nslookup
command is available in most Microsoft, Apple IOS, and Linux operating systems. To
run nslookup you just type the nslookup command on the command line in a DOS
window, Mac IOS terminal window, or Linux shell.
In its most basic operation, nslookup allows the host running nslookup to query any
specified DNS server for a DNS record. The queried DNS server can be a root DNS
server, a top-level-domain (TLD) DNS server, an authoritative DNS server, or an
intermediate DNS server (see the textbook for definitions of these terms). For example,
nslookup can be used to retrieve a “Type=A” DNS record that maps a hostname (e.g.,
www.nyu.edu) to its IP address. To accomplish this task, nslookup sends a DNS query
to the specified DNS server (or the default local DNS server for the host on which
nslookup is run, if no specific DNS server is specified), receives a DNS response from
that DNS server, and displays the result.
Let’s take nslookup out for a spin! We’ll first run nslookup on the Linux command
line on the newworld.cs.umass.edu host located in the CS Department at the University of
Massachusetts (UMass) campus, where the local name server is named
6
References to figures and sections are for the 8 th edition of our text, Computer Networks, A Top-down
Approach, 8h ed., J.F. Kurose and K.W. Ross, Addison-Wesley/Pearson, 2020. Our website for this book is
http://gaia.cs.umass.edu/kurose_ross You’ll find lots of interesting open material there.
primo.cs.umass.edu (which has an IP address 128.119.240.1). Let’s try nslookup in its
simplest form:
Figure 1: the basic nslookup command
In this example the nslookup command is given one argument, a hostname
(www.nyu.edu). In words, this command is saying “please send me the IP address for the
host www.nyu.edu.” As shown in the screenshot, the response from this command
provides two pieces of information: (1) the name and IP address of the DNS server that
provides the answer – in this case the local DNS server at UMass; and (2) the answer
itself, which is the canonical host name and IP address of www.nyu.edu. You may have
noticed that there are two name/address pairs provided for www.nyu.edu. The first
(216.165.47.12) is an IPv4 address in the familiar-looking dotted decimal notation; the
second (2607:f600:1002:6113::100) is a longer and more complicated looking IPv6
address. We’ll learn about IPv4 and IPv6 and their two different addressing schemes
later in Chapter 4. For now, let’s just focus on our more comfortable (and common) IPv4
world7.
Although the response came from the local DNS server (with IP address 128.119.240.1) at
UMass, it is quite possible that this local DNS server iteratively contacted several other
DNS servers to get the answer, as described in Section 2.4 of the textbook.
In addition to using nslookup to query for a DNS “Type=A” record, we can also use
nslookup to nslookup to query for a “TYPE=NS” record, which returns the hostname
(and its IP address) of an authoritative DNS server that knows how to obtain the IP
addresses for hosts in the authoritative server’s domain.
Figure 2: using nslookup to find the authoritative name servers for the nyu.edu domain
7
For Mac OS, if you want to work just in the IPv4 world: System preferences -> Network. Then select
your active interface (e.g., Wi-Fi) and Advanced->TCP/IP. Then select the Configure IPv6 drop-down
menu and set it to “Link-local only” or “Off”.
In the example in Figure 2, we’ve invoked nslookup with the option “-type=NS” and
the domain “nyu.edu”. This causes nslookup to send a query for a type-NS record to the
default local DNS server. In words, the query is saying, “please send me the host names
of the authoritative DNS for nyu.edu”. (When the –type option is not used, nslookup uses
the default, which is to query for type A records.) The answer, displayed in the above
screenshot, first indicates the DNS server that is providing the answer (which is the
default local UMass DNS server with address 128.119.240.1) along with three NYU
DNS name servers. Each of these servers is indeed an authoritative DNS server for the
hosts on the NYU campus. However, nslookup also indicates that the answer is “nonauthoritative,” meaning that this answer came from the cache of some server rather than
from an authoritative NYU DNS server. Finally, the answer also includes the IP
addresses of the authoritative DNS servers at NYU. (Even though the type-NS query
generated by nslookup did not explicitly ask for the IP addresses, the local DNS server
returned these “for free” and nslookup displays the result.)
nslookup has a number of additional options beyond “-type=NS” that you might want
to explore. Here’s a site with screenshots of ten popular nslookup uses:
https://www.cloudns.net/blog/10-most-used-nslookup-commands/ and here are the “man
pages” for nslookup: https://linux.die.net/man/1/nslookup.
Lastly, we sometimes might be interested in discovering the name of the host associated
with a given IP address, i.e., the reverse of the lookup shown in Figure 1 (where the
host’s name was known/specified and the host’s IP address was returned). nslookup can
also be used to perform this so-called “reverse DNS lookup.” In Figure 3, for example,
we specify an IP address as the nslookup argument (128.119.245.12 in this example)
and nslookup returns the host name with that address (gaia.cs.umass.edu in this
example)
Figure 3: using nslookup to perform a “reverse DNS lookup”
Now that we’ve provided an overview of nslookup, it’s time for you to test drive it
yourself. If you’re unable to run the nslookup command Figure 4 shows a screenshot.
But it is highly recommended you do this on your machine instead:
1. Run nslookup to obtain the IP address of the web server for the Indian
Institute of Technology in Bombay, India: www.iitb.ac.in. What is the IP address
of www.iitb.ac.in
2. What is the IP address of the DNS server that provided the answer to your
nslookup command in question 1 above?
3. Did the answer to your nslookup command in question 1 above come from an
authoritative or non-authoritative server?
4. Use the nslookup command to determine the name of the authoritative name
server for the iit.ac.in domain. What is that name? (If there are more than one
authoritative servers, what is the name of the first authoritative server returned by
nslookup)? If you had to find the IP address of that authoritative name server,
how would you do so?
Figure 4: using nslookup to find the IP address of www.iitb.ac.in and the names of the
authoritative name servers for the iitb.ac.in domain
2. The DNS cache on your computer
From the description of iterative and recursive DNS query resolution (Figures 2.19 and
2.20) in our textbook, you might think that the local DNS server must be contacted every
time an application needs to translate from a hostname to an IP address. That’s not
always true in practice!
Most hosts (e.g., your personal computer) keep a cache of recently retrieved DNS records
(sometimes called a DNS resolver cache), just like many Web browsers keep a cache of
objects recently retrieved by HTTP. When DNS services need to be invoked by a host,
that host will first check if the DNS record needed is resident in this host’s DNS cache; if
the record is found, the host will not even bother to contact the local DNS server and will
instead use this cached DNS record. A DNS record in a resolver cache will eventually
timeout and be removed from the resolver cache, just as records cached in a local DNS
server (see Figures 2.19, 2.20) will timeout.
You can also explicitly clear the records in your DNS cache. There’s no harm in doing
so – it will just mean that your computer will need to invoke the distributed DNS service
next time it needs to use the DNS name resolution service, since it will find no records in
the cache. On a Mac computer, you can enter the following command into a terminal
window to clear your DNS resolver cache:
sudo killall -HUP mDNSResponder
On Windows computer you can enter the following command at the command prompt:
ipconfig /flushdns
and on a Linux computer, enter:
sudo systemd-resolve –flush-caches
3. Tracing DNS with Wireshark
Now let’s play with nslookup8.
● Start packet capture.
● Do an nslookup on www.cs.umass.edu
● Stop packet capture.
You should get a trace that looks something like the following in your Wireshark
window. Let’s look at the first type A query (which is packet number 19 in the figure
below, and indicated by the “A” in the Info column for that packet.
Save the wireshark-trace, you will be asked to upload it to Nexus. Also prepare your
answers for the following questions, that you will be asked on Nexus:
1. What is the destination port for the DNS query message? What is the source
port of the DNS response message?
2. To what IP address is the DNS query message sent? Is this the IP address of
your default local DNS server?
3. Examine the DNS query message. What “Type” of DNS query is it? Does the
query message contain any “answers”?
4. Examine the DNS response message to the query message. How many
“questions” does this DNS response message contain? How many “answers”?
8
If you are unable to run Wireshark and capture a trace file contact Dr. Beck.
Last, let’s use nslookup to issue a command that will return a type NS DNS record,
Enter the following command:
nslookup –type=NS umass.edu
Again save the trace9 and prepare answers for the following questions:
5. To what IP address is the DNS query message sent? Is this the IP address of
your default local DNS server?
6. Examine the DNS query message. How many questions does the query have?
Does the query message contain any “answers”?
7. Examine the DNS response message. How many answers does the response
have? What information is contained in the answers? How many additional
resource records are returned? What additional information is included in
these additional resource records?
9
If you are unable to run Wireshark and capture a trace file contact Dr. Beck.