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

89590599 2019-06-21

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

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

从应用层协议协商机制看,是否应该选择支持 HTTP/2 的 CDN△ 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 的 CDN

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

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

这里就要讲一下 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 拓展列出了浏览器支持的三种协议。

从应用层协议协商机制看,是否应该选择支持 HTTP/2 的 CDN
△图3
图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 传输协议,保证了浏览器的兼容性问题。

总结

综上所述,在浏览器不支持 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 。

参考内容来源:

Jerry Qu的博客

维基百科-HTTP2

推荐阅读:一文读懂 HTTP/2 特性

相关推荐