the receive window

Think of a mailbox with limited room. You can tell the postman 'I have space for ten more letters' — and a courteous postman won't stuff in an eleventh until you've emptied some. The receive window is that 'how much room I have left' message. It is the value a TCP receiver advertises to tell the sender how many more bytes it is currently prepared to accept.

Mechanically, the receiver maintains a buffer for arriving data that its application hasn't consumed yet. The receive window equals the free space in that buffer right now: total buffer size minus the bytes already received and waiting to be read. The receiver writes this number into the window field of the TCP header on segments it sends back (often piggybacked on ACKs). The sender uses it as a hard cap: the amount of unacknowledged data it has in flight must not exceed the latest advertised receive window. As the application drains the buffer, the window grows; if the application stops reading, the window shrinks, possibly to zero, which tells the sender to pause.

Why it matters: the receive window is the concrete control signal of TCP flow control — it's literally how a slow receiver throttles a fast sender. Two practical notes. The 16-bit window field tops out at 65,535 bytes, which is far too small for today's fast, long-distance links; a window scaling option negotiated at connection setup multiplies it so windows can reach megabytes (otherwise throughput would be capped by the bandwidth-delay product). And the receive window is only one of two limits on the sender — the other is the congestion window — and the sender always respects the smaller of the two.