来看看HTTP3——为什么QUIC比HTTP更快


介绍

在过去的三十年里,HTTP(超文本传输协议)一直是互联网的支柱。我们能够浏览网页、下载文件、流媒体电影等,都是因为HTTP。该协议多年来不断发展,并见证了重大改进。

HTTP协议是一种应用层协议,工作在TCP(传输控制协议)之上。TCP协议存在若干限制,导致网络应用响应速度较慢。

为了克服TCP的缺点,Google 开发了一种革命性的传输协议,称为QUIC。QUIC几年前被标准化,并加入了IETF(互联网工程任务组)。

在过去的几年里,QUIC的采用率呈指数级增长。大多数科技公司如谷歌、Facebook、Pinterest等,已经开始采用使用QUIC作为传输层的HTTP/3.0。这些公司在使用HTTP/3.0和QUIC后,网站性能显著提升。

TCP和UDP是如何工作的?

TCP(传输控制协议)和UDP(用户数据报协议)是传输层协议。这些协议用于处理互联网数据包在电子设备之间的流动。接下来,让我们看下两个协议究竟是如何工作的。

TCP

TCP是一种基于连接的协议。客户端与服务器建立连接后再发送数据。TCP连接会通过一种被称为“三次握手”的机制建立。下面的图展示了三次握手的过程: quic01.png 这个过程包括三个步骤:

  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: quic02.jpg 到目前为止,我们已经了解了TCP和UDP协议是如何工作的。现在让我们探索一下HTTP协议,它是一种应用层协议。

HTTP的发展

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

HTTP/1.0

在最初的HTTP/0.9版本之后,HTTP/1.0开始支持header、body、文本文件等。客户端每次使用HTTP从服务器获取数据时,都必须创建一个TCP连接。这导致了大量资源浪费在建立连接上。

HTTP/1.1

该版本的协议增加了在客户端和服务器之间复用现有TCP连接以获取新数据的能力。这是通过HTTP头部的keep-alive实现的。

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

这减少了资源浪费并提高了性能,因为不需要创建冗余连接。然而,一个主要的缺点是所谓的队头阻塞(Head of the line blocking)问题。

下图展示了队头阻塞问题。 quic03.png

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

HTTP/2.0

HTTP 2.0通过多路复用解决了队头阻塞问题。借助多路复用,可以在同一个TCP连接上发送多个文件。 quic04.png 这带来了性能提升,并在应用层解决了队头阻塞问题。然而,在TCP层,如果发生数据包丢失,则必须等待数据包重传。

在数据包丢失的情况下,多路复用解决方案没有如预期那样工作。事实上,如果数据包丢失率超过5%,HTTP 1.1的表现比HTTP 2.0反而更好。队头阻塞问题从应用层转移到了传输层。

下图展示了单个数据包丢失如何导致多个流延迟: quic05.png 当一个数据包丢失时,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如何适应网络栈: quic06.png 既然我们已经了解了QUIC的基础知识,接下来让我们深入探讨该协议的工作原理。

QUIC是如何工作的?

QUIC握手

QUIC基于UDP工作,不需要经过三次握手过程。三次握手的过程增加了额外的开销和延迟。因此,QUIC通过减少连接延迟提高了性能。

在TCP的情况下,还有一个用于TLS的额外握手,这会增加延迟。QUIC将TLS握手和QUIC握手结合在一次会话中,从而减少握手次数,提高了性能。

可靠性

你可能会问:“由于QUIC基于UDP,数据包会丢失吗?”答案是否定的。QUIC在UDP之上增加了可靠性。它实现了数据包重传机制,以防未收到必要的数据包。例如:如果服务器没有收到客户端的第5个数据包,协议将检测到这一点,服务器将要求客户端重新发送该数据包。

多路复用

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

下图展示了QUIC中多路复用的工作原理: quic07.png QUIC还通过其多路复用解决了TCP面临的队头阻塞问题。如果一个流出现数据包丢失,只有该流会受到影响。QUIC中的流是独立的,不会相互影响。

安全性

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

为什么选择QUIC?

  • 减少延迟 - QUIC通过将TLS握手与连接建立结合起来,最小化了延迟。这也被称为0-RTT(零往返时间)。它可以更快地建立连接,从而提升Web应用程序的性能。

  • 多路复用 - 通过多路复用,QUIC可以在单个通道上发送多个数据流。这对下载多个文件(如图片、JavaScript、CSS等)的客户端应用程序非常有帮助。

  • 连接迁移 - 使用QUIC,你可以无缝地从一个网络接口切换到另一个(如从WiFi切换到移动数据)。这对移动设备非常重要,提升了用户体验。

  • 改进的安全性 - QUIC基于TLS 1.3,提供了更好的安全性。此外,它还加密了协议的大部分内容,而不像TCP与TLS,只加密HTTP负载。与TCP相比,它对安全攻击更具抵抗力。

  • 广泛支持 - 自推出以来,QUIC的采用率一直在上升。这进一步增强了它的有效性。

HTTP/3和QUIC

HTTP/3是超文本传输协议(HTTP)的最新版本。它内部使用QUIC而不是TCP,旨在为现代网络提供更高效和安全的基础。HTTP/3具备QUIC提供的所有优势。

HTTP/3由IETF标准化。今天,互联网流量的很大一部分依赖于HTTP/3。下图显示了HTTP/3的采用率: quic0.png 从上图可以看出,采用率已经飙升至30%,并逐渐超过HTTP/1.1。按照目前的增长率,HTTP/3将在未来几年逐渐超过HTTP/2。

结论

自HTTP诞生三十多年来,互联网已经走过了漫长的道路。HTTP的演变使得在线体验更加高效和响应迅速。随着现代应用程序需求的增长,我们意识到底层协议(如TCP)的固有限制。

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

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