Three-way Handshake actually means that when establishing a TCP connection, the client and server need to send a total of 3 packets. The main purpose of the three-way handshake is to confirm whether the receiving and sending capabilities of both parties are normal , and to specify your own initialization sequence number to prepare for subsequent reliable transmission. In essence, it is to connect to the designated port of the server, establish a TCP connection, synchronize the sequence number and confirmation number of both parties, and exchangeTCP窗口大小 information.
At the beginning, the client is in CLOSED state and the server is in LISTEN state.
First handshake :
The client sends a SYN message to the server and indicates the client's initialization sequence number ISN. At this time the client is in SYN_SENT state. The synchronization bit in the header is SYN=1, the initial sequence number seq=x, and the message segment with SYN=1 cannot carry data, but it consumes a sequence number; (the client sends a network packet and the server receives it. In this way, the server can get Conclusion: the sending capability of the client and the receiving capability of the server are normal )
Second handshake :
After receiving the client's SYN message, the server will respond with its own SYN message and also specify its own initialization sequence number ISN(s). At the same time, the client's ISN + 1 will be used as the ACK value, indicating that it has received the client's SYN, and the server is in the state at this time SYN_RCVD . In the confirmation message segment, SYN=1, ACK=1, confirmation number ack=x+1, and initial sequence number seq=y; (The server sends the packet and the client receives it. In this way, the client can draw the conclusion: the server received , sending capability, the client's receiving and sending capabilities are normal. However, at this time the server cannot confirm whether the client's receiving capability is normal )
The third handshake :
The client receives the SYN+ACK packet from the server and sends a confirmation packet ACK (ack=k+1) to the server. After the packet is sent, the client and the server enter the ESTABLISHED state and complete the three-way handshake (the client sends the packet and the server receives it. In this way The server can draw the conclusion: the client's receiving and sending capabilities are normal, and the server's own sending and receiving capabilities are also normal )
1.2 What is a semi-join queue?
After the server receives the client's SYN for the first time, it will be in the SYN_RCVD state. At this time, the two parties have not fully established their connection. The server will put the requested connection in this state in a queue. We call this queue Semi-joined queue .
Of course, there is also a full connection queue , that is, the three-way handshake has been completed, and the connection established will be placed in the full connection queue. If the queue is full, packet loss may occur.
Here is an additional point about the number of SYN-ACK retransmissions :
After the server sends the SYN-ACK packet, if it does not receive the customer confirmation packet, the server will perform the first retransmission. After waiting for a period of time and still not receiving the customer confirmation packet, it will perform the second retransmission. retransmission times. If the number of retransmissions exceeds the maximum number of retransmissions specified by the system, the system will delete the connection information from the semi-connection queue.
Note that the waiting time for each retransmission is not necessarily the same. It usually increases exponentially. For example, the interval is 1s, 2s, 4s, 8s...
1.3 Is ISN (Initial Sequence Number) fixed?
When a peer sends its SYN to establish a connection, it chooses an initial sequence number for the connection. The ISN changes over time, so each connection will have a different ISN. ISN can be viewed as a 32-bit counter that increments by 1 every 4ms. The purpose of selecting sequence numbers in this way is to prevent packets that have been delayed in the network from being transmitted later, causing one party to the connection to misinterpret it.
One of the important functions of the three-way handshake is that the client and server exchange ISN (Initial Sequence Number) so that the other party knows how to assemble the data according to the sequence number when receiving data next. If the ISN is fixed, it is easy for an attacker to guess subsequent confirmation numbers, so the ISN is dynamically generated.
1.4 Can data be carried during the three-way handshake?
In fact, data can be carried during the third handshake. However, the first and second handshakes cannot carry data
Why is this? You can think about a question. If the first handshake can carry data, if someone wants to maliciously attack the server, he will put a large amount of data in the SYN message in the first handshake every time. Because the attacker simply ignores whether the server's receiving and sending capabilities are normal, and then frantically re-sends SYN messages, this will cause the server to spend a lot of time and memory space receiving these messages.
In other words, data cannot be placed in the first handshake. One simple reason is that it will make the server more vulnerable to attacks. For the third time, the client is already in the ESTABLISHED state. For the client, it has established a connection and already knows that the server's receiving and sending capabilities are normal, so there is nothing wrong with being able to carry data.
1.5 What is a SYN attack?
Server-side resource allocation is allocated during the second handshake, while client-side resources are allocated when the three-way handshake is completed , so the server is vulnerable to SYN flooding attacks. SYN attack means that the client forges a large number of non-existent IP addresses in a short period of time and continuously sends SYN packets to the server. The server replies with confirmation packets and waits for the client to confirm. Since the source address does not exist, the server needs to continue to resend until it times out. , these forged SYN packets will occupy the unconnected queue for a long time, causing normal SYN requests to be discarded because the queue is full, causing network congestion and even system paralysis. SYN attack is a typical DoS/DDoS attack.
Detecting SYN attacks is very convenient. When you see a large number of semi-connected states on the server, especially if the source IP address is random, you can basically conclude that this is a SYN attack. On Linux/Unix, you can use the system's own netstat command to detect SYN attacks.
netstat -n -p TCP | grep SYN_RECV 1
Common methods to defend against SYN attacks include the following:
- Shorten the timeout (SYN Timeout) time
- Increase the maximum number of half connections
- Filter gateway protection
- SYN cookies technology
2. Wave four times
Establishing a connection requires three handshakes, and terminating a connection requires four waves (the four waves are also called a four-way handshake). This is caused by TCP's half-close . The so-called semi-closed actually means that TCP provides the ability for one end of the connection to receive data from the other end after finishing its sending.
The teardown of a TCP connection requires sending four packets, so it is called a Four-way handshake. Either the client or the server can actively initiate the wave action.
At the beginning, both parties are in ESTABLISHED the state. If the client initiates a shutdown request first. The process of waving four times is as follows:
- The first wave: the client sends a FIN message, and a sequence number is specified in the message. At this time the client is in
FIN_WAIT1state.
That is, it sends a connection release message segment (FIN=1, sequence number seq=u), stops sending data, actively closes the TCP connection, enters the FIN_WAIT1 (termination wait 1) state, and waits for confirmation from the server. - The second wave: After receiving the FIN, the server will send an ACK message and use the client's sequence number value + 1 as the sequence number value of the ACK message, indicating that it has received the client's message. At this time, the server in
CLOSE_WAITstate.
That is, after receiving the connection release message segment, the server sends a confirmation message segment (ACK=1, confirmation number ack=u+1, sequence number seq=v), and the server enters the CLOSE_WAIT (closed waiting) state. At this time, TCP In a semi-closed state, the connection from the client to the server is released. After receiving the confirmation from the server, the client enters the FIN_WAIT2 (termination wait 2) state and waits for the connection release segment sent by the server. - The third wave: If the server also wants to disconnect, it will send a FIN message and specify a sequence number just like the client's first wave. The state of the server at this time
LAST_ACK.
That is, the server has no data to send to the client. The server sends a connection release message segment (FIN=1, ACK=1, sequence number seq=w, confirmation number ack=u+1), and the server enters LAST_ACK (final confirmation). ) status, waiting for confirmation from the client. - The fourth wave: After receiving the FIN, the client also sends an ACK message as a response, and uses the server's sequence number value + 1 as the sequence number value of its own ACK message. At this time, the client is in the state
TIME_WAIT. It takes a while to ensure that the server receives its own ACK message before it enters the CLOSED state. After the server receives the ACK message, it is in the closed connection stateCLOSED.
That is, after the client receives the connection release message segment from the server, it sends a confirmation message segment (ACK=1, seq=u+1, ack=w+1), and the client enters the TIME_WAIT (time waiting) state. At this time, TCP has not been released, and the client needs to wait for the time 2MSL set by the timer to enter the CLOSED state.
Receiving a FIN simply means that there is no data flow in that direction. It is normal for the client to perform an active shutdown and enter TIME_WAIT. The server usually performs a passive shutdown and will not enter the TIME_WAIT state.
In socket programming, any party performing the close() operation can generate a waving operation.
2.1 Why does it take four times to wave?
Because when the server receives the client's SYN connection request message, it can directly send a SYN+ACK message. The ACK message is used for response, and the SYN message is used for synchronization . But when closing the connection, when the server receives the FIN message, it is likely that the SOCKET will not be closed immediately, so it can only reply with an ACK message first to tell the client, "I received the FIN message you sent." I can only send FIN messages after all the messages on my server have been sent, so they cannot be sent together. So four waves are needed.
2.2 2MSL waiting state
The TIME_WAIT state also becomes the 2MSL wait state. Each specific TCP implementation must choose a maximum segment lifetime MSL (Maximum Segment Lifetime), which is the maximum time that any segment can remain in the network before being discarded. This time is limited because TCP segments are transmitted within the network as IP datagrams, and IP datagrams have a TTL field that limits their lifetime.
For the MSL value given by a specific implementation, the processing principle is: when TCP performs an active close and sends back the last ACK, the connection must stay in the TIME_WAIT state for 2 times the MSL. This allows TCP to send the final ACK again in case this ACK is lost (the other end times out and resends the final FIN).
Another result of this 2MSL waiting is that during the 2MSL waiting period of this TCP connection, the socket that defines this connection (the client's IP address and port number, the server's IP address and port number) can no longer be used. This connection can only be used again after 2MSL ends.
2.3 What is the significance of waiting for 2MSL when waving four times to release the connection?
MSL is the English abbreviation of Maximum Segment Lifetime, which can be translated as "maximum segment life". It is the longest time for any message to exist on the network. After this time, the message will be discarded.
In order to ensure that the last ACK segment sent by the client can reach the server. Because this ACK may be lost, the server in the LAST-ACK state will not receive the confirmation message for FIN-ACK. The server will time out and retransmit the FIN-ACK, and then the client will retransmit the confirmation again and restart the time 等待计时器. Finally, both the client and the server can be shut down normally. Assume that the client does not wait for 2MSL, but releases the close directly after sending the ACK. Once the ACK is lost, the server cannot enter the closed connection state normally.
Two reasons:
-
Ensure that the last ACK segment sent by the client can reach the server .
This ACK message segment may be lost, so that B in the LAST-ACK state cannot receive the confirmation of the sent FIN+ACK message segment, and the server times out and retransmits the FIN+ACK message segment, while the client can After receiving the retransmitted FIN+ACK message segment within 2MSL time, the client retransmits the confirmation and restarts the 2MSL timer. Finally, both the client and the server enter the CLOSED state. If the client is in the TIME-WAIT state If you do not wait for a period of time, but release the connection immediately after sending the ACK message segment, you will not be able to receive the FIN+ACK message segment retransmitted by the server, so it will not send another confirmation message segment, and the server will not be able to function normally. Enter the CLOSED state.
-
Prevent "expired connection request segment" from appearing in this connection .
After the client sends the last ACK segment, and then goes through 2MSL, all the segments generated during the duration of this connection will disappear from the network, so that these segments will not appear in the next new connection. An old connection request segment.
2.4 Why does the TIME_WAIT state need to go through 2MSL before returning to the CLOSE state?
Theoretically, after all four messages are sent, you can directly enter the CLOSE state. However, the network may be unreliable and the last ACK may be lost. Therefore, the TIME_WAIT state is used to resend ACK messages that may be lost .
3. Summary
"TCP/IP Detailed Explanation Volume 1: Protocol" has a TCP state transition diagram, which is very representative and helps everyone understand the state changes of the three-way handshake and the four-way wave. As shown in the figure below, the thick solid arrows represent normal client state transitions, and the thick dotted arrows represent normal server state transitions.
Full text reference: https://blog.csdn.net/hyg0811/article/details/102366854Interviewer , don’t ask me about three handshakes and four waves_Ape Man Valley’s Blog-CSDN Blog_Ask me about someone who keeps sending messages to the server Request, that is still a dynamic IP, what should I do?