什么是 QUIC 和 HTTP/3？
快速 UDP 互联网连接 (QUIC)是一种通用传输层协议，旨在通过其灵活性、内置安全性、更少的性能问题和更快的采用率来取代传输控制协议 (TCP)。 QUIC 最初由 Google 开发，使用用户数据报协议 (UDP) 作为在客户端和服务器之间移动数据包的低级传输机制。 值得注意的是，QUIC 还将传输层安全性（TLS）作为一个整体组件，而不是像 HTTP/1.1 和 HTTP/2 那样作为附加层。
HTTP/3 基于 QUIC，是超文本传输协议 (HTTP) 的第三个主要版本，并于 2022 年被采纳为IETF 标准。 QUIC+HTTP/3 的创建是为了解决 TCP 固有的限制，这些限制限制了性能和用户体验。
API 是应用的“公众面孔”，揭示其执行的功能和可以提供的信息，并定义正确的请求格式。 当开发人员为应用创建并公开 API 时，它允许其他应用与其通信。
在许多情况下，API 可以节省开发人员宝贵的时间，因为它们使常用功能随时可用。 开发人员不需要重复现有应用的功能，而是可以通过调用现有应用程序的 API 将功能集成到自己的应用中。
HTTP 传输堆栈的高级概述
QUIC 的目标是为 HTTP/3 提供高性能、高可靠性和高安全性的传输协议（尽管 QUIC 也适用于非 HTTP 流量）。
如果您对 QUIC 完全不了解，我们建议您观看下面的介绍视频。
UDP、TCP 和 TLS
UDP 是一种简单、轻量级的协议，不需要像 TCP 那样进行复杂的三次握手来建立第一个连接。 这种简单性使得 UDP 快速且无连接，但这也意味着与 TCP 相比，它缺乏可靠和安全通信所必需的功能。
QUIC 的独特之处在于它融合了 UDP 和 TCP 协议的优点。 虽然它是无连接的并且利用 UDP 作为低级传输协议来减少连接和传输延迟，但由于它重新实现了 TCP 的连接建立和丢失检测功能（从而保证数据包的传输），因此它在较高层是面向连接的。 它负责识别丢失的数据并完成重新传输的任务，以确保无缝的用户体验。
QUIC 还将 TLS 作为一个整体组件，而不是像 HTTP/1.1 和 HTTP/2 那样作为附加层。 这种合并可确保消息默认被加密。
下图描述了 QUIC 网络的基本结构。 如图所示，包含 HTTP/3 请求、响应或任何应用数据的逻辑对象是 QUIC流。 为了在网络端点之间传输，QUIC 流被包裹在多个逻辑层内。
QUIC 流的剖析
从外到内，逻辑层和对象是：
- UDP 数据报 - 包含指定源端口和目标端口的标头（以及长度和校验和数据），后跟一个或多个 QUIC 数据包。 数据报是通过网络从客户端传输到服务器的信息单位。
- QUIC 数据包 - 包含一个 QUIC 头和一个或多个 QUIC 帧。
- QUIC 标头——包含有关数据包的元数据。 标头有两种类型：
- 长标头，在建立连接时使用。
- 短标头，在连接建立后使用。 它包含（除其他数据外）连接 ID、数据包号和密钥阶段（用于跟踪哪些密钥用于加密数据包，以支持密钥轮换）。 对于特定的连接和密钥阶段，数据包编号是唯一的（并且始终增加）。
- 帧 - 包含类型、流 ID、偏移量和流数据。 流数据分布在多个帧中，但可以使用连接 ID、流 ID 和偏移量进行组装，以正确的顺序呈现数据块。
- 流——单个 QUIC 连接内的单向或双向数据流。 每个 QUIC 连接可以支持多个独立流，每个流都有自己的流 ID。如果包含一些流的 QUIC 数据包丢失，这不会影响丢失数据包中未包含的任何流的进度（这对于避免 HTTP/2 遇到的队头阻塞至关重要）。 流可以是双向的并可由任一端点创建。
TLS 握手在客户端和服务器之间提供了安全的连接。 QUIC 提供的加密需要TLS v1.3 。 如下图所示，QUIC 保留了提供加密密钥的 TLS“内容层”，但用自己的传输机制取代了“记录层”。
QUIC 还依赖 TLS 来对安全性和性能至关重要的参数进行身份验证和协商。 这两个协议不是严格的分层，而是协作的： QUIC 使用 TLS 握手建立安全连接，而 TLS 使用 QUIC 提供的可靠性、有序传递和记录层。
从高层次上看，TLS 和 QUIC 组件之间有两种主要交互：
- TLS 组件通过 QUIC 组件发送和接收消息，QUIC 为 TLS 提供可靠的流抽象。
- TLS 组件为 QUIC 组件提供了一系列更新，包括（a）要安装的新数据包保护密钥和（b）状态变化，如握手完成、服务器证书等。
QUIC TLS 的 HTTP/3 支持选项
QUIC TLS 是专为 QUIC 协议设计的 TLS 变体。 目前，对于寻求 QUIC TLS 中 HTTP/3 支持的用户，有两个选项：
- OpenSSL QUIC 实现– OpenSSL 目前正致力于自行实现完整的 QUIC 堆栈。 此次开发将封装实现中的所有 QUIC 功能，使得 HTTP/3 用户可以更轻松地使用 OpenSSL TLS API，而不必担心 QUIC 特定的功能。
- 支持BoringSSL QUIC API 的库 – 各种 SSL 库（如 BoringSSL、quicTLS 和 LibreSSL（最初是 OpenSSL 的一个分支））现在通过实现 BoringSSL QUIC API 提供 QUIC TLS 功能。这是目前想要使用 HTTP/3 的用户的唯一选择，因为 OpenSSL QUIC TLS 实现尚未准备就绪。
QUIC+HTTP/3 旨在通过减少延迟和改善不可靠网络上的数据传输来提高 Web应用的性能。 它们的优点包括：
- 减少延迟——TCP 等传统协议由于其连接设置过程而遭受延迟。 QUIC+HTTP/3的多路复用能力使得它们能够更高效的建立连接，从而降低建立连接和传输数据的延迟。
- 更快的连接建立——QUIC+HTTP/3 将 TLS 握手和加密设置结合为一个步骤，减少了建立安全连接所需的往返次数。
- 多路复用——通过处理单个连接中的多个数据流，QUIC+HTTP/3 可以更有效地利用网络资源，并有助于避免队头阻塞问题，在传统 TCP 连接中，一个慢速流可能会延迟其他流。
- 改进的错误纠正——QUIC 采用前向纠错技术，可以帮助恢复丢失的数据包而无需重新传输，从而减少数据包丢失对性能的影响。
- 减少数据包丢失的影响——UDP 是无连接的，允许更快的传输，而不需要 TCP 进行严格的错误检查。 这在网络条件不太稳定的情况下尤其有利。
- 自适应拥塞控制——QUIC+HTTP/3 的设计比 TCP 的拥塞控制更高效、响应更快，从而可以在不同的网络环境中实现更好的性能。
- 迁移支持——QUIC+HTTP/3 可以在不同的网络连接之间无缝过渡（例如从 Wi-Fi 切换到蜂窝网络），而不会影响应用程序的性能。
- 提高安全性——QUIC+HTTP/3 默认集成加密，增强数据传输的安全性和隐私性。 这种加密可防止窃听和篡改传输中的数据。
- NAT 遍历——QUIC+HTTP/3 对 UDP 的使用可以帮助进行网络地址转换 (NAT) 遍历，使得在传统 TCP 连接可能遇到问题的情况下更直接地建立连接。
- 不断发展——由于 QUIC+HTTP/3 被设计为通过软件实现和更新，而不是需要改变底层网络基础设施，因此它们可以更快地更新和改进，以适应不断变化的网络条件和安全问题。
探索以下资源以了解 NGINX 的 QUIC+HTTP/3 实现以及使用 QUIC+HTTP/3 实现更快、更高效通信的其他方法。