作为一种广泛的,流行的下载模式.Bittorrent协议的使用给我们的互联网下载带了新的概念。那么在Bittorrent协议交互中我们如何理解这个过程呢?针对这方面的数据传输,我们现在来详细介绍一下。
Bittorrent协议交互
考虑到不同软件对Bittorrent协议的实现不同,我们下面的协议交互测量实验只针对于数据传输前后的报文进行分析。我们实验用的是BitComet 0.63。以下是测量的一些现象:(假设我们的机器是主机A)
1、无种子时的通信现象
在没有下载种子和提交下载命令的时候,可以看到主机与一系列IP地址的远端主机通信,发送大小为98字节的UDP报文,使用的端口都是17638。这些数据包可以看作是BitComet程序特有的给P2P网络主机发送的消息包(因为在ABC下载程序中中就没有这些UDP报文)
2、与tracker服务器通信
由于Tracker服务器提供Http/Https的服务,对Http/Https的请求做出响应。其中响应里包含了peer的列表,帮助主机A获得所需的信息。主机A通过.torrent文件中所记录的信息:tracker服务器列表和文件的info值发起对tracker服务器的HTTP连接,并用GET 命令获得peer列表。
3、与peers通信
当主机获得peer列表后将主动向这些IP地址发起TCP连接,端口随机分布,而且之后的数据传输都建立在TCP之上。在一次观测中发现一个IP(222.95.92.4 假设为B)地址占据了主要的流量,下面就对他们的通信进行观测分析:
在一次实验中(5M buffer)我们的主机A 与B的发送数据统计如下
|
Packets |
Bites |
A ->B |
2238 |
2142621 |
B->A |
1886 |
1367552 |
可以看到B作为A的主要数据来源, 也从A受到了相当的数据量,说明B地址的主机不是一个种子,而是与A一样的下载者。
在三次TCP握手之后,A主机向B发起Bittorrent handshake,B回送一个handshake. 其中关于handshake报文的内容信息可以参考,值得注意的是握手以字符19(0x13)开始,跟着是字符串'BitTorrent protocol',这可以作为检测BT下载的一个关键字信息。握手完毕之后是长度前缀和信息轮流出现的数据流。零长度信息用来保持连接,被忽略。这种信息一般2分钟发一次,但是在等待数据期间超时很容易发生。
Bittorrent协议中相关概念
Tracker:收集下载者信息的服务器,并将此信息提供给其他下载者,使下载者们相互连接起来,传输数据。
种子:指一个下载任务中所有文件都被某下载者完整的下载,此时下载者成为一个种子。发布者本身发布的文件就是原始种子。
做种:发布者提供下载任务的全部内容的行为;下载者下载完成后继续提供给他人下载的行为。