В I2P существует несколько BitTorrent-клиентов и трекеров. Поскольку адресация I2P использует Destination вместо IP-адреса и порта, для работы трекеров и клиентского программного обеспечения в I2P требуются незначительные изменения. Эти изменения описаны ниже. Обратите особое внимание на рекомендации по совместимости со старыми I2P-клиентами и трекерами.
Эта страница определяет детали протокола, общие для всех клиентов и трекеров. Конкретные клиенты и трекеры могут реализовывать другие уникальные функции или протоколы.
Мы приветствуем дополнительные порты клиентского и tracker-программного обеспечения для I2P.
Общее руководство для разработчиков
Большинство не-Java bittorrent клиентов будут подключаться к I2P через SAMv3 . SAM сессии (или внутри I2P, пулы туннелей или наборы tunnel) предназначены для длительного использования. Большинству bittorrent клиентов потребуется только одна сессия, созданная при запуске и закрытая при выходе. I2P отличается от Tor, где circuits могут быстро создаваться и удаляться. Тщательно продумайте и проконсультируйтесь с разработчиками I2P, прежде чем проектировать ваше приложение для использования более одной или двух одновременных сессий, или для их быстрого создания и удаления. Bittorrent клиенты не должны создавать уникальную сессию для каждого соединения. Спроектируйте ваш клиент так, чтобы использовать одну и ту же сессию для анонсов и клиентских соединений.
Также убедитесь, что настройки вашего клиента (и рекомендации пользователям по настройкам router’а, или настройки router’а по умолчанию, если вы поставляете router в комплекте) приведут к тому, что ваши пользователи будут вносить в сеть больше ресурсов, чем потреблять. I2P — это одноранговая сеть, и сеть не сможет выжить, если популярное приложение приведет сеть к постоянной перегрузке.
Не предоставляйте поддержку bittorrent через I2P outproxy в clearnet, так как это, вероятно, будет заблокировано. Обратитесь к операторам outproxy за советом.
Реализации Java I2P и i2pd router являются независимыми и имеют незначительные различия в поведении, поддержке функций и настройках по умолчанию. Пожалуйста, протестируйте ваше приложение с последними версиями обоих router.
i2pd SAM включён по умолчанию; Java I2P SAM — нет. Предоставьте пользователям инструкции о том, как включить SAM в Java I2P (через /configclients в консоли router), и/или выдавайте пользователю понятное сообщение об ошибке при неудачном первоначальном подключении, например: “убедитесь, что I2P запущен и интерфейс SAM включён”.
Java I2P и i2pd router имеют разные значения по умолчанию для количества tunnel. Значение по умолчанию для Java составляет 2, а для i2pd — 5. Для большинства случаев с низкой и средней пропускной способностью и низким или средним количеством подключений достаточно 3. Пожалуйста, укажите количество tunnel в сообщении SESSION CREATE для получения стабильной производительности с Java I2P и i2pd router.
I2P поддерживает множество типов подписей и шифрования. Для совместимости I2P по умолчанию использует старые и неэффективные типы, поэтому все клиенты должны указывать более новые типы.
При использовании SAM тип подписи указывается в командах DEST GENERATE и SESSION CREATE (для временных). Все клиенты должны устанавливать SIGNATURE_TYPE=7 (Ed25519).
Тип шифрования указывается в команде SAM SESSION CREATE или в опциях i2cp. Допускается использование нескольких типов шифрования. Некоторые трекеры поддерживают ECIES-X25519, некоторые поддерживают ElGamal, а некоторые поддерживают оба типа. Клиенты должны устанавливать i2cp.leaseSetEncType=4,0 (для ECIES-X25519 и ElGamal), чтобы иметь возможность подключаться к обоим типам.
Поддержка DHT требует SAMv3.3 PRIMARY и SUBSESSIONS для TCP и UDP в рамках одной сессии. Это потребует значительных усилий по разработке на стороне клиента, если только клиент не написан на Java. i2pd в настоящее время не поддерживает SAMv3.3. libtorrent в настоящее время не поддерживает SAMv3.3.
Без поддержки DHT вы можете захотеть автоматически объявляться в настраиваемом списке известных открытых трекеров, чтобы магнет-ссылки работали. Проконсультируйтесь с пользователями I2P для получения информации о работающих в данный момент открытых трекерах и поддерживайте ваши настройки по умолчанию актуальными. Поддержка расширения i2p_pex также поможет компенсировать отсутствие поддержки DHT.
Для получения дополнительных рекомендаций разработчикам по обеспечению использования приложением только необходимых ресурсов, пожалуйста, ознакомьтесь со спецификацией SAMv3 и нашим руководством по встраиванию I2P в ваше приложение . Свяжитесь с разработчиками I2P или i2pd для получения дальнейшей помощи.
Объявления
Клиенты обычно включают поддельный параметр port=6881 в announce для совместимости со старыми трекерами. Трекеры могут игнорировать параметр port и не должны требовать его.
Параметр ip представляет собой base 64 кодировку Destination клиента, используя алфавит I2P Base 64 [A-Z][a-z][0-9]-~. Destinations имеют размер 387+ байт, поэтому Base 64 составляет 516+ байт. Клиенты обычно добавляют “.i2p” к Base 64 Destination для совместимости со старыми трекерами. Трекеры не должны требовать добавления “.i2p”.
Другие параметры такие же, как в стандартном bittorrent.
Текущие Destination для клиентов составляют 387 или более байт (516 или более в кодировке Base 64). Разумный максимум, который можно предположить на данный момент, составляет 475 байт. Поскольку трекер должен декодировать Base64 для предоставления компактных ответов (см. ниже), трекер, вероятно, должен декодировать и отклонять некорректный Base64 при анонсировании.
Тип ответа по умолчанию — не компактный. Клиенты могут запросить компактный ответ с параметром compact=1. Трекер может, но не обязан, возвращать компактный ответ при запросе. Примечание: Все популярные трекеры теперь поддерживают компактные ответы, и как минимум один требует compact=1 в announce. Все клиенты должны запрашивать и поддерживать компактные ответы.
Разработчикам новых I2P-клиентов настоятельно рекомендуется реализовать анонсы через собственный tunnel, а не через HTTP-прокси клиента на порту 4444. Это более эффективно и позволяет tracker’у применять принуждение по destination (см. ниже).
Спецификация для UDP-анонсов была финализирована в 2025-06. Поддержка в различных I2P клиентах и трекерах будет внедряться позже в 2025 году. См. дополнительную информацию ниже.
Некомпактные ответы трекера
Примечание: Устарело. Все популярные трекеры теперь поддерживают компактные ответы, и как минимум один требует compact=1 в announce. Все клиенты должны запрашивать и поддерживать компактные ответы.
Неcompact-ответ точно такой же, как в стандартном bittorrent, с I2P “ip”. Это длинная base64-кодированная “DNS-строка”, вероятно с суффиксом “.i2p”.
Трекеры обычно включают поддельный ключ порта или используют порт из announce для совместимости со старыми клиентами. Клиенты должны игнорировать параметр порта и не должны требовать его наличия.
Значение ключа ip представляет собой base 64 от Destination клиента, как описано выше. Трекеры обычно добавляют “.i2p” к Base 64 Destination, если он не был указан в announce ip, для совместимости с более старыми клиентами. Клиенты не должны требовать добавленного “.i2p” в ответах.
Другие ключи и значения ответа такие же, как в стандартном bittorrent.
Компактные ответы трекера
В компактном ответе значение ключа словаря “peers” представляет собой одну строку байтов, длина которой кратна 32 байтам. Эта строка содержит объединённые 32-байтные SHA-256 хеши бинарных Destinations пиров. Этот хеш должен быть вычислен трекером, если только не используется принуждение destination (см. ниже), в этом случае хеш, переданный в HTTP заголовках X-I2P-DestHash или X-I2P-DestB32, может быть преобразован в бинарный формат и сохранён. Ключ peers может отсутствовать, или значение peers может иметь нулевую длину.
Хотя поддержка компактных ответов является необязательной как для клиентов, так и для трекеров, она настоятельно рекомендуется, поскольку уменьшает номинальный размер ответа более чем на 90%.
Принуждение назначения
Некоторые, но не все, I2P BitTorrent клиенты анонсируют через свои собственные tunnel. Tracker могут выбрать предотвращение спуфинга, требуя этого и проверяя Destination клиента, используя HTTP заголовки, добавленные I2PTunnel HTTP Server tunnel. Заголовки — это X-I2P-DestHash, X-I2P-DestB64 и X-I2P-DestB32, которые представляют разные форматы для одной и той же информации. Эти заголовки не могут быть подделаны клиентом. Tracker, проверяющий destination, может вообще не требовать параметр ip announce.
Поскольку несколько клиентов используют HTTP-прокси вместо собственного tunnel для объявлений, принудительная проверка назначения предотвратит их использование этими клиентами до тех пор, пока эти клиенты не будут переведены на объявления через собственный tunnel.
К сожалению, по мере роста сети будет расти и количество злонамеренных действий, поэтому мы ожидаем, что все трекеры в конечном итоге будут принудительно проверять назначения. Разработчики как трекеров, так и клиентов должны это предвидеть.
Объявление имён хостов
Имена хостов в URL анонсов в torrent-файлах обычно следуют стандартам именования I2P . В дополнение к именам хостов из адресных книг и именам хостов “.b32.i2p” в формате Base 32, должны поддерживаться полные Destination в формате Base 64 (с добавлением “.i2p” или без него). Закрытые трекеры должны распознавать свое собственное имя хоста в любом из этих форматов.
Для сохранения анонимности клиенты должны обычно игнорировать не-I2P URL-адреса объявлений в торрент-файлах.
Клиентские подключения
Соединения между клиентами используют стандартный протокол через TCP. В настоящее время не известно клиентов I2P, которые поддерживают связь через uTP.
I2P использует Destinations размером 387+ байт для адресов, как объяснено выше.
Если клиент имеет только хеш назначения (например, из компактного ответа или PEX), он должен выполнить поиск, закодировав его с помощью Base 32, добавив “.b32.i2p” и запросив службу именования, которая вернет полное назначение, если оно доступно.
Если клиент имеет полный Destination узла, который он получил в неуплотненном ответе, он должен использовать его напрямую при установке соединения. Не преобразуйте Destination обратно в Base 32 хеш для поиска, это весьма неэффективно.
Предотвращение межсетевого взаимодействия
Для сохранения анонимности I2P bittorrent-клиенты обычно не поддерживают анонсы или peer-соединения вне I2P. I2P HTTP outproxy-серверы часто блокируют анонсы. Неизвестно о SOCKS outproxy-серверах, поддерживающих bittorrent-трафик.
Для предотвращения использования не-I2P клиентами через HTTP inproxy, I2P трекеры часто блокируют доступы или анонсы, содержащие HTTP заголовок X-Forwarded-For. Трекеры должны отклонять стандартные сетевые анонсы с IPv4 или IPv6 IP-адресами и не передавать их в ответах.
PEX
I2P PEX основан на ut_pex. Поскольку формальная спецификация ut_pex, по-видимому, недоступна, может потребоваться обратиться к исходному коду libtorrent за помощью. Это сообщение расширения, идентифицируемое как “i2p_pex” в рукопожатии расширения . Оно содержит bencoded словарь с до 3 ключами: “added”, “added.f” и “dropped”. Значения added и dropped представляют собой по одной байтовой строке, длина которых кратна 32 байтам. Эти байтовые строки являются объединенными SHA-256 хешами бинарных Destinations пиров. Это тот же формат, что и значение словаря peers в компактном формате ответа i2p, указанном выше. Значение added.f, если присутствует, такое же, как в ut_pex.
DHT
Поддержка DHT включена в клиент i2psnark начиная с версии 0.9.2. Предварительные отличия от BEP 5 описаны ниже и могут быть изменены. Свяжитесь с разработчиками I2P, если вы хотите разработать клиент с поддержкой DHT.
В отличие от стандартной DHT, I2P DHT не использует бит в рукопожатии опций или сообщение PORT. Она объявляется с помощью сообщения расширения, идентифицируемого как “i2p_dht” в рукопожатии расширений . Оно содержит bencoded словарь с двумя ключами, “port” и “rport”, оба целые числа.
UDP (датаграммный) порт, указанный в компактной информации о узле, используется для получения датаграмм с возможностью ответа (подписанных). Это используется для запросов, за исключением объявлений. Мы называем это “портом запросов”. Это значение “port” из сообщения расширения. Запросы используют I2CP протокол номер 17.
В дополнение к этому UDP порту мы используем второй порт для датаграмм, равный порту запросов + 1. Он используется для получения неподписанных (необработанных) датаграмм для ответов, ошибок и объявлений. Этот порт обеспечивает повышенную эффективность, поскольку ответы содержат токены, отправленные в запросе, и не нуждаются в подписи. Мы называем его “портом ответов”. Это значение “rport” из сообщения расширения. Оно должно равняться порту запросов + 1. Ответы и объявления используют протокол I2CP номер 18.
Компактная информация о peer составляет 32 байта (32-байтный SHA256 Hash) вместо 4 байта IP + 2 байта порта. Порт peer отсутствует. В ответе ключ “values” представляет собой список строк, каждая из которых содержит одну компактную информацию о peer.
Компактная информация о узле составляет 54 байта (20-байтовый Node ID + 32-байтовый SHA256 Hash + 2-байтовый порт) вместо 20-байтового Node ID + 4-байтового IP + 2-байтового порта. В ответе ключ “nodes” представляет собой одну байтовую строку с объединенной компактной информацией о узлах.
Требование к безопасному идентификатору узла: Чтобы усложнить различные атаки на DHT, первые 4 байта идентификатора узла должны совпадать с первыми 4 байтами хеша назначения, а следующие два байта идентификатора узла должны совпадать со следующими двумя байтами хеша назначения, исключительно ИЛИ-связанными с портом.
В torrent-файле ключ “nodes” словаря trackerless torrent пока не определен. Это может быть список 32-байтовых бинарных строк (SHA256-хеши) вместо списка списков, содержащих строку хоста и целое число порта. Альтернативы: одна байтовая строка с объединенными хешами или просто список строк.
Трекеры датаграмм (UDP)
Спецификация для UDP announce в I2P была завершена в 2025-06. Поддержка в различных I2P клиентах и трекерах будет развертываться в течение 2025 года. Отличия от BEP 15 документированы в спецификации UDP announce . Спецификация также требует поддержки новых форматов Datagram 2/3 .
Дополнительная информация
- Стандарты I2P bittorrent обычно обсуждаются на zzz.i2p .
- Таблица возможностей текущего программного обеспечения трекеров также доступна там .
- FAQ по I2P bittorrent
- Обсуждение DHT на I2P