Tcp – Why is there a need of an ACK from initiater in a TCP connection

layer4tcp

Question is not a duplicate of this link. As that asks why we need a 3 way hand shake and I know why! my question is why cannot the ACK packet be accommodated by the following protocol packet(PSH ACK).

I get why is there a need of an handshake, but do we need the ACK in the end from the initater? Lets take an example of an http query which was followed by a TCP handshake.

CLIENT:23434 SN 0 -----> SERVER:80 -- SYN
CLIENT:23434 <----- SERVER:80 SN 0, AN 1 -- SYN ACK
CLIENT:23434 SN 1 AN 1 -----> SERVER:80 -- ACK
CLIENT:23434 SN 1 AN 1 -----> SERVER:80 -- PSH ACK(HTTP GET)

Now if there was to be a protocol(data) packet followed by the ACK of three way handshake with the same sequence number and acknowledgement number, Why have the ACK packet why not use the protocol packet only to synchronize?

Best Answer

Great question. I agree that this is not a duplicate of the other.

The goal of the three-way handshake is to establish a bidirectional communication channel. The communication that happens within that channel is outside the scope of TCP.

Sometimes, a connection is established for the Client to send something to the Server. Other times a connection is established for the Server to send something to the Client. TCP must account for both of these cases.

Re-quoting your communication illustration for simplicity and adding line numbers:

#1   SN 0 -----> SERVER:80 -- SYN
#2   <----- SERVER:80 SN 0, AN 1 -- SYN ACK
#3   SN 1 AN 1 -----> SERVER:80 -- ACK
#4   SN 1 AN 1 -----> SERVER:80 -- PSH ACK(HTTP GET)

If the protocol using TCP behaves like HTTP, where the first data transmission after the connection establishes is the Client sending data to the Server, then you're right to say the lone ACK (line #3) seems superfluous. The packet immediate following (line #4) would suffice tell the Server that the Client received their ISN (from line #2).

However not all protocols behave like HTTP -- some protocols mean for the Server to send the data immediately after the connection establishes. In those cases, the server must wait for the client to send the empty acknowledgement packet before it comes to acquire positive confirmation that the bidirectional communication channel is successfully established and data transfer can begin.

This is more rare in the Internet, but it does exist. Offhand, I can think of Passive FTP, where the client initiates the data connection (aka, sends the initial SYN) but the purpose of the connection is for the server to send the initial data packet -- which starts as soon as the data connection is established.

TCP can not behave one way for certain protocols and another way for other protocols. Hence, the empty acknowledgement must be sent so that both scenarios are accounted for.

Related Topic