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