Каталог провайдеров Волгограда

Шейпер

Это плохая, даже больше, невежественная статья вводящая в заблуждение. Если вы никак, или плохо разбираетесь в механизмах полисинга и шейпинга не читайте её. Прочитайте “Cisco QoS Exam Certification Guide” Wendell Odom 6 главу, можно не читать дальше концепта. Если же вы достаточно в себе уверены, то можете оценить глубину заблуждения попытки выдать результаты наблюдаемого явления за его суть. Мне по-прежнему не нравятся графики которые приводятся в подобных статьях про полисинг и шейпинг, где показана зависимость скорости от времени (график ускорения), а не количество данных от времени (график скорости), но здесь эта проблема тоже не решена корректно.

  1. Пример 1
  2. Пример 2
  1. Пример 3
  1. Заключение

Шейпинг в общем случае полисинг - совокупность механизмов управления потоком данных для передачи заданного объёма и типа информации в единицу времени. Так как IP сети в своей основе не поддерживают общих встроенных механизмов управления потоком, то однозначно определить произвольную скорость передачи или даже дробную к установленной скорости физического интерфейса является проблематичным. Хотя такие механизмы по отдельности есть на уровнях [Ethernet](https://wikipedia.org/wiki/Ethernet _flow_control) и в TCP, в сетях с коммутацией каналов, Frame Relay (где определены канальные механизмы сквозного взаимодействия между источником и приёмником), а также в других протоколах, но вместе в гетерогенной сети объединяющей множество технологий и протоколов такого механизма не определено. В тоже время необходимость в этом существует во многих практических областях, например, для распределение клиентов интернет провайдера в одном выделенном канале от магистрального провайдера.

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

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

Так как мы говорим о цифровых сетях передачи данных, ещё одной дискретной величиной является время. То есть, ни одно устройство не может определить произвольный параметр в произвольное время. Кванты времени строго фиксированы - каждую секунду, каждую микросекунду, и т.д. В общем случае самое минимальное значение это каждый тик, задающего временного генератора. В том числе и поэтому, чтобы быть более точным, на сетевых интерфейсах накапливается общее количество переданных октетов (байтов) и фрагментов (пакетов), а скорость передачи это уже производное значение вычисляемое отдельно.

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

Рассмотрим ряд примеров. Для простоты восприятия будем рассматривать целые значения не привязанные к конкретным протоколам, но не забываем что пакет данных это не прихоть, ввиду наличия в нём служебных данных: заголовков, контрольной суммы - нельзя принять его частично или произвольно его сформировать.

Пример 1

Вычислим за сколько передаётся один байт данных, это одна сотая - 0,01 секунды. Соответственно пакет с данными будет передан за одну десятую - 0,1 секунды. Скорость 90 байт/c это ровно 9 пакетов в секунду. Следовательно при заданной скорости передатчика 9 пакетов будет передано за 0,9 секунды, а не за целую секунду как того требуют условия задачи, поэтому оставшуюся часть секунды данные передавать не должны, иначе скорость будет превышена. И вот здесь начинается работа шейпера или полисера. Так как мы не можем передавать каждый байт медленнее, по той причине что никак не влияем на передатчик, следующие 10 байт необходимо задержать для дальнейшей передачи - это шейпер, или вообще не передавать - это полисер.

Если у нас полисер, то следующая секунда будет идентична предыдущей и в каждом цикле мы теряем по 10 байт.

Полисер. Пример 1.

Если шейпер, то следующая секунда начнётся с буферизированного пакета. Но скорость передатчика у нас не изменилась, а с помощью лишнего пакета который мы сохранили она дополнительно увеличилась, поэтому следующую секунду надо передать 1 сохранённый пакет + 10 пакетов с передатчика то есть фактическая скорость 11 пакетов в секунду или 110 байт секунду. Но по условию задачи мы должны передавать только 9 пакетов в секунду, таким образом на второй секунде мы должны будем сохранить уже 2 пакета в буфере.

Шейпер. Пример 1.

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

Пример 2

Учтём дискретность потока

85 байт это 8,5 пакетов, в отличие от первого примера мы должны передавать дробное количество пакетов. Так как пакет является неделимой частью поэтому передать половину пакета мы не можем - либо всё, либо ничего. И вот тут в силу вступают различные алгоритмы поведения, основанные в общем случае на усреднении битовой скорости и допущении что мгновенная скорость может быть превышена или недостаточной.

Если следовать правилам из первого примера, то полисер должен отбросить пакет и тогда скорость передачи будет 80 байт/с, что меньше заданной.

Полисер. Пример 2.

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

Шейпер. Пример 2.

Однако если говорить о большем периоде, применение различных алгоритмов позволяет удерживать скорость равную заданной на длительных промежутках времени, например, в первую секунду передать пакет целиком - 90 байт/c, а во вторую секунду отбросить - 80 байт/c (шейпер этот пакет сохранит для последующей передачи).

Полисер. Пример 2.1.

Таким образом за две секунды средняя скорость передачи будет равна (90+80)/2 = 85 байт/c. Явление изменяемости скорости передачи в единицу времени носит название jitter и вносит своё негативное влияние в данные которые требуют высокой стабильности потока: голос и видео.

Шейпер. Пример 2.1.

Следствие

Важный вывод из второго примера - чем больше пакет тем вероятнее что граница ограничения придётся как раз на него и все данные будут потеряны, не важно передан 1 байт из 100 байтного пакета или 99 байт. Поэтому чем пакет меньше тем надёжнее, так поступает, например, постоянно уменьшая размер фрагментов данных при ухудшении качества канала.

Пример 3

Добавим дискретное время

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

Дискретный период определён в 1 секунду, поэтому рассчитать скорость за более короткий период или что-то делать до истечения этого времени мы не сможем. По прошествии первой секунды мы вычислили скорость 200 байт/c, но наше ограничение составляет 90 байт/c, следовательно следующий квант времени надо передать столько данных чтобы первоначальное ограничение было выполнено. Полисер прекратит передачу на следующую секунду и данные будут потеряны, но при этом мы всё равно будем иметь скорость передачи 100 байт/c больше необходимого, соответственно и следующую секунду данные передаваться также не будут, хотя они и поступают от источника - итоговый результат около 67 байт/c.

Полисер. Пример 3.

Шейпер предварительно сохранит данные в буфер, таким образом первую секунду передача остановлена, в этом время заполняется буфер и считается скорость, следующую секунду мы навёрстываем простой первой секунды передавая 180 байт или 18 пакетов, третью секунду отдаём остаток в 20 байт и заполняем буфер вновь пришедшим потоком от источника. Средняя скорость будет такая же как в случае с полисером, но данные потеряны не будут.

Шейпер. Пример 3.

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

Burst

Ещё одним важным понятием связанным с квантованием времени является burst. Это величина задаваемая в количестве данных - октетах/байтах которые могут быть переданы сверх установленного лимита в единицу времени, прежде чем устройство начнёт ограничивать передачу, и в основном применима только для полисеров. Так как для каждого потока существует максимальный практический и теоретический предел больше которого источник послать не сможет - скорость физического интерфейса, то фактически burst устанавливает насколько коротким должен быть интервал квантования и какова максимальная допустимая мгновенная скорость передачи.

200 байт/c (скорость интерфейса) - 90 байт/c (наше ограничение) = 110 байт/c разделим на burst 110 байт получим частоту вычисления скорости передачи 1 раз за секунду, так мы поступаем в 3 примере, где у нас в первую секунду достигается максимальная возможная скорость передачи.

Если burst задать 10 байт, то 200 байт/c (скорость интерфейса) - 90 байт/c (наше ограничение) = 110 байт/c разделим на burst 10 байт получим частоту вычисления скорости передачи 11 раз за секунду, то есть минимальный квант времени чуть больше 1 десятой секунды (можно сравнить со значениями из первого примера). Чем чаще мы вычисляем скорость, тем точнее мы следуем ограничению. График ниже наглядно это показывает.

Burst.

А если burst равен 0 байт, то 200 байт/c - 90 байт/c = 110 байт/c разделить на 0 байт получили бесконечное количество опросов за единицу времени, это приводит нас к выводу о том что всегда существует некоторое допущения в любой передаче, и строго соответствовать заданному ограничению невозможно с практической точки зрения. Достаточная точность средний размер пакета в потоке, большего не требуется, потому что пакеты передаются только целиком.

Заключение

Приведённые выше примеры, конечно, не отражают всей действительности поведения устройств и являются лишь понятийным определением происходящих событий. Шейпер как механизм ограничения скорости эффективен только на очень низких (по современным меркам) скоростях передачи в 1-2 Мегабита в секунду. Потому что память для хранения передаваемых данных является очень дорогим инструментом, а чем больше скорости тем больше данных надо сохранять. Но при этом шейпер играет очень важную роль - когда канал связи очень медленный тратить время на повторную передачу данных является накладным процессом.

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

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