HTTP/2 存在的缺陷：

队头阻塞

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

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

TCP 和 TLS 的 握手时延

• 发起HTTP 请求需要经过 TCP 三次握手和 TLS（1.2） 四次握手的·1过程。共 3 个 RTT 后才能发出请求数据。
• TCP 具有 【拥塞控制】的特性，对于刚建立连接的 TCP 会有个【慢启动】的过程。它会对 TCP 连接产生“减速”效果。

网络迁移需要重新连接

基于 TCP 传输协议的 HTTP 协议，是通过四元组（源 IP、源端⼝、⽬的 IP、⽬的端⼝）确定⼀条 TCP 连接。

当 IP 地址或端口号变动时，需要 TCP 和 TLS 重新握手。

这不利于移动设备切换网络的场景，如 4G 网络环境切换成 WIFI，意味着 IP 地址变化了。

解决办法：

HTTP/3 把 传输层协议替换成 UDP；还基于 UDP 协议在 应用层 实现了 QUIC 协议。

UDP不需要连接，没有握手和挥手过程，所以 自然比 TCP 快。

QUIC 协议具有类似 TCP 的连接管理、拥塞窗口、流量控制的网络特性。相当于将不可靠传输的 UDP 协议变成“可靠”的。

QUIC 协议

优点：

无队头阻塞

QUIC 协议也有 Stream 与 多路复用的概念。

QUIC 连接上的多个 Stream 之间都是独立的。某个流发生了丢包，只会影响该流。

更快地建立连接

HTTP/3 在传输数据前也需要 QUIC 协议握手，但只需 1 RTT。

握手的目的是为确认双方的【连接 ID】。

QUIC 内部包含了 TLS 1.3，它在自己的帧会携带 TLS 里的 “记录”。因此仅需 1 RTT 就可以 同时 完成建立连接与密钥协商。甚至在第二次连接时，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0 RTT 的效果。

连接迁移

QUIC 协议没有用四元组的方式来“绑定”连接。

而是通过【连接 ID】来标记通信的两个端点。即使移动设备的网络变化导致IP地址改变，只要仍保有上下文信息（连接 ID 、TLS 密钥等），就可以“无缝”对接。

HTTP/3 直接使用 QUIC 里的 Stream

HTTP/2 和 HTTP/3 帧格式对比

HTTP/3 的头部压缩算法

QPACK

QPACK

• 与 HTTP/2 中的 HPACK 编码⽅式相似， HTTP/3 中的 QPACK 也采⽤了静态表、动态表及 Huffman 编码。
• 静态表有91项。
• QUIC 有两个特殊的单向流（mean：只有一端可以发送消息）。用来同步双方的动态表。

解决了 HTTP/2 的问题：动态表具有时序性。如果首次出现的请求包丢失了，后续收到的请求则不能根据动态表上的 index 来解码出 HPACK 头部。因为对方还没建立好动态表。因此请求会阻塞直到 首次丢失的那个数据包重传过来。

标签：TLS,协议,HTTP,TCP,介绍,QUIC,连接
来源： https://www.cnblogs.com/tiddler/p/16651122.html