Torrent-клиент на linux-шлюзе — миф или реальность?

Обзавёлся я как-то практически случайным образом материнской платой формата Mini-ITX на Intel Atom, и сразу же в голове мелькнула мысль: «Нешумный домашний сервер!..» (блок питания подойдёт ноутбучный + впаянный процессор с пассивным охлаждением). Подумано — сделано!

Докупил корпус, память, один 2.5 HDD (запланировав через пару месяцев взять такой же для зеркала), а так же вторую сетевую карту для раздачи интернета в локальную сеть, и вот на моём почти-сервере красуется новенький (на то время) Debian Squeeze.

Предвкушая вопрос «зачем понадобилось ядро именно с OpenVZ?», отвечу так: я из разряда людей, старающихся выжать из имеющегося всё и ещё чуть-чуть, поэтому, имея белую статику, было принято решение поднять web, mail и jabber сервера, плюс в качестве «и ещё чуть-чуть» заиметь там же torrent-качалку 24/7.

Всё бы ничего, если бы не одно НО — torrent-клиент на шлюзе! Звучит [не]много бредово, не так ли? Но не спешите с выводами: подобный бред вполне себе имеет право на жизнь. Более того, было найдено рабочее решение, которое позволило мирно сосуществовать качалке с другими сервисами на (практически) одном и том же сервере, а так же не мешать клиентам локальной сети. Но обо всём по порядку…

1. Немного теории

Я не один раз встречал утверждение, что заниматься шейпингом входящего трафика — дело неблагодарное, т.к. он уже пришёл, а значит откусил часть/всю ширину вашего канала у вышестоящей раздающей стороны (например, у провайдера). Это утверждение верное, но, как всегда, есть нюансы…

Во-первых, для tcp-соединений имеет место "медленный старт". Это значит, что пакеты между хостами не начнут отправляться сразу с максимальной скоростью. Вместо этого она (скорость) будет увеличиваться/уменьшаться постепенно с параллельной проверкой на подтверждения приёма пакетов и наличие потерь. Иными словами скорость отправки пакетов будет плавать, подстраиваясь под пропускную способность канала между хостами.

Приняв во внимание такое поведение, мы можем искусственно занижать скорость прохождения пакетов, тем самым навязывая хостам снижение скорости передачи,

Для tcp-соединений
 

1. Шейпим только исходящий трафик

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

из чего вытекает, что если torrent-клиент слушает входящий по отношению к направлению трафика интерфейс, то всё, что прилетает на этот интерфейс (в данном случае WAN) будет попадать в программу без какой-либо задержки со всеми вытекающими…

Тупик? Или всё же есть выход? Есть — venet-интерфейс на хостовой системе, который является виртуальной сетевой картой, работающей на третьем уровне OSI, и весь ip-трафик, прилетевший извне, перед тем, как попасть в контейнер, проходит через этот самый venet. Значит не всё так плохо: закинув torrent-клиент и остальные сервисы в контейнеры, я смогу преспокойно шейпить весь их трафик так же, как и для устройств, находящихся за физическим интерфейсом LAN.

Развернув на хосте VZ-контейнеры, получилась такая вот схема:

WAN — физический интерфейс, смотрящий в мир
VENET — виртуальный L3-интерфейс, через который проходит весь трафик, идущий в контейнеры (подсеть 192.168.254.0/24)
LAN — физический интерфейс, смотрящий в локальную сеть (подсеть 192.168.8.0/24)

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

У меня ширина канала в мир составляет 100 МБит/с, и абсолютно предсказуемо мне захотелось максимально использовать это в своих корыстных и не очень целях следующим образом:

• если в какой-то промежуток времени что-то тянется извне torrent-клиентом (контейнер BitTorrent) и только им, то всю имеющуюся полосу нужно отдать ему
• если во время скачивания torrent-клиентом чего-либо кто-то из локальной сети или подсети контейнеров начинает смотреть/качать с 80-го (или 443-го) порта, то torrent-трафик нужно зажать до, допустим, 1МБита/сек, а остальную ширину отдать под http-трафик
• самое главное — всю ширину канала должны иметь возможность использовать любые устройства независимо от того, в какой подсети они находятся: за LAN-интерфейсом или за VENET-интерефейсом

Звучит неплохо, не правда ли? А если ещё учесть, что 2-й пункт списка — малая доля требований, реализовав которые можно добиться идиллии из разряда «торренты тянутся, пинги бегают, youtube'чик смотрится, то желания воплотить это в жизнь появляется ещё больше.

Но, как было сказано выше, в случае входящих соединений извне делить всю ширину WAN-интерфеса между двумя интерфейсами (LAN — для локальной сети, VENET — для подсети контейнеров) не предоставляется возможным, т.к. корневой класс, которому будет выделена (почти) вся доступная ширина канала должен может принадлежать корневой дисциплине, которая вешается только на одно устройство. В данном случае это может быть либо LAN, либо VENET, но никак не оба одновременно.

http://habrahabr.ru/post/239949/