Перейти к содержимому 
Я показываю, как Формирование полосы пропускания на серверах и управление трафиком в Linux для управления потоками пакетов таким образом, чтобы заметно снизить задержки, джиттер и перебои в работе. Я использую приоритетные очереди, лимиты и правила QoS для защиты критически важных для бизнеса потоков, таких как VoIP, API или запросы в магазин, от фоновой нагрузки и резервного копирования.
Центральные пункты
Следующие основные положения помогут мне целенаправленно контролировать пропускную способность и трафик на серверах Linux и сделать их постоянно планируемыми.
- Расстановка приоритетов Критичные по времени потоки уменьшают задержки и джиттер.
- Ограничения по ставкам и дросселирование позволяют избежать всплесков и заторов в буфере.
- HTB/SFQ справедливо распределять пропускную способность и поддерживать постоянные классы.
- Фильтр QoS контроль по IP, порту, протоколу или меткам.
- Мониторинг С помощью P95 и оповещений можно обнаружить узкие места на ранней стадии.
Я выстраиваю эти пункты шаг за шагом, постоянно измеряю эффект и адаптирую классы и расценки к реальному использованию.
Что на самом деле означает формирование полосы пропускания
При формировании я регулирую Движение по участкам активно, а не просто реактивно дросселировать. Я поддерживаю постоянную скорость, отдаю приоритет трафику в реальном времени и интерактивному трафику и сглаживаю нерегулярные всплески данных. Для этого я использую ограничение скорости для исходящего трафика и дросселирование для входящих потоков данных. Такое разделение создает четкую ответственность за каждое направление и предотвращает переполнение буферов. Для хостинговых сред я устанавливаю определенные верхние пределы для каждого клиента или приложения, чтобы пик нагрузки не привел к замедлению работы всей системы.
Управление трафиком в Linux: инструменты и концепции
В Linux я контролирую трафик с помощью инструмента тс и дисциплины очередей ядра (qdisc). Типичными строительными блоками являются корневой qdisc, классы и фильтры, определяющие назначение пакетов по приоритетам и лимитам. Я часто начинаю с HTB в качестве иерархического контроллера для гарантированной и максимальной скорости. Я также использую SFQ для справедливого распределения внутри класса. Я ограничиваю пропускную способность до 90-95 процентов от физически возможной скорости, чтобы сохранить запас скорости и избежать пиков задержки.
Формирование входного сигнала (Ingress): IFB вместо Policer
Для входящего трафика я не формирую его непосредственно на физическом интерфейсе, а использую IFB-устройство (промежуточный функциональный блок). Я зеркалирую входящие пакеты на IFB и обрабатываю их там как исходящий трафик - включая иерархию HTB, справедливость и ограничения. Это мельче чем чистый полисер, который только отбрасывает жесткие сигналы и часто увеличивает джиттер.
modprobe ifb numifbs=1
ip link add ifb0 type ifb
ip link set dev ifb0 up
# Активируйте ingress на PHY и перенаправьте на IFB
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 \
действие зеркальное egress redirect dev ifb0
# Шейпинг на IFB, как и в случае с egress
tc qdisc add dev ifb0 root handle 2: htb default 20
tc class add dev ifb0 parent 2: classid 2:10 htb rate 40mbit ceil 60mbit
tc class add dev ifb0 parent 2: classid 2:20 htb rate 20mbit ceil 40mbit
tc qdisc add dev ifb0 parent 2:10 handle 210: fq_codel
tc qdisc add dev ifb0 parent 2:20 handle 220: sfq
С помощью IFB я получаю контроль над пиками загрузки, например, когда входящие задания резервного копирования или зеркалирования перегружают полосу пропускания. На практике я использую IFB на интерфейсах с сильно асимметричными скоростями (например, 1G/200M) или там, где входящие всплески ставят под угрозу интерактивность.
HTB, TBF и SFQ в сравнении
Для правильного выбора qdisc Я рассматриваю цели приложения: Гарантии, поведение во время всплеска и справедливость. HTB предлагает иерархические классы с фиксированными и максимальными ставками, TBF строго ограничивает по маркерам, SFQ распределяет возможности по потокам. В сочетании они образуют устойчивую структуру на практике: HTB ограничивает и гарантирует, SFQ предотвращает доминирование отдельных соединений, TBF усмиряет настойчивые всплески. В следующей таблице приведены основные характеристики для типичных серверных сценариев. Это позволяет мне быстрее решить, какая дисциплина имеет смысл в тот или иной момент.
| qdisc/Feature | Назначение | Сильные стороны | Типичное использование |
|---|---|---|---|
| HTB | Иерархия и контроль скорости | Гарантированная ставка, верхний предел, наследство | Клиенты, классы обслуживания, профили QoS |
| TBF | Строгий Крышки | Простой, очень детерминированный | Ограничение на количество подключений, жесткие ограничения на приложения |
| SFQ | Справедливость на поток | Низкие накладные расходы, хорошее распространение | Загрузки, P2P, множество сессий |
| FQ_CoDel | AQM против буферблота | Низкая задержка, отсеивание очередей | Пограничные маршрутизаторы, каналы связи, критичные к задержкам |
Для доступа с сильно колеблющимся RTT я использую FQ_CoDel или - в зависимости от ядра - CAKE в качестве универсального решения. Однако в серверной практике я придерживаюсь HTB+SFQ/FQ_CoDel, потому что в иерархии можно чисто объединить гарантии, заимствование и справедливое распределение.
Практика: правила tc для типичных серверов
Я начинаю с простого HTB-структурировать, а затем распределять с помощью фильтра. Корневой qdisc с классом по умолчанию ловит неклассифицированные пакеты, приоритетные классы получают гарантированную скорость. Затем я уточняю фильтры: HTTP/S в класс A, репликация баз данных в класс B, резервное копирование в класс C. Таким образом, запросы магазинов выполняются быстро, а резервные копии используют остатки. Для ознакомления с основами и словарным запасом я отсылаю вас к этому введению в Управление полосой пропускания, что делает процедуру осязаемой.
tc qdisc add dev eth0 root handle 1: htb default 20
tc class add dev eth0 parent 1: classid 1:10 htb rate 50mbit ceil 70mbit
tc class add dev eth0 parent 1: classid 1:20 htb rate 20mbit ceil 50mbit
tc class add dev eth0 parent 1: classid 1:30 htb rate 10mbit ceil 30mbit
tc qdisc add dev eth0 parent 1:10 handle 110: sfq
tc qdisc add dev eth0 parent 1:20 handle 120: sfq
tc qdisc add dev eth0 parent 1:30 handle 130: sfq
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 443 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 prio 2 u32 match ip dport 3306 0xffff flowid 1:20
tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 match ip sport 22 0xffff flowid 1:30
Классификация с DSCP и метками (с поддержкой IPv4/IPv6)
Чтобы фильтры работали независимо от версии IP и NAT, я помечаю пакеты заранее, а затем сопоставляю их через fwmark в классах. Это избавляет меня от сложных совпадений u32 и сохраняет правила компактными. Я также использую DSCP для сквозной семантики, например, для VoIP или интерактивности.
# Пример с nftables: приоритет TLS, дросселирование резервных копий
nft add table inet mangle
nft add chain inet mangle prerouting { type filter hook prerouting priority -150; }
nft add rule inet mangle prerouting tcp dport 443 meta mark set 10
nft add rule inet mangle prerouting tcp dport 22 meta mark set 30
nft add rule inet mangle prerouting tcp dport 873 meta mark set 40 # rsync/Backups
# Mapping в классах HTB (работает для IPv4/IPv6 одинаково)
tc filter add dev eth0 parent 1:0 prio 1 handle 10 fw flowid 1:10
tc filter add dev eth0 parent 1:0 prio 2 handle 30 fw flowid 1:30
tc filter add dev eth0 parent 1:0 prio 3 handle 40 fw flowid 1:20
Важно: я устанавливаю DSCP/маркеры настолько, насколько это возможно. на краю (на входе в машину или перед ней), чтобы последующие решения принимались быстро, а у ТК было меньше работы под нагрузкой.
Стратегии QoS для хостинга: справедливость и ограничения
В многопользовательских системах я обеспечиваю безопасность Справедливость через фиксированные гарантии для каждого клиента и лимиты для каждого приложения. Я маркирую пакеты по DSCP или по портам и распределяю их по соответствующим классам. Загрузка и резервное копирование разрешены для заполнения емкости, в то время как интерактивным сессиям отдается приоритет. Таким образом, услуги, соответствующие SLA, остаются приоритетными, не исключая других арендаторов. В этом обзоре я кратко описываю практические сценарии и логику расстановки приоритетов Приоритизация трафика что хорошо согласуется с правилами ТК.
Постоянство и автоматизация
Мои политики QoS выдерживают перезагрузки и перезапуски интерфейсов. Я храню команды tc в виде идемпотентного скрипта и интегрирую его в systemd или netplan/networkd. Для устройств с динамическими именами (например, veth/tap) я использую правила udev или шаблоны systemd.
# /usr/local/sbin/tc-setup.sh (сборка idempotent)
#!/bin/sh
tc qdisc replace dev eth0 root handle 1: htb default 20
# ... больше классов/фильтров здесь
# systemd unit: /etc/systemd/system/tc-setup.service
[Unit]
Описание=Настройка управления трафиком
После=network-online.target
Хочет=network-online.target
[Сервис]
Тип=oneshot
ExecStart=/usr/local/sbin/tc-setup.sh
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
Я внедряю изменения контролируемым образом: сначала на этапе постановки, затем в течение ограниченного времени в производственной системе (замена тс вместо добавить), сопровождаемые метриками и кнопкой отката.
Мониторинг, P95 и устранение неисправностей без разочарований
Я постоянно измеряю эффект, а не концентрируюсь на Интуиция покинуть. Задержки P95, длина очереди и потери пакетов показывают, эффективны или слишком строги правила. Такие инструменты, как iftop, vnStat и Netdata, позволяют увидеть пики нагрузки, журналы tc и iptables показывают распределение. Если возникает джиттер, я немного уменьшаю значения ceil и проверяю CoDel/FQ_CoDel в качестве меры AQM. В случае возникновения узких мест я пошагово корректирую веса классов и сохраняю окна измерений после каждого изменения.
Методология испытаний: моделирование нагрузки и верификация
Я моделирую реалистичные сценарии: непрерывный поток (iperf3), короткие взаимодействия (небольшие HTTP-запросы) и периодические всплески (резервное копирование/rsync) параллельно. Затем я проверяю, поддерживают ли интерактивные потоки стабильно низкую задержку и сглаживаются ли всплески.
# Тест в обратном направлении (загрузка/передача)
iperf3 -c -R -t 60
# Чтение статистики шейпинга
tc -s qdisc show dev eth0
tc -s class show dev eth0
# Проверьте распределение джиттера/RTT
ping -i 0.2 -c 100 | awk '/time=/{print $7}'Если классы постоянно нуждаются в заимствованиях, я немного увеличиваю гарантированные ставки. Если в очередях AQM накапливаются падения, я проверяю размеры буферов и то, не установлены ли лимиты слишком агрессивно.
Настройка производительности: покрытие 90-95 %, сглаживание разрывов, MTU
Я ограничиваю скорость вывода до 90-95% скорости соединения, чтобы избежать разбухания буфера и обеспечить работу AQM. Я сглаживаю всплески с помощью параметров token bucket (rate, burst/latency), чтобы краткосрочные пики не заполняли всю очередь. Я проверяю MTU, чтобы уменьшить фрагментацию и избежать проблем с MTU пути. Для сильно колеблющихся рабочих нагрузок я устанавливаю щедрые значения ceil, но консервативные гарантированные скорости. Такая настройка позволяет поддерживать высокую скорость приоритетного трафика, в то время как фоновые процессы продолжают работать в нейтральном режиме.
Аппаратная разгрузка, многопотоковая очередь и настройка IRQ
Для точного шейпинга на быстрых каналах я знаю о взаимодействии с разгрузкой сетевых карт. TSO/GSO/GRO ускоряют, но на очень низких целевых скоростях они могут ухудшить мелкозернистость. Для чувствительных каналов я отключаю TSO/GSO в качестве теста и измеряю выигрыш в задержках/процессорах по сравнению с ним. На сетевых картах с несколькими очередями я использую mq-Я распределяю нагрузку на процессор с помощью RPS/XPS и IRQ pinning, чтобы работа QoS не простаивала на CPU.
# Выборочное тестирование разгрузки (осторожно в производстве)
ethtool -K eth0 tso off gso off gro off
# Расположение многопотоковой очереди
tc qdisc add dev eth0 root handle 1: mq
tc qdisc add dev eth0 parent 1:1 handle 10: htb default 20
tc qdisc add dev eth0 parent 1:2 handle 20: htb default 20
# ... продолжите работу с каждой очередью и установите классы/фильтры, как обычно
С txqueuelen, размеры кольцевых буферов и сродство IRQ, я продолжаю уменьшать задержку. Цель - добиться стабильного, короткого пути очереди, который не опрокидывается под нагрузкой.
Безопасность и сегментация: формирование с помощью брандмауэра и VLAN
Я сочетаю QoS с Сегментация, чтобы критически важные сети сохраняли свои собственные возможности. Я устанавливаю собственные очереди для каждой VLAN или интерфейса, брандмауэры маркируют пакеты, как только они попадают на сервер. Это означает, что tc приходится принимать меньше решений под нагрузкой, поскольку пакеты классифицируются на ранней стадии. Резервные копии из VLAN хранилища остаются на своем пути, а внешний HTTP не страдает от голода. Разделение также сокращает время анализа ошибок, поскольку потоки могут быть назначены более четко.
Виртуализация и контейнеры: где я формируюсь
В установках KVM/virtio я предпочитаю формировать Край: на интерфейсе моста (br0), на физическом восходящем канале (eth0) или конкретно для каждого гостя на его интерфейсе vnet. Мне нравится реализовывать гарантии для каждого арендатора на vnetX, глобальные ограничения на uplink. В Kubernetes tc можно реализовать на veth peers или uplinks узлов; я назначаю маркеры на ранней стадии через CNI/iptables/nftables, чтобы распределение оставалось детерминированным. Для SR-IOV или DPDK я убеждаюсь, что пути передачи данных вообще проходят через tc - в противном случае я формирую их заранее или использую собственные ограничители скорости NIC.
Затраты и преимущества: Эффективность вместо модернизации оборудования
С чистым Формирование Я лучше использую существующие линии и часто экономлю на дорогостоящей модернизации. Меньшая потеря пакетов и меньшая задержка напрямую улучшают работу пользователей. В хостинговых средах это окупается вдвойне, поскольку справедливые лимиты предотвращают эскалацию между клиентами. На практике я вижу, что стабильные тарифы увеличивают пропускную способность, поскольку сокращается количество повторных передач. В конечном итоге эти эффекты отражаются в более четких SLA и уменьшении количества обращений в службу поддержки.
Частые подводные камни и быстрая проверка
- Неподходящие единицы: Я проверяю, есть ли
мбитиkbitзаписываются правильно, а скорость передачи/латентность соответствуют MTU. - Изменение приоритетов: слишком много высокоприоритетных классов без реального ограничения приводят к голоду дефолтных классов. Я строго придерживаюсь верхних пределов.
- NAT/IPv6 упущен: Портовые фильтры не работают как положено после NAT/IPv6. Я помечаю на ранней стадии (fwmark), а затем создаю карту в классах.
- Ceil меньше, чем ставка: распространенная опечатка, которая блокирует заимствования. Я проверяю каждый класс с помощью
tc -s class. - Входящий поток только поляризован: жесткий сброс создает джиттер. С IFB я формирую более тонкую и справедливую структуру.
- Перегрузки искажают результаты измерений: Я документирую состояние разгрузки для каждого теста и сравниваю яблоки с яблоками.
Перспективы на будущее: Резервирование с поддержкой ИИ и адаптивные политики
Я использую такие тенденции, как Предсказания на основе исторической нагрузки для динамической настройки классов незадолго до пиковых значений. Модели обучения резервируют пропускную способность для VoIP или фаз проверки до роста очередей. В гибридных сетях между облаком и локальной сетью я использую временные ограничения и бюджеты на пропускную способность, которые изменяют политику по расписанию. Это сокращает операционные вмешательства и сохраняет предсказуемость услуг даже во время особых событий. Более подробные сведения о масштабировании и ограничениях я привожу здесь: Управление трафиком и лимиты на хостинг.
Резюме и контрольный список
Сначала я установил четкий Иерархия с HTB, выдаю гарантии и поддерживаю Ceil немного ниже скорости соединения. Затем я классифицирую в соответствии с сервисами, протоколами или DSCP и проверяю задержку, джиттер и значения P95. Я использую SFQ или FQ_CoDel для обеспечения справедливого распределения и коротких очередей. Мониторинг сопровождает каждое изменение, так что я могу принимать решения о последствиях, а не гадать. Это означает, что формирование полосы пропускания - не разовый акт, а постоянный цикл управления, который обеспечивает безопасность и предсказуемость трафика сервера.
