Как работает приоретизация трафика

ты можешь управлять только тем, что у тебя есть. «Приоритезировать» входящий трафик можно лишь после получения этого трафика (либо перекладывать эту задачу на предыдущие хопы, например, на твоего провайдера), ограничивая его для последующих получателей (клиентов). Управлять исходящим трафиком можно до его отправки, объявляя некоторое количество очередей и определяя порядок «выливания» данных из этих очередей. Можешь помечать трафик для указания следующим хопам о твоих требованиях к передаче этого трафика, но обрубать/давать зелёный свет будешь уже не ты, а кто-то далее, и этот кто-то может переопределить твой трафик в другой класс, перепометить или вообще снять метки, либо применять к твоим классам трафика совершенно левые правила приоритезации.

Твой вариант с торрентами: допустим, ты крепкий сидер, 30ТБ и прочие награды. Раздаёшь всю коллекцию дебиана, начиная с самых первых преальф. Канал в исходящем направлении забит под завязку. Но тебе захотелось испросить с гуголя страничку, о чём и был составлен запрос. Этот запрос инкапсулируется в IP-пакет и отлавливается твоим локальным приоритезатором как требующи особого отношения (синее ведёрко и т.д.). Забитый канал питается из некоторой очереди, в которой стройными рядами выстроены пакеты торрентов, но, согласно метке, твой запрос становится в самое начало очереди и отправляется при первой же возможности. Входящий же трафик есть стихия. Ты можешь лишь разбирать поток всякого хлама в надежде найти там ответы на твои запросы или чьи-либо сообщения, адресованные тебе. Либо! ты можешь договориться с провайдером, который со своей стороны будет обрабатывать трафик согласно некоторым правилам, например, так же как и ты помечая tcp:80-трафик синим ведёрком и отправляя его тебе в обход общей очереди.

И не следует забывать о сопутствующих технологиях аля tcp-windowing и его аналогам канального/сетевого/транспортного/прикладного уровней.

з.ы. а вообще - пора отдыхать. Иначе «много прочитал и мало понял» будет продолжаться.

вотъ luigi@ вещает час о dummynet с картинками
http://www.youtube.com/watch?v=r8vBmybeKlE
hint: есть субтитры

См. основы IP/TCP стека, в особенности TCP congestion алгоритмы и жизннный цикл TCP соединения. Тогда станет понятно почему возможности по приоритезации такие ограниченные и получишь ответы на большую часть своих вопросов. Потом уже можно читать lartc и т.п.

Спасибо, кое-что понятно.
Тогда применяя теорию к моей конкретной задаче:
Нужно чтобы торрент клиент deluge на домороутере автоматом понижал скорость закачки, если компы-клиенты, подключенные к домороутеру, запрашивают инфу из сети (например, http трафик).
Получается, что это невозможно, т.к провайдер не предоставляет возможности приоретизации трафика, поэтому я не могу заставить http трафик быстрее приходить ко мне, следовательно я не могу реализовать мою задачу. Верно?

Получается, что это невозможно, т.к провайдер не предоставляет возможности приоретизации трафика, поэтому я не могу заставить http трафик быстрее приходить ко мне, следовательно я не могу реализовать мою задачу. Верно?

Невозможно полностью решить задачу на уровне пакетов, но на уровне приложения (т.е. торрент клиента) можно, если оно само умеет ограничивать свой входящий трафик: нужно мониторить объёмы http трафика и в соответствии с ним урезать квоты в клиенте.

я не могу заставить http трафик быстрее приходить ко мне

Можно попробовать добиться этого несколько очистив канал от других видов трафика.
Схема работы: есть канал шириной X, если он, к примеру, забит под потолок torrent-ами, то новому HTTP трафику будет проблематично протиснуться, даже, если правила shaper-а выставляют для него больший приоритет и могут «подвинуть» torrent-ы. Для этого можно выделить резервную полосу - сказать shaper-у, что размер канала у нас не X, а Y = X - сколько_то. Таким образом внезапно возникший входящий трафик сможет пролезть при работе торрентов на максимуме.
Соответственно shaper увидит этот HTTP трафик, подумает, что прийдя он занял какую-то полосу от полосы Y, и начнёт ужимать torrent-ы до уровня torrent+HTTP = Y. Снова у нас останется запасная полоса X-Y, готовая пропустить новую волну трафика.

А ограничивать входящий можно так же, как и исходящий. Не важно, что он к нам уже пришёл, важно, что первым его получает ядро, а не коненчная программа. Конечной программе его можно выдавать не сразу, а по чуть-чуть - получится то же самое, что и задержка трафика на шлюзе провайдера. Программа тогда будет медленнее слать уведомления об успешной доставке пакетов, которые как раз и вызывают приход новых.

Возможно написал несколько сумбурно, но думаю основную мысль понять можно :-)