在Dropbox,我们的网络团队最近升级了前端Nginx的服务器,并让我们的Web服务支持启HTTP/2。 在这篇文章中,希望分享我们在HTTP / 2转换过程中的经验和研究成果。 对我们来说虽然这次升级整体是平滑升级,但是也有需要注意几个问题,可能有些人也会遇到。

背景:HTTP/2和Dropbox的web服务基础设施

HTTP/2(RFC 7540)是HTTP协议的新的主要版本。 它是基于SPDY ,并提供相对于HTTP/1.1的几个性能优化。 这些优化包括更有效的报头压缩,服务器推送,流复用通过相同的连接等。截至今天, HTTP/2由主要浏览器的支持

Dropbox的使用开源Nginx建立SSL连接,并基于第7层做网络流量负载均衡。 在升级之前,我们的前端服务器运行Nginx 1.7并持SPDY。 另一个升级动机是,最新版的Chrome浏览器目前支持SPDY和HTTP/2,但他们将在 5月15日放弃支持SPDY协议。 如果到了那个时候我们还不支持HTTP/2,我们的Chrome用户会被迫从使用SPDY退回到HTTP / 1.1。

HTTP/2升级过程

我们的HTTP/2升级是一个直接的平稳过渡过程。 Nginx在1.9.5版本添加了HTTP/2模块(由Dropbox的联合开发),默认情况下去除了SPDY的支持。 在我们的情况下,决定升级到Nginx 1.9.15,这是当时最新的稳定版本。

nginx的升级的时候需要对配置文件做简单的修改。如果想要启用HTTP/2,需要在listen指令后面添加http2
修饰。在我们这边,由于之前已经使用了SPDY,所以现在只需要简单的把spdy替换成http2就可以了。

Before (SPDY): listen ABCD:443 ssl spdy ;
After (HTTP/2): listen ABCD:443 ssl http2 ;

当然,你可能想通过这里直达完整的Nginx的HTTP/2的配置选项并针对具体情况做优化。

至于部署,我们先在canary机器上部署了HTTP/2一周,在这个时候生产环境依然使用SPDY。在验证正确性和性能评估后,HTTP/2开始启用作为我们的Web服务。
请输入图片描述

从SPDY顺利过渡到HTTP/2(60分流量)

上图显示了从SPDY到HTTP/2平滑过渡。 剩余的HTTP/1.1连接未在该图中所示。 我们在23,36和50分钟的时候逐步在所有前端Web服务器启用HTTP/2。在此之前,所有的连接包括canary机器的HTTP/2流量和生产环境的SPDY流量。 正如你所看到的,大概所有的客户SPDY最终迁移到HTTP/2。

意见

当我们在canary机器启用了HTTP/2后,密切的关注了性能方面的情况。 我们的观察包括演示HTTP/2的效能表现数据,以及需要注意几个问题,因为大多数HTTP/2的实现是还是比较新的。

性能改进

我们已经看到由于更有效的报头压缩(HPACK),在入口业务的带宽明显的减少。
请输入图片描述
流量带宽
降低入口流量的带宽(24小时流量)
上图显示了金丝雀和生产设备,其中HTTP/2只金丝雀计算机上启用的平均水平(每一台机器)通信带宽的比例。 每金丝雀或生产机器约接收从负载平衡器流量的量相同。 如可以看到的,我们已启用后的HTTP / 2的入口业务带宽被显著减少(接近50%)。 值得注意的是,虽然我们在所有的金丝雀和生产计算机上启用SPDY之前,我们并没有对SPDY头压缩转,由于相关的安全问题( CVE-2012-4929又名犯罪)。 至于出口流量,并没有显著变化,因为通常头促成了响应流量的一小部分。

需要注意几个问题

增加的延迟POST请求。当我们启用了HTTP/2的金丝雀的机器,我们注意到在平均等待时间的增加。 下图显示了金丝雀和生产机器之间P50请求延迟的比例。 我们调查了这个问题,发现增加的延迟是由POST请求介绍。 进一步研究后,此行为似乎是由于在Nginx的15年9月1日的具体实施。 相关的讨论可以在发现Nginx的邮件列表的线程 。

要求延迟
请输入图片描述
增加P50要求延迟(24小时流量)
请注意,增加的P50要求延迟比我们在这里看到(约1.5倍),依赖于特定流量的工作量。 在大多数情况下,开销大约是一个额外的往返时间对于我们来说,并没有太大的影响我们的关键性能。 但是,如果你的工作负载包括许多小型和延迟敏感的POST请求,那么增加的延迟是升级到Nginx的15年9月1日时要考虑的一个重要因素。

小心启用HTTP/2的一切,尤其是当你不控制客户端。由于HTTP/2还是比较新的,从我们的经验,某些客户端/库和服务器的实现是不完全兼容呢。 例如:

nginx的15年9月1日,如果他们试图确认连接设置帧之前发送数据帧的客户可以得到拒绝POST请求流错误。 我们已经看到了雨燕SDK这个问题。 值得注意的是,监测Nginx的错误日志是在部署期间至关重要的,而此特定错误消息需要增加错误日志严重性信息。
Chrome未与NO_ERROR处理RST_STREAM正确而引起的问题( 铬问题#603182 nginx的14年9月1日)。 一种解决方法已被列入Nginx的15年9月1日。
Nghttp2没有送END_STREAM在没有窗户的空间,也有人在上述讨论Nginx的邮件列表的线程 。
因为我们的API用户可以使用各种第三方HTTP库,我们需要让我们的API的HTTP/2支持之前进行更广泛的测试。

调试工具

CloudFlare的已经提出了的HTTP/2调试工具很好的总结 。 此外,我们还发现了Chrome的净内部工具(可在镀铬://净内部/#在Chrome http2)是有帮助的。 下图是打开一个新的HTTP/2会话www.dropbox.com当网内部报告帧交换的截图。
请输入图片描述
截图打开一个新的HTTP/2会话时,净内部的
总体而言,我们做了一个平稳过渡到HTTP/2。 下面是从这篇文章的几个外卖。

这是简单的启用HTTP/2 Nginx的。
显著入口流量的带宽减少,因为报头压缩。
增加POST请求的延迟是由于Nginx的15年9月1日的具体HTTP/2的实现。
小心启用HTTP/2的一切,实现是不完全兼容呢。
金丝雀验证和Nginx的错误日志检查有助于及早发现潜在的问题。
我们希望这篇文章是为那些谁有兴趣启用HTTP/2为他们服务或有志于在一般网络很有帮助。 我们也想听听您在下面的意见反馈。

原文链接

标签: http2, nginx, dropbox

添加新评论