Summary of solutions to socket sticking and unpacking

In the usual client socket development, if the client continuously sends data packets to the server, the data received by the server will appear two packets stick together, which is often encountered in the TCP protocol. Packaging and unpacking issues.

We all know that TCP belongs to the protocol of the transport layer. In addition to the TCP protocol, the transport layer also has the UDP protocol. So will UDP stick or unpack? The answer is no. UDP is sent based on packets. It can be seen from the frame structure of UDP that 16 bits are used in the UDP header to indicate the length of the UDP data packets. Therefore, different data packets can be well distinguished at the application layer, so that Avoid sticking and unpacking problems. TCP is based on byte streams. Although the data exchange between the application layer and the TCP transport layer is data blocks of varying sizes, TCP only regards these data blocks as a series of unstructured byte streams without boundaries; It can also be seen from the frame structure of TCP that there is no field indicating the data length in the TCP header. Based on the above two points, when using TCP to transmit data, it is possible to stick or unpack packets.

Form of sticking and unpacking

Now suppose the client sends two data packets continuously to the server, represented by packet1 and packet2, then the data received by the server can be divided into three types, which are listed as follows:

In the first case, the receiving end normally receives two data packets, that is, there is no unpacking and packet sticking, which is not within the scope of this article.

In the second case, the receiver only receives one data packet. Since TCP does not lose packets, this data packet contains the information of the two data packets sent by the sender. This phenomenon is called sticky packets. . This situation is difficult for the receiver to handle because the receiver does not know the boundaries of the two packets.

In the third case, this situation has two manifestations, as shown in the following figure. The receiving end receives two data packets, but these two data packets are either incomplete or have an extra piece. In this case, unpacking and sticking occur. If no special treatment is applied to these two cases, it is also difficult for the receiving end to deal with them.

 

The reasons for sticking and unpacking

There are many reasons for the occurrence of TCP sticking or unpacking. Here are some common points, which may not be comprehensive. Welcome to add.

1. If the data to be sent is larger than the remaining space in the TCP send buffer, unpacking will occur.

2. If the data to be sent is larger than MSS (maximum message length), TCP will unpack before transmission.

3. The data to be sent is smaller than the size of the TCP send buffer. TCP will send the data written to the buffer multiple times at one time, and a sticky packet will occur.

4. If the application layer of the receiving data end fails to read the data in the receiving buffer in time, sticky packets will occur.

etc.

Sticking and unpacking solutions

Through the above analysis, we understand the reasons for sticking or unpacking, so how to solve this problem? The key to solving the problem is how to add boundary information to each data packet. The commonly used methods are as follows:

1. The sender adds a packet header to each data packet. The header should contain at least the length of the data packet, so that the receiver can know the actual length of each data packet by reading the length field of the packet header after receiving the data. .

2. The sender encapsulates each data packet into a fixed length (if it is not enough, it can be filled with 0s), so that the receiving end will naturally split each data packet every time it reads fixed-length data from the receiving buffer. Come.

3. A boundary can be set between data packets, such as adding special symbols, so that the receiving end can split different data packets through this boundary.

etc.

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324445473&siteId=291194637