《bittorrent协议规范》由会员分享，可在线阅读，更多相关《bittorrent协议规范（33页珍藏版）》请在金锄头文库上搜索。
1、BitTorrent协议规范 目的此规范的目的是详细介绍 BitTorrent 协议规范 v1.0 。Bram 的协议规范网站 http:/ 简要地叙述了此协议，在部分范围缺少详细行为阐述。希望此文档能成为 一个正式的规范，明确的条款，将来能作为讨论和执行的基础。此文档规定由 BitTorrent 开发者维持和使用。欢迎大家为它做贡献，其中的内容代表当前协议，它仍由许多客户使用。这里不是提出特性请求的地方。如果有请求，请见邮箱列表。 应用范围本文档适用于 BitTorrent 协议规范的第一版(v1.0)。目前，这份文档应用于 torrent 文件结构、用户线路协议和服务器（Tracker）
2、HTTP/HTTPS 协议规范。如果某个协议的修改有了新的定义，它们会被指定在协议相应的页面，而不在这里。 约定在本文档中，使用了许多约定来简明和明确地表达信息。用户（peer） v/s 客户端（client）：在本文档中，一个用户可以是任何参与下载的 BitTorrent 客户端。客户端也是一个用户，尽管 BitTorrent 客户端运行在本地机器上。本规范的读者可能会认为自己是连接了许多用户的客户端。片断（piece） v/s 块（block）：在本文档中，片断是指在元信息文件中描述的一部分已下载的数据，它可通过 SHA-1 hash 来校验。而块是指客户端向用户请求的一部分数据。两块或更
3、多块组成一个完整的片断，它能被校验。实际标准：大的斜体字文本指出普通的准则在不同客户端 BitTorrent 的执行，它被当作为实际标准。 为了帮助其他人找到本文档最近的修改，请填写改变日志（最后一段）。它应包含一个简短的项目（如：一行），用来记录你每次对此文档的主要改动。 B编码主条目：BencodeB编码是一种以简洁格式指定和组织数据的方法。支持下列类型：字节串、整数、表和字典。 字节串字节串按如下编码：<以十进制 ASCII 编码的串长度>：<串数据>注意没有开始和结束的分隔符。 例：“4：spam” 代表字符串“spam
4、221; 整数整数按如下编码：i<以十进制 ASCII 编码的整数>e开始的“i”与结尾的“e”分别是开始和结束分隔符。可以使用如“i-3e”之类的负数。但不能把“0”放到数字的前面，如“i04e”。另外，“i0e”是有效的。例：“i3e”代表整数“3” 表表按如下编码：l<编码值>e开始的“l”与结尾的“e”分别是开始和结束分隔符。
5、 表可以包含任何已编码的类型，包括整数、串、字典和其他的表。例：l4:span4:eggse 代表两个串的表“spam”、“eggs” 字典字典按如下编码：d<编码串><编码元素>e开始的“d”与结尾的“e”分别是开始和结束分隔符。 注意关键字必须被编码为串。值可以是任何已编码类型，包括整数、串、表和其他字典。关键字必须是串，以分类的顺序出现（以原始串排列，而不是以字母数字）例1：d3:cow3:moo4:spam4:eggse 代表字典 cow => moo, spa
6、m => eggs 例2：d4:spaml1:a1:bee 代表字典 spam => a, b 元信息文件结构所有在元信息文件中的数据都要编码。编码规则如上所述。元信息文件（以 .torrent 结尾的文件）的内容是一个编码的字典，包含以下列表中的各项。所有字符串值都以 UTF-8 编码。标记没有为“可选”的键值是必需的字段：信息 一个描述 torrent 文件的字典。有两种可能的形式：一种是没有目录结构的“单一文件”，另一种是包含子目录树的“多文件”对于“单一文件”来说，信息字典包含以
7、下的结构：长度: 文件字节数长度（整数）md5和: （可选）一个 32 位的 16 进制字符串，它对应于文件的 MD5和。不被 BitTorrent 所使用，但被一些程序包含，以提供更大的兼容性。名称: 文件的名称。建议使用（字节串）。片断长度: 每个片断的字节数（整数）。片断: 包含所有 20 字节 SHA-1 散列值的字符串，每个片断都有唯一的值。（字节串）对于“多文件”来说，信息字典包含以下的结构：文件：字典列表，每个文件都有一个。每个在表中的字典包含以下键值：长度：文件长度的字节数（整数）md5和: （可选）一个 32 位的 16 进制字符串，它对应于文件的 M
8、D5和。不被 BitTorrent 所使用，但被一些程序包含，以提供更大的兼容性。路径：一个包含着一个或多个字符串元素的，它包含路径和文件名。每个表中元素对应于一个目录名或（在最后的元素的情况下）文件名。例：文件名“dir1/dir2/file.ext”将包含三种串元素：“dir1”、“dir2”和“file.ext”。编码为串表的例子“l4:dir14:dir28:file.exte”名称：结构中根目录的名称包含上述文件列表中所有文件的目录（字符串）片断长度: 每个片断的字
9、节数（整数）。片断: 包含所有 20 字节 SHA-1 散列值的字符串，每个片断都有唯一的值。（字节串）发布：服务器的发布 URL （字符串） 发布列表：（可选）这是官方规范的一个扩展，它是向后兼容的。此键值用来执行备份服务器的列表。完整的规范可在 http:/ 找到。 创建日期：（可选） torrent 文件的创建时间，使用标准 Unix 时间格式（从 UTC 1970年1月1日 00：00：00 开始，整数秒） 评论：（可选）发布者的自由评论（字符串） 由……创建：（可选）创建 torrent 文件的名字和程序版本（字符串） 注意：片断长度指定了标准的片断大小，通常
10、是 2 的 n 次方。片断长度的一般是根据 torrent 文件中所有数据的数量来决定的，如果片断太大，会导致效率低，出错概率增加；而如果太小，则会使生成的 torrent 元数据文件过大。常识决定使用最小的片断大小，这样就会使生成的 torrent 文件不大于 5075 KB （可以减轻存储 torrent 文件服务器的负担）。但是，由于没有严格限制存储和带宽，即使为了高效率的共享文件可能导致生成更大的 torrent 文件，也建议将小于 810 GB 文件的片断大小设为小于或等于 512 KB。通常大小是 256 KB,512 KB 和 1 MB。除了最后的片断大小不定以外，其余片断大小是
11、相等的。因此片断的数目由总大小决定。对于多文件模式下的片断边界，将文件数据设想为一个长的连续流，由文件有序列表中的每个文件相互连接而成。片断数目和其边界的决定方式与单一文件相同。片断可能由两个文件的边界组成。 每个片断都有相应的 SHA-1 hash 数据校验码。这些校验码相互连接形成上述的信息字典的片断值。注意这不是一个表，而是一个字符串。其长度必须是 20 字节的整数倍。 服务器 HTTP/HTTPS 协议服务器是用类响应 HTTP GET 请求的一种 HTTP/HTTPS 服务。该请求包括客户端的度量标准，这个标准可以帮助服务器全面统计 torrent 文件。基本的 URL 包括元数据文
12、件（torrent）中定义的“发布 URL”。再将那些参数通过标准 CGI 方法添加到此 URL 中（如：“?”在发布 URL 之后，紧接着“参数=值”的序列，分隔符“&”）注意所有在 URL 中的二进制数据（特别是 info_hash 和 peer_id）必须使用转义符。这意味着除 0-9，a-z，A-Z和$-_.+!*()外，其余字节需要采用“%nn”格式的编码，其中的“nn”是字节的 16 进制数值。（详细见 RFC1738）客户端向服务
13、器的 GET 请求的参数如下：info_hash：元信息文件中 20 字节的 SHA-1 散列值。注意此值会进入编码字典中，如上述的信息关键字的定义所述。与不需编码的 peer_id 相比，它总是被 URL 编码。 peer_id：客户端 ID ，客户端用来唯一标识自己 ID 的 20 字节的串，它在客户端启动时生成。允许为任何值，包括二进制数据。目前没有特定的算法来生成客户端 ID。但是，人们会认为它至少对于自己的本地机器是唯一的，从而应该像进程 ID 一样合并数据，也可能在启动时由时标记录。见本区域下面的一般客户端编码的 peer_id。 端口：客户端监听的端口号。BitTorrent 所
14、使用的典型端口是 6881-6889。如果此范围的端口都无效，可以选择其他的。 已上传的：从客户端发送“已开始”事件到服务器算起的上传总量，数值采用 10 进制的 ASCII。对于没有在官方规范明确指出的，该值应为已上传的字节总数。 已下载的：从客户端发送“已开始”事件到服务器算起的下载总量，数值采用 10 进制的 ASCII。对于没有在官方规范明确指出的，该值应为已下载的字节总数。 剩下的：客户端需要下载的字节数，以 10 进制 ASCII 编码。 紧密的：客户端接受一个紧密的响应。客户端列表由客户端串代替，此串中每个客户端都编码成 6 字节。
15、前 4 字节是主机名（以网络的字节顺序），后两个字节是端口号（同样以网络字节的顺序）。 事件：如果被指定，则是已开始，已完成，已停止中的一个，或者为空（表示未指定）。如果未指定，此请求为常规时间间隔中的一次运行。 已开始：向服务器发送的第一个请求，必须包含开始值的事件关键字。 已停止：如果客户端关机则须发送到服务器上。 已完成：完成下载时必须发送到服务器上。但是，当客户端启动时下载完成度为 100% （即：做种中）则不会发送。可能这是允许服务器增加“已完成下载”的方法。 ip：可选。客户端的真实 IP 地址，以点分四元组格式或 RFC3513 中定义的 16 进制 IPv6 地址。注意：大体上此参数没有客户端地址重要，它能由 IP 地址决定，HTTP 请求也来自该处。仅在请求参与的 IP 地址不是客户端的 IP 地址的情况下才需要。这种情况发生在客户端通过代理服务器与服务器进行通信的情形。当客户端和服务器同时处在本地 NAT 网关时也需要。原因是服务器会发出客户端的内部地址（RFC
