HTTP 3.0 于 2022年6月6日正式发布，目前的使用量已经高于 HTTP 1.1，HTTP 3.0 的核心上实际是QUIC，可以说 HTTP 3.0 就是 HTTP over QUIC。
HTTP 2.0 遗留的问题
- 加密问题： 虽然 HTTP/2.0 鼓励使用加密，但并未将其设为强制要求。这可能导致一些网站在实施 HTTP/2.0 时选择不使用加密，从而使数据在传输过程中处于风险之中。
- TCP 队头阻塞问题：虽然 HTTP/2.0 通过多路复用解决了 HTTP/1.x 的队头阻塞问题，但在 TCP 层面，队头阻塞问题仍然存在。如果一个 TCP 数据包丢失，那么 TCP 会停止发送数据，直到丢失的数据包被确认接收。这可能导致 HTTP/2.0 的所有并行请求都被阻塞。
- 优先级调度：HTTP/2.0 提供了一种机制，允许客户端指定请求的优先级。然而，这个设计过度超前和复杂，导致很多应用并没有实现。
- 连接建立的延迟：在 HTTP/2.0 中，建立一个新的连接需要进行多次往返通信，这可能会导致延迟。特别是在切换网络的情况下，比如从wifi切换到5g网络，TCP就需要重新建立连接。
在TCP连接中，以下五元素之一变化，就会导致连接断开 TCP 五元组
- 源IP
- 源端口
- 通信层协议
- 目标端口
- 目标IP
什么是QUIC
采用UDP传输层： QUIC 使用UDP（用户数据报协议）作为传输层协议，与传统的TCP相比，UDP减少了连接建立的延迟。TCP需要经历三次握手来建立连接，这会引入1个往返时间（1-RTT）的延迟。相比之下，QUIC的UDP传输层减少了这个握手过程，从而减少了建立连接的时间。这有助于提高网络通信的效率，尤其是对于那些对延迟要求较高的应用程序。
使用TLS 1.3协议： QUIC集成了TLS（传输层安全性）协议的最新版本，即TLS 1.3。TLS 1.3具有改进的安全性（删除了不安全的套件算法）和性能特性，其中一个显著的特点是支持1-RTT和0-RTT握手。传统的TLS握手需要多个往返时间（RTT），而QUIC协议通过TLS 1.3允许客户端在TLS握手完成之前发送应用程序数据。这意味着在第一次握手时需要1-RTT，但之后，已建立连接的客户端可以使用缓存的信息来快速恢复TLS连接，只需0-1 RTT。这显著减少了建立连接的时间，使数据能够更快地传输，特别是对于重复连接的情况。
![[quic.png]]
QUIC协议的特点
- 基于UDP的传输层协议
- 是可靠的传输协议。虽然 UDP 协议是不可靠的传输协议，但是
QUIC协议在 UDP 协议的基础上进行了改造，使得它能够提供和 TCP 协议类似的可靠性，比如它提供了数据包重传、拥塞控制、调整传输节奏以及其他一些 TCP 中存在的特性。 - 实现了无序、并发的字节流。QUIC 协议的单个数据流可以保证有序交付，但多个数据流之间可能乱序!
- 快速握手。QUIC协议提供了0-RTT 和1-RTT 的连接建立。
- 使用 TLS 13 传输层安全协议。与更早的 TLS 版本相比，TLS 1.3 有着很多优点，但使用它的最主要原因是其握手所花费的往返次数更少。
QUIC 协议的核心特性
笛福赫尔曼密钥交换
QUIC 使用了
DH算法进行密钥协商。DH 算法依赖离散对数这一数学难题, 正向计算简单，逆向计算及其困难，过程简单描述为：选取一个质数 P 和 G ，通讯双方分别根据自己私钥 a、 P 、 G 计算出对应的公钥 M，将[P、G、M]发送给对方，双方再根据对方的公钥和自己的私钥计算出通讯密钥
公钥计算公式为： 秘钥计算公式为：
公钥计算：
| P | G | a | M |
|---|---|---|---|
| 23 | 5 | 6 | 8 |
| 23 | 5 | 15 | 19 |
秘钥计算
| P | G | M | S |
|---|---|---|---|
| 23 | 5 | 19 | 2 |
| 23 | 5 | 8 | 2 |
1-RTT（1 Round-Trip Time）
- Server 端计算好秘钥 a, 并且将 P G M 打包成 config
- Client 向 Server 端发送
Client Hello - Server 向 Client 端发送 config
- Client 生成自己的私钥 a'，并且计算出 M' , 使用 config 中的 M 计算出秘钥 S，使用秘钥S对数据进行加密，发送
加密数据+M' - Server 端接收到
加密数据和M'，根据 [P、G、 M'] 计算出秘钥 S, 使用秘钥 S 对加密数据进行还原
0-RTT（0 Round-Trip Time）
- 如果是复用连接的情况下，只需要复用之前的链接和config配置，就能直接进行传输数据
- 0-RTT 特性就无需再次握手，而是直接将加密数据进行发送。这对于移动应用、网页加载速度和实时通信非常重要，因为它可以加速用户体验。
无队头阻塞的多路复用
- 多路复用是 QUIC 的另一个核心特性，旨在解决传统 HTTP/1.1 和 HTTP/2 中存在的队头阻塞问题。在传统的 HTTP 中，如果某个请求的响应出现延迟或丢失，它将阻塞后续请求的处理，从而导致页面加载速度变慢。
- QUIC 允许多个逻辑数据流通过单个连接并行传输。每个数据流都有其独立的流量控制和优先级，这意味着一个数据流的延迟不会影响其他数据流。这提高了网络效率，允许快速响应多个请求，从而改善了用户体验。这对于现代网站、应用程序和多媒体流式传输非常重要。
无歧义重传
- 无歧义重传是 QUIC 的重要特性，用于确保数据的可靠传输。在不稳定的网络环境中，数据包可能会丢失或损坏，因此需要一种机制来恢复丢失的数据而不引入重复数据。
- QUIC 使用序列号来唯一标识数据包，并在接收方接收到数据包后发送确认。如果发送方没有收到确认，它会重新发送数据包，但只会重传丢失的数据包。这种机制确保了可靠的数据传输，而不会引入不必要的重传，从而提高了效率。
- 此外，QUIC 还支持拥塞控制，它可以根据网络条件调整数据包的发送速率，以避免网络拥塞。这有助于保持网络的稳定性和性能。
QUIC 的缺点
增加了遭受攻击的脆弱性
QUIC协议更容易受到分布式拒绝服务（DDoS）攻击的威胁。因为它是无连接的，不需要像TCP那样进行三次握手，攻击者更容易发起反射和放大攻击，通过伪造源IP地址来淹没目标服务器，使其不可用。QUIC的无连接性使其更难以进行流量控制和访问控制，从而增加了DDoS攻击的可能性。
兼容性问题
QUIC协议相对较新，可能与某些旧设备、网络设备或防火墙不兼容。一些应用程序需要精确控制网络行为，而QUIC的新特性可能不适用于所有用例。因此，在部署QUIC时，需要考虑与现有基础设施和设备的兼容性问题。
传输速率较低
尽管QUIC被设计为提供更快速和高效的数据传输，但它的传输速率可能受到加密和身份验证机制的影响。QUIC在数据包传输方面增加了额外的开销，这可能导致较小数据包的传输速率较低，尤其是在高延迟网络中。
故障排除困难
与TCP相比，使用QUIC进行网络故障排除可能更加复杂。由于QUIC的加密和身份验证功能，诊断与数据包丢失、网络拥塞或性能问题相关的问题可能需要更高级的网络监控工具和专业知识。解决问题的难度可能增加，因为数据包内容和流量可能不可见。
需要保持最新状态
QUIC仍然处于不断发展和演进的阶段，因此可能会发生协议规范的更改和更新。使用QUIC的组织需要及时了解最新的开发和更新，以确保协议的实现始终保持最新状态，以获得最佳性能和安全性。
实验数据曲线：
- 在网络良好的情况下，有效数据的传输量 QUIC 是低于 TCP 的，因为加密过程是需要花费时间的
- 在网络20%丢包率的情况下，有效数据的传输量 QUIC 明显高于 TCP。
