ACM通信

实践

如果可以，把我藏起来

作者:Jacob Loveless
ACM通信，2018年1月，第61卷第1期，第62-68页
10.1145 / 3132261
评论

多年前，我把暑假的大部分时间都关在公寓里，用来解决网络理论中一个鲜为人知的问题——双向信道容量问题。我确信我就要取得突破了。(我不是。)到处都是报纸，夹杂着太多10美分的星期二玉米卷包装纸的残余。

一个好朋友过来给我带来了更好的食物，帮我算了算，结束了我孤独的疯狂。她仔细地听着，我在房间里跳来跳去地抓着文件，语无伦次地唠叨着我的“突破”。

然后她严肃地拿起一支笔，把我漏掉的那个瑕疵写了出来，把证据抹掉了。

我惊呆了，心碎了。她抬起头说:“但这很好，因为你在这里做的是把问题定义得更具体。”她接着说了一个我一直铭记在心的简单真理:

“大多数时候，定义问题比找到答案更难，也更有价值。这个世界需要明确定义的难题。通常情况下，只有一两个人一起解决一个问题，但有数百人一起解决一个定义明确的问题。”

所以，亲爱的读者，这就是我想开始的地方。本文着眼于构建一个去中心化的互联网所固有的问题。大胆的?是的，但是近年来这已经成为了一个新的焦点，甚至是网络之父本人(参见Tim Berners-Lee的Solid项目)⁴)．一些公司和开源项目现在都在关注“内容交付”问题的不同方面。我们公司Edgemesh (https://edgemesh.com)正与Peer5等下一代内容传送网络(https://peer5.com)和Streamroot (https://streamroot.io)，这两家公司都专注于视频传输。其他的，例如开源星际文件系统(IPFS;https://ipfs.io)项目正在寻找定义、分发和定义“Web”的全新方法。

事实上，一个更好的互联网的概念已经悄悄进入大众媒体。在HBO的情景喜剧第四季硅谷，主人公理查德·亨德里克斯设计了一种新的方法，利用P2P协议以完全分布式的方式在互联网上分发内容。“如果我们能做到这一点，我们就能建立一个完全去中心化的现有互联网版本，”亨德里克斯说，“没有防火墙，没有通行费，没有政府监管，没有间谍活动。从任何意义上讲，信息都将是完全免费的。”故事情节围绕这样一个想法展开:成千上万的用户将在他们的移动设备上分配一小部分可用存储，而'魔笛手'软件将把这些存储集合在一个分布式存储“云”中。然后，当然，手机爆炸了，笑声随之而来。

分布式互联网的核心思想是有道理的，但是如何构建它呢?正如我很久以前在自己被单独监禁期间学到的，在深入研究可能的解决方案之前，你需要更清楚地定义问题。

回到顶部

分布式互联网的问题

2008年，世界上最大的内容分发网络Akamai的联合创始人Tom Leighton概述了内容分发的四个主要架构:集中托管、“大数据中心”内容分发网络(cdn)、高度分布式cdn和P2P网络。Leighton指出:

“P2P可以被认为是将分布式架构发挥到逻辑的极致，理论上提供了几乎无限的可扩展性。此外，在当前的网络定价结构下，P2P提供了诱人的经济效益。”¹¹

他接着指出了其他人在过去的发现，尽管P2P设计是从理论上讲最可扩展的是，有几个具体的实际问题吞吐量、可用性,能力。

吞吐量。最常被注意到的问题是边缘设备的上行容量有限，正如Leighton在他2008年的文章中所指出的:

P2P面临着一些严重的限制;最明显的原因是P2P网络的总下载容量受到其总上行容量的限制。不幸的是，对于消费者宽带连接，上行速度往往比下行速度低得多:例如，康卡斯特的标准高速互联网包提供6Mbps的下载，但只有384Kbps的上传(1/16)^th下载吞吐量)。¹¹

这一限制在今天已不像近10年前那样严重，当时美国的上传速度徘徊在0.5 mbps左右。图1显示当前从Speedtest.net (http://www.speedtest.net/reports/)．这些数据点表明，全球“最后一英里”吞吐量几乎是2008年同期水平的30倍。这就够了吗?一个上传速率在这些指标中较低的四分之一(4Mbps)的对等体是否足够?关于实际网页加载时间，这个问题已经被彻底探索过了。

图1。带宽速率(上传/下载，宽带/移动)。

当以谷歌SPDY闻名的Mike Belshe研究终端客户端带宽和页面加载时间之间的关系时，他发现“带宽并不(太)重要”。3一旦客户端可用带宽达到5Mbps，对终端用户页面负载的影响就可以忽略不计了。图2显示页面加载时间作为客户端带宽的函数，假设固定的RTT(往返时间)为60ms。

图2。页面加载时间是客户端带宽的函数。

可用性。分布式Internet的下一个主要障碍是对等可用性。也就是说，是否有足够的同伴，他们是否在线，是否有足够的时间提供价值?在过去的10年里，边缘设备的数量确实增加了，但增加的足够多吗?看看“2017年互联网趋势”，¹⁴由风险投资公司KPCB的Mary Meeker编译，你可以看到“可用的同伴”数量在过去十年中仅从移动端增加了多少(见图3)．

图3。玛丽·米克尔的2017年智能手机分析。

如今，全球约49%的人口已联网¹⁰大约37亿人，很多人有多种设备，这是一个大边缘设备池。风险投资公司安德森·霍洛维茨(Andressen Horowitz)的彼得·莱文(Peter Levine)将我们的财富再往前推了几年，并预测不久我们的财富将超过数十亿美元，并朝着这个目标前进数万亿的设备。¹²

你可以通过观察Edgemesh一个拥有全球客户基础的单个电子商务客户网站的网络来了解其规模。

可以肯定地说，在线设备已经足够多了，但平均用户在线的时间足够长吗?什么是“足够长”的同伴是有用的?

一个明智的出发点可能是希望对等体在线的时间足够长，以便任何对等体能够与全球任何地方的其他对等体通信。给定这个，我们可以设定一些界限。

地球的周长约为40000公里。经验法则是光在光纤中移动1公里需要4.9微秒。这意味着数据可以在大约五分之一的时间内环游全球^th一秒(196毫秒)。哦，如果愿望只会让事情变成这样，但正如斯坦福大学的斯图尔特·切希尔在《傻瓜，这是延迟》一书中指出的那样，⁶互联网的运行速度至少要比这慢两倍。这两倍的减速意味着绕地球一周大约需要400毫秒。不幸的是，我花了一段时间在远程——特别是在延迟优化的业务上¹³我认为这个时间需要再翻一番，以考虑到全球运输路线;因此，数据可以在大约800毫秒内传遍世界。如果用户在线并且在低于800毫秒的间隔内可用，这可能会出现问题。由于大多数去中心化解决方案都要求用户访问内容(例如，在网站上)，真正的问题是，全球用户平均浏览页面的时间是多少?

结果是3分36秒，²⁴或者说216000毫秒。

为了确认这一点，我计算了过去6个月Edgemesh用户群的所有对等会话时间(Edgemesh对等体在线并连接到网格的时间)(图4)．平均时间是3分47秒。

图4。对等体时间直方图。

在任何一种情况下，如果节点保持在线的时间足够下载一个网页，那么数据就有足够的时间环绕地球270次，当然也足够联系地球上任何地方的对等体。

能力。如果有足够多的用户在足够长的时间内在线，并且他们有一个可接受的出口吞吐量(上传带宽)，那么剩下的问题就是是否有足够的可用容量(磁盘空间)来提供一个功能正常的网络。

如果我们假设一个站点有20%的用户在移动端，80%的用户在桌面端，并进一步扩展到每个桌面用户500MB的可用容量和每个移动用户50MB的可用容量(浏览器可用存储池的低端)，如果所请求的内容遵循Zipf分布，我们可以提取一个估计所需的网格大小来实现给定的缓存命中率。¹从本质上说，一个拥有500GB静态内容的网站，也就是大约1600万张平均Web图片的网站，需要200万个独立节点的在线容量，才能实现理论上100%的流量卸载到P2P网络(图片与用户的比例大约为8:1)。

回到顶部

启用分布式互联网

既然我们已经更好地定义了问题并建立了理论新解决方案的可行性，是时候看看可用的技术来解决这个问题了。首先，我们可以稍微限制一下我们的注意力。IPFS等实现关注于分发整个内容库，使您完全摆脱Web服务器和DNS的限制。这是一个巨大的改变，但代价是它需要用户极大地修改他们访问内容的方式。

由于P2P设计依赖于整个网络的规模，这个模型很难增长，直到它达到临界质量。在Edgemesh，我们希望专注于透明地增强现有的web内容交付(例如，在浏览器中)，而不需要对用户体验进行任何更改。这意味着确保技术遵守以下三个限制:

• 对于用户来说，解决方案应该是透明的。
• 对于开发人员来说，解决方案应该不需要任何基础设施更改。
• 对于操作，解决方案应该是自我管理的。

下一个问题是应该把重点放在哪里。

完全启用对等增强的交付所有内容是困难和危险的，特别是允许执行同行交付的JavaScript。有80%的解决方案吗?HTTP Archive发布的趋势显示，静态组件(图像/视频/字体/CSS)约占页面总权重的81%。⁹

考虑到这些细节，让我们将焦点缩小到启用/增强这些更传统的CDN资产的边缘交付，以及移动和存储数据的相关挑战。

移动数据:构建一个新的网络(覆盖)。为了支持P2P分布，需要开发一个覆盖网络，以允许P2P连接在更大的现有互联网基础设施中运行。幸运的是，这样的堆栈是可用的:WebRTC(实时通信)¹⁹)．WebRTC于2011年由谷歌正式启动，它是一个浏览器内网络堆栈，支持点对点通信。WebRTC主要用于语音和视频应用程序(谷歌Hangouts/Dua/Allo, Slack, Snapchat, Amazon Chime, WhatsApp, Facebook Messenger)，以促进点对点视频和音频会议。

WebRTC是个大项目;2016年6月谷歌提供了几个关键的里程碑⁷根据它收集的数据，以及六个月后的一些额外更新:²⁵

• 20亿Chrome浏览器与WebRTC。
• 每周在Chrome上有10亿WebRTC音频/视频分钟。
• 每周Chrome上1 pb的数据通道流量(占所有Web流量的0.1%)。
• 1200家基于webrtc的公司和项目(6月份为950家)。
• 包括WebRTC在内的50亿手机应用下载量。

主要的浏览器都支持WebRTC，如chrome、Firefox、Edge和现在的Safari，²将WebRTC五年的采用与其他voip风格的协议进行比较可以看出其规模。⁸

WebRTC是一个用户空间的网络堆栈。与依赖TCP进行传输的HTTP不同，WebRTC的根源是一个更古老的协议流控制传输协议(SCTP)，并将其封装在用户数据报协议(UDP)中。这允许更低的延迟传输，消除了线头阻塞，并且，作为一个单独的网络堆栈，允许WebRTC使用比单独的HTTP多得多的带宽。

SCTP有点像开放系统互连(OSI)模型传输层的电灯泡——我们经常忘记它的存在，但它有一些非常强大的功能。最初引入它是为了支持IP网络中的信令，²²SCTP很快被下一代网络(IMS和LTE)采用。

WebRTC利用SCTP提供可靠的、面向消息的传递传输(封装在UDP或TCP中，具体取决于实现⁵)．除了SCTP, WebRTC还利用了另外两个主要协议:用于安全的数据报传输层安全(DTLS) (SSL的衍生品)和允许在网络地址转换(NAT)环境中支持(例如，防火墙遍历)的交互式连接建立(ICE)。

ICE协议的细节以及它与信号服务器(例如STUN和turnn)的工作方式超出了本文的范围，但只需说明WebRTC拥有实现真正的点对点网络的所有必要管道就足够了。

一个简单的例子是Serene Han的WebRTC Golang实现。²¹Han的聊天演示允许您在两台机器之间传递SDP(会话描述协议)详细信息(复制粘贴信令)以启用P2P聊天。要自己运行这个程序(假设您在本地有一个Docker实例)，只需执行以下操作:

码头运行- golang bash

然后在Docker实例中，这一行代码将帮助您设置:

Apt-get update && Apt-get install libx11-dev -y && \ go get github.com/keroserene/go-webrtc && \ CD /go/src/github.com/kerose-rene/go-webrtc && \ go运行demo/chat/chat.go

如果你更喜欢浏览器本地的起点，看看简单对等模块，^20.最初来自Feross Aboukhadijeh与WebTorrent (https://webtorrent.io)．

存储数据:浏览器存储选项和资产拦截。下一步是寻找一种方法，既可以拦截标准HTTP请求，又可以开发一个系统来存储点对点交付的资产。对于请求-拦截问题，您只需看看service worker。¹⁸service worker是大多数浏览器中可用的新特性，它允许在浏览器中运行后台进程。与可以用作线程代理的Web worker一样，服务worker在如何与文档对象模型(Document Object Model, DOM)交互和交换数据方面也有限制。

然而，service worker有一个强大的特性，最初是为支持离线页面加载而开发的:Fetch API。¹⁶Fetch API允许service worker拦截请求和响应调用，类似于HTTP代理。

随着service worker联机，您现在可以拦截传统的HTTP请求并将这些请求卸载到P2P网络。剩下的最后一个组件将是浏览器本地存储模型，其中可以存储和分发p2p加速的内容。尽管在浏览器中存在不少于5种不同的存储选项，IndexedDB¹⁷实现是service-worker上下文中和DOM上下文中唯一可用的存储API, WebRTC代码可以在其中执行，这就是Edgemesh选择它作为存储基础的原因。另外，也可以在service-worker上下文中使用CacheStorage API。¹⁵

回到顶部

实现分布式互联网

我们有一个理论上可行的模型来支持点对点的内容交付。我们有一个功能强大的网络堆栈，可以实现特别高效的点对点传输和对浏览器内存储介质的访问。所以，游戏正在进行中!

图5是Edgemesh p2p加速内容传递系统的流程图。该图显示了service-worker框架将在何处启用资产拦截，而WebRTC(由信号服务器辅助)将促进浏览器到浏览器的资产复制。

图5。WebRTC增强资产交付流程图。

回到Mike Belshe的研究，我们可以开始挖掘一些需要优化的关键领域。与带宽不同的是，增加超过5Mbps的带宽对页面加载时间的影响可以忽略不计，延迟(RTT)会显著增加页面加载时间。^3.

WebRTC已经是一种高效的协议，但对等选择过程提供了进一步减少延迟的机会。例如，如果您位于纽约，那么为东京的同行提供服务可能不是最佳选择。

一个简单的优化方法可能是优选驻留在同一网络中的对等体，可能由自治系统(AS)识别。²³对等体编号。即使是这种简单的优化也可以将平均延迟减少两倍。图6显示了通过as内路由优先级提升性能。

图6。通过路由优先级提高性能。

另一个优化是选择将哪些资产复制到对等体中。例如，如果用户当前正在浏览一个网站的登陆页，我们基本上可以为下一个页面预先缓存所有的图像，有效地完全消除延迟。这是Edgemesh团队目前的研究领域，但早期的解决方案已经显示出巨大的前景。图7显示了单个客户域支持edgemesh的客户端(加速)和不支持edgemesh的客户端(标准)的有效渲染时间。平均页面加载时间几乎减少了1 / 2。

图7。P2P增强后台缓存对加载时间的影响。

的页面加载时间统计数据显示，当大多数页面内容都能被有效地预先预测时，这一点表现得最为明显图8．

图8。页面加载时间组件:加速与标准。

回到顶部

结论

我已经有好几天没有出门了，而且我还得再过几天才能把自己打扮得漂漂亮亮。在之前的几周里，我和团队一直在办公室里夜以继日地工作，基本上是从头开始重写软件。我们原以为只需要一个星期，但现在已经三个月了。在我们使用的临时白板桌上，越来越多的空快递袋堆在一起，这让我们很难弄清楚真正的大变化是什么。我们确信这就是我们一直在寻找的突破(事实证明确实如此)，并且这个版本将会使问题变得更加开放。我低头想让我的角色发挥作用，然后我就迷路了。然后我听到了敲门声。她进来坐了下来，耐心地把空披萨盒子挪到一边，而我则喋喋不休地谈论着我们的重大突破以及我是如何陷入困境的。

然后，就像近20年前一样，她抓起马克笔说:

“亲爱的，我想我看到问题了。你没有正确地定义这个问题。大多数时候，定义问题比找到答案更难，也更有价值。那么，你到底想解决什么问题?”

世界的联系比以往任何时候都要紧密，随着我们的袖珍超级计算机和物联网的未来，下一代网络可能只是通过点对点的模式交付。这是一个巨大的问题空间，但必要的工具和技术今天就在这里。我们只需要更好地定义这个问题。

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2018 ACM, Inc.