Использование IFB вместо IMQ
Версия от 10:18, 18 ноября 2008; Misha (обсуждение | вклад) (Новая: Попробую перевести статью [http://www.linuxfoundation.org/en/Net:IFB Net:IFB]<br> Не пинайте, за плохой Английский. Переводил ...)
Попробую перевести статью Net:IFB
Не пинайте, за плохой Английский. Переводил с помощью www.translate.ru
Net:IFB
Промежуточное Функциональное Устройство (IFB) блочной конструкции - наследник IMQ iptables модуля, который никогда не объединялся. Преимущество перед текущим IMQ; уборщик в особенности в SMP; с _lot_ меньше кодекса. Старые Фиктивные функциональные возможности устройства сохранены, в то время как новый одно единственное умирает, если Вы используете действия.
Использование IFB
Насколько я знаю, ниже приведены причины, почему люди используют IMQ. Было бы хорошо узнать еще что-то, что я пропустил.
- qdiscs/policies, которые являются за устройство в противоположность широкой системе. IMQ учитывает разделение.
- Позволяет организацию входящих очередей для ограничения, вместо понижения. Я не знаю ни о каком исследовании, которое показывает, что охрана хуже чем формирование в достижении цели конца контроля за нормой. Мне было бы интересно, если любой экспериментирует.
- Очень интересное использование: если Вы используете p2p, и Вы хоте дать предпочтение своему собственного локальному трафику (когда ответы возвращаются) тому, кто использет Вашу систему, чтобы сделать bittorent. Таким образом QoSing, основанный на состоянии, входит как решение. Что люди сделали к achive, это было палкой IMQ где-нибудь предместный крюк. Я думаю, что это - довольно опрятная особенность, чтобы иметь в Linux вообще. (то есть не только для IMQ).
As far as i know the reasons listed below is why people use IMQ. It would be nice to know of anything else that i missed.
- qdiscs/policies that are per device as opposed to system wide. IMQ allows for sharing.
- Allows for queueing incoming traffic for shaping instead of dropping. I am not aware of any study that shows policing is worse than shaping in achieving the end goal of rate control. I would be interested if anyone is experimenting.
- Very interesting use: if you are serving p2p you may wanna give preference to your own localy originated traffic (when responses come back) vs someone using your system to do bittorent. So QoSing based on state comes in as the solution. What people did to achive this was stick the IMQ somewhere prelocal hook. I think this is a pretty neat feature to have in Linux in general. (i.e not just for IMQ).