http three handshake four waves

Recently, I have been busy watching the front-end vue-related content, and the back-end related content has not been followed up. The article has been stopped for 3 weeks,,, hey, still lazy! The master said that life lies in sports, it is still necessary to learn, and the articles still need to be sorted out, let's not talk about it---
refer to:
----------------------------------------------------------------------------
We often say that the http protocol requires three handshakes to establish a connection, and four waves of hands to disconnect the connection, but what is going on, and why is it designed this way?
In fact, it is not accurate to say this. It should be said that the tcp protocol requires 3 handshakes to establish a connection, and 4 handshakes to disconnect the connection, and http is based on the tcp protocol, so we usually say the same. In fact, http doesn't care that tcp handshakes and waves several times to establish a connection. It only cares if you are connected well and can you help me transmit data. If the bottom layer of http does not use the tcp protocol, it doesn't matter if the handshake is established. Follow the waving process.
----------------------------------------------------------------------------
However, since our daily network access http uses tcp, let's take a look at this process.
tcp can provide full-duplex data streaming services. Full-duplex, to put it bluntly, means that A can send a message to B at the same time, and B can also send a message to A, and both of them can send messages to each other at the same time; half-duplex means that In a certain time period, A can be sent to B, but B cannot be sent to A. In another time period, it is reversed; simplex means that only one can be sent to the other, similar to a one-way street for a car;
Connection establishment process:
1. The TCP server process first creates the transmission control block TCB, and is always ready to accept the connection request of the client process. At this time, the server enters the LISTEN state;
2. The TCP client process also first creates the transmission control block TCB, and then sends a connection request message to the server. This is the same part in the message header, SYN=1, and selects an initial sequence number seq=x. At this time, the TCP client The end process has entered the SYN-SENT (synchronized sent state) state. TCP stipulates that the SYN segment (the segment with SYN=1) cannot carry data, but it needs to consume a sequence number.
3. After receiving the request message, the TCP server sends a confirmation message if it agrees to connect. The confirmation message should be ACK=1, SYN=1, the confirmation number is ack=x+1, and a sequence number seq=y should also be initialized for itself. At this time, the TCP server process has entered the SYN-RCVD (synchronous receive )condition. This packet also cannot carry data, but also consumes a sequence number.
4. After the TCP client process receives the confirmation, it must also give the confirmation to the server. Confirm that the ACK of the message is 1, ack=y+1, and its own sequence number is seq=x+1. At this time, the TCP connection is established, and the client enters the ESTABLISHED (connection established) state. TCP stipulates that the ACK segment can carry data, but if it does not carry data, the sequence number is not consumed.
5. When the server receives the confirmation from the client, it also enters the ESTABLISHED state, after which the two parties can start communication.
This process is understood as if the two were shouting:
A: Hello, is there anyone, I want to establish a connection
B: Yes, wow, you build it, wait for you to shout
A: Okay, here I come
Then the two established a connection,,,,
Do you have to shake hands three times, or two?
Such a scene:
  • A->B: Dongyaodongyao, I'm Dongguai, please reply, Over.
  • B->A: Dongguai, Dongyao received, Over.
Please judge from the above dialogue,
1. Can B receive information from A? (the answer is yes)
2. Can A receive information from B? (you guess?)
The core idea of ​​tcp is to ensure the reliable transmission of data. If it is done twice, obviously it will not work, but will it be possible to do it three times? Not necessarily, maybe the third time the network is interrupted, and then A thinks that B has received it, and then sends a message, in fact, B does not receive it, but this cannot be completely guaranteed. No matter how many handshakes are made, the absolute reliability of transmission cannot be satisfied. For efficiency and relative reliability, 3 times is just right, so 3 times (just AB confirms each other once).
Disconnection process:
1. The client process sends a connection release message and stops sending data. Release the header of the data message, FIN=1, and its sequence number is seq=u (equal to the sequence number of the last byte of the previously transmitted data plus 1), at this time, the client enters FIN-WAIT-1 (termination waiting 1) Status. TCP stipulates that even if the FIN segment does not carry data, it also consumes a sequence number.
2. The server receives the connection release message, sends an acknowledgement message, ACK=1, ack=u+1, and brings its own serial number seq=v. At this time, the server enters CLOSE-WAIT (close waiting )condition. The TCP server notifies the high-level application process, and the client is released in the direction of the server. At this time, it is in a semi-closed state, that is, the client has no data to send, but if the server sends data, the client still has to accept it. This state will continue for a period of time, that is, the duration of the entire CLOSE-WAIT state.
3. After the client receives the confirmation request from the server, at this time, the client enters the FIN-WAIT-2 (termination wait 2) state, waiting for the server to send a connection release message (before that, it needs to accept the last message sent by the server. data).
4. After the server sends the last data, it sends a connection release message to the client, FIN=1, ack=u+1. Since it is in the half-closed state, the server is likely to send some data again. The sequence number is seq=w. At this point, the server enters the LAST-ACK (last acknowledgment) state and waits for the client's confirmation.
5. After the client receives the connection release message from the server, it must send an acknowledgment, ACK=1, ack=w+1, and its own serial number is seq=u+1. At this point, the client enters the TIME- WAIT (wait for time) state. Note that the TCP connection has not been released at this time, and the client will enter the CLOSED state only after 2*MSL (maximum segment lifetime) has elapsed.
6. As long as the server receives the confirmation sent by the client, it will enter the CLOSED state immediately. Similarly, after revoking the TCB, this TCP connection is ended. As you can see, the server ends the TCP connection earlier than the client.
Why does it take 3 times to establish a connection and 4 times to disconnect?
Because tcp is full-duplex, each direction needs to be disconnected separately, 2 times in each direction, so 4 times.
Does it have to be 4 times? Can't it be 3 times? It's the same as establishing a connection. When the server replies, can't the request be disconnected by the way?
No, because when the client requests the server to disconnect, there is no more data to send in the direction that the client sends data to the server, but the server may still have information to send to the client, and the time required is uncertain. You can't keep the client waiting without replying, you can only reply one first, let the client disconnect, and then disconnect the connection from the server to the client after the server has finished sending the data;
Why does the client have to wait for 2MSL at the end?
MSL (Maximum Segment Lifetime), TCP allows different implementations to set different MSL values.
First, ensure that the last ACK message sent by the client can reach the server, because this ACK message may be lost. From the perspective of the server, I have sent a FIN+ACK message requesting disconnection, and the client still No response was given to me, it should be that the request disconnection message I sent was not received, so the server will resend it again, and the client can receive the retransmitted message within this 2MSL time period, and then give A response message is sent, and the 2MSL timer is restarted.
Second, prevent the "invalid connection request segment" similar to that mentioned in the "three-way handshake" from appearing in this connection. After the client sends the last acknowledgment message, in this 2MSL time, all message segments generated during the duration of this connection can be eliminated from the network. In this way, the request message of the old connection will not appear in the new connection.
Waiting for 2MSL to confirm that there is no problem?
No, there is also a timeout mechanism, which will close the connection even if no reply is received. The entire shutdown process is as follows:
 tcp close connection state transition
The above figure is the state transition diagram of the active closing end of the tcp connection:
(1) The application layer calls the close function to initiate a close connection request
(2) Send FIN to the peer, close the write channel, and enter the FIN_WAIT1 state by itself
(3) Wait for the arrival of the confirmation ACK from the peer, and enter the FIN_WAIT2 state after receiving the ACK; if the confirmation ACK is not received within the timeout period, enter the CLOSED state directly
(4) If the FIN of the opposite end is received in the FIN_WAIT1 state, it will enter the CLOSING state (both send a request to close the connection)
(5) Enter the TIME_WAIT state after FIN_WAIT2 receives the peer FIN; if the FIN is not received within the timeout period, it directly enters the CLOSED state
(6) Enter the CLOSED state after waiting for 2 MSLs (the longest survival period of 2 messages) in the TIME_WAIT state
----------------------------------------------------------------------------
Why 3 times, why 4 times, more or less, will it work, why wait, what will happen if you don't wait, how to make sure the communication is reliable, and how to make sure that the opposite side is also disconnected when disconnected, don't wait all the time It's a waste of resources,,,, um, almost solved, over
 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324654526&siteId=291194637