BT9G LABS / DHT Deep Dive #04

InfoHash в деталях: BitTorrent v1, v2, Magnet, BTIH и BTMH

Как вычисляются идентификаторы BitTorrent-контента и как v1/v2 представлены в Magnet links через BTIH и BTMH.

BT9G LabsОпубликовано 3 мин чтения

BT9G Labs / DHT Deep Dive #04. Разбираем границу идентичности Torrent и архитектурные последствия поддержки SHA-1, SHA-256 и hybrid torrent.

InfoHash в деталях: BitTorrent v1, v2, Magnet, BTIH и BTMH

Краткое резюме

  • Тема: InfoHash в деталях: BitTorrent v1, v2, Magnet, BTIH и BTMH
  • Ключевые слова: InfoHash, BitTorrent v1, BitTorrent v2, BTIH, BTMH
  • Для кого: backend-разработчики, исследователи протоколов, инженеры поисковых систем и разработчики BitTorrent-клиентов
  • Цель: Объяснить механизм достаточно точно, чтобы на его основе можно было принимать реальные архитектурные решения для краулинга, индексации и поиска.

Системная схема

Идентичность задает info dictionary

В BitTorrent v1 InfoHash — это SHA-1 от исходного bencoded info dictionary, а не от всего .torrent файла. Поля вроде комментариев или списка Tracker могут меняться без изменения InfoHash, если сам info остается тем же.

Индексатору важно не пересериализовать структуру неосторожно: изменив байтовое представление info, можно получить другой хеш даже при логически похожих данных.

v1/BTIH и v2/BTMH

Классический v1 использует 20-байтовый SHA-1 и в Magnet обычно представлен urn:btih. v2 по BEP 52 использует SHA-256, Merkle tree и multihash-представление urn:btmh. Существуют и hybrid torrent, совместимые с двумя поколениями.

Поэтому модель данных не должна предполагать, что любой идентификатор — это просто 40 hex-символов. Лучше хранить namespace/версию, алгоритм и нормализованное бинарное значение отдельно.

Что это меняет в поисковом индексе

Content identity лежит в основе deduplication, проверки Metadata, маршрутов detail page и объединения наблюдений из разных источников. Tracker, DHT activity и Peer endpoints должны присоединяться к сущности контента как наблюдения, а не менять сам идентификатор.

Такой подход дает возможность поддержать v1, v2 и hybrid без хака по длине строки и безопасно развивать схему позже.

Эскиз реализации

import hashlib

def v1_infohash(raw_bencoded_info: bytes) -> bytes:
    return hashlib.sha1(raw_bencoded_info).digest()

def v2_infohash(raw_bencoded_info: bytes) -> bytes:
    return hashlib.sha256(raw_bencoded_info).digest()

Инженерные заметки BT9G Labs

Для индексатора уровня BT9G важнее не максимальное число событий, а правильное разделение идентичности контента, краткоживущих сетевых наблюдений, состояния сбора и поискового представления. Поля, полученные из DHT или от Peer, должны иметь источник и временную метку. Метрики стоит вести по этапам: discovery, соединение, handshake, поддержка расширений, получение Metadata, проверка, сохранение и индексация. Это позволяет видеть реальное узкое место системы, а не списывать все неудачи на «нестабильную сеть».

Типичные ошибки

  • Хешировать весь .torrent вместо исходного info dictionary для v1.
  • Считать hex-регистр разными ресурсами.
  • Предполагать только 20-байтовый SHA-1.
  • Не проектировать схему под v2 и hybrid torrent.

Связанные статьи BT9G Labs

Источники

Следующая статья: BEP 5: ping, find_node, get_peers и announce_peer на уровне DHT-сообщений →

Материал описывает публичное поведение протоколов BitTorrent для инженерных и исследовательских целей и не означает, что любой наблюдаемый Swarm доступен, корректен или разрешен к распространению.