Управление входящим трафиком.
NFS_Daemon 11 декабря, 2009 - 18:08
Хотелось бы узнать как можно выставлять приоритеты и ограничивать скорость входящей полосы для разных компютеров, приложений.
Для исходящего можно, например, использовать HTB. А для входящего что?
На некоторых источниках упоминается об управлении окном tcp/ip, а как это можно делать не сказано.
»
- Для комментирования войдите или зарегистрируйтесь
Понятие "входящий" и
Понятие "входящий" и "исходящий" - относительные :) Т.е. - то, что для клиента является входящим траффиком, для сервера - исходящий, и соответственно, наоборот (на клиентском интерфейсе, естественно). iproute2 вполне подходит для решения задач как по приоритетам, так и по ограничению входящей/исходящей полос. Рассказывать подробно довольно долго, попробуйте сначала что-нибудь прочесть по данной теме.
Насчет "входящий-исходящий" - можно рассмотреть простейшую схему: допустим, есть сервер с двумя интерфейсами. Один интерфейс - клиентский, второй смотрит во внешнюю сеть. В этом случае входящий поток для клиента регулируется на клиентском интерфейсе, а исходящий - на внешнем. Ну, а дальше разберетесь.
Входящий от провайдера.
Меня интерисует входящий трафик от провайдера.
Метод - две сетевые карты - две исходящих очереди будет работать, по моему мнению, если роутер имее более трех сетевых с одинаковой пропускной способностью (частный случай), либо когда сумма нагрузок всех входящих... Не хочу заморачиватся..
Ясно лишь то, что если с одной стороны у вас (точнее у меня) ADSL с 2 Мб/с, а с другой Ethernet с 100 Мб/с, то на Ethernet карте никакой очереди не будет, она скорее останется у провайдера, а меня такой расклад не устраивает, т.к. я ее не могу использовать для приоритизации необходимых мне протоколов.
ну от правайдера к
ну от правайдера к абоненту.... тоесть входящая абонента?
от провайдера к моему
от провайдера к моему роутеру, а от него к моим пользователям.
вот в теме "Ограничение
вот в теме "Ограничение скорости для ip адреса" у меня указанно как я ограничиваю скорость к абоненту
указав внутренний интерфейс по анологии можно сделать для внешнего а соответственно от абонента
Главное приоритизация.
Мне нужно больше не ограничение, а сделать приоритетными одни протоколы над другими, иными словами мне нужно минимизировать задержку для группы протоколов (при этом чтобы оставшаяся часть полосы могла использоватся как угодно - хоть закачки, хоть почта), но при этом не потерять максимальную пропускную способность всего канала.
На счет ограничения
Ограничить скорость для меня не выход, т.к. в этом случае очередь пакетов образуется у провайдера, что неблагоприятно скажется на "пингах".
Вернее даже не так - у провайдера ее может и не будет, но от потерей пакетов, которые приходят сверх ограничителя скорости, я бы хотел бы отказатся, т.к. это уже просто перевод канала.
Опять не то, я хочу сказать что я не желаю терять полезную информацию, но при этом, если это поможет, я хочу контролировать исходящую служебную tcp/ip.
Альтернатива управлению окном.
Итак я ищу метод (точнее работающую реализацию метода) Управления окном TCP/IP. Но я подумал о другом методе, который можно будет реализовать рпи помощи iproute2.
Как работает tcp/ip: вкратце, упуская кучу нюансов - отсылает несколько пакетов, ждет подтвержидения о получении каждого, при получении подтверждения от первого отосланого отсылается следующий, и т.д. А если мне фильтровать исходящие (от роутера к хостам интернета) пакеты подтверждения, и ограничивать их частоту отправки для каждой сессии отдельно. Это, теоритичесски - я не очень хорошо знаю все нюансы tcp/ip, может работать так как мне нужно. Но тогда нужен демон который сможет эту информацию (статистику по сессиям - отправлено/получено байт) обрабатывать и реагировать на "прожорливые" сессии.
Если я где-то ошибаюсь, подправьте.
Если вы таки сможете изменить
1.Если вы таки сможете изменить окно - что это изменит с учетом того, что другие параметры соединения не меняются ?
если eсть канал в N мегабайт, то как вы окно не меняйте , эта величина не изменится.
Если стоит задача приоретизации некоего траффика ( как одного из аспектов инжиниринга траффика) , то не факт
что искомый траффик использует протокол TCP
Обычно приетиризируемый траффик, такой как VoIP, юзает как раз UDP/SIP.
2. Идея шейпинга входящего траффика в tcp есть большой развод - главная причина данного утверждения есть факт получения пакета на интерфейс :-D
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Приотизацию для не tcp/ip пока что не нужна.
Пока что я не использую VoIP и другие не TCP/IP протоколы.
Разве размер окна не влияет кол-во информации которую можно передать одним махом (и лишь потом ожидать подтверждения)?
В общем на даный момент есть только одно теоретичесски реализуемое, но для меня и моего провайдера абсолютно неприемливое - это установка на стороне провайдера роутера который и будет "шейпить" исходящий в мою сторону трафик :(.
Не совсем согласен. Напрямую TCP/IP не допускает этой функции, но все же есть дисциплина RED, которая в некоей степени этот механизм реализует, мне нужна подобная схема, но не настолько кардинальная, ибо терять половину полосы пропускания я не хочу.
И на счет вашего утверждения - с уже пришедшими пакетами - да согласен, уже ничего не сделаешь, но я хочу влиять на их отправку с удаленного хоста, согласно описанию протокола tcp/ip на некоторые не совсем благоприятные для него условия.
Пока что я не использую VoIP
UDP(VoIP) это протокол семейства IP, но да - это не TCP.
"передать одним махом" - да , влияет.
Если у вас ADSL, то 99,9% за то , что уменьшение окна приведет только к увеличению паразитного траффика (на величины долей %% из за возросшего служебного тарффика).
но никак значительно не снизит пропускную способность канала.
В принципе это и есть самый стандартный,теоретически и практически правильный способ
И всё таки , управление траффиком, имхо, не задача , а способ : Что вы хотите получить в результате ?
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Моя цель следующая.
Вернее лучше сначала описать что имею, а потом что хочу.
Итак - имею ADSL-роутер и 5 компьютеров (на три дома).
В одном из этих домов живет заядлый геймер (любитель on-line игр), я же любитель поставить что-то большое на загрузку.
Хочется ни с кем не ссорится и при этом чтобы все были довольны, то есть я хочу чтобы мои загрузки не мешали его играм, ну и еще некоторым протоколам которые я использую (pptp, rdp, ssh).
И все же на счет TCP/IP.
Я хочу уточнить один момент.
Давайте рассмотрим следующий пример:
[Host1] <-100Mb/s->[Router1]<-1Mb/s->[Router2]<-100Mb/s->[Host2]
Допустим у нас идет передача данных от Host1 к Host2, В момент старта соединения его скорость будет "плавно" увеличиватся до величины немного меньшей чем 1 Мб/с, а потом будет держатся на таком уровне до окончания соединения (при условии что передается что-то большое и нет потерь паветов в сетях). Теперь вопрос - как хосты узнают о слабом звене (сеть между Router1 и Router2)?
Ответом наверное будет - методом "тыка" - увеличиваем скорость пока не получаем либо потери либо большие задержки от удаленного хоста.
Вопрос №2 - так почему же нельзя создать подобные условия при помощи Traffic Control исскуственно, дабы убедить сам протокол что передача идет по медленному каналу?