小林计网笔记-3.7 HTTP/3强势来袭

3.7 HTTP/3强势来袭

美中不足的HTTP/2

HTTP/2通过头部压缩、二进制编码、并发传输、服务器推送等新特性大幅度提升HTTP/1.1的性能，而美中不足的是HTTP/2协议是基于TCP实现的，于是存在的缺陷有三个：

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

队头阻塞

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

上图中，Stream2有一个TCP报文丢失了，那么即使收到了Stream3和Stream4的TCP报文，应用层也是无法读取的，相当于阻塞了Stream3和Stream4请求。
因为TCP是字节流协议，TCP层必须保证收到的字节数据是完整且有序的，如果序列号较低的TCP段在网络传输中丢失了，即使序列号较高的TCP段已经被接收了，应用层也无法从内核中读取到这部分数据，从HTTP视角看，就是请求阻塞了。

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

TCP与TLS的握手时延迟

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

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

网络迁移需要重新连接

一个TCP连接是由四元组（源IP地址，源端口，目标IP地址，目标端口）确定，如果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/2 Stream与多路复用的概念，也是可以在同一条连接上并发传输多个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，因此仅需1RTT就可以同时完成建立连接与密钥协商，甚至在第二次连接的时候，应用数据包可以和QUIC握手哦信息（连接信息+TLS信息）一起发送，达到0RTT的效果。
如下图右边部分，HTTP/3当会话恢复时，有效负载数据与第一个数据包一起发送，可以做到0-RTT：

连接迁移

基于TCP传输协议的HTTP协议，由于是通过四元组（源IP、源端口、目的IP、目的端口）确定一条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项更新各自的动态表，接着后续传输时仅用1个数字表示，然后对方可以根据这1个数字从动态表查到对应的数据，不必每次都传输长长的数据，大大提升了编码效率。
动态表具有时序性，如果首次出现的请求发生了丢包，后续的收到请求，对方就无法解码出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，因此仅需1RTT就可以同时完成建立连接与TLS密钥协商，甚至在第二次连接的时候，应用数据包可以和QUIC握手信息（连接信息+TLS信息）一起发送，达到0-RTT的效果。
• 连接迁移。QUIC协议没有用四元组的方式绑定连接，而是通过连接ID来标记通信的两个端点，客户端和服务器可以各自选择一组ID来标记自己，因此即使移动设备的网络变化后，导致IP地址改变了，只要仍保有上下文信息（连接ID、TLS密钥等），就可以无缝地复用原连接，消除重连地成本。

另外，HHTP/3的QPACK通过两个特殊的单向流来同步双方的动态表，解决了HTTP/2的HPACK队头阻塞问题。