计算机网络

计算机网络之HTTP篇（上）

编程Cookbook

• 39 min read
计算机网络之HTTP篇（上）

大家好，这里是编程Cookbook。本文详细介绍计算机网络中的HTTP协议相关的内容，包括单不限于HTTP各个版本及其优势、请求和响应、HTTPS等。

@[toc]

HTTP协议

HTTP 1.0、1.1、2.0和3.0有什么区别？

HTTP（HyperText Transfer Protocol）是用于Web通信的核心协议，历经多个版本的演进，旨在提升性能、安全性和可靠性。以下是HTTP 1.0、1.1、2.0和3.0的演变和进化过程：

1. HTTP 1.0

发布时间：1996年（RFC 1945）

HTTP 1.0是第一个正式的HTTP版本，主要特点如下：

  1. 无状态、无连接：每个请求-响应都需要单独建立TCP连接，请求完成后即关闭连接，导致开销较大。
  2. 默认不支持持久连接：每次请求都要进行TCP三次握手，增加了延迟。
  3. 请求/响应模型：
    • 采用纯文本格式，使用GET、POST、HEAD等基本方法。
    • 服务器必须等待前一个请求完成才能处理下一个请求（队头阻塞问题）。
  4. 缓存控制有限：
    • 缓存控制主要依赖于 Expires 头字段，该字段用于指定资源的绝对过期时间，例如：
      Expires: Wed, 20 Mar 2025 12:00:00 GMT
    • 客户端通常无法有效判断资源是否需要重新请求。

缺点：

  • 连接效率低，每次请求都要重新建立TCP连接。
  • 无法进行并行请求，影响性能。
  • 服务器端没有缓存机制，带宽利用率低。

2. HTTP 1.1

发布时间：1997年（RFC 2068，后续更新RFC 2616）

HTTP 1.1是Web发展的重要里程碑，针对HTTP 1.0的性能问题进行了多项优化：

  1. 支持持久连接（Persistent Connection）：
    • 默认开启TCP长连接（Connection: keep-alive）。
    • 允许在同一个TCP连接中传输多个请求，减少连接建立的开销。
  2. 支持流水线（Pipelining）：
    • 允许客户端并行发送多个请求（但服务器仍需按顺序响应）。
    • 仍然存在 队头阻塞（Head-of-line Blocking） 问题，因为一个请求处理慢会阻塞后续请求。
  3. 增加缓存机制：
    • 新增Cache-Control字段，支持max-age（资源多少秒内有效）、no-cache（即使客户端本地有缓存副本，也不能直接使用，必须向服务器发送请求，询问该资源是否有更新）、no-store（禁止缓存，每次都请求最新数据）等控制缓存行为。
  4. 分块传输编码（Chunked Transfer Encoding）：
    • 允许服务器分块发送数据，适用于大文件传输。
  5. 支持Host字段：
    • HTTP 1.0没有Host字段，导致一个IP只能提供一个网站。
    • HTTP 1.1通过Host字段支持虚拟主机（Virtual Host），使得一个服务器可以托管多个网站。例如，example.com 和 another.com 可以共享同一个 IP 地址，在 HTTP 请求中通过 Host 字段区分不同的网站。

缺点：

  • 队头阻塞问题仍然存在（尽管流水线请求可以提高并行度，但服务器仍按顺序处理请求）。
  • 复杂的TCP握手和慢启动机制仍然影响性能。

3. HTTP 2.0

发布时间：2015年（RFC 7540）

HTTP 2.0在SPDY协议的基础上进行了优化，引入了二进制帧、多路复用、头部压缩和服务器推送等机制，大幅提升了性能：

  1. 二进制分帧（Binary Framing）：
    • HTTP 1.x使用纯文本解析，这意味着请求和响应的每个部分（如请求行、头部、正文）都是可读的字符串。HTTP 2.0改为二进制格式，将数据分成小的帧进行传输，使得解析更高效，
    • 数据被封装成帧（Frame），提高解析和传输效率。
  2. 多路复用（Multiplexing）：
    • 一个TCP连接中可同时并行处理多个请求，每个请求通过不同的流ID标识。
    • 解决了HTTP 1.1的队头阻塞问题，避免了多个请求串行处理的开销。
  3. 头部压缩（Header Compression）：
    • 采用HPACK算法进行头部压缩，减少冗余数据（重复的头部字段），提高带宽利用率。
  4. 服务器推送（Server Push）：
    • 服务器可以主动推送客户端可能需要的资源（如CSS、JS），减少额外的请求次数。
  5. 优先级和流控制：
    • 允许客户端指定请求的优先级，使得关键资源可以优先加载。

缺点：

  • TCP层面仍然存在队头阻塞：
    • HTTP 2.0本身解决了应用层的队头阻塞，但由于所有请求仍共用一个TCP连接，如果TCP丢包，整个连接上的所有请求都会受到影响。

HTTP/2 仍然基于 TCP 协议，而 TCP 是面向流的协议，要求数据按顺序到达。如果 TCP 数据包丢失或乱序，TCP 层会等待丢失的数据包重传，导致后续数据被阻塞。
HTTP/3 通过使用 QUIC 协议 彻底解决了 TCP 层的队头阻塞问题：基于 UDP，不再依赖 TCP。每个流独立传输，丢失的数据包只会影响对应的流，不会阻塞其他流。

4. HTTP 3.0

发布时间：2022年（RFC 9114）

HTTP 3.0基于QUIC协议，彻底解决了TCP的队头阻塞问题，提供了更快、更稳定的传输：

  1. 基于UDP的QUIC协议：
    • HTTP 3.0不再依赖TCP，改用UDP【QUIC（Quick UDP Internet Connections）】。
    • 解决了TCP的队头阻塞问题，即使某个请求丢包，不会影响其他请求。
  2. 0-RTT握手：
    • QUIC协议基于UDP，可实现0-RTT连接建立，减少首次请求的延迟。
    • 之前的TCP+TLS通常需要1~3次往返（RTT）才能建立连接，而QUIC可以在首次请求时就发送数据。
  3. 内置TLS 1.3：
    • HTTP 3.0强制使用TLS 1.3进行加密通信，提升安全性。
    • 由于QUIC集成TLS加密，减少了额外的TLS握手延迟。
  4. 改进的流控制：
    • QUIC中的流是独立的，某个流的丢包不会影响其他流的数据传输，提高了并发性能。
  5. 更快的重连：
    • QUIC支持连接迁移，即使设备IP发生变化（如WiFi切换到4G），连接仍可保持不中断，而TCP需要重新建立连接。

缺点：

  • QUIC基于UDP，部分老旧网络设备或防火墙可能不兼容。
  • 服务器端实现复杂度提高，需要支持QUIC协议栈。
  • 更高的CPU占用，由于QUIC自身需要处理丢包、流量控制等，而TCP的优化已经非常成熟。

总结对比

版本 主要特点 连接复用 队头阻塞 传输方式 加密
HTTP 1.0 每次请求建立新连接 ❌ 严重 纯文本 ❌
HTTP 1.1 持久连接、流水线 ❌ 仍然存在 纯文本 ❌
HTTP 2.0 二进制分帧、多路复用、服务器推送、头部压缩 ✅ TCP层仍存在 二进制 ✅（可选）
HTTP 3.0 基于QUIC、UDP传输、无队头阻塞、TLS1.3协议、0-RTT ✅ ❌（彻底解决） 二进制 ✅（强制TLS 1.3）

结论

  • HTTP 1.0 → 1.1：引入长连接和缓存控制，提高效率。
  • HTTP 1.1 → 2.0：二进制帧、多路复用、头部压缩等，解决应用层队头阻塞。
  • HTTP 2.0 → 3.0：基于QUIC（UDP），彻底解决TCP队头阻塞，提高传输速度。

HTTP 3.0已经成为Web未来发展的趋势，尤其适用于高延迟、不稳定网络环境（如移动设备），大幅提升Web体验。

HTTP/1.1的管道化（Pipelining）是什么？

HTTP/1.1的管道化（Pipelining） 是一种优化技术，允许在同一个TCP连接上并行发送多个HTTP请求，而无需等待每个请求的响应。

作用：

  • 在传统的HTTP/1.0中，每个请求/响应必须按顺序进行：发送一个请求，等待响应，然后才能发送下一个请求。
  • HTTP/1.1的管道化通过允许多个请求同时发送，从而减少了等待时间和TCP连接的开销，理论上提高了请求的吞吐量。

工作原理：

  • 在一个TCP连接上，客户端可以连续发送多个HTTP请求，而不需要等待每个请求的响应。也就是说，多个请求可以"排队"（pipelining），而服务端则会按顺序返回响应。
  • 管道化请求和响应都是基于同一个TCP连接完成的，客户端发送请求后，不需要等待每个响应返回就可以继续发送下一个请求。

限制：

  • 响应顺序问题：HTTP/1.1中的管道化请求必须按顺序返回响应。即使某些请求的处理完成得较快，后面的请求也必须等到前面的请求响应后才能发送，造成头部阻塞（Head-of-Line Blocking）问题。
  • 服务端支持：并非所有的服务器和中间代理都支持管道化。
  • 浏览器支持：很多现代浏览器已经不再完全支持HTTP/1.1的管道化，因为它容易导致性能瓶颈。

总结：
HTTP/1.1的管道化尝试通过在同一连接上并行发送多个请求来提高效率，但由于顺序和阻塞问题，它并没有广泛解决性能瓶颈。

HTTP 2.0

HTTP/2 通过二进制分帧、多路复用、头部压缩、服务器推送和优先级与流控制等特性，显著提升了 Web 性能。这些改进使得 HTTP/2 成为现代 Web 应用的重要基础，特别是在高并发和高延迟的场景下。然而，HTTP/2 仍然依赖 TCP，因此在某些情况下（如网络丢包）性能可能受限，这也是 HTTP/3 进一步改进的方向。

1. 二进制分帧（Binary Framing）

核心概念：

  • HTTP/2 将通信数据分解为更小的二进制帧（Frame），每个帧属于一个特定的流（Stream）。
  • 帧是 HTTP/2 的最小通信单位，所有请求和响应都被拆分为多个帧进行传输。

帧的结构：

  • 每个帧包含以下字段：
    • 长度（Length）：帧的长度。
    • 类型（Type）：帧的类型【如 HEADERS （传输 HTTP 头部信息）、DATA（ 传输 HTTP 请求或响应的主体数据）、PRIORITY （设置流的优先级）等】。
    • 标志（Flags）：用于控制帧的行为（如是否结束流）。
    • 流标识符（Stream ID）：标识帧所属的流。
    • 帧负载（Payload）：帧的实际数据。

优势：

  • 高效解析：二进制格式比 HTTP/1.x 的文本格式更紧凑，解析速度更快。
  • 灵活性：帧可以乱序传输，接收方根据流 ID 重新组装。
  • 扩展性：新的帧类型可以通过扩展协议支持更多功能。

示例：

HTTP/1.x（如 HTTP/1.1）使用 纯文本（明文）格式 传输请求和响应，所有内容以人类可读的字符形式表示。

示例（HTTP/1.1 请求）：

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

HTTP/2 将报文转换为 二进制编码帧（Binary Frames），所有数据以紧凑的二进制字节流传输。

  • 一个 HTTP 请求可能被拆分为：
    • 一个 HEADERS 帧（包含请求头）。
    • 多个 DATA 帧（包含请求体）。
  • 这些帧可以在同一个连接上并行传输。

示例（HTTP/2 帧结构）：


+-----------------------------------------------+
| Length (24 bits)                              |  # 帧长度
+---------------+---------------+---------------+
| Type (8 bits) | Flags (8 bits)                |  # 帧类型和标志
+-+-------------+---------------+---------------+
|R| Stream Identifier (31 bits)                |  # 流标识符
+=+=============================================+
| Frame Payload (0 or more bytes)               |  # 帧数据
+-----------------------------------------------+

2. 多路复用（Multiplexing）

核心概念：

  • HTTP/2 允许在 同一个 TCP 连接上同时传输多个请求和响应。
  • 每个请求和响应都被分配一个唯一的流 ID，用于标识和区分。

工作原理：

  • 客户端和服务器可以在一个连接上同时发送多个流的帧。
  • 帧根据流 ID 进行区分，接收方将帧重新组装为完整的请求或响应。
  • 详细介绍如下：
    1. 分帧（Frame）：HTTP/2将数据分为多个小的“帧”（frame）。每个帧都有一个标识符，可以属于不同的请求和响应。请求和响应的数据分解成多个小帧，然后通过单一的连接进行传输。
    2. 流（Stream）：每个请求/响应都有一个唯一的流标识符。HTTP/2允许同时在多个流中发送数据，因此可以在一个连接上处理多个请求/响应。
    3. 无顺序依赖：不同于HTTP/1.1的管道化，HTTP/2的多路复用允许请求和响应完全独立地并行处理，避免了头部阻塞问题。响应的顺序不再受到请求发送顺序的限制。
    4. 优先级和流控制：HTTP/2支持请求和响应的优先级控制，客户端可以向服务器声明某些请求的优先级，以便优化资源的调度。

优势：

  • 解决队头阻塞：HTTP/1.1 中，一个慢请求会阻塞后续请求。HTTP/2 中，多个请求可以并行处理。
  • 减少连接数：HTTP/1.1 需要多个 TCP 连接来并行处理请求，而 HTTP/2 只需一个连接。
  • 降低延迟：在高延迟网络中，多路复用显著减少了请求的等待时间。

缺点：

  • TCP层面仍然存在队头阻塞：
    • HTTP 2.0本身解决了应用层的队头阻塞，但由于所有请求仍共用一个TCP连接，如果TCP丢包，整个连接上的所有请求都会受到影响。

示例：

  • 客户端同时请求 HTML、CSS 和 JavaScript 文件。
  • 服务器在一个连接上并行发送这些文件的帧，客户端根据流 ID 重新组装。

3. 头部压缩（Header Compression）

核心概念：

  • HTTP/2 使用 HPACK 算法对 HTTP 头部进行压缩。
  • 头部字段被编码为索引值，减少了重复传输。

HPACK 的工作原理：

  • 静态表：包含 61 个常见的 HTTP 头部字段（如 :method、:path 等）。
  • 动态表：在连接过程中动态更新的表，用于存储重复出现的头部字段。
  • 哈夫曼编码：对头部值进行压缩。

优势：

  • 减少冗余：例如，Cookie 和 User-Agent 等头部字段只需发送一次，后续请求可以复用。
  • 节省带宽：头部压缩显著减少了数据传输量，特别是在高并发场景下。

示例：

  • 第一次请求：
    • 头部：:method: GET, :path: /index.html, user-agent: Chrome
    • 动态表更新为：[:method: GET, :path: /index.html, user-agent: Chrome]
  • 第二次请求：
    • 头部：:method: GET, :path: /style.css, user-agent: Chrome
    • 只需发送 :path: /style.css，其他字段从动态表中引用。

4. 服务器推送（Server Push）

核心概念：

  • 服务器可以在客户端请求之前主动推送资源。
  • 推送的资源与原始请求共享同一个连接。

工作原理：

  • 当服务器收到一个请求时，可以预测客户端可能需要其他资源。
  • 服务器发送一个 PUSH_PROMISE 帧，告知客户端即将推送的资源。
  • 客户端可以选择接受或拒绝推送的资源。

优势：

  • 减少延迟：客户端无需额外请求资源，服务器可以提前推送。
  • 优化加载：例如，推送 CSS 和 JavaScript 文件，减少页面渲染时间。

示例：

  • 客户端请求 index.html。
  • 服务器推送 style.css 和 script.js，因为这些资源通常与 HTML 文件一起使用。

5. 优先级和流控制

优先级（Prioritization）：

  • 核心概念：客户端可以为每个流设置优先级，服务器根据优先级处理请求。
  • 优先级字段：
    • 流依赖（Stream Dependency）：指定流的依赖关系。
    • 权重（Weight）：指定流的相对优先级。
  • 优势：
    • 确保关键资源（如 CSS 和 JavaScript）优先加载。
    • 优化页面渲染性能。

流控制（Flow Control）：

  • 核心概念：HTTP/2 提供了基于流的流量控制机制。
  • 工作原理：
    • 每个流都有一个流量控制窗口，用于限制发送方可以发送的数据量。
    • 接收方可以动态调整窗口大小。
  • 优势：
    • 防止一端发送过多数据导致另一端过载。
    • 确保每个流都能公平使用带宽。

示例：

  • 客户端请求 HTML、CSS 和 JavaScript 文件，并为 CSS 文件设置更高的优先级。
  • 服务器优先发送 CSS 文件，确保页面尽快渲染。

HTTP 3.0

HTTP 3.0 基于 QUIC 协议，通过以下改进显著提升了传输性能：

  1. 基于 UDP：解决了 TCP 的队头阻塞问题，提供了更低的延迟和更高的并发性能。
  2. 内置 TLS 1.3：强制加密通信，提升了安全性。
  3. 0-RTT 握手：减少了首次请求的延迟，提升了用户体验。
  4. 改进的流控制：独立的流控制机制，确保某个流的丢包不会影响其他流。
  5. 连接迁移：支持无缝切换网络，提升了移动端体验。

HTTP 3.0 是未来 Web 通信的重要方向，特别是在高延迟和高丢包率的网络环境中，它能够提供更快、更稳定的传输性能。

1. 基于 UDP 的 QUIC 协议

核心概念：

  • HTTP/3 不再依赖 TCP，而是基于 QUIC（Quick UDP Internet Connections） 协议。
  • QUIC 运行在 UDP 之上，结合了 TCP 的可靠性 和 UDP 的灵活性。

工作原理：

  1. UDP 作为传输层：
    • QUIC 使用 UDP 作为底层协议，避免了 TCP 的连接建立和维护开销。
    • UDP 是无连接的，QUIC 在应用层实现了可靠性、拥塞控制和流量控制。
  2. 多路复用和独立流：
    • QUIC 将数据分为多个独立的流（Stream），每个流都有自己的序列号和流量控制。
    • 即使某个流发生丢包，其他流的数据传输不会受到影响。
  3. 快速重传和恢复：
    • QUIC 使用更高效的重传机制，通过数据包编号（Packet Number）和确认机制（ACK）快速检测和恢复丢包。

优势：

  • 解决 TCP 队头阻塞问题：独立的流控制确保某个流的丢包不会影响其他流。
  • 更低的延迟：UDP 的无连接特性减少了协议开销。
  • 更好的拥塞控制：QUIC 实现了更灵活的拥塞控制算法。

示例：

  • 在 HTTP/2 中，TCP 层的丢包会导致整个连接阻塞。
  • 在 HTTP/3 中，只有发生丢包的流会受到影响，其他流不受影响。

2. 内置 TLS 1.3

核心概念：

  • QUIC 集成了 TLS 1.3，强制使用加密通信。
  • TLS 1.3 是当前最安全的加密协议，提供了更强的安全性和更快的握手速度。

工作原理：

  1. TLS 1.3 握手：
    • QUIC 将 TLS 1.3 握手与连接建立合并，减少了额外的握手延迟。
    • TLS 1.3 支持 1-RTT 和 0-RTT 握手。
  2. 加密与解密：
    • QUIC 使用 TLS 1.3 加密所有通信数据，防止中间人攻击和数据篡改。
    • 加密密钥在握手过程中动态生成。
  3. 会话恢复：
    • 通过会话票据（Session Ticket）实现快速会话恢复，支持 0-RTT 数据传输。

优势：

  • 安全性提升：强制加密防止了中间人攻击和数据篡改。
  • 减少延迟：TLS 1.3 的握手过程更高效。

示例：

  • 在 HTTP/2 中，TLS 握手和 TCP 握手是分开的，增加了延迟。
  • 在 HTTP/3 中，TLS 1.3 直接集成到 QUIC 协议中，握手更快。

3. 0-RTT 握手

核心概念：

  • QUIC 支持 0-RTT（零往返时间） 连接建立。
  • 客户端可以在首次请求时直接发送数据，无需等待握手完成。

工作原理：

  1. 首次连接（1-RTT）：
    • 客户端和服务器需要完成一次完整的 TLS 1.3 握手。
    • 服务器会生成一个会话票据（Session Ticket），客户端可以缓存该票据。
  2. 后续连接（0-RTT）：
    • 客户端使用缓存的会话票据，直接发送数据。
    • 服务器验证票据后，立即开始处理请求。
  3. 安全性：
    • 0-RTT 数据可能会受到重放攻击，因此 QUIC 限制了 0-RTT 数据的使用范围（如仅用于幂等请求）。

优势：

  • 减少延迟：0-RTT 显著减少了首次请求的延迟。
  • 提升用户体验：页面加载速度更快。

示例：

  • 用户首次访问网站时，需要 1-RTT 完成握手。
  • 用户再次访问时，可以直接发送数据，无需等待握手。

4. 改进的流控制

核心概念：

  • QUIC 中的流是独立的，每个流都有自己的流量控制窗口。
  • 某个流的丢包不会影响其他流的数据传输。

工作原理：

  1. 独立的流控制：
    • 每个流都有自己的流量控制窗口，客户端和服务器可以动态调整窗口大小。
    • 即使某个流发生丢包，其他流仍可以继续传输。
  2. 多路复用：
    • QUIC 支持在同一个连接上并行传输多个流。
    • 每个流的数据包可以乱序到达，接收方根据流 ID 重新组装。
  3. 快速重传：
    • QUIC 使用数据包编号（Packet Number）和确认机制（ACK）快速检测和恢复丢包。

优势：

  • 更高的并发性能：多个流可以并行传输，互不干扰。
  • 更灵活的流量控制：动态调整窗口大小，适应不同的网络环境。

示例：

  • 在 HTTP/2 中，TCP 层的丢包会导致整个连接阻塞。
  • 在 HTTP/3 中，只有发生丢包的流会受到影响，其他流不受影响。

5. 连接迁移

核心概念：

  • QUIC 支持 连接迁移，即使设备的 IP 地址发生变化，连接仍可以保持不中断。
  • 这是通过使用连接 ID（Connection ID） 而不是 IP 地址来标识连接实现的。

工作原理：

  1. 连接 ID：
    • QUIC 使用连接 ID 来标识连接，而不是依赖 IP 地址和端口。
    • 即使设备的 IP 地址发生变化，连接 ID 保持不变。
  2. 无缝迁移：
    • 当设备切换网络（如从 WiFi 切换到 4G）时，QUIC 可以无缝迁移连接。
    • 客户端和服务器通过连接 ID 重新建立通信。
  3. 安全性：
    • 连接迁移过程中，TLS 1.3 加密密钥保持不变，确保通信安全。

优势：

  • 无缝切换网络：提升移动端用户体验。
  • 提升可靠性：在网络不稳定的环境中，连接不会中断。

示例：

  • 用户正在观看视频，从 WiFi 切换到移动数据网络。
  • 在 TCP 中，连接会中断，视频需要重新加载。
  • 在 QUIC 中，连接可以无缝迁移，视频继续播放。

QUIC 协议的应用层实现

QUIC 在应用层实现了以下关键功能：

  1. 可靠性：
    • 通过数据包编号、确认机制和快速重传，确保数据完整传输。
  2. 拥塞控制：
    • 使用基于丢包的拥塞控制算法和带宽估计，避免网络过载。
  3. 流量控制：
    • 通过流级别和连接级别的流量控制，防止接收方缓冲区溢出。

这些机制使 QUIC 能够在 UDP 的基础上提供类似 TCP 的可靠性和性能，同时避免了 TCP 的队头阻塞问题。QUIC 的设计使其特别适合高延迟和高丢包率的网络环境，为 HTTP/3 提供了更快、更稳定的传输基础。

1. 可靠性

核心问题：

  • UDP 本身是不可靠的，数据包可能会丢失、重复或乱序到达。
  • QUIC 需要在应用层实现类似 TCP 的可靠性机制，确保数据完整传输。

实现原理：

  1. 数据包编号（Packet Number）：
    • QUIC 为每个数据包分配一个唯一的编号（Packet Number）。
    • 接收方通过数据包编号检测丢包和乱序。
  2. 确认机制（ACK）：
    • 接收方会定期发送确认帧（ACK Frame），告知发送方已成功接收的数据包编号。
    • 发送方根据 ACK 帧判断是否需要重传丢失的数据包。
  3. 快速重传：
    • 如果发送方检测到某个数据包丢失（如未收到对应的 ACK），会立即重传该数据包。
    • QUIC 使用更高效的重传算法，减少重传延迟。

优势：

  • 确保数据完整传输：即使 UDP 数据包丢失，QUIC 也能通过重传机制恢复数据。
  • 减少延迟：快速重传机制降低了丢包对性能的影响。

2. 拥塞控制

核心问题：

  • 网络拥塞会导致数据包丢失和延迟增加。
  • QUIC 需要在应用层实现拥塞控制机制，避免网络过载。

实现原理：

  1. 基于丢包的拥塞控制：
    • QUIC 使用类似于 TCP 的拥塞控制算法（如 Cubic 或 BBR）。
    • 当检测到数据包丢失时，QUIC 会减少发送速率，避免进一步加剧网络拥塞。
  2. 带宽估计：
    • QUIC 通过测量往返时间（RTT）和数据包丢失率，动态估计可用带宽。
    • 根据带宽估计调整发送速率。
  3. 平滑速率调整：
    • QUIC 使用更平滑的速率调整算法，避免 TCP 的锯齿状速率波动。
    • 这有助于提高网络利用率和稳定性。

优势：

  • 避免网络过载：通过动态调整发送速率，QUIC 可以有效避免网络拥塞。
  • 提高网络利用率：更平滑的速率调整算法提高了带宽利用率。

3. 流量控制

核心问题：

  • 接收方的处理能力有限，如果发送方发送数据过快，可能导致接收方缓冲区溢出。
  • QUIC 需要在应用层实现流量控制机制，确保发送方不会发送过多数据。

实现原理：

  1. 基于流的流量控制：
    • QUIC 为每个流（Stream）单独设置流量控制窗口。
    • 接收方通过发送窗口更新帧（WINDOW_UPDATE Frame），告知发送方当前可接收的数据量。
  2. 动态窗口调整：
    • 接收方可以根据自身的处理能力动态调整流量控制窗口大小。
    • 发送方根据窗口大小限制发送的数据量。
  3. 连接级别的流量控制：
    • 除了流级别的流量控制，QUIC 还实现了连接级别的流量控制。连接级别（Connection-level）在 QUIC 协议中指的是针对整个网络连接的流量控制机制，而不仅仅是单个数据流。
    • 这确保整个连接的数据传输不会超过接收方的处理能力。

优势：

  • 防止缓冲区溢出：流量控制机制确保发送方不会发送过多数据。
  • 提高资源利用率：动态窗口调整机制提高了网络和接收方的资源利用率。

流量控制与拥塞控制的对比

特性 流量控制（Flow Control） 拥塞控制（Congestion Control）
目标 防止发送方发送速率超过接收方的处理能力 防止网络中的数据流量超过网络的承载能力
关注点 发送方和接收方之间的速率匹配 网络中多个发送方和接收方之间的资源竞争
实现方式 滑动窗口、停止-等待协议 慢启动、拥塞避免、快速重传、快速恢复
应用场景 点对点通信 网络层通信
示例 TCP 中的滑动窗口 TCP 中的慢启动和拥塞避免
  • 流量控制 关注的是发送方和接收方之间的速率匹配，防止接收方缓冲区溢出。
  • 拥塞控制 关注的是网络中的资源竞争，防止网络拥塞。
  • 两者在 TCP 协议中协同工作，确保数据能够高效、可靠地传输。

0-RTT 握手

0-RTT 握手 是 QUIC 协议（或者说是TSL 1.3协议）中的一项重要特性，它允许客户端在首次请求时直接发送数据，而无需等待完整的握手过程完成。这种机制显著减少了连接建立的延迟，特别是在需要频繁建立连接的场景中（如 Web 浏览）。尽管 0-RTT 存在一定的安全限制，但它在提升用户体验和减少延迟方面具有显著优势，特别是在需要频繁建立连接的场景中。以下是 0-RTT 握手 的详细介绍：

QUIC 不需要三次握手：因为它基于 UDP，并且内置了 TLS 1.3，将握手过程优化为 1-RTT 或 0-RTT。

TLS 1.3 是 TLS 协议的最新版本，它对握手过程进行了大幅优化：

  • 简化握手：
    • TLS 1.3 删除了不必要的步骤（如密钥交换算法的协商），将握手过程简化为 1-RTT。
  • 0-RTT 支持：
    • TLS 1.3 支持 0-RTT 模式，允许客户端在首次请求时直接发送数据。

1. 什么是 RTT？

  • RTT（Round-Trip Time） 是指数据包从客户端发送到服务器，再从服务器返回客户端所需的时间。
  • 在传统的 TCP + TLS 握手过程中，通常需要 1~3 次 RTT 才能建立安全连接并开始传输数据。

2. 0-RTT 握手的核心思想

  • 0-RTT 握手 的目标是减少连接建立的延迟，允许客户端在首次请求时直接发送数据。
  • 这是通过缓存和复用之前的会话信息（如 TLS 会话票据）来实现的。

3. 0-RTT 握手的工作原理

0-RTT 握手 的实现依赖于 1-RTT 握手 的首次连接。具体来说，0-RTT 握手是建立在 首次 1-RTT 握手 的基础上的，只有在首次连接完成后，后续连接才能使用 0-RTT 握手。以下是详细的解释：

首次连接（1-RTT）

  1. 客户端发起连接：
    • 客户端发送一个 ClientHello 消息，包含支持的加密套件和协议版本。
  2. 服务器响应：
    • 服务器回复一个 ServerHello 消息，选择加密套件并生成会话票据（Session Ticket）。
    • 服务器还会发送公钥和证书，用于后续的密钥交换。
  3. 密钥交换 & 会话票据缓存：
    • 客户端和服务器通过密钥交换算法（如 ECDHE）生成共享密钥。
    • 服务器返回的会话票据（Session Ticket）会被客户端缓存，以便在后续连接（0-RTT）中使用。

后续连接（0-RTT）/ 下一次连接到同一服务器时

  1. 客户端发起连接：
    • 客户端使用缓存的会话票据，直接发送 ClientHello 消息和 0-RTT 数据。
    • 0-RTT 数据是客户端希望在握手完成之前发送的应用数据（如 HTTP 请求）。
  2. 服务器验证票据：
    • 服务器验证会话票据的有效性。
    • 如果票据有效，服务器立即开始处理 0-RTT 数据。
  3. 完成握手：
    • 服务器回复 ServerHello 消息，并继续完成剩余的握手步骤。
    • 客户端和服务器最终确认连接的安全性。

4. 0-RTT 的优势

  1. 减少延迟：
    • 客户端可以在首次请求时直接发送数据，无需等待握手完成。
    • 这显著减少了页面加载时间，特别是在高延迟网络中。
  2. 提升用户体验：
    • 用户感知的响应速度更快，特别是在需要频繁建立连接的场景中（如 Web 浏览）。
  3. 高效复用连接：
    • 通过缓存会话票据，客户端可以快速恢复之前的连接状态，减少重复握手开销。

5. 0-RTT 的局限性

  1. 安全性限制：
    • 0-RTT 数据可能会受到重放攻击（Replay Attack）。重放攻击是一种网络攻击方式，攻击者通过截获合法通信中的数据包，并将其重新发送到目标系统，以欺骗系统执行已经发生过的操作。
    • 为了防止重放攻击，QUIC 限制了 0-RTT 数据的使用范围（如仅用于幂等请求）。
  2. 依赖缓存：
    • 0-RTT 依赖于客户端和服务器之间的会话缓存。
    • 如果缓存失效（如服务器重启或票据过期），客户端需要重新进行完整的 1-RTT 握手。

6. 0-RTT 的应用场景

  1. Web 浏览：
    • 用户在访问网站时，可以直接发送 HTTP 请求，无需等待握手完成。
  2. API 调用：
    • 客户端可以快速发送 API 请求，减少延迟。
  3. 实时通信：
    • 在实时通信场景中（如视频会议），0-RTT 可以减少连接建立的延迟。

7. 示例

首次连接（1-RTT）

  1. 客户端访问 https://example.com。
  2. 客户端和服务器完成完整的 TLS 1.3 握手（1-RTT）。
  3. 服务器生成会话票据并发送给客户端。

后续连接（0-RTT）/ 下一次连接 到同一服务器时

  1. 客户端再次访问 https://example.com。
  2. 客户端使用缓存的会话票据，直接发送 HTTP 请求（0-RTT 数据）。
  3. 服务器验证票据后，立即处理请求并返回响应。

TLS系列协议

TLS（Transport Layer Security，传输层安全协议） 是一组用于保护网络通信安全的协议，旨在为数据传输提供加密、认证和完整性保护。TLS 是 SSL（Secure Sockets Layer）的继任者，广泛应用于 HTTPS、电子邮件、即时通讯等场景。以下是 TLS 系列协议的简要介绍：

1. SSL（Secure Sockets Layer）

  • 发布时间：1994 年（SSL 1.0 未发布，SSL 2.0 于 1995 年发布）。
  • 特点：
    • 由 Netscape 开发，是 TLS 的前身。
    • 提供了基本的加密和认证功能。
  • 问题：
    • SSL 2.0 和 SSL 3.0 存在严重的安全漏洞（如 POODLE 攻击），已被弃用。

2. TLS 1.0

  • 发布时间：1999 年。
  • 特点：
    • 基于 SSL 3.0，但修复了 SSL 3.0 的一些安全问题。
    • 支持 RSA 密钥交换和多种加密算法（如 3DES、RC4）。
  • 问题：
    • 仍然存在一些安全漏洞（如 BEAST 攻击）。
    • 逐渐被淘汰。

3. TLS 1.1

  • 发布时间：2006 年。
  • 特点：
    • 修复了 TLS 1.0 的一些安全问题（如 CBC 模式攻击）。
    • 引入了显式 IV（初始化向量）以防止 BEAST 攻击。
  • 问题：
    • 仍然使用一些不安全的加密算法（如 RC4）。
    • 逐渐被淘汰。

4. TLS 1.2

  • 发布时间：2008 年。
  • 特点：
    • 支持更安全的加密算法（如 AES-GCM、SHA-256）。
    • 引入了更灵活的扩展机制。
    • 广泛使用，是目前最普及的 TLS 版本。
  • 问题：
    • 仍然支持一些不安全的特性（如 RSA 密钥交换、SHA-1）。
    • 握手过程较慢（需要 2 次往返）。

5. TLS 1.3

  • 发布时间：2018 年。
  • 特点：
    • 更强的安全性：移除了不安全的加密算法（如 RSA 密钥交换、SHA-1），默认支持前向安全性。
    • 更快的握手：支持 1-RTT 和 0-RTT 握手，显著减少了连接延迟。
    • 简化的协议：移除了冗余特性，使协议更简洁、更易于实现。
  • 优势：
    • 当前最安全的 TLS 版本，被广泛应用于 HTTPS、QUIC 协议等场景。

TLS 系列协议的演进总结

版本 发布时间 主要特点 问题与局限性
SSL 2.0 1995 提供了基本的加密和认证功能。 存在严重安全漏洞，已被弃用。
SSL 3.0 1996 修复了 SSL 2.0 的一些问题。 存在 POODLE 攻击等漏洞，已被弃用。
TLS 1.0 1999 基于 SSL 3.0，修复了一些安全问题。 存在 BEAST 攻击等漏洞，逐渐被淘汰。
TLS 1.1 2006 修复了 TLS 1.0 的 CBC 模式攻击。 仍然使用不安全的算法，逐渐被淘汰。
TLS 1.2 2008 支持更安全的加密算法（如 AES-GCM），广泛使用。 仍然支持不安全的特性，握手较慢。
TLS 1.3 2018 移除不安全算法，支持 1-RTT 和 0-RTT 握手，提供更强的安全性和更快性能。 需要客户端和服务器同时支持。

总结

TLS 系列协议从 SSL 发展到 TLS 1.3，逐步增强了安全性和性能。TLS 1.3 是当前最先进的版本，提供了更强的加密、更快的握手速度和更简洁的协议设计，已成为互联网通信安全的标准。

TLS 1.2 和 TLS 1.3

TLS 1.2 和 TLS 1.3 是 传输层安全协议（Transport Layer Security, TLS） 的两个重要版本。TLS 1.2 是目前广泛使用的版本，而 TLS 1.3 是最新的版本，提供了更强的安全性和更快的性能。以下是它们的详细介绍和对比：

1. TLS 1.2

发布时间：2008 年。

主要特点

  1. 支持现代加密算法：
    • 支持 AES-GCM、AES-CBC、SHA-256 等现代加密算法。
    • 移除了不安全的算法（如 MD5、SHA-1 逐渐被淘汰）。
  2. 灵活的扩展机制：
    • 支持 SNI（Server Name Indication），允许在同一 IP 地址上托管多个 HTTPS 网站。
    • 支持 ALPN（Application-Layer Protocol Negotiation），用于协商应用层协议（如 HTTP/2）。
  3. 前向安全性（Forward Secrecy）：
    • 支持 ECDHE（椭圆曲线迪菲-赫尔曼密钥交换），确保即使服务器的私钥泄露，之前的通信记录也无法被解密。
  4. 广泛兼容性：
    • 目前最广泛使用的 TLS 版本，几乎所有现代浏览器和服务器都支持 TLS 1.2。

握手过程

第 1 次往返（RTT-1）

  1. ClientHello（客户端 → 服务器）

    • 客户端发送 支持的加密套件、TLS 版本、随机数（Client Random） 等信息。

  2. ServerHello（服务器 → 客户端）

    • 服务器选择 TLS 版本、加密套件，返回 随机数（Server Random）。
    • 服务器发送 Certificate（证书）。
    • 若使用 DHE/ECDHE，则发送 ServerKeyExchange。
    • 服务器发送 ServerHelloDone，表示第一轮交互完成。

RTT-1 结束（客户端收到 ServerHelloDone）

第 2 次往返（RTT-2）

  1. ClientKeyExchange（客户端 → 服务器）

    • 客户端发送 密钥交换参数（若使用 RSA，则是预主密钥；若使用 ECDHE，则是公钥）。
    • 发送 ChangeCipherSpec（表示后续通信将加密）。
    • 发送 Finished（基于握手计算出的 MAC，确保握手完整性）。

  2. ServerFinished（服务器 → 客户端）

    • 服务器收到 ClientKeyExchange 后，计算会话密钥。
    • 服务器发送 ChangeCipherSpec（表示后续通信加密）。
    • 服务器发送 Finished，确保握手完整性。

RTT-2 结束（客户端收到 ServerFinished）

问题与局限性

  1. 握手延迟：
    • 需要 2 次往返（2-RTT）才能完成握手，增加了连接建立的延迟。
  2. 支持不安全的特性：
    • 仍然支持一些不安全的特性（如 RSA 密钥交换、SHA-1）。

2. TLS 1.3

发布时间：2018 年。

主要特点

  1. 更强的安全性：
    • 移除了不安全的加密算法（如 RSA 密钥交换、SHA-1、CBC 模式加密）。
    • 仅支持现代加密算法，如 AES-GCM、ChaCha20-Poly1305、ECDHE。
  2. 更快的握手：
    • 默认握手仅需 1 次往返（1-RTT）。
    • 支持 0-RTT 握手，允许客户端在首次请求时直接发送数据。
  3. 简化的协议设计：
    • 移除了冗余特性（如压缩、重协商），减少了协议复杂性。
  4. 加密握手过程：
    • 握手过程被加密，防止中间人攻击（如协议降级攻击）。
  5. 前向安全性：
    • 默认使用 ECDHE，确保前向安全性。

握手过程

1-RTT 标准握手
  1. ClientHello（客户端发起握手）：
    • 发送 支持的 TLS 版本、加密套件，发送 ECDHE 密钥参数（提前发出密钥交换信息）。
  2. ServerHello（服务器响应）：
    • 选择 TLS 版本、加密套件，发送 ECDHE 公钥。
    • 发送 证书（Certificate），完成密钥协商。
    • 服务器发送 New Session Ticket（会话票据，用于后续 0-RTT 恢复）。
    • 服务器发送 Finished，握手完成。
  3. Client Finished（客户端确认）：
    • 客户端计算密钥后，立即发送 Finished（确认握手完整性）。
    • 不会阻塞服务器的数据传输，正式进入加密通信。

TLS 1.3 仍然是 1-RTT 握手，Client Finished 只是确认，不算额外的 RTT！

时延：1-RTT（一次往返）

0-RTT 快速恢复握手

适用于会话恢复，允许客户端在首次链接时就发送数据，不必等待握手完成。

  1. ClientHello + 0-RTT 数据：
    • 客户端发送缓存的 会话票据（Session Ticket），立即发送数据。
  2. ServerHello：
    • 服务器验证会话票据，恢复密钥。
    • 服务器处理 0-RTT 数据并完成握手。

安全性考虑：

  • 0-RTT 数据可能遭受 重放攻击（Replay Attack）。
  • 适用于非敏感数据，如静态资源请求。

优势

  1. 更强的安全性：
    • 移除了不安全的算法，默认支持前向安全性。
  2. 更快的连接速度：
    • 1-RTT 握手减少了握手延迟。
    • 0-RTT 握手允许客户端在首次请求时直接发送数据。
  3. 更简洁的协议：
    • 移除了冗余特性，简化了协议设计和实现。

问题与局限性

  1. 兼容性问题：
    • 需要客户端和服务器同时支持 TLS 1.3。
    • 一些旧设备或软件可能不支持 TLS 1.3。
  2. 0-RTT 的安全限制：
    • 0-RTT 数据可能受到重放攻击（Replay Attack），因此仅适用于幂等请求。

3. TLS 1.2 和 TLS 1.3 的对比

特性 TLS 1.2 TLS 1.3
发布时间 2008 年 2018 年
握手延迟 2-RTT 1-RTT（默认），0-RTT（可选）
加密算法 支持 AES-GCM、AES-CBC、SHA-256 等 仅支持现代算法（如 AES-GCM、ChaCha20）
前向安全性 可选（需使用 ECDHE） 默认支持
协议复杂性 较复杂，支持冗余特性 简化，移除冗余特性
安全性 较高，但支持不安全的特性 更强，移除不安全的算法
兼容性 广泛兼容 需要客户端和服务器支持

4. 应用场景

  • TLS 1.2：
    • 目前最广泛使用的版本，适合需要广泛兼容性的场景。
  • TLS 1.3：
    • 适合对安全性和性能要求较高的场景（如金融、电商、实时通信）。
    • 逐渐成为主流，特别是在支持 HTTP/3 和 QUIC 协议的环境中。

5. 总结

  • TLS 1.2 是目前广泛使用的版本，提供了较高的安全性和兼容性。
  • TLS 1.3 是最新的版本，提供了更强的安全性、更快的握手速度和更简洁的协议设计。
  • 在配置 HTTPS 时，建议优先支持 TLS 1.3，并同时兼容 TLS 1.2，以兼顾安全性和兼容性。