forum.lissyara.su

Я совсем уже запутался

из статьи "PF: разбираем конфиг для офисов"

PS: долго не мог понять почему у меня на шлюзе, на котором кроме раздачи трафика в локалку крутится rtorrent (для rtorrent выделена отдельная очередь) торрентовский трафик съедал всю полосу download, хотя имел более низкий приоритет по сравнению с остальными очередями. Потом дошло: его download трафик не проходит через внутренний интефейс и соответсвенно не может быть зашейплен. Upload пожалуйста, download нет. Хотя теоретически можно было бы для rtorrenta завести отдельный компьютер и расположить его внутри локальной сети, "за фаерволом".

То есть зашейпить download rtorrent'а невозможно в принципе?

ХОТЯ. Чисто тероетически: Если а) канал симметичен б)BitTorrent по TCP. То можно детектить перегрузку входящего трафика на внешнем интерфейсе и искусственно задерживать отправку ACK'ов для torrent'овских пакетов. Квитанции идут с задержкаии -> скорость на download'е падает.
я уже весь мозг себе съел

Входящий трафик традиционно не ограничивают. Такого мнения придерживаются и разработчики OpenBSD. Есть горячие головы, которые утверждают, что ограничивать полосу для входящего трафика даже нужно, но понятных мне аргументов так и не услышал.
Логично разделять сервисы, т.е. пограничный маршрутизатор/шлюз/МСЭ выполняет свои функции (маршрутизация, фильтрование, ограничение полосы, трансляция адресов и т.д.), а torrent-клиент крутиться на выделенном узле.
=====
С самим torrent'ом то-же не всё так просто: он стремительно переползает на UDP-транспорт. Об очередях и приоритетах толково написано в статье "Использование Hierarchical Fair Service Curve (HFSC) в OpenBSD" (_http://dreamcatcher.ru/2009/11/30/Использование-hierarchical-fair-service-curve-hfsc-в-openbsd/).
=====
И никто не отменял настройки прожорливости самого torrent-клиента.

Спасибо за статью! Интересно и доступно. После прочтения решил отказаться от CBQ в пользу HFSC.

Не отрицаю, что можно ограничить полосу самим torrent-клиентом. Но не спортивно это, и вся соль от шейпингования пропадает.

Сценарий: есть клиент в локальной сети, который качает что то с большой скоростью. Входящий трафик поступает на интерфейс шлюза, исходящий - только ACK'и. Это на внешке. PF полученный трафик зажимает и медленно отдает в локалку. Удаленный Интернет-сервер начинает передавать пакеты медленнее, т.к. понимает, что трафик стал задерживаться. Так ведь обычно работает шейпинг?

А в случае если сервер и есть клиент, исходящего трафика выходит нет. И ничего не мешает серверу захватить всю полосу пропускания. Так выходит?

много думаю...

Va_ писал(а):Спасибо за статью! Интересно и доступно. После прочтения решил отказаться от CBQ в пользу HFSC.

Да пожалуйста, только она не мной написана.

Va_ писал(а):Не отрицаю, что можно ограничить полосу самим torrent-клиентом. Но не спортивно это, и вся соль от шейпингования пропадает.

Вам шашечки или ехать (с) Народная мудрость.

Va_ писал(а):Сценарий: есть клиент в локальной сети, который качает что то с большой скоростью. Входящий трафик поступает на интерфейс шлюза, исходящий - только ACK'и. Это на внешке. PF полученный трафик зажимает и медленно отдает в локалку. Удаленный Интернет-сервер начинает передавать пакеты медленнее, т.к. понимает, что трафик стал задерживаться. Так ведь обычно работает шейпинг?

То, что вы описали - это результат взаимодействия TCP/IP-стека и шейпера. Шейпер просто ограничивает полосу, но вцелом - правильно.

Va_ писал(а):А в случае если сервер и есть клиент, исходящего трафика выходит нет. И ничего не мешает серверу захватить всю полосу пропускания. Так выходит?

Или так: входящий трафик сервиса не является исходящим для какого-либо интерфейса и его ограничение - не тривиальная задача.

А вариант с ограничением upload/download в ~/.rtorrent.rc вам не подходит?

unix-admin писал(а):А вариант с ограничением upload/download в ~/.rtorrent.rc вам не подходит?

Не подходит. Если других пользователей нет, то rtorrent должен использовать всю полосу. Если есть - занижать скорость торрентов. В конфиге торрента явное указание на скорость.

BlackCat, до меня дошло. Спасибо