BT协议分析(1)—1.0协议

  • 简述

BT下载是采用P2P的下载方式,下载的大致形式采用如下图所示,处于图示中心的称为Tracker服务器,其余称为Peer。

 

缺点

1.资源的安全性

2.资源的实效性(没有上传者则BT也将失效)

3.版权

  • 协议分析

对BT协议(1.0)的分析主要包含4个部分:

1.种子文件的分析

2.同Tracker服务器的通讯(采用HTTP协议)

3.同其他peer(配合/协同者)的通讯(采用TCP协议)

4.总结

分析前的了解

在这些分析之前,需要先了解两点BT协议采用的基础:

1.BT协议中采用的单位

2.BT协议中采用的编码

1--单位说明:

下载的文件被划分成大小相同的piece(除了最后一个),以1 – 256KB (假设一个piece=256KB)称为第1个piece,之后按顺序称呼,每个piece都有独特的hash值,作为版本号。

piece下面又划分了block,block一般为固定值16KB,在同peer(同为下载者的对象主机)之间每次传输的单位为block,client(本机)需要记录该block的是属于那个piece的block。

Tips:

1.piece需要是16KB的整数倍

2.对piece的校验流程:

下载完成 è 使用标准算法(Sha1)计算1的hash值 è 比较种子文件的hash值同2的hash值

2--单位说明:

种子文件又成metafile(元文件),文件内部的编码采用BenCode(B编码),BenCode中存在4中类型。

类型


格式及范例


字符串


格式:<字符串长度>:<字符串>

范例:字符串good

4:good


整型


格式:i<十进制的整型数>e => i(interge)为起始符,e(end)为结束符

范例:数字5

i5e


列表


格式:l<其他类型>e =>l(list)为起始符,e(end)为结束符

范例:字符串good + 字符串nihao

l4:good5:nihaoe


字典


格式:d<关键字><值>e =>d(dictionary)为起始符,e(end) 其中:关键字必须为字符串,值则未限定

范例:good为key,列表nihao和hello为值

d4:goodl5:nihao5:helloee

协议分析(1)--种子文件分析

(a)枚举文件说明

=>以文本打开单文件.torrent文件:

d8:announce35:http://192.168.73.197:8080/announce10:created by13:BitComet/1.3713:creation datei1472779924e8:encoding5:UTF-84:infod4:ed2k16:??~_x0010_€?_x001D_8_x0007_/vG8:filehash20:E氙率>w?⒂?y<?伖6:lengthi30791e4:name22:btdownloadservice.mmap10:name.utf-822:btdownloadservice.mmap12:piece lengthi32768e6:pieces20:E氙率>w?⒂?y<?伖e5:nodesll4:6881i0eel5:37049i0eel5:33281i0eel5:18021i0eel5:51413i0eel5:21793i0eel5:51413i0eel5:18672i0eel4:6881i0eel4:5712i0eee9:publisher10:hejianglin15:publisher.utf-810:hejiangline

解析情况

=>以文本打开多文件.torrent文件:

d8:announce35:http://192.168.73.197:8080/announce10:created by13:BitComet/1.3713:creation datei1472781603e8:encoding5:UTF-84:infod5:filesld4:ed2k16:鳛 *羉_x0007_実?⒚!彐o8:filehash20:碊?a?戎7暰毿警U_x0019_6?:lengthi5e4:pathl9:test1.txte10:path.utf-8l9:test1.txteed6:lengthi32763e4:pathl104:_____padding_file_0_濡傛灉鎮ㄧ湅鍒版鏂囦欢锛岃鍗囩骇鍒癇itComet(姣旂壒褰楁槦)0.85鎴栦互涓婄増鏈琠___e10:path.utf-8l104:_____padding_file_0_濡傛灉鎮ㄧ湅鍒版鏂囦欢锛岃鍗囩骇鍒癇itComet(姣旂壒褰楁槦)0.85鎴栦互涓婄増鏈琠___eed4:ed2k16:?c]獝狎褧Ao顫?:filehash20:_x0010_烱<P装遰?浧飷f?6:lengthi5e4:pathl9:test2.txte10:path.utf-8l9:test2.txteee4:name3:dir10:name.utf-83:dir12:piece lengthi32768e6:pieces40:B橫?鬝笫Pi烃}璭鑱k_x0010_烱<P装遰?浧飷f?e5:nodesll4:6881i0eel5:37049i0eel5:33281i0eel5:18021i0eel5:51413i0eel5:21793i0eel5:56963i0eel5:38322i0eel5:26121i0eel4:5712i0eee9:publisher10:xxxxxxxxxx15:publisher.utf-810:xxxxxxxxxxe

解析情况

 

关于各个关键key的作用请看下面(b)key的说明

(b)key说明

=>单/多文件都包含的key说明

key


说明


announce


Tracker的主服务器


announce-list(可选)


Tracker服务器备用列表


creation date(可选)


种子文件建立的时间


comment(可选):


种子文件的注释


created by(可选)


创建人或创建程序的信息


info


文件信息,二种情况:单文件结构或多文件结构

=>单文件中的info说明

key


说明


length


文件的大小,用byte计算


md5sum(可选)


MD5校验和,不使用


name


文件名


piece length


每个piece的大小,用byte计算


pieces


每个piece的20个字节的SHAT Hash的值

=>多文件中的info说明

key


说明


files


表示文件的名字和大小下面说明


md5sum(可选)


MD5校验和,不使用


name


目录名字


piece length


每个piece的大小,用byte计算


pieces


每个piece的20个字节的SHAT Hash的值

=>多文件中的files说明

key


说明


lenghth


文件的大小,用byte计算


path


文件的名字


path.utf-8


文件名的UTF-8编码

有点乱,请看(c)总结

(c)总结

=>单文件torrent的种子结构信息

├─announce

├─announce-list

├─comment

├─comment.utf-8

├─creation date

├─encoding

├─info

│ ├─length

│ ├─name

│ ├─name.utf-8

│ ├─piece length

│ ├─pieces

│ ├─publisher

│ ├─publisher-url

│ ├─publisher-url.utf-8

│ └─publisher.utf-8

└─nodes //dht

=>多文件torrent的种子结构信息

├─announce

├─announce-list

├─comment

├─comment.utf-8

├─creation date

├─encoding

├─info

│ ├─files

│ │ ├─length

│ │ ├─path

│ │ └─path.utf-8

│ ├─name

│ ├─name.utf-8

│ ├─piece length

│ ├─pieces

│ ├─publisher

│ ├─publisher-url

│ ├─publisher-url.utf-8

│ └─publisher.utf-8

└─nodes //dht

 

BT协议分析(2)--Tracker服务器的通讯(采用HTTP协议GET方式)

(a)目的

1.将下载进度报告给Tracker以便Tracker进行相关统计

2.获取当前下载同一个资源的peer的IP和端口号

(b)操作

=>主机发送给Tracker服务器请求当前连接着同一文件的peer地址

格式:<Tracker服务器地址>?<parm1=value1>&<><parm2=value2>...

例如:

http://tk.greedland.net/announce?

info_hash=01234567890123456789

&peer_id=01234567890123456789

&port=3210

&compact=1

&uploaded=0

&downloaded=0

&left=8000000

&event=started

参数说明:

参数


意义


info_hash


种子文件info对应的hash值(固定20字节)


peer_id


随机标识符,表示自身的请求(固定20字节)


port


主机监听端口号,用与同其他peer的连接请求


uploaded


当前的上传总量(单位Byte)


downloaded


当前的下载总量(单位Byte)


left


剩余下载量,即下载总量 - 已下载量


compact


Tracker服务器的反馈当前peer的方式

1 = 每个peer占6个字节,前4字节为peer的IP地址,其余为peer的端口号


event


主机的下载状态:

start = 主机开始下载(主机同Tracker首次通信时)

completed = 主机已完成下载

stoped = 结束,主机即将关闭


ip


可选,主机IP地址


numwant


可选,Tracker服务器反馈peer的数量(默认50个)


key


可选,随机标识符


trackerid


可选

=>Tracker服务器返回结果(B编码的字典)

d //

8:complete //..已完成数量

i100e

10:incomplete // ..未完成数量

i200e

8:interval // ..间隔时间

i1800e

5:peers // ..当前peers

300:......

e

参数说明:

关键字


意义


failure reason


GET失败的原因(human string)


warning message


GET警告字符串(human string)


interval


主机下次连接Tracker所需时间(单位:秒)


min interval


主机下次连接Tracker所需的最小时间(单位:秒)


tracked id


指明Tracker的ID


complete


整数,当前存在多少个peer已完成该文件的下载


incomplete


整数,当前存在多少个peer未完成该文件的下载


peers


各个peer的IP和端口号,字符串

具体分析:

URL的具体情况:/announce?info_hash=%98%13%c7%a0%87%eb%a7%a6gh%dc%86kU%03m%ff%2fr%94&peer_id=-UT348B-%03%a6%df%91%063%f8%daC%1e%02F&port=24842&uploaded=0&downloaded=0&left=13547779828&corrupt=0&key=917599C2&numwant=200&compact=1&no_peer_id=1 HTTP/1.1

回包信息:

BT协议分析(3)--同其他peer(配合/协同者)的通讯(采用TCP协议)

(a)通讯协议格式说明

主机同peer之间的通讯格式主要分为两种:握手及其他

=>握手采用的格式和参数说明

格式:<pstrlen><pstr><reserved><info_hash><peer_id>


参数


所占字节数


意义


pstrlen


1


pstr的长度,为固定值19


pstr


19


BitTorrent protocol,BitTorrent协议的关键字


reserved


8


扩展字节,一般设置为0


info_hash


20


同主机发送到Tracker的Get请求中的info_hash为同值


peer_id


20


识别BT软件类型

=>其他的参数说明

格式:<length prefix><message ID><payload>


参数


所占字节数


意义


length prefix


4


表示message ID 和 payload的长度和


message ID


1


十进制整数,表示消息的编号


payload


随机


负载,表示消息的内容

message ID说明

消息类型


消息格式


所占字节数


意义


keep_alive


<len=0000>

即:0000


4


2分钟内没有向peer发送任何消息,则发送此消息


choke


<len=0001><id=0>

即:00010


5


阻塞接收消息的peer,即该peer无法下载主机资源


unchoke


<len=0001><id=1>

即:00011


5


解除阻塞。


interested


<len=0001><id=2>

即:00012


5


通知peer,peer上存在主机上没有的资源


not interested


<len=0001><id=3>

即:00013


5


通知peer,peer上存在的资源主机上都有


have


<len=0005><id=4><piece index>

即:00054<piece index>


9


通知所有peer,主机拥有此index的piece


bitfield


<len=0001 + X(见注1)><id=5><bitfield>

即:< 1(表示id长度) +bitfile的长度>5<bitfield>


不固定


主机同peer端交换当前资源的信息


request


<len=0013><id=6><index><begin><length>

即:000136<piece的索引><piece的偏移><请求的数据长度>


17


主机请求获取peer上的资源


piece


<len=0009+X><id=7><index><begin><block>

即:<9+block的长度(见注2)>7<index><begin><block>


不固定


主机上传资源到peer


cancel


<len=0013><id=8><index><begin><length>即:

000138<piece的索引><piece的偏移><请求的数据长度>


17


同request的作用相反,用于取消获取的请求


port


<len=0003><id=9><listen-port>

即:00039<监听端口>


7


只在支持DHT(见注3)的主机上使用,指明DHT监听的端口号

注1:

X:表示为(Bit)位图的长度,每个Bit代表一个Piece,假设当前文件为801个piece,则需要801个Bit来表示,也即101个字节,第一个Bit表示第一个piece,Bit为1表明当前主机拥有此piece。

注2:

9 = id(1) + index(4) + begin(4)

X表示block的长度

block表示传输的资源数据(一般为slice的长度)

注3:

DHT:Distributed Hash Table(分布式哈希表),每个客户端都可以充当服务器,这样在没有Tarcker服务器的时候,主机仍然可以在其他peer上下载文件。采用UDP协议(采用的端口号同TCP端口号一致)

完全不知道是什么?请看(b)交互步骤

 

(b)交互步骤

步骤1.建立握手消息,创建针对peer的状态变量

当前主机对成功建立连接peer都需要维护一个和peer之间的状态信息

状态变量


意义


am_chocking


意义:主机阻塞标志

1 = 主机同peer信息阻塞,peer不可以获取主机数据

0 = 非阻塞,peer可以获取主机数据

default = 1


am_interested


意义:主机数据不完整标志

1 = peer存在主机没有的piece

0 = peer上的piece主机上都有

default = 0


peer_chocking


意义:peer阻塞标志

1 = peer同当前主机阻塞,主机不可获取peer端数据

0 = 非阻塞,主机可以获取peer数据

default = 1


peer_interested


意义:peer数据不完整标志

1 = 主机存在peer没有的piece(数据)

0 = 主机上的piece,peer上都有

default = 0

步骤2.互换所拥有的资源情况

采用上述的bitfield交换数据

步骤3.交流对资源的意愿信息

采用上述的choke/unchoke/interested/not interested /have 交换数据

步骤4.互相请求资源

采用上述的request / cancel / piece交换数据

步骤5.断开连接

(c)交互算法

下载策略:

1.片段选择法

a)向一个peer请求完整的一个piece

b)优先请求当前piece拥有者最少的piece

c)在最开始采用随机下载piece

d)但下载中遇上某个piece传输速度慢的情况,客户端向所有的piece发送该piece的block的请求

片段选择策略:

在开始和最后的阶段,随机的去多个peer上获取相同的block

2.阻塞算法

性能优化策略。

每个客户端同固定数量的peer保持疏通,如何判断保持疏通的对象? (根据与peer的连接速度)

BT协议采用每10秒计算与当前peer的连接速度,选取速度最快的4个选择疏通.

另外在处理空闲连接是否具有更好的下载速度时,BT协议为每个peer设定一个optimistic unchoking peer,

每个主机每隔30s计算当前主机同该peer的传输速度,优于最优的那个则采用为4个选择疏通对象的其中一个。

且每隔30s置换一个peer对象.

当主机下载结束后,是如何选择4个疏通对象的?于传输速度最优的4个peer保持疏通关系

  • 总结

以图为例,BT采取的流程大致如下。

  • 参考

http://www.bittorrent.org/

http://www.cnblogs.com/happyhotty/articles/2064058.html

http://www.cnblogs.com/DxSoft/archive/2012/02/11/2346314.html

http://blog.chinaunix.net/uid-26548237-id-3056731.html

时间: 09-06

BT协议分析(1)—1.0协议的相关文章

linux 网络协议分析---3

本章节主要介绍linxu网络模型.以及常用的网络协议分析以太网协议.IP协议.TCP协议.UDP协议 一.网络模型 TCP/IP分层模型的四个协议层分别完成以下的功能: 第一层 网络接口层 网络接口层包括用于协作IP数据在已有网络介质上传输的协议.实际上TCP/IP标准并不定义与ISO数据链路层和物理层相对应的功能.相反,它定义像 地址解析协议(Address Resolution Protocol,ARP)这样的协议,提供TCP/IP协议的数据结构和实际物理硬件之间的接口. 第二层 网间层 网

SD3.0协议解读四

前面的文章提到过SD卡主要分为两个操作模式,一是初始化和识别操作模式,另一种就是这篇文章需要分析的数据传输模式啦. 数据传输模式: 数据传输模式主要有六种状态,分别是Stand-by状态.Transfer状态.Sending-data状态.Receive-data状态.Programming状态.Disconnect状态.这六种状态通过不同的Command就可以切换到某种状态,换句话说,这六种状态贯穿了整个数据传输模式. 要理解数据传输模式的流程,老衲认为除了理解这六种状态,还需要对Comman

OpenDaylight与Mininet应用实战之OpenFlow1.0协议分析

继本专题基本环境搭建(一)之后,本文在此基础上熟悉平台操作,以及通过wireshark抓包工具分析OpenFlow(以下简写为OF)协议.具体的OF官方协议及白皮书可在资料库栏目中下载阅读.注:此文涉及的环境仅支持OF1.0版本,对于OF1.2.OF1.3版本可用其他平台测试,后续会另做专题讨论. 1 打开wireshark并创建拓扑 按照章节一搭建平台,启动ODL,并打开wireshark.进入装有Mininet的VM,通过mn命令指定网络拓扑及指定此ODL控制器. Mininet创建网络拓扑

蓝牙协议分析(11)_BLE安全机制之SM

1. 前言 注1:此SM是Security Manager的缩写,非彼SM,大家不要理解歪了! 书接上文,我们在"蓝牙协议分析(10)_BLE安全机制之LE Encryption"中介绍了BLE安全机制中的终极武器----数据加密.不过使用这把武器有个前提,那就是双方要共同拥有一个加密key(LTK,Long Term Key).这个key至关重要,怎么生成.怎么由通信的双方共享,关系到加密的成败.因此蓝牙协议定义了一系列的复杂机制,用于处理和加密key有关的操作,这就是SM(Secu

HTTP协议分析

http协议介绍 目录: 一.http协议版本 二.http文档的生成方式 三.http协议的报文 四.http请求方法 五.http状态码分析 一.http协议(版本) 1.http:Hyper Text Transfer Protocol超文本传输协议,是互联网应用最广泛的一种网络协议,主要用于web服务,通过计算机处理文本消息,格式为HTML(Hyper Text Mark Language)超文本标记语言实现 2.http协议的版本: (1).http0.9:仅与用户传输html文档 (

蓝牙协议分析(7)_BLE连接有关的技术分析

转自:http://www.wowotech.net/bluetooth/ble_connection.html#comments 1. 前言 了解蓝牙的人都知道,在经典蓝牙中,保持连接(Connection)是一个相当消耗资源(power和带宽)的过程.特别是当没有数据传输的时候,所消耗的资源完全被浪费了.因而,对很多蓝牙设备来说(特别是功耗敏感的设备),希望在无数可传的时候,能够断开连接.但是,由于跳频(hopping)以及物理通道(Physical Channel)划分的缘故,经典蓝牙连接

深入理解OAuth2.0协议

1. 引言 如果你开车去酒店赴宴,你经常会苦于找不到停车位而耽误很多时间.是否有好办法可以避免这个问题呢?有的,听说有一些豪车的车主就不担心这个问题.豪车一般配备两种钥匙:主钥匙和泊车钥匙.当你到酒店后,只需要将泊车钥匙交给服务生,停车的事情就由服务生去处理.与主钥匙相比,这种泊车钥匙的使用功能是受限制的:它只能启动发动机并让车行驶一段有限的距离,可以锁车,但无法打开后备箱,无法使用车内其他设备.这里就体现了一种简单的"开放授权"思想:通过一把泊车钥匙,车主便能将汽车的部分使用功能(如

物联网MQTT协议分析和开源Mosquitto部署验证

在<物联网核心协议—消息推送技术演进>一文中已向读者介绍了多种消息推送技术的情况,包括HTTP单向通信.Ajax轮询.Websocket.MQTT.CoAP等,其中MQTT协议为IBM制定并力推,其具有开放.简单.轻量级以及易于实现的特点使得其即便在资源受限的环境中也能得到很好的使用,比如运行在资源紧缺型的嵌入式系统中或网络带宽非常昂贵的环境中,除此之外,它也被广泛用于遥感勘测.智能家居.能源监测和医疗应用程序等各个领域,是物联网的重要组成部分,将来可能会成为物联网的事实标准. 本篇文章将帮助

协议分析 - DHCP协议解码详解

协议分析 - DHCP协议解码详解 [DHCP协议简介] DHCP,全称是 Dynamic Host Configuration Protocol﹐中文名为动态主机配置协议,它的前身是 BOOTP,它工作在OSI的应用层,是一种帮助计算机从指定的DHCP服务器获取它们的配置信息的自举协议. DHCP使用客户端/服务器模式,请求配置信息的计算机叫做DHCP客户端,而提供信息的叫做DHCP的服务器.DHCP为客户端分配地址的方法有三种:手工配置.自动配置.动态配置. DHCP最重要的功能就是动态分配