Что такое шейпинг трафика
Перейти к содержимому

Что такое шейпинг трафика

Что такое шейпинг в ИТ? Значение термина шейпинг

Шейпинг – это не только вид гимнастики. Термин шейпинг означает еще и ограничение пропускной способности канала для конкретного узла сети ниже технических возможностей канала до узла. Шейпинг обычно используют в качестве средства ограничения максимального потребления интернет-трафика со стороны сетевого узла.

Устройство или ПО, которое осуществляет ограничение скорости именуют шейпером.

Алгоритм шейпинга для сетей, которые работают с пакетами данных следующий:

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

Помогло? Делись!

Реклама:

Представляем
систему управления сайтами
NetCat

CMS NetCat — профессиональная коммерческая система управления Интернет-сайтами, один из лидеров на российском рынке веб-разработок.
Наша компания является сертифицированным партнером и рекомендуемым разработчиком сайтов на NetCat во Владивостоке.
В настоящее время большинство новых сайтов мы создаем на основе ее программной платформы.

Шейпинг (информатика)

Шейпинг — ограничение пропускной способности канала для отдельного узла сети ниже технических возможностей канала до узла. Шейпинг обычно используется как средство ограничения максимального потребления трафика со стороны узла сети.

Устройство (или программу), осуществляющую ограничение скорости называют шейпер.

Простейший алгоритм

Алгоритм шейпинга для сетей, работающих с пакетами (фреймами или другими PDU) данных, обычно заключается в создании очереди пакетов от клиента. В единицу времени пропускаются пакеты общим объёмом не более N байт (где N — выставленное ограничение). В случае, если объём передаваемых данных превышает выделенную клиенту пропускную способность и очередь заполнена, лишние пакеты не принимаются. За счёт ненулевого размера очереди в начале соединения возможно временное превышение ограничения по скорости.

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

См. также

  • Алгоритм текущего ведра (один из алгоритмов шейпинга)
  • cFosSpeed (один из коммерческих шейперов)
Это заготовка статьи о компьютерах. Вы можете помочь проекту, исправив и дополнив её.
Это примечание по возможности следует заменить более точным.
  • Найти и оформить в виде сносок ссылки на авторитетные источники, подтверждающие написанное.
  • Викифицировать статью.
  • Производительность компьютерных сетей
  • Управление компьютерной сетью

Wikimedia Foundation . 2010 .

Что такое шейпинг трафика

Авторские права © 2001-2007 Thomas M. Eastep

Авторские права © 2005 Arne Bernin & Thomas M. Eastep

Авторские права © 2007 Russian Translation: Grigory Mokhin

Этот документ разрешается копировать, распространять и/или изменять при выполнении условий лицензии GNU Free Documentation License версии 1.2 или более поздней, опубликованной Free Software Foundation; без неизменяемых разделов, без текста на верхней обложке, без текста на нижней обложке. Копия лицензии приведена по ссылке « GNU Free Documentation License » .

Содержание

Важно

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

Предупреждение

Иначе говоря, чтение только документации Shorewall не будет достаточным для понимания раскрываемых здесь тем.

Как минимум, потребуется обратиться к следующим дополнительным источникам:

  • LARTC HOWTO: http://www.lartc.org
  • Руководство по HTB: http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm
  • Некоторые документы с сайта http://www.netfilter.org/documentation/index.html#documentation-howto. Рекомендуем ознакомиться с очень хорошим руководством Оскара Андреассона.
  • Вывод команды man iptables

Введение

Начиная с версии 2.5.5 в Shorewall реализована встроенная поддержка управления трафиком и шейпинга трафика. В более ранних версиях эти возможности были ограниченными. Можно было использовать собственный сценарий tcstart (это можно и сейчас), но, за исключением файла tcrules, в файлах конфигурации Shorewall не была предусмотрена возможность определения классов и дисциплин очередей.

До сих пор поддержка управления трафиком является неполной, например, не поддерживаются все опции (и особенно различные алгоритмы очередей) из ядра Linux, но для большинства случаев она будет достаточной. Если у вас уже есть сценарий для управления трафиком, который вы собираетесь использовать и в будущем, то соответствующие инструкции приведены по ссылке ниже в этом документе. Для того чтобы это заработало, требуется включить поддержку управления трафиком в ядре и в Shorewall, как описано далее.

Управление трафиком и шейпинг трафика в Linux

В этом разделе кратко описано, как работает управление трафиком в Linux. Даже если этого должно быть достаточно для настройки управления трафиком в файлах конфигурации Shorewall, мы очень рекомендуем внимательно прочитать руководство Linux Advanced Routing and Shaping HOWTO. Во время написания этого документа текущей версией была 1.0.0.

Начиная с версии 2.2, в Linux реализованы полные возможности управления трафиком. Предусмотрены различные алгоритмы, которые применяются для приоритизации очередей пакетов, выходящих с интерфейса. Стандартный алгоритм называется pfifo, и, как следует из самого названия, это очередь типа первым пришел — первым ушел. Фактически при этом никакого управления трафиком не происходит, и если какое-то соединение забивает весь канал, то этот алгоритм не сможет этого предотвратить.

Для управления трафиком в Shorewall используются два алгоритма, HTB (иерархический набор маркеров) и SFQ (очередь с равноправным стохастическим упорядочением). SFQ использует простую схему: отслеживаются все соединения (tcp или udp), и трафик распределяется между ними. Обычно это работает хорошо. HTB позволяет определить набор классов, между которыми распределяется трафик. Для каждого класса можно указать минимальную и максимальную полосу пропускания, а сами классы упорядочить в иерархическую структуру, чтобы классы с меньшим приоритетом получали доступ к каналу только в том случае, если запросы более важных классы удовлетворены. Встроенные функции управления трафиком в Shorewall позволяют определить такие классы и указать для них полосу пропускания. Внутри самих классов используется SFQ, чтобы их различные внутренние потоки данных обрабатывались как равноправные.

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

Есть одно исключение. Если ограничить входящий трафик значением чуть меньшим, чем фактическая пропускная способность канала, то будет исключено образование очередей на другом конце соединения. Это бывает полезно, если управление потоком на другом конце канала невозможно, а сам он подключен к сети по более быстрому каналу, например, если вы подключены к провайдеру по кабельному модему или модему DSL, а маршрутизатор провайдера подключен к быстрому магистральному каналу. Поэтому, если отбрасывать слишком быстро приходящие пакеты, то основной протокол сможет это обнаружить и снизить скорость соединения. В TCP такой механизм встроен, в UDP не встроен, но протокол, работающий поверх UDP, может иметь такой механизм.

В таких случаях создание очередей будет иметь неприятные последствия, если есть пакеты, которые должны проходить в первую очередь, как, например, VoIP или ssh. Для таких соединений важно, чтобы пакеты проходили с минимальной задержкой. Для других пакетов, таких как загрузка по HTTP, задержка на несколько секунд не будет иметь значения.

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

Управление исходящим трафиком достигается посредством распределения потока пакетов по классам. Класс связан ровно с одним сетевым интерфейсом и имеет ряд атрибутов:

  1. PRIORITY — используется для указания приоритетов классов, к которым относятся отправляемые пакеты. Приоритет — это число, при этом 1 задаёт наивысший приоритет, 2 — следующий по важности и т.д.
  2. RATE — скорость, то есть минимальная гарантированная пропускная способность, которая должна обеспечиваться для класса, когда возрастает нагрузка на канал. Классы с более высоким приоритетом (меньшие значения PRIORITY) обслуживаются даже в том случае, если заданы другие классы с гарантированной пропускной способностью, но низшим приоритетом (большие значения PRIORITY).
  3. CEIL — ограничение, максимальная полоса пропускания, которая отводится для класса, когда канал свободен.
  4. MARK — метка. В Netfilter предусмотрены способы маркировки пакетов. Метки пакетов — это числа. В Shorewall они могут принимать значение от 1 до 255. Метки пакетов присваиваются различным типам пакетов согласно правилам, заданным в файле /etc/shorewall/tcrules .

Для каждого интерфейса необходимо задать один класс, который будет классом по умолчанию. К этому классу будут относиться непомеченные данные, то есть пакеты, для которых не задана метка в файле /etc/shorewall/tcrules .

Netfilter также поддерживает метки соединений. Метки соединений можно присвоить соединениям в правилах /etc/shorewall/tcrules , можно скопировать метку пакета в метку соединения (SAVE), или скопировать метку соединения в метку пакета (RESTORE).

Конфигурация ядра Linux

Для работы требуется ядро не ниже 2.4.18. На рисунке показаны опции ядра, которые необходимо включить. Для встроенной поддержки необходимы опции HTB scheduler, Ingress scheduler, PRIO pseudoscheduler и SFQ queue. Прочие планировщики или алгоритмы очередей необязательны.

Также требуются классификаторы u32 и fw из главного меню Networking Options (не показаны).

На следующем рисунке показано, как я настроил QoS у себя в ядре 2.6.13:

Конфигурация ядра изменилась в 2.6.16 — вот мои рекомендации.

Включение поддержки TC в Shorewall

Поддержку TC требуется включить независимо от того, применяются ли встроенные функции или вы используете собственный сценарий tcstart.

Для включения встроенных функций управления трафиком в Shorewall выполните следующее:

  • Задайте TC_ENABLED равным «Internal» в /etc/shorewall/shorewall.conf. Если TC_ENABLED=Yes, то Shorewall будет искать внешний файл tcstart (см. далее).
  • Если задать параметр CLEAR_TC в /etc/shorewall/shorewall.conf равным Yes, то при запуске, перезапуске и остановке Shorewall будет сбрасываться текущая конфигурация управления трафиком. Обычно именно это и требуется при работе с встроенными функциями, а также с собственным сценарием tcstart.
  • Следующие действия зависят от того, применяются ли встроенные функции или собственный сценарий. Подробнее это объясняется в следующих разделах.

Работа с встроенными функциями управления трафиком и шейпинга

Встроенные в Shorewall функции управления трафиком — это тонкая оболочка для очереди входящих пакетов (ingress qdisc), HTB и SFQ. Эта оболочка позволяет выполнить следующие задачи:

  • Определить классы HTB в файлах конфигурации Shorewall.
  • Включить загрузку конфигурации управления трафиком вместе с загрузкой правил фильтрации пакетов и правил для меток.
  • Распределить пакеты по классам HTB согласно значениям TOS.
  • Отнести исходящие пакеты TCP ACK к классу HTB.
  • Распределить пакеты по классам HTB согласно значениям меток пакетов.

Предупреждение

Встроенные в Shorewall функции управления трафиком ограничены десятью (10) устройствами.

Больше никаких задач встроенные функции управления трафиком не выполняют. Поэтому, чтобы их использовать, необходимо понимать, как работает HTB и управление трафиком в Linux, и как работают метки пакетов Netfilter. За дополнительной информацией обратитесь к ссылкам, приведенным в начале этого документа.

Для задания пропускной способности (как устройств, так и классов) используйте kbit или kbps (для килоБАЙТ в секунду) БЕЗ пробела между числом и единицей измерения (то есть 100kbit НО НЕ 100 kbit). Можно также использовать mbit, mbps или число (означающее байты), но поддерживаются только целые числа (0.5 использовать нельзя ).

Для того чтобы правильно настроить устройства, необходимо выяснить фактическую пропускную способность канала в обоих направлениях. Это особенно важно для соединений DSL или любых других, для которых пропускная способность канала не гарантирована. Не верьте числам, которые называет провайдер, но сами измерьте реальную скорость канала. В этом могут помочь различные утилиты в сети, попробуйте поискать «dsl speed test» в google (для Германии можно использовать arcor speed check). Найдите тест поближе к себе.

/etc/shorewall/tcdevices

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

Далее описаны столбцы файла:

  • INTERFACE — Имя интерфейса. Интерфейс может быть указан не более одного раза. Использовать псевдоним интерфейса (например, eth0:0) здесь нельзя, см. FAQ #18. Также нельзя использовать символы подстановки, например, если есть несколько интерфейсов ppp, то все их необходимо здесь перечислить. В версиях Shorewall до 3.0.8 и 3.2.0 Beta 8, устройство, имя которого указано в столбце, должно было существовать в момент запуска, перезапуска или обновления Shorewall. Начиная с версии 3.0.8 и 3.2.0 Beta 8 Shorewall может определить, существует ли устройство, и настроит его только в том случае, если оно существует. Если оно не существует, то будет показано следующее предупреждение: WARNING: Device not found — traffic-shaping configuration skipped
  • IN-BANDWIDTH — Пропускная способность входящего канала для этого интерфейса. Обратите внимание, что шейпинг входящего трафика невозможен, так как пакеты уже пришли. В этом столбце можно задать максимальную скорость, разрешенную для этого интерфейса, при превышении которой пакеты будут отбрасываться. Это полезно главным образом для соединений DSL или кабельных, чтобы избежать очередей в устройствах провайдера. Если не следует отбрасывать никакие пакеты, то укажите значение, превышающее фактическую максимальную скорость канала (в Shorewall начиная с версии 3.2.6 можно также указать 0). Для того чтобы определить оптимальное значение, укажите сначала значение, которое заведомо ниже, чем измеренная скорость канала (процентов на 20). Далее, в ходе загрузки файлов, измеряйте время ответа на ping между своей системой и маршрутизатором провайдера и постепенно увеличивайте это значение. Оптимальным будет значение, при превышении которого время ответа на ping будет резко расти.
  • OUT-BANDWIDTH — Пропускная способность исходящего канала для этого интерфейса. Это максимальная скорость, с которой может работать исходящее соединение. В терминах классов tc эта скорость называется полной (full). Превышающий эту скорость исходящий трафик будет отбрасываться.

Пример 1.

Предположим, что вы работаете с PPP по Ethernet (DSL), а интерфейс — это ppp0. Устройство имеет исходящую скорость 500 кбит и входящую — 6000 кбит

#INTERFACE IN-BANDWITH OUT-BANDWIDTH ppp0 6000kbit 500kbit

/etc/shorewall/tcclasses

В этом файле можно задать классы, по которым будет распределяться исходящий трафик.

  • INTERFACE — Имя интерфейса. Должно совпадать с именем интерфейса в файле /etc/shorewall/tcdevices .
  • MARK — метка. Должна быть целым числом от 1 до 255. Эти метки задаются в файле tcrules. Они помечают пакеты, которые тем самым будут отнесены к определенным здесь классам очередей. Одни и те же метки могут использоваться для разных интерфейсов.
  • RATE — скорость, то есть минимальная гарантированная пропускная способность, которая должна обеспечиваться для класса, когда возрастает нагрузка на канал. Классы с более высоким приоритетом обслуживаются даже в том случае, если заданы другие классы с гарантированной пропускной способностью, но низшим приоритетом. Если сумма значений RATE для всех классов, присвоенных интерфейсу, превышает OUT-BANDWIDTH для интерфейса, то предел OUT-BANDWIDTH не будет соблюдаться.
  • CEIL — ограничение, максимальная полоса пропускания, которая отводится для данного класса, когда канал свободен. Это полезно, если есть трафик, для которого будет выделяться полная скорость канала, если более важные службы (такие как ssh) не используются. Значение «full» означает, что максимальная пропускная способность для класса определяется значением, заданным для интерфейса.
  • PRIORITY — позволяет указать приоритет для класса. Пакеты из класса с более высоким приоритетом (то есть меньшим значением) будут обрабатываться раньше, чем пакеты с низшим приоритетом. Здесь можно просто указать значение метки, если метки присваиваются согласно приоритетам.
  • OPTIONS — Список параметров через запятую. Возможны следующие параметры:
  • default — класс по умолчанию для интерфейса, к которому будет отнесен весь трафик, не отнесенный к другим классам.

Примечание

Необходимо указать default ровно для одного класса для интерфейса.

Примечание

Каждая из этих опций применима только для одного класса интерфейса.

Примечание

Эта опция применима только для одного класса интерфейса.

/etc/shorewall/tcrules

Классификатор fwmark является удобным средством для классификации пакетов при управлении трафиком. В файле « /etc/shorewall/tcrules » эти метки представлены в виде таблицы. Глубже познакомиться с маркировкой пакетов в Netfilter/Shorewall позволяет этот документ.

Обычно метка пакета ставится в цепочке PREROUTING перед тем, как осуществляется замена адресов. При этом невозможно помечать входящие пакеты согласно их целевому адресу, если применяется SNAT или Masquerading. Тем не менее, можно осуществлять маркировку пакетов в цепочке FORWARD, если задать опцию MARK_IN_FORWARD_CHAIN в файле shorewall.conf.

Далее описаны столбцы файла:

  • MARK или CLASSIFY — MARK задает значение метки, которая присваивается пакету в случае совпадения с правилом. Она должна быть целым числом от 1 до 255. Вслед за этим значением может идти « : » и одно из значений: « F » , « P » или «T», которые обозначают соответственно маркировку в цепочках FORWARD, PREROUTING или POSTROUTING. Если эти дополнительные спецификаторы опущены, то цепочка, в которой осуществляется маркировка пакетов, определяется следующим образом:
  • Если SOURCE — это $FW[:< адрес >], то правило вставляется в цепочку OUTPUT.
  • В противном случае цепочка определяется по значению опции MARK_IN_FORWARD_CHAIN из файла shorewall.conf.

Примечание

Спецификатор «T» был добавлен в Shorewall версии 3.3.6 и недоступен в более ранних версиях.

Обычно метка присваивается пакету. Если вслед за меткой указать «:» и «C», то метка будет применяться к соединению. «C» можно сочетать с «F», «P» или «T», чтобы указать, что соединение следует пометить в определенной цепочке (например, «CF», «CP», «CT»).

Предусмотрены также следующие специальные значения:

  1. RESTORE [/ маска ] — восстановить метку пакета из метки соединения, используя маску, если она указана. Ядро и iptables должны поддерживать CONNMARK. Как и ранее, можно использовать дополнительные спецификаторы 😛 , :F или :T .
  2. SAVE [/ маска ] — сохранить метку пакета в метке соединения, используя маску, если она указана. Ядро и iptables должны поддерживать CONNMARK. Как и ранее, можно использовать дополнительные спецификаторы 😛 , :F или :T .
  3. CONTINUE — прекратить обработку дальнейших правил маркировки в таблице. Как и ранее, можно использовать дополнительные спецификаторы 😛 , :F или :T .
  4. COMMENT (Начиная с Shorewall версии 3.3.3) — остальной текст в строке будет добавлен как комментарий в правила Netfilter, генерируемые по следующим записям. Комментарий будет выделен символам «/* . */» в выводе команды shorewall show mangle Для того чтобы комментарий не применялся к последующим строкам, укажите COMMENT в отдельной строке.

При работе с CLASSIFY ядро и iptables должны поддерживать CLASSIFY. В этом случае в столбце будет содержаться классификатор (classid) в виде :, где и должны быть целыми числами. Он соответствует указанию ‘class’ в следующих модулях управления трафиком:

atm
cbq
dsmark
pfifo_fast
htb
prio

В версиях Shorewall до 3.2.3 правила классификации всегда помещались в цепочку POSTROUTING. Начиная с Shorewall версии 3.2.3 классификация осуществляется в цепочке POSTROUTING, кроме тех случаев , когда SOURCE содержит $FW[:< адрес >], для которых классификация осуществляется в цепочке OUTPUT. При работе со встроенными функциями управления трафиком класс — это номер устройства (первая запись в файле /etc/shorewall/tcdevices — это устройство 1, вторая — устройство 2 и т.д.), а класс — это значение MARK класса, перед которой стоит число «1» (для MARK со значением 1 класс — это 11, для MARK со значением 22 — класс 122, и т.д.).

joe # программа должна выполняться пользователем joe :kids # программа выполняется участниками группы 'kids' !:kids # программа выполняется участниками группы 'kids' +upnpd # программа upnpd (эта функция была удалена из Netfilter в версии ядра 2.6.14).
! Обратное соответствие (не равно)
Значение метки соединения или пакета.
Маска, применяемая к метке перед сравнением
:C обозначает метку соединения. Если она не указана, то сравнивается метка пакета.
Minimize-Delay (16)
Maximize-Throughput (8)
Maximize-Reliability (4)
Minimize-Cost (2)
Normal-Service (0)

Пример 2.

Все пакеты, приходящие на eth1, должны иметь метку 1. Все пакеты, приходящие на eth2 и eth3, должны иметь метку 2. Все пакеты, созданные в системе файрвола, должны иметь метку 3.

#MARK SOURCE DESTINATION PROTOCOL PORT(S) 1 eth1 0.0.0.0/0 all 2 eth2 0.0.0.0/0 all 2 eth3 0.0.0.0/0 all 3 $FW 0.0.0.0/0 all

Пример 3.

Все пакеты GRE (протокол 47), не созданные в системе файрвола и имеющие целевой адрес 155.186.235.151, должны иметь метку 12.

#MARK SOURCE DESTINATION PROTOCOL PORT(S) 12 0.0.0.0/0 155.182.235.151 47

Пример 4.

Все пакеты SSH, приходящие с 192.168.1.0/24 и предназначенные для 155.186.235.151, должны иметь метку 22.

#MARK SOURCE DESTINATION PROTOCOL PORT(S) 22 192.168.1.0/24 155.182.235.151 tcp 22

Пример 5.

Все пакеты SSH, проходящие через первое устройство в файле /etc/shorewall/tcdevices, должны быть отнесены в класс с меткой 10.

#MARK SOURCE DESTINATION PROTOCOL PORT(S) CLIENT # PORT(S) 1:110 0.0.0.0/0 0.0.0.0/0 tcp 22 1:110 0.0.0.0/0 0.0.0.0/0 tcp - 22

Пример 6.

Все пакеты echo ICMP должны иметь метку 1. Весь трафик протоколов p2p должен иметь метку 4.

Это чуть более сложный случай. Поскольку модуль ipp2p не в состоянии распознать все пакеты в соединении как пакеты P2P, то все соединение помечается как P2P, если совпадение найдено хотя бы для одного пакета. Предполагается, что метка пакета/соединения 0 означает неклассифицированные пакеты.

#MARK SOURCE DESTINATION PROTOCOL PORT(S) CLIENT USER/ TEST # PORT(S) GROUP 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 4 0.0.0.0/0 0.0.0.0/0 ipp2p:all SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0

Последние четыре правила означают следующее:

«Если пакет не был классифицирован (метка пакета 0), то скопировать метку соединения в метку пакета. Если метка пакета уже задана, то никаких действий более не требуется. Если пакет относится к типу P2P, то задать метку пакета 4. Если метка пакета задана, то сохранить ее в качестве метки соединения.»

Устройства ppp

Если подключение к провайдеру выполняется через ppp/pppoe/pppoa, и вы используете управление трафиком, то необходимо перезапустить управление трафиком shorewall. Причина этого состоит в том, что если соединение ppp перезапускается (обычно это происходит как минимум раз в день), то все фильтры и qdisc « tc » , связанные с этим интерфейсом, будут удалены.

Самым простым решением будет перезапуск shorewall при повторном установлении соединения. Для этого добавьте в сценарий « /etc/ppp/ip-up.d » следующую строку.

#! /bin/sh /sbin/shorewall refresh

Базовые принципы полисеров и шейперов

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

Тема качества обслуживания не самая простая для понимания, а если вы когда-нибудь интересовались именно полисерами и шейперами, то скорее всего встречали однотипные графики, отображающие зависимость скорости от времени, слышали термины «корзина», «токены» и «burst», может быть даже видели формулы для расчёта каких-то параметров. Хороший и типичный пример есть в СДСМ — глава про QoS и ограничение скорости.

В этой статье попробуем зайти чуть с другой стороны, опираясь на учебник Cisco, RFC 2697 и RFC 2698 — самые базовые понятия.

Первое в чём надо разобраться и на чём строится весь механизм управления скоростью — это понятие самой скорости. Скорость — величина производная, вычисляемая, нигде и ни в каком месте мы не видим её напрямую. Устройства оперируют только данными и их количеством. Про скорость мы говорим в контексте наблюдения и мониторинга, зная объём переданных данных за 5 минут или за 5 секунд и получая разные значения средней скорости.

Второе, количество данных пропускаемое интерфейсом за отрезок времени — константа, абсолют. Его нельзя ни уменьшить ни увеличить. Через 100Мбит/c интерфейс 90Мбит будут пропущены всегда за 0,9 секунды, а оставшуюся 0,1 секунду интерфейс будет простаивать. Но с учётом того что скорость вычисляемое значение, получим что данные были переданы со средней скоростью 90Мбит/c. Это мало похоже на дорожный трафик, у нас всегда либо 100% загруженность, либо полный простой. В контексте сетевого трафика, загруженность интерфейса — это сколько свободных промежутков времени у него остаётся из общего измеряемого интервала. Дальше продолжим употреблять размерность Мбит и секунды, для лучшего понимания, хотя это и не имеет никакого значения.

Отсюда вытекает основная задача и способ ограничения пропуска трафика — передать не больше заданного количества данных за единицу времени. Если у нас есть 100Мбит, а мы хотим ограничить скорость 50Мбит/c, то за эту секунду нам надо передать не больше 50Мбит, а оставшиеся данные передать в следующую секунду. При этом у нас есть только один способ это сделать — включить интерфейс, который всегда работает с постоянной скоростью, или выключить его. Выбор только в том, как часто мы будем включать и выключать.

Burst

Посмотрим на график скорости из учебника 5 класса по физике. Здесь показана зависимость объёма переданных данных по оси Y, от времени по оси X. Чем круче наклон прямой, тем больше скорость. Передать 50Мбит за секунду можно разными способами:

  1. Передать всё сразу за 0,5 секунды, а потом ждать следующей (зелёная сплошная)
  2. Передавать чаще, делая меньшие паузы, но увеличив их количество

Если burst=50, CIR=50Мбит/c, то время равно 1 секунде: Time Interval = Burst / CIR = 50/50 . Значит каждую секунду, мы можем передать не больше 50Мбит. Так как скорость интерфейса у нас 100Мбит/c, то 50Мбит будут переданы за 0,5 секунды, оставшееся время будет простой. Начиная со следующей секунды у нас опять будет возможность передать 50Мбит.

В случае burst=25, получим 25/50 или 0,5 секунды между передачей каждых 25Мбит. С учётом скорости интерфейса на передачу 25Мбит будет затрачено 25/100=0,25 секунды и следующие 0,25 секунды интерфейс будет простаивать. В каждом случае мы 1/2 = CIR / Interface rate времени тратим на передачу и 1/2 на простой. Если увеличить CIR до 75Мбит/c, то соответственно 75/100=3/4 периода займёт передача и 1/4 пауза.

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

В большинстве случаев при конфигурации оборудования используются именно burst, хотя могут использоваться и временные интервалы. На графике хорошо видны отличия, меньший burst даёт более строгое следование заданному ограничению — график не убегает далеко от СIR, даже на меньшем измеряемом промежутке и при этом обеспечивает короткие паузы между моментами передачи. А больший burst не ограничивает трафик на коротких отрезках. Если измерять скорость только за первые 0,5 секунды, то получилось бы 50/0,5 = 100Мбит/c. А долгая пауза после такой передачи может негативно сказаться на механизмах управления трафиком за границами нашего устройства, или привести к потере логического соединения.

Если быть ближе к реальности, сетевой трафик, как правило, не передаётся непрерывно, а имеет разную интенсивность в разные моменты времени (зелёный пунктир):

На этом графике видно, что за 1 секунду мы хотим передать 55Мбит при ограничении 50Мбит. То есть, реальный трафик практически не выходит за границы которые мы установили к концу измеряемого интервала. При этом механизмы ограничения приводят к тому, что передаётся меньший объём данных чем мы ожидаем. И здесь больший burst выглядит лучше, так как захватываются интервалы где трафик действительно передаётся, а меньший burst и желание строго ограничивать трафик на всём участке, выливается в большие потери.

Шейпер

Будем ещё ближе к реальности, в которой всегда имеется буфер для передачи данных. С учётом того что интерфейс у нас или занят на 100% или простаивает, а данные могут поступать одновременно из нескольких источников быстрее чем интерфейс может их передавать, то даже простейший буфер формирует очередь, позволяя данным дождаться момента передачи. Он также позволяет компенсировать те потери которые у нас могут возникнуть из-за введённых ограничений:

Policer это график Burst 5 с предыдущего изображения. Shaper тот же график Burst 5, но с учётом буфера, в котором задерживаются не успевшие передаться данные и которые могут быть переданы чуть позже.

В результате, мы полностью обеспечили наши требования по ограничению трафика «сгладив» пики источника и не потеряв данные. Трафик по-прежнему имеет пульсирующую форму: чередующиеся периоды передачи и паузы — потому что мы не можем повлиять на скорость интерфейса и управляем только объёмом передаваемых за раз данных. Это тот самый график сравнения шейпера и полисера из СДСМ QoS, но с другой стороны:

Какой ценой мы этого достигли? Ценой буфера, который не может быть бесконечным и который вносит задержку в передаче данных. Пик на графике буфера приходится на 15Мбит, это те данные которые теряются полисером, но задерживаются шейпером. При заданном ограничении 50Мбит/c — это 15/50=300 миллисекунд, что для многих сетевых приложений уже за гранью дозволенного.

А теперь посмотрим когда эта цена играет роль, достаточно лишь чуть большей интенсивности трафика — 60Мбит/c, при ограничении 50Мбит/c:

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

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

Корзина

Для учёта объёма трафика переданного через интерфейс используется понятие и термин корзина. Фактически, это счётчик от максимального значения burst до 0, который уменьшается с передачей каждого кванта данных — токена. Соответственно, есть два процесса — один наполняет корзину, второй из неё забирает.

Корзина наполняется до величины burst каждый заданный интервал, при известном CIR. Для burst 5 и CIR 50, каждые 0,1 секунду, как было рассчитано чуть ранее. Но объём трафика за интервал времени может быть меньше чем заданный нами burst, так как условие ограничения — «не больше». Значит этот счётчик может не доходить до 0 и в корзине остаются токены. Тогда в следующий интервал, при заполнении корзины, неиспользуемый объём данных (токенов) будет потерян.

Такая ситуация видна на графике Policer выше, каждые 0,05 секунд мы в состоянии передать 5Мбит на скорости интерфейса, но количества данных которые у нас есть всего 3Мбит, так как скорость поступления данных всего 60Мбит/c. Именно поэтому график почти сливается с CIR, что не совсем корректно. Передача в любом случае осуществляется на скорости интерфейса и 3Мбит будут переданы за 0,03 секунды, а оставшиеся 0,02 будет пауза. Это давало бы нам характерную лесенку, которую мы видим на графике Shaper. Здесь, как раз, пример средней скорости и сглаживания точности измерения, что обычно показывают системы мониторинга оперирующие даже не секундами, а минутами.

Улучшим подход, зная что трафик спонтанен и больший burst может помочь не потерять данные. Введём ещё одну корзину, куда будем складывать неиспользованные на предыдущем интервале токены. Таким образом, в случае отсутствия трафика от источника, будет частично компенсироваться этот простой, как если бы у нас был больший burst. Для каждой корзины задаётся собственный burst, для основной — Committed Burst, CBS, Bc. А для второй — Excess Burst, EBS, Be. Таким образом максимальный объём данных который может быть непрерывно передан равен CBS+EBS.

Shaper Exs (жёлтый) — график с учётом двух корзин, каждая объёмом burst в 5Мбит. Shaper — график с предыдущего изображения. Теперь максимальный burst=EBS+CBS=10 и первые 0,1 секунду мы используем его. Основную корзину мы пополняем каждые 5/50=0,1 секунду. Соответственно, в момент времени 0,1 опять есть возможность передавать данные и период непрерывной передачи длится 0,15 секунды. В результате длительного простоя, когда трафика с источника не было и все данные из буфера мы передали, в момент времени 0,6 секунд, добавляем неиспользуемый объём данных во вторую корзину. Таким образом, получаем возможность снова вести непрерывный пропуск трафика в течение 0,15 секунд, что позволяет вовсе не использовать буфер. В итоге, получили удачный компромисс точности нарезки полосы, в случае интенсивного трафика, и лояльности в отношении всплесков при использовании большего burst.

Сделаем ещё одно улучшение касающееся времени. Избавимся от периодического процесса пополнения корзины и заменив его на пополнение только в те моменты, в которые к нам поступают данные. В большинстве случаев, меньше чем одним, целым пакетом за раз никто не оперирует. Поэтому можно посчитать период между приходами последовательных пакетов и пополнять корзину тем объёмом данных, которые соответствуют данному периоду. Это, во первых, исключит необходимость держать отдельный таймер для временных интервалов связанных с burst периодами, а во вторых, сократит периоды между возможными пропусками трафика.

Следовательно burst, как максимальный объём непрерывно передаваемых данных, отделился от понятия количество пополняемых за раз данных, хотя формула осталась та же: пополняемый объём в токенах = интервал между последовательными пакетами * CIR . Но пополнить корзину больше чем её максимальный объём burst мы не можем, это то условие с помощью которого и достигается ограничение. Размер пакета задаёт наименьший из возможных burst — размер наименьшего пакета в данной сетевой технологии. Если burst будет меньше, то целый пакет невозможно будет отправить за отведённый интервал, при заданной скорости интерфейса.

Полисер: 1 скорость, 2 корзины, 3 цвета

До этого речь шла, в основном, о шейперах, хотя понятия и термины аналогичны тем что применимы и для полисеров. Полисер, однако, как это определено в RFC 2697 это не механизм ограничения трафика, это механизм его классификации. Каждый проходящий пакет, в соответствии с заданным CIR, CBS и EBS относится к одной из категорий (цвету): conform (green), exceed (yellow), violate (red). На устройствах можно сразу настроить в каком случае трафик стоит блокировать, но в общем случае, это именно назначение метки или покраска.

Для каждого пакета происходит проверка по следующему алгоритму:

  1. Если размер пакета меньше чем токенов в первой корзине, то этот пакет помечается как green, а из первой корзины вычитается количество токенов соответствующих размеру пакета, иначе
  2. Если размер пакета меньше чем токенов во второй Excess корзине, то этот пакет помечается как yellow, а из второй корзины вычитается количество токенов соответствующих размеру пакета, иначе
  3. Пакет помечается как red и ничего и ниоткуда не вычитается.

Используем те же параметры что и раньше CIR=50, CBS=5, EBS=5. Количество токенов в корзинах теперь показано отдельно: основная Bucket C (голубой) и дополнительная Bucket E (фиолетовый). Теперь у нас не непрерывный поток битовых данных, а пакеты по 5Мбит. Что не совсем реально, трафик, в общем случае, состоит из разных по размеру пакетов приходящих в разные интервалы времени, и это очень сильно может изменить картину происходящего. Но для демонстрации базовых принципов и удобства подсчёта используем такой вариант. Также, отражён процесс пополнения корзины с приходом каждого пакета.

В первые 0,05 секунд передаём пакет в 5Мбит, опустошая основную корзину. С приходом второго пакета мы пополняем её, но на величину 2,5Мбит, что соответствует заданному CIR 0,05*50. Этих токенов не хватает для передачи следующего пакета в 5Мбит, поэтому мы опустошаем вторую корзину, но пакет помечается по другому. Через 0,05 секунд опять приходит пакет, и мы опять пополняем основную корзину на 2,5Мбит и этого объёма хватает для его передачи в зелёной категории. Следующему пакету, несмотря на то что корзина пополняется, уже не хватает токенов и он попадает в красную категорию. Красный сплошной график отражает ситуацию, если отбрасываются только пакеты помеченные красным.

Во время простоя корзины не пополняются, как это было видно на предыдущем графике, но в момент времени 0,6, при получении следующей порции данных высчитывается интервал между пакетами: 0,6-0,3=0,3 секунды, следовательно у нас есть 0,3*50=15Мбит для того чтобы пополнить основную корзину. Максимальный её объём CBS=5Мбит, остатком пополняется вторая корзина, тоже объёмом EBS=5Мбит. Оставшиеся 5Мбит мы не используем, тем самым трафик с очень длинными паузами всё равно ограничивается, чтобы не допустить ситуации: час бездействия — час без ограничений.

В итоге, на графике 6 зелёных участков или 30Мбит переданных за секунду — средняя скорость 30Мбит/c, что соответствует использованию только одной корзины и двух цветов. 3 жёлтых участка и в сумме с первым графиком 45Мбит/c, с учётом красных участков 55Мбит/c — две корзины, три цвета.

2 скорости, 3 цвета

Существует ещё один подход RFC 2698, в котором задаётся параметр пиковой скорости PIR — Peak Information Rate. И в этом случае используются две корзины, но каждая из которых заполняется независимо от другой — одна в соответствии с CIR, другая с PIR:

  1. Bucket CIR, пополняемый объём в токенах = интервал между последовательными пакетами * CIR
  2. Bucket PIR, пополняемый объём в токенах = интервал между последовательными пакетами * PIR

Трафик, как и в предыдущем случае, классифицируется на 3 категории следующим образом:

  1. Если размер пакета меньше чем токенов в CIR корзине, то этот пакет помечается как green и из обеих корзин вычитается количество токенов соответствующих размеру пакета, иначе
  2. Если размер пакета меньше чем токенов в PIR корзине, то этот пакет помечается как yellow и только из PIR корзины вычитается количество токенов соответствующих размеру пакета, иначе
  3. Пакет помечается как red и ничего и ниоткуда не вычитается.

Вспомним для чего нам вторая корзина и больший burst, чтобы компенсировать периоды простоя трафика за счёт менее строго ограничения за больший период. Подход с двумя условиями даёт нам ту же возможность. Сформируем PIR и CIR равными 50Мбит/c, размер первой корзины 5, а второй PBS 10. Почему 10? Потому что это независимое ограничение, что возвращает нас к самому первому графику показывающему разницу burst. То есть, мы хотим добиться среднего результата между burst 5 и burst 10 и задаём эти условия напрямую.

Получили такой же график для полисера, что и при использовании предыдущего метода. При burst=10 получаем больше свободы, а вторым условием burst=5 добавляем точности. Обратите внимание как ведут себя корзины, каждая сама по себе.

Два отдельных условия, каждое из которых выполняется для одних и тех же входящих значений. Более строгое — классифицирует трафик, который гарантированно попадает под него, а менее строгое расширяет эти границы. В случае равных CIR и PIR, получаем взаимозаменяемый с предыдущим метод.

А устанавливая PIR скорость увеличиваем количество степеней свободы. Можно отдельно проверить разные burst при разных профилях трафика с разными CIR, а потом совместить всё вместе с использованием этого метода:

CIR=50, PIR=75, CBS=5, PBS=7,5. CBS и PBS выбраны таким образом, чтобы укладываться в одинаковый интервал. Но, конечно, можно исходить из других условий, например для PIR сделать меньший burst, чтобы увеличить гарантию не выхода за обозначенные границы, а для CIR наоборот, более лояльный.

В принципе, при интенсивном трафике нет причин ставить маленький burst ни в каком случае, ни для какой из корзин. Несколько десятков секунд и несколько лишних мегабайт не сделают погоды на продолжительных временных интервалах, но частые блокировки из-за небольшого burst, могут сломать незаметные для нас механизмы регулировки потока. Для трафика 80Мбит/c, в зелёную зону уложилось 40Мбит/c. Учитывая жёлтую как раз вписались между CIR и PIR — 60МБит/c. Ещё раз, механизмы ограничения пытаются гарантировать не выход за верхние границы, про нижние они ничего не знают. И как видно в примерах, результирующий трафик всегда меньше заданных ограничений, иногда сильно меньше, даже если он сам попадал в них без посторонней помощи.

Описанные выше подходы сформировались в RFC уже больше 20 лет назад, но на свалку истории пока не торопятся, и часто применяются именно как ограничивающий инструмент ухудшающий качество, а не как классификатор, или как компенсирующий механизм. Даже в самых современных реализациях вы обязательно встретите если не эти алгоритмы, но эти термины обязательно и, конечно, сложность применения понятия скорости в сетях передачи данных. Может быть с ещё одной статьёй разобраться во всём этом станет чуть проще.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *