Войти
Bufferbloat является причиной высокой задержки в сети с коммутацией пакетов, вызванные избыточной буферизацией из пакетов. Bufferbloat также может вызвать изменение задержки пакета (также известное как джиттер), а также снизить общую пропускную способность сети. Когда маршрутизатор или коммутатор настроен на использование чрезмерно больших буферов, даже очень высокоскоростные сети могут стать практически непригодными для многих интерактивных приложений, таких как передача голоса по IP ( VoIP), онлайн-игры и даже обычный веб-серфинг.
Некоторые производители коммуникационного оборудования встраивают излишне большие буферы в свои сетевые продукты. В таком оборудовании буферный поток возникает, когда сетевой канал становится перегруженным, что приводит к тому, что пакеты помещаются в очередь на длительные периоды в этих больших буферах. В системе очередей «первым пришел - первым вышел» чрезмерно большие буферы приводят к более длинным очередям и более высокой задержке и не улучшают пропускную способность сети.
Явление буферного вспучивания было описано еще в 1985 году. Оно привлекло более широкое внимание, начиная с 2009 года.
Установленное практическое правило для сети Производители оборудования должны были предоставить буферы, достаточно большие для размещения по крайней мере 250 мс буферизации для потока трафика, проходящего через устройство. Например, для интерфейса маршрутизатора Gigabit Ethernet потребуется относительно большой буфер размером 32 МБ. Такой размер буферов может привести к отказу алгоритма управления перегрузкой TCP . Затем буферам требуется некоторое время для истощения, прежде чем управление перегрузкой будет сброшено, а TCP-соединение снова наберет скорость и снова заполнит буферы. Bufferbloat, таким образом, вызывает такие проблемы, как высокая и переменная задержка, а также блокирование узких мест сети для всех других потоков, поскольку буфер заполняется пакетами одного потока TCP, а другие пакеты затем отбрасываются.
Раздутый буфер имеет эффект только когда этот буфер действительно используется. Другими словами, слишком большие буферы имеют разрушительный эффект только тогда, когда ссылка, которую они буферируют, становится узким местом. Размер буфера, обслуживающего узкое место, можно измерить с помощью утилиты ping, предоставляемой большинством операционных систем. Во-первых, другой хост должен постоянно опрашиваться; затем следует несколько раз начать и несколько раз остановить загрузку с него в течение нескольких секунд. По задумке алгоритм предотвращения перегрузки TCP быстро заполняет узкое место на маршруте. Если загрузка (и выгрузка, соответственно) коррелирует с прямым и важным увеличением времени приема-передачи, о котором сообщает ping, то это демонстрирует, что буфер текущего узкого места в направлении загрузки (и загрузки, соответственно) раздувается. Поскольку увеличение времени приема-передачи вызвано буфером в узком месте, максимальное увеличение дает приблизительную оценку его размера в миллисекундах.
В предыдущем примере с использованием расширенного traceroute вместо простого пинга (например, MTR ) не только продемонстрирует наличие раздутого буфера в узком месте, но также определит его местоположение в сети. Traceroute достигает этого, отображая маршрут (путь) и измеряя задержки передачи пакетов по сети. История маршрута записывается как время приема-передачи пакетов, полученных от каждого последующего хоста (удаленного узла) на маршруте (пути).
Большая часть TCP-перегрузка Алгоритмы управления полагаются на измерение случаев отбрасывания пакетов для определения доступной полосы пропускания между двумя концами соединения. Алгоритмы ускоряют передачу данных до тех пор, пока не начнут выпадать пакеты, а затем снижают скорость передачи. В идеале они продолжают регулировать скорость передачи до тех пор, пока она не достигнет равновесной скорости соединения. Чтобы алгоритмы могли выбрать подходящую скорость передачи, обратная связь об отбрасывании пакетов должна происходить своевременно. Если заполнен большой буфер , пакеты будут доставлены в пункт назначения, но с большей задержкой. Пакеты не были отброшены, поэтому TCP не замедляется после насыщения восходящей линии связи, дополнительно заполняя буфер. Новые поступающие пакеты отбрасываются только тогда, когда буфер полностью насыщен. Как только это произойдет, TCP может даже решить, что путь соединения изменился, и снова перейти к более агрессивному поиску новой рабочей точки.
Перед передачей пакеты помещаются в очередь в сетевом буфере; в проблемных ситуациях пакеты отбрасываются, только если буфер заполнен. На старых маршрутизаторах буферы были довольно маленькими, поэтому они быстро заполнялись, и поэтому пакеты начали падать вскоре после того, как канал стал насыщенным, поэтому протокол TCP мог регулироваться, и проблема не становилась очевидной. На новых маршрутизаторах буферы стали достаточно большими, чтобы хранить несколько секунд буферизованных данных. Для TCP может показаться, что перегруженный канал работает нормально по мере заполнения буфера. Алгоритм TCP не знает, что канал перегружен, и не начинает предпринимать корректирующих действий до тех пор, пока буфер окончательно не переполнится и пакеты не будут отброшены.
Все пакеты, проходящие через простой буфер, реализованный в виде единой очереди, будут испытывать аналогичную задержку, поэтому задержка любого соединения, проходящего через заполненный буфер, будет затронута. Доступная полоса пропускания канала также может оказаться неиспользованной, поскольку некоторые быстрые пункты назначения не могут быть быстро достигнуты из-за того, что буферы забиты данными, ожидающими доставки в медленные пункты назначения. Эти эффекты ухудшают интерактивность приложений, использующих другие сетевые протоколы, включая UDP, используемые в чувствительных к задержкам приложениях, таких как VoIP и онлайн-игры.
Независимо от требований к полосе пропускания, на любой тип услуги, для которой требуется стабильно низкая задержка или передача без дрожания, может влиять bufferbloat. Примеры включают голосовые вызовы, онлайн-игры, видеочат и другие интерактивные приложения, такие как обмен мгновенными сообщениями, потоковое радио, видео по запросу, и удаленный вход.
Когда присутствует явление буферного раздува и сеть находится под нагрузкой, даже обычная загрузка веб-страницы может занять много секунд, или простые запросы DNS могут завершиться ошибкой из-за тайм-аутов. Фактически любое TCP-соединение может отключиться по таймауту и отключиться, а UDP-пакеты могут быть потеряны. Поскольку продолжение потока загрузки TCP зависит от пакетов ACK в потоке загрузки, проблема с буферным разносом при загрузке может привести к сбою других не связанных приложений загрузки, потому что пакеты ACK не достигают своевременно Интернет-сервера. Вы можете, например, ограничить скорость передачи при загрузке OneDrive синхронизации, чтобы не беспокоить других пользователей домашней сети.
DSL Reports Speedtest - это простой в использовании тест, который включает оценку для буферной пустоты. ICSI Netalyzr был еще одним интерактивным инструментом, который можно было использовать для проверки сетей на наличие буферной памяти вместе с проверкой многих других распространенных проблем конфигурации. Служба была закрыта в марте 2019 года. На веб-сайте bufferbloat.net перечислены инструменты и процедуры для определения того, имеет ли соединение избыточную буферизацию, которая замедлит его.
Некоторые технические Существуют решения, которые можно условно разделить на две категории: решения, нацеленные на сеть, и решения, нацеленные на конечные точки. Эти два типа решений часто дополняют друг друга. Иногда проблема возникает из-за сочетания быстрых и медленных сетевых путей.
Сетевые решения обычно принимают форму алгоритмов управления очередью. Решение этого типа было в центре внимания рабочей группы IETF AQM. Известные примеры включают:
Примечательными примерами решений, нацеленных на конечные точки, являются:
Проблема также может быть уменьшена за счет уменьшения размера буфера в ОС и сетевом оборудовании; однако это часто невозможно настроить, и оптимальный размер буфера зависит от скорости линии, которая может отличаться для разных пунктов назначения.
DiffServ не решает и не может избежать проблемы с буферным заполнением, поскольку при возникновении проблемы затрагиваются все пакеты.
