February 2019, Reading time: 6 minutes
In this post we will use wireshark to analyze an http connection, where a client requests a single webpage from a server. Here is the output of the capture. you can do right click, open in a new tab, to see full size image.
if you want to download the pcap file click here
This is very obvious because I have as source an internal IP address, but I could have figured it out from the time interval between SYN, SYN-ACK and ACK.
Time between SYN and SYN-ACK is 0.214
Time between SYN-ACK and ACK is 0.000110
So the capture is obviously at the source. In order to see the time or delta between displayed packets you have to go to View, Time Display Format, Seconds since previous displayed packet
Because we are capturing at the source the RTT is the time between SYN and SYN-ACK which is 0.214. Othwerwise I would look at the time between SYN-ACK and ACK. If we captured somewhere in between, the RTT would be (ACK - SYN) / 2
In the beginning the client sends a SYN request. The important this to note is the options section. It supports an MSS of 1460, a window size of 8192 (hex 2000) with a scaling factor of 2 (hex 02) (multiply by 2^2=4) and selective acks.
The server responds with a SYN-ACK with window size 29200 (hex 7210), scaling factor 8 (hex 08, multiply by 2^8=256) Len=0, MSS=1452 and SACK permitted.
You can see also that although the tcp length is 0, the client and the server increase the sequence number by 1. this is called phantom byte.
The client sends an http request, packet 4, requesting a GET / http/1.1 (this is the root document). This packet has an initial sequence number of 1 and 709 bytes segment length. So the next sequence number should be 710 and the ack from the server should be 710.
Indeed packet 5 from the server is a packet with seq 1 and ack 710 length 0. Because the server didn’t manage to send any data yet, it sends an empty ack, otherwise the ack would be piggybacked in the data.
packet 6 is again from the server with seq 1 (since the previous packet had length 0), ack 710, length 1452
packet 7 is again from the server with seq 1453 (1452+1), length 1452, acks 710 (the client hasn’t sent anything new)
packet 8 client sends a packet with seq 710 (710+0), ack 2905 (1453+1452), and length 0
packet 9 server sends a packet with seq 2905 (1453+1452), acks 710 (710+0), and length 1452
packet 10 server sends a packet with seq 4357(2905+1452), acks 710(client hasn’t send anything), and length 1452
packet 11 client sends a packet with seq 710 (710+0), ack 5809 (4357+1452), length 0
packet 12 server sends a packet with seq 5809 (4357+1452), acks 710(710+0), length 1452
packet 13 server sends a packet with seq 7261 (5809+1452), acks 710(710+0), length 1452
packet 14 client sends a packet with seq 710 (710+0), acks 8173(7261+1452), length 1452
packet 15 server sends a packet with seq 8173 (7261+1452), acks 710(710+0), length 1452
packet 16 client sends a packet with seq 710 (710+0), acks 10165(8173+1452), length 0
packet 17 server sends a packet with seq 10165 (8173+1452), acks 710(710+0), length 1452
packet 18 server sends a packet with seq 11617 (10165+1452), acks 710(710+0), length 1452
packet 19 client sends a packet with seq 710 (710+0), acks 13069(11617+1452), length 0
… and so on
packet 35 is HTTP/1.1 200 OK.
whether the packet http OK will appear at the end of the all the reassembled pdu or in the beginning depends on the parameter “allow subdissector to reassemble tcp streams”.
This affects also the http.time that is calculated by wireshark. if you expand the http protocol you will see a field calculated by wireshark that says time since request 0.483secs. Request in frame: 4. If we have “allow subdissector to reassemble tcp streams” off, the http response time is 0.2578
so if we want to calculate http response times, in order to find when the http server responded late, it is advised to turn reassemble off. Then we can set a filter like http.time >= 0.3 to show all the http responses where the server took more than 0.3 secs to return an HTTP OK message.
packet 37 client sends a FIN-ACK with seq 710, length 0
packet 38 server sends a FIN-ACK, with seq 28100, ack 711, length 0
packet 39 client sends an ACK seq 711, ack 28101, length 0
As you can see the FIN increase the sequence number by 1 as just as the SYN
From statistics - conversations, we can see that the server sent to client 23 packets and 29k bytes while the client sent 16 packets and 1585 bytes. the total duration was 2.3 secs
From statistics - packet lengths, we can see the various packet lengths and the averages
From statistics - IO graph, the packets per second. int the first second we have 36 packets and the rest 3 packets (fin, fin-ack, ack) in the other second. this is obvious if you change the time display to seconds since beginning of capture
From statistics - http - packet counter, from an application protocol perspective, you can see that I only had one http request GET / and one http response 200 OK
From statistics - sequence numbers - stevens graph, direction from server to client, we see there was a delay between packet 20 and 22. from wireshark we can see this delay is 0.683-0.490=0.193. this is not due to tcp window size, because the window size on the client remains constant around 66792
from statistics - sequence numbers - tcptrace, we see that the distance between the two lines, that corresponds to the window size is arround 66000, as much as the window advertised by the client. We also see the delay between packet 20 and 22
I have zoomed on this graph. you can see that the first vertical line at around 0.49 corresponds to packet 20 which has sequence number 13069 and length 1452. the next packet from the server is packet 22 at 0.68secs and tcp sequence number 14521 (13069+1452)
For more information on understanding tcptrace graphs in wireshark, I recommend packetbomb http://packetbomb.com/understanding-the-tcptrace-time-sequence-graph-in-wireshark/