The TCP three-way handshake is almost a common problem for recent graduate interviews. However, there are still many mistakes on the Internet to know why [TCP is a three-way handshake, not two or four times? The popular answer on (https://www.zhihu.com/question/24853633) is an example. The first analogy of 3.6K approval is wrong:
Three-way handshake:
"Hey, can you hear it?"
"I can hear it, can you hear me?"
"I can hear you, today balabala..."
The same analogy of 107 approvals is also wrong:
The handshake is the same as the military service, which is derived from the ceremonies of "the enemy and the other side confirm each other's hands without weapons and no malice." (Although the two parties need to confirm each other in four steps, since the intermediate confirmation and request are executed by the same person, the merger becomes one step)
Zheng En reached out and said: You see, I have no weapons in my hand. (SYN)
Rump looked and said: Well, it really doesn't. (ACK)
Then he also reached out and said: You see, I have no weapons in my hand. (SYN)
Zheng En looked and said: Well, it seems that you really have sincerity. (ACK)
These two analogies are mistakes that are taken for granted, why are they wrong, and if you look at the complete text, you will know what you know.
In addition, in the fourth edition of Xie Xiren's "Computer Network", the purpose of "three-way handshake" is to "in order to prevent the failed connection request message segment from being suddenly transmitted to the server, thus generating an error", this only It can be regarded as a cause and does not involve the essence.
The example in Xie Xiren's "Computer Network" is such that the "failed connection request segment" is generated in such a case that the first connection request segment sent by the client is not lost, but A network node stayed for a long time, so that the delay reached the server some time after the connection was released. Originally this was a segment that had expired. However, after the server receives the invalid connection request segment, it is mistaken for a new connection request sent by the client again. Then an acknowledgment message segment is sent to the client, agreeing to establish a connection. Assuming no “three-way handshake”, a new connection is established as soon as the server issues an acknowledgment. Since the client does not issue a request to establish a connection, it will ignore the server's acknowledgment and will not send data to the server. But the server thought that a new transport connection had been established and had been waiting for the client to send data. In this way, many resources of the server are wasted. The "three-way handshake" approach can prevent this from happening. For example, in the case just now, the client will not issue an acknowledgment to the server's confirmation. The server knows that the client does not require a connection because it does not receive an acknowledgment. ”
If you peruse [RFC793] (https://www.ietf.org/rfc/rfc793.txt), which is TCP's protocol RFC, you will find out why the three-way handshake is necessary - TCP needs The seq serial number is used for reliable retransmission or reception, and it is impossible to distinguish whether the seq is delayed or the seq of the old link when the connection multiplexing is avoided. Therefore, a three-way handshake is required to agree to determine the ISN (initial seq serial number) of both parties.
The detailed RFC interpretation is given below: (The data group is called Segment, and the domestic is usually called by the package)
The first thing we need to know is that TCP's reliable connection is achieved by seq (sequence numbers).
A fundamental notion in the design is that every octet of data sent over a TCP connection has a sequence number. Since every octet is sequenced, each of them can be acknowledged. The acknowledgment mechanism employed is cumulative so that an acknowledgment of sequence number X indicates that all octets up to but not including X Have been received.
A basic setting in TCP design is that each packet sent over a TCP connection has a sequence number. And because each package has a serial number, it can be confirmed to receive these packages.
The acknowledgment mechanism is cumulative, so a acknowledgment of the sequence number X means that the X sequence number (excluding the X) package is acknowledged.
The protocol places no restriction on a particular connection being used over and over again.
The problem that arises from this is -- "how does the TCP identify duplicate segments from previous incarnations of the connection?" This problem becomes apparent if the connection is being opened and closed in quick succession, or if the connection breaks with loss of memory and is then reestablished.
The TCP protocol does not restrict the reuse of a particular connection (like sockets at both ends).
So there is a problem: After this connection is suddenly disconnected and reconnected, how does TCP recognize the packet that was retransmitted by the old link before? - This requires a unique ISN (Initial Serial Number) mechanism.
When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours. Since we assume that segments will stay in the network no more than the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55 hours we can reasonably assume that ISN's will be unique.
When a new connection is established, the 'initial sequence number ISN generator' will generate a new 32-bit ISN.
This generator will grow with a 32-bit clock, which is almost a '4μs`, so the ISN will cycle once in about 4.55 hours.
(The counter of 2^32 bit needs 2^32*4 μs to increase itself. Dividing by the total number of μs in 1 hour can calculate 2^32*4 /(1*60*60*1000*) 1000) = 4.772185884)
And a segment in the network is not longer than the Maximum Segment Lifetime (MSL), which is 2 minutes by default, and the MSL is shorter than 4.55 hours, so we can think that the ISN will be unique.
Both the sender and the receiver will have their own ISN (X and Y in the following example) to communicate with each other. The specific description is as follows:
A --> B SYN my sequence number is X
A <-- B ACK your sequence number is X
A <-- B SYN my sequence number is Y
A --> B ACK your sequence number is Y
Both 2 and 3 are sent to A, so they can be merged together, so they become three way (or three message) handshake (in fact, the translation is a three-step handshake, or three communication handshakes are more accurate)
So in the end it can be concluded that a three-way handshake is a must:
A three way handshake is necessary because sequence numbers are not tied to a global clock in the network, and TCPs may have different mechanisms for picking the ISN's. The receiver of the first SYN has no way of knowing whether the segment was an old delayed one or not, unless it remembers the last sequence number used on the connection (which is not always possible), and so it must ask the sender to verify this SYN. The three way handshake and the advantages of a clock-driven scheme are discussed in [3].
A three way handshake is necessary because the sequence numbers are not bound to the global clock of the entire network (all one clock is used uniformly to determine if the packet is delayed) and TCPs may have Different mechanisms to choose ISN (initial serial number).
When the receiver receives the first SYN, there is no way to know if the SYN has been delayed for a long time, unless he has a way to remember the last received sequence in this connection (however this is not always possible) .
The meaning of this sentence is: a seq comes over, not the same as the seq now remembered. How do I know if he is delayed or is it delayed?
Therefore, the receiver must confirm the SYN with the sender.
Assuming that the SEQ in the SYN is not confirmed, then only:
A --> B SYN my sequence number is X
A <-- B ACK your sequence number is X SYN my sequence number is Y
Only B confirms that A has received SEQ, and A cannot confirm receipt of B. That is, only the packets sent by A to B are reliable, and the packets sent by B to A are not, so this is not a reliable connection. In this case, if only A is required to send to B, and B does not need to respond, you can skip the three-way handshake.
TCP A TCP B
1. CLOSED LISTEN
2. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED
3. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN, ACK> <-- SYN-RECEIVED
4. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
5. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED
Basic 3-Way Handshake for Connection Synchronization
Figure 7.
In the picture above
- In the second line, A sends SEQ 100 and the flag is SYN;
- In the third line, B sends back ACK 101 and SEQ 300, and the flags are SYN and ACK (the two processes are merged). Note that an ACK of 101 means that B wants to receive the data segment starting with the 101 serial number.
- In the fourth line, A returns empty data, SEQ 101, ACK 301, and the flag is ACK. At this point, both start SEQ (ie ISN) numbers 100 and 300 are confirmed to have been received.
- In the fifth line, the packet is officially sent. Note that the ACK is still the 301 of the fourth line because there is no SYN that requires an ACK (the fourth line has already been ACKed).
Therefore, the correct analogy should be like this: TCP transmission information can be understood as the United States and China use cargo ships to pass goods, but because a ship can not be put on, the goods must be separated by a ship.
So a serial number is needed to identify the goods as the first few, so that they are stitched back to the original goods upon arrival.
Because of the same channel (that is, tcp connection), there may be multiple shipments (multiplexed tcp connections). When shipping, both parties need to notify each other
Where do the serial numbers start (init seq) so that they can identify whether they are a pair of goods and can be spliced into complete goods.
The most important thing about cargo transport splicing (tcp) is reliability. If you do not use the three-way handshake to confirm that both parties can get the other party's serial number (seq), you can't know what the current cargo number is in the current flight (connection). It’s gone.
TCP A TCP B
1. CLOSED LISTEN
2. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED
3. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN, ACK> <-- SYN-RECEIVED
4. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
5. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED
Basic 3-Way Handshake for Connection Synchronization
Figure 7.
In the picture above
- In the second line, A sends SEQ 100 and the flag is SYN;
- In the third line, B sends back ACK 101 and SEQ 300, and the flags are SYN and ACK (the two processes are merged). Note that an ACK of 101 means that B wants to receive the data segment starting with the 101 serial number.
- In the fourth line, A returns empty data, SEQ 101, ACK 301, and the flag is ACK. At this point, both start SEQ (ie ISN) numbers 100 and 300 are confirmed to have been received.
- In the fifth line, the packet is officially sent. Note that the ACK is still the 301 of the fourth line because there is no SYN that requires an ACK (the fourth line has already been ACKed).
Above, 4 The final confirmation process is to bring the data.
The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion. this, a special control message, reset, has been devised. If the receiving TCP is in a non-synchronized state (i.e., SYN-SENT, SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset. If the TCP is in one of the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it aborts the connection and informs its user. We discuss this latter case under "half-open" connections below.
The principle of the three-way handshake is to prevent the initialization of the old multiplexed link from causing problems. In order to solve this problem, we designed the special control signal to deal with it.
If the receiving TCP is in an unsynchronized state such as SYN-SENT, SYN-RECEIVED, it will return a reset to the other party.
If TCP is in sync state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it will terminate the connection and notify the user.
It looks a bit winding, let's take a look at the legend:
TCP A TCP B
1. CLOSED LISTEN
2. SYN-SENT --> <SEQ=100><CTL=SYN> ...
3. (duplicate) ... <SEQ=90><CTL=SYN> --> SYN-RECEIVED
4. SYN-SENT <-- <SEQ=300><ACK=91><CTL=SYN,ACK> <-- SYN-RECEIVED
5. SYN-SENT --> <SEQ=91><CTL=RST> --> LISTEN
6. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED
7. SYN-SENT <-- <SEQ=400><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
8. ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK> --> ESTABLISHED
Recovery from Old Duplicate SYN
This is an example of an old in-transit packet being sent to a new connection when the connection is multiplexed.
- 3, an old duplicate SYN arrives at B.
- 4, B does not show whether it is old, and it is normal to return the package.
- 5, A detected B returned ACK is incorrect, so return RST (reset)
- 6, B receives the RST (reset) signal, and then becomes the LISTEN state.
- 7, the new connection normal SYN has finally arrived, and the three-way handshake is normal.
This is a simplified case, but it can be seen how TCP handles the arrival of packets that reuse old links.
postscript
Ps: On the method of global clock, I found a paper: http://mirrors.ustc.edu.cn/rfc/ien/ien193.pdf, interested students can look at it.