**Настройка QoS в RouterOS (издание 2020)**
**Введение:**
В этой статье представлено общее руководство по реализации QoS с использованием MikroTik RouterOS. Качество обслуживания (QoS) – обширная тема. Поэтому эта короткая статья не будет пытаться охватить все крайние случаи, сравнивать многочисленные алгоритмы или давать глубокие сведения о приоритизации пакетов. Однако, можно добиться хороших, даже отличных результатов, создавая простые классификации и действия для наиболее распространенных потоков трафика. Приведенная здесь конфигурация подходит для малого бизнеса, домашней сети, IP-телефонии и игровых сред, где одно устройство обеспечивает управление QoS.
**Зачем приоритизировать трафик?**
Как правило, это связано с перегрузкой сети. Это чаще всего происходит, когда два или более приложений запрашивают достаточно данных, чтобы превысить пропускную способность интерфейса. Возможно, вы хотите планировать заранее, зная, что будет перегрузка. Даже когда отдельные приложения и протоколы хорошо справляются с управлением сами по себе, они не осознают влияние, которое они оказывают на остальную сеть. QoS – это своего рода сетевой контроллер, который следит за всеми потоками пакетов и принимает разумные решения для всех. Поскольку сетевые интерфейсы работают последовательно, интерактивный трафик будет ждать, пока не будут обработаны многочисленные пакеты, стоящие перед ним, от трафика, занимающего много места. Даже если вы могли бы позволить себе больше интернет-соединений и больше маршрутизаторов, сети все равно может быть перегружена. Поэтому приоритизация вашей сети — это механизм QoS для управления различными типами потоков трафика.
**Типы трафика:**
Вам нужно классифицировать как минимум три типа: интерактивный, сетевой и большой (бульварный). В целях этой статьи VoIP-пакеты считаются интерактивным трафиком и являются наиболее важными. Сетевой трафик состоит из DNS, ICMP и ACK пакетов. К категории большого трафика относятся HTTP и QUIC. Также есть категория "все остальное", которая получает самый низкий приоритет. Когда происходит наш интерактивный трафик, мы гарантируем, что он никогда не будет заблокирован другими типами. Фактически, все остальные типы трафика будут иметь вторичное значение в течение потоков VoIP-пакетов, но только когда сеть находится под угрозой перегрузки. Используйте нашу модель в качестве руководства и создайте свои собственные категории.
**Как определить типы трафика:**
Существует несколько способов. У некоторых приложений есть стандартные номера портов, такие как DNS. Возможно, у вас есть оборудование, устанавливающее биты DSCP. Вы также можете проверить IP-адреса, MAC-адреса или даже VLAN-ID, чтобы узнать важность пакетов, поступающих из этих местоположений. Также возможно проверить скорость передачи байтов для идентификации потокового трафика. Знание типов используемых приложений и их требований к пропускной способности поможет вам правильно определить, что важно или, по крайней мере, в какую категорию его следует отнести.
[Изображение, URL: /upload/forum/mikrotik/6677e5e82af2374ea249f7dbbc40616db933d7ee.png]
**Как работают интерфейсы и QoS вместе:**
Полезно немного понять работу интерфейсов, очередей и формирования трафика, прежде чем переходить к реализации. Представьте интерфейсы как ведра, а пакеты — как разные цветные жидкости. Эти ведра имеют дренажный порт внизу, чтобы выпустить жидкость. На наши ведра выливают красные, зеленые и синие жидкости. Таким образом, у нас есть два момента: скорость дренажного порта и размер ведра. Если каждые 5 минут прибывает пять пакетов, легко понять, что наше ведро с этим прекрасно справится. Но если каждый 10 000 пакетов прибывает каждую секунду, у нас возникнут проблемы. Мы могли бы ускорить порт, например, с интерфейсом 100GbE. Но это имеет побочные эффекты, и не всегда доступно приобретение более быстрых интерфейсов. Мы могли бы взять ведро побольше. Ведро настолько большое, что в нем может поместиться слон. К сожалению, последняя капля красного может занять слишком много времени, пока вся синяя жидкость не стечет. Независимо от скорости нашего дренажного порта или размера ведра, оно может быть настолько задействовано, что не сможет справиться с входящими данными. Наше ведро может переполниться, выбрасывая часть пакетов. При использовании QoS мы используем характеристики порта и ведра, но мы также уведомляем те, кто выливает жидкости, чтобы они выпускали их более ответственным образом для нашей пропускной способности. Если они этого не сделают, мы примем меры, чтобы гарантировать, что пакеты, которые для нас наиболее важны, не переполнятся. С помощью QoS это делается путем отбрасывания пакетов. Естественно, некоторые пакеты нельзя отбрасывать без влияния на пользовательский опыт. Мы планируем это соответствующим образом.
**Отказ от ответственности:**
То, что представлено ниже, — это мое лучшее понимание того, как реализовать заявленные цели. Не следует включать FastTrack. Требуется обратная связь от MikroTik, а также от членов форума, чтобы сделать этот документ точным. Пожалуйста, предложите изменения, которые следует внести. Давайте сделаем этот вопрос общепонятным.
Особая благодарность bharrisau за тестирование и обратную связь.
**Введение:**
В этой статье представлено общее руководство по реализации QoS с использованием MikroTik RouterOS. Качество обслуживания (QoS) – обширная тема. Поэтому эта короткая статья не будет пытаться охватить все крайние случаи, сравнивать многочисленные алгоритмы или давать глубокие сведения о приоритизации пакетов. Однако, можно добиться хороших, даже отличных результатов, создавая простые классификации и действия для наиболее распространенных потоков трафика. Приведенная здесь конфигурация подходит для малого бизнеса, домашней сети, IP-телефонии и игровых сред, где одно устройство обеспечивает управление QoS.
**Зачем приоритизировать трафик?**
Как правило, это связано с перегрузкой сети. Это чаще всего происходит, когда два или более приложений запрашивают достаточно данных, чтобы превысить пропускную способность интерфейса. Возможно, вы хотите планировать заранее, зная, что будет перегрузка. Даже когда отдельные приложения и протоколы хорошо справляются с управлением сами по себе, они не осознают влияние, которое они оказывают на остальную сеть. QoS – это своего рода сетевой контроллер, который следит за всеми потоками пакетов и принимает разумные решения для всех. Поскольку сетевые интерфейсы работают последовательно, интерактивный трафик будет ждать, пока не будут обработаны многочисленные пакеты, стоящие перед ним, от трафика, занимающего много места. Даже если вы могли бы позволить себе больше интернет-соединений и больше маршрутизаторов, сети все равно может быть перегружена. Поэтому приоритизация вашей сети — это механизм QoS для управления различными типами потоков трафика.
**Типы трафика:**
Вам нужно классифицировать как минимум три типа: интерактивный, сетевой и большой (бульварный). В целях этой статьи VoIP-пакеты считаются интерактивным трафиком и являются наиболее важными. Сетевой трафик состоит из DNS, ICMP и ACK пакетов. К категории большого трафика относятся HTTP и QUIC. Также есть категория "все остальное", которая получает самый низкий приоритет. Когда происходит наш интерактивный трафик, мы гарантируем, что он никогда не будет заблокирован другими типами. Фактически, все остальные типы трафика будут иметь вторичное значение в течение потоков VoIP-пакетов, но только когда сеть находится под угрозой перегрузки. Используйте нашу модель в качестве руководства и создайте свои собственные категории.
**Как определить типы трафика:**
Существует несколько способов. У некоторых приложений есть стандартные номера портов, такие как DNS. Возможно, у вас есть оборудование, устанавливающее биты DSCP. Вы также можете проверить IP-адреса, MAC-адреса или даже VLAN-ID, чтобы узнать важность пакетов, поступающих из этих местоположений. Также возможно проверить скорость передачи байтов для идентификации потокового трафика. Знание типов используемых приложений и их требований к пропускной способности поможет вам правильно определить, что важно или, по крайней мере, в какую категорию его следует отнести.
[Изображение, URL: /upload/forum/mikrotik/6677e5e82af2374ea249f7dbbc40616db933d7ee.png]
**Как работают интерфейсы и QoS вместе:**
Полезно немного понять работу интерфейсов, очередей и формирования трафика, прежде чем переходить к реализации. Представьте интерфейсы как ведра, а пакеты — как разные цветные жидкости. Эти ведра имеют дренажный порт внизу, чтобы выпустить жидкость. На наши ведра выливают красные, зеленые и синие жидкости. Таким образом, у нас есть два момента: скорость дренажного порта и размер ведра. Если каждые 5 минут прибывает пять пакетов, легко понять, что наше ведро с этим прекрасно справится. Но если каждый 10 000 пакетов прибывает каждую секунду, у нас возникнут проблемы. Мы могли бы ускорить порт, например, с интерфейсом 100GbE. Но это имеет побочные эффекты, и не всегда доступно приобретение более быстрых интерфейсов. Мы могли бы взять ведро побольше. Ведро настолько большое, что в нем может поместиться слон. К сожалению, последняя капля красного может занять слишком много времени, пока вся синяя жидкость не стечет. Независимо от скорости нашего дренажного порта или размера ведра, оно может быть настолько задействовано, что не сможет справиться с входящими данными. Наше ведро может переполниться, выбрасывая часть пакетов. При использовании QoS мы используем характеристики порта и ведра, но мы также уведомляем те, кто выливает жидкости, чтобы они выпускали их более ответственным образом для нашей пропускной способности. Если они этого не сделают, мы примем меры, чтобы гарантировать, что пакеты, которые для нас наиболее важны, не переполнятся. С помощью QoS это делается путем отбрасывания пакетов. Естественно, некоторые пакеты нельзя отбрасывать без влияния на пользовательский опыт. Мы планируем это соответствующим образом.
**Отказ от ответственности:**
То, что представлено ниже, — это мое лучшее понимание того, как реализовать заявленные цели. Не следует включать FastTrack. Требуется обратная связь от MikroTik, а также от членов форума, чтобы сделать этот документ точным. Пожалуйста, предложите изменения, которые следует внести. Давайте сделаем этот вопрос общепонятным.
Особая благодарность bharrisau за тестирование и обратную связь.
