HTTP/3 详解：深度长文

IETF 的 QUIC 在技术上与 Google 的 QUIC 非常不同，你看由于 TCP 是一个更老的协议且并非仅仅为了加载网页而设计的它不知道 A、B或 C， 例如他们都知道 CIDs K、C 和 D 实际上都映射到连接 X，例如DNS、SSH、SMB、RTP 等都可以通过 QUIC 运行，这可能使得 QUIC 在高吞吐量场景下速度更慢如我们将在第2部分中看到， QUIC 支持多个独立字节流， 让我们仔细看看这些点，。

如果这些实现过于陈旧、缺乏更新或存在漏洞那么这些扩展就无法实用，因此我们可以在等待 B 丢失的数据时开始处理 A 和 C 对吗 遗憾的是情况并非如此因为重传逻辑发生在 TCP 层而 TCP 并不知道 A、B 和 CTCP 反而认为 X 文件的一部分已经丢失因此它认为必须阻止 X 其余数据的处理直到缺口被填补。

所以如果这四个参数中的任何一个发生变化连接将变得无效需要重新建立包括一个新的握手，**这些说法是错误的，HTTP/3 并不是因为我们将 TCP 替换为 UDP 就神奇地比 HTTP/2 更快，这个“协议栈”中的每个协议都有其自己的功能和责任见下图。

然而客户端和服务器之间还有许多其他设备它们也有自己的  TCP  代码例如防火墙、负载均衡器、路由器、缓存服务器、代理等，这不仅改善了其安全性和隐私特性还有助于其部署和演进，首先正如已经讨论的QUIC 几乎完全加密意味着如果我们想部署更新版的 QUIC我们只需要更新端点客户端和服务器而不是所有中间设备，例如如果设备是防火墙它可能被配置为阻止所有包含未知扩展的流量，如下图所示，因此这些连接有时需要重新启动导致一些停机时间， 关键点 这里的关键点是在 TCP 中连接由 四个参数 定义当端点改变网络时这些参数可能会改变。

换句话说没有办法不使用 TLS 使用 QUICQUIC以及随之 HTTP/3始终是完全加密的。

随着时间的推移我们试图发展和升级 TCP 以改善这些问题甚至引入新的性能特性， 这可能会让你感到困惑我刚才不是说 CID 在跨网络时应该保持不变吗好吧那是一个简化，ISP 和中间网络可能会阻止它因为平均延迟和数据包丢失百分比等指标不再容易获得使得检测和诊断问题更加困难， 最后虽然不是 QUIC 本身的真正要求但大多数实现目前是在“用户空间”完成的与通常在“内核空间”完成的TCP相反， 协议相互之间的“分层”是为了允许轻松重用它们的功能，我们选择分拆工作首先“修复”HTTP/1.1导致现在的 HTTP/2， 改善这种情况是 HTTP/2 的主要目标之一，他们说 HTTP/3 更快因为就像 UDP 一样它不建立连接也不等待数据包重传，例如 TCP  要求进行一个“握手”来建立新连接，正如我们所说HTTP/2 也包括在单个TCP连接上运行多个流的概念。

结论  让我们总结一下我们在这部分中学到的内容， 使用 CID 还有其他要克服的挑战， QUIC 使用连接 ID， 然而这样做将导致我们在尝试演进 TCP 时遇到的同样问题所有设备都必须首先更新以便识别并允许 QUIC。

使用帧的一个非常有用的副作用然而是在未来定义新的帧类型作为 QUIC 扩展将非常容易， 假设第三个 TCP 数据包丢失了包含文件 B 的第一批数据但所有其他数据都被送达， 公司可能希望在其防火墙上阻止它因为检测不需要的流量变得更加困难。

你可以说演进 TCP 已经变得实际上不可能了。

QUIC 使用 TLS 对每个单独的数据包进行加密而 TLS-over-TCP 可以同时加密多个数据包， QUIC 的新方法为一系列性能改进铺平了道路但它们的潜在收益比通常在 QUIC 和 HTTP/3 的文章中传达的更为细微， QUIC 可以更容易地演进。

毕竟不仅仅是 TCP 存在问题， TCP 是提供关键服务如 可靠性和顺序交付 给其他协议如 HTTP的主要协议， 关键点  这里的关键点是 TCP 从未设计为通过单个连接传输多个独立文件。

实践中UDP 主要用于实时流量该流量以高速率更新因此数据包丢失后缺失的数据很快就会过时例如实时视频会议和游戏。

与 TCP 不同QUIC 密切了解它正在多路复用多个、独立的字节流。

为什么我们需要 HTTP/3 我经常遇到的一个问题是“为什么在 HTTP/2在 2015 年才标准化之后不久我们就需要 HTTP/3”这确实让人感到奇怪直到你意识到我们首先并不真的需要一个新的  HTTP  版本而是需要对底层的传输控制协议TCP进行升级， 让我们来看看两者的区别