"Why the three-way handshake?"
The implication of this question is actually asking: "Why not 0, 1, 2, 4 or even more handshakes".
Make sure both sending and receiving capabilities are good .
A comment under this answer : It’s actually very simple, 1.a->b, there is no state at this time, 2. b->a, b sends something to a, indicating that the thing of a has been received, which proves the sending ability of a There is no problem, and it proves that the receiving ability of b is also no problem. If it ends here, then there is no way to guarantee the receiving ability of a and the sending ability of b. If 3. a->b is added, it proves that a has received b's transmission, then b's sending ability is also good, and a's receiving ability is also good. In this way, the receiving and sending capabilities of a and b are both good, so there is no need to prove it again. As for the problem that the third package did not arrive as mentioned by the poster, suppose that in process 3, a was sent, but b was not. For a, b has received his own transmission and responded to himself, so he can think that b is normal, and a believes that he is also normal, so at this time, for a, the tcp handshake is over, but for b For example, when a does not respond when the second packet is sent, then b will think that there is a problem with a's receiving ability, and b will keep sending it until a responds. Otherwise, b will never think that the tcp handshake is over.
Both parties believe that the transmission of the current channel/data is reliable .
Original comment : So the three-way handshake is not a requirement of TCP itself, but is caused by the requirement of "transmitting information reliably on an unreliable channel". Please pay attention to the essential requirements here: the channel is unreliable, and the data transmission must be reliable :
the essence of this problem is that through an incompletely reliable channel, at least several message transmissions are required, and people on both sides of the channel can reach a consensus on a problem. For TCP For example, regardless of whether there is an initial sequence number requirement, at least three message exchanges are required if both parties agree to start sending data:
- 0 times: obviously not
- 1 time: A->B, A does not know whether B agrees
- 2 times: A->B, B->A. B does not know whether A has received his message, because the channel is not completely reliable.
Here A is already sure that the channel is reliable, but B is not sure. Here if you put This is natural for the channel to be the TCP link itself, i.e. full duplex, but not for someone like me who splits the link into channels in both directions. And TCP can indeed establish a semi-link- 3 times: A->B, B->A, A->B. Both sides have received the other party's ACK, which means that each understands the other party's intentions, so that the simplest question of whether to start communication
If the question is a little more detailed: "Why is it a three-way handshake, not a two-way handshake ?", that is, you are asking about the role of the third handshake.
Why is TCP a three-way handshake instead of two or four? - wuxinliulei's answer - Zhihu :
In order to prevent the invalid connection request segment from being suddenly transmitted to the server, resulting in an error.
"Why is there a three-way handshake, but four waves?"
This question is actually asking why the server's ACK and FIN cannot be sent at the same time in "Four Waves". Because in the answer to "Why is it a three-way handshake", I saw an answer saying:
- A sends a synchronization signal SYN + A's seq
- B confirms receipt of A's SYN, records A's seq, and names B's ACK
- B sends SYN + B's seq
- A confirms B's SYN, and records B's seq, named A's ACK
Obviously, steps 2 and 3 can be combined, so only 3 handshakes are required.
But I think this answer is to explain the background and origin of the question "Why is there a three-way handshake, but four waves?", namely: why are the ACK and SYN on the server side developed separately in the four waves?
A more reasonable explanation is:
This is because the server sends ACK and SYN in one message to the client after receiving the SYN message of the connection establishment request in the LISTEN state. When closing the connection, when receiving the other party's FIN message, it only means that the other party no longer sends data but can still receive data, and one's own party may not have sent all the data to the other party, so one's own party can close immediately, or send some After the data is sent to the other party , send a FIN message to the other party to express agreement to close the connection now. Therefore, your own ACK and FIN are generally sent separately.