0. 引言1. Kademlia协议2. KRPC 协议 KRPC Protocol3. DHT 公网嗅探器实现(DHT 爬虫)4. BitTorrent协议5. uTP协议6. Peer Wire协议 7. BitTorrent协议扩展与ut_metadata和ut_pex(Extension for Peers to Send Metadata Files)8. 用P2P对等网络思想改造C/S、B/S架构的思考

magnet:?xt=urn:btih:<info-hash>&dn=<name>&tr=<tracker-url>1. <info-hash>: Infohash的16进制编码，共40字符。为了与其它的编码兼容，客户端应当也支持32字符的infohash base32编码 2. Xt是唯一强制的参数3. dn是在等待metadata时可能供客户端显示的名字4. 如果只有一个字段，Tr是tracker的url，如果有很多的tracker，那么多个tr字段会被包含进去 # dn和tr都是可选的 

http://blog.csdn.net/xxxxxx91116/article/details/8549454

1. Kademlia规定了网络的结构，也规定了通过节点查询进行信息交换的方式2. Kademlia网络节点之间使用UDP进行通讯3. 参与通讯的所有节点形成一张虚拟网(或者叫做覆盖网)。这些节点通过一组数字(或称为节点ID)来进行身份标识4. 节点ID不仅可以用来做身份标识，还可以用来进行值定位(值通常是文件的散列或者关键词)5. 其实，节点ID与文件散列直接对应，它所表示的那个节点存储着哪儿能够获取文件和资源的相关信息6. 当我们在网络中搜索某些值(即通常搜索存储文件散列或关键词的节点)的时候，Kademlia算法需要知道与这些值相关的键，然后分步在网络中开始搜索。每一步都会找到一些节点，这些节点的ID与键更为接近，如果有节点直接返回搜索的值或者再也无法找到与键更为接近的节点ID的时候搜索便会停止。这种搜索值的方法是非常高效的7. 与其他的分散式杂凑表的实现类似，在一个包含n个节点的系统的值的搜索中，Kademlia仅访问O(log(n))个节点。非集中式网络结构还有更大的优势，那就是它能够显著增强抵御拒绝服务攻击的能力。即使网络中的一整批节点遭受泛洪攻击，也不会对网络的可用性造成很大的影响，通过绕过这些漏洞(被攻击的节点)来重新编织一张网络，网络的可用性就可以得到恢复 

1. 第一代P2P文件分享网络，像Napster，依赖于中央数据库来协调网络中的查询2. 第二代P2P网络，像Gnutella，使用泛滥式查询(query flooding)来查询文件，它会搜索网络中的所有节点3. 第三代p2p网络使用分散式杂凑表来查询网络中的文件，分散式杂凑表在整个网络中储存资源的位置

1. 节点和它本身之间的异或距离是02. 异或距离是对称的：即从A到B的异或距离与从B到A的异或距离是等同的3. 异或距离符合三角不等式: 三个顶点A B C，AC异或距离小于或等于AB异或距离和BC异或距离之和，这种几何数学特征，可以很好的支撑算法进行寻路路由

因为Kademlia是根据bit位XOR计算得到"相对距离"的，对于越低bit位，XOR可能得到的结果越小，对于越高位的bit位，XOR可能得到的值就越大，并且是呈现2的指数方式增长的，所以，从数学上来说，一个DHT网络中的所有节点，通过这种方式(XOR距离)进行寻址，每次前进一个bit，最大只需要log2N次即可到达目标节点(log2逼近的思路，即bit 2可以表示世界上任何数字)

1. 节点ID的一位就是1bit，假设我们的节点ID是: 1110002. 对第一个K桶来说，它的列表中的条目必须第一bit不能是1，因为第一个K桶的含义是和该节点的距离是最远的一个分组，第一位不为1，它背后的含义是该分组里的节点和该节点的距离至少在2^6以上，它代表了整个网络中和该节点逻辑距离最远的一些节点 它的列表条目是这样的: 0 00000 ~ 0 1111113. 对第二个K桶来说，它的列表中的条目的第一位必须是1，表示和当前节点的第一bit相同，第二bit不能是1，这样代表的意思是第二个K桶里的节点和该节点的距离是介于MAX(2bit)和MIN(1bit)之间的距离，它的列表条目是这样的: 10 0000 ~ 10 11114. 第三个K桶的情况和前2个相同5. 对第四个K桶的来说，它的列表中的条目前三位都是1，第四位不是0，它的列表条目是这样的: 1111 00 ~ 1111 116. 后面的bit位情况类推，可以看出，越低bit位的K桶的MAX(XOR)就越小，它的可变范围就越小了。这代表了越低bit位的K桶里存储的都是距离当前节点越近的Nod节点

1. 找到某个条目和目标节点XOR为0，即已经寻址成功，则直接返回这个条目给requester即可2. 如果没找到XOR结果为0的条目，则选取那个XOR值最小的条目对应的K桶中的K个条目返回给requester，因为这些条目是最有可能存储了目标节点ID条目的

1. 这就意味着很容易使用网络中远离该节点的一半节点来填充第一个列表(第一位不同的节点最多有一半)2. 而用网络中四分之一的节点来填充第二个列表(比第一个列表中的那些节点离该节点更近一位)3. 依次类推。如果ID有128个二进制位，则网络中的每个节点按照不同的异或距离把其他所有的节点分成了128类，ID的每一位对应于其中的一类

1. 向节点列表中存信息: 录入别的节点发布的声明2. 和从节点列表中取信息的操作3. 甚至还包括当时协助其他节点寻找相应键对应值的操作: 转发其他节点的寻址请求

1. 节点的HASH值决定了它们的逻辑距离，即Kademlia网络中的下一跳寻址是根据HASH XOR的值范围(数值大小范围)结果决定的2. 该网络最大可有2^3，即8个关键字和节点，目前共有7个节点加入，每个节点用一个小圈表示(在树的底部)3. 考虑那个用黑圈标注的节点6，它共有3个K桶(即3bit位)节点0，1和2(二进制表示为000，001和010)是第一个K桶的候选节点000 -> 110: 6001 -> 110: 5010 -> 110: 4节点3目前(二进制表示为011)还没有加入网络节点4和节点5(二进制表示分别为100和101)是第二个K桶的候选节点100 -> 110: 2101 -> 110: 1 节点7(二进制表示为111)是第3个K桶的候选节点111 -> 110: 1

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

1. 在节点查询的时候，它先得到它K桶中离所查询的键值最近的K个节点(XOR值最小的那个条目所在的分组)，然后向这K个节点发起FIND_NODE消息请求(因为这个K桶内的节点最有可能寻址成功)2. 消息接收者收到这些请求消息后将在他们的K桶中进行查询，如果他们知道离被查键更近的节点，他们就返回这些节点(最多K个)    1) 找到某个条目和目标节点XOR为0，即已经寻址成功，则直接返回这个条目给requester即可    2) 如果没找到XOR结果为0的条目，则选取那个XOR值最小的条目对应的K桶中的K个条目返回给requester，因为这些条目是最有可能存储了目标节点ID条目的3. 消息的请求者在收到响应后将使用它所收到的响应结果来更新它的结果列表，返回的结果也应该插入到刚才发起请求的那个K桶里，这个结果列表总是保持K个响应FIND_NODE消息请求的最优节点(即离被搜索键更近的K个节点) 4. 然后消息发起者将向这K个最优节点发起查询，因为刚开始的查询很可能K桶里存的不全是目标节点，而是潜在地离目标节点较近的节点5. 不断地迭代执行上述查询过程。因为每一个节点比其他节点对它周边的节点有更好的感知能力(水波扩散式的节点寻址方式)，因此响应结果将是一次一次离被搜索键值越来越近的某节点。如果本次响应结果中的节点没有比前次响应结果中的节点离被搜索键值更近了(即发现这轮查询的结果未发生diff变化了)，这个查询迭代也就终止了6. 当这个迭代终止的时候，响应结果集中的K个最优节点就是整个网络中离被搜索键值最近的K个节点(从以上过程看，这显然是局部的，而非整个网络，因为这本质和最优解搜索算法一样，可能陷入局部最优解而无法获得全局最优解) 7. 节点信息中可以增加一个往返时间，或者叫做RTT的参数，这个参数可以被用来定义一个针对每个被查询节点的超时设置，即当向某个节点发起的查询超时的时候，另一个查询才会发起，当然，针对某个节点的查询在同一时刻从来不超过α个

1. 考虑到节点未必都在线的情况，资源的值被存在多个节点上(节点中的K个)，并且，为了提供冗余，还有可能在更多的节点上储存值2. 储存值的节点将定期搜索网络中与储存值所对应的键接近的K个节点并且把值复制到这些节点上，这些节点可作为那些下线的节点的补充3. 另外，对于那些普遍流行的内容，可能有更多的请求需求，通过让那些访问值的节点把值存储在附近的一些节点上(不在K个最近节点的范围之类)来减少存储值的那些节点的负载，这种新的存储技术就是缓存技术，通过这种技术，依赖于请求的数量，资源的值被存储在离键越来越远的那些节点上(资源热度越高，缓存cache就越广泛)，这使得那些流行的搜索可以更快地找到资源的储存者5. 由于返回值的节点的NODE_ID远离值所对应的关键字，网络中的"热点"区域存在的可能性也降低了。依据与键的距离，缓存的那些节点在一段时间以后将会删除所存储的缓存值。DHT的某些实现(如Kad)即不提供冗余(复制)节点也不提供缓存，这主要是为了能够快速减少系统中的陈旧信息。在这种网络中，提供文件的那些节点将会周期性地更新网络上的信息(通过NODE_LOOKUP消息和STORE消息)。当存有某个文件的所有节点都下线了，关于该文件的相关的值(源和关键字)的更新也就停止了，该文件的相关信息也就从网络上完全消失了 

1. 想要加入网络的节点首先要经历一个引导过程。在引导过程中，节点需要知道其他已加入该网络的某个节点的IP地址和端口号(可从用户或者存储的列表中获得)。假如正在引导的那个节点还未加入网络，它会计算一个目前为止还未分配给其他节点的随机ID号，直到离开网络，该节点会一直使用该ID号 2. 正在加入Kademlia网络的节点在它的某个K桶中插入引导节点(加入该网络的介绍人)(负责加入节点的初始化工作)，然后向它的唯一邻居(引导节点)发起NODE_LOOKUP操作请求来定位自己，这种"自我定位"将使得Kademlia的其他节点(收到请求的节点)能够使用新加入节点的Node Id填充他们的K桶(邻居互相认识)3. 同时也能够使用那些查询过程的中间节点(位于新加入节点和引导节点的查询路径上的其他节点)来填充新加入节点的K桶(相当于完成一个DNS递归查询后，沿途路径上的DNS IP都被记录了)。想象一下这个过程    1) 新加入的节点可能和"引导节点"距离很远，它一上来就向离自己几何距离最远的引导节点问话: "谁知道我自己这个节点在哪?"，引导节点会尽力去回答这个问题，即引导节点会把自己K桶内最有可能知道该节点位置(即离该几点XOR几何距离最近的K个点返回给新加入的请求节点)    2) 新加入的请求方收到了K个节点后，把这K个节点保存进自己的K桶，然后继续向这些节点去"询问(发起find_node请求)"自己的节点在哪，这些节点会收到这些请求，同时也把新加入节点保存进自己的K桶内    3) 整个过程和向DNS根域名服务器请求解析某个域名的递归过程类似4. 这一自查询过程使得新加入节点自引导节点所在的那个K桶开始，由远及近，对沿途的所有节点逐步得到刷新，整条链路上的邻居都认识了这个新邻居5. 最初的时候，节点仅有一个K桶(覆盖所有的ID范围)，当有新节点需要插入该K桶时，如果K桶已满，K桶就开始分裂，分裂发生在节点的K桶的覆盖范围(表现为二叉树某部分从左至右的所有值)包含了该节点本身的ID的时候。对于节点内距离节点最近的那个K桶，Kademlia可以放松限制(即可以到达K时不发生分裂)，因为桶内的所有节点离该节点距离最近，这些节点个数很可能超过K个，而且节点希望知道所有的这些最近的节点。因此，在路由树中，该节点附近很可能出现高度不平衡的二叉子树。假如K是20，新加入网络的节点ID为"xxx000011001"，则前缀为"xxx0011..."的节点可能有21个，甚至更多，新的节点可能包含多个含有21个以上节点的K桶(位于节点附近的k桶)。这点保证使得该节点能够感知网络中附近区域的所有节点 

1. Kademlia使用异或来定义距离。两个节点ID的异或(或者节点ID和关键字的异或)的结果就是两者之间的距离。对于每一个二进制位来说，如果相同，异或返回0，否则，异或返回1。异或距离满足三角形不等式: 任何一边的距离小于(或等于)其它两边距离之和2. 异或距离使得Kademlia的路由表可以建在单个bit之上，即可使用位组(多个位联合)来构建路由表。位组可以用来表示相应的K桶，它有个专业术语叫做前缀，对一个m位的前缀来说，可对应2^m-1个K桶(m位的前缀本来可以对应2^m个K桶)另外的那个K桶可以进一步扩展为包含该节点本身ID的路由树3. 一个b位的前缀可以把查询的最大次数从logn减少到logn/b。这只是查询次数的最大值，因为自己K桶可能比前缀有更多的位与目标键相同，这会增加在自己K桶中找到节点的机会，假设前缀有m位，很可能查询一个节点就能匹配2m甚至更多的位组，所以其实平均的查询次数要少的多 4. 节点可以在他们的路由表中使用混合前缀，就像eMule中的Kad网络。如果以增加查询的复杂性为代价，Kademlia网络在路由表的具体实现上甚至可以是有异构的

1. 假如一个节点希望分享某个文件，它先根据文件的内容来处理该文件，通过运算，把文件的内容散列成一组数字，该数字在文件分享网络中可被用来标识文件2. 这组散列数字必须和节点ID有同样的长度，然后，该节点便在网络中搜索ID值与文件的散列值相近的节点，然后向这些被搜索到的节点广播自己(即把它自己的IP地址存储在那些搜索到的节点上)，本质意思是说: "你如果要搜索这个文件，就去找那些节点ID就好了，那些节点ID会告诉搜索者应该到自己这里来(文件发布者)来建立TCP连接，下载文件"，也就是说，它把自己作为文件的源进行了发布(文件共享方式)。正在进行文件搜索的客户端将使用Kademlia协议来寻找网络上ID值与希望寻找的文件的散列值最近的那个节点(寻找文件的过程和寻找节点的机制形成了统一，因为文件和节点的ID的HASH格式是一样的)，然后取得存储在那个节点上的文件源列表 3. 由于一个键(HASH)可以对应很多值，即同一个文件(通过一个对应的HASH公布到P2P网络中)可以有多个源(因为可能有多个节点都会有这个文件的拷贝)，每一个存储源列表的节点可能有不同的文件的源的信息，这样的话，源列表可以从与键值相近的K个节点获得。 文件的散列值通常可以从其他的一些特别的Internet链接的地方获得，或者被包含在从其他某处获得的索引文件中(即种子文件)4. 文件名的搜索可以使用关键词来实现，文件名可以分割成连续的几个关键词，这些关键词都可以散列并且可以和相应的文件名和文件散列储存在网络中。搜索者可以使用其中的某个关键词，联系ID值与关键词散列最近的那个节点，取得包含该关键词的文件列表。由于在文件列表中的文件都有相关的散列值，通过该散列值就可利用上述通常取文件的方法获得要搜索的文件 

https://zh.wikipedia.org/wiki/Kademliahttp://file.scirp.org/pdf/3-4.3.pdf

1. string: 字符是以这种方式编码的: <字符串长度>:<字符串> 如 hell: 4:hell2. integer: 整数是一这种方式编码的: i<整数>e 如 1999: i1999e3. list: 列表是一这种方式编码的: l[数据1][数据2][数据3][…]e 如列表 [hello, world, 101]：l5:hello5:worldi101ee4. dictionary: 字典是一这种方式编码的: d[key1][value1][key2][value2][…]e，其中 key 必须是 string 而且按照字母顺序排序 如字典 {aa:100, bb:bb, cc:200}： d2:aai100e2:bb2:bb2:cci200ee

1. t关键字: 每条消息都包含 t 关键字，它是一个代表了 transaction ID 的字符串。transaction ID 由请求节点产生，并且回复中要包含回显该字段(挑战-响应模型)，所以回复可能对应一个节点的多个请求。transaction ID 应当被编码为一个短的二进制字符串，比如 2 个字节，这样就可以对应 2^16 个请求2. y关键字: 它由一个字节组成，表明这个消息的类型。y 对应的值有三种情况    1) q 表示请求(请求Queries): q类型的消息它包含 2 个附加的关键字 q 和 a        1.1) 关键字 q: 是字符串类型，包含了请求的方法名字(get_peers/announce_peer/ping/find_node)        1.2) 关键字 a: 一个字典类型包含了请求所附加的参数(info_hash/id..)    2) r 表示回复(回复 Responses): 包含了返回的值。发送回复消息是在正确解析了请求消息的基础上完成的，包含了一个附加的关键字 r。关键字 r 是字典类型        2.1) id: peer节点id号或者下一跳DHT节点                2.2) nodes": ""                 2.3) token: token    3) e 表示错误(错误 Errors): 包含一个附加的关键字 e，关键字 e 是列表类型        3.1) 第一个元素是数字类型，表明了错误码，当一个请求不能解析或出错时，错误包将被发送。下表描述了可能出现的错误码        201: 一般错误        202: 服务错误        203: 协议错误，比如不规范的包，无效的参数，或者错误的 toke        204: 未知方法         3.2) 第二个元素是字符串类型，表明了错误信息

ping Query = {"t":"aa", "y":"q", "q":"ping", "a":{"id":"abcdefghij0123456789"}}bencoded = d1:ad2:id20:abcdefghij0123456789e1:q4:ping1:t2:aa1:y1:qeResponse = {"t":"aa", "y":"r", "r": {"id":"mnopqrstuvwxyz123456"}}bencoded = d1:rd2:id20:mnopqrstuvwxyz123456e1:t2:aa1:y1:re

find_node Query = {"t":"aa", "y":"q", "q":"find_node", "a": {"id":"abcdefghij0123456789", "target":"mnopqrstuvwxyz123456"}}# "id" containing the node ID of the querying node, and "target" containing the ID of the node sought by the queryer. bencoded = d1:ad2:id20:abcdefghij01234567896:target20:mnopqrstuvwxyz123456e1:q9:find_node1:t2:aa1:y1:qeResponse = {"t":"aa", "y":"r", "r": {"id":"0123456789abcdefghij", "nodes": "def456..."}}bencoded = d1:rd2:id20:0123456789abcdefghij5:nodes9:def456...e1:t2:aa1:y1:re

参数: {"id" : "<querying nodes id>", "target" : "<id of target node>"}回复: {"id" : "<queried nodes id>", "nodes" : "<compact node info>"}

1. 请求方的id: 发起这个DHT节点寻址的节点自身的ID，可以类比DNS查询中的客户端2. 目标target id: 需要查询的目标ID号，可以类比于DNS查询中的URL，这个ID在整个递归查询中是一直不变的3. 被请求节点的id: 在节点的递归查询中，请求方由远及近不断询问整个链路上的节点，沿途的每个节点在返回时都要带上自己的id号

1. get_peers 请求包含 2 个参数(id请求节点ID，info_hash代表torrent文件的infohash，infohash为种子文件的SHA1哈希值，也就是磁力链接的btih值)2. response get_peer:     1) 如果被请求的节点有对应 info_hash 的 peers，他将返回一个关键字 values，这是一个列表类型的字符串。每一个字符串包含了 "CompactIP-address/portinfo" 格式的 peers 信息(即对应的机器ip/port信息)(peer的info信息和DHT节点的info信息是一样的)    2) 如果被请求的节点没有这个 infohash 的 peers，那么他将返回关键字 nodes(需要注意的是，如果该节点没有对应的infohash信息，而只是返回了nodes，则请求方会认为该节点是一个"可疑节点"，则会从自己的路由表K捅中删除该节点)，这个关键字包含了被请求节点的路由表中离 info_hash 最近的 K 个节点(我这里没有该节点，去别的节点试试运气)，使用 "Compactnodeinfo" 格式回复。在这两种情况下，关键字 token 都将被返回。token 关键字在今后的 annouce_peer 请求中必须要携带。token 是一个短的二进制字符串

get_peers Query = {"t":"aa", "y":"q", "q":"get_peers", "a": {"id":"abcdefghij0123456789", "info_hash":"mnopqrstuvwxyz123456"}}bencoded = d1:ad2:id20:abcdefghij01234567899:info_hash20:mnopqrstuvwxyz123456e1:q9:get_peers1:t2:aa1:y1:qeResponse with peers = {"t":"aa", "y":"r", "r": {"id":"abcdefghij0123456789", "token":"aoeusnth", "values": ["axje.u", "idhtnm"]}}bencoded = d1:rd2:id20:abcdefghij01234567895:token8:aoeusnth6:valuesl6:axje.u6:idhtnmee1:t2:aa1:y1:reResponse with closest nodes = {"t":"aa", "y":"r", "r": {"id":"abcdefghij0123456789", "token":"aoeusnth", "nodes": "def456..."}}bencoded = d1:rd2:id20:abcdefghij01234567895:nodes9:def456...5:token8:aoeusnthe1:t2:aa1:y1:re

参数: {"id" : "<querying nodes id>", "info_hash" : "<20-byte infohash of target torrent>"}回复: {"id" : "<queried nodes id>", "token" :"<opaque write token>", "values" : ["<peer 1 info string>", "<peer 2 info string>"]}或: {"id" : "<queried nodes id>", "token" :"<opaque write token>", "nodes" : "<compact node info>"}

1. 第一个参数是 id: 包含了请求节点的 ID2. 第二个参数是 info_hash: 包含了 torrent 文件的 infohash3. 第三个参数是 port: 包含了整型的端口号，表明 peer 在哪个端口下载4. 第四个参数数是 token: 这是在之前的 get_peers 请求中收到的回复中包含的。收到 announce_peer 请求的节点必须检查这个 token 与之前我们回复给这个节点 get_peers 的 token 是否相同(也就说，所有下载者/发布者都要参与检测新加入的发布者是否伪造了该资源，但是这个机制有一个问题，如果最开始的那个发布者就伪造，则整条链路都是一个伪造的错的资源infohash信息了)如果相同，那么被请求的节点将记录发送 announce_peer 节点的 IP 和请求中包含的 port 端口号在 peer 联系信息中对应的 infohash 下，这意味着一个一个事实: 当前这个资源有一个新的peer提供者了，下一次有其他节点希望或者这个资源的时候，会把这个新的(前一次请求下载资源的节点)也当作一个peer返回给请求者，这样，资源的提供者就越来越多，资源共享速度就越来越快

arguments:  {"id" : "<querying nodes id>","implied_port": <0 or 1>,"info_hash" : "<20-byte infohash of target torrent>","port" : <port number>,"token" : "<opaque token>"}response: {"id" : "<queried nodes id>"}

announce_peers Query = {"t":"aa", "y":"q", "q":"announce_peer", "a": {"id":"abcdefghij0123456789", "implied_port": 1, "info_hash":"mnopqrstuvwxyz123456", "port": 6881, "token": "aoeusnth"}}bencoded = d1:ad2:id20:abcdefghij01234567899:info_hash20:<br />mnopqrstuvwxyz1234564:porti6881e5:token8:aoeusnthe1:q13:announce_peer1:t2:aa1:y1:qeResponse = {"t":"aa", "y":"r", "r": {"id":"mnopqrstuvwxyz123456"}}bencoded = d1:rd2:id20:mnopqrstuvwxyz123456e1:t2:aa1:y1:re

generic error = {"t":"aa", "y":"e", "e":[201, "A Generic Error Ocurred"]}bencoded = d1:eli201e23:A Generic Error Ocurrede1:t2:aa1:y1:ee

http://www.bittorrent.org/beps/bep_0005.htmlhttps://segmentfault.com/a/1190000002528378https://github.com/wuzhenda/simDHThttps://wenku.baidu.com/view/9a7b447aa26925c52cc5bfc9.htmlhttp://www.bittorrent.org/beps/bep_0005.html

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

from gevent import monkeymonkey.patch_all()from gevent.server import DatagramServerimport geventimport socketfrom hashlib import sha1from random import randintfrom struct import unpackfrom socket import inet_ntoafrom threading import Timer, Threadfrom gevent import sleepfrom collections import dequefrom bencode import bencode, bdecodeBOOTSTRAP_NODES = (    ("router.bittorrent.com", 6881),    ("dht.transmissionbt.com", 6881),    ("router.utorrent.com", 6881))TID_LENGTH = 2RE_JOIN_DHT_INTERVAL = 3MONITOR_INTERVAL = 10TOKEN_LENGTH = 2def entropy(length):    return "".join(chr(randint(0, 255)) for _ in xrange(length))def random_id():    h = sha1()    h.update(entropy(20))    return h.digest()def decode_nodes(nodes):    n = []    length = len(nodes)    if (length % 26) != 0:        return n    for i in range(0, length, 26):        nid = nodes[i:i+20]        ip = inet_ntoa(nodes[i+20:i+24])        port = unpack("!H", nodes[i+24:i+26])[0]        n.append((nid, ip, port))    return ndef get_neighbor(target, nid, end=10):    return target[:end]+nid[end:]class KNode(object):    def __init__(self, nid, ip, port):        self.nid = nid        self.ip = ip        self.port = portclass DHTServer(DatagramServer):    def __init__(self, max_node_qsize, bind_ip):        s = ‘:‘ + str(bind_ip)        self.bind_ip = bind_ip        DatagramServer.__init__(self, s)        self.process_request_actions = {            "get_peers": self.on_get_peers_request,            "announce_peer": self.on_announce_peer_request,        }        self.max_node_qsize = max_node_qsize        self.nid = random_id()        self.nodes = deque(maxlen=max_node_qsize)    def handle(self, data, address): #        try:            msg = bdecode(data)            self.on_message(msg, address)        except Exception:            pass    def monitor(self):        while True:            # print ‘len: ‘, len(self.nodes)            sleep(MONITOR_INTERVAL)    def send_krpc(self, msg, address):        try:            self.socket.sendto(bencode(msg), address)        except Exception:            pass    def send_find_node(self, address, nid=None):        nid = get_neighbor(nid, self.nid) if nid else self.nid        tid = entropy(TID_LENGTH)        msg = {            "t": tid,            "y": "q",            "q": "find_node",            "a": {                "id": nid,                "target": random_id()            }        }        self.send_krpc(msg, address)    def join_DHT(self):        for address in BOOTSTRAP_NODES:            self.send_find_node(address)    def re_join_DHT(self):        while True:            if len(self.nodes) == 0:                self.join_DHT()            sleep(RE_JOIN_DHT_INTERVAL)    def auto_send_find_node(self):        wait = 1.0 / self.max_node_qsize / 5.0        while True:            try:                node = self.nodes.popleft()                self.send_find_node((node.ip, node.port), node.nid)            except IndexError:                pass            sleep(wait)    def process_find_node_response(self, msg, address):        # print ‘find node‘ + str(msg)        nodes = decode_nodes(msg["r"]["nodes"])        for node in nodes:            (nid, ip, port) = node            if len(nid) != 20: continue            if ip == self.bind_ip: continue            if port < 1 or port > 65535: continue            n = KNode(nid, ip, port)            self.nodes.append(n)    def on_message(self, msg, address):        try:            if msg["y"] == "r":                if msg["r"].has_key("nodes"):                    self.process_find_node_response(msg, address)            elif msg["y"] == "q":                try:                    self.process_request_actions[msg["q"]](msg, address)                except KeyError:                    self.play_dead(msg, address)        except KeyError:            pass    def on_get_peers_request(self, msg, address):        try:            infohash = msg["a"]["info_hash"]            tid = msg["t"]            nid = msg["a"]["id"]            token = infohash[:TOKEN_LENGTH]            info = infohash.encode("hex").upper() + ‘|‘ + address[0]            print  info + "\n",            msg = {                "t": tid,                "y": "r",                "r": {                    "id": get_neighbor(infohash, self.nid),                    "nodes": "",                    "token": token                }            }            self.send_krpc(msg, address)        except KeyError:            pass    def on_announce_peer_request(self, msg, address):        try:            # print ‘announce peer‘            infohash = msg["a"]["info_hash"]            token = msg["a"]["token"]            nid = msg["a"]["id"]            tid = msg["t"]            if infohash[:TOKEN_LENGTH] == token:                if msg["a"].has_key("implied_port") and msg["a"]["implied_port"] != 0:                    port = address[1]                else:                    port = msg["a"]["port"]                    if port < 1 or port > 65535: return                info = infohash.encode("hex").upper()                print  info + "\n",        except Exception as e:            print e            pass        finally:            self.ok(msg, address)    def play_dead(self, msg, address):        try:            tid = msg["t"]            msg = {                "t": tid,                "y": "e",                "e": [202, "Server Error"]            }            self.send_krpc(msg, address)        except KeyError:            print ‘error‘            pass    def ok(self, msg, address):        try:            tid = msg["t"]            nid = msg["a"]["id"]            msg = {                "t": tid,                "y": "r",                "r": {                    "id": get_neighbor(nid, self.nid)                }            }            self.send_krpc(msg, address)        except KeyError:            passif __name__ == ‘__main__‘:    sniffer = DHTServer(50, 8080)    gevent.spawn(sniffer.auto_send_find_node)    gevent.spawn(sniffer.re_join_DHT)    gevent.spawn(sniffer.monitor)    print(‘Receiving datagrams on :6882‘)    sniffer.serve_forever()

#!/usr/bin/env python# encoding: utf-8# apt-get install python-dev# pip install bencode# pip install mysql-python# apt-get install libmysqlclient-devimport mathimport socketimport threadingfrom time import sleep, timefrom hashlib import sha1from random import randintfrom struct import pack, unpackfrom socket import inet_ntoafrom threading import Timer, Threadfrom time import sleepfrom collections import dequefrom bencode import bencode, bdecodefrom Queue import Queueimport base64import jsonimport urllib2import tracebackimport gcBOOTSTRAP_NODES = (    ("router.bittorrent.com", 6881),    ("dht.transmissionbt.com", 6881),    ("router.utorrent.com", 6881))TID_LENGTH = 2RE_JOIN_DHT_INTERVAL = 3TOKEN_LENGTH = 2BT_PROTOCOL = "BitTorrent protocol"BT_MSG_ID = 20EXT_HANDSHAKE_ID = 0def entropy(length):    return "".join(chr(randint(0, 255)) for _ in xrange(length))def random_id():    h = sha1()    h.update(entropy(20))    return h.digest()def decode_nodes(nodes):    n = []    length = len(nodes)    if (length % 26) != 0:        return n    for i in range(0, length, 26):        nid = nodes[i:i + 20]        ip = inet_ntoa(nodes[i + 20:i + 24])        port = unpack("!H", nodes[i + 24:i + 26])[0]        n.append((nid, ip, port))    return ndef timer(t, f):    Timer(t, f).start()def get_neighbor(target, nid, end=10):    return target[:end] + nid[end:]def send_packet(the_socket, msg):    the_socket.send(msg)def send_message(the_socket, msg):    msg_len = pack(">I", len(msg))    send_packet(the_socket, msg_len + msg)def send_handshake(the_socket, infohash):    bt_header = chr(len(BT_PROTOCOL)) + BT_PROTOCOL    ext_bytes = "\x00\x00\x00\x00\x00\x10\x00\x00"    peer_id = random_id()    packet = bt_header + ext_bytes + infohash + peer_id    send_packet(the_socket, packet)def check_handshake(packet, self_infohash):    try:        bt_header_len, packet = ord(packet[:1]), packet[1:]        if bt_header_len != len(BT_PROTOCOL):            return False    except TypeError:        return False    bt_header, packet = packet[:bt_header_len], packet[bt_header_len:]    if bt_header != BT_PROTOCOL:        return False    packet = packet[8:]    infohash = packet[:20]    if infohash != self_infohash:        return False    return Truedef send_ext_handshake(the_socket):    msg = chr(BT_MSG_ID) + chr(EXT_HANDSHAKE_ID) + bencode({"m": {"ut_metadata": 1}})    send_message(the_socket, msg)def request_metadata(the_socket, ut_metadata, piece):    """bep_0009"""    msg = chr(BT_MSG_ID) + chr(ut_metadata) + bencode({"msg_type": 0, "piece": piece})    send_message(the_socket, msg)def get_ut_metadata(data):    try:        ut_metadata = "_metadata"        index = data.index(ut_metadata) + len(ut_metadata) + 1        return int(data[index])    except Exception as e:        passdef get_metadata_size(data):    metadata_size = "metadata_size"    start = data.index(metadata_size) + len(metadata_size) + 1    data = data[start:]    return int(data[:data.index("e")])def recvall(the_socket, timeout=15):    the_socket.setblocking(0)    total_data = []    data = ""    begin = time()    while True:        sleep(0.05)        if total_data and time() - begin > timeout:            break        elif time() - begin > timeout * 2:            break        try:            data = the_socket.recv(1024)            if data:                total_data.append(data)                begin = time()        except Exception:            pass    return "".join(total_data)def ip_black_list(ipaddress):    black_lists = [‘45.32.5.150‘, ‘45.63.4.233‘]    if ipaddress in black_lists:        return True    return Falsedef download_metadata(address, infohash, timeout=15):    if ip_black_list(address[0]):        return    try:        the_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)        the_socket.settimeout(15)        the_socket.connect(address)        # handshake        send_handshake(the_socket, infohash)        packet = the_socket.recv(4096)        # handshake error        if not check_handshake(packet, infohash):            try:                the_socket.close()            except:                return            return        # ext handshake        send_ext_handshake(the_socket)        packet = the_socket.recv(4096)        # get ut_metadata and metadata_size        ut_metadata, metadata_size = get_ut_metadata(packet), get_metadata_size(packet)        # print ‘ut_metadata_size: ‘, metadata_size        # request each piece of metadata        metadata = []        for piece in range(int(math.ceil(metadata_size / (16.0 * 1024)))):            request_metadata(the_socket, ut_metadata, piece)            packet = recvall(the_socket, timeout)  # the_socket.recv(1024*17) #            metadata.append(packet[packet.index("ee") + 2:])        metadata = "".join(metadata)        info = {}        meta_data = bdecode(metadata)        del metadata        info[‘hash_id‘] = infohash.encode("hex").upper()        if meta_data.has_key(‘name‘):            info["hash_name"] = meta_data["name"].strip()        else:            info["hash_name"] = ‘‘        if meta_data.has_key(‘length‘):            info[‘hash_size‘] = meta_data[‘length‘]        else:            info[‘hash_size‘] = 0        if meta_data.has_key(‘files‘):            info[‘files‘] = meta_data[‘files‘]            for item in info[‘files‘]:                # print item                if item.has_key(‘length‘):                    info[‘hash_size‘] += item[‘length‘]            info[‘files‘] = json.dumps(info[‘files‘], ensure_ascii=False)            info[‘files‘] = info[‘files‘].replace("\"path\"", "\"p\"").replace("\"length\"", "\"l\"")        else:            info[‘files‘] = ‘‘        info[‘a_ip‘] = address[0]        info[‘hash_size‘] = str(info[‘hash_size‘])        print info, "\r\n\r\n"        del info        gc.collect()    except socket.timeout:        try:            the_socket.close()        except:            return    except socket.error:        try:            the_socket.close()        except:            return    except Exception, e:        try:            # print e            # traceback.print_exc()             the_socket.close()        except:            return    finally:        the_socket.close()        returnclass KNode(object):    def __init__(self, nid, ip, port):        self.nid = nid        self.ip = ip        self.port = portclass DHTClient(Thread):    def __init__(self, max_node_qsize):        Thread.__init__(self)        self.setDaemon(True)        self.max_node_qsize = max_node_qsize        self.nid = random_id()        self.nodes = deque(maxlen=max_node_qsize)    def send_krpc(self, msg, address):        try:            self.ufd.sendto(bencode(msg), address)        except Exception:            pass    def send_find_node(self, address, nid=None):        nid = get_neighbor(nid, self.nid) if nid else self.nid        tid = entropy(TID_LENGTH)        msg = {            "t": tid,            "y": "q",            "q": "find_node",            "a": {                "id": nid,                "target": random_id()            }        }        self.send_krpc(msg, address)    def join_DHT(self):        for address in BOOTSTRAP_NODES:            self.send_find_node(address)    def re_join_DHT(self):        if len(self.nodes) == 0:            self.join_DHT()        timer(RE_JOIN_DHT_INTERVAL, self.re_join_DHT)    def auto_send_find_node(self):        wait = 1.0 / self.max_node_qsize        while True:            try:                node = self.nodes.popleft()                self.send_find_node((node.ip, node.port), node.nid)            except IndexError:                pass            sleep(wait)    def process_find_node_response(self, msg, address):        nodes = decode_nodes(msg["r"]["nodes"])        for node in nodes:            (nid, ip, port) = node            if len(nid) != 20: continue            if ip == self.bind_ip: continue            n = KNode(nid, ip, port)            self.nodes.append(n)class DHTServer(DHTClient):    def __init__(self, master, bind_ip, bind_port, max_node_qsize):        DHTClient.__init__(self, max_node_qsize)        self.master = master        self.bind_ip = bind_ip        self.bind_port = bind_port        self.process_request_actions = {            "get_peers": self.on_get_peers_request,            "announce_peer": self.on_announce_peer_request,        }        self.ufd = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)        self.ufd.bind((self.bind_ip, self.bind_port))        timer(RE_JOIN_DHT_INTERVAL, self.re_join_DHT)    def run(self):        self.re_join_DHT()        while True:            try:                (data, address) = self.ufd.recvfrom(65536)                msg = bdecode(data)                self.on_message(msg, address)            except Exception:                pass    def on_message(self, msg, address):        try:            if msg["y"] == "r":                if msg["r"].has_key("nodes"):                    self.process_find_node_response(msg, address)            elif msg["y"] == "q":                try:                    self.process_request_actions[msg["q"]](msg, address)                except KeyError:                    self.play_dead(msg, address)        except KeyError:            pass    def on_get_peers_request(self, msg, address):        try:            infohash = msg["a"]["info_hash"]            tid = msg["t"]            nid = msg["a"]["id"]            token = infohash[:TOKEN_LENGTH]            msg = {                "t": tid,                "y": "r",                "r": {                    "id": get_neighbor(infohash, self.nid),                    "nodes": "",                    "token": token                }            }            self.send_krpc(msg, address)        except KeyError:            pass    def on_announce_peer_request(self, msg, address):        try:            infohash = msg["a"]["info_hash"]            token = msg["a"]["token"]            nid = msg["a"]["id"]            tid = msg["t"]            if infohash[:TOKEN_LENGTH] == token:                if msg["a"].has_key("implied_port ") and msg["a"]["implied_port "] != 0:                    port = address[1]                else:                    port = msg["a"]["port"]                self.master.log(infohash, (address[0], port))        except Exception:            print ‘error‘            pass        finally:            self.ok(msg, address)    def play_dead(self, msg, address):        try:            tid = msg["t"]            msg = {                "t": tid,                "y": "e",                "e": [202, "Server Error"]            }            self.send_krpc(msg, address)        except KeyError:            pass    def ok(self, msg, address):        try:            tid = msg["t"]            nid = msg["a"]["id"]            msg = {                "t": tid,                "y": "r",                "r": {                    "id": get_neighbor(nid, self.nid)                }            }            self.send_krpc(msg, address)        except KeyError:            passclass Master(Thread):    def __init__(self):        Thread.__init__(self)        self.setDaemon(True)        self.queue = Queue()    def run(self):        while True:            self.downloadMetadata()    def log(self, infohash, address=None):        self.queue.put([address, infohash])    def downloadMetadata(self):        # 100 threads for download metadata        for i in xrange(0, 100):            if self.queue.qsize() == 0:                sleep(1)                continue            announce = self.queue.get()            t = threading.Thread(target=download_metadata, args=(announce[0], announce[1]))            t.setDaemon(True)            t.start()trans_queue = Queue()if __name__ == "__main__":    # max_node_qsize bigger, bandwith bigger, spped higher    master = Master()    master.start()    print(‘Receiving datagrams on :6882‘)    dht = DHTServer(master, "0.0.0.0", 6881, max_node_qsize=10)    dht.start()    dht.auto_send_find_node()

http://www.lyyyuna.com/2016/03/26/dht01/

1. "peer" 是在一个 TCP 端口上监听的客户端/服务器，它实现了 BitTorrent 协议 2. "节点" 是在一个 UDP 端口上监听的客户端/服务器，它实现了 DHT(分布式哈希表) 协议 DHT 由节点组成，它存储了 peer 的位置。BitTorrent 客户端包含一个 DHT 节点，这个节点用来联系 DHT 中其他节点，从而得到 peer 的位置，进而通过 BitTorrent 协议下载 

1. 当节点要为 torrent(种子文件) 寻找 peer(保存了目标资源的IP) 时，它将自己路由表中的节点 ID 和 torrent 的 infohash(资源HASH) 进行"距离对比"(节点和目标文件的距离)，然后向路由表中离 infohash 最近的节点发送请求，问它们正在下载这个 torrent 的 peer 的联系信息2. 因为资源HASH和节点HASH都共用一套20bytes的命名空间，所以DHT节点充当了peer节点的"代理"的工作，我们不能直接向peer节点发起资源获取请求(即使这个peer节点确实存储了我们的目标资源)，因为peer节点本身不具备处理P2P request/response能力的，我们需要借助DHT的能力，让DHT告诉我们哪个peer节点保存了我们想要的资源或者哪个DHT节点可能知道从而递归地继续去问那个DHT网络3. 如果一个被联系的节点知道下载这个 torrent 的 peer 信息，那个 peer 的联系信息将被回复给当前节点。否则，那个被联系的节点则必须回复在它的路由表中离该 torrent 的 infohash 最近的节点的联系信息，4. 最初的节点重复地请求比目标 infohash 更近的节点，直到不能再找到更近的节点为止5. 查询完了之后，客户端把自己作为一个 peer 插入到所有回复节点中离种子最近的那个节点中，这一步背后的含义是: 我之前是请求这个资源的人，我们现在获取到资源了，我在下载这个文件的同时，我也要充当一个新的peer来向其他的客户端贡献自己的文件共享，这样，当另外的其他客户端在发起新的请求的时候，DHT节点就有可能把当前客户端对应的peer返回给新的请求方，这样不断发展下去，这个资源的热度就越来越热，下载速度也越来越快6. 请求 peer 的返回值包含一个不透明的值，称之为"令牌(token)"7. 如果一个节点宣布它所控制的 peer 正在下载一个种子(即该节点拥有该文件资源)，它必须在回复请求节点的同时，附加上对方向我们发送的最近的"令牌(token)"。这样当一个节点试图"宣布"正在下载一个种子时，被请求的节点核对令牌和发出请求的节点的 IP 地址。这是为了防止恶意的主机登记其它主机的种子。由于令牌仅仅由请求节点返回给收到令牌的同一个节点，所以没有规定他的具体实现。但是令牌必须在一个规定的时间内被接受，超时后令牌则失效。在 BitTorrent 的实现中，token 是在 IP 地址后面连接一个 secret(通常是一个随机数)，这个 secret 每五分钟改变一次，其中 token 在十分钟以内是可接受的

请求方生成一个随机值，跟着我的请求发给被请求方，被请求方回复的时候要带上这个随机值，那请求方就知道，你是我刚才想请求的那个人

1. 每个节点维护一个路由表保存已知的好节点。路由表中的节点是用来作为在 DHT 中请求的起始点。路由表中的节点是在不断的向其他节点请求过程中，对方节点回复的。即DHT中的K桶中的节点，当我们请求一个目标资源的时候，我们根据HASH XOR从自己的K桶中选择最有可能知道该资源的节点发起请求，而被请求的节点也不一定知道目标资源所在的peer，这个时候被请求方会返回一个新的"它认为可能知道这个peer的节点"，请求方收到这个新的节点后，会把这个节点保存进自己的K桶内，然后继续发起请求，直到找到目标资源所在的peer为止2. 并不是我们在请求过程中收到的节点都是平等的，有的节点是好的，而另一些则不是。许多使用 DHT 协议的节点都可以发送请求并接收回复，但是不能主动回复其他节点的请求，这种节点被称之为"坏节点"3. 节点的路由表只包含已知的好节点，这很重要。好节点是指在过去的 15 分钟以内，曾经对我们的某一个请求给出过回复的节点(存活好节点)，或者曾经对我们的请求给出过一个回复(不用在15分钟以内)，并且在过去的 15 分钟给我们发送过请求。上述两种情况都可将节点视为好节点。在 15 分钟之后，对方没有上述 2 种情况发生，这个节点将变为可疑的。当节点不能给我们的一系列请求给出回复时，这个节点将变为坏的。相比那些未知状态的节点，已知的好节点会被给于更高的优先级。# 这就反过来告诉我们，如果我们要做DHT嗅探，我们的嗅探器除了要能够发出FIND_NODE请求及接收返回之外，还需要能够响应其他节点发来的请求(get_peers/announce_peer)，这样才不会被其他节点列入"可疑"甚至"坏节点"列表中4. 路由表覆盖从 0 到 2^160 全部的节点 ID 空间。路由表又被划分为桶(bucket)，每个桶包含一部分的 ID 空间。空的路由表只有一个桶，它的 ID 范围从 min=0 到 max=2^160。当 ID 为 N 的节点插入到表中时，它将被放到 ID 范围在 min <= N < max 的 桶 中5. 空的路由表只有一个桶，所以所有的节点都将被放到这个桶中。每个桶最多只能保存 K 个节点，当前 K=8。当一个桶放满了好节点之后，将不再允许新的节点加入，除非我们自身的节点 ID 在这个桶的范围内。在这样的情况下，这个桶将被分裂为 2 个新的桶，每个新桶的范围都是原来旧桶的一半。原来旧桶中的节点将被重新分配到这两个新的桶中。如果一个新表只有一个桶，这个包含整个范围的桶将总被分裂为 2 个新的桶，每个桶的覆盖范围从 0..2^159 和 2^159..2^160 # 以log2N的方式不断分裂，类似于Kademlia中的K桶机制6. 当桶装满了好节点，新的节点会被丢弃。一旦桶中的某个节点变为了坏的节点，那么我们就用新的节点来替换这个坏的节点。如果桶中有在 15 分钟内都没有活跃过的节点，我们将这样的节点视为可疑的节点，这时我们向最久没有联系的节点发送 ping。如果被 ping 的节点给出了回复，那么我们向下一个可疑的节点发送 ping，不断这样循环下去，直到有某一个节点没有给出 ping 的回复，或者当前桶中的所有节点都是好的(也就是所有节点都不是可疑节点，他们在过去 15 分钟内都有活动)。如果桶中的某个节点没有对我们的 ping 给出回复，我们最好再试一次(再发送一次 ping，因为这个节点也许仍然是活跃的，但由于网络拥塞，所以发生了丢包现象，注意 DHT 的包都是 UDP 的)，而不是立即丢弃这个节点或者直接用新节点来替代它。这样，我们得路由表将充满稳定的长时间在线的节点 7. 每个桶都应该维持一个 lastchange 字段来表明桶中节点的"新鲜"度。当桶中的节点被 ping 并给出了回复，或者一个节点被加入到了桶，或者一个节点被新的节点所替代，桶的 lastchange 字段都应当被更新。如果一个桶的 lastchange 在过去的 15 分钟内都没有变化，那么我们将更新它。这个更新桶操作是这样完成的    1) 从这个桶所覆盖的范围中随机选择一个 ID，并对这个 ID 执行 find_nodes 查找操作。常常收到请求的节点通常不需要常常更新自己的桶    2) 反之，不常常收到请求的节点常常需要周期性的执行更新所有桶的操作，这样才能保证当我们用到 DHT 的时候，里面有足够多的好的节点 8. 在插入第一个节点到路由表并启动服务后，这个节点应试着查找 DHT 中离自己更近的节点，这个查找工作是通过不断的发出 find_node 消息给越来越近的节点来完成的，当不能找到更近的节点时，这个扩散工作就结束了9. 路由表应当被启动工作和客户端软件保存(也就是启动的时候从客户端中读取路由表信息，结束的时候客户端软件记录到文件中)

1. peers 如果支持 DHT 协议就将 BitTorrent 协议握手消息的保留位的第 8 字节的最后一位置为 12. 这时如果 peer 收到一个 handshake 表明对方支持 DHT 协议，就应该发送 PORT 消息。它由字节 0x09 开始，payload 的长度是 2 个字节，包含了这个 peer 的 DHT 服务使用的网络字节序的 UDP 端口号3. 当 peer 收到这样的消息时应当向对方的 IP 和消息中指定的端口号的节点发送 ping4. 如果收到了 ping 的回复，那么应当使用上述的方法将新节点的联系信息加入到路由表中 

1. info(dictinary): 必选, 表示该bt种子文件的文件信息     1) 文件信息包括文件的公共部分        1.1) piece length(integer): 必选, 每一数据块的长度        1.2) pieces(string): 必选, 所有数据块的 SHA1 校验值        1.3) publisher(string):    可选, 发布者        1.4) publisher.utf-8(string): 可选, 发布者的 UTF-8 编码        1.5) publisher-url(string): 可选, 发布者的 URL        1.6) publisher-url.utf-8(string): 可选, 发布者的 URL 的 UTF-8 编码    2) 如果 bt 种子包含的是单个文件，包含以下内容        2.1) name(string): 必选, 推荐的文件名称        2.2) name.utf-8(string): 可选, 推荐的文件名称的 UTF-8 编码        2.3) length(int): 必选，文件的长度单位是字节    3) 如果是多文件，则包含以下部分:        3.1) name(string): 必选, 推荐的文件夹名称        3.2) name.utf-8(string): 可选, 推荐的文件名称的 UTF-8 编码        3.3) files(list): 必选, 文件列表，每个文件列表下面是包括每一个文件的信息，文件信息是个字典     4) 文件字典        4.1) length(int): 必选，文件的长度单位是字节        4.2) path(string): 必选，文件名称，包含文件夹在内        4.3) path.utf-8(string): 必选，文件名称 UTF-8 表示，包含文件夹在内        4.4) filehas(string): 可选，文件hash        4.5) ed2k(string): 可选, ed2k 信息 2. announce(string): 必选, tracker 服务器的地址3. announce-list(list): 可选, 可选的 tracker 服务器地址4. creation date(interger): 必选, 文件创建时间5. comment(string): 可选, bt 文件注释6. created by(string): 可选，文件创建者

d8:announce33:udp://mgtracker.org:2710/announce13:announce-listll33:udp://mgtracker.org:2710/announceel35:http://share.camoe.cn:8080/announceel29:udp://11.rarbg.me:80/announceel32:http://tracker.tfile.me/announceel40:http://open.acgtracker.com:1096/announceel34:http://mgtracker.org:2710/announceel35:udp://tracker.openbittorrent.com:80el44:udp://tracker.openbittorrent.com:80/announceel38:udp://torrent.gresille.org:80/announceel34:udp://glotorrents.pw:6969/announceel33:udp://208.67.16.113:8000/announceel31:udp://9.rarbg.com:2710/announceel30:udp://9.rarbg.me:2710/announceel31:udp://tracker.ex.ua:80/announceee10:created by13:uTorrent/204013:creation datei1491018889e8:encoding5:UTF-84:infod5:filesld6:lengthi2168824586e4:pathl6:01.mp4eed6:lengthi2175155313e4:pathl6:02.mp4eed6:lengthi2165600175e4:pathl6:03.mp4eed6:lengthi2172491370e4:pathl6:04.mp4eed6:lengthi2168274148e4:pathl6:05.mp4eed6:lengthi2174880177e4:pathl6:06.mp4eed6:lengthi373e4:pathl38:HQC＠水嫩的大白菜_2017.3.31.txteee4:name60:In.the.Name.of.People.EP01-06.2017.1080p.WEB-DL.x264.AAC-HQC12:piece lengthi4194304e6:pieces62120:XXXXX(SHA1杂凑值)

Tracker地址: udp://mgtracker.org:2710/announceTracker服务器地址列表: udp://mgtracker.org:2710/announcehttp://share.camoe.cn:8080/announceudp://11.rarbg.me:80/announcehttp://tracker.tfile.me/announcehttp://open.acgtracker.com:1096/announcehttp://mgtracker.org:2710/announceudp://tracker.openbittorrent.com:80udp://tracker.openbittorrent.com:80/announceudp://torrent.gresille.org:80/announceudp://glotorrents.pw:6969/announceudp://208.67.16.113:8000/announceudp://9.rarbg.com:2710/announceudp://9.rarbg.me:2710/announceudp://tracker.ex.ua:80/announce创建者: uTorrent/204013创建时间: datei1491018889e8encoding: UTF-8info: 文件列表字典(包含了一批文件)    length: 2168824586    path: 01.mp4    ..杂凑SHA1内容: 按照每个文件块(pieces)的方式分别计算SHA1杂凑值9

1. 先根据infohash下载种子文件的info字段，种子文件并不是必须的，但是info字段却必不可少2. 然后根据infohash下载源文件，将下载的每一个数据块和info中的对应的SHA1校验码进行比较，不一致重新下载该数据块

1. 一般的种子文件会包含announce，也就是tracker服务器的地址(trackerless是BTTorrent的趋势)2. 如果没有tracker服务器，文件中可能会包含nodes，nodes是存有种子信息的peer节点，这样的种子文件就是trackerless torrent。如果有nodes客户端直接从nodes获取种子信息3. 而从DHT网络中下载下来的种子文件既没有annouce也没有nodes，客户端只能通过info字段计算出hashinfo，再从bootstrap node节点开始在DHT网络中寻找种子信息 

http://xiaoxia.org/2013/05/11/magnet-search-engine/https://segmentfault.com/a/1190000000681331http://www.360doc.com/content/15/0507/16/3242454_468754791.shtml

1. type(包类型):    1) ST_DATA = http://www.mamicode.com/0: 最重要的数据包，uTP就是使用该类型的包传送数据    2) ST_FIN = 1: 关闭连接，这是uTP连接的最后一个包，类似于TCP中的FIN    3) ST_STATE = 2: 简单的应答包，表明已从对方收到了数据包，该包不包含任何数据，seq_nr值不变    4) ST_RESET = 3: 终止连接，类似于TCP中的RST    5) ST_SYN = 4: 初始化连接，类似于TCP中的SYN，这是uTP连接的第一个包2. ver: This is the protocol version. The current version is 1.3. extension: The type of the first extension in a linked list of extension headers.     1) 0 means no extension.    2) Selective acks: There is currently one extension:4. connection_id: This is a random, unique, number identifying all the packets that belong to the same connection. Each socket has one connection ID for sending packets and a different connection ID for receiving packets. The endpoint initiating the connection decides which ID to use, and the return path has the same ID + 1.    uTP的一个很重要的特点是使用connection id来标识一次连接，而不是每个包算一次连接。所以在分析ST_DATA时，需要注意找所有connection id相同的数据包，然后按seq_nr排序，seq_nr应该是依次递增的(注意ST_STATE包不会增加seq_nr值)，如果发现两个ST_DATA的seq_nr值相同则说明后面那个报文是重复报文需要忽略掉，如果发现两个ST_DATA的seq_nr值不是连续的，中间差了一个或多个，则可能是由于网络原因发生了丢包现象，数据包将不可用5. timestamp_microseconds: This is the ‘microseconds‘ parts of the timestamp of when this packet was sent. This is set using gettimeofday() on posix and QueryPerformanceTimer() on windows. The higher resolution this timestamp has, the better. The closer to the actual transmit time it is set, the better.6. timestamp_difference_microseconds: This is the difference between the local time and the timestamp in the last received packet, at the time the last packet was received. This is the latest one-way delay measurement of the link from the remote peer to the local machine. When a socket is newly opened and doesn‘t have any delay samples yet, this must be set to 0.7. wnd_size: Advertised receive window. This is 32 bits wide and specified in bytes. The window size is the number of bytes currently in-flight, i.e. sent but not acked. The advertised receive window lets the other end cap the window size if it cannot receive any faster, if its receive buffer is filling up. When sending packets, this should be set to the number of bytes left in the socket‘s receive buffer.8. seq_nr9. ack_nr

http://www.bittorrent.org/beps/bep_0029.html

<pstrlen><pstr><reserved><info_hash><peer_id> 

‘AG‘ - Ares‘A~‘ - Ares‘AR‘ - Arctic‘AV‘ - Avicora‘AX‘ - BitPump‘AZ‘ - Azureus‘BB‘ - BitBuddy‘BC‘ - BitComet‘BF‘ - Bitflu‘BG‘ - BTG (uses Rasterbar libtorrent)‘BR‘ - BitRocket‘BS‘ - BTSlave‘BX‘ - ~Bittorrent X‘CD‘ - Enhanced CTorrent‘CT‘ - CTorrent‘DE‘ - DelugeTorrent‘DP‘ - Propagate Data Client‘EB‘ - EBit‘ES‘ - electric sheep‘FT‘ - FoxTorrent‘FX‘ - Freebox BitTorrent‘GS‘ - GSTorrent‘HL‘ - Halite‘HN‘ - Hydranode‘KG‘ - KGet‘KT‘ - KTorrent‘LH‘ - LH-ABC‘LP‘ - Lphant‘LT‘ - libtorrent‘lt‘ - libTorrent‘LW‘ - LimeWire‘MO‘ - MonoTorrent‘MP‘ - MooPolice‘MR‘ - Miro‘MT‘ - MoonlightTorrent‘NX‘ - Net Transport‘PD‘ - Pando‘qB‘ - qBittorrent‘QD‘ - QQDownload‘QT‘ - Qt 4 Torrent example‘RT‘ - Retriever‘S~‘ - Shareaza alpha/beta‘SB‘ - ~Swiftbit‘SS‘ - SwarmScope‘ST‘ - SymTorrent‘st‘ - sharktorrent‘SZ‘ - Shareaza‘TN‘ - TorrentDotNET‘TR‘ - Transmission‘TS‘ - Torrentstorm‘TT‘ - TuoTu‘UL‘ - uLeecher!‘UT‘ - µTorrent‘VG‘ - Vagaa‘WD‘ - WebTorrent Desktop‘WT‘ - BitLet‘WW‘ - WebTorrent‘WY‘ - FireTorrent‘XL‘ - Xunlei‘XT‘ - XanTorrent‘XX‘ - Xtorrent‘ZT‘ - ZipTorrent

http://www.bittorrent.org/beps/bep_0020.htmlhttps://wiki.theory.org/BitTorrentSpecification#peer_id

{‘m‘: {‘ut_metadata‘, 3}, ‘metadata_size‘: 31235}

0. request(请求): 请求消息并不在字典中附加任何关键字，这个消息的回复应当来自支持这个扩展的peer，是一个reject或者data消息，回复必须和请求所指出的片相同Peer必须保证它所发送的每个片都通过了infohash的检测。即直到peer获得了整个metadata并通过了infohash的验证，才能够发送片(即一个peer应该保证自己已经完整从其他peer中拷贝了一份相同的资源文件后，才能继续响应其他节点的拷贝请求)。Peers没有获得整个metadata时，对收到的所有metadata请求都必须直接回复reject消息# exampel{‘msg_type‘: 0, ‘piece‘: 0}d8:msg_typei0e5:piecei0ee# 这代表请求消息在请求metadata的第一片1. data这个data消息需要在字典中添加一个新的字段，"total_size".这个关键字段和extension头的"metadata_size"有相同的含义，这是一个整型Metadata片被添加到bencode字典后面，他不是字典的一部分，但是是消息的一部分(必须包括长度前缀)。如果这个片是metadata的最后一个片，他可能小于16KB。如果它不是metadata的最后一片，那大小必须是16KB# example{‘msg_type‘: 1, ‘piece‘: 0, ‘total_size‘: 3425}d8:msg_typei1e5:piecei0e10:total_sizei34256eexxxxxxxx...# x表示二进制数据(metadata) 2. rejectReject消息没有附件的关键字。它的意思是peer没有请求的这个metadata片信息 在客户端收到收到一定数目的消息后，可以通过拒绝请求消息来进行洪泛攻击保护。尤其在metadata的数目乘上一个因子时 # {‘msg_type‘: 2, ‘piece‘: 0}d8:msg_typei1e5:piecei0ee

{    e: 0,    ipv4: xxx,    ipv6: xxx,    complete_ago: 1,    m:    {        upload_only: 3,        lt_donthave: 7,        ut_holepunch: 4,        ut_metadata: 2,        ut_pex: 1,        ut_comment: 6    },    matadata_size: 45377,    p: 33733,    reqq: 255,    v: BitTorrent 7.9.3    yp: 19616,    yourip: xxx}1. m: 是一个字典，表示客户端支持的所有扩展以及每个扩展的编号    1) ut_pex: 表示该客户端支持PEX(Peer Exchange)    2) ut_metadata表示支持BEP-009(也就是交换种子文件的metadata)

00 00 00 1b 14 02 ... 00 00 00 1b 1. 消息长度为 0x1b (27 bytes) 2. 14 表示是 扩展消息(0x14 = 20)3. 02 对应上面m字典中的 ut_metadata，所以我们这个消息是ut_metadata消息

00 00 00 03 09 83 c5 --> message ID为9，port消息，表示端口号为0x83c5 = 3373300 00 00 03 14 03 01 --> message ID为20(0x14)，extend消息，编号03为upload_only，表示设置upload_only = 100 00 31 70 14 02 xx --> message ID为20(0x14)，extend消息，编号02为ut_metadata，后面的xx表示[msg_type: 1, piece: 2, total_size: 45377]和相应块的metadata数据

piece 0: 0x0001 ~ 0x4000 长度0x4000piece 1: 0x4001 ~ 0x8000 长度0x4000piece 2: 0x8001 ~ 0xb141 长度0x3141

http://www.bittorrent.org/beps/bep_0010.htmlhttp://www.aneasystone.com/archives/2015/05/analyze-magnet-protocol-using-wireshark.html

1. 实现P2P的第一步是在互联网上进行检索，找到拥有所需内容和计算能力的结点地址2. 第二步是通过互联网实现对等连接

1. 无组织的P2P重叠网: 目前在互联网上广泛使用的大多是无组织的P2P重叠网，如BitTorrent(BT)下载。无组织的P2P重叠网已经演进了几代    1) 第一代P2P网络采用中央控制网络体系结构。早期的软件Napster就采用这种结构    2) 第二代P2P采用分散分布网络体系结构，适合在自组织(Ad hoc)网上应用，如即时通信等    3) 第三代P2P采用混合网络体系结构，这种模式综合了第一代和第二代的优点，用分布的超级结点取代中央检索服务器，并进一步利用有组织网的分布式哈希表(DHT)加速检索 2. 有组织的P2P重叠网: 有组织的P2P重叠网目前还处于学术界研究阶段，如Tapestry、Chord、Pastry和CAN等网络。正在研究的新一代的P2P应用包括多播、网络存储等都运行在这种有组织的P2P重叠网上3. 混合型网三大类: 一些实用系统开始使用混合型结构

1. 一种方法是先下载，下载后再观看，这种方法现在被称为播客(Podcast)2. 另一种就是用流媒体的方式边下载边收看。P2P技术对这两种方式都支持

1. 利用P2P技术实现大规模流媒体点播和直播的系统Webcast出现于1998年。Webcast利用一棵二叉多播树在用户之间进行实时多媒体数据的传输和共享。此后由于流媒体直播服务相对简单，首先得到快速发展2. 2000年出现第一套P2P视频直播系统的原型——ESM系统，该系统采用用户网状结构互连构造最优媒体数据多播树的方法在用户间传播实时的多媒体内容。由于算法限制，这套系统只能扩展到几千人同时在线，但已经标志着P2P流媒体直播系统进入了系统发展期。3. 此后各种原型系统、高度可扩展的应用层多播协议大量涌现。其中典型的系统有提供音频广播的Standford大学的Peercast系统和德国的P2PRadio系统，他们均采用开放源代码。而应用层多播协议有    1) 微软的Coopnet/Splitstream协议    2) 思科的Overcast协议    3) 马里兰大学的NICE协议    4) 伯克利大学的Gossip协议等虽然这些系统和协议尚不能实用，但为P2P流媒体直播打下了坚实的理论基础 5. 2004年5月欧洲杯期间，香港科技大学张欣研博士开发的CoolStreaming原型系统在Planetlab网上试用获得成功。这套系统使用Goosip协议在用户之间传播控制信令，使用类似于BT的"多点对多点数据传播协议"在用户之间传送媒体数据包。CoolStreaming系统是第一次真正将高可扩展和高可靠性的网状多播协议应用在P2P流直播系统当中，标志P2P直播技术进入准商业运作阶段在CoolStreaming成功的鼓舞下，中国流媒体直播技术和业务发展迅速，在世界上独树一帜，目前中国有10多个网站使用各自发展的软件提供P2P流媒体直播业务。用户最多的是PPLive网采用的Synacast系统。Synacast系统的核心是一套完整的网上视频传输和运营支持业务平台。在此平台上可以方便地完成节目采集、发布、认证、统计分析等功能由于采用了P2P技术进行流媒体内容的分发，Synacast系统对服务器端的要求比较低。通常情况下，每一个源分发服务程序只占用5%左右的CPU负载，20 MB的内存和10 Mb/s的网络带宽。以PPLive网为例，该网站原本使用的是传统的Windows Media服务器，一台100 Mb/s服务器以单播方式提供一路节目的直播，最多可支持200～300个用户并发访问；当使用了Synacast技术后，一台100 Mb/s接入互联网的普通PC服务器可以同时提供5～10路视频节目的直播，每一路节目均可以支持百万用户同时收视 

1. 2000年，美国普度大学实现的GnuStream系统是在Gnutella网络基础之上的第一个P2P准点播系统。该系统也使用了网状多播的策略。由于版权因素的限制，这套系统没有能得到大规模的使用2. 2000年之后，P2P的点播技术在适用于点播的应用层传输协议技术、底层编码技术以及数字版权技术等方面都有重要进展    1) 在应用层传输协议方面，比较重要的有2002年提出的P2Cast协议    2) 2003年提出的CollectCast协议(用于PROMISE系统)3. 目前正在发展实用的P2P点播系统，开始进入商业应用阶段4. 美国在线(AOL)和华纳兄弟合作将在互联网上采用Kontiki公司P2P VoD推出In2TV业务，为客户提供电视剧点播业务。有6类电视剧节目，具有DVD质量的视频效果。In2TV还提供各种交互服务如游戏等 

1. 登录客户端(包括PC客户端和手机客户端)需要进行改造，需要支持UDP DHT，它不再直接和中心服务器进行握手登录，而是在P2P网络中，以对等的关系共同存储所有用户的帐号资料信息 (装备/游戏币等)# 这里需要明白，如果我们只是让P2P来负责共享云端的业务负载服务器，即承担分布式调度的问题，本质问题并没有改变，攻击者依然能够很容易获取到所有的负载业务服务器2. 要解决可信认真问题，即网络中任意节点广播出来的说现网的用户账户信息，需要让网络中的其他用户(可以理解为矿工)进行数学可信验证，以达到不可伪造的面对3. 但是同时伴随着问题2，如果用Bit币网络那种"挖矿验证"的方法，一次"账本广播"需要至少经过3层的挖矿后才可以被全网所有节点接收，而这个时间周期要花费地较长，不是很符合游戏这种对实时性要求较高的业务场景4. 新节点入网问题，对DHT网络来说，新节点的入网有2种方式：1）通过引导节点来引导进入、2）通过现网随机某个节点发布的磁力链接进入网络(但是这个情况同样需要一个中心节点服务磁力分发)。总的来说，依然存在一个单点问题，如果这个单点入口Down了，则新节点的入网将无法进行，整个网络的鲁棒性依然得不到保证

http://www.zte.com.cn/cndata/magazine/zte_communications/2006/3/magazine/200605/t20060525_150563.htmlhttp://www.zte.com.cn/cndata/magazine/zte_communications/2007/6/magazine/200712/t20071220_150729.htmlhttp://www.it.com.cn/f/news/079/28/484649.htmhttp://www.chinaunicom.com.cn/upload/1246533688964.pdf