bt协议分析

BitTorrent协议特征分析

1、概述

BitTorrent（简称BT）是一种文件分发协议，属于P2P协议。它通过URL识别内容并且和网络无缝结合。它在HTTP平台上的优势在于，同时下在一个文件的下载者在下载的同时不断互相上传数据，使文件源可以在很有限的负载增加的情况下支持大量下载者同时下载。

一 BT系统的组成结构

  1 普通的Web服务器：   例如Apache或IIS服务器

2 一个静态的种子文件：   即.Torrent文件，采用Bencoding编码

3  Tracker服务器：        追踪下载同一文件的用户

4 终端用户的Web浏览器：用于下载种子文件

5  BT客户端：             例如 BitCommet， BitSpirit

1.BT协议的工作过程

       BT协议主要包括3个部分：.torrent文件的格式、tracker HTTP/HTTPS协议和peer wire协议(使用TCP)。

其中trackerHTTP/HTTPS协议是BT客户机与tracker服务器之间的通信协议，

peer wire是BT客户机之间的通信协议。

       .torrent文件是一个文本文件，包含了tracker信息和文件信息两部分。tracker信息主要是BT下载中需要用到的tracker服务器的地址和针对tracker服务器的设置；文件信息是指将目标文件计算处理后再根据BT协议的B编码规则编码后得到的信息。

        BT的主要原理是把提供下载的文件虚拟分成大小相等的块，块大小必须为2Kbyte的整数次方（由于是虚拟分块，硬盘上并不产生各个块文件），并把每个块的索引信息和Hash验证码写入.torrent文件中，所以.torrent文件就是被下载文件的“索引”。种子提供站点也就是.torrent文件的提供站点，为下载者提供.torrent文件下载服务。目录服务器记录被下载的文件的索引信息及下载该文件的用户的信息（主要是IP地址及端口号）。

torrent文件内容采用了B编码。

      虽然比用纯二进制编码效率低，但由于结构简单而且不受字节存储顺序影响（所有数字以十进制编码，不存在大端小端的问题）——这对于跨平台性非常重要。而且具有较好的灵活性，即使存在故障的字典键，只要将其忽略并更换新的就能兼容补充。

        这种编码方式支持四种类型的数据：string, int, Dictionary<string, object>, List<object>，各自的编码规则如下：

1.1 string类型

        string类型的编码格式为[length]:[string]。以字符串的长度开头，加一个冒号，并以字符串内容结束。示例："abc" => 3:abc

1.2 int类型

        int类型的编码格式为i[int]e。以i开头，加上数字，以e结尾。 示例：123 => i123e

1.3 List<object>类型

        List<object>类型的编码格式为l[object]e。以l开头，加上列表中各个元素的编码（元素的类型同样为BEncoding支持的类型），以e结尾。 示例：List<"abc", 123> => l3:abci123ee

1.4 Dictionary<string, object>类型

        Dictionary<string, object>类型的编码格式为d[Key-Value Pair]e。以d开头，加上字典中每个键值对的编码，以e结尾。示例：Dictionary<{"name":"create chen"},{"age":23}> => d4:name11:create chen3:agei23ee

工作过程：    

BT客户机依次向.torrent中的tracker服务器发送连接请求，以获得正在下载该文件的对等方列表（主要是IP地址和监听端口）。假如连接成功获得列表，就关闭连接，尝试与列表中的对等方建立连接；假如不成功，尝试下一个tracker服务器。用ethereal抓包是如下数据：

GET                 /announce?info_hash=%B39%BEeJB%7B%BA%08%8C%DA%B7%E3y%E9sN%20%B2%DC&peer_id=%2DSD0100%2D%CFQ%91%05%86%06%AD%DF%A9%90N%27&ip=192.168.34.52&port=80&uploaded=0&downloaded=0&left=116569407&numwant=200&key=22446&compact=1&event=started HTTP/1.0

Host: tk2.greedland.net

User-Agent: Bittorrent

Accept: */*

Accept-Encoding: gzip

Connection: closed

GET请求内容格式说明如下：

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

●peer_id：BT客户机的惟一性标志，在客户机启动时产生，共20bit。在BTV1.0中没有规定产生peer_id的算法，只要求能够保证惟一性即可。

●port：提供上传的端口号，亦即常说的监控端口。

●key：可选。一个扩展的惟一性标志，即使改变了IP地址，也可以使用该字段标志该BT客户机。

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

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

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

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

除了上面这些例子中包含的参数外，可选的参数还有：

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

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

●trackerid：可选。假如在之前的announce中包含了trackerid，将其值设置在该处。

服务器中有个track程序来治理这些请求，得到这一串代码后就会用info_hash来查找列表，若找到就可以下载。接着它会反连（NatCheck）客户机的IP地址和端口来判定它是内网用户还是公网用户（像10.10.10.x这样的地址。是无法连通的）。接下来服务器返回现在正在下载这个文件的所有公网用户的IP地址和端口。HTTP服务器返回数据如下：

d8:completei88e10:incompletei70e8:intervali1800e12:minintervali1800e5:peers300:

 4c 0a 8b 27 58 cb 3d 3c cd 64 69 dd da 00 42 0e 92 24 83 dd c0 ec 43……

其中“300:”及其之前的部分使用的是ASCII字符集，“300:”之后的部分是用16进制表示的二进制数。从分组内容可以看出interval的值为1800。也就是BT客户机最多每隔1800个时间单位就与tracker服务器重新联系一次：peers部分共有300 byte。BT客户机支持对对等方列表的压缩，”300:”之后每 6 byte表示一个对等方，例如4c 0a 8b 27 58 cb表示的对等方是76.10.139.39:22731对等方列表的长度为300 byte，也就是说返回的对等方个数为50个。

1.2 tracker HTTP/HTTPS协议

       BT客户端依次向.torrent中的trackerr服务器发送连接请求，以获得正在下载该文件的对等方列表。如果连接成功获得列表，就关闭连接，尝试与列表中的对等方建立连接；如果不成功，尝试下一个tracker服务器。

第一、客户端获取Tracker服务器的IP地址

图一 客户端发送DNS请求包

从DNS服务器的响应来看，我们可以获取Tracker服务器的IP地址：

10.rarbg.com：是一个别名服务器

       主名称：tracker.publicbt.com：95.211.88.54、95.211.88.49、95.211.88.51、

       9.rarbg.com：                    83.149.126.97

               exodus.desync.com：              208.83.20.164

               pow7.com：                       同10.rarbg.com

               tracker.novalayer.org：          194.54.80.150

               tracker.publicbt.com：           95.211.88.54、95.211.88.49、95.211.88.51

       tracker.torrent.to：             127.0.0.1

               tracker.torrentbay.to：          109.235.55.11

               tracker.1337x.org:               95.215.62.224

               tracker.openbittorrent.com: 95.215.62.26

       以上为各Tracker服务器的IP地址。

第二、TrackerHTTP/HTTPS协议

       BT客户端依次向.torrent文件中的tracker服务器发送连接请求，以获取peers列表（主要是IP地址和监听端口）。如果连接成功获取列表，就关闭连接，尝试与列表中的对等方建立连接；如果不成功，尝试下一个tracker服务器。

图二 BT客户端向Tracker服务器发送HTTP请求

       447号分组中的HTTP部分内容如图6所示。

图三 HTTP部分内容

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

●     info_hash：.torrent文件中的info部分的sha1效验码，共20字节。Tracker服务器通过它在发布列表中找到对应的记录。

●     peer_id：BT客户端的唯一性标识，在客户端启动时产生，共20bit。貌似没有具体的产生peer-id的算法，只要求能够保证唯一性即可。

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

●     port：监听端口，这里为10775。

●     uploaded/downloaded：上传/下载的字节数（从客户机向Tracker服务器发送”started”开始计算）。

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

●     numwant：可选。客户端希望从Tracker服务器得到的对等方的数目。

●     key:可选。一个扩展的唯一性标识，即使改变了IP地址，也可以使用该字段标识该BT客户机。

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

 

       另外，在与Tracker服务器交互的过程中，有很多服务器的已经被封杀禁止，所以，会有很多这样的结果。

图四 被封后的Tracker服务器交互过程

       Tracker服务器有个tracker程序来管理这些请求，得到这一串代码后就会用info_hash来查找列表，若找到就可以下载。接着就会反连（NatCheck）客户端的IP地址和端口，判断它是内网用户还是公网用户。接下来服务器返回现在正在下载这个文件的所有公网用户的IP和端口。返回的部分数据如图五所示。

图五 HTTP之上部分数据

       其中“660：”以及之前的部分使用的是ASCII字符集，“660：”之后的部分是用16进制表示的二进制数。从分组内容可以看出：完成整个文件下载的peers数为76；正在下载的peers数目为10个；还没有完成该文件下载的peers数目为34；interval的值为1967，也就是说BT客户端最多每隔1967个时间单位就与tracker服务器重新联系一次；最少时间间隔为983；peer部分共有660个字节，由于BT客户端支持对等方列表的压缩，即6个字节表示一个对等方，也就说返回的对等方个数为110个。

 1.3 peer wire协议

       BT客户机会尝试与返回的对等方列表中的部分对等方建立连接，下面是对等放列表中的208.131.161.209:53062为例，分析一下对等方之间的交互过程。如图六所示，只分析TCP之上的部分。约定对等方A指的是208.131.161.209:53062，对等方B指的是172.16.8.93:3012.

图六 对等方间通信过程

       建立TCP连接之后，对等方之间的交互过程包括以下几步：

（1）       握手，通过Handshake分组实现。

（2）       互换所拥有的资源的情况。通过Bitfield分组实现。该例中，对等方B尚未下载任何资   源，故公布资源拥有情况的只有对等方A。对等方A通过分组283公布了自己资源拥有情况。

（3）       互通对资源的意愿情况，包括interested、nointerested、choke、unchoke等4种。

（4）       互相请求资源，通过request piece、piece分组实现。

（5）       断开连接。因为peer wire协议使用了TCP方式，对等方A与对等方B断开连接时，只需要断开他们之间的TCP连接即可。

图七 Handshake数据包的上层内容

       握手：Handshake：<pstrlen><pstr><reserved><info_hash><peer_id>

       pstrlen:<pstr>的字符串长度，单个字节。

           pstr: 协议的标识符，字符串类型。

           reserved: 8 个保留字节。当前的所有实现都使用全0.这些字节里面的每一个字节都可以用来                      改变协议的行为。来自Bram 的邮件建议应该首先使用后面的位，以便可以使用前面                      的位来改变后面位的意义。

          info_hash: 元信息文件中info 键(key)对应值的20 字节SHA1哈希。这个nfo_hash和在tracker                      请求中info_hash 是同一个。

          peer_id: 用于唯一标识客户端的20 字节字符串。这个peer_id 通常跟在tracker 请求中传送                      的peer_id相同(但也不尽然，例如在Azureus，就有一个匿名选项)。

       在BitTorrent 协议1.0版本，pstrlen = 19, pstr = “BitTorrent protocol”。

       连接的发起者应该立即发送握手报文。如果接收方能够同时地服务多个torrent，它会等待发起者的握手报文(torrent 由infohash 唯一标识)。尽管如此，一旦接收方看到握手报文中的info_hash 部分，接收方必须尽快响应。tracker 的NAT-checking 特性不会发送握手报文的peer_id 字段。

       如果一个客户端接收到一个握手报文，并且该客户端没有服务这个报文的info_hash，那么该客户端必须丢弃该连接。如果一个连接发起者接收到一个握手报文，并且该报文中peer_id 与期望的peer_id 不匹配，那么连接发起者应该丢弃该连接。注意发起者可能接收来自tracker 的peer信息，该信息包含peer 注册的peer_id。来自于tracker的peer_id 需要匹配握手报文中的peer_id。

图八 Bitfiled数据包上层数据

       bitfield:<len=0001+X><id=5><bitfield>

       itfield 报文可能仅在握手序列发送之后，其他消息发送之前立即发送。它是可选的，如果一个客户端没有piece(片)，就不需要发送该报文。bitfield 报文长度可变，其中x 是bitfield的长度。payload 是一个bitfield，该bitfield表示已经成功下载的piece(片)。第一个字节的高位相当于piece 索引0。设置为0的位表示一个没有的piece，设置为1 的位表示有效的和可用的piece。末尾的冗余位设置为0。

       长度不对的bitfield将被认为是一个错误。如果客户端接收到长度不对的bitfield 或者bitfield 有任一冗余位集，它应该丢弃这个连接。

图九 request piece数据包上层部分

       request piece分组结构如上图所示。

       该报文长度固定，用于请求一个块。payload包含如下信息：

       index：整数，指定从零开始的piece索引。

       begin：整数，指定piece中从零开始的字节偏移。

       length：整数，指定请求的长度。

依据BT应用程序的这些特点，检测BT流量存在的一种方法主要分4个步骤：

1、特征字符串匹配。假如分组的负载中出现了字符串“BitTorrentprotocol”，表明有BT客户机运行，将该分组中的源IP地址和源端口号记为{IP.port}对，凡与此{IP，port}对相关的分组均判定为BT流量。

2、特征端口匹配。所有使用6881-6889作为端口号的分组均被判定为BT流量。

3、tracker服务器规则。将目的端口号为8000、8080、6969和2710的TCP分组的目的IP地址标记为tracker服务器，将源端口号为8000、8080、6969和2710的TCP分组的源IP地址标记为tracker服务器，所有与tracker服务器相关的分组均被判定为BT流量。

4、通过以上3步可以较准确地判定流中是否存在BT业务，但并不能保证找出所有的BT分组。为了进一步增加判定的准确性。可使用流之间关系信息。例如某一时间段内，相同两台主机之间的流被关联在一起；来自不同主机的有着相同目的地址和目的端口号的流被关联起来；在某一时间段内来自同一主机的流被关联起来等。