По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Продолжаем рассказывать про механизмы QoS (Quality of Service) . Мы уже рассказаывали про то, какие проблемы могут быть в сети и как на них может повлиять QoS. В этой статье мы поговорим про механизмы работы QoS.
Механизмы QoS
В связи с тем, что приложения могут требовать различные уровни QoS, возникает множество моделей и механизмов, чтобы удовлетворить эти нужды.
Рассмотрим следующие модели:
Best Effort –негарантированная доставка используется во всех сетях по умолчанию. Положительная сторона заключается в том, что эта модель не требует абсолютно никаких усилий для реализации. Не используются никакие механизмы QoS, весь трафик обслуживается по принципу “пришел первым – обслужили первым”. Такая модель не подходит для современных сетевых сред;
Integrated Services (IntServ) – эта модель интегрированного обслуживания использует метод резервирования. Например, если пользователь хотел сделать VoIP вызов 80 Кбит/с по сети передачи данных, то сеть, разработанная исключительно для модели IntServ, зарезервировала бы 80 Кбит/с на каждом сетевом устройстве между двумя конечными точками VoIP, используя протокол резервирования ресурсов RSVP (Resource Reservation Protocol) . На протяжении звонка эти 80 Кбит/с будут недоступны для другого использования, кроме как для VoIP звонка. Хотя модель IntServ является единственной моделью, обеспечивающей гарантированную пропускную способность, она также имеет проблемы с масштабируемостью. Если сделано достаточное количество резервирований, то сеть просто исчерпает полосу пропускания;
Differentiated Services (DiffServ) – модель дифференцированного обслуживания является самой популярной и гибкой моделью для использования QoS. В этой модели можно настроить каждое устройство так, чтобы оно могло использовать различные методы QoS, в зависимости от типа трафика. Можно указать какой трафик входит в определенный класс и как этот класс должен обрабатываться. В отличие от модели IntServ, трафик не является абсолютно гарантированным, поскольку сетевые устройства не полностью резервируют полосу пропускания. Однако DiffServ получает полосу, близкую к гарантированной полосе пропускания, в то же время решая проблемы масштабируемости IntServ. Это позволило этой модели стать стандартной моделью QoS;
Инструменты QoS
Сами механизмы QoS представляют собой ряд инструментов, которые объединяются для обеспечения уровня обслуживания, который необходим трафику. Каждый из этих инструментов вписывается в одну из следующих категорий:
Классификация и разметка (Classification and Marking) - Эти инструменты позволяют идентифицировать и маркировать пакет, чтобы сетевые устройства могли легко идентифицировать его по мере пересечения сети. Обычно первое устройство, которое принимает пакет, идентифицирует его с помощью таких инструментов, как списки доступа (access-list), входящие интерфейсы или deep packet inspection (DPI), который рассматривает сами данные приложения. Эти инструменты могут быть требовательны к ресурсам процессора и добавлять задержку в пакет, поэтому после того как пакет изначально идентифицирован, он сразу помечается. Маркировка может быть в заголовке уровня 2 (data link), позволяя коммутаторам читать его и/или заголовке уровня 3 (network), чтобы маршрутизаторы могли его прочитать. Для второго уровня используется протокол 802.1P, а для третьего уровня используется поле Type of Service. Затем, когда пакет пересекает остальную сеть, сетевые устройства просто смотрят на маркировку, чтобы классифицировать ее, а не искать глубоко в пакете;
Управление перегрузками (Congestion Management)– Перегрузки возникают, когда входной буфер устройства переполняется и из-за этого увеличивается время обработки пакета. Стратегии очередей определяют правила, которые маршрутизатор должен применять при возникновении перегрузки. Например, если интерфейс E1 WAN был полностью насыщен трафиком, маршрутизатор начнет удерживать пакеты в памяти (очереди), чтобы отправить их, когда станет доступна полоса пропускания. Все стратегии очередей направлены на то, чтобы ответить на один вопрос: “когда есть доступная пропускная способность, какой пакет идет первым?“;
Избегание заторов (Congestion Avoidance) – Большинство QoS механизмов применяются только тогда, когда в сети происходит перегрузка. Целью инструментов избегания заторов является удаление достаточного количества пакетов несущественного (или не очень важного) трафика, чтобы избежать серьезных перегрузок, возникающих в первую очередь;
Контроль и шейпинг (Policing and Shaping) – Этот механизм ограничивает пропускную способность определенного сетевого трафика. Это полезно для многих типичных «пожирателей полосы» в сети: p2p приложения, веб-серфинг, FTP и прочие. Шейпинг также можно использовать, чтобы ограничить пропускную способность определенного сетевого трафика. Это нужно для сетей, где допустимая фактическая скорость медленнее физической скорости интерфейса. Разница между этими двумя механизмами заключается в том, что shaping формирует очередь из избыточного трафика, чтобы выслать его позже, тогда как policing обычно сбрасывает избыточный трафик;
Эффективность линков (Link Efficiency) – Эта группа инструментов сосредоточена на доставке трафика наиболее эффективным способом. Например, некоторые низкоскоростные линки могут работать лучше, если потратить время на сжатие сетевого трафика до его отправки (сжатие является одним из инструментов Link Efficiency);
Механизмы Link Efficiency
При использовании медленных интерфейсов возникают две основных проблемы:
Недостаток полосы пропускания затрудняет своевременную отправку необходимого объема данных;
Медленные скорости могут существенно повлиять на сквозную задержку из-за процесса сериализации (количество времени, которое маршрутизатору требуется на перенос пакета из буфера памяти в сеть). На этих медленных линках, чем больше пакет, тем дольше задержка сериализации;
Чтобы побороть эти проблемы были разработаны следующие Link Efficiency механизмы:
Сжатие полезной нагрузки (Payload Compression) – сжимает данные приложения, оправляемые по сети, поэтому маршрутизатор отправляет меньше данных, по медленной линии;
Сжатие заголовка (Header Compression) – Некоторый трафик (например, такой как VoIP) может иметь небольшой объем данных приложения (RTP-аудио) в каждом пакете, но в целом отправлять много пакетов. В этом случае количество информации заголовка становится значимым фактором и часто потребляет больше полосы пропускания, чем данные. Сжатие заголовка решает эту проблему напрямую, устраняя многие избыточные поля в заголовке пакета. Удивительно, что сжатие заголовка RTP, также называемое сжатым транспортным протоколом реального времени (Compressed Real-time Transport Protocol - cRTP) уменьшает 40-байтовый заголовок до 2-4 байт!;
Фрагментация и чередование (Link Fragmentation and Interleaving) - LFI решает проблему задержки сериализации путем измельчения больших пакетов на более мелкие части до их отправки. Это позволяет маршрутизатору перемещать критический VoIP-трафик между фрагментированными частями данных (которые называются «чередованием» голоса);
Алгоритмы очередей
Постановка в очереди (queuing) определяет правила, которые маршрутизатор должен применять при возникновении перегруженности. Большинство сетевых интерфейсов по умолчанию используют базовую инициализацию First-in, First-out (FIFO) . В этом методе сначала отправляется любой пакет, который приходит первым. Хотя это кажется справедливым, не весь сетевой трафик создается равным. Основная задача очереди - обеспечить, чтобы сетевой трафик, обслуживающий критически важные или зависящие от времени бизнес-приложения, отправлялся перед несущественным сетевым трафиком. Помимо очередности FIFO используются три первичных алгоритма очередности:
Weighted Fair Queuing (WFQ)– WFQ пытается сбалансировать доступную полосу пропускания между всеми отправителями равномерно. Используя этот метод, отправитель с высокой пропускной способностью получает меньше приоритета, чем отправитель с низкой пропускной способностью;
Class-Based Weighted Fair Queuing (CBWFQ) – этот метод массового обслуживания позволяет указать гарантированные уровни пропускной способности для различных классов трафика. Например, вы можете указать, что веб-трафик получает 20 процентов полосы пропускания, тогда как трафик Citrix получает 50 процентов пропускной способности (вы можете указать значения как процент или конкретную величину полосы пропускания). Затем WFQ используется для всего неуказанного трафика (остальные 30 процентов в примере);
Low Latency Queuing (LLQ) - LLQ часто упоминается как PQ-CBWFQ, потому работает точно так же, как CBWFQ, но добавляется компонент приоритета очередей (Priority Queuing - PQ). Если вы указываете, что определенный сетевой трафик должен идти в приоритетную очередь, то маршрутизатор не только обеспечивает пропускную способность трафика, но и гарантирует ему первую полосу пропускания. Например, используя чистый CBWFQ, трафику Citrix может быть гарантированно 50% пропускной способности, но он может получить эту полосу пропускания после того, как маршрутизатор обеспечит некоторые другие гарантии трафика. При использовании LLQ приоритетный трафик всегда отправляется перед выполнением любых других гарантий. Это очень хорошо работает для VoIP, делая LLQ предпочтительным алгоритмом очередей для голоса;
Существует много других алгоритмов для очередей, эти три охватывают методы, используемые большинством современных сетей
Ранее мы уже рассказывали про регулировку громкости в Asterisk. Этот метод рабочий, но весьма статичен. Поэтому в голову пришла интересная мысль.
Представьте, вы совершаете звонок. И, неожиданно, ваш собеседник начинает "кричать" в трубку. Пусть кричит – наши нервы прошли и не такое, но дело в том, что громкость звонка задана жёстко в кастомном диалплане. Поэтому, ощущения от крика буду особенно острыми :)
А теперь, вообразите, что у вас есть возможность сделать собеседника "тише" кнопками телефонного аппарата. А потом, когда он успокоится, сделать снова громче. Интересно? Поехали.
Подготовка
Откроем FreePBX. Открыв модуль сервисных кодов (feature codes), мы обнаружим, что в нем можно только изменить существующие коды, но добавить новые нельзя.
Решение указанной в начале статьи задачи будет базироваться на встроенных функциях Asterisk. То есть мы не будем добавлять кастомный контекст.
Настройка
Открываем файл /etc/asterisk/globals_custom.conf. Этот файл позволяет переписать или добавить глобальные переменные, используемые Asterisk (как стандартные, так и ваши личные).
Если данного файла нет, то его нужно создать. Например, вот так:
touch /etc/asterisk/globals_custom.conf
chown asterisk:asterisk /etc/asterisk/globals_custom.conf
chmod 775 /etc/asterisk/globals_custom.conf
В файл добавляем следующую конструкцию:
DYNAMIC_FEATURES=VUp#VDown#MUp#MDown
Vol=0
Mic=0
Мы задали специальные функции, которые понадобятся нам далее. Сейчас будем закреплять комбинации цифр за кодами. Для этого открываем файл etc/asterisk/features_applicationmap_custom.conf и запишем в него следующее:
VUp => 52*,self,Macro,VolumeUp
VDown => 58*,self,Macro,VolumeDown
MUp => 54*,self,Macro,MicUp
MDown => 56*,self,Macro,MicDown
Мы закрепили за кодами выполнение макроса громкости, который мы напишем далее. Не пугайтесь - "странные" комбинации выбраны по причине того, что их просто запомнить, так как на клавиатуре телефона, это так называемый "крест", наподобие джойстика ;)
Go ahead. Приступаем к самим макросам. Для этого открываем файл /etc/asterisk/extensions_custom.conf и добавляе:
[from-internal-custom]
Set(__DYNAMIC_FEATURES=VUp#VDown#MUp#MDown)
Таким образом, мы подключаем добавленные коды в диалплан Asterisk, который генерирует FreePBX.
Не спешите закрывать файл extensions_custom.conf. В него же добавляем механизм увеличения громкости. То есть, макросы о которых мы писали ранее:
[macro-VolumeUp]
exten => s,1,Set(Vol=$[${Vol}+5])
same => n,Set(VOLUME(TX)=${Vol})
[macro-VolumeDown]
exten => s,1,Set(Vol=$[${Vol}-5])
same => n,Set(VOLUME(TX)=${Vol})
[macro-MUp]
exten => s,1,Set(Mic=$[${Mic}+5])
same => n,Set(VOLUME(RX)=${Mic})
[macro-MDown]
exten => s,1,Set(Mic=$[${Mic}-5])
same => n,Set(VOLUME(RX)=${Mic})
Можно выдохнуть. На этом правки закончены. Как вы могли заметить, почему-то "громкостей" несколько. Все достаточно просто. Это 2 макроса на увеличение и уменьшение громкости канала звука и, соответственно, канала микрофона.
Что нам все эти коды дают (по сравнению с жестко прописанными числами)? В любой момент разговора, если вы плохо (тихо) слышите собеседника, нужно набрать на телефоне 52* и громкость увеличится, так можно делать несколько раз пока уровень громкости собеседника не станет приемлемым. Это работает и наоборот: 58* и собеседник становится "тише".
Удобно, правда? :) Из плюсов - не надо прерывать звонок. Нет жёсткого ограничения громкости. Если разговор затягивается на длительное время, можно выставить комфортную слышимость.
Ну а второй макрос, спросите вы? Представьте: что делать, если собеседник жалуется, что вас тихо слышно? Нет проблем. Набираем 54* и собеседник начинает нас лучше слышать, то есть, мы увеличиваем громкость канала нашего микрофона!
Дело в том, что если вы не используете какие либо сетевые сервисы (такие как NFS доступ, например) на своем Linux сервере, то скорее всего portmapper вам не нужен.
А чтобы окончательно уверить вас в том, чтобы выключить службу, вот вам факт: злоумышленники юзают сервис portmapper для увеличения эффекта DDoS-атак.
А теперь о том, как проверить portmapper на вашем сервере и отключить его.
Коротко о том, что делает portmapper
Портмаппер это специальный сервис в Linux, который обеспечивает службы RPC (Remote Procedure Call), такие как NFS - служба, например. Кстати говоря, portmapper обитатет на 111 порту (TCP и UDP).
RPC (Remote Procedure Call) - так называемый удаленный вызов процедур. Если кратко, это технология, позволяющая определенному софту вызывать функции и процедуры на других сетевых машинах
Как посмотреть RPC службы
Легко. Вы можете посмотреть список активных RPC - служб с помощью команды rpcinfo. Вот так:
[root@merionet ~]# rpcinfo -p
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
У нас запущен только сам portmapper. Переходим к экзекуции.
Остановить portmapper in CentOS 7
Сервис, отвечающий за portmapper как правило называется rpcbind. Останавливаем службу и сокет, как показано ниже:
[root@merionet ~]# systemctl stop rpcbind
Warning: Stopping rpcbind.service, but it can still be activated by:
rpcbind.socket
[root@merionet ~]# systemctl stop rpcbind.socket
Полностью выключаем portmapper, даже после перезагрузки
Убедимся, что сервис тоже выключен:
[root@merionet ~]# systemctl disable rpcbind
А теперь контрольный в голову. Проверяем, что при попытке посмотреть информацию по rpc (команда )
[root@merionet ~]# rpcinfo -p
rpcinfo: can't contact portmapper: RPC: Remote system error - Connection refused
Готово. Теперь, ваш сервер стал чуточку безопаснее.