TCP three-way handshake

TCP three-way handshake flow chart:

Description of the TCP three-way handshake process (refer to the figure above):

1. Initial state:

First, both the client and the server are in the CLOSED state. The client will call the connect function to open the connection, and the server will call the listen function to be in the LISTEN state.

2. The first handshake

The client establishes a socket and calls the connect function. At this time, it will send a connection request message to the server. The SYN field in the message is set to one, and an initial sequence number seq=x will be selected at the same time, and then the client will enter the SYN_SENT state.

TCP stipulates that the SYN segment (the segment with SYN=1) cannot carry data, but it needs to consume a sequence number

3. The second handshake

After the server receives the client request message, if it agrees to establish a connection, it will confirm the message. In this message, the ACK bit and the SYN bit are one, the confirmation number ack=x+1, and it will also initialize a serial number for itself. seq=y, at this time the server enters the SYN_RCVD state

This packet also cannot carry data, but also consumes a sequence number

4. The third handshake

After the client receives the confirmation ACK, it will also send a confirmation message to the server, and then the client will enter the ESTABLISHED state. In this message, the ACK bit is one, and ack=y+ 1. TCP stipulates that the ACK segment can carry data, but if it does not carry data, the sequence number is not consumed. Therefore, if data is carried at this time, the serial number at this time is x+1. After the server receives the ACK, it will also enter the ESTABLISHED state. At this point, the TCP connection establishment process ends.

TCP three-way handshake related problems

1. Why three handshakes instead of two handshakes

<1> Two handshakes may cause the expired SYN segment sent by the client to be transmitted to the server, and the server allocates resources for it, wasting resources 

Assuming a 2-way handshake: 

• If the client sends the SYN segment A1 to the server, if there is a failure on the transmission link, the transmission time to the server is quite delayed. During this time period, the client does not receive the SYN segment A1 from the server. Confirmed, then a SYN segment A2 will be retransmitted
• Suppose the server receives the SYN segment A2 normally, and then returns ACK A2. Since there is no third handshake, the Client and Server have already established a connection at this time.
• Suppose that the SYN segment A1 is then transmitted to the server in the link. At this time, the server will return ACK A1, but since the client no longer recognizes A1, the client will discard the ACK A1, but the server will keep this equivalent to "zombie". "Connection. 

Therefore, if two handshakes are used, since A has not issued a request to establish a connection, it will not manage B's confirmation and will not send data to B. But B thinks that a new transmission connection has been established, and has been waiting for A to send data. Many of B's ​​resources are just wasted.

<2> Two handshakes may lead to deadlock

• The client sends a SYN segment A1 to the server to request the establishment of a connection, and the server returns an ACK A1 response segment. Since it is a two-way handshake, the server thinks that the connection is established successfully and can transmit data packets.
• If the ACK A1 response segment is lost during transmission, the client does not know whether the server agrees to establish a connection, and will ignore the data packet sent by the server and wait for the ACK. Repeated sending of this packet results in a deadlock.
• Regarding the statement of deadlock, I still have some doubts. I think this kind of deadlock does not occur in general, because the server will return an error after re-sending the packet for a certain number of times, and will not keep trying. For the client, since the ACK is not received, the connection request will be retransmitted, and the server will reprocess the request (such as processing the request through other processes and threads), and return the ACK again

Open links on both ends at the same time

In the case where two applications are actively opening each other at the same time, the ports on the two ends need to be consistent, which requires both parties to be familiar with the ports. The probability of this happening is very small. Here is a brief introduction.

Scenes:

1. The application of PC1 performs active open using port 7777 and port 8888 of PC2

2. The application of PC2 uses port 8888 and port 7777 of PC1 to perform active open

3. The SYN packet opens the opposite end at the same time, which means that it is opened at the same time

TCP中，对于同时打开它仅建立一条连接而不是两条连接 ，状态变迁图如下：同时发送SYN包，然后收到进行确认直接进入ESTABLISHED状态，可以看到同时打开需要连接建立需要4个报文段，比三次握手多一次！

参考：

《TCP/IP》详解卷1

博客：https://blog.csdn.net/qzcsu/article/details/72861891