LINUX.ORG.RU
ФорумAdmin

Ограничение входящего траффика


0

0

Есть шлюз, который по nat раздает инет по локалке. Хотелось бы по некоторым правилам приоритезировать входящий траффик, и резать некоторый. Если я правильно понимаю tc служит для контроля траффика исходящей очереди, но никак не входящей. Или я неправ? Я сделал следующим образом. Пока для простоты скажем мне просто одной машине в локалке нужно порезать весь входящий траффик. Я в iptables, в таблице mangle добавил правила:

$IPT -t mangle -A FORWARD -s 192.168.1.41 -j CONNMARK --set-mark 5

$IPT -t mangle -A FORWARD -m connmark --mark 5 -j CONNMARK --restore-mark # чтобы переместить метку из CONNMARK в просто MARK

Далее в tc, на интерфейсе локалки вешаю дисциплину htb. Создаю рут и дефолтовый класс на него, с rate = 1000Kbit, ceil = 100000Kbit (100Mb сетка, rate можно было и побольше поставить наверное, незнаю что это я так мало сделал =/) Затем создаю дополнительный класс, тоже htb, с rate=1Kbit, ceil=3Kbit (это класс для ограниченного инета). Далее tc filter вешаю фильтр на fwmark 5, чтобы попадал в этот ограниченный класс. На leaf's вешаю pfifo. Вроде бы все работает, на маркированной машине действительно траффик урезается до 3х кбит =)

Но есть вопросы. Во первых насколько целесобразно так ограничивать траффик? Цель ограничения траффика - его платность. Но ведь я ограничиваю скорость уже на внутреннем интерфейсе. Как в такой ситуации будет вести себя поток траффика? Я вижу 2 варианта.

1. Клиент посылает запрос на сервер, и сервер бесконтрольно, на максимальной скорости для моего интренет соединения. Пакеты попадают на роутер. Пока есть свободные токены у htb, он потихоньку выдает их клиенту, на заданной скорости в 3кбита. Но т.к. скорость интернет соединения намного превышает эти 3кбита, то со временем токены закончаться и пакеты начнут отбрасываться. В результате клиент будет в дальнейшем запрашивать их дополнительно и я вместо экономии получу прибавку паразитного траффика.

2. Клиент посылает запрос на сервер, сервер выдает некоторую часть пакетов и ждет ответа от клиента, об успешной доставки. Пакеты спокойно укладываются в токены и потихоньку уходят клиенту. Клиент получив всю очередь пакетов посылает запрос серверу на очередную порцию. Лишних пакетов нет, траффик искуственно урезан, все довольны. Соб-но это и есть главные вопросы, которые меня ну очень интересуют =)

anonymous

Вот статистика если нужна:

linux ~ # tc -s -d qdisc show dev eth1
qdisc htb 1: r2q 10 default 10 direct_packets_stat 312 ver 3.17
 Sent 1236184222 bytes 1814142 pkt (dropped 32488, overlimits 999569 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc pfifo 20: parent 1:10 limit 5p
 Sent 1227611398 bytes 1798136 pkt (dropped 31378, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc pfifo 30: parent 1:11 limit 5p
 Sent 8483828 bytes 15394 pkt (dropped 1110, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0

linux ~ # tc -s -d class show dev eth1
class htb 1:11 parent 1:1 leaf 30: prio 0 quantum 1000 rate 8000bit ceil 24000bit burst 1604b/8 mpu 0b overhead 0b cburst 1611b/8 mpu 0b overhead 0b level 0
 Sent 8484903 bytes 15399 pkt (dropped 1110, overlimits 0 requeues 0)
 rate 272bit 0pps backlog 0b 0p requeues 0
 lended: 10158 borrowed: 5241 giants: 0
 tokens: 1556000 ctokens: 521334

class htb 1:1 root rate 1000Kbit ceil 100000Kbit burst 2100b/8 mpu 0b overhead 0b cburst 51600b/8 mpu 0b overhead 0b level 7
 Sent 1236201138 bytes 1813989 pkt (dropped 0, overlimits 0 requeues 0)
 rate 9192bit 2pps backlog 0b 0p requeues 0
 lended: 5406 borrowed: 0 giants: 0
 tokens: 15968 ctokens: 4120

class htb 1:10 parent 1:1 leaf 20: prio 0 quantum 12500 rate 1000Kbit ceil 100000Kbit burst 2100b/8 mpu 0b overhead 0b cburst 51600b/8 mpu 0b overhead 0b level 0
 Sent 1227716235 bytes 1798590 pkt (dropped 31378, overlimits 0 requeues 0)
 rate 8920bit 2pps backlog 0b 0p requeues 0
 lended: 1798425 borrowed: 165 giants: 0
 tokens: 15968 ctokens: 4120

linux ~ # tc filter show dev eth1
filter parent 1: protocol ip pref 1 fw
filter parent 1: protocol ip pref 1 fw handle 0x5 classid 1:11


1:11 как видно ограниченный класс. Пугает наличие dropped пакетов. И отсутсвие overlimits.

Да, и видимо в дефолтном классе 1:10 нужно все-таки поднять rate и burst, а то токенов видимо не хватает.

anonymous
()

Почитал по диагонали, советую поиск.

>Если я правильно понимаю tc служит для контроля траффика исходящей очереди, но никак не входящей

tc вообще ничего не контролирует сама по себе, но управлять можно попытатся и входящим трафиком.

>В результате клиент будет в дальнейшем запрашивать их дополнительно и я вместо экономии получу прибавку паразитного траффика.

если все сделать правильно, tcp-пакеты не будут теряться, а скорость их поступления будет уменьшена клиенскоми приложениями до нужной тебе.

Во втором вопросе не понял суть вопроса.

fagot ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.