HTTP/2介绍

gRPC系列文章(一)

HTTP/2是HTTP/1的升级版,在完全保留HTTP语义的基础上优化了连接延迟,这篇文章将详细的介绍HTTP/2的工作原理。

基础概念

在HTTP/2中完全使用了二进制传输方案,完全放弃了可读性,但带来了巨大的效能提升。为什么二进制传输方案会带来能效提升的问题我们稍后讨论,但是需要明确的是不管多少的HTTP请求,client和server都只建立一条TCP连接,比如"GET localhost/a.html"和"GET localhost/b.html"都是在同一个TCP链路上被传送。

流(Stream)是指一个双向数据流通道12。流是一个逻辑上的概念3,在一次HTTP请求的request和response在同一个流上传递,而TCP连接是复用的,这导致一个物理连接内承载不同流的数据,因此每一个流都会被分配一个ID用于区分数据是属于哪个流的。同时,双向意味着不仅仅client可以向server发送信息,server也能向client发送信息。(这里与主动推送能力的概念还是有分别的。)由客户端建立的流的ID都是奇数的,由服务端建立的流的ID都是偶数的。

信息(Message)是指一个request或者response的全部数据。

帧(Frame)是传输的最小单位,一般来说一个信息由一个或多个帧组成。

帧(Frame)

一个数据帧如上图所示,主要有6个部分组成:

  • Length:帧长度,默认长度为16KB;
  • Type:帧类型,比如传输HTTP Headers的HEADER帧,传输数据的DATA帧等等;
  • Flags:标识位,根据帧类型的不同含义不同;
  • R:暂时忽略
  • Stream Identifier:流ID,一个帧要么属于一个流,要么属于整个TCP连接(ID为0x0);
  • Frame Payload:根据Type有不同的格式。

DATA帧

DATA帧的Type为0x0,重要的DATA帧中Flags的含义:

  • END_STREAM(0x1):告知接受者没有数据要发送了,流进入关闭状态或半关闭状态;
  • PADDED(0x8):表示在Payload中启用填充数据。
DATA帧Payload结构

Payload的结构比较简单,虚线部分都是与Padding相关的内容,如果Flags的PADDED位置0,则虚线数据都不存在,反之则则存在。真正的数据结构存在于Data部分。

HEADER帧

HEADER帧的Type为0x1,重要的HEADER帧中Flags的含义4

  • END_STREAM(0x1):标志流结束,比如在gRPC场景下的Trailer Headers,与DATA帧不同的是,携带END_STREAM的HEADER帧依然可以接受CONTINUATION帧5
  • END_HEADERS(0x4):表示这个帧包含了全部的header block,不会再有CONTINUATION帧了;
  • PADDED(0x8):与DATA帧的PADDED标识含义相同;
  • PRIORITY(0x20):表示Exclusive Flag (E)、Stream Dependency和Weight fields存在,稍后介绍。
HEADER帧Payload结构

所有的Headers都包装在Header Block Fragment中,由于HPACK机制不同的Header状态传输的数据也都不同。

(不同的HEADER格式暂略)

多路复用

HTTP/2正是利用多路复用机制才能极大的降低延迟,在本节中先与HTTP/1进行对比,然后再详细的介绍多路复用机制的原理。

我们假设有2个请求的情景,我们将会分别讨论HTTP/1.0、HTTP/1.1和HTTP/2的请求过程。需要一提的是HTTP/2的请求过程图仅供参考。

http协议对比-fNRLyh

HTTP/1.0是最原始的HTTP版本,也是效率最低的。在上图中可以看到发送两次请求需要建立两次TCP连接,需要经历6次握手过程和8次挥手过程,效率之慢可想而知。HTTP/1.0的问题就出在建立TCP连接次数过多上。

HTTP/1.1引入了keep-alive机制,来解决建立TCP连接次数过多的问题,在上图中可以看到多次请求复用了TCP连接。但是HTTP/1.1的问题是请求需要顺序发送,也是Req1必须等到Req0接收到response之后才能发送,如果Req0非常耗时,那么Req1就会出现饥饿现象。

HTTP/2引入了二进制流,所有数据的传输都基于一个TCP链路,同时一个request或response被分割为若干个帧,帧与帧的传输是完全并行的,不存在HTTP/1.1中Req1需要等待Req0的问题。每个帧都属于一个流或者属于本次TCP连接,即使乱序发射也可以根据流ID进行拼合,所以即使并行发送,也能保证数据完整无误。

头部压缩

HTTP/2中引入了HPACK作为头部压缩策略,通过静态表和动态表实现头部压缩。静态表中存储的是HTTP通用headers,比如Method, URL等等,动态表则是用户自定义的headers,如果一个header是用户自定义的,那么首次到达服务器时会在动态表中分配一个索引。这些表的作用是确定索引与header的映射关系,在表中的header以后就可以使用索引代替字符串,提高传输效率。

如果当前header已经被传输到服务器中且对应的值不变,那么这个值就不需要再次被传输了。一个非常典型的例子是cookie,cookie是一串长度很长的字符串且内容基本不变,在HTTP/2中cookie只会被传输一次,之后将使用索引代替,假设cookie长100bytes,索引长1byte,那么做n次传输就能节省(n-1)*99bytes。

当然头部压缩还有很多细节,在这里就不一一展开了,如果感兴趣可以参考RFC文档

  1. https://pingcap.com/zh/blog/grpc

  2. https://zhuanlan.zhihu.com/p/26559480

  3. https://halfrost.com/http2_begin/

  4. https://www.cnblogs.com/ghj1976/p/4581426.html

  5. https://httpwg.org/specs/rfc7540.html#HEADERS

All rights reserved
Except where otherwise noted, content on this page is copyrighted.