Сети и протоколы
TCP handshake: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту TCP handshake — цена RTT, рандомизация ISN, SYN cookie, congestion control, стопоры Nagle и исчерпание TIME-WAIT.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь в реальном инциденте — не флаг для называния, а компромисс, который надо взвесить, пока горит задержка или память.
Цель
Убедись, что связываешь цену RTT в handshake, безопасность ISN, защиту от флуда, congestion control и канонические production-патологии — тот синтез, к которому вели отдельные уроки.
Викторина
Completed
REST-клиент открывает новое TCP-соединение на каждый запрос к origin с RTT 140 мс, затем накладывает TLS 1.3. Почему каждый вызов медленный, хотя payload крошечный, и какой структурный фикс?
Heads-up Крошечный payload — не CPU-проблема. Задержка — это цепочка round-trip'ов (TCP handshake + TLS), оплачиваемая на каждое соединение, что и амортизирует keep-alive.
Heads-up Крошечный ответ помещается в стандартное IW=10 (~14.6 КБ) за первый RTT; slow start не узкое место. Цена — round-trip'ы handshake на каждое соединение.
Heads-up Nagle стопорит конвейерные мелкие записи в одном соединении, а не cold-start round-trip'ы открытия нового соединения на каждый запрос. Здесь фикс — переиспользование, а не TCP_NODELAY.
Викторина
Completed
Почему RFC 6528 вычисляет Initial Sequence Number как счётчик по времени плюс keyed-хэш 4-кортежа, а не начинает с нуля?
Heads-up Рандомизация ISN — не шифрование, TCP несёт открытый текст. Она лишь останавливает предсказание sequence number; конфиденциальность — задача TLS, слоя выше.
Heads-up Выбор ISN не имеет отношения к распределению по ядрам (это RSS/RPS на NIC). RFC 6528 — чисто защита от инъекции.
Heads-up Любому соединению всё равно нужны все три шага. ACK доказывает живость независимо от способа выбора ISN; рандомизация меняет значение, а не число шагов.
Викторина
Completed
Во время SYN-флуда твой публичный listener держится с tcp_syncookies=1, но легитимные клиенты на трансконтинентальном пути 200 мс жалуются, что пропускная способность застряла на ручейке. Почему?
Heads-up Cookie меняют CPU на память — они вообще не аллоцируют request_sock. Удар по пропускной способности — от потери Window Scaling/SACK/Timestamps в cookie, а не от давления памяти.
Heads-up SYN-флуд — это крошечные пакеты, переполняющие half-open очередь, а не bandwidth канала. Потолок пропускной способности на соединение — от отброшенной опции scaling в cookie-валидированных handshake.
Heads-up Cookie не меняют алгоритм congestion control. Они отбрасывают TCP-опции, несомые в SYN; ограничитель — потолок окна 64 КиБ.
Викторина
Completed
Сервис 4K-видео по cellular (RTT 150 мс, ~1% случайных потерь) видит, как пропускная способность CUBIC падает до доли ёмкости канала. Переход на BBR восстанавливает почти line-rate. В чём причина?
Heads-up Оба могут стартовать с IW=10. Устойчивая разница — loss-агностичная модель bandwidth/RTT у BBR против loss-триггерных срезов окна у CUBIC, а не разовое преимущество начального окна.
Heads-up BBR всё равно ретрансмитит потерянные данные — надёжность неизменна. Он просто не трактует потерю как сигнал congestion, поэтому не обваливает темп на случайных дропах.
Heads-up Congestion control не меняет MSS, а jumbo-фреймы не выживают на cellular-путях. Выигрыш — чисто разница в моделировании loss против congestion.
Викторина
Completed
Redis-клиент на том же хосте дата-центра показывает стабильный p99 ~40–200 мс на мелких конвейерных командах, без потерь и без давления CPU. Корневая причина?
Heads-up Установленное соединение прошло slow start, и крошечные команды не нагружают cwnd. Стопор — дедлок Nagle плюс delayed-ACK, лечится через TCP_NODELAY.
Heads-up TIME-WAIT влияет на открытие новых соединений (переиспользование портов), а не на задержку команд на уже установленном сокете. Квант 40 мс прямо указывает на delayed-ACK.
Heads-up Выбор ISN никак не влияет на задержку на команду. Цифра 40 мс — это таймер delayed-ACK во взаимодействии с Nagle.
Викторина
Completed
Load balancer возвращает EADDRNOTAVAIL на исходящий connect() к одному бэкенду; ss показывает ~30k сокетов TIME-WAIT к этому origin. Коллега предлагает понизить MSL, чтобы TIME-WAIT быстрее сливался. Как читать ситуацию правильно?
Heads-up TIME-WAIT существует, чтобы поглощать запоздалые ретрансмиты на том же 4-кортеже; его укорачивание приглашает повреждение устаревшим сегментом. Безопасные рычаги — tcp_tw_reuse плюс пулинг соединений.
Heads-up tcp_tw_recycle убрали в Linux 4.12, потому что он дропал легитимные SYN от клиентов за NAT. Никогда не включай его; используй tcp_tw_reuse.
Heads-up SYN cookie защищают входящую half-open SYN-очередь; они ничего не делают для исходящего исчерпания эфемерных портов в TIME-WAIT. Совсем не тот слой.
Итог
Сквозная линия юнита — одна цепочка решений: handshake стоит round-trip, который ты амортизируешь переиспользованием соединений, рандомизация ISN его защищает, SYN cookie обороняют его под флудом (ценой отброшенных опций), congestion control решает, как быстро он заполнит трубу (CUBIC реагирует на потерю, BBR моделирует bandwidth и RTT), а канонические production-сбои — стопоры Nagle плюс delayed-ACK, утечки CLOSE-WAIT, исчерпание TIME-WAIT — у каждого один верный рычаг и несколько правдоподобных неверных. Знать, какой рычаг и почему остальные провалятся, — и есть синтез.