В Linux нещата са малко по-сложни. PRIO qdisc е класическа верижна дисциплина, която съдържа произволен брой класове с различен приоритет. При добавянето на пакет се избира суб-qdisc, определен от зададената в tc команда за филтриране. При създаването на нова верига PRIO, се създават три суб-верижни pfifo дисциплини. Всъщност, създават се 3 класа, именувани автоматично m:1, m:2 и m:3, където m е главния номер на верижната дисциплина. Всеки от тези класове се обединява с pfifo като отделен qdisc
Всеки път, когато трябва да се прибави пакет, той първоначално се насочва към клас :1. Когато той е празен, пакета се насочва към клас :2, а след това и към клас :3.
Тази дисциплина е много полезна за приоритизиране на определен трафик пред друг.
В tc тя има следните параметри:
- Връзки.
- Номер на създадените връзки. Всяка от тях е клас. Ако този номер се промени, трябва да бъде променена и prio-картата.
- Рrio-карта.
Ако за класифицирането на трафика не бъдат осигурени филтри, PRIO qdisc извлича информацията за неговото приоритизиране от TC_PRIO. Ядрото назначава на всеки пакет TC_PRIO – приоритет, основаващ се на TOS – флаговете или на предадените от приложението (socket options) опции.
TC_PRIO се определя и картографира от TOS, както следва:
Връзките са класове, именувани, по подразбиране, major:1 до major:3 така, че ако PRIO qdisc се именува 12:, tc филтрира трафика до 12:1 (връзка 0), за да гарантира приоритет. Това се повтаря като, връзка 0 става второстепенен (minor) номер 1, връзка 1 става второстепенен номер 2 и т.н.
Параметрите на рrio-картата сочат, че за да се създаде опашъчна дисциплина PRIO, трябва да бъдат създадени филтри, тъй като зададените по подразбиране параметри не са подходящи. Защо? За да бъде предпазен TOS. Настройките на PRIO qdisc, включващи използването на филтри са следните:
- Код за потвърждение: Избери целия код
# tc qdisc add dev eth0 root handle 1: prio
В посочената по-горе команда ръчно се задава номер 1:0 на PRIO qdisc (при използването на tc нулата може да бъде пропусната). Тъй като подреждането в PRIO е донякъде автоматизирано, тази команда съдава класове 1:1, 1:2 и 1:3, всеки от които съдържа инсталирана верига pfifо.
За задаването на филтри, към prio-класовете 1:1, 1:2 и 1:3 се назначават класове AF11, AF21 и AF31. Това означава:
AF11 = 1-2 = 001010
AF21 = 2-2 = 010010
AF31 = 3-2 = 011010
Това са шестте най-леви бита (кодови позиции DS); пълният TOS-байт ще съдържа два нулеви бита в дясно. В крайна сметка се получава:
AF11 = 00101000 = 0x28
AF21 = 01001000 = 0x48
AF31 = 01101000 = 0x68
Последното хексадесетично число се използва за създаването на филтри. Първия от тях е:
- Код за потвърждение: Избери целия код
# tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 \
match ip tos 0x28 0xff flowid 1:1
Обяснението на съдържанието на тази команда е, както следва:
- 'tc filter add dev eth0' – на утройство eth0 в tc се добавя филтър;
- 'parent 1:0' – източника на филтъра се идентифицира чрез номер 1:0 (или PRIO qdisc);
- 'prio 1' – този филтър има приоритет 1 (другите филтри ще имат, съответно, номера 2,3,4 и т.н., в този ред);
- 'protocol ip' – използва се IP протокол;
- 'u32' – конкретизира се вида на филтъра ;
- 'match ip' – тази част от командата задава на останалата й част да се съгласува с ip-хедера на пакета;
- 'tos 0x28 0xff' – указва отговарящите на класа tos-байтове (tc винаги умножава двете части: 0x28 * 0xff е равно на 0x28);
- 'flowid 1:1' означава, че потоците, отговарящи на този филтър, трябва да бъдат изпратени директно в класа, идентифициран с 1:1 (или клас PRIO 1:1).
Следващите две команди, с които се създава prio qdisc, са:
- Код за потвърждение: Избери целия код
# tc filter add dev eth0 parent 1:0 prio 2 protocol ip u32 \
match ip tos 0x48 0xff flowid 1:2
# tc filter add dev eth0 parent 1:0 prio 3 protocol ip u32 \
match ip tos 0x58 0xff flowid 1:3
Предимствата на PRIO са:
- За софтуер-базирани рутери, в сравнение с по-усложнените верижни дисциплини, PQ осигурява на системата по-малко изчислително време.
- PQ позволява на рутерите да организират буфериралите пакети, като обслужва един клас трафик различно от други класове. Например, на приложенията в реално време, както и на интерактивния звук и картина, може да бъде зададен приоритет, пред приложения, които не оперират в реално време.
PQ има и известни ограничения:
- Ако количеството на трафика с висок приоритет не е зададено в периферията на мрежата, трафикът с по-нисък приоритет може да бъде забавен, докато приоритизирания бъде обслужен.
- Ако обема на трафика с най-висок приоритет стане много голям, трафикът с по-нисък приоритет може да бъде пропуснат, докато буферното пространство, назначено за този трафик се препълни. В този случай е възможно комбинацията от пропускане и пренасочване на пакети и увеличената латентност да доведе до пълна липса на трафик с по-нисък приоритет. Недопускащата изключения конфигурация на PQ може да съдаде мрежова среда, в която, докато цялата мрежа е ангажирана с обработката на трафика с най-висок приоритет, се доставя приоритизирана услуга с ограниченото качество.
- Неадекватното поведение на потока с най-висок приоритет може значително да допринесе за забавяне и прекъсване в другите потоци с висок приоритет, които споделят същата опашка.
- PQ не е решение на ограниченията на FIFO, където при претоварване UDP-потоците се обработват с предимство пред TCP-потоците. Ако на PQ се зададе по-висок приоритет на TCP-потоците, механизмите за управление на прозорците и трафика ще се опитат да употребят целия трафик на изходящия порт.
С оглед вземането на оптимални решения, е по-важно да се знаят предимствата и недостатъците на всяка дисциплина, отколкото командите за нейното конфигуриране. (за повече инфо: Stef Coene, www.docum.org )
Източник: Основен
