Windows & Retransmits
tcpdump prints a line like win 501 on nearly every acknowledgment, and that one number is a live ceiling: send past it and the receiver has nowhere to put the bytes, so the sender waits.
- ▸A receiver with a full buffer advertises a ceiling of zero, and the sender waits rather than dies.
- ▸Three repeated acknowledgments for the same byte are enough to resend a lost segment, no timer required.
- ▸The window
tcpdumpprints can be off by a hundredfold, because the real value is shifted.
A sender with a megabyte to push does not get to push a megabyte. On every acknowledgment it receives, the receiver includes a number: how many more bytes of buffer space are free beyond the byte it just confirmed. That number is the receive window, and the sender treats it as a hard ceiling on its in-flight bytes, the data it has sent but not yet had acknowledged. Reach the ceiling and the sender stops, even with plenty left to send and the network wide open.
The ceiling moves. When the receiving application reads slowly, bytes pile up in the kernel buffer, free space drops, and the next acknowledgment quotes a smaller window. Drain the buffer and the window quoted grows again. ss -tan shows the same story from outside the connection: a climbing Recv-Q is the buffer filling, and the advertised window shrinks in step with it. The window is not a setting anyone dialed in; it is a live readout of one buffer's free space, recomputed and re-sent with every acknowledgment.