大多数时候，定义问题比找到答案更难，也更有价值。世界需要困难的、定义明确的问题。互联网固有的问题是什么？可能是“内容交付”问题的不同方面，比如客户端的内容加速，高质量的视频交付等等。其实，一个更好的互联网概念已经进入了大众的视野，就是利用在Internet上以完全分布式的方式发布内容的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连接在现有的Internet基础设施上运行。幸运的是，有这样的堆栈可用，那就是WebRTC。WebRTC是一种浏览器内网络协议栈，支持点对点通信，主要用于语音和视频应用程序，以促进点对点视频和音频会议。与依赖TCP作为传输的HTTP不同，WebRTC依赖于较旧的协议SCTP，并将其包装在UDP中。这允许更低的延迟传输，消除数据包队头阻塞，并且作为一个独立的网络堆栈，允许WebRTC使用比单独使用HTTP多得多的带宽。SCTP有点像OSI传输层的第三个轮子，我们常常忘记它的存在，但它有一些非常强大的特性，并提供可靠的、面向消息的传输。除了SCTP之外，WebRTC还利用两个额外的主要协议：数据传输层安全(DTLS)和交互式连接建立(ICE)来支持网络地址转换(NAT)环境，例如防火墙穿越。可以说，WebRTC拥有实现真正的对等网络所需的所有管道。P2P浏览器支持目前Chrome、Firefox、Edge以及现在的Safari等主流浏览器都支持WebRTC。对于http请求的拦截，可以通过serviceworker来实现。服务工作者是大多数浏览器中的一项新功能，它允许在浏览器中运行后台进程。与可以用作线程代理的WebWorker类似，ServiceWorker在与DOM交互和交换数据的方式上也有一些限制。然而，serviceworkers有一个强大的功能，最初是为支持离线页面加载而开发的：FetchAPI。FetchAPI允许服务工作者拦截请求和响应调用，类似于HTTP代理。通过serviceworker，现在可以拦截传统的HTTP请求并将这些请求添加到P2P网络中。利用浏览器的本地存储模型，可以存储和分发P2P加速内容。虽然浏览器中存在多种不同的存储选项，但IndexedDB是服务工作者和DOM中唯一可用的存储API，WebRTC代码可以在其中执行。可能的优化有了P2P内容交付模型和可用的网络堆栈，应该可以实现某些有效的传输和对浏览器内存储媒体的访问。一个简单的优化可能是有利于驻留在同一网络中的对等点，可能由每个对等点的自治系统识别，并且这种优化可以将平均延迟减少两倍。另一个优化是选择将哪些资源复制到对等节点。例如，如果用户当前正在浏览网站的登录页面，Ben可以预测下一页的所有图像，从而有效地完全消除延迟。总之，世界比以往任何时候都更加紧密相连。随着便携设备计算能力的提升和物联网的到来，下一代网络是否有可能以P2P的方式发布？
