Она носит название bufferbloat, или «излишняя сетевая буферизация». Обсудим причины, а также механизмы, которые позволят разрешить ситуацию (по крайней мере, в теории).
Буферное надувательство
При обмене информацией пакеты проходят через десятки и сотни буферов данных. За их состоянием следят специальные алгоритмы контроля перегрузки, которые предотвращают переполнение и снижают скорость передачи. Однако если очередь пакетов — например, в широкополосном маршрутизаторе — становится слишком длинной, возникают нюансы.
Большое количество пакетов может вызывать так называемое «распухание буфера», или bufferbloat. Это явление приводит к продолжительным паузам в передаче данных. Перебои особенно заметны в контексте требовательных сетевых задач вроде стриминга, онлайн-игр и даже VoIP.
Эксперимент с целью оценить влияние bufferbloat на пропускную способность проводили в сетях американских провайдеров. В обычном режиме средняя задержка на 40-мегабитном DSL-подключении составляет 27 мс, а на 300-мегабитном оптоволокне — 20 мс. Если нагрузить канал (например, передачей фото или видео в облако), средние задержки «подскакивают» до 281 и 48 мс соответственно.
Давняя проблема
О ситуации с излишней сетевой буферизацией известно как минимум с 2010 года. Впервые о ней заговорил Джим Геттис, инженер и член комитета W3C. Но за прошедшие двенадцать лет bufferbloat так и не удалось побороть окончательно.
Да, существуют специальные алгоритмы, противостоящие раздуванию буферов. Например, классические Reno и CUBIC, которые идентифицируют перегрузку по количеству потерянных пакетов. С другой стороны, BBR применяет методы моделирования канала связи и прогнозирует пропускную способность на основе показателя RTT. Кроме них, существуют десятки других алгоритмов, а в 2011 году вообще был сформирован экспериментальный репозиторий Linux-ядра — debloat-testing. Разработчики тестировали в нем новые механизмы для противодействия излишней буферизации.
Однако в августе инженеры из MIT опубликовали результаты нового исследования. Они утверждают, что существующие механизмы борьбы с bufferbloat недостаточно эффективны. В большинстве случаев они ориентируются на рост задержек и потери пакетов — ключевые индикаторы перегрузки сети — но их может вызывать не только переполнение буфера.
Вообще, существуют специальные инструменты для проверки качества соединения. Если во время нагрузочного тестирования задержка серьезно возрастает, скорее всего, сеть подвержена влиянию bufferbloat. Например, можно воспользоваться консольной утилитой flent. На официальном сайте проекта вы найдете руководство по быстрому старту и полную документацию. Но чтобы оценить пропускную способность достаточно ввести следующую команду:
flent rrul -p all_scaled -H flent-fremont.bufferbloat.net Также существуют специальные тесты, которые позволяют провести оценку в онлайн-формате и без установки дополнительного ПО.
Движение вперед
Решением проблемы bufferbloat может стать дальнейшее развитие программно-аппаратного стека. Одна из перспективных технологий в этой области — smart queue management (SQM).
На сетевом устройстве формируются несколько очередей (вместо одной) для разных типов трафика — например, загрузки данных в облачное хранилище, передачу электронной почты или потокового видео. Приоритет отдают очередям меньшего размера, чтобы компактные задания «не застревали» за длинными последовательностями пакетов. В каком-то смысле SQM напоминает QoS в сетях провайдеров, только последняя технология приоритезирует различные классы трафика. К сожалению, большинство маршрутизаторов на рынке пока не поддерживает smart queue management.
В долгосрочной перспективе решением может стать переход на новую сетевую архитектуру. В этом направлении уже ведут работу инженеры IETF. Они работают над проектом L4S и предлагают [PDF, стр.1] использовать масштабируемые алгоритмы контроля перегрузки канала вроде Prague, Explicit Congestion Notification (ECN) и Dual Queue Coupled Active Queue Management (DQC AQM). Однако разработка идет как минимум с 2017 года, и до финализации стандарта все еще далеко.
Дополнительное чтение в нашем блоге на Хабре:
Смешали TCP — почему появился стандарт RFC 9293
Проанализировать потоки трафика — поможет PiRogue
Больше материалов о сетях и работе провайдеров — на сайте VAS Experts:
Если нужно взять и поднять собственный DNS-сервер
Торрент-трафик растет: наши наблюдения
