如果我们需要进行文件的下载,那么怎么做呢?
简单的方式是通过HTTP下载,但是通过这种方式下载,速度经常达不到带宽的上限
然后就是通过FTP,文件传输协议下载,利用两个TCP来做到传输一个文件
这两个链接分别是:
1.控制链接:服务器会长期开放 FTP的端口 21,用于方便客户端去连接,客户端主动的发起连接,然后传递命令,服务器获取到命令,进行对应的回复,常用的命令有 list-获取文件目录;refer-获取一个文件;store-存一个文件
2.数据连接:每当一个文件进行传输的时候,就创建一个数据连接
FTP的两种工作模式
每次传输一个文件,都要建立一个全新的连接,FTP的就针对开放了几个端口,来分为了两种工作模式
主动模式(PORT):客户端随机打开一个大于1024的端口N,并且开发一个N+1的端口,这样连接服务器的端口21的时候,让服务器端连接自己的N+1端口
被动模式(PASV):开启一个FTP连接的时候,客户端开启两个连接 N端口 和N+1端口,第一个用于连接21端口,并提交自己的PASV命令,然后服务器会开启任意的一个端口P,然后返回这个P的端口号,这样客户端收到了这个P端口号,就会通过N+1连接端口号P
但是这样存在的一个问题,就是单一服务器的带宽压力,因为这是一个传统的服务器传输方式
于是为了缓解服务器的压力,无论是带宽和存储能力,我们使用新的方式,P2P就是Peer-to-Peer,资源不集中的存储,而是分散的存储在多台的设备上,这些设备被称为Peer
假如下载一个文件的时候,我们只需要知道哪些服务器存放了文件,然后跟这些服务器(Peer)之间,建立了点对点的连接,而不用到中心服务器上连接,就可以直接下载文件,在下载了之后,你也就成为了Peer中的一员,如果有相邻的服务器需要下载,那么就可以直接从你这里拿
这样,你使用P2P的时候,下载了,自己也就加入这个P2P的网络了,会同时具有上传和下载的流量,那么这样自己既从别人那里拿取文件,别人也从我这里拿取文件,速度就快了
那么如何知道Peer服务器的地址呢?
这就是需要种子文件了,就是.torrent文件,这个文件由两个部分组成,分别是annouce(tracker URL)和文件信息
文件信息有如下的内容
info区:这个种子有几个文件,文件的大小,目录结构,目录和文件的名字
Name:顶层目录的名字
各个段的大小,每个端将文件分成了很多小段,然后分段的下载
段哈希值:整个种子汇总,每个端的SHA-A哈希值拼在一起
下载的时候,先解析出.torrent文件,然后得到了tracker地址,然后连接 tracker服务器,获取到其他的下载者,然后下载者彼此互联,告诉对方自己拥有的块,然后交换没有的数据,这样就减轻了服务器的负担,每次下载一个端,就校验HASH验证码,然后和torrent文件中的对比
这样下载的过程中,很依赖于tracker,tracker收集各个下载者的信息,然后讲这个信息提供给其他的下载者,使得他们彼此联系,但是如果tracker出现了问题,或者无法连接,那么BT工具就废了
于是推出了去中心化网络(DHT)
那么什么是去中心化呢?就是每个加入这个DHT网路的人,都要存储这个网络里的资源信息和其他成员的联系信息,大家一起构成了一个庞大的分布式数据库
这里有一个著名的DHT协议,Kademlia协议
任何一个BitTorrent启动后,都是有两个角色,一个是peer,监听一个TCP端口,用来上传和下载文件,一个是DHT node,监听一个UDP的端口,通过这个UDP加入了这个DHT的网络
在DHT网络中,每个DHT node都有一个ID,这个ID是一个很长的喘,每个DHT都掌握着一些知识,就是文件索引,也就是他应该知道哪些节点保存着哪些的文件
文件哈希,每个DHT node不会有着全局的只是,也不知道所有的文件保存在了哪里,只需要知道一部分
这个是通过了哈希算法计算的
每个文件都有一个哈希值,而DHT node的ID是和哈希值相同长度的串
DHT算法的规定是,如果一个文件算出一个哈希值,那么这个哈希值一样的那个DHT node,就有必要知道这个文件能从哪里下载
当然不会每次都能找到一样的,也可能一样的那个Node也应该知道,ID和这个哈希值非常接近N个DHT node也应该知道
什么叫哈希值接近呢?例如只修改了最后一位,就很接近,修改了倒数2位,也不远,修改了倒数3位,也可以,总之,能够凑齐N位就行
加入,我们一个文件1,通过哈希计算,得到了node c,那么node c利用知道1的存放地址
同理文件2通过hash计算,得到了node e,那么node e知道,如果 D E的id值接近了,那么D应该也需要知道
如果有一个新的节点 node new知道了,如果想要下载文件1,首先要加入DHT网络,如何加入呢?
首先说,因为DHT网络环境的原因,那么torrent文件中就保存了list的node节点,,那么我们假设这些节点中总有一个能连得上
加入找到了一个DHT node里面,加入了网络
node new会计算出一个文件1的哈希值,并且根据这个哈希值,来知道从这个哈希值和相临的node,从而方便去找这个对应的文件,
但是node new如何知道联系nodeC呢?因为node列表中可能没有node C,那么他只能去问,谁认识node C啊,在DHT网络中,每个node都保存了一定的联系方式,但是只是一部分,每个节点都会彼此通信,更新联系方式
而且有一个理论 六度理论.如果需要联系比尔盖茨,只需要六个人就能联系上了
如果node new想要联系nodec,就需要进行广播,求转发,这样node C联系上了
node C告诉node new,如果需要下载文件1,就需要去B D F去下载,于是node new 选择一个进行下载
然后下载了之后,就自己本地有了文件1了,那可以告诉node C和node C相邻的节点上,我也有文件1了,可以加入文件拥有列表了
但是node new上还么有文件索引,但是肯定有些文件的哈希值和node new 的ID能匹配的上,在DHT网络上,会有节点告诉他,应该知道哪些文件的下载地址
那么这些都分布式了,剩下的是一些细节上的问题
1.DHT node ID和文件哈希是什么?
节点ID是一个随机选择的160 bits空间,文件的哈希也是如此
2.ID什么样才算相似
在Kademlia网络中,距离是通过异或算的
假如,假如ID只有5位,一个ID为01010,另一个是00010,距离就是01000,为8
依次类推出来的,异或的位高的,距离远,低的距离近
这样就是ID近否的由来
那么朋友圈的维护是怎么样的呢?
DHT的联系方式,也是有一定规则的,按照距离分层,假设某个节点的ID是01010,如果一个节点的ID,前面所有的位数和其一致,只有最后一位不同,这样的节点只有一个,距离为1 00001,
这样的节点应归属于 k-bucket 1
如果一个节点和这个节点的异或是00010或者00011,那么就是距离2和3,归为k-bucket 2
这样一次类推
导致朋友圈到达了一定数量
DHT网络是如何查找朋友的?
假设一个node A的ID是00110,node B的ID位10000,异或距离为10110,距离范围5,在k-bucket 5
A查找B的话,就首先看自己的k-bucket 5中有没有B,如果有就好了,可能没有,没有的话,就在自己的k-bucket 5中查找一个C,因为C的ID的第5位肯定和B相同,那么和B的距离更小,相当于A B之间的距离缩短了一般
然后请求C,找B,如果有就好了,没有就嵌套的搜索,一步步的找到了B
对于总节点为N个的,只需要查找log2(N)就可以了
那么DHT中,朋友是如何沟通的呢?
Kademlia算法中
这个维护节点的指令,只有四个
PING:查看是否在线
STORE:要求一个节点存储一份数据
FIND_NODE:根据节点ID查找一个节点
FIND_VALUE:根据一个ID查找一个数据,主要就是找到了保存文件的节点
那么DHT如何更新朋友圈呢?
每个bucket的节点,按照最后一次接触的时间倒序排序,朋友圈最近接触过的人是最熟的
每次执行四个指令中任何一个都会触发更新
当一个节点与自己接触,都检查是否已经在k-bucket上,如果已经在了,就是挪到了最新的位置
如果是新的,就需要检查通信录是否已经满了,如果没满,直接加入最新的
如果满了,就ping一下最后接触的,然后ping通了,就舍弃新节点,如果ping不通,就舍弃旧的节点,将新的加入
这样保证了整体节点的网络畅通性
课后总结:
下载一个文件,可以采用的方式,可以是 HTTP和FTP,这两个都是集中下载的,P2P则是换了一种思路,采用非中心的下载方式
P2P有两种方式,一种依赖于tracker,元数据集中
一种是分布式的哈希算法 DHT,元数据和文件数据都打乱
接下来两个问题
1.去中心化分布式哈希的算法,还有什么应用场景吗
2.如果下载一个文件,需要使用域名,但网络通信使用的是IP,那么如何实现的映射的呢?
1.域名解析,这样也能做
2.使用DNS协议,进行了相关的映射
3.或者应用到区块链网络上
对于为什么可能出现下载文件99.9%的情况呢?
不管是什么方式的P2P,都是为了缓解server端压力,将压力放在了client端
而最后的99.9&的出现
1.两种原因,最后的校验,出现了某个问题,进行了重新下载
2.因为某个持有文件的client下线了,而只能从你这个99.9%中获取,于是先提供出去这些下载好的文件,方便他人下载,然后再下载完成下线
最后,无论是依赖于tracker,还是分布式哈希算法,p2p的主要能力,就是为了减少server压力,将压力转嫁给了client
99.9%的定义,最后校验出了错误,漏失了某个文件’
为何漏失了,还是p2p开宗明义,client流量压力多大下线了,其他人就无法找到这个文件了,顶多DHT网络告诉了每个client,漏失文件在某个下线的人手上,必须等着其上线,并且先把手上的其他的给其他人吧
为了解决这个问题,最早应该是迅雷,提供p2sp,长效种子
至于为何会99.99%,应该是进阶的技术问题