Practical TCP Series - Sequence and Acknowledgment Numbers

This is the fourth TCP article in the 5-part “Practical TCP Series”. Every time we look at a TCP Header, we see sequence and ack numbers. What are these numbers? How can we use them to analyze application issues? Are there any tips and tricks with Wireshark to help? This article will answer these questions, and show how Wireshark can be used to better understand these numbers. What are the sequence and acknowledgement numbers?

Bottom line, these are 32 bit numbers used by TCP to track data that is sent, received, and outstanding. TCP keeps track of data by assigning a sequence number to each byte sent, then it uses the corresponding acknowledgement numbers to determine if any data was lost in transit. At the beginning of a TCP connection, each side will start by using an Initial Sequence Number (ISN) derived from a unique clock value from 0 to 4,294,967,295.

Note: By default, the Wireshark user interface will display these starting sequence numbers as zero, regardless of what these values really are. The purpose of this is to make sequence and acknowledgement number analysis simpler. These values will be referred to as relative sequence numbers to the connection.

How They Work We will use this picture to help learn this process:

Packet 1. Station A sends a SYN to Station B with a sequence number of 0. The Ack number is also zero. Packet 2. Station B starts its sequence number at zero and acknowledges Station A’s sequence number by adding a 1. Packet 3. Station A sends an ACK to Station B to acknowledge it’s starting sequence number. It also adds a 1 to the ISN. Packet 4. Station A sends a GET request to Station B. This request is 100 Bytes long. The sequence number for station A starts at 1, but this packet has 100 Bytes of data in it. We add the amount of data sent to the current sequence number, then we get the next expected sequence number, 101. Packet 5. Station B responds to the request from Station A. Since B has not sent data yet, its sequence number is still at 1. However in order to acknowledge receipt of the 100 bytes from Station A, it sends an acknowledgement number of 101. This packet contains 200 bytes of data, not including the IP and TCP headers. The next expected sequence number for station B will be 201. Packet 6. Station A sends another request containing 50 bytes. It is now at sequence number 101 to start. The next expected sequence number should be 151 (101 + 50 = 151). It acknowledges the 200 bytes sent by station B by sending an ack number of 201. Packet 7. Station B responds to the request with a 1000 byte packet. The starting sequence number is 201, so the next expected sequence number is 1201. It successfully received the 50 bytes from station A, so it acks with 151. And so on… The two machines will use these sequence numbers to track what has been sent and received. Remember that each side maintains its own sequence numbers. There is no running total for both sides of the conversation in a single sequence number. Using these sequence numbers, we can see gaps in data where traffic was lost. For example, we may see traffic for sequence numbers 0-1000, then miss a few packets, and see another packet with a sequence number of 1500. Where are the missing 500 bytes? Wireshark does a great job of flagging these packets as out-of-order or “previous packet lost”. Wireshark also has a very useful chart for graphing out sequence numbers called the “Stevens Graph”, available under Statistics | TCP Stream graph. This graph makes gaps in data and retransmissions very clear. In the chart below, we graphed the sequence numbers from a backup server during the backup and we could clearly see the gaps in transmission. This should be a solid line!

Using these graphs for sequence numbers, we can track down the exact point during a data transfer where the data stream delays. Understanding how sequence numbers and acknowledgment numbers work within TCP is critical when analyzing data transfer. To keep this article from getting too long, we will examine more specific problems in future articles. For now, if you have any questions, comments, or need any clarification on sequence and acknowledgment numbers, feel free to comment below. Thank you for reading and the last article in the TCP Series will be up soon!