Analysis of HTTP message #2

This is the analysis of the second frame which I posted in my first post 

2)  Timestamp 0.000044  I won’t describe everything that I already talked about in the first post instead only the necessary stuff.  2nd IP packet contains the TCP SYN-ACK segment which is the response of server side.

If you take a look at the first message with timestamp 0.000000, we can see that Len=0, which means there is no data sent but in the SYN-ACK segment we are acknowledging one byte by sending 2215066426 + 1 = 2215066427.  Why do we acknowledge something that we haven’t received? If you look at the definition of sequence number in RFC793:

A fundamental notion in the design is that every octet of data sent 
over a TCP connection has a sequence number

As far as I can see on the net but not on any RFC so far, it is called phantom byte (see :

3) Timestamp 0.000320

This is the last segment having ACK bit on that completes the three way handshake.
As it can be seen Sequence number incremented by one and Acknowledgement bit is set which acks the previous SYN-ACK segment’s sequence number. In this segment only ACK bit is set and look all other optional fields (i.e MSS,SACK) disappeared. They are available only in the first two SYN segments not in any other segment.
I have also drew a picture of the three way communication in which sequence number increments can be easily seen.
with this post, I am finishing the three way handshake. I will continue with the other TCP segments in another post.

About: rtoodtoo

Worked for more than 10 years as a Network/Support Engineer and also interested in Python, Linux, Security and SD-WAN // JNCIE-SEC #223 / RHCE / PCNSE

You have a feedback?

Discover more from

Subscribe now to keep reading and get access to the full archive.

Continue reading