15.8. Формирователь трафика: Низкая задержка, максимальная производительность.
 | Этот сценарий претерпел существенные изменения. Ранее он предназначался только для Linux-клиентов в вашей сети! Теперь же он может влиять на Windows и Mac машины |
При разработке сценария преследовались следующие цели:
- Обеспечить низкую задержку для интерактивного трафика.
Это означает, что перекачка больших объемов данных не должна отрицательно сказываться на работе через ssh или telnet. Это очень важно, поскольку в период интерактивного взаимодействия с удаленной системой даже незначительные задержки, скажем в 200 мсек, вызывают у пользователя чувство раздражения.
- Обеспечить приемлемую скорость web-серфинга
Даже учитывая тот факт, что http-трафик сам по себе является довольно объемным, он не должен подвергаться значительным задержкам.
- Обеспечить достаточно высокую скорость передачи больших объемов данных.
Довольно часто возникает ситуация, когда исходящий трафик практически полностью блокирует входящий.
Оказывается, что все поставленные цели вполне достижимы. Основная причина, по которой перекачка значительных объемов вызывает задержки интерактивного трафика, заключается в наличии больших очередей во многих устройствах доступа, таких как модемы DSL.
В следующем разделе дается детальное описание причин, которые вызывают задержки, и даются практические рекомендации по их устранению. Однако, если вас не интересуют пространные размышлизмы, то можете просто пропустить его и сразу перейти к разделам со сценариями.
15.8.1. Почему все так сложно?
Поставщикам услуг Интернет хорошо известно, что пользователей в основном интересует скорость, с которой они могут получать данные. Но помимо пропускной способности канала, на скорость скачивания очень сильно влияют факты потери пакетов. Увеличение очередей способствует уменьшению потерь, что в свою очередь приводит к увеличению скорости скачивания. Поэтому поставщики услуг, как правило, создают очереди очень большого объема.
Однако, увеличение очередей приводит к появлению задержек в интерактивном трафике. Интерактивные пакеты сначала попадают в исходящую очередь, где они ожидают отправки на удаленную систему, в результате может пройти до нескольких секунд (!), пока они достигнут места назначения. То же самое повторяется на обратном пути -- сначала пакеты попадают в огромную очередь для входящего трафика, у поставщика услуг, долго ожидают отправки и только потом попадают к вам.
В этом руководстве мы расскажем вам, о способах обслуживания очередей, но, к большому сожалению, не все очереди нам доступны. Так, очереди поставщика услуг нам не подвластны совершенно, в то время, как очередь исходящего трафика, скорее всего находится внутри вашего кабельного или DSL модема. Некоторые модели допускают возможность конфигурирования очередей, но чаще всего такая возможность отсутствует.
Итак, что же дальше? Поскольку мы лишены возможности управлять этими очередями, то напрашивается очевидное решение -- они должны быть перемещены на наш Linux-маршрутизатор. К счастью это возможно. Для этого необходимо:
- Ограничить скорость исходящего трафика.
Ограничивая скорость исходящего трафика, величиной несколько меньшей, чем пропускная способность канала, мы тем самым ликвидируем исходящую очередь в модеме. Таким образом, исходящая очередь как бы перемещается в маршрутизатор.
- Ограничить скорость входящего трафика.
Это немного сложнее, поскольку действительно отсутствует возможность влияния на скорость поступления данных. Тем не менее, можно попробовать сбрасывать пакеты, если скорость поступления слишком высока, это заставит TCP/IP снизить скорость передачи до желаемого уровня. Поскольку в данном вопросе чрезмерное усердие может только навредить, то необходимо предусмотреть величину возможного превышения на коротких отрезках времени.
При выполнении этих условий, входящая очередь будет ликвидирована полностью (за исключением коротких пиков), и появляется возможность управления исходящей очередью, используя всю мощь, которую предоставляет операционная система Linux.
После этого остается обеспечить первоочередную передачу интерактивного трафика. А для того, чтобы входящий трафик не блокировался исходящим, необходимо так же обеспечить первоочередную передачу ACK-пакетов. При наличии объемного трафика в обоих направлениях, возникают значительные задержки, поэтому входящие ACK-пакеты не должны проигрывать в конкурентной борьбе с исходящим трафиком.
После выполнения необходимых настроек, мы получили следующие результаты на ADSL соединении в Нидерландах:
Базовое время ожидания отклика:
туда-обратно мин/ср/макс = 14.4/17.1/21.7 мсек
Во время скачивания, без формирователя трафика:
туда-обратно мин/ср/макс = 560.9/573.6/586.4 мсек
Во время отправки большого объема, без формирователя трафика:
туда-обратно мин/ср/макс = 2041.4/2332.1/2427.6 мсек
С формирователем трафика, при отправке большого файла на скорости 220 Кбит/сек:
round-trip min/avg/max = 15.7/51.8/79.9 мсек
С формирователем трафика, при скачивании на скорости 850 Кбит/сек:
туда-обратно мин/ср/макс = 20.4/46.9/74.0 мсек
При наличии исходящего трафика, скорость входящего достигает ~80%
от максимально возможного значения. Скорость исходящего трафика
колеблется около 90%. При этом время ожидания подскакивает до 850 мсек,
причина пока не выяснена.
Чего можно ожидать от этого сценария, во многом зависит от фактической пропускной способности канала для исходящего потока. При наличии объемного исходящего трафика, перед исходящим интерактивным пакетом практически всегда будет стоять какой либо другой пакет, что и обусловливает нижний предел времени ожидания. Вы можете рассчитать этот предел, разделив MTU на максимальную скорость для исходящего потока. Типичные значения будут несколько выше. Чтобы достичь лучшего эффекта, можно попробовать несколько уменьшить MTU!
Ниже приводятся две версии сценария формирователя трафика. Одна версия построена на базе HTB, разработанной Девиком (Devik), другая -- на базе CBQ, которая, в отличие от HTB, включена в состав ядра Linux. Оба сценария проверены и дают прекрасные результаты.
15.8.2. Формирователь трафика на базе CBQ.
Может работать практически с любой версией ядра. В данной реализации, внутри CBQ qdisc размещаются две SFQ (Stochastic Fairness Queues), что даст возможность равноправного сосуществования нескольких потоков данных.
Входящий трафик формируется с помощью tc-фильтров, содержащих Token Bucket Filter.
Вы можете улучшить сценарий за счет добавления ключевых слов bounded в строках, начинающихся со слов tc class add .. classid 1:20. Если вы предполагаете уменьшать MTU, не забудьте уменьшить и значения allot и avpkt!
#!/bin/bash
# Формирователь трафика для домашнего соединения с Интернет
#
#
# Установите следующие параметры так, чтобы они были немного меньше фактических
# Единицы измерения -- килобиты
DOWNLINK=800
UPLINK=220
DEV=ppp0
# очистка входящей и исходящей qdisc
tc qdisc del dev $DEV root 2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null
###### исходящий трафик
# установка корневой CBQ
tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit
# ограничить общую исходящую скорость величиной $UPLINK -- это предотвратит
# появление огромных очередей в DSL модеме,
# которые отрицательно сказываются на величине задержки:
# базовый класс
tc class add dev $DEV parent 1: classid 1:1 cbq rate ${UPLINK}kbit \
allot 1500 prio 5 bounded isolated
# высокоприоритетный (интерактивный) класс 1:10:
tc class add dev $DEV parent 1:1 classid 1:10 cbq rate ${UPLINK}kbit \
allot 1600 prio 1 avpkt 1000
# класс по-умолчанию 1:20 -- получает немного меньший объем трафика
# и имеет более низкий приоритет:
tc class add dev $DEV parent 1:1 classid 1:20 cbq rate $[9*$UPLINK/10]kbit \
allot 1600 prio 2 avpkt 1000
# оба получают дисциплину Stochastic Fairness:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
# определения фильтров
# TOS = Minimum-Delay (ssh, НО НЕ scp) -- в 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
match ip tos 0x10 0xff flowid 1:10
# ICMP (ip protocol 1) -- в интерактивный класс 1:10
# так мы сможем удивить своих друзей:
tc filter add dev $DEV parent 1:0 protocol ip prio 11 u32 \
match ip protocol 1 0xff flowid 1:10
# Поднять скорость входящего трафика, при наличии исходящего -- передать ACK-пакеты
# в интерактивный класс:
tc filter add dev $DEV parent 1: protocol ip prio 12 u32 \
match ip protocol 6 0xff \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
flowid 1:10
# остальной трафик не является интерактивным поэтому передаем его в 1:20
tc filter add dev $DEV parent 1: protocol ip prio 13 u32 \
match ip dst 0.0.0.0/0 flowid 1:20
########## входящий трафик #############
# необходимо несколько уменьшить скорость поступления входящего трафика,
# это предотвратит задержку пакетов в очередях у поставщика услуг.
# Поставщики имеют обыкновение увеличивать размеры очередей,
# поэтому, экспериментальным путем подберите требуемые значения,
# при которых скачивание будет происходить с максимальной скоростью.
#
# присоединить входной ограничитель:
tc qdisc add dev $DEV handle ffff: ingress
# сбрасывать все подряд (0.0.0.0/0), что приходит со слишком большой скоростью.
tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
Если вы собираетесь использовать этот сценарий совместно с ppp -- скопируйте его в /etc/ppp/ip-up.d.
Если последние две строки в сценарии порождают сообщения об ошибке -- обновите версию tc!
15.8.3. Формирователь трафика на базе HTB.
Следующий вариант сценария достигает поставленных целей за счет использования замечательных особенностей HTB (см. раздел Hierarchical Token Bucket). Требует наложения "заплаты" на ядро!
#!/bin/bash
# Формирователь трафика для домашнего соединения с Интернет
#
#
# Установите следующие параметры так, чтобы они были немного меньше фактических
# Единицы измерения -- килобиты
DOWNLINK=800
UPLINK=220
DEV=ppp0
# очистка входящей и исходящей qdisc
tc qdisc del dev $DEV root 2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null
###### исходящий трафик
# установка корневой HTB, отправить трафик по-умолчанию в 1:20:
tc qdisc add dev $DEV root handle 1: htb default 20
# ограничить общую исходящую скорость величиной $UPLINK -- это предотвратит
# появление огромных очередей в DSL модеме,
# которые отрицательно сказываются на величине задержки:
tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k
# высокоприоритетный (интерактивный) класс 1:10:
tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \
burst 6k prio 1
# класс по-умолчанию 1:20 -- получает немного меньший объем трафика
# и имеет более низкий приоритет:
tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[9*$UPLINK/10]kbit \
burst 6k prio 2
# оба получают дисциплину Stochastic Fairness:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
# TOS = Minimum-Delay (ssh, НО НЕ scp) -- в 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
match ip tos 0x10 0xff flowid 1:10
# ICMP (ip protocol 1) -- в интерактивный класс 1:10
# так мы сможем удивить своих друзей:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
match ip protocol 1 0xff flowid 1:10
# Поднять скорость входящего трафика, при наличии исходящего -- передать ACK-пакеты
# в интерактивный класс:
tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \
match ip protocol 6 0xff \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
flowid 1:10
# остальной трафик не является интерактивным поэтому он попадает в 1:20
########## входящий трафик #############
# необходимо несколько уменьшить скорость поступления входящего трафика,
# это предотвратит задержку пакетов в очередях у поставщика услуг.
# Поставщики имеют обыкновение увеличивать размеры очередей,
# поэтому, экспериментальным путем подберите требуемые значения,
# при которых скачивание будет происходить с максимальной скоростью.
#
# присоединить входной ограничитель:
tc qdisc add dev $DEV handle ffff: ingress
# сбрасывать все подряд (0.0.0.0/0), что приходит со слишком большой скоростью.
tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
Если вы собираетесь использовать этот сценарий совместно с ppp -- скопируйте его в /etc/ppp/ip-up.d.
Если последние две строки в сценарии порождают сообщения об ошибке -- обновите версию tc!