ѕодпишитесь на наш Telegram-канал Ѕудьте в курсе последних новостей 👇 😉 ѕодписатьс€
ѕоддержим в трудное врем€ —пециальное предложение на техническую поддержку вашей »“ - инфраструктуры силами наших экспертов ѕодобрать тариф
ѕоставка оборудовани€ √аранти€ и помощь с настройкой. —кидка дл€ наших читателей по промокоду WIKIMERIONET  упить
»нтерфейс статистики Merion Mertics показывает ключевые диаграммы и графики по звонкам, а также историю звонков в формате, который легко поймет менеджер ѕопробовать бесплатно
¬недрение
офисной телефонии
Ўаг на пути к созданию доступных унифицированных коммуникаций в вашей компании ¬недрить
»нтеграци€ с CRM ѕомогаем навести пор€док с данными
и хранить их в единой экосистеме
ѕодключить
»“ Ѕезопасность ”мна€ информационна€ безопасность дл€ вашего бизнеса «аказать
ћерион Ќетворкс

8 минут чтени€

Ѕуферизаци€ пакетов дл€ работы с перегруженным интерфейсом кажетс€ прекрасной идеей. ƒействительно, буферы необходимы дл€ обработки трафика, поступающего слишком быстро или несоответстви€ скорости интерфейса - например, при переходе от высокоскоростной LAN к низкоскоростной WAN. ƒо сих пор это обсуждение QoS было сосредоточено на классификации, приоритизации и последующей пересылке пакетов, помещенных в очередь в этих буферах, в соответствии с политикой. ћаксимально большой размер буферов кажетс€ хорошей идеей. “еоретически, если размер буфера достаточно велик, чтобы поставить в очередь пакеты, превышающие размер канала, все пакеты в конечном итоге будут доставлены. ќднако, как большие, так и переполненные буферы создают проблемы, требующие решени€.

”правление очеред€ми и буферизаци€?

 огда пакеты наход€тс€ в буфере, они задерживаютс€. Ќекоторое количество микросекунд или даже миллисекунд добавл€етс€ к пути пакета между источником и местом назначени€, пока они наход€тс€ в буфере, ожида€ доставки. «адержка перемещени€ €вл€етс€ проблемой дл€ некоторых сетевых разговоров, поскольку алгоритмы, используемые TCP, предполагают предсказуемую и в идеале небольшую задержку между отправителем и получателем.

¬ разделе активного управлени€ очередью вы найдете различные методы управлени€ содержимым очереди. Ќекоторые методы решают проблему переполненной очереди, отбрасыва€ достаточно пакетов, чтобы оставить немного места дл€ вновь поступающих. ƒругие методы решают проблему задержки, поддержива€ небольшую очередь, минимизиру€ врем€, которое пакет проводит в буфере. Ёто сохран€ет разумную задержку буферизации, позвол€€ TCP регулировать скорость трафика до скорости, соответствующей перегруженному интерфейсу.


”правление переполненным буфером: взвешенное произвольное раннее обнаружение (WRED)

ѕроизвольное раннее обнаружение (RED) помогает нам справитьс€ с проблемой переполненной очереди. Ѕуферы не бесконечны по размеру: каждому из них выделено определенное количество пам€ти.  огда буфер заполн€етс€ пакетами, новые поступлени€ отбрасываютс€. Ёто не сулит ничего хорошего дл€ критического трафика, такого как VoIP, от которого нельз€ отказатьс€, не повли€в на взаимодействие с пользователем. —пособ решени€ этой проблемы - убедитьс€, что буфер никогда не будет полностью заполнен. ≈сли буфер никогда не заполн€етс€ полностью, то всегда есть место дл€ приема дополнительного трафика.

„тобы предотвратить переполнение буфера, RED использует схему упреждающего отбрасывани€ выбранного вход€щего трафика, оставл€€ места открытыми. „ем больше заполн€етс€ буфер, тем больше веро€тность того, что вход€щий пакет будет отброшен. RED €вл€етс€ предшественником современных вариантов, таких как взвешенное произвольное раннее обнаружение (WRED). WRED учитывает приоритет вход€щего трафика на основе своей отметки. “рафик с более высоким приоритетом будет потер€н с меньшей веро€тностью. Ѕолее веро€тно, что трафик с более низким приоритетом будет отброшен. ≈сли трафик использует какую-либо форму оконного транспорта, например, такую как TCP, то эти отбрасывани€ будут интерпретироватьс€ как перегрузка, сигнализирующа€ передатчику о замедлении.

RED и другие варианты также решают проблему синхронизации TCP. Ѕез RED все вход€щие хвостовые пакеты отбрасываютс€ при наличии переполненного буфера. ƒл€ трафика TCP потер€ пакетов в результате отбрасывани€ хвоста приводит к снижению скорости передачи и повторной передаче потер€нных пакетов.  ак только пакеты будут доставлены снова, TCP попытаетс€ вернутьс€ к более высокой скорости. ≈сли этот цикл происходит одновременно во многих разных разговорах, как это происходит в сценарии с отключением RED-free, интерфейс может испытывать колебани€ использовани€ полосы пропускани€, когда канал переходит от перегруженного (и сбрасывани€ хвоста) к незагруженному и недоиспользованному, поскольку все д throttled-back TCP разговоры начинают ускор€тьс€.  огда уже синхронизированные TCP-разговоры снова работают достаточно быстро, канал снова становитс€ перегруженным, и цикл повтор€етс€.

RED решает проблему синхронизации TCP, использу€ случайность при выборе пакетов дл€ отбрасывани€. Ќе все TCP-разговоры будут иметь отброшенные пакеты. “олько определенные разговоры будут иметь отброшенные пакеты, случайно выбранные RED. TCP-разговоры, проход€щие через перегруженную линию св€зи, никогда не синхронизируютс€, и колебани€ избегаютс€. »спользование каналов св€зи более устойчиво.


”правление задержкой буфера, Bufferbloat и CoDel

«десь может возникнуть очевидный вопрос. ≈сли потер€ пакетов - это плохо, почему бы не сделать буферы достаточно большими, чтобы справитьс€ с перегрузкой? ≈сли буферы больше, можно поставить в очередь больше пакетов, и, возможно, можно избежать этой досадной проблемы потери пакетов. ‘актически, эта стратеги€ больших буферов нашла свое применение в различных сетевых устройствах и некоторых схемах проектировани€ сети. ќднако, когда перегрузка канала приводит к тому, что буферы заполн€ютс€ и остаютс€ заполненными, большой буфер считаетс€ раздутым. Ётот феномен так хорошо известен в сетевой индустрии, что получил название: bufferbloat.

Bufferbloat имеет негативный оттенок, потому что это пример слишком большого количества хорошего. Ѕуферы - это хорошо. Ѕуферы предоставл€ют некоторую свободу действий, чтобы дать пачке пакетов где-нибудь остатьс€, пока выходной интерфейс обработает их. ƒл€ обработки небольших пакетов трафика необходимы буферы с критическим компромиссом в виде введени€ задержки, однако превышение размера буферов не компенсирует уменьшение размера канала.  анал имеет определенную пропускную способность. ≈сли каналу посто€нно предлагаетс€ передать больше данных, чем он может передать, то он плохо подходит дл€ выполнени€ требуемой от него задачи. Ќикака€ буферизаци€ не может решить фундаментальную проблему пропускной способности сети.

”величение размера буфера не улучшает пропускную способность канала. ‘актически, посто€нно заполненный буфер создает еще большую нагрузку на перегруженный интерфейс. –ассмотрим несколько примеров, противопоставл€ющих протоколов Unacknowledged Datagram Protocol (UDP) и Transmission Control Protocol (TCP).

  1. ¬ случае VoIP-трафика буферизованные пакеты прибывают с опозданием. «адержка чрезвычайно мешает голосовой беседе в реальном времени. VoIP - это пример трафика, передаваемого посредством UDP через IP. UDP-трафик не подтверждаетс€. ќтправитель отправл€ет пакеты UDP, не беспоко€сь о том, доберутс€ ли они до места назначени€ или нет. ѕовторна€ передача пакетов не производитс€, если хост назначени€ не получает пакет UDP. ¬ случае с VoIP - здесь важно, пакет приходит воврем€ или нет. ≈сли это не так, то нет смысла передавать его повторно, потому что уже слишком поздно. —лушатели уже ушли. LLQ может прийти вам в голову как ответ на эту проблему, но часть проблемы - это слишком большой буфер. ƒл€ обслуживани€ большого буфера потребуетс€ врем€, вызывающее задержку доставки трафика VoIP, даже если LLQ обслуживает трафик VoIP. Ѕыло бы лучше отбросить VoIP-трафик, наход€щийс€ в очереди слишком долго, чем отправл€ть его с задержкой.
  2. ¬ случае большинства приложений трафик передаетс€ по протоколу TCP через IP, а не по протоколу UDP. TCP - протокол подтверждений. ќтправитель трафика TCP ожидает, пока получатель подтвердит получение, прежде чем будет отправлен дополнительный трафик. ¬ ситуации bufferbloat пакет находитс€ в переполненном, слишком большом буфере перегруженного интерфейса в течение длительного времени, задержива€ доставку пакета получателю. ѕолучатель получает пакет и отправл€ет подтверждение. ѕодтверждение пришло к отправителю с большой задержкой, но все же пришло. TCP не заботитс€ о том, сколько времени требуетс€ дл€ получени€ пакета, пока он туда попадает. », таким образом, отправитель продолжает отправл€ть трафик с той же скоростью через перегруженный интерфейс, что сохран€ет избыточный буфер заполненным и врем€ задержки увеличиваетс€. ¬ крайних случа€х отправитель может даже повторно передать пакет, пока исходный пакет все еще находитс€ в буфере. ѕерегруженный интерфейс, наконец, отправл€ет исходный буферизованный пакет получателю, а втора€ копи€ того же пакета теперь находитс€ в движении, что создает еще большую нагрузку на уже перегруженный интерфейс!

Ёти примеры демонстрируют, что буферы неподход€щего размера на самом деле не год€тс€. –азмер буфера должен соответствовать как скорости интерфейса, который он обслуживает, так и характеру трафика приложени€, который может проходить через него.

ќдна из попыток со стороны сетевой индустрии справитьс€ с большими буферами, обнаруженными вдоль определенных сетевых путей, - это контролируема€ задержка, или CoDel. CoDel предполагает наличие большого буфера, но управл€ет задержкой пакетов, отслежива€, как долго пакет находитс€ в очереди. Ёто врем€ известно, как врем€ пребывани€.  огда врем€ пребывани€ пакета превысило вычисленный идеал, пакет отбрасываетс€. Ёто означает, что пакеты в начале очереди-те, которые ждали дольше всего-будут отброшены до пакетов, наход€щихс€ в данный момент в хвосте очереди.

јгрессивна€ позици€ CoDel в отношении отбрасывани€ пакетов позвол€ет механизмам управлени€ потоком TCP работать должным образом. ѕакеты, доставл€емые с большой задержкой, не доставл€ютс€, а отбрасываютс€ до того, как задержка станет слишком большой. ќтбрасывание вынуждает отправител€ TCP повторно передать пакет и замедлить передачу, что очень желательно дл€ перегруженного интерфейса. —овокупный результат - более равномерное распределение пропускной способности дл€ потоков трафика, конкурирующих за интерфейс.

¬ ранних реализаци€х CoDel поставл€лс€ в устройства потребительского уровн€ без параметров. ѕредполагаютс€ определенные настройки по умолчанию дл€ »нтернета. ќни включают 100 мс или меньше времени двустороннего обмена между отправител€ми и получател€ми, а задержка 5 мс €вл€етс€ максимально допустимой дл€ буферизованного пакета. “ака€ конфигураци€ без параметров упрощает де€тельность поставщиков сетевого оборудовани€ потребительского уровн€. ѕотребительские сети €вл€ютс€ важной целью дл€ CoDel, поскольку несоответствие высокоскоростных домашних сетей и низкоскоростных широкополосных сетей вызывает естественную точку перегрузки.  роме того, сетевое оборудование потребительского уровн€ часто страдает от слишком большого размера буферов.