The OpenNET Project / Index page

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

Использование dummynet для ограничения трафика во FreeBSD

20.05.2005 14:49

Посетитель под ником napTu3aH написал статью, в которой попытался на примерах раскрыть некоторые тонкости и особенности лимитирования трафика, при использовании pipe в ipfw.

  1. Главная ссылка к новости (http://www.opennet.dev/base/net...)
  2. OpenNews: Ipfw и управление трафиком в FreeBSD
  3. Неофициальный перевод системной документации по ipfw
  4. Управление трафика в IPFW через использование IPFW WF2Q+ очередей
  5. OpenNews: Руководство по IPFW на русском языке
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/5495-ipfw
Ключевые слова: ipfw, pipe, bandwidth, dumynet
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (12) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, FAKE (?), 18:09, 20/05/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вобщем-то доходчиво написано, но ничего нового кроме ipfw -f pipe flusр
     
     
  • 2.2, toor99 (ok), 18:33, 20/05/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Ну а что там может быть принципиально нового? Dummynet делает примитивный тейлдроп, со всеми его недостатками.  А более совершенную  altq во FreeBSD, насколько я понимаю, никто перетаскивать не собирается.
     
     
  • 3.3, gate (?), 18:44, 20/05/2005 [^] [^^] [^^^] [ответить]  
  • +/
    > А более совершенную  altq во FreeBSD, насколько я понимаю, никто перетаскивать не собирается.

    А зачем собираться? altq уже давно в пятой ветке.

     
  • 3.5, citrin (ok), 19:29, 20/05/2005 [^] [^^] [^^^] [ответить]  
  • +/
    >  Ну а что там может быть принципиально нового? Dummynet делает примитивный тейлдроп, со всеми его недостатками

    Там есть еще RED и GRED. А вот подбор оптимальных параметров для RED это очень сложная задача.

     
  • 3.6, uldus (ok), 22:12, 20/05/2005 [^] [^^] [^^^] [ответить]  
  • +/
    >со всеми его недостатками.  А более совершенную  altq во
    >FreeBSD, насколько я понимаю, никто перетаскивать не собирается.

    Использовал ALTQ в FreeBSD 2.2.1, когда в других операционках шейперами и не пахло. Кстати, и сейчас мало какой шейпер докатился до уровня тогдашнего ALTQ. Если бы не появился простой и предельно ясный Dummynet, ALTQ давно был бы официально в системе.

     

  • 1.4, GR (??), 18:44, 20/05/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Toor99 или у меня затмение или ....
    http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-pf.html
    :-)
     
  • 1.7, adsh (??), 02:56, 21/05/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё хорошо, только лучше ещё использовать GRED - меньше будет потерь и скорость не будет всё время скакать туда / сюда как бешенная. Ну и размеры очередей пакетов подобрать.
     
     
  • 2.8, dmitry (??), 13:04, 23/05/2005 [^] [^^] [^^^] [ответить]  
  • +/
    как правильно GRED и размер очереди подобрать. каким алгоритмом руководствоваться?

     
     
  • 3.10, adsh (??), 22:45, 23/05/2005 [^] [^^] [^^^] [ответить]  
  • +/
    >как правильно GRED и размер очереди подобрать. каким алгоритмом руководствоваться?

    С эти очень просто. Поскольку очередь не может быть больше 2*max_th - то такую её и ставим.

    Для канала в несколько мегабит рекомендую:

    pipe 100 config bw 1Mbit/s queue 60 gred 0.002/10/30/0.1
    queue 100 config pipe 100 queue 60 mask dst-ip 0xffffffff gred 0.002/10/30/0.1
    add queue 100 tcp from aaa.bbb.ccc.ddd 80 to any via fxp0 out

    В данном случае - весь исходящий тафик веб сервера равномерно распределяется между всеми пользователями и не зависит от количества сессий, открытых каждым клиентом. Пример - для сервера - файлопомойки.

     
     
  • 4.12, net11 (?), 14:31, 24/05/2005 [^] [^^] [^^^] [ответить]  
  • +/
    >>как правильно GRED и размер очереди подобрать. каким алгоритмом руководствоваться?
    >
    >С эти очень просто. Поскольку очередь не может быть больше 2*max_th -
    >то такую её и ставим.
    >
    >Для канала в несколько мегабит рекомендую:
    >
    >pipe 100 config bw 1Mbit/s queue 60 gred 0.002/10/30/0.1
    >queue 100 config pipe 100 queue 60 mask dst-ip 0xffffffff gred 0.002/10/30/0.1
    >
    >add queue 100 tcp from aaa.bbb.ccc.ddd 80 to any via fxp0 out
    >
    >
    >В данном случае - весь исходящий тафик веб сервера равномерно распределяется между
    >всеми пользователями и не зависит от количества сессий, открытых каждым клиентом.
    >Пример - для сервера - файлопомойки.


    Не подскажите как лучше поделить канал 256к на клиентов по 64к, какие очереди поставить и параметры gred
    подскажите плизз

     

  • 1.9, santa (?), 13:28, 23/05/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я не согласен с этим

    >Оба пользователя непрерывно качают примерно одинаковый поток данных.
    >Один из них начал качать раньше. Когда появился второй, то система
    >начала ограничивать поток для первого до 110/2=55 Кбит/с. Считая что
    >второму также будет отведено 55Кбит/с, однако
    .....

    в примерах
    ipfw queue 1 config pipe 1 weight 50 queue 20
    weight 50 - не означает деления канала на части,
    а говорит о приоритете, то есть если у двух очередей одинаков приоритет
    то пакеты из этих очередей будут выходить по очереди и канал действительно будет делится поровну (если приоритет одинаков).

    поэтому если канал реально 80Кбит/с а pipe на 110Кбит/с
    вырисовывается другая картина.
    если первый пользователь начал раньше качать то его очередь
    единственная и он полностью подгребает канал под себя.
    если начинает качать второй юзер (подразумевается что приоритеты
    очередей у них одинаковы и не обязательно 50) то пакеты из очередей выходят равномерно, а значит скорость делится поровну 80/2=40Кбит/с.

    скорость pipe больше чем реальная нужно ставить тогда, когда нужно не ограничить
    скорость а распределить по приоритетам.
    Я например не зажимаю никого, а всем даю одинаковый приоритет чтоб никто не смог
    большим количеством сессий подгребать под себя канал

     
  • 1.11, eplumber (??), 08:07, 24/05/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сделал
    Работает
    Риспект
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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