Чем определяется QoS?
𝔯𝔱_𝔣𝔞𝔫И вот мы дошли до темы QoS.
Знаете почему только сейчас, и почему это будет закрывающая статья всего курса? Потому что QoS необычайно сложен. Сложнее всего, что было прежде в цикле.
Это не какой-то магический архиватор, который ловко сожмёт трафик на лету и пропихнёт ваш гигабит в стомегабитный аплинк. QoS - это о том как пожертвовать чем-то ненужным, впихивая невпихуемое в рамки дозволенного.
QoS настолько опутан аурой шаманизма и недоступности, что все молодые (и не только) инженеры стараются тщательно игнорировать его существование. Считая, что достаточно закидать проблемы деньгами, и бесконечно расширяя линки. Правда пока они не осознают, что при таком подходе их неизбежно ждёт провал. Или бизнес начнёт задавать неудобные вопросы, или возникнет масса проблем, почти не связанных с шириной канала, зато прямо зависящих от эффективности его использования. Ага, VoIP активно машет ручкой из-за кулис. А мультикастовый трафик ехидно поглаживает вас по спинке.
Поэтому давайте просто осознаем, что QoS это обязательно. Познать его придётся так или иначе. И почему бы не начать сейчас, в спокойной обстановке.
До того как читатель нырнёт в эту нору, я заложу в него три установки:
— Не все проблемы можно решить расширением полосы.
— QoS не расширяет полосу.
— QoS про управление ограниченными ресурсами.
Бизнес ожидает от сетевого стека того, что он будет просто хорошо выполнять свою несложную функцию — доставлять битовый поток от одного хоста до другого: без потерь и за предсказуемое время.
Из этого короткого предложения можно вывести все метрики качества сети:
Потери.
Эта метрика говорит о том, сколько из отправленных источником пакетов дошло до адресата.
Причиной потерь могут быть: проблема в интерфейсе/кабеле, перегрузка сети, битовые ошибки, блокирующие правила ACL.
Что делать в случае потерь решает приложение. Оно может проигнорировать их, как в случае с телефонным разговором, где запоздавший пакет уже не нужен. Или перезапросить его отправку — так делает TCP, чтобы гарантировать точную доставку исходных данных.
Задержки.
Это время, которое необходимо данным, чтобы добраться от источника до получателя.
Совокупная задержка складывается из следующих компонентов:
- Задержка сериализации (Serialization Delay) — время, за которое узел разложит пакет в биты и поместит в линк к следующему узлу. Она определяется скоростью интерфейса. Так, например, передача пакета размером 1500 байт через интерфейс 100Мб/с займёт 0,0001 с, а на 56 кб/с — 0,2 с.
- Задержка передачи сигнала в среде (Propagation Delay) — результат ограниченной скорости света. Физика не позволяет добраться из Нью-Йорка до Томска по поверхности планеты быстрее чем за 30 мс (фактически порядка 70 мс).
- Задержки, вносимые QoS — это томление пакетов в очередях (Queuing Delay) и последствия шейпинга (Shaping Delay). Об этом мы сегодня будем говорить много и нудно в главах Управление перегрузками и Ограничение скорости.
- Задержка обработки пакетов (Processing Delay) — время на принятие решения, что делать с пакетом: lookup, ACL, NAT, DPI, — и доставку его от входного интерфейса до выходного. Но с того дня, когда Juniper в своём M40 разделил Control и Data Plane, задержку обработки перестали брать во внимание, т.е. ей можно пренебречь.
Задержки не так страшны приложениям, где не требуется спешка: обмен файлами, сёрфинг, VoD, интернет-радиостанции и т.д. И напротив, они критичны для интерактивных: 200мс уже неприятны на слух при телефонном разговоре.
Связанный с задержкой термин, но не являющийся синонимом — RTT (Round Trip Time) — это путь туда-обратно. При пинге и трассировке вы видите именно RTT, а не одностороннюю задержку, хотя величины и имеют корреляцию.
Джиттер.
Разница в задержках между доставкой последовательных пакетов называется джиттером.
Как и задержка, джиттер для многих приложений не имеет значения. И даже, казалось бы, какая разница — пакет доставлен, чего же боле?
Однако для интерактивных сервисов он важен. Возьмём в качестве примера ту же телефонию. По сути она является оцифровкой аналоговых сигналов с разбиением на отдельные чанки (порции) данных. На выходе получается достаточно равномерный поток пакетов. На принимающей стороне есть небольшой буфер фиксированного размера, в который укладываются последовательно поступающие пакеты. Для восстановления аналогового сигнала необходимо определённое их количество. В условиях плавающих задержек следующий чанк данных может не прийти вовремя. Что равносильно потере, и сигнал не удаcтся восстановить.
Наибольший вклад в вариативность задержки вносит как раз QoS. Об этом тоже много и нудно в тех же главах Управление перегрузками и Ограничение скорости. Потери, Задержки и Джиттер - основные характеристики качества сети, но есть две другие, которые тоже играют не последнюю роль.
Неупорядоченная доставка.
Ряд приложений, таких как телефония, NAS, CES экстремально чувствительны к неупорядоченной доставке пакетов. Т.е. когда они приходят к получателю не в том порядке, в котором были отправлены. Это может приводить к потере связности, ошибкам, повреждению файловой системы.
И хотя неупорядоченная доставка не является формально характеристикой QoS, но определённо относится к качеству сети.
Даже в случае TCP, толерантного к этому виду проблем, происходят дублирующиеся ACK'и и ретрансмиты.
Полоса пропускания.
Её не выделяют как метрику качества сети, поскольку фактически её недостаток выливается в три указанные выше. Однако в наших реалиях: когда некоторым приложениям она должна быть гарантирована, или, наоборот, по договору должна быть ограничена, а, например, MPLS TE её резервирует на всём протяжении LSP, - упомянуть её, хотя бы как слабую метрику, стоит.