I cannot figure out why a pure ACK will increment the sequence number of the sending host by 1 when the TCP segment contains only a header, such as in the third segment in a three-way handshake for establishing a TCP connection.

For example:

  1. Host1 sends a SYN segment (seq = ISN(c), options) to Host2.
  2. Host2 sends a SYN+ACK segment (seq = ISN(s), ACK = ISN(c)+1, options) back to Host1.
  3. Host1 sends the last ACK segment (seq = ISN(c) +1, ACK = ISN(s)+1) to server to complete the handshake.

But there is no data contained in the 3rd segment, meaning Host1 does not inject more bytes into the communication path. What is being sent is the header only. Why would its seq be different from segment 1?

  • 1
    TCP knows nothing about clients and servers, it connects peers. The client/server concept is an application-layer concept, which is off-topic here.
    – Ron Maupin
    Mar 6, 2018 at 0:54
  • 3
    It is the SYN in the 2nd segment which is incrementing the ACK in the third. Not the ACK in the 2nd segment. A TCP header which only consists of the ACK will not increment the SEQ/ACK. This answer may provide more details.
    – Eddie
    Mar 6, 2018 at 1:00

2 Answers 2


It isn't necessarily the case that the third segment contains no data. From Data Communications and Networking (Forouzan):

Note that the ACK segment does not consume any sequence numbers if it does not carry data, but some implementations allow this third segment in the connection phase to carry the first chunk of data from the client (emphasis mine). In this case, the segment consumes as many sequence numbers as the number of data bytes. An ACK segment, if carrying no data, consumes no sequence number.

I found the answer to your question in Computer Networking: A Top-Down Approach (Kurose and Ross):

Upon receiving the SYNACK segment, the client also allocates buffers and variables to the connection. The client host then sends the server yet another segment; this lasts segment acknowledges the server's connection-granted segment (the client does so by putting the value server_isn+1 in the acknowledgement field of the TCP segment header). The SYN bit is set to zero, since the connection is established. This third stage of the three-way handshake may carry client-to-server data in the segment payload.

There's a diagram on the following page that the explanation refers to (the one below isn't from the book, but the idea is the same):

TCP three-way handshake: segment exchange


The base logic of SYN is "let's agree that I've sent byte X last" (ISN). The base logic of ACK is "please send byte Y next".

Accordingly, the first ACK needs to be ISN+1.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.