Computer network - three handshakes, four waves

TCP three-way handshake

1、The first SYN message:
The client randomly initializes the serial number client_isn , puts it into the serial number segment of the TCP header,
and then sets SYN to 1 . Send the SYN message to the server, indicating that the connection is initiated,
and then the client is in the SYN-SENT state.

2、The second message SYN+ACK message:
The server receives the SYN message from the client, puts its own serial number server_isn into the serial number segment of the TCP header , fills the
confirmation response number into client_ins + 1, and sets SYN+ACK to 1 .
Send the SYN+ACK message to the client , and then enter the SYNRCVD state.

3、The third message ACK:
After receiving the message from the server, the client will also respond to the server with the last response message .

• First, the ACK flag position of the first response message TCP is 1,
• Next , fill in server_isn + 1 in the " Confirmation Response Number" field ,
• Finally, send the message to the server,
  this time the message can carry the data from the client to the server, and then the client is in the ESTABLISHED state.
  After the server receives the response message from the client, it also enters the ESTABLISHED state

---

The process of three-way handshake:

• Initially, both client and server are in CLOSED state. The client actively opens the connection, the server passively punches in the connection, ends the CLOSED z state, starts listening, and enters the LISTEN state.

a handshake

• The client will randomly initialize the serial number (client_isn), put this serial number in the "serial number" field of the TCP header, and set the SYN flag to 1, indicating a SYN message .
• Then send the first SYN message to the server, which means to initiate a connection to the server . This message does not contain application layer data, and then the client is in the SYN-SENT state.

Second handshake

• After the server receives the SYN message from the client, the server first also randomly initializes its serial number (server_isn), and fills this serial number into the "serial number" field of the TCP header.
• Next, fill in the "confirmation response number" field of the TCP header into client_isn + 1, and then set the SYN and ACK flags to 1 .
• Finally, the message is sent to the client, and the message does not contain application layer data, and then the server is in the SYN-RCVD state.

three handshake

• After the client receives the message from the server, it needs to respond to the server with the last response message . First, the ACK flag in the TCP header of the response message is 1.
• Next, fill in server_isn + 1 in the "Confirmation Response Number" field,
• Finally, send the message to the server, this time the message can carry the data from the client to the server , and then the client is in the ESTABLISHED state.

---

Well, after the three-way handshake process, the connection between the client and the server is determined to be normal, and then enters the ESTABLISHED state, and the server and client can communicate happily.

Why is there a three-way handshake?

Summarize:

1. The three-way handshake can prevent the initialization of repeated historical connections (the main reason)
2. Three-way handshake can synchronize the initial serial numbers of both parties
3. Three-way handshake can avoid resource waste

Explanation:
1. Prevent the initialization of repeated historical connections (the main reason)

1. When the old SYN message arrives at the server first, the server returns an ACK+SYN message
2. After receiving it, the client can judge that this is a historical connection (serial number expired or
   timed out then the client will send an RST message to the server, indicating that the connection is terminated .

The two-way handshake begins to generate data after receiving the response from the server, and it cannot be judged whether the current connection is a historical connection.

The three-way handshake can determine whether the current connection is a historical connection because the client has enough context when the client is about to send the third message.

The client sends multiple SYN (all the same four-tuple) messages to establish a connection. In the case of network congestion:

• An "old SYN message" arrives at the server earlier than the "latest SYN" message, then the server will return a SYN + ACK message to the client, and the confirmation number in this message is 91 (90 +1).
• After the client receives it, it finds that the confirmation number it expects to receive should be 100 + 1 instead of 90 + 1, so it will return a RST message.
• After the server receives the RST message, it will release the connection.
• After the latest SYN arrives at the server, the client and the server can normally complete the three-way handshake.

The "old SYN message" mentioned above is called a historical connection. The main reason why TCP uses a three-way handshake to establish a connection is to prevent the "historical connection" from initializing the connection.

---

If it is a two-way handshake connection, the historical connection cannot be blocked, so why can't the TCP two-way handshake prevent the historical connection?

Let me directly talk about the conclusion, mainly because in the case of two handshakes, the server has no intermediate state for the client to prevent historical connections, which may cause the server to establish a historical connection, resulting in waste of resources .

Think about it, in the case of two handshakes, the server enters the ESTABLISHED state after receiving the SYN message, which means that it can send data to the other party at this time, but the client has not yet entered the ESTABLISHED state at this time.

• Assuming this is a historical connection, and the client judges that this connection is a historical connection, it will return an RST message to disconnect.
• The server enters the ESTABLISHED state during the first handshake, so it can send data, but it does not know that this is a historical connection, and it will only disconnect after receiving the RST message.

It can be seen that if two handshakes are used to establish a TCP connection, the server does not block the historical connection before sending data to the client, causing the server to establish a historical connection and send data in vain. A waste of resources on the server side.

Therefore, to solve this phenomenon, it is best to block the historical connection before the server sends data, that is, before the connection is established, so as not to cause waste of resources. To realize this function, three handshakes are required.

Therefore, the main reason why TCP uses a three-way handshake to establish a connection is to prevent the "historical connection" from initializing the connection.

2. Synchronize the initial serial numbers of both parties
Both parties of the TCP protocol must maintain a "serial number", which is a key factor for reliable transmission.

• The receiving end can deduplicate data.
• The receiving end can receive in sequence number order.
• Identify sent packets and which ones have been received.

In this way, the initial sequence numbers of both parties can be reliably synchronized.

3. Avoid wasting resources.

1. The two-way handshake will cause message retention, and the server will repeatedly accept useless connection request SYN messages, resulting in repeated allocation of resources.
2. When there are only two handshakes, if the client's SYN request connection is blocked in the network and the client does not receive the ACK message from the server, it will resend the SYN.
3. Since there is no third handshake, the server does not know whether the client has received the ACK confirmation signal sent by itself to establish a connection
   , so every time a SYN is received, it can only actively establish a connection

---

process

1. The client sends the first packet, a SYN packet carrying the client's initial sequence number.
2. The server sends the second message, which carries the ACK + SYN response message of the server's initial sequence number ,
   indicating that it has received the SYN message from the client.
3. The client sends the third message, which carries the server's ACK response message.

---

TCP four wave process

disconnection process

1. Assuming that the client intends to close the connection, it sends a FIN packet with the TCP header FIN set to 1 to the server .
2. After the server receives it, it sends an ACK response message to the client .
3. After waiting for the server to process the data, send a FIN message to the client .
4. After receiving the FIN message, the client returns an ACK response message.
5. After the server receives the ACK message, it enters the close state, and the server completes the connection closing .
6. After a period of 2MSL, the client automatically enters the close state , and the client also completes the closing of the connection.

Why do you need to wave four times?

When closing the connection, the client sends a FIN message, indicating that it no longer sends data, but can still receive data .

When the client receives the FIN message, it first returns an ACK response message , and the server may still need to process and send data.

Wait until it no longer sends data before sending a FIN message to the client to express agreement to close the connection .

From the above process we can see that:

1. The server usually needs to wait for the completion of sending and processing the data, so the ACK and FIN of the server are generally sent separately, resulting in one more handshake than the three-way handshake .

2. The first ACK response message can be omitted, because the next message segment carries ACK information, and whether ACK occurs depends on the delayed acknowledgment feature.

3. Delayed acknowledgment: After receiving the packet, if the receiver has no content to reply to the sender, it will delay for a period of time before confirming. If there is data to be transmitted within this time range, it will reply with the confirmation packet. This is also known as data piggybacking . Delayed confirmation only reduces the burden on the network, and may not improve network performance, and in some cases it will affect performance.

Why is the waiting time of TIME_WAIT 2MSL?

1. MSL is the Maximum Segment Lifetime, the maximum lifetime of a packet . It is the longest time any packet exists on the network. After this time, the packet will be discarded.

2. Wait twice for the MSL: There may be data packets from the sender in the network. When these data packets from the sender are processed by the receiver, they will send a response to the other party, so it takes twice as long to wait .

3. The time of 2MSL starts from the time when the client sends ACK after receiving FIN .
   If within the TIME-WAIT time, because the client's ACK is not transmitted to the server, and the client receives the FIN message resent by the server, then the 2MSL time will be reset.