(1) 最稀缺优先（Rarest First）#

• 逻辑：在下载过程中，Peer 并不是从头到尾按顺序下载文件的，而是统计所有邻居拥有的块，计算每个块在当前局部网络中的副本总数。优先请求那个副本数量最少的块。
• 深度原因：
  • 防止“孤块”断供：如果大家都先下热门块，而唯一拥有稀缺块的 Seeder 下线了，文件分发就会卡在 99% 永远无法完成。最稀缺优先同时让块在网络中分布更均匀。
  • 提高交换价值：你手里持有的块越稀缺，你在 Peer 群中的“议价能力”就越强，别人越愿意为了换取你的稀缺块而给你提供带宽。

(2) “一报还一报”策略（Tit-for-Tat）#

为了防止“只下载不上传”的吸血鬼行为，BT 引入了激励机制：

• Unchoked： Peer 会每隔10秒评估邻居的上传速率，选出 前 4 名 速度最快的邻居设为**Unchoked(解除阻塞)**状态，给他们全速发送数据，形成正反馈循环。
• Optimistic Unchoking：（乐观疏通）每隔30秒，随机选择一个被阻塞(Choked)的邻居发送数据。
  • 作用： 让新加入的 Peer 有机会获取第一个块，从而进入交换循环，而不是永远无法获得数据。这也有助于发现更有潜力的邻居。

集中式目录（Napster模式）#

这是最早期的 P2P 形式，虽然传输是点对点的，但目录查找是中心化的。

• 运行逻辑：
  1. 每个 Peer 上线后，向中央服务器注册自己拥有的文件列表。
  2. 中央服务器维护一个庞大的数据库（IP 地址 + 文件名）。
  3. 当 Peer A 想搜资源时，询问中央服务器。服务器返回持有该文件的 Peer B 的 IP，A 再直接连 B 下载。
• 致命缺陷：
  • 单点故障(Single Point of Failure)：服务器挂了，整个网络瞬间瘫痪。
  • 性能瓶颈：随着用户达到千万级，服务器处理查询请求的压力巨大。
  • 法律风险：由于服务器明明白白地记录了谁在分享版权内容，Napster 很快就因为侵权被法律诉讼直接封禁。

全查询泛洪（Gnutella模式）#

为了摆脱对中心服务器的依赖，Gnutella 走向了另一个极端：完全去中心化。

• 运行逻辑：
  1. 覆盖网络(Overlay Network)：Peer 之间建立逻辑连接（每个 Peer 随机连几个邻居）。
  2. 泛洪查询(Flooding)：Peer A 想搜文件，就给所有邻居发查询请求Query。
  3. 递归转发：邻居收到后，如果自己没有，就转发给它的邻居。
  4. TTL：为了防止请求在互联网上无限循环，每个请求都有一个 TTL（通常为 7），每转发一次减 1，减到 0 就丢弃。
  5. 逆向响应：如果 Peer B 找到了文件，它会沿着查询过来的路径（Reverse Path）回传一个 QueryHit 消息。
• 致命缺陷：
  • 广播风暴：网络中充斥着海量的查询报文。如果网络有 100 万人，每人搜一次，产生的流量会瞬间瘫痪互联网。
  • 搜索延迟高：可能搜了半天，请求还没传到有资源的人那里 TTL 就耗尽了。

层次化覆盖网络（KaZaA / 电驴 / Skype）#

这是对前两代的“折中方案”，它引入了**超级节点(Super Nodes)**的概念。

• 运行逻辑：
  1. 角色分化：根据带宽、CPU 和稳定性，将 Peer 分为普通节点和超级节点。
  2. 局部集中：普通节点只连接一个超级节点。普通节点把自己拥有的文件列表告诉超级节点。
  3. 超级节点互联：超级节点之间组成一个高层的 P2P 网络，互相交换索引信息或转发查询。
  4. 查询路径：普通节点查询 -> 请求发给超级节点 -> 超级节点在本地查（快）或者去问其他超级节点（范围广）。
• 优势：
  • 兼顾效率与抗压：不像 Napster 那样脆弱，也不像 Gnutella 那样混乱。
  • 性能优化：它利用了互联网中“长尾效应”里的头部节点（高带宽、常年在线的用户）来承担索引任务。

核心思想：Hash 映射，将文件名和节点IP映射到同一个数值空间内，被赋予了同样的身份地位#

1. 哈希化：每个文件通过 SHA-1 等算法得到一个 160 位的InfoHash，每个 Peer 启动时，根据其 IP 和端口同样算出 160 位的Node ID。
2. 就近存储原则：Key 为 $K$ 的文件索引信息，必须存储在 Node ID 与 $K$ 在数学上异或(XOR)距离最近（非物理距离）的那个节点上。

查找流程：$O(\log N)$ 路由#

• 路由表(K-buckets)：节点会把 160 位的 ID 空间切分成 160 个区域（桶）。每个节点只记录少数邻居的信息，但这些邻居是按规则分布的（如 Chord 算法中的手指表，或 Kademlia 中的 K 桶）。
• 跳跃式查找：
  • 当你要找 Key 为 $K$ 的文件，而你手里没有时，你会把请求发给 Node ID 最接近 $K$ 的3位邻居发送，FIND_NODE(K) 请求。
  • 这些邻居收到请求后，如果自己没有 $K$ 的信息，会返回它们各自路由表中离 $K$ 最近的Node ID节点名单。
  • 你拿到一堆新的、更近的Node ID名单，更新自己的候选列表，然后再向这批新节点发请求。定位到距离 $K$ 最近的节点，对方返回持有该文件的 Peer IP 列表。
• 确定性：就像二分查找一样不断逼近，搜索空间呈指数级缩小。在有 100 万个节点的网络中，通常只需要 10~20次 跳转就能精准定位资源。

数据的存储与发布 (Publishing)#

当你（Peer B）拥有一个文件想分享给别人时，不需要上传到服务器，只需在 DHT 网络中：

1. 计算 Hash：算出文件的 Key $K$。
2. 寻找归宿：发起上述的 DHT 查找流程，找到全网 Node ID 离 $K$ 最近的 20 个节点。
3. 宣告存储：向这 20 个节点发送 STORE 请求，告诉它们：“我是 Peer B，我手里有 $K$ 这个文件，请帮我记录一下。”
4. 定期刷新：为了防止节点下线导致索引丢失，Peer B 会定期（如每小时）重新发布一次。