酷应用

从应用层协议协商机制看，是否应该选择支持 HTTP/2 的 CDN

百家作者：又拍云 2017-09-11 10:23:28

又拍云 Open Talk 技术沙龙北京站，等你报名

——BEGIN——

随着网络传输数据量的剧增，网络数据的传输优化已经变得刻不容缓。选用支持 HTTP/2 的 CDN 可以在很大程度缓解数据量大带来的传输压力。

HTTP/2 针对每个服务器只使用一个连接，省去了多次建立连接的时间，提升了网站的访问速度。还通过压缩头部数据，提升了网站的缓存利用率和加载度。同时 HTTP/2 减少了 TLS 的性能损失，可以让更多的应用使用 TLS，进一步保证了用户的数据安全。

△ HTTP/1.1、HTTP/2 传输性能对比

到目前为止，绝大部分浏览器已经支持 HTTP/2 协议了，但是还有部分浏览器存在不支持 HTTP/2 的问题，那在浏览器不支持 HTTP/2 的情况下，用户访问网站时会不会受到影响？

这里面就涉及 HTTP/2 的应用层协议协商机制，今天我就跟大家聊聊它。

什么是应用层协议协商

应用层协议协商（Application-Layer Protocol Negotiation，简称 ALPN）是一个进行应用层协议协商的传输层安全协议（TLS）扩展。ALPN 允许应用层协商应该在安全连接上采用哪个协议，以避免额外且独立于应用层协议的往返协商通信。

应用层协议协商的作用

应用层协议协商机制的作用简单来说，如果浏览器本身不支持 HTTP/2， TLS 握手过程中 ALPN 扩展中就不会带 h2，CDN 服务端也不会选择 HTTP/2 作为后续协议。而是会和浏览器进行协商，选择 HTTP/2 或者 HTTP 1.1 。

不同情况下的协商结果

服务端	浏览器	协商结果
支持 HTTP/2	支持 HTTP/2	使用 HTTP/2
支持 HTTP/2	不支持 HTTP/2	不进行协商，使用 HTTP/1.1
不支持 HTTP/2	支持 HTTP/2	进行协商，使用 HTTP/1.1
不支持 HTTP/2	不支持 HTTP/2	不进行协商，使用 HTTP/1.1

服务端与浏览器如何进行协商

那么服务端和浏览器是怎么通过应用层协商协议进行协商的呢？

这里就要讲一下 HTTP/2 协议的另一个特点。虽然 HTTP/2 本身并没有要求它必须基于 HTTPS（TLS）部署，但是目前几乎所有的 HTTP/2 和 HTTPS 都是捆绑在一起的，并且当前的主流浏览器，都只支持基于 HTTPS（TLS）部署的 HTTP/2。

因此 HTTP/2 应用层协议协商是在 TLS 握手阶段进行的。当浏览器在建立 TLS 连接时，通过 ALPN 扩展列出了浏览器支持的各种应用层协议。这其中，HTTP/2 协议的标识为 “h2”。图2为浏览器 Client Hello 阶段 ALPN 拓展列出了浏览器支持的三种协议。

△ 图2

图3为服务端 Server Hello 阶段响应浏览器的协议，并判断使用 HTTP/2 传输协议的结果。以又拍云 CDN 服务端为例，又拍云 CDN 服务端是默认支持了 HTTP/2 协议的，在 Server Hello 中通过 ALPN 扩展的展示结果中列出了 h2。如果浏览器不支持 HTTP/2 协议，那么 CDN 服务端就会从浏览器的 ALPN 列表中选定一个浏览器可以支持的协议并进行返回，比如 HTTP/1.1 协议。

又拍云 CDN 服务端同时支持 HTTP/1.1。在这种情况下，即使浏览器不支持 HTTP/2，双方也可以协商出可用的 HTTP 传输协议，保证了浏览器的兼容性问题。

△ 图3

总结

综上所述，在浏览器不支持 HTTP/2 的情况下，用户访问网站时不会受到影响。通过应用层协议协商机制，可以保证服务器与浏览器的兼容。

目前又拍云 CDN 服务已全平台支持 HTTP/2，并且默认开启。只要使用又拍云 HTTPS 加速服务的域名，就可免费享受 HTTP/2 服务，无需做任何特殊配置。

另外 HTTP/2 协议对 TLS 有着严格的限制，只能使用 TLSv1.2+ 以上的版本。而又拍云 HTTPS 已经支持 TLSv1.0、TLSv1.1、TLSv1.2 的协议了，可以完全兼容 HTTP/2 协议。所以，老铁们大可放心使用又拍云的 HTTPS 服务，同时享受免费的 HTTP/2 。

——MORE——

更多技术干货

不要错过小拍日志

点击阅读原文

让思想丰满一下