P2P文件分发与BitTorrent

P2P（Peer-to-Peer）

P2P体系结构中，其中每个peer节点都能够帮助服务器来分发文件。也就是说，当一个peer节点接收到文件数据时，它可以利用自己的上载能力重新将数据分发给其它peer节点。

BitTorrent

BitTorrent是一种用于文件分发的P2P协议，其中参与一个特定文件分发的所有peer的集合被称为洪流（torrent）。在一个torrent中的peer彼此下载等长度的文件块（chunk），块长度通常为256KB。

当一个peer节点一开始加入一个torrent时，它没有文件块。随着时间的推移，它将累积越来越多的文件块。当它下载文件块时，也为其它peer节点上载了多个文件块。peer节点一旦获得了整个文件，它可以自私地离开torrent，也可以大公无私地留在torrent中并继续向其它peer节点上载文件块。

例如，当一个peer节点Alice加入torrent时，追踪服务器随机选择一些peer节点，并将这些peer节点的IP地址发送给Alice。Alice持有这些peer节点的列表，试着与该列表上的多个peer节点创建并行的TCP连接。这里称所有与Alice成功地创建TCP连接的peer节点为邻近peer节点（neighboring peers）。

随着时间的推移，其中的一些peer节点可能离开，而其它peer节点可能试着与Alice创建TCP连接。因此，邻近peer节点会随着时间而改变。

在任何时刻，每个peer节点都拥有来自某文件块的子集，且不同的peer节点具有不同的文件块子集。Alice周期性地询问每个邻近peer节点它们所具有的块列表，并对当前还没有的块发出请求。

Alice使用一种称为最稀缺优先（rarest first）的策略，其思路是根据她没有的块从她的邻居中找到拷贝数量最少的那些块，并优先请求这些稀缺块。因此，最稀缺的块会更迅速地分发，其目标是均衡每个块在torrent中的拷贝数量。

分发时间的容量下界

用比特表示文件大小$F$，服务器上载速率为$u_s$，最慢对等方下载速率为$d_{min}$，有$N$个接收方。服务器单独分发需要上载$NF$比特，每个接收方仍要下载$F$比特，因此：

P2P中，服务器至少送出一份完整文件，而对等方也能贡献上载速率$u_i$：

这些是理想容量下界，不是任意分块与调度都能达到的保证。连接开销、块不可用、对等方离开与实际调度都可能增加耗时。追踪服务帮助发现邻居，并不要求所有文件正文都经过追踪服务器。