趣谈网络协议笔记-二（第十七讲）

趣谈网络协议笔记-二（第十七讲）

P2P协议：我下小电影，99%急死你

---

自勉

• 逃离舒适区！

---

正文

一. P2P协议

整个篇章讲的就是这两个协议之间的区别。P2P协议就是迅雷下载数据时所用的协议，
众所周知，如果使用迅雷进行下载的时候，可以直接复制http链接，也可以输入种子，然后”强大“的迅雷就会进行解析之后，将可下载的文件的目录显示出来。用户就可以通过UI界面选择需要的内容进行下载了。
那么种子中到底包含了什么内容呢？为什么迅雷下载会比直接网页上下载更加迅速呢？接下来一个个解开。
现在一般的家庭都基本换上了百兆宽带了吧，这里的百兆指的是带宽，即能每秒能处理100M次的高低频变化，换算成字节就是差不多10M左右的传输速度。但是如果这么大的数据传输，全部通过单台服务器进行，人口基数一大，服务器其实很吃力，往往不能最大限度的满足家庭的下载需要。
那么面对如此严峻的情况，该采取什么样的方法或者说手段才能最大限度地利用带宽呢？只需要将服务器的负担分散就行了，但是我作为下载提供方，总不可能为了全中国人民的幸福着想就无限制地提高服务器的成本，毕竟自己也要吃饭的。
所以P2P协议就是为了解决这个难题而诞生的，通过这个协议可以将每个已经下载了相关数据的客户端变成一台临时的服务器，大家人人为我，我为人人，互惠互利，共同提高下载速度。这也解决了标题中的疑问，为什么99%的时候往往会拖很长的时间，明明之前的下载有如神助。这是因为别人也需要通过你作为渠道来下载他所需的数据。
P2P协议的关键在于种子（车牌），也就是日常生活中所看到的.torrent后缀的文件。.torrent 文件由两部分组成，分别是：announce（tracker URL）和文件信息。announce所对应的服务器中存储着种子中各个文件的位置，因为之前这些位置的主机都通过P2P协议从服务器中获取了对应文件分块的位置，因此有了”备案“，所以迅雷在某些程度上其实知道你都下过什么东西= =，哪天他实在缺钱了，呵呵，把你的相关信息卖掉，你懂的。所以，如果你的种子指向的是某些被禁止的资源，那么他完全可以通过不给你提供这些文件的具体位置的方式来禁止你进行文件的下载。

文件信息里面有这些内容。

• info 区：这里指定的是该种子有几个文件、文件有多长、目录结构，以及目录和文件的名字。
• Name 字段：指定顶层目录名字。
• 每个段的大小：BitTorrent（简称 BT）协议把一个文件分成很多个小段，然后分段下载。
• 段哈希值：将整个种子中，每个段的 SHA-1 哈希值拼在一起。

所以即使你打算下载某些违禁的资源，你依然可以看到这些资源的目录以及文件大小，因为这些信息时直接包含在种子文件里的。这也可以解释为什么那些种子搜索网站可以提供每个种子中的目录信息，因为他们完全不需要通过种子对相关内容进行下载，直接分析种子就行了。

---

二. DHT协议

P2P协议虽然很棒，迅雷也正是靠着这个强势地占用网络上绝大多数资源。不知道迅雷资源的审核人员身体状况还好不好= =，毕竟一般谨慎一些的都会有一些备份吧。但是如果announce挂掉跑路了，与之关联的所有种子也就失去了意义，因为所有种子都没有办法通过他来获取到需要文件的位置。
DHT协议作为解决手段就应运而生了，DHT（distributed hash table）的目的就是避免P2P所依赖的位置信息的中心化存储，即所谓的distributed，分布式的思路。
有一种著名的 DHT 协议，叫 Kademlia 协议。这个和区块链的概念一样，很抽象，我来详细讲一下这个协议。

任何一个 BitTorrent 启动之后，它都有两个角色。一个是peer，监听一个 TCP 端口，用来上传和下载文件，这个角色表明，我这里有某个文件。另一个角色 DHT node，监听一个 UDP 的端口，通过这个角色，这个节点加入了一个 DHT 的网络。

DHT个人感觉是基于P2P的衍生，从多个数据源分别获取数据的思路这点还是不会变的，变得是如何获取数据源。
记得互联网中有一个六度分隔理论，即地球上的任何两个人在互联网上都能通过六层关系进行连接。所以下次你去面试任何一家公司的时候，你直接和面试官说，我不仅仅是你的远房亲戚，更是你老板的远房亲戚！
DHT获取数据源的方式就和这个思路差不多，当你获取一个种子的时候，你就会获取到和你关系从近到远的一层层联系人，这一层层的联系人就是你找到特定某个人的钥匙！

Kademlia 算法中，每个节点只有 4 个指令。

• PING：测试一个节点是否在线，还活着没，相当于打个电话，看还能打通不。
• STORE：要求一个节点存储一份数据，既然加入了组织，有义务保存一份数据。
• FIND_NODE：根据节点 ID 查找一个节点，就是给一个 160 位的 ID，通过上面朋友圈的方式找到那个节点。
• FIND_VALUE：根据 KEY 查找一个数据，实则上跟 FIND_NODE 非常类似。KEY 就是文件对应的 160 位的 ID，就是要找到保存了文件的节点。

从图中可以看到，每个DHT节点id所表示的是其对于一个特定文件的关系。在DHT中替代announce的是一个DHT的列表，DHT规定了与文件hash值相近的N个DHT节点就包含了指向文件存储位置的信息，所以只需要按列表进行id异或操作，比较结果<=N，则尝试从其获取文件存储节点信息。如果最近有某个id符合<=N的条件的节点通过上述四个指令之一和当前节点进行联系，如果该节点就存在于当前DHT列表中，就直接将其移至列表最前端，如果不存在，那么就找到复合<=N的最末端节点，尝试ping测试其是否在线，如果在线，就把末端节点放置到列表最前端，舍弃新节点，毕竟同样是活跃的，老节点稳定性一般更好。这里的思路和LRU算法的思想差不多。

---

后记

本来今天想偷偷懒的，但是还是写一篇吧，适当鞭策一下自己，很多时候不是什么坏事！
说好的今天要完成三篇的呢= =