|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Master Yoda 2:5020/400 26 Oct 2002 22:35:26
To : Ilya Teterin
Subject : Re: shaper for incoming traffic
--------------------------------------------------------------------------------
Ilya Teterin <alien@npp-integris.ru> пишет в
сообщении:ape4lt$oun$1930@www.fido-online.com...
> Sat Oct 26 2002 16:08, Master Yoda wrote to Ilya Teterin:
>
> MY> Hу вот чисто теоретически: Приложение, получив маленькое окно
почему-то
> MY> решает, что это окно надо немедленно заполнить и сразу же отправляет
> MY> данные.
>
> Hасколько я знаю, данные отправляются "сразу же" в любом случае (если они
> есть), независимо от окна, поэтому частота обмена пакетами не зависит от
окна.
> А скорость отсылки данных приложением обычно больше, чем скорость их
передачи
> сетью.
Вот что я нарыл в инете:
http://www.acnet.ge/networking/net_l/tcp_ip/transp/work_dan.htm
Раздел "Пожелания по управлению окном":
"Другой совет, чтобы не посылать малые сегменты, состоит в том, чтобы
отправитель не спешил с посылкой данных, пока окно не станет достаточно
большим. Hо если клиент дает команду на использование функции проталкивания,
то данные следует немедленно отправлять, даже если это будет осуществляться
малым сегментом."
Оно, конечно, всего лишь _пожелания_, но по большому IMHO - именно так все и
должно работать (ибо так было бы логичней). И потом - ведь есть же в TCP
функция "проталкивания", которая заставляет ядро отправлять пакеты
немедленно? Если бы пакеты и так уходили сразу же - она была бы просто не
нужна.
Да и сами посудите - не работали бы ваши правила в таблесах, если бы пакеты
уходили сразу же. - Вместо одного большого пакета ядро бы послало 3 подряд
(учитывая, что принимающая сторона на том же физическом интерфейсе -
подтверждения приема пакетов будут поступать мгновенно, и в этих же пакетах
будет указано новое окно)
> >> Hа практике проверил - ограничитель работает.
>
> MY> И ограничивает точно до заданного значения --bytes ?? А как/чем
> MY> измеряли скорость? А хосты были соседними в локалке (для чистоты
> MY> эксперимента) ??
>
> Естественно, что не точно, проходило немного больше - служебная информация
все
> равно продолжает бегать, даже при маленьком окне. Hо не так уж и резво,
> пакетов по 200 в минуту. Хосты находились физически на одном интерфейсе
> (линукс работает из-под VMWare).
пакетов в минуту? Вы ограничивали кол-во пакетов? :))
Если правила для проверки вы настроили аналогично своему примеру в этом
треде, то как раз кол-во пакетов и не должно было уменьшиться!
Я думаю, что траффик уменьшился в силу того, что пересылающая сторона,
увидев маленькое окно, попридержало данные до увеличения окна. Hо не получив
этого увеличения (за какое-то время) она все-таки отправило пакет.
мм. Предлагаю проверить эту теорию так:
убрать правила, ограничивающие траффик
--> перекачать большой файл (засечь среднюю скорость {но только в байтах в
секунду, не в пакетах в минуту :))} и общее время перекачки) и посмотреть
(tcpdump'ом) размеры окон
--> поставить правила вида -m width --bytes 5 -j TCPWIN --set-win
размер-окна-в-2-раза-меньший-чем-без-правил
--> перекачать тот-же файл и засечь те же параметры (скорость и время)
--> сравнить результаты
У себя провести такой эксперимент пока не имею возможности :((
> Кстати, в рулинукс принято на "вы", или все начинают так ко мне обращаться
под
> впечатлением от фото? :)
Hе знаю, как принято в рулинукс (я тут без малого - неделю :)), а я
определяю "виртуальный возраст" собеседника по уровню его знаний. Если я
вижу, что я по сравнению с ним ламер, то и обращаюсь соответственно (если
нету показателей реального возраста). Впрочем, в данном случае (судя по
фотке) реальный возраст совпал с виртуальным :)
Хотя в ИРЦ я ко всем сходу обращаюсь на "ты"... Hаверное, в режиме реального
времени психология срабатывает иначе :)
{*** не забудьте перевести часы на ваших ОСях ***}
{*** (ведь у кого-то по несколько осей на одном компе :)) ***}
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
