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

Зачем нужно ограничение интернет-трафика?

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

Но нагрузка на разные участки сети и объем трафика, идущий от или к каждому пользователю и устройству, никогда не бывает равномерным. При этом на предприятие выделяется обычно один канал от провайдера, и в этом канале сидят все пользователи компании. Провайдер не будет следить, кто из ваших сотрудников и департаментов «забивает» канал и своим трафиком занимает всю «полосу движения» — да так, что встает работа офиса или удаленного филиала. В банк не уходят платежки, в момент важных переговоров «падает» Skype, не выгружается аналитика из клиентских систем. Что делать? Расставить приоритеты использования канала в компании и обеспечить умное распределение загрузки.

Для этого применяется ограничитель скорости интернета, она же программа ограничения трафика.

Что такое «шейпер» и как он помогает бизнесу

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

Программа для регулировки скорости интернета называется шейпер трафика, а сам процесс распределения загрузки — шейпингом (англ. придание формы), потому что она действительно формирует пользовательский и общий трафик компании.

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

Программа для ограничения скорости интернета регулирует и количество пакетов, получаемых в секунду, и одновременно открытых соединений (сессий). Еще с ее помощью можно запретить многопоточную закачку через прокси-сервер, чтобы пользователи не увлекались скачиванием «тяжелого» внешнего или внутреннего контента. А еще такое ограничение помогает остановить вирусную атаку.

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

Шейпер в решении «Смарт-Софт»

Программа для снижения скорости интернета — обязательный атрибут универсального шлюза безопасности Traffic Inspector Next Generation. Она позволяет учитывать и внешний трафик от провайдера, причем разделять его на платный и бесплатный и анализировать потребление по IP-протоколам и портам. Здесь можно задавать внешние счетчики, лимиты, оповещения о перерасходе, блокировки особо «прожорливых» пользователей. Помогает такая программа и для ограничения скорости интернета по Wi-Fi, что важно гостиницам, ресторанам и другим заведениям, раздающим интернет своим посетителям.

Ограничение скорости передачи трафика. Policer или shaper, что использовать в сети?

Когда речь заходит об ограничении пропускной способности на сетевом оборудовании, в первую очередь в голову приходят две технологи: policer и shaper. Policer ограничивает скорость за счёт отбрасывания «лишних» пакетов, которые приводят к превышению заданной скорости. Shaper пытается сгладить скорость до нужного значения путём буферизации пакетов. Данную статью я решил написать после прочтения заметки в блоге Ивана Пепельняка (Ivan Pepelnjak). В ней в очередной раз поднимался вопрос: что лучше – policer или shaper. И как часто бывает с такими вопросами, ответ на него: всё зависит от ситуации, так как у каждой из технологий есть свои плюсы и минусы. Я решил разобраться с этим чуточку подробнее, путём проведения нехитрых экспериментов. Полученные результаты подкатом.

И так, начнём с общей картинки разницы между policer и shaper.

Как видно, policer срезает все пики, shaper же делает сглаживание нашего трафика. Достаточно неплохое сравнение между policer и shaper можно найти здесь.

Обе технологии в своей основе используют механизм токенов (token). В этом механизме присутвует виртуальное ограниченное по размеру ведро (token bucket), в которое с некой регулярностью поступают токены. Токен, как проездной, расходуется для передачи пакетов. Если токенов в ведре нет, то пакет отбрасывается (могут выполняться и другие действия). Таким образом, мы получаем постоянную скорость передачи трафика, так как токены поступают в ведро в соответствии с заданной скоростью.

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

Механизм токенов позволяет обеспечить гибкость в настройке ограничения скорости. Размер ведра влияет на то, как мы будем усреднять нашу скорость. Если ведро большое (т.е. токенов там может скопиться много), мы позволим трафику сильнее «выпрыгивать» за отведенные ограничения в определённые моменты времени (эквивалент усреднения на большем промежутке времени). Если размер ведра маленький, то трафик будет более равномерный, крайне редко превышая заданный порог (эквивалент усреднения на маленьком промежутке времени).

В случае policer’а наполнение ведра происходит каждый раз, когда приходит новый пакет. Количество токенов, которые загружаются в ведро, зависит от заданной скорости policer’а и времени, прошедшего с момента поступления последнего пакета. Если токенов в ведре нет, policer может отбросить пакеты или, например, перемаркировать их (назначить новые значения DSCP или IPP). В случае shaper’а наполнение ведра происходит через равные промежутки времени независимо от прихода пакетов. Если токенов не хватает, пакеты попадают в специальную очередь, где ждут появления токенов. За счёт этого имеем сглаживание. Но если пакетов приходит слишком много, очередь shaper’а в конечном счёте переполняется и пакеты начинают отбрасываться. Стоит отметить, что приведённое описание является упрощённым, так как и policer и shaper имеют вариации (детальный разбор данных технологий займёт объём отдельной статьи).

Эксперимент

А как это выглядит на практике? Для этого соберём тестовый стенд и проведём следующий эксперимент. Наш стенд будет включать устройство, которое поддерживает технологии policer и shaper (в моём случае – это Cisco ISR 4000; подойдёт устройство любого вендора аппаратное или программное, которое поддерживает данные технологии), генератор трафика iPerf и анализатор трафика Wireshark.

Сначала посмотрим на работу policer. Настроим ограничение скорости равным 20 Мбит/с.

В iPerf запускаем генерацию трафика в рамках четырёх потоков, используя протокол TCP.

Средняя скорость составила 17.1 Мбит/с. Каждая сессия получила разную пропускную способность. Обусловлено это тем, что настроенный в нашем случае policer не различает потоки и отбрасывает любые пакеты, которые превышают заданное значение скорости.

С помощью Wireshark собираем дамп трафика и строим график передачи данных, полученный на стороне отправителя.

Чёрная линия показывают суммарный трафик. Разноцветные линии – трафик каждого потока TCP. Прежде чем делать какие-то выводы и углубляться в вопрос, давайте посмотрим, что у нас получится, если policer заменить на shaper.

Настроим shaper на ограничение скорости 20 Мбит/с.

При настройке используем автоматическое выставляемое значение размера ведра токенов BC и BE равное 8000. Но меняем размер очереди с 83 (по умолчанию в версии IOS XE 15.6(1)S2) на 200. Сделано это сознательно, чтобы получить более чёткую картину, характерную для shaper’а. На этом вопросе мы остановимся более подробно в подкате «Влияет ли глубина очереди на нашу сессию?».

В iPerf запускаем генерацию трафика в рамках четырёх потоков, используя протокол TCP.

Средняя скорость составила 19.3 Мбит/с. При этом каждый поток TCP получил примерно одинаковую пропускную способность.

С помощью Wireshark собираем дамп трафика и строим график передачи данных, полученный на стороне отправителя.

Чёрная линия показывают суммарный трафик. Разноцветные линии – трафик каждого потока TCP.

Сделаем первые промежуточные выводы:

  • В случае policer полезная пропускная способность составила 17.1 Мбит/с. Каждый поток в разные моменты времени имел разную пропускную способность.
  • В случае shaper полезная пропускная способность составила 19.3 Мбит/с. Все потоки имели примерно одинаковую пропускную способность.

Начнём c графиков, на которых отображаются пакеты с привязкой ко времени их передачи. Первый график – policer’а, второй – shaper’а.

Из графиков видно, что пакеты в случае shaper передаются более равномерно по времени. При этом в случае policer видны скачкообразные разгоны сессии и периоды пауз.

Анализ TCP сессии при работе policer

Посмотрим поближе на сессию TCP. Будем рассматривать случай policer’а.

Протокол TCP в своей работе опирается на достаточно большой набор алгоритмов. Среди них для нас наиболее интересными являются алгоритмы, отвечающие за управление перегрузками (congestion control). Именно они отвечают за скорость передачи данных в рамках сессии. ПК, на котором запускался iPerf, работает под управлением Windows 10. В Windows 10 в качестве такого алгоритма используется Compound TCP (CTCP). CTCP в своей работе позаимствовал достаточно многое из алгоритма TCP Reno. Поэтому при анализе TCP сессии достаточно удобно посматривать на картинку с состояниями сессии при работе алгоритма TCP Reno.

На следующей картинке представлен начальный сегмент передачи данных.

    На первом этапе у нас устанавливается TCP сессия (происходит тройное рукопожатие).

Чтобы посмотреть параметры TCP, можно воспользоваться PowerShell.

Смотрим, какой глобальный шаблон TCP используется в нашей системе по умолчанию.

В режиме TCP slow-start размер окна (cwnd) увеличивается каждый раз при получении ACK. При этом оно не может превысить значение awnd. За счёт такого поведения, мы имеем практически экспоненциальный рост количества передаваемых пакетов. Наша TCP сессия разгоняется достаточно агрессивно.

  1. ПК устанавливает TCP-соединение (№1-3).
  2. Отправляет 10 пакетов (№4-13), не дожидаясь подтверждения (ACK), так как cwnd=10*MSS.
  3. Получает ACK (№14), который подтверждает сразу два пакета (№4-5).
  4. Увеличивает размер окна Cwnd=(10+2)*MSS=12*MSS.
  5. Отправляет дополнительно три пакета (№15-17). По идее ПК должен был отправить четыре пакета: два, так как он получил подтверждение на два пакета, которые были переданы ранее; плюс два пакета из-за увеличения окна. Но в реальности на самом первом этапе система шлёт (2N-1) пакетов. Найти ответ на этот вопрос мне не удалось. Если кто-то подскажет, буду благодарен.
  6. Получает два ACK (№18-19). Первое ACK подтверждает получение удалённой стороной четырёх пакетов (№6-9). Второе — трёх (№10-12).
  7. Увеличивает размер окна Cwnd=(12+7)*MSS=19*MSS.
  8. Отправляет 14 пакетов (№20-33): семь новых пакетов, так как получили ACK на семь ранее переданных пакетов, и ещё семь новых пакетов, так как увеличилось окно.
  9. И так далее.

После получения трёх Dup ACK наша TCP сессия переходит в фазу восстановления после потери (loss recovery, включающую алгоритмы Fast Retransmit/Fast Recovery). Отправитель устанавливает новое значение ssthresh = cwnd/2 (32K) и делает окно cwnd = ssthresh+3*MSS.

Как только было отправлено количество пакетов, укладывающихся в окно cwnd, система останавливается. Для продолжения передачи данных ей нужны новые ACK (не Dup ACK). Но ACK не приходят. Все повторные пакеты отбрасываются policer’ом, так в ведре закончились токены, а времени, чтобы их восполнить, прошло слишком мало.

В алгоритме Compound TCP для регулирования скорости передачи используется окно отправителя (sending window — wnd), которое зависит от двух взвешенных величин: окна перегрузки (cwnd) и окна задержки (delay window — dwnd). Cwnd, как и раньше, зависит от полученных ACK, dwnd зависит от величины задержки RTT (round trip time). Окно wnd растёт только один раз за период времени RTT. Как мы помним, в случае slow-start окно cwnd росло при получении каждого ACK. Поэтому в режиме congestion avoidance сессия разгоняется не так быстро.

Анализ TCP сессии при работе shaper

Теперь давайте посмотрим поближе на сегмент передачи данных для случая shaper. Для наглядности возьмём аналогичный масштаб, как и для графика policer на Рис.6.

Из графика мы видим всё ту же лесенку. Но размер ступенек стал существенно меньше. Однако если приглядеться к графику на Рис. 10, мы не увидим небольших «волн» на конце каждой ступеньки, как это было на Рис. 9. Такие «волны» были следствием потери пакетов и попыток их передачи заново.

Рассмотрим начальный сегмент передачи данных для случая shaper.

Происходит установление сессии. Далее начинается разгон в режиме TCP slow-start. Но этот разгон более пологий и имеет ярко выраженные паузы, которые увеличиваются в размере. Более пологий разгон обусловлен тем, что размер ведра по умолчанию для shaper всего (BC+BE) = 20 000 байт. В то время как для policer размер ведра — 625 000 байт. Поэтому shaper срабатывает существенно раньше. Пакеты начинают попадать в очередь. Растёт задержка от отправителя к получателю, и ACK приходят позже, чем это было в случае policer. Окно растёт существенно медленнее. Получается, что чем больше система передаёт пакетов, тем больше их накапливается в очереди, а значит, тем больше задержка в получении ACK. Имеем процесс саморегуляции.

Через некоторое время окно cwnd достигает значения awnd. Но к этому моменту у нас накапливается достаточно ощутимая задержка из-за наличия очереди. В конечном итоге при достижении определённого значения RTT наступает равновесное состояние, когда скорость сессии больше не меняется и достигает максимального значения для данного RTT. В моём примере среднее RTT равно 107 мс, awnd=64512 байт, следовательно, максимальная скорость сессии будет соответствовать awnd/RTT= 4.82 Мбит/с. Примерно такое значение нам и выдал iPerf при измерениях.

Но откуда берутся ярко выраженные паузы в передаче? Давайте посмотрим на график передачи пакетов через устройство с shaper в случае, если у нас всего одна TCP сессия (Рис.12). Напомню, что в нашем эксперименте передача данных происходит в рамках четырёх TCP сессий.

На этом графике очень хорошо видно, что нет никаких пауз. Из этого можно сделать вывод, что паузы на Рис.10 и 11 обусловлены тем, что у нас одновременно передаётся четыре потока, а очередь в shaper одна (тип очереди FIFO).

На Рис.13 представлено расположение пакетов разных сессий в очереди FIFO. Так как пакеты передаются пачками, они будут располагаться в очереди таким же образом. В связи с этим задержка между поступлением пакетов на приёмной стороне будет двух типов: T1 и T2 (где T2 существенно превосходит T1). Общее значение RTT для всех пакетов будет одинаковым, но пакеты будут приходить пачками, разнесёнными по времени на значение T2. Вот и получаются паузы, так как в момент времени T2 никакие ACK к отправителю не приходят, при этом окно сессии остаётся неизменным (имеет максимальное значение равное awnd).

Логично предположить, что, если заменить одну общую очередь FIFO на несколько для каждой сессии, никаких ярко выраженных пауз не будет. Для такой задачи нам подойдёт, например, очередь типа Weighted Fair Queuing (WFQ). В ней для каждой сессии создаётся своя очередь пакетов.

Из общего графика мы сразу видим, что графики всех четырёх TCP сессий идентичны. Т.е. все они получили одинаковую пропускную способность.

А вот и наш график распределения пакетов по времени передачи ровно в том же масштабе, что и на Рис. 11. Никаких пауз нет.

Стоит отметить, что очередь типа WFQ позволит нам получить не только более равномерное распределение пропускной способности, но и предотвратить «забивание» одного типа трафика другим. Мы всё время говорили про TCP, но в сети также присутствует и UDP трафик. UDP не имеет механизмов подстройки скорости передачи (flow control, congestion control). Из-за этого UDP трафик может с лёгкостью забить нашу общую очередь FIFO в shaper’е, что драматически повлияет на передачу TCP. Напомню, что, когда очередь FIFO полностью заполнена пакетами, по умолчанию начинает работать механизм tail-drop, при котором отбрасываются все вновь пришедшие пакеты. Если у нас настроена очередь WFQ, каждая сессия пережидает момент буферизации в своей очереди, а значит, сессии TCP будут отделены от сессий UDP.

Самый главный вывод, который можно сделать после анализов графиков передачи пакетов при работе shaper’а – у нас нет потерянных пакетов. Из-за увеличения RTT скорость сессии адаптируется к скорости shaper’а.

Конечно! Изначально (если кто-то об этом ещё помнит) мы изменили глубину очереди с 83 (значение по умолчанию) на 200 пакетов. Сделали мы это для того, чтобы очереди хватило для получения достаточного значения RTT, при котором суммарная скорость сессий становиться примерно равна 20 Мбит/с. А значит, пакеты «не вываливаются» из очереди shaper’а.

При глубине в 83 пакета очередь переполняется быстрее, нежели достигается нужное значение RTT. Пакеты отбрасываются. Особенно ярко это проявляется на начальном этапе, когда у нас работает механизм TCP slow-start (сессия разгоняется максимально агрессивно). Стоит отметить, что количество отброшенных пакетов несравнимо меньше, чем в случае с policer, так как увеличение RTT приводит к тому, что скорость сессии растёт более плавно. Как мы помним, в алгоритме CTCP размер окна в том числе зависит от значения RTT.

Графики утилизации пропускной способности и задержки при работе policer и shaper

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

График утилизации пропускной способности:

В случае policer мы видим скачкообразный график: сессия разгоняется, потом наступают потери, и её скорость падает. После чего всё повторяется снова. В случае shaper наша сессия получает примерно одинаковую пропускную способность на протяжении всей передачи. Скорость сессии регулируется за счёт увеличения значения RTT. На обоих графиках вначале можно наблюдать взрывной рост. Он обусловлен тем, что наши вёдра изначально полностью заполнены токенами и TCP-сессия, ничем не сдерживаемая, разгоняется до относительно больших значений (в случае shaper это значение в 2 раза меньше).

График задержки RTT для policer и shaper (по-хорошему, это первое о чём мы вспоминаем, когда говорим про shaper):

В случае policer (первый график) задержка RTT для большинства пакетов минимальна, порядка 5 мс. На графике также присутствуют существенные скачки (до 340 мс). Это как раз моменты, когда пакеты отбрасывались и передавались заново. Тут стоит отметить, как Wireshark считает RTT для TCP трафика. RTT – это время между отправкой оригинального пакета и получением на него ACK. В связи с этим, если оригинальный пакет был потерян и система передавала пакет повторно, значение RTT растёт, так как точкой отсчёта является в любом случае момент отправки оригинального пакета.

В случае shaper задержка RTT для большинства пакетов составила 107 мс, так как они все задерживаются в очереди. Есть пики до 190 мс.

Выводы

Итак, какие итоговые выводы можно сделать. Кто-то может заметить, что это и так понятно. Но наша цель была копнуть чуточку глубже. Напомню, что в эксперименте анализировалось поведение TCP-сессий.

    Shaper предоставляет нам на 13% больше полезной пропускной способности, чем policer (19.3 против 17.1 Мбит/с) при заданном ограничении в 20 Мбит/с.

Если policer настроен ближе к получателю, наша сеть фактически занимается прокачкой бесполезного трафика, который будет в итоге отброшен policer’ом. Например, в разрезе глобальной сети интернет это может является проблемой, так как трафик режется зачастую ближе к получателю.

Вообще наличие очереди может достаточно негативно сказываться на работе приложений – так называемый эффект излишней сетевой буферизации (Bufferbloat). Поэтому с глубиной очереди надо быть аккуратными.

В этом году при поддержке Google было проведено исследование, в котором анализировался негативный эффект работы policer’а в сети интернет. Было определено, что от 2% до 7% потерь видео трафика по всему Миру вызвано срабатыванием policer’а. Потери пакетов при непосредственной работе policer’а составили порядка 21%, что в 6 раз больше, чем для трафика, который не подвержен срабатыванию данной технологии. Качество видео трафика, который подвергся обработке policer’ом, хуже, чем в случае, если policer не срабатывал.

Для борьбы с негативным эффектом работы policer’а предлагаются следующие меры в зависимости от точки их применения.

  1. В policer’е уменьшить размер ведра (burst size). Это приведёт к тому, что TCP сессия не сможет слишком сильно разогнаться, пока есть свободные токены, и быстрее начнёт адаптацию под реальную пропускную способность.
  2. Вместо policer’а использовать shaper (с небольшой глубиной очереди).
  3. Использовать и shaper, и policer одновременно. В этом случае shaper располагается чуть раньше, чем policer. Shaper задерживает пакеты, сглаживая колебания. Из-за такой задержки policer успевает аккумулировать достаточное количество токенов, чтобы передавать трафик. Потери в таком случае минимизируются.

Для контент-провайдеров предлагается ограничивать скорость отправки трафика на сервере, чтобы избегать включения policer’а. Но на практике оценить реальную скорость канала не всегда просто. Второй метод — избегать взрывной передачи трафика за счёт модификации алгоритмов TCP: использовать TCP Pacing (отправлять пакеты с привязкой к RTT, а не к моменту получения ACK) и изменить схему работы фазы loss recovery (на каждый полученный ACK слать только один новый пакет).

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

Почти все приложения, использующие Интернет, работают через TCP (RFC 793) поверх IP. Протокол IP всего лишь передает пакеты, не заботясь о том, что они могут быть поврежденными, идти в неправильном порядке и т.д. К тому же IP не позволяет адресовать пакет какой-либо конкретной программе. Все эти недостатки устраняются уровнем выше – в TCP. Его характеристики следующие:
Потоковый интерфейс: Все байты информации, отправляемые одним приложением с одной стороны, придут к приложению-получателю с другой стороны в той же последовательности, в какой были посланы. Нет никакого ограничения на размер сообщенния: TCP сам разбивает по своему усмотрению информацию на пакеты.
Достоверность и надежность: Для каждого сегмента (пакета) TCP вычисляет контрольную сумму и отбрасывает его, если она неправильная. Он повторяет пересылку до тех пор, пока не получит подтверждение от получателя о правильном приеме или пока не убедится в том, что канал невозможно использовать и не выйдет время ожидания.
Мультиплексирование: TCP использует механизм портов для осуществления мультиплексирования, тем самым позволяя приложениям-отправителям адресовать данные конкретным приложениям-получателям. Например, веб-серверы, как правило, используют порт 80. Когда браузер соединяется с сервером, он также указывает и порт источника. При этом веб-страница отсылается именно ему. Обычно серверные порты имеют значение меньше 1024 (хотя и не всегда); клиентские порты обычно находятся в диапазоне от 1024 и выше.
Предотвращение перегрузки канала: Наконец, TCP имеет контроль загрузки линии, который позволяет ему определить, не теряются ли ресурсы из-за посылки большего объема трафика, чем может передавать канал.

предотвращение перегрузки канала в TCP

Кроме встроенного простого механизма самосинхронизации, основанного на «окне», ограничивающем количество пересылаемой информации, TCP имеет еще четыре дополнительных механизма, осуществляющих регулировку загрузки канала: медленный старт, предотвращение перегрузки, быстрая перепосылка и быстрое восстановление. Алгоритмы этих механизмов описаны в RFC 2001.

медленный старт
После инициализации соединения, другая сторона сообщает TCP объем данных, приготовленных в буфере. Это значение называется «предложенным размером окна». На установление соединения уходит 3 пакета: инициализирующий пакет с установленным SYN-битом, ответ от хоста-получателя с установленными битами SYN/ACK и финальный пакет от хоста-инициатора с установленным битом ACK.
После вышеописанной процедуры установления соединения локальный (и удаленный) TCP может передавать данные до тех пор, пока окно не заполнится. После этого он должен подождать подтверждений о приеме некоторой части информации. Только после их получения он может продолжить передачу. При получении от удаленного TCP слишком большого значения размера предложенного окна, локальный TCP не начинает сразу же использовать окно полностью. Это необходимо потому что на пути может встретится низкоскоростное соединение, и маршрутизатор, подключенный к нему не сможет буферизировать все накапливающиеся данные пока они не будут переданы через соединение. Таким образом, передающая сторона использует окно предотвращения перегрузки в дополнение к предложенному окну. Окно предотвращения перегрузки сначала имеет размер, равный максимальному размеру сегмента. После получения каждого уведомления о приеме данных, размер этого окна удваивается. Если размер сегмента равен 1460 байтам (что соответствует 1500-байтному пакету Ethernet минус IP- и TCP-заголовки), и приемник предлагает 8192-байтное окно, передатчик установит размер окна предотвращения перегрузки в 1460 байт, передаст первый пакет и будет ждать подтверждения. После получения первого подтверждения, размер окна увеличится до 2920 байт, и предадутся 2 пакета. После получения следующего подтверждения размер окна становится равным 5840 байтам, позволяя пересылать 4 пакета. Один пакет еще не подтвержден, поэтому пересылаются 3 пакета. После получения подтверждения, размер окна увеличится до предложенного.

защита от перегрузки
Защита от перегрузки предлагает другую переменную: границу медленного старта (slow start threshold size (ssthresh)). При инициализации соединения значение ssthresh устанавливается равным 65535 байтам (максимально возможное предложенное окно). Если информация не теряется, алгоритм затяжного пуска будет увеличивать размер окна до тех пор, пока он не станет максимальным. Если же TCP получает пришедшее не по порядку подтверждение, в силу вступает механизм предотвращения перегрузки. В данном случае под пришедшим не по порядку подтверждением подразумевается подтверждение о приеме информации, которая уже была передана, и подтверждение о ее приеме было получено. Это происходит при потере пакета: принимающий TCP отправляет передающему подтверждение на информацию до потерянного пакета, говоря примерно следующее: « Я все еще жду информацию, следующую за тем, что я сейчас подтверждаю» Такая схема необходима из-за того, что подтверждения TCP кумулятивны, т.е. нельзя сказать: «Я получил байты 1000-1499, но потерял 500-999»
После получения повторяющегося подтверждения, передающий TCP принимает неподтвержденную информацию за трагически погибшую из-за перегрузки канала. При этом ssthresh и размер окна предотвращения перегрузки устанавливаются равными половине текущего размера окна до тех пор, пока он равен как минимум двум максимальным размерам сегмента. После этого, окну разрешается увеличиваться очень медленно, чтобы сразу же не вернуться к состоянию перегрузки. Если передающий TCP длительное время не получает никаких подтверждений, он определяет эту ситуацию как массивную перегрузку и инициирует механизм затяжного пуска, понижая при этом значение ssthresh. Таким образом, до тех пор, пока размер окна предотвращения перегрузки меньше или равен значению ssthresh, используется затяжной пуск (окно удваивается после каждого подтверждения), а после него – предотвращение перегрузки (окно медленно увеличивается).

быстрая перепослылка и восстановление
Если TCP получает подряд три идущих не по порядку подтверждения, он решает, что один пакет был потерян (одно или два неправильных подтверждения воспринимаются им как изменение очередности передачи пакетов в сети). После этого он пересылает пакет заново, не дожидаясь тайм-аута. Значение ssthresh устанавливается так же, как и при защите от перегрузки, но размер «перегрузочного» окна принимается равным ssthresh плюс три максимальных сегмента (размер равен количеству информации, успешно полученной приемником, определенному по идущим не по порядку подтверждениям). В результате TCP замедляется, но не сильно, так как при этом через него все еще проходит достаточно большой объем данных.

влияние потери пакетов и задержек на работу TCP

В результате работы вышеописанных механизмов TCP сильно замедляется при потере большого числа пакетов. Ситуация ухудшается, когда время прохождения пакетов туда и обратно (RTT) большое из-за того, что использование окон ограничивает пропускную способность TCP до размера окна, деленного на время прохождения пакетов туда и обратно. Это означает, что даже с максимальным размером окна в 64 кб (без включения высокопроизводительных расширений TCP), производительность TCP на трансконтинентальной линии с задержкой прохождения пакетов туда и обратно в 70 мс не превысит 900 кбит/с. При потере пакета это значение уменьшается вдвое и возвращается к назад только после сотен успешных подтверждений. Таким образом, даже случайная потеря пакета может существенно снизить эффективность использования пропускной способности территориально протяженного соединения TCP-сессией.
Поведение двух основных категорий не-TCP приложений в условиях потери пакетов различно. К первой категории можно отнести мультимедиа (потоковое аудио и видео), ко второй – приложения, основанные на небольших транзакциях, не требующих большого количества служебной информации вроде DNS. Как правило, потоковые аудио и видео не слишком чувствительны к потере пакетов, тем не менее, от нее несколько пострадает качество. Что же касается вещей вроде разрешения имен DNS, то потеря пакетов существенно замедлит индивидуальные транзакции (для них наступает тайм-аут и требуется повторение). Из-за того, что не-TCP приложения не имеют адекватной реакции на потерю пакетов, часто бывает так, что они увеличивают перегрузку канала, продолжая посылать больший объем трафика, чем может передавать соединение.
Несмотря на то, что некоторые потерянные пакеты – результат ошибок в битах на физическом уровне или временных проблем с маршрутизацией, основная причина потерь – перегрузка канала чрезмерным трафиком. Рассмотрим ситуацию, когда, например, скорость подключения маршрутизатора к популярному направлению равна 155 Мбит/с, а для этого направления со скоростью 200 Мбит/с приходит трафик. Первое, что сделает маршрутизатор – поставит пакеты, которые невозможно переслать немедленно, в очередь. IP-трафику свойственны кратковременные вспышки активности длительностью от секунды до нескольких секунд. Очередь сглаживает подобные неоднородности. Ценой этого являются некоторые дополнительные задержки пакетов, но, по крайней мере, пакеты не теряются. Тем не менее, если чрезмерно интенсивный трафик передается длительное время, очередь может переполниться. При этом маршрутизатору ничего не остается, кроме как отбрасывать все входящие пакеты, до тех пор, пока очередь переполнена. Это называется «отбрасывать хвост» («tail drop»). Механизмы защиты от перегрузки разработаны именно для этой ситуации, таким образом, в данном случае все TCP-сессии замедлятся, при этом перегрузка должна исчезнуть. Однако может возникнуть более сложный случай перегрузки, когда трафик представляет собой множество коротких TCP-сессий (например, web или email). В этом случае количества инициализирующих пакетов (в это время TCP еще находится режиме затяжного пуска) может хватить, чтобы вызвать перегрузку. Не-TCP приложения также легко могут вызвать перегрузку, так как они не обладают механизмами защиты от нее.

образование очередей

Образование очередей происходит только в случае, когда интерфейс слишком занят. Если же он свободен, то пакеты передаются без всякой дополнительной обработки. Все стандартные очереди работают по принципу FIFO (first in, first out): пакет, который пришел раньше всех, будет передан первым и т.д. Если очередь заполнена до отказа и приходят новые пакеты, то происходит «отброс хвоста». Более изощренные способы организации очередей часто используют несколько очередей. Пакеты классифицируются в соответствии с потребностями пользователя и затем сортируются по соответствующим очередям. Затем, при освобождении интерфейса, с помощью специального алгоритма выбирается очередь, пакет из которой будет отправлен. Например, маршрутизаторы Cisco поддерживают несколько стратегий организации очередей: FIFO, WQF, RED, по приоритету, произвольные. Следует отметить, что все специальные методики организации очередей дают эффект только в случаях, когда невозможно немедленно отправить пакет через интерфейс. Если же интерфейс свободен и в очереди не находится пакетов, то новый пакет пересылается сразу же.

FIFO
Стратегия FIFO – самая простая. При ее использовании пакеты передаются в том же порядке, в каком приходят. Как правило, ее применяют на быстрых интерфейсах. Чтобы ее включить, необходимо отключить все остальные механизмы организации очередей:

!
interface Serial0
no fair-queue
!

взвешенные очереди (Weighted fair queuing, WQF)
Механизмы, использующие очереди с весами, пытаются разделить пропускную способность между несколькими потоками данных (обычно это TCP-сессии), таким образом, чтобы потоки с большой активностью не захватывали монопольно соединение. Как правило, WQF применяется для низкоскоростных интерфейсов. Включить WQF можно следующим образом:

!
interface Serial0
fair-queue
!

опознание перегрузки (Random early detect, RED)
При переполнении очереди RED начинает отбрасывать пакеты для предотвращения перегрузки канала. Больше всего RED обращает внимания на сессии с наибольшим объемом трафика, поэтому именно они замедляются в первую очередь. При использовании опознания перегрузки с весами (Weighted random early detect), в первую очередь будут отбрасываться пакеты с наименьшим приоритетом. В отличие от WFQ, очередей с приоритетами и произвольных очередей, RED не требовательна к процессорному времени и может применяться на высокоскоростных интерфейсах. Она нуждается в размере очереди на передачу большем, чем стандартные 40 пакетов, чтобы иметь возможность начать отброс пакетов заранее и избежать «отброса хвоста».

!
interface Ethernet0
random-detect
hold-queue 200 out
!

Кстати, в RFC 2309 проблемная группа проектирования Интернет (IETF) рекомендует использовать RED в Интернет-маршрутизаторах.

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

!
interface Serial0
priority-group 1
!
priority-list 1 protocol ip medium udp domain
priority-list 1 protocol ip low tcp ftp
priority-list 1 protocol ip low tcp ftp-data
!

произвольные очереди
В данном случае применяются несколько очередей. Для каждой очереди можно задать количество информации, которое должно быть передано из нее перед тем, как начнется передача из следующей очереди. Эта методика позволяет гарантировать некоторое минимальное значение пропускной способности, отводимое под каждый вид трафика. В то же время, незадействованная пропускная способность доступна другим видам трафика. В следующем примере под WWW-трафик отводится 75% пропускной способности, 5%— DNS и 20% — остальным.

!
interface Serial0
custom-queue-list 1
!
queue-list 1 protocol ip 1 tcp www
queue-list 1 protocol ip 2 udp domain
queue-list 1 default 3
queue-list 1 queue 1 byte-count 7500
queue-list 1 queue 2 byte-count 500
queue-list 1 queue 3 byte-count 2000
!

В данном случае если, например, WWW-трафику маловато 75% пропускной способности и остальные виды не-WWW/DNS -трафика потребляют только 5%, то оставшиеся 15% пропускной способности отдаются WWW. Таким образом, пропускная способность не тратится зря.

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

При применении шейпинга, происходит подсчет трафика для конкретного интерфейса. Шейпинг может применяться ко всему трафику или же только к тому, который удовлетворяет какому-либо списку. Это происходит не зависимо от того, свободен ли интерфейс, или в очереди находятся пакеты. Когда трафик достигает некоторого заданного пользователем значения, следующие поступающие пакеты становятся в очередь и задерживаются. Таким образом, потребляемая пропускная способность ограничивается на настраиваемое значение.
Ограничение скорости, иногда называемое также ограничением трафика похоже на шейпинг. Отличие заключается в том, что чрезмерный трафик обрабатывается отдельно от обычного, по правилам, настраиваемым пользователем. Наиболее распространенный способ обработки лишнего трафика – отброс его, но существуют и другие способы, например, уменьшение значения поля приоритета в IP-заголовке. В следующем примере включается шейпинг для одного интерфейса и ограничение скорости для другого.

!
interface Serial0
traffic-shape rate 128000 8000 8000 1000
!
interface Serial1
rate-limit output 128000 8000 8000 conform-action transmit exceed-action drop
!

Шейпинг и ограничение скорости обычно применяются, когда необходимо ограничить доступную клиенту пропускную способность, если, например, оплачена низкая, а подключение производится по интерфейсу, имеющему высокую пропускную способность. Однако в данном случае лучше не применять ограничение скорости, так как оно отбрасывает много пакетов, заставляя TCP думать, что линия перегружена. Посему он замедляется, но спустя некоторое время опять пытается ускорить темп, вызывая тем самым очередную потерю пакетов. Шейпинг же всего лишь замедляет пакеты, так что через некоторое время TCP адаптируется к доступной пропускной способности. В следующем примере показана производительность FTP на соединении с применением ограничения скорости до 128к.

ftp>put testfile
local: testfile remote: testfile
150 Opening BINARY mode data connection for ‘testfile’.
100% |**********************************| 373 KB 00:00 ETA
226 Transfer complete.
382332 bytes sent in 35.61 seconds (10.48 KB/s)

Как видно, пропускная способность для FTP составила 84 кбит/с, т.е. примерно две трети от доступной. Как будет вести себя та же передача, на том же соединении, но с применением шейпинга, показано ниже:

ftp>put testfile
local: testfile remote: testfile
150 Opening BINARY mode data connection for ‘testfile’.
100% |**********************************| 373 KB 00:00 ETA
226 Transfer complete.
382332 bytes sent in 24.73 seconds (15.10 KB/s)

На сей раз производительность составила 121 кбит/с, что всего лишь на несколько процентов меньше доступной, учитывая служебную информацию TCP, IP и соединения.
Кроме отбивания атак типа «отказ в обслуживании», ограничение скорости имеет еще одно потенциальное применение, так как в отличие от шейпинга и других механизмов организации очередей может быть применено и к входящему трафику. Когда провайдер договаривается с клиентом о некоторой пропускной способности, он может использовать шейпинг для ограничения доступной клиенту входящей пропускной способности. Но так как невозможно применить шейпинг к входящим в интерфейс пакетам, на клиента возлагается задача шейпинга его исходящего трафика. Для того чтобы убедиться, что клиент не превышает оговоренный лимит трафика, провайдер может дополнительно применить ограничение скорости на входящий трафик.

Iljitsch van Beijnum, перевод Дмитрия Герусса.

Сетевые решения. Статья была опубликована в номере 01 за 2003 год в рубрике технологии

Задание уровней качества связи.

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

Технология, которая позволяет ограничивать скорость и качество доступа в Интернет, называется шейпинг (от англ. Shape — форма). Образно говоря — это технология придания некой формы графику загрузки канала.

Шейпер — это алгоритм, который помимо управления очередностью пакетов позволяет отбрасывать не удовлетворяющие условиям. К таковым относятся алгоритмы PCQ и HTB (о них поговорим несколько позже).

Существует ещё один тип алгоритмов, используемых для управления движением пакетов внутри шейпера Schedulers. Их задача состоит только в формировании очередей согласно приоритетам пакетов, адресу источника, получателя и другим параметрам. К этому типу алгоритмов относятся PFIFO, BFIFO,SFQ, PCQ, RED.

Под-очередь — очередь, сформированная из пакетов по тому или иному признаку.

Queuing discipline (qdisc — дисциплина очереди) — алгоритм, который захватывает пакеты и точно определяет в каком порядке и каким образом они будут двигаться.

В основе шейпинга, используемого в Mikrotik, лежит дисциплина очереди HTB, реализованная во многих Linux-системах. Ее изучение является достаточно сложной, однако необходимой задачей для новичка, потому как без этих знаний дальше неудачных попыток и копирования правил из документации мало кто заходит.

Список основных возможностей по управлению трафиком в Mikrotik выглядит следующим образом:

  • ограничение скорости по IP-адресам, подсетям, протоколам, портам, времени суток и другим параметрам;
  • ограничение P2P-трафика (BitTorrent, eMule);приоритизация одних потоков пакетов над другими;
  • использование пиковых скоростей для быстрого WEB-браузинга;
  • разделение канала между пользователями поровну или в других пропорциях;
  • возможность задания гарантированной скорости.

Ключевым понятием для HTB является класс. Приставка Hierarhical в аббревиатуре HTB означает, что дисциплина позволяет строить иерархию классов.

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

Q1 rusqos.JPG

Схематическое изображение структуры HTB

На схеме выше изображена иерархия классов, в которую из файервола (Filter) поступают пакеты с данными. В зависимости от приоритета, параметров классов и загрузки канала они попадают или в локальные очереди (Self Feed), или передаются в очереди родительских классов (Inner Feed).

Класс характеризуют следующие параметры:

  • limit-at – гарантированная скорость;
  • max-limit – ограничение скорости;
  • priority – приоритет класса.

Класс может находиться в одном из трех состояний:

  • Зеленый — пропускная способность правила не превышает параметр limit-at. В этом случае пакеты не двигаются вверх по иерархии, а перемещаются сразу в выходной поток своего уровня согласно приоритетам.
  • Желтый — пропускная способность правила больше limit-at, но меньше max-limit. В этом случае класс отключается от выходного потока своего уровня и подключается к родительскому классу.
  • Красный — пропускная способность правила больше max-limit. В этом состоянии класс отключается от родительского и подключается к локальной очереди.

Пользуясь уже даже этими данными, можно составлять правила, однако на практике некоторые вещи могут выглядеть несколько иначе.

В Mikrotik предусмотрены два типа правил, разнесенные на разные закладки в графической утилите Winbox (с ее помощью можно конфигурировать Mikrotik из-под Windows):

  • Simple Queues;
  • Queue Trees.

О них мы поговорим несколько позже, а сейчас рассмотрим несколько примеров работы HTB

Создадим несколько правил

1. Рассмотрим первый случай, когда клиенты 1 и 2 передают данные со скоростью меньше, чем указано в параметре limit-at, а клиент 3 не работает.

Q2 rusqos.jpg

Как видим, пакеты с данными от leaf1 и leaf2 (клиенты) не передаются в родительские классы, а выстраиваются в локальную очередь в соответствии со своими приоритетами

2. Сейчас посмотрим что будет, в случае если клиент leaf2 будет передавать данные со скоростью больше limit-at, но меньше max-limit указанных в его параметрах и меньше limit-at в параметрах ClassB, к которому он прикреплен. Одновременно с ним leaf1 будет передавать данные со скоростью не превышающей limit-at.

Q3 rusqos.jpg

В данном случае получается интересная ситуация: клиент leaf1 будет иметь больший приоритет, чем leaf2, хотя в параметрах последнего указан больший приоритет. Это связано с тем, что передавая данные со скоростью более limit-at leaf2 подключился к родительскому классу, имеющему приоритет 8. При этом существует правило, что на нижних уровнях приоритет пакетов при одинаковых условиях больше, чем на верхних.

3. Рассмотрим следующий пример: скорости передачи данных для leaf1 превысила допустимое max-limit, клиент leaf2 передает данные на скорости больше limit-at и меньше max-limit, клиент leaf3 работает на скорости меньше limit-at.

Q4 rusqos.jpg

Это весьма интересный случай. В данной ситуации видно, что ClassA перегружен данными из Leaf1, поэтому ClassB не получит разрешения на передачу.В результате работоспособным окажется только клиент leaf3, подключенный в локальную очередь на нулевом уровне.

4. Теперь рассмотрим пример, когда данные будут одновременно передавать leaf1, leaf2, leaf3, ClassB будет желтым, а ClassA зеленым.

Q5 rusqos.jpg

В результате этого на втором уровне leaf2 попадет в очередь первым (так как имеет больший приоритет), а leaf1 и leaf3 подвергнутся случайному выбору для определения порядка следования.

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

Bursts

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

Разработчики Mikrotik предоставили в распоряжение все необходимые инструменты для управления описанной выше пиковой скоростью. Следующие параметры характеризуют ее поведение:

  • burst-limit — скорость, которая будет доступна сразу при подключении;
  • burst-threshold – средняя скорость за последние burst-time секунд;
  • burst-time — время для подсчета burst-threshold.

Момент, когда клиенту или классу нужно выдать максимальную скорость, определяется следующим образом. Раз в 1/16 времени burst-time вычисляется загрузка канала на указанное число секунд. Если средняя загрузка составила менее burst-threshold, то клиенту или классу выделяется указанная в burst-limit скорость до тех пор, пока она не превысит burst-threshold. После этого действует ограничение max-limit до тех пор, пока снова не случится понижение скорости менее burst-threshold.

Установим следующие параметры limit-at=128000/128000, max-limit=256000/256000, burst-limit=512000/512000, burst-treshold=192000/192000, burst-time=8, и понаблюдаем что случится с графиком загрузки канала от одного клиента:

Q6 rusqos.jpg

Данный график характерен для случая с закачкой большого файла по протоколу http. После первой секунды средняя загрузка канала будет равна (0+0+0+0+0+0+0+512)/8=64 kbps, что менее установленного нами параметра burst-threshold. После второй секунды средняя скорость будет равна (0+0+0+0+0+0+512+512)/8=128kbps. После третьей секунды средняя скорость превысит показатель burst-threshold. В этот момент скорость резко упадет до значения параметра max-limit и будет держаться на этом уровне до тех пор, пока средняя загрузка канала не станет меньше burst-threshold и снова не произойдет выдача burst скорости.

Schedulers

Рассмотрим алгоритмы так называемых Schedulers, о которых упоминалось выше. Обычно они применяются вкупе с шейперами, однако некоторые из них так же обладают функциями ограничения скорости. Физически Scheduler предшествует шейперу и представляет ему уже подготовленные очереди пакетов, к которым следует применять ограниения.

PFIFO/BFIFO

Packet/Bytes (FIFO) алгоритм, основанный на принципе первый пришел-первый ушел. Используется для ethernet-интерфейсов. Единственный параметр, используемвый для конфигурирования данного алгоритма, — это pfifo-limit (bfifo-limit). Он указывает на количество байт, которые могут храниться в выходном буфере. Не попавшие в буфер пакеты будут разрушаться. Графически алгоритм можно изобразить с помощью следующей схемы. По сути дела PFIFO/BFIFO ничего особенного из себя не представляет и никаких приемуществ не дает. Он просто есть и используется там, где его использовать целесообразно…

Q7 rusqos.jpg

SFQ (Stochastic Fairness Queuing) – этот алгоритм можно назвать «случайно-честным». Он применятся тогда, когда требуется предоставить всем TCP/UDP-подключениям одинаковую возможность по передаче данных. Для конфигурирования SFQ используется два параметра:

  • sfq-perturb – указывает через какое время нужно менять хэширующий алгоритм, который определяет как будут формироваться под-очередь запросов;
  • pcq-allot – определяет количество байт в под-очереди.

SFQ работает по следующему принципу: алгоритм изымания пакетов из под-очередей одновременно выпускает в выходной интерфейс pcq-allot количество байт, а хэширующий алгоритм добавляет к каждый под-очереди pcq-allot байт, сохраняя при этом равновесие и одинаковую длину всех подочередей. Схему работы SFQ можно сравнить с мясорубкой, в которой через выходную решетку одновременно изо всех дырок в одинаковом количестве выходит фарш :).

Q8 rusqos.jpg

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

PCQ (Per Connection Queuing) является частным случаем SFQ за тем исключением, что формирование потоков в под-очереди будет происходить в соответствии с неким правилом. Это может быть адрес источника/получателя и порт источника/получателя. Таким образом можно равномерно распределить скорость между участниками вне зависимости от количества открытых подключений. Алгоритм предоставляет следующие параметры для конфигурирования:

  • pcq-classifier – параметр для формирования очередей. Может принимать следующие значения:

1. src-address – параметром для группировки в субочереди служит адрес источника; 2. src-port – параметром для группировки в субочереди служит порт источника; 3. dst-address – параметром для группировки в субочереди является адрес назначения; 4. dst-port – параметром для группировки в субочереди служит порт получателя.

  • pcq-rate – число, которое указывает в какой пропорции разделять трафик по очередям. По-умолчанию 0.
  • pcq-limit – длина под-очереди;
  • pcq-total-limit — общее количество пакетов во всех очередях.

Q9 rusqos.jpg

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

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

RED (Random Early Detection) – алгоритм, призванный выравнивать пропускную способность и сглаживать скачки, контролируя средний размер очереди. Когда ее размер достигает значения red-min-threshold алгоритм удаляет случайно выбранный пакет. Число удаленных пакетов растет с увеличением среднегого размера очереди. Если размер достигает значения red-max-threshold все пакеты удаляются. Однако случаются ситуации, когда реальный размер очереди (не средний) значительно больше red-max-threshold. В таком случае все пакеты, выходящие за рамки предела red-limit, удаляются.

Q10 rusqos.jpg

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

От теории к практике

Сейчас мы знаем все необходимое для того, чтобы построить необходимые нам правила. Так как на практике применение алгоритмов SFQ и RED используется крайне редко, то на примерах их работы мы останавливаться не будем.

Queue Trees

Queue Trees — особый тип очередей, который прямо отражает устройство шейпера HTB. Он позволяет строить деревья правил (классов) и на самом низком уровне управлять пакетами.

Вкратце объясним значение основных элементов управления, присутствующих в Queue Trees:

  • burst-limit (целое) – максимальная burst-скорость;
  • burst-threshold (целое) – средняя загрузка канала, при которой разрешено выдать burst-limit;
  • burst-time (время) – используется для подсчета средней загрузки канала;
  • flow (text) – поток, маркированный в /ip firewall mangle;
  • limit-at (целое) – гарантированная скорость;
  • max-limit (целое) – максимальная скорость;
  • name (text) – имя очереди;
  • parent (text) – родитель в иерархии классов HTB;
  • priority (целое: 1..8) – приоритет очереди;
  • queue (text) – тип очереди. Задается в /queue type.

Примеры

I. Итак, создадим правило, которое позволит получить клиентам локальной или виртуальной сети максимальную скорость и минимальное время отклика при обращении к сайту www.drivermania.ru , однако разделит скорость между всеми поровну.

1. Пометим все пакеты идущие от пользователей на адрес 66.148.73.54 и обратно. Для этого нужно создать 4 правила, два из которых пометят подключения в прямом и обратом направлении, а другие два пометят пакеты в этих подключениях. Необходимо обратить внимание, что очереди работают именно с пакетами, а не помеченными подключениями. Зачастую это создает у новичков вопросы плана: «Я пишу все правильно, а оно не работает. Может это глюки?» Для таких шаманов ниже приведен пример, как нужно делать, чтобы ОНО работало.

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

3. Создадим очереди для входящего и исходящего трафика

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

Практически в Queue Trees мы можем оперировать только ограничением скорости. Остальные параметры, такие как адрес источника, получателя, время суток, протокол, порты и т.д. указываются в разделе Mangle-файервола.

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

Для этого нужно создать четыре правила в Firewall:

  • в первом пометим все подключения, у которых адрес получателя 195.222.70.250 именем cybernet-connection-up;
  • пакеты в подключениях cybernet-connection-up именем cybernet-packet-u;
  • в первом пометим все подключения у которых адрес источника 195.222.70.250 именем cybernet-connection-from;
  • пакеты в подключениях cybernet-connection-from именем cybernet-packet-from.

Следующим шагом создадим два правила в Queue Trees: одно для входящего потока, другое для исходящего.

Вышеописанные действия позволят пакетам, приходящим и уходящим с адреса 195.222.70.250, попадать в приоритетные очереди и всегда иметь гарантированные 50 Kbit/s.

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

Simple Queues

Рассмотрим тип очередей Simple Queues. Эти очереди являются простыми, а если быть точнее, то упрощенными. В самом деле для их использования не нужно применять промаркированные пакеты из Firewall, однако при этом теряется некоторая гибкость. Здесь в качестве основных параметров, к которым следует применять правило, относятся адреса источника и получателя. На вкладке Advanced утилиты Winbox можно обнаружить и некоторые другие параметры, однако они не относятся к списку обязательных к заполнению.

Q11 rusqos.JPG

Список текущих возможностей простых очередей выглядит следующим образом:

  • работа с P2P-трафиком;
  • применение очередей в определенных интервалах времени;
  • приоритезация потоков;
  • использование в качестве параметров несколько цепочек пакетов, маркированных в /ip firewall mangle;
  • шейпинг бидеракционного трафика (одно правило для входящего и исходящего потока).

Стоит отметить, что начиная с версии Mikrotik 2.9 в Simple Queues стало возможным указывать параметр Parent для простых очередей. Таким образом можно строить практически аналогичные деревья классов, как и для Queue Trees за тем исключением, что здесь оперировать будем не пакетами и потоками, а адресами.

Стоит так же помнить, что Simple Queues не что иное, как частный случай Queue Trees. Поэтому создавая новые правила стоит обращать внимание не существует ли уже что-то подобное, оперирующее с теми же адресами, портами или другими параметрами. В случае сходства, приоритет окажется на стороне Queue Trees и ваши простые очереди просто не будут работать.

Перед началом составления правил в Simple Queues необходимо понять что есть входящий и исходящий трафик для нашего провайдера, нашего роутера и наших клиентов. На рисунке выше изображена стандартная схема направления потоков трафика от провайдера к нашему роутеру и от роутера к клиенту. Стоит обратить внимание, что исходящий трафик клиента для нашего роутера будет являться входящим и наоборот. То же самое можно сказать про нашего провайдера-исходящий трафик для него-это входящий для нас.

Q12 rusqos.JPG

Список параметров для конфигурирования простых очередей в Mikrototik 2.9.x выглядит следующим образом:

  • burst-limit (целое) – максимальная burst-скорость;
  • burst-threshold (целое) – средняя загрузка канала при которой разрешено выдать burst-limit;
  • burst-time (время) – используется для подсчета средней загрузки канала;
  • dst-address (IP адрес/маска) – адрес назначения;
  • dst-netmask (netmask) – маска подсети для dst-address;
  • interface (text) – интерфейс, для которого предназначается правило;
  • limit-at (целое/целое) – гарантированный канал;
  • max-limit (целое/целое) – максимальная величина канала;
  • name (text) – имя правила;
  • p2p (any | all-p2p | bit-torrent | blubster | direct-connect | edonkey | fasttrack | gnutella | soulseek | winmx) – тип P2P-трафика;
  • packet-marks (name; по умолчанию: «») — цепочка пакетов, промаркированных в /ip firewall mangle;
  • parent (name) – имя родительской очереди;
  • priority (целое: 1..8) – приоритет. 1- больший, 8-самый маленький;
  • queue (name/name; default: default/default) – имя очереди из /queue type;
  • target-addresses (IP address/netmask) – исходный адрес;
  • time (time-time,sat | fri | thu | wed | tue | mon | sun; по умолчанию: «») — применить очередь к временному интервалу;
  • total-burst-limit (целое) – максимальная burst скорость в очереди global-total;• total-burst-threshold (целое) – средняя скорость в очереди global-total;
  • total-burst-time (time) — используется для подсчета средней загрузки канала в очереди global-total;
  • total-limit-at (целое) – гарантированная скорость в очереди global-total (входящий+исходящий каналы);
  • total-max-limit (целое) – максимальная скорость передачи данных в очереди global-total.

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

Примеры

Сэмулируем для нашего клиента канал с 64/42 kbit/s с гарантированной скоростью 32/32 kbit/s в будние дни и 256/128 kbit/s с гарантированной скоростью 64/64 kbit/s в выходные.

Результатом нашей работы будет два правила:

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

Q13 rusqos.jpgQ14 rusqos.jpg

При желании можно позаботиться о быстром открытии страниц, добавив параметры burst-limit и burst-time.

Данное правило можно было бы несколько видоизменить, разделив указанную скорость между всей сетью 192.168.11.0.24. В этом случае для параметра queue нужно указать тип очереди pcq-download, приведенный выше в примере с Queue Trees.

Простые очереди позволяют достаточно просто реализовать возможность предоставления на определенные адреса неограниченной скорости.

Добавим к вышеприведенным правилам ещё одно, которое будет выглядеть следующим образом:

В результате чего клиент с адресом 192.168.11.1 получит доступ к адресу 84.201.225.124 со скоростью от 1 до 2 мегабит.

При выделении гарантированной пропускной способности нужно помнить, что сумма limit-at всех клиентов должна быть меньше или равна общей пропускной способности канала. Только в этом случае можно говорить о какой-то гарантированной скорости.

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

Ещё одно замечание связанно с тем, что напрямую вписать URI-адрес в поле ввода IP-адреса не представляется возможным, но иногда необходимо, так как многие сайты имеют динамические адреса. Данную проблему можно решить, прописав необходимый адрес ресурса в разделе /ip firewall address-list и дав ему имя, по которому в последствии можно обратиться.

Q15 rusqos.jpg

Вывод

Возможности по управлению трафиком в Mikrotik 2.9 претерпели некоторые изменения по сравнению с предыдущими версиями. Это позволило стать этой операционной системе рядом и даже несколько потеснить аппаратные решения от Cisco, сохранив при этом удобство и огромную гибкость в конфигурировании. Объединив Mikrotik и биллинг с поддержкой протокола Radius, можно получить мощную систему, подходящую как для сети среднего провайдера, так и в качестве сервера, раздающего Интернет внутри локальной домашней сети или сети предприятия. Стоит отметить, что вышеописанные возможности шейпинга можно применить не только к разделению доступа в интернет, но и к созданию резервных каналов связи. В сочетании с беспроводными технологиями RouterOS может превратить груду уже никому не нужного металлолома и нескольких беспроводных сетевых карт в мощную Wi-Fi соту с разделением доступа и предоставлением гарантированной полосы пропускания своим клиентам.

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

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