Короткий итог по ограничению скорости
В то время как шейпинг откладывает трафик при превышении, полисинг его отбрасывает.
Шейпинг не подходит для приложений, чувствительных к задержкам и джиттеру. Для реализации полисинга в железе используется алгоритм 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. Сложнейшая система с многочисленными движущимися частями.
Всё хорошо (правда ведь?) звучало до сих пор, но что же творится под ванильной внешней панелью маршрутизатора?
Годами вендоры добавляли всё новые и новые конутры, разрабатывали сложнейшие чипы, расширяли буферы, чтобы с одной стороны поспевать за растущим объёмом трафика и новыми его категориями, а с другой, решать нарастающий проблемы, вызываемые первым пунктом.
Непрекращающаяся гонка. Нельзя терять пакеты, если конкурент их не теряет. Нельзя отказаться от функционала, если соперник стоит с ним под дверями заказчика. Айда в логово проприетарщины!
Last updated