基于P2P的互联网内容加速

开发 开发工具
大多数时候,定义问题比找到答案更难,也更有价值。这个世界需要困难的、明确界定的问题。

[[421315]]

大多数时候,定义问题比找到答案更难,也更有价值。这个世界需要困难的、明确界定的问题。

互联网所固有的问题是什么?可能是“内容交付”问题的不同方面,例如,客户端的内容加速,高质量的视频交付等到。事实上,一个更好的互联网概念已经走进了大众的视野,即使用 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的模式发布么?

责任编辑:武晓燕 来源: 51CTO专栏
相关推荐

2015-04-27 11:49:23

2010-03-10 10:51:30

2016-04-25 13:02:00

2009-01-18 09:36:00

2018-05-03 21:26:32

互联网保险理赔

2012-12-10 09:46:21

P2P云存储Symform

2023-03-14 12:43:57

2010-03-22 15:27:40

云计算

2010-07-13 14:41:14

2020-03-05 20:30:15

Syncthing文件同步工具开源

2022-07-19 16:59:04

流媒体传输IPC物联网

2009-05-18 09:11:00

IPTV融合宽带

2015-04-27 14:29:53

C#UDP实现P2P语音聊天工具

2010-07-07 10:31:45

2017-05-17 14:56:55

2012-09-25 13:47:43

C#网络协议P2P

2011-08-01 16:27:04

WEC7互联网电视

2018-08-16 07:29:02

2010-06-28 11:15:45

BitTorrent协

2013-12-12 13:46:40

大数据金融P2P大数据
点赞
收藏

51CTO技术栈公众号