From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, FSL_HELO_BARE_IP_2, RCVD_IN_DNSWL_LOW, RCVD_NUMERIC_HELO, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS, T_HEADER_FROM_DIFFERENT_DOMAINS autolearn=no autolearn_force=no version=3.4.0 X-Injected-Via-Gmane: http://gmane.org/ To: community@lists.altlinux.org From: Anton Farygin Date: Wed, 19 Nov 2014 13:11:32 +0300 Message-ID: <546C6CD4.6050701@altlinux.com> References: <327084908.179208.1416210476735.JavaMail.zimbra@ilimnet.ru> <482551904.179209.1416210540268.JavaMail.zimbra@taf.ru> <1594679792.186263.1416225311668.JavaMail.zimbra@ilimnet.ru> <610468569.186291.1416225352167.JavaMail.zimbra@taf.ru> <546B2476.6010304@altlinux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.112.110.22 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: Subject: Re: [Comm] =?utf-8?b?0KDQsNGB0YjQuNGA0LXQvdC90YvQuSDRgdC40L3RgtCw0Lo=?= =?utf-8?b?0YHQuNGBINC60LvQsNGB0YHQuNGE0LjQutCw0YLQvtGA0LAgdTMyINC00Ls=?= =?utf-8?q?=D1=8F_iproute2_tc_filter?= X-BeenThere: community@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Community general discussions List-Id: ALT Linux Community general discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 10:11:50 -0000 Archived-At: List-Archive: List-Post: On 18.11.2014 18:41, Eugine Kosenko wrote: > Да, как я и думал. > > http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.qdisc.filters.html > > Если нет желания учить tc, то рекомендуют использовать критерий fw, > опираясь на маркеры iptables, а не критерий u32. Конечно, я на предыдущее письмо и хотел ответить в таком же макаре - зачем u32 для системы из двух хостов ? iptables в этом плане намного удобнее. > > 2014-11-18 14:38 GMT+00:00 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 >: > > On 17.11.2014 21:10, Eugine Kosenko wrote: > > 2014-11-17 13:55 GMT+02:00, 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 > > > > > > > _______________________________________________ > community mailing list > community@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/community >