计算机网络笔记No.8

P2P文件分发举例

• 纯P2P架构
  • 没有服务器
  • 任意端系统之间直接通信
  • 节点阶段性接入Internet
  • 节点可能更换IP地址

假设中心网络具有足够带宽，服务器上传带宽为u_s，节点i的上传带宽为u_i，节点i的下载带宽为d_i
问题 : 从一个服务器向N个节点分发一个文件需要多长时间?

CS（客户机/服务器） 文件分发：

.服务器串行地发送N个副本，需要时间：NF/u_s；
客户机i需要下载的时间：F/d_i
那么总时间表示为： d_cs = max { NF/u_s, F/min(d_i) }

P2P文件分发

服务器必须发送一个副本，时间： F/u_s
客户机i需要i下载时间：F/d
总共需要下载NF比特，最快的可能上传速率：u_s + ∑u_i
那么总时间表示为：d_P2P = max { F/u_s, F/min(d_i) , NF/(u_s + ∑u_i) }

对比

客户端上传速率 = u，F/u = 1小时， u_s = 10u,，d_min ≥ u~s

CS：随着 N 增大，下载时间线性增加
P2P：下载时间总是小于CS

P2P应用：BitTorrent应用

文件分发应用 BT下载

• 使用BT传输一个文件，文件会被划分为若干个 256KB大小的chunk（块）
• 当有节点加入时，它没有 chunk ，但是随着时间逐渐累积——向tracker注册以获得节点清单，与某些节点（“邻居”）建立连接，从他们那里获取
  • 获取chunk
    • 给定任一时刻，不同的节点持有文件的不同chunk集合
    • 节点定期查询每个邻居所持有的chunk列表
    • 节点发送请求，请求获取缺失的chunk（稀缺优先算法）
• 下载的同时，节点也需要向其他节点上传 chunk
  • 发送chunk
    • 向其他邻居发送chunk：正在向本节点发送Chunk的速率最快的4个(每10秒重新评估top4)
    • 每30秒随机选择一个其他节点，向其发送chunk（新选择节点可能加入top 4）

P2P应用：索引技术

P2P系统的索引：信息到节点位置(IP地址+端口号)的映射

• 文件共享(电驴)
  • 利用索引动态跟踪节点所共享的文件的位置
  • 节点需要告诉索引它拥有哪些文件
  • 节点搜索索引，从而获知能够得到哪些文件
• 即时消息(QQ)
  • 索引负责将用户名映射到位置
  • 当用户开启IM应用时，需要通知索引它的位置
  • 节点检索索引，确定用户的IP地址

索引存储方式：集中式、洪泛式查询、层次式

集中式索引

• 节点加入时，通知*服务器需要 IP地址、内容，*服务器提供节点的位置
• 节点通过服务器提供的信息查询并请求

集中式索引的问题：单点失效问题、性能瓶颈、版权问题
内容和文件传输是分布式的，但是内容定位是高度集中式的

洪泛式查询

完全分布式架构

• 查询消息通过已有的TCP连 接发送
• 节点转发查询消息
• 如果查询命中，则利用反向 路径发回查询节点

可能会造成网络堵塞

层次式覆盖网络

介于集中式索引和洪泛查询之间的方法，

覆盖网络(overlay network): Graph

• 节点X与Y之间如果有TCP连接， 那么构成一个边
• 所有的活动节点和边构成覆盖网络
• 边：虚拟链路
• 节点一般邻居数少于10个

• 每个节点或者是一个超级节点，或者被 分配一个超级节点
  • 节点和超级节点间维持TCP连接
  • 某些超级节点对之间维持TCP连接
• 超级节点负责跟踪子节点的内容

—————————————————————————————————————————————

由于本人水平有限及时间仓促或疏忽大意以及其他的一些原因，文中难免会存在一些错误，如若有发现不正确的地方，还请大佬们评论或私信告之于我，以便及时纠错