HTTP各个版本对比

前置知识

什么是HTTP

​ HTTP (HyperText Transfer Protocol，超文本传输协议) 是一种用于分布式、协作式、超媒体信息系统的应用层协议。简单来说，它是万维网（World Wide Web）数据通信的基础，规定了客户端（通常是网页浏览器）和服务器（通常是网站服务器）之间如何请求和传输数据。

超文本 (HyperText)

​ 最初 HTTP 设计是为了传输 HTML (HyperText Markup Language) 文档，这些文档可以通过超链接 (hyperlinks) 连接到其他文档，形成一个“网络”。现在，HTTP 不仅仅传输 HTML，还可以传输图片、视频、音频、JSON、XML 等任何类型的数据。

客户端-服务器模型（Client-Server Model）

HTTP 是一个基于请求-响应模型的协议：

• 客户端（Client）

  发起请求的一方（（如浏览器、爬虫、API 客户端））

• 服务器（Server）

  接收请求并返回响应的一方（如 Nginx, Apache, Node.js 服务器）

注意，在HTTP/2.0版本，通过多路复用 (Multiplexing) 和一种特殊的 HTTP/2 帧类型——PUSH_PROMISE 帧实现了服务器的推送功能，即服务器同样可以向客户端发送请求，而不只是单向的请求-响应。

无状态（Stateless）

​ 这是 HTTP 的一个重要特性。服务器默认不保存关于客户端先前请求的任何信息。每个请求都被视为独立的事务。如果需要保持状态（如用户登录状态），通常通过 Cookies、Session 或 Token 等机制在 HTTP 之上实现。

各个版本介绍与对比

HTTP/0.9（1991年）

特点

协议设计非常简单，也被称为单行协议（one-line protocol），具体表现在以下几个方面：

1. 只支持GET方法
2. 没有请求头（Request Headers）或响应头（Response Headers）
3. 服务器响应后直接返回 HTML 内容，没有状态码或错误码。
4. 响应完毕后，连接立即关闭（单条短连接）。

解决的问题

实现了最初的网络文档（主要是HTML）获取。

缺点

因为是第一版HTTP协议，所以功能极其有限，无法传输除 HTML 外的其他类型文件，没有状态管理，没有版本号，只有最简单的传输功能；

HTTP/1.0（1996年 - RFC 1945）

特点

1. 引入了请求头和响应头的概念，允许传输元数据（如 Content-Type, User-Agent, Server 等）

   元数据，即HTTP报文中的请求体/响应体，一般都是以键值对的形式出现的，用来描述HTTP请求/响应的基本信息

2. 支持多种请求方法，GET，POST等

3. 引入了状态码，如 200 OK, 404 Not Found, 500 Internal Server Error

4. 支持传输多种文件类型，一般会在请求/响应报文对应的请求体/响应体中的Content-Type字段体现

5. 短连接，HTTP/1.0版本默认使用短连接建立连接，而这也是后续HTTP版本重点关注的问题，也可以通过非标准的Connection: Keep-Alive头部尝试保持连接，但不是所有服务器和客户端都支持良好。

   为什么短连接是一个严重的问题？

   短连接意味着每一个请求/响应周期都会建立一个TCP连接，而TCP连接为了保证可靠性，需要进行三握四挥过程以保证连接的正确建立，由此带来的时间和资源消耗是巨大的，尤其是在高并发的场景下，TCP频繁的建立和断开会导致高延迟和低效的性能，由此还可能引发网络空间的拥塞问题，所以后续的HTTP版本都在避免使用短连接特性，在HTTP/1.1版本下，默认使用长连接形式

解决的问题

尽管HTTP/1.0版本还是存在很多问题，但是由于其支持更多的网络请求方式和文件类型，丰富了协议功能，使其能够处理更复杂的 Web 应用和多媒体内容

缺点

1. 短连接，上文已经介绍过，这里不再赘述（短连接也有其他的描述，比如连接无法复用，其本质和短连接是一样的）

   短连接问题在其后续版本HTTP/1.1中就被默认的长连接选项Keep-Alive解决

2. 队头阻塞问题

   和短连接问题一样，这也是严重限制传输性能的又一大问题，具体表现在在同一个TCP连接中，如果前一个请求未完成响应，后续必须阻塞式等待该响应被处理后，方可继续执行，但是这个问题直到HTTP/2提出多路复用机制后才得以解决

HTTP/1.1（1999年 - RFC 2616，后被 RFC 7230-7235 系列取代）

特点

1. 持久化连接（即长连接），默认启用Connection: Keep-Alive，允许在一个 TCP 连接上传输多个 HTTP 请求和响应，显著减少了连接建立的开销。
2. 管道化，允许客户端在收到前一个响应之前发送多个请求，但是因为队头阻塞的存在，容易出现错误，所以很多浏览器都会默认禁用该功能
3. Host 头部，强制要求请求中包含 Host 头部，使得一台物理服务器可以托管多个域名（虚拟主机）
4. 新增方法，较HTTP/1.0版本又增加了一些方法：OPTIONS, PUT, DELETE, TRACE, CONNECT

解决的问题

增加了默认长连接功能，大幅提升了 HTTP 性能，减少了网络延迟和服务器压力，

缺点

1. 队头阻塞，具体问题在上文已经介绍，但是很遗憾，HTTP/1.1版本并未解决该问题，直到HTTP/2版本提出的多路复用机制才正式解决该问题

2. 头部冗余问题，在抓取HTTP包时可以发现，其请求和响应的头部信息的很多字段是重复的（比如常见的HOST和USER-AGNET字段，而且这些冗余字段一般都未进行压缩），由此会带来巨大的传输开销

3. 连接数限制: 浏览器通常会对单个域名下的并发 TCP 连接数做限制（一般是6-8个）。

   为什么需要连接数限制？

   首先明确一点，每一个TCP连接的建立都需要消耗一定量的资源，如果对每个客户端的TCP连接数量不加以限制，会出现无限多的TCP连接（可能由恶意应用产生），类似于一种微型的Dos攻击，导致其他的TCP连接受到影响，所以需要加以限制

   而在HTTP/2版本中，采用多路复用机制彻底解决了该问题，关于多路复用在之后进行介绍

HTTP/2（2015年 - RFC 7540）

在我看来，HTTP/2版本具有划时代的意义，主要有以下几点：

1. 解决了队头阻塞 (Head-of-Line Blocking) - 应用层突破

2. 二进制分帧 (Binary Framing Layer) - 效率与健壮性提升

3. 头部压缩 (Header Compression - HPACK) - 大幅减少开销

4. 单一连接策略 - 简化与高效

5. 服务器推送 (Server Push) - 优化加载路径（虽然实践中效果存疑），这里会再介绍一种应用层协议，可以较好的处理服务器主动推送的需求

6. 流优先级 (Stream Prioritization) - 优化资源加载顺序

7. 引入多路复用机制，从根本上提供了比管道化更可靠、更高效的并发机制

HTTP/2 不是对 HTTP/1.1 的简单修补或功能增加，而是对其底层传输机制进行了根本性的重新设计（虽然仍基于 TCP）。它通过引入二进制分帧和多路复用，一举解决了困扰 Web 性能多年的核心问题——队头阻塞和低效的连接利用率。这使得 Web 应用加载更快、响应更及时、网络资源利用更高效。同时，它还通过头部压缩减少了开销，并通过优先级和服务器推送提供了更精细的性能优化手段。

特点（与上文一一对应）

1. 引入多路复用

2. 协议改为二进制格式，数据被封装在不同的帧中，这是协议层面的根本性转变

3. HPACK 算法，使用静态表、动态表和霍夫曼编码来压缩头部

4. 基于多路复用机制，浏览器通常只需要与服务器建立一个 TCP 连接即可高效处理所有请求，极大的减少了 TCP 和 TLS 的握手开销

   什么是TLS（HTTPS 加密过程）

   TLS 是一种加密协议，旨在为网络通信提供安全性和数据完整性。它是其前身 SSL (Secure Sockets Layer，安全套接层) 的继任者。TLS 最常见的应用场景是保护 Web 浏览器和 Web 服务器之间的通信（即 HTTPS，HTTP over TLS），但它也可以用于保护其他应用层协议，如电子邮件 (SMTP, IMAP, POP3)、FTP (FTPS)、VPN 等。

   TLS 的核心目标

   1. 保密性 (Confidentiality / Privacy)
      • 通过对称加密算法（如 AES）对通信双方传输的数据进行加密。
      • 即使数据在传输过程中被第三方截获，没有密钥也无法解密和理解其内容。
      • 对称加密的密钥是在连接建立的握手阶段，通过非对称加密或密钥交换算法（如 RSA, Diffie-Hellman）安全地协商生成的。
   2. 完整性 (Integrity)
      • 通过消息认证码 (Message Authentication Code, MAC) 来确保数据在传输过程中没有被篡改。
      • 发送方会根据数据内容计算出一个 MAC 值并附加到数据后面。接收方收到数据后，会用相同的密钥和算法重新计算 MAC 值，并与收到的 MAC 值进行比较。
      • 如果不匹配，则表明数据在传输过程中被修改过。
   3. 身份认证 (Authentication)
      • 通常情况下，TLS 可以验证服务器的身份。服务器会向客户端出示一个由受信任的证书颁发机构 (Certificate Authority, CA) 签发的数字证书。客户端会验证该证书的有效性（如有效期、签名、颁发者等）以确认服务器的真实身份，防止中间人攻击。
      • TLS 也支持客户端身份认证（双向认证），但这在 Web 场景中不太常见，更多用于企业内部或特定安全需求的应用。

   TLS 的工作流程 (简化版握手过程 - Handshake)

   TLS 连接的建立过程涉及一个复杂的“握手”阶段，目的是让客户端和服务器就加密参数达成一致，并安全地交换密钥。

   1. ClientHello

      • 客户端向服务器发起连接请求，并发送一个 ClientHello 消息。
      • 一个 ClientHello 消息由以下几部分组成：
        • 客户端支持的 TLS 版本号。
        • 一个客户端生成的随机数 (Client Random)。
        • 客户端支持的密码套件 (Cipher Suites)列表（指定了加密算法、密钥交换算法、哈希算法等组合）。
        • 客户端支持的压缩方法 (现在通常不使用)。
        • 可选的扩展 (Extensions)，如 SNI (Server Name Indication，用于虚拟主机)。

   2. ServerHello & Certificate & ServerKeyExchange (可选) & ServerHelloDone

      服务器收到 ClientHello 后，如果同意建立连接，会回复一系列消息：

      1. ServerHello:

         • 服务器选择的 TLS 版本号（从客户端支持的列表中选择一个）。

         • 一个服务器生成的随机数 (Server Random)。

         • 服务器从客户端密码套件列表中选择一个密码套件。

         • 选择的压缩方法。

      2. Certificate (通常是服务器证书):

         • 服务器将其数字证书（包含公钥和 CA 签名）发送给客户端。客户端会验证该证书。

      如何验证？

      简单来说，这会包含两个部分，一个是明文的数据，一个是签名，首先客户端会对明文数据进行SHA256哈希处理，得到一个结果，然后用公钥对签名进行解密，也得到一个结果，比较这两个结果，一样则说明数据没有被篡改；

      3. ServerKeyExchange (可选):

         • 如果选择的密钥交换算法需要额外信息（例如，基于 Diffie-Hellman 的密钥交换，服务器会发送其 DH 参数和签名）。对于基于 RSA 的密钥交换，此步骤可能省略，因为公钥已在证书中。

      4. CertificateRequest (可选):

         • 如果服务器需要验证客户端身份（双向认证），会发送此消息请求客户端证书。

      5. ServerHelloDone:

         • 告知客户端服务器的初始协商消息已发送完毕。

   3. ClientKeyExchange & ChangeCipherSpec & Encrypted Handshake Message (Finished)

      客户端收到服务器的消息后：

      1. 验证服务器证书: 确保证书有效、来自受信任的 CA、与访问的域名匹配等。

      2. (可选) Certificate & CertificateVerify: 如果服务器请求了客户端证书，客户端会发送自己的证书和对前面握手消息的签名（使用客户端私钥）。

      3. ClientKeyExchange:

         • 客户端根据协商好的密钥交换算法生成一个“预主密钥 (Pre-Master Secret)”。

         • 如果使用 RSA，客户端用服务器证书中的公钥加密这个预主密钥，然后发送给服务器。

         • 如果使用 Diffie-Hellman，客户端生成自己的 DH 参数，计算出预主密钥，并将自己的公开 DH 参数发送给服务器。

      4. 生成主密钥 (Master Secret): 客户端和服务器使用 Client Random, Server Random 和 Pre-Master Secret，通过一个伪随机函数 (PRF) 计算出相同的主密钥。

      5. 生成会话密钥 (Session Keys): 从主密钥派生出用于对称加密和 MAC 计算的实际会话密钥。

      6. ChangeCipherSpec: 客户端通知服务器，它将开始使用协商好的加密参数和会话密钥加密后续消息。

      7. Encrypted Handshake Message (Finished): 客户端将之前所有握手消息的哈希值用新的会话密钥加密后发送给服务器。这是对握手过程完整性的校验，也是第一个使用新加密参数的消息。

   4. Server ChangeCipherSpec & Encrypted Handshake Message (Finished)

      • 服务器收到客户端的 ClientKeyExchange 后，如果使用 RSA，用自己的私钥解密得到预主密钥。然后，服务器也计算出主密钥和会话密钥。
      • ChangeCipherSpec: 服务器通知客户端，它也将开始使用协商好的加密参数和会话密钥加密后续消息。
      • Encrypted Handshake Message (Finished): 服务器同样将之前所有握手消息的哈希值用新的会话密钥加密后发送给客户端，作为对握手完整性的校验。

   5. 应用数据传输 (Application Data)

      • 握手成功！现在客户端和服务器都拥有了共享的会话密钥。
      • 双方可以使用这些会话密钥通过对称加密算法加密应用层数据（如 HTTP 请求/响应），并使用 MAC 保证数据完整性，然后进行安全的通信。

5. 允许服务器在客户端请求之前，主动将客户端可能需要的资源推送过去，这里再介绍一种支持主动向客户端推送消息的协议：WebSocket协议

   WebSocket 应用层协议

   WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议，有下列几个特征：

   1. 全双工通信 (Full-duplex Communication)
   2. 单个 TCP 连接
   3. 低延迟、低开销
   4. 解决了 HTTP 实时通信的局限性
   5. 协议标识符为ws://（未加密）和wss://（加密）

   具体介绍可以看WebSocket详解

6. 允许客户端明确告知服务器资源的优先级，服务器可以根据优先级分配资源（如带宽、CPU），从而优化用户感知的加载性能

缺点

1. TCP 队头阻塞 (TCP Head-of-Line Blocking)

   ​ 这是传输层协议的问题，无法在应用层解决，所以在后续的HTTP/3版本中，更换了所依赖的TCP传输层协议，换成了基于UDP协议优化的QUIC协议

2. 连接建立的延迟 (TCP and TLS Handshake Latency)

   ​ 尽管 HTTP/2 鼓励使用单个 TCP 连接，从而减少了连接建立的总次数，但单个连接的建立仍然需要 TCP 三次握手和 TLS 握手（对于 HTTPS）。这个过程通常需要 2-3 个网络往返时间 (RTT)，在高延迟网络中仍然是一个显著的开销；

   ​ 所以，在后续的HTTP/3 (QUIC)版本中，将传输层握手和加密握手合并，并将 TLS 版本升级到 TLS 1.3，通常可以将握手延迟降低到 1 RTT，甚至支持 0-RTT 会话恢复

3. 服务器推送 (Server Push) 的复杂性和有效性质疑

   ​ 虽然服务器推送旨在提前将资源发送给客户端以减少延迟，但其实际应用效果并不总是理想的，主要原因有以下几点：

   • 缓存问题: 服务器很难准确知道客户端缓存中已有哪些资源。推送已缓存的资源会浪费带宽。客户端可以拒绝推送，但 PUSH_PROMISE 帧本身仍然有开销。
   • 预测困难: 服务器需要准确预测客户端将需要哪些资源，错误的预测会导致推送无用资源，反而浪费资源。
   • 实现和配置复杂: 正确有效地配置和使用服务器推送对开发者来说有一定难度。
   • 优先级冲突: 推送的资源可能会与客户端主动请求的更重要资源竞争带宽。

4. 单点故障 (Single Point of Failure for the Connection)

   ​ HTTP/2 鼓励使用单个 TCP 连接来承载所有请求。虽然这提高了效率，但也意味着如果这个唯一的 TCP 连接出现问题（例如，由于网络波动或中间设备故障导致连接中断），那么所有正在进行的请求和响应都会失败，需要重新建立连接并重试所有未完成的请求

5. 实现复杂度

   ​ 相比 HTTP/1.1，HTTP/2 协议本身（包括二进制分帧、流控制、优先级、头部压缩等）要复杂得多。这给服务器、客户端以及相关库的实现者带来了更大的挑战。

HTTP/3（2022年 - RFC 9114）

​ 可以看作是对HTTP/2的补充和进化，实现的核心机制就是基于UDP的QUIC协议，该协议不再依赖于 TCP (Transmission Control Protocol) 作为其传输层协议，而是构建在 QUIC (Quick UDP Internet Connections) 协议之上，而 QUIC 本身运行在 UDP (User Datagram Protocol) 之上。

特点

1. 基于 QUIC 协议:

   ​ 这是 HTTP/3 最根本的特点。QUIC 是一个由 Google 最初设计和实现的，现在由 IETF 标准化的新的传输层协议。它集成了许多现代传输和安全特性。

2. 多路复用 (Multiplexing) - 传输层实现:

   ​ 与 HTTP/2 类似，HTTP/3 支持多路复用，允许在单个 QUIC 连接上并行传输多个 HTTP 请求和响应流。
   ​ 但是HTTP/2 的多路复用在应用层实现，受限于底层 TCP 的顺序性。QUIC 在传输层实现了流的独立性，一个流的丢包不会阻塞其他流。

3. 集成的加密 (Integrated Encryption):

   ​ QUIC 强制要求所有连接都进行加密，其加密功能与 TLS 1.3 紧密集成或类似。这意味着 HTTP/3 连接默认就是安全的，没有未加密的 HTTP/3 选项。

4. 改进的连接建立速度 (Reduced Connection Establishment Latency):

   ​ QUIC 将传输层握手和加密握手（类似 TLS 1.3）合并进行，因此连接的建立变得更加快速——对于新连接，通常只需要 1 RTT (Round-Trip Time) 即可完成握手并开始传输数据。
   并且对于之前已建立过连接的客户端，支持 0-RTT 连接恢复，客户端可以在第一个数据包中就发送应用数据，极大地减少了延迟。

5. 连接迁移 (Connection Migration):

   ​ QUIC 连接使用连接 ID (Connection ID) 而不是 IP 地址和端口号的四元组来标识；
   ​ 当客户端的网络发生变化（例如从 Wi-Fi 切换到蜂窝网络导致 IP 地址改变），只要客户端能继续使用相同的连接 ID 与服务器通信，连接就可以保持活动状态，无需重新建立，提供了无缝的漫游体验。

6. 改进的拥塞控制 (Improved Congestion Control):

   ​ QUIC 具有更灵活和可插拔的拥塞控制机制，可以更快地适应网络条件变化，比传统的 TCP 拥塞控制（如 Reno, Cubic）有更好的性能潜力。

7. 头部压缩 (QPACK):

   ​ HTTP/3 使用 QPACK 作为其头部压缩算法。QPACK 与 HTTP/2 的 HPACK 类似，但进行了一些调整以适应 QUIC 的流特性（例如，避免了 HPACK 中因有序交付要求可能导致的队头阻塞问题）。

解决的问题

1. TCP 队头阻塞 (TCP Head-of-Line Blocking):

   ​ 这是 HTTP/3 解决的最核心问题。HTTP/2 虽然在应用层解决了 HTTP 队头阻塞，但无法避免 TCP 层的队头阻塞（一个 TCP 包丢失会阻塞整个连接上的所有流）。QUIC 在 UDP 之上实现了独立的流，一个流的数据包丢失或延迟只影响该流，不会阻塞其他并发流的传输。这在高丢包率网络中性能提升尤为明显。

2. 连接建立延迟:

   ​ 传统的 TCP + TLS 握手需要 2-3 RTT。HTTP/3 (QUIC) 通过 1-RTT 甚至 0-RTT 的连接建立，显著减少了初始连接的延迟。

3. 网络切换时的连接中断:

   ​ HTTP/1.x 和 HTTP/2 基于 TCP，当客户端 IP 地址改变时连接会中断。HTTP/3 的连接迁移特性解决了这个问题，提高了移动用户的体验。

4. 强制和现代化的加密:

   ​ 通过强制使用类似 TLS 1.3 的加密，提高了 Web 通信的整体安全性，并淘汰了过时的加密套件。

缺点

1. UDP 可能被防火墙或中间设备阻止:

   ​ 一些企业或网络环境中的防火墙和网络中间设备 (Middleboxes) 可能配置为阻止或限制 UDP 流量，特别是针对非标准端口或未知协议。这可能导致 HTTP/3 连接失败，需要回退到 HTTP/2 或 HTTP/1.1。

2. CPU 消耗可能更高:

   ​ QUIC 协议本身（包括加密、解密、拥塞控制、流管理等）的处理逻辑比 TCP 更复杂，尤其是在用户空间实现时，可能会比内核空间的 TCP 消耗更多的 CPU 资源。不过，随着优化的进行，这个问题正在得到改善。

3. 部署和普及需要时间:

   ​ 作为一个相对较新的协议，HTTP/3 的广泛部署需要服务器、客户端（浏览器）、操作系统、网络库以及网络基础设施（如 CDN、负载均衡器）的全面支持。虽然其支持度在快速增长，但仍需要时间才能达到 HTTP/2 的普及程度。

4. 拥塞控制算法的成熟度和一致性:

   ​ QUIC 允许更灵活的拥塞控制，但也意味着不同实现可能采用不同的算法（如Google的BBR现代拥塞控制算法），其在复杂网络环境下的表现和相互作用仍在研究和优化中。

5. 对网络调试和监控工具的挑战:

   ​ 由于 QUIC 流量是加密的，**传统的基于 TCP 的网络分析工具（如 Wireshark，如果无法获取解密密钥）**可能难以深入分析 QUIC 流量的细节。需要新的工具和方法来适应。

如何基于UDP实现一个类TCP的可靠性传输协议

前置

简单分析

先分析一下，UDP是一个不可靠的传输层协议，不可靠意味着它没有TCP实现可靠性的那些机制，我们先来回顾一下TCP为了实现可靠性传输提供了哪些机制（具体的TCP实现可靠性传输机制的介绍可以看我写的另一篇文章：TCP是如何实现可靠性传输的）：

1. 序列号和确认应答机制
2. 重传机制
   1. 超时重传
   2. 快速重传
3. 滑动窗口机制
   1. 拥塞窗口机制
   2. 流量控制机制
4. 连接管理机制
5. 校验和机制

但是，既然 TCP 天然支持可靠传输，为什么还需要基于 UDP 实现可靠传输呢？这不是重复造轮子吗？

所以，我们不仅要实现可靠性传输，还要解决TCP无法解决的问题

TCP协议的缺陷

• 升级 TCP 的工作很困难

  ​ TCP 协议栈通常是在操作系统的内核空间实现的，所以对TCP协议的修改、增加新特性或部署新的拥塞控制算法，通常需要更新整个操作系统的内核；而且大量的网络中间设备（防火墙、NAT 设备、负载均衡器等），这些设备可能对 TCP 头部或行为有特定的假设，任何关于TCP的改变可能会导致中间件出现错误，从而导致网络的崩溃；

• TCP 建立连接的延迟

  ​ 三次握手，这个过程至少需要 1.5 个网络往返时间 (RTT) 才能完成连接的建立。如果在此之上还需要进行 TLS (Transport Layer Security) 握手以建立安全连接 (HTTPS)，则通常还需要额外的 1-2 个 RTT（对于 TLS 1.2）。因此，建立一个安全的 TCP 连接总共可能需要 2-3.5 个 RTT，这是一个不小的时间开销，特别是针对高延迟的网络，连接建立延迟会非常显著。

• TCP 存在队头阻塞问题

  ​ TCP 是一个可靠的、按序传输的协议。这意味着如果 TCP 连接中的一个数据包在网络中丢失或延迟，发送方必须等待该数据包被成功重传并被接收方确认为止，接收方才能按顺序将后续的数据包交付给上层应用。即使后续的数据包已经到达接收方，它们也必须等待这个丢失的数据包；尤其在丢包率较高的网络（如无线网络、拥挤的网络）中，TCP 队头阻塞会显著降低多路复用协议（如 HTTP/2）的性能，因为一个流的问题会影响所有流。

• 网络迁移需要重新建立 TCP 连接

  ​ TCP 连接是通过一个四元组来唯一标识的：{源IP地址, 源端口号, 目标IP地址, 目标端口号}。当客户端设备的网络环境发生变化时（例如，手机从 Wi-Fi 网络切换到蜂窝移动网络，或者笔记本电脑在不同 Wi-Fi 热点间切换），客户端的 IP 地址通常会改变。由于 IP 地址是 TCP 连接标识的一部分，IP 地址的改变会导致原有的 TCP 连接失效和中断。此时，客户端必须与服务器重新建立一个新的 TCP 连接（包括三次握手和 TLS 握手），这会导致应用中断、延迟增加，并可能丢失之前的会话状态（除非应用层有特殊处理）。

QUIC 协议

前面已经介绍了TCP协议的缺陷，而在HTTP/3之前，又都是依赖TCP协议建立的，所以为了避免上述的问题，在HTTP/3版本中，抛弃了传输层的TCP协议，改用UDP作为HTTP/3的底层传输层协议，此时如何实现基于UDP的可靠性传输又成了一个问题，不过现在市面上已经有基于 UDP 协议实现的可靠传输协议的成熟方案了，那就是 QUIC 协议

QUIC 是如何实现可靠性传输的

QUIC 协议实现可靠性传输其实主要是对