Why Does TCP Have Sticky and Half Packets? Causes and Effective Solutions

Why TCP Can Produce Sticky and Half Packets

TCP is a stream‑oriented protocol; it does not preserve message boundaries. When data is written to a socket, the kernel may combine several writes into a single segment or split a large write into multiple segments. Consequently the receiver may obtain more or fewer bytes than a logical application message, leading to “sticky packets” (multiple messages merged) or “half packets” (a message received partially).

Sender writes data larger than the socket send buffer – the kernel fragments it.

Receiver reads fewer bytes than were sent, leaving remaining bytes in the receive buffer for the next read.

Application data exceeds the network MTU, causing IP fragmentation.

TCP may deliver data in any grouping: one send may be received multiple times or several sends may be coalesced into a single receive.

Because TCP provides a continuous byte stream, the application must define its own message boundaries.

Common Strategies to Delimit Messages

1. Use a Separate Short‑Lived Connection per Request

Open a new TCP connection for each logical request and close it after the response is sent. This guarantees that the bytes on the wire belong to a single message, but the overhead of TCP handshake and teardown makes it inefficient for high‑frequency traffic.

2. Frame the Data Within a Persistent Connection

Encapsulate each logical message into a frame that carries enough information for the receiver to determine where the message ends.

2.1 Fixed‑Length Frames

All frames have the same byte length. The decoder can simply read a fixed number of bytes for each message. In Netty this is implemented by FixedLengthFrameDecoder. This approach is trivial to code but wastes space when the actual payload is shorter than the fixed size.

2.2 Delimiter‑Based Frames

Append a special delimiter (e.g., \n or a custom byte sequence) after each payload. The receiver scans the incoming stream for the delimiter and extracts the bytes before it. Netty provides DelimiterBasedFrameDecoder. No extra padding is needed, but the delimiter must be escaped or avoided inside the payload, which requires additional processing.

2.3 Length‑Field Frames

Prepend a length field that specifies the size of the following payload. A typical format is: [Length][Payload] The length field can be 1, 2, 4, or 8 bytes depending on the maximum expected message size. Netty offers LengthFieldBasedFrameDecoder for decoding and LengthFieldPrepender for encoding. This method allows the receiver to read exactly the number of bytes indicated by the length field, avoiding delimiter‑escaping and minimizing wasted space. The only caveat is that the maximum payload size must be known in advance to choose an appropriate field width.

Among the three framing techniques, length‑field framing provides the best trade‑off between efficiency, simplicity, and robustness, and is therefore the most widely recommended solution.