1. Чем определяется QoS?

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

pageПотериpageЗадержкиpageДжиттер

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

Тогда все пакеты пролетают насквозь в том же порядке, в котором они пришли и не испытывают никаких дополнительных задержек — негде задерживаться. Но на самом деле каждый маршрутизатор восстанавливает из сигнала биты и пакеты, что-то с ними делает (об этом пока не думаем) и потом обратно преобразует пакеты в сигнал. Появляется задержка сериализации. Но в целом это не страшно поскольку она постоянна. Не страшно до тех пор, пока ширина выходного интерфейса больше, чем входного. Например, на входе в устройство гигабитный порт, а на выходе радио-релейная линия 620 Мб/с, подключенная в такой же гигабитный порт? Никто не запретит пулять через формально гигабитный линк гигабит трафика. Ничего тут не поделаешь — 380 Мб/с будут проливаться на пол. Вот они — потери.

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

Или входных интерфейсов пять, а выходной один, и одновременно пять узлов начали пытаться влить трафик одному получателю. Добавим щепотку теории VoIP (статью, про который никто так и не написал) — он весьма чувствителен к задержкам и их вариации. Если для TCP-потока видео с youtube (на момент написания статьи QUIC — ещё остаётся экспериментом) задержки даже в секунды ровным счётом ничего не стоят благодаря буферизации, то директор после первого же такого разговора с камчаткой призовёт к себе руководителя тех.отдела. В более старые времена, когда автор цикла ещё делал уроки по вечерам, проблема стояла особенно остро. Модемные соединения имели скорость 56к.

И когда в такое соединение приходил полуторакилобайтный пакет, он оккупировал всю линию на 200 мс. Никто другой в этот момент пройти не мог. Голос? Не, не слышал. Отсюда и такие невеликие значения MTU. 1500 как максимальный MTU гарантировало, что пакет не будет висеть в очереди уж очень долго.Поэтому таким важным является вопрос MTU - пакет не должен слишком надолго оккупировать интерфейс. Чем менее он скоростной, тем меньший MTU необходим.Вот они — задержки. Сейчас канал свободен и задержка низкая, через секунду кто-то начал качать большой файл и задержки выросли. Вот он — джиттер.

Таким образом нужно, чтобы голосовые пакеты пролетали через трубу с минимальными задержками, а youtube подождёт.

Имеющиеся 620 Мб/с нужно использовать и для голоса, и для видео, и для B2B клиентов, покупающих VPN. Хотелось бы, чтобы один трафик не притеснял другой, значит нужна гарантия полосы.

Last updated

Revision created on 9/3/2018