И так, речь пойдет о traffic-shape.Появилась необходимость задавить некоторых особо любящих клубничку пользователей. Не так, что бы совсем задавить, но существенно зажать им канал. Так, что бы не больше положенного.
Помятуя, что скорость TCP PUSH'ей не может превышать скорость TCP ACK'ов согласно RFC, для ограничения _входящиего_ на этих пользователей трафика, на _исходящем_ интерфейсе прописываю traffic-shape(имеено его, так как он работает с _исходящим_ трафиком)
interface GigabitEthernet0/1
description Link to ISP
traffic-shape group 199 8000 1000 1000 500Extended IP access list 199
10 permit tcp host x.x.x.147 any eq www (75391 matches)
20 permit tcp host x.x.x.147 any eq 443 (254 matches)sparta#sh traffic-shape st
Acc. Queue Packets Bytes Packets Bytes Shaping
I/F List Depth Delayed Delayed Active
Gi0/1 199 9 75926 13581663 72436 13291253 yesTraffic queued in shaping queue on GigabitEthernet0/1
Traffic shape group: 199
Queueing strategy: weighted fair
Queueing Stats: 35/500/64/2 (size/max total/threshold/drops)
Conversations 7/13/16 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 8 kilobits/sec
Как видно --- вроде бы все работает: доступная полоса 8кбс. Делаем контрольный замер с машины x.x.x.147 путем закачивания файла по HTTP:С выключеным traffic-shape ~100КБ/с.
С включеным ~30КБ/сКак видим заявленая Available Bandwidth 8 kilobits/sec никак не соотвествует действительности.
Есть ли этому разумное объяснение?
а почему бы все же не шейпить на интерфейсе повернутом лицом к пользователям?
>а почему бы все же не шейпить на интерфейсе повернутом лицом к
>пользователям?
Потому что это не разгрузит канал ISP-Cisco. А именно этой ставится целью.
мне показалось что цель!
"Появилась необходимость задавить некоторых особо любящих клубничку пользователей"
а с чего ты взял что не разгрузит?
>мне показалось что цель!
>"Появилась необходимость задавить некоторых особо любящих клубничку пользователей"Правильно, задавив любителей разгружу канал.
>а с чего ты взял что не разгрузит?
Еще раз: потому что согласно RFC скорость PUSH не может превышать скорость ACK. Соотвественно, ограничивая скорость _исходящего_ от пользователя трафика, я разгружаю _входящий_ на роутер канал, так как от целевого сервера поток будет идти согласовано потоку от пользователя.
Просто тупо ограничивая поток в сторону _клиента_ я не ограничиваю поток на роутер. А просто, тупо отбрасываю пакеты сверх заданной скорости _на роутере_. То есть, уже после того, как на роутер этот поток вольется со всей доступной скоростью. И даже, скорее всего, еще больше таким образом увеличу нагрузку на канал ISP-Cisco из-за ретрансмиттов. Хоть и разгружу канал Ciso-Client. Но задача другая.
ну прям все так и тупо.
а как тебе то, что с замедлением скорости приема , уменьшается и скорость передачи? Пока источник не получит подтверждение о получении он не отправит следующую порцию?
>ну прям все так и тупо.
>а как тебе то, что с замедлением скорости приема , уменьшается и
>скорость передачи? Пока источник не получит подтверждение о получении он не
>отправит следующую порцию?Вот именно! Только разверните в другую сторону. Веб-сервер не получает подтверждения приема
(ACK) и не посылает(PUSH) следущую порцию данных. Имено поэтому надо замедлять скорость оправки _исходящих_ ACK-ов, что бы получить замедление во _входящем_.Зажимать же _входящий_ трафик не имеет практического смысла. Это уже неоднократно обсуждалось на форумах ОпенНет-а со ссылками и на Стивенса и на RFC.
а можно эти ссылки? на стивенса?
Скажу честно, RFC не читал :)Но, если бы он выполнялся так, как Вы его трактуете, то смысла в ассимметричных каналах типа ADSL не было бы никакого. То есть для ADSL типично ~5МБит/с к абоненту, ~500кБит/с от абонента. То есть абонент никогда бы не смог закачать что-нибудь по TCP со скоростью нисходящего канала 5МБит/с, поскольку восходящий - только 500кБит/с. Но Все качают :)
Полагаю, что как-то не так трактуется RFC...
Зажимая исходящий канал, по которому уходят TCP ACK-и, мы удерживаем эти ACK-и в очереди, не отправляя их, и, соответственно, задерживаются новые TCP пакеты с данными на web-сервере. Думаю, тут просто нужно экспериментально подобрать лимит для ACK-ов...
Заранее прошу простить, если написал что-то не то :), тем более, не ознакомившись с RFC...
>Скажу честно, RFC не читал :)
>Но, если бы он выполнялся так, как Вы его трактуете, то смысла
>в ассимметричных каналах типа ADSL не было бы никакого. То есть
>для ADSL типично ~5МБит/с к абоненту, ~500кБит/с от абонента. То есть
>абонент никогда бы не смог закачать что-нибудь по TCP со скоростьюДа. По поводу ассиметричных каналов я и сам в растерянности. Поэтому комментировать не буду.
Но то, что схема изложеная мной реально работала когда вместо Cisco стояла FreeBSD(где это все работало через ALTQ) --- факт. И я несколько удивлен, что это не работает на Cisco. То есть, оно конечно работает, замедление есть и это тоже факт. Но работает не так, как ожидалось.
покажи правила которые бли на FreeBSD
>покажи правила которые бли на FreeBSDrl0 --- внутренний интерфейс.
altq on rl0 cbq bandwidth 100Mb queue { q_def,std_in }
queue std_in bandwidth 1Mb { www_in, other}
queue www_in bandwidth 500Kb cbq(borrow red)
queue other bandwidth 500Kb cbq(red)
queue q_def bandwidth 99Mb cbq(default)pass in quick on $int_ifs proto tcp from <netall> to any port { www,ftp-data,7999 >< 9000 } queue www_in keep state
>>Скажу честно, RFC не читал :)
>>Но, если бы он выполнялся так, как Вы его трактуете, то смысла
>>в ассимметричных каналах типа ADSL не было бы никакого. То есть
>>для ADSL типично ~5МБит/с к абоненту, ~500кБит/с от абонента. То есть
>>абонент никогда бы не смог закачать что-нибудь по TCP со скоростью
>
>Да. По поводу ассиметричных каналов я и сам в растерянности. Поэтому комментировать
>не буду.
>
>Но то, что схема изложеная мной реально работала когда вместо Cisco стояла
>FreeBSD(где это все работало через ALTQ) --- факт. И я несколько
>удивлен, что это не работает на Cisco. То есть, оно конечно
>работает, замедление есть и это тоже факт. Но работает не так,
>как ожидалось.При ограничении трафика на интерфейсе повернутом к пользователю, пакеты первышающие лимит дропаются, изменяется размер тсп окна, пакеты приходят реже, и уменьшается поток данных от сервера.
конечно все несколько сложнее, но суть та же
Результаты Ваших замеров вполне нормальные!!!!!
Зарезая скорость ASK-ов вы конечно режете скорость и обратную, косвенно...
НО
Размер пакета при закачке (идущего к клиенту) примерно 1500 байт, размер подтверждения - гораздо меньше, байт примерно 150, соответственно вы при закачке получаете 10 кратный перекос, добавьте к этому размер окна, которое редко составляет 1 пакет, и получите что на 1 подтверждение отрпавляется 2 и более пакетов с данными, соответственно перекос увеличивается, исходя из ваших данных размер окна установился примерно на 2-4, вот и получили 30-ти кратную разницу скоростей.
Именно поэтому и возможны асимметричные каналы :)
ну думаю что это есть объяснение возможности существования асимметричных каналов. интересно услышать академическое мнение.
>ну думаю что это есть объяснение возможности существования асимметричных каналов. интересно услышать
>академическое мнение.
fantom написал вам абсолютно правильно, внимательно читайте как работает TCP.
про трафик шейп добавлю он не дропает пакет при превышении лимита а ставит его в очередь(буферизирует) за счет чего размазывает нагрузку, а уже когда будет превышен размер всплеска(расширенного) тогда дропнет.
когда говорят об ассиметричности канала, говорят всего лишь о том что можно получать и передавать данные с разной скоростью. а не скоростях канала в обе стороны в рамках одного соединения.
>когда говорят об ассиметричности канала, говорят всего лишь о том что можно
>получать и передавать данные с разной скоростью. а не скоростях канала
>в обе стороны в рамках одного соединения.Правильно ли я Вас понял, что абсолютно невозможно на ассиметричном канале (напр., ADSL) установить одно TCP соединение, например, с FTP сервером, и в "один поток" получать с него данные со скоростью быстрее, чем обратный канал?
>>когда говорят об ассиметричности канала, говорят всего лишь о том что можно
>>получать и передавать данные с разной скоростью. а не скоростях канала
>>в обе стороны в рамках одного соединения.
>
>Правильно ли я Вас понял, что абсолютно невозможно на ассиметричном канале (напр.,
>ADSL) установить одно TCP соединение, например, с FTP сервером, и в
>"один поток" получать с него данные со скоростью быстрее, чем обратный
>канал?
асимметричный канал значит, что на канальном уровне у вас есть разные скорости приема/передачи, TCP в одну сессию даст вам использовать все его возможности при соответствующих условия, вам fantom все написал читайте внимательно и что непонятно спрашивайте или почитайте книгу.
>асимметричный канал значит, что на канальном уровне у вас есть разные скорости
>приема/передачи, TCP в одну сессию даст вам использовать все его возможности
>при соответствующих условия, вам fantom все написал читайте внимательно и что
>непонятно спрашивайте или почитайте книгу.
Большое спасибо за подробный ответ, теперь все абсолютно ясно.
нет, неправильно.
создание асиммитричных каналов это не следствие свойств тсп соединений.
в рамках одного соединения, когда клиент и сервер установили соединение.
когда клиент получает данные, и когда клиент посылает подтверждение, скорости в обоих направлениях одинаковы, и при "идеальных" услових зависят о полосы пропускания канала.
и если в downstream вы за одну минуту получите больше пакетов чем в upstream, это не значит что скорости были различны, а потому что в разных направлениях было послано разное количестов пакетов.
не знаю удалось ли мне объяснить.
>нет, неправильно.
>создание асиммитричных каналов это не следствие свойств тсп соединений.
>в рамках одного соединения, когда клиент и сервер установили соединение.
>когда клиент получает данные, и когда клиент посылает подтверждение, скорости в обоих
>направлениях одинаковы, и при "идеальных" услових зависят о полосы пропускания канала.неправильно, скорость потока будет разная. АСК несет только информацию о том что все пакеты в окне доставлены или нет.
>
>и если в downstream вы за одну минуту получите больше пакетов чем
>в upstream, это не значит что скорости были различны, а потому
>что в разных направлениях было послано разное количестов пакетов.
>не знаю удалось ли мне объяснить.
не только разное количество пакетов, но и их размер. Как следствие разная скорость потока в разных направлениях.
>>нет, неправильно.
>>создание асиммитричных каналов это не следствие свойств тсп соединений.
>>в рамках одного соединения, когда клиент и сервер установили соединение.
>>когда клиент получает данные, и когда клиент посылает подтверждение, скорости в обоих
>>направлениях одинаковы, и при "идеальных" услових зависят о полосы пропускания канала.
>
>неправильно, скорость потока будет разная. АСК несет только информацию о том что
>все пакеты в окне доставлены или нет.
>
>>
>>и если в downstream вы за одну минуту получите больше пакетов чем
>>в upstream, это не значит что скорости были различны, а потому
>>что в разных направлениях было послано разное количестов пакетов.
>>не знаю удалось ли мне объяснить.
>
>
>не только разное количество пакетов, но и их размер. Как следствие разная
>скорость потока в разных направлениях.выдержка из первой попавшейся статьи:
Протокол TCP требует, чтобы все отправленные данные были подтверж-
дены принявшей их стороной. Он использует таймауты и повторные передачи
для обеспечения надежной доставки. Отправителю разрешается передавать
некоторое количество данных, недожидаясь подтверждения приема ранее отп-
равленных данных. Таким образом, между отправленными и подтвержденными
данными существует окно уже отправленных, но еще неподтвержденных данных.
Количество байт, которые можно передавать без подтверждения, называется
размером окна. Как правило, размер окна устанавливается в стартовых фай-
лах сетевого программного обеспечения. Так как TCP-канал является дуп-
лексным, то подтверждения для данных, идущих в одном направлении, могут
передаваться вместе с данными, идущими в противоположном направлении.
Приемники на обеих сторонах виртуального канала выполняют управление
потоком передаваемых данных для того, чтобы не допускать переполнения
буферов.
вот ссалка на статью:
http://pascal.sources.ru/docs/tcpbook.htm
Можно найти более развернутое описание, но результат будет тот же.
Читать книги это правильно. Чего Вам советую.
никто не спорит что размеры данных и размер подтверждения разные.
думаю мы путаем понятия, отправитель меняет размер окна и частоту отправки данных.
но скорость прохождения очередной порции по каналу от этого не меняется.
>никто не спорит что размеры данных и размер подтверждения разные.
>думаю мы путаем понятия, отправитель меняет размер окна и частоту отправки данных.
>
>но скорость прохождения очередной порции по каналу от этого не меняется.
Привожу пример:сервер подключен 100 мегабитным каналом в инет.
клиент подключен 1 мегабитным каналом в инет.
Клиент установил ТСП сесию с сервером и начал качать данные.Сервер отправил ему 10 пакетов по 1500 байт он это сделает на скорости 100 мегабит что приблизительно займет у него:
0,0012 секунды
а вот принять его клиенту потребуется через этот канал:
0,12 секунды
Соответственно через некоторое время выходная очередь на устройстве которое стоит у провайдера к клиенту переполнится и начнет дропать пакеты.
И клиент в АСКе скажет серверу до меня дошло только 5 пакетов например. Сервер начнет менять окно в результате начнет варьироваться скорость.
что не понятно ?
>>никто не спорит что размеры данных и размер подтверждения разные.
>>думаю мы путаем понятия, отправитель меняет размер окна и частоту отправки данных.
>>
>>но скорость прохождения очередной порции по каналу от этого не меняется.
>
>
>Привожу пример:
>
>сервер подключен 100 мегабитным каналом в инет.
>клиент подключен 1 мегабитным каналом в инет.
>
>
>Клиент установил ТСП сесию с сервером и начал качать данные.
>
>Сервер отправил ему 10 пакетов по 1500 байт он это сделает на
>скорости 100 мегабит что приблизительно займет у него:
>0,0012 секунды
>а вот принять его клиенту потребуется через этот канал:
>0,12 секунды
>Соответственно через некоторое время выходная очередь на устройстве которое стоит у провайдера
>к клиенту переполнится и начнет дропать пакеты.
>И клиент в АСКе скажет серверу до меня дошло только 5 пакетов
>например. Сервер начнет менять окно в результате начнет варьироваться скорость.
>что не понятно ?именно так и будет. сервер будет отправлять меньше данных, или реже их отправлять, не пойму только что из этого следует.
>>>никто не спорит что размеры данных и размер подтверждения разные.
>>>думаю мы путаем понятия, отправитель меняет размер окна и частоту отправки данных.
>>>
>>>но скорость прохождения очередной порции по каналу от этого не меняется.
>>
>>
>>Привожу пример:
>>
>>сервер подключен 100 мегабитным каналом в инет.
>>клиент подключен 1 мегабитным каналом в инет.
>>
>>
>>Клиент установил ТСП сесию с сервером и начал качать данные.
>>
>>Сервер отправил ему 10 пакетов по 1500 байт он это сделает на
>>скорости 100 мегабит что приблизительно займет у него:
>>0,0012 секунды
>>а вот принять его клиенту потребуется через этот канал:
>>0,12 секунды
>>Соответственно через некоторое время выходная очередь на устройстве которое стоит у провайдера
>>к клиенту переполнится и начнет дропать пакеты.
>>И клиент в АСКе скажет серверу до меня дошло только 5 пакетов
>>например. Сервер начнет менять окно в результате начнет варьироваться скорость.
>>что не понятно ?
>
>именно так и будет. сервер будет отправлять меньше данных, или реже их
>отправлять, не пойму только что из этого следует.
то что в обратную сторону трафика идет в разы меньше так как данных, то там совсем не много. ТСП адаптируется к каналам (на вход к запрашивающей стороне) и обратный трафик совсем не значительный только для подтверждения.
да, именно так.
>нет, неправильно.
>создание асиммитричных каналов это не следствие свойств тсп соединений.
>в рамках одного соединения, когда клиент и сервер установили соединение.
>когда клиент получает данные, и когда клиент посылает подтверждение, скорости в обоих
>направлениях одинаковы, и при "идеальных" услових зависят о полосы пропускания канала.
>
>и если в downstream вы за одну минуту получите больше пакетов чем
>в upstream, это не значит что скорости были различны, а потому
>что в разных направлениях было послано разное количестов пакетов.
>не знаю удалось ли мне объяснить.Создание ассимметричных каналов, конечно, не является следствием свойств TCP соединений. Ассимметричные каналы создаются независимо от TCP, IP или любых других протоколов верхнего уровня. Просто канальные скорости различаются в нисходящем и в восходящем направлениях - вот и канал и получается ассимметричным, ему, в принципе, все равно, что там на вышестоящих уровнях передается и принимается.
Далее, речь идет, насколько я понимаю, о трактовке RFC, описывающего механизмы TCP соединений. И автор топика приводит такую трактовку RFC: "Помятуя, что скорость TCP PUSH'ей не может превышать скорость TCP ACK'ов согласно RFC..."
Так вот какая скорость имеется в виду? Байт в секунду? Пакетов в секунду?
Еще раз заранее прошу меня извинить, поскольку вышеупомянутого RFC я не читал, и высказываю сейчас исключительно собственные предположения. Исходя из собственной практики, могу предположить, что в RFC имеется в виду (и, следовательно, именно это и реализовано в стеках TCP/IP разных производителей) скорость в пакетах в секунду. Иначе на любом ассимметричном канале не было бы возможности, например, загружать "в один поток" с FTP сервера файлы с полной скоростью нисходящего канала, которая, как правило, выше, чем скорость восходящего канала. То есть скорости в байтах/с в разных направлениях - разные из-за разных размеров пакетов.
>>нет, неправильно.
>>создание асиммитричных каналов это не следствие свойств тсп соединений.
>>в рамках одного соединения, когда клиент и сервер установили соединение.
>>когда клиент получает данные, и когда клиент посылает подтверждение, скорости в обоих
>>направлениях одинаковы, и при "идеальных" услових зависят о полосы пропускания канала.
>>
>>и если в downstream вы за одну минуту получите больше пакетов чем
>>в upstream, это не значит что скорости были различны, а потому
>>что в разных направлениях было послано разное количестов пакетов.
>>не знаю удалось ли мне объяснить.
>
>Создание ассимметричных каналов, конечно, не является следствием свойств TCP соединений. Ассимметричные каналы
>создаются независимо от TCP, IP или любых других протоколов верхнего уровня.
>Просто канальные скорости различаются в нисходящем и в восходящем направлениях -
>вот и канал и получается ассимметричным, ему, в принципе, все равно,
>что там на вышестоящих уровнях передается и принимается.именно так
>
>Далее, речь идет, насколько я понимаю, о трактовке RFC, описывающего механизмы TCP
>соединений. И автор топика приводит такую трактовку RFC: "Помятуя, что скорость
>TCP PUSH'ей не может превышать скорость TCP ACK'ов согласно RFC..."в RFC ничего не говорится о скорости, автор провел логическую нить, и он по сути прав.
>
>Так вот какая скорость имеется в виду? Байт в секунду? Пакетов в
>секунду?
>
>Еще раз заранее прошу меня извинить, поскольку вышеупомянутого RFC я не читал,
>и высказываю сейчас исключительно собственные предположения. Исходя из собственной практики, могу
>предположить, что в RFC имеется в виду (и, следовательно, именно это
>и реализовано в стеках TCP/IP разных производителей) скорость в пакетах в
>секунду. Иначе на любом ассимметричном канале не было бы возможности, например,
>загружать "в один поток" с FTP сервера файлы с полной скоростью
>нисходящего канала, которая, как правило, выше, чем скорость восходящего канала. То
>есть скорости в байтах/с в разных направлениях - разные из-за разных
>размеров пакетов.иначе бы ничто не мешало исходящей скорости быть такой же большой как и нисходящей, когда бы сервер стоял со стороны ADSL модема а клиент со стороны DSLAM
рассуждать об разгрузке канала, обговаривая только особенности работы протокола TCP, забывая что существует огромное количество протоколов, в том числе механизмы и протоколы организации L3 VPN( тогда ваши старания танцев с бубном вокруг TCP пойдут прахом) - в корне неверно. Тем более говорить об организации ассиметричных каналов в DSL. Для данных задач существует резервирование + приоритезация траффика.