Liberatum.ru

У вас вдруг стал хуже работать Интернет?..

В конце 2008 года разработчики uTorrent собрались заменить транспортный протокол с TCP на UDP, реализовав поверх него свою прослойку под названием чTP - дескать, так будет эффективнее. Тогда же исследователь по имени Ричард Беннет заявил, что это будет полная жопа для всего Интернета - UDP менее 2% во всём трафике, он используется для приложений реального времени (игры, телефония) и для критически важного DNS, в общем, пострадают все, из-за отсутствия в нём нормального congestion control (обработки перегрузок сети). Разработчики на это ответили, что они сделают congestion control еще лучше, чем в TCP, и торрент станет даже меньше забивать каналы и мешать другим, чем сейчас. И включили по умолчанию новый протокол uTP в бета-версиях uTorrent 1.8 (правда, сначала только на прием). Время шло, обещанной жопы всея Интернета не было...
До этого февраля. Буквально в понедельник админы бывшего СССР начали спрашивать друг друга, у всех ли отмечено сильное возрастание нагрузки за последние дни. Таки да, оказалось у многих. Выяснилось, что месяц назад вышел uTorrent 2.0, у кучи народа вылезло окошко с предложением обновиться, и с начала февраля пошел рост PPS (нагрузки по пакетам в секунду), причем обратите внимание, не трафика. Много где оборудование к такому неожиданному повороту сюжета было не готово, и проблемы работы Интернета ощутили на себе все, не только "качки". Более того, не только оборудование провайдеров - у многих стали гнать домашние роутеры и ADSL-модемы (вот пост на Хабре на тему), хотя опять же человек может не связать обновление у себя uTorrent и начать обвинять провайдера.

Вот это обсуждение на nag.ru: http://forum.nag.ru/forum/index.php?showtopic=55025&st=160&p=478584
В этой теме было много интересного, например, такая проблема не только у нас, в Амстердаме тоже отмечают увеличение PPS за этот месяц. На этот топик понабежали "хомячки" после обсуждений на том же Хабре и даже на закрытом torrents.ru начали подозревать, что это связано с происками провайдеров. Там было найдено и решение - блокировать пакеты установления соединения поверх UDP по сигнатуре, она оказалась достаточно простая, приведены строки конфигов для разного железа. Надо отметить, что провайдеры имеют на это полное моральное право (потому что разработчики долбоебы, см. ниже), но есть и юридическое обоснование, в теме приведена выдержка из Постановления РФ по такому случаю. Кто-то даже предлагал привлечь разработчиков uTorrent по ст. 272-273 УК РФ (благо среди них есть русские) - за фактический DDOS на оборудование.

Нехрен вы...ться, если не понимаешь в протоколах

Обнаружилось и много других интересных вещей, теперь по технической части. Во-первых, спецификация uTP на http://www.bittorrent.org/beps/bep_0029.html оказалась не той, что реально применяется сейчас - и разработчики uTorrent сказали кому-то в IRC, что сейчас ловят по одному из начальных значений, которое в будущем будет меняться, то есть приведенные решения в будущем перестанут работать. А учитывая, что количество обновляющихся на новую версию юзеров всё растёт... думаю, понимание принципов его блокировки еще пригодится, чтобы адаптировать способы.

Разработчиков спрашивали на форумах еще в прошлом году и критиковали за ряд решений. Более того, спецификация еще и не была доступна для публичного review, как это принято в нормальном случае разработки стандартов Internet. На http://forum.bittorrent.org/viewtopic.php?id=162 заметили, что реальные пакеты uTP не соответствуют спецификации, но ответа разработчиков пока нет. Но - они ж опробовали в локалке, и всё работало замечательно, хехе. К чему нам опыт 30-летней разработки TCP, который разрабатывался, заметим, учеными в университетах?.. Которые его отлаживали и исправляли до действительно массового внедрения на реальных ошибках - первый опыт перегрузки (meltdown) Сети был в конце 80-х. Суть введенных тогда механизмов congestion control (контроля перегрузок) - при отправке данных TCP-стек вашего компьютера постепенно "разгоняет" поток, до тех пор, пока принимающая сторона не сообщит, что часть пакетов не дошла. Тогда делается вывод, что канал забит полностью, надо немного понизить скорость (и такие проверки делаются постоянно, потому что маршруты в Интернете могут в любой момент измениться, и в канале могут еще находиться пакеты других пользователей). Со временем оно обросло сложной математикой (чтобы точнее и быстрее сходилось), оборудование у провайдеров также рассчитано на такое поведение TCP, все методы регулировки полосы и обеспечения качества связи это учитывают. А на UDP отклика от другой стороны нет, можно послать слишком много пакетов и "засрать" канал (причем не только себе), этот отклик придется делать вручную (фактически изобретая TCP заново).

У этого протокола есть ряд принципиальных архитектурных проблем, которые ведут к большому числу пакетов. Это мешает даже его непосредственной цели - улучшить скачивание. Например, на http://forum.utorrent.com/viewtopic.php?id=69592 отметили, что "uTP used 13130 packets, and TCP only 8499 (uTP used 55% more packets than TCP!)" - а это значит, что для файла того же размера трафика на TCP будет меньше.

Одна из ключевых проблем - поверх UDP эмулируется такой же потоковый протокол, как TCP, то есть, пакеты приложению должны приходить по порядку. Фактически, uTP - это во многом изобретение велосипеда, справедливо указывали, что можно было бы просто внедрить нужные механизмы в TCP (правда, это потребует апгрейд всех операционных систем, да). Но и без этого, протоколу передачи файлов, а особенно такому, как BitTorrent, совершенно неважно, в каком порядке передаются блоки файла, можно было бы в UDP это соптимизировать. Им предлагались решения получше. Я бы еще добавил туда DCCP - он, например, хотя бы ECN поддерживает, в отличие от.

Другая из проблем, увеличивающих PPS - это репакетизация и MTU. Максимальный размер пакета на Ethernet 1500 байт, в случае PPPoE (например, ADSL) - он будет уже 1492 байта. Если целый пакет "не пролезает" - без проблем, TCP нумерует байты, он может разбить их на два пакета так, что будет использован максимальный доступный MTU. Но в uTP нумеруются не байты, а пакеты. Это значит, что если был потерян пакет, то его нельзя разбить, надо перепослать его же целиком, иначе будет ошибка в нумерации. А если он не пролезает из-за MTU - его остается только фрагментировать на том роутере, где уменьшается. То есть, после такой точки в сети (а это типичный случай на том же ADSL, от компа до модема 1500, от модема до провайдера 1492) пойдет в два раза больше пакетов.

У TCP на это дело есть худо-бедно, но работающий механизм PMTUd, обнаруживает и подстраивается. Разработчики uTP решили, что можно им воспользоваться - если в ответ пришлют ICMP need-fragment. Но они не учли, что дофига где неграмотные админы блокируют на файрволах ICMP целиком, чем ломают этот механизм. Если у вас когда-нибудь была странная ситуация (особенно на ADSL), что одни сайты работают, другие ни в какую; или же короткие письма (комментарии в форму на сайт, etc.) пролезают, длинные нет - это вот оно. На этот случай производители кабельных модемов и всяких других решений уже давно делают "костыль" - проходящим TCP-пакетам автоматически правится MSS на поменьше. И для всех приложений, работающих по TCP, это прозрачно. Но здесь-то UDP... Вот им и остается уповать на фрагментацию, которая резко увеличит количество пакетов.

Далее, http://forum.bittorrent.org/viewtopic.php?id=131 сообщает, что "Acks are required for every packet". В TCP давно уже научились экономить на ответных пакетах, посылая их только когда надо, совсем не на каждый. А сделано это затем, чтобы как можно точнее измерять задержку между пакетами. Спрашивается, зачем минимизация задержки приложению передачи файлов, ведь в TCP для bulk transfer через long fat pipe давно уже есть алгоритмы?..

Тут и вылезает главная причина увеличения PPS и проблема протокола - это сделано затем, чтобы уменьшить время между перепосылками при потере пакетов - дескать, при шейпинге в буфере модема лучше пусть место кончится для небольших пакетов, меньше перепосылать придется. Более того, BEP-0029 прямо заявляет:
In order to have as little impact as possible on slow congested links, uTP adjusts its packet size down to as small as 150 bytes per packet. Using packets that small has the benefit of not clogging a slow up-link, with long serialization delay. The cost of using packets that small is that the overhead from the packet headers become significant. At high rates, large packet sizes are used, at slow rates, small packet sizes are used.

Другими словами, как только uTP обнаруживает потерю пакета вследствие шейпинга или достижения ширины канала, он начинает уменьшать размер пакета, что ведет к увеличению нагрузки, вследствие того еще большим потерям и дальнейшему уменьшению размера пакета, вот такая больная рекурсия. При этом и изначальный-то размер пакета невелик - всего 300 байт...

Вырезано отсюда: http://nuclight.livejournal.com/125372.html
Так же рекомендую почитать вот это: http://nuclight.livejournal.com/125747.html

Оценка: Select rating Poor Okay Good Great Awesome

Пока без оценки