详解 QUIC 与 TCP 对比：为何 QUIC 更胜一筹？

引言

在过去的三十年里，HTTP（超文本传输协议）一直是互联网的支柱。我们可以通过 HTTP 浏览网页、下载文件、流式传输电影等。这一协议随着时间的推移已经得到了重大改进。

HTTP 协议是一个应用层协议，它基于 TCP（传输控制协议）工作。TCP 协议有若干限制，导致 Web 应用响应较慢。

谷歌开发了一种名为 QUIC 的颠覆性传输协议，以克服 TCP 的缺点。QUIC 几年前被标准化，并加入到了 IETF（互联网工程任务组）。

近几年来，采用 QUIC 的公司数量呈指数增长。大多数技术公司，如谷歌、Facebook、Pinterest 等，已经开始采用在传输层使用 QUIC 的 HTTP/3.0。这些公司已经看到了其网站在使用 HTTP/3.0 和 QUIC 后性能的显著提升。

让我们开始我们的旅程，了解 QUIC 将如何取代 TCP。我们首先将了解 TCP 和 UDP 的一些基本网络概念。之后，我们将回顾 HTTP 的发展历程，以及每个版本是如何克服前一版本的限制的。然后我们将看看 QUIC 是什么，以及它是如何工作的。我们将探讨为什么 QUIC 比 TCP 具有更高的性能。

TCP 和 UDP 是如何工作的？

TCP（传输控制协议）和 UDP（用户数据报协议）是传输层协议。这些协议管理着来自任何电子设备的网络数据包的流动。让我们详细了解这两种协议是如何工作的。

TCP

TCP 是一种基于连接的协议。客户端与服务器建立连接后发送数据。TCP 连接通过一种称为三次握手的机制建立。下图说明了三次握手过程：

TCP 三次握手过程

该过程包括三个步骤：

1. SYN - 客户端向服务器发送一个 SYN 数据包。
2. ACK - 收到 SYN 后，服务器通过 ACK 数据包向客户端发送确认。
3. SYN-ACK - 客户端收到服务器的 ACK 数据包后，最终通过 SYN-ACK 向服务器发送确认。

TCP 是一种有状态且可靠的协议。它保证了一台设备到另一台设备的所有数据包的传递。此外，它允许客户端和服务器使用同一个连接进行通信。

UDP

UDP 是一种无连接协议。与 TCP 不同，客户端与服务器之间没有三次握手。客户端发送数据包给服务器，不等待服务器的确认。

UDP 不保证 100% 的数据包传递。数据包可能会丢失，可能不会到达另一台设备。UDP 不像 TCP 那样可靠。

由于没有初始握手，UDP 比 TCP 快得多。出于性能考虑，UDP 主要用于流数据的应用，如音乐/视频。

TCP 与 UDP 对比模因

到目前为止，我们已经了解了 TCP 和 UDP 协议的工作原理。现在让我们探索 HTTP 协议，它是一个应用层协议。

HTTP 的发展历史

HTTP 的第一个版本是 1989 年由 Tim Berners-Lee 在 CERN 开发的。从那时起，这个协议经历了多次优化和性能改进。大多数现代设备使用 HTTP 1.1/HTTP 2.0 和 HTTP 3.0。我们将回顾 HTTP 的历史，并了解该协议经历的主要变化。

HTTP/1.0

在最初的 HTTP/0.9 版本之后，HTTP/1.0 开始支持头部、请求体、txt 文件等。客户端每次从服务器获取数据时必须创建一个 TCP 连接。这导致了建立连接的资源大量浪费。

HTTP/1.1

此协议增加了在客户端和服务器之间重用现有 TCP 连接来获取新数据的支持。这是通过 HTTP 头 部的 keep-alive实现的。

如果客户端想要获取 10 个 Javascript 文件，则它会与服务器建立一次连接。然后，它会重用同一连接并获取这 10 个文件，而不是为每个文件创建一个新连接。

这减少了资源浪费并改善了性能，因为它避免了创建冗余连接。然而，一个主要的缺点是称为队头阻塞的问题。

让我们通过一个例子来理解这个概念。如上图所示，你有三个文件——图片、文本和视频。视频文件的大小较大，传输所需时间更长。由于视频文件需要更长时间，它将阻止图像和文本文件的发送。

HTTP/2.0

HTTP 2.0 通过多路复用解决了 队头阻塞 问题。通过多路复用，多个文件可以通过同一个 TCP 连接发送。

这结果提升了性能并在应用层解决了队头阻塞问题。然而，在 TCP 层面，如果发生数据包丢失，则必须等待数据包重传。

多路复用解决方案在数据包丢失的情况下并未像预期那样工作。事实上，如果数据包丢失超过 5%，HTTP 1.1 的表现会优于 HTTP 2.0。队头阻塞问题从应用层转移到了传输层。

下图说明了单个数据包丢失导致多个流延迟的情况：

当一个数据包丢失时，TCP 会将后续数据包存储在其缓冲区中，直到收到丢失的数据包。然后，TCP 使用重传来获取丢失的数据包。HTTP 无法看到 TCP 的重传。因此，在这种情况下，不同的流会看到传输的延迟。

什么是 QUIC？

在过去的几节中，我们看到 TCP 有一些固有的限制，例如三次握手和队头阻塞。这些限制可以通过增强 TCP 或用新协议替换 TCP 来解决。

尽管增强 TCP 听起来很简单，但 TCP 存在于与操作系统紧密结合的最底层。简单来说，TCP 的代码存在于内核层而不是用户空间。考虑到庞大的设备数量，要在内核空间实施更改可能需要很长时间才能影响到所有用户。

因此，谷歌提出了一种新的协议 QUIC，作为 TCP 的替代品。与 TCP 一样，QUIC 也是一个传输层协议。然而，它位于用户空间而不是内核空间。这使得它比 TCP 更容易更改和增强。

QUIC 基于 UDP 工作。它通过使用 UDP 来克服 TCP 的限制。它只是在 UDP 之上增加了一个层或包装器。这个包装器添加了 TCP 的特性，如拥塞控制、数据包重传、多路复用等。它内部使用 UDP，并在其上添加了 TCP 的最佳特性。

既然我们现在了解了 QUIC 的基本知识，让我们深入了解这个协议的工作方式。

QUIC 是如何工作的？

QUIC 握手

QUIC 基于 UDP，并且无需经历三次握手过程。三次握手过程增加了额外的开销并增加了延迟。因此，QUIC 通过减少连接延迟来提高性能。

在 TCP 的情况下，用于 TLS 的额外握手也会增加延迟。QUIC 在单个调用中结合了 TLS 握手和 QUIC 握手。通过优化握手过程，它提高了性能。

可靠性

你可能会想：“既然 QUIC 基于 UDP，数据包会不会丢失呢？”答案是否定的。QUIC 在 UDP 堆栈上增加了可靠性。例如，如果服务器没有从客户端收到第 5 个数据包，协议将检测到这一点，服务器将要求客户端重新发送相同的数据包。

多路复用

与 TCP 类似，QUIC 也实现了多路复用。客户端可以同时使用单个通道传输多个文件。QUIC 为每个流（传输的文件）创建一个 UUID。它使用 UUID 来识别流。然后，多个流通过一个单一通道发送。

下图说明了 QUIC 中多路复用的工作机制：

QUIC 中的多路复用

QUIC 通过其多路复用也解决了 TCP 面临的队头阻塞问题。如果一个流遭受数据包丢失，仅该流会受到影响。QUIC 中的流是独立的，不会相互影响。

安全性

此外，QUIC 还支持 TLS 1.3（传输层安全）。这保证了数据的安全性和保密性。TLS 加密了 QUIC 协议的大部分，如数据包编号和连接关闭信号。

为什么选择 QUIC？

• 减少延迟 - 通过结合 TLS 握手和连接设置，QUIC 最小化了延迟。这也被称为 0-RTT（零延迟请求）。它结果在更快的连接建立和提高了 Web 应用的性能。
• 多路复用 - 通过多路复用，QUIC 可以通过单一通道发送多个数据流。这对下载多个文件（如图片、JavaScript、CSS 等）的客户端应用程序非常有帮助。
• 连接迁移 - 使用 QUIC，您可以在不中断的情况下从一个网络接口切换到另一个（例如从 WiFi 切换到移动数据）。这对移动设备来说很重要，提升了用户体验。
• 提升安全性 - QUIC 运作于 TLS 1.3 之上，提供更好的安全性。此外，它还加密了协议的大部分内容，与仅加密 HTTP 负载的 TCP+TLS 相比，它对安全攻击具有更高的抵抗力。
• 广泛支持 - 自从它推出以来，它的采纳率一直在增长。这进一步加强了其有效性。

HTTP/3 和 QUIC

HTTP/3 是超文本传输协议（HTTP）的最新版本。它在内部使用 QUIC 而不是 TCP。它旨在为现代 Web 提供一个更高效和安全的基础。它具有 QUIC 提供的所有好处。

HTTP/3 由 IETF 标准化。今天，大部分互联网流量都依赖于 HTTP/3。

从上图可以看出，采用率飙升至 30%，并且正逐渐超过 HTTP/1.1。随着采用率的增长，HTTP/3.0 将在未来几年逐渐超过 HTTP/2.0。

结论

自 HTTP 三十年前问世以来，互联网已经取得了长足的进步。HTTP的演进使在线体验变得更加高效和响应迅速。随着现代应用的不断增长需求，我们意识到了底层协议如 TCP 的固有限制。

Google 开发了变革性的协议 QUIC。它利用 UDP 并解决了 TCP 的所有缺陷。减少延迟、多路复用、增强安全性和连接迁移是 QUIC 的一些显著特征。QUIC 带来的创新解决了队头阻塞等问题。

像谷歌和 Facebook 这样的大型技术公司通过在 HTTP/3 中采用 QUIC，看到了性能的显著提升。随着采用率的上升和支持的增加，HTTP/3 将成为互联网通信的标准。在未来几年内，互联网将演变并过渡到 HTTP/3，以实现更高的效率、可靠性和性能。

• 源于：https://engineeringatscale.substack.com/p/how-quic-is-displac...