浅谈网络 | 应用层之HTTP协议

一些 URL 会更详细地描述资源的位置，比如 http://www.163.com/index.html，其中 /index.html 指定了具体的资源路径。正因为 URL 的格式是统一的，当我们将这样一个字符串输入浏览器地址栏时，浏览器可以按照约定的规则对其进行解析和处理。

这种统一性是互联网高效运作的基础，它不仅让浏览器知道该如何处理地址，还让服务器能够快速找到资源的位置，为用户提供服务。HTTP 协议就是在这种资源定位规则的基础上，为我们提供了访问和传输信息的能力。

HTTP 请求的准备

当我们在浏览器中输入 www.163.com 并按下回车，浏览器首先会将这个域名发送给 DNS 服务器，让它解析为对应的 IP 地址。关于 DNS 的解析过程，其实非常复杂，这部分内容我们会在后续专门讲解 DNS 时详细说明。这里，我们暂时只需要知道最终会得到一个 IP 地址即可。那么接下来是不是直接发送 HTTP 请求呢？

并不是。

HTTP 是基于 TCP 协议的，因此在发送 HTTP 请求之前，需要先建立 TCP 连接。建立连接的过程你应该还记得，我们在第 11 节讲过 三次握手 的流程。

目前大部分使用的 HTTP 协议版本是 HTTP/1.1，它默认启用了 Keep-Alive 功能。这意味着在一次 TCP 连接中，可以复用这个连接来处理多个请求，而不需要每次请求都重新建立和关闭连接。

如果你已经学习过 TCP 的原理，就会知道三次握手和四次挥手的过程其实是比较耗时和复杂的。如果每次请求都需要新建连接，然后做完一件事情就关闭连接，这样的方式无疑会非常浪费资源。启用 Keep-Alive 后，一个 TCP 连接可以支持多次请求，大幅提高了通信效率，同时也减少了系统资源的开销。

所以，在发送 HTTP 请求之前，准备工作包括：

DNS 解析：将域名解析为目标服务器的 IP 地址。
TCP 连接建立：通过三次握手与目标服务器建立可靠的连接。
启用连接复用：利用 HTTP/1.1 的 Keep-Alive 功能，在同一连接中处理多个请求，降低连接建立和断开的成本。

这些准备工作为 HTTP 请求的发送奠定了基础，让浏览器和服务器之间的通信更加高效和可靠。

HTTP 请求的构建

建立了连接以后，浏览器就要发送 HTTP 的请求。

请求的格式就像这样。

https://i-blog.csdnimg.cn/direct/ab4f6e87ee624bb49516ee6c48ae5ce5.png" alt="在这里插入图片描述" />
HTTP 的报文大概分为三大部分。第一部分是请求行，第二部分是请求的首部，第三部分才是请求的正文实体。

第一部分：请求行
在请求行中，URL 可能是类似 http://www.163.com 的地址，版本通常为 HTTP/1.1。在这里需要特别提到的是 HTTP 方法。HTTP 方法有多种类型，不同的方法对应不同的操作语义。

对于访问网页来说，最常用的方法是 GET。顾名思义，GET 就是向服务器请求获取某些资源，比如网页中的页面内容。除了页面，GET 请求也可以返回其他格式的资源，比如一个 JSON 字符串。返回内容的具体格式和内容由服务器端的实现决定。

例如，在云计算中，如果服务器端提供了一个基于 HTTP 协议的 API 来获取所有云主机的列表，那么会通过 GET 方法来请求，服务器返回的可能是一个 JSON 字符串。这个 JSON 字符串包含了一个云主机列表，其中的每一项是单个云主机的信息。

另一种常见的方法是 POST，它用于向服务器发送数据，而不是获取资源。POST 请求通常会将数据放在请求的正文中，正文的格式可以是多种类型，常见的是 JSON。

例如，在支付场景中，客户端需要将“我是谁？我要支付多少钱？我购买的是什么？”这些信息通过 POST 请求发送到服务器。而在云计算中，如果服务器端提供了一个 API 来创建云主机，客户端会使用 POST 方法将创建云主机所需的信息（如 CPU、内存、硬盘大小等）以 JSON 字符串的形式发送给服务器。

还有一种方法是 PUT，用于向指定资源位置上传更新的内容。不过，HTTP 服务器通常不允许直接上传文件，因此 PUT 和 POST 在实际中都会用于向服务器传递数据。二者的区别在于：POST 通常用于 创建资源，而 PUT 则多用于 更新资源。

例如，云主机已经创建完成后，如果需要给这个云主机打上一个标签（如标明它是生产环境或测试环境），可以使用 PUT 方法来更新这个标签。

另外，还有一个常见的方法是 DELETE，顾名思义，用于删除指定的资源。例如，删除某个云主机时，就会调用 DELETE 方法向服务器发送删除请求。

这些方法构成了 HTTP 请求的核心操作，为客户端与服务器之间的通信提供了灵活和规范化的接口。

第二部分：首部字段

在请求行的下面就是 HTTP 的首部字段区域。首部字段以 key:value 的形式存在，用冒号分隔，承载了很多与请求相关的重要信息。

例如，Accept-Charset 指定客户端可以接受的字符集类型，防止服务器返回的数据使用了不兼容的字符集，导致显示乱码的问题。

另一个常见的字段是 Content-Type，用于声明请求正文的格式。比如，在进行 POST 请求时，如果正文是 JSON 格式，就需要将这个字段设置为 application/json，以便服务器正确解析数据。

除了这些基础字段，还需要重点提到缓存。缓存的引入可以极大提升性能，减少重复加载的开销。那么为什么需要缓存呢？主要是为了减少对服务器的压力和提高用户体验。

以浏览商品详情为例，页面中可能包含商品的价格、库存、展示图片和使用手册等信息。其中，图片是静态资源，通常保持较长时间不变，而库存信息可能会随时更新。如果每次刷新页面都重新加载所有资源（包括那些未变化的图片），不仅浪费网络带宽，还会给服务器带来很大压力。

在高并发的系统中，为了优化性能，往往会在业务逻辑处理之前设置一个 接入层，负责处理静态资源请求。接入层的任务是将这些静态资源（如图片和使用手册）缓存下来，避免每次都触发服务端请求。动态数据（如价格和库存）则通过实时接口获取，从而实现数据分层加载，提升效率。

这个架构的图就像这样。
https://i-blog.csdnimg.cn/direct/b803bf848c7544b38b97110b2acfc23f.png" alt="在这里插入图片描述" />
从这张架构图可以看出，客户端的请求会经过多个层次的处理。首先是 DNS 和 CDN，它们的作用是优化资源的分发和加载效率，这部分将在后面的章节详细讲解。而和本节内容关系密切的则是 Nginx 层。

Nginx 如何处理 HTTP 协议？
在这个架构中，Nginx 负责接收和分发 HTTP 请求。如果是静态资源，Nginx 会先查询 Varnish 缓存层。只有当缓存过期时，才会将请求进一步转发到 Tomcat 应用集群 来获取实际数据。

对于缓存的管理，HTTP 头中的 Cache-Control 是一个非常重要的字段。例如：

当客户端的请求头中包含 max-age 指令时，缓存层会检查缓存的资源是否还在允许时间范围内。如果缓存的时间小于指定的 max-age，那么客户端可以直接接受缓存的资源，无需访问后端。
如果 max-age=0，则表示客户端明确要求最新的数据。在这种情况下，缓存层通常会将请求转发到应用集群以获取最新的资源。

另一个与缓存相关的字段是 If-Modified-Since，它可以用来判断资源是否需要更新。工作机制是：

客户端发送请求时，附带上次缓存资源的更新时间。
服务器接收到请求后，对比资源的更新时间：
- 如果资源自那之后没有更新，服务器会返回 304 Not Modified 响应，客户端无需重新下载资源，从而节省带宽。
- 如果资源已经更新，服务器会返回最新的内容，客户端会重新下载。

通过这些机制，可以有效地减少不必要的数据传输，优化 HTTP 请求的处理效率。

在构建这些缓存策略后，Nginx 会根据 HTTP 请求头来处理这些逻辑，最终将 HTTP 报文传递给下一层：传输层。浏览器会负责将 HTTP 请求交给传输层来建立连接，这个过程使用了前面讲解过的 Socket 接口。不过在浏览器中，这些底层细节已经由程序预先实现好了，我们无需手动编写。

通过这种多层次架构设计，不仅可以提升静态资源的加载效率，还能减轻后端服务器的压力，为高并发的业务场景提供强大的支持。

HTTP 请求的发送过程

HTTP 协议是基于 TCP 协议的，因此它采用面向连接的方式，通过 二进制流（stream） 将请求发送给对方。在 TCP 层，二进制流会被切分为一个个 报文段 并逐段发送到服务器。

1. TCP 的可靠传输
每发送一个报文段，接收方都需要返回一个 ACK（确认），以保证数据可靠到达。如果未收到 ACK，TCP 会进行重新传输，直到确认数据送达。即使同一个数据包可能传输多次，但这些重试操作由 TCP 层自动处理，而 HTTP 协议不需要关心这些细节。

2. IP 层封装
在 TCP 层发送每一个报文段时，会加上 源地址（发送方的地址）和 目标地址（接收方的地址），并将这些信息封装到 IP 头 中，交给 IP 层 进行传输。

3. MAC 地址解析
IP 层需要判断目标地址是否与本机在同一个局域网内：

如果在同一个局域网：
- IP 层会发送 ARP 协议（地址解析协议）来查询目标 IP 地址对应的 MAC 地址。
- 获取到目标 MAC 地址后，会将 源 MAC 地址 和 目标 MAC 地址 填入 MAC 头，发送数据包。
如果不在同一个局域网：
- IP 层会将数据发送到默认网关，并通过 ARP 协议获取网关的 MAC 地址。
- 源 MAC 地址设置为本机 MAC，目标 MAC 地址设置为网关 MAC，最终将数据包发给网关。

4. 路由转发
网关收到数据包后，检查其目标 MAC 地址是否匹配。如果匹配，网关会查看包中的目标 IP 地址：

根据路由协议，网关找到下一跳路由器的地址，并获取该路由器的 MAC 地址。
替换目标 MAC 地址为下一跳路由器的 MAC 地址后，将数据包转发出去。

通过这种方式，数据包在多个路由器之间逐跳转发，最终到达目标局域网。

5. 到达目标主机
当数据包进入目标局域网时，最后一跳的路由器会发送 ARP 请求，获取目标机器的 MAC 地址。将包的目标 MAC 地址更新后，路由器将包发送到目标机器。

目标机器接收到数据包后，会进行以下步骤：

检查 MAC 地址是否匹配，如果匹配，将包接收。
检查 IP 地址是否匹配，如果匹配，根据 IP 头中的 协议字段 知道上层协议是 TCP，于是交给 TCP 层处理。
在 TCP 层解析 序列号，检查该包是否为当前需要的数据：
- 如果是需要的数据，将其放入缓存并返回一个 ACK。
- 如果不是需要的数据，则丢弃该包。

6. 到达 HTTP 服务
在 TCP 头中，还包含一个 端口号，它指向目标主机上某个监听此端口的服务。例如，HTTP 服务器通常监听 80 或 443 端口。TCP 层会将数据包交给监听该端口的 HTTP 服务进程。

HTTP 服务器接收到请求后，会解析内容并发现客户端请求的是一个网页资源。服务器会将网页内容（可能是 HTML、CSS、JavaScript 等）封装到 HTTP 响应中，通过相同的 TCP 连接返回给客户端。

整个过程完成后，客户端会接收到网页内容并呈现给用户。

总结
HTTP 请求发送的过程涵盖了从应用层（HTTP）、传输层（TCP）、网络层（IP）到数据链路层（MAC）的完整链路：

HTTP 请求被封装为 TCP 报文流。
TCP 报文被封装进 IP 包。
IP 包通过 MAC 地址在局域网或路由器之间转发。
目标主机接收并处理，最终将数据交给 HTTP 服务。
HTTP 服务生成响应，沿相同路径返回客户端。

这一系列的步骤构成了互联网中一个完整的 HTTP 请求-响应流程。

HTTP 返回的构建

HTTP 的返回报文也是有一定格式的。这也是基于 HTTP 1.1 的。

https://i-blog.csdnimg.cn/direct/0fa2f753416440699240d09caa28b431.png" alt="在这里插入图片描述" />
状态码是 HTTP 请求结果的直接反映。例如，200 状态码表示请求成功，一切顺利；而 404 则表示服务器无法找到请求的资源，是我们最不想看到的情况之一。状态码旁边的短语还会提供简单的解释，说明问题的原因。

在响应中，接下来是返回的首部字段部分，这些字段也是以 key:value 的形式出现。例如：

Retry-After：这个字段告诉客户端应在多长时间后再次尝试请求。常见场景是在服务返回 503 错误（服务暂时不可用）时，配合这个字段一起使用。
Content-Type：用于指明响应内容的格式，比如 text/html 表示返回的是 HTML，application/json 表示返回的是 JSON 数据。

服务器构造好返回的 HTTP 报文后，需要将其发送给客户端。这依然是通过 Socket 和 TCP 层 来完成的。TCP 会将返回的 HTML 数据切分为一个个小的段，每个段都会带上 TCP 头部，并通过可靠传输机制确保每个段都能顺利到达客户端。

这些段在加上 TCP 头后，会交由 IP 层处理，再次进入网络传输的链路。这次发送过程与请求过程的路径可能不同，但逻辑是一样的：数据从服务器出发，经过网关、路由器，逐跳传输到达客户端的局域网。

客户端接收到数据包后，会依次进行以下操作：

检查 MAC 地址 和 IP 地址 是否匹配，如果匹配，则接收数据包。
将数据交给 TCP 层，检查序列号，确保是按顺序接收到的报文段。如果是需要的报文段，则将其缓存并返回 ACK 确认。
根据 TCP 头部中的端口号，将数据包发送到监听该端口的进程。对于 HTTP 响应，这个进程通常是浏览器。

浏览器作为客户端，收到完整的 HTTP 报文后会解析它：

首先查看状态码。如果状态码是 200，表示请求成功，服务器正常返回。
然后从 HTTP 报文的正文中提取 HTML 内容。HTML 是一种标准的网页格式，浏览器根据 HTML 的结构和样式规则，渲染出一个绚丽多彩的网页。

这就是一个完整的 HTTP 请求和响应过程，从客户端发起请求到服务器返回结果，再到客户端解析并展示内容，体现了整个互联网通信的高效和复杂性。

HTTP 2.0

HTTP 协议也在不断进化，在 HTTP/1.1 的基础上发展出了 HTTP/2，解决了传统 HTTP 在实时性和并发性上的诸多问题。

HTTP/1.1 的通信方式是基于纯文本的，每次通信都需要携带完整的 HTTP 头部。如果不使用流水线（Pipeline）模式，那么每次请求和响应都只能按一去一回的顺序进行。这种机制导致了较大的延迟，并且在高并发场景下效率明显不足。

为了解决这些问题，HTTP/2 引入了一些新的优化机制。首先是 头部压缩。HTTP/2 在客户端和服务端之间建立了一个共享的索引表，通过索引表记录重复的头部字段。这样，对于相同的头部字段，只需要传递索引值，而不再重复传输整个键值对，从而显著减少了头部的传输开销。

其次，HTTP/2 引入了 多路复用 的概念。它将一个 TCP 连接切分成多个虚拟的通道，称为 流（Stream）。每个流都有唯一的 ID，并且流的方向可以是客户端到服务端，也可以是服务端到客户端。通过这种机制，多个流可以共享同一个 TCP 连接，而不再需要为每个请求建立单独的连接。

流还支持 优先级 设置。客户端和服务端可以根据流的优先级，决定优先处理哪些数据，从而提高传输效率。

HTTP/2 还将所有的传输内容分割为更小的消息和帧，并采用 二进制格式编码，取代了 HTTP/1.1 的文本协议。常见的帧包括：

Header 帧：用于传输头部信息，并且会开启一个新的流。
Data 帧：用于传输正文实体。一个流可以包含多个 Data 帧。

通过这些机制，HTTP/2 的客户端可以将多个请求分配到不同的流中，然后将请求内容拆分为多个帧，以二进制形式进行传输。帧在传输时可以打散并乱序发送，接收端会根据帧的 流标识符（Stream ID）将它们重新组装。同时，传输过程会优先处理优先级更高的流，从而提高通信的实时性和并发性。

通过头部压缩、多路复用以及二进制帧的引入，HTTP/2 显著提升了性能，使得通信更加高效、灵活，也为现代应用场景提供了更强大的支持。

我们来举一个例子。

假设我们的一个页面要发送三个独立的请求，一个获取 css，一个获取 js，一个获取图片 jpg。如果使用 HTTP 1.1 就是串行的，但是如果使用 HTTP 2.0，就可以在一个连接里，客户端和服务端都可以同时发送多个请求或回应，而且不用按照顺序一对一对应。
https://i-blog.csdnimg.cn/direct/0b330612e8e0435eba21a2a13a5cbc64.png" alt="在这里插入图片描述" />
HTTP 2.0 其实是将三个请求变成三个流，将数据分成帧，乱序发送到一个 TCP 连接中。
https://i-blog.csdnimg.cn/direct/7ed29bb1771e4818abc34456dafb693e.png" alt="在这里插入图片描述" />
HTTP 2.0 成功解决了 HTTP 1.1 的队首阻塞问题，同时，也不需要通过 HTTP 1.x 的 pipeline 机制用多条 TCP 连接来实现并行请求与响应；减少了 TCP 连接数对服务器性能的影响，同时将页面的多个数据 css、js、 jpg 等通过一个数据链接进行传输，能够加快页面组件的传输速度。

QUIC 协议

HTTP/2 虽然通过多路复用大幅提升了并发性，但由于其底层仍然基于 TCP 协议，仍然存在一些固有的问题。例如，TCP 在处理包时有严格的顺序要求。当某个数据包丢失时，整个 TCP 连接需要等待这个包完成重传后才能继续。这种机制会导致 HTTP/2 的多路复用也受到影响。即使 HTTP/2 将数据划分为多个流（stream），一个流的数据包丢失也会阻塞其他流的传输，形成“队头阻塞”。

为了打破这个限制，Google 提出了基于 UDP 的 QUIC 协议，通过更灵活的机制彻底改变了传统的传输模式。QUIC 可以说是“城会玩”，因为它重新定义了许多网络通信的基本规则。

自定义连接机制
在传统的 TCP 中，一条连接由四元组标识（源 IP、源端口、目的 IP、目的端口）。如果其中任何一个元素发生变化，例如手机在 Wi-Fi 和移动网络之间切换，TCP 连接会断开并需要重新建立。这意味着每次切换都需要经历重新握手的时延。

QUIC 基于 UDP，不再使用四元组标识连接，而是通过一个 64 位随机数 作为连接 ID。这种连接 ID 是独立于 IP 和端口的，因此当网络环境发生变化时，只要连接 ID 不变，就可以无缝续传，无需重新握手。这对于移动网络环境下的稳定性是一个巨大的提升。

自定义重传机制
TCP 为了保证可靠性，采用了序号和应答机制，超时重传的算法是基于 RTT（往返时间）进行动态调整的。但 RTT 的计算在 TCP 中并不精确。例如，当发送序号为 100 的包未收到确认后重新发送，最终收到的 ACK 是 101。此时，RTT 的采样可能有两种情况：

用后一个包的发送时间计算 RTT，结果可能偏短。
用前一个包的发送时间计算 RTT，结果可能偏长。

QUIC 的机制更加精确。它也使用序列号，但规定每个序列号的包只发送一次，重传时会分配新的序列号。例如，第一个发送的包序号是 100，如果需要重传，下次发送的序号是 101。返回的 ACK 100 是对第一个包的确认，ACK 101 是对第二个包的确认。通过这种方式，QUIC 能够准确地计算 RTT，避免不准确的采样。

同时，为了保证数据流的完整性，QUIC 定义了一个 offset（偏移量） 概念。QUIC 是面向连接的，像 TCP 一样传输一个连续的数据流。数据在流中会标记一个偏移量 offset。即使同一偏移量的数据需要多次发送，QUIC 会根据 offset 拼接数据，最终还原完整的数据流。如果某个 offset 的数据包未收到，就重传该部分数据；如果收到，则按照偏移量顺序拼接到流中。

QUIC 的这种设计，不仅避免了传统 TCP 的顺序问题，还通过灵活的 offset 和序列号机制实现了高效的数据重传，同时保持流的完整性。这让它在应对高并发和网络切换场景时表现更加出色。
https://i-blog.csdnimg.cn/direct/7d0df5380ca2404fbe6155c5d87389fd.png" alt="在这里插入图片描述" />
无阻塞的多路复用
通过自定义的连接和重传机制，QUIC 完美解决了 HTTP/2 在多路复用中可能出现的阻塞问题。

与 HTTP/2 类似，QUIC 允许在同一条连接上创建多个 stream，用于传输多个 HTTP 请求。然而，QUIC 基于 UDP，每个 stream 是独立的，彼此之间没有依赖关系。例如，当 stream2 的一个 UDP 包丢失时，虽然需要重传，但这并不会影响其他 stream 的数据传输。假如后续的 stream3 的 UDP 包已经到达，它无需等待 stream2 的丢包重传，直接可以传递给用户。这种机制彻底避免了 HTTP/2 中因为 TCP 顺序依赖引起的队头阻塞问题。

自定义流量控制
QUIC 的流量控制与 TCP 类似，也是通过窗口控制机制实现的。QUIC 使用 window_update 来通知对端可接受的字节数。但与 TCP 不同的是，QUIC 的流量控制不仅适用于整个连接，还适用于连接中的每个独立 stream。

在 TCP 中，接收窗口的起始点由下一个可接收并 ACK 的序列号决定。如果某个序列号的包未到，即便后续的包都已到达缓存，窗口也无法右移，因为 TCP 的累计应答机制要求必须按顺序接收并确认。这种机制会导致后续到达的包无法被确认，可能因为超时而触发不必要的重传，浪费带宽。

QUIC 的 ACK 机制基于 offset，每个 offset 的包到达后都会立即被缓存并确认，不需要等待前面的包。这种机制确保只需等待丢失的包进行重传，而其他包不会被延迟处理。窗口的起始位置由当前接收到的最大 offset 决定，从该 offset 到 stream 的最大缓存容量，是真正的窗口大小。这样的设计更加灵活和准确，有效提高了带宽利用率并减少了重传开销。

通过无阻塞的多路复用和精细的流量控制机制，QUIC 显著优化了 HTTP 的传输效率，为高并发和复杂网络环境提供了更强的支持。
https://i-blog.csdnimg.cn/direct/5fbb16f6d1a948ddb52316c0861fe3e8.png" alt="在这里插入图片描述" />
总结：

HTTP 协议虽然很常用，也很复杂，重点记住 GET、POST、 PUT、DELETE 这几个方法，以及重要的首部字段；

HTTP 2.0 通过头压缩、分帧、二进制编码、多路复用等技术提升性能；

QUIC 协议通过基于 UDP 自定义的类似 TCP 的连接、重试、多路复用、流量控制技术，进一步提升性能。

HTTP/3 是基于 QUIC 协议的新一代 HTTP 协议，是对 HTTP/2 的重要升级。它通过在传输层和应用层的多个关键改进，解决了传统 TCP 和 HTTP/2 中的性能瓶颈，为互联网通信带来了显著优化。

HTTP/3 的背景和动机
尽管 HTTP/2 引入了多路复用和头部压缩，大幅提升了传输效率，但它依然使用 TCP 作为底层传输协议。TCP 的传输顺序和可靠性机制导致的队头阻塞问题仍未解决，尤其是在高丢包率或网络切换场景下，这种限制变得更加明显。此外，TCP 的连接建立需要通过三次握手，增加了初次连接时的延迟。

QUIC（Quick UDP Internet Connections）是由 Google 提出的基于 UDP 的传输协议，旨在替代 TCP。HTTP/3 基于 QUIC 协议，继承了 HTTP/2 的优势，同时解决了 TCP 的局限性，为现代互联网的高速通信提供了新的可能。

HTTP 3.0

HTTP/3 的关键特性

无阻塞的多路复用
HTTP/3 基于 QUIC 协议，允许在单一连接上创建多个独立的 stream。与 HTTP/2 不同，QUIC 的 stream 之间是完全独立的，没有传输顺序依赖。因此，即使某个 stream 的数据包丢失或需要重传，也不会阻塞其他 stream 的数据传输。这种设计有效避免了 HTTP/2 因底层 TCP 的队头阻塞问题而导致的性能损失。
更快的连接建立
QUIC 协议通过结合 TLS 加密握手，将传统 TCP 的三次握手和 TLS 握手合并为一次，实现了 0-RTT（零往返时间）的连接建立。在网络环境良好的情况下，客户端可以直接发送数据，大幅降低初次连接的延迟。
高效的重传机制
QUIC 使用独立于 IP 地址和端口的 64 位连接 ID 标识连接，因此在移动网络环境下，当 IP 或端口发生变化时，连接可以保持不变，避免重新建立连接的开销。此外，QUIC 的重传机制基于序列号递增的方式，每次重传的数据包都有新的序列号，避免了 TCP 在 RTT 计算中的模糊问题，提高了重传效率。
灵活的流量控制
QUIC 为整个连接和每个 stream 单独实现流量控制，避免单个 stream 占用过多资源而影响其他 stream 的传输。基于 offset 的 ACK 机制可以精准地确认数据包，确保丢包的重传不会影响已接收数据的传递。
全面的加密和安全性
HTTP/3 默认使用 TLS 1.3 加密，提升了通信的隐私性和安全性。QUIC 的设计从底层保证了数据的加密，简化了安全配置，并消除了潜在的中间人攻击和数据篡改风险。
头部压缩
与 HTTP/2 类似，HTTP/3 也支持头部压缩，但采用了专为 QUIC 优化的 QPACK 算法。QPACK 的设计允许头部压缩和解压缩在多路复用中独立操作，避免了 HTTP/2 中动态表更新引起的队头阻塞问题。

HTTP/3 的实际应用场景

高丢包率网络
在高丢包率或不稳定的网络环境下，HTTP/3 的无阻塞多路复用和灵活的重传机制能够显著提升性能。例如，在线视频流、实时语音通话等需要低延迟的应用将直接受益于 HTTP/3。
移动网络切换
HTTP/3 的连接 ID 独立于 IP 和端口，在移动设备切换网络时（如从 Wi-Fi 切换到蜂窝数据网络）能够保持连接的连续性，减少延迟和中断。
高并发场景
HTTP/3 在单一连接上支持大量独立的 stream，对于高并发场景（如 CDN 分发、多人在线游戏等）提供了更高效的支持。
安全敏感应用
由于 HTTP/3 内置 TLS 1.3 加密，对敏感数据的传输提供了更高的安全性，适用于在线支付、银行交易等场景。