BT9G LABS / DHT chuyên sâu #04

InfoHash Chuyên Sâu: BitTorrent v1, v2, Magnet Link, BTIH Và BTMH

Tìm hiểu cách hình thành InfoHash trong BitTorrent v1 và v2, sự khác biệt giữa BTIH và BTMH, cùng tác động tới magnet link và indexing.

BT9G LabsXuất bản 4 phút đọc

BT9G Labs / DHT Deep Dive #04. InfoHash là định danh mật mã của metadata Torrent, vì vậy cách tính và lưu trữ chính xác rất quan trọng đối với search engine.

InfoHash Chuyên Sâu: BitTorrent v1, v2, Magnet Link, BTIH Và BTMH

Tóm tắt nhanh

  • Chủ đề: InfoHash Chuyên Sâu: BitTorrent v1, v2, Magnet Link, BTIH Và BTMH
  • Từ khóa chính: InfoHash, BTIH, BTMH, BitTorrent v1, BitTorrent v2, magnet link
  • Đối tượng đọc: kỹ sư backend, người nghiên cứu giao thức, search engineer và nhà phát triển BitTorrent
  • Mục tiêu: Giải thích giao thức và thiết kế hệ thống đủ chính xác để áp dụng vào pipeline discovery, metadata, indexing và search trong thực tế.

Góc nhìn hệ thống

Info dictionary là ranh giới định danh

Trong file .torrent, phần info xác định danh tính của Torrent. Hash được tính trên biểu diễn bencoded chính xác, không phải tên hiển thị hay JSON đã parse. Một thay đổi byte có ý nghĩa trong info dictionary sẽ tạo ra định danh khác.

Parser không nên parse rồi serialize lại theo format khác để tính hash. Tốt hơn là giữ raw info bytes hoặc một phương pháp đảm bảo việc verify luôn dựa trên payload gốc.

v1 và namespace BTIH

BitTorrent v1 dùng SHA-1 trên bencoded info dictionary, tạo ra giá trị 20 byte. Magnet link cổ điển biểu diễn nó bằng xt=urn:btih:..., thường ở dạng hex hoặc Base32.

Nhiều hệ thống cũ dùng chuỗi hex 40 ký tự làm primary key. Điều này tiện cho v1 nhưng không nên trở thành giả định cứng cho mọi version BitTorrent.

v2, SHA-256 và BTMH

BitTorrent v2 dùng SHA-256 và Merkle structure để xác minh nội dung. Magnet mới có thể dùng multihash qua namespace BTMH. Hybrid Torrent có thể đồng thời hỗ trợ v1 và v2, vì vậy cùng một publication có thể liên quan tới nhiều định danh hợp lệ.

Database nên lưu loại hash và algorithm một cách tường minh thay vì chỉ có CHAR(40).

Tác động tới indexing

Canonical identity, magnet representation, raw metadata và search document nên là các lớp khác nhau. Khi ingest, metadata phải được hash lại theo đúng version và so với target trước khi đánh dấu là valid.

Nếu hỗ trợ v1, v2 và hybrid, hãy liên kết các identity có quan hệ mà không gộp nhầm. Tên file giống nhau không phải là bằng chứng hai Torrent có cùng nội dung.

Phác thảo triển khai

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()

Ghi chú kỹ thuật từ BT9G Labs

Với một hệ thống lập chỉ mục như BT9G, số lượng packet hoặc InfoHash nhìn thấy không phải là thước đo quan trọng duy nhất. Nên tách rõ danh tính nội dung, quan sát mạng, trạng thái thu thập, metadata đã xác minh và search document thành các lớp dữ liệu riêng. Mọi dữ liệu đến từ DHT hoặc Peer nên có nguồn và timestamp. Khi đó có thể theo dõi bottleneck ở từng giai đoạn: discovery, kết nối, handshake, extension negotiation, metadata transfer, verification, lưu trữ và indexing.

Sai lầm thường gặp

  • Tính InfoHash từ JSON đã parse thay vì raw bencoded info dictionary.
  • Giả định mọi InfoHash đều là 40 ký tự hex.
  • Trộn v1 và v2 mà không lưu hash type.
  • Coi tên Torrent là định danh canonical.

Bài viết BT9G Labs liên quan

Tài liệu tham khảo

Bài tiếp theo: Giải Thích Các Message DHT Trong BEP 5: ping, find_node, get_peers Và announce_peer →

Bài viết này nhằm giải thích các giao thức BitTorrent công khai và mô hình kỹ thuật. Việc quan sát một Swarm không đồng nghĩa nội dung đó đang khả dụng, hợp lệ hoặc được phép phân phối.