> For the complete documentation index, see [llms.txt](https://wtifs.gitbook.io/diva-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wtifs.gitbook.io/diva-notes/network/http3.md).

# HTTP 3

**HTTP/2 存在的问题**

**队头阻塞**

TCP传输过程中会把数据拆分为一个个按照顺序排列的数据包，这些数据包通过网络传输到了接收端，接收端再按照顺序将这些数据包组合成原始数据，这样就完成了数据传输。但是如果其中的某一个数据包没有按照顺序到达，接收端会一直保持连接等待数据包返回，这时候就会阻塞后续请求。这就发生了**TCP队头阻塞**。

`HTTP2` 是基于 `TCP` 协议的，因此也存在这个问题

**TCP握手时长**

`TCP` 三次握手的过程客户端和服务器之间需要交互三次，那么也就是说需要消耗 `1.5 RTT`。

另外，如果使用的是安全的 `HTTPS` 协议，就还需要使用 `TLS` 协议进行安全数据传输，这个过程又要消耗 `1.5 RTT`

**升级 TCP ？**

基于上面我们提到的这些问题，升级 `TCP` 协议是否可行？

这就涉及到一个 **协议僵化** 的问题。大部分现有网络上的交换机、路由器、操作系统都不支持直接升级，更换设备的成本巨大。

**QUIC协议**

Google 2013年开发的基于 `UDP` 的协议，全称 `Quick UDP Internet Connection`

有以下特点：

* 基于 `UDP` 的传输层协议：它使用 `UDP` 端口号来识别指定机器上的特定服务器。
* 可靠性：虽然 `UDP` 是不可靠传输协议，但是 `QUIC` 在 `UDP` 的基础上做了些改造，使得他提供了和 `TCP` 类似的可靠性。它提供了数据包重传、拥塞控制、调整传输节奏以及其他一些 `TCP` 中存在的特性。
* 实现了无序、并发字节流：`QUIC` 的单个数据流可以保证有序交付，但多个数据流之间可能乱序
* 快速握手：`QUIC` 提供 `0-RTT` 和 `1-RTT` 的连接建立，比三次握手快
  * 首次建立连接时实际上就是三次握手，只是在第三次握手时直接带上了数据，耗时 `1-RTT`
  * 后续建立连接时会直接使用缓存的密钥，密钥未过期时，直接发送数据即可，耗时 `0-RTT`
* 使用 `TLS 1.3` 传输层安全协议：降低 `TLS` 握手延迟至 `1RTT`

**缺点**

一样存在 **协议僵化** 的问题。因为 `UDP` 一直以来的定位都是不可靠连接，很多中间设备对 `UDP` 的支持程度并不高，有的甚至会过滤一些端口的 `UDP` 包，导致丢包

**参考**

[Hollis - Google、Facebook等均开始支持的HTTP3到底是个什么鬼](https://zhuanlan.zhihu.com/p/338560677)