Computer communication EDA343/DIT420
Lab 1
Packet and Traffic Analysis Using Network Sniffing Software
1. There are three assignments in this course. First two assignments are in form of
programming or network software experiment labs whereas the third assignment is
in form of a written report. For each assignment there will be a fixed deadline as
mentioned in the submission system. This is the PM of the first lab.
2. You may work in groups of max 2 students per group and computer.
3. Completed lab work must be reported with answers of the questions embedded in
the lab tasks. The report must be posted to pingpong before the deadline.
Please read through this PM before attending the lab session and make sure that you
are prepared to use Wireshark.
This lab is including adopted and selected parts from the Wireshark Labs which can be
downloaded from the course book home page: http://wps.aw.com/aw_kurose_network_5
(“Student resources” / “Wireshark labs”).
Wireshark ® is popular network protocol analyzer and it is available to download using
http://www.wireshark.org/download.html under the GNU General Public License.
Purpose: To learn how to listen to network traffic and analyze different protocols as well
as learning to use some useful system utilities.
Background reading:
Read related sections in Chapter 2 (Application) and Chapter 3 (Transport), p lease see
below the outlined sections of the course book.
Preparation: Either at home using your own installation of the software or at campus
using the computers of the lab rooms J232 (Gnistan) and J234 (Bryggan), floor 2 in
Jupiter building; prepare by yourself the first part of the exercises (Getting Started with
Wireshark) to be familiar with the program and its usage; please refer to the “Wireshark
Lab” at the end of Chapter 1 in the course book.
The following lab parts are the ones that should be performed fully during the lab
sessions.
1.
2.
3.
4.
Getting Started with Wireshark (prepared before the lab session)
HTTP (section 2.2)
DNS (section 2.5)
TCP (sections 3.5 and 3.7)
For those who wish and who have some time, you may also perform by yourself the
following optional labs at home:
Page 1 Useful and practical information
You will be working in the Windows environment but the instructions include as well
the Linux environment. To facilitate the work, a small list of things to think about and
practical information is found next on this page.
Time estimation:
Estimate about little bit more than one hour for each part of lab (they are three HTTP lab,
DNS lab and TCP lab). Try to understand all topics before continuing with the next part!
Bring the book:
You will most likely have to consult the book about various topics, so make sure each
group has at least one book available!
Using Wireshark on computers in lab room:
You are going to use the Chalmers studat-computers located in Jup232 (Gnistan) and
Jup234 (Bryggan). When coming to the lab, you must log into the machine in front of you
using operating system Windows. Use your Chalmers student account to log in. You are
going to get some root privileges on these computers that allow you to perform the lab
tasks using Wireshark. Ordinary studat-users are not allowed to capture network traffic.
Note: In any other Studat-computer rooms Wireshark must run with administrator (root)
privileges. If you just start Wireshark, you will get an error message “permission denied”
when trying to capture packets.
Using traces:
The book resources include traces files for the Wireshark labs. You may use these prerecorded trace files at home but not during the lab session. Please note; do not use any
trace file during the lab exercises, since you are able to run Wireshark on a live network
connection in the lab room. You should use your own outworked trace.
Manuals and on-line help:
If you need help about a command, you can ask the system in Linux by giving the
command “man command” in a terminal window. In Windows use the help parameter /?
To get help, for example enter C:\> ipconfig /?.
Web browser:
When using web browser you may need to clean the cache as outlined in the text of the
instructions depending on which browser is in use.
DNS:
In addition to the nslookup command, you can experiment with the host command. Also,
note that the Linux ifconfig has different arguments than Windows ipconfig. In order to
flush DNS-cache use the command “ sudo /etc/init.d/nscd restart “ as it is outlined in
the text of the instructions.
Page 2 HTTP (March 2012)
Adopted from Wireshark Labs
© 2009 J.F. Kurose, K.W. Ross. All Rights Reserved
Computer Networking: A Top down Approach, 5th edition.
In this lab, you’ll explore several aspects of the HTTP protocol; the basic GET/response
interaction, HTTP message format, retrieving large HTML files, retrieving HTML files with
embedded objects, and optional HTTP authentication and security. Before beginning these labs,
you might want to review section 2.2 of the book.
1. The Basic HTTP GET/response interaction
Let’s begin the exploration of HTTP by downloading a very simple HTML file; one that is very
short, and contains no embedded objects.
Do the following:
• Start up your web browser.
• Start up the Wireshark packet capture, as described in the introductory lab (but don’t yet
begin packet capture). Enter the string “http” in the Filter-field (or in the display-filterspecification window), then press the button Apply so that only captured HTTP messages
will be displayed later in the packet-listing window. (We are only interested in the HTTP
protocol here, and don’t want to see the clutter of all captured packets).
• Start Wireshark packet capture.
• 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.
• Stop Wireshark packet capture.
Wireshark will show in the packet-listing window that two HTTP messages are 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 GET message, when you highlight it 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 header information as well. We want to minimize the amount of non-HTTP data displayed
(We are interested in HTTP here, and you will be investigating these other protocols in later labs),
so make sure that the boxes at the far left of the Frame, Ethernet, IP and TCP information have a
plus sign (which means there is hidden, not displayed information), and the HTTP line has a minus
sign (which means that all information about the HTTP message is displayed).
N o t e : You should ignore any HTTP GET and response for favicon.ico. There is no reference to
this file in the html-page; 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. Just ignore the
GET/response messages of this file.
Page 3 By looking at the information in the HTTP GET and response messages, answer the following
questions. When answering, you should inspect the fields of the GET and response messages to
indicate where in the message you’ve found the information about answers.
1.
2.
3.
4.
5.
6.
7.
What is the IP address of your computer?
What HTTP version is your browser running? What version is the server running?
What languages (if any) does your browser indicate to the server that it can accept?
What is the status code returned from the server to your browser?
When was the HTML-file that you are retrieving last-modified at the server?
How many bytes of content are being returned to your browser?
By inspecting the raw decoded data in the packet-contents window, compare the header
lines with those that are displayed in the protocol-contents window, are they the same?
N o t e : In your answer to question 5 above, you might have been surprised to find that the
document you just retrieved was last modified within a minute before you downloaded the
document. That’s because (for this particular file), the gaia.cs.umass.edu server is setting the file’s
last-modified time to be the current time, and is doing so once per minute. Thus, if you wait a
minute between accesses, the file will appear to have been recently modified, and hence your
browser will download a “new” copy of the document.
2. The HTTP CONDITIONAL GET/response interaction
Recall from Sections 2.2.5-2.2.6 of the book, that most web browsers perform object caching and
thus perform a conditional GET when retrieving an HTTP object. Before performing the steps
below, make sure your browser’s cache is empty. (To do this under Firefox, select Tools → Clear
Recent History, or for Internet Explorer, select Tools → Internet Options → General Tab→ Clear
History; these actions will remove cached files from your browser’s cache.)
Now do the following:
• Start up your web browser, and make sure your browser’s cache is cleared, as explained
above.
• Start up the Wireshark packet capture, and enter “http” in the Filter-field as before.
• 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.
•
Answer the following questions:
8. Inspect the contents of the first HTTP GET request from your browser to the server. Is the
request indicating conditional GET?
9. Inspect the contents of the server response. Does the server explicitly return the contents of
the file? How can you tell?
10. Now inspect the contents of the second HTTP GET request from your browser to the server.
Which HTTP header line does the request indicate conditional GET?
11. What is the HTTP status code and phrase returned from the server in response to this second
HTTP GET? Does the server explicitly return the contents of the file? Explain.
Page 4 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 you download a large 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 capture, and enter “http” in the Filter-field as before.
• 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.
In the packet-listing window, you should see the HTTP GET message, followed by a multiplepacket response to your HTTP GET request. This multiple-packet response deserves a bit of
explanation. Recall from Section 2.2 (see Figure 2.9 in the book) that the HTTP response message
consists of a status line, followed by header lines, followed by a blank line, followed by the entity
body. 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 single TCP segment or one IP
packet. The single HTTP response message is thus broken into several pieces by TCP, with each
piece being contained within a separate TCP segment. (Each TCP segment may be recorded as a
separate packet by Wireshark or a number of segments are reassembled and the former will also be
indicated by the “Continuation” phrase displayed by Wireshark. It should be clear here that there is
no “Continuation” message in HTTP!). Please check Wireshark Preferences → Protocols → HTTP
to see what options to choose in order to suppress reassembly of segments.
Answer the following questions:
12. How many HTTP GET request messages are sent by your browser?
13. How many data-containing TCP segments are needed to carry the single HTTP response?
14. What is the status code and phrase associated with the response to the HTTP GET request?
15. Are there any HTTP status-lines in the transmitted data associated with a TCP-induced
“Continuation”?
4. HTML Documents with Embedded Objects
Now that you’ve seen how Wireshark displays the captured packet traffic for large HTML files,
you can look at what happens when your browser downloads a file with embedded objects, i.e., a
file that includes other objects (in the example below, image files) that are stored on other servers.
Do the following:
• Start up your web browser, and make sure your browser’s cache is cleared.
• Start up the Wireshark packet capture and enter “http” in the Filter-field as before.
• Enter the following URL into your browser
http://gaia.cs.umass.edu/wireshark-labs/HTTP-wireshark-file4.html
• Stop Wireshark packet capture.
Your browser should display a short HTML file with two images. These two images are referenced
in the base HTML file. That is, the images themselves are not contained in the HTML; instead the
URLs for the images are contained in the downloaded base HTML file. As discussed in the book,
your browser will have to retrieve these logos from the indicated web sites. The publisher’s logo is
retrieved from the http://www.pearsonhighered.com web site. The image of the course book’s
cover is stored at the http://manic.cs.umass.edu server.
Page 5 Answer the following questions:
16. How many HTTP GET request messages are sent by your browser? To which Internet
addresses are these GET requests sent?
17. Can you tell whether your browser downloaded the two images serially, or whether they are
downloaded from the two web sites in parallel? Explain.
5. HTTP Authentication (Optional)
Finally, let’s try visiting a web site that is password-protected and examine the sequence of HTTP
messages exchanged for such a site. So let’s access this “secure” password-protected site.
Do the following:
• Start up your browser and make sure that the browser’s cache is cleared, as before.
• Start up the Wireshark packet capture.
• Enter the following URL into your browser
http://gaia.cs.umass.edu/wireshark-labs/protected_pages/HTTP-wiresharkfile5.html
• This URL is password protected. The username is “wireshark-students” and the password
is “network”. Type the requested user name and password into the pop up box.
• Stop Wireshark packet capture, and enter “http” in the display-filter-specification window,
so that only captured HTTP messages will be displayed later in the packet-listing window.
Now let’s examine the Wireshark output. You might want to first read up on HTTP authentication
by reviewing the easy-to-read material on “HTTP Access Authentication Framework” at
http://frontier.userland.com/stories/storyReader$2159
Answer the following questions:
18. What is the server’s response (status code and phrase) in response to the initial HTTP GET
message from your browser?
19. When your browser’s sends the HTTP GET message for the second time, what new field is
included in the HTTP GET message?
The username (wireshark-students) and password (network) that you entered are encoded in the
string of characters (d2lyZXNoYXJrLXN0dWRlbnRzOm5ldHdvcms=) following the
“Authorization: Basic” header in the client’s HTTP GET message.
While it may appear that your username and password are encrypted, they are simply encoded in a
format known as Base64 format. The username and password are not encrypted! To see this, go to
decoder web page http://www.securitystats.com/tools/base64.php. Enter the base64encoded string d2lyZXNoYXJrLXN0dWRlbnRz and press decode. Voila! You have translated
from Base64 encoding to ASCII encoding, and thus should see your username! To view the
password, enter the remainder of the string Om5ldHdvcms= and press decode. Since anyone can
download a tool like Wireshark and sniff packets (not just their own) passing by their network
adapter, and anyone can translate from Base64 to ASCII (you just did it!), it should be clear to you
that simple passwords on WWW sites are not secure unless additional measures are taken.
Fear not! As you will see in Chapter 7, there are ways to make WWW access more secure.
However, you’ll clearly need something that goes beyond the basic HTTP authentication
framework!
Page 6 DNS (March 2012)
Adopted from Wireshark Labs
© 2009 J.F. Kurose, K.W. Ross. All Rights Reserved
Computer Networking: A Top down Approach, 5th edition.
As described in section 2.5 of the book, the Domain Name System (DNS) mainly translates
hostnames to IP addresses, fulfilling a critical role in the Internet infrastructure. In this lab, you’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 (cache-only) DNS server, and receives a response back.
As shown in Figures 2.21 and 2.22 in the book, much can go on “under the covers” invisible to the
DNS clients, as the hierarchical DNS servers communicate with each other to either recursively
or/and 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.5 of the book.
In particular, you may want to review the material on local DNS servers, DNS caching, Resource
Records and DNS message format.
1. nslookup
In this lab, you’ll make extensive use of the nslookup tool, which is available in most Linux/Unix
and Microsoft platforms today. To run nslookup in Linux/Unix, you open a terminal window and
just enter the nslookup command on the command line. To run it in Windows, open the Command
Prompt and run nslookup on the command line.
The general syntax of nslookup command is:
nslookup –option1 –option2 host-to-find dns-server
In general, nslookup can be run with zero, one, two or more options. And as you will see in the
following examples, the dns-server is optional as well; if it is not supplied, the query is sent to the
default local DNS server.
In its most basic operation, nslookup tool allows the host to query any specified DNS server for a
DNS record. The queried DNS server can be a root DNS server, a Top-Level- Domain DNS server,
an authoritative DNS server, or an intermediate DNS server (see the book for definitions of these
terms). To accomplish this task, nslookup sends a DNS query to the specified DNS server, receives
a DNS reply from that same DNS server, and displays the result.
Consider first the results by entering the command:
nslookup www.chalmers.se
In words, this command is saying “please send me the IP address for the host www.chalmers.se”.
When running nslookup, if no DNS server is specified, then nslookup sends the query to the default
DNS server. The response from this server provides two pieces of information: (1) the name and IP
address of the DNS server that provides the answer; and (2) the answer itself, which is the host
Page 7 name and IP address of www.chalmers.se. Although the response will come from the local DNS
server at the Chalmers University (probably res1.chalmers.se), it is quite possible that this local
DNS server iteratively contacted several other DNS servers to get the answer, as described in
Section 2.5 of the book. Now consider the results by entering a second command:
nslookup -type=NS mit.edu
In this example, you provide the option “-type=NS” and the domain “mit.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 mit.edu”. (When the -type
option is not used, nslookup uses the default, which is to query for type A records.) The answer will
first indicate the DNS server that is providing the answer (which is the default local DNS server)
along with three MIT name servers. Each of these servers is indeed an authoritative DNS server for
the hosts on the MIT campus. However, nslookup also indicates that the answer is “nonauthoritative,” meaning that this answer came from the cache of the local server rather than directly
from an authoritative MIT DNS server. Finally, the answer also includes the IP addresses of the
authoritative DNS servers at MIT. (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.). Finally consider a third command:
nslookup www.aiit.or.kr bitsy.mit.edu
In this example, you indicate that you want the query to be sent to the DNS server bitsy.mit.edu
rather than to the default local DNS server. Thus, the query and reply transaction takes place
directly between your querying host and bitsy.mit.edu. In this example, the DNS server
bitsy.mit.edu recursively provides the IP address of the host www.aiit.or.kr, which is a web server
at the Advanced Institute of Information Technology (in Korea).
Do the following (and write down your commands and the results):
1. Run nslookup to obtain the IP address of a Web server in Asia.
2. Run nslookup to determine the authoritative DNS servers for a university in Europe.
3. Run nslookup to determine the mail servers for Yahoo!
2. ipconfig/ifconfig
The commands ipconfig (for Windows) and ifconfig (for Linux/Unix) are among the most useful
little utilities in your host, especially for debugging network issues. ipconfig or ifconfig can be
used to show host current TCP/IP information, including IP address, adapter type and so on. For
example, if you want all this information about your host, just enter:
C:\> ipconfig /all
into the Command Prompt, in Windows
$ /sbin/ifconfig
into a terminal, in Linux
In Section 2.5 you learned that a host can cache DNS records it recently obtained. To clear the
cache, enter:
C:\> ipconfig /flushdns
into the Command Prompt, in Windows
$ sudo /etc/init.d/nscd restart
into a terminal, in Linux
.
Flushing or restarting the DNS cache clears all entries and reloads the entries from the hosts file.
Page 8 3. Tracing DNS with Wireshark
Now that you are familiar with nslookup and ipconfig/ifconfig, you’re ready to get down to some
serious business. Let’s first capture the DNS packets that are generated by ordinary Web surfing
activity.
• Use the appropriate command to empty the DNS cache in your host.
• Open your browser and empty the browser cache.
• Start Wireshark and enter “ip.addr = = your_IP_address” into the Filter-field, where you
find out your_IP_address using ipconfig/ifconfig. This filter removes all packets that neither
originate nor are destined to your host.
• Start packet capture in Wireshark.
• With your browser, visit the Web page: http://www.ietf.org
• Stop packet capture.
Answer the following questions:
4. Locate the DNS query and response messages. Are they sent over UDP or TCP?
5. What are the source and the destination ports used for the DNS query and response
messages?
6. To what IP address is the DNS query message sent? Is this the IP address of your local
DNS server? Use ipconfig /all in Windows, or enter the command cat /etc/resolv.conf in
Linux to determine the IP address of your local DNS server.
7. Examine the DNS query message. What “Type” of DNS query is it? Which information
fields “sections” are there in the query message?
8. Examine the DNS response message. How many “sections” are provided? What does each
of these fields contain?
9. Consider the subsequent TCP SYN packet sent by your host. Does the destination IP
address of the SYN packet correspond to any of the IP addresses provided in the DNS
response message?
10. This web page contains images. In order to retrieve each image a GET message is sent with
the host name www.ietf.org, does your host issue new DNS queries to resolve it? Why?
Now let’s examine DNS messages using nslookup.
• Start packet capture.
• Type and execute the command: nslookup www.aiit.or.kr bitsy.mit.edu
• Stop packet capture.
You should now get a packet trace where nslookup actually sent three DNS queries and received
three DNS responses. For the purpose of this assignment, in answering the following questions,
you should focus on the desired query and response messages to translate the hostname. Please
ignore any other sets of queries/responses, as they are specific to the DNS configuration of the
host and are not normally generated by standard Internet applications.
Answer the following questions:
11. To what IP address is the DNS query message sent? Is this the IP address of your default
local DNS server? If not, what does the IP address correspond to?
12. Examine the DNS query message. What “Type” of DNS query is it? Does the query
message contain any “sections”?
13. Examine the DNS response message. How many “answers” are provided? What does each
of these answers contain?
Page 9 TCP (March 2012)
Adopted from Wireshark Labs
© 2009 J.F. Kurose, K.W. Ross. All Rights Reserved
Computer Networking: A Top down Approach, 5th edition.
In this lab, you’ll investigate the behaviour of TCP in detail. You’ll do so by analyzing a trace of
the TCP segments sent and received when transferring a 150 Kbyte file (containing the text of
Lewis Carroll’s Alice’s Adventures in Wonderland) from your computer to a remote server.
Before beginning this lab, you’ll probably want to review sections 3.5 and 3.7 in the book.
You are going to:
•
•
•
•
•
Study TCP’s use of sequence and acknowledgement numbers for providing reliable data
transfer,
Consider briefly TCP connection setup
Look at TCP’s receiver-advertised flow control mechanism.
Investigate the performance (throughput and round-trip time) of the TCP connection
between your computer and the server.
See TCP’s congestion control algorithm; slow start and congestion avoidance in action,
1. Capturing a bulk TCP transfer from your computer to a remote server
Before beginning the exploration of TCP, you’ll need to use Wireshark to obtain a packet trace of
the TCP transfer of a file from your computer to a remote server. You’ll do so by accessing a Web
page that will allow you to enter the name of a file stored on your computer (which contains the
ASCII text of Alice Adventures in Wonderland), and then transfer the file to the Web server using
the HTTP POST method (see section 2.2.3 in the book).
You’re using the POST method this time rather than the GET method because you’d like to
transfer a large amount of data from your computer to a Web server. Of course, you’ll be running
Wireshark during this time to obtain the trace of the TCP segments sent and received from your
computer.
Do the following:
• Start up your web browser.
• Go the http://gaia.cs.umass.edu/wireshark-labs/alice.txt and retrieve an ASCII
copy of Alice Adventure in Wonderland. Store this file somewhere on your computer.
• Next go to http://gaia.cs.umass.edu/wireshark-labs/TCP-wireshark-file1.html
You should see a screen that looks like:
Page 10 • Use the Browse button in this form to enter the name of the file (full path name) on your
computer containing Alice Adventure in Wonderland (or do so manually). Don’t yet press
the “Upload alice.txt file” button.
• Now start up Wireshark and begin packet capture. Returning to your browser, press the
“Upload alice.txt file” button to upload the file to the gaia.cs.umass.edu server. Once the
file has been uploaded, a short congratulations message will be displayed in your browser.
• Stop Wireshark packet capture.
2. A first look at the captured trace
Before analyzing the behaviour of the TCP connection in detail, let’s take a high level view of the
trace. Since this lab is about TCP rather than HTTP, let’s change Wireshark’s “listing of captured
packets” window so that it shows information about the TCP segments containing the HTTP
messages, rather than about the HTTP messages. To do so; filter the packets displayed in the
Wireshark window by entering “tcp” in the Filter field and then press the button Apply. You
should now see a series of TCP segments sent between your computer and gaia.cs.umass.edu. You
will use this packet trace that you have captured to study TCP behaviour in the rest of this lab.
You should see the initial three-way handshake containing SYN/ACK messages. Then you should
see an HTTP POST message and a series of “HTTP Continuation” segments being sent from your
computer to gaia.cs.umass.edu. Recall from a previous discussion in the earlier HTTP Wireshark
lab, that there is no such thing as an “HTTP Continuation” message. This is Wireshark’s way of
indicating that there are multiple TCP segments being used to carry a single HTTP message. You
should also see TCP ACK segments being returned from gaia.cs.umass.edu to your computer.
Whenever possible, you should indicate which packet(s) within the trace that you used to answer the
question and explain your answer. Answer the following questions:
1. What is the IP address and TCP port number used by your computer (source)?
2. What is the IP address of gaia.cs.umass.edu? On what port number is it sending
and receiving TCP segments for this connection?
Page 11 3. TCP Basics
Answer the following questions for the TCP segments:
3. Identify the TCP segments that are used to initiate the TCP connection between your
computer and gaia.cs.umass.edu. What are the initial sequence numbers being used?
For each one, what is in the segment that identifies it as an initial connection segment?
4. What is the value of the ACKnowledgement field in each of these initial segments? How
does each side determine that value? What is; in the segment, that identifies it as a ACK
segment?
5. What is the sequence number of the TCP segment containing the HTTP POST method?
Consider the first TCP segment containing HTTP in this connection. Note that in order to
find the POST command; you’ll need to dig into the packet content field at the bottom of
the Wireshark window, looking for a segment with a “POST” within its data field.
6. What are the sequence numbers of the first six segments in the TCP connection (following
the segment containing the HTTP POST)? At what time is each segment sent? When is the
ACK for each segment received? Make a table of these values.
7. Given the difference between when each TCP segment is sent, and when its
acknowledgement is received, what is the RTT value for each of the six segments? What is
the Estimated RTT value after the receipt of each ACK? Assume that the value of the
Estimated RTT is equal to the measured RTT for the first (POST) segment, and then the
Estimated RTT is computed using the Estimated RTT equation (given in Section 3.5.3 in the
book) for all subsequent segments. Complete the table in your answer for Q.6.
N o t e : Wireshark has a nice feature that allows you to plot the RTT for each of the TCP segments
sent. Select a TCP segment that is being sent from your computer to the gaia.cs.umass.edu server in
the “listing of captured packets” window. Then select:
Statistics → TCP Stream Graph → Round Trip Time Graph.
8. What is the length of data in each of these six TCP segments?
9. What is the minimum amount of available buffer space advertised by the receiver for the
entire trace? Does the lack of receiver buffer space ever throttle the sender?
10. Are there any retransmitted segments in the trace file? What do you check for (in the trace)
in order to answer this question?
11. How much data does the receiver typically acknowledge in an ACK? Can you identify cases
where the receiver is ACKing every other received segment (see Table 3.2 in the book).
12. What is the overall throughput (in kbps) for the whole TCP connection? Explain how you
have calculated this value.
N o t e : The TCP segments are all equal or less than 1460 bytes. This is because the computer has
an Ethernet card that limits the length of the maximum IP packet (MTU) up to 1500 bytes (40 bytes
of TCP/IP header data and 1460 bytes of TCP payload). This 1500-byte value is the standard
maximum length allowed by Ethernet.
13. In order to see the TCP flow graphically; select a TCP segment in the “listing of captured
packets” window and then select the menu Statistics → Flow Graph. Choose flow type
“TCP flow”. Now by using this TCP flow graph you may verify your answers of the above
questions Q. 8-12.
Page 12 4. TCP Congestion Control
Let’s now examine the amount of data sent per unit time from your computer to the server.
Rather than (tediously!) calculating this from the raw data in the Wireshark window, you’ll use one
of Wireshark’s TCP graphing utilities; Time-Sequence Graph (Stevens) to plot out data.
• Select a TCP segment in the Wireshark’s “listing of captured-packets” window. Then select
the menu Statistics → TCP Stream Graph → Time-Sequence Graph (Stevens). You should see
a plot of the segments sent per time. In this graph; each dot represents a TCP segment sent, and
the utility is plotting the sequence number of the segment versus the time at which it was sent.
Note that a set of dots stacked above each other represents a series of packets that are sent backto-back by the sender.
Answer the following questions:
14. Using sequence-time plot of the segments being sent from your computer to the
gaia.cs.umass.edu server; can you identify where TCP’s slow start phase begins and ends,
and where congestion avoidance takes over? Include a copy of your plot and explain your
answer with values from it.
15. Comment on ways in which the measured data differs from the idealized behaviour of TCP
that you’ve studied in the book.
Page 13