The TCP three handshake protocol is designed to reliably establish a connection in an unreliable Internet environment, and the three handshakes ensure that both ends are capable of sending and receiving.So why three instead of two or four handshakes?
Why not a second handshake?
In the case of a quadratic handshake, where the client sends a SYN to the server and the server replies with a SYN-ACK to the client, the connection is established at that point.
In this case, if the first SYN request is delayed in the network and the connection is established after the client resends the SYN, then when the delayed SYN request reaches the server, the server assumes that it is a new connection request, and at that point the client pays no attention to the server’s response, causing the server to keep on waiting and wasting resources.
Why not four handshakes?
Four handshakes add additional latency and complexity, and a fourth handshake doesn’t provide any additional assurance that three handshakes have solved the problem.
Three handshakes are already able to confirm that the sending and receiving capabilities of both parties are normal, and further confirmations would only add a round trip time and reduce the efficiency of establishing a connection.
Three handshakes to establish a connection:
- Client sends SYN: The client selects a random sequence number x to send a SYN message and enters the SYN_SENT state.
- Server sends SYN-ACK): the server receives the SYN message, selects its own sequence number y, and sends a SYN-ACK message, and the server enters the SYN_RCVD state.
- Client sends ACK: the client receives the SYN-ACK message, sends an ACK message, and then enters the ESTABLISHED state.
Four hand waves after the end of a data transmission:
TCP connection termination, on the other hand, requires four hand waves, this is because a TCP connection is full duplex, i.e. both sides of the communication can send and receive information at the same time. When terminating a connection, each direction needs to be closed individually, so four waves are required.
- Client sends FIN: the client decides that the data has been sent and sends a FIN message.
- Server ACK: the server receives this FIN message, sends an ACK message to acknowledge it, and enters the CLOSE_WAIT state.
- SERVER SEND FIN: The server sends a FIN message when it is ready to close the connection.
- Client ACK: When the client receives the FIN, it sends an ACK message and then enters the TIME_WAIT state. After a period of time to ensure that the server receives the ACK message, the client closes the connection.
Life example:
You can compare the three handshakes to a telephone conversation. When you dial a phone number, the other person answers (the first handshake), you start greeting each other to make sure the other person can hear you (the second handshake), and then you start a conversation (the third handshake).
If you greet each other only once, you may not be sure the other person actually heard you; if you greet each other multiple times, it’s redundant and inefficient.
At the end of the call, you hang up when you say “goodbye” (the first wave), and the other person hangs up when they say “goodbye” (the second wave), thus ensuring that both parties understand that the call is over.
At the end of a phone conversation:
You first say “Do you have anything else, no I’m going to hang up” (the first wave), waiting for the other party to respond, which is equivalent to sending a FIN packet.
The other party responds “Let me think about what else” (second wave), which is equivalent to the other party sending an ACK packet, but the other party may still have some things to deal with, so the call is not immediately ended.
After a while, the other party confirms, “OK, I have nothing more to say, so hang up” (third wave), then the other party sends a FIN packet.
You respond with “Got it, hang up” (the fourth wave of the hand), corresponding to the ACK packet, after which both parties can hang up and end the call.