SYN cookie, TFO и TIME-WAIT при высокой нагрузке

Нагруженный балансировщик начинает возвращать EADDRNOTAVAIL на исходящих соединениях к бэкенду. Команда ss -tan показывает 30 000 сокетов в состоянии TIME-WAIT. Одновременно публичный слушатель атакуется SYN flood. Оба явления решаются через sysctl Linux — но неправильный sysctl ухудшает ситуацию.

Внутреннее устройство SYN cookie

При SYN flood очередь полуоткрытых соединений на сервере переполняется. Вместо выделения request_sock для каждого SYN ядро использует путь в net/ipv4/tcp_ipv4.c:cookie_v4_init_sequence:

ISN_в_SYN-ACK = MAC от (saddr, sport, daddr, dport, isn, secret)

Старшие 5 бит кодируют индекс MSS (8 вариантов), следующие 6 бит — счётчик минут (окно повтора), нижние 21 бит — HMAC. Соединение тут же забывается. Когда приходит ACK, cookie_v4_check пересчитывает и проверяет. Если проверка прошла — ядро выделяет полный сокет. Если нет — ACK молча отбрасывается.

Компромисс: CPU вместо памяти — хорошо для больших серверов, не для маленьких. Цена: в cookie выживает только MSS. Масштаб окна, SACK и метки времени, предложенные в исходном SYN, молча отбрасываются для соединений, прошедших проверку через cookie. На высококачественном пути с большим RTT во время flood пропускная способность легитимных клиентов деградирует — окно ограничено 64 КиБ без масштабирования.

Linux включает SYN cookie, когда очередь полуоткрытых соединений превышает tcp_max_syn_backlog (зависит от системы, обычно 4096). Включается через net.ipv4.tcp_syncookies=1 (по умолчанию с ядра 2.4). Значение 2 форсирует безусловную генерацию cookie для тестирования.

$ sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0' -tnn
14:23:45.123456 IP 203.0.113.50.34521 > 198.51.100.10.443: Flags [S], seq 1000000, win 29200, length 0
14:23:45.123489 IP 198.51.100.10.443 > 203.0.113.50.34521: Flags [S.], seq 3851629874, ack 1000001, win 28960, length 0
14:23:45.124000 IP 203.0.113.50.34522 > 198.51.100.10.443: Flags [S], seq 2000000, win 29200, length 0
14:23:45.124050 IP 198.51.100.10.443 > 203.0.113.50.34522: Flags [S.], seq 4025814937, ack 2000001, win 28960, length 0
14:23:45.125000 IP 203.0.113.50.34521 > 198.51.100.10.443: Flags [.], seq 1000001, ack 3851629875, win 29200, length 0
14:23:45.125010 IP 203.0.113.50.34522 > 198.51.100.10.443: Flags [.], seq 2000001, ack 4025814938, win 29200, length 0
14:23:45.200000 IP 203.0.113.100.55000 > 198.51.100.10.443: Flags [S], seq 5000000, win 29200, length 0
14:23:45.200050 IP 198.51.100.10.443 > 203.0.113.100.55000: Flags [S.], seq 2941837465, ack 5000001, win 28960, length 0
(ACK от 203.0.113.100 не пришёл; SYN flood с разных поддельных адресов)

TCP Fast Open (TFO, RFC 7413)

Стандартное рукопожатие стоит 1 RTT до данных приложения. TFO устраняет это для последующих соединений:

1. Первое соединение: сервер отправляет опцию Fast Open Cookie в SYN-ACK; клиент кэширует её для пары (IP-сервера, порт-сервера).
2. Последующие соединения: клиент помещает cookie в SYN вместе с данными приложения размером до MSS; сервер проверяет и обрабатывает данные, пока завершает рукопожатие — экономя 1 RTT.

На RTT 280 мс (Лондон → Сидней) TFO экономит 280 мс на каждом тёплом соединении.

Реальность развёртывания: проблемы с промежуточными устройствами убили широкое серверное распространение TFO. Middlebox-устройства (файрволы, DPI, некоторые NAT-шлюзы) вырезают опцию TFO из SYN, ломая доставку cookie. Некоторые NAT-шлюзы ломают cookie при смене внешнего IP клиента. Откат обязателен, но добавляет задержку. Серверное развёртывание ограничено; большинство интереса к 0-RTT сместилось к QUIC, который работает поверх UDP и обходит протокольное окостенение сетевой инфраструктуры. Linux поддерживает обе стороны с ядра 3.6 (2012) через битовую маску net.ipv4.tcp_fastopen (1=клиент, 2=сервер, 3=оба).