为什么HTTP/3要基于UDP？可靠吗？

HTTP/3解决了那些问题？

HTTP2协议基于TCP有序字节流实现，因此应用层的多路复用并不能做到无序地并发，在丢包场景下会出现队头阻塞问题。

HTTP3采用UDP作为传输层协议，重新实现了无序连接，并在此基础上通过有序的QUIC Stream提供了多路复用。

与HTTP2中的HPACK编码方式相似，HTTP3中的QPACK也采用了静态表、动态表及Huffman编码。

HTTP/2 没使⽤常⻅的 gzip 压缩⽅式来压缩头部，⽽是开发了HPACK 算法，HPACK 算法主要包含：

客户端和服务器两端都会建⽴和维护「字典」，⽤⻓度较⼩的索引号表示重复的字符串，再⽤ Huffman 编码压缩数据，可达到 50%~90% 的⾼压缩率。

动态表就是将未包含在静态表中的Header项，在首次出现时加入动态表，这样后续传输时仅用数字表示，大大提升了编码效率。

因此，动态表是天然具备时序性的，如果首次出现的请求出现了丢包，后续请求解码HPACK头部时，会被阻塞。

QPACK将动态表的编码、解码独立在单向Stream中传输，仅当单向Stream中的动态表编码成功后，接收端才能解码双向Stream上HTTP消息里的动态表索引。

物联网时代，移动设备接入的网络会频繁变动，从而导致设备IP地址改变。

对于通过四元组（源IP、源端口、目的IP、目的端口）定位连接的TCP协议来说，这意味着连接需要断开重连。

而HTTP3的QUIC层允许移动设备更换IP地址后，只要仍保有上下文信息（比如连接ID、TLS密钥等），就可以复用原连接。

Packet Header实现了可靠的连接。
QUIC Frame Header在无序的Packet报文中，基于QUIC Stream概念实现了有序的字节流，这允许HTTP消息可以像在TCP连接上一样传输；
HTTP3 Frame Header定义了HTTP Header、Body的格式，以及服务器推送、QPACK编解码流等功能。

为了进一步提升网络传输效率，Packet Header又可以细分为两种：