A sequence.
When we talk about TCP, we talk about three handshakes and four waves. But most of the materials and articles are about the normal process. But have you ever wondered what happens when something goes wrong during a three-handshake or four-wave? And who will handle it?
As a reliable protocol, TCP needs to establish a connection between two ends before and after data transmission and maintain the connection status on both ends. There is nothing special about TCP. In the face of changing network conditions, it can only ensure reliability through constant retransmission and various algorithms.
Before establishing a connection, TCP uses a three-way handshake to ensure that the status of both ends is correct, and then data can be transmitted normally. When data transfer is complete and the two ends need to be disconnected, TCP disconnects the two ends through a four-way handshake and reclaims resources.
When we learn TCP connection and disconnection, most of us are talking about a standard process, but the network environment is changeable, many times it is not as standard as textbooks, so today we will talk about, TCP three handshake and four wave, if there is an abnormal situation, how to deal with it? Who will deal with it?
TCP Three-way handshake
2.1 Simple understanding of the three-way handshake
Although this is an anomaly, let’s take a look at the three-way handshake.
When transferring data over TCP, the first step is to establish a connection. The process of establishing a TCP connection is called the three-way handshake.
We often describe the three-way handshake as “request → reply → reply of reply”.
As for the TCP handshake, why three? In fact, it is to let both ends experience a “request → reply” process, to confirm that the other party is still in. The network situation is changeable. Both ends need to initiate a request and reply to each other to ensure that the other party and the network are normal.
The following diagram shows the classic TCP three-way handshake message and the change of the two-end state.
Let’s explain the graph first:
1. Initially, both ends are in the CLOSE state. To provide services, the server actively listens to a port and enters the LISTEN state.
2. The client proactively sends a SYN packet and then enters the SYN-sent state. After receiving the SYN packet, the server replies with a SYN,ACK packet and enters the SYN-RCVD state.
3. After receiving the SYN,ACK packet from the server, the client can confirm that the SYN exists, reply to the ACK packet, and enter the ESTABLISHED state.
4. The server enters the ESTABLISHED state after receiving the last ACK packet.
This is a normal TCP three-way handshake. After the handshake, both ends enter the ESTABLISHED state. After the handshake, data transfer is normal.
2.2 TCP Handshake Exceptions
The normal sending and replying of the three-way handshake, and the two-end state reversal we’ve talked about, now we’re going to look at the anomalies that occur during the three-way handshake.
1. The first SYN packet is lost on the client.
If the client loses the first “SYN” packet, that is, the server doesn’t even know that the client sent the packet, the processing is mostly on the client.
In THE TCP protocol, if no ACK packet is received within a certain period of time, whether the request packet is not received by the other party or the reply packet is not received by the other party, the packet is considered to be lost and the timeout retransmission mechanism is triggered.
Therefore, the SYN packet is retransmitted. According to TCP/IP Volume I: Protocol, three attempts are made at intervals of 5.8s, 24s, 48s, and approximately 76s. Most Berkeley systems limit the maximum time to establish a new connection to 75s.
If the first SYN packet is lost, it will be retransmitted. The total attempt time is 75s.
Reference: “TCP/IP (18 | 1 TCP connection establishment and termination of”
2. The server receives SYN and replies with the SYN,ACK packet. Procedure
In this case, the server has received the packet and replied with a SYN ACK packet. If the ACK packet is missing, the client considers the original SYN packet to be missing and retransmits the packet, which is the “error 1” process.
If the server loses the SYN,ACK packet and does not receive any ACK packet from the client within the timeout period, retransmission is triggered. In this case, the server is in SYN_RCVD state and sends the SYN,ACK packet again after 3s, 6s, and 12s.
The number of times for retransmitting the SYN,ACK packet varies depending on the operating system. For example, in Linux, the value can be set using tcp_SYNack_retries. The default value is 5. If no ACK is received within this number of retries, the server automatically closes the connection.
If the client does not receive SYN,ACK, the client retransmits the PACKET. If the client receives SYN,ACK, the server immediately resends the SYN,ACK packet.
3. The ACK packet that replies with SYN,ACK for the last time is lost.
If the last ACK packet is lost, the server uses the retransmission mechanism because it cannot receive the ACK packet, and the client enters the ESTABLISHED state.
In most cases, after the client enters the ESTABLISHED state, it considers that the connection is ESTABLISHED and sends data immediately. However, the server is still in syn-RCVD state because it did not receive the last ACK packet.
In this case, the key is how to handle the packets received by the client in syn-RCVD state.
When the server is in syn-RCVD state, it will directly reply to the RTS packet after receiving the packet from the client, indicating that the server is in error and enters the CLOSE state.
However, this setting is a little too strict. Imagine that the server is still trying to determine whether or not the other party really exists through the three-way handshake. At this point, the data of the other party has already been sent, so it must exist.
Therefore, when the server is in the SYN-RCVD state and receives data packets from the client, the server considers that the connection is ESTABLISHED and enters the ESTABLISHED state.
What happens if the third ACK of the TCP three-way handshake is lost?
So why is this the case?
When the client is in the ESTABLISHED state, when it sends packets, it carries the ACK id of the previous packet. Therefore, even if the ACK id of the response packet is lost, the server can use the ACK id to enter the ESTABLISHED state when receiving the packet.
Reference: What if a TCP Handshake Segment is Lost?
4. The client intentionally does not send the last SYN packet.
In front of the normal abnormal logic, both sides are still friendly, according to the rules, abnormal is mainly due to the network and other objective problems, next to say a malicious situation.
If a malicious client sends a SYN packet and does not reply with a SYN,ACK packet, the server is in a half-connected state. The server does not wait indefinitely but waits for a period of time through tcp_SYNack_retries.
If a large number of such malicious connections occur in a short period of time, the server is under great pressure. This is called SYN FLOOD attacks.
This belongs to the category of security attack and defense, today will not discuss, interested can understand.
Three. TCP wave four times
3.1 Simple understanding of the four waves
After the TCP three-way handshake, continue to analyze the TCP four-way wave exception.
In style, before we do that, let’s take a quick look at TCP’s four waves.
When the data transfer is complete and the connection needs to be disconnected, TCP securely disconnects the connection by waving four times.
Why does it take three handshakes and four waves?
Essentially, both ends need to go through a “break up” process to ensure that they and their counterparts are in the right state. In the spirit of friendly negotiation attitude, you put forward the first break up, but also to the biggest goodwill to the other side, can not hit the other side a unprepared. You said you would stop playing, and then who would dare to play with you.
The following figure shows the classic TCP four-wave message and the change of the two-end state.
Let’s explain this graph:
1. Initially, both ends are in the ESTABLISHED state and transmit data. One end initiates a FIN packet to disconnect the connection. After “FIN” is emitted, the client enters the FIN-WaIT-1 state.
2. After receiving the FIN message, the server replies with ACK to indicate that it knows the connection and enters the closed-wait state from ESTABLISHED to perform preparations before the connection is disconnected.
3. The client enters the FIN-WaIT-2 state after receiving the ACK message from FIN. After the server completes the preparatory work, it sends a “FIN,ACK” message to the client, indicating that IT is ok and requests to disconnect. After the message is sent, the server enters the last-ACK state.
4. After receiving the “FIN,ACK” message, the client immediately replies with “ACK” indicating that it is aware of the request and enters the TIME_WAIT state. For stability and security, the client will WAIT in the time-wait state for 2MSL before entering the CLOSED state.
5. After receiving the ACK message from the client, the server enters the CLOSED state from the last-ACK state.
After four normal waves, both ends enter the CLOSED state, after which, the two ends are officially disconnected.
3.2 TCP wave Waving Exception
Now that we have a brief understanding of the normal process of sending and answering the four waves, let’s continue to look at the abnormal situation that occurs during the four waves.
1. The disconnected FIN packet is lost.
As we have stressed before, if a packet is sent, as long as there is no ACK reply from the peer end within a certain period of time, the packet is considered lost and the timeout retransmission mechanism will be triggered. They don’t care if they lost their packet or their ACK.
Therefore, if the client loses the first “FIN” packet or does not receive an “ACK” reply from the peer end, the client will trigger timeout retransmission until the number of retransmission times is triggered and the connection is directly closed.
For the server, if the “FIN” sent by the client is not received, it does not feel anything. Will also close the connection after some time.
2. The server loses the first ACK reply.
Since the client does not receive an ACK response, it tries to retransmit the FIN request. After receiving the REQUEST, the server retransmits the ACK request.
In this case, the server enters the closed-wait state and prepares for the connection disconnection. When it is ready, it replies with “FIN,ACK”, noting that this message carries the response sequence number of the previous “ACK”.
As long as the message is not lost, the client can directly switch from fin-wait-1 state to time-wait state by using the response sequence number in the “FIN,ACK” packet, and start to WAIT for up to 2MSL.
3. The FIN and ACK sent by the server are lost.
The server retransmits data after a timeout. In this case, the client is in fin-WaIT-2 state (the ACK is also lost) and waits. Or in time-wait state, WAIT 2MSL.
In other words, the client will still be there for a short period of time. After receiving the “FIN,ACK” packet from the server, the client will reply with an “ACK” reply and do its own state switchover.
4. The last ACK sent by the client is lost.
After receiving an ACK reply, the client enters the time-wait state and waits for 2MSL. Because the server does not receive an ACK reply, it tries again for a period of TIME until the server disconnects.
Or, after a new client is connected, the server replies with an RST message after receiving the FIN message. After receiving the RST message, the server resets the status.
5. After the client receives the ACK, the server runs away.
After receiving an ACK, the client enters fin-WaIT-2 and waits for a “FIN” packet from the server, which will never happen if the server runs away.
In TCP, there is no mechanism for handling this state. The operating system takes over the state. For example, under Linux, you can set a timeout for this state with the tcp_fin_timeout parameter.
Note that when tcp_fin_TIMEOUT is exceeded, instead of switching to TIME_WAIT, the state goes directly to CLOSED.
Reference: About FIN_WAIT2
6. After receiving the ACK, the client runs away.
After receiving the ACK message, the client immediately runs away. The server does not receive any reply to the subsequent FIN,ACK message, and constantly uses the TCP timeout retry mechanism. In this case, the server is in the last-ACK state.
That is to be divided into two situations:
- The server automatically disconnects after a certain period of time.
- Disconnect the device after receiving the RST message.
An “RST” message is a reset message indicating that the current error should be returned to the original state. If a client runs away and a new client accesses the client, the client sends SYN to establish a connection. In this case, the SYN is ignored and replies with a FIN,ACK message. The new client does not recognize the FIN message and replies with an RST message.
Coping with the TCP Time-Wait State on Busy Linux Servers
Four. Summary moment
This article discusses the TCP in the three handshake and four wave, abnormal processing logic.
In most cases, timeout retransmissions are relied on to ensure TCP reliability, but the number of retransmissions, state transitions, and which states are taken over by the system are the subject of this article.
If you have any questions, please leave a message for discussion. If you have any help, please don’t forget to forward and click on the collection to support it. Thank you!
“Growth”, will get the learning materials I prepared.
