9.2TCP и UDP

Разбери, какие гарантии TCP строит поверх IP: порядок байтов, повторную передачу, flow control и congestion control. Сопоставь их с UDP, закрытием соединения и keep-alive, чтобы понимать цену надёжного потока.

Что именно TCP добавляет поверх IP

IP обещает ровно одно: «постараюсь доставить пакет по адресу». Пакет может пропасть, продублироваться, прийти вторым из трёх, побиться. TCP превращает это в надёжный упорядоченный поток байт между двумя процессами и делает это пятью механизмами:

• Соединение - обе стороны согласуют начальное состояние (рукопожатие), а потом и завершение.
• Порядковые номера и подтверждения: нумеруется каждый байт, приёмник сообщает, до какого места он всё получил.
• Ретрансмиссии: всё, что не подтвердили, уходит заново.
• Управление потоком - чтобы не завалить приёмник.
• Управление перегрузкой - чтобы не завалить сеть между вами.

# Заголовок TCP, 20 байт без опций
src port (2)   dst port (2)
sequence number (4)          # номер первого байта в сегменте
acknowledgment number (4)    # следующий ожидаемый байт (кумулятивно)
data offset + flags (2)      # SYN ACK FIN RST PSH URG ECE CWR
window (2)                   # свободное место в буфере приёма, до 65535 без wscale
checksum (2)   urgent (2)
опции: MSS, window scale, SACK permitted, timestamps, TCP Fast Open

TCP передаёт поток байт, а не сообщения. Один Write на 10 КБ может приехать пятью Read, а три Write по 100 байт могут прийти одним. Границ сообщений в TCP нет, их задают сами: длиной префикса, разделителем или заголовком Content-Length. Это, кстати, самый частый практический вопрос по TCP на собесе.

Трёхстороннее рукопожатие

Порядковые номера, подтверждения, ретрансмиссии

Нумеруются байты, не пакеты. seq в сегменте несёт номер его первого байта, ack в обратном пакете - номер следующего ожидаемого байта. Подтверждение кумулятивное: ack=5000 означает «всё до 4999 включительно у меня есть», и это подтверждение перекрывает все предыдущие. Поэтому потеря одного ACK не фатальна: следующий всё закроет.

Потерю замечают двумя способами, и по смыслу они сильно разные:

• Таймаут RTO. Отправитель держит таймер; сработал - сегмент уходит заново. RTO не константа: ядро считает сглаженное SRTT и разброс RTTVAR по алгоритму Джекобсона, RTO = SRTT + 4 × RTTVAR, с нижней границей (в Linux 200 мс). Повторный таймаут удваивает RTO (экспоненциальный откат), а по алгоритму Карна замеры RTT по ретрансмиссиям не учитываются, иначе оценка поедет.
• Три дублирующих ACK → fast retransmit. Приёмник, получая сегменты «с дыркой», на каждый шлёт один и тот же ack (номер начала дырки). Три одинаковых ack подряд означают «один сегмент потерялся, остальные идут», и отправитель повторяет его сразу, не дожидаясь таймера.

SACK (RFC 2018) чинит главную слабость кумулятивного ACK: без него приёмник не может сказать «мне не хватает только байтов 5000–6460, а 6460–20000 уже есть». С SACK он перечисляет полученные диапазоны в опциях, и отправитель повторяет ровно дырки, а не всё начиная с потерянного места. Без SACK на канале с потерями и большим окном пропускная способность падает в разы. Договариваются о нём в рукопожатии (SACK permitted).

Управление потоком: окно получателя

Окном называют разрешение отправителю: сколько байт можно послать и не ждать, пока их подтвердят. Байты, которые уже ушли, но ещё не подтверждены, называют «в полёте». Набрал полное окно - стой и жди ACK; пришёл ACK - окно «скользит» вперёд, и можно слать дальше. Без окна отправитель либо ждал бы подтверждение после каждого сегмента (и упёрся бы в один сегмент за RTT), либо завалил бы получателя.

Окон на самом деле два, и действует меньшее из них: rwnd говорит, сколько готов принять получатель, cwnd - сколько отправитель считает безопасным для сети между вами. Этот раздел про первое, следующий про второе.

Приёмник в каждом ACK объявляет rwnd, свободное место в своём буфере приёма. Отправитель не имеет права держать «в полёте» больше этого объёма. Так защищается медленное приложение-получатель: если оно не вызывает Read, буфер ядра заполняется, rwnd падает, и в пределе объявляется нулевое окно: отправитель замолкает и периодически шлёт window probe, пока окно не откроется.

Отсюда формула: максимальная пропускная способность одного TCP-соединения ограничена window / RTT. При RTT 100 мс и окне 64 КБ это ~5 Мбит/с, сколько бы гигабит ни было в канале. Это и есть bandwidth-delay product, поэтому на длинных «толстых» линках включают window scaling и поднимают net.ipv4.tcp_rmem/tcp_wmem.

Управление перегрузкой

Окно получателя ничего не знает о том, что творится между хостами. Перегрузку сети TCP оценивает сам, по косвенным признакам (потери, а в современных алгоритмах ещё и рост задержки), и держит второе окно, cwnd. Реально в полёте может быть min(rwnd, cwnd) байт.

Классическую схему (Reno/NewReno) называют AIMD. CUBIC, дефолт в Linux с 2006 года, заменяет линейный рост кубической функцией от времени с последней потери: быстро возвращается к прежнему окну и осторожно щупает выше, и на «толстых» каналах с большим RTT это заметно быстрее. BBR от Google меняет саму модель: он не считает потерю сигналом перегрузки (на Wi-Fi и мобильных потери бывают от помех), а постоянно оценивает доступную полосу и минимальный RTT и держит ровно столько данных в полёте, сколько нужно, чтобы не наполнять буферы промежуточных роутеров. Так он лечит bufferbloat.

Закрытие соединения и TIME_WAIT

Закрытие четырёхстороннее, потому что TCP-соединение полнодуплексное: FIN говорит «я больше ничего не пришлю», но встречный поток остаётся живым. Это и есть half-close, в Go его делает conn.CloseWrite() на *net.TCPConn. Если приложение на пассивной стороне закрывает сокет сразу, ядро склеивает ACK и FIN, и пакетов получается три.

TIME_WAIT возникает только у того, кто закрыл первым. Это единственное состояние, которое живёт после того, как приложение уже забыло про сокет: ядро держит пятёрку занятой 2 × MSL (в Linux это константа 60 секунд, TCP_TIMEWAIT_LEN, меняется только пересборкой ядра).

Про RST помни отдельно: это не «закрытие», а «аварийный сброс». Он прилетает, когда пишут в закрытый сокет, когда порт никто не слушает, при SO_LINGER с нулевым таймаутом. При переполнении очереди приёма Linux по умолчанию RST не шлёт, а молча выбрасывает SYN; RST будет, только если включён tcp_abort_on_overflow. В Go это connection reset by peer. От FIN он отличается сильно: FIN закрывает упорядоченно, данные в буферах дойдут, а RST выбрасывает всё немедленно.

UDP: что остаётся, если убрать всё

Заголовок UDP весит 8 байт: порт источника, порт назначения, длина, контрольная сумма. Состояния нет, соединения нет, номеров нет, буквально «IP плюс порты плюс checksum». Отсюда всё остальное:

• Не гарантирует доставку: датаграмма может пропасть, и никто об этом не узнает.
• Не гарантирует порядок - вторая может обогнать первую.
• Не защищает от дублей: маршрутизация может размножить пакет.
• Нет управления перегрузкой - UDP-приложение может утопить канал, ответственность на нём.
• Сохраняет границы сообщений: один WriteTo = одна датаграмма = один ReadFrom. Это плюс, а не минус: не нужен фреймер.

Зачем он нужен, если такой «плохой»: когда опоздавшие данные бесполезны. В голосовом звонке повторять пакет, который опоздал на 300 мс, бессмысленно - лучше проиграть тишину и идти дальше. Когда запрос и ответ помещаются в одну датаграмму (DNS), рукопожатие ради одного вопроса даёт только накладные расходы. Когда нужен multicast/broadcast, которого в TCP нет вовсе. И когда надёжность хочется реализовать самому, по-своему, как сделал QUIC.

Keep-alive: TCP и HTTP - это разные вещи

// TCP keep-alive: ядро само пингует пира. Дефолт ОС в 2 часа почти всегда бесполезен.
d := &net.Dialer{
    Timeout: 3 * time.Second,
    KeepAliveConfig: net.KeepAliveConfig{ // Go 1.23+: раньше был только KeepAlive time.Duration
        Enable:   true,
        Idle:     30 * time.Second, // начать пробы после 30 с тишины
        Interval: 10 * time.Second, // интервал между пробами
        Count:    3,                // после 3 неудач соединение мертво
    },
}

// HTTP keep-alive: транспорт переиспользует соединения из пула.
tr := &http.Transport{
    DialContext:         d.DialContext,
    MaxIdleConns:        200,
    MaxIdleConnsPerHost: 100, // дефолт всего 2, главная причина всплеска TIME_WAIT
    IdleConnTimeout:     90 * time.Second,
}
client := &http.Client{Transport: tr, Timeout: 5 * time.Second}

Head-of-line blocking

«Блокировка головой очереди» случается, когда первый элемент очереди тормозит всех, кто за ним, хотя они уже готовы. В сетях она встречается на двух разных уровнях, и на собесе их надо разделить.

• HOL на уровне HTTP/1.1. В одном соединении запросы обрабатываются строго по очереди: следующий ответ нельзя начать, пока не дописан предыдущий. Обходили это открытием 6 параллельных соединений на домен и доменным шардингом. Конвейеризация должна была помочь, но ответы всё равно обязаны идти в порядке запросов, поэтому один медленный ответ блокировал остальные - её отключили во всех браузерах.
• HOL на уровне TCP. Живёт ниже и не лечится прикладным протоколом. TCP обязан отдать приложению байты по порядку: если потерялся сегмент, все пришедшие после него сегменты лежат в буфере приёма и не отдаются наверх, пока потерянный не будет ретранслирован. Это стоит минимум одного RTT.

Дальше цепочка, которая и есть «правильный» ответ. HTTP/2 мультиплексирует потоки внутри одного TCP-соединения и убирает HOL уровня HTTP - но, положив все потоки в один TCP, делает TCP-HOL больнее: потеря одного пакета останавливает все логические потоки сразу (в HTTP/1.1 встали бы только запросы одного из шести соединений). QUIC закрывает вопрос: он поверх UDP и ведёт порядок и ретрансмиссии отдельно для каждого потока, поэтому потеря пакета тормозит только тот поток, чьи байты потерялись.

// SO_REUSEADDR Go ставит на слушающий сокет сам; SO_REUSEPORT - через Control
lc := net.ListenConfig{
    Control: func(network, address string, c syscall.RawConn) error {
        var opErr error
        err := c.Control(func(fd uintptr) {
            opErr = unix.SetsockoptInt(int(fd), unix.SOL_SOCKET, unix.SO_REUSEPORT, 1)
        })
        if err != nil { return err }
        return opErr
    },
}
ln, err := lc.Listen(context.Background(), "tcp", ":8080")

conn, _ := net.ListenPacket("udp", ":9000")
buf := make([]byte, 65535)               // берём с запасом: короткий буфер отрежет хвост
for {
    n, addr, err := conn.ReadFrom(buf)   // ровно одна датаграмма за вызов
    if err != nil {
        if errors.Is(err, net.ErrClosed) { return }
        continue                         // прочие ошибки чтения на UDP обычно не фатальны
    }
    go handle(conn, addr, append([]byte(nil), buf[:n]...)) // копия: buf перезапишет следующий ReadFrom
}

// сервер: свои таймауты и время жизни простаивающего соединения
srv := &http.Server{
    ReadHeaderTimeout: 5 * time.Second,
    ReadTimeout:       15 * time.Second,
    WriteTimeout:      30 * time.Second,
    IdleTimeout:       120 * time.Second, // сколько держим keep-alive без запросов
}
// srv.SetKeepAlivesEnabled(false) выключает HTTP keep-alive, например перед graceful shutdown

Что стоит запомнить

• TCP даёт приложению упорядоченный поток байтов и скрывает потери через retransmission; границы сообщений нужно задавать протоколом приложения.
• Receive window ограничивает отправителя по ёмкости получателя, congestion control - по состоянию сети.
• TCP keep-alive проверяет простаивающее соединение на уровне ОС; HTTP keep-alive переиспользует соединение для запросов.

Частые ошибки

• Не трактуй успешный Write как подтверждение, что удалённое приложение обработало данные.
• Не забывай, что потеря одного сегмента может задержать последующие байты TCP потока (head-of-line blocking).
• UDP не становится ненадёжным для каждой задачи: он оставляет приложению контроль над потерями, порядком и повторами.

KeepAliveConfig: net.KeepAliveConfig{
    Enable: true,
    Idle: 30 * time.Second,
    Interval: 10 * time.Second,
    Count: 3,
}

buf := make([]byte, 512)
for {
    n, addr, err := conn.ReadFrom(buf)
    if err != nil { continue }
    go handle(buf[:n], addr)
}