Why does tcp need three-way handshake?

Transmission Control Protocol (TCP) is a connection-oriented, reliable, byte-stream-based transport layer communication protocol. is specifically designed to provide a reliable end-to-end byte stream over unreliable internetwork. An internetwork differs from a single network because different parts of the internetwork may have very different topologies, bandwidths, latency, packet sizes, and other parameters. The design goal of TCP is to be able to dynamically adapt to these characteristics of the internetwork, and still be robust in the face of multiple failures.
Each TCP connection requires three phases: connection establishment, data transfer, and connection release. The "three-way handshake" occurs during the connection establishment phase. There are many detailed explanations of the specific process of the "three-way handshake" on the Internet. You can Google it yourself. The discussion here is - why the "three-way handshake" is needed.
After I Google the answer to this question, I found that the process of "three-way handshake" is described in great detail on the Internet, but there is no good answer to why "three-way handshake" is needed to establish a connection. Only resort to books.
In the fourth edition of Xie Xiren's "Computer Network", the purpose of the "three-way handshake" is "to prevent an invalid connection request segment from being suddenly transmitted to the server, resulting in errors." The purpose of the "three-way handshake" in another classic "Computer Network" is to solve the problem of "duplicate packets with delay in the network". These two different expressions actually illustrate the same problem.
The example in Xie Xiren's edition of "Computer Network" is like this, the "invalid connection request segment" is generated in such a situation: the first connection request segment sent by the client is not lost, but in the A network node has been stuck for a long time, so that it is delayed until a certain time after the connection is released before reaching the server. Originally this was a long-defunct segment. However, after the server receives the invalid connection request segment, it mistakenly believes that it is a new connection request sent by the client again. So it sends a confirmation segment to the client and agrees to establish a connection. Assuming that the "three-way handshake" is not used, as long as the server sends an acknowledgement, a new connection is established. Since the client has not issued a request to establish a connection now, it will ignore the confirmation of the server and will not send data to the server. But the server thinks that a new transport connection has been established and has been waiting for the client to send data. In this way, many resources of the server are wasted in vain. The "three-way handshake" approach can prevent the above phenomenon from happening. For example, in the case just now, the client will not issue confirmation to the server's confirmation. Since the server does not receive the confirmation, it knows that the client has not requested to establish a connection. "
This example clearly illustrates the meaning of the "three-way handshake" for establishing a reliable connection.
It is interesting to see a post discussing the TCP "three-way handshake" in TopLanguage of Google Groups. The owner of the post asked the question of "Why is the TCP connection establishment a three-way handshake?". Among the many replies, one reply said: "The essence of this problem is that the channel is unreliable, but the communication needs to reach an agreement on a certain issue. And to solve this problem, no matter what information you include in the message, the three-way communication is the theoretical minimum. So the three-way handshake is not a requirement of TCP itself, but to meet the "reliable transmission of information on an unreliable channel" This is It is caused by the demand. Please pay attention to the essential requirements here, the channel is unreliable, and the data transmission must be reliable. If it is reached three times, then whether you want to continue handshake or send data, it has nothing to do with the need for reliable information transmission. Therefore, if the channel is reliable, that is, whenever a message is sent, the other party must receive it, or you don't care whether the other party receives your message or not, then you can send the message directly like UDP.". This can be seen as another solution to the purpose of the "three-way handshake".