BitTorrent协议概述

本文转自  http://www.doc88.com/p-691270196531.html

1. BT网络架构

BT网络由以下几部分组成：.torrent文件、种子提供站点、目录服务器和内容发布者/下载者。

（1）.torrent文件（又称种子文件）是一个文本文件，包含了tracker信息和文件信息两部分。Tracker信息主要是BT下载中需要用到的tracker服务器的地址和针对tracker服务器的设置；文件信息是指将目标文件计算处理后再根据BT协议的B编码规则编码后得到的信息。BT的主要原理是把提供下载的文件虚拟分成大小相等的块，块大小必须为2Kbyte的整数次方，并把每个块的索引信息和Hash验证码写入.torrent文件中，所以.torrent文件就是被下载文件的“索引”。

（2）种子提供站点也就是.torrent文件的提供站点，为下载者提供.torrent文件下载服务。

（3）目录服务器记录被下载的文件的索引信息及下载该文件的用户的信息（IP地址及端口号等）。

（4）早期的BT协议只支持tracker服务器，这种目录服务器是集中式目录与分布式查询的混合型；在BT协议的升级版本中，增加了对DHT（分布式Hash表）网络的支持，该网络中目录服务器是分布式的。内容发布者/下载者是BT网络的主体，最终的下载由它们完成。

 

2. BT协议的工作过程

BT协议主要包括3部分：.torrent文件的格式、tracker HTTP/HTTPS协议和Peer wire协议（使用TCP）。其中tracker HTTP/HTTPS 协议是BT客户机与tracker服务器之间的通信协议。Peer wire协议是BT客户机之间的通信协议。

在介绍BT协议的三个部分之前，引出BT协议中的一种常见编码形式--B编码。B编码是一种简洁的数据组织方式，支持4种数据类型：byte strings、integers、lists和dictionaries。

byte strings（字节字符串）的编码格式：<十进制ASCII表示的字符串长度>:<字符串数据>

integers（整数）的编码格式：i<十进制ASCII表示的整数>e

lists（列表）的编码格式：l<B编码值>e

dictionaries（字典）的编码格式：d<B编码字符串><B编码元素>e

图1 BT网络架构图

 

2.1 .torrent文件格式

如图2所示，就是一个.torrent文件的内容。

图2 .torrent文件内容

这个文件是从北邮人BT上发布的一部电影《电锯惊魂6》的种子文件。其中的一些主要域如下：

（1） announce ：tracker服务器的URL，本例中为

http://tracker.byr.cn/announce.php?passkey=e38432a4975a295669339ac69afcf57910

（2）announce-list（可选）：备用tracker服务器的URL列表，本例中没有该列表。

（3）created by（可选）：制作.torrent文件的工具，本例中使用的制作工具是uTorrent/1850。

（4）creation date（可选）：.torrent文件的创建日期，使用标准的UNIX时间，本例中卫1258917365。

（5）encoding（可选）：发布的资源使用的编码方式，本例中使用的是UTF-8。

（6）comment（可选）：.torrent文件制作者添加的任意格式的说明。本例中无comment。

（7）info：发布的文件的信息。有两种格式，单文件格式和多文件格式。单文件格式包括length、md5sum（可选）、name、piece length、pieces；多文件格式包括files、name、piece length、pieces，其中files包括length、path、md5sum（可选），每一个文件都有单独的length、path、md5sum（可选）。本例使用多文件格式。

 

2.2 Tracker HTTP/HTTPS协议

BT客户机依次向.torrent中的tracker服务器发送连接请求，以获得正在下载该文件的对等方列表（主要是IP地址和监听端口）。如果连接成功获得列表，就关闭连接，尝试与列表中的对等方建立连接；如果不成功，尝试下一个tracker服务器。表1显示了BT客户机与服务器的交互过程。

 

表1 BT客户机与服务器的交互过程

  

分析这些分组，易知分组702、748（分组702的重传）、750、752是建立TCP连接的三次握手。BT客户机通过753分组向tracker服务器发出获取对等方列表的请求，754、755为应答。757-760分组为关闭连接的交互过程。下面重点分析753、754和755号分组。

753号分组中的HTTP部分内容如图3所示，使用*号代替空格以便于分析。

图3 753分组内容（客户机向tracker服务器发送的数据内容）

 

其中一些成分的含义如下：

info_hash：.torrent文件中的info部分的SHA1校验码，共20 byte。tracker服务器通过它在发布列表中找到对应的记录。

peer_id：BT客户机的唯一性标识，在客户机启动时产生，共20 bit。

port：提供上传的端口号，亦即常说的监控端口，这里是6641（可自行设定）。

key：可选。一个扩展的唯一性标识，即使改变了IP地址，也可以使用该字段标识该BT客户机（这么牛？）。

uploaded/downloaded：上传/下载的字节数（从客户机向tracker服务器发送“started”开始计算），服务器可以用它来做流量分析。

left：还需要下载的字节数。

compact：压缩标识。如果值为1表示接受压缩格式的对等非列表，即用6 byte表示一个对等方（前4 byte表示IP地址，后2 byte表示端口号）；值为0表示不接受。

event：表明客户机的状态，只能是started、completed、stopped等3种中的一种。

ip（可选）：IP地址，没有的话服务器会自己找到。

numwant（可选）：客户机希望从tracker服务器得到的对等方的数目。

trackedid（可选）：如果在之前的announce中包含了trackerid，将其值设置在该处。

 

服务器中有个track程序来管理这些请求，得到这一串代码后就会用info_hash来查找列表，若找到就可以下载。接着它会反连（NatCheck）客户机的IP地址和端口来判断它是内网用户还是公网用户（向10.10.10.x这样的地址，是无法连通的）。接下来服务器返回现在正在下载这个文件的所有公网用户的IP地址和端口（包含在分组754、755中，因返回的数据比较多，所以被分片返回）。HTTP之上的部分数据如图4所示。

图4 755分组部分内容（服务器返回给客户机用户信息的部分内容）

 

图中“1998：”及其之前的部分使用的是ASCII字符集，“1998：”之后的部分是用16进制表示的二进制数。从分组内容可以看出interval的值为1800，也就是BT客户机最多每隔1800个时间单位就与tracker服务器重新连接一次：peers部分共有1998 byte。对753号分组的分析可知，BT客户机支持对对等方列表的压缩，因此在754、755号分组返回的对等方列表是用压缩方式存储的，即6 byte表示一个对等方，例如 da 40 91 e8 41 af 表示的对等方是218.64.145.232:16815，dd ea 3b 9f 7a 2f 表示的对等方是221.234.59.149:31279。对等方列表的长度为1998 byte，也就是说返回的对等方个数为333个。

 

2.3 Peer wire协议

Peer wire协议中的消息有两种（客户机之间通信的协议）：

（1）handshake消息：必要的信息，而且必须是由客户端发出的第一个信息。消息格式：<pstrlen><pstr><reserved><info_hash><peer_id>

pstrlen：<pstr>的长度，是单一的原始字节。

pstr：协议的字符串标识。

reserved：8字节保留字。现在的实现中这8字节都为0,。这些字节的比特位可用于改变协议的行为。

info_hash：元信息文件中的键info的20字节SHA1哈希值。这和Tracker请求传送的info_hash是一样的。

peer_id：客户端使用的唯一性ID，20字节字符串。这和Tracker请求传送的peer_id是一样的。

（2）其余消息：消息格式为<长度前缀><消息ID><负载>，这样的消息有：keep-alive：<len=0000>

该消息后面没有任何数据，因此长度前缀为0，因此没有消息ID和负载。Peer在一段时间内都接收不到消息的话，可能会关闭连接，所以可以发送keep-alive维持连接。该消息通常每两分钟发送一次。

chock：<len=0001><id=0>  chock消息长度固定，且没有负载。

unchock：<len=0001><id=1>  unchock消息长度固定，且没有负载。

interested：<len=0001><id=2>  interested消息长度固定，且没有负载。

not interested：<len=0001><id=3>  not interested消息长度固定，且没有负载。

have：<len=0005><id=4><piece index>  have消息长度固定。负载是一个片的索引，该索引从零开始，是成功下载且通过哈希验证的。

bitfield：<len=0001+X><id=5><bitfield>  bitfield消息可能只在握手系列完成后立刻发送，在这之前没有其他任何消息发送。它是可选的，而且如果客户端不拥有任何片则不需要发送。

bitfield消息是变长的，X指bitfield的长度。负载是一个比特组表示已经成功下载的片，第一个字节的高比特位表示索引为0的片，置0的比特位表示缺失的片，置1表示有效的可提供的片，最后剩余的比特位置0。

长度不正确的bitfield应视为出错。如果长度不正确，或剩余比特位由任何位置1，客户端都应该丢弃连接。

request：<len=0013><id=6><index><begin><length>   request消息长度固定，用于请求一个块。器负载包含下列信息：index（整数，指明片的索引号），begin（整数，指明片内的字节偏移量），length（整数，指明要求的长度。该值通常为16384字节）。

piece：<len=0009+X><id=7><index><begin><block>  piece消息变长，X指block的长度。负载包含下列信息index（整数，指明片的索引号），begin（整数，指明片内的字节偏移量），block（块数据，是指定索引的片的子集）。

cancel：<len=0013><id=8><index><begin><length>   cancel消息固定长度，用于取消请求。负载和request消息的一样。一般用于“End Game”阶段。

port：<len=0003><id=9><listen-port>  port消息由实现了DHT Tracker的新版本客户端软件发出。监听端口是该peer的DHT节点的监听端口，该peer应被插入到当地路由表上（如果DHT Tracker支持的话）。

 

3. 结论

综上，得到BT协议的工作过程为：

（1）资源发布者制作.torrent文件并上载到种子发布站点，将客户机连入BT网络并在tracker服务器上发布信息。默认情况下，BT的监听端口为6881-6889，也可由使用者指定；tracker服务器的监听端口主要有8080、8000、6969和2710，它们采用的连接方式都是TCP。

（2）BT客户机（下载者）获取.torrent文件，并向.torrent文件中提供的tracker服务器依次发起连接请求，直至与其中之一建立TCP连接并获取对等方列表。

（3）BT客户机随机地向列表中的对等方发起连接请求，因为对等方列表中对等方个数比较多，所以在段时间内发出大量TCP连接请求分组。这些分组的源地址相同，端口号相邻，目的地址/端口号不同，并且有相当一部分的目的端口号为6881-6889（未有对NAT穿透的操作？）。

（4）如果连接建立成功，BT对等方之间进行握手，握手过程中使用特征字符串“BitTorrent protocol”。然后使用interested、not interested、choke和unchoke等4种分组互通对资源的意愿情况，之后通过Request Piece和Piece分组传输资源（分片下载？）。

（5）资源传输完毕，关闭TCP连接（因为客户机之间的连接方式是TCP，更难实现NAT传统。）。