It is easy to understand TCP's three-way handshake to establish a connection and the four-way handshake to release the connection.

It is easy to understand TCP's three-way handshake to establish a connection and the four-way handshake to release the connection.

Why do I wave three times when TCP establishes a connection?

Each TCP connection requires three phases: Connection establishment, data transmission, and connection release. The three-way handshake occurs in the connection establishment phase. In Xie xiiren's fourth edition of computer network, the three-way handshake aims to prevent the invalid connection request packet segment from being suddenly transmitted to the server, thus generating errors. In another classic book "Computer Network", the three-way handshake aims to solve the problem of network latency and repeated grouping. The two unused expressions clarify the same issue.

The example in Xie xiiren's computer network is as follows: the first connection request message segment sent by the client is not lost, but is stuck at a certain network node for a long time. As a result, it will arrive at the server at a certain time after the connection is released. This is a long-overdue packet segment. However, after the server receives the invalid Connection Request Message segment, it is mistaken for a new connection request sent by the client again. Therefore, the client sends a confirmation message segment and agrees to establish a connection. If three handshakes are not used, the new connection is established as long as the server sends a confirmation. Because the client does not send a connection request, it does not accept the confirmation from the server or send data to the server. However, the server thinks that the new transport connection has been established and waits for the client to send data. In this way, many server resources are wasted. The three-way handshake can prevent the above phenomenon. For example, in that case, the client will not send confirmation to the server. Because the server cannot receive the confirmation, it knows that the client does not require a connection.

This example clearly explains the meaning of three handshakes for establishing a reliable connection. In Google Groups's TopLanguage, it is interesting to see a post about TCP three-way handshake. Among the many replies, the author wrote: the essence of this problem is that the channel is not reliable, but the dual-producer communication needs to reach an agreement on a problem. to solve this problem, no matter what information you contain in the message, three-way communication is the theoretical minimum. therefore, the three-way handshake is not a requirement of TCP, but caused by the requirement of "reliably transmitting information over unreliable channels. note the essential requirements here. The channel is not reliable and data transmission is reliable. three times, you want to shake hands or send data later. It doesn't matter if you want to transmit reliable information. therefore, if the channel is reliable, that is, no matter when a message is sent, the other party will be able to receive the message, or you do not care if you want to ensure that the other party receives your message, then you can directly send messages like UDP .. This is another way of thinking for the purpose of three-way handshakes.

 

Example of a call:

A: Hello, I'm A. Can you hear me?

B: Yes. I'm B. Do you hear me talking?

A: Well, I heard it.

Establish a connection and start chatting!

 

 

Why does the TCP termination link take four times?

1. When host A confirms that the data has been sent and B knows that B has accepted the data, it will send FIN to host B if it wants to close the data sending port (of course, the signal can still be sent.

2. Host B receives the FIN sent by A, indicating that it will send an ACK reply.

3. B may still send data, but it does not mean to close the data port. Therefore, FIN and ACK are not sent at the same time, but wait until B's data is sent, to send FIN to host.

4. A receives the FIN from B, knows that B's data is also sent, replies to ACK, A waits for 2MSL, and does not receive any message from B, knowing that B has received its own ACK, A closes the link and B Closes the link.

 

Why does A wait for 2MSL, from TIME_WAIT to CLOSE?

The Client sends the final ACK reply, but the ACK may be lost. If the Server does not receive the ACK, it will repeatedly send the FIN fragment. Therefore, the Client cannot be immediately closed. It must confirm that the Server has received the ACK. The Client enters the TIME_WAIT status after sending the ACK. The Client sets a timer to wait for 2MSL. If you receive the FIN again within this time period, the Client resends the ACK and waits for 2MSL again. The so-called 2MSL is twice the MSL (Maximum Segment Lifetime ). MSL indicates the maximum survival time of a clip in the network. 2MSL indicates the maximum time required for sending and replying. If the Client does not receive the FIN again until 2MSL, the Client assumes that the ACK has been successfully received and ends the TCP connection.

 

This online reprinted example is good:

Three-way handshake:
A: "Hey, can you hear me ?" A-> SYN_SEND

B: "I can hear you. Can you hear me ?" Both B-> SYN_RCVD | A-> ESTABLISHED

A: "I can hear you. Today, balabala ......" B-> ESTABLISHED

Four Waves:
A: "Hey, I won't talk about it ." A-> FIN_WAIT1

B: "I understand. Wait. The last sentence has not been completed yet. Balabala ....." B-> CLOSE_WAIT | A-> FIN_WAIT2

B: "Well, I will not say that ." B-> LAST_ACK

A: "I understand ." A-> TIME_WAIT | B-> CLOSED

A waits for 2MSL to ensure that B receives the message. Otherwise, repeat "I know", A-> CLOSED

Link: https://zhuanlan.zhihu.com/p/21940234