HTTP/3：基于UDP的新HTTP协议

vlambda
2021-08-26

HTTP/3：基于UDP的新HTTP协议

认知计算与云安全

在不久的将来，认知计算时代一定会彻底走入我们的生活，有兴趣入行未来前沿产业的朋友，可以关注我们，及时获取人工智能、大数据、云计算和物联网的前沿资讯和基础知识，让我们一起携手，引领人工智能的未来！

24篇原创内容

Official Account

截至2021年5月，HTTP/3协议仍是互联网草案，但谷歌、微软或Facebook等公司已经使用它来加速网络。根据W3Techs上关于HTTP/3使用的数据，大约19%的网站已经支持 HTTP/3。

HTTP/3 协议是超文本传输协议 (HTTP) 的新版本，基于 UDP 协议。它以前被称为 HTTP-over-QUIC 。网络协议 QUIC 最初由 Google 开发，将取代 HTTP/2 。 HTTP/3 的开发始于多年前，其目标是通过对数据传输方式进行一些重要更改来加快 Internet 速度。

HTTP/3受益于UDP协议的特性，并在TCP层定义了以前HTTP版本中的许多新特性。这允许消除互联网基础设施中存在的限制。HTTP/1.1和HTTP/2在传输层使用TCP，而HTTP/3使用 QUIC，旨在解决HTTP/2关于下载线性进展的主要问题之一。

尽管HTTP/2由于多路复用缓解了“首行阻塞”问题，但它仍然受到TCP的限制。因为，尽管允许使用唯一的TCP连接进行多次传输，但当其中一个丢失数据包时，整个连接会在等待TCP重新传输丢失的数据包时停止。HTTP/3不受此阻塞问题的限制，这要归功于它与无连接UDP协议的集成。

通过原生提供多路复用，QUIC允许丢失的数据包仅影响那些数据丢失的传输。因此，QUIC连接中的新流不需要等待其他流完成。此外，还消除了TCP握手开销，因此减少了延迟。关于可靠性，QUIC没有包含TCP协议的一些特性，但是在UDP层之上弥补了它，提供了数据包的重传、排序等功能。

一、传输层：TCP与UDP

1.1 TCP：传输控制协议

TCP是传输控制协议的缩写。该协议位于Internet协议(IP)层之上。TCP是许多Internet 协议和服务的基础，除其他外，它负责：

为网络、文件传输等提供必要的可靠性。
建立多步连接，保证数据包顺序，提供丢包重传。
提供用于错误检测的校验和计算。

然而，在可靠性方面，TCP协议也有一个重要的限制：确保正确传递信息所需的所有往返的开销。正因为如此，TCP成为了提高速度的瓶颈。尽管HTTP/2在这方面提供了一些改进，稍后会解释。

该协议由于深度集成到操作系统、固件等中而没有发生重大变化，修改它并不是一件容易的事。

1.2 UDP：用户数据报协议

UDP是用户数据报协议的首字母缩写。UDP是一种基于数据报的无连接协议；没有交货保证。信息传递、数据完整性等都委托给应用层。UDP协议主要用于VoIP、DNS、DHCP和 BOOTP等应用。UDP数据包格式规范是最小的。它的标题包括：

源和目的端口，
包头和包数据的长度（以字节为单位），
和校验和数据完整性验证（可选IPv4和强制性的IPv6的）。

UDP协议规范被广泛使用。因此，任何实质性的改进还需要对连接到Internet的设备的固件和操作系统进行重大更改。

1.3 QUIC网络协议

QUIC由Google的Jim Roskind于2012年设计，是一种基于UDP传输层的网络协议。Google 的QUIC版本只专注于HTTP传输，使用HTTP/2的语法。然而，在标准化方面，IETF走得更远。

QUIC重新定义了“用户空间”中网络层、通信、可靠性特性和安全特性的限制。这允许避免升级互联网范围系统的内核的需要。尽管如此，UDP的使用给QUIC和HTTP/3带来了优点和缺点。挑战之一是CPU负载，根据一些估计，与HTTP/2相比，QUIC负载可以翻倍。这是因为操作系统和软件没有针对使用UDP进行优化；因为TCP长期以来一直是主要协议。

此外，对于QUIC连接，必须使用TLS；以阻止中间设备更改或检测流量。QUIC流有一个标识谁开始传输的ID，它们通过单向或双向QUIC连接发送。

二、HTTP/3的实现

在我们深入研究HTTP/3之前，让我们快速浏览一下HTTP多年来的演变，以便更好地理解为什么需要HTTP/3。

2.1 HTTP的演进

在HTTP/1.0中，为客户端和服务器之间的每个请求/响应交换创建一个新的TCP连接，这意味着所有请求都会产生延迟损失，因为TCP和TLS握手在每个请求之前完成。

更糟糕的是，TCP并没有在连接建立后尽快发送所有未完成的数据，而是强制执行一个称为“慢启动”的预热期，这允许TCP拥塞控制算法确定可以传输的数据量在网络路径发生拥塞之前的任何给定时刻，并避免用它无法处理的数据包淹没网络。但是因为新连接必须经过慢启动过程，所以它们不能立即使用所有可用的网络带宽。

随着网络的发展，随着每个网站所需的资源（CSS、JavaScript、图像等）数量逐年增加，浏览器在获取和呈现网页时需要越来越多的并发性。但由于HTTP/1.1一次只允许客户端进行一次HTTP请求/响应交换，因此在网络层获得并发的唯一方法是并行使用多个到同一源的TCP连接，从而失去了大部分的好处保持活动连接。虽然连接仍会在一定程度上（但较少）被重用，但我们又回到了原点。

最后，十多年后，出现了SPDY，然后是HTTP/2，其中引入了HTTP“流”的概念：一种抽象，允许HTTP实现将不同的HTTP交换并发复用到同一个TCP连接上，允许浏览器以更有效地重用TCP连接。

但是，再一次，这不是灵丹妙药！HTTP/2解决了最初的问题——单个TCP连接的低效使用——因为多个请求/响应现在可以通过同一连接同时传输。但是，即使丢失的数据仅涉及单个请求，所有请求和响应也会同样受到丢包（例如由于网络拥塞）的影响。这是因为虽然 HTTP/2层可以在不同的流上隔离不同的HTTP交换，但TCP不知道这种抽象，它所看到的只是一个没有特定含义的字节流。

TCP的作用是以正确的顺序将整个字节流从一个端点传送到另一个端点。当携带其中一些字节的TCP数据包在网络路径上丢失时，它会在流中产生一个间隙，并且TCP需要在检测到丢失时通过重新发送受影响的数据包来填充它。这样做时，丢失的字节之后的任何成功传递的字节都不能传递给应用程序，即使它们本身没有丢失并且属于完全独立的HTTP请求。因此，它们最终会被不必要地延迟，因为TCP无法知道应用程序是否能够在没有丢失位的情况下处理它们。这个问题被称为“首行阻塞”。

2.2 HTTP/3用武之地

HTTP/3没有使用TCP作为会话的传输层，而是使用QUIC，这是一种新的Internet传输协议，它在传输层引入流作为一等公民。QUIC流共享相同的QUIC连接，因此不需要额外的握手和慢启动来创建新的，但QUIC流是独立传递的，因此在大多数情况下，影响一个流的丢包不会影响其他流。这是可能的，因为QUIC数据包封装在UDP数据包之上。

与TCP相比，使用UDP具有更大的灵活性，并使QUIC实现完全存在于用户空间中——协议实现的更新不像TCP那样与操作系统更新相关联。使用QUIC，HTTP级别的流可以简单地映射到QUIC流之上，以获得HTTP/2的所有好处，而不会出现首行阻塞。

QUIC还结合了典型的3次TCP握手和TLS1.3的握手。结合这些步骤意味着默认提供加密和身份验证，并且还可以更快地建立连接。换句话说，即使在HTTP会话中的初始请求需要新的 QUIC连接时，数据开始流动之前产生的延迟也低于使用TLS的TCP。

但是为什么不在QUIC之上使用HTTP/2，而不是创建一个全新的HTTP修订版呢？毕竟，HTTP/2还提供了流复用功能。事实证明，它比那要复杂一些。

虽然某些HTTP/2特性确实可以很容易地映射到QUIC之上，但并非所有特性都如此。特别是HTTP/2的头压缩方案HPACK，在很大程度上取决于将不同的HTTP请求和响应传送到端点的顺序。QUIC强制执行单个流中字节的传递顺序，但不保证不同流之间的排序。

这种行为需要创建一个新的HTTP头压缩方案，称为QPACK，它解决了这个问题，但需要更改HTTP映射。此外，HTTP/2提供的一些功能（如每个流的流量控制）已经由QUIC本身提供，因此它们从HTTP/3中删除，以消除协议中不必要的复杂性。

认知计算与云安全

24篇原创内容

Official Account

vlambda博客
学习文章列表