[Comm] Расширенный синтаксис классификатора u32 для iproute2 tc filter

[Eugine Kosenko]

В целом я описал проблему тут:

http://lists.altlinux.org/pipermail/community/2014-November/683031.html

В общем, испытываю все прелести разделенного узкого канала.

Кроме описанных бед есть еще несколько. Например, на обеих машинах стоят
менеджеры закачек: на Linux (роутере) это aria2, на Windows (клиенте) ----
некий Download Manager. Менеджеры закачек ведут себя настолько агрессивно,
что во время их работы невозможно даже открыть страницу в браузере. Очень
часто не удается добраться до ftp при выполнении apt-get.

Можно, конечно же, подрезать скорость пакетной закачки средствами самих
менеджеров. Но тогда они не используют всю ширину канала, если никто не
работает в браузере.

Трафик из браузера можно назвать "интерактивным" и обеспечить ему приоритет
обслуживания и гарантированную скорость. Но это не совсем та
интерактивность, которую предлагают обеспечить, например, тут:

http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.interactive-prio.html

Дело в том, что закачки почти всегда идут через HTTP, изредка через FTP.
Такой трафик неразличим по порту назначения. Важен не порт, а процесс,
который является источником трафика. Например, в упомянутом мною Download
Master есть возоможность автоматически снижать скорость закачки при
обнаружении активности браузера. Но у aria и apt-get ведь такой возможности
нет.

Более абстрактно могу поставить задачу так. Есть два типа приложений ---
"интерактивные", которым нужно первоочередное обслуживание и
гарантированная полоса, и "пакетные", которым неважна очередность и
скорость, но при отсутствии "интерактивного" трафика им должна быть
предоставлена вся максимально возможная полоса. При этом в каждом классе
приоритеты, в принципе, неважны, достаточно любой "честной" дисциплины типа
той же SFQ. И еще неважно, на какой из машин генерируется трафик --- на
роутере или на клиенте. И та и та станция генерируют трафик обоих типов
(хотя иногда хочется предоставить больше возможностей моему трафику на
роутере под Linux, то есть, выделить его в промежуточный класс с
определенными гарантиями обслуживания).

Пока что вижу решение в том, чтобы дисциплинарно направить весь
"интерактивный" трафик на squid-прокси, а ему предоставить необходимые
гарантии обслуживания (в перспективе кроме squid можно направить туда же
еще пару "критичных" приложений типа того же apt). Однако в целом это
решение выглядит криво. Во-первых, на уровне iptables придется выделять
пакеты в цепочке OUTPUT по признаку pid-owner, где должен быть подставлен
pid прокси (а их ведь несколько). Кроме того, это означает искусственную
донастройку iptables в момент старта squid в обход etcnet, что тоже
некрасиво. Во-вторых, непонятно, что с этими выделенными пакетами делать
--- маркировать или направить на виртуальный "интерфейс для балансировки".
С интерфейсом примерно понятно, но такое решение кажется слишком сложным и
включает, как мне кажется, ненужный форвардинг. А вот можно ли при
балансировке классифицировать пакеты по поставленым ранее меткам --- это я
и хотел выяснить.

Ну и вообще смотрю, что можно еще сделать в этой ситуации.


2014-11-18 10:50 GMT+00:00 Anton Farygin <rider на altlinux.com>:

> On 17.11.2014 21:10, Eugine Kosenko wrote:
>
>> 2014-11-17 13:55 GMT+02:00, alexei на taf.ru <alexei на taf.ru>:
>>
>>> Хм... Я не понял что вас еще надо от u32 помимо того, что уже есть в
>>> указанной доке.
>>>
>>
>> Конкретно интересует именно содержимое раздела 12.1.3:
>>
>> http://lartc.org/howto/lartc.adv-filter.html#AEN1327
>>
>> Именно в этом разделе описаны те самые специфичные селекторы, которые
>> меня интересует. Увы, раздел по большей части состоит из
>> процитированных мной FIXME. То есть, такая таблица есть, но вынесена в
>> отдельный файл, ссылки на который в тексте не дается. Хотя я очень
>> хотел бы увидеть именно эту таблицу, даже если она на польском языке.
>>
>> Отдельные примеры дают только общее представление. Меня, например,
>> интересует, можно ли понятным образом проанализировать метки пакета
>> после прохождения iptables? Я не силен в RFC и боюсь наделать ошибки,
>> вычисляя смещения и двоичные значения полей.
>>
>> Ну и вообще, как мне кажется, документация должна быть полной, не так ли?
>>
>
> Нет желание рассказать конечную цель, которую вы пытаетесь достигнуть
> чтением документации ?
>
> Я для u32 пользуюсь такой штукой как shapercontrol - всё просто и понятно.
>
> Да, на последних ядрах u32 сломан для i586. Имейте это ввиду.
>
>
>
>
> _______________________________________________
> community mailing list
> community на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/community
>
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/community/attachments/20141118/a90e7ec6/attachment.html>