Summary

  • TCP's PUSH function asks the transport not to keep waiting indefinitely for more application bytes before forwarding and delivering the data already supplied.
  • PSH is not a record marker: a SEND buffer, a TCP segment, a receive buffer and an application message need not share boundaries.
  • RFC 9293 allows implementations not to expose PUSH to applications, but still forbids indefinite buffering and requires PSH on the last queued segment when the sender has no more data buffered.
  • Applications that need message framing must provide it above TCP; a packet capture cannot recover authoritative record boundaries from PSH alone.

From letters to a stream

RFC 793 arrived after earlier TCP specifications had experimented with a “letter” idea. Its preface says that the letter mechanism had been redescribed as a push function. The distinction matters. A letter suggests a unit whose edge survives delivery. PUSH instead became a request about progress through buffers.

The specification describes TCP data as a continuous stream of octets. A sending implementation may collect application data and package it into segments at its convenience. When the user invokes PUSH, TCP is asked to transmit the queued data and carry it through to the receiver promptly. That request changes how long the stack may wait; it does not change the data model from stream to records.

Four boundaries that need not agree

Consider one application SEND containing a complete command. If PUSH is available and selected, RFC 9293 says PSH is placed on the last TCP segment created from that buffer. The qualifying words are the mechanism: TCP may split the buffer across segments, combine it with other data, or collapse successive push indications while packetizing.

At the far endpoint, a receive buffer can fill before PSH arrives, so data may be returned to the application without a PUSH indication. If PSH arrives before the buffer fills, an interface that exposes the indication can return a partially filled buffer. The application can also issue reads of sizes unrelated to any sender write.

The write boundary, segment boundary, receive-buffer boundary and application-message boundary are therefore separate facts. TCP guarantees the ordered byte stream, not their alignment.

What the bit actually asks for

The historical purpose of PUSH was to avoid a deadlock in which an application needed the submitted bytes delivered but the sending or receiving side kept waiting for more data. RFC 793 required the receiving TCP not to wait for additional bytes after seeing PUSH before passing available data upward.

RFC 9293 preserves the function while making the API boundary explicit. A TCP endpoint may let an application set PUSH on SEND. If that option is absent, the sender still must not buffer data indefinitely, and it must set PSH on the last buffered segment when no more queued data remains. On receipt, exposing the PUSH indication to the application is optional.

PSH therefore cannot be read as a universal application command. It is a transport signal whose exact visibility depends on the interface, while its core purpose remains progress rather than framing.

Prompt does not mean unconstrained

PUSH is also not a promise that bytes bypass every other transmission rule. Flow control still limits how much the peer can accept. Congestion control still governs sending into the network. RFC 9293 notes that Nagle's algorithm may buffer data without regard to PUSH, and recommends creating maximum-sized segments when possible.

The safe claim is narrower: PUSH expresses that the application does not want TCP to wait merely for later SEND calls before moving the available data. It does not guarantee a particular packet count, delivery instant or read completion.

Framing remains above TCP

An application protocol that needs messages must define them itself. It can prefix a length, use delimiters, carry a fixed-size structure or adopt another framing rule. The receiver then parses the ordered stream according to that rule, regardless of how TCP divided the bytes in flight.

This boundary also disciplines packet analysis. A PSH-bearing segment is evidence that a push indication was placed at that point in one packetization. It is not proof that the sender issued exactly one write, that the receiver returned exactly one read, or that an application record ended there.

Sources