到目前为止，本章中描述的应用程序（包括 Web、电子邮件和 DNS）都采用客户端-服务器（client-server）架构，并且非常依赖于永远在线的基础架构服务器。 回想一下第 2.1.1 节，在 P2P 架构中，对永远在线的基础架构服务器的依赖最小（或不依赖）。 相反，成对的间歇连接的主机（称为对等点（peers））直接相互通信。 对等点不属于服务提供商，而是由用户控制的个人电脑、笔记本电脑和智能手机。<br />在本节中，我们考虑一个非常自然的 P2P 应用程序，即将一个大文件从单个服务器分发到大量主机（称为对等点）。 该文件可能是 Linux 操作系统的新版本、现有操作系统的软件补丁或 MPEG 视频文件。 在客户端-服务器文件分发中，服务器必须向每个对等方发送文件的副本——这给服务器带来了巨大的负担并消耗了大量的服务器带宽。 **在 P2P 文件分发中，每个对等方可以将其接收到的文件的任何部分重新分发给任何其他对等方，从而在分发过程中协助服务器。 截至 2020 年，最流行的 P2P 文件分发协议是 BitTorrent。**最初由 Bram Cohen 开发，现在有许多不同的独立 BitTorrent 客户端符合 BitTorrent 协议，就像有许多 Web 浏览器客户端符合 HTTP 协议一样。 在本小节中，我们首先在文件分发的上下文中检查 P2P 架构的自扩展性（self-scalability）。 然后，我们将详细介绍 BitTorrent，重点介绍其最重要的特性和功能。

P2P体系结构的可扩展性 Scalability of P2P Architectures

为了将客户端-服务器架构与对等架构进行比较，并说明 P2P 固有的自扩展性，我们现在考虑一个简单的量化模型，用于将文件分发到两种架构类型的一组固定对等点。 如图2.22所示，server和对等点通过访问链路连接到Internet。 我们表示服务器访问链路的上传速率，用表示第个节点访问链接的上传速率，用表示第个节点访问链接的下载速率。 还用 表示要分发的文件的大小（以位为单位），用 表示想要获取文件副本的对等节点的数量。 分发时间（distribution time）将文件拷贝到所有N个对等点所花费的时间。在我们对以下分发时间的分析中，对于客户端-服务器和 P2P 架构，我们做出了简化（并且通常准确 [Akella 2003]）假设互联网核心具有充足的带宽，这意味着所有瓶颈都在接入网络中 . 我们还假设服务器和客户端不参与任何其他网络应用程序，因此它们所有的上传和下载访问带宽都可以完全用于分发此文件。
让我们首先确定客户端-服务器架构的分发时间（distribution time），我们用 表示。 在客户端-服务器架构中，没有任何对等点有助于分发文件。 我们提出以下看法：

• 服务器必须将文件的一个副本传输到 N 个对等方中的每一个。 因此，服务器必须传输 位。 由于服务器的上传速率是，所以分发文件的时间必须至少是 。
• 表示下载速率最低的对等点的下载速率，即。 下载速率最低的对等点无法在小于 秒内获取文件的所有 位。 因此，最小分发时间至少为 。

将这两个观察结果放在一起，我们得到：

这为客户端-服务器架构提供了最小分发时间（minimum distribution time）的下限。 在家庭作业问题中，您将被要求证明服务器可以安排其传输以便实际达到下限。 所以我们把上面提供的这个下界作为实际的分发时间，也就是，

我们从公式 2.1 中看到，对于足够大的 ，客户端-服务器分发时间由 给出。 因此，分发时间随节点数 线性增加。 因此，例如，如果从一周到下一周的节点数量增加了一千倍，从一千到一百万，则将文件分发给所有节点所需的时间将增加 1,000。
现在让我们对 P2P 架构进行类似的分析，其中每个对等点都可以协助服务器分发文件。 特别是，当一个对等点收到一些文件数据时，它可以使用自己的上传能力将数据重新分发给其他对等点。 计算 P2P 体系结构的分发时间比客户端-服务器体系结构要复杂一些，因为分发时间取决于每个对等点如何将文件的一部分分发给其他对等点。 然而，可以获得最小分发时间的简单表达式 [Kumar 2006]。 为此，我们首先进行以下观察：

• 在分发开始时，只有服务器拥有该文件。 为了让这个文件进入对等社区（the community of peers），服务器必须至少将文件的每一位发送到它的访问链路中。 因此，最小分发时间至少为 。 （与客户端 - 服务器方案不同，服务器发送一次的位可能不必再次由服务器发送，因为对等点可能会在它们之间重新分发该位。）
• 与客户端-服务器架构一样，下载速率最低的对等点无法在小于 秒的时间内获取文件的所有 位。 因此，最小分配时间至少为 。
• 最后观察到整个系统的总上传能力（total upload capacity）等于服务器的上传速率加上各个对等点的上传速率，即。 系统必须向 个对等体中的每一个传送（上传） 个比特，从而总共传送 个比特。 这不能以比 更快的速度完成。 因此，最小分发时间也至少为 。

将这三个观察结果放在一起，我们得到了 P2P 的最小分发时间，用 表示。

公式 2.2 提供了 P2P 架构的最小分发时间的下限。 事实证明，如果我们想象每个对等点在收到比特后就可以重新分发比特，那么就有一种再分发方案（redistribution scheme）实际上达到了这个下限 [Kumar 2006]。 （我们将在作业中证明这个结果的一个特例。）实际上，在重新分发文件块而不是单个位的情况下，公式 2.2 可以很好地近似实际最小分配时间。 因此，我们取公式 2.2 提供的下界作为实际最小分发时间，即

图 2.23 比较了客户端-服务器和 P2P 架构的最小分发时间，假设所有对等点都具有相同的上传速率 。 在图 2.23 中，我们设置 小时，，。 因此，一个对等点可以在一小时内传输整个文件，服务器传输速率是对等点上传速率的10倍，并且（为简单起见）对等点下载速率设置得足够大，以免产生影响。 我们从图 2.23 中看到，对于客户端 - 服务器架构，分发时间随着对等点数量的增加而线性且无限制地增加。 但是，对于P2P架构，最小分发时间不仅总是小于客户端-服务器架构的分发时间； 对于任意数量的对等点 ，它也少于一小时。因此，具有 P2P 架构的应用程序可以自我扩展。 这种可扩展性（scalability）是对等点既是比特的再分发者（redistributors）又是比特消费者（consumers）的直接结果。

Figure 2.23 ♦ Distribution time for P2P and client-server architectures

BitTorrent

BitTorrent 是一种流行的 P2P 文件分发协议 [Chao 2011]。 在 BitTorrent 行话中，参与分发特定文件的所有对等点的集合称为 torrent（种子）。 Torrent 中的对等点相互下载相同大小的文件块，典型的块大小为 256 KB。 当对等点首次加入 torrent 时，它没有块。 随着时间的推移，它积累了越来越多的块。 在下载块的同时，它也会将块上传到其他对等点。 一旦对等点获取了整个文件，它可能（自私地）离开种子文件，或（无私地）留在种子文件中并继续向其他对等点上传块。 而且，任何对等点都可以在任何时候只带着块的子集离开种子，然后再重新加入种子。
现在让我们仔细看看 BitTorrent 的运作方式。 由于 BitTorrent 是一个相当复杂的协议和系统，我们将只描述其最重要的机制，并深入了解一些细节； 这将使我们能够透过树木看到森林。 每个 torrent 都有一个称为跟踪器（tracker）的基础设施节点（infrastructure node）。 当对等点加入 torrent 时，它会向跟踪器注册自己，并定期通知跟踪器它仍在 torrent 中。 通过这种方式，跟踪器跟踪参与 torrent 的对等点。 在任何时刻，给定的 torrent 可能有少于十个或多于一千个节点参与。
如图 2.24 所示，当新的对等点 Alice 加入 torrent 时，跟踪器从参与的对等点集中随机选择一部分对等点（具体来说，假设为 50 个），并将这 50 个对等点的 IP 地址发送给 Alice 。 拥有此对等点列表，Alice 尝试与此列表中的所有对等点建立并发 TCP 连接。 让我们将所有与 Alice 成功建立 TCP 连接的对等点称为“邻居对等点（neighboring peers）”。 （在图 2.24 中，Alice 只有三个相邻的对等点。通常，她会有更多。）随着时间的推移，其中一些对等点可能会离开，而其他对等点（最初的 50 个之外）可能会尝试与 Alice 建立 TCP 连接。 所以一个对等点的相邻对等点会随着时间的推移而波动。

Figure 2.24 ♦ File distribution with BitTorrent
在任何给定的时间，每个对等点都将拥有文件中的一个块子集，不同的对等点具有不同的子集。 定期，Alice 会向她的每个相邻对等方（通过 TCP 连接）询问他们拥有的块列表。 如果 Alice 有 L 个不同的邻居，她将获得 L 个块列表。 有了这些信息（knowledge），Alice 将为她目前没有的块发出请求（再次通过 TCP 连接）。
所以在任何给定的时刻，Alice 都会有一个块的子集，并且知道她的邻居有哪些块。 有了这些信息，Alice 将要做出两个重要的决定。 首先，她应该首先向邻居请求哪些块？ 其次，她应该将请求的块发送给她的哪个邻居？ 在决定请求哪些块时，Alice 使用了一种称为最稀有优先（rarest first）的技术。 这个想法是从她没有的块中确定她的邻居中最稀有的块（即邻居中重复副本最少的块），然后首先请求那些最稀有的块。 通过这种方式，最稀有的块可以更快地重新分配，旨在（大致）均衡种子中每个块的副本数量。
为了确定她响应了哪些请求，BitTorrent 使用了一种巧妙的交易算法（trading algorithm）。基本思想是 Alice 优先考虑当前以最高速率提供她的数据的邻居。具体来说，对于她的每个邻居，Alice 不断测量她接收比特的速率，并确定以最高速率馈送（feeding）她比特的四个对等点。然后，她通过向上述（same）这四个对等点发送块来作为回报（reciprocates）。每 10 秒，她重新计算速率并可能修改四个对等点的集合。在 BitTorrent 行话中，据说这四个对等点是非阻塞的（unchoked）。重要的是，每 30 秒，她还会随机选择一个额外的邻居并发送给它组块（chunks）。让我们调用随机选择的对等节点 Bob。在 BitTorrent 行话中， Bob 是乐观非阻塞（optimistically unchoked）。因为 Alice 正在向 Bob 发送数据，所以她可能成为 Bob 的前四个上传者之一，在这种情况下，Bob 将开始向 Alice 发送数据。如果 Bob 向 Alice 发送数据的速率足够高，那么 Bob 可以反过来成为 Alice 的前四名上传者之一。换句话说，每 30 秒，Alice 将随机选择一个新的交易伙伴并与该伙伴开始交易。 如果两个同行对交易感到满意，他们会将彼此放在前四名的名单中，并继续相互交易，直到其中一个同行找到更好的合作伙伴。 结果是能够以兼容速率上传的对等点倾向于找到彼此。 随机邻居选择还允许新对等点获得块，以便他们可以进行交易。 除了这五个对等点（四个“顶级”对等点和一个探测（probing）对等点）之外的所有其他相邻对等点都被“阻塞（choked）”，也就是说，它们不会从 Alice 那里收到任何块。 BitTorrent 有许多有趣的机制，这里没有讨论，包括片段（pieces）（迷你块）、流水线（pipelining）、随机优先选择（random first selection）、结束模式（endgame mode）和反冷落（anti-snubbing） [Cohen 2003]。
刚才描述的交易激励机制（The incentive mechanism for trading）通常被称为针锋相对（tit-for-tat） [Cohen 2003]。 事实证明，这种激励机制是可以规避的 [Liogkas 2006; 洛赫 2006; 皮亚泰克 2008]。 尽管如此，BitTorrent 生态系统还是非常成功，数以百万计的同步节点在数十万个种子中积极共享文件。 如果 BitTorrent 的设计没有针锋相对（或变体），但在其他方面完全相同，BitTorrent 现在可能甚至不存在，因为大多数用户将是免费搭便车（freeriders） [Saroiu 2002]。
我们通过简要提及 P2P 的另一个应用，即分布式哈希表 (Distributed Hast Table，DHT) 来结束对 P2P 的讨论。 分布式哈希表是一个简单的数据库，数据库记录分布在 P2P 系统中的对等点上。 DHT 已被广泛实施（例如，在 BitTorrent 中）并且已成为广泛研究的主题。 配套网站的视频注释中提供了概述。