The reason TCP stick package / unpacking and solutions

In the usual client socket development, if the client continuously send data packets to the server, the server receives the data packet will be the case of two stick together, which is stuck in the TCP protocol commonly encountered problems package and unpacking.

We all know that TCP is the transport layer protocol, in addition to the transport layer TCP protocol but also have the UDP protocol. So whether UDP stick package or unpacking phenomenon will happen then? The answer is no. UDP packets are sent on, it can be seen from the frame structure of the UDP, the UDP header to indicate the use of the 16bit length of the UDP data packets, and therefore can well separate different areas of the data packet at the application layer, thereby stick package to avoid problems and unpacking. TCP is a byte-oriented and, although the data exchange between the application layer and the TCP transport layer is a data block sizes, but these data blocks TCP only as a series of unstructured byte stream, no border; Further a frame structure can also be seen from the TCP in the TCP header length field is not data indicating, based on the above points, when data transfer using TCP, it may have a stick package or unpacking phenomenon occurs.

Stick package, unpacking forms

Now assume that the client to the server continuously transmits two data packets, and with packet1 represented packet2, the server receives the data may be divided into three, we are listed below:

The first case, the receiving terminal normally receives two packets, i.e., stick package and unpacking phenomenon does not occur, such conditions are not within the scope of this discussion.
Here Insert Picture Description
The second case, the receiving terminal receives only one packet, since TCP packet loss will not occur, so that a packet contains two packets of information sent by a transmitter, a phenomenon that is stick package . Since this case the receiver does not know the limits of the two data packets, it is difficult for the receiving end is processed.
Here Insert Picture Description
The third case, this case has two forms, as shown below. The receiver receives two packets, but both packets is either incomplete, or is out of a plurality, i.e. this situation occurs and stick package unpacking. If both cases without special treatment, is also bad for the receiving side processing.
Here Insert Picture Description
Stick package, unpacking reasons occur

TCP stick package or unpacking occur for many reasons, now lists common points, may be incomplete, please add,

1, data to be transmitted is greater than the size of the TCP send buffer space remaining, unpacking will occur.

2, data to be transmitted is larger than the MSS (maximum packet size), TCP will be unpacked before transmission.

3, the data to be transmitted is less than the size of the TCP send buffer, the TCP data buffer multiple writes once sent out will occur stick package.

4, the data receiving side application layer did not read the received data buffer, stick package will occur.

and many more.

Stick package, unpacking solutions

Through the above analysis, we know the cause of stick package or unpacking happen, then how to solve this problem? The key problem is how to add boundary information for each data packet, commonly used method has the following:

1, the transmitting end to each packet to add pack header, the header should contain at least a length of the packet, so that the receiving terminal after receiving the data by reading the packet length field of the header, they know the actual length of each data packet a.

2, the sending end of each fixed length data packet is encapsulated (not 0 may be filled up by), this end of the fixed-length data read from the receive buffer to each receive each data packet naturally split open Come.

3, may be provided at a boundary between the data packet, such as adding special symbols, so that the receiving end this boundary can be a different data packet split open.

and many more.

Published 21 original articles · won praise 10 · views 8100

Guess you like

Origin blog.csdn.net/weixin_44997483/article/details/102574934