【译】2016 年 5 月 31 号，Google Chrome 将大面积禁用 HTTP/2

本文由360搜索前端负责人屈屈翻译，除了翻译之外，文后还有屈屈对本文的注解，欢迎享用！...



本文由360搜索前端负责人屈屈翻译，除了翻译之外，文后还有屈屈对本文的注解，欢迎享用！英文原文链接： https://ma.ttias.be/day-google-chrome-disables-http2-nearly-everyone-may-31st-2016/

译文如下：

如果你之前阅读过本文（或者看过我在 Twitter 上的吐槽），或许你已经知道了这个消息。否则，以下是简短总结：

Chromium 项目（对用户来说就是 Chrome 浏览器）将会在 2016 年 5 月 15 号 2016 年 5 月 31 号切换协商协议 —— 也就是服务端和浏览器之间用来决定使用 HTTP/1.1 还是最新的 HTTP/2 的协议。
更新：这个变化会在 Chrome 51 中到来（感谢 Eric），原本计划于 5 月 15 号发布，现在看来会推迟几天。最新的开发日程表显示，将于 5 月 31 号发布。

这本不是什么大事情，但不幸的是：以前（2016 年 5 月 31 号之前），Chrome 使用名为

NPN

（Next Protocol Negotiation，下一代协议协商）的协商协议，它不见得多有效率，但凑合着也能用。

后来，又诞生了一项名为 

ALPN

（Application Layer Protocol Negotiation，应用层协议协商）的协商协议。它更有效率，也有更多面向未来的功能。从 

NPN

 迁移到 

ALPN

 应该是个利大于弊的好主意。

然而，运行着 HTTP/2 的服务端，遇到了一个比较现实的问题：要支持 

ALPN

，首先得有 OpenSSL 1.0.2。

然后呢？赶紧化身为系统管理员去升级吧！

我知道，这听上去很容易，对吗？好吧，并不是。这里有一份最新 Linux（2016 年 5 月）中的 OpenSSL 版本对比：

操作系统OpenSSL 版本CentOS 50.9.8eCentOS 61.0.1eCentOS 71.0.1eUbuntu 14.04 LTS1.0.1fUbuntu 16.04 LTS1.0.2gDebian 7 (Wheezy)1.0.1eDebian 8 (Jessie)1.0.1k从这份列表中不难看出问题所在：只有最新的 Ubuntu 16.04 LTS（发布时间不足一个月）才支持 OpenSSL 1.0.2。

升级 OpenSSL 软件包并不是一件容易的事。因为要想用上最新的 OpenSSL 发行版，依赖 OpenSSL 库的任何其它软件，都必须重新打包（以及测试）。

另一方面，OpenSSL 1.0.1 的支持很快就要结束，操作系统发行版升级它只是时间问题。

OpenSSL 1.0.1 的支持将于 2016-12-31 停止。在那之后，OpenSSL 1.0.1 不会再有任何发行版，也不会有任何安全补丁。
OpenSSL 发行说明

为了让你对 OpenSSL 被广泛依赖的现状有所了解，在一个典型的 LAMP 服务器上（例如提供你正在阅读的文章服务的机器），需要用到 OpenSSL 库的软件有这些：

$ lsof | grep libssl | awk '{print $1}'| sort | uniq

anvil

fail2ban

gdbus

gmain

httpd

postfix

mysqldNetworkManagernginx

php-fpm

puppet

sshd

sudo

tuned

zabbix_agent

升级 OpenSSL 会重新打包以上所有软件。往轻了说，这是个麻烦的事情。实际上，这很可能不只是重新打包，而是每一个软件都要为 OpenSSL 1.0.2 中的新增或变动的 API 修改代码。

当前，在现代服务器（非 Ubuntu 16.04 LTS）运行 HTTP/2 的最简单方案，或许是先运行一个 Ubuntu 16.04 的 Docker 容器，然后再在容器里运行服务。

我不是在责怪 Google 切换协议和推动 WEB 发展，我只是悲伤地认为这件事的结果会是：大量 Google Chrome 用户将再一次无法享受到 HTTP/2。

在 2016 年 5 月 31 号之前，用户在 Google Chrome 网络控制台看到是这样的：



在 5 月 31 号之后，它会变成老旧的 HTTP/1.1：



过去，在 Nginx 中启用 HTTP/2 是一件非常简单的事情，但今后要支持 Chrome 就会复杂不少。

这个变化也不是凭空而来：在过去的 2015 年里，Chrome 禁用过 

NPN

，但很快就由于影响面太大而回滚。我们在 2015 年末就知道，这个变化终究会到来 —— 我们有 6 个月的时间来支持 

ALPN

，但从现在 OpenSSL 部署情况来看，这远远不够。

如果你想要跟进 Red Hat (Fedora, RHEL & CentOS) 的 OpenSSL 升级情况，这篇文章有更多信息：RFE: Need OpenSSL 1.0.2。

由于我主要用 CentOS，我不太清楚 Debian 或 Ubuntu 中 OpenSSL 的当前状态。

屈屈注：

Google 在 SPDY 协议中开发了 

NPN

 这个 TLS 扩展，随着 SPDY 被 HTTP/2 取代，NPN 也被官方修订为 

ALPN

。二者的目标一致，都是用来在服务端和浏览器之间协商使用哪个 HTTP 版本，但实现细节不一样，相互无法兼容。

由于 Chrome 51 会禁用 

NPN

，只支持 

ALPN

，而后者需要 OpenSSL 1.0.2 —— 它的普及程度很低。所以作者悲观地认为 Chrome 51 发布那天，大部分 HTTP/2 网站都会因为不支持 

ALPN

 而无法与 Chrome 协商使用 HTTP/2，从而退化到 HTTP/1.1。

实际上，在编译 Nginx 时通过 

--with-openssl

 参数指定 OpenSSL 1.0.2+ 或 LibreSSL 2.1.3+ 源码目录，即可让编译出来的 Nginx 支持 

ALPN

 扩展，也不会修改系统自带 OpenSSL 库。另外，推荐使用 Qualys SSL Labs 工具来检查自己的 HTTP/2 服务器是否支持 

ALPN

。

如果大家喜欢这篇文章，可以转发给你的朋友，如果你还没有关注奇舞周刊，欢迎关注！

    关注 奇舞周刊