[HTTP3]HTTP/3_http3 帧

美中不足的HTTP/2

HTTP/2通过头部压缩、二进制编码、多路复用、服务器推送等特性大幅度提升了HTTP/1.1的性能，而美中不足的是HTTP/2协议是基于TCP实现的，于是存在3个缺陷。

• 队头阻塞
• TCP与TLS的握手延迟；
• 网络迁移需要重新连接

队头阻塞

HTTP/2多个请求时跑在一个TCP连接中的，那么当TCP丢包时，整个TCP都要等待重传，那么就会阻塞该TCP连接中的所有请求。

因为TCP是字节流协议，TCP层必须保证收到的字节数据是完整且有序的，如果序列号较低的TCP段在网络中丢失了，即使序列号较高的TCP段已经被接收了，应用层因为无法从内核中读取这部分数据，从HTTP视角看，就是请求被阻塞了。

 图中发送方发送了很多个packet，每个packet都有自己的序号，你可以认为是TCP的序列号，其中packet 3在网络中丢失了，即使packet4-6被接收后，由于内核中的TCP数据不是连续的，于是接收方的应用层就无法从内核中读取到，只有等到packet3重传后，接收方的应用层才可以从内核中读取到数据，这就是HTTP/2的队头阻塞问题，是在TCP层面发生的。

TCP与TLS的握手时延延迟

发起HTTP请求，需要经过TCP三次握手和TLS四次握手（TLS 1.2）的过程，因此共需要3个RTT的时延才能发出请求数据。

另外，TCP由于具有拥塞控制的特性，所以刚建立连接的TCP会有个慢启动的过程，它会对TCP连接产生“减速”效果。

网络迁移需要重新连接

一个TCP连接是由四元组（源IP地址、源端口、目标ID地址、目标端口）确定的，这意味着如果IP地址或者端口变动了，就会导致需要TCP与TLS重新握手，这不利于移动设备切换网络的场景，比如4G网络环境切换成WIFI。

这些问题都是TCP协议固有的问题，无论应用层的HTTP/2再如何设计都无法逃脱，要解决这个问题，就必须把传输层协议替换成UDP，这个大胆的决定，HTTP/3做了。

QUIC协议的特点

我们深知，UDP是一个简单、不可靠的传输协议，而且是UDP包之间是无序的，也没有依赖关系。

而且，UDP是不需要连接的，也就不需要握手和挥手的过程，所以天然的就比TCP快。

当然，HTTP/3不仅仅简单将传输协议替换了UDP，还基于UDP协议在应用层实现了QUIC，它具有类似TCP的连接管理、拥塞窗口、流量控制的网络特性，相当于将不可靠的UDP协议变成“可靠”的了，所以不用担心数据包丢失的问题。

QUIC协议的优点有很多，比如：

• 无队头阻塞
• 更快的连接建立
• 连接迁移

无队头阻塞

QUIC协议也有类似HTTP/2Stream与多路复用的概念，也是可以在同一条连接上并发传输多个Stream，Stream可以认为就是一条HTTP请求。

由于QUIC使用的传输协议是UDP，UDP不关心数据包的顺序，如果数据包丢失，UDP也不关心。

不过QUIC协议会保证数据包的可靠性，每个数据包都有一个序号唯一标识，当某个流中的一个数据包丢失了，即使该流的其他数据包到达了，数据也无法被HTTP/3读取，直到QUIC重传的报文，数据才会交给HTTP/3.

而其他流的数据报文只要被完整接收，HTTP/3就可以读取到数据。这与HTTP/2不同，HTTP/2只要某个流中的数据包丢失了，其他流也会因此首影响。

所以，QUIC连接上的多个Stream之间并没有依赖，都是独立的，某个流发生丢包了，只会影响该流，其他流不受影响。

更快的连接建立

对于HTTP/1和HTTP/2协议，TCP和TLS分层，分别属于内核实现的传输层、openssl库实现的表示层，因此它们难以合并在一起，需要分批次来握手，先TCP握手，在TLS握手。

HTTP/3在传输数据前虽然需要QUIC协议握手，这个握手过程只需要1RTT，握手的目的是为确认双方的连接ID，连接迁移就是基于连接ID实现的。

但是HTTP/3的QUIC协议并不是TLS分层，而是QUIC内部包含了TLS，它在自己的帧会携带TLS里的记录，在加上QUIC使用的TLS1.3，因此仅需1个RTT就可以同时完成建立连接与密钥协商，甚至在第二次连接的时候，应用数据包可以和QUIC握手信息（连接信息+TLS信息）一起发送，达到0-RTT的效果。

如下图所示，HTTP/3当会话恢复时，有效负载数据与第一个数据包一起发送，可以做到0-RTT：

连接迁移

在前面我们提到，基于TCP传输协议的HTTP协议，由于是通过四元组确定一条TCP连接，那么当移动设备的网络从4G切换到WIFI时，意味着IP地址变化了，那么就必须要断开连接，然后重新简历连接，而建立连接的过程包含TCP三次握手和TLS四次握手的延迟，实际TCP慢启动的减速过程，给用户的感觉就是网络突然卡顿了一下，因此连接的迁移成本是很高的。

而QUIC协议没有用四元组的方式来“绑定”连接，而是通过连接ID来标记通信的两个端点，客户端和服务器可以各自选择一组ID来标记自己，因此即使移动设备的网络变化后，导致IP地址变化了，只要扔保有上下文信息(如连接ID、TLS密钥等）,就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。

HTTP/3协议

HTTP/3同HTTP/2一样采用二进制帧的结构，不同的地方在于HTTP/2的二进制帧里需要定义Stream，而HTTP/3自身不需要在定义Stream，直接使用QUIC里的Stream，于是HTTP/3的帧的结构也变得简单了。

 从上图可以看到，HTTP/3帧头只有两个字段：类型和长度。

根据帧类型的不同，大体上分为数据帧和控制帧两大类，HEADERS帧（HTTP头部）和DATA帧（HTTP包体）属于数据帧。

HTTP/3在头部压缩算法这一方法也做了升级，升级成了QPACK，与HTTP/2中的HPACK编码方式相似，HTTP/3中的QPACK也采用了静态表、动态表及Huffman编码。

对于静态表的变化，HTTP/2中的HPACK的静态表只有61项，而HTTP/3中的QPACK的静态表扩大到91项。

HTTP/2和HTTP/3的Huffman编码并没有多大不同，但是动态表编码方式不同。

所谓的动态表，在首次请求-响应后，双方会将未包含在静态表中的Header项更新各自的动态表，接着后续传输时仅用一个数字表示，然后对方可以根据这一个数据从动态表查到对应的数据，就不必每次都传输长长的数据，大大提升了编码效率。

可以看到，动态表是具有时序性的，如果首次出现的请求发生了丢包，后续的收到请求，对方就无法解码出HPACK头部，因为对方还没建立好动态表，因此后续的请求解码会阻塞到首次请求中丢失的数据包重传过来。

HTTP/3的QPACK解决了这一问题，那它是如何解决的呢？

QUIC会有两个特俗的单向流，所谓的单向流只有一段可以发送消息，双向则指两端都可以发送消息，传输HTTP消息时用的是双向流，这两个单向流的用法：

• 一个叫QPACK Encoder Stream，用于将一个字典（key-value）传递给对方，比如面对不属于静态表的HTTP请求头部，客户端可以通过这个stream发送字典。
• 一个叫QPACK Decoder Stream，用于响应对方，告诉它刚发的字典已经更新到自己的本地动态表了，后续就可以使用这个字典来编码了。

这两个特俗的单向流是用来同步双方的动态表，编码方收到解码方更新确认的通知后，才使用动态表编码HTTP头部。

总结

HTTP/2虽然具有多个流并发传输的能力，但是传输层是TCP协议，于是存在以下缺陷：

• 队头阻塞，HTTP/2多个请求跑在一个TCP连接上，如果序列号较低的TCP段在网络传输中丢失了，即使序列号较高的TCP段已经被接受了，应用层因为无法从内核中读取到这部分数据，从HTTP视角看，就是多个请求被阻塞了。
• TCP和TLS握手时延，TCP三次握手和TLS四次握手，共有3-RTT的时延；
• 连接迁移需要重新连接，移动设备从4G网络环境切换到WIFI时，由于TCP是基于四元组来确认一条TCP连接的，那么网络环境变化后，就会导致IP地址或端口变化，于是TCP只能断开连接，然后在重新建立连接，切换网络环境的成本高；

HTTP/3就将传输层从TCP替换成了UDP，并在UDP协议上卡发了QUIC协议，来保证数据的可靠传输。

QUIC协议的特点：

• 无队头阻塞，QUIC连接上的多个Stream之间并没有依赖，都是独立的，也不会有底层协议限制，某个流发生丢包了，只会影响该流，其他流不受影响；
• 建立连接速度快，因为QUIC内部包含TLS1.3，因此仅需要1个RTT就可以同时完成建立连接与TLS密钥协商，甚至在第二次连接的时候，应用数据包可以和QUIC握手信息一起发送，达到0-RTT的效果。
• 连接迁移，QUIC协议没有用四元组的方式来绑定连接，而是通过连接ID来标记通信的两个端点，客户端和服务器可以各自选择一组ID来标记自己，因此即使移动设备的网络变化后，导致IP地址变化了，只要仍保有上下文信息，就可以无缝的复用原连接，消除重连的成本。