форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Маршрутизаторы CISCO и др. оборудование. (Public)
Изначальное сообщение		[Проследить за развитием треда]

"не ново: traffic-shape"

Сообщение от Xela (ok) on 06-Фев-07, 11:51

И так, речь пойдет о traffic-shape. Появилась необходимость задавить некоторых особо любящих клубничку пользователей. Не так, что бы совсем задавить, но существенно зажать им канал. Так, что бы не больше положенного. Помятуя, что скорость TCP PUSH'ей не может превышать скорость TCP ACK'ов согласно RFC, для ограничения _входящиего_ на этих пользователей трафика, на _исходящем_ интерфейсе прописываю traffic-shape(имеено его, так как он работает с _исходящим_ трафиком) interface GigabitEthernet0/1 description Link to ISP traffic-shape group 199 8000 1000 1000 500 Extended 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  yes Traffic 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 никак не соотвествует действительности. Есть ли этому разумное объяснение?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Сообщения по теме

[Сортировка по времени, UBB]

1. "не ново: traffic-shape"

Сообщение от A Clockwork Orange on 06-Фев-07, 12:32

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "не ново: traffic-shape"
	Сообщение от Xela (ok) on 06-Фев-07, 12:40
	>а почему бы все же не шейпить на интерфейсе повернутом лицом к >пользователям? Потому что это не разгрузит канал ISP-Cisco. А именно этой ставится целью.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "не ново: traffic-shape"
	Сообщение от A Clockwork Orange on 06-Фев-07, 12:50
	мне показалось что цель! "Появилась необходимость задавить некоторых особо любящих клубничку пользователей" а с чего ты взял что не разгрузит?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "не ново: traffic-shape"
	Сообщение от Xela (ok) on 06-Фев-07, 13:06
	>мне показалось что цель! >"Появилась необходимость задавить некоторых особо любящих клубничку пользователей" Правильно, задавив любителей разгружу канал. >а с чего ты взял что не разгрузит? Еще раз: потому что согласно RFC скорость PUSH не может превышать скорость ACK. Соотвественно, ограничивая скорость _исходящего_ от пользователя трафика, я разгружаю _входящий_ на роутер канал, так как от целевого сервера поток будет идти согласовано потоку от пользователя. Просто тупо ограничивая поток в сторону _клиента_ я не ограничиваю поток на роутер. А просто, тупо отбрасываю пакеты сверх заданной скорости _на роутере_. То есть, уже после того, как на роутер этот поток вольется со всей доступной скоростью. И даже, скорее всего, еще больше таким образом увеличу нагрузку на канал ISP-Cisco из-за ретрансмиттов. Хоть и разгружу канал Ciso-Client. Но задача другая.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "не ново: traffic-shape"
	Сообщение от A Clockwork Orange on 06-Фев-07, 13:27
	ну прям все так и тупо. а как тебе то, что с замедлением скорости приема , уменьшается и скорость передачи? Пока источник не получит подтверждение о получении он не отправит следующую порцию?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "не ново: traffic-shape"
	Сообщение от Xela (ok) on 06-Фев-07, 13:46
	>ну прям все так и тупо. >а как тебе то, что с замедлением скорости приема , уменьшается и >скорость передачи? Пока источник не получит подтверждение о получении он не >отправит следующую порцию? Вот именно! Только разверните в другую сторону. Веб-сервер не получает подтверждения приема (ACK) и не посылает(PUSH) следущую порцию данных. Имено поэтому надо замедлять скорость оправки _исходящих_ ACK-ов, что бы получить замедление во _входящем_. Зажимать же _входящий_ трафик не имеет практического смысла. Это уже неоднократно обсуждалось на форумах ОпенНет-а со ссылками и на Стивенса и на RFC.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "не ново: traffic-shape"
	Сообщение от A Clockwork Orange on 07-Фев-07, 16:57
	а можно эти ссылки? на стивенса?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "не ново: traffic-shape"
	Сообщение от Антон (??) on 06-Фев-07, 13:34
	Скажу честно, RFC не читал :) Но, если бы он выполнялся так, как Вы его трактуете, то смысла в ассимметричных каналах типа ADSL не было бы никакого. То есть для ADSL типично ~5МБит/с к абоненту, ~500кБит/с от абонента. То есть абонент никогда бы не смог закачать что-нибудь по TCP со скоростью нисходящего канала 5МБит/с, поскольку восходящий - только 500кБит/с. Но Все качают :) Полагаю, что как-то не так трактуется RFC... Зажимая исходящий канал, по которому уходят TCP ACK-и, мы удерживаем эти ACK-и в очереди, не отправляя их, и, соответственно, задерживаются новые TCP пакеты с данными на web-сервере. Думаю, тут просто нужно экспериментально подобрать лимит для ACK-ов... Заранее прошу простить, если написал что-то не то :), тем более, не ознакомившись с RFC...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "не ново: traffic-shape"
	Сообщение от Xela (ok) on 06-Фев-07, 13:49
	>Скажу честно, RFC не читал :) >Но, если бы он выполнялся так, как Вы его трактуете, то смысла >в ассимметричных каналах типа ADSL не было бы никакого. То есть >для ADSL типично ~5МБит/с к абоненту, ~500кБит/с от абонента. То есть >абонент никогда бы не смог закачать что-нибудь по TCP со скоростью Да. По поводу ассиметричных каналов я и сам в растерянности. Поэтому комментировать не буду. Но то, что схема изложеная мной реально работала когда вместо Cisco стояла FreeBSD(где это все работало через ALTQ) --- факт. И я несколько удивлен, что это не работает на Cisco. То есть, оно конечно работает, замедление есть и это тоже факт. Но работает не так, как ожидалось.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "не ново: traffic-shape"
	Сообщение от A Clockwork Orange on 06-Фев-07, 13:52
	покажи правила которые бли на FreeBSD
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "не ново: traffic-shape"
	Сообщение от Xela (ok) on 06-Фев-07, 14:07
	>покажи правила которые бли на FreeBSD rl0 --- внутренний интерфейс. 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
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "не ново: traffic-shape"
	Сообщение от Evgeniy (??) on 06-Фев-07, 14:09
	>>Скажу честно, RFC не читал :) >>Но, если бы он выполнялся так, как Вы его трактуете, то смысла >>в ассимметричных каналах типа ADSL не было бы никакого. То есть >>для ADSL типично ~5МБит/с к абоненту, ~500кБит/с от абонента. То есть >>абонент никогда бы не смог закачать что-нибудь по TCP со скоростью > >Да. По поводу ассиметричных каналов я и сам в растерянности. Поэтому комментировать >не буду. > >Но то, что схема изложеная мной реально работала когда вместо Cisco стояла >FreeBSD(где это все работало через ALTQ) --- факт. И я несколько >удивлен, что это не работает на Cisco. То есть, оно конечно >работает, замедление есть и это тоже факт. Но работает не так, >как ожидалось. При ограничении трафика на интерфейсе повернутом к пользователю, пакеты первышающие лимит дропаются, изменяется размер тсп окна, пакеты приходят реже, и уменьшается поток данных от сервера. конечно все несколько сложнее, но суть та же
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "не ново: traffic-shape"
	Сообщение от fantom (??) on 06-Фев-07, 21:08
	Результаты Ваших замеров вполне нормальные!!!!! Зарезая скорость ASK-ов вы конечно режете скорость и обратную, косвенно... НО Размер пакета при закачке (идущего к клиенту) примерно 1500 байт, размер подтверждения - гораздо меньше, байт примерно 150, соответственно вы при закачке получаете 10 кратный  перекос, добавьте к этому размер окна, которое редко составляет 1 пакет, и получите что на 1 подтверждение отрпавляется 2 и более пакетов с данными, соответственно перекос увеличивается, исходя из ваших данных размер окна установился примерно на 2-4, вот и получили 30-ти кратную разницу скоростей. Именно поэтому и возможны асимметричные каналы :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "не ново: traffic-shape"
	Сообщение от A Clockwork Orange on 07-Фев-07, 09:18
	ну думаю что это есть объяснение возможности существования асимметричных каналов. интересно услышать академическое мнение.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "не ново: traffic-shape"
	Сообщение от Lacunacoil (ok) on 07-Фев-07, 13:41
	>ну думаю что это есть объяснение возможности существования асимметричных каналов. интересно услышать >академическое мнение. fantom написал вам абсолютно правильно, внимательно читайте как работает TCP. про трафик шейп добавлю он не дропает пакет при превышении лимита а ставит его в очередь(буферизирует) за счет чего размазывает нагрузку, а уже когда будет превышен размер всплеска(расширенного) тогда дропнет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "не ново: traffic-shape"
	Сообщение от A Clockwork Orange on 07-Фев-07, 14:23
	когда говорят об ассиметричности канала, говорят всего лишь о том что можно получать и передавать данные с разной скоростью. а не скоростях канала в обе стороны в рамках одного соединения.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "не ново: traffic-shape"
	Сообщение от Антон (??) on 07-Фев-07, 14:40
	>когда говорят об ассиметричности канала, говорят всего лишь о том что можно >получать и передавать данные с разной скоростью. а не скоростях канала >в обе стороны в рамках одного соединения. Правильно ли я Вас понял, что абсолютно невозможно на ассиметричном канале (напр., ADSL) установить одно TCP соединение, например, с FTP сервером, и в "один поток" получать с него данные со скоростью быстрее, чем обратный канал?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "не ново: traffic-shape"
	Сообщение от Lacunacoil (ok) on 07-Фев-07, 15:10
	>>когда говорят об ассиметричности канала, говорят всего лишь о том что можно >>получать и передавать данные с разной скоростью. а не скоростях канала >>в обе стороны в рамках одного соединения. > >Правильно ли я Вас понял, что абсолютно невозможно на ассиметричном канале (напр., >ADSL) установить одно TCP соединение, например, с FTP сервером, и в >"один поток" получать с него данные со скоростью быстрее, чем обратный >канал? асимметричный канал значит, что на канальном уровне у вас есть разные скорости приема/передачи, TCP в одну сессию даст вам использовать все его возможности при соответствующих условия, вам fantom все написал читайте внимательно и что непонятно спрашивайте или почитайте книгу.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "не ново: traffic-shape"
	Сообщение от Антон (??) on 07-Фев-07, 15:17
	>асимметричный канал значит, что на канальном уровне у вас есть разные скорости >приема/передачи, TCP в одну сессию даст вам использовать все его возможности >при соответствующих условия, вам fantom все написал читайте внимательно и что >непонятно спрашивайте или почитайте книгу. Большое спасибо за подробный ответ, теперь все абсолютно ясно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "не ново: traffic-shape"
	Сообщение от A Clockwork Orange on 07-Фев-07, 15:17
	нет, неправильно. создание асиммитричных каналов это не следствие свойств тсп соединений. в рамках одного соединения, когда клиент и сервер установили соединение. когда клиент получает данные, и когда клиент посылает подтверждение, скорости в обоих направлениях одинаковы, и при "идеальных" услових зависят о полосы пропускания канала. и если в downstream вы за одну минуту получите больше пакетов чем в upstream, это не значит что скорости были различны, а потому что в разных направлениях было послано разное количестов пакетов. не знаю удалось ли мне объяснить.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "не ново: traffic-shape"
	Сообщение от Lacunacoil (ok) on 07-Фев-07, 15:39
	>нет, неправильно. >создание асиммитричных каналов это не следствие свойств тсп соединений. >в рамках одного соединения, когда клиент и сервер установили соединение. >когда клиент получает данные, и когда клиент посылает подтверждение, скорости в обоих >направлениях одинаковы, и при "идеальных" услових зависят о полосы пропускания канала. неправильно, скорость потока будет разная. АСК несет только информацию о том что все пакеты в окне доставлены или нет. > >и если в downstream вы за одну минуту получите больше пакетов чем >в upstream, это не значит что скорости были различны, а потому >что в разных направлениях было послано разное количестов пакетов. >не знаю удалось ли мне объяснить. не только разное количество пакетов, но и их размер. Как следствие разная скорость потока в разных направлениях.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "не ново: traffic-shape"
	Сообщение от Lacunacoil (ok) on 07-Фев-07, 15:54
	>>нет, неправильно. >>создание асиммитричных каналов это не следствие свойств тсп соединений. >>в рамках одного соединения, когда клиент и сервер установили соединение. >>когда клиент получает данные, и когда клиент посылает подтверждение, скорости в обоих >>направлениях одинаковы, и при "идеальных" услових зависят о полосы пропускания канала. > >неправильно, скорость потока будет разная. АСК несет только информацию о том что >все пакеты в окне доставлены или нет. > >> >>и если в downstream вы за одну минуту получите больше пакетов чем >>в upstream, это не значит что скорости были различны, а потому >>что в разных направлениях было послано разное количестов пакетов. >>не знаю удалось ли мне объяснить. > > >не только разное количество пакетов, но и их размер. Как следствие разная >скорость потока в разных направлениях. выдержка из первой попавшейся статьи:      Протокол TCP требует, чтобы все отправленные данные  были  подтверж- дены  принявшей их стороной.  Он использует таймауты и повторные передачи для обеспечения надежной доставки.   Отправителю  разрешается  передавать некоторое  количество данных, недожидаясь подтверждения приема ранее отп- равленных данных.  Таким образом, между отправленными  и  подтвержденными данными существует окно уже отправленных, но еще неподтвержденных данных. Количество байт, которые можно передавать без  подтверждения,  называется размером окна.  Как правило, размер окна устанавливается в стартовых фай- лах сетевого программного обеспечения.  Так как TCP-канал  является  дуп- лексным,  то  подтверждения для данных, идущих в одном направлении, могут передаваться вместе с данными,  идущими  в  противоположном  направлении. Приемники  на  обеих  сторонах  виртуального  канала выполняют управление потоком передаваемых данных для того,  чтобы  не  допускать  переполнения буферов. вот ссалка на статью: http://pascal.sources.ru/docs/tcpbook.htm Можно найти более развернутое описание, но результат будет тот же. Читать книги это правильно. Чего Вам советую.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "не ново: traffic-shape"
	Сообщение от A Clockwork Orange on 07-Фев-07, 16:02
	никто не спорит что размеры данных и размер подтверждения разные. думаю мы путаем понятия, отправитель меняет размер окна и частоту отправки данных. но скорость прохождения очередной порции по каналу от этого не меняется.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "не ново: traffic-shape"
	Сообщение от Lacunacoil (ok) on 07-Фев-07, 16:31
	>никто не спорит что размеры данных и размер подтверждения разные. >думаю мы путаем понятия, отправитель меняет размер окна и частоту отправки данных. > >но скорость прохождения очередной порции по каналу от этого не меняется. Привожу пример: сервер подключен 100 мегабитным каналом в инет. клиент подключен 1 мегабитным каналом в инет. Клиент установил ТСП сесию с сервером и начал качать данные. Сервер отправил ему 10 пакетов по 1500 байт он это сделает на скорости 100 мегабит что приблизительно займет у него: 0,0012 секунды а вот принять его клиенту потребуется через этот канал: 0,12 секунды Соответственно через некоторое время выходная очередь на устройстве которое стоит у провайдера к клиенту переполнится и начнет дропать пакеты. И клиент в АСКе скажет серверу до меня дошло только 5 пакетов например. Сервер начнет менять окно в результате начнет варьироваться скорость. что не понятно ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "не ново: traffic-shape"
	Сообщение от A Clockwork Orange on 07-Фев-07, 16:44
	>>никто не спорит что размеры данных и размер подтверждения разные. >>думаю мы путаем понятия, отправитель меняет размер окна и частоту отправки данных. >> >>но скорость прохождения очередной порции по каналу от этого не меняется. > > >Привожу пример: > >сервер подключен 100 мегабитным каналом в инет. >клиент подключен 1 мегабитным каналом в инет. > > >Клиент установил ТСП сесию с сервером и начал качать данные. > >Сервер отправил ему 10 пакетов по 1500 байт он это сделает на >скорости 100 мегабит что приблизительно займет у него: >0,0012 секунды >а вот принять его клиенту потребуется через этот канал: >0,12 секунды >Соответственно через некоторое время выходная очередь на устройстве которое стоит у провайдера >к клиенту переполнится и начнет дропать пакеты. >И клиент в АСКе скажет серверу до меня дошло только 5 пакетов >например. Сервер начнет менять окно в результате начнет варьироваться скорость. >что не понятно ? именно так и будет. сервер будет отправлять меньше данных, или реже их отправлять, не пойму только что из этого следует.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "не ново: traffic-shape"
	Сообщение от Lacunacoil (ok) on 07-Фев-07, 17:32
	>>>никто не спорит что размеры данных и размер подтверждения разные. >>>думаю мы путаем понятия, отправитель меняет размер окна и частоту отправки данных. >>> >>>но скорость прохождения очередной порции по каналу от этого не меняется. >> >> >>Привожу пример: >> >>сервер подключен 100 мегабитным каналом в инет. >>клиент подключен 1 мегабитным каналом в инет. >> >> >>Клиент установил ТСП сесию с сервером и начал качать данные. >> >>Сервер отправил ему 10 пакетов по 1500 байт он это сделает на >>скорости 100 мегабит что приблизительно займет у него: >>0,0012 секунды >>а вот принять его клиенту потребуется через этот канал: >>0,12 секунды >>Соответственно через некоторое время выходная очередь на устройстве которое стоит у провайдера >>к клиенту переполнится и начнет дропать пакеты. >>И клиент в АСКе скажет серверу до меня дошло только 5 пакетов >>например. Сервер начнет менять окно в результате начнет варьироваться скорость. >>что не понятно ? > >именно так и будет. сервер будет отправлять меньше данных, или реже их >отправлять, не пойму только что из этого следует. то что в обратную сторону трафика идет в разы меньше так как данных, то там совсем  не много. ТСП адаптируется к каналам (на вход к запрашивающей стороне) и обратный трафик совсем не значительный только для подтверждения.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "не ново: traffic-shape"
	Сообщение от A Clockwork Orange on 07-Фев-07, 17:38
	да, именно так.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "не ново: traffic-shape"
	Сообщение от Антон (??) on 07-Фев-07, 15:45
	>нет, неправильно. >создание асиммитричных каналов это не следствие свойств тсп соединений. >в рамках одного соединения, когда клиент и сервер установили соединение. >когда клиент получает данные, и когда клиент посылает подтверждение, скорости в обоих >направлениях одинаковы, и при "идеальных" услових зависят о полосы пропускания канала. > >и если в downstream вы за одну минуту получите больше пакетов чем >в upstream, это не значит что скорости были различны, а потому >что в разных направлениях было послано разное количестов пакетов. >не знаю удалось ли мне объяснить. Создание ассимметричных каналов, конечно, не является следствием свойств TCP соединений. Ассимметричные каналы создаются независимо от TCP, IP или любых других протоколов верхнего уровня. Просто канальные скорости различаются в нисходящем и в восходящем направлениях - вот и канал и получается ассимметричным, ему, в принципе, все равно, что там на вышестоящих уровнях передается и принимается. Далее, речь идет, насколько я понимаю, о трактовке RFC, описывающего механизмы TCP соединений. И автор топика приводит такую трактовку RFC: "Помятуя, что скорость TCP PUSH'ей не может превышать скорость TCP ACK'ов согласно RFC..." Так вот какая скорость имеется в виду? Байт в секунду? Пакетов в секунду? Еще раз заранее прошу меня извинить, поскольку вышеупомянутого RFC я не читал, и высказываю сейчас исключительно собственные предположения. Исходя из собственной практики, могу предположить, что в RFC имеется в виду (и, следовательно, именно это и реализовано в стеках TCP/IP разных производителей) скорость в пакетах в секунду. Иначе на любом ассимметричном канале не было бы возможности, например, загружать "в один поток" с FTP сервера файлы с полной скоростью нисходящего канала, которая, как правило, выше, чем скорость восходящего канала. То есть скорости в байтах/с в разных направлениях - разные из-за разных размеров пакетов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "не ново: traffic-shape"
	Сообщение от A Clockwork Orange on 07-Фев-07, 15:56
	>>нет, неправильно. >>создание асиммитричных каналов это не следствие свойств тсп соединений. >>в рамках одного соединения, когда клиент и сервер установили соединение. >>когда клиент получает данные, и когда клиент посылает подтверждение, скорости в обоих >>направлениях одинаковы, и при "идеальных" услових зависят о полосы пропускания канала. >> >>и если в downstream вы за одну минуту получите больше пакетов чем >>в upstream, это не значит что скорости были различны, а потому >>что в разных направлениях было послано разное количестов пакетов. >>не знаю удалось ли мне объяснить. > >Создание ассимметричных каналов, конечно, не является следствием свойств TCP соединений. Ассимметричные каналы >создаются независимо от TCP, IP или любых других протоколов верхнего уровня. >Просто канальные скорости различаются в нисходящем и в восходящем направлениях - >вот и канал и получается ассимметричным, ему, в принципе, все равно, >что там на вышестоящих уровнях передается и принимается. именно так > >Далее, речь идет, насколько я понимаю, о трактовке RFC, описывающего механизмы TCP >соединений. И автор топика приводит такую трактовку RFC: "Помятуя, что скорость >TCP PUSH'ей не может превышать скорость TCP ACK'ов согласно RFC..." в RFC ничего не говорится о скорости, автор провел логическую нить, и он по сути прав. > >Так вот какая скорость имеется в виду? Байт в секунду? Пакетов в >секунду? > >Еще раз заранее прошу меня извинить, поскольку вышеупомянутого RFC я не читал, >и высказываю сейчас исключительно собственные предположения. Исходя из собственной практики, могу >предположить, что в RFC имеется в виду (и, следовательно, именно это >и реализовано в стеках TCP/IP разных производителей) скорость в пакетах в >секунду. Иначе на любом ассимметричном канале не было бы возможности, например, >загружать "в один поток" с FTP сервера файлы с полной скоростью >нисходящего канала, которая, как правило, выше, чем скорость восходящего канала. То >есть скорости в байтах/с в разных направлениях - разные из-за разных >размеров пакетов. иначе бы ничто не мешало исходящей скорости быть такой же большой как и нисходящей, когда бы сервер стоял со стороны ADSL модема а клиент со стороны DSLAM
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "не ново: traffic-shape"
	Сообщение от mig (??) on 07-Фев-07, 19:16
	рассуждать об разгрузке канала, обговаривая только особенности работы протокола TCP, забывая что существует огромное количество протоколов, в том числе механизмы и протоколы организации L3 VPN( тогда ваши старания танцев с бубном вокруг TCP пойдут прахом) - в корне неверно. Тем более говорить об организации ассиметричных каналов в DSL. Для данных задач существует резервирование + приоритезация траффика.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]