+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 ячейка спасет нас? Может быть еще и АТМ воскреснет?
Бороться с пирингом и облаками - это точно не конструктивно, ведь в их корне - децентрализация хранения и передачи данных, за этим будущее, если мы не хотим жить в полицейском мире. ИМХО, операторы и пир-ту-пирщики должны сесть за стол, выпить немного чаю и поговорить "за жизнь".