LINUX.ORG.RU
ФорумAdmin

Шейпинг входящего трафика. Правда всё так плохо со скоростью??


0

1

http://computerlib.narod.ru/html/adslmanagement.htm 3.5.1. Почему сложно организовать ограничение скорости входящего трафика

Мы хотим ограничить скорость входящего трафика, чтобы избежать переполнения очереди у провайдера, который иногда буфферизирует до пяти секунд потока данных. Проблема заключается в том, что на данный момент существует единственный способ это сделать — терять заведомо корректные пакеты. А эти пакеты уже отняли часть полосы пропускания вашего ADSL модема и лишь для того, чтобы быть уничтожеными в надежде, что следующие пакеты будут прибывать с меньшей скоростью. Утерянные пакеты будут переданы повторно. что в конечном счете займет больше полосы пропускания. Когда мы ограничиваем трафик, мы ограничиваем количество пакетов в момент времени допускаемых в нашу сеть. Потому фактическая скорость входящего потока выше, из-за пакетов которые мы уничтожаем. В результате, нам будет необходимо ограничить нашу скорость входящего потока намного ниже, чем действительная скорость ADSL модема чтобы достичь малой задержки. На практике, мне пришлось ограничить мой 1.5Мбит/сек ADSL модем до 700Кбит/сек с тем, чтобы обеспечить приемлемую задержку при пяти одновременных закачках. Чем больше у вас TCP соединений, тем большая часть полосы пропускания будет теряться, и тем ниже вам придется ставить ограничение скорости.

Как же так? Всё реально так плохо? И вообще я что-то смотрю тема именно шейпинга входящего траффика как-то высосана из пальца. Это вообще эффективно хоть в каких-то реальных задачах? Или ограничение скорости обычным дроппером является самым правильным решением?


Ответ на: комментарий от ansky

Ну или перекидывать на ifb/imq(как и сделано в статье).
Разница то какая? Вопрос ведь про саму суть _шейпинга_ входящего траффика.

dx ()
Ответ на: комментарий от dx

шейпить входящий трафик ПО ОПРЕДЕЛЕНИЮ НЕЛЬЗЯ. Ведь он уже пришел. Поэтому шейпинга как такового нет, есть полисинг, то есть грубо говоря ты дропаешь уже пришедший трафик. Гораздо полезнее переформулировать задачу так, чтобы надо было шейпить исходящий трафик

Pinkbyte ★★★★★ ()

>на данный момент существует единственный способ это сделать — терять заведомо корректные пакеты

или шейпить на выходе к пользователю. Тогда на роутере будет создана очередь, которая разгрузит очередь на оборудовании провайдера

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

шейпить входящий трафик ПО ОПРЕДЕЛЕНИЮ НЕЛЬЗЯ. Ведь он уже пришел. Поэтому шейпинга как такового нет, есть полисинг, то есть грубо говоря ты дропаешь уже пришедший трафик.

Если рассмотреть случай транзитного роутера, то для него любой трафик -входящий на каком то интерфейсе. Однако успешно получается его шейпить. Хотя трафик этот уже пришел на роутер от клиента или апстрима. Шейпиг превратится в полисинг при перманентной перегрузке очереди.

ventilator ★★★ ()
Ответ на: комментарий от ventilator

>Если рассмотреть случай транзитного роутера, то для него любой трафик -входящий на каком то интерфейсе

я привык в этом случае рассматривать любой трафик как ИСХОДЯЩИЙ на каком-то интерфейсе :-)

Pinkbyte ★★★★★ ()

TCP это протокол с обратной связью поэтому с шейпингом проблем нет. Шейпь, всё будет хорошо.

true_admin ★★★★★ ()
Ответ на: комментарий от ventilator

>Шейпиг превратится в полисинг при перманентной перегрузке очереди.
так а вот в статье, чтобы перенести очередь от провайдера себе - пришлось из 1.5 мегабита до 700килобит скорость уменьшить. Меня это как-бэ пугает ))

dx ()

> Как же так? Всё реально так плохо?

Да. Если это udp, то есть, к примеру, торрент. Потому торрент - зло и я бы, с удовольствием, лично оторвал яйца автору протокола. И да, я против копирастов в принципе, но я готов их поддержать в борьбе против недософта ал-ля торрент.

AS ★★★★★ ()
Ответ на: комментарий от AS

Эээ ээ ээ! За что яйца то???
http://ru.wikipedia.org/wiki/%CE%9CTorrent#.C2.B5TP
μTP — переимплементация TCP на основе протокола UDP с измененным контролем за переполнением, который реагирует раньше, чем соответствующий алгоритм в TCP. Таким образом, при увеличении загрузки канала μTP первым замедляется и отдает канал другим приложениям. При использовании TCP канал распределялся равномерно по соединениям, а поскольку у P2P программ обычно на порядок больше соединений, чем у других, они просто забирали под себя весь канал, увеличивая пинг и делая работу других приложений медленной или вообще невозможной.

dx ()
Ответ на: комментарий от dx

>μTP

μTP — наколенная поделка, от которой провайдеры срут кирпичами, т.к. количество пакетов в секунду взлетает до небес и нагрузка на оборудование.

А для юзеuра получаются те же яйца, только в профиль. Либо ты дропаешь легальный трафик, чтобы сообщить стеку TCP, что у тебя затык, либо ты передаешь бльше служебной информации в заголовках... Чудес не бывает.

Чисто теоретически в TCP есть способ сообщить явно о возможном затыке, называется ECN. Но, поскольку в винде это не поддерживается... ну ты понял.

Про раздутые буфера даже термин выдумали — bufferbloat. Но хомячкам — пофиг. И провайдерам — пофиг. И вообще всем пофиг.

Macil ★★★★★ ()
Ответ на: комментарий от Pinkbyte

Только вот полисить в режиме HTB или CFQ трудновато...В том-то вся и соль чтобы ше просто дропать, а ещё и замедлять некторый вид трафика. а так как входящий трафан тоже делится на классы, то хочется полисить теми же методами что и шейпенье. но ведро так делать не позволяет, ЕМНИП.

на всякий случай, если кто не понял о чем речь

mmarkk ()
Ответ на: комментарий от mmarkk

>Ну нет. раздутые буфера - это совсем другое.

Как раз именно это. Почему-то производители сетевых железяк считают, что чем больше зафигачат буфера, тем будет лучше. На практике это приводит к негативным последствиям.

Macil ★★★★★ ()

хвала космическому макаронному монстру, что всё так плохо. Т.к. если бы дела обстояли лучше, то конечному пользователю было бы значительно хуже, ведь первыми подобной возможностью воспользовались бы провайдеры, жёстко наплевав на любые принципы аля «сетевой нейтралитет».

По сути - шейпи исходящий, полиси входящий, учи философию.

spunky ★★ ()
Ответ на: комментарий от Macil

я ни разу не претендую на специалиста по всем железкам, да и на знатока средней температуры по палате, но о каком буфере ты говоришь?

spunky ★★ ()
Ответ на: комментарий от spunky

>но о каком буфере ты говоришь

Я тоже не претендую на специалиста. Вот тут все подробно объяснено http://www.bufferbloat.net/

Краткое содержание: огромное количество данных по пути из точки A в точку B оседает в буферах промежуточных устройств. Из-за этого существующих TCP'шным механизмам противодействия затыкам, в особенности slow-start'у, напрочь сносит крышу.

Macil ★★★★★ ()
Ответ на: комментарий от Macil

1. Большие буфера вкупе с NAPI могут дать Ъ 1.4 мегапакета в секунду га гегобите. Ибо за одну транзакиыю едро может выгребать по много пакетов за раз. и при том без интераптов вообще.

2. А насчёт раздутых буферов - почему-то подумал про Семенович....

mmarkk ()
Ответ на: комментарий от Macil

Прочитай про TSO (TCP segment offloading) и зачем оно нужно. Так что буфферизация - это не так плохо для больших нагрузок.

mmarkk ()
Ответ на: комментарий от dx

> μTP — переимплементация TCP на основе протокола UDP с измененным контролем за переполнением, который

реагирует раньше, чем соответствующий алгоритм в TCP. Таким образом, при увеличении загрузки канала μTP
первым замедляется и отдает канал другим приложениям.

Оно работает только в том случае, если торрент-клиент с торрент-сервером это обрабатывают. Да и оператору от этого никакого прока практически. Как уже заметили. Только апгрейдить железки/каналы. А это - бабло. И ладно бы, если бы торрент-качальщики это бабло отбивали, но нет, им бы безлимит пошире и подешевле.

AS ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.