Understanding TCP Sequence and Acknowledgment Numbers

Fun fact: the 3-way hanshake can be in fact a four way handshake - see here (although I don't believe that it is implemented like that anywhere):

http://www.breakingpointsystems.com/community/blog/tcp-portals-the-handshakes-a-lie/

Great stuff Jeremy! Excellent explanation of TCP operation PLUS how to use Wireshark features to examine and learn about how a protocol works. Expect a flood of hits from my students!

Aubrey

Hi Jeremy,

Great article.

When I studied TCP first, I was thought that ack no. is the next byte receiver is expecting. i.e if ack no. is 726 that means, receiver received 725 bytes of data and sender can send data starting from 726th byte.

So to me this sentence doesn't make much sense:

"Notice that the acknowledgment number has been increased by 1 although no payload data has yet been sent by the client. This is because the presence of the SYN or FIN flag in a received packet triggers an increase of 1 in the sequence."

As it seems to me that is is expecting data stream starting from byte 1. So Ack no. is not increased.

Though the meaning is same.

PS: Thank you for the demo of ability of wireshark. I still don't know much abt this tool.

@Mimo: In this instance, as is typical with network protocols in general, our counter is zero-indexed; the first byte is byte 0, not byte 1. the SYN flag increases the counter by one to 1, which is actually the second possible value.

Hope that helps.

Mimo, you are correct. Do a search on google for TCP phantom byte and that will explain why there is an increment of 1 in the setup and teardown processes.

Also check out Laura Chappells WireShark training, good stuff.

http://support.novell.com/techcenter/articles/nc2001_05e.html

Note. During the TCP startup and teardown sequence, a "phantom byte" causes the sequence number and acknowledgment number fields to increment by 1 even though no data is exchanged. This phantom byte can be confusing when you have just learned that the sequence number field increments only when data is sent.

G'day,

Great post! I've just recently started down the road to CCNA having always been interested in networking. I've used wireshark in the past for very basic troubleshooting, but this is a nice deep (comparitivley speaking!) look at TCP.

One question: packet 36 contains a PSH or push flag. What is this in relation to the HTTP stream?

Cheers,
Adam.

Thank you yohan900 and stretch for the information!!

@ tormentum
http://support.microsoft.com/kb/169292
If the PUSH bit set, data will be delivered up to the application right away, but the ack may still be delayed.

Hope this helps....

It would have been much better to call this a "Three-step handshake" or "Three-phase handshake". To me, "Three-way handshake" implies that here are three different parties shaking hands when in fact it is a method that requires three steps for two parties to communicate.

Just an observation . .

Hi, So if client is sending a data over different TCP segments the acknowledge number on client side will not increase untill all the data has been sent over..???

I have a client which sends data to server and when I capture it I see the data is not in single IP datagram but I see that the whole data sent to server spans over multiple TCP segments and in Two IP datagrams.

My questions is if I need to collect all the data sent by client to server how do I reassemble them at TCP lever. I am capturing IP packets which encapsulates TCP....

Thanks,
Angelo

Hi,
This is good stuff, but why didn't u talk about packet#36 and packet#37? If those are also added to this article, then this will be more useful for beginners.

Thanks,

Natraj.

Good tutorial, many thanks for it.

Why does wireshark keep displaying len=0 for each tcp segment ?

A good explanation on TCP basics. Your decision to use relative numbers is clear, but I always tend to stick with actual numbers in the 3-way handshake part. This is to emphasize my students that both ends use their own, independent seq numbers that gets increased while data flow goes on. It's easy to mix them when both start from zero, as is the case with wireshark using relative seq numbers.

Keep up the good work!

Great Explanation !!! It cleared most of the doubts that I had.

Earlier my assumption was the sequence number would be sequential and I did not know that Acknowledgement was related to the amount of bytes transferred. But you made it clear. Thanks a lot.

Excellent explanation. I was just hunting for this type of explanation on the complete cycle of TCP packet. Got more interest after reading this article.

Thank you very much Jeremy.

Thank you Jeremy it is a great article!

Looking at the connection termination:

"The server acknowledges the client's desire to terminate the connection by increasing the acknowledgement number by one (similar to what was done in packet #2 to acknowledge the SYN flag) and setting the FIN flag as well."

Please share your thoughts on this because I thought that the ACK and FIN can not be combined in the same segment because the the server might still be processing a transaction and not ready to close yet so it waits until it finishes processing those transactions before setting FIN flag. Thus it is a way hand shake when tearing down a connection.

Hi, thanks for this great tutorial, have an exam in a few days and this had made things a lot clearer although realy, I didn't need to go this much is depth.

Thank you.

After a zillion sites I finally understand the concept of ACK numbers. Your step by step break down of the diagram was key for me. Note: I'm going to a very well-known University and none of their material explains this concept like you have done.

The following was what did it for me:
"Packet #: 7 The sequence number of the client has been increased to 726 because of the last packet it sent. Having received 1448 bytes of data from the server, the client increases its acknowledgement number from 1 to 1449.

For the majority of the capture, we will see this cycle repeat. The client's sequence number will remain steady at 726, because it has no data to transmit beyond the initial 725 byte request. The server's sequence number, in contrast, continues to grow as it sends more segments of the HTTP response."

I realized that the server could send more than the client requested. We were asked to break down 8 packets into a diagram and explain their movements, in Wireshark, with several criteria. In ALL of their examples the server NEVER sent more data. After 3 hours I was ready to blow.

Thanks for your posting.

Thanks, this gives an intuitive understanding of TCP/IP.

Thanks
Regards
Mohsen hs

Thank you so much for providing the knowledge about TCP.
this is really helpful and much more deep than i expected.

cheers
jatin.

This made it much clearer for me, thank you. How's the Lab coming? Hope your having a good 2013.

-Hatcreek

It's the first post / article I've read about the subject that is clear and understandable.

Thanks

Jeremy,

You simply rock dude lml !

Hi,

Your blog entries are very clear and clears the basic concepts going under these complex protocols. Thanks for the good explanation, this helped me to concrete my idea about how the TCP communication works.

Warm Regards,
Haridas N.

Hi, thanks a lot, nice post.

BTW Professor Philip Levis in the "Introduction to Networking" Fall 2012 Stanford Online course explains (Week 3, Tcp Header lecture) that the TCP ack number is the last received byte PLUS ONE, that is refers to the next byte that one wants to accept, not the last byte received.

Kind of helps to grasp the counts.

Keep up the good work,
Guest

FYI, the use of an apparently random number for the initial sequence number is not a bug in Wireshark and is a very intentional implementation detail.

See http://tools.ietf.org/html/rfc1948 but, in brief, making the sequence number less predictable helps to prevent certain types of malicious attacks.

See also the wiki page on TCP: http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Reliable_transmission

"In the first two steps of the 3-way handshake, both computers exchange an initial sequence number (ISN). This number can be arbitrary, and should in fact be unpredictable to defend against TCP sequence prediction attacks."

I didn't understand this under packet #3-

At this point, the sequence number for both hosts is 1. This initial increment of 1 on both hosts' sequence numbers occurs during the establishment of all TCP sessions.

I guess the SEQ # of Server is still 0.

I know that in packet # 3 (from client) ACK = 1 still how does it increment the SEQ # at the server side?

Great article!

What you write about SEQ N and ACK N and how they are incremented is not written in any TCP article I read, but that's exactly how "real" TCP works!

Thank you so much!!!

superb article!

its clear your all doubt and also provides you basic ideas.
Thankx man

You know that moment when something just all of a sudden makes complete sense? Yeah, reading this article gave me that moment!

Thank you!

Nice stuff!

Can someone explain why in the packet #4 (HTTP GET) the sender has the ACK flag bit ON. Is that mandatory? I have noticed the same for the packet #38. I have been trying to find a reference on how mandatory the ACK flag is but can't find.

Thank you Jeremy for this blog, it's value won't be deprecated as long as TCP protocol is used.

Doubt: You mentioned that if the SYN/FIN bit is set in the received packet, the outgoing Ack no will be +1. I don't understand the statement in tear down process "acknowledges the server's FIN packet by incrementing the acknowledgement number by 1 to 22952" why is there a random increment of the last packet? Or Did i miss something?

Thanks for another great article.

I'd like to note, that some Cisco books explain Ack number a bit differently. In particular, Doyle's Routing TCP/IP states following:

"Acknowledgment Number is a 32-bit field that identifies the sequence number the source next expects to receive from the destination. If a host receives an acknowledgment number that does not match the next sequence number it intends to send (or has sent), it knows that packets have been lost."

This was quite helpful! I'm a developer and thought I knew all I needed to know about packet analysis -- boy was I wrong! After reading this post, I immediately signed up!

Thanks so much for sharing your knowledge!

Sincerely, Keith E. Cooper Tampa, FL.

Another explanation comes from Richard Stevens' TCP/IP Illustrated vol. 2: (slightly paraphrased):

Every byte of data exchanged across a TCP connection, along with the SYN and FIN flags, is assigned a seq. #. The seq # in a packet contains the number of the first byte in the seqment, which may be zero if the relative seq # starts at zero.

The ack # contains the next seq # the sender of the ack expects to receive, thus acknowledging all data up to the ack # minus 1. Thus, the ack # is the next seq # expected by the sender of the ack. The ack # is valid only if the ACK flag is set in the header.

I believe the inclusion of the SYN/FIN flags explains the "phantom byte" discussed elsewhere.

Excellent article! This really helped me refreshing my tcp knowledge for analysis!

If you need an idea for a new article, how about the SSL handshake explained in the flow chart? :)

Hi, Thanks for the post. I was wondering that in stop and wait the sequence number is one bit. Does this mean that out of 32 bit we only use one bit and rest 31 bits are useless. And we toggle this one bit sequence number from 0 to 1 and vice versa. If this is not true where does this one bit sequence number fits in the protocol itself.

Thanks for clearing my doubts in advance