BBR, производственная наблюдаемость и за пределами TCP

Сервис потоковой передачи видео раздаёт 4K-сегменты по межконтинентальным мобильным путям (RTT 150 мс, 1% случайных потерь). Пропускная способность CUBIC рушится до доли от реальной ёмкости канала. Переключение на BBR удерживает throughput близко к максимуму на том же пути. Разница не в пропускной способности — в разных ответах на вопрос «что означает потерянный пакет?»

BBR против CUBIC против Reno

Reno (классический): делить cwnd пополам при потерях, аддитивное увеличение за RTT. Простой, широко реализован.

CUBIC (дефолт Linux с 2.6.19): функция роста в форме кубической кривой — вогнутый зонд ниже предыдущего максимума, выпуклый зонд выше него. Уменьшает ~0,7× при потерях. Восстанавливает пропускную способность на путях с высоким BDP быстрее, чем Reno.

BBR (Bottleneck Bandwidth and RTT): полностью отказывается от сигнализации на основе потерь. Напрямую оценивает пропускную способность узкого места пути (через скорость доставленных байт) и минимальный RTT (через метки времени пакетов), затем устанавливает темп отправки в соответствии с ними. Потери трактуются как неоднозначный шум — могут быть перегрузкой или случайными сбросами. На 1% случайных потерь BBR удерживает пропускную способность близко к максимуму; CUBIC оседает на доле от этого значения.

BBRv3 (релиз Google 2023 г.): исправляет баги преждевременного зонда и конвергенции в BBRv2. Развёрнут на google.com, YouTube, Cloudflare и Netflix. По состоянию на начало 2025 г. не влит в mainline Linux; требует кастомного ядра или сторонского бэкпорта. Mainline Linux 6.x поставляется с BBR 1.x.

Практические рекомендации: используйте CUBIC для серверов общего назначения на стандартных ядрах, стандартных датацентровых и региональных ISP путях, где потери редки и означают перегрузку. Переходите на BBR для трансконтинентального WAN, мобильных или спутниковых путей, где 0,5–2% случайных потерь — норма и снижение CUBIC рушит throughput.

Установка для сокета: setsockopt(SOL_TCP, TCP_CONGESTION, "bbr"). Для всей системы: net.ipv4.tcp_congestion_control=bbr.

Производственная наблюдаемость

ss -tin выводит живые значения cwnd, RTT, дисперсию RTT, повторные передачи и состояние откатного таймера на соединение — без накладных расходов на ядро. Запускайте на любом производственном хосте.

$ ss -tin state established | grep -A1 "dport 443"
# Вывод включает: cwnd:10 ssthresh:2147483647 rtt:42.8/8.5 acked:142 retrans:0/0

Ключевые поля:

• cwnd: текущее окно перегрузки в MSS
• rtt/rttvar: сглаженный RTT и дисперсия в миллисекундах
• retrans:sent/outstanding: суммарные повторные передачи
• ssthresh: порог медленного старта (2147483647 = бесконечность = в медленном старте)

ss -s суммирует количество сокетов по состоянию — следите за скачками CLOSE-WAIT.

nstat раскрывает счётчики из /proc/net/netstat: RetransSegs, TCPSlowStartRetrans, TCPDSACKRecv. Для долгосрочного мониторинга tcp_diag питает Prometheus-экспортёры (node_exporter раскрывает большинство метрик); SLO-важные метрики — скорость повторных передач, RTT p95/p99 и соотношение CLOSE-WAIT:ESTABLISHED.

$ ss -tan state established | wc -l
12384
$ ss -tan state close-wait | wc -l
9821
$ ss -tan state time-wait | wc -l
1247
$ ss -s
Total: 12500
TCP:   23552 (estab 12384, closed 8920, orphaned 2, timewait 1247)
$ ps -p 1234 -o pid,stat,rss,vsz,cmd
PID STAT  RSS    VSZ CMD
1234 Ssl 8392000 12000000 /usr/bin/app-server

Семантика RST

RST в TCP — это резкое закрытие соединения: без обмена FIN, без TIME-WAIT, получатель немедленно удаляет состояние соединения. Возникает когда:

• Пакет приходит на порт, который никто не слушает.
• Приложение вызывает close() на сокете с непрочитанными данными и SO_LINGER с lingertime=0.
• Сосед отправляет мусор, нарушающий конечный автомат.
• Stateful файрвол решает, что соединение простаивает.

RST-атаки: злоумышленник, способный угадать порядковые номера в пределах окна приёма, может подделать RST и разорвать установленное соединение. RFC 5961 ужесточает допустимое окно RST. Долгоживущие простаивающие соединения (BGP-сессии, SSH) наиболее уязвимы.

MPTCP (RFC 8684)

Multipath TCP переносит одно логическое соединение по нескольким путям (Wi-Fi + мобильная сеть, сервер с несколькими NIC). Рукопожатие MPTCP добавляет опцию MP_CAPABLE в SYN/SYN-ACK/ACK; если оба конца поддерживают её, устанавливается первый подпоток, а дополнительные подпотоки открываются на разных интерфейсах через MP_JOIN. iOS использует MPTCP с iOS 7 для Siri. Linux 5.6+ поставляется с RFC 8684. Ограниченное распространение за пределами Apple из-за middlebox-устройств, не понимающих опцию и откатывающихся к обычному TCP.

kTLS + TCP

kTLS (Linux 4.13+ TX, 4.17+ RX, NIC offload в 6.0+) переносит симметричное шифрование TLS-записей в ядро через setsockopt(SOL_TLS, ...). После завершения TLS-рукопожатия в пространстве пользователя ядро берёт на себя шифрование записей; в сочетании с sendfile() файлы перемещаются из page-cache в NIC, не попадая в пространство пользователя. Netflix сообщает об экономии 8–29% CPU при доставке статических ресурсов. kTLS не меняет поведение TCP — управление перегрузкой, повторные передачи, управление окном остаются стандартными.

Связь TCP с QUIC

TCP — один уровень в стеке; TLS находится непосредственно поверх него; HTTP/1.1 и HTTP/2 работают на TLS. HTTP/3 — исключение: он работает на QUIC, который использует UDP и заново изобретает надёжность и управление перегрузкой в пространстве пользователя. Причина: эволюция TCP в пространстве ядра оказалась слишком медленной. Уроки TCP — порядковые номера, ACK, управление перегрузкой, медленный старт, быстрая повторная передача — все воспроизводятся в QUIC, только на другом уровне. Понимание TCP делает QUIC механистически прозрачным; обратное неверно.