http3
介绍
在过去的三十年里，HTTP（超文本传输协议）一直是互联网的支柱。由于 HTTP，我们能够浏览网页、下载文件、流式传输电影等。该协议经过多年的发展，并见证了重大的改进。
HTTP协议是一种应用程序协议，工作在**TCP（传输控制协议）**之上。TCP 协议有几个限制，导致 Web 应用程序响应速度较慢。
谷歌开发了一种名为QUIC的改变游戏规则的传输协议，以克服TCP的缺点。 几年前，QUIC被标准化并添加到IETF（互联网工程任务组）中。
在过去几年中，QUIC 的采用呈指数级增长。大多数科技公司，如谷歌、Facebook、Pinterest等，已经开始采 用HTTP/3.0，在传输层面使用QUIC。这些公司通过HTTP/3.0和QUIC看到了其网站性能的显着改善。
让我们踏上我们的旅程，了解 QUIC 将如何取代 TCP。我们将首先介绍TCP和UDP的几个基本网络概念。稍后，我们将研究 HTTP 的演变以及每个版本如何克服上一个版本的局限性。然后，我们将看到 QUIC 是什么以及它是如何工作的。我们将探讨为什么与 TCP 相比，QUIC 具有高性能。
《大规模工程》是一本由读者支持的出版物。要接收新帖子并支持我的工作，请考虑成为免费或付费订阅者。
订阅
TCP 和 UDP 是如何工作的？
TCP（传输控制协议）和 UDP（用户数据报协议）是传输级协议。这些协议管理进出任何电子设备的互联网数据包流。让我们详细了解这两种协议的工作原理。
技术合作计划（TCP）
TCP 是一种基于连接的协议。客户端与服务器建立连接，然后发送数据。TCP 连接是通过称为“三向握手”的机制建立的。下图说明了三向握手过程：-
TCP 3 向握手过程
该过程包括三个步骤：-
- SYN - 客户端向服务器发送 SYN 数据包。
- ACK - 收到 SYN 后，服务器通过 ACK 数据包将确认发送回客户端。
- SYN-ACK - 从服务器接收到ACK数据包后，客户端最终通过SYN-ACK向服务器发送确认。
TCP 是一种有状态且可靠的协议。它保证将所有数据包从一台设备传送到另一台设备。此外，它还允许客户端和服务器使用相同的连接进行通信。
UDP的
UDP 是一种无连接协议。与 TCP 不同，客户端和服务器之间没有三向握手。客户端将数据包发送到服务器，并且不等待服务器的确认。
UDP 不保证 100% 传输数据包。数据包可能会丢失，并且可能无法到达其他设备。UDP 不像 TCP 那样可靠。
由于没有初始握手，因此 UDP 比 TCP 快得多。出于性能原因，UDP 主要用于音乐/视频等流数据应用程序。
这是一个流行的互联网模因，它对 TCP/UDP 进行了挖掘：-
TCP VS UDP 模因
到目前为止，我们已经了解了 TCP 和 UDP 协议的工作原理。现在让我们来探讨一下 HTTP 协议，它是一种应用程序级协议。
HTTP 的演变
HTTP 的第一个版本是由 CERN 的 Tim Berners-Lee 于 1989 年开发的。从那时起，该协议进行了多次优化和性能改进。大多数现代设备使用 HTTP 1.1/HTTP 2.0 和 HTTP 3.0。让我们回顾一下HTTP的历史，并了解该协议所经历的重大变化。
HTTP/1.0
在最初的 HTTP/0.9 版本之后，HTTP/1.0 开始支持头、请求正文、txt 文件等。每次使用 HTTP 从服务器获取数据时，客户端都必须创建 TCP 连接。这导致了建立连接的大量资源浪费。
HTTP/1.1
此协议增加了对重用客户端和服务器之间的现有 TCP 连接以获取新数据的支持。这是在 HTTP 标头的帮助下实现的。keep-alive
如果客户端想要获取 10 个 Javascript 文件，那么它将与服务器建立一个连接。然后，它将重用相同的连接并获取 10 个文件，而不是为每个文件创建一个新连接。
这样可以减少资源浪费并提高性能，因为它避免了创建冗余连接。然而，一个主要的缺点是被称为线头阻塞的问题。
下图说明了线路阻塞问题的头。
线路阻塞的头部
让我们通过一个例子来理解这个概念。如上图所示，您有三个文件 - 图像、文本和视频。视频文件的大小较大，传输时间更长。由于视频文 件需要更多时间，因此会阻止发送图像和文本文件。
HTTP/2.0
HTTP 2.0 通过多路复用解决了*线路阻塞问题。*在多路复用的帮助下，可以通过同一个TCP连接发送多个文件。
HTTP/2.0 中的多路复用
这导致了性能的提升，并解决了应用程序级别的线路头阻塞问题。但是，在TCP层，如果出现数据包丢失，则必须等待数据包重新传输。
在数据包丢失的情况下，多路复用解决方案无法按预期工作。事实上，如果数据包丢失率超过 5%，HTTP 1.1 的性能优于 HTTP 2.0。线路堵塞问题从应用层过渡到传输层。
下图说明了单个数据包丢失如何导致多个流延迟：-
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是如何工作的？
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？
- 减少延迟 - QUIC 通过将 TLS 握手与连接设置相结合来最大程度地减少延迟。这也称为 0-RTT（零往返时间）。它可以更快地建立连接并提高 Web 应用程序的性能。
- 多路复用 - 通过多路复用，QUIC 可以通过单个通道发送多个数据流。它极大地帮助了下载多个文件（即图像、Javascript、CSS 等）的客户端应用程序。
- 连接迁移 - 使用 QUIC，您可以从一个网络接口切换到另一个网络接口（wifi 到移动数据），而不会出现任何故障。这对移动设备很重要，可以改善用户体验。
- 改进的安全性 - QUIC 适用于 TLS 1.3，它提供了更好的安全性。此外，它还对协议的大部分内容进行加密，这与使用 TLS 的 TCP 不同，后者仅加密 HTTP 有效负载。与 TCP 相比，它对安全攻击的抵御能力更强。
- 广泛的支持 - 自成立以来，它的采用率一直在上升。这进一步加强了它的有效性。