TCP flow control и backpressure

Overview

TCP flow control защищает receive buffer конкретного endpoint от переполнения. Receiver сообщает в Window field, сколько octets начиная с ACK number он готов принять. Sender хранит это значение как send window и не должен выпускать новые sequence numbers за разрешённую границу.

Если receiver application перестаёт вызывать recv(), уже подтверждённые, но ещё не потреблённые bytes занимают receive buffer. Advertised window уменьшается вплоть до zero. Sender TCP останавливает новые data bytes, его локальный send buffer заполняется, и backpressure становится видимым в Winsock API. Это не обязательно network loss и не то же самое, что congestion control: flow control отражает capacity receiver, congestion control — оценку capacity path.

Components

• application producer — источник bytes; без собственного rate limit способен накапливать неограниченный backlog вне socket.
• send() / WSASend() — boundary, где backpressure проявляется ожиданием, short result, WSAEWOULDBLOCK или asynchronous completion.
• sender send buffer — bounded local queue bytes, ещё не завершивших transport lifecycle.
• SND.WND — окно, объявленное remote receiver и ограничивающее новые sequence numbers sender.
• RCV.WND — текущая capacity receive side, которую endpoint сообщает в ACK segments.
• receiver receive buffer — accepted and acknowledged bytes, которые user process ещё не забрал.
• slow recv() consumer — application bottleneck; сеть может быть здорова, пока очередь растёт.

Scenarios

1. Receiver успевает читать. recv() освобождает buffer, positive window позволяет steady transfer.
2. Receiver перестал читать. RCV.WND падает до zero, sender TCP останавливается, а затем заполняется local send buffer.
3. Window снова открывается. После чтения receiver отправляет window update, и существующее connection продолжает data transfer.

Failure modes

• Путать zero receive window с packet loss и лечить его только retransmission или увеличением timeout.
• Путать flow control с congestion control; у механизмов разные сигналы и цели, хотя оба ограничивают sender.
• Продолжать создавать application work после WSAEWOULDBLOCK и переносить unbounded queue из ядра в heap процесса.
• Считать успешный send() доказательством того, что receiver application уже освободил receive buffer.
• Игнорировать readiness/completion notifications и делать tight retry loop, который расходует CPU без появления capacity.
• Увеличивать socket buffers без общего memory budget и admission control.

References

• RFC 9293, section 3.8.6: Managing the Window
• RFC 9293, section 3.8.6.1: Zero-Window Probing
• Microsoft Learn: send function
• Microsoft Learn: WSAEventSelect function
• Microsoft Learn: Overlapped I/O