这份文章描述了 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 的一部分，用于在对等方之间交换哈希值，以验证共享文件的完整性。
参考链接
- http://www.bittorrent.org/beps/bep_0004.html
