A TCP socket can hold a small write instead of transmitting it immediately when earlier data remains unacknowledged. This behavior comes from Nagle coalescing: it limits the stream of small TCP segments by allowing outstanding data to influence transmission of newly queued bytes.
On Linux, setting TCP_NODELAY disables that coalescing rule for the socket. Small writes become eligible for prompt transmission, subject to the rest of the TCP stack, congestion control, flow control, queue state, and device scheduling.
The option changes a sender-side batching decision. It does not turn TCP into a message protocol, remove buffering, force one packet per write(), or provide a fixed latency bound.
Nagle coalescing reacts to outstanding data
TCP exposes an ordered byte stream. Application write boundaries do not define segment boundaries on the wire.
Without TCP_NODELAY, the sender can coalesce small amounts of queued data while previously transmitted data is still unacknowledged. The intent is to avoid producing a sustained sequence of tiny segments when an application emits small writes faster than acknowledgments return.
This behavior is state-dependent. A small write made with no relevant outstanding data may be transmitted promptly. A similar write made while data is awaiting acknowledgment can remain queued until an acknowledgment arrives or enough data accumulates for a larger segment.
The resulting delay is therefore not a generic sleep inserted after every small write. It follows TCP state and the amount of data already in flight.
TCP_NODELAY removes that coalescing condition
Linux exposes TCP_NODELAY through the TCP socket option level:
int enabled = 1;
if (setsockopt(fd, IPPROTO_TCP, TCP_NODELAY,
&enabled, sizeof(enabled)) == -1) {
return -1;
}Once enabled, the socket no longer applies Nagle’s rule to defer small queued data solely because earlier data remains unacknowledged.
That distinction matters for request-response protocols that produce short dependent writes. If a later write cannot be generated until the peer reacts to an earlier one, sender-side coalescing can become visible as application latency. Removing that condition can reduce the interval between the application enqueueing bytes and TCP making them eligible for transmission.
The option is per socket. It is not a host-wide mode and does not alter unrelated TCP connections.
A write call still has no packet identity
TCP_NODELAY is sometimes described too strongly as making every write() send immediately. TCP does not preserve such a mapping.
Several mechanisms can separate application calls from observed packets:
- multiple writes can be combined before packet construction;
- one large write can be split across multiple segments;
- segmentation offload can hand a larger buffer to a network device for later segmentation;
- congestion control can prevent immediate transmission;
- receiver flow control can limit sending;
- queueing in the kernel or network device can add delay.
For the same reason, a packet capture is not a direct record of application write calls. Offload placement and capture location can also affect the segment shapes visible to tracing tools.
TCP_NODELAY removes one specific sender-side reason for holding small data. It does not bypass the rest of the transmission pipeline.
Delayed acknowledgments are a separate mechanism
Receiver acknowledgment policy is distinct from Nagle coalescing. A receiver may delay an acknowledgment briefly in anticipation of data to send in the reverse direction or another segment to acknowledge.
When a sender uses Nagle coalescing and the receiver uses delayed acknowledgments, certain small request-response patterns can expose the interaction between the two policies. The sender may be waiting for an acknowledgment before releasing a small queued write while the receiver is waiting briefly before generating that acknowledgment.
TCP_NODELAY breaks the sender side of that interaction by removing Nagle-based deferral. It does not disable delayed acknowledgment behavior at the peer.
This separation is important when attributing latency. A connection can have TCP_NODELAY enabled and still encounter delay from acknowledgment policy, scheduling, congestion, receiver processing, or application behavior.
Small writes can increase packet overhead
Disabling coalescing can trade batching efficiency for lower sender-side delay. Applications that emit many tiny writes can cause more small segments to become eligible for transmission.
Each additional segment carries protocol headers and consumes processing across the sender, receiver, and network. The cost can include packet-rate pressure, interrupt or polling work, queue operations, and reduced payload efficiency.
The effect depends on traffic shape. A service that writes complete multi-kilobyte responses gains little from disabling a rule that mainly affects small writes with outstanding data. A latency-sensitive protocol that emits short dependent records can have a materially different profile.
This is a workload boundary rather than a universal socket setting.
TCP_CORK applies a different batching policy
Linux also provides TCP_CORK, which is aimed at holding partial frames so the sender can assemble fuller segments. It represents a stronger batching intent than leaving Nagle coalescing enabled.
The two options address opposite pressures: TCP_NODELAY removes Nagle-based waiting for small queued data, while TCP_CORK can deliberately retain partial output for batching.
Linux permits both options to be set, but treating them as interchangeable obscures their roles. Code that manages either option benefits from making the intended transmission policy explicit at the point where application output changes phase.
The option changes eligibility, not delivery semantics
Enabling TCP_NODELAY does not alter TCP’s reliable ordered byte-stream contract. It does not create record boundaries, add delivery acknowledgments at the application layer, or make a successful write() mean that the peer has received the bytes.
A successful write normally reports that data was accepted into the local socket’s send path. Transmission and peer receipt occur later under TCP’s normal mechanisms.
The precise boundary is narrow: TCP_NODELAY disables Nagle coalescing on that socket. Latency effects follow from removing that one condition from a larger transport pipeline.