支持BT协议的P2P应用程序很多，如BitBuddy、FlashBT、BitComet和BitSpirit等，这里以应用程序BT为例来分析BT协议。本文中的BT，如其后没有“协议”两字，表示的是BT应用程序。BT由如下几部分组成：.torrent文件、种子提供站点、目录服务器和内容发布者/下载者。.torrent文件是一个文本文件，包含了tracker信息和文件信息两部分。tracker信息主要是BT下载中需要用到的tracker服务器的地址和针对tracker服务器的设置；文件信息是指将目标文件计算处理后再根据BT协议的B编码规则网编码后得到的信息。BT的主要原理是把提供下载的文件虚拟分成大小相等的块，块大小必须为2Kbyte的整数次方（由于是虚拟分块，硬盘上并不产生各个块文件），并把每个块的索引信息和Hash验证码写入.torrent文件中，所以.torrent文件就是被下载文件的“索引”。种子提供站点也就是.torrent文件的提供站点，为下载者提供.torrent文件下载服务。目录服务器记录被下载的文件的索引信息及下载该文件的用户的信息（主要是IP地址及端口号）。早期的BT协议只支持tracker（种子发布站）服务器，这种目录服务器是集中式目录与分布式查询的混合型；在BT协议的升级版本中，增加了对DHT（分布式Hash表）网络的支持，该网络中目录服务器是分布式的。本文的讨论只涉及tracker服务器。内容发布者/下载者是BT网络的主体，最终的下载由它们完成。构成BT网络的这几部分的相互关系如图1所示。图1BT覆盖网络的结构根据BT的工作原理，为了分析BT协议的交互过程，本文重点关注本地BT客户机的运行过程。图2显示了BT协议的测试环境，其中BT客户机的IP地址是，使用Wireshark俘获BT协议分组的交互过程，Wireshark版本号为。它们与因特网相连，BT服务器位于因特网，BT版本号为。BT协议的测试环境BT协议主要包括3个部分：.torrent文件的格式（现已加密，对非支持BT协议的软件透明）、trackerHTTP/HTTPS协议和Bittorrent协议。其中trackerHTTP/HTTPS协议是BT客户机与tracker服务器之间的通信协议，Bittorrent协议是BT客户机之间的通信协议。下面介绍一下trackerHTTP/HTTPS协议。BT客户机依次向.torrent中的tracker服务器发送连接请求，以获得正在下载该文件的对等方列表（主要是IP地址和监听端口）。如果连接成功获得列表，就关闭连接，尝试与列表中的对等方建立连接；如果不成功，尝试下一个tracker服务器。由下图知本次测试环境第一次向服务器tracker地址为，结果没有找到，BT客户机与BT服务器的交互过程下图所示。BT客户机与BT服务器的交互过程分析这些分组，易知分组197、198、199是建立TCP连接的三次握手。BT客户机通过200号分组向tracker服务器发出获取对等方列表的请求，202、203（重复）号是对分组为应答。204是对203号分组的应答，205-218号分组是双方互相关闭TCP连接并复位的过程。下面重点分析200号分组。200号分组中的HTTP部分内容如图所示，使用*号代替空格以便于分析。图200号分组中的HTTP部分内容(没有找到)最后，（用随机网络的路由算法）向地址为的服务器发出请求，经过2090、2501、2502建立了TCP连接，如:BT客户机与BT服务器的交互过程，第一个握手分组2504（带Options12字节）如下所示：带Options选项的不带Options选项的其中一些成分的含义如下：●SHA1Hashofinfodictionary：.torrent文件中的文件夹得FQDN下的绝对路径的Shal值。tracker服务器通过它在发布列表中找到对应的记录。●peer_id：BT客户机的惟一性标志，在客户机启动时产生，共20bit。在BTV1.0中没有规定产生peer_id的算法，只要求能够保证惟一性即可。虽然该机器上有这一个文件，但由于种种原因，它获得不了其资源，于是就有了分组4116，BitTorrentcontinuationdata的回应。然后，再有了分组4119，continuationdata的回应。分组5956，发出handshark-TCP-Retransmission请求，继续寻找资源。这个5647分组也是continuationdata。也就用这种方式对等节点间建立连接。当建立TCP后，对等方之间的交互过程如下图所示：包括以下几步：（1）首先，10.80.120请求与113.229.1