WikiDer > Bufferbloat

Bufferbloat

Bufferbloat является причиной высокого задержка в сети с коммутацией пакетов вызвано избытком буферизация из пакеты. Bufferbloat также может вызвать изменение задержки пакета (также известный как джиттер), а также уменьшают общую сеть пропускная способность. Когда маршрутизатор или же выключатель настроен на использование чрезмерно больших буферов, даже очень высокоскоростные сети могут стать практически непригодными для многих интерактивных приложений, таких как передача голоса по IP (VoIP), онлайн-игры, и даже обычный веб-серфинг.

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

Феномен буферного всплытия был описан еще в 1985 году.[1] Он получил более широкое внимание с 2009 года.[2]

Буферизация

Смотрите также: CoDel § Теоретические основы

Установленный практическое правило для производителей сетевого оборудования должно было предоставить буферы, достаточно большие, чтобы вместить как минимум 250РС буферизации потока трафика, проходящего через устройство. Например, маршрутизатор Гигабитный Ethernet интерфейс потребует относительно большого 32МБ буфер.[3] Такой размер буферов может привести к отказу Алгоритм контроля перегрузки TCP. Затем буферам требуется некоторое время для истощения, прежде чем будет сброшено управление перегрузкой, а TCP-соединение снова вернется к скорости и снова заполнит буферы.[4] Таким образом, Bufferbloat вызывает такие проблемы, как высокая и переменная задержка, а также блокирование узких мест сети для всех других потоков, поскольку буфер заполняется пакетами одного потока TCP, а другие пакеты затем отбрасываются.[5]

Раздутый буфер действует только тогда, когда этот буфер действительно используется. Другими словами, слишком большие буферы имеют разрушительный эффект только тогда, когда ссылка, которую они буферизуют, становится узким местом. Размер буфера, обслуживающего узкое место, можно измерить с помощью пинг утилита, предоставляемая большинством операционных систем. Во-первых, другой хост должен постоянно опрашиваться; затем следует несколько раз начать и несколько раз остановить загрузку с него в течение нескольких секунд. По задумке алгоритм предотвращения перегрузки TCP быстро заполняет узкое место на маршруте. Если загрузка (и выгрузка, соответственно) коррелирует с прямым и важным увеличением времени приема-передачи, о котором сообщает ping, то это демонстрирует, что буфер текущего узкого места в направлении загрузки (и загрузки, соответственно) раздувается. Поскольку увеличение времени приема-передачи вызвано буфером в узком месте, максимальное увеличение дает приблизительную оценку его размера в миллисекундах.[нужна цитата]

В предыдущем примере с помощью расширенного трассировка инструмент вместо простого пинга (например, MTR) не только продемонстрирует наличие раздутого буфера в узком месте, но также определит его местоположение в сети. Traceroute достигает этого, отображая маршрут (путь) и измеряя задержки передачи пакетов по сети. История маршрута записывается как время приема-передачи пакетов, полученных от каждого последующего хоста (удаленного узла) в маршруте (пути).[6]

Механизм

Смотрите также: Настройка TCP § Размер окна, и Медленный старт

Наиболее Контроль перегрузки TCP алгоритмы полагаются на измерение возникновения отбрасывания пакетов для определения доступных пропускная способность между двумя концами соединения. Алгоритмы ускоряют передачу данных до тех пор, пока не начнут выпадать пакеты, а затем снижают скорость передачи. В идеале они продолжают регулировать скорость передачи до тех пор, пока она не достигнет равновесной скорости соединения. Чтобы алгоритмы могли выбрать подходящую скорость передачи, обратная связь об отбрасывании пакетов должна происходить своевременно. С большим буфер который был заполнен, пакеты прибудут в пункт назначения, но с большей задержкой. Пакеты не были отброшены, поэтому TCP не замедляется после насыщения восходящей линии связи, дополнительно заполняя буфер. Новые поступающие пакеты отбрасываются только тогда, когда буфер полностью насыщен. Как только это произойдет, TCP может даже решить, что путь соединения изменился, и снова перейти к более агрессивному поиску новой рабочей точки.[7]

Перед отправкой пакеты помещаются в очередь в сетевом буфере; в проблемных ситуациях пакеты отбрасываются, только если буфер заполнен. На старых маршрутизаторах буферы были довольно маленькими, поэтому они быстро заполнялись, и поэтому пакеты начали падать вскоре после того, как канал стал насыщенным, поэтому протокол TCP мог регулироваться, и проблема не становилась очевидной. На новых маршрутизаторах буферы стали достаточно большими, чтобы хранить несколько секунд буферизованных данных. Для TCP может показаться, что перегруженный канал работает нормально по мере заполнения буфера. Алгоритм TCP не знает, что канал перегружен, и не начинает предпринимать корректирующих действий до тех пор, пока буфер окончательно не переполнится и пакеты не будут отброшены.

Все пакеты, проходящие через простой буфер, реализованный в виде единой очереди, будут испытывать аналогичную задержку, поэтому будет затронута задержка любого соединения, проходящего через заполненный буфер. Доступная полоса пропускания канала также может оказаться неиспользованной, поскольку некоторые быстрые пункты назначения могут не быть быстро достигнуты из-за того, что буферы забиты данными, ожидающими доставки в медленные пункты назначения. Эти эффекты ухудшают интерактивность приложений, использующих другие сетевые протоколы, включая UDP используется в чувствительных к задержкам приложениях, таких как VoIP и онлайн-игры.[8][самостоятельно опубликованный источник]

Влияние на приложения

Независимо от требований к полосе пропускания, на любой тип услуги, для которой требуется стабильно низкая задержка или передача без дрожания, может влиять bufferbloat. Примеры включают голосовые вызовы, онлайн-игры, видеочати другие интерактивные приложения, такие как мгновенное сообщение, потоковое радио, видео по запросу, и удаленный вход.

Когда присутствует явление буферного раздува и сеть находится под нагрузкой, даже обычная загрузка веб-страницы может занять много секунд, или простые запросы DNS могут завершиться ошибкой из-за тайм-аутов.[9] Собственно любой TCP соединение может тайм-аут и отключиться, и Пакеты UDP можно заблудиться. Поскольку продолжение потока загрузки TCP зависит от пакетов ACK в потоке загрузки, проблема с буферным разносом при загрузке может привести к сбою других не связанных приложений загрузки, потому что пакеты ACK не достигают своевременно Интернет-сервера. Вы можете, например, ограничить скорость передачи загрузки Один диск синхронизация, чтобы не беспокоить других Домашняя сеть пользователей.

Диагностические инструменты

DSL сообщает Speedtest[10] это простой в использовании тест, который включает оценку для буферной пустоты. ICSI Netalyzr[11] был еще одним онлайн-инструментом, который можно было использовать для проверки сетей на наличие буферной памяти вместе с проверкой многих других распространенных проблем конфигурации.[12] Служба была закрыта в марте 2019 года. На веб-сайте bufferbloat.net перечислены инструменты и процедуры для определения того, имеет ли соединение избыточную буферизацию, которая замедлит его.[13][самостоятельно опубликованный источник]

Решения и смягчения

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

Сетевые решения обычно имеют форму алгоритмов управления очередью. Этот тип решения был в центре внимания IETF Рабочая группа AQM.[14] Известные примеры включают:

Известные примеры решений, нацеленных на конечные точки:

Проблема также может быть уменьшена за счет уменьшения размера буфера в ОС.[9] и сетевое оборудование; однако это часто невозможно настроить, и оптимальный размер буфера зависит от скорости линии, которая может отличаться для разных пунктов назначения.

DiffServ не решает и не может избежать проблемы с раздутием буфера, так как при возникновении проблемы затрагиваются все пакеты.[19]

Смотрите также

Рекомендации

  1. ^ «На пакетных коммутаторах с бесконечным хранилищем». 31 декабря 1985 г.
  2. ^ ван Бейджнум, Ильич (7 января 2011 г.). «Понимание Bufferbloat и гонки вооружений сетевых буферов». Ars Technica. Получено 12 ноября, 2011.
  3. ^ Гвидо Аппенцеллер; Исаак Кеслассы; Ник МакКаун (2004). «Определение размера буферов маршрутизатора» (PDF). ACM SIGCOMM. ACM. Получено 15 октября, 2013.
  4. ^ Николс, Кэтлин; Якобсон, Ван (6 мая 2012 г.). «Контроль задержки очереди». Очередь ACM. ACM Publishing. Получено 27 сентября, 2013.
  5. ^ Геттис, Джим (май – июнь 2011 г.). «Bufferbloat: темные буферы в Интернете». Интернет-вычисления IEEE. IEEE. С. 95–96. Дои:10.1109 / MIC.2011.56. Архивировано из оригинал 12 октября 2012 г.. Получено 20 февраля, 2012.
  6. ^ "traceroute (8) - страница руководства Linux". die.net. Получено 27 сентября, 2013.
  7. ^ Якобсон, Ван; Карелс, MJ (1988). «Предотвращение и контроль перегрузок» (PDF). Обзор компьютерных коммуникаций ACM SIGCOMM. 18 (4). Архивировано из оригинал (PDF) 22 июня 2004 г.
  8. ^ «Техническое введение в Bufferbloat». Bufferbloat.net. Получено 27 сентября, 2013.
  9. ^ а б c d Геттис, Джим; Николс, Кэтлин (январь 2012 г.). «Bufferbloat: темные буферы в Интернете». Коммуникации ACM. 55 (1). ACM: 57–65. Дои:10.1145/2063176.2063196. Получено 28 февраля, 2012. Цитировать журнал требует | журнал = (помощь)
  10. ^ "Тест скорости - насколько быстро у вас интернет?". dslreports.com. Получено 26 октября, 2017.
  11. ^ «ИКСИ Нетализр». berkeley.edu. Архивировано из оригинал 7 апреля 2019 г.. Получено 30 января, 2015.
  12. ^ "Понимание ваших результатов Netalyzr". Получено 26 октября, 2017.
  13. ^ «Тесты на Bufferbloat». bufferbloat.net. Получено 26 октября, 2017.
  14. ^ «Рабочая группа IETF AQM». ietf.org. Получено 26 октября, 2017.
  15. ^ Пан, Ронг; Натараджан, Прити; Пильоне, Кьяра; Прабху, Мифили; Субраманиан, Виджай; Бейкер, Фред; Верстег, Билл (2013). PIE: упрощенная схема управления для решения проблемы буферной памяти. 2013 14-я Международная конференция IEEE по высокопроизводительной коммутации и маршрутизации (HPSR). IEEE. Дои:10.1109 / HPSR.2013.6602305.
  16. ^ Хойланд-Йоргенсен, Ток; Маккенни, Пол; Тахт, Дэйв; Геттис, Джим; Эрик Дюмазет (18 марта 2016 г.). «Планировщик пакетов FlowQueue-CoDel и алгоритм управления активной очередью». Получено 28 сентября, 2017.
  17. ^ "Функция управления буфером восходящего потока DOCSIS". CableLabs. стр. 554–556. Получено 9 августа, 2012.
  18. ^ Хойланд-Йоргенсен, Ток; Казиор, Михал; Тэхт, Дэйв; Хуртиг, Пер; Брюнстрем, Анна (2017). Преодоление аномалии: достижение низкой задержки и справедливости разговора в WiFi. Ежегодная техническая конференция USENIX 2017 (USENIX ATC 17). USENIX - Ассоциация передовых вычислительных систем. С. 139–151. ISBN 978-1-931971-38-6. Получено 28 сентября, 2017. исходный код.
  19. ^ Хайн, Матиас. "Bufferbloat» Журнал ADMIN ". Журнал ADMIN. Получено 11 июня, 2020.

внешняя ссылка