Глава про TCP важна тем, что показывает цену надёжной доставки: соединение, порядок байтов, контроль потока и перегрузки всегда оплачиваются задержкой, памятью и состоянием.
На практике это помогает проектировать повторные попытки, повторное использование соединений, стриминг и обратное давление с пониманием того, как транспортный слой меняет задержку и пропускную способность приложения.
В интервью и архитектурных обсуждениях материал полезен тем, что позволяет объяснять выбор транспорта и поведение системы под нагрузкой через реальные механизмы TCP, а не через общие слова о надёжности.
Практическая польза главы
Надежная доставка
Помогает понимать цену подтверждений, повторных передач и сохранения порядка для задержки и устойчивости сервиса.
Поведение при перегрузке
Учит учитывать управление перегрузкой при проектировании потоков данных и политик повторных попыток.
Жизненный цикл соединения
Показывает, как рукопожатие, поддержание соединения и очереди влияют на путь пользовательского запроса.
Глубина на интервью
Усиливает обсуждение транспортного слоя в кейсах с высокими требованиями к надежности.
RFC
RFC 9293 (TCP)
Действующий первоисточник по TCP: формат сегмента, состояния соединения и правила работы протокола — то, на что стоит сослаться вместо устаревших обзоров.
Ярлык «надёжный транспорт» закрывает только половину разговора. На практике протокол TCP — это слой, который переводит качество сети в конкретные задержки, расход памяти, цену соединения и поведение сервиса под нагрузкой.
Для системного дизайна полезно понимать, как строит соединение, зачем ему и почему вместе с и определяют устойчивость сервиса не меньше, чем код приложения.
На скорость передачи влияют , , , и . Именно они объясняют, почему номинальная ширина канала ещё не гарантирует высокую и низкую .
Для архитектора отсюда следуют прикладные решения: когда держать , как настраивать и , как реагировать на , где нужен и почему фаза или могут неожиданно испортить путь пользовательского запроса.
Ключевые свойства протокола TCP
Надёжная доставка
Байтовый поток сохраняется в порядке: сегменты подтверждаются, потерянные — уходят на повторную передачу без участия приложения.
Работа через соединение
До первого байта полезной нагрузки стороны согласуют состояние сеанса и базовые параметры. Это плата за предсказуемость потока.
Подтверждения и повторные передачи
Подтверждение (ACK) даёт отправителю обратную связь о доставке и позволяет восстановить поток после сетевых сбоев, не дожидаясь жалобы пользователя.
Управление потоком
Окно приёма не даёт отправителю утопить буферы получателя — сколько уместится, столько и придёт.
Управление перегрузкой
Темп задаёт не отправитель, а сигналы сети: потери, задержки, явные пометки. Максимальная скорость любой ценой ломает соседей по каналу.
Как устроен заголовок сегмента протокола TCP
В заголовке нет ничего лишнего: каждое поле отвечает за конкретный механизм — порядок доставки, подтверждения, согласование окна, контроль ошибок и реакцию на потери.
Базовый заголовок сегмента протокола TCP
20-60 байтПорт источника
16 бит
Порт назначения
16 бит
Номер последовательности
32 бит
Номер подтверждения
32 бит
Длина заголовка
4 бит
Резерв
4 бит
Флаги
8 бит
Размер окна
16 бит
Контрольная сумма
16 бит
Указатель срочных данных
16 бит
Опции и выравнивание (необязательно)
32 бит
Базовый заголовок обычно занимает 20 байт. Опции вроде максимального размера сегмента (MSS), масштабирования окна, SACK Permitted и Timestamps могут расширить его до 60 байт.
Жизненный цикл соединения протокола TCP
Установка соединения
SYN -> SYN с подтверждением ACK -> подтверждение ACK. Стороны договариваются о начальных номерах последовательности, максимальном размере сегмента (MSS) и параметрах окна — без этого первый байт данных не пойдёт.
Передача данных
Байтовый поток режется на сегменты, подтверждения ACK сигналят о доставке, окно приёма дышит вместе с буферами получателя, потерянные сегменты уходят на повторную передачу.
Завершение соединения
FIN и подтверждения ACK обмениваются в обе стороны, активная сторона садится в TIME_WAIT. Это страховка: чтобы старые сегменты не приклеились к следующему соединению на тех же портах.
Трёхшаговое рукопожатие протокола TCP
Рукопожатие — это не «открытие сокета», а синхронизация номеров последовательности, проверка достижимости второй стороны и создание состояния соединения. За это состояние потом приходится платить задержкой на каждом новом запросе и памятью на сервере.
Трёхшаговое рукопожатие TCP
Выберите шаг или используйте кнопки, чтобы заново пройти установку соединения.
Состояние
Нажмите «Начать», чтобы пройти все шаги установки TCP-соединения.
Соединение установлено — и протокол TCP начинает балансировать между желанием ускориться и сигналами, что сеть уже на пределе. В этой фазе видно, где упираемся: в получателя, в очереди по дороге или в ширину канала.
Контроль потока и перегрузок в динамике
Прокрутите шаги по RTT, чтобы увидеть, как меняются окно перегрузки и окно приёма.
Окно перегрузки (cwnd)
2 MSSОкно приёма (rwnd)
18 MSSЭффективное окно отправки
2 MSSЗагрузка очереди
8%Высокая заполненность очереди увеличивает хвостовую задержку даже без крупных потерь.
RTT
18 ms
Потери
0.0%
Оценка пропускной способности
1.3 Mbps
MSS = 1460B
Фаза: Медленный старт
Что происходит на этом шаге: Соединение только стартовало: отправитель быстро наращивает cwnd, а сеть пока почти не ограничивает поток.
Расшифровка обозначений
- cwnd = окно перегрузки - Ограничение на стороне отправителя: меняется по сигналам перегрузки и задаёт объём данных в полёте.
- rwnd = окно приёма - Ограничение на стороне получателя: передаётся в ACK и показывает доступный буфер.
- окно отправки = min(cwnd, rwnd) - Фактический лимит отправки всегда определяется меньшим из этих двух окон.
Связанная глава
IPv4 и IPv6: эволюция IP-адресации
Почему свойства IP-маршрутизации задают потолок пропускной способности и устойчивости протокола TCP сильнее, чем кажется.
Как маршрутизация и сеть меняют поведение протокола TCP
Время прохождения и произведение пропускной способности на задержку (BDP)
Чем выше время прохождения туда и обратно (RTT) и произведение пропускной способности на задержку, тем шире должно быть эффективное окно — иначе канал простаивает в ожидании подтверждений.
Потери и рост очередей
Каждая потеря и переполнение очереди ужимают окно перегрузки (cwnd). Хвостовая задержка растёт, восстановление потока заметно затягивается.
Асимметрия маршрутов
Прямой и обратный пути нередко расходятся: сегменты приходят не по порядку, появляются лишние дублирующие подтверждения ACK и ложные сигналы потерь.
Максимальный размер блока передачи (MTU) и фрагментация
Сломанное определение максимального размера блока передачи (MTU) на пути даёт фрагментацию, чёрные дыры и тяжёлые циклы повторной передачи — а в логах сервиса это выглядит как «иногда подвисает».
Тайм-ауты простоя у преобразования сетевых адресов (NAT) и балансировщиков
Долгоживущие сеансы протокола TCP молча обрываются на промежуточных устройствах. Сервис получает обрыв соединения и принимает его за сетевой инцидент, хотя проблема в политике преобразования сетевых адресов или балансировщика.
Почему это важно для системного дизайна
- Стоимость рукопожатия и прогрев соединений напрямую попадают в 95-й перцентиль (p95) и 99-й перцентиль (p99) на входе в сервис — это первое, что замечает пользователь.
- Реальную пропускную способность задают размер окна, время прохождения туда и обратно (RTT) и управление перегрузкой, а не номинальная ширина канала в договоре с провайдером.
- Неаккуратные тайм-ауты и повторные попытки под нагрузкой превращают единичную деградацию в каскадный сбой быстрее, чем успевает сработать алерт.
- Когда понятно, как ведёт себя транспорт, сетевой инцидент отличается от ошибки в бизнес-логике на минутах, а не на часах.
Частые ошибки
Считать транспортный слой стабильным по умолчанию и закрывать глаза на хвостовую задержку на сетевых участках.
Сваливать признаки перегрузки сети и тайм-ауты приложения в одну метрику — потом невозможно понять, где именно сломалось.
Не держать пул соединений и поддержание соединения (keep-alive): каждый запрос платит за рукопожатие, 95-й перцентиль раздувается на пустом месте.
Одни и те же тайм-ауты и политики повторных попыток для трафика внутри дата-центра и между регионами — гарантированный путь к каскадным сбоям.
Связанные главы
- Модель OSI - ставит протокол TCP на транспортный уровень и даёт способ разбирать сетевые инциденты по слоям, а не вслепую.
- IPv4 и IPv6: эволюция IP-адресации - разбирает, как маршрутизация IP и формат адресов под ногами протокола TCP меняют его поведение под нагрузкой.
- Протокол UDP - альтернатива для случаев, когда встроенные гарантии протокола TCP стоят дороже, чем приложение готово платить — и гарантии переносятся в код.
- Протокол HTTP - верхний этаж над TCP в большинстве сервисов: видно, как прикладной протокол переиспользует соединения и где он усиливает узкие места транспорта.
- Протокол WebSocket - сценарий долгоживущих соединений по протоколу TCP, где обрывы преобразования сетевых адресов (NAT) и стоимость памяти на сервере выходят на первый план.
- Балансировка трафика - L4/L7-балансировка, закрепление соединений и тайм-ауты сетевых устройств — три места, где сеансы протокола TCP чаще всего рвутся незаметно для приложения.
- Подходы к удалённым вызовам - поверх транспорта — прикладной слой: тайм-ауты, повторные попытки и нарастающие паузы, которые должны согласовываться с поведением протокола TCP, а не воевать с ним.
- Зачем нужны распределённые системы и консистентность - следующий шаг разговора: от механики одного соединения к компромиссам, которые архитектор делает на уровне всей распределённой системы.