BitTorrent 扩展协议（Extension Protocol）详解

概述

一个协议从制定之初就不可能是完美的，总是要根据具体情况扩展功能，但扩展功能的同时要考虑与旧版本协议的兼容性，否则当一个用户升级了新的协议后，可能之前的许多功能就不能用，因为可能大多数人还没有升级。

BitTorrent 扩展协议（Extension Protocol）为 BitTorrent 协议簇提供了一个简单而轻量的扩展方式，可以在保证兼容性的同时为协议加入新的功能。比如基于 DHT 协议的磁力链接就是使用扩展协议加入的新功能。

本文将介绍 BT 扩展协议的报文格式和时序。

伙伴（Peer）协议在完成握手后，为每一种消息都指定了一个唯一的 ID，并且每次发送消息时，都要在消息的最开始处填充本次消息的字节长度，这个长度也包含“长度”这项数据本身占据的空间。

伙伴（Peer）协议中并没有可以用于扩展功能的消息类型，所以扩展协议为此新增了一个消息类型，并指定了唯一的 ID，即 extended 消息，ID 是 20。

扩展消息的用处是完成扩展协议本身的握手流程，并且协助其它协议的工作，比如协助 DHT 协议传输 DHT 节点的 UDP 端口。

扩展消息的 ID 为 20，当程序发送这一消息时，其布局是下面这样的，

第 0 ~ 3 个字节	第 4 个字节	第 5 个字节	若干个字节
整个消息的长度	消息的 ID（20）	扩展消息的 ID	载荷（payload）

extended 消息布局

报文中的第五个字节如果为 0 则表示这是握手消息，如果大于 0 则表示为其它协议的消息。报文中的载荷当扩展消息 ID 为 0 是是握手消息的载荷，其它情况下则由具体的协议规定，比如 DHT 协议就规定了载荷的格式。

握手消息应当在伙伴（Peer）协议完成握手后立即发送给对方，一方收到握手消息后，也可以向对方发送握手消息用来禁用某个协议，或者协商某个协议。

握手消息的载荷是一个经过了 B 编码的字典。下面列出的所有的字典中的项目都是可选的，任何一个未知的项目都应该被忽略，字典的全部内容都是区分大小写的。

这个字典中包含下列内容。

m：一个字典，从一个字符串映射到一个非负整数。字符串是受支持的协议的名称，非负整数是这个协议的 ID。协议的名称必须是唯一的，ID 则只需要保证对于通信双方唯一即可。如果 ID 为 0 则表示发送方希望禁用这个 ID 对应的协议。
p：一个整数，表示发送握手消息的一方监听的 TCP 端口号。对于握手消息的接收方，通常不需要发送这一项，因为对方只有在知道了监听端口后才能够向其发送握手消息。
v：客户端的名称（UTF-8），比如 “uTorrent 1.2”。
yourip：一个字符串，表示握手消息发送方看到的接收方的 IP 地址的紧凑表。消息的接收方可能持有多个 IP 地址，这一项可以告诉接收方它的哪个 IP 被发送方所使用。
ipv6：如果发送方持有一个或多个 IPV6 地址，则应该将这些 IPV6 地址以紧凑表的形式写入到这一项中。
ipv4：基本同 ipv6。
reqq：一个整数，表示发送方允许多少个消息排队处理，超出此数量后消息可能会被丢弃。

这种握手消息比较奇怪，通常来说，一方发送握手消息后，另一方会以另外的格式来回复握手消息，比如 TLS 的 ClientHello 消息和 ServerHello 消息。但这里握手消息无论是发送还是回复都遵循同一种格式，不过也意料之中，毕竟 P2P 网络中不区分客户端和服务端。

举个例子来直观地了解一下握手消息。

d1:md11:LT_metadatai1e6:ut_pexi2ee1:pi6881e1:v12:uTorrent 1.2e

上面就是一个合法的握手消息的载荷，如果将其转化为 JSON 格式则是下面这样。

{
    "m": {
        "LT_metadata": 1,
        "ut_pex": 2
    },
    "p": 6881,
    "v": "uTorrent 1.2"
}