Алгоритм медленного старта¶

Алгоритм медленного старта (англ. slow-start algorithm) — это механизм управления перегрузкой в протоколах транспортного уровня, преимущественно в протоколе TCP (Transmission Control Protocol), который регулирует скорость отправки данных в начале соединения или после восстановления связи после потери пакетов. Основная цель алгоритма — предотвратить перегрузку сети, постепенно увеличивая объём передаваемых данных, пока не будет достигнут пороговый уровень, после чего применяются другие алгоритмы (например, предотвращение перегрузки). Алгоритм медленного старта является частью более широкого набора методов управления перегрузкой TCP, разработанных для обеспечения стабильной работы интернета.

¶История

Алгоритм медленного старта был впервые описан в 1988 году в работе Ван Джейкобсона «Congestion Avoidance and Control» (RFC 1122). В 1980-х годах в интернете наблюдались частые коллапсы перегрузки, когда из-за неконтролируемого роста трафика маршрутизаторы переполнялись, что приводило к массовым потерям пакетов и снижению пропускной способности. Джейкобсон предложил подход, при котором отправитель TCP начинал с минимального темпа отправки данных и увеличивал его экспоненциально, пока не наступали признаки перегрузки.

В 1990-х годах алгоритм медленного старта был включён в стандарт TCP Reno, который стал основой для большинства реализаций TCP. Позднее, в 2000-х, алгоритм был усовершенствован в вариантах TCP NewReno, TCP Cubic и других, где были добавлены механизмы для более точного определения порога перегрузки и ускорения восстановления после потерь. В современных версиях TCP (например, в Linux с 2018 года используется BBR — Bottleneck Bandwidth and Round-trip propagation time) алгоритм медленного старта может быть модифицирован или заменён, но его принципы остаются актуальными.

¶Принцип работы

¶Начало соединения

При установлении TCP-соединения отправитель не знает пропускной способности сети и уровня загрузки маршрутизаторов. Алгоритм медленного старта задаёт начальный размер окна перегрузки (congestion window, cwnd) — количество сегментов данных, которые могут быть отправлены без подтверждения получения. В классической реализации TCP (RFC 5681) начальное значение cwnd составляет 1 сегмент (обычно 1 MSS — Maximum Segment Size, максимальный размер сегмента, часто 1460 байт для Ethernet). Однако в современных системах (например, в Linux с 2013 года) начальное окно может быть увеличено до 10 сегментов (RFC 6928) для ускорения загрузки веб-страниц.

¶Экспоненциальный рост

После отправки первого сегмента отправитель ждёт подтверждения (ACK) от получателя. Каждое полученное подтверждение увеличивает cwnd на 1 сегмент. Таким образом, за каждый RTT (Round-Trip Time, время кругового обхода) размер окна удваивается:

• 1 RTT: cwnd = 2 сегмента
• 2 RTT: cwnd = 4 сегмента
• 3 RTT: cwnd = 8 сегментов
• 4 RTT: cwnd = 16 сегментов

Этот экспоненциальный рост продолжается, пока не будет достигнут порог медленного старта (ssthresh, slow-start threshold) или не произойдёт потеря пакета.

¶Порог медленного старта

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

¶Обработка потерь пакетов

Если происходит потеря пакета (например, из-за переполнения буфера маршрутизатора), отправитель получает сигнал: либо тайм-аут (RTO, Retransmission Timeout), либо три дублированных ACK (в случае быстрой повторной передачи). В ответ на потерю:

• ssthresh устанавливается равным половине текущего cwnd (но не менее 2 сегментов).
• cwnd сбрасывается до начального значения (1 сегмент или 10 сегментов в современных реализациях).
• Алгоритм медленного старта запускается заново, но теперь с новым, более низким порогом ssthresh.

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

¶Классификация и варианты

¶TCP Reno

Классическая реализация, описанная в RFC 5681. Использует медленный старт с начальным окном 1 сегмент, порог ssthresh, вычисляемый после потерь. После потери пакета переходит в фазу предотвращения перегрузки с линейным ростом.

¶TCP NewReno

Улучшение TCP Reno, предложенное в RFC 3782. Включает механизм быстрой повторной передачи и быстрого восстановления, что позволяет избежать полного сброса cwnd при множественных потерях в одном окне. Медленный старт работает аналогично, но восстановление после потерь происходит быстрее.

¶TCP Cubic

Алгоритм, используемый по умолчанию в ядре Linux с 2005 года. В фазе предотвращения перегрузки использует кубическую функцию для роста окна, что даёт лучшую производительность в высокоскоростных сетях. Медленный старт в TCP Cubic может быть ускорен за счёт большего начального окна (до 10 сегментов) и адаптивного порога.

¶TCP BBR (Bottleneck Bandwidth and Round-trip propagation time)

Алгоритм, разработанный Google в 2016 году. Вместо экспоненциального роста на основе потерь пакетов BBR оценивает пропускную способность узкого места сети и минимальное RTT. Медленный старт в BBR выполняется за один RTT: отправитель сразу отправляет столько данных, сколько позволяет оценённая пропускная способность, что значительно ускоряет начало передачи.

¶Применение

¶Веб-серфинг и загрузка страниц

Алгоритм медленного старта критически важен для работы веб-браузеров. При открытии веб-страницы браузер устанавливает несколько TCP-соединений (обычно 6–10 на домен). Медленный старт позволяет каждому соединению постепенно увеличивать скорость, не перегружая сеть. Современные браузеры (Chrome, Firefox) используют начальное окно в 10 сегментов, что сокращает время загрузки страниц на 10–20% по сравнению со старыми реализациями.

¶Потоковое видео и аудио

Сервисы потокового вещания (YouTube, Netflix) используют протоколы на основе TCP (например, QUIC, который также включает медленный старт). Алгоритм позволяет быстро адаптироваться к изменениям пропускной способности сети, что важно для предотвращения буферизации. Однако для потокового видео медленный старт может быть недостаточно быстрым, поэтому используются дополнительные механизмы, такие как адаптивное битрейт-стриминг.

¶Облачные вычисления и дата-центры

Внутри дата-центров, где задержки малы (RTT менее 1 мс), медленный старт может быть излишне медленным. Для ускорения передачи данных между серверами используются модифицированные версии TCP (например, DCTCP — Data Center TCP), которые изменяют порог ssthresh и начальное окно. В DCTCP медленный старт может быть пропущен, если сеть не перегружена.

¶Критика и ограничения

¶Медленный старт в высокоскоростных сетях

В сетях с высокой пропускной способностью (например, 10 Гбит/с и выше) экспоненциальный рост медленного старта может занимать много RTT, прежде чем окно достигнет оптимального размера. Например, для заполнения канала в 10 Гбит/с с RTT 10 мс требуется около 10 RTT (0,1 секунды), что приемлемо, но для каналов в 100 Гбит/с и RTT 100 мс (например, трансатлантические соединения) медленный старт может занять несколько секунд, снижая эффективность передачи.

¶Проблемы с малыми окнами

При малых размерах окна (например, начальное окно в 1 сегмент) медленный старт может быть слишком консервативным. Это особенно заметно в мобильных сетях с высокими задержками (3G/4G), где RTT может достигать 100–200 мс. В таких условиях загрузка небольшого файла (например, 10 КБ) может занять несколько RTT из-за медленного старта, что увеличивает задержку.

¶Альтернативы и модификации

Для преодоления ограничений были предложены альтернативы: алгоритм HyStart (Hybrid Slow Start), который определяет момент перехода к предотвращению перегрузки на основе измерения задержек (RTT), а не только потерь. HyStart используется в TCP Cubic и Linux по умолчанию с 2013 года. Другой подход — алгоритм BBR, который полностью отказывается от экспоненциального роста в пользу оценки пропускной способности.

¶Интересные факты

• Название «медленный старт» вводит в заблуждение: на самом деле алгоритм быстро увеличивает скорость (экспоненциально), но начинается с минимального значения.
• В ранних версиях TCP (до 1988 года) не было управления перегрузкой, что приводило к коллапсам сети. Алгоритм медленного старта стал одним из ключевых решений, спасших интернет от перегрузок.
• В современных операционных системах (Windows, Linux, macOS) начальное окно медленного старта увеличено до 10 сегментов (RFC 6928), что ускоряет загрузку веб-страниц на 10–20% по сравнению с 1 сегментом.
• Алгоритм медленного старта используется не только в TCP, но и в протоколах QUIC (используется в HTTP/3) и SCTP (Stream Control Transmission Protocol).

¶Источники

• RFC 5681 — TCP Congestion Control
• RFC 6928 — Increasing TCP's Initial Window
• Jacobson, V. (1988). Congestion Avoidance and Control. ACM SIGCOMM Computer Communication Review.
• Allman, M., Paxson, V., & Stevens, W. (1999). TCP Congestion Control. RFC 2581.
• Cardwell, N., et al. (2016). BBR: Congestion-Based Congestion Control. ACM Queue.