Utp протокол – Основы компьютерных сетей. Тема №3. Протоколы нижних уровней (транспортного, сетевого и канального) — groupnk.ru — Группа НК — комплексные поставки электрооборудования в Москве и регионах

Содержание

что это, как, зачем? / Habr

Традиционно большинство P2P-приложений использовало TCP для обмена данными. Про то, что µTorrent начинает использовать новый протокол, основанный на UDP, на хабре уже упоминали (раз, два). В данном посте новый протокол µTP описан подробнее, в том числе его тюнинг и возможность отключения. Подробности описаны таким образом, чтобы было понятно далёким от сетевых протоколов людям.

Update: Официальная документация на протокол: www.bittorrent.org/beps/bep_0029.html

Пара слов про TCP и UDP. Первый расшифровывается как Transmission Control Protocol, или протокол управления потоком. Он удобен тем, что даёт использующей его программе гарантию, что данные дойдут до адресата целыми, полностью и в том порядке, в котором были отправлены. Его использование требует предварительной установки соединения и его закрытия в конце. Этакое создание «трубы» через которую будет идти обмен данными. UDP же не предоставляет никаких гарантий что данные дойдут, или что дойдут в правильном порядке. Он только позволяет переслать небольшой блок данных (датаграмму) от одного адреса другому. Вся работа по проверке доставки, и при необходимости — повторной посылке, ложится на саму программу.

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

При этом, если посылающий сидит на широком канале, а принимающий — на модеме, то первый сразу отправляет большой блок данных, который может быстро дойти до провайдера второго, и потихоньку просачиваться в модем. В это время первый, не получив подтверждения о получении, перешлёт часть кусков заново. Ещё раз, и ещё, в результате магистраль провайдера оказывается забита этой ненужной перепосылкой. Одна из основных целей uTP — устранить эту лишнюю нагрузку на провайдеров от P2P-трафика.

Латентно uTP появился в µTorrent версии 1.8, но умел принимать только входящие uTP-соединения, инициировать их сам — не умел. Впервые это научилась альфа-версия 1.9, потом стало возможным включить это и в новых версиях 1.8 ключиком bt.transp_disposition. Его значение от версии к версии менялось, но сейчас устаканилось на следующих битовых флагах:

1 — разрешить инициировать исходящие TCP-соединения,
2 — разрешить инициировать исходящие uTP-соединения,
4 — разрешить принимать входящие TCP-соединения,
8 — разрешить принимать входящие uTP-соединения

Таким образом, 13 (1+4+8), значение по умолчанию в последних версиях 1.8, означает возможность принимать все виды соединений, но самостоятельно устанавливать только TCP. 15 (значение по умолчанию в 2.0) разрешает все виды как исходящих так и входящих соединений. Чтобы запретить uTP вообще (если он вызывает какие-либо проблемы) надо поставить 5 (1+4). Стоит ли ставить 15 в 1.8 — вопрос спорный, на официальном форуме пишут что поддержка uTP в версии 2.0 намного лучше, поэтому скорость в 1.8 может быть хуже, чем по TCP.

В версии 2.0 также появилась поддержка UDP-трекеров. Для трекера вообще TCP очень излишний и требует много лишних ресурсов пакетами установки/закрытия соединения, поэтому для открытых трекеров UDP — благо. Например, последнее время трекер anirena очень глючит по TCP и далеко не с первого раза отвечает, DHT там часто запрещён, а UDP-трекер работает прекрасно. Но для закрытых трекеров он не подходит, т.к. не позволяет послать пасскей, чтобы идентифицировать таким образом качающего.

Ещё в 2.0 появится метод обхода некоторых NAT (STUN), что поможет соединяться большему числу NAT-страдальцев, хотя будет работать не во всех случаях.

Лично меня из всех новшеств 2.0 больше всего порадовал TCP Rate Control. Он позволяет подстраивать скорость и TCP-соединений так, чтобы они не мешали другим приложениям и минимизировать лишнюю перепосылку пакетов, о которой написано выше. Раньше это достигалось установкой cFos-драйвера, в котором можно было поставить низкий приоритет торренту, высокий — браузеру, а с версией 2.0 этого больше не требуется. Управляется это опцией bt.tcp_rate_control, если вам важнее чтобы торрент не мешает другим интернет-приложениям — его стоит включить, если важна максимальная скорость торрента — есть смысл отключить, на официальном форуме пишут что это иногда скорость увеличивает.

Замечу, что в uTP это делается всегда, даже в версии 1.8, а скорость TCP-трафика подстраивается под загрузку канала только в 2.0. В uTP постоянно меряется время отклика от пиров, с которыми происходит обмен данными. как только этот «пинг» начинает увеличиваться, задолго до начала потерь пакетов, µTorrent сбавляет скорость.

За счёт этого, пока канал свободен — он используется на полную. как только например другое приложение (броузер) начинает грузить канал — в µTorrent’е начинает возрастать время отклика, и он автоматически освобождает канал для броузера. Как только пинг вернулся обратно (канал снова освободился) — µTorrent увеличивает загрузку канала. При этом лишних перепосылок пакетов гораздо меньше, чем если бы это происходило на TCP-уровне

Впрочем, тут есть интересный момент, что с ней или по uTP исходящий канал может забиваться на 95%, а без неё только с TCP — на 100%, но эта разница в 5% может оказаться той самой излишней перепосылкой одних и тех же пакетов, что канал забивает, а реальной пользы не приносит, так что imho не всегда когда канал чуть недозабивается это значит что новая версия хуже.

Ещё в обсуждениях часто мелькает ключ net.calc_overhead. Если он включен, то при настройке скорости учитывается и служебный трафик — запросы блоков, подтверждения, уведомления какие блоки у кого есть и т.п. Если отключен — считаются только сами блоки данных. Поэтому раньше советовали ограничивать исходящий канал в торренте до 80-90% от реального, иначе он весь забивался отправляемыми блоками, и уведомления о получении блоков и запросы новых не успевали проходить, поэтому серьёзно страдала скорость скачивания. Опять же, на широких каналах некоторые пишут что при выключении этой опции скорость чуть выше, но может это глюк бета-версии и в релизе всё будет нормально.

Тут ещё есть такой момент, в котором я не уверен на 100%, но кажется что служебного трафика в uTP больше. Ибо в каждой маленькой датаграмме надо передавать что это за блок, от какого торрента, а по TCP можно посылать большие блоки, не подписывая каждый кусочек. Впрочем, тут будет служебный трафик самого TCP, так что не факт что он сильно «экономичнее».

Ещё нельзя не упомянуть такое явление, как «шейпинг» или «резание» P2P-трафика некоторыми провайдерами. Для России это (пока?) не актуально, а на открытых трекерах, где много пиров со всего мира, скорость по uTP значительно выше.

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

Другие «продвинутые» опции, на которые можно обратить внимание:
bt.connect_speed — сколько максимум новых соединений можно устанавливать в секунду (стоит увеличить, у меня стоит 80),
net.max_halfopen — про это много писалось, и менять стоит вместе с патчем tcpip.sys, хотя с протоколом uTP это уже не важно.
net.utp_target_delay — это некий целевой «пинг» при подстройке соединений, в некоторых случаях при его увеличении где-то до 400-500 скорость становится лучше.
peer.disconnect_inactive_interval — через сколько секунд закрывается соединение с пиром, с которым нет обмена данными, актуально больше для открытых трекеров где больше народу и «плохих» пиров, либо на случай сетевых глюков — чтобы быстрее определять разрыв соединения и переустанавливать его. в некоторых случаях имеет смысл понизить до 90-120.

Версия 2.0 хотя и бета — вполне стабильная, скачать можно тут: forum.utorrent.com/viewtopic.php?id=60602

По личным ощущениям, в старых альфах 1.9 при скачивании с открытых трекеров если до этого входящий канал загружался где-то на 1/3, с uTP стал грузиться где-то на 2/3. При скачивании с закрытых трекеров раньше канал загружался так, что броузер начинал подтормаживать, а в 2.0 всё летает.

Torrent/uTP — о протоколе и самодельных DPI / СоХабр

В 2009 году появился Micro Transport Protocol, сокращённо — uTP, можно ознакомится тут.
Суть задумки в том, чтобы не полагаться на TCP Congestion Control, которым под виндой рулить весьма проблематично, а самим управлять загрузкой канала.
uTP выявил много узких мест как у провайдеров так и у пользователей: ещё вчера прекрасно работающие роутеры превратились в тыкву. А некоторые пользователи обнаружили что торренты качаются на все 100 мегабит, не зависимо от тарифа.

Также провайдерам намного сложнее блокировать передачу данных через μTP благодаря отсутствию строгих, формализованных отличий UDP пакетов обычного трафика (формируемого, к примеру, сетевыми играми) от трафика, формируемого протоколом μTP, в отличие от TCP пакетов, по содержанию полей которых можно делать вывод об их принадлежности к p2p-трафику.

https://ru.wikipedia.org/wiki/ΜTorrent

Как не правильно блокировать можно почитать тут: geektimes.ru/post/243305/

и немного ниже 🙂

Жизнь с uTP

Слухи, сплетни, домыслыВ адрес авторов uTP звучала масса упрёков в изобретении TCP с нуля и хождении по всем граблям, в том что они не взяли уже готовые протоколы, и в том что теперь придётся обновляться и расширятся.
С точки зрения разработчиков — выбора особо не было: TCP все провайдеры шейпят и душат, для управления всеми аспектами работы tcp протокола в винде нужны права администратора и скорее всего свой драйвер, многие другие протоколы которые ходят поверх IP (tcp/udp/gre/udplite/…) вообще провайдерами фильтруются и в винде их так просто не реализовать.
Потому просто взяли и сделали поверх UDP.

Это решение подкосило многие домашние мыльницы и некоторых провайдеров.

Количество трансляций в NAT роутеров стало очень быстро расти.
Для TCP — NAT знает когда соединение установлено и когда оно завершено, а для UDP понятие соединений отсутствует в принципе, поэтому обычно применяются таймеры для удаления старых сессий.

Другим побочным эффектом явилось то, что uTorrent запрашивал больше трафика чем позволял тарифный план провайдера, и от этого страдали даже те провайдеры у которых шейпер был настроен правильно: на хомячка из интернета прилетало ощутимо больше его тарифного плана и этот излишек дропался шейпером. Провайдеры несли финансовые потери от такого DDoS хомяка на самого себя.
Авторы uTorrent позже всё таки научились правильно подстраиваться под канал, но их эксперименты стоили нервов и денег.

Ещё одним неприятным моментом в экспериментах с uTP на начальных этапах было то, что он генерировал большую пакетную нагрузку, отправляя множество мелких UDP пакетов. Позднее авторы научились заполнять пакеты с данными целиком.
Повышение пакетрейта губительно сказывается на WiFi и прочих радиолинках.

В целом, протокол оказал ощутимое влияние как на провайдеров так и на производителей железа, я бы даже сказал что он подготовил почву для HD в ютубе.

Протокол uTP

Документация на английском

Версия 0

Начиная с uTorrent 1.8

typedef struct utp_pkt_s { 	/* offset - PacketFormat */
	uint32_t	connid;		/* 00 connection ID */
	uint32_t	tv_sec;		/* 04  */
	uint32_t	tv_usec;	/* 08  */
	uint32_t	reply_micro;	/* 12  */
	uint8_t	windowsize;	/* 16 receive window size in PACKET_SIZE chunks */
	uint8_t	ext;		/* 17 Type of the first extension header */
	uint8_t	flags;		/* 18 Flags */
	uint16_t	seq_nr;		/* 19 Sequence number */
	uint16_t	ack_nr;		/* 21 Acknowledgment number */
								/* 23 ext/data */
} utp_pkt_t, *utp_pkt_p; /* 23 bytes */

Версия 1

Начиная с uTorrent 2.0

typedef struct utp_pkt_v1_s { 	/* offset - PacketFormatV1 */
	uint8_t	version:4;	/* 00 protocol version */
	uint8_t	type:4;		/* 00 type (formerly flags) */
	uint8_t	ext;		/* 01 Type of the first extension header */
	uint16_t	connid;		/* 02 connection ID */
	uint32_t	tv_usec;	/* 04  */
	uint32_t	reply_micro;	/* 08  */
	uint32_t	windowsize;	/* 12 receive window size in bytes */
	uint16_t	seq_nr;		/* 16 Sequence number */
	uint16_t	ack_nr;		/* 18 Acknowledgment number */
								/* 20 ext/data */
} utp_pkt_v1_t, *utp_pkt_v1_p; /* 20 bytes */

Типы пакетов

enum {
	ST_DATA		= 0,	/* Data packet. */
	ST_FIN		= 1,	/* Finalize the connection. This is the last packet. */
	ST_STATE		= 2,	/* State packet. Used to transmit an ACK with no data. */
	ST_RESET		= 3,	/* Terminate connection forcefully. */
	ST_SYN		= 4,	/* Connect SYN. */
	ST_NUM_STATES	/* Used for bounds checking. */
};

flags из версии 0 превратился в type в версии 1, типы пакетов перечислены выше.

Сначала отправляется SYN на него приходит ответ STATE или RESET.
Завершается соединение на FIN или RESET.
DATA и STATE используются при передаче данных.

connid — идентификатор соединения. В TCP его роль выполняет номер порта (вернее их пара). Номер соединения у двух хостов всегда различается на единицу.
Вообще довольно запутанная и странная схема установления соединения:
>> SYN: connid=34 — запрос на установление соединения
<< STATE: connid=34 — подтверждение
>> DATA: connid=35 — передача данных
<< STATE: connid=34 — подтверждение передачи данных
Те инициатор соединения задаёт номер соединения в первом пакете а в дальнейшем использует номер на единицу больше.

seq_nr и ack_nr — используется чтобы ориентироваться в потоке в случае потери или реордеринга (когда первый отправленный пакет приходит после второго).

Остальные поля меня интересовали мало, хотя для ext опций валидацию написал.

ext — если есть дополнительные расширения/данные в пакете после заголовка, аналог IP otions.

tv_usec, reply_micro, windowsize — относятся к информации необходимой для управления скоростью передачи.

Шифрование

Если кто то ещё читает и не уснул то мог заметить что шифрования нет.
Его действительно нет!
Не потому что описание не полное а потому что оно реализовано несколькими уровнями выше и uTP никак не касается.
uTP заголовки никак не шифруются.

Заход 1: uTPControl

Из спортивного интереса я решил попробовать написать нечто что сможет аккуратно выключать uTP у юзеров чей трафик проходит через роутер с моей программой.
В начале я пробовал слать RESET с виндовой машины, перебирая connid, но это явно не работало, не совпадали адреса отправителя пакета и seq_nr, ack_nr. Это был первый неудачный опыт.

uTPControl — была первая более менее программа которую я написал под FreeBSD.
uTPControl — block uTP torrent proto
uTP протокол был любезно предоставлен в libuTP всему интернету 🙂

Работало uTPControl чрезвычайно просто: программа создавала divert сокет и бесконечно читала из него пакеты в цикле. Если это был UDP пакет, в котором ВОЗМОЖНО uTP версии 0 или 1 и тип пакета не FIN и не RESET то генерируем UDP-uTP RESET пакет и отправляем обратно.
Те клиент пытался установить связь и сразу получал RESET — те его вроде как отключил тот к кому он подключался.

Минусов у этого решения было два:
1. Ложные срабатывания: иногда пакеты от некоторых онлайн игр были прямо как uTP и им улетал ответ, видимо у игр от этого срывало крышу и юзеры жаловались.

2. Низкая производительность: все пакеты из ядра копировались в юзерспейс и там в один поток обрабатывались.

В один поток на CoreDuo Е5300 под FreeBSD 7.3 выдавало до 100 тысяч пакетов RESET в секунду.
Один поток можно было обойти запустив несколько экземпляров и как то раскидав через ipfw пакеты между ними.

В виду этих фатальных недостатков интерес со стороны сообщества пропал и я её забросил.

Был человек который превратил это в netgraph ноду, но ложные срабатывания это не вылечило.

Заход 2: ng_utp

uTP (udp torrent) netgraph node
Прошло полтора года, я успел покопаться в ядре FreeBSD и netgraph, лучше узнать как работает сеть и пришла мысль: uTP имеет состояния аналогичные TCP, значит чтобы его 100% определять нужно эти состояния отслеживать.
Заодно я ещё раз заглянул в libuTP и получше посмотрел за что можно зацепится.
За сигнатуры я решил не цепляться, это плохой путь с массой ложных срабатываний и мучениями по их поддержанию — авторы уже несколько раз меняли начальные константы и сигнатуры «протухали» у тех кто их использовал.
Идеальный вариант это свой «клиент» с референсной реализацией uTP который будет выстраивать таблицу соединений на основе пролетающих через него пакетов и уже по данным этой таблицы что то можно делать.

В итоге получилась netgraph нода, которую можно подключать к L2 хукам типа ng_ether или L3 хукам, например ng_ipfw. В первом случае можно вообще сделать прозрачный эзернет мост из двух сетевух (не обязательно физических). Ещё можно просто поставить тазик и зеркалировать на него весь траф, но я сейчас не уверен в работоспособности такой схемы.

Результатов замеров производительности я не сохранил.
Однако нода без проблем параллелится по ядрам, может выполнятся как контексте ISR так и потоками netgraph, взаимные блокировки потоков сведены к минимуму.

В случае L2: мультикаст и броадкаст пакеты пролетают сразу насквозь, тэгированный трафик обрабатывается как обычный. QinQ не делал, добавить не сложно.
Обрабатываются только IPv4 пакеты UDP, не адресованные и не отправленные с 127/8, не являющиеся броадкастом или мультикастом, и ещё немного проверок что это не мусор а то что нужно, включая опциональную проверку контрольной суммы IP и UDP.

Далее проверяется что содержимое UDP пакета похоже на uTP.

Если содержимое похоже то ищем в таблице состояний запись для данной пары хостов: src ip:port / dst ip:port, если не находим то меняем местами и ищем ещё раз. Не нашли и пакет не FIN или RESET — добавляем. (подозреваю что на линухе с conntrack было бы чуть проще, а тут пришлось самому писать)
Теперь есть элемент который хранит все uTP соединения между двумя хостами или то что похоже на них.
Ищем там connid, если не нашли то connid+-1, если опять нет — добавляем.

Теперь у нас есть куда писать данные по конкретному uTP соединению.
Пишем: время последнего обновления, время последней отправки запроса и получения ответа, считаем запросы и ответы, запоминаем какие типы пакетов встречались.
seq_nr и ack_nr можно было бы тоже запоминать и анализировать но и без них достаточно точно получается определять.
Старые записи удаляются автоматически.

Теперь мы точно знаем что хосты установили uTP соединения, знаем сколько каждый отправил пакетов и получил ответов, знаем их идентификаторы, можно действовать.

Действовать имеет смысл только для DATA и STATE пакетов.

Что можно сделать:

ничего, просто мониторинг: есть счётчики по хостам, соединениями, сами таблицы с хостами…
дропать пакеты с uTP: src ip:port + dst ip:port есть
помечать пакеты: на L2 в VLAN заголовке PCP для тегированных пакетов 802.1P
помечать пакеты: на L3 в IP заголовке — ip_tos — DSCP
отправлять uTP — RST пакеты

Чтобы сгенерировать RST пакет все данные есть: src ip:port + dst ip:port, pkt_ver, connid, ack_nr, seq_nr.
Фактически у IP/UDP пакета заменяются данные, пересчитывается контрольная сумма и от отправляется дальше.

Подробнее про счётчики — по ссылке, там описание, если его мало есть код 🙂

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

Сигнатуры

И эти люди продают мне интернет?!!! — возникает у меня периодически к голове, когда я читаю провайдерский форум. 🙂

Провайдеры искали способ как быстро нормализовать работу сети и решили фильтровать uTP по сигнатурам пакетов, добавляя их то в ACL коммутаторов то в фаервол BSD/Linux роутера.
«Странность» ситуации в том, что сигнатуры искали анализируя пакеты.
Притом, что код libuTP был открыт 16 мая 2010 года — через 4 месяца после выхода uTorrent 2.0 где uTP был включён.

Спустя пару месяцев «живительные» сигнатуры путём нечеловеческих усилий по анализу пакетов были получены.
Ещё через некоторое время авторы поменяли пару незначительных для протокола начальных значений в SYN пакете и что то рандомизировали (connid, seq_nr — больше не смогли) 🙂

После того как ng_utp был написан стало понятно что проверять корректность работы с помощью tcpdump без правильных сигнатур мягко говоря не удобно — слишком много лишнего приходилось пробегать глазами.
Я ещё раз пробежался по коду libuTP и получились такие сигнатуры, сейчас может быть они уже устарели.

Версия 0

SYN

syn — 14 bytes

‘udp[17] = 2 and udp[18] = 4 and udp[21:2] = 0 and udp[23] = 0 and udp[24] = 8 and udp[25:4] = 0 and udp[29:4] = 0’

41 = udp hdr len (8) + upd pkt data len

upd header included:
‘(udp[4:2] = 41 and udp[25:2] = 0x0204 and udp[29:4] = 0x00000008 and udp[33:4] = 0 and udp[37:4] = 0)’

— последнее это то что можно скармливать в tcpdump, отличается от первой смещениями и тем что константы объединены чтобы сравнений было меньше. Первая больше для самообразования.

RESET

rst — 4 bytes

‘udp[17] = 0 and udp[18] = 3’

31 = udp hdr len (8) + upd pkt data len

upd header included:
‘(udp[4:2] = 31 and udp[25:2] = 0x0003)’

Версия 1

SYN

syn — 14 bytes

‘udp[0] & 0x0f = 1 and udp[0] & 0xf0 = 0x40 and udp[1] = 2 and udp[18:2] = 0 and udp[20] = 0 and udp[21] = 8 and udp[22:4] = 0 and udp[26:4] = 0’

(udp[0] & 0x0f = 1 and udp[0] & 0xf0 = 0x40) => udp[0] = 0x41

38 = udp hdr len (8) + upd pkt data len

upd header included:
‘(udp[4:2] = 38 and udp[8:2] = 0x4102 and udp[26:4] = 0x00000008 and udp[30:4] = 0 and udp[34:4] = 0)’

RESET

rst — 4 bytes
‘udp[0] & 0x0f = 1 and udp[0] & 0xf0 = 0x30 and udp[1] = 0’
(udp[0] & 0x0f = 1 and udp[0] & 0xf0 = 0x30) => udp[0] = 0x31)
28 = udp hdr len (8) + upd pkt data len

upd header included:
‘(udp[4:2] = 28 and udp[8:2] = 0x3100)’

Обнаружение фильтрации

Проще всего, используя описание протокола, реализовать простенький клиент, который будет устанавливать соединение и пытаться отправлять данные.
По сути нужно симулировать установление соединения, и дальше пытаться слать DATA и STATE пакеты в ответ с ext типа ACK.
Дальше один клиент запускается в интернете, другой у себя и смотрим теряются ли пакеты в 100% случаев или может RESET приходят.
Сходным образом при использовании yota некоторые пакеты из l2tp на завершающем этапе согласования пропадают в 100% случаев. Так было ещё в сентябре.

Заключение

1. То что написано в вики на русском — полнейший бред: uTP имеет достаточно чёткие сигнатуры и легко ловится DPI.
Более того, ловить сигнатуры в TCP ощутимо сложнее, поскольку для гарантированного обнаружения нужно уметь собирать несколько пакетов вместе и уже потом проверять содержимое: клиент может передавать данные по одному байту.
Авторы uTP либо не ставили себе цель сделать протокол без сигнатур либо даже не приблизись к цели.
(На мой взгляд в начале не ставили, а потом было уже поздно и рандомизация отдельных полей не помогает).
Вики на английском более адекватна.

2. Производители различных DPI уже давно добавили сигнатуры для uTP, вряд ли им это было трудно сделать.

3. В порядке слухов: для линукса вроде бы тоже есть ядерная версия для работы с uTP протоколом на базе ipp2p а может уже отдельно. Но в паблик её не выкладывали. С середины 2012 года.

4. Для IPv6 код не писал, на всякий случай 😉

5. uTP не лучше TCP для передачи данных, вся проблема в том, что TCP можно хоть как то управлять из приложения только на BSD/Linux — setsockopt(…, IPPROTO_TCP, TCP_CONGESTION,…) — основное что требуется, хотя и там более тонкие параметры congestion control для отдельных сокетов не настраиваются.
Говорить про оверхэд в 23/20 байт сейчас уже не актуально, HTTP/2.0 не сильно лучше.
Возможно с приходом кучи готовых либ для HTTP/2.0 торренты пустят и через него, скорее всего это вопрос времени.

Torrent-uTP — о протоколе и самодельных DPI

Также провайдерам намного сложнее блокировать передачу данных через μTP благодаря отсутствию строгих, формализованных отличий UDP пакетов обычного трафика (формируемого, к примеру, сетевыми играми) от трафика, формируемого протоколом μTP, в отличие от TCP пакетов, по содержанию полей которых можно делать вывод об их принадлежности к p2p-трафику.

https://ru.wikipedia.org/wiki/ΜTorrent

Как не правильно блокировать можно почитать тут: geektimes.ru/post/243305/
и немного ниже 🙂

Жизнь с uTP

Слухи, сплетни, домыслы В адрес авторов uTP звучала масса упрёков в изобретении TCP с нуля и хождении по всем граблям, в том что они не взяли уже готовые протоколы, и в том что теперь придётся обновляться и расширятся.
С точки зрения разработчиков — выбора особо не было: TCP все провайдеры шейпят и душат, для управления всеми аспектами работы tcp протокола в винде не нужны права администратора и скорее всего свой драйвер, многие другие протоколы которые ходят поверх IP (tcp/udp/gre/udplite/…) вообще провайдерами фильтруются и в винде их так просто не реализовать.
Потому просто взяли и сделали поверх UDP.

Это решение подкосило многие домашние мыльницы и некоторых провайдеров.
Количество трансляций в NAT роутеров стало очень быстро расти.
Для TCP — NAT знает когда соединение установлено и когда оно завершено, а для UDP понятие соединений отсутствует в принципе, поэтому обычно применяются таймеры для удаления старых сессий.

Протокол uTP

Документация на английском

Версия 0

Начиная с uTorrent 1.8

typedef struct utp_pkt_s { 	/* offset - PacketFormat */
	uint32_t	connid;		/* 00 connection ID */
	uint32_t	tv_sec;		/* 04  */
	uint32_t	tv_usec;	/* 08  */
	uint32_t	reply_micro;	/* 12  */
	uint8_t	windowsize;	/* 16 receive window size in PACKET_SIZE chunks */
	uint8_t	ext;		/* 17 Type of the first extension header */
	uint8_t	flags;		/* 18 Flags */
	uint16_t	seq_nr;		/* 19 Sequence number */
	uint16_t	ack_nr;		/* 21 Acknowledgment number */
								/* 23 ext/data */
} utp_pkt_t, *utp_pkt_p; /* 23 bytes */

Версия 1

Начиная с uTorrent 2.0

typedef struct utp_pkt_v1_s { 	/* offset - PacketFormatV1 */
	uint8_t	version:4;	/* 00 protocol version */
	uint8_t	type:4;		/* 00 type (formerly flags) */
	uint8_t	ext;		/* 01 Type of the first extension header */
	uint16_t	connid;		/* 02 connection ID */
	uint32_t	tv_usec;	/* 04  */
	uint32_t	reply_micro;	/* 08  */
	uint32_t	windowsize;	/* 12 receive window size in bytes */
	uint16_t	seq_nr;		/* 16 Sequence number */
	uint16_t	ack_nr;		/* 18 Acknowledgment number */
								/* 20 ext/data */
} utp_pkt_v1_t, *utp_pkt_v1_p; /* 20 bytes */

Типы пакетов

enum {
	ST_DATA		= 0,	/* Data packet. */
	ST_FIN		= 1,	/* Finalize the connection. This is the last packet. */
	ST_STATE		= 2,	/* State packet. Used to transmit an ACK with no data. */
	ST_RESET		= 3,	/* Terminate connection forcefully. */
	ST_SYN		= 4,	/* Connect SYN. */
	ST_NUM_STATES	/* Used for bounds checking. */
};

flags из версии 0 превратился в type в версии 1, типы пакетов перечислены выше.
Сначала отправляется SYN на него приходит ответ STATE или RESET.
Завершается соединение на FIN или RESET.
DATA и STATE используются при передаче данных.

connid — идентификатор соединения. В TCP его роль выполняет норме порта (вернее их пара). Номер соединения у двух хостов всегда различается на единицу.
Вообще довольно запутанная и странная схема установления соединения:
>> SYN: connid=34 — запрос на установление соединения
<< STATE: connid=34 — подтверждение
>> DATA: connid=35 — передача данных
<< STATE: connid=34 — подтверждение передачи данных
Те инициатор соединения задаёт номер соединения в первом пакете а в дальнейшем использует номер на единицу больше.

Остальные поля меня интересовали мало, хотя для ext опций валидацию написал.

ext — если есть дополнительные расширения/данные в пакете после заголовка, аналог IP otions.

tv_usec, reply_micro, windowsize — относятся к информации необходимой для управления скоростью передачи.

Шифрование

Заход 1: uTPControl

2. Низкая производительность: все пакеты из ядра копировались в юзерспейс и там в один поток обрабатывались.
В один поток на CoreDuo Е5300 под FreeBSD 7.3 выдавало до 100 тысяч пакетов RESET в секунду.
Один поток можно было обойти запустив несколько экземпляров и как то раскидав через ipfw пакеты между ними.

В виду этих фатальных недостатков интерес со стороны сообщества пропал и я её забросил.

Был человек который превратил это в netgraph ноду, но ложные срабатывания это не вылечило.

Заход 2: ng_utp

Далее проверяется что содержимое UDP пакета похоже на uTP.
Если содержимое похоже то ищем в таблице состояний запись для данной пары хостов: src ip:port / dst ip:port, если не находим то меняем местами и ищем ещё раз. Не нашли и пакет не FIN или RESET — добавляем. (подозреваю что на линухе с conntrack было бы чуть проще, а тут пришлось самому писать)
Теперь есть элемент который хранит все uTP соединения между двумя хостами или то что похоже на них.
Ищем там connid, если не нашли то connid+-1, если опять нет — добавляем.

Действовать имеет смысл только для DATA и STATE пакетов.

Что можно сделать:

ничего, просто мониторинг: есть счётчики по хостам, соединениями, сами таблицы с хостами…
дропать пакеты с uTP: src ip:port + dst ip:port есть
помечать пакеты: на L2 в VLAN заголовке PCP для тегированных пакетов 802.1P
помечать пакеты: на L3 в IP заголовке — ip_tos — DSCP
отправлять uTP — RST пакеты

Подробнее про счётчики — по ссылке, там описание, если его мало есть код 🙂

Сигнатуры

Версия 0

SYN

syn — 14 bytes

‘udp[17] = 2 and udp[18] = 4 and udp[21:2] = 0 and udp[23] = 0 and udp[24] = 8 and udp[25:4] = 0 and udp[29:4] = 0’

41 = udp hdr len (8) + upd pkt data len

upd header included:
‘(udp[4:2] = 41 and udp[25:2] = 0x0204 and udp[29:4] = 0x00000008 and udp[33:4] = 0 and udp[37:4] = 0)’

RESET

rst — 4 bytes

‘udp[17] = 0 and udp[18] = 3’

31 = udp hdr len (8) + upd pkt data len

upd header included:
‘(udp[4:2] = 31 and udp[25:2] = 0x0003)’

Версия 1

SYN

syn — 14 bytes

‘udp[0] & 0x0f = 1 and udp[0] & 0xf0 = 0x40 and udp[1] = 2 and udp[18:2] = 0 and udp[20] = 0 and udp[21] = 8 and udp[22:4] = 0 and udp[26:4] = 0’

(udp[0] & 0x0f = 1 and udp[0] & 0xf0 = 0x40) => udp[0] = 0x41

38 = udp hdr len (8) + upd pkt data len

upd header included:
‘(udp[4:2] = 38 and udp[8:2] = 0x4102 and udp[26:4] = 0x00000008 and udp[30:4] = 0 and udp[34:4] = 0)’

RESET

rst — 4 bytes
‘udp[0] & 0x0f = 1 and udp[0] & 0xf0 = 0x30 and udp[1] = 0’
(udp[0] & 0x0f = 1 and udp[0] & 0xf0 = 0x30) => udp[0] = 0x31)
28 = udp hdr len (8) + upd pkt data len

upd header included:
‘(udp[4:2] = 28 and udp[8:2] = 0x3100)’

Обнаружение фильтрации

Проще всего используя описание протокола реализовать простенький клиент, который будет устанавливать соединение и пытаться отправлять данные.
По сути нужно симулировать установление соединения, и дальше пытаться слать DATA и STATE пакеты в ответ с ext типа ACK.
Дальше один клиент запускается в интернете, другой у себя и смотрим теряются ли пакеты в 100% случаев или может RESET приходят.
Сходным образом при использовать yota некоторые пакеты из l2tp на завершающем этапе согласования пропадают в 100% случаев. Так было ещё в сентябре.

Заключение

2. Производители различных DPI уже давно добавили сигнатуры для uTP, вряд ли им это было трудно сделать.

4. Для IPv6 код не писал, на всякий случай 😉

Автор: Ivan_83

Источник

протокол uTP открыт под лицензией MIT, и первая интеграция этой библиотеки / Habr

Сегодня Bittorrrent а именно разработчики uTorrent открыли свою спецификацию uTP под лицензией MIT/

Исходный код в виде библиотеки написанной на С++ можно скачать на github

А так же была выпущена новая версия KTorrent 4.0

В ней была добавлена библиотека uTP
А так же еще некоторые изменения о которых можно почитать на официальном сайте
Плюсы uTP в том что
* Он динамически себя ограничивает в зависимости от использования интернета другими приложениями на компьютере
* обход некоторых NAT методом STUN
* Если вдруг пакет теряется то протокол увеличивает фрагментацию, начальная фрагментация 300 байт
Некоторые провайдеры говорят что их оборудования слишком перегружено из-за введения uTP, но вы сами подумайте, если вдруг где либо осуществляется фильтрация трафика bittorrent то uTorrent а в скоро и другие клиенты, будут увеличивать фрагментацию пакетов и создавать подобию не слабой DDOS атаки на оборудования, вы скажите, кошмар, ужас.
Но прелесть заключается в том что бы уменьшить нагрузку на оборудования — надо разрешить и не фильтровать трафик.

Те кто не согласен со мной можете отключить uTP в ваших клиентах.

Для того что бы отключить uTP выполните следующее:
В переменной bt.transp_disposition в дополнительных настройках uTorrent поставте нужное вам значение.
1 — разрешить инициировать исходящие TCP-соединения,
2 — разрешить инициировать исходящие uTP-соединения,
4 — разрешить принимать входящие TCP-соединения,
8 — разрешить принимать входящие uTP-соединения

Таким образом, 13 (1+4+8), значение по умолчанию в последних версиях 2.x, означает возможность принимать все виды соединений, но самостоятельно устанавливать только TCP. 15
Кстати теперь uTorrent в зависимости от условий и типов клиента использует как uTP так и стандартный TCP протокол, аналогично Skype…
О том что такое uTP подробней можно почитать тут

Ждем добавления uTP в rTorrent и Transmission !

Кстати они выложили свой uTP в свободный доступ после голосования на их uservoise вот тут
Там есть много интересного за что можно проголосовать, например клиент под Linux, оглавление голосования тут

Применить ограничение к utp соединениям – что это

Все Тут Online > Технический раздел > Полезные программы > Интернет и безопасность > Разгоняем uTorrent, увеличиваем скорость скачивания с торрентов

PDA

Просмотр полной версии : Разгоняем uTorrent, увеличиваем скорость скачивания с торрентов

anatol1961

24.05.2013, 15:42

http://s2.1pic.org/files/2013/05/24/d560afd7f943f691afb4.png (http://1pic.org)

Некоторые провайдеры в целях уменьшения нагрузки на канал вместо
расширения его вступают на скользкий путь — уменьшения приоритета
торрент трафика. Основная масса торрент трафика проходит через uTP
соединения, которые можно отключить и существенно увеличить
скорость загрузки с торрентов.

Итак, Необходимо запретить принимать и инициировать uTP-соединения.
Делается это следующим образом:
Настройка → Конфигурация → Дополнительно →
bt.transp_disposition

Меняем значение на «5».

Подробное описание значений для «интересующихся»:
1 — разрешить инициировать исходящие TCP-соединения,
2 — разрешить инициировать исходящие uTP-соединения
4 — разрешить принимать входящие TCP-соединения
8 — разрешить принимать входящие uTP-соединения
16 — новый uTP заголовок, который поддерживается только с 2.0 (соединений с 1.8 не будет)
13 (1+4+8) — принимать все виды соединений, но самостоятельно устанавливать только TCP.
15 — разрешить все виды как исходящих так и входящих соединений.
5 (1+4) — запретить uTP вообще

Благодарю! Нужная тема.

anatol1961

24.05.2013, 16:00

я знаю, поэтому и создал такую тему. Опять же она нужна только тем кто в теме (типа каламбур) , что прискорбно.

Толя, ну уж не знаю… Если нажать несколько кнопок людям лень, чтобы проверить, то что тут и обсуждать то!

anatol1961

24.05.2013, 16:11

Дима, да я ж не про то. Прискорбно то что люди не хотят учиться ничему. Даже зарегиться где то (на русском языке !!!) — непреодолимая задача, не говоря уже про англоязычные ( не китайские ) ресурсы.
Как привык, то и ладно — ничего новое не интересует. Но это их дело,бог с ними, мое дело предложить… Главное я знаю как мне лучше, и не устану учиться до самой смерти.

Синдикат

24.05.2013, 17:36

Анатолий, отличная тема, сегодня хоть немного наладили инет, завтра настрою попробую.:icon_lex:

Синдикат, надо ровно 3 секунды… значение «5» поставить. Зачем до завтра ждать?

А тех. админ на форуме — самый главный чел, если будешь прислушиваться к его советам, то сэкономишь своё время, деньги и здоровье!

bt.connect_speed — сколько максимум новых соединений можно устанавливать в секунду (можно увеличить),

net.utp_target_delay — пинг при подстройке соединений (можно увеличить),

peer.disconnect_inactive_interval — время в секундах, через сколько закрывается соединение с пиром, с которым нет обмена данными (можно уменьшить), чтобы быстрее определять разрыв соединения и перезапускать его

net.max_halfopen — можно увеличить раза в полтора-два

Можно попробовать запускать саму программу от имени администратора (помогает,когда раздача «краснеет»).

Вообщем… путем подбора дополнительных параметров и использования различных прокси вполне реально разогнать до скорости заявленной провайдером.

anatol1961

25.05.2013, 02:01

Как ни разгоняй отдельно взятую программу — эффекта можно не заметить если предварительно не выполните еще несколько пунктов :

1. максимальное количество одновременных исходящих соединений нужно увеличить. Читать здесь (http://www.vsetutonline.com/forum/showthread.php?t=4954)

2. Повышаем резервную пропускную способность . Читать здесь (http://www.vsetutonline.com/forum/showpost.php?p=122382&postcount=85)

3. С помощью Auslogics BoostSpeed (http://www.vsetutonline.com/forum/showthread.php?t=41188&page=2&highlight=Auslogics+BoostSpeed) выполняем Ускорение интернета-Автоматическое (для тех кто это не сделал руками по информации из пункта 2. по команде regedit.exe )
Сделать проверку системы в Auslogics BoostSpeed тоже не будет лишним.

Всем успеха! Надеюсь что моя информация кому то пригодится.

Если все инструкции выполнить, то для 100 мегабитного тарифа скорость должна быть около ~ 12.3 мб/с и она должна быть стабильна при наличии сидов.

То есть так:

http://i48.fastpic.ru/big/2013/0525/ff/35b8973ffdaee9ebdba2e14e8c790cff.png (http://i47.fastpic.ru/big/2013/0525/53/c4cc860698ec2bea34a5764969bc7d53.jpg)

Отсюда легко посчитать для любого другого тарифа.

Роутер, как только не настраивал, все равно режет 0.5-1 мб/с, ну и все провода, я после мастеров от провайдера поменял естественно, как впрочем и антенный кабель и заземление к аппаратуре и быт. приборам..

Толя, я не знаю как ещё привлечь наших форумчан к чтению тех. раздела. :icon_dunno:

Музыку качественную из раздела винила тоже не хотят скачивать! Я просто офигиваю, когда читаю, что сжимают!

Из одного из центровых релизов нашего форума «Сборник оцифровок с пластов на 78 оборотов 24/48000 Lossless»

дима привет превратить этот шедевр в мп-3 сколько ставить на конвертирование 192 или 256 ответь спасибо

Федор_Чистяков, ни в коем случае не превращать в mp3 и ни в коем случае не перводить в 16.44,1 Обломаешь cебе весь кайф!
Это не тот случай, когда всё равно! Я бы и сам переконвертировал, чтобы побыстрому закинуть на форум, если б это напрочь не погубило бы всю музыку в релизе!

Федор_Чистяков, если будешь переводить из 24 в 16 bit и не использовать дизеринг, то музыка в тихих местах просто исчезнет! Надо пользоваться исходным музыкальным материалом.

Может тогда не заливать, уделить большее внимание CD по дискографиям? Всё ремастированное под бумбоксы может пойти в ход, раз уж такое дело! Например, CD-диски японцы со звонким звучанием, как раз для русских ушей.

anatol1961

25.05.2013, 03:28

Во всех роутерах есть потери. Но есть и плюсы от его применения. У меня заявленная провайдером скорость 50 мбит , стоит ZyXel Keenetic Lite к нему проводом подключен один комп, второй через WI-FI . Если включить закачку на двух компа одновременно — скорость приема на каждом 50-60 мбит. При этом еще ребенка подключает айфон по WI-FI и не жалуется на недостаток скорости.

Может тогда не заливать, уделить большее внимание CD

Да просто уже переизбыток инфы со многих источников — естественно происходит спад интереса.

Синдикат

25.05.2013, 03:34

Дмитрий
надо ровно 3 секунды… значение «5» поставить. Зачем до завтра ждать?
Дмитрий, мне не трудно поставить все значения. просто еще не отремонтировали полностью линию, не стабильная связь.
Может даже придется сменить провайдера, прошла неделя и результат ноль, не хотят работать, только гребут бабло.
Буду готовить письмо ген директору Телекома.
Это сработает.

anatol1961, модель роутера очень хорошая, но оперативки 32 mb. У товарища был такой инет отваливался с ним регулярно, так и не разобрались почему, скорей всего из-за провайдера тип подключения IP-o- E.

Синдикат, конечно надо менять, раз такое отношение к клиенту, который ему ежемесячно платит!
Если есть альтернативный провайдер, то как только, так сразу!

anatol1961

25.05.2013, 03:52

не знаю, что там было, может сам девайс бракованный попался. мой экземпляр без нареканий работает, я ему сразу прошивку обновил на новую (два года назад ) и больше не прикасаюсь. Один раз только сбой был (выходящий ip сам поменял для wi-fi ) из-за отключения электричества и все.

Вот статейку сейчас ещё нашёл, возможно пригодится…

Тонкая настройка BitTorrent-клиента [максимальная скорость, настройка портов и решение проблем] (http://sonikelf.ru/tonkaya-nastrojka-bittorrent-klienta-maksimalnaya-skorost-nastrojka-portov-i-reshenie-problem/)

В статье дана таблица по которой основные настройки можно поменять, в соответствии с типом соединения и скоростью.

Дополнительные настройки как у автора статьи трогать … всё чисто индивидуально, надо подбирать.

bt.transp_disposition = 5
И запрет на uTP-соединения

это всё пока что, по дополнительным.

Я бы не стал ставить дополнительные, как у автора статьи. Экспериментируйте…

anatol1961, скорей всего брак, он самопроизвольно перезагружаться стал через 3 недели после установки, а так Китай рулит и цены нормальные! Вспомнил… ещё вонял он какой-то гадостью сильно. ))

anatol1961

25.05.2013, 07:11

anatol1961, Китай рулит и цены нормальные! Вспомнил… ещё вонял он какой-то гадостью сильно. ))

Может ты перепутал чего, не вонял он ни разу у меня /
Вот такой (http://market.yandex.ru/model.xml?hid=723087&modelid=6515903&clid=502) у меня

anatol1961, да я не перепутал, наверно просто бракованный попался.
Желаю тебе, чтобы твой долго проработал! :icon_drinks:

anatol1961

25.05.2013, 09:00

Зная тягу китайцев к подделке всего — от иголки до самолета, уже ничему не удивляешься…

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

Новый протокол uTP в µTorrent 2.0 создал проблемы для провайдеров и пользователей: rednyrg721 — LiveJournal

«Во второй версии торрент-клиента µTorrent была официально добавлена поддержка протокола uTP. Среди преимуществ протокола был заявлен более быстрый обмен файлами за счёт перехода на протокол UDP и, как следствие этого, уменьшение нагрузки на оборудование провайдеров и участников файлового обмена. Но, к сожалению, из-за плохой реализации работы протокола всё произошло наоборот, нагрузка на сетевое оборудование не уменьшилась, а увеличилась.
Увеличение нагрузки заметили как интернет-провайдеры, так и обычные пользователи торрент-клиента. Причиной возросшей нагрузки на оборудование стал малый размер пакетов (до 150 байт), передаваемых торрент-клиентом, вызвавший рост PPS (Packets Per Second) в 1,5-2 раза. В данный момент для снижения нагрузки интернет-провайдеры блокируют работу протокола uTP, заставляя µTorrent использовать для своей работы TCP-, а не UDP-соединения между пирами.
Для отключения протокола uTP в своём торрент-клиенте вам необходимо выставить параметр bt.transp_disposition в значение 5 в расширенных настройках клиента.»

Отсюда. Ещё на тему. Ещё.

Интересная получается штука — создатели популярной программы могут поставить на колени пол-интернета. А ответственности, как таковой, у них и нет ни перед кем (да и полных спецификаций протокола нету в открытом доступе даже вроде как). В 2008 году была паническая статейка на тему (оригинал, продолжение), но автора её засмеяли. А оказывается, он в чём-то прав был )

Пара-тройка цитат из обсуждения на форуме провайдеров (http://forum.nag.ru/forum/index.php?showtopic=55025):
«А можно ли расценивать действия разработчиков как попытку DDoS атаки и инкриминировать 272 статью УК РФ?
Создать хотя бы прецедент, дабы люди сначала думали, а потом уже делали, осознавая всю ответственность.»
«Согласен. Самое дурное в этой ситуации — то, что в открытом доступе даже нет полного описания этого uTP.»
«Да, и еще раз да.
Торент клиент сознательно формирует дос на шейп, цель загрузить его под завязку.»
«Проблема то в том, что поведение носит характер DDoS атак на провайдерское оборудование. И если у провайдеров покрупнее оборудование переваривает неглядя, то у других, данное поведение может вызывать очень большие осложнения во всей сети. Т.е. работа отдельно взятой программы может стать причиной неработоспособности целой сети. И, откровенно говоря, не всякий провайдер сможет оперативно отреагировать на возникшую проблему — заменить те же серверы доступа/роутеры на высокопроизводительные не всем по карману. Особенно если речь идет о небольших провайдерах, работающих в масштабах маленьких городов и поселков.
С другой стороны — чем больше волнений на эту тему будет, тем быстрее (покрайней мере очень надеюсь на это) разработчики исправят данный недочет в своем ПО.
Есть еще один момент в данном вопросе, о котором многие забывают. Даже если провайдерское оборудование переваривает сие издевательство не моргнув и глазом, то есть такие зловещие девайсы как «бытовые роутеры» в том числе с wifi на борту, которые буквально таки помирают под натиском пакетной нагрузки (http://vilianov.habrahabr.ru/blog/84111/). А пользователи зачастую валят все на провайдеров, не понимая, что сами являются виноватыми в том что их роутеры перестают работать.»

UPD 13.03 Подробный пост на тему с предысторией и кучей технических подробностей.

Фильтрация uTP (Torrent UDP) внутри PPTP GRE: nuclight — LiveJournal

Краткое содержание: как отфильтровать uTP на FreeBSD в теме на Наге уже сказали, однако для случая пакетов внутри туннеля PPTP GRE решения не было, о чем здесь и будет рассказано, но сначала — предыстория.

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

В конце 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 байт…

Но хватит о грустном. Решение для обычного не-туннельного уже применяют, теперь пришла пора сделать для случая PPTP.

Составим выражение для tcpdump…

В предыдущем посте я описывал принципы работы BPF. Когда увидел в теме на Наге просьбу аналога для PPTP, вспомнил, что у меня же была похожая задача, там же и описана. В самом деле, там искалось DHT, здесь просто другая сигнатура. Итак, назовём файл tcpdump-gre-utp-cpp и поправим:

#define IPHDRLEN(firstbyte) ((ip[firstbyte]&0xf)<<2)
#define GRESTART IPHDRLEN(0)
/* Check that is GREv1 with seq num and proto set per RFC 2637 */
#define VALID_PPTP_GRE ((ip[GRESTART:4] & 0xff7fffff) = 0x3001880b)
/* ACK is optional 4 bytes to previous 12 */
#define GRE_DATA_START (GRESTART + ((ip[GRESTART+1] & 0x80) >> 5) + 12)
/* Actual IP byte values to find in the UDP payload of inner IP datagram */
#define IS_TORRENT_UTP(udp_hdr_start)   (ip[(udp_hdr_start+20):4]=0x7fffffff)
/* Check inner IP has UDP payload (proto 17) then calculate offset and pass it to UTP macro */
#define INNER_IS_UDP(ppp_hdr_len)       (ip[GRE_DATA_START+ppp_hdr_len+9]=17)
#define INNER_UDP_OFFSET(ppp_hdr_len)   (GRE_DATA_START+ppp_hdr_len+IPHDRLEN(GRE_DATA_START+ppp_hdr_len))
#define INNER_IS_UTP(ppp_hdr_len)       (INNER_IS_UDP(ppp_hdr_len) and IS_TORRENT_UTP(INNER_UDP_OFFSET(ppp_hdr_len)))

/*
 * Finally, expression: sort by most frequent pattern first.
 * We check four possible PPP headers corresponding to IP, then
 * pass length of matched PPP header to checking macros.
 */
proto gre and VALID_PPTP_GRE and (
        (
                (ip[GRE_DATA_START]=0x21) and INNER_IS_UTP(1)
        ) or (
                (ip[GRE_DATA_START:2]=0xff03) and (ip[GRE_DATA_START+2]=0x21) and INNER_IS_UTP(3)
        ) or (
                (ip[GRE_DATA_START:4]=0xff030021) and INNER_IS_UTP(4)
        ) or (
                (ip[GRE_DATA_START:2]=0x0021) and INNER_IS_UTP(2)
        )
)

Засунем это дело в скрипт из предыдущего поста, и…

…и обламываемся

Не работает. Не матчит. Запуск tcpdump -Xs 0 -ni em0 `cpp -P tcpdump-gre-utp-cpp` тоже молчит. Значит, дело не в ng_bpf. Заменяю в итоговом выражении UTP на UDP — начинает ловить все UDP-пакеты в туннеле. Ага, значит дело в финальной части выражения. Делаю тестовый пакет, выкусываю комментариями лишние ветки — всё равно не матчит. Начинаю смотреть в tcpdump -d — там теперь всего 70 с небольшим инструкций, это уже поддается анализу человеком. Ага, таки да — обнаружен баг, tcpdump генерирует неверный код. Отправил баг-репорт (см. kern/144325), но эта бага практически наверняка есть и на линуксе — проект tcpdump отдельный…

Придется писать вручную
Что ж, придется применить знания по ассемблеру BPF и заняться тяжелым ручным трудом. Правда, имея перед глазами файл для препроцессора, перевести несколько проще, даже применяя оптимизации. Примерно 4 часа работы, включая отладку, и вот что получилось:

bpf_prog_len=36 bpf_prog=[
{ code=177 jt=0 jf=0 k=0 }          BPF_LDX+BPF_B+BPF_MSH   X <- 4*(P[k:1]&0xf)      ; X <- outer IP hdr length
{ code=64 jt=0 jf=0 k=0 }           BPF_LD+BPF_W+BPF_IND    A <- P[X+k:4]
{ code=84 jt=0 jf=0 k=0xff7fffff }  BPF_ALU+BPF_AND+BPF_K   A <- A & k
{ code=21 jt=0 jf=31 k=0x3001880b } BPF_JMP+BPF_JEQ+BPF_K   pc += (A == k) ? jt : jf ; not VALID_PPTP_GRE, exit
{ code=80 jt=0 jf=0 k=1 }           BPF_LD+BPF_B+BPF_IND    A <- P[X+k:1]            ; begin calc GRE hdr length
{ code=84 jt=0 jf=0 k=0x80 }        BPF_ALU+BPF_AND+BPF_K   A <- A & k
{ code=116 jt=0 jf=0 k=5 }          BPF_ALU+BPF_RSH+BPF_K   A <- A >> k
{ code=4 jt=0 jf=0 k=12 }           BPF_ALU+BPF_ADD+BPF_K   A <- A + k
{ code=12 jt=0 jf=0 k=0 }           BPF_ALU+BPF_ADD+BPF_X   A <- A + X               ; now A = GRE_DATA_START
{ code=7 jt=0 jf=0 k=0 }            BPF_MISC+BPF_TAX        X <- A
{ code=72 jt=0 jf=0 k=0 }           BPF_LD+BPF_H+BPF_IND    A <- P[X+k:2]
{ code=21 jt=0 jf=

Utp протокол – Основы компьютерных сетей. Тема №3. Протоколы нижних уровней (транспортного, сетевого и канального)

что это, как, зачем? / Habr

Torrent/uTP — о протоколе и самодельных DPI / СоХабр

Жизнь с uTP

Протокол uTP

Версия 0

Версия 1

Типы пакетов

Шифрование

Заход 1: uTPControl

Заход 2: ng_utp

Сигнатуры

Версия 0

SYN

RESET

Версия 1

SYN

RESET

Обнаружение фильтрации

Заключение

Torrent-uTP — о протоколе и самодельных DPI

Жизнь с uTP

Протокол uTP

Версия 0

Версия 1

Типы пакетов

Шифрование

Заход 1: uTPControl

Заход 2: ng_utp

Сигнатуры

Версия 0

SYN

RESET

Версия 1

SYN

RESET

Обнаружение фильтрации

Заключение

протокол uTP открыт под лицензией MIT, и первая интеграция этой библиотеки / Habr

А так же была выпущена новая версия KTorrent 4.0

Те кто не согласен со мной можете отключить uTP в ваших клиентах.

Ждем добавления uTP в rTorrent и Transmission !

Применить ограничение к utp соединениям – что это

Новый протокол uTP в µTorrent 2.0 создал проблемы для провайдеров и пользователей: rednyrg721 — LiveJournal

Фильтрация uTP (Torrent UDP) внутри PPTP GRE: nuclight — LiveJournal

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

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

Составим выражение для tcpdump…

…и обламываемся

Добавить комментарий Отменить ответ