Задача вобщем такая.
Есть локальная сеть порядка 500 IP. Необходимо ограничить потолок полосы
на вход/выход для всех IP, кроме привилегированных. А то канал отдельные
несознательные личности забивают.
Железо: C-5505+ATM+RSFC.
Я вижу возможности в Шейпинге и Рэйт-лимит, но не могу врубиться, что лучше - недавно я с Цисками работать начал.
Помогите советом плиззз.
>Задача вобщем такая.
>Есть локальная сеть порядка 500 IP. Необходимо ограничить потолок полосы
>на вход/выход для всех IP, кроме привилегированных. А то канал отдельные
>несознательные личности забивают.
>Железо: C-5505+ATM+RSFC.
>Я вижу возможности в Шейпинге и Рэйт-лимит, но не могу врубиться, что
>лучше - недавно я с Цисками работать начал.
>Помогите советом плиззз.входящий траффик (если он из и-нета) ограничивать особого смысла нет
а исходящий...я думаю traffic-shaping вам как раз
или CBWFQ
>
>входящий траффик (если он из и-нета) ограничивать особого смысла нет
>а исходящий...я думаю traffic-shaping вам как раз
>или CBWFQА почему нет смысла ограничивать входящий - может, люди сидят, фильмы переписывают? Пусть переписывают, но медленно...
Ведь деньги-то как раз за входящий и платятся.
>
>>
>>входящий траффик (если он из и-нета) ограничивать особого смысла нет
>>а исходящий...я думаю traffic-shaping вам как раз
>>или CBWFQ
>
>А почему нет смысла ограничивать входящий - может, люди сидят, фильмы переписывают?
>Пусть переписывают, но медленно...
>Ведь деньги-то как раз за входящий и платятся.правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу пропускания, провайдер его УЖЕ ПОСЧИТАЛ
так есть-ли особый смысл?
>>А почему нет смысла ограничивать входящий - может, люди сидят, фильмы переписывают?
>>Пусть переписывают, но медленно...
>>Ведь деньги-то как раз за входящий и платятся.
>
>правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу
>пропускания, провайдер его УЖЕ ПОСЧИТАЛ
>так есть-ли особый смысл?
Смысл есть. Он состоит в том, что бы в дальнейшем такого не было.
А то провайдер вопить начинает: что делаете гады! Мы вас наголо подстригем !!
Кроме того, есть приоритетные адреса (сервера), доступ к которым должен быть гарантирован..
Я не против фильмов, но если фильм скачивается за полчаса, то остальные в это время отдыхают - фильмокачатель занял практически всю полосу. а если их 10 - то вообще дело труба.. То же самое и с исходящим трафиком, ибо фильмы туда-сюда летают..
Вобщем необходимы симметричные ограничения и уравнивание юзеров по занимаемой полосе.
>Я не против фильмов, но если фильм скачивается за полчаса, то остальные
>в это время отдыхают - фильмокачатель занял практически всю полосу. а
>если их 10 - то вообще дело труба.. То же самое
>и с исходящим трафиком, ибо фильмы туда-сюда летают..
>Вобщем необходимы симметричные ограничения и уравнивание юзеров по занимаемой полосе.все-таки судя по всему вы не поняли....
то что дошло до вашего рутера уже заняло канал, и от того что вы дропнете эти пакеты, канала больше не будеткакой смысл дропать пакеты, которые уже дошли до вас, за которые вы фактически заплатили?
>какой смысл дропать пакеты, которые уже дошли до вас, за которые вы
>фактически заплатили?Traffic-shape не дропает пакеты, а делеит их. Достаточно посмотреть статитсику sho traffic-shape statistic.
Задержка пакетов как раз и означает что уменьшается входной поток, т.к. клиентский комп увеличивает свои TCP таймауты и освобождает канал.
>правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу
>пропускания, провайдер его УЖЕ ПОСЧИТАЛ
>так есть-ли особый смысл?Входящие пакеты тоже не бесконечным потоком льются, если задержать отправку пакетов с подтверждением доставки или начать дропать пакеты, никуда входящий трафик не дойдет, а будет шейпится не хуже исходящего (точнее дойдет тельно первая партия пакетов, остальные будут жать в очереди на отправляющей пакеты машине).
>>правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу
>>пропускания, провайдер его УЖЕ ПОСЧИТАЛ
>>так есть-ли особый смысл?
>
>Входящие пакеты тоже не бесконечным потоком льются, если задержать отправку пакетов с
>подтверждением доставки или начать дропать пакеты, никуда входящий трафик
да? а вы можете именно их задержать? :) или сможете именно их дропать?>не дойдет,
>а будет шейпится не хуже исходящего (точнее дойдет тельно первая партия
>пакетов, остальные будут жать в очереди на отправляющей пакеты машине).да? а когда выйдет таймаут tcp-сессия прервется и все пойдет заново?
а если udp-поток?
>>>правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу
>>>пропускания, провайдер его УЖЕ ПОСЧИТАЛ
>>>так есть-ли особый смысл?
>>
>>Входящие пакеты тоже не бесконечным потоком льются, если задержать отправку пакетов с
>>подтверждением доставки или начать дропать пакеты, никуда входящий трафик
>да? а вы можете именно их задержать? :) или сможете именно их
>дропать?
>
>>не дойдет,
>>а будет шейпится не хуже исходящего (точнее дойдет тельно первая партия
>>пакетов, остальные будут жать в очереди на отправляющей пакеты машине).
>
>да? а когда выйдет таймаут tcp-сессия прервется и все пойдет заново?
>а если udp-поток?конечно, если резать входящий траффик в результате он сократится, но незначительно, и думаю что в результате фактически никакого выигрыша не будет
traffic-shape for download is OK. As much as it can it buffers
packets. After some time it drops packets. This way TCP "Window"
becomes smaller and "ACK" more seldom. (IMHO) :)
interface Ethernet0 <-- download (local) int
bandwidth 512 <-- total
traffic-shape group 192 420000 10080 10080 1000
!
! This way you shape all network to 420kbps and leave ~50kbps for your
! critical "10.10.10.111"
!
access-list 192 deny ip any host 10.10.10.111 <-- critical IP
access-list 192 permit ip any any time-range sheiper1 <-- all other NETtime-range sheiper1
periodic weekdays 7:59 to 17:01
!
Я думаю тут надо подходить комплексно, то есть регулировать трафик со стороны провайдера и со стороны Вашей сети.
Способов регулирования достаточно много и лучше это обсудить с провайдером, думаю они не откажут.
Это более оптимальный путь, так как Вы можете полноценно оказывать влияние только на трафик из своей сети но ни как не в свою сеть.
Провайдер наоборот.
а что провайдер то кричит, ему то какое дело, ему деньги за это и платят...
Для Volume
Для чего же тогда trafic-shape оно нужно?
>Я думаю тут надо подходить комплексно, то есть регулировать трафик со стороны
>провайдера и со стороны Вашей сети.
>Способов регулирования достаточно много и лучше это обсудить с провайдером, думаю они
>не откажут.
>Это более оптимальный путь, так как Вы можете полноценно оказывать влияние только
>на трафик из своей сети но ни как не в свою
>сеть.
>Провайдер наоборот.
В корне не согласен. Если я запру на вход некий IP, ни кто на него мне 1Gb трафика не зальет. Логично? Тогда что мешает не убивать холопа, но и жить ему не давать? Речь, образно говоря, идет о создании некой плотины, которая не отправляет поток назад, а регулирует его сдерживая. Таким образом, мы получаем не бурный поток, а аккуратненький ручеек. Пусть юзер качает хоть Гигами, но не за полчаса, а за день-другой.
А провайдер недоволе не объемами, атем что наше учреждение полосу иногда занимает гигантскую. И либо провайдер начнет уши подстригать, либо я сам порядок с юзерами наведу. Вопрос стоит в таком ключе.
>>Я думаю тут надо подходить комплексно, то есть регулировать трафик со стороны
>>провайдера и со стороны Вашей сети.
>>Способов регулирования достаточно много и лучше это обсудить с провайдером, думаю они
>>не откажут.
>>Это более оптимальный путь, так как Вы можете полноценно оказывать влияние только
>>на трафик из своей сети но ни как не в свою
>>сеть.
>>Провайдер наоборот.
>В корне не согласен. Если я запру на вход некий IP, ни
>кто на него мне 1Gb трафика не зальет. Логично? Тогда что
>мешает не убивать холопа, но и жить ему не давать? Речь,
>образно говоря, идет о создании некой плотины, которая не отправляет поток
>назад, а регулирует его сдерживая. Таким образом, мы получаем не бурный
>поток, а аккуратненький ручеек. Пусть юзер качает хоть Гигами, но не
>за полчаса, а за день-другой.
>А провайдер недоволе не объемами, атем что наше учреждение полосу иногда занимаетДа я купил у провайдера кнала с такой то полосой пропусания, и какое дело и что? какое дело провайдера на сколько канал занят? не понимаю
>гигантскую. И либо провайдер начнет уши подстригать, либо я сам порядок
>с юзерами наведу. Вопрос стоит в таком ключе.
>>А провайдер недоволен не объемами, атем что наше учреждение полосу иногда занимает
>
>Да я купил у провайдера кнала с такой то полосой пропусания, и
>какое дело и что? какое дело провайдера на сколько канал занят?
>не понимаюТут не надо ничего понимать, ситуация ВОТ_ТАКАЯ (см. выше)и это медицинский
факт. Из него и надо исходить. Разговоры о провайдере - разговоры в пользу бедных.. Нужно техническое решение с моей стороны.
И все..
>Тут не надо ничего понимать, ситуация ВОТ_ТАКАЯ (см. выше)и это медицинский
>факт. Из него и надо исходить. Разговоры о провайдере - разговоры в
>пользу бедных.. Нужно техническое решение с моей стороны.
>И все..А вот это, Вы, батенька зряя..
Здесь я могу прочитать, что Вы хотели сделать, но уверенны ли Вы, что это правильно?
Нет никаких реальных исходных данных - хотя бы как идет работа с провайдером (разумеется только техника - ну ее коммерцию :-))?
Может тогда на Ваш вопрос найдется лучший ответ? Все же немного неприятно когда из тебя пытаются вытянуть решение, ничего не говоря (попросту говоря - разводят).
>
>А вот это, Вы, батенька зряя..
>
>Здесь я могу прочитать, что Вы хотели сделать, но уверенны ли Вы,
>что это правильно?
>
>Нет никаких реальных исходных данных - хотя бы как идет работа с
>провайдером (разумеется только техника - ну ее коммерцию :-))?Вы праву, коммерция - ну ее. :-)
Речь идет о ВУЗовской сети. Есть некий головной ВУЗ со своим Центром
управления полетами - условный "провайдер". Есть разбросанные по городу
ВУЗы. Я админю один из них.
"Взаимодействие с "провайдером"" примерно такое - приходит почтой ко мне
малява: ваш IP-такой-то в такое-то время занимал гигантсую (входящуюу или
исходящуюу) полосу в канале, разобраться, принять меры, доложить! Вот и
все взаимодействие.
Я ни кого ни на что разводить не имею желания. Я имею желания установить
потолок в полосе на вход/выход для каждого IP из моих сетей, так что бы
связь была устойчивой для каждого, без потерь пакетов, с мнимальными
издержками. Исключение - привилегированные IP (сервера и т.д..).
Мое железо - C-5505+ATM+RSFC+FDDI. Железо новое, мной необъезженное,
по этому может и формулирую дурацкие запросы..
Если я сам не сделаю ограничений - сделают "уровнем выше" без всяких
разборок, от этого пострадают ВСЕ. А потом ломать их на снятие ограничений
дело долгое и утомительное..
>>
>>А вот это, Вы, батенька зряя..
>>
>>Здесь я могу прочитать, что Вы хотели сделать, но уверенны ли Вы,
>>что это правильно?
>>
>>Нет никаких реальных исходных данных - хотя бы как идет работа с
>>провайдером (разумеется только техника - ну ее коммерцию :-))?
>
>Вы праву, коммерция - ну ее. :-)
>Речь идет о ВУЗовской сети. Есть некий головной ВУЗ со своим Центром
>
>управления полетами - условный "провайдер". Есть разбросанные по городу
>ВУЗы. Я админю один из них.
>"Взаимодействие с "провайдером"" примерно такое - приходит почтой ко мне
>малява: ваш IP-такой-то в такое-то время занимал гигантсую (входящуюу или
> исходящуюу) полосу в канале, разобраться, принять меры, доложить! Вот и
>все взаимодействие.
>Я ни кого ни на что разводить не имею желания. Я имею
>желания установить
>потолок в полосе на вход/выход для каждого IP из моих сетей, так
>что бы
>связь была устойчивой для каждого, без потерь пакетов, с мнимальными
>издержками. Исключение - привилегированные IP (сервера и т.д..).
>Мое железо - C-5505+ATM+RSFC+FDDI. Железо новое, мной необъезженное,
>по этому может и формулирую дурацкие запросы..
>Если я сам не сделаю ограничений - сделают "уровнем выше" без всяких
>
>разборок, от этого пострадают ВСЕ. А потом ломать их на снятие ограничений
>
> дело долгое и утомительное..ну, как говориться, раз пошла такая пьянка...
я в этом случае car посоветую - режет трафик в обе стороны, меньше грузит циску.
однако это решение "в лоб" - советую присмотреться к высказываниям udlus и evo, поскольку проблему, обозначенную Volume это решить не поможет (если она актуальна - до сих пор непонятно откуда прет "наглый" входящий трафик (на твой маршрутизатор) - из вашей внутреней сети (вузоской) или из вне?)
>однако это решение "в лоб" - советую присмотреться к высказываниям udlus и
прошу прощения - не udlus,а uldus.
>>А потом ломать их на снятие ограничений
>> дело долгое и утомительное..
>
>ну, как говориться, раз пошла такая пьянка...
>я в этом случае car посоветую - режет трафик в обе стороны,
>меньше грузит циску.
>однако это решение "в лоб" - советую присмотреться к высказываниям udlus и
>evo, поскольку проблему, обозначенную Volume это решить не поможет (если она
>актуальна - до сих пор непонятно откуда прет "наглый" входящий трафик
>(на твой маршрутизатор) - из вашей внутреней сети (вузоской) или из
>вне?)
Тут надо определиться в терминах. Я считаю входящим (для меня) трафик
поступающий на смотрящий наружу интерфейс (ATM) моего роутера.
Внутренней сетью я считаю СВОЮ сеть, на которую смотрит внутренний интерфейс роутера (FDDI). Вузовской сетью я называю сеть раскинутую по ВУЗам города. Идет трафик из Парагвая или из соседнего ВУЗа, мне фиолетово
- для меня он ВХОДЯЩИЙ. "Наглый" трафик может быть как входящий, так и
исходящий. Критерий наглости - гигантская занимаемая полоса. Ее и надо
ограничить.
>Тут не надо ничего понимать, ситуация ВОТ_ТАКАЯ (см. выше)и это медицинский
>факт. Из него и надо исходить. Разговоры о провайдере - разговоры в
>пользу бедных.. Нужно техническое решение с моей стороны.
>И все..Ситуация НИКАКАЯ! я в вопросе вижу только то, что Вы хотите сделать (а Вы уверенны, что это правильно?). При этом я не вижу полной ситуации, в которой надо решать этот вопрос. Для примера - откуда качают эти фильмы?: из Вашей локальной сети или Ваш клиент через Вас?
Если Вы провайдер - это одно, если стоите на страже отдельной локальной сетки - это другое, если и первое и второе (все догадались :)) - это третье...
>Ситуация НИКАКАЯ! я в вопросе вижу только то, что Вы хотите сделать
>(а Вы уверенны, что это правильно?). При этом я не вижу
>полной ситуации, в которой надо решать этот вопрос. Для примера
>- откуда качают эти фильмы?: из Вашей локальной сети или Ваш
>клиент через Вас?
>
>Если Вы провайдер - это одно, если стоите на страже отдельной локальной
>сетки - это другое, если и первое и второе (все догадались
>:)) - это третье...
Фильмы качают ото всюду :-)) Меня интересует лишь канал НАРУЖУ - ВХОД и ВЫХОД.
>Это более оптимальный путь, так как Вы можете полноценно оказывать >влияние только
>на трафик из своей сети но ни как не в свою сеть.
У меня на роутере 2 интерфейса, наружный и внутренний. Что мне мешает
полноценно оказывать влияния на входящий и исходящий трафик ?????
>traffic-shape for download is OK. As
>much as it can it buffers
>packets. After some time it drops
>packets. This way TCP "Window"
>becomes smaller and "ACK" more seldom. (IMHO) :)
>-----------SKIP-----------
>time-range sheiper1
> periodic weekdays 7:59 to 17:01
>!Спасибо, попробую применить.
>>Входящие пакеты тоже не бесконечным потоком льются, если задержать отправку пакетов с
>>подтверждением доставки или начать дропать пакеты, никуда входящий трафик
>да? а вы можете именно их задержать? :) или сможете именно их
>дропать?Это сводится к задаче шейпинга исходящих пакетов, так как пакеты с подтверждениями уже исходящий трафик. Что касается "именно их", то заполнение полей TCP/IP заголовках никто не отменял, а задержать пакет в очереди или вообще периодически дропать не так сложно и этого вполне хватит для регулирования входящего потока (все вышесказанное справедливо конечно же для TCP).
>>
>>>
>>>входящий траффик (если он из и-нета) ограничивать особого смысла нет
>>>а исходящий...я думаю traffic-shaping вам как раз
>>>или CBWFQ
>>
>>А почему нет смысла ограничивать входящий - может, люди сидят, фильмы переписывают?
>>Пусть переписывают, но медленно...
>>Ведь деньги-то как раз за входящий и платятся.
>
>правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу
>пропускания, провайдер его УЖЕ ПОСЧИТАЛ
>так есть-ли особый смысл?технически ты прав, но если крендель, который за день выкачивает фильмы пза 30 минут, станет качать их по 12 часов, то думаю, ему это не так интересно будет, со всеми вытекающими последствиями :)....
для TCP во всяком случае - манипулированием шириной окна. систему сделал, у некоторых стоит, вроде никаких жалоб.
>для TCP во всяком случае - манипулированием шириной окна. систему сделал, у
>некоторых стоит, вроде никаких жалоб.
>>для TCP во всяком случае - манипулированием шириной окна. систему сделал, у
>>некоторых стоит, вроде никаких жалоб.какими еще мыслями? все вроде уже сказано.
у TCP-пакета есть параметр "окно" (window), определяющее, сколько октетов информации готова принять сторона, сообщающая window (то есть пакеты с window идут в одну сторону, пакеты с данными - в обратную).
при window>MTU отсылается сразу несколько пакетов (например, 64K/1500 ~ 42). Сокращение параметра window до MTU вызовет снижение скорости в avg(window)/MTU раз за счет того, что за тот же промежуток времени отсылается только один пакет. Экспериментально снижение скорости составляет не меньше 10.
Остается только считать нагрузку на канал, и если она больше допустимой, менять на лету параметр window в TCP-пакетах, и это снижает нагрузку (до 10 раз). Этого достаточно, чтобы красиво резать трафик - без расхода памяти, загрузки процессора и глюков, возникающих из-за дропанья пакетов в других методах.
Недостатки:
1. ограничивает только TCP-составляющую. Впрочем, в подавляющем большинстве случаев именно TCP вызывает значительную загрузку канала.
2. при большой наглости (если желающие перегрузить канал откроют в 10 раз больше потоков, чем обычно) засрать канал таки удастся. решается добавлением дропалки при перегрузке, тогда лишние потоки будут только уменьшать результирующую скорость, и наглецы смиряцца и станут хорошими.У меня есть только реализация под linux в виде пары модулей netfilter (рассчет нагрузки в байт/секунду и изменение окна TCP-пакета). Для прочих ОС и железок - пинайте своих кернелхакеров и фирмварщиков.
под linux ;) набирается из головы, могут быть баги.ставится width-patch
#чайн для ограничения трафика (имя не важно)
iptables -N cutter#ежели на всех хватает, то не надо резать, мы не жадные...
#жадным следующую строчку не надо
iptables -A cutter -m width --bytes=ширина канала в байтах/сек -j RETURN#неприкосновенным не мешать!
iptables -A cutter -s привелегированный -j RETURN#сюда идет трафик непривелегинованных ип в случае перегрузки канала
#мы его считаем и в случае чего снижаем окно до MTU-100
iptables -A cutter -p TCP -m width --bytes=СколькоМыИмДадим -j TCPWIN --set-win=1400#ну и домой
iptables -A cutter -j RETURN#тк я не стал заморачиваться с connection tracking'ом, а менять window нужно в пакетах, идущих в "обратную сторону", на самом деле ограничивается трафик в обе стороны - и входящий, и исходящий.
#направим весь трафик сходить сосчитаться и поправиться
iptables -A INPUT -j cutter
iptables -A OUTPUT -j cutter
>Задача вобщем такая.
>Есть локальная сеть порядка 500 IP. Необходимо ограничить потолок полосы
>на вход/выход для всех IP, кроме привилегированных. А то канал отдельные
>несознательные личности забивают.
>Железо: C-5505+ATM+RSFC.
>Я вижу возможности в Шейпинге и Рэйт-лимит, но не могу врубиться, что
>лучше - недавно я с Цисками работать начал.
>Помогите советом плиззз.Рабочий конфиг:
роутер под Linux SlackWare 8.1
PII-350/64Mb Ram/Hdd 6Gb
сетка на 35 комповядро собрано с поддержкой CBQ
скрипт Павла Голубева ( http://freshmeat.net/projects/cbq.init )
iproute2 (tc и ip)режится ИСХОДЯЩИЙ трафик на каждый IP причем динамически, тк стоит управляющий демон, который выставляет нужную скорость для каждого IP по указаниям с пульта управления :)
система установки скорости тривиальна до бзобразия, файлики с кофигурацими скорости канала на каждый IP, после чего один раз запускается Голубевский скрипт - cbq start
пример конфигурационного файлика:
DEVICE=eth1,100Mbit,10Mbit //Описание интерфейса где будет происходит шейп, в моем случее это локальная карточка
RATE=128KBit //максимальная выделяемая скорость
WEIGHT=12Kbit // хз что такое на всегда должна быть =RATE/10
PRIO=5 //приоритет обработки
RULE=172.18.1.5 //собственно IP на который навешиваем ограничения скорости
все это работает уже два года, жалоб нет.
Основная проблема - мое нежелание запихнуть в загрузку ограничитель скорости для всех и сразу, а то если линукс валится все прутся в инет по бешенному пока не проснется упровляющий демон.Темы по поводу ограничения ВХОДЯЩЕГО трафика, под моей конфигурацией это можно решить только установкой еще одного физического роуера и резать на нем.
И Вообще зачем резать Входящий трафик, ведь он уже приехал на гейт, а вы его резать, нужно резать только ИСХОДЯЩИЙ, получится, то что запросы на получение будут просто медленно проходить, соответственно источник будет медленно отвечать. По UDP данный набор режет тоже и правельно.
ЗЫ: щас вроде появилось продолжение CBQ под названием TBQ
>И Вообще зачем резать Входящий трафик, ведь он уже приехал на гейт,
>а вы его резать, нужно резать только ИСХОДЯЩИЙ, получится, то что
>запросы на получение будут просто медленно проходить, соответственно источник будет медленно отвечать. По UDP данный набор режет тоже и правельно.Прочитал я ваши мнения, но так и не понял всех кто утверждает что не надо резать входящий.
Смотрите
НЕ режем: Ушло от меня 600 байт запроса (Х пакетов) [исходящий]
в ответ закачивается что-нибудь в огромных количествах и в итоге за N секунд я получил многа много Мегабайт входящего ... вы меня не ограничили по исходящиму.режем входящий: Ушло от меня 600 байт запроса (те же Х пакетиков) [исходящий] в ответ начинает так же как и в прошлый раз закачиваться что-нибудь в огромных количествах и в итоге за N секунд я получил НАМНОГО МЕНЬШЕ Мегабайт входящего ... Т.е. Заплатили за тот же периодж времени меньше денюшков.
А почему так ?
А вот потому что входящий начинаеться только после ответов сервера готовых принять их ... т.е.:
Сервер извне посылает N пакетиков траффика... когда ваш сервер ответит что принял их успешно - посылаются следующие, а если ответит с задержкой? Правильно, за то же время вы получите от сервера извне намного меньше пакетов! Тут немного там немного, а в куче дают хороший результат .... $$$$$$$$ :)
Поправьте если я не прав?