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

前言

有关于 TCP 和 UDP “连接”这个词，是一个逻辑中的“虚拟”的概念，是为了方便我们的学习理解。

UDP的无连接，TCP的连接，唯区别是，UDP把只管发送，TCP每次都对发送的数据进行ACK确认。

这部分代码是放在传输层，还是放在应用层，这都关系不大。

QUIC是可以独立于操作系统发行的，避免了操作系统缓慢的更新换代问题。

QUIC依然要面对消息的可靠性、滑动窗口、拥塞控制等问题，你可以认为它就是一个TCP（但是本质不一样）。

Chromium 官方宣布 Chrome正在部署到 HTTP/3 与IETF QUIC。

因为TCP本身非常复杂，并且有太多历史遗留的包袱。

TCP协议，目前已经被编码到了操作系统，不论是协议升级，还是Bug修复，都是一个大工程。

选择了UDP， UDP是一张白纸，它只是IP协议的一个编程接口。

HTTP3创造出Connection ID概念实现了连接迁移，通过融合传输层、表示层，既缩短了握手时长，也加密了传输层中的绝大部分字段，提升了网络安全性。
HTTP3在Packet层保障了连接的可靠性，在QUIC Frame层实现了有序字节流，在HTTP3 Frame层实现了HTTP语义，这彻底解开了队头阻塞问题，真正实现了应用层的多路复用。
QPACK使用独立的单向Stream分别传输动态表编码、解码信息，这样乱序、并发传输HTTP消息的Stream既不会出现队头阻塞，也能基于时序性大幅压缩HTTP Header的体积。

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又可以细分为两种：

posted @ 2022-03-31 15:10 Ricardo_ML 阅读(2451) 评论(3) 编辑收藏举报

刷新页面返回顶部