Você está na página 1de 5

Wireshark Lab5 (TCP).

_ Team 7
112327
122074 14010870

1. What is the IP address and TCP port number used by the client
computer (source)
that is transferring the file to gaia.cs.umass.edu? To answer this question,
its
probably easiest to select an HTTP message and explore the details of the
TCP
packet used to carry this HTTP message, using the details of the selected
packet
header window (refer to Figure 2 in the Getting Started with Wireshark
Lab if
youre uncertain about the Wireshark windows.

The IP address for the host (in MIT) is 192.168.1.102 and the port number is
1161.
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?

The IP address of gaia.cs.umass.edu is 128.119.245.12 and the port


number
used for this connection is 80 (indicating a web server).

3. What is the IP address and TCP port number used by your client
computer
(source) to transfer the file to gaia.cs.umass.edu?

The sequence number of the SYN segment is 232129012. Clicking on the


Flags field in Ethereal reveals the details of all the flag fields. Notice that
the SYN flag
for this segment has been set to 1, implying that this segment is a SYN
segment.

4. What is the sequence number of the TCP SYN segment that is used to
initiate the

TCP connection between the client computer and gaia.cs.umass.edu?


What is it
in the segment that identifies the segment as a SYN segment?
The sequence number of the SYNACK segment is 883061785. The
acknowledgement field is 232129013. The SYNACK packet is
acknowledging the
previously received SYN packet with the sequence number 232129012
and since this
SYN segment does not contain any data, the TCP receiver on the web
server simply
increments this value by 1 and copies it to the acknowledgement field.
The server is
thus indicating to the client that the next segment, which it expects from
the client,
should contain the sequence number 232129013. On examining the flag
fields of this
TCP segment, we see that the SYN and ACK flag bits are both set to 1
implying that
this is a SYNACK packet.
5. What is the sequence number of the SYNACK segment sent by
gaia.cs.umass.edu
to the client computer in reply to the SYN? What is the value of the
Acknowledgement field in the SYNACK segment? How did
gaia.cs.umass.edu
determine that value? What is it in the segment that identifies the
segment as a
SYNACK segment?
The sequence number of the ACK segment sent by the client is
232129013.
The acknowledgment filed contains 883061786 (1 greater than the
sequence # of the
SYNACK). No, this segment does not contain any data. The ACK flag is set
to 1
indicating that this is an ACK segment.

6. What is the sequence number of the TCP segment containing the HTTP
POST
command? Note that in order to find the POST command, youll 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.

The sequence number of the TCP segment containing the POST method is
232129013. Notice that the sequence number is same as the sequence
number for the
ACK segment that was sent prior to this segment. The reason for this is
that the ACK
segment contained no data and hence the sequence number was not
incremented
7. Consider the TCP segment containing the HTTP POST as the first
segment in the
TCP connection. What are the sequence numbers of the first six segments
in theTCP connection (including the segment containing the HTTP POST)?
At what
time was each segment sent? When was the ACK for each segment
received?
Given the difference between when each TCP segment was sent, and
when its
acknowledgement was received, what is the RTT value for each of the six
segments? What is the EstimatedRTT value (see Section 3.5.3, page 239
in
text) after the receipt of each ACK? Assume that the value of the
EstimatedRTT is equal to the measured RTT for the first segment, and then
is
computed using the EstimatedRTT equation on page 239 for all
subsequent
segments.
Note: Wireshark has a nice feature that allows you to plot the RTT for
each of the TCP segments sent. Select a TCP segment in the listing of
captured packets window that is being sent from the client to the
gaia.cs.umass.edu server. Then select: Statistics->TCP Stream Graph>Round Trip Time Graph.
The details for the first six segments and the corresponding ACKs are
provided
below along with the calculation of the EstimatedRTT:
No. Sequence # Length (in
bytes)
Time sent Time
ACK
received
Sample
RTT
Estimated
RTT
1 232129013 565 0.026477 0.053937 0.02746 0.02746
2 232129578 1460 0.041737 0.077294 0.035557 0.028472

3
4
5
6

232131038
232132498
232133958
232135418

1460
1460
1460
1460

0.054026
0.054690
0.077405
0.078157

0.124085
0.169118
0.217299
0.267802

0.070059
0.114428
0.139894
0.189645

0.03367
0.043765
0.055781
0.072514

8. What is the length of each of the first six TCP segments?4


See the above table for the TCP segment lengths. Note that the length in the table indicates
the payload contained in the TCP header. It does not include the 20 byte TCP header.
9. What is the minimum amount of available buffer space advertised at
the received
for the entire trace? Does the lack of receiver buffer space ever throttle
the
sender?
To answer this question examine all the ACK (and SYNACK) packets sent
by
the server to the client. The minimum advertised window is 5840 and this
is advertised
in the SYNACK segment. The receiver window does not seem to throttle
the sender at
all. Even when the advertised receiver window is at its lowest value (5840:
equivalent to
4 MSS packets of 1460 bytes), the sender seems to be constrained by
congestion
window as opposed to the flow control window. Notice that in the later
part of the trace,
when the congestion window has grown to a reasonable size, the receiver
advertised
window is very large (mostly 62780 bytes: 43 MSS segments). Hence the
lack of
receiver buffer space does not seem to be an issue with this connection.
10. Are there any retransmitted segments in the trace file? What did you
check for (in
the trace) in order to answer this question?
There are no retransmitted segments in the trace file. If at all a packet is
retransmitted there would be a repeat entry for that segment which is
retransmitted with
the same sequence number. However there is no such occurrence in the
entire trace file.
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 on page 247 in the text).


In the early part of the trace file (probably slow-start phase), we notice
that
each packet is individually being ACKed by the receiver. We observe
behaviour where
the sender transmits a burst of packets and the receiver then sends back
ACKs for each
of them. However later on in the trace, in particular at segment # 60, you
will notice
that the ACK with the acknowledgement field as 232166981 is actually
acknowledging
two segments with sequence #232164061 and # 232165521. From this
point on there
are several instances when the receiver sends an ACK for every other
received segment.
The receiver is typically sending a cumulative ACK for two TCP segments
that it
receives. As explained earlier this is due to the fact that TCP uses Delayed
ACKs where
the receiver waits for up to 500 msec for the arrival of another in-order
segment and
then sends a cumulative ACK for both of the received segments. (Refer to
Table 3.2 on
page 245 in Section 3.5.4 of the text).
12. What is the throughput (bytes transferred per unit time) for the TCP
connection?
Explain how you calculated this value.

The total size of the data file being transmitted is 150KB. The total duration
required for transmitting this file (neglecting the three-way handshake process) is
5.624664 seconds. So the average throughput for the TCP connection is 150 x
8/5.624664 = 213.346 Kbits/second.
An alternate way to compute the throughput could also involve looking at the amount of
data that the TCP sender sends back-to-back as part of one window and dividing this by
the total time since the transmission of the first packet in this window till the last ACK
(for the last packet in this window) is received. This throughput will be slightly greater
than that calculated above since it does not take into account the slow start phase.

Você também pode gostar