The article long-term maintenance version: yuanrengu.com/2020/77eef7…

Three handshakes and four waves of the hand are common in various companies, but also have a certain level of differentiation, some interviewers also used as a warm-up question. Many friends say that the answer to this question is very good at the beginning, but the more you answer the more cold sweat, and finally stopped eating.

A typical interview scenario is like this:

Interviewer: Tell me about the three handshakes

Job seeker: The first handshake means that the client sends a packet to the server. The second handshake means that the server responds with a packet to the client after receiving the packet. The third handshake means that the client sends a packet to the server after receiving the packet.

Interviewer: And then?

Job seeker: That’s the three-way handshake. It’s easy.

Interviewer:…

(A cool cool to you)

Remember a sentence from the Valley of apes: The simpler the interview question is, the bigger the hole is hidden, and it is generally needed to expand the question. Was the applicant’s answer wrong? Sure, but it may not be as good as the interviewer’s expectations.

I hope you can read with the following questions and gain more.

  1. Please draw a diagram of three handshakes and four waves
  2. Why three handshakes when connecting?
  3. What is a semi-connected queue?
  4. Is the ISN(Initial Sequence Number) fixed?
  5. Can you carry data during a three-way handshake?
  6. What does the client server do if the third handshake is lost?
  7. What is a SYN attack?
  8. Why do you need four waves?
  9. What is the meaning of waiting for 2MSL when four times waving to release the connection?

1. Three handshakes

A three-way Handshake is a TCP connection that requires the client and server to send Three packets. The main function of the three-way handshake is to confirm whether the receiving and sending capabilities of both parties are normal, and to specify their initial serial numbers for the preparation of reliable transmission. In fact, it is to connect the server to the specified port, establish a TCP connection, and synchronize the serial number and confirmation number of both sides of the connection, exchange TCP window size information.

At first, the client is in the Closed state and the server is in the Listen state. Shake hands three times:

  • First handshake: The client sends a SYN packet to the server with the initial sequence number ISN(c) of the client. The client is in the SYN_SEND state.

    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 client, and the server is in the SYN_RCVD 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 server. The client is in the ESTABLISHED state. After receiving the ACK packet, the server is also in the ESTABLISHED state. In this case, a connection is ESTABLISHED.

    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.

The sender of the first SYN performs active open and the recipient of the next SYN performs passive open.

In socket programming, a client executing connect() triggers a three-way handshake.

1.1 Why three handshakes, not two?

To figure this out, we need to figure out what the purpose of the three-way handshake is, and whether it can be achieved with just two handshakes.

  • 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.

Imagine a two-handshake situation like this:

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.

1.2 What is a Half-connection 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 sending the SYN-ACK packet, the server retransmits the syn-ACK packet for the first time. If the server does not receive the syn-ACK packet for 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……

1.3 Is the ISN(Initial Sequence Number) 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. The ISN can be thought of as a 32-bit counter incremented by 1 every 4ms. The purpose of this selection is to prevent a packet delayed in the network from being transmitted later, resulting in a misinterpretation of it by one of the connected parties.

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.

1.4 Can data be carried during the 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.

1.5 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.

SYN attacks are very easy to detect. When you see a lot of semi-connected states on the server, especially if the source IP address is random, you can basically tell that this is a SYN attack. On Linux/Unix, you can use the netstats command to detect SYN attacks.

netstat -n -p TCP | grep SYN_RECV
Copy the code

Common SYN attack defense methods are as follows:

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

2. Wave four times

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. The client or server can initiate the handshake.

Both sides are initially in the ESTABLISHED state. Suppose the client initiates the shutdown request first. The four-wave process is as follows:

  • 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.

Receiving a FIN simply means that there is no data flow in that direction. It is normal for a client to perform active shutdown and enter TIME_WAIT, while a server usually performs passive shutdown and does not enter TIME_WAIT.

In socket programming, a close() operation on either side produces a wave operation.

2.1 Why do you need four waves?

After receiving a SYN request packet from a client, the server sends a SYN+ACK packet. ACK packets are used for reply, and SYN packets are used for synchronization. However, when the server receives a FIN packet, it may not close the SOCKET immediately. Therefore, the server can only reply with an ACK packet to tell the client, “I received the FIN packet you sent.” I can send FIN packets only after all packets on the server are sent. Therefore, THE FIN packets cannot be sent together. So you need four waves.

2.2 2MSL Wait status

The TIME_WAIT state also becomes the 2MSL wait state. Each TCP implementation must select a Maximum Segment Lifetime (MSL), which is the Maximum time that a packet Segment is allowed to live in the network before being discarded. This time is limited because TCP segments travel across the network as IP datagrams, and IP datagrams have TTL fields that limit their lifetime.

For a given MSL value for a particular implementation, the rule is that when TCP performs an active shutdown and sends back the last ACK, the connection must stay in TIME_WAIT for twice as long as MSL. This causes TCP to send the last ACK again in case the ACK is lost (the other end times out and resends the last FIN).

Another consequence of this 2MSL wait is that the socket that defines the TCP connection (client’S IP address and port number, server’s IP address and port number) can no longer be used during the 2MSL wait. This connection can only be used after 2MSL ends.

2.3 What is the meaning of waiting for 2MSL when four times wave to release 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 segment may be lost. As a result, user B in the last-ack state cannot receive the sent FIN+ACK segment. The server retransmits the FIN+ACK segment, and the client can receive the FIN+ACK 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.
  2. 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.

2.4 why does TIME_WAIT take 2MSL to return to CLOSE?

Theoretically, after all four packets are sent, the CLOSE state can be directly entered. However, the network may be unreliable and the last ACK may be lost. Therefore, the TIME_WAIT state is used to resend ACK packets that may be lost.

3. Summary

TCP/IP Volume 1: Protocols has a typical TCP state transition diagram to help you understand the state changes of the three-way handshake and the four-way wave. As shown in the figure below, the thick solid arrows indicate normal client state transitions and the thick dashed arrows indicate normal server state transitions.

In the future, the interviewer will ask you for three more handshakes and four more waves. Just throw this essay at the interviewer. It’s all there.

Reference: TCP/IP Volume 1: Protocols