<div dir="ltr"><div>Да, как я и думал.<br><br><a href="http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.qdisc.filters.html">http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.qdisc.filters.html</a><br><br></div>Если нет желания учить tc, то рекомендуют использовать критерий fw, опираясь на маркеры iptables, а не критерий u32.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-11-18 14:38 GMT+00:00 Eugine Kosenko <span dir="ltr"><<a href="mailto:eugine.kosenko@gmail.com" target="_blank">eugine.kosenko@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">В целом я описал проблему тут:<br><div><div><div><br><a href="http://lists.altlinux.org/pipermail/community/2014-November/683031.html" target="_blank">http://lists.altlinux.org/pipermail/community/2014-November/683031.html</a><br><br></div><div>В общем, испытываю все прелести разделенного узкого канала.<br><br></div><div>Кроме описанных бед есть еще несколько. Например, на обеих машинах стоят менеджеры закачек: на Linux (роутере) это aria2, на Windows (клиенте) ---- некий Download Manager. Менеджеры закачек ведут себя настолько агрессивно, что во время их работы невозможно даже открыть страницу в браузере. Очень часто не удается добраться до ftp при выполнении apt-get.<br><br></div><div>Можно, конечно же, подрезать скорость пакетной закачки средствами самих менеджеров. Но тогда они не используют всю ширину канала, если никто не работает в браузере.<br><br>Трафик из браузера можно назвать "интерактивным" и обеспечить ему приоритет обслуживания и гарантированную скорость. Но это не совсем та интерактивность, которую предлагают обеспечить, например, тут:<br><br><a href="http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.interactive-prio.html" target="_blank">http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.interactive-prio.html</a><br></div><div><br></div><div>Дело в том, что закачки почти всегда идут через HTTP, изредка через FTP. Такой трафик неразличим по порту назначения. Важен не порт, а процесс, который является источником трафика. Например, в упомянутом мною Download Master есть возоможность автоматически снижать скорость закачки при обнаружении активности браузера. Но у aria и apt-get ведь такой возможности нет.<br><br>Более абстрактно могу поставить задачу так. Есть два типа приложений --- "интерактивные", которым нужно первоочередное обслуживание и гарантированная полоса, и "пакетные", которым неважна очередность и скорость, но при отсутствии "интерактивного" трафика им должна быть предоставлена вся максимально возможная полоса. При этом в каждом классе приоритеты, в принципе, неважны, достаточно любой "честной" дисциплины типа той же SFQ. И еще неважно, на какой из машин генерируется трафик --- на роутере или на клиенте. И та и та станция генерируют трафик обоих типов (хотя иногда хочется предоставить больше возможностей моему трафику на роутере под Linux, то есть, выделить его в промежуточный класс с определенными гарантиями обслуживания).<br><br></div><div>Пока что вижу решение в том, чтобы дисциплинарно направить весь "интерактивный" трафик на squid-прокси, а ему предоставить необходимые гарантии обслуживания (в перспективе кроме squid можно направить туда же еще пару "критичных" приложений типа того же apt). Однако в целом это решение выглядит криво. Во-первых, на уровне iptables придется выделять пакеты в цепочке OUTPUT по признаку pid-owner, где должен быть подставлен pid прокси (а их ведь несколько). Кроме того, это означает искусственную донастройку iptables в момент старта squid в обход etcnet, что тоже некрасиво. Во-вторых, непонятно, что с этими выделенными пакетами делать --- маркировать или направить на виртуальный "интерфейс для балансировки". С интерфейсом примерно понятно, но такое решение кажется слишком сложным и включает, как мне кажется, ненужный форвардинг. А вот можно ли при балансировке классифицировать пакеты по поставленым ранее меткам --- это я и хотел выяснить.<br><br></div><div></div><div>Ну и вообще смотрю, что можно еще сделать в этой ситуации.<br></div><div><br></div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2014-11-18 10:50 GMT+00:00 Anton Farygin <span dir="ltr"><<a href="mailto:rider@altlinux.com" target="_blank">rider@altlinux.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 17.11.2014 21:10, Eugine Kosenko wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2014-11-17 13:55 GMT+02:00, <a href="mailto:alexei@taf.ru" target="_blank">alexei@taf.ru</a> <<a href="mailto:alexei@taf.ru" target="_blank">alexei@taf.ru</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Хм... Я не понял что вас еще надо от u32 помимо того, что уже есть в<br>
указанной доке.<br>
</blockquote>
<br>
Конкретно интересует именно содержимое раздела 12.1.3:<br>
<br>
<a href="http://lartc.org/howto/lartc.adv-filter.html#AEN1327" target="_blank">http://lartc.org/howto/lartc.<u></u>adv-filter.html#AEN1327</a><br>
<br>
Именно в этом разделе описаны те самые специфичные селекторы, которые<br>
меня интересует. Увы, раздел по большей части состоит из<br>
процитированных мной FIXME. То есть, такая таблица есть, но вынесена в<br>
отдельный файл, ссылки на который в тексте не дается. Хотя я очень<br>
хотел бы увидеть именно эту таблицу, даже если она на польском языке.<br>
<br>
Отдельные примеры дают только общее представление. Меня, например,<br>
интересует, можно ли понятным образом проанализировать метки пакета<br>
после прохождения iptables? Я не силен в RFC и боюсь наделать ошибки,<br>
вычисляя смещения и двоичные значения полей.<br>
<br>
Ну и вообще, как мне кажется, документация должна быть полной, не так ли?<br>
</blockquote>
<br></div></div>
Нет желание рассказать конечную цель, которую вы пытаетесь достигнуть чтением документации ?<br>
<br>
Я для u32 пользуюсь такой штукой как shapercontrol - всё просто и понятно.<br>
<br>
Да, на последних ядрах u32 сломан для i586. Имейте это ввиду.<div><div><br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
community mailing list<br>
<a href="mailto:community@lists.altlinux.org" target="_blank">community@lists.altlinux.org</a><br>
<a href="https://lists.altlinux.org/mailman/listinfo/community" target="_blank">https://lists.altlinux.org/<u></u>mailman/listinfo/community</a></div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>