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

1 март, 2010 - 14:43Юрий Кученко

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

Полтора года назад Ричард Беннет (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-provaideri/  Отечественный форум с описанием проблем связанных с работой торентов. Менее информативен, но содержит интересные рассуждения поводу очереди на шейпере и объяснение того, чем это может обернуться для провайдера.

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