当前位置：网站首页>On N handshakes and M waves of TCP

On N handshakes and M waves of TCP

2022-06-24 17:17:00 【Yerik】

In the computer network TCP/IP Protocol stack , There are two most common protocols in the transport layer ,TCP and UDP. When it comes to TCP, The two knowledge points of introduction are also test points , Even if it's about details , What's going to be a problem is ** Three handshakes and four waves **.

Start with a picture ,tcp State machine , From this state machine , We can see two topics that we are going to discuss this time .

tcp State machine

Three handshakes

The general content of the three handshakes , It can even be drawn as a cartoon in the picture below .

Three handshakes

To make fun is to make fun of , But the truth is the same . We know TCP The purpose of this paper is to provide reliable byte stream service , In order to accurately deliver the data to the destination ,TCP The protocol adopts three times handshake strategy to establish transmission channel , The process is as follows ：

Three handshake states

At the first two ends TCP The process is all in CLOSE( close ) state .
The sender A Actively send a message with SYN( synchronize) Mark the packet to the receiver B.A I will take the initiative at this time (active open) Go to connect The server , And send SYN, Suppose the serial number is J, The receiver is passive (passive open), What we should pay attention to is ** The serial numbers sent by the client and the server are random **
The receiving party B Upon receipt of SYN after , If you agree to establish a connection , Will send back another SYN And one. ACK( The reply ) To the sender A,ACK The serial number of is J+1 It's for SYNJ Response to , Newly sent SYN K The serial number is K The packet passing confirmation message , Means I received .** This serial number is also random **
The sender A Send back another one with ACK Packets for flags , On behalf of me , Express ** handshake ** end . The sender is receiving a new SYNK, ACKJ+1 after , In response ACKK+1 To indicate receipt of , Connection channel establishment
Then both sides can start sending data

The essence

Let's have a look at TCP The format of the message header

tcp message .png

here TCP Messages actually involve a lot of content , But this time we only focus on the control bit , Because the control position has something to do with our three handshakes and four waves .

URG： When URG=1 when , Indicates that the emergency pointer field is valid , Tell the system that there is emergency data in this message segment , Priority transmission .
ACK： When ACK=1 when , The confirmation number field is valid ,ACK=0 The confirmation number field is invalid
PSH： received TCP Of PSH=1 Message segment , Accept the application process as soon as possible , Instead of waiting until the entire cache is full to deliver up .
RST： When RSH=1 Time indicates TCP There was an error connecting , Connection must be released , Then reestablish the connection .
SYN：SYN=1 This is a connection request or a connection acceptance message .
FIN：FIN=1 Indicates that the data of the sender of this message segment is sent , And asks to release the transport connection .

It should be noted that , When transmitting data after three handshakes , If the first packet is sent by the client after the handshake , The first packet is seq and ack It's the same as the third handshake , So what was sent later seq and ack It's based on the last received packet seq、ack and len（ Data length ） obtain , Specific for ：seq=ack,ack=seq+len

The function of the serial number

The function of the serial number is to make one TCP The receiver can discard duplicate segments , Record segments that arrive in a random order . because TCP Use IP To transmit message segments , and IP It does not provide the ability to eliminate duplicates or ensure correct ordering . On the other hand ,TCP Is a byte stream protocol , Never send data in a random order to the upper program . therefore TCP The receiver will be forced to hold the data with a large sequence number before handing it over to the application , Until the missing small serial number segment is filled .

We are RFC793, That is to say TCP The agreement RFC, You'll find out why it's necessary to shake hands three times ——TCP need seq Serial number for reliable retransmission or reception , To avoid connection reuse, we can't distinguish seq It's delayed or old links seq, So it takes three handshakes to make an agreement ISN（ initial seq Serial number ）

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.

TCP A basic design setting is , adopt TCP Connect every packet sent , There is one. sequence number, Because every package has a serial number , So they can be confirmed to receive these packets . The confirmation mechanism is cumulative , So one is right sequence number X The confirmation of , signify X Before the serial number ( barring X) All packets are 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.

TCP The protocol is not limited to a specific connection （ Both ends socket equally ） It's being reused . So there's a problem ： After this connection suddenly breaks down and reconnects ,TCP How to identify the old link before the re sent package ？—— 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 , Initial serial number ( initial sequence number ISN) The generator will generate a new 32 Bit ISN.

ISN The calculation of is as follows ：

ISN = M + F(localhost, localport, remotehost, remoteport)

among M It's a timer , every other 4µs Add 1. F It's a Hash Algorithm , According to the source IP、 Purpose IP、 Source port 、 The destination port generates a ** Random number **.

This generator will use a 32 Bit long clock , almost 4µs Grow once , therefore ISN It will be around 4.55 Once an hour .

And a segment in the network is not longer than the maximum segment lifetime MSL Maximum Segment Lifetime, By default 2 Minutes long ,MSL Than 4.55 The hours are shorter , So we can say ISN It's going to be the only one .

The function of three handshakes

One TCP The connection consists of a 4 Tuples make up , Two IP Address and two port Numbers . One TCP Connections are usually divided into three phases ： start-up 、 The data transfer 、 sign out （ close ）. Connect before the client and server communicate ,“3 The second handshake ” The role of both sides is to be clear about their own and the other side's income 、 Hair power is normal .

One of the important functions of triple handshake is the exchange between client and server ISN(Initial Sequence Number), In this way, the other party knows how to assemble the data according to the serial number when receiving the data next .

Do you have to shake hands three times ？

During the three handshakes , In fact, the effect of the implementation is to let the server know that the client knows that the server knows . So it's really meant to be a doll , There may be doubts , Just let the server know that the client knows ？ Or don't you need to let the client know that the server knows that the client knows that the server knows that ？ Why make such a fuss ？ The author once studied his views in Xie Xiren's book , His idea is to prevent the invalid connection request message from suddenly being sent to the opposite end , So there's a mistake .

Teacher Xie further explained , So-called “ Invalid connection request message segment ” This is how it came about .

Consider a normal situation , A Make a connection request , However, due to the loss of the connection request message, no acknowledgement was received . therefore A Retransmit the connection request again . Confirmation was later received , It establishes the connection . After data transmission , It releases the connection .A Two connection request message segments are sent , The first one is missing , The second one arrived B, No, “ Invalid connection request message segment ".
Now suppose there is an abnormal situation , namely A The first connection request segment sent is not lost , But in some network nodes for a long time , So that it will not arrive until some time after the connection is released B. Originally, this is a message segment that has already failed . but B After receiving this invalid connection request message segment , I mistook it for A Another new connection request . So I went to A Send confirmation message segment , Agree to establish a connection . It is assumed that message handshake is not used , So as long as B Send a confirmation , A new connection is established .
Because now A No connection request was made , So I won't pay any attention to B The confirmation of , Nor to B send data . but B But think that a new transport connection has been established , And kept waiting A Send data .B So many of our resources are wasted .

The above is the understanding of the academic school , Mainly from the aspect of exception handling , If it's a second handshake , If there is congestion, the reconnection will result in , Exceptions to end-to-end services , We need to design an exception handling mechanism .

After the Google Groups Of TopLanguage I saw a discussion in the article TCP“ Three handshakes ” I think it's interesting . The poster put forward “TCP Why three handshakes to establish a connection ？” The problem of , Among the many replies , One reply said ：“ The essence of the problem is , The channel is unreliable , But communication needs to agree on a certain issue . And to solve this problem , Whatever information you include in the message , Triple communication is the theoretical minimum . So three handshakes is not TCP The demands of itself , But to satisfy ‘ Reliable transmission of information over unreliable channels ’ This demand leads to . Please note the essential requirements here , The channel is unreliable , Data transmission should be reliable . Three times to , You want to shake hands later , 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 will certainly receive it , Or you don't care if you want to make sure the other person gets your message , That would be like UDP Then you can send the message directly .”

This can actually be seen as right “ Three handshakes ” Another perspective of purpose . Full screen engineering thinking , After all, it's a compromise on the unreliability of channel transmission , Complete the transmission of reliable information . After all 3 The second handshake accomplishes two important functions , Both sides should be ready to send data ( Both sides know that they are ready to ), Also allow both parties to negotiate the initial serial number , This serial number is sent and confirmed during handshake .

For example, we now change three handshakes to just two handshakes , Deadlocks are possible . Suppose the computer S and C Communication between , here C to S Send a connection request packet ,S Received this group , Concurrent Send confirmation response group . According to the agreement of two handshakes ,S Think the connection has been successfully established , You can start sending data packets . But ,C stay S In case that the reply packet of is lost in the transmission , Will not know S Are you ready to , I do not know! S What kind of serial number to create ,C Even doubted S Whether to receive your own connection request grouping . under these circumstances ,C Think the connection has not been established successfully , Will ignore S Any data sent... Points Group , Only wait for the connection to confirm the reply group . and S After the outgoing packet times out , Send the same packet over and over again . This creates a deadlock . The cartoon diagram is shown in the picture

Three handshakes succeeded .png

Two handshakes 1.png

Two handshakes 2.png

In the previous description, we know that both the sender and the receiver will have their own ISN （ In the following example is X And Y） To communicate with each other , The specific description is as follows ：

1. A --> B  SYN my sequence number is X 

2. A <-- B  ACK your sequence number is X 

3. A <-- B  SYN my sequence number is Y 

4. A --> B  ACK your sequence number is Y

2 And 3 All are B Send to A, So it can be combined , Become three way (or three message) handshake, At this point, it can be concluded that , Three handshakes are necessary ：

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.

because sequence numbers（ Serial number ） There is no global clock bound to the entire network （ All use one clock , You can determine if the packet is delayed ） as well as TCPs There may be different mechanisms to choose ISN（ Initial serial number ）.

The receiver receives the first SYN when , There's no way to know this SYN Is it a long delay , Unless he has a way to remember in this connection , The last one I received sequence numbers（ But it's not always possible ）.

The meaning of this sentence is ： One seq Over here. , Just like what I remember now seq Dissimilarity , How do I know he was delayed last , It's the last delay ？ therefore , The receiver must confirm with the sender SYN.

Suppose you don't confirm SYN Medium SEQ, So there's only ：

1) A --> B  SYN my sequence number is X 

2) A <-- B  ACK your sequence number is X  SYN my sequence number is Y

Only B Yes, it's received A Of SEQ, A Unable to confirm receipt of B Of . in other words , Only A Send to B My bags are reliable , and B Send to A But it's not , So it's not a reliable connection . In this case, if only A Send to B ,B No need to respond , You don't have to shake hands three times .

Four waves （Four-Way-Wavehand）

Then he shook hands three times , Is that the same with the other four waves ？ In order to compromise 、 In order to eliminate the abnormal situation ？ Let's deduce step by step .

Four waves .png

First wave ：Client Send a FIN, Used to close Client To Server Data transfer of ,Client Get into FIN_WAIT_1 state .
Second wave ：Server received FIN after , Send a ACK to Client, Confirmation No. is receipt No +1（ And SYN identical , One FIN Occupy a sequence number ）,Server Get into CLOSE_WAIT state . here TCP It's semi closed , The server can send data to the client , And the server can't send data .
Third wave ：Server Send a FIN, Used to close Server To Client Data transfer of ,Server Get into LAST_ACK state .
Fourth wave ：Client received FIN after ,Client Get into TIME_WAIT state , wait for 2 MSL（ Maximum message lifetime ） Release the connection after , And then send a ACK to Server, Confirmation No. is receipt No +1,Server After confirmation, enter CLOSED state , Release the connection , Finish four waves .

In popular parlance :

Client： I'm done with everything
Server： I've heard all about , But wait for me , I haven't finished
Server： Okay , I have finished
Client： well , Then our correspondence is over :)

significance

When the passive party receives the FIN Message notification , It just means that the active party has no data to send to the passive party . But not all the data of the passive party is completely sent to the active party , So the passive side won't shut down immediately SOCKET, It may also need to send some data to the active party , Send again FIN Message to the active party , Tell the active party to agree to close the connection , So here ACK Message and FIN In most cases, messages are sent separately .

reason

Notice that there are two states during the wave Close-wait and Time-wait, This is also the reason why we need to design four handshakes .

CLOSE-WAIT

The client sends it FIN After connection release message , The server received this message , It's in CLOSE-WAIT state . This state is for the server to send data that has not been transmitted yet , After transmission , The server will send FIN Connection release message .

TIME-WAIT

The client receives... From the server FIN Enter this state after the message , This is not a direct entry into CLOSED state , Also need to wait for a time timer to set the time 2MSL.

Why? A stay TIME-WAIT The state must wait 2MSL Time of ？

There are two reasons to do this ：

In order to ensure A The last one sent ACK Message segments can reach B.A Send this ACK Message segments may be lost , If B received A The confirmation message sent , that A Will resend the connection release request message ,A Waiting for a while is to deal with this situation .
prevent “ Invalid connection request message segment ” Appears in this link .A After sending the last ACK After message segment , After another time 2MSL, All the message segments generated during the time of this connection will disappear from the network . In this way, the old connection request segment will not appear in the next new connection .

You have to shake hands four times ？

This is because of the server side LISTEN In state SOCKET When I received SYN After connection request of message , It can be ACK and SYN(ACK Act as a response , and SYN It's synchronous ) Put it in a message to send . But when you take the initiative to close the connection , When receiving from the other party FIN Message notification , It just means there's no data sent to you ; But not all your data has been sent to each other , therefore ** Probably ** It may not close right away SOCKET, That is, you may need to send some data to the other party , Send again FIN Message to the other party to indicate that you agree to close the connection now , So it's here ACK Message and FIN In most cases, messages are sent separately