這份文章描述了 BitTorrent 協議已知的比特位用途和分配情況及消息標識符。
保留位分配#
為了未來可能出現的需求而預留的一些二進制位。這些位在當前版本的協議中沒有被使用，但是為了兼容未來的擴展，被保留用於以後的用途。保留位分配通常在協議中的特定字段中使用，例如 IP 頭部、 TCP 頭部和 UDP 頭部等。這些位可以用於未來標準的更新，因此任何以後的規範或協議都可以使用它們，而無需更改現有的協議。通過保留位分配，協議設計者可以確保協議在未來得到擴展時仍然保持向後兼容性，並且不會破壞現有系統的功能。
reserved[0]（"reserved[0]" 是指 BitTorrent 協議消息的一個保留字段，它的原始值為 0 。這個字段通常用於協議的擴展和更新，以便在未來版本中添加新的功能或更改現有功能。下同。）
0x80 Azureus Messaging Protocol"（Azureus Messaging Protocol 是一種與 BitTorrent 協議相關的通信協議，用於在 P2P 網絡中交換信息和數據。 Azureus 是一個著名的 BitTorrent 客戶端軟件，在其早期的版本中使用了自己的通信協議，即 Azureus Messaging Protocol，以實現對等節點之間的交互和控制。 Azureus Messaging Protocol 通常用於支持比特流下載、種子文件共享等 BitTorrent 相關功能，同時也可以用於客戶端之間的通信和協作。雖然 Azureus Messaging Protocol 已經被許多現代的 BitTorrent 客戶端所取代，但它仍然是 BitTorrent 技術發展歷程中重要的一部分。）
reserved[2]
0x08 BitTorrent Location-aware Protocol (no known implementations)（BitTorrent Location-aware Protocol (BLP) 是一種 BitTorrent 協議的擴展，旨在允許提供更好的下載性能和負載平衡。該協議使用 IP 地址來確定每個對等方的物理位置，並根據距離選擇最佳的源。然而，目前沒有已知的客戶端使用此協議。）
reserved[5]
0x10 LTEP (Libtorrent Extension Protocol)（Libtorrent Extension Protocol（LTEP）是由 libtorrent 庫使用的擴展協議，它使得 BitTorrent 客戶端能夠發送和接收在原始 BitTorrent 協議規範中未定義的擴展消息。這些擴展消息可用於各種目的，例如添加新功能或改善 BitTorrent 客戶端的性能。）
0x02 Extension Negotiation Protocol
0x01 Extension Negotiation Protocol（0x02 和 0x01 都是代表 Extension Negotiation Protocol 的代碼。 Extension Negotiation Protocol 是 BitTorrent 協議的一部分，用於在協議握手期間交換對等方所支持的協議擴展。當兩個對等方建立連接時，它們將發送包含各自支持的擴展的消息。這些擴展可以是標準擴展，如 ut_metadata 和 ut_holepunch，也可以是特定於客戶端或應用程序的自定義擴展。通過使用 Extension Negotiation Protocol，對等方可以協商並啟用共同支持的擴展，從而提高下載效率和功能性。）
reserved[7]
0x01 BitTorrent DHT（0x01 表示支持 BitTorrent DHT（分佈式哈希表），允許 BitTorrent 客戶端在沒有 tracker 的情況下查找和聯繫其他客戶端。）
0x02 XBT Peer Exchange（0x02 表示支持 XBT Peer Exchange，一種優化了 tracker 網絡負載的 P2P 網絡協議。）
0x04 suggest, haveall, havenone, reject request, and allow fast extensions（0x04 表示支持 suggest 、 haveall 、 havenone 、 reject request 和 allow fast 擴展。這些功能可以改進下載效率，例如通過發送 haveall 和 havenone 消息來告訴對等方它所擁有或不擁有的文件塊。）
0x08 NAT Traversal（0x08 表示支持 NAT Traversal 擴展，使 BitTorrent 客戶端可以使用 NAT 網絡穿越技術來連接其他客戶端。）
0x10 hybrid torrent legacy to v2 upgrade（0x10 表示支持 hybrid torrent legacy to v2 upgrade 擴展，允許舊版 BitTorrent 客戶端與新版客戶端無縫協作。）
已知的哈希碰撞：#
在哈希函數中已經存在兩個不同的輸入，它們產生相同的輸出值。這種情況被稱為哈希碰撞。哈希函數的目的是將任意長度的數據映射到固定大小的輸出。然而，由於輸入的不確定性和輸出的有限性，一些輸入可能會產生相同的輸出。通常，哈希函數被設計為具有高度隨機和複雜性，從而使哈希碰撞的概率非常低，並且可以忽略不計。然而，在某些情況下，攻擊者可能會利用哈希碰撞來進行惡意攻擊。例如，攻擊者可能會使用哈希碰撞來偽造數字簽名、執行重放攻擊或破解密碼等。
reserved[0]
0xFF BitComet Extension Protocol
reserved[1]
0xFF BitComet Extension Protocol
0xFF 是 BitComet 擴展協議（BitComet Extension Protocol）中的一個字節標誌符，用於標識協議的握手消息。該協議是 BitTorrent 網絡上一種特殊的擴展協議，通過在原有 BitTorrent 協議的基礎上增加新功能，提供更高效和更可靠的傳輸服務。
reserved[7]
0x01 XBT Metadata Exchange (implemented only in XBT)
XBT Metadata Exchange 協議允許客戶端通過 Tracker 伺服器從其他客戶端中獲取元數據信息，而不必下載完整的種子文件。這在某些情況下可以提高下載效率和節省帶寬。當一個 XBT 客戶端連接到 XBTIT Tracker 時，它可以向 Tracker 發送支持 XBT Metadata Exchange 的握手消息，其中包括 reserved[7] 設置為 0x01 。如果 Tracker 支持 XBT Metadata Exchange，則它會在回覆握手消息時指示客戶端。此後，客戶端就可以通過 Tracker 從其他支持 XBT Metadata Exchange 的客戶端中獲取元數據信息。
“Extension Protocol”，也稱為 LibTorrent Extension Protocol（LTEP），是在 BitTorrent 協議中實現進一步擴展的推薦方法。 LTEP 提供了一種標準化機制，用於在不引起位或消息 ID 衝突的情況下添加新功能到協議中。 LTEP 提供了一種更強大、更可靠的方式來擴展 BitTorrent 協議，並被建議用於希望添加新功能到協議中的開發者。
使用 LTEP，擴展位碰撞變得不可能，因為沒有分配新的擴展位。相反，所有擴展都在連接開始時進行協商，並分配唯一的標識符。這確保每個擴展都有一個獨特的標識符，不會與其他擴展產生衝突。同樣，使用 LTEP 時消息 ID 碰撞也變得不可能，因為消息 ID 是在連接開始時按需分配的。這意味著每種消息類型都有一個獨特的 ID，不會與其他消息類型衝突。雖然使用 LTEP 時擴展名稱衝突仍然有可能，但與以前的方法相比，衝突的概率要小得多。這是因為所有擴展都由 BitTorrent 社區註冊和跟蹤，有助於確保新擴展不會與現有的衝突。
保留消息 IDs#
核心協議:#
0x00 choke
0x01 unchoke
0x02 interested
0x03 not interested
0x04 have
0x05 bitfield
0x06 request
0x07 piece
0x08 cancel
choke 和 unchoke 用於控制上傳帶寬。當一個對等方 choked 另一個對等方時，它告訴它不再向其發送任何數據。當 unchoked 時，它允許另一個對等方下載數據。
interested 和 not interested 用於表示一個對等方是否對另一個對等方擁有的數據感興趣。
have 和 bitfield 用於描述一個對等方已經擁有的數據，以便其他對等方可以知道他們需要什麼數據。
request 和 piece 用於實際傳輸數據。請求包含所需數據塊的索引和長度，而 Piece 包含實際的數據。
cancel 允許取消先前發出的請求，這樣可以更好地管理網絡流量。
DHT 擴展:#
0x09 port
port 用於 DHT 擴展，用於向其他對等方公開端口號。
快速擴展:#
0x0D suggest
0x0E have all
0x0F have none
0x10 reject request
0x11 allowed fast
suggest 、 have all 、 have none 、 reject request 和 allowed fast 都是 Fast 擴展的一部分，可以提高下載速度。
Additional IDs used in deployed clients:#
0x14 LTEP Handshake (implemented in libtorrent, uTorrent,...)
LTEP 握手是使用 libtorrent 、 uTorrent 等客戶端實現的握手協議，用於在開始下載之前執行一些必要的步驟。
Hash Transfer Protocol:#
0x15 hash request
0x16 hashes
0x17 hash reject
hash request 、 hashes 和 hash reject 是 Hash Transfer Protocol 的一部分，用於在對等方之間交換哈希值，以驗證共享文件的完整性。