本文建立了分析BT协议的环境，通过俘获BT分组并对照BT协议规范，分析了BT通信协议的交互过程，并据此配合BT的特征字符串、特征端口及行为特征，提出了一种检测通信流中存在BT通信的方法。
1、概述
传统的因特网服务如Web、FTP、DNS等均使用客户机/服务器（C/S）模式进行通信。在通信过程中，提供服务的程序称为服务器，请求服务的程序称为客户机。因此，在复杂通信的过程中，一个服务器很可能在另一次通信中变为客户机，反之亦然。C/S模式的特征是：服务器是总是打开的主机，具有永久的IP地址，并可扩展为服务器池；客户机与服务器直接通信，可以间歇地与服务器连接，可以具有动态的IP地址，并且客户机彼此之间不直接通信。C/S模式的最大特点是服务和资源集中，所有对服务请求的处理通常是由服务器完成的。
对等方到对等方（peer-to-peer，P2P）是近年来流行起来的通信模式，但实际上因特网正是基于这种理念建立起来的。随着因特网用户和服务的增多，服务器面临的压力越来越大，P2P又重新回到了人们的视线中。在P2P模式中，无总是打开的应用服务器，任意的端系统之间可直接通信，对等方间歇地连接，并可改变IP地址。P2P模式的特征是：服务和资源分布化，资源不集中存储在某些设备上，而是分散存储在运行P2P程序的设备上，每一个对等方都可以为其他对等方提供服务。例如，主机A要从网上下载一个文件a，如果以P2P模式工作，那么它工作的基本过程是：定位具有文件a的对等方，向对等方提出下载请求，并获得该文件。值得注意的是，主机A在下载文件a的同时，可能也在为其他用户提供文件（包括文件a）下载。根据定位文件a的方式不同，可将P2P应用方式分为3类：集中式目录、分布式查询和结合这两者的混合方式[1]。集中式目录模式属于第一代P2P应用，使用一台大型服务器（或服务器场）来提供目录服务，其代表是Napster[2]，缺点是存在单点故障、性能瓶颈和侵犯版权等问题。分布式查询将目录服务完全分布在覆盖网络的所有对等方中，每一个对等方负责维护一部分目录内容。系统采用洪泛查询（query flooding）算法使用户获得文件信息，收到该报文的主机向它们的所有邻居转发该报文，这些邻居又依次向它们的所有邻居转发该报文等，其代表是Gnutella[3]。第3种方式是前两种方式的结合，其中一种实现方法是将覆盖网络中的对等方划分为若干小组，每个小组选取一个具有高带宽连接和高因特网连接性的成员作为组长，组长负责管理组内成员及与其他组长通信。在小组内使用集中式目录服务，服务器就是该组的组长。各组长之间使用分布式的目录服务。混合方式目前在P2P应用中使用最为广泛，其代表是KaZaA、BitTorrent（BT）[4]。
由于BT使用广泛，其通信协议引起的流量巨大，BT对因特网的运营、维护和管理具有重要影响。为此，参考文献[5]对BT的一般工作原理进行了介绍，参考文献[6]在分析BT工作原理的基础上，比较了BT与C/S模式应用程序的特点，提出了一种BT改进建议，但这些文献都没有详细地分析BT通信协议（简称BT协议）原理和交互过程。为此本文深入分析了BT通信协议和其交互过程，研究了BT通信的特点，并由此提出了一种检测通信流中存在BT通信的方法。
2、建立BT的分析环境
支持BT协议的P2P应用程序很多，如BitBuddy、FlashBT、BitComet和BitSpirit等，这里以应用程序BT为例来分析BT协议。本文中的BT，如其后没有“协议”两字，表示的是BT应用程序。
BT由如下几部分组成：.torrent文件、种子提供站点、目录服务器和内容发布者/下载者。.torrent文件是一个文本文件，包含了tracker信息和文件信息两部分。tracker信息主要是BT下载中需要用到的tracker服务器的地址和针对tracker服务器的设置；文件信息是指将目标文件计算处理后再根据BT协议的B编码规则网编码后得到的信息。BT的主要原理是把提供下载的文件虚拟分成大小相等的块，块大小必须为2 Kbyte的整数次方（由于是虚拟分块，硬盘上并不产生各个块文件），并把每个块的索引信息和Hash验证码写入.torrent文件中，所以.torrent文件就是被下载文件的“索引”。种子提供站点也就是.torrent文件的提供站点，为下载者提供.torrent文件下载服务。目录服务器记录被下载的文件的索引信息及下载该文件的用户的信息（主要是IP地址及端口号）。早期的BT协议只支持tracker服务器，这种目录服务器是集中式目录与分布式查询的混合型；在BT协议的升级版本中，增加了对DHT（分布式Hash表）网络的支持，该网络中目录服务器是分布式的。本文的讨论只涉及tracker服务器。内容发布者/下载者是BT网络的主体，最终的下载由它们完成。构成BT网络的这几部分的相互关系如图1所示。
图1 BT覆盖网络的结构
根据BT的工作原理，为了分析BT协议的交互过程，本文重点关注本地BT客户机的运行过程。图2显示了BT协议的测试环境，其中BT客户机的IP地址是192.168.0.179，使用Active Ports工具获取BT使用的端口号，Active Ports的版本号为1.4。使用协议分析仪Ethereal俘获BT协议分组的交互过程，运行Ethereal协议分析仪的IP地址是192.168.0.179，Ethereal版本号为0.10.14。它们通过路由器与因特网相连，BT服务器位于因特网，BT版本号为4.20.2。
图2 BT协议的测试环境
3、BT协议的工作过程
BT协议主要包括3个部分：.torrent文件的格式、tracker HTTP/HTTPS协议和Peer wire协议（使用TCP）。其中tracker HTTP/HTTPS协议是BT客户机与tracker服务器之间的通信协议，Peer wire协议是BT客户机之间的通信协议。
使用Ethereal跟踪分析下载一个文件的过程中BT协议的具体交互过程，结合BT协议规范，绘制了BT协议各组件的工作时序图（参见图3）。
图3 BT协议各组件的工作时序
3.1 .torrent文件的结构
图4是下载中使用的.torrent文件的一段主要内容，采用了B编码。B编码是一种简洁的数据组织方式，支持4种数据类型：byte strings、integers、lists和dictionaries。integers、lists和dictionaries类型分别以字母i、l、d作为首定界符，以字母e作为尾定界符。byte strings类型不使用首/尾定界符，其格式为<十进制表示的字符串长度>：<字符串>，如4:spam表示字符串“spam”。这4种数据类型嵌套使用构成了.torrent文件的内容。其中，用*号代替空格以便于分析。
图4 .torrent文件的内容
其中的一些主要成份如下：
- announce：tracker服务器的URL，本例中为http：//tracker.cnxp.com:8080/announce。
- announce-list：可选。备用tracker服务器的URL列表，本例中为http://tracker.cnxp.com:8080/announce,http://btfans.3322.org:6969/announce等。
- creation date：可选。.torrent文件的创建日期，使用标准的UNIX时间，本例中为1152105243。
- comment：可选。.torrent文件制作者添加的任意格式的说明。
- created by：可选。制作.torrent文件的工具，本例中使用的制作工具是BitComet/0.67。
- encoding：可选。发布的资源使用的编码方式，在本例中使用的是GBK。
- info：发布的文件的信息。有两种格式，单文件格式和多文件格式。单文件格式包括length、md5sum（可选）、name、piece length、pieces；多文件格式包括files、name、piece length、pieces，其中files包括length、path、md5sum（可选），每一个文件都有单独的length、path、md5sum（可选）。本例使用多文件格式，共有两个文件，分别是“Love Undercover Ⅲ.txt”和“影视帝国（bbs.cnxp.com）.新扎师妹
3.国语DVDSCR中字.rmvhe”，piece长度为262 144 byte.piece个数为34 780。
.torrent文件中还包括其他一些可选项，只要它们遵循B编码方式就能够被客户机识别，这里不再累述。
3.2 tracker HTTP/HTTPS协议
BT客户机依次向.torrent中的tracker服务器发送连接请求，以获得正在下载该文件的对等方列表（主要是IP地址和监听端口）。如果连接成功获得列表，就关闭连接，尝试与列表中的对等方建立连接；如果不成功，尝试下一个tracker服务器。
服务器tracker.cnxp.com的IP地址为61.129.77.239，btfans.3322.org的IP地址为61.129.78.114，BT客户机与BT服务器的交互过程如图5所示。
图5 BT客户机与BT服务器的交互过程
分析这些分组，易知分组702、748（分组702的重传）、750、752是建立TCP连接的三次握手。BT客户机通过753号分组向tracker服务器发出获取对等方列表的请求，754号、755号分组为应答。757-760号分组为关闭连接的交互过程。下面重点分析753号、754号和755号分组。
753号分组中的HTTP部分内容如图6所示，使用*号代替空格以便于分析。
图6 753号分组中的HTTP部分内容
其中一些成分的含义如下：
- info_hash：.torrent文件中的info部分的Shal校验码，共20 byte。tracker服务器通过它在发布列表中找到对应的记录。
- peer_id：BT客户机的惟一性标志，在客户机启动时产生，共20 bit。在BT V1.0中没有规定产生peer_id的算法，只要求能够保证惟一性即可。
- 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服务器得到的对等方的数目。
- trackerid：可选。如果在之前的announce中包含了trackerid，将其值设置在该处。
服务器中有个track程序来管理这些请求，得到这一串代码后就会用info_hash来查找列表，若找到就可以下载。接着它会反连（NatCheck）客户机的IP地址和端口来判断它是内网用户还是公网用户（像10.10.10.x这样的地址。是无法连通的）。接下来服务器返回现在正在下载这个文件的所有公网用户的IP地址和端口（包含在分组754、755中，因为返回的数据比较多，所以被分片返回）。HTTP之上的部分数据如图7所示。
图7 HTTP之上的部分数据
其中“1998：”及其之前的部分使用的是ASCII字符集，“1998：”之后的部分是用16进制表示的二进制数。从分组内容可以看出interval的值为1 800。也就是BT客户机最多每隔1 800个时间单位就与tracker服务器重新联系一次：peers部分共有1 998 byte。对753号分组的分析可知，BT客户机支持对对等方列表的压缩，因此在754、755号分组返回的对等方列表是用压缩方式存储的，即6 byte表示一个对等方，例如da40 91 e8 41 af表示的对等方是218.64.145.232:16815,dd ea 3b 9f 7a 2f表示的对等方是221.234.59.149:31279。对等方列表的长度为1 998 byte，也就是说返回的对等方个数为333个。
3.3 Peer wire协议
BT客户机会尝试与返回的对等方列表中的部分对等方建立连接，下面以对等方列表中的221.234.59.149:31279为例，分析一下对等方之间的交互过程。如图8所示，只分析TCP之上的部分。约定对等方A指的是221.234.59.149:31279，对等方B指的是192.168.0.179:1504。
图8 对等方间通信过程
建立TCP连接之后，对等方之间的交互过程包括以下几步：
（1）握手，通过Handshake分组实现。在本例中通过分组2480和2481实现。
（2）互换所拥有的资源的情况。通过Bitfield分组实现。该例中，对等方B尚未下载任何资源，故公布资源拥有情况的只有对等方A。对等方A通过分组2487公布了自己的资源拥有情况。
（3）互通对资源的意愿情况，包括interested、not interested、choke、unchoke等4种。本例中通过分组2490、2493实现。
（4）互相请求资源，通过request piece、piece分组实现，例如本例中的分组2495、2503、2696。
（5）断开连接。因Peer wire协议使用了TCP方式，对等方A与对等方B断开连接时，只需要断开它们之间的TCP连接即可。
分组2495是一个request piece分组，其结构如图9所示，其中需要的参数有piece index（片标志）、begin offset of piece（片起始偏移地址）、piece length（片长度）。分组2696是一个answer piece分组（也称为piece分组），其结构如图10所示，其中包括piece index（片标志）、begin offset of piece（片起始偏移地址）、date（数据）。
图9 request piece分组的结构
图10 piece分组的结构
4、一种检测BT流量的方法
经分析，BT应用程序的工作过程归纳如下：
- 资源发布者制作.torrent文件并上载到种子发布站点，将客户机连入BT网络并在tracker服务器上发布信息。默认情况下，BT的监听端口为6881-6889，也可由使用者指定；tracker服务器的监听端口主要有8080、8000、6969和2710，它们采取的连接方式都是TCP。
- BT客户机（下载者）获取.torrent文件，并向.torrent文件中提供的tracker服务器依次发起连接请求，直至与其中之一建立TCP连接并获取对等方列表。使用Ethereal抓包分析，发现这些连接请求被接受的可能性比较小，一般不到10%。
- BT客户机（下载者）获取.torrent文件，并向.torrent文件中提供的tracker服务器依次发起连接请求，直至与其中之一建立TCP连接并获取对等方列表。使用Ethereal抓包分析，发现这些连接请求被接受的可能性比较小，一般不到10%。
- BT客户机随机地向列表中的对等方发起连接请求，因为对等方列表中对等方个数比较多，所以在短时间内发出大量TCP连接请求分组。这些分组的源地址相同，源端口号相邻，目的地址／端口号不同，并且有相当一部分的目的端口号为6881-6889。
- 如果连接建立成功，BT对等方之间进行握手，握手过程中使用特征字符串“BitTorrent protocol”。然后使用interested、not interested、choke和unchoke等4种分组互通对资源的意愿情况，之后通过Request Piece和Piece分组传输资源。
- 资源传输完毕，关闭TCP连接。
- 依据BT应用程序的这些特点，本文提出了检测BT流量存在的一种方法。该检测方法主要分4个步骤：
- 特征字符串匹配。如果分组的负载中出现了字符串“BitTorrent protocol”，表明有BT客户机运行，将该分组中的源IP地址和源端口号记为{IP.port}对，凡与此{IP，port}对相关的分组均判定为BT流量。
- 特征端口匹配。所有使用6881-6889作为端口号的分组均被判定为BT流量。
- tracker服务器规则。将目的端口号为8000、8080、6969和2710的TCP分组的目的IP地址标记为tracker服务器，将源端口号为8000、8080、6969和2710的TCP分组的源IP地址标记为tracker服务器，所有与tracker服务器相关的分组均被判定为BT流量。
- 通过以上3步可以较准确地判断流中是否存在BT业务，但并不能保证找出所有的BT分组。为了进一步增加判断的准确性。可使用流之间关系信息。例如某一时间段内，相同两台主机之间的流被关联在一起；来自不同主机的有着相同目的地址和目的端口号的流被关联起来；在某一时间段内来自同一主机的流被关联起来等。
笔者根据这种检测BT流量的方法实现了相关检测程序。由于该方法使用了特征字符串和特征端口来判断BT流量并使用流关系，在一定程度上解决了因程序使用随机端口带来的检测困难，提高了检测的准确性。程序实验结果也表明了上述算法的有效性。限于篇幅，将另文报告。
