BitTorrent协议规范中文.docx

1、BitTorrent协议规范中文BitTorrent协议规范try维基百科，自由的百科全书BitTorrent是由布莱姆科恩设计的一个点对点（P2P）文件共享协议，此协议使多个客户端通过不可信任的网络的文件传输变得更容易。目录 1 目的 2 应用范围 3 约定o 3.1 B编码 3.1.1 字节串 3.1.2 整数 3.1.3 表 3.1.4 字典 4 元信息文件结构 5 服务器 HTTP/HTTPS 协议 6 服务器“刮”约定 7 用户线路协议（TCP）o 7.1 概述o 7.2 数据类型o 7.3 消息流o 7.4 握手 7.4.1 peer_ido 7.5 消息 8 算法o 8.1 排队

2、o 8.2 超级种子o 8.3 片断下载策略o 8.4 最后阶段o 8.5 阻塞与最佳畅通o 8.6 反冷落 9 相关文档 10 请参阅目的此规范的目的是详细介绍BitTorrent协议规范 v1.0 。Bram 的协议规范网站 简要地叙述了此协议，在部分范围缺少详细行为阐述。希望此文档能成为一个正式的规范，明确的条款，将来能作为讨论和执行的基础。此文档规定由BitTorrent开发者维持和使用。欢迎大家为它做贡献，其中的内容代表当前协议，它仍由许多客户使用。这里不是提出特性请求的地方。如果有请求，请见邮箱列表。应用范围本文档适用于BitTorrent协议规范的第一版(v1.0)。目前，这份文

3、档应用于 torrent 文件结构、用户线路协议和服务器（Tracker） HTTP/HTTPS 协议规范。如果某个协议的修改有了新的定义，它们会被指定在协议相应的页面，而不在这里。约定在本文档中，使用了许多约定来简明和明确地表达信息。 用户（peer） v/s 客户端（client）：在本文档中，一个用户可以是任何参与下载的BitTorrent客户端。客户端也是一个用户，尽管BitTorrent客户端运行在本地机器上。本规范的读者可能会认为自己是连接了许多用户的客户端。 片断（piece） v/s 块（block）：在本文档中，片断是指在元信息文件中描述的一部分已下载的数据，它可通过 SHA

4、-1 hash 来校验。而块是指客户端向用户请求的一部分数据。两块或更多块组成一个完整的片断，它能被校验。 实际标准：大的斜体字文本指出普通的准则在不同客户端BitTorrent的执行，它被当作为实际标准。为了帮助其他人找到本文档最近的修改，请填写改变日志（最后一段）。它应包含一个简短的项目（如：一行），用来记录你每次对此文档的主要改动。B编码主条目：BencodeB编码是一种以简洁格式指定和组织数据的方法。支持下列类型：字节串、整数、表和字典。字节串字节串按如下编码：注意没有开始和结束的分隔符。例：“4：spam” 代表字符串“spam”整数整数按如下编码：ie开始的“i”与结尾的“e”分别

5、是开始和结束分隔符。可以使用如“i-3e”之类的负数。但不能把“0”放到数字的前面，如“i04e”。另外，“i0e”是有效的。例：“i3e”代表整数“3”表表按如下编码：le开始的“l”与结尾的“e”分别是开始和结束分隔符。表可以包含任何已编码的类型，包括整数、串、字典和其他的表。例：l4:span4:eggse 代表两个串的表“spam”、“eggs”字典字典按如下编码：de开始的“d”与结尾的“e”分别是开始和结束分隔符。注意关键字必须被编码为串。值可以是任何已编码类型，包括整数、串、表和其他字典。关键字必须是串，以分类的顺序出现（以原始串排列，而不是以字母数字）例1：d3:cow3:mo

6、o4:spam4:eggse 代表字典 cow = moo, spam = eggs 例2：d4:spaml1:a1:bee 代表字典 spam = a, b 元信息文件结构所有在元信息文件中的数据都要编码。编码规则如上所述。元信息文件（以 .torrent 结尾的文件）的内容是一个编码的字典，包含以下列表中的各项。所有字符串值都以 UTF-8 编码。标记没有为“可选”的键值是必需的字段： 信息一个描述 torrent 文件的字典。有两种可能的形式：一种是没有目录结构的“单一文件”，另一种是包含子目录树的“多文件”对于“单一文件”来说，信息字典包含以下的结构：长度: 文件字节数长度（整数）md

7、5和: （可选）一个 32 位的 16 进制字符串，它对应于文件的 MD5和。不被BitTorrent所使用，但被一些程序包含，以提供更大的兼容性。名称: 文件的名称。建议使用（字节串）。片断长度: 每个片断的字节数（整数）。片断: 包含所有 20 字节 SHA-1 散列值的字符串，每个片断都有唯一的值。（字节串）对于“多文件”来说，信息字典包含以下的结构：文件：字典列表，每个文件都有一个。每个在表中的字典包含以下键值：长度：文件长度的字节数（整数）md5和: （可选）一个 32 位的 16 进制字符串，它对应于文件的 MD5和。不被BitTorrent所使用，但被一些程序包含，以提供更大的兼

8、容性。路径：一个包含着一个或多个字符串元素的，它包含路径和文件名。每个表中元素对应于一个目录名或（在最后的元素的情况下）文件名。例：文件名“dir1/dir2/file.ext”将包含三种串元素：“dir1”、“dir2”和“file.ext”。编码为串表的例子“l4:dir14:dir28:file.exte”名称：结构中根目录的名称包含上述文件列表中所有文件的目录（字符串）片断长度: 每个片断的字节数（整数）。片断: 包含所有 20 字节 SHA-1 散列值的字符串，每个片断都有唯一的值。（字节串） 发布：服务器的发布 URL （字符串） 发布列表：（可选）这是官方规范的一个扩展，它是向后

9、兼容的。此键值用来执行备份服务器的列表。完整的规范可在 找到。 创建日期：（可选） torrent 文件的创建时间，使用标准 Unix 时间格式（从 UTC 1970年1月1日 00：00：00 开始，整数秒） 评论：（可选）发布者的自由评论（字符串） 由创建：（可选）创建 torrent 文件的名字和程序版本（字符串）注意： 片断长度指定了标准的片断大小，通常是 2 的 n 次方。片断长度的一般是根据 torrent 文件中所有数据的数量来决定的，如果片断太大，会导致效率低，出错概率增加；而如果太小，则会使生成的 torrent 元数据文件过大。常识决定使用最小的片断大小，这样就会使生成的

10、torrent 文件不大于 5075 KB （可以减轻存储 torrent 文件服务器的负担）。但是，由于没有严格限制存储和带宽，即使为了高效率的共享文件可能导致生成更大的 torrent 文件，也建议将小于 810 GB 文件的片断大小设为小于或等于 512 KB。通常大小是 256 KB,512 KB 和 1 MB。除了最后的片断大小不定以外，其余片断大小是相等的。因此片断的数目由总大小决定。对于多文件模式下的片断边界，将文件数据设想为一个长的连续流，由文件有序列表中的每个文件相互连接而成。片断数目和其边界的决定方式与单一文件相同。片断可能由两个文件的边界组成。 每个片断都有相应的 SHA

11、-1 hash 数据校验码。这些校验码相互连接形成上述的信息字典的片断值。注意这不是一个表，而是一个字符串。其长度必须是 20 字节的整数倍。服务器 HTTP/HTTPS 协议服务器是用类响应 HTTP GET 请求的一种 HTTP/HTTPS 服务。该请求包括客户端的度量标准，这个标准可以帮助服务器全面统计 torrent 文件。基本的 URL 包括元数据文件（torrent）中定义的“发布 URL”。再将那些参数通过标准 CGI 方法添加到此 URL 中（如：“?”在发布 URL 之后，紧接着“参数=值”的序列，分隔符“&”）注意所有在 URL 中的二进制数据（特别是info_hash和p

12、eer_id）必须使用转义符。这意味着除 0-9，a-z，A-Z和$-_.+!*()外，其余字节需要采用“%nn”格式的编码，其中的“nn”是字节的 16 进制数值。（详细见 RFC1738）客户端向服务器的 GET 请求的参数如下： info_hash：元信息文件中 20 字节的 SHA-1 散列值。注意此值会进入编码字典中，如上述的信息关键字的定义所述。与不需编码的peer_id相比，它总是被 URL 编码。 peer_id：客户端 ID ，客户端用来唯一标识自己 ID 的 20 字节的串，它在客户端启动时生成。允许为任何值，包括二进制数据。目前没有特定的算法来生成客户端 ID。但是，人们

13、会认为它至少对于自己的本地机器是唯一的，从而应该像进程 ID 一样合并数据，也可能在启动时由时标记录。见本区域下面的一般客户端编码的peer_id。 端口：客户端监听的端口号。BitTorrent所使用的典型端口是 6881-6889。如果此范围的端口都无效，可以选择其他的。 已上传的：从客户端发送“已开始”事件到服务器算起的上传总量，数值采用 10 进制的 ASCII。对于没有在官方规范明确指出的，该值应为已上传的字节总数。 已下载的：从客户端发送“已开始”事件到服务器算起的下载总量，数值采用 10 进制的 ASCII。对于没有在官方规范明确指出的，该值应为已下载的字节总数。 剩下的：客户端

14、需要下载的字节数，以 10 进制 ASCII 编码。 紧密的：客户端接受一个紧密的响应。客户端列表由客户端串代替，此串中每个客户端都编码成 6 字节。前 4 字节是主机名（以网络的字节顺序），后两个字节是端口号（同样以网络字节的顺序）。 事件：如果被指定，则是已开始，已完成，已停止中的一个，或者为空（表示未指定）。如果未指定，此请求为常规时间间隔中的一次运行。 o 已开始：向服务器发送的第一个请求，必须包含开始值的事件关键字。 o 已停止：如果客户端关机则须发送到服务器上。 o 已完成：完成下载时必须发送到服务器上。但是，当客户端启动时下载完成度为 100% （即：做种中）则不会发送。可能这是

15、允许服务器增加“已完成下载”的方法。 ip：可选。客户端的真实 IP 地址，以点分四元组格式或 RFC3513 中定义的 16 进制 IPv6 地址。注意：大体上此参数没有客户端地址重要，它能由 IP 地址决定，HTTP 请求也来自该处。仅在请求参与的 IP 地址不是客户端的 IP 地址的情况下才需要。这种情况发生在客户端通过代理服务器与服务器进行通信的情形。当客户端和服务器同时处在本地 NAT 网关时也需要。原因是服务器会发出客户端的内部地址（RFC1918），这是不可到达的。所以客户端必须清楚地把自己的外部可到达的 IP 地址发送到其他客户端中。不同的服务器对此参数的解释有所不同。某些只有

16、当请求参与的 IP 地址属于 RFC1918 时才允许。有些无条件允许，但有些则完全忽略。如果使用 IPv6 地址（如：2001:db8:1:2:100），则表示客户端能通过 IPv6 进行通信。 需求数目：可选。客户端想从服务器接收的用户数目。允许此值为“0”。如果不用此项，则默认值为 50 个用户。 关键字：可选。一个不与任何用户共享的另外的标识。当 IP 地址改变后，允许客户端证明它们的标识。 服务器id：可选。如果先前发布包含服务器的 id，它应放在这里。服务器作出“text/plain”文档的响应包括以下编码字典的关键字： 失败原因：如果当前使用此值，则其余关键字不会使用。该值是可读

17、的错误消息，包括请求失败的原因。（字符串） 警告消息：（新）与失败原因相似，但响应仍然会被正常处理。警告消息看起来像错误。 时间间隔：以秒计算，是客户端发送规则请求到服务器之后等待的时间。（强制） 最小时间间隔：最小发布时间间隔。当前客户重发间隔不能小于此值。 服务器 id：一个客户端应在下一个通告发回的字符串。如果没有该值，先前通告会发出一个服务器 id ，不要丢弃旧的值，一直使用它。 完成：拥有完整文件的用户数，即做种者（整数） 未完成：非种子用户的数目，也叫“吸血者”（整数） 用户：是字典的列表，每个值都有如下的关键字： o 用户 id：用户的自选择 ID，如上述用来发送服务器请求的（字

18、符串） o ip：用户的 IP 地址（IPv4 或 IPv6 格式）或域名（字符串） o 端口：用户的端口号（整数）如上所述，用户列表长度默认值为 50。如果连接的用户少于该值，列表会更小。另外，服务器随机选择用户及其响应。服务器在响应请求时可能使用一个更智能的机构来选择用户。例如，应避免向其他做种者报告种子。在事件发生（即：已停止或已完成）或客户端需要连接更多的用户时，客户端向服务器发送请求的间隔可以低于指定的时间间隔。但是，为了获得更多的用户而向服务器频繁地请求会被认为是错误的行为。如果客户端想在回应中得到许多用户，则需要在“需求数目”参数中设定。使用者注意：30 个用户就算丰富的源了，官

19、方客户端版本 3（v3）实际上在连接数少于 30 时会尝试增加新的连接，当连接数大于或等于 55 时会拒绝连接多余的用户。这个值对性能很重要。当完成下载一个新的片断时，“已拥有”消息（见下面）将会发送到最活动的用户。结果广播通信量与用户数目成正比例增加。大于 25 时，新用户不太可能会增加下载速度。有人强烈建议用户界面设计者使该项模糊和很难修改，因为那样做几乎没有用。服务器“刮”约定根据惯例，多数服务器支持请求的另一种形式，这种方式询问给定的服务器正在处理的 torrent （或所有的 torrent）。通常叫做“刮页”，因为它自动处理“刮屏”（服务器统计页）冗长的部分。刮 URL 也是一种类

20、似于上面描述的 HTTP GET 方法。但基本 URL 不同。用以下步骤来得到刮 URL：从发布 URL 开始寻找其中最后一个“/”。如果在文本之后的“/”不是“announce”，它将被作为一个符号，此符号不支持刮约定。如果是，则以“scrape”代替“announce”来找到刮页。例：(发布 URL -刮 URL) - - - - (不支持刮) - - (不支持刮) - (不支持刮)特别注意：结束引语没有完成。此标准是由 Bram 在BitTorrent开发列表文件中说明的。刮 URL 可以作为可选参数“info_hash”的一个补充，是一个 20 字节的值。这限制了服务器向特殊种子汇报。

21、另外，服务器正在处理的所有种子的统计也被发回。为了降低服务器的负载和带宽，有人强烈建议软件作者尽可能使用“info_hash”参数。HTTP GET 方法的响应是一个由编码字典组成的“text/plain”文档，包括以下关键字： 文件：每个 torrent 都包含一对关键字的字典，内容是统计数据。如果添加了有效的“info_hash”，此字典将包含单个关键字。每个关键字由一个 20 字节的info_hash值组成。该关键字的值是另一个包含下列名称的嵌套字典： o 已完成：拥有整个文件的用户数目，即做种者（整数） o 已下载：服务器注册编号完成的总数（“事件完成”，即客户端完成下载 torren

22、t） o 未完成：非做种者用户的数目，也叫“吸血者”（整数） o 名称：（可选）torrent 的内部名称，由 torrent 文件中信息字段指定注意此响应有三层字典嵌套。例如：d5:filesd20:.d8:completei5e10:downloadedi50e10:incompletei10eeee其中“.”是 20 字节的info_hash，以上表明有 5 个做种者，10 个吸血者和 50 个完成下载的用户。用户线路协议（TCP）概述用户线路协议使元信息文件中片断的交换变得更容易。注意原始规范在描述用户协议时也使用术语“片断”，但与元信息文件中的术语“片断”不同。由于该原因，术语“块”

23、将在本规范中用来描述用户之间通过线路交换的数据。客户端必须为每个远程用户的连接保持状态信息： 被阻塞：远程用户是否阻塞此客户端。当用户阻塞客户端时，不会响应任何请求。客户端不应尝试发送请求块，所有未响应的请求会被远程用户丢弃。 感兴趣：远程用户是否对此客户端感兴趣。当客户端未阻塞时，远程用户将开始发送请求块。注意这也意味着客户端需要记住自己是否对远程用户感兴趣和阻塞它。因此，真正的列表看起来像这样： am_choking：此客户端阻塞远程用户 am_interseted：此客户端对远程用户感兴趣 peer_chokong：远程用户阻塞此客户端 peer_interested：远程用户对此客户端

24、感兴趣客户端的连接以“被阻塞”和“不感兴趣”开始。也就是： am_choking = 1 am_interested = 0 peer_choking = 1 peer_interested = 0 当客户端对远程用户感兴趣并且远程用户未阻塞该客户端时，客户端开始下载块。当客户端没有阻塞远程用户并且远程用户对该客户端感兴趣时，客户端开始上传块。客户端保持通知远程用户自己是否对它们感兴趣，这是很重要的。与每个远程用户连接的状态信息应保持最新，直到该客户端被阻塞。这允许远程用户知道当自己未阻塞时，客户端是否会开始下载；反之亦然。数据类型如果不特别指定，在用户线路协议中的所有整数都会编码成 4 字节

25、 big endian 值。这包括所有消息中的长前缀，它在握手之后。消息流用户线路协议包括初始握手。之后，用户通过长前缀消息的交换来进行通信。长前缀是上述的一个整数。握手握手是必需的消息，它一定是由客户端发送的第一条消息。 握手： o pstrlen：串的长度，作为单个原始字节 o pstr：协议的串标识符 o reserved：8 个保留字节。当前的执行使用全。字节中的每位可以用来改变协议的行为。一封 Bram 的电子邮件建议首先使用末位，以使首位可用来改变末位的含义。 o info_hash：元信息文件信息关键字的 20 字节 SHA-1 散列值。这与服务器请求中发送的info_hash意

26、义相同。 o peer_id：每个客户端用来作为唯一标识的 20 个字节的串。这与服务器请求中发送的peer_id意义相同。在BitTorrent协议 v1.0 中：pstrlen=19，pstr=BitTorrent protocol连接的发起者应该立即发送彼此的握手信息。即使接收者能同时提供多个 torrent（torrent通过自己的info_hash来唯一标识），它也应等待发起者的握手信息。但是，接收者在看到握手的info_hash部分后必须迅速回应。服务器的 NAT 检查特性不会发送握手的peer_id字段。如果客户端收到一个当前不能处理的握手info_hash，该客户端就会断开那个

27、连接。如果连接的发起者收到一个握手信息，其中的peer_id与预期的不同，那么发起者就会断开该连接。注意发起者可能会收到来自服务器的远程用户信息，它包括远程用户注册的peer_id。来自服务器的peer_id与握手信息中的应该相同。peer_id主要有两种将客户端及其版本信息编码到peer_id的方法：Azureus型和 Shadow 型。Azureus型使用如下编码：“-”，一个客户端标识使用两个字符，版本号用 4 个 ASCII 数字表示，“-”紧跟在随机数字之后。例如：-AZ2060-.已知采用这种方法编码的客户端是： AR - Arctic AZ - Azureus BB - BitB

28、uddy BC - BitComet BS - BTSlave BX - Bittorrent X CD - Enhanced CTorrent CT - CTorrent LP - Lphant LT - libtorrent lt - libTorrent MP - MooPolice MT - MoonlightTorrent QT - Qt 4 Torrent example RT - Retriever SB - Swiftbit SS - SwarmScope SZ - Shareaza TN - TorrentDotNET TR - Transmission TS - Torre

29、ntstorm UT - Torrent XT - XanTorrent ZT - ZipTorrentShadow 型采用如下编码：用 1 个 ASCII 字母或数字标识客户端，3 个 ASCII 数字标识版本号，“-”紧跟在随机数字之后。例如：S587-.已知采用此种类型编码的客户端为： A - ABC O - Osprey Permaseed R - Tribler S - Shadows client T - BitTornado U - UPnP NAT Bit Torrent Bram 的客户端现在采用的形式： M3-4-2-BitComet则不同。它的peer_id由四个 ASCII 字符组成“exbc”，后面是两个字节的“x”和“y”