专栏首页CSDN技术头条干货丨通过HTTP/2实现每天处理400GB图片的实践

干货丨通过HTTP/2实现每天处理400GB图片的实践

如今确定下来的HTTP/2规格已经引发了web性能社区的广泛关注。新协议旨在解决老旧的HTTP/1.x协议相关的常见网络性能问题,同时还要保留老协议的现有语义。

今年早些时候,我们开始针对静态资源进行小规模部署;在对新的基础架构建立信心后,我们开始将静态资源全部转向HTTP/2之上。令人惊讶的是:平台的某些部分速度明显变慢。本文涵盖了我们在采用HTTP/2时,由于性能倒退而做的调查,这些故事并非web性能、特别是与HTTP/2相关的万能灵药,但希望我们分享的经验能对大家有所帮助。

为什么选择HTTP/2?

不论怎样,HTTP/2已经与free performance的概念联系起来了,它是怎样让我们对web性能的所有认知都成了错误?

事实上,HTTP/2的性能只是众多细微差别之一。

与针对每个资源都创建新连接的HTTP/1.x不同,HTTP/2在每个主机上最多只创建一个连接,通过使用二进制分帧协议(binary framing protocol)的合串流(multiplexed stream)实现。二进制分帧负责匹配多个并发请求,以作出回应。

出自Ilya Grigorik的PPT:让我们优化HTTP/2

由于不再限于每个连接处理一个事务,在很大程度上解决了队首堵塞的问题,创建的连接更少也意味着延迟与TCP拥塞控制问题的减少。结合之后,由于减少了服务器与客户端之间往返的数据量与时间,这些特性会带来大幅的性能提升。

监控HTTP/2的性能

我们使用Calibre对终端用户性能进行人工监控,同时收集不同的指标,将这些数据的一小部分通过高可视化的Geckoboard展示在办公室里。

墨尔本办公室中,受到Etsy启发的性能展示界面

我们使用了下列指标来指代用户感知的页面加载性能与HTTP/2成功的表现,选择这些指标的原因在于:它们会受到页面加载生命周期中不同方面的影响。

  • DOMContentLoaded事件因同步脚本延迟;
  • 首次绘制的时间因CSS与字体等影响渲染的因素而推迟;
  • 视觉完形的时间因图片与潜在异步脚本等不影响渲染的因素而推迟;
  • 速度指标(Speed Index)受到视觉完形速率的影响。

测试并验证HTTP/2的成功

我们先将图片缩略图CDN迁移到CloudFlare上,后者本身支持HTTP/2。初始的基准测试显示:CloudFlare的延迟与反应时间与我们现有CDN的相应指标可堪相比。

作为设计类网站,我们的大部分页面都是以图片为主的,通常都会有超过50张的图片。在HTTP/1.x中,有许多微资源的页面会因一些小变化而造成连接延迟,从而受到不利影响。对于这些受到延迟影响的页面,我们希望视觉完形地更快一些,至于速度有多快要取决于连接延迟与图片数量,可以预料在高延迟、低带宽的3G网络上也会出现这种趋势。

对于受到带宽限制的页面,我们希望不会出现明显变化。

针对图片单独启用HTTP/2不会影响队首堵塞问题,因此首次绘制时间或者DOMContentLoaded不会有什么变化。

现实

结果还不够明晰,下面我们将对细微差异与惊喜做以探究,并讨论推出HTTP/2后的未来考虑。

测试

我们通过功能标记(feature flag)启用了HTTP/2 CDN,并在之后一周内截取了大致100张Calibre截图,包括启用和未启用新CDN的。Calibre的Chrome代理位于美国,延迟低带宽高。

案例研究:设计师作品集

设计师作品集代表着99designs典型的受延迟影响页面,我们观察到,在速度指标与视觉完形时间上有5%的提高,首次绘制时间都差不多,但有趣的是使用HTTP/2进行初次渲染更完整。

通过HTTP/2初次渲染的图片更完整

案例研究:Discover设计集

Discover设计集代表着平台的极端案例:这些页面每个分别有80张图片(差不多10mb),对带宽极其依赖,因此降低延迟所带来的影响近乎微不足道。根据预期,这些页面在性能方面的变化不大。

但实际上在视觉完形和速度指标方面,结果却有大约5%-10%的性能倒退,不过整体页面加载时间减少,代表着我们已从连接延迟降低中获益。

HTTP/2的首次绘制延迟与视觉完形时间

高延迟测试

为了收集高延迟连接下的数据,我们在3G连接配置中使用了WebPagetest,尽管初次绘制的完整度仍旧更高,但速度明显有所降低,不过整体的页面加载时间还是减少了。

与直觉相反,设计师页面与Discovery页面的视觉完形延迟分别增加了平均15%与25%。

总结

  1. 对于典型的图片密集、受延迟影响的页面,使用高速低延迟连接,视觉完形速度平均获得了5%的增长。
  2. 对于图片特别密集、受带宽影响很大的页面,使用同样的连接,视觉完形速度反而降低了平均5%-10%。
  3. 在高延迟低速连接下,页面在视觉完形方面有极高的延迟。
  4. 在所有测试中我们发现,整体的页面加载时间增加了,首次绘制的完成度更高。

事后分析

收集到的数据提出了一个很大的问题,

在使用HTTP/2时,受到带宽影响的页面无论加载速度增加与否,在视觉完形方面花费的时间都更长。为什么会这样呢?

假设一:网络饱和

HTTP/1.x的流量由于对很多短期连接是开发能够的,因此本质上是忽上忽下的,因此能在开发工具的网络瀑布图看到如下情形。

HTTP/1.x交错的网络瀑布图

一开始,我们以为单独、使用期长的TCP连接加载数MB的图片数据时,可能会因加载CSS、JS或者字体等布局阻塞资源而耗尽带宽。然而,在网络瀑布图中并未显示出加载布局阻塞资源所带来的变化。

假设二:改变的加载优先级

在使用HTTP/1.x时,浏览器的限制是同一个源大约只能同时有6个公开连接。当探测到资源时,会自动添加到先进先出(FIFO)资源下载队列中。针对同一个源的连接数受限,造成了资源加载实际存在优先级,队列中的每个资源代表着一个请求-回应的循环,这个循环必须在资源离开队列前完成,这种行为就是我们所知的网络瀑布流。

HTTP/2的分帧协议使得浏览器将多个请求与回应拼在一起,导致不再有优先级队列的问题。

Discover页面在使用HTTP/1.x和HTTP/2时的网络时间线

我们认为,HTTP/1.x将<script>放在文档末尾的最佳实践现在反而有负作用。

我们关于性能的了解真的错了么?

然而,DOMContentLoaded的时间与之前一致,又排除了这种可能性,根据网络瀑布图,我们可以确认布局阻塞资源比图片的优先级要高。

在实践中,浏览器中的资料下载队列是有优先级的。因此,在页面底部找到<script>前就开始请求那80张图片,并不会造成脚本加载延迟。

假设三:数据流

没有了HTTP/1.x的并发连接限制,浏览器可以立即对所有80张图片进行加载。服务器会对所有的图片请求同时作出回应,浏览器会在图片完成下载后进行绘制。我们可以从网络时间线确认这一行为。

Discover页面,前20张图片请求的HTTP/2网络时间线

图片仍会按照文档顺序执行请求,然而较小的图片会更快完成下载,因此渲染也更快。如果较大的图片刚好在前面的viewport视窗中,由于加载时间较长,视觉完形速度也更慢。

对比3g网络下,Discover页面在HTTP/1.x与HTTP/2中的加载情况

这也解释了为什么视觉完形在带宽较紧张时花费更久,差异这么大。

HTTP/2的细则

在数据流中我们遇到的问题实际上是HTTP/2的一大特性,之前并未讨论太多。

Ilya Grigorik做出了很好的阐述:

“使用HTTP/2时,浏览器是否以最佳方式来传递回应数据要取决于服务器,这不仅仅是字节数或者每秒请求数的问题,更是数据传输的次序问题,请仔细对你的HTTP/2服务器进行测试。”

传统来说,资源会按照文档次序来执行请求,同时浏览器可能会为提高性能而做一些调整。这种方式有一些很大的问题:

  • 调整缺失文档记录;
  • 不同浏览器的调整方式不同;
  • 不同浏览器版本的调整方式也不同;
  • 调整是针对整个网站的。

这些调整的变化可能会造成页面性能突然发生变化,而且没有预警。

HTTP/2改变了资源优先级的排列方式,目前由浏览器与服务器共同分担这一责任。浏览器给服务器发出优先级的建议信息,但由服务器决定按照什么次序排列。

这种权力的变更是双刃剑。

资源优先级调整同时存在于服务器与客户端之中,可能会让情况更加不透明,也更加碎片化。然而,让服务器来作出决定实际上是将权力交还给开发人员。

心得

根据我们的调查发现,free performance并不存在。

追求web性能是一种权衡和差异化的行为。

在图片密集型页面中,使用多路复用的HTTP/2连接,而不是HTTP/1.x连接的临界点在于:何时延迟接近图片的平均下载时间。在高延迟和低带宽的合适平衡下,我们可以发现HTTP/2对于小图片加载会有大幅的性能提升。

HTTP/2的部署才刚起步,覆盖范围也很广:

  • 资源权重优先级;
  • 资源依赖优先级;
  • 多路复用的调整;
  • 数据流与连接流的控制。

在未来数年中,可以预见在这些层面会有调整、优化,还有bug无可回避地出现。理解这项新技术的动机与权衡非常重要,这样我们才能准确区分出价值与炒作。

图像优化的注意点

在Discover的案例中,无论是对于HTTP/1还是HTTP/2的用户来说,图片优化的改进无疑会减少视觉完形的时间。而HTTP/2的用户是否能有更大收益还无法确定,我们仍需要考虑优化方案为整个平台带来的工作量以及开销。

作为设计类网站,我们的图片质量是至关重要的,我们在这方面极度用心,因为图片的优化不当也会对用户体验造成很大影响。

我们反复权衡了堆栈复杂度、大量预览图的处理成本、其它会对用户体验造成影响的机会成本,而根据我们的调查,目前的边缘缓存与低开销交付(比如HTTP/2)正好达到合适的平衡。

本文分享自微信公众号 - CSDN技术头条(CSDN_Tech),作者:Michael Mifsud

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-08-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 超过一千一百万台HTTPS Web服务器或受到新密码破译攻击的威胁

    互联网研究组周四警告说,受传输层安全协议保护的超过以前一百万台Web服务器,由于最近的一种新型低成本的密码敏感的会话攻击,可能已经不再安全。全球最受欢迎的前10...

    CSDN技术头条
  • Instagram 的持续部署实践

    在Instagram,我们每日部署后端代码的次数达30-50次,只要有工程师将修改内容提交到主服务器,部署就会进行,而且在大多情况下无需人工介入。这听起来也许很...

    CSDN技术头条
  • JMeter 怎么学?

    大家在网上搜寻许多关于 JMeter 的应用案例时是不是有过这样的遭遇: 明明是按照文档中的内容去做的,但是好些时候总是出错,这个时候会疯狂搜索各类与问题相关的...

    CSDN技术头条
  • HTTP概述 原

    HTTP定义:HTTP是超文本传输协议,是用于传输诸如HTML的超媒体文档的应用层协议,它被设计用于Web浏览器和Web服务器之间的通信。

    tianyawhl
  • 图解HTTP脑图

    在做接口测试的过程中特别是在面试的过程中,都会遇到一些HTTP协议的基础知识问题。一般来说一开始做接口测试并不需要对HTTP协议了解很清楚,但是随着测试的深入,...

    FunTester
  • HTTP协议发展历程

    HTTP超文本传输协议是一个用于传输超文本文档的应用层协议,它是为Web浏览器与Web服务器之间的通信而设计的,HTTP协议到目前为止全部的版本可以分为HTTP...

    WindrunnerMax
  • 使用 HTTP/2 提升性能的几个建议

    历史悠久的超文本传输协议,即HTTP标准,最近版本升级了。HTTP/2在2015年5月被批准,目前已经在很多Web浏览器和服务器中得到实现(包括NGINX Pl...

    sunsky
  • http/2将淘汰websocket? http/3将使用udp? http新闻

    我们正处于互联网所依赖的协议的重大转变之中:HTTP。这一变化提出了许多问题和疑虑,我们正在听取和阅读有关HTTP / 2的许多好(和坏)信息。虽然它提供了很多...

    Jean
  • HTTP概述

    <img style="width: 600px;" src="http://7tszky.com1.z0.glb.clouddn.com/FgB7-X3Scd...

    腾讯IVWEB团队
  • 一文领略 HTTP 的前世今生

    HTTP 协议在当今的互联网可谓是随处可见,一直默默的在背后支持着网络世界的运行,对于我们程序员来说 HTTP 更是熟悉不过了。

    灵魂画师牧码

扫码关注云+社区

领取腾讯云代金券