traffic control + squid

Не очень понял. Средствами сквида регулировать устроит?

http://linuxnews.ru/docs/squid.html

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

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

Нет, конечно сквид управляет только своим трафиком и про внешний, относительно него, ничего не знает.

Но только я не понимаю, почему нельзя выделить весь трафик сквида и указать ему приоритет. А свой трафик уже пусть сам разбирает, там tc не нужен. Ограничивать полосу он умел всегда.

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

> Так что в качестве простого и тупого решения могу посоветовать выделить отдельную машину для шейпинга. Можно даже виртуальную.

Спасибо, но как раз хотелось бы более сложного решения.

> Но только я не понимаю, почему нельзя выделить весь трафик сквида и указать ему приоритет. А свой трафик уже пусть сам разбирает, там tc не нужен. Ограничивать полосу он умел всегда.

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

А все о того, что вы пытаетесь делить на ноль :)

Управление входящим трафиком в принципе аналогично делению на ноль - красивого и изящного решения нет, заглушки ужасны, и вообще этого лучше не делать.

> Управление входящим трафиком в принципе аналогично делению на ноль - красивого и изящного решения нет, заглушки ужасны, и вообще этого лучше не делать.

Ну вы же не хотите сказать, что это принципиально неразрешимая задача?

Может, "приоритетных потребителей" трафика не заворачивать на сквид, а пускать напрямую через tc ?
Либо, поднять им второй(приоритетный) сквид. и уже трафик второго сквида пускать через приоритетную очередь tc.

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

>Ну вы же не хотите сказать, что это принципиально неразрешимая задача?

Хочу. Впрочем, это сказали уже до меня.

Но вот, кстати, интересно, когда я на сквиде режу скорость клиенту, то что при этом происходит? Сервер видит что принимают медленно и начинает медленнее отдавать? Или оно буферизуется локально?

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

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

Судя по всему именно такое положение дел имеет место быть

>>Ну вы же не хотите сказать, что это принципиально неразрешимая задача?

>Хочу. Впрочем, это сказали уже до меня.

Я не говорил о принципиальной неразрешимости. Иначе бы тему не создавал. Я просто не знаю как решить эту задачу средствами iproute2, iptables, squid.

О ней подробно рассказал sin_a.

>Я не говорил о принципиальной неразрешимости. Иначе бы тему не создавал. Я просто не знаю как решить эту задачу средствами iproute2, iptables, squid.

Стандартными средствами эту задачу не решить. Шейпер в линукс работает только с исходящим трафиком. Тут высказывалась мысль, что если пытаться шейпить входящий, то это будет приводить только к повторной посылке удаленным сервером дропнытых на шейпере пакетов. Я не гуру, но логично предположить, что когда скачивается по модему файл со скоростью 5кбайт/c с хостинга, который подключен к гигабитному порту в rent.net, что этот сервер не будет забивать весь свой канал дупами непринятых вашим модемом пакетов. Так что смысл во входящем шейпере есть. Я знаю, только один способ его организовать - это патчить iptables и ядро IMQ. Это очень заебный и неочевидный способ, но другого я не знаю.

Бля, скажите мне как вставить код в ЛОР. Не смог вставить пример настройки iptables

> Я знаю, только один способ его организовать - это патчить iptables и ядро IMQ. Это очень заебный и неочевидный способ, но другого я не знаю.

И можно будет чтобы локально сгенерированный трафик с ftp и http серверов тоже через imq1 (исходящий траф от сервера в инет) проходил? Я так понял, что с этим проблемы

Когда-то в древние времена тестировал squid (кажется 2.5) на предмет delay pool-ов - тест показывал, что при зажимании отдачи delay pool-ами, внешний входящий трафик тоже снижался.

> IMQ ... не может работать с локально генерируемым трафиком
Это где такое написано ?

> чтобы локально сгенерированный трафик с ftp и http серверов тоже через imq1
iptables -t mangle -A POSTROUTING -j IMQ --todev 1

Это в общем, а так конечно надо выделить этот локальный трафик (отделить от транзитного):
iptables -t mangle -A POSTROUTING -s $local_ip -j IMQ --todev 1

$local_ip указывать в соответствии с тем, как относительно NAT будет выполняться вход в IMQ (задаётся в ядре, может быть "before nat" и "after nat")

Разыскивается толковое описание использования IFB устройства для решения вышеописанной задачи. Кто имел дело с IFB - прошу помочь разобраться. Документация скудная, из примеров мало что понятно.

Вроде как получилось. Завтра проверка в полевых условиях. Эксперимент показал хоть и ощутимое падение интерактивности ssh и rdp, но все же приемлемое. Правда это на одном входящем потоке на сервере. Завтра проверю при реальных многопоточно-многопользовательских нагрузках. Сделано перенаправлением входящего на интернет-интерфейс трафика на виртуальное устройство IFB (поддерживается ядром где-то с 2.6.22), на этом устройстве соответственно шейпится весь входящий трафик, по классам, как положено. С этого же устройства трафик либо идет локальным приложениям (сквиду) либо на внутренний интерфейс пользователям через нат (ssl, например). Исходящий в интернет трафик шейпится на выходе интернет-интерфейса. В скором времени отпишусь о результатах полевых испытаний.

Мда. Очереди у htb перегружены, пакеты не дропаются а задерживаются, из-за этого большой лаг (300-500 мс). Зато поточные приложения работают нормально (закачка файлов, например), а от интерактивных (ssh, rdp) остаются самые плохие впечатления. Впрочем, не хуже чем было без использования htb. И что главное - в htb нельзя установить длину очереди, как в tbf :( из-за этого весь интерактив своидтся на нет. И по-моему не очень он следует приоритетам :\