PDF缓存我，如果你可以
构建去中心化的网络交付模型
雅各布·洛夫莱斯 (Jacob Loveless)
多年前，我把大部分暑假都浪费在公寓里，解决一个晦涩的网络理论问题（双向信道容量问题）。我确信我离突破很近了。（我并没有。）论文到处都是，与太多 10 美分 Taco Tuesday 包装纸的残余物混杂在一起。
一位好朋友顺道拜访，带来了更好的食物，伸出数学援助之手，并结束了我的孤独疯狂。她仔细地听着，我跳过房间抓起论文，语无伦次地唠叨着我的“突破”。
然后她庄重地拿起笔，写出了我错过的缺陷，抹去了证明。
我震惊而心碎。她抬起头说：“但这很棒，因为你在这里所做的是更具体地定义了问题。” 她继续说出一个我一直铭记于心的简单真理
“大多数时候，定义问题比找到答案更难也更有价值。世界需要困难的、定义明确的问题。通常，只有一两个人一起研究答案——但数百人研究定义明确的问题。”
因此，亲爱的读者，这就是我想开始的地方。与 acmqueue 中的大多数文章不同，这篇文章不是关于一项新技术或对从业者解决方案的阐述。相反，本文着眼于构建更去中心化的互联网中固有的问题。大胆吗？是的，但这已成为近年来重新关注的焦点，甚至包括 Web 之父本人（参见蒂姆·伯纳斯-李的 Solid 项目4）。多家公司和开源项目现在正专注于“内容交付”问题的不同方面。我们公司 Edgemesh (https://edgemesh.com) 正在与下一代内容交付网络（如 Peer5 (https://peer5.com) 和 Streamroot (https://streamroot.io)）一起，致力于增强对等客户端内容加速，这两者都专注于视频交付。其他公司，例如开源 IPFS（星际文件系统；https://ipfs.io）项目，正在寻找定义和分发以及定义“网络”的全新方法。
事实上，关于更美好互联网的概念已经悄然进入大众媒体。在 HBO 情景喜剧《硅谷》第 4 季中，主角理查德·亨德里克斯设计了一种使用 P2P（点对点）协议以完全分布式的方式在互联网上分发内容的新方法。“如果我们能做到，我们就可以构建当前互联网的完全去中心化版本，”亨德里克斯说，“没有防火墙，没有收费站，没有政府监管，没有间谍活动。信息将在各个意义上完全自由。” 故事情节围绕着数千名用户将在其移动设备上分配一小部分可用存储空间的想法展开，并且 Pied Piper 软件将在这些设备上组装存储空间，形成分布式存储“云”。当然，然后手机爆炸，闹剧随之而来。
分布式互联网的核心理念确实有道理，但它将如何构建？正如我很久以前在自我强加的孤独禁闭中所学到的那样，在深入研究可能的解决方案之前，您需要更清楚地定义问题。
分布式互联网的问题
在他 2008 年的 acmqueue 文章“提高互联网性能”中，全球最大的内容分发网络 Akamai 的联合创始人汤姆·莱顿概述了内容分发的四种主要架构：集中式托管、“大数据中心” CDN（内容分发网络）、高度分布式 CDN 和 P2P 网络。莱顿指出，在这些架构中
“P2P 可以被认为是将分布式架构推向逻辑上的极端，理论上提供了近乎无限的可扩展性。此外，在当前的网络定价结构下，P2P 提供了有吸引力的经济性。”11
然后他指出，其他人过去也发现，尽管 P2P 设计理论上是最具可扩展性的，但仍存在一些实际问题，特别是吞吐量、可用性和容量。
吞吐量
最常被提及的问题是边缘设备有限的上行链路容量，正如莱顿在他的 2008 年文章中指出的那样
P2P 面临一些严重的限制，最值得注意的是，P2P 网络的总下载容量受到其总上行链路容量的限制。不幸的是，对于消费者宽带连接，上行链路速度往往远低于下行链路速度：例如，Comcast 的标准高速互联网套餐提供 6 Mbps 的下载速度，但仅提供 384 Kbps 的上传速度（下载吞吐量的十六分之一）。11
与大约十年前美国上传速度徘徊在 0.5 Mbps 左右时相比，这种限制在今天并不那么严重。图 1 显示了从 Speedtest.net (http://www.speedtest.net/reports/) 获取的当前上传和下载速度。这些数据点表明，全球“最后一公里”的吞吐量速率几乎是 2008 年的 30 倍。这足够了吗？上传速率处于这些指标的较低四分位数 (~4 Mbps) 的对等方是否足够？关于实际网页加载时间，这个问题已经得到了充分的探讨。
当 Mike Belshe（Google SPDY 的名人）研究终端客户端带宽和页面加载时间之间的关系时，他发现“带宽无关紧要（很大程度上）。”3 一旦客户端的可用带宽达到 5 Mbps，对最终用户的页面加载的影响就可以忽略不计。图 2 显示了页面加载时间与客户端带宽的函数关系，假设固定 RTT（往返时间）为 60 毫秒。
可用性
分布式互联网的下一个主要障碍是对等方可用性。即，是否有足够的对等方，以及它们是否在线并可用足够长的时间来提供价值？在过去的十年中，边缘设备的数量肯定有所增加，但增加得足够了吗？查看“2017 年互联网趋势”14（由风险投资公司 KPCB 的玛丽·米克尔汇编），您可以看到过去十年中仅移动设备“可用对等方”的数量增加了多少（参见图 3）。
今天，全球约有 49% 的人口已联网10——约 37 亿人，其中许多人拥有多台设备——因此这是一个庞大的边缘设备池。风险投资公司安德森·霍洛维茨的彼得·莱文将我们带到了几年之后，并预测我们很快将超越数十亿，走向数万亿台设备。12
您可以通过查看 Edgemesh 网络来了解规模，该网络适用于全球客户群的单个电子商务客户网站，如图 4 和图 5 所示。
可以肯定地说，在线设备足够多，但普通用户在线时间是否足够长以供使用？对等方有用的“足够长”是多少？
一个明智的起点可能是希望对等方在线足够长的时间，以便任何对等方都可以到达全球任何地方的任何其他对等方。鉴于此，我们可以设置一些界限。
地球的周长约为 40,000 公里。经验法则是光通过光纤移动 1 公里需要 4.9 微秒。这意味着数据可以在大约五分之一秒（196 毫秒）内环绕地球一周。哦，如果愿望能够成真就好了，但正如斯坦福大学的斯图尔特·切希尔在“是延迟，笨蛋”6 中指出的那样，互联网的运行速度至少比这慢两倍。这种 2 倍的减速意味着环绕地球一周大约需要 400 毫秒。不幸的是，我曾在电信行业工作过一段时间——特别是在延迟优化的业务13 中——我认为这个时间需要再次加倍才能考虑到全球传输路由；因此，数据可以在大约 800 毫秒内环绕世界一周。如果用户在线且可用的时间间隔少于 800 毫秒，这可能会成为问题。由于大多数去中心化解决方案都需要用户访问内容（例如，在网站上），因此真正的问题是，全球用户的平均页面浏览时间是多少？
结果证明是 3 分 36 秒24，或 216,000 毫秒。
为了再次检查这一点，我提取了过去六个月 Edgemesh 用户群中所有对等会话时间（Edgemesh 对等方在线并连接到网格的时间量）（图 6）。平均值与 3 分 47 秒一致。
在任何情况下，如果节点在线的时间仅足够下载单个网页，那么数据就有足够的时间环绕地球 270 圈，当然足以联系地球上任何地方的对等方。
容量
如果足够的用户在线足够长的时间，并且他们具有可接受的出口吞吐量（上传带宽），那么剩下的问题就是是否有足够的备用容量（磁盘空间）可用来提供功能性网络。
如果我们假设一个站点有 20% 的用户使用移动设备，80% 的用户使用台式机——并将此进一步扩展到每个台式机用户 500 MB 的可用容量和每个移动用户 50 MB 的可用容量（浏览器可用存储池的下限）——如果请求的内容遵循 Zipf 分布1，我们可以提取实现给定缓存命中率的估计所需网格大小。图 7 显示了对于 0.5 TB、1 TB 和 2 TB 活动缓存的可变缓存命中率所需的估计网格大小。这些数字对于基线来说肯定看起来是合理的。本质上，具有 500 GB 静态内容（约 1600 万张平均网络图像）的网站将需要 200 万个不同节点的在线容量，才能将其流量的理论卸载量达到 P2P 网格的 100%（图像与用户之比约为 8:1）。
启用分布式互联网
既然我们已经更好地定义了问题并确定了新解决方案的理论可行性，现在是时候研究可用于解决该问题的技术了。首先，我们可以稍微缩小我们的关注范围。诸如 IPFS 之类的实现专注于分发整个内容库，从而使您完全摆脱 Web 服务器和 DNS 的限制。这是一个非常棒的全面变革，但权衡之处在于，它将要求用户大幅修改他们访问内容的方式。
由于点对点设计依赖于总网络规模，因此该模型在达到临界规模之前难以增长。在 Edgemesh，我们希望专注于透明地（例如，在浏览器中）增强现有 Web 内容交付，而无需对用户体验进行任何更改。这意味着确保该技术遵守以下三个限制
• 对于用户而言，解决方案应该是透明的。
• 对于开发人员而言，解决方案应该不需要零基础设施更改。
• 对于运营而言，解决方案应该是自我管理的。
下一个问题是具体关注哪里。
完全启用所有内容的对等增强交付既困难又危险（尤其是在允许执行对等交付的 JavaScript 的情况下）。是否有 80% 的解决方案？HTTP Archive 发布的趋势表明，静态组件（图像/视频/字体/CSS）约占页面总重量的 81%9，如图 8 所示。
鉴于这些细节，让我们将重点缩小到启用/增强这些更传统的 CDN 资产的边缘交付以及移动和存储数据的相关挑战。
移动数据：构建新网络（覆盖网络）
为了支持点对点分发，需要开发一个覆盖网络，以允许点对点连接在更大的现有互联网基础设施内运行。幸运的是，这样的堆栈是可用的：WebRTC（实时通信19）。WebRTC 由 Google 于 2011 年开始认真开发，是一种浏览器内网络堆栈，可实现点对点通信。WebRTC 主要用于语音和视频应用程序（Google Hangouts/Dua/Allo、Slack、Snapchat、Amazon Chime、WhatsApp、Facebook Messenger），以促进点对点视频和音频会议。
WebRTC 意义重大；在 2016 年 6 月（仅五年后），Google 提供了从其收集的统计数据中得出的几个 关键里程碑7 （以及 2016 年底的一些 其他更新25）
• 20 亿个安装了 WebRTC 的 Chrome 浏览器。
• 每周在 Chrome 上进行 10 亿分钟的 WebRTC 音频/视频通话。
• 每周在 Chrome 上产生 1 PB 的 DataChannel 流量（占所有 Web 流量的 0.1%）。
• 1,200 家基于 WebRTC 的公司和项目（6 月份为 950 家）。
• 50 亿次包含 WebRTC 的移动应用下载。
主要浏览器（Chrome、Firefox、Edge 以及现在的 Safari2）都支持 WebRTC。将 WebRTC 五年的采用率与其他 VoIP 风格的协议进行比较，可以显示出规模（参见图 9）。8
WebRTC 是用户空间网络堆栈。与依赖 TCP 进行传输的 HTTP 不同，WebRTC 植根于一种更古老的协议——SCTP（流控制传输协议）——并将其封装在 UDP（用户数据报协议）中。这允许更低的延迟传输，消除队头阻塞，并且作为单独的网络堆栈，允许 WebRTC 使用比单独 HTTP 显著更多的带宽。
SCTP 有点像 OSI（开放系统互连）模型的传输层的第三个轮子——我们经常忘记它的存在，但它具有一些非常强大的功能。SCTP 最初是为了支持 IP 网络中的信令22 而引入的，很快就在下一代网络（IMS 和 LTE）中得到采用。
WebRTC 利用 SCTP 提供可靠的、面向消息的交付传输（封装在 UDP 或 TCP 中，具体取决于实现5）。除了 SCTP 之外，WebRTC 还利用了另外两个主要协议：DTLS（数据报传输层安全性），用于安全（SSL 的衍生产品）和 ICE（交互式连接建立），以允许在 NAT（网络地址转换）环境（例如，防火墙穿越）中提供支持。
ICE 协议的详细信息及其与信令服务器（例如，STUN 和 TURN）的工作方式超出了本文的范围，但足以说明 WebRTC 具有启用真正的点对点联网所需的所有必要管道。
一个简单的例子是 Serene Han 的 WebRTC Golang 实现。21 Han 的聊天演示允许您在两台机器之间传递 SDP（会话描述协议）详细信息（复制粘贴信令）以启用点对点聊天。要自己运行此程序（假设您在本地有 Docker 实例），只需执行以下操作
docker run —it golang bash
然后在 Docker 实例中，这一行代码将为您设置
apt-get update && apt-get install libx11-dev -y && \ go get github.com/keroserene/go-webrtc && \ cd /go/src/github.com/keroserene/go-webrtc && \ go run demo/chat/chat.go
如果您更喜欢浏览器原生起点，请查看 simple-peer 模块20，最初来自 Feross Aboukhadijeh 在 WebTorrent (https://webtorrent.io) 中的工作。
存储数据：浏览器存储选项和资源拦截
下一步是找到一种方法，既可以拦截标准 HTTP 请求，又可以开发一种系统来存储点对点交付的资源。对于请求拦截问题，您无需再寻找服务工作线程。18 服务工作线程是大多数浏览器中提供的一项新功能，允许在浏览器中运行后台进程。与 Web 工作线程（可以用作线程的代理）类似，服务工作线程对其如何与 DOM（文档对象模型）交互和交换数据有限制。
但是，服务工作线程确实有一个最初为支持离线页面加载而开发的强大功能：Fetch API16。Fetch API 允许服务工作线程拦截请求和响应调用，类似于 HTTP 代理。如图 10 所示。
有了在线服务工作线程，您现在可以拦截传统的 HTTP 请求，并将这些请求卸载到 P2P 网络。剩下的最后一个组件将是浏览器本地存储模型，P2P 加速的内容可以在其中存储和分发。尽管浏览器中存在不少于五种不同的存储选项，但 IndexedDB17 实现是唯一在服务工作线程上下文和 DOM 上下文（WebRTC 代码可以在其中执行，这也是 Edgemesh 选择它作为存储库的原因）中可用的存储 API。或者，CacheStorage API 也可以在服务工作线程上下文中使用。15
实施分布式互联网
我们有一个理论上可行的模型来支持点对点内容交付。我们有一个功能性的网络堆栈，可以实现临时的、高效的点对点传输和对浏览器内存储介质的访问。因此，游戏开始了！
图 11 是 Edgemesh P2P 加速内容交付系统的流程图。该图显示了服务工作线程框架将在何处启用资源拦截，而 WebRTC（在信令服务器的帮助下）将促进浏览器到浏览器之间的资源复制。
然后，回到 Mike Belshe 的研究，我们可以开始深入研究一些需要优化的关键领域。与带宽不同，在带宽方面，在 5 Mbps 以上添加更多带宽对页面加载时间的影响微乎其微，而延迟 (RTT) 会显着增加页面加载时间，如图 12 所示。3
WebRTC 已经是一种高效的协议，但对等方选择过程为进一步减少延迟提供了机会。例如，如果您位于纽约，则提供东京的对等方可能不是最佳选择。图 13 显示了 Edgemesh 网络中一系列会话的 WebRTC 延迟分布样本。我们能做得更好吗？
一个简单的优化可能是优先选择位于同一网络中的对等方，这可以通过每个对等方的 AS（自治系统）23 编号来识别。即使是这种简单的优化也可以将平均延迟减少一半。图 14 显示了通过 AS 内路由偏好提高的性能。
另一个优化是选择要复制到对等方中的资源。例如，如果用户当前正在浏览站点的着陆页，我们基本上可以预缓存下一页的所有图像，从而有效地消除延迟。这是 Edgemesh 团队当前的研究领域，但早期的解决方案已经显示出巨大的希望。图 15 显示了针对单个客户域的启用 Edgemesh 的客户端（加速）和未启用 Edgemesh 的客户端（标准）的有效渲染时间。平均页面加载时间缩短了近一半。
当页面上的大部分内容可以有效地预缓存时，这一点最清楚地体现在图 16 的页面加载时间统计数据中。
结论
我已经有几天没出门了，也有几天没让自己看起来像样了。在之前的几周里，我和团队日夜把自己关在办公室里，基本上是从头开始重写软件。我们认为这需要一周时间，但现在已经是 2017 年的第三个月了。堆积如山的空外卖袋堆在我们使用的临时白板桌子上，让人难以看清大的变化到底是什么。我们确信这就是我们一直在寻找的突破（事实证明确实如此），并且这个版本将是彻底解决问题的版本。我埋头苦干，试图让我的零件工作，但我迷失了方向。然后我听到了敲门声。她走了进来，坐了下来，耐心地把空披萨盒移到一边，而我滔滔不绝地谈论着我们的重大突破以及我是如何陷入困境的。
然后，就像她将近二十年前所做的那样，她拿起记号笔说
“亲爱的，我想我看到了问题所在。你没有正确定义问题。大多数时候，定义问题比找到答案更难也更有价值。所以，你到底想解决什么问题？”
世界比以往任何时候都更加互联，并且随着我们的袖珍超级计算机和物联网（物联网）的未来，下一代网络可能只是以点对点模型交付的。这是一个巨大的问题空间，但必要的工具和技术今天已经存在。我们只需要更好地定义问题。
参考文献
1. Adamic, L. A., Huberman, B. A. 2002. Zipf's law and the Internet. Glottometrics 3: 143-150; http://www.hpl.hp.com/research/idl/papers/ranking/adamicglottometrics.pdf.
2. Apple Inc. Safari 11.0; https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Safari_11_0/Safari_11_0.html.
3. Belshe, M. 2010. More bandwidth doesn't matter (much); https://docs.google.com/.
4. Berners-Lee, T. Solid; https://solid.mit.edu/.
5. BlogGeek.Me. 2014. Why was SCTP selected for WebRTC's data channel; https://bloggeek.me/sctp-data-channel/.
6. Cheshire, S. 1996-2001. It's the latency, stupid; http://www.stuartcheshire.org/rants/latency.html.
7. Google Groups. 2016. WebRTC; https://groups.google.com/forum/#!topic/discuss-webrtc/I0GqzwfKJfQ.
8. Hart, C. 2017. WebRTC: one of 2016's biggest technologies no one has heard of. WebRTC World; http://www.webrtcworld.com/topics/webrtc-world/articles/428444.
9. HTTP Archive; http://httparchive.org/trends.php.
10. Internet World Stats. 2017. World Internet usage and population statistics—March 31, 2017; http://www.internetworldstats.com/stats.htm.
11. Leighton, T. 2008. Improving performance on the Internet. acmqueue 6(6); https://queue.org.cn/detail.cfm?id=1466449.
12. Levine, P. 2016. The end of cloud computing. Andreessen Horowitz; http://a16z.com/2016/12/16/the-end-of-cloud-computing/.
13. Loveless, J. 2013. Barbarians at the gateways. acmqueue 11(8); https://queue.org.cn/detail.cfm?id=2536492.
14. Meeker, M. 2017. Internet trends 2017—code conference. KPCB; http://www.kpcb.com/internet-trends.
15. Mozilla Developer Network. 2017. CacheStorage; https://mdn.org.cn/en-US/docs/Web/API/CacheStorage.
16. Mozilla Developer Network. 2017. FetchAPI; https://mdn.org.cn/en-US/docs/Web/API/Fetch_API.
17. Mozilla Developer Network. 2017. IndexedDB API; https://mdn.org.cn/en-US/docs/Web/API/IndexedDB_API.
18. Mozilla Developer Network. 2017. Using service workers; https://mdn.org.cn/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers.
19. Real-time communication in web browsers (rtcweb) Charter for Working Group; http://datatracker.ietf.org/wg/rtcweb/charter/.
20. Simple WebRTC video/voice and data channels. Github; https://github.com/edgemesh/simple-peer.
21. WebRTC for Go. Github; https://github.com/keroserene/go-webrtc.
22. Wikipedia. Signalling System No. 7; https://en.wikipedia.org/wiki/Signalling_System_No._7.
23. Wikipedia. Autonomous system; https://en.wikipedia.org/wiki/Autonomous_system_(Internet).
24. Wolfgang Digital. 2016. E-commerce KPI benchmarks; https://www.wolfgangdigital.com/uploads/general/KPI_Infopgrahic_2016.jpg.
25. YouTube. 2016. WebRTC; https://youtu.be/OUfYFMGtPQ0?t=16504.
雅各布·洛夫莱斯 是 Edgemesh Corporation 的首席执行官，Edgemesh Corporation 是一家领先的边缘网络加速平台。在加入 Edgemesh 之前，洛夫莱斯曾担任 Lucera Financial Infrastructures 的首席执行官，Lucera Financial Infrastructures 是一家为金融机构提供全球网络服务的提供商。他曾是 Cantor Fitzgerald and Company 的合伙人，负责运营该公司近 10 年的全球低延迟交易业务。在加入华尔街之前，他曾担任国防部的高级工程师和顾问，专注于大规模数据分析程序和分布式网络。洛夫莱斯主要关注低延迟网络和分布式计算。他之前的 文章可在 https://queue.org.cn/detail.cfm?id=2536492 和 https://queue.org.cn/detail.cfm?id=2534976 上查阅。
版权 © 2017 归所有者/作者所有。出版权已授权给 。
最初发表于 Queue 第 15 卷，第 4 期—
在 数字图书馆 中评论本文
更多相关文章
大卫·科利尔-布朗 (David Collier-Brown) - 你对带宽一窍不通
当您的员工或客户说他们的互联网性能很差时，带宽可能不是问题。一旦他们的带宽达到 50 到 100 Mbps，问题就是延迟，即 ISP 的路由器处理他们的流量需要多长时间。如果您是一家 ISP，并且所有客户都讨厌您，请振作起来。这现在是一个可以解决的问题，这要归功于一群敬业的人，他们追查到了这个问题，解决了它，然后在家庭路由器中验证了他们的解决方案。
杰弗里·H·库珀 (Geoffrey H. Cooper) - 使用 FDO 和不受信任的安装程序模型的设备入职
设备的自动入职是处理正在安装的越来越多的“边缘”和 IoT 设备的一项重要技术。设备的入职与大多数设备管理功能不同，因为设备的信任从工厂和供应链转移到目标应用程序。为了通过自动入职加快流程，供应链中的信任关系必须在设备中正式化，以允许自动化过渡。
布莱恩·伊顿 (Brian Eaton)、杰夫·斯图尔特 (Jeff Stewart)、乔恩·特德斯科 (Jon Tedesco)、N. 西汉·塔斯 (N. Cihan Tas) - 通过关键路径跟踪进行分布式延迟分析
低延迟是许多 Google 应用程序（如搜索）的重要功能，延迟分析工具在维持大规模低延迟方面发挥着关键作用。对于包括功能和数据不断发展的服务的复杂分布式系统，将总体延迟保持在最低水平是一项具有挑战性的任务。在大型真实世界的分布式系统中，现有的工具（如 RPC 遥测、CPU 分析和分布式跟踪）对于理解整个系统的子组件很有价值，但在实践中不足以执行端到端延迟分析。
大卫·克劳肖 (David Crawshaw) - 一切 VPN 都是全新的
VPN（虚拟专用网络）已经有 24 年的历史了。这个概念是为与我们今天所知的互联网截然不同的互联网而创建的。随着互联网的发展和变化，VPN 用户和应用程序也在发展和变化。VPN 在 2000 年代的互联网中经历了尴尬的青春期，与其他广泛流行的抽象概念交互不良。在过去的十年中，互联网再次发生了变化，这种新的互联网为 VPN 提供了新的用途。一种全新的协议 WireGuard 的开发为构建这些新的 VPN 提供了技术基础。
© 保留所有权利。