昨晚偶尔清理Chrome扩展时，发现我的“HTTP/2和SPDY指示器”扩展好像很久没有打开了。当你访问支持HTTP/2（或者之前的SPDY协议）的网站时这个插件就会亮起，我清楚的记得之前https://linux.cn/专门支持HTTP/2。我***的反应是这个插件有问题？于是打开Chrome调试工具，发现request和response真的是HTTP/1.1的。嘿！经过一番研究，原来是从Chrome51开始，在2016年2011年5月31日之前，支持NPN协商协议的HTTP/2网站仍然会使用HTTP/2访问；之后，只有支持ALPN协商协议的HTTP/2网站才会被使用——目前ALPN协议很少被使用。该发行版支持openssl-1.0.2支持。发生了什么？在服务器端，我们知道原来的web访问协议是HTTP/1，包括之前的HTTP/1.0和目前大部分网站使用的HTTP/1.1（HTTP/0.9是实验性协议，已经废弃）。然而，随着Web应用越来越复杂，之前的HTTP/1.x协议似乎已经无法满足日益复杂的Web服务需求。比如明文请求、请求复用等问题。因此，Google开发了一种新的传输层协议，称为SPDY。既然用过这个新协议的人都同意，Google就把这个协议提交给了IETF，大家觉得SPDY这个名字不好听（SPDY是Google的注册商标），就叫HTTP/2吧！SPDY该协议基于SSL/TLS。Google开发了一个名为NextProtocolNegotiation(NPN)的SSL/TLS扩展，用于在客户端连接服务器时协商是否使用HTTP/2协议。Web服务器实现支持SPDY协议，而OpenSSL等SSL实现支持NPN。但随着SPDY被提交给IETF，继而成为HTTP/2协议，谷歌也放弃了SPDY的开发，全身心投入到HTTP/2的开发中。以前使用的NPN也被新的协商协议ALPN所取代。-由应用层协议协商取代。NPN和ALPN是不兼容的，它们的主要区别是：NPN是服务器发送的支持的协议列表，由客户端选择。对于ALPN，客户端发送列表，服务器选择它。在NPN中，最终的选择结果是在ChangeCipherSpec之后发送给服务器的，也就是加密了。在ALPN中，所有协商都是明文形式。这样做的好处主要是安全方面的考虑，但是这带来了一个问题，NPN已经得到了OpenSSL的广泛支持，而ALPN目前只有最新的openssl-1.0.2才支持。目前几个主流Linux发行版的OpenSSL版本及支持的协商协议如下：Linux发行版OpenSSL版本支持的协商协议CentOS/OracleLinux/RHEL5.10+0.9.8e不支持CentOS/OracleLinux/RHEL6.5+，7.0+1.0.1eNPNUbuntu12.04LTS1.0.1NPNUbuntu14.04LTS1.0.1fNPNUbuntu16.04LTS1.0.2gALPNandNPNDebian7.01.0.1eNPNDebian8.01.0.1kNPN从上面我们可以看到基本上所有服务器级别的Linux发行版不支持OpenSSL和ALPN，唯一支持的Ubuntu16.04LTS显然用得不多。不要小看0.0.1版本的差异。对于其他软件来说，0.0.1的差别基本可以忽略不计，但是对于OpenSSL来说，就是两代了。OpenSSL是一个非常底层的库，许多重要的软件都依赖于它。因此，各个发行版在升级OpenSSL时所采取的态度是相当保守的。比如我们可以看到CentOS系统中有哪些软件使用了OpenSSL：$lsof|greplibssl|awk'{print$1}'|sort|uniqanvilfail2bangdbusgmainhttpdpostfixmysqldNetworkManagernginxphp-fpmpupetsshdsudotunedzabbix_agent还没有经过足够的测试，Linux发行版不会在生产中随便升级（服务器）环境。为了解决旧版本（1.0.1）中的安全问题，他们宁愿将新版本（1.0.2）中的安全修复程序移植回旧版本，也不愿升级到新版本（1.0.2）新特性，这就是为什么你会看到各种版本号，比如1.0.1e、1.0.1k等。当然你可以自己编译一个***OpenSSL来替换你系统中的openssl-1.0.1，但我不会你不认为你会这样做，是吗？顺便说一下，NPN和ALPN可以共存，但是客户端会优先选择ALPN。在浏览器端（Chrome），从Chrome51开始，谷歌取消了对SPDY的支持，但这不是问题，因为不仅使用SPDY的web服务器越来越少，而且从SPDY升级到HTTP也非常简单/2。Nginx、Apache等服务器的配置非常简单。但不幸的是，在Chrome51中，谷歌也取消了对NPN的支持！如果您的网络服务器使用的是openssl-1.0.2以下版本，不支持ALPN协商，那么Chrome51及更高版本将使用HTTP/1协议访问您的网站。Google对放弃NPN支持做了简单的解释，但无论如何，NPN协议不会在Chrome51之后回归。另一方面，OpenSSL将不会在2016年12月31日之后继续发布openssl-1.0.1系列的新版本，安全修复到此为止。在这种情况下，你原本支持HTTP/2的网站，通过HTTP/2提供的连接多路复用等新特性，在Chrome下访问时获得了很好的体验，但现在又退回到了之前的老状态。我应该怎么办？有几种方法：换个浏览器，山不来我来，我去山。Chrome51+不支持带NPN的HTTP/2网站。作为浏览器，你可以使用其他浏览器，如Safari、Edge等，这样你就可以使用新协议访问全球10%支持HTTP/2的Web服务器。但是，作为服务器运营商，你不能忽视50%+的Chrome用户。更改服务器如上所示，Ubuntu16.04LTS是目前唯一正式支持openssl-1.0.2的Linux发行版。如果您一直使用Ubuntu作为服务器，请考虑升级。LTS版本最多支持五年。当然，在生产环境中，即使你是Ubuntu服务器，更新版本也是一个大问题，所以要慎重考虑。重新编译由于更改服务器不是一个好的选择，您有另一种解决方案，即使用新的openssl-1.0.2源代码重新编译您的Web服务器，例如nginx。下面简单介绍一下如何用openssl-1.0.2编译nginx。（1.0.2系列的最新版本是1.0.2j，当然，如果非要用1.1.0，我也无话可说。。。）首先下载并解压openssl-1.0.2j：#wgethttps:///万维网。openssl.org/source/openssl-1.0.2j.tar.gz#tar-zxvfopenssl-1.0.2j.tar.gz然后使用--with-openssl=../openssl-1.0.2j选项和您的其他选项：./configure--with-openssl=../openssl-1.0.2j--with-http_v2_module--with-http_ssl_module配置编译后，可以使用nginx-V查看你的OpenSSL的nginx版本。这种自编译的优点是灵活性高，但需要时刻注意各个组件是否存在严重的安全漏洞，待修复版本发布后重新编译。除了自己编译容器，如果你的系统环境已经有容器的支持，你也可以在容器中运行一个Ubuntu16.04LTS，并在其中运行webserver。综上所述，以上就是HTTP/2和Chrome之间的故事。您准备好升级HTTP/2支持了吗？要知道，相比于HTTP/2的访问体验，你肯定不会想回到HTTP/1。
