Tcp – Why does an pure ACK increment the sequence number

tcp

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

For example:

Host1 sends a SYN segment (seq = ISN(c), options) to Host2.
Host2 sends a SYN+ACK segment (seq = ISN(s), ACK = ISN(c)+1,
options) back to Host1.
Host1 sends the last ACK segment (seq = ISN(c) +1, ACK = ISN(s)+1)
to server to complet 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 header only. Why would its seq be different from that from segment 1?

Best Answer

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):

Related Solutions

Tcp – what happens (on the server) when a client does not respond to the SYN-ACK segment (second step) of the three-way handshake used in TCP

the server will periodically retransmit the syn-ack and eventually timeout and abandon the connection entry if the final ack is not received.

This does consume some RAM and is the subject of DoS attacks. However there are operating system mitigations available - in linux minisocks are used to keep the footprint down and after a certain point you can transition to syncookies which don't require any server side state during this period. (but they have downsides).

Tcp – How to understand the sequence number of segments in TCP termination process in TCP/IP Illustrated, Volume 1: The Protocols (2nd Edition)

It is clearly spelled out in RFC 793 Transmission Control Protocol, Section 3.5 Closing a Connection:

      TCP A                                                TCP B

  1.  ESTABLISHED                                          ESTABLISHED

  2.  (Close)
      FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  --> CLOSE-WAIT

  3.  FIN-WAIT-2  <-- <SEQ=300><ACK=101><CTL=ACK>      <-- CLOSE-WAIT

  4.                                                       (Close)
      TIME-WAIT   <-- <SEQ=300><ACK=101><CTL=FIN,ACK>  <-- LAST-ACK

  5.  TIME-WAIT   --> <SEQ=101><ACK=301><CTL=ACK>      --> CLOSED

  6.  (2 MSL)
      CLOSED

                         Normal Close Sequence

                               Figure 13.

The RFC is the definition of TCP, and textbooks may have errors (it happens all the time). It is a good idea to also study the RFCs of any protocols which you are learning.

Best Answer

Related Solutions

Tcp – what happens (on the server) when a client does not respond to the SYN-ACK segment (second step) of the three-way handshake used in TCP

Tcp – How to understand the sequence number of segments in TCP termination process in TCP/IP Illustrated, Volume 1: The Protocols (2nd Edition)

Related Topic