The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Маршрутизаторы CISCO и др. оборудование.
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Ограничить ширину полосы для IP., Monster_C (?), 28-Фев-03, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


28. "резать входящий трафик МОЖНО! :)"  +/
Сообщение от баггзиemail (?), 17-Мрт-03, 00:13 
для TCP во всяком случае - манипулированием шириной окна. систему сделал, у некоторых стоит, вроде никаких жалоб.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

29. "а 'МОЖНО! :)'  тогда мыслями по этому повдоу  поделиться?"  +/
Сообщение от LSemail (?), 18-Мрт-03, 03:14 
>для TCP во всяком случае - манипулированием шириной окна. систему сделал, у
>некоторых стоит, вроде никаких жалоб.


Ответить | Правка | Наверх | Cообщить модератору

30. "можно..."  +/
Сообщение от баггзиemail (?), 18-Мрт-03, 09:43 
>>для TCP во всяком случае - манипулированием шириной окна. систему сделал, у
>>некоторых стоит, вроде никаких жалоб.

какими еще мыслями? все вроде уже сказано.

у TCP-пакета есть параметр "окно" (window), определяющее, сколько октетов информации готова принять сторона, сообщающая window (то есть пакеты с window идут в одну сторону, пакеты с данными - в обратную).

при window>MTU отсылается сразу несколько пакетов (например, 64K/1500 ~ 42). Сокращение параметра window до MTU вызовет снижение скорости в avg(window)/MTU раз за счет того, что за тот же промежуток времени отсылается только один пакет. Экспериментально снижение скорости составляет не меньше 10.

Остается только считать нагрузку на канал, и если она больше допустимой, менять на лету параметр window в TCP-пакетах, и это снижает нагрузку (до 10 раз). Этого достаточно, чтобы красиво резать трафик - без расхода памяти, загрузки процессора и глюков, возникающих из-за дропанья пакетов в других методах.

Недостатки:
1. ограничивает только TCP-составляющую. Впрочем, в подавляющем большинстве случаев именно TCP вызывает значительную загрузку канала.
2. при большой наглости (если желающие перегрузить канал откроют в 10 раз больше потоков, чем обычно) засрать канал таки удастся. решается добавлением дропалки при перегрузке, тогда лишние потоки будут только уменьшать результирующую скорость, и наглецы смиряцца и станут хорошими.

У меня есть только реализация под linux в виде пары модулей netfilter (рассчет нагрузки в байт/секунду и изменение окна TCP-пакета). Для прочих ОС и железок - пинайте своих кернелхакеров и фирмварщиков.

Ответить | Правка | Наверх | Cообщить модератору

31. "решение для оригинального вопрошавшего"  +/
Сообщение от баггзиemail (?), 18-Мрт-03, 10:05 
под linux ;) набирается из головы, могут быть баги.

ставится width-patch

#чайн для ограничения трафика (имя не важно)
iptables -N cutter

#ежели на всех хватает, то не надо резать, мы не жадные...
#жадным следующую строчку не надо
iptables -A cutter -m width --bytes=ширина канала в байтах/сек -j RETURN

#неприкосновенным не мешать!
iptables -A cutter -s привелегированный -j RETURN

#сюда идет трафик непривелегинованных ип в случае перегрузки канала
#мы его считаем и в случае чего снижаем окно до MTU-100
iptables -A cutter -p TCP -m width --bytes=СколькоМыИмДадим -j TCPWIN --set-win=1400

#ну и домой
iptables -A cutter -j RETURN

#тк я не стал заморачиваться с connection tracking'ом, а менять window нужно в пакетах, идущих в "обратную сторону", на самом деле ограничивается трафик в обе стороны - и входящий, и исходящий.

#направим весь трафик сходить сосчитаться и поправиться
iptables -A INPUT -j cutter
iptables -A OUTPUT -j cutter

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру