HTTP3
一、HTTP2的问题
对头阻塞
HTTP/2 多个请求是跑在⼀个 TCP 连接中的,那么当 TCP 丢包时,整个 TCP 都要等待重传,那么就会阻塞该 TCP 连接中的所有请求。由于内核中的TCP 数据不是连续的,于是接受方的应用层就无法从内核中读取到,只有等到丢包的数据重传后,接收方的应用层才可以从内核中读取到数据,这就是 HTTP/2的队头阻塞问题,是在 TCP层面发生的。
TCP与TLS的握手时延迟
发起HTTP 请求时,需要经过TCP三次握手和 TLS 四次握手(TLS 1.2)的过程,因此共需要 3 个 RTT 的时延才能发出请求数据。
网络迁移需要重新连接
⼀个TCP 连接是由四元组(源IP地址,源端口,目标IP地址,目标端口)确定的,这意味着如果IP地址或者端口变动了,就会导致需要TCP 与 TLS重新握手,这不利于移动设备切换网络的场景,比如 4G网络环境切换成 WIFI。 这些问题都是TCP协议固有的问题,无论应用层的 HTTP2 在怎么设计都无法逃脱。要解决这个问题,就必须把传输层协议替换成 UDP,这个大胆的决定,HTTP3做了。
二、QUIC协议的特点
HTTP3不仅仅只是简单将传输协议替换成了UDP,还基于UDP 协议在应用层实现了QUIC协议,它具有类似 TCP 的连接管理、拥塞窗口、流量控制的网络特性,相当于将不可靠传输的 UDP 协议变成“可靠”的了, 所以不用担心数据包丢失的问题。
无队头阻塞
QUIC 协议会保证数据包的可靠性,每个数据包都有⼀个序号唯⼀标识。当某个流中的⼀个数据包丢失了,即 使该流的其他数据包到达了,数据也无法被 HTTP3 读取,直到QUIC重传丢失的报文,数据才会交给 HTTP3。 而其他流的数据报文只要被完整接收,HTTP3 就可以读取到数据。这与 HTTP2 不同,HTTP2 只要某个流中的数据包丢失了,其他流也会因此受影响。 所以,QUIC连接上的多个Stream 之间并没有依赖,都是独立的,某个流发生丢包了,只会影响该流,其他流不受影响。
更快的连接建立
HTTP3在传输数据前虽然需要QUIC协议握手,这个握手过程只需要1RTT,握手的目的是为确认双方的连接 ID,连接迁移就是基于连接ID实现的。HTTP3的QUIC协议并不是与TLS分层,而是QUIC内部包含了TLS,它在自己的帧会携带TLS里的“记 录”,再加上QUIC使用的是 TLS1.3,因此仅需1个 RTT就可以同时完成建立连接与密钥协商,甚至在第二次连接的时候,应用数据包可以和QUIC握手信息(连接信息 + TLS信息)⼀起发送,达到 0-RTT的效果。
连接迁移
QUIC 协议没有用四元组的⽅式来“绑定”连接,而是通过连接 ID来标记通信的两个端点,客户端和服务器可以各自选择⼀组ID 来标记自己,因此即使移动设备的网络变化后,导致IP地址变化了,只要仍保有上下文信息(比如连接ID、TLS 密钥等),就可以“无缝”地复用原连接,消除重连的成本,没有丝毫卡顿感,达到了连接迁移的功能。
三、HTTP3协议
HTTP2与HTTP3的帧格式
头部算法
HTTP3在头部压缩算法这一方便也做了升级,升级成了 QPACK。与HTTP2中的HPACK编码方式相似, HTTP3中的QPACK也采用了静态表、动态表及Huffman编码,对于静态表的变化,HTTP2中的HPACK的静态表只有61项,而HTTP/3 中的QPACK的静态表扩大到91项。 HTTP2和HTTP3的Huffman编码并没有多大不同,但是动态表编解码方式不同。
HTTP2和HTTP3的Huffman编码并没有多大不同,但是动态表编解码方式不同。
所谓的动态表,在首次请求-响应后,双方会将未包含在静态表中的Header项更新各自的动态表,接着后续传输时仅用1个数字表示,然后对方可以根据这1个数字从动态表查到对应的数据,就不必每次都传输太长的数据,大大提升了编码效率。 可以看到,动态表是具有时序性的,如果首次出现的请求发生了丢包,后续的收到请求,对方就无法解码出HPACK头部,因为对方还没建立好动态表,因此后续的请求解码会阻塞到首次请求中丢失的数据包重传过来
HTTP/3 的 QPACK 解决了这⼀问题,那它是如何解决的呢?
QUIC会有两个特殊的单向流,所谓的单项流只有⼀端可以发送消息,双向则指两端都可以发送消息,传输HTTP消息时用的是双向流,这两个单向流的用法: ⼀个叫QPACK Encoder Stream, 用于将⼀个字典(key-value)传递给对方,比如⾯对不属于静态表的HTTP请求头部,客户端可以通过这个 Stream 发送字典; ⼀个叫QPACK Decoder Stream,用于响应对方,告诉它刚发的字典已经更新到自己的本地动态表了,后续就可以使用这个字典来编码了。
这两个特殊的单向流是⽤来同步双方的动态表,编码方收到解码方更新确认的通知后,才使用动态表编码HTTP头部