4 way TCP handshake

  

Why TCP connection termination needs four-way handshake?



Note that the server sends two packets: ACK: 1 and SYN: 1 in sequence. Why not combine these two packets into one to have a better network performance?

We didn’t combine the ACK: 1 packet (marked as ②) and the FIN: 1 packet (marked as ③) into one packet.

The reason is ACK: 1 packet (marked as ②) is send by TCP stack automatically. And the next FIN: 1 packet (marked as ③) is controlled in application level by calling close socket API. Application has the control to terminate the connection. So in common case, we didn’t merge this two packets into one.

It’s flexible for the application to control this process, for example, in this way the application can reuse existing TCP connection to reduce the overhead and improve the performance.

In packet 2, the server Ack’s the client Fin bit but notice that the Ack # is not incremented by 1.  This means that the server is telling the client that it does not expect to receive any more data packets (since it’s received a Fin bit and the closing process has started.


Comments

Popular posts from this blog

TCP Keepalives & its sequence numbering

Why is the TCP Stack Dropping SYN Packets?

TCP FSM