ѕодпишитесь на наш Telegram-канал Ѕудьте в курсе последних новостей 👇 😉 ѕодписатьс€
ѕоддержим в трудное врем€ —пециальное предложение на техническую поддержку вашей »“ - инфраструктуры силами наших экспертов ѕодобрать тариф
ѕоставка оборудовани€ √аранти€ и помощь с настройкой. —кидка дл€ наших читателей по промокоду WIKIMERIONET  упить
»нтерфейс статистики Merion Mertics показывает ключевые диаграммы и графики по звонкам, а также историю звонков в формате, который легко поймет менеджер ѕопробовать бесплатно
¬недрение
офисной телефонии
Ўаг на пути к созданию доступных унифицированных коммуникаций в вашей компании ¬недрить
»нтеграци€ с CRM ѕомогаем навести пор€док с данными
и хранить их в единой экосистеме
ѕодключить
»“ Ѕезопасность ”мна€ информационна€ безопасность дл€ вашего бизнеса «аказать
ћерион Ќетворкс

10 минут чтени€

 лассификаци€ сама по себе не приводит к определенному состо€нию переадресации со стороны сетевого устройства. —корее, классификаци€ трафика - это первый необходимый шаг в создании основы дл€ дифференцированного поведени€ пересылки. ƒругими словами, пакеты были классифицированы и дифференцированы, но это все. ¬ы€вление различий - это не то же самое, что дифференцированные действи€ с этими классами.

Ќаше обсуждение QoS теперь переходит в сферу политики.  ак управл€ть перегруженными интерфейсами?  огда пакеты ожидают доставки, как сетевое устройство решает, какие пакеты будут отправлены первыми? “очки прин€ти€ решени€ основаны в первую очередь на том, насколько хорошо пользовательский интерфейс может выдерживать джиттер, задержку и потерю пакетов. ƒл€ решени€ этих проблем возникают различные проблемы и инструменты QoS.


—воевременность: организаци€ очередей с малой задержкой

—етевые интерфейсы пересылают пакеты как можно быстрее.  огда трафик проходит со скоростью, меньшей или равной пропускной способности выходного интерфейса, трафик доставл€етс€ по одному пакету за раз, без каких-либо проблем.  огда интерфейс может соответствовать предъ€вл€емым к нему требовани€м, перегрузки не возникает. Ѕез перегрузок нет необходимости беспокоитьс€ о дифференцированных типах трафика. ќтметки на отдельных пакетах можно наблюдать в статистических цел€х, но политики QoS, которую нужно примен€ть, нет. “рафик поступает на выходной интерфейс и доставл€етс€.

 ак было рассказано ранее в лекции " оммутаци€ пакетов", пакеты доставл€ютс€ в кольцо передачи после коммутации. ‘изический процессор исход€щего интерфейса удал€ет пакеты из этого кольца и синхронизирует их с физической сетевой средой. „то произойдет, если будет передано больше пакетов, чем может поддерживать канал св€зи? ¬ этом случае пакеты помещаютс€ в очередь, выходную очередь, а не в кольцо передачи. ѕолитики QoS, настроенные на маршрутизаторе, фактически реализуютс€ в процессе удалени€ пакетов из очереди вывода на кольцо передачи дл€ передачи.  огда пакеты помещаютс€ в очередь вывода, а не в кольцо передачи, интерфейс считаетс€ перегруженным.

ѕо умолчанию перегруженные сетевые интерфейсы доставл€ют пакеты в пор€дке очереди (FIFO). FIFO не принимает стратегических решений на основе дифференцированных классов трафика; скорее, FIFO просто обслуживает буферизованные пакеты по пор€дку настолько быстро, насколько это позвол€ет выходной интерфейс. ƒл€ многих приложений FIFO - неплохой способ удалени€ пакетов из очереди. Ќапример, в реальном мире может быть небольшое вли€ние, если пакет протокола передачи гипертекста (HTTP, протокол, используемый дл€ передачи информации World Wide Web) с одного веб-сервера передаетс€ раньше, чем пакет с другого веб-сервера.

ƒл€ других классов трафика большое внимание удел€етс€ своевременности. ¬ отличие от FIFO, некоторые пакеты следует переместить в начало очереди и отправить как можно быстрее, чтобы избежать задержки и вли€ни€ на работу конечного пользовател€. ќдно из последствий - это пакет, прибывающий слишком поздно, чтобы быть полезным. ƒругой удар заключаетс€ в том, что пакет вообще не поступает. —тоит рассмотреть каждый из этих сценариев, а затем несколько полезных инструментов QoS дл€ каждого.

√олосовой трафик по IP (VoIP) должен воврем€. ѕри рассмотрении голосового трафика подумайте о любом голосовом чате в реальном времени, который осуществл€етс€ через »нтернет с помощью такого приложени€, как Skype. ¬ большинстве случаев качество св€зи приличное. ¬ы можете слышать другого человека. Ётот человек может вас слышать. –азговор протекает нормально. — таким же успехом вы можете находитьс€ в одной комнате с другим человеком, даже если он находитс€ на другом конце страны.

»ногда качество звонков VoIP может снижатьс€. ¬ы можете услышать серию субсекундных заиканий в голосе человека, при этом скорость передачи голоса нерегул€рна. ¬ этом случае вы испытываете джиттер, что означает, что пакеты не поступают стабильно воврем€. „резмерно длинные промежутки между пакетами привод€т к слышимому эффекту заикани€. ’от€ пакеты не были потер€ны, они не были своевременно доставлены по сетевому пути. √де-то по пути пакеты задерживались достаточно долго, чтобы по€вились слышимые артефакты. Ќа рисунке 5 показан джиттер при пакетной передаче.

 ачество вызова VoIP также может пострадать из-за потери пакетов, когда пакеты на сетевом пути были сброшены по пути. ’от€ существует множество потенциальных причин потери пакетов в сетевых пут€х, рассмотренный здесь сценарий - это "отбрасывание хвоста", когда поступило такое количество трафика, которое выходит за пределы возможностей выходного интерфейса, и в буфере не остаетс€ места дл€ добавлени€ в очередь дополнительных излишков. ¬ результате отбрасываютс€ самые последние поступлени€ трафика; это падение называетс€ хвостовым падением.

 ачество вызова VoIP также может пострадать из-за потери пакетов, когда пакеты на сетевом пути были сброшены по пути. ’от€ существует множество потенциальных причин потери пакетов в сетевых пут€х, рассмотренный здесь сценарий - это "отбрасывание хвоста", когда поступило такое количество трафика, которое выходит за пределы возможностей выходного интерфейса, и в буфере не остаетс€ места дл€ добавлени€ в очередь дополнительных излишков. ¬ результате отбрасываютс€ самые последние поступлени€ трафика; это падение называетс€ хвостовым падением.

 огда трафик VoIP отбрасываетс€, слушатель слышит результат потери. ≈сть пробелы, в которых голос говор€щего полностью отсутствует. ќтброшенные пакеты могут проходить в виде тишины, поскольку последний бит прин€того звука зацикливаетс€, чтобы заполнить пробел, продолжительное шипение или другой цифровой шум. Ќа рисунке ниже показаны отброшенные пакеты через маршрутизатор или коммутатор.

Jitter при доставке пакетов в —ети? ќтброшенные пакеты через маршрутизатор или коммутатор

„тобы обеспечить стабильное качество вызовов даже в услови€х перегруженности сетевого пути, необходимо примен€ть схему приоритезации QoS. Ёта схема должна соответствовать следующим критери€м.

  • “рафик VoIP должен быть доставлен: потер€ пакетов VoIP приводит к слышимому прерыванию разговора.
  • “рафик VoIP должен доставл€тьс€ воврем€: задержка или прерывание пакетов VoIP приводит к слышимым заикани€м.
  • “рафик VoIP не должен ограничивать пропускную способность других классов трафика: так же важно, как и VoIP, хорошо написанные политики QoS уравновешивают своевременную доставку голосовых пакетов с необходимостью дл€ других классов трафика также использовать канал.

–аспространенной схемой, используемой дл€ определени€ приоритетов трафика, чувствительного к потер€м и jitter, €вл€етс€ организаци€ очередей с низкой задержкой (LLQ). Ќикакие RFC IETF не определ€ют LLQ; скорее, поставщики сетевого оборудовани€ изобрели LLQ в качестве инструмента в наборе политик QoS дл€ определени€ приоритетов трафика, требующего низкой задержки, jitter и потерь, например, голоса.

LLQ есть два ключевых элемента.

  • “рафик, обслуживаемый LLQ, передаетс€ как можно быстрее, чтобы избежать задержки и минимизировать джиттер.
  • “рафик, обслуживаемый LLQ, не может превышать определенный объем полосы пропускани€ (обычно рекомендуетс€ не более 30% доступной полосы пропускани€). “рафик, превышающий предел пропускной способности, скорее отбрасываетс€, чем передаетс€. Ётот метод позвол€ет избежать потери трафика других классов.

¬ этой схеме подразумеваетс€ компромисс дл€ услуг классов трафика посредством LLQ. “рафик будет обслуживатьс€ как можно быстрее, эффективно перемеща€ его в начало очереди, как только он обнаруживаетс€ на перегруженном интерфейсе. «агвоздка в том, что существует ограничение на то, сколько трафика в этом классе будет обрабатыватьс€ таким образом. Ёто ограничение налагаетс€ сетевым инженером, составл€ющим политику QoS.

¬ качестве иллюстрации предположим, что канал WAN имеет доступную пропускную способность 1024  бит/с. Ётот канал соедин€ет головной офис с облаком WAN поставщика услуг, которое также соедин€ет несколько удаленных офисов с головным офисом. Ёто загруженный канал WAN, по которому проходит трафик VoIP между офисами, а также трафик веб-приложений и резервный трафик врем€ от времени.  роме того, предположим, что система VoIP кодирует голосовой трафик с помощью кодека, требующего 64  бит/с на разговор.

“еоретически, этот канал с пропускной способностью 1024  бит/с может обеспечить одновременные разговоры VoIP 16 × 64  бит/с. ќднако это не оставит места дл€ других типов трафика, которые присутствуют. Ёто зан€тое соединение WAN! –ешение должно быть прин€то при написании политики QoS. —колько голосовых разговоров будет разрешено LLQ, чтобы избежать нехватки оставшегос€ трафика полосы пропускани€? ћожно было бы сделать выбор, чтобы ограничить LLQ пропускной способностью только 512  бит/с, что было бы достаточно дл€ обработки восьми одновременных разговоров, оставив остальную часть канала WAN дл€ других классов трафика.

ѕредполага€, что канал перегружен, что произойдет с дев€тым разговором VoIP, если он должен находитьс€ в ситуации, чтобы политика QoS была эффективной? Ётот вопрос на самом деле наивен, потому что он предполагает, что каждый разговор обрабатываетс€ отдельно политикой QoS. ‘актически, политика QoS рассматривает весь трафик, обслуживаемый LLQ, как одну большую группу пакетов. ѕосле присоединени€ дев€того разговора VoIP будет трафик на 576  бит/с, который будет обслуживатьс€ LLQ, которому выделено только 512  бит/с. „тобы найти количество отброшенного трафика, вычтите общий трафик, выделенный дл€ LLQ, из общего предлагаемого трафика: 576  бит/с - 512  бит/с = 64  бит/с трафик LLQ будет отброшен в соответствии с ограничением полосы пропускани€. ќтброшенные 64  бит/с будут исходить от класса трафика LLQ в целом, что повли€ет на все разговоры VoIP. ≈сли дес€тый, одиннадцатый и двенадцатый разговор VoIP присоединитьс€ к LLQ, проблема станет более серьезной. ¬ этом случае 64  бит/с × 4 = 256  бит/с несоответствующего трафика, который будет отброшен из LLQ, что приведет к еще большим потер€м во всех разговорах VoIP.

 ак показывает этот пример, дл€ управлени€ перегрузкой необходимо знать состав приложений, врем€ пиковой нагрузки, требовани€ к полосе пропускани€ и доступные варианты сетевой архитектуры. “олько после того, как будут учтены все моменты, можно найти решение, отвечающее бизнес-цел€м. Ќапример, предположим, что 1024  бит/с - это максимальное значение, которое вы можете сделать дл€ линии дальней св€зи из-за ограничений по стоимости. ¬ы можете увеличить ограничение полосы пропускани€ LLQ до 768  бит/с, чтобы обеспечить 12 разговоров со скоростью 64  бит/с каждый. ќднако дл€ другого трафика останетс€ только 256  бит/с, чего, возможно, недостаточно дл€ удовлетворени€ потребностей вашего бизнеса в других приложени€х.

¬ этом случае можно согласовать с администратором системы голосовой св€зи использование голосового кодека, требующего меньшей полосы пропускани€. ≈сли новый кодек, требующий только 16  бит/с полосы пропускани€ на вызов, развернут вместо исходных 64  бит/с, 32 разговора VoIP могут быть перенаправлены без потерь через LLQ с выделенной полосой пропускани€ 512  бит/с.  омпромисс?  ачество голоса. „еловеческий голос, закодированный со скоростью 64  бит/с, будет звучать более четко и естественно по сравнению с голосом, закодированным на скорости 16  бит/с. “акже может быть лучше кодировать со скоростью 16  бит/с, чтобы отбрасывать меньше пакетов и, следовательно, общее качество лучше.  акое решение применить, будет зависеть от конкретной ситуации.

„ерез интерфейс может пройти больше трафика, чем указано в ограничении полосы пропускани€ LLQ. ≈сли ограничение полосы пропускани€ дл€ трафика, обслуживаемого LLQ, установлено на максимум 512  бит/с, возможно, что трафик класса более чем на 512  бит/с пройдет через интерфейс. “акое запрограммированное поведение про€вл€етс€ только в том случае, если интерфейс не перегружен. ¬ исходном примере, где используетс€ кодек 64  бит/с, передача 10 разговоров со скоростью 64  бит/с по каналу приведет к передаче голосового трафика 640  бит/с по каналу пропускной способности 1024  бит/с (1024  бит/с - 640  бит/с = 384  бит/с осталось). ѕока все другие классы трафика остаютс€ ниже общего использовани€ полосы пропускани€ 384  бит / с, канал не будет перегружен. ≈сли канал не перегружен, политики QoS не вступают в силу. ≈сли политика QoS не действует, то ограничение полосы пропускани€ LLQ в 512  бит/с не вли€ет на 640  бит/с агрегированного голосового трафика.

¬ этой статье о LLQ контекстом был голосовой трафик, но имейте в виду, что LLQ может примен€тьс€ к любому желаемому виду трафика. ќднако в сет€х, где присутствует VoIP, VoIP обычно €вл€етс€ единственным трафиком, обслуживаемым LLQ. ƒл€ сетей, в которых нет трафика VoIP, LLQ становитс€ интересным инструментом, гарантирующим своевременную доставку с малой задержкой и дрожанием других видов трафика приложений. ќднако LLQ - не единственный инструмент, доступный дл€ составител€ политики QoS. “акже пригод€тс€ несколько других инструментов.