BT下载原理简介

1.BT下载原理简介

BT是一种用来进行文件下载的共享软件（不是“变态”），全名叫"BitTorrent"。BitTorrent 是一个多点下载的源码公开的P2P软件，使用非常方便，就像一个浏览器插件，很适合新发布的热门下载。其特点简单的说就是：下载的人越多，速度越快。

一般来讲，下载是把文件由服务器端传送到客户端，例如FTP，HTTP，PUB等等。工作原理如下图：

但是这样就出现了一个问题，随着用户的增多，对带宽的要求也随之增多，用户过多就会造成瓶颈，而且搞不好还会把服务器挂掉，所以很多的服务器会都有用户人数的限制，下载速度的限制，这样就给用户造成了诸多的不便。

但BT就不同，用BT下载反而是用户越多，下载越快，这是为什么呢？因为BT用的是一种传销的方式来达到共享的，工作原理如下图：

BT首先在上传者端把一个文件分成了Z个部分，甲在服务器随机下载了第N各部分，乙在服务器随机下载了第M个部分，这样甲的BT就会根据情况到乙的电脑上去拿乙已经下载好的M部分，乙的BT就会根据情况去到甲的电脑上去拿甲已经下载好的N部分，这样就不但减轻了服务器端得负荷，也加快了用户方（甲乙）的下载速度，效率也提高了，更同样

减少了地域之间的限制。比如说丙要连到服务器去下载的话可能才几K，但是要是到甲和乙的电脑上去拿就快得多了。所以说用的人越多，下载的人越多，大家也就越快，BT的优越性就在这里。而且，在你下载的同时，你也在上传（别人从你的电脑上拿那个文件的某个部分），所以说在享受别人提供的下载的同时，你也在贡献。

2.BT协议介绍

2.1. 综述

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

一个BT式文件分发需要以下实体：

●一个普通网络服务器

●一个静态元信息文件（'Metainfo' file）

●一个BT Tracker

●一个“原始”下载者（'original' downloader）

●网络终端的浏览器

●网络终端的下载者

这里假设理想情况下一个文件有多个网络终端的下载者。

架设一个BT服务器步骤如下：

1.开始运行Tracker（已运行的跳过这一步）；

2.开始运行普通网络服务器程序，如Apache，已运行的跳过这一步；

3.在网络服务器上将.torrent文件关联到Mime类型application/x-bittorrent（已做过关联的跳过这一步）；

4.用要发布的完整文件和Tracker的URL创建一个元信息文件（.torrent文件）；

5.将元信息文件放置在网络服务器上；

6.在网页上发布元信息文件（.torrent文件）的链接；

7.原始下载者开始提供完整的文件（原本）。

通过BT下载步骤如下：

1.安装BT客户端程序（已安装的跳过这一步）；

2.上网；

3.点击一个链到.torrent文件的链接；

4.选择本地存储路径，或者选定未完成的下载的续传；

5.等待下载完成；

6.下载者退出下载（之前下载者不停止上传）。

连通性如下：

●网站正常提供静态文件，并且启动客户端上的BitTorrent helper（这里说官方的客户端程

序）；

●Tracker即时接收所有下载者信息，并且给每个下载者一份随机的peer列表。通过HTTP

或HTTPS协议实现；

●下载者定时向Tracker登记，使之知道每个人的进度，并和那些直接连接上的peer互相进

行数据的上传下载。这些连接遵循BitTorrent peer协议，通过TCP协议进行通信。

●原始下载者只上传不下载，他拥有整个文件，所以向网络中传输完文件的所有部分是很

必要的。在一些人气很旺的下载中，原始下载者经常可以在较短的时间后退出上传，因为许多下载已经完成，并且可能依然在运行（此时相当于替原始下载者接着提供上传）。

2.2. B编码及元信息文件

元信息文件和Tracker的回应信息都以一种简单高效可扩展的格式（Bencoding，B编码格式）传送。B编码过的信息就是字典和列表的嵌套（像在Python中一样），这些字典和列表包含字符串和整型数据。它的可扩展性是因为字典中存在被忽略的关键值（key），所以附加可选的关键值也可以在以后添加。

B编码的规则如下：

●字符串表示为前缀十进制的字符串长度加冒号再跟原字符串。

如4:spam就相当于'spam'。

●整型数据的表示是前面加'i'后面加'e'中间是十进制数，如i3e就相当于3，i-3e就是-3。整

型数据没有长度限制。i-0e无效，所有以'i0'开头的除了代表0的i0e，其它都无效。

●列表编码为一个'l'开头，后面跟它所包含的项目（已经被编码过）最后加一个'e'，比如

l4:spam4:eggse 就等于['spam', 'eggs'] 。

●字典编码为一个'd'开头，后面是关键值（key）及其对应值轮流出现，最后加一个'e'。

如：d3:cow3:moo4:spam4:eggse 相当于{'cow': 'moo', 'spam': 'eggs'} d4:spaml1:a1:bee 相当于{'spam': ['a', 'b']} 关键值必须是处理过的字符串（用原始字符串编码的，而不是数字字母混合编码的）。

元信息文件就是B编码的有以下关键值的字典（括号里面的字是简译的关键值中文意思，不作为关键值一部分，后同）：

announce（声明）：Tracker的URL。

info（信息）：此关键值对应一个包含以下关键值的字典。

●关键值name对应一个字符串，代表默认的下载文件（或保存时目录)的名字。它是

纯粹建议性的。

●关键值piece length（块长）对应文件分割成的块的字节数。出于传输需要，文件被

分割成大小相等的块，除了最后一块可能会被文件尾截断而小一些（剩下的大小不

足一个块长）。块长一般来说是2的权值，大部分设块长为256K即2的18次幂

（BitTorrent官方版3.2版本以前的默认值是1M，2的20次幂）。

●关键值pieces（块）对应一个字符串，此字符串长度是20的倍数。它可以再分成每

20字节一段的多个字符串，分别对应块在相应索引中的SHA1校验码（hash）。

●关键值length（长度）和files（文件），它们不能同时出现也不能都不出现。当length

出现说明这个元信息文件只是提供单文件下载（the single file case），否则说明是多

文件下载（the multi-file case），载到一个目录里。

单文件情况下，length对应文件长度的字节数。多文件情况被看作是把许多单文件按文件列表中的顺序连成一个大文件下载，

而关键值files就对应文件列表，是一个字典的列表，其中每个字典又包含以下关键值：

●length（长度）：文件长度的字节数。

●path（路径）：一个包含字符串的列表，字符串就是子目录名，最后一项的字符串

就是文件本身的文件名。（一个长度为零的length表单是错误的。）

2.3. Tracker HTTP协议

Tracker质询是双向的。Tracker通过HTTP协议的GET参数获得信息，然后返回一个B编码后的信息。尽管Tracker需要在自己的服务器端执行，但它运行流畅就像Apache的一个嵌入模块。

Tracker的GET请求有如下关键值：

●info_hash

20字节长的SHA1验证码，就是元信息文件中的info值中分出来的字符串进行B编码

以后的信息，是元信息文件的一个支链。这个值必须是自动转换的。

●peer_id

一个20字节长的字符串，是每个用户开始新下载时随机生成的ID。这个值也必须

是自动转换的。

●ip

一个非强制性的参数（可有可无）给出peer所在的IP（或DNS主机名），一般是和Tracker 同机器的原始下载者得到后用来散发文件。

●port

监听端口，官方默认的是从6881端口开始试，如果端口被占用则依次向后推一个端口直到找到空闲端口，到6889端口没找到就放弃。

●uploaded

目前总上传量，编码为十进制ASCII码。

●downloaded

目前总下载量，编码为十进制ASCII码。

●left

还要下载的字节数，编码为十进制ASCII码。这个数不能通过文件长度和已下载数出来的，因为文件可能是续传的，还可能有一些已经下载的数据不能通过完整性检查必须被重新下载。

●event

这是个非强制性的关键值，有started，completed或stopped（或empty，等同于未运行）三种值。如果没有这个关键值，说明下载状态的声明也会从下载者那里定期发出。首次开始下载时发出started值，完成下载时发出completed。当文件完整后再开始，没有

completed发出，下载者中止下载时发出stopped。

Tracker的回应也是B编码字典。如果Tracker回应中有关键值failure reason（失败原因），则对应一个人易读懂的字符串信息，解释质询失败的原因，不需要其它关键值。

否则，回应必须有两个关键值：

●interval（间隔）：对应下载者定期发出请求的间隔秒数；

●peers，peers是个包含字典的列表，每个字典对应一个peer，里面包含关键值peer id、

ip和port，分别对应peer自选ID、IP地址或DNS主机名的字符串以及端口号。记住

假如下载者发生一个意外事件或者想要更多的peer列表，下载者会不定期重发请

求。

如果你想对元信息文件或者Tracker质询进行扩展，请与Bram Cohen进行协调，确保所有扩展都兼容。

（downloader 通过HTTP 的GET 命令来向tracker 发送查询请求，tracker 响应一个peers 的列表）

2.4. BitTorrent peer protocol

BT对等协议基于TCP，它很有效率，并不需要设置任何socket选项。（译注：BT对等协议指的是peer与peer之间交换信息的协议）

对等的两个连接是对称的，消息在两个方向上同样的传递，数据也可以在任何一个方向上流

动。一旦某个peer下载完了一个片断，并且也检查了它的完整性，那么它就向它所有的peers 宣布它拥有了这个片断。

Peer之间的上载和下载关系有其简单的机制来保证。

在连接的任一端包含两个bit位用来指示连接状态：choked or not、interested or not。

连接的任何一端都包含两比特的状态信息：choked or not（是否choked），interested or not（是否感兴趣）。Choking是通知对方，没有数据可以发送，除非unchoking发生。Choking的原因以及技术后文解释。

一旦一端状态变为interested，而另一端变为非choking，那么数据传输就开始了。（也就是说，一个peer，如果想从它的某个peer那里得到数据，那么，它首先必须将它两之间的连接设置为interested，其实就是发一个消息过去，而另一个peer，要检查它是否应该给这个家伙发送数据，如果它对这个家伙是unchoke，那么就可以给它发数据，否则还是不能给它数据）Interested状态必须一直被设置――任何时候。要用点技巧才能比较好的实现这个目的，但它使得下载者能够立刻知道哪些peers将开始下载。

对等协议

由一个握手开始，后面是循环的消息流，每个消息的前面，都有一个数字来表示消息的长度。握手的过程

首先是先发送19，跟着是字符串“BitTorrent protocol”。19就是“Bittorrent protocol”的长度。后续的所有的整数，都采用big-endian 来编码为4个字节在协议名称之后，是8个保留的字节，这些字节当前都设置为0。接下来对元文件中的info 信息，通过sha1 计算后得到的hash值，20个字节长。接收消息方，也会对info 进行一个hash 运算，如果这两个结果不一样，那么说明对方要的文件，并不是自己所要提供的，所以切断连接。接下来是20个字节的peer id。

接下来就是以消息长度开始的消息流，这是可选的。长度为0 的消息，用于保持连接的活动状态，被忽略。通常每隔2分钟发送一个这样的消息。

其它类型的消息，都有一个字节长的消息类型，可能的值如下：

‘choke’, ‘unchoe’, ‘interested’, not interested’类型的消息不再含有其它数据了。

‘bitfield’永远也仅仅是第一个被发送的消息。它的数据实际是一个位图，如果downloader 已经发送了某个片断，那么对应的位置1，否则置0。Downloaders如果一个片断也没有，可以忽略这个消息。（通过这个消息，能知道什么了？）

‘have’类型的消息，后面的数据是一个简单的数字，它是下载者刚刚下载完并检查过完整性的片断的索引。（由此，可以看到，peer通过这种消息，很快就相互了解了谁都有什么片断）

‘request’类型的消息，后面包含索引、开始位置和长度)长度是2的幂。当前的实现都用的是215 ，而关闭连接的时候，请求一个超过2 17的长度。(这种类型的消息，就是当一个peer希望另一个peer给它提供片断的时候，发出的请求)

‘cancel’类型的消息，它的数据和’request’消息一样。它们通常只在下载趋向完成的时候发送，也就是在‘结束模式“阶段发送。在一次下载接近完成的时候，最后的几个片断需要很长时间才能下载完。为了确保最后几个片断尽快下载完，它向所有的peers发送下载请求。为了保证这不带来可怕的低效，一旦某个片断下载完成，它就其它peers发送’cancel’消息。（意思就是说，我不要这个片断了，你要是准备好了，也不用给我发了，可以想象，如果对方还是把数据发送过来了，那么这边必须忽略这些重复的数据）。

‘piece’类型的消息，后面保护索引号、开始位置和实际的数据。注意，这种类型的消息和‘request’消息之间有潜在的联系（译注：因为通常有了request消息之后，才会响应‘piece’消息）。如果choke和unchoke消息发送的过于迅速，或者，传输速度变的很慢，那么可能

会读到一些并不是所期望的片断。（也就是说，有时候读到了一些片断，但这些片断并不是所想要的）

Choking 算法

BT下载过程中没有一个统一的资源调度，所有的下载者都希望能够尽可能的提高下载速度，对等体之间从任何对端下载，同时礼尚往来的进行上传，就是说，在下载上传形成对子，对于不合作方，则在上传方向进行Choke（阻塞），比如我和你之间形成Pair，但是你只想下载不想上传，则把你Choke。Choking用于阶段性的阻止上载，但是在Choking结束后，上传可以继续进行。

Choking算法不是BT链路协议的技术组成，但是对提高下载效率很有作用，一个好的Choking应该能够利用各种资源，保障参加下载的每个用户获得理想的下载速度，同时杜绝有人只下载不上载。

每一个BT客户一般会不阻塞一定数量的对等体，所以应该决定哪些Peer应该不去阻塞，这个决定是是基于当前的下载速度，为提高效率，BT对20S内的下载速度进行计算，同时为避免频繁的计算在成效率下降，BT每隔10S进行一次计算，10S的时间也足够TCP机制达到最高的下载速度。另外，为了始终选择到能够提供最大下载速度的Peer，BT会使用一种‘optimistic unchoke’机制，每隔30s就循环的地Choke一个Peer，这样有机会去查询是否还有更好的下载对象。

2.5. BT限流的解决方案

1、利用客户端与客户端连接的端口号：

BT实现中，提供了一个端口范围（6881～6889），如果通过这个范围的所有端口来限流，一些运营商曾采用这种方法来封杀BT，如长城宽带和重庆网通曾采用这种方法来封堵BT。

这种方法在前期一定程度上是可用的；因为：BT的官方网站提供了一个默认的监听端口范围（6881～6889）。但是，这种方法比较片面，因为通过一定的技术手段可以改变这个端口范围（网上有）；另外，BT的客户端较多，它们所采用的端口范围及实现方式各不相同（见下表）。

所以，采用这种方来对BT进行限流效果不是很好。

2、对协议进行分析

对所有的ip 包都进行检查，如果ip 包的数据区包含BT 对等协议的特征“BitTorrent protocol”（BT协议规定），那么可以标识这是一个BT流，标识了以后，就可以采取相应的措施（CAR）对它进行限流。

以下是通过对几种BT客户端的报文分析来验证上述方案。

客户端：贪婪ABC

由上图可以看贪婪ABC建立连接的过程是：

1、TCP的三次握手。

2、握手成功后，紧接着是BT对等协议的二次握手。

3、握手成功后，进行数据的传输。

由图分析可知：

1、TCP三此握手与BT对等协议二次握手用的端口号都是一样的，并且以后得数据

传输用的端口号也和前两者是一样的。

2、TCP头之后的BT对等协议的报文格式对应如下：

19－对应图中的“13（十六进制）”

…B?－对应图中的“42（十六进制）”以后对应“Bittorrent protocol”

八个保留字节－对应图中的八个“00（十六进制）”

info 信息－对应的报文有20个字节长

总长为48字节

客户端：BitTorrent Plus! 2

由上图可以看BitTorrent Plus! 2建立连接的过程是：

1、TCP的三次握手。

2、握手成功后，紧接着是BT对等协议的二次握手。

3、握手成功后，进行数据的传输。

由图分析可知：

1、TCP三此握手与BT对等协议二次握手用的端口号都是一样的，并且以后得数据

传输用的端口号也和前两者是一样的。

2、TCP头之后的BT对等协议的报文格式对应如下：

19－对应图中的“13（十六进制）”

…B?－对应图中的“42（十六进制）”以后对应“Bittorrent protocol”

八个保留字节－对应图中的八个“00（十六进制）”

info 信息－对应的报文有20个字节长

peer id－20个字节

总长为68字节

客户端：BitComet

由上图可以看BitTorrent Plus! 2建立连接的过程是：

1、TCP的三次握手。

2、握手成功后，紧接着是BT对等协议的二次握手。

3、握手成功后，进行数据的传输（图中显示握手没有成功）。

由图分析可知：

1、TCP三此握手与BT对等协议二次握手用的端口号都是一样的，并且以后得数据

传输用的端口号也和前两者是一样的。

2、TCP头之后的BT对等协议的报文格式对应如下：

19－对应图中的“13（十六进制）”

…B?－对应图中的“42（十六进制）”以后对应“Bittorrent protocol”

八个保留字节－对应图中的八个“00（十六进制）”

info 信息－对应的报文有20个字节长

peer id－20个字节

总长为68字节

总结：

1、三个不同客户端的报文验证了BT对等协议的连接过程是：

（1）TCP的三次握手。

（2）握手成功后，紧接着是BT对等协议的二次握手。

（3）握手成功后，进行数据的传输。

2、TCP三此握手与BT对等协议二次握手用的端口号都是一样的，并且以后得数据传输用的端口号也和前两者是一样的。

3、TCP头之后的BT对等协议的报文格式对应如下：

19－对应图中的“13（十六进制）”

…B?－对应图中的“42（十六进制）”以后对应“Bittorrent protocol”

八个保留字节－对应图中的八个“00（十六进制）”

info 信息－对应的报文有20个字节长