你知道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头部