The Nagle Algorithm

RFC 896 · one sentence that tamed the tinygram flood

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

▸See a keystroke leave instantly when the connection is idle
▸Watch later keystrokes queue — and learn exactly what releases them
▸Verify Nagle has no timer: the network's own ACK is the clock
▸Judge when an application should disable it (TCP_NODELAY)

Before this lesson — it builds directly on:

Interactive programs write tiny amounts constantly — one keystroke at a time in a remote shell. If TCP sent each one immediately, every single character would travel in its own packet: 1 byte of data wrapped in 40 bytes of headers. In 1984 that traffic pattern was congesting real networks, so John Nagle proposed one rule: if you already have unacknowledged data outstanding, hold small writes in the buffer until that acknowledgement comes back, then send everything you've accumulated as one segment. It sounds like it would add delay, and it does — but the delay is bounded by exactly one round trip, and the packet count collapses.

✗ Common misunderstanding: If I send() twice, the other side will recv() twice with the same boundaries.

Why that's wrong: TCP is a byte stream with no message boundaries. Two writes may arrive coalesced in one segment, and one write may be split across several.

Correct model: TCP guarantees the ORDER and completeness of bytes, never their grouping. Applications must frame their own messages (length prefixes, delimiters).

The packets prove it: In the Nagle lesson three separate keystrokes arrive inside ONE segment — the receiver cannot tell where the writes were.

Watch these fields in the lab: tcp.flags.psh

A remote shell session where you type 8 characters. Compare sending each immediately with letting Nagle batch them, on a 40 ms round trip.

  without Nagle — one segment per keystroke:
     8 packets  ×  (1 B data + 40 B headers)  =   328 B on the wire
     useful payload:  8 B  →  overhead 97.6 %

  with Nagle — first keystroke goes immediately, the rest batch per RTT:
     packet 1:  1 B   (nothing outstanding, so send at once)
     packet 2:  3 B   (three keystrokes arrived during the 40 ms wait)
     packet 3:  3 B
     packet 4:  1 B
     4 packets  =  164 B on the wire, same 8 B delivered

  added latency for the batched characters:  at most one RTT

Notice that nothing chose the batch size of three — the round-trip time did. That is the whole design: the algorithm has no tuning knob because the network sets the pace. And the first keystroke always goes out immediately, which is why an idle interactive session still feels responsive.

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

Nagle's rule has no timer and no configurable batch size. What determines how much data ends up in each segment?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.