`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Юрий Кученко

Цивилизованному Интернету подложили … «хомячка»

+1616
голосов

Увы, пророчества, даже не совсем внятно изложенные, иногда сбываются.

Полтора года назад Ричард Беннет (Richard Bennett) высказал идею , что злоупотребления при использовании протокола UDP, если последний станет нормой для пиринговых сетей, может парализовать весь остальной обмен в Интернет. Признаться, аргументов в противовес пророчеству автора у меня тогда не нашлось, но сохранилось ощущение фантомности угрозы, как после прочтения страшилок о Конце Света.

Да, в сравнении с TCP, UDP содержит меньше служебной информации, следовательно, несет больше полезных данных. Но кому придет в голову, например, организация гарантированной доставки пакета с его помощью за счет дополнительных механизмов квитирования «поверх» стандартных правил обмена (некий tcp over udp) в широко распространенном приложении...?

Напомнили о пророчестве несколько бесед в течении последнего месяца со специалистами-сетевиками, работающими в разных по масштабам и направлениям бизнеса компаниях. В одном случае коллега рассказал о росте трафика во внешних каналах, к которым подключен данный провайдер. Причем, абсолютно непропорциональному расширению собственной и транзитной (партнера) абонентских баз клиентов, подключенных по безлимитным (по объемам трафика) тарифам.

В другой беседе речь шла о аномальном увеличении нагрузки на свои узлы маршрутизации при сравнительно небольшом росте суммарного объема циркулирующего трафика.

Наконец, буквально неделю назад один из российских провайдеров "полуофициально шепнул" об этом, назвав конкретные цифры: у него за одну неделю февраля количество обрабатываемых пакетов в секунду (pps, packets per second) на маршрутизирующем оборудовании возросло на 30-50%.

Глазами специалиста, суть происходящего такова: с конца января (стабильная µTorrent версия 2.0 с µTP вышла как раз 25 января, официально доступна с 3 февраля) в статистических отчетах операторов связи обнаружен непрерывный рост UDP-трафика и одновременно уменьшение средней величины пакетов, которые существенно увеличивали нагрузку на сетевое оборудование. Наблюдения показали, что чем сильнее загружен канал клиента, тем мельче пакеты (до 150 б), длиннее очередь на «шейпере» и выше нагрузка на роутерах.

Во всех случаях причиной происходящего был назван МикроТоррент (µTorrent), с версии 1.8.1 начавший осваивать протокол обмена µTP (Micro Transport Protocol, кстати, так не получивший одобрение IETF). И провайдерам просто повезло, что в силу разных причин клиенты до версии µTorrent v2.0 не обновились одномоментно. (В ней, по умолчанию, UDP-загрузка стартует первой, а если не получится, то лишь тогда – по TCP.) В противном случае нарастание проблем в сети вместо плавного носило бы мгновенный характер и, возможно, сразу «повалило» до трети отечественных провайдеров. Остальные могли бы трактовать поведение как DDoS-атаки на провайдерское оборудование с соответствующим недемократичным «закручиванием гаек» в аварийном порядке.

Окончательный анализ ситуации был осложнен тем, что в открытом доступе полного описания протокола, который стал занимать значительную долю UDP трафика, нет: это описание устарело и не дает полной картины, а статья в Википедии  достаточно поверхностно описывает характер проблем.

Реинжениринг позволил не только убедиться, что согласно алгоритмам µTP в процессе обмена уменьшается длина пакета с ростом загрузки канала, но и предположить, что для подтверждения используются UDP-пакеты квитирования (с функцией, типа ACK) размером в 2 десятка байт.

Логика разработчиков протокола и алгоритмов µTorrent (реклама преимуществ здесь) может оправдываться тем, что они не считают разумным ждать TCP-ACK от доставки пакета. Ведь TCP-поток формируется последовательно, и если в стеке, например, уже находится 50 пакетов, но нет двух, то переданы приложению они не будут, пока потерянные не придут. А вот пиринговое приложение по своей сути как раз и не критично к строгой последовательности в поступлении информации, ведь оно запрашивает и собирает файлы по кусочкам.

И что получается в действительности? Приложение, соответственно, уменьшает размер пакета, потому что у него растет время между отсылкой пакета и приходом квитанции. Но растет-то оно потому, что пакеты стоят в переполненной очереди на «шейпере». И вместо того что бы сначала сбавить количество посылаемых, алгоритм … далее уменьшает их размер. В результате, при данном агрессивном алгоритме использования UDP-протокола МикроТоррентом результирующий трафик (емкость канала) на клиенте практически не меняется. То есть исходная мечта создателей данного ПО – загрузить канал «под завязку» от этого ближе не становится. Меняется только структура трафика – появляется больше мелких пакетов, что для провайдера на самом деле более опасно чем рост трафика.

Давайте посчитаем: если в ходу пакеты по 150 байт, то при скорости 100 мегабит оператору потребуется обработать в секунду ... 87 тысяч пакетов! Не всякий провайдер сможет оперативно отреагировать на возникшую проблему: заменить те же серверы доступа/роутеры на высокопроизводительные не всем по карману. В результате, многие российские провайдеры (от отечественных информации пока не имею) вынуждены были для своих клиентов ввести в дополнение к ограничениям по Mbps, еще и по pps.

Но, даже если провайдерское оборудование сможет справиться с этим алогичным алгоритмом обмена, вместо выжатых из провайдера нескольких лишних процентов полосы, клиент рискует потерять значительно больше благодаря возросшей пакетной нагрузке … на свой домашний шлюз и, возможно даже – на свой не очень современный ПК! А что он сделает, увидев, что скорость закачки снизилась? Правильно, без тени сомнения обратится в техподдержку и свалит свои проблемы на провайдера.

Так как локальная ситуация моделируется достаточно несложно, я провел небольшой эксперимент с имеющимся ADSL-WiFi-шлюзом, который могу предложить продвинутым пользователям µTorrenta. Особо впечатляющим тест будет выглядеть на древних роутерах с WiFi. В моем цикле испытаний устройство начало «притомаживать» примерно уже при 30-40 активных сессиях «обычной» закачки, но при агрессивной работе по UDP (всего 5 раздач) потеряло сразу почти треть полосы. Несомненно, причина – в превышение возможного количества корректно обрабатываемых пакетов за единицу времени.

В заключение, думаю, немного юмора этому посту не повредит. Привожу варианты «политической подоплеки» сложившейся ситуации, которые уже бродят по Сети, и, наверное, в ближайшее время будут подняты на щит желтой прессой (в порядке от более абсурдных идей к менее):

1. Ситуация инспирирована провайдерами, которым выгоднее продавать клиенту не месячный объем трафика (это не гламурно), не bps (клиент до подписания договора быстро находит предлог "до"  во фразе «предостовлять…Х Mbps»), а более сложно контролируемый pps.
2. Вендоры высокопроизводительного сетевого оборудования оплачивают «ошибки» разработчиков МикроТорента, стремясь обосновать необходимость в смене операторского парка, дабы покрыть падение прибыли во время кризиса.
3. Правообладатели некоторого ПО, неудовлетворенные эффективностью борьбы с нелегальным контентом, мотивируют операторов связи на бескомпромиссную войну с клиентами пиринговых сетей.

Продолжать?

Лично мое мнение, что в данном случае просто сработало следствие Закона Мерфи для сетевого ПО. Согласно нему приложения, хорошо оттестированные в изолированной локальной сети, будут вести себя в Интернет абсолютно по-другому. Соответственно, хочется верить, что результат работы этого агрессивного алгоритма, который был создан для максимальной утилизации полосы пропускания, стал неожиданным для самих разработчиков. И что в ближайшее время он будет скорректирован, сняв повод для нарастающего противостояния клиент-оператор.

А пока пользователям µTorrent можно порекомендовать "не дразнить гусей": укрощение протокола µTP в настройках - дело нескольких минут.

Некоторые ссылки по теме:
http://en.wikipedia.org/wiki/Micro_Transport_Protocol#Known_problems Известные проблемы µTP

http://nag.ru/news/newsline/17886/ Интересное обсуждение с участием серьезных специалистов. Предлагаются примеры создания фильтров и методов ограничения UDP-активности разной степени радикальности для различного оборудования.

http://local.com.ua/forum/topic/20354-torent-pochemu-ego-tak-ne-ljubjat-... Отечественный форум с описанием проблем связанных с работой торентов. Менее информативен, но содержит интересные рассуждения поводу очереди на шейпере и объяснение того, чем это может обернуться для провайдера.

http://vilianov.habrahabr.ru/blog/84111/
О том, как плохо бывает домашнему шлюзу под натиском пакетной нагрузки. С моими результатами приведенные не совпали, но сути это не меняет.

 

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+1616
голосов

Напечатать Отправить другу

Читайте также

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

укрощение протокола µTP в настройках - дело нескольких минут.

Как?

Пришлось гуглить минут 20. Ответ не сильно очевиден.
Итак, для начала цитата с одного из форумов:
"For ut 1.8.3 & 1.9 bt.transp_disposition is a bitfield, so the following numbers can be ADDED or used on their own to get the desired effect:

4 – incoming TCP
8 – incoming uTP
1 – outgoing TCP
2 – outgoing uTP

Specific combinations:
5 – TCP incoming + outgoing only (uTP disabled)
10 – uTP only
13 – TCP incoming + outgoing with uTP outgoing only (*1.8.3 default)
15 – both TCP and uTP, incoming + outgoing (*1.9 default)"

Теперь немного по-русски.
запускаем uTorrent, идем в Настройка -> Конфигурация -> Дополнительно. Ищем параметр "bt.transp_disposition".
Если мы хотим полностью включить uTP - ставим цифру 15.
Если мы хотим ОТКЛЮЧИТЬ uTP - меняем значение на 5.
Сохраняем значение, останавливаем все закачки на 30 секунд, потом запускаем их вновь.

Сорри, не думал, что это вызовет осложнения ;)

Я также "игрался" со строкой
bt.transp_disposition 5
(то есть (1+4))
Означает сие:
"_1_ : разрешить инициировать исходящие TCP-соединения.
2 : разрешить инициировать исходящие uTP-соединения.
_4_ : разрешить принимать входящие TCP-соединения.
8 : разрешить принимать входящие uTP-соединения "

По умолчанию стоит 15
UP и DOWN были выставлены на 30/20

После этого желательно все же выйти из программы и снова зайти.

С точки зрения сетевого тестового сегмента, ускоряли его возврат к нормальной жизни:
Run -- CMD -- arp -d
или обычная перезагрузка тестируемого ПК. Но, возможно, это необязательно, а просто особенность сложившейся у меня тестовой связки "провайдер-шлюз-ПК через WiFi"

Да, в версии 2.0 build 16850 (возможно и на других -- не обратил внимание), есть специфика в bt.transp_disposition. Достаточно галочки в параметрe Enable bandwidth management (вкладка BitTorrent) и значение bt.transp_disposition автоматически устанавливается равным 15, при снятии галочки значение становится равным 5.
И наоборот если менять bt.transp_disposition на 15 или 5 галочка на этом параметре (Enable bandwidth managemet) будет соответственно ставиться или убираться.
Причем программа допускает сочетание bt.transp_disposition 13 и включенного параметра Enable bandwidth management, что означает разрешение входящих uTP-соединения и соответственно не упрощает ситуацию.

Мдя. Век дружест­вен­ных пользо­ва­тель­ских интер­фей­сов оконча­тель­но наступил. :)

Самое обидное, что никак с торрентом на сетевом уровне не поборешься - система предельно живуча... Нужен высокоуровневый пакетный фильтр-анализатор трафика чтобы как-то "урезонить" торрент-трафик.

V.K.

Конечно, на коммутаторе тут ничего не сделашь, кроме, возможно, "прощай UDP" (что означает "прощай голос, прощай геймер" и др.)

Я не большой специалист по настройке оборудования провайдерского уровня, но вроде-как работающие и менее радикальные фильтры BGP (от D-Link до различны Сisco) выработаны на вышеупомянутом форуме nag.ru.

> Конечно, на коммутаторе тут ничего не сделашь, кроме, возможно, "прощай UDP" (что означает "прощай голос, прощай геймер" и др.)

... а также прощай днс, что для обычного пользователя == прощай интернет

Возможно, в зависимости от того какого Уровня коммутатор. Один порт (53) можно в ACL прописать открытым. На неуправляемом, соответственно, никакие правила не создашь.

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

Да ладно вам, сделают в последней сборке по умолчанию снятую галочку в параметрe Enable bandwidth management/Вкл. управление скоростью (вкладка BitTorrent) и все прийдет в норму.

... и наступят на горло
http://forum.utorrent.com/viewtopic.php?pid=460104
собственной песне, по собственной инициативе?

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

Какая к чертям песня? Эффективности ноль, а нагрузка на промежуточное оборудование с пустого места на 55% выше. Какого @@@ я должен отдавать такты моего процессора на их песню?

Кстати там конкретно написано, что DIR-300 + беспроводка подыхает.

Помоему интернет не должен становиться рабом пиринговых сетей.

Интернет также не должен становиться их врагом. Ибо интернет существует именно для передачи данных, и политика «этот трафик нам не по нраву» контр­продук­тив­на по определению.

ЗЫ: По-моему, «по-моему» пишется через дефис.

Еще раз для тупых. В моем компе стоит МОЙ процессор. И я не намерен давать бессмысленную увеличенную нагрузку на него с нулевой выгодой. Пусть лучше больше ресурса будет свободно для игр.

Я присоединюсь к вашей беседе. А почему ТВОИ игры приоритетней, чем МОИ торренты? А про "тупых", так тут еще и банят, не забывай.
.
Более логично было бы провайдерам всего мира не ждать 1,5 года, а модифицировать программно-аппаратную составляющую серверного оборудования для более быстрой обработки малых UDP пакетов.

Потому что нагрузка идет на МОЙ процессор! Читай внимательно. Вот когда ты оплатишь мне 6-ти ядерный комп, вот тогда и будешь говорить про свои торренты.

Ну хорошо, объясни мне как для тупых: чем в данном случае нагружен ТВОЙ процессор в ТВОЁМ компе, если шейпинг происходит на обору­до­ва­нии провай­де­ра? Или ты говоришь от лица провайдера? — тогда при чём здесь игры?

Господа, не ссорьтесь!
Как-то все очень конкретно и примитивно получается… :)))
Действительно, основная проблема, которой посвящен блог, связана с резким увеличением нагрузки на провайдерское оборудование.
Однако я лично убедился, что нагрузка на оборудование клиента также возрастает.
Несколько характерных граничных примеров, свидетельствующих о критичность к настройкам uT (разрешен ли UTP) с которыми столкнулся (цифры несколько абстрактны, но тем не менее…):
1. Шлюз ADSL («древний», но «боевой», на TI): видимо, существенно усложняется обработка на уровне беспроводного интерфейса (11g, WEP-64) + затыки при большом количестве сессий и, особенно, в силу роста pps. При звонке SIP качество съезжает с 4 на 3…2,5 балла (субъективно по 5-бальной шкале, детальная диагностика в шлюзе отсутствует).
2. ПК (а весьма часто загрузки поручают старенькому PC-файл-серверу домашней сети, а не рабочей машине). Наблюдал на Athlon-750, 512 MB, XP при отключенном брандмауэре: увеличение загрузки с 25-35% до 40-60% и почти удвоение объема используемой памяти.

Итого, насколько я знаю по спецификациям, в относительно старых коробках стоят процы x86 около 100 мегагерц. В новейших около 300. Если экстраполировать на Athlon-750, то как раз и выходит, что новейшие коробки легко вытянут, старые загнутся с двукратной перегрузкой, то есть гарантированно! Технология обещает убить Сеть в тех местах, где стоит оборудование старше 2 лет...
Мило.

Для тупых - эта технология приводит к тому, что захлебывается не только какое то там оборудование провайдеров, на которое мне начхать, но и МОЯ коробка, в которой стоит фактически х86 процессор, обеспечивающий работой НАТ. Также эта технология фактически на 40% увеличивает нагрузку на мой CPU, который участвует в формировании сетевых пакетов, когда торрент запущен на моем компе. Фактически это абсолютно маразматическая технология, которая НЕ дает прироста скорости, а дает лишь дополнительную нагрузку.
Как я понял, гарантированно не подыхать будут только новейшие коробки-роутеры по цене 150$ и выше. Все зависит еще и от скорости, которую дает провайдер, чем шире канал, тем быстрее коробка загнется под гнетом мельчайших пакетов.

Провайдерам имеет смысл с одной стороны - ограничить pps на клиента...с другой - разъяснить свои проблемы пользователям трекеров - например, через статьи и FAQ на тех же трекерах. Вплоть до рекомендации использовать "правильные" торрент-клиенты. Протестировать их не так трудно...если оператор действительно заинтересован в снижении нагрузки на роутеры - а не в тривиальной "рубке" торрентов аки Воля.

Разумеется, всё это до тех пор пока разработчики utorrentа не исправят положение.

Провайдерам имеет смысл с одной стороны - ограничить pps на клиента

Хм, а как пересічному клиенту этот pps контролировать?

с другой - разъяснить свои проблемы пользователям трекеров - например, через статьи и FAQ на тех же трекерах.

А вот это — правильный подход.

Вплоть до рекомендации использовать "правильные" торрент-клиенты.

Смотря какой «настйчивости» будет рекомендация...

...а не в тривиальной "рубке" торрентов аки Воля.

«Воля» рубит торренты? В чём это выражается?

Как исправить? Там нет технологической возможности правильно измерить задержку для кореектного увеличения размера пакета. То есть сама идея не может быть реализирована на практике В ПРИНЦИПЕ ввиду больших погрешностей измерения данных, необходимых в работе оптимизатора пакетов.

А не дай бог, у людей еще и подключение по VPN - так тогда полная....

IP ячейка спасет нас? Может быть еще и АТМ воскреснет?

Бороться с пирингом и облаками - это точно не конструктивно, ведь в их корне - децентрализация хранения и передачи данных, за этим будущее, если мы не хотим жить в полицейском мире. ИМХО, операторы и пир-ту-пирщики должны сесть за стол, выпить немного чаю и поговорить "за жизнь".

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT