Протокол TCP и управление потоком данных

Содержание

1. 1. Эволюция и роль TCP в сетях3
2. 2. Механизм скользящего окна5
3. 3. Алгоритмы управления перегрузкой8
4. 4. Сравнение и практические аспекты10

1. Эволюция и роль TCP в сетях

В конце 1960-х Министерство обороны США взялось за создание сети ARPANET. Тогда никто не думал, что её протоколы доживут до наших дней. Инженерам пришлось решать странную задачу: линии связи то и дело отказывали, узлы падали, но данные обязаны были доходить до получателя. Ответ появился в 1974 году, когда Винтон Серф и Роберт Кан опубликовали статью с описанием протокола TCP. Суть их идеи сводилась к тому, чтобы перенести заботу о целостности информации с оборудования на сам протокол. Пусть сеть теряет пакеты, портит их или дублирует. Конечные узлы всё равно должны это заметить и исправить.

TCP работает на четвёртом, транспортном уровне модели OSI. Этот уровень сидит между прикладными программами и нижележащими протоколами, которые отвечают за маршрутизацию. Выглядит это так: приложение создаёт сокет (связку IP-адреса и номера порта) и отправляет через него данные. Порт, скажем, 80 для HTTP или 443 для HTTPS, указывает на конкретный сервис на хосте. Благодаря сокетам TCP умеет мультиплексировать: на одной машине много приложений спокойно обмениваются данными одновременно, не создавая друг другу помех.

В основе TCP лежит несколько обязательных шагов. Перед началом передачи отправитель и получатель делают трёхэтапное рукопожатие: обмениваются пакетами SYN, SYN-ACK и ACK. Так устанавливается соединение и согласуются стартовые порядковые номера. Дальше поток байтов режется на сегменты, каждому присваивается уникальный номер. Получатель, когда сегмент доходит, шлёт подтверждение (ACK), где указывает номер следующего байта, который ждёт. Если подтверждения нет, отправитель передаёт данные заново. Эта схема ловит потери, дубликаты и перестановки пакетов.

Главное различие между TCP и его соседом по транспортному уровню, UDP, упирается в подход к доставке. UDP создавался для таких вещей, как

видеозвонки или DNS-запросы: он шлёт дейтаграммы без всяких обещаний. Быстро, но без гарантий, дойдёт ли пакет. TCP же обещает доставку, проверяет каждый сегмент через контрольную сумму и следит за потоком. За это приходится платить: заголовок TCP занимает минимум 20 байт (у UDP всего 8), а само установление соединения добавляет задержку. Впрочем, для пересылки файлов, почты или веб-страниц такие издержки вполне оправданы.

Надёжность и сделала TCP основой интернета. По данным Cisco за 2023 год, на TCP приходится примерно 85% всего веб-трафика. Протокол менялся, обрастал новыми алгоритмами, но базовая архитектура, которую придумали Серф и Кан, осталась прежней. И она по-прежнему обеспечивает предсказуемую и корректную передачу данных в сети, где единственное постоянство это непостоянство.

2. Механизм скользящего окна

Простейшая схема подтверждения, когда отправитель ждет ACK на каждый сегмент, превращает сеть в медленный последовательный конвейер. Время простоя канала в таком режиме сравнимо со временем передачи, что резко снижает пропускную способность. Скользящее окно решает эту проблему радикально: оно разрешает отправлять несколько сегментов подряд, не дожидаясь ответа на каждый из них. Отправитель хранит копии неподтвержденных данных и сдвигает границу окна только после получения подтверждений.

Размер этого окна определяет не отправитель, а получатель. В каждом сегменте TCP есть поле Window Size, и именно это значение управляет объемом данных, которые может послать другая сторона. Получатель вычисляет его исходя из свободного места в своем приемном буфере. Если приложение медленно читает данные, буфер заполняется, и получатель уменьшает окно в своих ответах, фактически приказывая отправителю сбавить темп. Когда буфер освобождается, окно снова увеличивается. Так устанавливается динамическое равновесие, защищающее память получателя от переполнения. По сути, это и есть управление потоком в его чистом виде: отправитель физически не может завалить получателя данными, которые тот не в состоянии обработать.

Однако простое наличие окна не гарантирует эффективности. Сетевые инженеры давно заметили, что наивная отправка мелких порций данных создает паразитную нагрузку. В 1984 году Джон Нейгл предложил элегантное правило, ставшее стандартом де-факто. Алгоритм Нейгла запрещает отправлять маленький сегмент, если есть неподтвержденные данные. Отправитель ждет либо подтверждения на предыдущие сегменты, либо накопления данных до размера максимального сегмента. Это правило хорошо работает для интерактивных приложений вроде Telnet, где каждый нажатый символ превращается в отдельный пакет. Без него такие приложения порождали бы тысячи крошечных дейтаграмм,

забивая канал заголовками.

Противовесом алгоритму Нейгла выступает задержка подтверждений. Получатель не отправляет ACK немедленно на каждый сегмент, а выдерживает паузу в 40-200 миллисекунд в надежде объединить несколько подтверждений в одно. Это снижает количество служебных пакетов в обратном направлении и позволяет передавать данные вместе с подтверждениями в одном сегменте. Но здесь есть тонкий момент: совместная работа алгоритма Нейгла и delayed ACK может привести к тупиковой ситуации. Отправитель ждет ACK, чтобы послать новые данные, а получатель ждет данные, чтобы отослать подтверждение. Протокол выходит из этого состояния только по истечении таймера, что добавляет задержку до 200 миллисекунд на каждое взаимодействие.

Скользящее окно в TCP не является статичной величиной. Оно постоянно меняется, отражая состояние канала и ресурсы приемника. Механизм работает в обе стороны: каждая из сторон соединения объявляет свое окно для противоположного направления. Это асимметричный процесс, который позволяет одному направлению передачи доминировать над другим. На практике размер окна ограничен сверху не только буфером, но и полем заголовка, которое имеет длину 16 бит. Это дает максимум 65535 байт, что для современных высокоскоростных каналов часто недостаточно. Поэтому в RFC 1323 был предложен масштабирующий коэффициент окна, который сдвигает это значение влево на несколько бит, увеличивая эффективный размер окна до гигабайта.

Правильная настройка окна критична для производительности. Слишком маленькое окно заставляет отправителя простаивать, ожидая подтверждений, и не использует доступную полосу пропускания. Слишком большое окно может переполнить буфер получателя, что вызовет отбрасывание пакетов и повторные передачи. Идеальный размер окна, как правило, равен произведению пропускной способности канала на время кругового обхода (так называемому произведению

задержки на полосу пропускания). Именно эта величина определяет, сколько данных должно находиться в полете для полного заполнения конвейера. Скользящее окно, таким образом, является не просто механизмом надежности, но и инструментом тонкой настройки, от которого напрямую зависит скорость передачи данных в любой TCP-сети.

3. Алгоритмы управления перегрузкой

Скользящее окно решает проблему простоя канала, но порождает новую угрозу. Если отправитель агрессивно заполняет сеть данными, буферы маршрутизаторов переполняются, и пакеты начинают массово отбрасываться. В конце 1980-х годов это явление получило название «коллапс сети»: пропускная способность падала до нуля, хотя все узлы продолжали передачу. Для борьбы с этим эффектом Вэйн Джейкобсон в 1988 году предложил алгоритмы, ставшие ядром современного управления перегрузкой.

Медленный старт действует вопреки своему названию. Он начинается не с максимального, а с минимального размера окна перегрузки (cwnd), обычно одного сегмента. После каждого подтверждения ACK окно увеличивается экспоненциально: 1, 2, 4, 8 сегментов. Такой рост выглядит стремительным, но он строго ограничен порогом ssthresh (slow start threshold). Логика проста: пока сеть отвечает подтверждениями, значит, она справляется с нагрузкой. Если ACK перестают приходить, передача останавливается на текущем уровне, не успев создать затор.

Экспоненциальный рост не может продолжаться вечно, иначе TCP снова спровоцирует перегрузку. Поэтому после достижения ssthresh алгоритм переключается в режим предотвращения перегрузки (congestion avoidance). Здесь cwnd растет уже не в геометрической, а в арифметической прогрессии: примерно один сегмент за время кругового обхода (RTT). Это медленный, линейный подъем, который позволяет прощупать доступную полосу без риска создать очередь. По сути, TCP действует как альпинист, который осторожно проверяет каждый выступ перед тем, как перенести на него вес.

Но сеть непредсказуема, и потери пакетов случаются даже при аккуратном росте окна. Классическая реакция, ожидание тайм-аута, слишком дорога: передача простаивает, а пропускная способность падает. Здесь вступают в действие быстрая повторная передача и быстрое

восстановление. Если получатель принимает сегмент с нарушенной последовательностью, он отправляет три одинаковых ACK (duplicate ACK) на последний корректно принятый сегмент. Тройное повторение ACK служит надежным сигналом потери. Отправитель немедленно повторяет пропавший сегмент, не дожидаясь истечения таймера. При этом cwnd уменьшается вдвое, но не обнуляется, что позволяет сохранить темп передачи. Этот механизм, реализованный в версии TCP Reno, заметно ускоряет восстановление соединения по сравнению с ранней версией Tahoe, которая в аналогичной ситуации начинала с нуля.

Интересно, что все эти алгоритмы работают без какого-либо центрального координатора. Каждый узел TCP сам оценивает состояние сети по косвенным признакам: подтверждениям, их задержкам и потерям. Это децентрализованная система, где каждый участник стремится к максимуму, но вынужден уступать, когда сеть сигнализирует о перегрузке. Такое поведение обеспечивает справедливое распределение полосы между конкурирующими потоками: агрессивный отправитель быстро упрется в порог, а умеренный будет спокойно увеличивать окно.

За прошедшие десятилетия появились модификации: New Reno улучшила обработку множественных потерь, Cubic адаптировала рост окна для высокоскоростных каналов. Но фундаментальные принципы, заложенные Джейкобсоном, остаются неизменными. Они превратили TCP из простого транспортного механизма в систему, способную выживать в условиях перегруженного интернета, где число одновременных соединений измеряется миллионами.

4. Сравнение и практические аспекты

Скользящее окно и управление перегрузкой решают разные задачи, хотя в заголовке TCP они соседствуют. Окно, объявляемое получателем, защищает его буфер от переполнения: отправитель не пошлёт больше данных, чем готов принять собеседник. Окно перегрузки (cwnd), которое вычисляет сам отправитель, защищает сеть. Оно ограничивает объём данных в полёте, чтобы не перегрузить промежуточные маршрутизаторы. В работающей реализации действующее окно равно минимуму из этих двух величин. Если получатель готов принять 64 КБ, а cwnd составляет 16 КБ, отправитель ограничен вторым числом. Игнорирование любого из ограничений ведёт либо к потере пакетов из-за переполнения буфера, либо к коллапсу сети, когда полезная пропускная способность падает до нуля из-за повторных передач.

Эволюция TCP в части управления перегрузкой хорошо прослеживается по конкретным реализациям. TCP Tahoe, появившийся в конце 1980-х, при обнаружении потери пакета откатывал окно к единице и заново проходил медленный старт. Это просто, но слишком грубо: на канале с задержкой 100 мс и пропускной способностью 10 Мбит/с такой откат съедал секунды. TCP Reno добавил быстрое восстановление: при получении трёх дублирующих ACK окно уменьшалось вдвое, а не до нуля, что заметно ускоряло реакцию на единичные потери. Проблема Reno в том, что он плохо масштабируется на каналы с большой полосой пропускания. Линейный рост окна в фазе предотвращения перегрузки слишком медленный, чтобы заполнить трубу в 10 Гбит/с. TCP Cubic, используемый в Linux по умолчанию с 2006 года, решает это нелинейной функцией роста окна. После потери он быстро восстанавливает прежний размер, а затем плавно приближается к нему. Это даёт выигрыш на длинных каналах без агрессивного захвата полосы у конкурентов. По данным из работ Сангты Ха и Илайи Ретиса, Cubic показывает в 10-20 раз более высокую пропускную способность, чем Reno, на

каналах с задержкой 100 мс и полосой 100 Мбит/с.

Практическая настройка TCP часто важнее выбора версии алгоритма. Размер окна приёма по умолчанию в старых системах составлял 64 КБ, что ограничивало пропускную способность на каналах с высокой задержкой. Формула пропускной способности проста: окно делится на RTT. Для канала в 1 Гбит/с с задержкой 50 мс нужно окно не менее 6,25 МБ, иначе канал будет простаивать. Современные ОС автоматически масштабируют окно, но на спутниковых каналах с RTT 500-600 мс этого может не хватить, и приходится вручную увеличивать буферы ядра. Таймеры повторной передачи тоже требуют калибровки. Стандартный алгоритм Карна вычисляет RTO как средневзвешенное RTT плюс четыре отклонения, но при резких скачках задержки это приводит к ложным тайм-аутам. На спутниковых линиях с переменной загрузкой операторы часто увеличивают минимальный RTO до 1-2 секунд, чтобы избежать ненужных повторных передач.

Диагностика сетевых проблем без понимания этих механизмов превращается в гадание. Если приложение отдаёт данные медленно, нужно смотреть не только на загрузку CPU, но и на значение cwnd в выводе ss или netstat. Маленькое окно перегрузки при отсутствии потерь указывает на ограничение приёма на стороне получателя. Резкие падения cwnd до половины говорят о потерях пакетов, а их источником могут быть как переполненные очереди маршрутизаторов, так и битые линки. В высоконагруженных дата-центрах, где RTT составляет 0,5 мс, стандартный Cubic ведёт себя плохо: он слишком долго растёт и не успевает адаптироваться к всплескам трафика. Поэтому для таких сред Google разработал алгоритм BBR, который оценивает реальную полосу пропускания и минимальную задержку, а не реагирует на потери. Это показывает: единого лучшего TCP не существует, и выбор версии зависит от характеристик сети и типа трафика. Инженер, который понимает разницу между окном получателя и окном перегрузки, а также знает, как поведёт себя конкретный

алгоритм на заданной топологии, сможет выжать из сети максимум без слепого перебора параметров.