BT9G LABS / DHT 深度解析 #04

InfoHash 深度解析：BitTorrent v1、v2、Magnet、BTIH 與 BTMH

理解 BitTorrent 內容標識如何計算，以及 v1 SHA-1、v2 SHA-256、BTIH 與 BTMH 在 Magnet 鏈接中的關係。

BT9G Labs發布於 3 分鐘閱讀

BT9G Labs / DHT Deep Dive #04. 從內容身份邊界出發，解釋 v1 與 v2 Torrent 如何生成雜湊，以及搜索索引應如何正確處理兩代標識。

InfoHash 深度解析：BitTorrent v1、v2、Magnet、BTIH 與 BTMH

快速摘要

  • 主題: InfoHash 深度解析：BitTorrent v1、v2、Magnet、BTIH 與 BTMH
  • 核心關鍵詞: InfoHash, BitTorrent v1, BitTorrent v2, BTIH, BTMH
  • 適合讀者: 後端工程師、協議研究者、搜索工程師以及 BitTorrent 實現者
  • 目標: 用足夠準確的協議與系統視角解釋原理，並能直接支持真實的採集、索引和搜索架構設計。

系統視圖

info dictionary 才是身份邊界

在 BitTorrent 中，Torrent 的內容身份並不是對整個 .torrent 檔案隨便做一次雜湊。v1 的 InfoHash 是對 bencoded info dictionary 的編碼結果執行 SHA-1；因此注釋、創建者、Tracker 列表等 info 之外的欄位發生變化時，v1 InfoHash 可以保持不變。

索引器如果重新序列化 info 結構再計算雜湊，必須極其謹慎。尤其是解析後重編碼可能改變原始字節序列，進而得到不同的雜湊。最安全的做法是保留用於身份校驗的原始字節邊界。

v1 與 BTIH

經典 BitTorrent v1 使用 20 字節 SHA-1 InfoHash。在 Magnet URI 中，這種標識通常通過 xt=urn:btih:... 表示，可以是十六進制或 Base32 編碼。大量 DHT、Tracker 與現有索引生態都圍繞這個 160-bit 標識構建。

資料庫層應把“原始二進制雜湊”和“展示編碼”分開。十六進制大小寫差異不應該製造兩個資源記錄，使用者輸入的 Base32 也應規範化到同一個 canonical key。

v2、SHA-256 與 BTMH

BitTorrent v2 在 BEP 52 中引入 SHA-256 和 Merkle tree 等設計，內容身份不再完全等同於傳統 v1 的 20 字節雜湊。Magnet 表示通常使用 multihash 形式的 urn:btmh:。此外還存在同時兼容 v1 與 v2 的 hybrid torrent。

因此現代搜索系統不能把“InfoHash 永遠就是 40 個十六進制字符”寫死在所有資料模型中。更穩妥的設計是顯式保存協議版本、雜湊算法、原始摘要以及可用於 URL/搜索的規範化表示。

對索引系統意味著甚麼

內容身份是去重、Metadata 校驗、詳情頁路由和跨來源合併的基礎。v1、v2 和 hybrid 資料必須採用明確規則，不能簡單把不同 namespace 的字串塞進同一列後靠長度猜類型。

對於 BT9G 一類系統，最好讓 canonical content identity 與“從哪裡發現”“哪些 Tracker 出現過”“最近有哪些 Peer 活躍”解耦。這樣同一內容可以聚合多種網路來源，同時不污染真正的身份欄位。

實現示意

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 的欄位都應該保留來源與時間戳，並通過階段化指標區分發現、連接、協商、Metadata 獲取、校驗、入庫和索引等環節。這樣才能在規模擴大後定位真實瓶頸，而不是把所有失敗都歸因於“網路不穩定”。

常見誤區

  • 對整個 .torrent 檔案直接計算 v1 InfoHash。
  • 把十六進制大小寫差異當成不同資源。
  • 假設所有 InfoHash 都固定為 20 字節 SHA-1。
  • 沒有為 v2 和 hybrid torrent 預留資料模型。

相關 BT9G Labs 文章

參考資料

下一篇: BEP 5 DHT 報文詳解：ping、find_node、get_peers 與 announce_peer →

本文用於解釋公開的 BitTorrent 協議與工程實現思路，不代表任何被觀察到的 Swarm 一定可用、有效或被授權傳播。