Skip to content

Latest commit

 

History

History
32 lines (21 loc) · 4.21 KB

5-korotkii-itog-po-ogranicheniyu-skorosti.md

File metadata and controls

32 lines (21 loc) · 4.21 KB

Короткий итог по ограничению скорости

В то время как шейпинг откладывает трафик при превышении, полисинг его отбрасывает.

Шейпинг не подходит для приложений, чувствительных к задержкам и джиттеру.
Для реализации полисинга в железе используется алгоритм Token Bucket, для шейпинга — Leaky Bucket.
Token Bucket может быть:

  • С одним ведром — Single Rate — Two Color Marking. Позволяет допустимые всплески.

  • С двумя вёдрами — Single Rate — Three Color Marking (sr-TCM). Излишки из ведра C (CBS) пересыпаются в ведро E. Позволяет допустимые и избыточные всплески.

  • С двумя вёдрами — Two Rate — Three Color Marking (tr-TCM). Вёдра C и P (PBS) пополняются независимо с разными скоростями. Позволяет пиковую скорость и допустимые и избыточные всплески.

    sr-TCM сфокусирован на объёме трафика сверх лимита. tr-TCM — на скорости, с которой он поступает.
    Полисинг может использоваться на входе и на выходе с устройства. Шейпинг преимущественно на выходе
    Для PHB CS и EF используется Single Rate Two Color Marking.
    Для AF — sr-TCM или tr-TCM.

    Для, возможно, лучшего понимания рекомендую обратиться к оригинальным RFC или почитать тут.

Механизм Token Bucket вполне применим и в быту. Например, если я иду с друзьями в бар, в то время, как жена проводит время с двумя детьми, то каждую минуту из ведра вынимается токен.
Если я вычерпаю всё ведро, то на выходных не могу пойти на пробежку — жду, пока накапает. Если токенов мало, то часок побегать можно, а вот уехать на выходной на работу, чтобы заняться статьёй — уже нет.
Правда рейт наполнения ведра не постоянный, токены выделяются за добрые дела. На самом деле здесь система из двух связанных ведёр — моего и жены. Но так можно и на целую статью материала написать.

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

Всё хорошо (правда ведь?) звучало до сих пор, но что же творится под ванильной внешней панелью маршрутизатора?

Годами вендоры добавляли всё новые и новые конутры, разрабатывали сложнейшие чипы, расширяли буферы, чтобы с одной стороны поспевать за растущим объёмом трафика и новыми его категориями, а с другой, решать нарастающий проблемы, вызываемые первым пунктом.

Непрекращающаяся гонка. Нельзя терять пакеты, если конкурент их не теряет. Нельзя отказаться от функционала, если соперник стоит с ним под дверями заказчика.
Айда в логово проприетарщины!