HTTP2 规范在2015年5月正式发布,至今大多数浏览器和服务器已经对此协议提供了支持:
作为一个对 HTTP1.x 进行了加强、补充和完善的更好的协议,值得我们好好的去了解它,然后使用它做出更美妙的事情。
1 过去和现在
HTTP1.1 自从1997年发布1999年最后一次修改以来,我们已经使用 HTTP1.x 相当长一段时间了,但是随着近十年互联网的爆炸式发展,当时协议规定的某些特性,已经无法满足现代网络的需求了。
HTTP1.x 有以下几点致命缺陷:(以浏览器至服务器为例)
- 协议规定客户端对同一域的并发连接最多只能2个(浏览器实现一般是2~8个),但是现代网页平均一个页面需要加载 40个资源
- 线头阻塞(Head of line blocking)问题:同一个连接中的请求,需要一个接一个串行发送和接收
- 基于文本协议,请求和响应的头信息非常大,并且无法压缩。
- 不能控制响应优先级,必须按照请求顺序响应。
- 只能单向请求,也就是客户端请求什么,服务器只能返回什么。
就是以上问题严重影响了现代互联网信息交互的效率和灵活性,此时更现代更高效的通讯协议 HTTP2 应运而生。
HTTP2 使用了多路复用
、HPACK头压缩
、流 + 二进制帧
和流优先级
等技术手段解决上述问题。
2 HTTP2
HTTP2 的前身是 SPDY协议(一个 Google 主导推行的应用层协议,作为对 HTTP1 的增强),第一版草稿就是基于 SPDY3 规范修改制定而来。HTTP2必须在维持原来 HTTP 的范式(不改动 HTTP/1.x 的语义、方法、状态码、URI 以及首部字段等等)前提下,实现突破性能限制,改进传输性能,实现低延迟和高吞吐量。
HTTP2 的特性包括:
- 传输内容使用二进制协议
- 使用帧作为最小传输单位
- 多路复用
- 头压缩
- 服务器推送
- 优先级与依赖性
- 可重置
- 流量控制
- HTTPS rfc 规范并没有要求 HTTP2 强制使用 TLS,但是目前世界所有浏览器和服务器实现都基于 HTTPS 来实现 HTTP2
2.1 二进制
在 HTTP1.x 时代,无论是传输内容还是头信息,都是文本/ASCII编码的,虽然这有利于直接从请求从观察出内容,但是却使得想要实现并发传输异常困难(存在空格或其他字符,很难判断消息的起始和结束)。使用二进制传输可以避免这个问题,因为传输内容只有1和0,通过下面第二点的“帧”规范规定格式,即可轻易识别出不同类型内容。同时使用二进制有一个显而易见的好处是:更小的传输体积。
2.2 二进制分帧
HTTP2 在维持原有 HTTP 范式的前提下,实现突破性能限制,改进传输性能,实现低延迟和高吞吐量的其中一个关键是:在应用层(HTTP2)和传输层(TCP or UDP)之间增加了二进制分帧层
。
帧(Frame)是 HTTP2 通讯中的最小传输单位,所有帧以固定的 9 个八位字节头部开头,随后是一个可变长度的有效载荷
帧结构图
+-----------------------------------------------+
| 长度Length (24) |
+---------------+---------------+---------------+
| 类型Type (8) | 标志Flags (8) |
+-+-------------+---------------+-------------------------------+
|R| 流标识符Stream Identifier (31) |
+=+=============================================================+
| 帧载荷Frame Payload (0...) ...
+---------------------------------------------------------------+
规范中一共定义了 10 种不同的帧,其中最基础的两种分别对应于 HTTP1.x 的 DATA 和 HEADERS。
一个真正的 HTTP2 请求类似下图:
2.3 多路复用(Multiplexing)和流
上一节提到的
Stream Identifier
将 HTTP2 连接上传输的每个帧都关联到一个“流”。流是一个独立的,双向的帧序列,可以通过一个 HTTP2 的连接在服务端与客户端之间不断的交换数据。
每个单独的 HTTP2 连接都可以包含多个并发的流,这些流中交错的包含着来自两端的帧。流既可以被客户端/服务器端单方面的建立和使用,也可以被双方共享,或者被任意一边关闭。在流里面,每一帧发送的顺序非常关键。接收方会按照收到帧的顺序来进行处理。
上面是《HTTP2 讲解》对流的解释,下面接着是一个小火车的例子,但是个人觉得这个例子有一定的偏差,并且并不能让人直观的理解 帧-流-连接
之间的关系,以下是个人理解:
A "stream" is an independent, bidirectional sequence of frames exchanged between the client and server within an HTTP/2 connection. --rfc7540 StreamsLayer
“流”是一个逻辑上的概念(没有真正传输流这么个东西),是 HTTP2 连接中在客户端和服务器之间交换的独立双向帧序列,这就是为什么在规范中的 stream 也是用双引号括起来的原因。从上一节我们可以知道,HTTP2 的传输单位是帧,流其实就是一个帧的分组集合的概念,为什么需要这个逻辑集合呢?答案就在多路复用
。
多路复用是解决 HTTP1.x 缺陷第一点(并发问题)和第二点(HOLB线头问题)的核心技术点。这里需要举个🌰来说明:
假设已经建立了 TCP 连接,现在需要客户端发起了两个请求,从流的角度看是这样的:
但是实际 TCP 连接只有一个,两个帧是不可能真的“同时”到达服务器的,多路复用更像是 CPU 处理任务概念中的 并发
,而不是并行,从规范中使用术语 Stream Concurrency 而不是 Stream Parallelism
也可得出此结论,所以实际传输时是下图:
上图需要注意三点:
- 同一个流中的帧是交错传输的!
- Header 帧必须在 data 帧前面,因为无论是客户端还是服务端,都依赖 header 帧的信息解析 data 帧的数据!
- 先到的帧不一定先返回,快的可以先返回!
正是由于上述第一点特性,解释了为什么需要“流”这个逻辑集合。同时,通过这种 帧-流-连接
的组合,解决了请求并发(一次连接多个请求)和HOLB线头问题(并发发送,异步响应)。
进入 HTTP/2: the Future of the Internet 由 Akamai 公司建立的官方 Demo,可以看出 HTTP2 相比于之前的 HTTP1.1 在性能上的大幅度提升。
HTTP1.1
HTTP2
在过去,我们发现 HTTP 性能优化的关键不在于高宽带,而是低延迟。
从上图可见,当带宽到达一定的速度之后,对页面加载速度的提升已经很少了,但是随着延迟的减少,页面加载时间会对应持续的减少。由于 TCP 连接存在一种称为「调谐」的慢启动(slow start)特性,让原本就具有突发性和短时性的 HTTP 连接变的十分低效。而 HTTP2 通过让所有数据流共用同一个连接,可以更有效地使用 TCP 连接,让高带宽也能真正的服务于 HTTP 的性能提升。
以上纯属个人理解,如有不对请不吝指出共同讨论,感谢!
2.4 头压缩
我们都知道 HTTP协议本身是无状态(stateless) 的:每个请求之间互不关联,每个请求都需要携带服务器所需要的所有细节信息。比如说请求1发送给服务器信息“我是用户A”,然后请求二发送信息“修改我的用户名为XX”,这时如果请求二没有携带“我是用户A”的信息,那么服务器是不知道要修改哪个用户的用户名的。
这显然是不符合当前 web 应用系统架构的,因为一般系统都需要进行鉴权,日志记录,安全校验等限制,所以需要获取当前操作用户的信息,出于安全和性能考虑我们不能在消息体中明文包含这些信息,HTTP2 之前的解决方案一般是使用 Cookies 头、服务器session 等方式模拟出“状态”。而使用 Cookies 头的缺点就是每个请求都需要携带庞大的重复的信息并且无法压缩,假设一个请求的 header 是2kb,那么一百个请求就是重复的 200Kb 信息,这是一个巨大的带宽浪费。
HTTP2 增加了两个特性解决上述问题:
- HPACK,专门为头部压缩设计的算法,还被指定成单独的草案中。
- 首部表,HTTP2 在户端和服务器端使用“首部表”来跟踪和存储之前发送的键-值对,对于相同的数据,不再通过每次请求和响应发送;通信期间几乎不会改变的通用键-值对(用户代理、可接受的媒体类型,等等)只需发送一次。
2.5 服务器推送
这个功能通常被称作“缓存推送(cache push)”。主要的思想是:当一个客户端请求资源X,而服务器知道它很可能也需要资源Z的情况下,服务器可以在客户端发送请求Z前,主动将资源Z推送给客户端。这个功能帮助客户端将Z放进缓存以备将来之需。
服务器推送需要客户端显式的允许服务器提供该功能。但即使如此,客户端依然能自主选择是否需要中断该推送的流。如果不需要的话,客户端可以通过发送一个 RST_STREAM
帧来中止推送。
我们来看一下实际场景:现在我们访问一个网站,第一个请求一般是获取 Document 页面,然后浏览器解析这个页面,在遇到需要资源获取的时候(css、js、图片等),再去发起资源获取请求,如下图:
【传统做法】
为了加速这个过程,减少白屏时间,传统的做法是把首页需要的资源都内联到 Document 中,还有合并资源比如 CSS sprites,js 压缩合并等。如下图:
【HTTP2】
在 HTTP2 的场景下,客户端在请求 Document 的时候,服务器如果知道页面需要的资源有哪些,就可以把那些资源也一同返回了:
注意:主动推送的资源是能被浏览器缓存的!
那么问题来了,如果客户端已经缓存了资源,此时服务器每次都还推送同样的资源给客户端,这不是很大的浪费吗?
答:原来确实会存在这种情况,所以 IETF 小组正在拟定一个名为 cache-digest的技术规范,用于帮助客户端主动告诉服务端哪些资源已经缓存了,不需要重复发送。
关于服务端推送对网页性能的影响,和对于 CDN 的使用的比较,可以参考下面两篇文章:
- measuring-server-push-performance
- http://www.ruanyifeng.com/blog/2018/03/http2_server_push.html
结论:使用 HTTP2 的多路复用和服务器推送功能,并不意味着可以减少甚至抛弃使用 CDN,因为 CDN 带来的现实地理位置上延迟减少是 HTTP2 所不能解决的,反而我们应该思考的是如何把 HTTP2 和 CDN 结合起来,进一步提升网络服务的效率和稳定性,减少延迟。
2.6 优先级与依赖性
每个流都包含一个优先级(也就是“权重”),它被用来告诉对端哪个流更重要。当资源有限的时候,服务器会根据优先级来选择应该先发送哪些流。
借助于PRIORITY帧,客户端同样可以告知服务器当前的流依赖于其他哪个流。该功能让客户端能建立一个优先级“树”,所有“子流”会依赖于“父流”的传输完成情况。
优先级和依赖关系可以在传输过程中被动态的改变。这样当用户滚动一个全是图片的页面的时候,浏览器就能够指定哪个图片拥有更高的优先级。或者是在你切换标签页的时候,浏览器可以提升新切换到页面所包含流的优先级。
2.7 可重置
HTTP1.x 的有一个缺点是:当一个含有确切值的 Content-Length
的 HTTP 消息被送出之后,你就很难中断它了。当然,通常你可以断开整个 TCP 链接(但也不总是可以这样),但这样导致的代价就是需要通过三次握手来重新建立一个新的TCP连接。
一个更好的方案是只终止当前传输的消息并重新发送一个新的。在http2里面,我们可以通过发送 RST_STREAM 帧来实现这种需求,从而避免浪费带宽和中断已有的连接。
2.8 流量控制
每个http2流都拥有自己的公示的流量窗口,它可以限制另一端发送数据。如果你正好知道SSH的工作原理的话,这两者非常相似。
对于每个流来说,两端都必须告诉对方自己还有足够的空间来处理新的数据,而在该窗口被扩大前,另一端只被允许发送这么多数据。
只有数据帧会受到流量控制。
总结
我们来归纳一下使用 HTTP2 能带来的好处:
- 更小的传输体积,更小或者省略重复的头消息
- 突破原有的 TCP 连接并发限制,使用一个 TCP 连接即可实现多请求并发,单链接也能减轻服务端的压力(更少的内存和 CPU 使用)
- 解决 HOLB 线头问题,慢的请求或者先发送的请求不会阻塞其他请求的返回
- 结合 CDN 提供实时性更高,延迟更低的内容分发代理服务,大大减少白屏时间
- 数据传输优先级可控,使网站可以实现更灵活和强大的页面控制
- 能在不中断 TCP 连接的情况下停止(重置)数据的发送
本文主要是学习笔记和个人理解,首发于 xlaoyu.info, 部分图片和文字引用网络,侵删。
参考文章:
- Ideal HTTP Performance 作者是 Mark Nottingham,IETF HTTP Working Group 的主席,Akamai 公司的首席架构师。
- TCP那些事
- HTTP2概述
- HTTP2讲解
- HTTP/2 is here, let’s optimize! Ilya Grigorik, Velocity SC 2015
- rfc7540
- HTTP2的总结
- HTTP2.0 的奇妙日常 -- alloyteam