Introduction and solution of TCP sticky packet and half packet (Part 1)

In network transmission, sticky packets and half packets are probably the most common problems. As the most commonly used NIO network framework in Java, Netty, how does it solve these problems? Let's take a look today.

[[280029]]

definition

In TCP transmission, when the client sends data, it actually writes the data into the TCP cache, and sticky packets and half packets are generated at this time.

The client sends two messages ABC and DEF to the server. How many situations will the server receive? It is possible that all messages ABCDEF are received at once, or it is possible that three messages AB, CD, and EF are received.

The above mentioned receiving all messages ABCDEF at one time is similar to packet sticking. If the size of the packet sent by the client is smaller than the TCP buffer capacity, and the TCP buffer can store multiple packets, then the client and server may transmit multiple packets in one communication. At this time, the server may read multiple packets from the TCP buffer at once. This phenomenon is called packet sticking.

The latter case mentioned above, where three messages AB, CD, and EF are received, is similar to half a packet. If the size of the packet sent by the client is larger than the TCP buffer capacity, then the data packet will be divided into multiple packets and sent to the server through the Socket multiple times. The first data obtained by the server from the receiving buffer is actually part of the whole packet, and a half packet is generated at this time (a half packet does not mean that only half of the whole packet is received, but part of the whole packet is received).

Cause

In fact, from the above definition, we can roughly know the cause of the occurrence.

The main reasons for sticky bags:

• The sender writes data each time < the socket buffer size
• The receiver does not read the socket buffer data in time.

The main reasons for half pack:

• The sender writes data each time > the socket buffer size
• The data being sent is larger than the protocol's MTU (Maximum Transmission Unit), so it must be unpacked

In fact, we can look at the problem from another angle:

• From the perspective of sending and receiving, one transmission may be received multiple times, and multiple transmissions may be received once.
• From the perspective of transmission, one transmission may occupy multiple transmission packets, and multiple transmissions may share one transmission packet.

The root cause is actually

TCP is a streaming protocol and messages have no boundaries.

(PS: Although UDP can also transmit multiple packets at a time or transmit a packet multiple times, each message has a boundary, so there will be no sticky packet or half-packet problems.)

Workaround

As mentioned above, the reason why UDP does not have sticky packet and half-packet problems is mainly because messages have boundaries. Therefore, we can also adopt a similar approach.

1. Change to short connection

Change the TCP connection to a short connection, one request for one short connection. In this way, the message between establishing the connection and releasing the connection is the transmitted information, and the message also has a boundary.

This method is very simple and does not require much modification in our application. However, its disadvantages are also obvious. It is inefficient. TCP connection and disconnection involve three-way handshake and four-way handshake. Each message involves these processes, which wastes performance.

Therefore, this approach is not recommended.

2. Encapsulation into frames

Encapsulation into framing (Framing), that is, the original unit of sending messages is the buffer size, now it is changed to frame, so that we can customize the boundary. Generally there are 4 ways:

3. Fixed length

In this way, the message boundary is just a fixed length.

The advantage is that it is very simple to implement, but the disadvantage is that there is a huge waste of space. If most of the messages transmitted are relatively short, a lot of space will be wasted.

Therefore, this method is generally not recommended.

4. Separator

In this way, the message boundary is the delimiter itself.

The advantage is that space is no longer wasted and the implementation is relatively simple. The disadvantage is that when delimiters appear in the content itself, they need to be escaped, so the entire content needs to be scanned whether it is sent or received.

Therefore, this method is not very efficient, but you can try it.

5. Special length field

This method is similar to the Content-Length field in HTTP requests, which has a dedicated field to store the length of the message. When receiving a message, the server first parses the fixed-length field (length field) to obtain the total length of the message, and then reads the subsequent content.

The advantage is that the user data can be accurately located and the content does not need to be escaped. The disadvantage is that the length is theoretically limited, and the maximum possible length needs to be limited in advance to define the number of bytes occupied by the length.

Therefore, this method is highly recommended.

6. Other methods

Other methods are different. For example, JSON can be seen as whether the {} is used in pairs. These advantages and disadvantages need to be weighed in their respective scenarios.

Implementation in Netty

Netty supports the first three methods of framing mentioned above. Here is a brief introduction: