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

目录

• 前言
• 为什么转用UDP？
  • HTTP/3解决了那些问题？
  • 队头阻塞问题
  • QPACK编码
• IOT
• 参考

推荐阅读：

• 计算机网络汇总

HTTP/3竟然是基于UDP的！开始我也很疑惑，UDP传输不可靠，没有拥塞机制，究竟怎么操作呢？

先说解决方案：

QUIC（Quick UDP Internet Connection）是谷歌制定的一种基于UDP的低时延的互联网传输层协议 ！

QUIC很好地解决了当今传输层和应用层面临的各种需求，包括处理更多的连接，安全性，和低延迟。

前言

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

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

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

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

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

---

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

为什么转用UDP？

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

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

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

• HTTP3创造出Connection ID概念实现了连接迁移，通过融合传输层、表示层，既缩短了握手时长，也加密了传输层中的绝大部分字段，提升了网络安全性。

• HTTP3在Packet层保障了连接的可靠性，在QUIC Frame层实现了有序字节流，在HTTP3 Frame层实现了HTTP语义，这彻底解开了队头阻塞问题，真正实现了应用层的多路复用。

• QPACK使用独立的单向Stream分别传输动态表编码、解码信息，这样乱序、并发传输HTTP消息的Stream既不会出现队头阻塞，也能基于时序性大幅压缩HTTP Header的体积。

HTTP/3解决了那些问题？

• HTTP3基于UDP协议重新定义了连接，在QUIC层实现了无序、并发字节流的传输，解决了队头阻塞问题（包括基于QPACK解决了动态表的队头阻塞）；

• HTTP3重新定义了TLS协议加密QUIC头部的方式，既提高了网络攻击成本，又降低了建立连接的速度（仅需1个RTT就可以同时完成建链与密钥协商）；

• HTTP3 将Packet、QUIC Frame、HTTP3 Frame分离，实现了连接迁移功能，降低了5G环境下高速移动设备的连接维护成本。

队头阻塞问题

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

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

QPACK编码

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

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

• 静态字典；（高频头部或者字段，共61种，QPACK中，则上升为98个静态表项）
• 动态字典；（自行构建。Index 62 起步）动态表编解码方式差距很大
• Huffman 编码 编码（压缩算法）；

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

---

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

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

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

IOT

物联网时代，移动设备接入的网络会频繁变动，从而导致设备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又可以细分为两种：

• Long Packet Header用于首次建立连接；

• Short Packet Header用于日常传输数据。

参考

• https://tools.ietf.org/html/draft-ietf-quic-http-34
• https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-17
• https://ably.com/topic/http3?amp%3Butm_campaign=evergreen&%3Butm_source=reddit&utm_medium=referral
• https://www.nginx.org.cn/article/detail/422
• https://www.chinaz.com/2020/1009/1192436.shtml