How to solve the problem of sticky tcp packets?

Methods to deal with tcp sticky packet problem: 1. Fixed-length sending method, the sending end uses LEN as the length to packetize when sending data; 2. Tail mark sequence method, in each data to be sent Set a special byte sequence at the end of the packet; 3. Header marking step-by-step reception method, define a user header, and indicate the size of the data packet sent each time in the header.

Methods to deal with tcp sticky packet problem:

1. Design Plan 1: Fixed-length sending

When sending data, a fixed-length design is adopted, that is, no matter how large the data is sent, it is packetized into a fixed length (for the convenience of description, the fixed length is recorded as LEN here), that is, sending When sending data, the end uses LEN as the length for packetization. In this way, the receiver receives with a fixed LEN, so that sending and receiving can correspond one to one. When sub-packaging, it may not be completely divided into multiple complete LEN packets. The last packet will generally be smaller than LEN. At this time, the last packet can fill the missing part with blank bytes.

Of course, this approach has flaws.

1. The insufficient length of the last packet is filled with blank parts, that is, invalid byte order. Then the receiver may have difficulty identifying this invalid part. It is just for filling in and has no actual meaning. This creates trouble for the receiving end to process its meaning. Of course, there are solutions, which can be compensated by adding flag bits, that is, adding a fixed-length header to the front of each data packet, and then sending the end mark of the data packet together. The receiver confirms the invalid byte sequence according to this mark, thereby achieving complete reception of the data.

2. When the length of sent packets is randomly distributed, bandwidth will be wasted. For example, the sending length may be 1,100, 1000, 4000 bytes, etc., and they all need to be sent according to the maximum fixed length, which is 4000. Other packets with data packets smaller than 4000 bytes will also be filled to 4000, causing ineffective waste of network load. .

To sum up, this solution has better effect when the length of the sent data packet is relatively stable (tends to a certain fixed value).

Related learning recommendations: PHP Programming from entry to proficiency

2. Design plan 2: Tail mark sequence

Set one at the end of each data packet to be sent A special byte sequence. This sequence has a special meaning. It has the same meaning as the end character "\0" of the string. It is used to mark the end of the data packet. The receiver can analyze the received data through the tail sequence. Confirm packet boundaries.

The flaws of this method are obvious:

1. The receiver needs to analyze the data and identify the tail sequence.

2. The determination of the tail sequence itself is a problem. What sequence can be used as a terminator like "\0"? This sequence must be a data sequence that does not have any meaning that is generally recognized by humans or programs, just like "\0" is an invalid string content and can therefore be used as the end mark of a string. So what is this sequence in ordinary network communication? I think it's hard to find the right answer for a while.

3. Design Plan 3: Step-by-step reception of header tags

This method is the best method based on the author’s limited knowledge. It does not lose efficiency and perfectly solves the boundary problem of packets of any size.

The implementation of this method is as follows: define a user header and indicate the size of the data packet sent each time in the header. Each time the receiver receives the data, it first reads the data according to the size of the header. This must only read the data of one header. It obtains the data size of the data packet from the header, and then reads it again according to this size. Read the content of the data.

In this way, each data packet is encapsulated with a header when it is sent, and then the receiver receives a packet in two times, the first time to receive the header, and the second time to receive the data content based on the size of the header. (The essence of data[0] here is a pointer, pointing to the text part of the data, or it can be the starting position of a continuous data area. Therefore, it can be designed as data[user_size], in this case.)

The following is a diagram to show the design idea.

It can be seen from the figure that the data is sent with the action of encapsulating the header; the receiver splits the reception of each packet into two times.

This solution seems to be exquisite, but in fact it also has flaws:

1. Although the header is small, each packet needs to encapsulate more sizeof(_data_head) data, and the cumulative effect cannot be completely ignored.

2. The receiving action of the receiver is divided into two times, that is, the data reading operation is doubled, and the recv or read of the data reading operation is a system call, which is harmful to the kernel. The overhead of the language is an impact that cannot be completely ignored, and the performance impact on the program is negligible (system calls are very fast).

Advantages: It avoids the complexity of program design, its effectiveness is easy to verify, and it is easier to meet the stability requirements of software design. To sum up, plan three is the best policy!

The above is the detailed content of How to solve the problem of sticky tcp packets?. For more information, please follow other related articles on the PHP Chinese website!