之前讨论的都是采用了客户-服务器体系结构，极大地依赖于总是打开的基础设施服务器。而P2P体系结构对总是打开的基础设施服务器有最小的（或者没有）依赖。与之相反，成对间歇连接的主机（称为对等方）彼此直接通信。
P2P文件分发
P2P体系结构的拓展性
通过观察上图P2P和客户服务器架构的分发时间对比可以得出如下结论：
客户端－服务器体系下，分发时间随着对等方数量线性增加
P2P体系下，分发时间呈线性增长而趋向一个常数，若F表示分发的文件比特数量，u表示所有对等方具有的相同上传速率，则这个常数为F／u。
因此，具有P2P体系结构的应用是能够自扩展的。这种扩展的直接成因是：对等方除了是比特的消费者外还是他们的重新分发者
最为流行的P2P协议是BitTorrent，迅雷的种子下载就属此例。
BitTorrent
洪流（torrent）：参与一个特定文件分发的所有对等方的集合
追踪器（tracker）：每个洪流具有的一个基础设施结点
邻近对等方：成功创建一个TCP连接的对等方
工作过程：
当一个对等方加入某洪流时，它向追踪器注册自己，并周期性地通知追踪器它仍在该洪流中。以这种方式，追踪器跟中正参与在洪流中的对等方。
如上图，假设有一个新的对等方Alice加入一个洪流
- 追踪器随机地从参与对等方的集合中选择对等方的一个子集（比如50个）并将这50个对等方的IP地址发送给Alice，Alice拥有了一个IP地址的列表
- Alice试图与列表上的所有对等方创建TCP连接，成为邻近对等方。图上显示有3个，实际上应该有多个。
- Alice周期性的询问每个邻近对等方他们所具有的块列表。
- 对当前自身没有的块信息，Alice发送请求获取（通过最稀缺优先技术确定请求哪个块）。向那些向她请求的块的邻居发送邻居没有的而自己有的块信息。BitTorrent使用了一种对换算法。该对换算法的基本思想是Alice根据当前能够以最高速率向她提供数据的邻居，给出其优先权。
兑换算法操作过程如下：
Alice对于她的每个邻居持续的测试接收到比特的速率，并确定以最高速率流入的4个邻居
每过10秒，她重新计算该速率并可能修改这4个对等方的集合
每隔30秒，Alice要随机选择另外一个邻居并向其发送块，也即Alie随机选择一名新的对换伴侣。
这种效果是对等方能够趋于找到彼此的协调的速率上载。随机选择邻居也允许新的对等方得到块，因此他们能够具有对换的东西，除了上诉5个对等方，其它对等方均被阻塞。这种交换激励机制也称为“一报还一报”。
分布式散列表
集中式数据库一般是直接采用客户-服务器体系结构，以在一个中心服务器中存储所有键值对。
这里考虑构建这种数据库的一个分布式、P2P版本，在数以百万计的对等方上存储键值对。在该P2P系统中，每个对等方将保持键值对仅占总体的一个小子集。我们将允许任何对等方用一个特别的键来查询该分布式数据库。分布式数据库则将定位拥有该响应键值对的对等方，然后向查询的对等方返回该键值对。任何对等方也将允许在数据库中插入新键值对。这样一种分布式数据库被称为分布式散列表（DHT）
- 首先，为每个对等方分配一个标识符，每个标识符是一个[0,2^n-1]范围内的整数，n取某些固定的值。同时要求键也是同一范围内的一个整数。对于键不是整数的记录，使用散列函数把键映射到[0,2^n-1]范围内的整数。这也是为什么叫散列表的原因
- 其次，定义为对等方分配键的规则。将最邻近对等方定义为键的最邻近后继。如果该键恰好等于这些对等方标识符之一，我们在匹配的对等方中存储键值对；如果该键大于所有对等方标识符，我们使用模2^n规则，在具有最小标识符的对等方中存储键值对。
- 然后，将对等方组织为一个环。在这种设置中，每个对等方仅与它的直接后继和直接前任联系（模2^n）。但是也会出现一个问题，就是由于每个对等方只知道两个邻居对等方，为了找到负责的键，DHT平均需要发送N/2条报文。所以，在设计DHT时，每个对等方必须跟踪的邻居数量与DHT 为解析而需要发送的报文数量存在着折中。已有研究表明DHT能被设计成每个对等方的邻居数量以及每个请求的报文数量均为O（logN）。
可以看到就是一个循环双向链表，对于对等方离开和加入也和链表插入和删除相同。