Раздувание буфера

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

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

Феномен «буферного раздувания» был описан еще в 1985 году. ^[1] Начиная с 2009 года, он получил более широкое внимание. ^[2]

Согласно некоторым источникам, наиболее частой причиной высокой задержки («задержки») в онлайн-видеоиграх является раздувание буфера локальной домашней сети. Высокая задержка может сделать невозможными современные онлайн-игры. ^[3]

Буферизация [ править ]

Для производителей сетевого оборудования общепринятым эмпирическим правилом было предоставление буферов, достаточно больших, чтобы обеспечить длительность буферизации не менее 250 мс для потока трафика, проходящего через устройство. маршрутизатора Например, для интерфейса Gigabit Ethernet потребуется относительно большой буфер размером 32 МБ . ^[4] Такой размер буферов может привести к сбою алгоритма контроля перегрузки TCP . Затем буферам требуется некоторое время для опустошения, прежде чем контроль перегрузки сбрасывается, TCP-соединение снова набирает скорость и снова заполняет буферы. ^[5] Таким образом, раздувание буфера вызывает такие проблемы, как высокая и переменная задержка, а также перекрытие узких мест сети для всех других потоков, поскольку буфер заполняется пакетами одного потока TCP, а другие пакеты затем отбрасываются. ^[6]

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

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

Механизм [ править ]

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

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

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

Влияние на приложения [ править ]

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

Когда присутствует явление раздувания буфера и сеть находится под нагрузкой, даже обычная загрузка веб-страниц может занять много секунд, или простые DNS-запросы могут завершиться неудачно из-за тайм-аута. ^[10] На самом деле любое TCP-соединение может истечь и отключиться, а UDP-пакеты могут быть отброшены. Поскольку продолжение потока загрузки TCP зависит от пакетов подтверждения (ACK) в потоке загрузки, проблема раздувания буфера при загрузке может привести к сбою других несвязанных приложений загрузки, поскольку пакеты ACK клиента не достигают своевременно интернет-сервера.

Обнаружение [ править ]

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

Решения и меры по смягчению последствий [ править ]

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

Сетевые решения обычно принимают форму алгоритмов управления очередями. Этот тип решения был в центре внимания рабочей группы IETF AQM. ^[16] Яркие примеры включают:

Ограничение длины очереди IP, см. настройку TCP.
Алгоритмы AQM , такие как CoDel и PIE . ^[17]
Гибридные алгоритмы AQM и планирования пакетов, такие как FQ-CoDel . ^[18]
Поправки к DOCSIS стандарту ^[19] чтобы обеспечить более разумное управление буфером в кабельных модемах . ^[10]
Интеграция управления очередями ( FQ-CoDel ) в Wi-Fi подсистему операционной системы Linux , поскольку Linux обычно используется в точках беспроводного доступа . ^[20]

Яркими примерами решений, ориентированных на конечные точки, являются:

Алгоритм управления перегрузкой BBR для TCP.
Протокол Micro Transport, используемый многими клиентами BitTorrent .
Методы использования меньшего количества соединений, такие как конвейерная обработка HTTP или HTTP/2 вместо простого протокола HTTP. ^[10]

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

Использование DiffServ (и использование нескольких очередей на основе приоритетов) помогает расставить приоритеты для передачи трафика с низкой задержкой (например, VoIP, видеоконференции, игры), перекладывая работу с перегрузкой и раздуванием буфера на трафик без приоритета. ^[21]

Оптимальный размер буфера [ править ]

Чтобы TCP-соединения с самой длинной задержкой по-прежнему получали свою долю пропускной способности, размер буфера должен быть как минимум произведением задержки полосы пропускания, деленным на квадратный корень из числа одновременных потоков. ^[22]^[4] Типичное эмпирическое правило — 50 мс данных о скорости линии. ^[23] но некоторые популярные переключатели потребительского класса имеют время всего 1 мс, ^[24] что может привести к дополнительной потере пропускной способности на соединениях с более длительной задержкой в случае локального конфликта с другими.

См. также [ править ]

Ссылки [ править ]

^ «О пакетных коммутаторах с бесконечным хранилищем» . 31 декабря 1985 года.
^ ван Бейнум, Ильич (7 января 2011 г.). «Понимание раздутия буферов и гонки вооружений в области сетевых буферов» . Арс Техника . Проверено 12 ноября 2011 г.
^ «Bufferbloat: темные буферы в Интернете: сети без эффективного AQM могут снова оказаться уязвимыми к коллапсу перегрузки» . Очередь . дои : 10.1145/2063166.2071893 . S2CID 18820360 .
↑ Перейти обратно: Перейти обратно: ^а ^б Гвидо Аппенцеллер; Исаак Кесласси; Ник МакКаун (2004). «Определение размеров буферов маршрутизатора» (PDF) . ACM SIGCOMM . АКМ . Проверено 15 октября 2013 г.
^ Николс, Кэтлин ; Джейкобсон, Ван (6 мая 2012 г.). «Управление задержкой очереди» . Очередь АКМ . Издательство АКМ . Проверено 27 сентября 2013 г.
^ Геттис, Джим (май – июнь 2011 г.), Bufferbloat: Dark Buffers in the Internet , IEEE Internet Computing, vol. 15, IEEE, стр. 95–96, doi : 10.1109/MIC.2011.56 , заархивировано из оригинала 12 октября 2012 г. , получено 20 февраля 2012 г.
^ «traceroute(8) — справочная страница Linux» . сайт die.net . Проверено 27 сентября 2013 г.
^ Джейкобсон, Ван; Карелс, MJ (1988). «Предотвращение и контроль перегрузок» (PDF) . Обзор компьютерных коммуникаций ACM SIGCOMM . 18 (4): 314–329. дои : 10.1145/52325.52356 . Архивировано из оригинала (PDF) 22 июня 2004 г.
^ «Техническое введение в Bufferbloat» . Bufferbloat.net . Проверено 27 сентября 2013 г.
↑ Перейти обратно: Перейти обратно: ^а ^б ^с ^д Геттис, Джим; Николс, Кэтлин (январь 2012 г.). «Bufferbloat: темные буферы в Интернете» . Коммуникации АКМ . 55 (1). АКМ: 57–65. дои : 10.1145/2063176.2063196 .
^ «Тест скорости — насколько быстрый у вас интернет?» . dslreports.com . Проверено 26 октября 2017 г.
^ «ИКСИ Нетализатор» . Беркли.edu . Архивировано из оригинала 7 апреля 2019 года . Проверено 30 января 2015 г.
^ «Понимание результатов Netalyzr» . Проверено 26 октября 2017 г.
^ «Тесты на Bufferbloat» . ufferbloat.net . Проверено 26 октября 2017 г. ^{[ самостоятельный источник ]}
^ «Введение в Bufferbloat» . ufferbloat.net . Проверено 8 мая 2023 г.
^ «Рабочая группа IETF AQM» . ietf.org . Проверено 26 октября 2017 г.
^ Пан, Ронг; Натараджан, Прити; Пильоне, Кьяра; Прабху, Митхили; Субраманиан, Виджай; Бейкер, Фред; ВерСтиг, Билл (2013). «PIE: облегченная схема управления для решения проблемы раздувания буфера». 2013 IEEE 14-я Международная конференция по высокопроизводительной коммутации и маршрутизации (HPSR) . 2013 г., 14-я Международная конференция IEEE по высокопроизводительной коммутации и маршрутизации (HPSR). IEEE. стр. 148–155. дои : 10.1109/HPSR.2013.6602305 . ISBN 978-1-4673-4620-7 .
^ Хойланд-Йоргенсен, Токе; Маккенни, Пол; Так, Дэйв; Геттис, Джим; Дюмазе, Эрик. Планировщик пакетов FlowQueue-CoDel и алгоритм управления активной очередью . дои : 10.17487/RFC8290 . РФК 8290 .
^ «Функция DOCSIS «Управление восходящим буфером»» . Кабельные лаборатории. стр. 554–556 . Проверено 9 августа 2012 г.
^ Хойланд-Йоргенсен, Токе; Казиор, Михал; Тяхт, Дэйв; Хуртиг, Пер; Брунстрем, Анна (2017). Покончив с аномалией: достижение низкой задержки и справедливости эфирного времени в Wi-Fi . Ежегодная техническая конференция USENIX 2017 (USENIX ATC 17). USENIX — Ассоциация передовых вычислительных систем. стр. 139–151. ISBN 978-1-931971-38-6 . Проверено 28 сентября 2017 г. исходный код .
^ Хейн, Матиас. «Bufferbloat » Журнал ADMIN» . Журнал АДМИН . Проверено 11 июня 2020 г.
^ Хьюстон, Джефф (12 декабря 2019 г.). «Размер буфера» . Блог APNIC . Проверено 16 октября 2022 г.
^ «Проблемы с размером буфера маршрутизатора/коммутатора» . fastdata.es.net . Проверено 16 октября 2022 г.
^ «BCM53115» . www.broadcom.com . Проверено 16 октября 2022 г.

Внешние ссылки [ править ]

BufferBloat: Что не так с Интернетом? Беседа с Винтом Серфом , Ван Джейкобсоном , Ником Уивером и Джимом Геттисом.
Google Tech Talk на YouTube , апрель 2011 г., Джим Геттис, введение Винта Серфа.
Bufferbloat: темные буферы в Интернете — только демонстрации на YouTube , апрель 2011 г., Джим Геттис , введение Винта Серфа
Bufferbloat: темные буферы в Интернете — демонстрации и обсуждения на YouTube 21-минутная демонстрация и объяснение типичного широкополосного раздувания буфера
LACNIC — BufferBloat на YouTube , май 2012 г., автор Фред Бейкер (председатель IETF) на испанском языке, доступны слайды на английском языке [1]
Определение размера TSO и планировщик FQ (Джонатан Корбет, LWN.net )

[1] «О пакетных коммутаторах с бесконечным хранилищем» . 31 декабря 1985 года.

[Ars_Understanding-2] ван Бейнум, Ильич (7 января 2011 г.). «Понимание раздутия буферов и гонки вооружений в области сетевых буферов» . Арс Техника . Проверено 12 ноября 2011 г.

[3] «Bufferbloat: темные буферы в Интернете: сети без эффективного AQM могут снова оказаться уязвимыми к коллапсу перегрузки» . Очередь . дои : 10.1145/2063166.2071893 . S2CID 18820360 .

[:0-4] Перейти обратно: Перейти обратно: ^а ^б Гвидо Аппенцеллер; Исаак Кесласси; Ник МакКаун (2004). «Определение размеров буферов маршрутизатора» (PDF) . ACM SIGCOMM . АКМ . Проверено 15 октября 2013 г.

[codel-acmq-5] Николс, Кэтлин ; Джейкобсон, Ван (6 мая 2012 г.). «Управление задержкой очереди» . Очередь АКМ . Издательство АКМ . Проверено 27 сентября 2013 г.

[6] Геттис, Джим (май – июнь 2011 г.), Bufferbloat: Dark Buffers in the Internet , IEEE Internet Computing, vol. 15, IEEE, стр. 95–96, doi : 10.1109/MIC.2011.56 , заархивировано из оригинала 12 октября 2012 г. , получено 20 февраля 2012 г.

[7] «traceroute(8) — справочная страница Linux» . сайт die.net . Проверено 27 сентября 2013 г.

[8] Джейкобсон, Ван; Карелс, MJ (1988). «Предотвращение и контроль перегрузок» (PDF) . Обзор компьютерных коммуникаций ACM SIGCOMM . 18 (4): 314–329. дои : 10.1145/52325.52356 . Архивировано из оригинала (PDF) 22 июня 2004 г.

[9] «Техническое введение в Bufferbloat» . Bufferbloat.net . Проверено 27 сентября 2013 г.

[acm-10] Перейти обратно: Перейти обратно: ^а ^б ^с ^д Геттис, Джим; Николс, Кэтлин (январь 2012 г.). «Bufferbloat: темные буферы в Интернете» . Коммуникации АКМ . 55 (1). АКМ: 57–65. дои : 10.1145/2063176.2063196 .

[11] «Тест скорости — насколько быстрый у вас интернет?» . dslreports.com . Проверено 26 октября 2017 г.

[12] «ИКСИ Нетализатор» . Беркли.edu . Архивировано из оригинала 7 апреля 2019 года . Проверено 30 января 2015 г.

[13] «Понимание результатов Netalyzr» . Проверено 26 октября 2017 г.

[14] «Тесты на Bufferbloat» . ufferbloat.net . Проверено 26 октября 2017 г. ^{[ самостоятельный источник ]}

[15] «Введение в Bufferbloat» . ufferbloat.net . Проверено 8 мая 2023 г.

[ietf-aqm-16] «Рабочая группа IETF AQM» . ietf.org . Проверено 26 октября 2017 г.

[PIE-17] Пан, Ронг; Натараджан, Прити; Пильоне, Кьяра; Прабху, Митхили; Субраманиан, Виджай; Бейкер, Фред; ВерСтиг, Билл (2013). «PIE: облегченная схема управления для решения проблемы раздувания буфера». 2013 IEEE 14-я Международная конференция по высокопроизводительной коммутации и маршрутизации (HPSR) . 2013 г., 14-я Международная конференция IEEE по высокопроизводительной коммутации и маршрутизации (HPSR). IEEE. стр. 148–155. дои : 10.1109/HPSR.2013.6602305 . ISBN 978-1-4673-4620-7 .

[fq-codel-18] Хойланд-Йоргенсен, Токе; Маккенни, Пол; Так, Дэйв; Геттис, Джим; Дюмазе, Эрик. Планировщик пакетов FlowQueue-CoDel и алгоритм управления активной очередью . дои : 10.17487/RFC8290 . РФК 8290 .

[docsis-19] «Функция DOCSIS «Управление восходящим буфером»» . Кабельные лаборатории. стр. 554–556 . Проверено 9 августа 2012 г.

[linux-wifi-20] Хойланд-Йоргенсен, Токе; Казиор, Михал; Тяхт, Дэйв; Хуртиг, Пер; Брунстрем, Анна (2017). Покончив с аномалией: достижение низкой задержки и справедливости эфирного времени в Wi-Fi . Ежегодная техническая конференция USENIX 2017 (USENIX ATC 17). USENIX — Ассоциация передовых вычислительных систем. стр. 139–151. ISBN 978-1-931971-38-6 . Проверено 28 сентября 2017 г. исходный код .

[21] Хейн, Матиас. «Bufferbloat » Журнал ADMIN» . Журнал АДМИН . Проверено 11 июня 2020 г.

[22] Хьюстон, Джефф (12 декабря 2019 г.). «Размер буфера» . Блог APNIC . Проверено 16 октября 2022 г.

[23] «Проблемы с размером буфера маршрутизатора/коммутатора» . fastdata.es.net . Проверено 16 октября 2022 г.

[24] «BCM53115» . www.broadcom.com . Проверено 16 октября 2022 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]