TCP byte stream: framing и partial I/O

Overview

TCP предоставляет приложению надёжный упорядоченный поток bytes. Он не сохраняет границы между вызовами send(), TCP segments и вызовами recv(). Поэтому application protocol обязан определить framing поверх stream.

В примере frame состоит из 4-byte unsigned length в network byte order и payload. «Привет» содержит 6 Unicode characters, но 12 bytes в UTF-8, поэтому весь frame занимает 16 bytes. Sender повторяет send() до передачи всех 16 bytes. Receiver накапливает произвольные positive chunks, сначала дожидается полного prefix, проверяет length, затем дожидается ровно указанного payload и продолжает parse loop для следующего frame.

Components

• frame A / frame B — единицы application protocol; их boundaries существуют только благодаря length prefix.
• send_all() loop — обрабатывает short send, сдвигая pointer и уменьшая remaining count.
• kernel send buffer — локально принятые TCP bytes; его содержимое ещё не доказывает чтение remote application.
• TCP segments — транспортные units с sequence numbers; они могут делить или объединять application writes.
• kernel receive buffer — ordered bytes после TCP reassembly.
• recv() loop — читает любое положительное число доступных bytes, обрабатывает zero как orderly shutdown, SOCKET_ERROR — через WSAGetLastError().
• application accumulator — сохраняет incomplete prefix или payload между вызовами recv().
• length-prefix parser — проверяет допустимый size до allocation и отдаёт handler только complete frames.

Scenarios

1. Short send. Первый send() принимает 7 из 16 bytes; loop корректно передаёт оставшиеся 9.
2. Один frame в нескольких recv(). Prefix и payload приходят chunks 2 + 5 + 9; parser ждёт полные 16 bytes.
3. Два frame в одном recv(). Один chunk содержит несколько frames; stateful parser извлекает оба по очереди.

Failure modes

• Полагаться на совпадение one send ↔ one segment ↔ one recv; TCP такого контракта не даёт.
• Игнорировать положительный short send и считать весь исходный buffer переданным.
• Терять incomplete prefix/payload между итерациями recv loop.
• Вызывать handler сразу после чтения prefix, не дождавшись полного payload.
• Доверять untrusted length и выделять память без maximum frame size, overflow checks и protocol timeout.
• Считать recv()==0 временным отсутствием данных: для connected stream это orderly shutdown peer send side.

References

• RFC 9293: Transmission Control Protocol
• Microsoft Learn: send function
• Microsoft Learn: recv function
• Microsoft Learn: Sending and Receiving Data on the Client
• Microsoft Learn: byte ordering