overview
The TCP protocol is the protocol of the transport layer in the five-layer protocol. The following depends on the network layer, link layer, and physical layer. For a message to be sent to the peer layer on another machine (assuming it is a server ) , each dependent Each layer will package the message. For example, the TCP protocol depends on the IP protocol of the network layer, so the sent message will be encapsulated as follows :
TCP protocol
When this data packet arrives at the server, the network layer of the server will decapsulate and verify the content of the IP- related protocol, and then the transport layer will decapsulate the TCP layer. Decapsulation involves a series of steps. Well? Is it sent to me ? These operations need to be judged based on the header information of the TCP message. The header contains the following content:
The header information of the TCP packet
Mainly through the header information to understand what this package is for, about the header information , here are a few that need to be used as follows :
ACK : The TCP protocol stipulates that it is only valid when ACK=1 , and it also stipulates that the ACK of all sent messages after the connection is established must be 1
SYN (SYNchronization) : Used to synchronize the serial number when the connection is established. When SYN=1 and ACK=0 , it indicates that this is a connection request message. If the other party agrees to establish a connection, it should set SYN=1 and ACK=1 in the response message . Therefore , setting SYN to 1 means that this is a connection request or connection acceptance message.
FIN ( finis ): that is, the meaning of termination, used to release a connection. When FIN = 1 , it indicates that the data of the sender of this segment has been sent, and the connection is required to be released.
"Note " :· URG, ACK, PSH, PST, RST, SYN, FIN only havethat is, there are only0or1.
TCP protocol three-way handshake
TCP protocol three-way handshake
"First handshake" : The client first sends a message segment requesting a connection to the server. The SYN bit of this message segmentis set to 1, and the sequence number Seq (Sequence Number) is set to a certain value, assuming it is X. Send After going out, the client enters the SYN_SEND state, waiting for the confirmation of the server;
"Second handshake" : The server receives the SYN segment. The server needs to confirm the SYN message segment after receiving the SYN message segmentfrom the client , and set the Acknowledgment Number to x+1 (Sequence Number+1); at the same time, it needs to send the SYN request message itself, and set the SYN position to 1. The Sequence Number is y; the server puts all the above information into a message segment (that is, the SYN+ACK message segment) and sends it to the client together. At this time, the server enters the SYN_RECV state;
"Third handshake" : The client receives the SYN+ACK segment from the server. Then set the Acknowledgment Number to y+1, and send an ACK message segment to the server. After the message segment is sent, both the client and the server enter the ESTABLISHED state , and complete the TCP three-way handshake.
After completing the three-way handshake, the client and server can start transmitting data. The above is the general introduction of the TCP three-way handshake.
Why a three-way handshake instead of two ?
Why do you have to make three connections? Is it okay twice ? It is said in Xie Xiren's "Computer Network":
In order to prevent the invalid connection request segment from being transmitted to the server suddenly, an error is generated. as follows:
" ❝ "The expired connection request segment" is generated in such a situation: the first connection request segment sent by the client is not lost, but stays in a certain network node for a long time, As a result, it is delayed until a certain time after the connection is released before reaching the server . It turns out that this is a segment that has already expired. However, after receiving the invalid connection request segment, the server mistook it as a new connection request sent by the client again. Then a confirmation message segment is sent to the client, agreeing to establish a connection. Assuming that the "three-way handshake" is not used, as long as the server sends a confirmation, a new connection is established. Since the client has not issued a request to establish a connection, it will ignore the server's confirmation and will not send data to the server. But the server thinks that the 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. The "three-way handshake" method can prevent the above phenomenon from happening. For example, in the situation just now, the client will not send a confirmation to the server's confirmation. Since the server does not receive the confirmation, it knows that the client did not request to establish a connection. ", preventing the server from wasting resources by waiting all the time. ❞
What if the third handshake fails?
In the tcp three-way handshake, after the second handshake is completed, connect returns successfully. If the ack packet of the third handshake is lost, the client already believes that the connection is successful . If there is no heartbeat packet at the application layer , the client will maintain it all the time. How to avoid this situation? If you are learning Spring Boot , then recommend a free tutorial that has been serialized for many years and continues to be updated: http://blog.didispace.com/spring-boot-learning-2x/
The second handshake server receives the SYN packet , then sends a SYN+ACK packet to confirm receipt and request to establish a connection, and the server enters the SYN_RECV state. At this time, the client failed to send ACK to the server during the third handshake , and the server has no way to enter the ESTABLISH state. At this time, data must not be transmitted. Regardless of whether the client actively sends data or not, the server will have a timer to send the second step. SYN+ACK packet, if the client sends ACK again successfully, the connection is established.
If it has been unsuccessful, the server will definitely have a timeout (about 64s ) setting. After the timeout, it will send an " RTS message" ( connection reset ) to the client and enter the CLOSED state to prevent SYN flood attacks. At this time, the client should also will close the connection.
" SYN flood attack:"
" ❝ The SYN attack uses the three-way handshake mechanism of TCP. The attacking end uses a forged IP address to send a request to the attacked end, but the response message sent by the attacked end will never be sent to the destination. Resources were consumed while waiting to close this connection", if there are tens of thousands of such connections, the host resources will be exhausted, thus achieving the purpose of the attack. ❞
TCP protocol breaks up four times
TCP protocol breaks up four times
Breaking up four times means that a certain end (either the client or the server) wants to end the session and disconnect, then the specific process is:
"First separation" : host1,setthe sequence number Seq (Sequence Number)andconfirmation packet ACK (Acknowledgment Number), assuming that seq is x+2, ACK=y+1, and then set the FIN flag to 1, send Host 2 sends a FIN segment; after that, host 1 entersthe FIN_WAIT_1state; this means that host 1 has no data to send to host 2;
"Second break-up" : Host 2 receives the FIN message segment sent by host 1, and returns an ACK message segment to host 1 (the value is the seq value of the received FIN message + 1); host 1 enters FIN_WAIT_2 state, waiting for the disconnection request packet FIN of host two;
"The third breakup" : host 2 sends a FIN message segment to host 1, which means that I can disconnect and request to close the connection, and host 2 enters the CLOSE_WAIT state at the same time;
"Fourth separation" : host 1 receives the FIN segment sent by host 2 , sends an ACK segment to host 2, the value is the Seq value of the FIN packet just received + 1, and then host 1 enters the TIME_WAIT state; 2 After receiving the ACK message segment fromhost 1 , close the connection; at this time, host 1 still has not received a reply after waiting for 2MSL , which proves that the server has been closed normally, well, host 1 can also close the connection.
why wave four times
TCP is in full-duplex mode, which means that when host 1 sends a FIN segment, it just means that host 1 has no data to send, and host 1 tells host 2 that all its data has been sent; however, At this time, host 1 can still accept data from host 2; when host 2 returns the ACK segment, it means that it already knows that host 1 has no data to send, but host 2 can still send data to host 1; when host 2 also When the FIN segment is sent, it means that host 2 has no data to send, and it will tell host 1 that I have no data to send, and then both parties will happily interrupt the TCP connection . If you want to correctly understand the principle of the four breakups, you need to understand the state changes during the four breakups.
Four waved state explanation
" FIN_WAIT_1 " : This state needs to be explained carefully. In fact,the true meaning of the FIN_WAIT_1 and FIN_WAIT_2 states is to wait for the other party's FIN message. The difference between these two states is: the FIN_WAIT_1 state actually means that when the SOCKET is in the ESTABLISHED state, it wants to actively close the connection and sends a FIN message to the other party. At this time, the SOCKET enters the FIN_WAIT_1 state. "That is, enter the FIN_WAIT_1 state after sending the FIN packet "
And when the other party responds to the ACK message, it enters the FIN_WAIT_2 state. Of course, under actual normal circumstances, no matter what the other party’s situation is, it should immediately respond to the ACK message, so the FIN_WAIT_1 state is generally difficult to see, and The FIN_WAIT_2 state can often be seen with netstat. "That is, enter the FIN_WAIT_2 state after sending the ACK message "
"Active party FIN_WAIT_2 " : This state has been explained in detail above. In fact, SOCKET in the FIN_WAIT_2 state means a semi-connection, that is, one party requests a close connection, but also tells the other party that I still have some data to send to you for the time being. ( ACK message) and close the connection later.
"Active side CLOSE_WAIT " : The meaning of this state is actually waiting to be closed. How do you understand it? When the other party closes a SOCKET and sends a FIN message to itself, your system will undoubtedly respond with an ACK message to the other party, and then enter the CLOSE_WAIT state. Next, what you really need to consider is to check whether you still have data to send to the other party. If not, then you can close the SOCKET and send a FIN message to the other party, that is, close the connection. So what youneed to do in the CLOSE_WAIT state is to wait for you to close the connection.
"Passive party LAST_ACK " : This state is relatively easy to understand. It is a passive closing party that waits for the other party's ACK message after sending a FIN messageAfter receiving the ACK message, it can enter the CLOSED available state. " That is, the state after receiving the other party's FIN packet and sending the ACK and FIN packet yourself "
"Passive party TIME_WAIT " : It means that it has received the other party's FIN message and sent an ACK message, and itwill return to the CLOSED available state after waiting for 2MSL . Ifin the FIN_WAIT1 state, when receiving a message with both the FIN flag and the ACK flag from the other party, it can directly enter the TIME_WAIT state without going through the FIN_WAIT_2 state.
"Active party CLOSED " : Indicates that the connection is interrupted.
TCP state diagram
state diagram explanation
CLOSED : The starting point, enter this state when the timeout or connection is closed.
LISTEN : The state when the svr end is waiting for a connection. The svr end needs to call the socket , bind, and listen functions to enter this state. This is known as the application being opened passively (waiting for a client to connect).
SYN_SENT: The client initiates a connection and sends SYN to the server. If the server cannot connect, it will directly enter the CLOSED state.
SYN_RCVD : Corresponding to 3 , the server accepts the SYN request from the client, and the server enters the SYN_RCVD state from the LISTEN state . At the same time, the server should respond with an ACK and send a SYN to the client; in another case, when the client receives a SYN request from the server while initiating a SYN , the client will change from SYN_SENT to SYN_RCVD .
ESTABLISHED : The server and the client enter the state after completing the 3 -way handshake, indicating that data transmission can already begin. The above is the description of the state transition between the server and the client when the connection is established. It is relatively simple and clear. If you are familiar with the three-way handshake, the state transition when establishing a connection is still easy to understand. Next, the server and the client carry out data transmission. . . . , Of course, there is also a lot of knowledge in it, so I will stop here and explain it later. Next, let's take a look at the description of the state transition when the connection is closed. Closing requires 4 interactions between the two parties, including some aftermath work ( TIME_WAIT state). Note that the party that is actively or passively closed here does not refer to a special Refers to the server side or the client side, which is relative to who initiates the shutdown request first.
FIN_WAIT_1: The party that actively closes, enters this state from state 5 . Send FIN to the other party for specific actions .
FIN_WAIT_2: The party that actively closes receives the other party's FIN ACK and enters this state. As a result, data from the other party can no longer be received. But able to send data to each other.
CLOSE_WAIT : After receiving FIN , the party that is passively closed enters this state. Receive FIN during specific actions and send ACK at the same time .
LAST_ACK : The party that is passively closed initiates a close request and enters this state from state 8 . Send FIN to the other party during the specific action , and enter the CLOSED state when receiving ACK .
CLOSING : When both sides initiate a closing request at the same time, FIN_WAIT_1 will enter this state. The specific action is to receive a FIN request and respond with an ACK at the same time .
TIME_WAIT : The most tangled state is coming. It can be seen from the state diagram that there are 3 states that can be transformed into it, let's analyze them one by one:
a. Enter this state by FIN_WAIT_2: when both parties do not initiate FIN at the same time,
The active closing party enters the state after receiving the FIN of the passive closing party after completing the closing request initiated by itself.
b. Enter from the CLOSING state: both parties initiate the closure at the same time, and both have made a request to initiate a FIN,
When FIN and ACK are received at the same time, enter from the CLOSING state.
c. Entering from FIN_WAIT_1 state: receiving FIN (initiated by the other party), ACK (response to FIN initiated by itself) at the same time,
The difference from b is that the ACK of the FIN response initiated by itself arrives before the FIN request of the other party.
And b means that FIN arrives first. This is the least likely case.
The most incomprehensible state of the 4 closed connections is TIME_WAIT , there are 2 reasons for TIME_WAIT :
Reliably implements termination of TCP full-duplex connections.
Allow old duplicate sections to disappear in the network.
Well, that’s all for today’s sharing, friends who like it are welcome to like, collect and forward, thank you! !