P2P 技术概述（一）

P2P (Peer to Peer，点对点) 是一种分布式网络应用架构，其各个交互实体都是对等的，这里对等是指各交互实体是在网络中同等特权、同等能力的参与者（后面我们会使用对等体称呼这些交互实体或者叫参与者），这些对等体共同形成了一个点对点的节点网络。

在我们日常接触的各种应用中大多数应用，无论是桌面应用，还是移动应用，或者是网页应用，通常来说是单机架构或者 C/S 架构。单机架构不涉及网络这里我们不做讨论。C/S 架构中 C 表示客户端（client），S 表示服务端（server），通常来说服务端是集中的，客户端是分散的，连接请求由客户端发起。其抽象模型如下图：

在当前 NAPT 无处不在的情况下这种架构是各种服务提供商为客户提供服务的最简单的选择也是首选。这种架构的优点：简单，易用管理。缺点：Server 端集中，是整个系统的风险点与瓶颈。而 P2P 架构的优缺点正好是和 C/S 架构是反过来的。

P2P 的两大特性

• 点对点

  点对点最大的优势是增加了实时性，在上面 C/S 架构中，两个 Client 想要通信，通信的数据包必须要先经过服务器在转发到另一个 Client，这无疑是增长了通信线路，而且如果 Client 过多，Server 很容易成为瓶颈点，而且 Server 也容易成为信息泄露的风险点。貌似说微信的通信就是点对点的，腾讯服务器不会记录用户的聊天记录，但是实际上是不是这样的作者无法考证。

• 分布式

  分布式的优势是增加了数据的安全性。在 C/S 架构中敏感数据和重要数据都存放在 Server 端，P2P 架构中数据分散存储在各对等体中，而且各对等体中互相有数据备份。

P2P 的这两大特性催生了两大神级应用：WebRTC 和 IPFS，本合集后续的文章我们详细介绍着两大神级应用的应用场景和计算原理。

P2P 难点：无处不在的 NAPT

说完了 P2P 的的特性，我们在来看一看 P2P 应用需要克服的最大困难。

NAPT 的出现最开始是为了解决 IPv4地址不足的问题。他最大的特性：NAPT 后的设备使用 NAT 网关的地址与外界联系，当设备不主动与外界联系时，外界就无法感知到该设备。NAPT 在当今 C/S 架构应用普遍存在的网络中工作的很好，C/S 架构永远都是客户端先发起请求，数量众多的客户端位于 NAT 网关后，集中的服务端位于公网（这种应用场景也提供了客户端网络环境的安全性）。但是对于 P2P 应用，这就是一道必须要克服的大山：如何使位于 NAT 网关后的设备能互相访问？

NAT 网关通常来说由防火墙设备承担，所有上图中 NAT 网关我使用了防火墙的图标。NAT 网关会拒绝一起主动访问网关后设备的流量。除非 NAT 网关后的设备主动访问了外部的设备，网关会放行外部设备回复的流量。

回到 P2P 应用，因为 NAPT 无处不在，所有 P2P 应用的对等设备通常都会位于 NAT 网关后，这也就导致了这些设备无法被外部发现，任何一个对等体向其他对等体发送请求都会被对方的 NAT 网关拒绝。为了克服这个困难，P2P 应用的基础技术就是 NAT 打洞，又称 NAT 穿透，内网穿透。WebRTC 专门在 github 创建了 pion 项目来提供 NAT 打洞的解决方案。IPFS 则是创建了 libp2p 项目来开源他们的打洞技术。

因为小编最近一直在研究 pion，而且 pion 是按照 IETF 一些列标准来实现的，兼容性会比较强。所以后续文档有优先介绍 pion 使用到的一些列技术。对于 IPFS 的 libp2p 小编还没来得及详细研究，待小编后续一番研究后也会出一篇详细的文档。

关于 P2P 的概述的内容就先讲到这里，这篇概述只是简单的提到了 P2P 使用到的技术，在后续我会在写一些列文章详细讲解 P2P 原理及应用，初步规划的章节：NAT 的原理及分类；NAT 会话穿越工具 STUN；使用中继技术实现 NAT 穿越 TURE；交互式连接建立 ICE；体验 WebRTC。

另外需要强调的一点：上面已经后续的章节主要说明的是如何在广域网也就是互联网环境下构建 P2P 应用。还有一些 P2P 应用专门在局域网下运行的，如阿里云团队开源的一款快速分发文件的工具Dragonfly。