3000 words on TCP protocol, handshake is not as simple as you think

Last time I talked about the UDP protocol. From this time on, I will talk about the TCP protocol. Because the TCP protocol involves a lot of things and it cannot be summarized in one article, I will divide the content of the TCP protocol into several parts and break them down one by one.

TCP segment structure

When talking about TCP protocol, the first words that come to mind are "connection-oriented" and "reliable". That's right, the TCP protocol is designed to establish a reliable connection between the client and the server.

Before talking about the connection process, let's take a look at the TCP segment structure. Through this structure, we can know what information TCP can provide:

There are a few things to note here:

• The TCP protocol requires a four-tuple (source IP, source port, destination IP, destination port) to determine the connection, which is different from the UDP protocol. In addition, the IP address is located in the IP segment, and the TCP segment does not contain IP address information.
• The length of the basic TCP header is 20 bytes, but since the length of the "option" is uncertain, the "header length" field is required to clearly give the header length. It should be noted here that the unit of the header length field is 32 bits, which is 4 bytes, so the minimum value of this field is 5.
• The fields marked in orange (confirmation number, receive window size, ECE, ACK) are used to "reply" to the other party. For example, after the server receives the data packet from the other party, it does not send a separate data packet to respond, but waits a while and attaches the confirmation information to the next data frame sent to the client, which is the piggybacking technology.
• The window size is a 16-bit unsigned number, which means that the window is limited to 65535 bytes, which limits the throughput performance of TCP, which is not very friendly to some high-speed and high-latency networks (you can think about why). Fortunately, TCP provides an additional window scaling option that allows this value to be scaled.

The following are the meanings of the 8 flags. Some older protocols may not have the first two flags:

Although there are many flags, it is easy to understand their functions if we look at them in a specific scenario.

Three-way handshake

The three-way handshake is to establish a connection between the client and the server. The process is not complicated, but there are many details to pay attention to.

This picture shows the handshake process. You can see that a total of three messages are transmitted between the client and the server. These three handshakes are actually the mutual confirmation of status between the two machines. Let's look at it one by one.

1. First handshake

First, the client initiates the connection. The first packet sets SYN (that is, SYN = 1), indicating that this packet is a SYN segment (also called segment 1). The purpose of this transmission is to tell the server that its initial sequence number is client_isn. There is also an implicit message that is not shown in the figure, which is to tell the server the port number it wants to connect to. In addition to these, the client will also send some options, but this has little to do with the three-way handshake, so let's not talk about it for now.

The most important thing to note in section 1 is client_isn, which is the initial sequence number. "RFC0793^1" states:

In other words, the initial sequence number is a 32-bit (virtual) counter, and this counter is incremented by 1 every 4 microseconds, that is, the value of ISN cycles every 4.55 hours. This measure is to prevent the sequence number from overlapping.

But even so, there are still security risks - because the initial ISN is still predictable, malicious programs may analyze the ISN, and then predict the ISN of subsequent TCP connections based on the previously used ISN, and then attack. A famous example is "The Mitnick attack^2". Here is an excerpt from the original text:

Therefore, in order to make the initial sequence number more difficult to predict, modern systems often use a semi-random method to select the initial sequence number. The detailed method will not be expanded here.

2. Second handshake

When the server receives the connection request from the client, it will send an ACK to the client to indicate that it has received the connection request. In addition, the server must tell the client its initial sequence number. These are actually two steps, but they can be completed by sending one data packet, using the piggybacking technology mentioned above. The ACK = client_isn + 1 in the figure refers to the value of the confirmation number field, which should be distinguished from the ACK flag.

There are actually a lot of things to note about the ACK field, but it is more intuitive to talk about it together with the sliding window, so I won’t mention it here.

It is important to emphasize here that when a SYN segment arrives, the server will check whether the number of connections in the SYN_RCVD state exceeds the parameter tcp_max_syn_backlog. If it exceeds, the server will reject the connection. Of course, this can also be exploited by hackers, and "SYN Flood" is a good example. Because after the server replies to SYN-ACK, it will wait for the client's ACK. If it does not receive it within a certain period of time, it will think that the packet is lost, and it will resend SYN-ACK. After repeating several times, the connection will be disconnected. Linux may take a minute to disconnect. Therefore, if the attacker creates a large number of SYN requests without replying, the server's SYN queue will be exhausted quickly. During this period of time, normal connections will not be responded to.

This state of the server is called muted. In order to defend against SYN Flood attacks, the server can use "SYN cookies". The idea is that when SYN arrives, it does not directly allocate memory for it, but encodes the information of this connection and saves it in the sequence number field of the SYN-ACK segment. If the client replies, the server will then solve the important information of the SYN message from the ACK field (it feels a bit like black magic), and allocate memory for the connection after successful verification. In this way, the server will not respond to the attacker's request, and the normal connection will not be affected.

However, SYN cookies themselves have some limitations and are not suitable as a default option. If you are interested, you can Google it yourself.

3. The third handshake

This is the last step in establishing a TCP connection. After the first two handshakes, the client (server) already knows the other party's sliding window size, initial sequence number and other information. Isn't that the end? Why is there a third handshake?

This is because although the server has sent the data packet, it does not know whether the client has received the packet, so the server needs to wait for the client to return an ACK, indicating that the client has received the data. At this point, the connection is completed.

After the connection is established, the data transmission phase begins. This involves many, many technologies, which I will write another article about.

Four waves

With the foundation of three-way handshake, four-way handshake is easier to understand:

The process of four waves is actually very simple. The server and the client send FIN and ACK segments to each other to inform the other party to disconnect.

One thing worth noting in the four waves is the TIME_WAIT state, which means that the party that actively closes the connection will have to wait for 2MSL time to completely close the connection even if it receives the FIN message from the other party. (The MSL here refers to the maximum segment generation period, which refers to the maximum time that a segment is allowed to exist in the network.) But why not just close the connection directly?

One reason is that the ACK segment of the fourth wave may not have reached the server. In order to prevent the server from being in the LAST_ACK state (the server will resend FIN until ACK is received), the client has to wait for a while to see if it needs to resend. If the packet is really lost, the server sends FIN, and the FIN message will not exceed 2MSL when it reaches the client (a maximum of 2MSL for a round trip). At this time, the TCP on the client side has not been shut down, and ACK can be resent.

Another reason is that after 2MSL, all packets related to the connection in the network have disappeared and will not interfere with the new connection. Let's take an example: if the client establishes a new connection to the server, some delayed data in the old connection persists until the new connection is established, and the sequence number happens to be within the sliding window, the server mistakenly receives it as a data packet of the new connection, as shown in the following figure:

The 2MSL mechanism avoids this situation.