×

bt协议

96
云烟1f3bca320ba6
2017.05.24 21:30* 字数 4594

BT协议

bt种子文件

编码 bencode

bencode 有 4 种数据类型: string, integer, list 和 dictionary。

  1. string

    e.g.: <字符串长度>:<字符串>

  2. integer

    e.g.: i<整数>e

  3. list

    e.g.: l数据1数据2数据3e

  4. dictionary

    e.g.: d[key1][value1][key2][value2][…]e,其中 key 必须是 string 而且按照字母顺序排序

种子文件结构

  • info 字典,描述种子内包含的文件列表信息,这里有两种类型,一是单文件的,二是多文件的,具体看后面的说明。
  • announce 字节串,描述 Tracker 的 URL。
  • announce-list 列表,可选,这是一个对官方规范的扩展项,提供后向兼容。
  • creation date 字节串,可选,这是一个UNIX时间戳,表示种子文件的创建时间。
  • comment 字节串,可选,自由描述字段,一般描述种子的制作者。
  • created by 字节串,可选,描述用于制作这个种子文件的程序。
  • encoding 字节串,可选,描述 info.pieces 字段的编码方式。

无论是单文件格式还是多文件格式种子文件,其 info 字段下都可以包含以下 3 个字段

  • piece length 整数,表示一个分片的长度(单位:字节),称之为 分片单位
  • pieces 字节串,是由多个分片的 SHA-1校验码(20字节/个) 拼凑而成的字节串,因此其长度总是为20的倍数。
  • private 整数,可选,如果这个值被置为1,那么 BT客户端 必须通过向 种子文件 中指定的 Tracker 汇报自身的存在,从而获取其它 伙伴 的信息。反之如果置0客户端 可以通过其它方法获取其它伙伴,例如 PEXDHT。因此,private 字段也可以理解为“禁止通过其它途径获取伙伴信息”。

当种子内仅包含一个文件的信息时,其 info 字段 内必须包括如下字段

  • name 字节串,种子内包含的唯一文件的名称,这不是强制性的命名,仅作参考。(下载时可以修改保存的文件名)
  • length 整数,种子内包含的唯一文件的大小,单位是字节。
  • md5sum 字节串,可选,这是一个32位的16进制字符串,表示种子内包含的唯一文件的 MD5 校验值。尽管几乎所有BT客户端都未使用到这个字段,但是它仍被保留作为兼容性字段

当种子内包含多个文件的信息时,其 info 字段 内必须包括如下字段

  • name 字节串,种子内所有文件的总名称,BT客户端下载时默认使用它作为资源的目录名称,同理,这不是强制性的命名,仅作参考。(下载时可以修改保存的目录名)

  • files列表,这是一个由多个字典组成的列表,每个字典对应一个文件的信息,这些字典的格式如下:

  • length 整数,文件的大小,单位是字节。
  • md5sum 字节串,可选,这是一个32位的16进制字符串,表示该文件的 MD5 校验值。尽管几乎所有BT客户端都未使用到这个字段,但是它仍被保留作为兼容性字段
  • path 列表 这是一个特殊的文件路径表示方式。假设一个文件在种子内对应的相对路径是a/bb/ccc/hello.txt,那么将其根据 / 分割开,得到顺序列表 [ 'a', 'bb', 'ccc', 'hello.txt' ],经过 BEncoding 编码后就是 l1:a2:bb3:ccc9:hello.txte

Tracker服务器

一般有http和udp两种

入参

  • info_hash:元信息文件中 20 字节的 SHA-1 散列值。注意此值会进入编码字典中,如上述的信息关键字的定义所述。与不需编码的 peer_id 相比,它总是被 URL 编码。
  • peer_id:客户端 ID ,客户端用来唯一标识自己 ID 的 20 字节的串,它在客户端启动时生成。允许为任何值,包括二进制数据。目前没有特定的算法来生成客户端 ID。但是,人们会认为它至少对于自己的本地机器是唯一的,从而应该像进程 ID 一样合并数据,也可能在启动时由时标记录。见本区域下面的一般客户端编码的 peer_id。
  • port:客户端监听的端口号。BitTorrent 所使用的典型端口是 6881-6889。如果此范围的端口都无效,可以选择其他的。
  • uploaded:从客户端发送“已开始”事件到服务器算起的上传总量,数值采用 10 进制的 ASCII。对于没有在官方规范明确指出的,该值应为已上传的字节总数。
  • downloaded:从客户端发送“已开始”事件到服务器算起的下载总量,数值采用 10 进制的 ASCII。对于没有在官方规范明确指出的,该值应为已下载的字节总数。
  • left:客户端需要下载的字节数,以 10 进制 ASCII 编码。
  • no_peer_id:客户端接受一个紧密的响应。客户端列表由客户端串代替,此串中每个客户端都编码成 6 字节。前 4 字节是主机名(以网络的字节顺序),后两个字节是端口号(同样以网络字节的顺序)。
  • event:如果被指定,则是已开始已完成已停止中的一个,或者为空(表示未指定)。如果未指定,此请求为常规时间间隔中的一次运行。
    • started:向服务器发送的第一个请求,必须包含开始值的事件关键字。
    • stopped:如果客户端关机则须发送到服务器上。
    • completed:完成下载时必须发送到服务器上。但是,当客户端启动时下载完成度为 100%(即:做种中)则不会发送。可能这是允许服务器增加“已完成下载”的方法。
  • ip:可选。客户端的真实 IP 地址,以点分四元组格式或 RFC3513 中定义的 16 进制 IPv6 地址。注意:大体上此参数没有客户端地址重要,它能由 IP 地址决定,HTTP 请求也来自该处。仅在请求参与的 IP 地址不是客户端的 IP 地址的情况下才需要。这种情况发生在客户端通过代理服务器与服务器进行通信的情形。当客户端和服务器同时处在本地 NAT 网关时也需要。原因是服务器会发出客户端的内部地址(RFC1918),这是不可到达的。所以客户端必须清楚地把自己的外部可到达的 IP 地址发送到其他客户端中。不同的服务器对此参数的解释有所不同。某些只有当请求参与的 IP 地址属于 RFC1918 时才允许。有些无条件允许,但有些则完全忽略。如果使用 IPv6 地址(如:2001:db8:1:2::100),则表示客户端能通过 IPv6 进行通信。
  • numwant:可选。客户端想从服务器接收的用户数目。允许此值为“0”。如果不用此项,则默认值为 50 个用户。
  • key:可选。一个不与任何用户共享的另外的标识。当 IP 地址改变后,允许客户端证明它们的标识。
  • trackerid:可选。如果先前发布包含服务器的 id,它应放在这里。

响应

  • failure reason:如果当前使用此值,则其余关键字不会使用。该值是可读的错误消息,包括请求失败的原因。(字符串)
  • warning message:(新)与失败原因相似,但响应仍然会被正常处理。警告消息看起来像错误。
  • interval:以秒计算,是客户端发送规则请求到服务器之后等待的时间。(强制)
  • min interval:最小发布时间间隔。当前客户重发间隔不能小于此值。
  • tracker id:一个客户端应在下一个通告发回的字符串。如果没有该值,先前通告会发出一个服务器 id ,不要丢弃旧的值,一直使用它。
  • complete:拥有完整文件的用户数,即做种者(整数)
  • incomplete:非种子用户的数目,也叫“吸血者”(整数)
  • peers:是字典的列表,每个值都有如下的关键字:
    • peer id:用户的自选择 ID,如上述用来发送服务器请求的(字符串)
    • ip:用户的 IP 地址(IPv4 或 IPv6 格式)或域名(字符串)
    • port:用户的端口号(整数)

DHT

概述 Overview

每个节点有一个全局唯一的标识符,作为 "node ID"。节点 ID 是一个随机选择的 160bit 空间,BitTorrent infohash[2] 也使用这样的 160bit 空间。 "距离"用来比较两个节点 ID 之间或者节点 ID 和 infohash 之间的"远近"。节点必须维护一个路由表,路由表中含有一部分其它节点的联系信息。其它节点距离自己越近时,路由表信息越详细。因此每个节点都知道 DHT 中离自己很"近"的节点的联系信息,而离自己非常远的 ID 的联系信息却知道的很少。

在 Kademlia 网络中,距离是通过异或(XOR)计算的,结果为无符号整数。distance(A, B) = |A xor B|,值越小表示越近。

当节点要为 torrent 寻找 peer 时,它将自己路由表中的节点 ID 和 torrent 的 infohash 进行"距离对比"。然后向路由表中离 infohash 最近的节点发送请求,问它们正在下载这个 torrent 的 peer 的联系信息。如果一个被联系的节点知道下载这个 torrent 的 peer 信息,那个 peer 的联系信息将被回复给当前节点。否则,那个被联系的节点则必须回复在它的路由表中离该 torrent 的 infohash 最近的节点的联系信息。最初的节点重复地请求比目标 infohash 更近的节点,直到不能再找到更近的节点为止。查询完了之后,客户端把自己作为一个 peer 插入到所有回复节点中离种子最近的那个节点中。

请求 peer 的返回值包含一个不透明的值,称之为"令牌(token)"。如果一个节点宣布它所控制的 peer 正在下载一个种子,它必须在回复请求节点的同时,附加上对方向我们发送的最近的"令牌(token)"。这样当一个节点试图"宣布"正在下载一个种子时,被请求的节点核对令牌和发出请求的节点的 IP 地址。这是为了防止恶意的主机登记其它主机的种子。由于令牌仅仅由请求节点返回给收到令牌的同一个节点,所以没有规定他的具体实现。但是令牌必须在一个规定的时间内被接受,超时后令牌则失效。在 BitTorrent 的实现中,token 是在 IP 地址后面连接一个 secret(通常是一个随机数),这个 secret 每五分钟改变一次,其中 token 在十分钟以内是可接受的。

路由表 Routing Table

每个节点维护一个路由表保存已知的好节点。路由表中的节点是用来作为在 DHT 中请求的起始点。路由表中的节点是在不断的向其他节点请求过程中,对方节点回复的。

并不是我们在请求过程中收到得节点都是平等的,有的节点是好的,而另一些则不是。许多使用 DHT 协议的节点都可以发送请求并接收回复,但是不能主动回复其他节点的请求。节点的路由表只包含已知的好节点,这很重要。好节点是指在过去的 15 分钟以内,曾经对我们的某一个请求给出过回复的节点,或者曾经对我们的请求给出过一个回复(不用在15分钟以内),并且在过去的 15 分钟给我们发送过请求。上述两种情况都可将节点视为好节点。在 15 分钟之后,对方没有上述 2 种情况发生,这个节点将变为可疑的。当节点不能给我们的一系列请求给出回复时,这个节点将变为坏的。相比那些未知状态的节点,已知的好节点会被给于更高的优先级。

路由表覆盖从 0 到 2^160 全部的节点 ID 空间。路由表又被划分为桶(bucket),每个桶包含一部分的 ID 空间。空的路由表只有一个桶,它的 ID 范围从 min=0 到 max=2^160。当 ID 为 N 的节点插入到表中时,它将被放到 ID 范围在 min <= N < max 的 桶 中。空的路由表只有一个桶,所以所有的节点都将被放到这个桶中。每个桶最多只能保存 K 个节点,当前 K=8。当一个桶放满了好节点之后,将不再允许新的节点加入,除非我们自身的节点 ID 在这个桶的范围内。在这样的情况下,这个桶将被分裂为 2 个新的桶,每个新桶的范围都是原来旧桶的一半。原来旧桶中的节点将被重新分配到这两个新的桶中。如果一个新表只有一个桶,这个包含整个范围的桶将总被分裂为 2 个新的桶,每个桶的覆盖范围从 0..2^159 和 2159..2160。

当桶装满了好节点,新的节点会被丢弃。一旦桶中的某个节点变为了坏的节点,那么我们就用新的节点来替换这个坏的节点。如果桶中有在 15 分钟内都没有活跃过的节点,我们将这样的节点视为可疑的节点,这时我们向最久没有联系的节点发送 ping。如果被 ping 的节点给出了回复,那么我们向下一个可疑的节点发送 ping,不断这样循环下去,直到有某一个节点没有给出 ping 的回复,或者当前桶中的所有节点都是好的(也就是所有节点都不是可疑节点,他们在过去 15 分钟内都有活动)。如果桶中的某个节点没有对我们的 ping 给出回复,我们最好再试一次(再发送一次 ping,因为这个节点也许仍然是活跃的,但由于网络拥塞,所以发生了丢包现象,注意 DHT 的包都是 UDP 的),而不是立即丢弃这个节点或者直接用新节点来替代它。这样,我们得路由表将充满稳定的长时间在线的节点。

每个桶都应该维持一个 lastchange 字段来表明桶中节点的"新鲜"度。当桶中的节点被 ping 并给出了回复,或者一个节点被加入到了桶,或者一个节点被新的节点所替代,桶的 lastchange 字段都应当被更新。如果一个桶的 lastchange 在过去的 15 分钟内都没有变化,那么我们将更新它。这个更新桶操作是这样完成的:从这个桶所覆盖的范围中随机选择一个 ID,并对这个 ID 执行 find_nodes查找操作。常常收到请求的节点通常不需要常常更新自己的桶,反之,不常常收到请求的节点常常需要周期性的执行更新所有桶的操作,这样才能保证当我们用到 DHT 的时候,里面有足够多的好的节点。

在插入第一个节点到路由表并启动服务后,这个节点应试着查找 DHT 中离自己更近的节点,这个查找工作是通过不断的发出find_node 消息给越来越近的节点来完成的,当不能找到更近的节点时,这个扩散工作就结束了。路由表应当被启动工作和客户端软件保存(也就是启动的时候从客户端中读取路由表信息,结束的时候客户端软件记录到文件中)。

协议消息

Kademlia协议共有四种消息

1. PING消息: 用来测试节点是否仍然在线
2. STORE消息: 在某个节点中存储一个键值对
3. FIND_NODE消息: 消息请求的接收者将返回自己桶中离请求键值最近的K个节点: 将请求者请求的节点HASH和自己的HASH进行XOR计算,将计算结果
4. FIND_VALUE消息: 与FIND_NODE一样,不过当请求的接收者存有请求者所请求的键的时候,它将返回相应键的值

DHT嗅探器的原理

DHT这种对等分布式网络在带来抗DDOS的优点的同时,也带来了一些缺点

1. 伪造攻击: 有些不听话的用户可能会在DHT网络里捣乱,譬如说撒谎,明明自己不是奥巴马,却偏说自己是奥巴马,这样会误导其他人无法正常获取想要的资源
2. 嗅探攻击: 另外,用户在DHT网络里的隐私可能会被窃听,因为在DHT网络里跟其他用户交换资源的时候,难免会暴露自己的IP地址,所以别人就会知道你有什么资源,你在请求什么资源了。这也是目前DHT网络里一直存在的一个弱点

参考:

https://wiki.theory.org/index.php/BitTorrentSpecification#Notes

https://fenying.gitbooks.io/bittorrent-specification-chinese-edition/content/

https://segmentfault.com/a/1190000002528378

http://www.cnblogs.com/LittleHann/p/6180296.html

技术wiki
Web note ad 1