ksg222 Dec 13 2016 at 10:32

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

16 min

55K

CBS corporate blogSystem administration*IT Infrastructure*Cisco*Network technologies*

+26

Comments 15

TimsTims Dec 13 2016 at 17:21

Очень мощная статья.
Всегда было интересно, что происходит с пакетами, когда достигается лимит, а тут такой разбор TCP :)

TimsTims Dec 13 2016 at 17:37

-Я думал, что знаю TCP… (с)

sky-walker Dec 13 2016 at 17:39

К сожалению, с Cisco работал мало, вопрос по Linux: правильно ли я понимаю, в tc на Linux реализован только policer, а собственно шейпинг трафика включается собственно механизмом TCP («медленный старт» и другие алгоритмы), который и сглаживает трафик после потери пакетов?

ksg222 Dec 13 2016 at 18:37

По поводу «tc на Linux», к сожалению, не подскажу. Но TCP slow-start и пр. алгоритмы функций шейпинга и полисера не реализуют. Их задачи совсем другие: обеспечение максимально допустимой скорости передачи данных в рамках TCP сессии. Шейпер и полисер стоят по другу сторону баррикад, ограничивая эту скорость.

EvilMan Dec 14 2016 at 15:58

В tc реализованы как policer, так и shaper трафика. Причём алгоритмов шейпинга несколько, с различными возможностями и сложностью настройки. Это именно шейперы, которые в случае необходимости, «придерживают» пакеты в буфере, выравнивая скорость передачи данных. Алгоритмы контроля перегрузки (congestion control) протокола TCP на конечных хостах уже после подстраиваются под задержки и потери сегментов, замедляя и ускоряя передачу данных.

insekt Dec 14 2016 at 07:09

Хорошая статья, спасибо. Теперь есть на что сослаться, а не объяснять все самому.
Небольшое замечание.
В данном контексте правильно говорить не «полоса пропускания» (единицы измерения Гц), а «пропускная способность» (единицы измерения б/с).

ksg222 Dec 14 2016 at 10:09

Вы правы, спасибо!

paralon Dec 14 2016 at 22:12

Сергей, добрый день. Не могу понять одной вещи.
Вот есть у нас параметр cwnd, о нём пишется:

По умолчанию значение окна перегрузки (congestion window — cwnd) для TCP-сессии в Windows 10 равно 10. Это означает, что данный ПК может отправить сразу 10 пакетов, не дожидаясь получения подтверждения на них в виде ACK.

То есть параметр cwnd вроде как отвечает за количество отправляемых пакетов (полагаю, правильно тут — сегментов, но не суть)

Далее есть параметры ssthresh и awnd:

В качестве начального значения порога прекращения работы алгоритма slow-start (ssthresh) и перехода в режим избегания перегрузки (congestion avoidence) берётся значение максимального окна, которое предоставил получатель (advertised window — awnd). В нашем случае ssthresh=awnd=64K

То есть, «в нашем случае awnd=64 000», и речь уже об объёме данных.
Итого cwnd показывает количество сегментов, awnd — объём данных.
Я не могу понять, как в таком случае сопоставляются данные параметры во фразе

Размер окна cwnd достигает максимального значения и становится равным awnd, а значит, cwnd = ssthersh.

Неужели в нашем случае количество отправляемых пакетов может достигнуть числа 64000?

aremdae Dec 14 2016 at 22:43

Не пытаясь ответить на вопрос, действительно ли cwnd == awnd с алгоритмической точки зрения, замечу, что 64000*1460 (стандартный MSS) = 93440 килобайт. Это не очень много. Здесь ведь не идет речь о том, чтобы отправлять эти данные без ACK. Это максимальное количество данных, которое может быть «в проводе». Т. е. ACK'и могут и в нормальной ситуации должны отправляться чаще, а число в 93440 является критической точкой, после которой передача трафика останавливается до получения ACK.

paralon Dec 14 2016 at 22:48

Я просто увидел фразу

Это означает, что данный ПК может отправить сразу 10 пакетов, не дожидаясь получения подтверждения на них в виде ACK.

и подумал, что cwnd — это всегда количество пакетов, которые можно отправить без ACK. Возможно что подумал неверно, отсюда и вопрос.
Я в данной теории слаб, поэтому и хочу потдверждения\опровежения, что в рамках tcp сессии существует возможность отправить 64 000 сегмента не получая ACK от получателя

ksg222 Dec 14 2016 at 23:16

Все значения (cwnd, awnd, ssthresh) определяют именно объём данных. И когда я писал, что в начале сессии можно передать 10 пакетов без подтверждения, я в неком роде упрощал. И видимо зря. Это внесло путаницу. Изначальное значение cwnd=10*MSS. Т.е. ваше замечание по поводу сегментов тоже верное. Всё-таки мы на транспортном уровне.

paralon Dec 15 2016 at 09:46

Спасибо за ответ в частности, и за статью в принципе!
То есть в итоге, есть некоторый коэффициент, ну допустим «K» (который в начале равен именно 10 в нашем случае), и растёт именно этот «K», пока произведение K*MSS (читай cwnd) не достигнет awnd? Именно этот «K» и определяет «количество отправляемых сегментов без ACK». И например при MSS = 1460 байт, «K» достигнет максимума при значении 64000/1460≈43

ksg222 Dec 15 2016 at 10:49

Если говорить чуточку абстрактно, всё верно. Просто в самом RFC коэффициента «К» нет. Есть только:

CONGESTION WINDOW (cwnd): A TCP state variable that limits the amount
of data a TCP can send. At any given time, a TCP MUST NOT send
data with a sequence number higher than the sum of the highest
acknowledged sequence number and the minimum of cwnd and rwnd.

VFedorV Jan 19 2017 at 15:23

хороший пример шейпера для ISR Вы привели, а есть у кого-нибудь для Cisco ASA? и желательно для туннеля IPSec (cryptomap based VPN)?
что-то типа такого:

access-list LIMIT-10Mbps extended permit tcp any 10.30.0.0 255.255.0.0

class-map LIMIT-10Mbps
match access-list LIMIT-10Mbps

policy-map LIMIT-10Mbps
  class LIMIT-10Mbps
    police output  10000000
     queue-limit 100 packets

Interface GigabitEthernet1/1
 service-policy LIMIT-10Mbps service-policy LIMIT-10Mbps interface office-users

будет работать?! где 10.30.0.0 255.255.0.0 — сети доступные через VPN Site-to-Site

ksg222 Jan 19 2017 at 16:33

Шейпинг поддерживался только на одноядерных ASA (5505, 5510 и пр.). Причём работает крайне нестабильно. На новых такого функционала вообще нет. Пример конфигурации.