TCP в ловушке Starlink: что мешает стабильной работе протокола

Услуга спутникового интернета Starlink от компании SpaceX представляет собой «крайне неблагоприятную среду» для широко используемого протокола TCP. Такую оценку дал Джефф Хьюстон, главный научный сотрудник Азиатско-Тихоокеанского центра информационных сетей, разместив в своем блоге анализ производительности Starlink.

TCP (Transmission Control Protocol) — это один из основных сетевых протоколов, обеспечивающий надежную передачу данных в интернете и других TCP/IP сетях. Он гарантирует, что пакеты данных будут доставлены в правильном порядке и без потерь, управляя скоростью передачи, определяя маршрут и запрашивая повторную отправку потерянных пакетов. Большинство популярных интернет-приложений и сервисов полагаются на TCP для обмена информацией.

Хьюстон объясняет, что спутники на низкой околоземной орбите настолько быстро проносятся над поверхностью нашей планеты, что способны пересечь небосклон от горизонта до горизонта менее чем за пять минут. Чтобы сохранить соединение, наземные антенны вынуждены периодически переключаться на другой аппарат в сети.

Используя команду PING, ученый обнаружил, что минимальная задержка изменяется каждые 15 секунд. Это и позволило предположить, что пользовательские терминалы непрерывно переключаются на новые спутники. По оценкам Хьюстона, оборудование Starlink отслеживает каждый спутник в течение 15-секундного интервала, что соответствует углу наблюдения в 11 градусов.

Во время переключений между спутниками Хьюстон зафиксировал потерю пакетов и значительные скачки задержки. В худшем случае задержка возрастала с 30 до 80 миллисекунд. Более того, в пределах каждого 15-секундного интервала отслеживания вариация задержки была относительно высокой — в среднем джиттер между последовательными интервалами RTT составлял 6,7 мс. Всплески задержки при переключениях достигали 30-50 мс. Это значит, что в системе Starlink используются большие буферы для сглаживания кратковременных проблем, возникающих при передаче соединения с одного спутника на другой. Наличие таких буферов помогает преодолевать временные сбои, вызванные частой сменой спутников во время сеанса связи.

В целом, по словам Хьюстона, для Starlink характерны «очень высокий уровень джиттера, доля потерянных пакетов порядка 1-2%, не связанная с перегрузкой сети, и задержка, регулярно скачущая каждые 15 секунд».

Такие условия и создают «крайне неблагоприятную среду для передачи данных» через протокол TCP. Значит, более старые версии, такие как Reno TCP, быстро реагирующие на потерю пакетов и медленно восстанавливающиеся, будут работать плохо при использовании сети Starlink.

Однако исследователь полагает, что эту проблему можно решить, немного оптимизировав протокол для работы со Starlink. Он предлагает три потенциальных кандидата, способных справиться с этой задачей...

Одним из возможных решений является протокол BBR (Bottleneck Bandwidth and Round-trip propagation time) — алгоритм управления перегрузкой TCP, разработанный в Google. BBR пытается предсказать задержки на сетевом пути и соответственно подстраивает стратегии отправки данных.

Также неплохо может справиться алгоритм предотвращения перегрузки CUBIC TCP в паре с селективными подтверждениями (SACK — RFC 2883).

Хьюстон считает, что помочь может и явное уведомление о перегрузке (Explicit Congestion Notification), поскольку оно способно обрабатывать ситуации со всплесками задержки, вызванными переключениями между спутниками.

Несмотря на трудности с TCP, испытания скорости, проводившиеся Хьюстоном каждые 4 часа с августа 2023 по март 2024 года, показали, что в целом Starlink обеспечивает неплохую пропускную способность. Медианное значение составило около 120 Мбит/с на скачивание с пиками до 370 Мбит/с и минимумами в 10 Мбит/с, а также 15 Мбит/с на отдачу с вариацией от 5 до 50 Мбит/с.