TCP three handshakes and four waves

Transfer: yuanrengu.com/2020/77eef7…

Three-way handshake

  • First handshake: The client sends a SYN packet to the server and specifies the ISN of the initial sequence number of the client. At this point the client is inSYN_SENTState.

A packet segment with SYN=1 in the header and initial sequence number seq=x cannot carry data but consumes one sequence number.

  • Second handshake: After receiving a SYN packet from the client, the server responds with its own SYN packet and specifies its initial SEQUENCE number, ISN(s). At the same time, the ISN + 1 of the client is used as the ACK value, indicating that the server has received a SYN from the clientSYN_RCVDIn the state.

In the acknowledgement packet segment, SYN=1, ACK=1, ACK= X +1, and seq= Y.

  • Third handshake: After receiving a SYN packet, the client sends an ACK packet. Similarly, the ISN + 1 of the server is used as the ACK value, indicating that a SYN packet has been received from the serverESTABLISHEDState. After receiving the ACK packet, the server is also inESTABLISHEDAt this point, the two parties have established a connection.

The ACK segment is ACK=1, the ACK number is ACK= Y +1, and the sequence number is SEq = X +1 (the initial value is SEq = X, so the second packet segment needs +1). The ACK segment can carry data. If it does not carry data, it does not consume the sequence number.

To explain the three-way handshake in more colloquial terms:

  • The server invokes the listen system command, enters the listening state, and waits for the connection of the client.
  • The client sends a message to the serverConnection request message, where SYN=1, ACK=0, select an initial sequence number x.
  • The server receives the request packet and sends it to the clientConnection confirmation message, SYN=1, ACK=1, acknowledge number x+1, and also select an initial sequence number Y.
  • After receiving the connection confirmation packet from the server, the client sends the packet to the serverSend confirmation, the confirmation number is Y +1, and the serial number is X +1.
  • After the server receives the confirmation from the client,Connection is established.

Why do we need three handshakes? Can’t we do two?

  • First handshake: The client sends a network packet and the server receives it. In this way, the server can conclude that the sending capability of the client and the receiving capability of the server are normal.
  • Second handshake: The server sends the packet and the client receives it. In this way, the client can conclude that the receiving and sending capabilities of the server and the client are normal. However, the server cannot confirm whether the client’s reception capability is normal.
  • Third handshake: The client sends the packet and the server receives it. In this way, the server can conclude that the receiving and sending capabilities of the client are normal, and the sending and receiving capabilities of the server are also normal.

Therefore, three handshakes are required to confirm the normal receiving and sending capabilities of both parties.

The possibility of two handshakes

For example, if the client sends a connection request but does not receive any confirmation because the connection request packet is lost, the client retransmits the connection request. Confirmation was received and a connection was established. After data transmission is completed, the connection is released. The client sends two connection request message segments. The first one is lost, and the second reaches the server. The server for the client and send a new connection request, and then send a confirmation message to the client, agreed to establish a connection, do not use three-way handshake, as long as the server send confirmation, to establish a new connection, confirmation letter from the client to ignore the service side, at this time also not send data, consistent service side waiting for the client to send data, waste of resources. (That is, in this case, the server and the client establish two TCP connections, wasting resources)

What is a semi-connected queue?

After the server receives the SYN from the client for the first time, it is in the SYN_RCVD state. At this time, the connection between the two parties has not been fully established. The server places the connection requests in this state in a queue, which is called a half-connection queue.

And of course, there’s a full connection queue, so if you’ve done the three-way handshake, then the connection is put in the full connection queue. If the queue is full, packet loss may occur.

After the server sends the SYN-ACK packet, if the server does not receive the syn-ACK packet, the server retransmits the SYN-ACK packet for the first time. After a period of time, the server retransmits the SYN-ACK packet for the second time. If the number of retransmission times exceeds the upper limit, the system deletes the connection information from the semi-connection queue. Note that the wait time for each retransmission may not be the same, but generally increases exponentially. For example, the interval is 1s, 2s, 4s, 8s…

SYN timed out during connection establishment. For example, if the server receives a SYN-ACK from clien and then replies with a SYN-ACK, the client is disconnected. The server does not receive an ACK from the client. Then, the connection is in an intermediate state, that is, it does not succeed or fail. Therefore, if the server does not receive any TCP within a certain period of time, it resends a SYN-ACK. Under Linux, the default number of retries is 5, and the retry interval starts at 1s. Each retry interval is 1s, 2s, 4s, 8s, and 16s, a total of 31 seconds. After the 5th retry, it has to wait for 32 seconds. TCP will disconnect the connection only after 1s + 2s + 4s+ 8s+ 16s + 32s = 2^ 6-1 = 63s.

Is it fixed?

When one end sends its SYN to establish a connection, it selects an initial sequence number for the connection. The ISN changes over time, so each connection will have a different ISN.

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 side knows how to assemble the data by Sequence Number when they receive the data next. If the ISN is fixed, an attacker can easily guess the subsequent confirmation number, so the ISN is dynamically generated.

For the three-way handshake of a connection, the initial value of the Sequence Number is initialized. The communication parties inform each other of their initialized Sequence Number (ISN: Inital Sequence Number). This number is used as the serial number of future data communication to ensure that the data received by the application layer is not out of order due to transmission problems on the network (TCP uses this serial number to concatenate data).

Can you carry data during a three-way handshake?

In fact, the third handshake can carry data. However, the first and second handshakes cannot carry data.

Why is that?

One problem you can imagine is that if the first handshake can carry data, if someone were to attack the server maliciously, they would put a lot of data in each SYN packet in the first handshake. The attacker does not care whether the server receives and sends SYN packets properly, and then frantically focuses on recurrent SYN packets, which will cost the server a lot of time and memory to receive them.

That is, data should not be released on the first handshake, for one simple reason: it makes the server more vulnerable. For the third time, the client is already in ESTABLISHED state. As far as the client is concerned, it has already established the connection and already knows that the server’s receiving and sending capabilities are normal, so there is no problem with carrying data.

What is a SYN attack?

Resource allocation on the server side is made during the second handshake, while resources on the client side are made when the third handshake is completed, so the server is vulnerable to SYN flooding attacks.

In a SYN attack, the Client forges a large number of nonexistent IP addresses and sends SYN packets to the Server. The Server replies with an acknowledgement packet and waits for the Client to confirm the attack. Because the source IP address does not exist, the Server resends the packets until the attack times out. These forged SYN packets occupy unconnected queues for a long time. As a result, normal SYN requests are discarded because the queues are full, causing network congestion or even system breakdown. SYN attack is a typical DoS/DDoS attack.

Common SYN attack defense methods are as follows:

  • Shorten SYN Timeout
  • Increase the maximum number of connections
  • Filtering gateway Protection
  • The SYN cookies technology

What happens if the third handshake fails?

When the handshake fails for the third time, the server does not retransmit ack packets but directly sends RST packets to the CLOSED state. This is done to prevent SYN flooding attacks.

Three handshakes summary

The primary purpose of the three-way handshake to establish a connection is to synchronize the serial number. Only when the sequence number is synchronized, reliable transmission can be achieved. Many features of TCP depend on the sequence number, such as traffic control, retransmission of lost messages, and so on.

If the SYN half-connection queue is full, can I only drop the connection? This is not the case, as enabling Syncookies can successfully establish a connection without using the SYN queue. Syncookies work like this: The server calculates a value according to the current status and sends it in its OWN SYN+ACK packet. When the client returns an ACK packet, the server takes out the value for verification. If it is valid, the connection is established successfully.

Four times to wave

Three handshakes are required to establish a connection, and four handshakes are required to terminate a connection (sometimes called four handshakes). This is caused by TCP half-close. The so-called half-closed is that TCP provides the ability for one end of a connection to receive data from the other end after it has finished sending.

Removing a TCP connection requires Four packets. This is called four-way Handshake. Either the client or the server can initiate the handshake.

  • First wave: The client sends a FIN packet with a specified sequence number. At this point the client is inFIN_WAIT1State. The issueConnect the release message segment(FIN=1, serial number seq= U), stops sending data again, actively closes the TCP connection, and enters FIN_WAIT1 (Terminate wait 1) state, waiting for confirmation from the server.
  • Second wave: After receiving the FIN, the server sends an ACK packet and uses the serial number of the client +1 as the SEQUENCE number of the ACK packet. In this case, the server is inCLOSE_WAITState. The server sends the connection release packet after receiving the segmentAcknowledgment message segment(ACK=1, ACK= u+1, seq= V), the server enters the CLOSE_WAIT state. At this time, TCP is in the half-closed state and the connection between the client and the server is released. After receiving the confirmation from the server, the client enters the FIN_WAIT2 state and waits for the connection-release packet segment sent by the server.
  • Third wave: If the server also wants to disconnect, the server sends a FIN packet with a specified sequence number as the first wave from the client. The server is inLAST_ACKIn the state. That is, the server does not send data to the client, the server sends dataConnect the release message segment(FIN=1, ACK=1, seq= W, ACK= U +1), the server enters the LAST_ACK state and waits for the confirmation from the client.
  • Fourth wave: After receiving the FIN, the client sends the same ACK packet and uses the sequence number of the server +1 as the sequence number of its own ACK packetTIME_WAITState. It takes a while to ensure that the server receives its ACK packet before it enters the CLOSED state. After receiving the ACK packet, the server is in the CLOSED stateCLOSEDState. After receiving the connection release packet from the server, the client sends the packetAcknowledgment message segment(ACK=1, SEq = U +1, ACK= w+1), the client enters the TIME_WAIT state. In this case, TCP is not released and the client enters the CLOSED state after waiting for the time set by the timer to be 2MSL.

Why do you need four waves

This is because TCP does not allow one-way transmission of data when the connection is half-open. Therefore, when a three-way handshake is used to establish a connection, the server sends an ACK and a SYN together to the client. ACK is used to open the client’s sending channel, and SYN is used to open the server’s sending channel. Thus, the original four handshakes were reduced to three.

But TCP allows one-way transmission of data when the connection is half-closed. For the sake of understanding, we call the party that closes the connection first the active party, and the party that closes the connection later the passive party. When the active party closes the connection, the passive party can still send data for a long time without calling the close function, and the connection is half-closed. This feature is due to the isolation of TCP’s bidirectional channels, but it also makes closing a connection require four waves of the hand.

What is the meaning of waiting for 2MSL when four times waving to release the connection?

MSL indicates the Maximum Segment Lifetime, which indicates the Maximum length of time that a packet exists on the network before being discarded.

To ensure that the last ACK packet segment sent by the client can reach the server. The ACK may be lost. As a result, the server in the last-ACK state cannot receive the fin-ACK acknowledgement packet. The server will time out to retransmit the FIN-ACK, and the client will retransmit again for confirmation, and the restart time will wait for a timer. Finally, both the client and the server can be shut down normally. Suppose the client does not wait for 2MSL, but releases the closed ACK after sending it. Once the ACK is lost, the server cannot enter the closed connection state properly.

Two reasons:

  1. Ensure that the last ACK packet sent by the client reaches the server.

The ACK packet segment may be lost. As a result, the server in the last-ack state cannot receive the confirmation of the sent FIN+ACK packet segment. The server retransmits the FIN+ACK packet segment timeout, and the client receives the FIN+ACK packet segment within 2MSL. Restart the 2MSL timer. Finally, both the client and server enter the CLOSED state. If the client does not WAIT for a period of TIME in the time-wait state but immediately releases the connection after sending the ACK packet, the client cannot receive the FIN+ACK packet retransmitted by the server, so it does not send the acknowledgement packet again. The server cannot enter the CLOSED state.

  1. Prevents invalid connection request message segment from appearing in this connection.

After sending the last ACK message segment, the client can make all the message segments generated during the duration of the connection disappear from the network after 2MSL, so that the old connection request message segment will not appear in the next new connection.

What happens if the active party does not keep TIME_WAIT? The connected port is now free and can be used again for new connections. However, a FIN packet from the passive node may arrive again, either because a router on the network sends an ORPHAN_retries packet repeatedly or because the passive node does not receive an ACK. In this case, a new connection that normally communicates may be closed by repeated FIN packets. If the TIME_WAIT state is reserved, FIN packets can be retransmitted. Of course, other data packets may be retransmitted. Therefore, the TIME_WAIT state prevents data errors.

How to handle too many time-wait states

  • Example Change the upper limit of the TIME_WAIT connection status
  • Enable the quick recycle mechanism
  • Enabling the Reuse mechanism
  • Example Change the short connection to the long connection
  • The client disconnects voluntarily