firstcalled Posted September 7, 2015 Добрый! Сразу расставлю точки над i: в linux новичок, поэтому большая просьба выражаться яснее и если вы используете спец. лексику, то используйте ее английские аналоги, чтобы я всегда мог загуглить и понять, о чем идет речь вообще. А теперь по существу вопроса. Что есть: системный блок с debian, 2 сетевых интерфейса, на этом деле настроена базовая маршрутизация и nat. Внешний интрефейс - eth0 - пусть будет 10.30.139.2/24, внутренний интерфейс - eth1 - пусть будет 192.168.1.2/24. Есть канал, равный 10мб в сек. Есть 10 пользователей. Чего хочется: чтобы он динамически делился, между всеми пользователями и чтобы все получали поровну. Прочитав мануалы с этих сайтов tldp.org/HOWTO/Traffic-Control-HOWTO/index.html и www.lartc.org/lartc.html и www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html и еще парочку, я примерно понял, как решение выглядит, но потом появился ряд вопросов: Во-первых, вся мощь tc утилины под linux используется только для исходящего трафика, входящий трафик мы не можем шейпить(shaping), все, что мы можем делать с ним - это откидывать(policing, согласно http://www.lartc.org), но я-то хочу не просто, чтобы 10 пользователей получали по 1мб. А чтобы, если канал используется двумя пользователями, то каждый бы получал по 5мб в среднем, если используется тремя, то по 3.3 и тд. Я думаю, вы поняли идею. А достичь этого просто при помощи отбрасывания пакетов мы не сможем. Начал искать и нашел такие вещи, как IMQ и IFB, но читая статьи про них и споры людей, понял, что это вроде бы как работает, но не является правильным использование этих "костылей". Тогда мне в голову пришла простая идея, ради которой и пишется сей опус, а что если шейпить входящий трафик(Internet -> eth0 -> внутренние процессы NAT и routing -> eth1 -> внутренняя сеть), но не на eth0, а на eth1?! Ведь для tc он будет считаться исходящим, ведь приходит он из внутренних процессов и отправляется в сеть, хотя для нас это, по факту, входяший трафик, верно? Или мои рассуждения неверны на корню? Во-вторых, насколько все-таки неверно использование IMQ и IFB? Правда ли это такие костыли, которых лучше избегать? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
disappointed Posted September 7, 2015 Без разницы, что на eth1 шейпить, что отзеркаленный на ifb с eth0 - суть не меняет, это трафик который пришёл от удалённой стороны, с ним можно только что-то сделать в надежде, что удалённый хост приостановит передачу. В принципе то, что описано приемлемо работает, но нужно запас оставлять в корневом классе, процентов 10-15 от реальной полосы, чтобы не упираться в шейпер/полисер вышестоящего оператора. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
firstcalled Posted September 7, 2015 Без разницы, что на eth1 шейпить, что отзеркаленный на ifb с eth0 - суть не меняет, это трафик который пришёл от удалённой стороны, с ним можно только что-то сделать в надежде, что удалённый хост приостановит передачу. В принципе то, что описано приемлемо работает, но нужно запас оставлять в корневом классе, процентов 10-15 от реальной полосы, чтобы не упираться в шейпер/полисер вышестоящего оператора. Спасибо за ответ! Насколько я помню и исходя из того, что я понял из QoS, если передающая сторона видит, что нет подтверждения от принимающей стороны того, что пакеты были доставлены, она, передающая сторона, должна уменьшить скорость передачи и повторить передачу недошедших пакетов. В squid это прекрасно работает. Должно работать и в tc. Есть, например, youtube и человек качает фильм, при этом полностью вычерпывает весь свой трафик, если мы настроим все правильно, то входящие пакеты, из-за отсутсвия места в очереди, будут отбрасываться, youtube будет снижать скорость и мы получаем то, что нужно. Верно же? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted September 7, 2015 QoS немного из другой оперы. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
evil-man Posted September 8, 2015 (edited) его хочется: чтобы он динамически делился, между всеми пользователями и чтобы все получали поровну. Прочитав мануалы с этих сайтов tldp.org/HOWTO/Traffic-Control-HOWTO/index.html и www.lartc.org/lartc.html и www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html и еще парочку, я примерно понял, как решение выглядит, но потом появился ряд вопросов: Добрый день! Того, что Вы описали, можно достигнуть, используя дисциплины очереди SFQ/FQ/QFQ и иже с ними, то есть любую Fair Queue дисциплину, которая распределяет ресурсы примерно равными частями между потоками. Так как вы отталкиваетесь от адреса источника (клиентский адрес), то надо будет повесить flow-фильтр с хешированием по адресу источника (на интерфейсе который смотрит в интернет) и адресу назначения (на интерфейсе, который смотрит в сторону клиентской сети). Edited September 8, 2015 by evil-man Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
disappointed Posted September 9, 2015 если передающая сторона видит, что нет подтверждения от принимающей стороны того, что пакеты были доставлены, она, передающая сторона, должна уменьшить скорость передачи и повторить передачу недошедших пакетов. Да, работает неплохо. Я в пору введения безлимов, когда цена каждого метра была поистине конской таким образом удерживал приемлемый интернет в условиях почти круглосуточной "полки". Самым критичным была именно подушка - запас по полосе, подбиралось экспереминтально, и ещё было важно чтобы вышестоящий оператор ни в коем случае не шейпил, а полисил, с большим бёрстом. Чтобы у него не образовывалась неподконтрольная очередь входящих пакетов. Тогда вообще на ура работать будет. Если применять сейчас то возможно будет проблема с торрентами по UDP, они довольно агрессивно работают. Можно попытаться дропать такой трафик по сигнатурам, там было за что зацепится на этапе установки соединения, но как с этим протоколом сейчас дела обстоят не знаю, возможно его уже обфусцировали. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vop Posted September 10, 2015 Если я правильно понял суть вопроса - старая проблема скрещивания NAT и shaper. Для того и используются либо псевдо-устройства, типа ifb, либо маркировка трафика до NATа для шейпера индивидуально для каждого абонента. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
kayot Posted September 11, 2015 vop Нет, у человека нет тоннелей или любых других виртуальных интерфейсов. Ему ничто не мешает шейпить на физических eth0 и eth1. Нужные примеры для реализации честного деления между абонентами есть в lartc, там 10 строк получится(HTB+SFQ и настройка rate/ceil). Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
disappointed Posted September 12, 2015 там 10 строк получится(HTB+SFQ и настройка rate/ceil). На полосах в сотни мегабит SFQ плохо придерживала торренты, я использовал bfifo с большим буфером. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vop Posted September 16, 2015 vopНет, у человека нет тоннелей или любых других виртуальных интерфейсов. Ему ничто не мешает шейпить на физических eth0 и eth1. У него есть NAT, и внешний интерфейс, на котором после ната трафик по абонентам не разделить. Или нет? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
