Name:

Std id#

[Date]
Contents
Wireshark Lab-1: TCP................................................................................................................................1
Transmission Control Protocol Basics.....................................................................................................3
Wireshark Lab-1: TCP

Answer1: I select and open the packet that contain http (HTTP 200 OK) data and then I print it
by using the file tab to answer this question. The client computer's IP address is the destination
IP address "192.168.1.102," and "1161" is the destination port number. This is the number that
the client computer uses to send data. because the HTTP 200 OK message that the response
given to the client by the server as shown below in the screenshot.

Figure 1
Answer2: The same packet containing HTTP (HTTP 200 OK) data is opened. IP address
"128.119.245.12" is the one used by the server, and it is also the one from which
gaia.cs.umass.edu was launched.
Gaia.cs.umass.edu uses the TCP/IP port number "80" because the server replies to client requests
with an HTTP 200 OK status code, as shown in the following screenshot.

Figure 2
Transmission Control Protocol Basics

Answer3: The client computer that connects to gaia.cs.umass.edu using a TCP SYN segment
with a sequence number “0”. The segment’s flags field show that it is a TCP SYN packet. The
SYN flag bit is set to 1 in the next screenshot, which means that it is a SYN packet.

Figure 3

Answer4: In response to a "SYN" request with sequence number 0, the gaia.cs.umass.edu sends
a TCP [SYN, ACK] packet. This acknowledgment number used by this segment is 1. The flags
field in the packet idecates that it is a TCP [SYN,ACK] packet as shown in the following image.

Figure 4
Answer5: I find the segment that contain HTTP POST command which contians the TCP packet
with a sequence number of 164041 and an ACK number 1 as shown in the figure below.

Figure 5

Answer6: Suppose the HTTP POST segment is the first one in the trace, then the first sequence
number will be “164041”, the second sequence number will be “164042”, the third sequence
number will be “164043”, fourth will be “164044”, fifth will be “164045” and sixth will be
“164046” as shown in the below image.

Figure 6

First of all, the HTTP POST packet will be sent and When the destination system receives it, it
will send an ACK packet to the source. Each packet will be sent after the ACK packet of the first
send segment was received. The ACK packet for each packet will be received after receiving the
pervious segment. The below are the sequence numbers of the six packets.

 Packet-1 sequence no: 164041

 Packet-2 sequence no: 164042
  Packet-3 sequence no: 164043
 Packet-4 sequence no: 164044
 Packet-5 sequence no: 164045
 Packet-6 sequence no: 164046

The timestamp and flag field tells us when a TCP segment was delivered and when it was
acknowledged. i.e., for each packet the timestamp will be different as for the first packet RTT is
0.000084 seconds and for the second packet RTT is 0.09213 seconds, for third packet RTT is
0.058416 seconds, for fourth RTT is 0.007943 seconds, for the fifth packet RTT is 0.005345
seconds and for the last packet RTT is 0.189966 seconds as shown in the below figures.

Figure 7

The second RTT is 0.09213 seconds as shown below.

Figure 8

The third one RTT is 0.058416 seconds as shown below.

Figure 9
The last one RTT is 0.189966 seconds as shown below.

Figure 10

The below figure shows round trip time graph for the captured file.

Figure 11

Answer7: The length of the first, second, third and sixth TCP segments is 0 and for the fourth
segment the TCP segments length is 565 and for the other five segment the TCP segments length
1460 as shown in the below screenshots.
 Figure 12

4th TCP Segment Length

Figure 13

6th TCP Segment Length

Figure 14
Answer8: Gaia.cs.umd.edu has a minimum available buffer of 17520 bytes for the whole trace.
This is shown in the TCP three-way handshaking ACK segment below.The recipient has
different buffer sizes. When looking at this trace, the transmitter is not throttled since the
recipient's buffer capacity is insufficient.

Figure 15

Answer9: This trace file contains no retransmitted packets. This may be verified by inspecting
the trace file's TCP packet sequence numbers. Each and every sequence number from the sender
(192.168.1.102:1161) to the destination (128.119.245.12:80) in this trace file's Time-Sequence-
Graph grows exponentially with time. Sequence numbers should be smaller than the sequence
numbers of adjacent packets when a packet is retransmitted.

Figure 16
Answer10: In most cases, the receiver confirms receipt of data by sending back an ACK. By
applying the filter (tcp and not tcp.len==0) in wireshark I filter all the TCP ACK packets and the
filter display 123 packets which are given below in the table.

Acknowledged Sequence Number Serial NO

565 1 ACK1

1460 566 ACK2

1460 2026 ACK3

1460 3486 ACK4

1460 4946 ACK5

1460 6406 ACK6

1460 7866 ACK7

1147 9013 ACK8

1460 10473 ACK9

1460 11933 ACK10

1460 13393 ACK11

1460 14853 ACK12

…… …… ……

…… …… ……

272 163769 ACK123

 Figure 17

Answer11: The calculation of TCP throughput hangs on mostly on the choice of the average
time. In this case, the average time may be used as the entire connection duration as is standard
practice when calculating bandwidth. After then, the ratio of total data to total transmission time
is used to determine the average TCP link throughput. 164,091 = 164,090 bytes is the entire
quantity of data. If the initial TCP packet took 0.026477 seconds to send and the last ACK
packet took 0.0248 seconds to receive, then the total amount of transmission time is 0.0248
seconds (5.455830 sec for packet number 202). The entire broadcast time is thus 5.455830 /
0.026477 = 5.4294 sec. As a result, 164090 / 5.4294 = 30.222 Kbps is the TCP link's throughput.
Answer12: Noticing the graph, one can notice that the steady start stage ends only the first 11.5
seconds. Then the TCP session appears to be always in a crowding resistance phase. As a result,
we miss the anticipated build-up behaviour in this phase, which means the TCP transmission
window does not maximise linearly. Rather of sending six-packet messages, it seems the sender
is sending six-packet messages. As the issued receiver window exceeds 5 packets, it seems that
this is not a flow control issue. This conduct may be because the HTTP server has set some sort
of speed limit as shown in the below screenshot.

Figure 18