大多数时候，定义问题比找到答案更难，也更有价值。这个世界需要困难的、明确界定的问题。
互联网所固有的问题是什么?可能是“内容交付”问题的不同方面，例如，客户端的内容加速，高质量的视频交付等到。事实上，一个更好的互联网概念已经走进了大众的视野，即使用 P2P 协议在互联网上以完全分布式的方式发布内容。如果可以做到这一点，就可以建立一个完全去中心化的互联网。特别地，IPFS正在寻找定义分发和定义“ Web”的全新方法。
这样的互联网理念确实有意义，但它将如何构建呢?
P2P的固有问题
在《面向互联网应用的网络优化》一文中谈到了内容分发的四种体系结构: 集中式托管、大型数据中心的CDN、高度分布式CDN 和 P2P 网络。其中指出：P2P 可以被认为是将分布式架构推向了逻辑极限，理论上提供了近乎无限的可伸缩性。此外，在目前的网络定价结构下，P2P 提供了很有吸引力的经济性。
尽管 P2P 设计在理论上是可伸缩性最好的，但仍然存在一些实际问题，特别是吞吐量、可用性和容量。
吞吐量
最常见的问题是边缘设备的上行链路容量有限，最主要的原因是 P2P 网络的总下载容量由于其总上行容量而受到限制。不幸的是，对于普通用户的宽带连接，上行速度往往比下行速度低得多。一个上传速率低于这些下行速率四分之一P2P网络是否足够了呢?
有研究表明，一旦客户端的可用带宽达到5mbps，那么对最终用户页面负载的影响可以忽略不计。
可用性
应用P2P的下一个主要障碍是对等节点的可用性。换句话说，是否有足够的参与者，他们是否在线并且有足够的时间提供价值?如今，边缘设备的数量确实增加了，但是增加的够多了吗?
许多人有多种设备，这是一个巨大的边缘设备池。走向数万亿的设备。有足够多的在线设备可能是安全的，但是普通用户在线的时间足够长吗?什么是“足够长的时间”?
赤道约40,000公里。根据经验数据，光通过光纤传输1公里需要4.9微秒。这意味着数据可以在1/5秒(196毫秒)内绕地球一周。如果认为互联网的运行速度至少比这慢两倍。这2倍的减速意味着环绕地球大约需要400毫秒。不幸的是，这个时间需要再加倍，以便考虑到全球传输路由，即便如此，数据可能也可以大约在大约800毫秒内传遍全世界。真正的问题是，全球用户的平均浏览时间是多少?有人统计的结果是是3分36秒，或216,000毫秒。
无论哪种情况，如果节点在线时间足够下载一个网页，那么数据就有足够的时间环绕地球数百次，当然足够与地球上任何地方的同行联系。
容量
如果有足够多的用户在线时间足够长，并且他们有一个可接受的出口吞吐量(上传带宽) ，剩下的问题就是是否有足够的空闲容量(磁盘空间)来提供一个正常运行的网络。如果请求的内容遵循 Zipf 分布，就可以估算P2P网络单元的大小，进而达到一个给定的缓存命中率。
互联网资源加载的P2P支持
如果已经更好地定义了问题，并建立了一个方案的理论可行性，接下来便是关注技术实现了。IPFS 之类的实现关注于分发整个内容库，允许用户完全摆脱 Web 服务器和 DNS 的限制。这是一个了不起的大规模改变，但代价是需要用户修改他们访问内容的方式。
由于 P2P 设计依赖于总的网络规模，这种模型在达到临界质量之前很难发展。如果提高现有 web 内容的透明交付，而不需要对用户体验进行任何更改，就意味着确保该技术遵守以下三个限制:
- 对于用户来说，解决方案应该是透明的
- 对于开发人员，解决方案应该要求零基础设施更改
- 对于操作，解决方案应该是自我管理的
对所有内容完全支持P2P是困难的，特别是允许执行具有业务逻辑的 JavaScript脚本。然而，如果关注流量的比重，会发现静态组件(图片/视频/字体/CSS)大约占网站数据的80%左右，部分支持P2P或许是可行的。
支持P2P 的协议栈选择
为了支持 P2P 内容分发，需要开发一个覆盖网络，允许 P2P 连接在现有互联网基础设施中运行。幸运的是，这样的堆栈是可用的，那就是WebRTC。WebRTC 是一个浏览器内的网络协议栈，支持点对点通信，主要应用于语音和视频应用程序，以促进点对点视频和音频会议。
与依赖 TCP 传输的 HTTP 不同，WebRTC 依赖于一个更古老的协议——SCTP ，并将其封装在UDP中。这允许更低的延迟传输，消除了数据包队列头部阻塞，并且，作为一个独立的网络堆栈，允许 WebRTC 使用比单独使用 HTTP 显著更多的带宽。
SCTP 有点像OSI传输层的第三个轮子，我们经常忘记它的存在，但它有一些非常强大的功能， 提供了可靠的、面向消息的传输。除了 SCTP，WebRTC 还利用了两个附加的主要协议: 安全数据传输层加密协议(DTLS)和交互式连接建立协议(ICE) ，以支持网络地址转换(NAT)环境，例如防火墙穿越。可以说， WebRTC 拥有实现真正的点对点网络所需的所有管道。
P2P 的浏览器支持
目前，主流的浏览器如Chrome、 Firefox、 Edge 以及现在的 Safari 都支持 WebRTC。对于http请求的拦截，可以通过service worker实现。service worker是大多数浏览器中的新特性，它允许在浏览器中运行后台进程。与可用作线程代理的 Web worker 类似，service worker 对于如何与DOM交互和交换数据也有一些限制。然而，service worker有一个最初为支持离线页面加载而开发的强大特性: Fetch API。Fetch API 允许service worker拦截请求和响应调用，类似于 HTTP 代理。
通过service worker，现在可以截获传统的 HTTP 请求，并将这些请求加到 P2P 网络中。利用浏览器本地的存储模型，可以存储和分发 P2P加速的内容。虽然浏览器中存在多种不同的存储选项，但 IndexedDB是service worker和 DOM 中唯一可用的存储 API，WebRTC 代码可以在其中执行。
可能的优化
有了P2P的内容交付模型和一个可用的网络协议栈，就应该可以实现特定的高效传输和访问浏览器内存储介质。
一个简单的优化可能是优先选择驻留在同一网络中的对等节点，或许可以通过每个对等点的自治系统来标识，这样的优化可以将平均延迟减少两倍。
另一个优化是选择将哪些资源复制到对等节点。例如，如果一个用户当前正在浏览一个网站的登陆页面，本上可以预测下一个页面的所有图像，有效地完全消除延迟。
一句话小结
现在的世界比以往任何时候都更加紧密联系在一起，随着便携设备的计算能力增强和物联网的到来，下一代网络可能会以P2P的模式发布么?
