Can you really explain TCP's three-way handshake and four-way handshake?

What is TCP

Before understanding the three-way handshake and four-way handshake, you must first understand what TCP is.

TCP is a connection-oriented, reliable, byte stream-based transport layer protocol.

• Connection: The so-called connection is actually the sum of state information that ensures reliability and flow control, including sokict, sliding window and sequence number.
• Reliability: TCP uses a series of control mechanisms such as sequence numbers, retransmission mechanisms, sliding windows, etc. to ensure that data is not duplicated, lost, and processed in order by the receiving end.
• Byte stream: TCP data is based on byte stream, so it is unbounded and can be infinitely large. TCP can send data to the receiving end in an orderly manner through a fragmentation mechanism.

TCP Structure

The TCP header is 20 bytes without the "option" field. It includes:

• 2-byte source port
• 2-byte destination port
• 4-byte sequence number
• 4-byte confirmation sequence number
• 4-bit header length
• 6-bit reserved field
• 6-bit flags (SYN, ACK, RST, FIN, URG, PSH)
• 2-byte window size
• 2-byte checksum
• 2-byte urgent pointer

It should be noted here that the "Option" field is used to assist in solving reliability issues. Because the length of this field is uncertain, the "Header Length" field is needed to indicate the length of the TCP header.

TCP three-way handshake process

What is a three-way handshake

TCP is connection-based, so a connection must be established before it can be used. The process of TCP establishing a connection is based on a three-way handshake.

• First, the server application listens to a port, that is, establishes a Socket in the listened state, and the server is in the listening state.
• When a client creates a socket and calls the connect function to connect to the server, it sends a TCP packet with a SYN state of 1 to the server, carrying its own random sequence number. The client is in the syn_send state.
• After receiving the SYN message, the server will create a connection and put it into the semi-connection queue of the current socket, and then reply with an ACK+SYN message with its own random sequence number and confirmation sequence number (client sequence number + 1). The server is in the syn_recv state.
• After receiving the ACK from the server, the client will process it and send an ACK message to the server with the confirmation sequence number (server sequence number + 1). At this time, the client is in the establisten state.
• After receiving the ack message, the server will put the connection in the semi-connection queue into the full connection queue and then enter the establishlisten state.

At this point, the TCP connection is established. Note that data can be transmitted after the third handshake. Data cannot be transmitted before this.

Why three-way handshake?

Generally, everyone thinks that the three-way handshake is to ensure that both the client and the server can confirm that they have established a one-way connection with the receiving end and that they can send and receive data successfully.

This answer itself is not wrong, but it is too crude.

Since the handshake is to ensure the establishment of the connection, we must first know what a TCP connection is.

A TCP connection is the sum of state information that ensures reliability and flow control, including sockets, sequence numbers, and sliding windows.

The sequence number is crucial here. It is the key to ensure that messages are not duplicated, lost, and in order. Therefore, the purpose here is to ensure the synchronization of the sequence number.

The client sends an initial sequence number to the server, and the server replies syn+ack, telling the client that the sequence number has been received and sending the server's initial sequence number to the client. After receiving it, the client also replies to the server to indicate that the sequence number has been received, so that both parties can ensure that the sequence numbers are synchronized.

But this is not the most important reason. The most important reason is to prevent the historical connection from being initialized and reconnected. For example, there is such a situation that the client sends a syn packet to the server, but the network is blocked and the server does not receive it, so the server will not reply. The client will resend the syn packet if it does not receive a reply, but at this time the server receives the first syn packet and replies to the client. At this time, the client will compare and verify whether this is the latest syn reply packet sent by itself. If not, it will send a rst packet to the server, indicating that it requires the server to terminate the connection. This is also the meaning of the three-way handshake.

If there is no third handshake, then after the above situation occurs, the server will create a connection for each syn request, and the connection needs to occupy memory, which will consume a lot of resources. This will cause a waste of resources, so the three-way handshake is necessary.

So is a four-way handshake possible?

A four-way handshake is also possible. In fact, the four-way handshake is that the client sends a syn packet to the server, the server replies with an ack packet, the server sends a syn packet to the client, and the client replies with an ack packet. The second handshake in the three-way handshake replies with a syn+ack packet, which is equivalent to merging the middle two of the four handshakes, so a three-way handshake is the best.

Four waves process

TCP is a bidirectional connection, so the connection in both directions must be disconnected.

1. Before disconnection, both the client and the server are in the ESTABLISTENED state.
2. The client calls the close method to disconnect the connection, and sends a fin packet to the server. The client is in the fin_wait1 state
3. After receiving the fin packet, the server will reply with an ack. At this time, the server is in the closed_wait state.
4. After the client receives the ack from the server, it means that it has disconnected from the server, but the connection from the server to the client has not been disconnected. The client needs to wait for the server to actively request to disconnect. At this time, the client is in the fin_wait2 state.
5. The reason why the server does not send a FIN packet to the client immediately is that the server may still have data to send, so the server needs to process the data to be processed before sending the FIN packet to the client. At this time, the data has been processed, and the server actively sends a FIN packet to the client. At this time, the server is in the last_ack state.
6. After receiving the fin packet, the client will reply ack to the server. At this time, the client is in the time_wait state.
7. After receiving the ack, the server sets the status to close.
8. The client will not directly enter the close state at this time, but will enter the time_wait state, which will last for 2MSL time.

In the world of network transmission, there are two values ​​used to indicate packet failure:

• MSL is the maximum survival time of a message in the network. If it exceeds this time, it will be discarded.
• TTL: There is a TTL field in the header of the IP layer to save the number of routes passed. The number will be reduced by 1 after each route passed. When it reaches 0, the data will be discarded.

Therefore, in general, MSL will be greater than the time it takes for TTL to decrease to 0.

Why is the MSL twice as high here?

Because when the client receives the fin packet from the server, it will reply ack to the server, but the client does not know whether the ack is sent successfully, so the client needs to confirm that the server has received it successfully before it can be set to the close state. How to confirm it? Because of the existence of the failed retransmission mechanism, if the server does not receive the ack due to network congestion, the server will send a fin again. An ack packet and another fin packet is 2 times the MSL. The timing of MSL starts from receiving the fin packet and sending the ack packet.

In addition to the above mentioned guarantee that the client's ack is sent to the server and is correctly received, it is also ensured that the party whose connection is being closed can be closed correctly.

It can also ensure that old connections blocked in the network are received when the port is reused, which will cause data confusion, and time_wait can ensure that all connections in the network are discarded.

The default MSL is 30 seconds. It should be noted that too many time_wait states will occupy memory resources and port resources, so it is not advisable to have too many.

Why four waves?

TCP is a two-way connection. The client sends a FIN packet to the server, and the server replies with an ACK. This is just the client telling the server not to send data to the server anymore.

The server also needs to tell the client that it will no longer send data to the client. In other words, the server also needs to send a fin packet to the client, and the client also needs to reply with an ack packet to the server. Only then can the server and the client enter the close state.

After the server receives the FIN packet sent by the client and replies with an ACK packet, it cannot immediately send a FIN packet to the sender because there may still be connections processing data. It must wait until the data is processed before sending a FIN packet to the client.

For this reason, the two middle steps cannot be combined like the three-way handshake.