＜计算机网络自顶向下＞ P2P应用

纯P2P架构

• 没有或者极少一直运行的Server，Peer节点间歇上网，每次IP地址都可能变化
• 任意端系统都可以直接通信
• 利用peer的服务能力，可扩展性好
• 例子：文件分发; 流媒体; VoIP
• 类别:两个节点相互上载下载文件，互通有无，构成覆盖网overlay（这种网络是逻辑的网络因为是在应用层的网络）
  • 非结构化P2P: 随机连接（集中化目录）
  • DHT（结构化）P2P: 形成特定的结构比如环或者树
• 缺点：难以管理，服务器动态，上载能力动态
• 问题：解决方法有集中，分散，半分散
  • 如何定位所需资源
  • 如何处理对等方的加入与离开

C/S VS P2P

从一台服务器分发文件（大小F）到N个peer需要多少时间：

|---------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------|
| | |

非结构化P2P

• P2P文件分发：bitTorrent
  • 文件被分为一个个块(chunk)，一个256KB
  • 每个peer维护一个bitmap，每个比特代表是否拥有某个块
  • 定期peers交换bitmap知道对方用有啥块
  • 网络中peers发送接收文件块，相互服务。请求稀缺块优先，防止那些拥有的peers全部下线（扰动churn）；提供服务的时候优先想那些给自己提供好的服务（比如带宽大）的节点服务
  • 有限的疏通：一次服务有限的节点，疏通它们，然后其他节点排队（不是FCFS，前三分之二个选择周期选择给自己提供好的服务的节点，后面三分之一个周期是随机选择），防止性能差

perrs都 tit-for-tat（以牙还牙）

• 节点加入洪流工作过程：带外解决（out of bound）
  有文件分发检索的网站，输入关键字，匹配文件（这里匹配的是文件哈希值，文件尚在下载是包括文件本身、唯一的哈希值和文件的描述）这些检索的网站上有一个torrent文件，这个文件包含跟踪文件的checking server（维护的是哪些节点在上载下载该文件）根据某些测略给发送请求的节点一个torrent文件里面的一些目标节点列表，然后发出请求的节点与列表中的节点互通有无形成洪流

集中式目录（集中）

• 维护一个目录知道每个节点已有的资源：文件传输是分散，定位内容高度集中
  • 问题：
    1. 单点故障
    2. 性能瓶颈：peer上线下线都要上报，会有性能问题
    3. 侵犯版权：很难处理侵权行为，一般一侵权就很多人
  • 例子：Napster

完全分布式目录 （分散）

• 没有中心服务器
• 每个节点都构成overlay
• 例子：Gnutella（泛洪现象flooding）
• 问题
  • 没完没了的转发查询（但是可以通过设置TTL等解决这个问题，使得泛洪有限）

加入节点的过程退出节点的过程：分别告诉邻居自己要退出了。邻居知道他要离开了以后找一个新的节点以维持平衡。

混合体 （半分散）

• 每个对等方要么是一个组长，要么隶属于一个组长
  • 组长和组员的关系相当于Napster
  • 组长和组长的关系相当于Gnutella
• 例子：KaZaA

DHT（结构化）P2P

• 按照id（哈希）大小形成固定结构，分发的每一个文件也通过哈希标识