HTTP协议版本

• HTTP/0.9 ：只支持Get方法，不支持多媒体内通的MIME类型、各种HTTP首部、版本号等。
• HTTP/1.0 ：相对于0.9版本，添加了版本号、各种HTTP首部、一些额外的方法、以及对多媒体对象的处理。
• HTTP/1.0+ ：在1.0的基础上添加了keep-alive持久链接、虚拟主机支持、以及代理连接支持。
• HTTP/1.1 ：对HTTP的性能优化，删除了一些不好的特性。
• HTTP/2.0 ：对性能进行了大幅度优化，以及更强大的服务逻辑远程执行框架。
• HTTP/3.0 ：超文本传输协议的最新版本，基于 QUIC（Quick UDP Internet Connections） 协议构建。

HTTP/0.9

• 仅支持 GET 方法，用于从服务器请求 HTML 文档。
• 不支持请求头或响应头。
• 不支持 MIME 类型。
• 没有状态码（如 404、200）。
• 无法传输非 HTML 的内容。
• 客户端请求是单行字符串，格式简单

GET /index.html

HTTP/1.0

• 请求和响应中引入了 头部信息（Headers），用于描述资源和通信的元信息。
• 除了 GET 方法，还增加了：
  • POST：用于向服务器提交数据。
  • HEAD：类似 GET，但只返回头部，不返回实际内容。
• 响应头中引入 Content-Type 字段，用于指定资源的媒体类型（如 HTML、图片、JSON 等）。
• 服务器使用状态码来描述请求的结果，例如：
  • 200 OK：请求成功。
  • 404 Not Found：资源未找到。
  • 500 Internal Server Error：服务器内部错误。
• 增加了简单的缓存机制。
• 每个请求完成后，连接立即关闭（短连接）。
• 为每个资源重新建立 TCP 连接，导致性能低下。
• 需要等待上一个请求得到响应后才能发起下一个请求（队头阻塞）

HTTP/1.0+

HTTP/1.0+是一个介于1.0和1.1之间的非标准实现，是部分厂商应对1.0的问题进行的改造版本，不同的厂商实现不完全相同。

•  引入了 Connection: keep-alive 头部字段，允许在一次 TCP 连接中处理多个请求。
• 引入了 Host 头部字段支持虚拟主机。
• HTTP/1.0+ 引入了部分 HTTP/1.1 的缓存控制字段：
  • Cache-Control：提供细粒度的缓存策略（如 no-cache、max-age）。
  • ETag：支持基于实体标签的缓存验证。
• HTTP/1.0+ 一些实现增加了分块传输支持，使服务器能在生成内容的同时开始发送响应。
• HTTP/1.0+ 中，部分实现扩展了状态码支持，例如：
  • 100 Continue（中间状态，用于指示请求可以继续）。
  • 206 Partial Content（用于断点续传）。
• HTTP/1.0+ 中，部分实现引入了 PUT、DELETE 等方法。

HTTP/1.1

HTTP/1.1 于 1997 年推出，它正式标准化了许多 HTTP/1.0+ 的非标准特性，同时增加了更多功能，也是现在用的最广泛的HTTP协议版本。

• 默认启用持久连接：
  • HTTP/1.1 默认使用持久连接，多个请求和响应可以复用一个 TCP 连接。
  • 通过 Connection: close 可以显式关闭连接。
• **分块传输编码
  • 允许服务器在不知道响应完整长度的情况下，分块发送数据。
  • 每个块有自己的长度标记，最后一个块长度为 0 表示结束。
  • 适用场景：
    • 动态生成的内容。
  • 示例： Transfer-Encoding: chunked
• 请求流水线
  • 客户端可以在接收到第一个响应前发送多个请求。
  • 限制：
    • 需要服务器按顺序处理请求。
    • 浏览器对其支持有限，实际使用较少。
• 虚拟主机支持
  • HTTP/1.1 强制要求 Host 头部字段。
  • 允许在同一 IP 地址上托管多个域名。
  • 示例：
    • Host: www.example.com
• 优化缓存机制
  • 引入了以下头部字段，增强缓存的灵活性和控制：
    • Cache-Control：
      • 用于精确控制缓存行为，例如 no-cache、no-store、max-age=3600。
    • ETag：
      • 使用实体标签（ETag）判断资源是否发生改变，支持条件请求。
    • If-Modified-Since 和 If-None-Match：
      • 用于验证缓存的资源是否需要更新。
• 新增状态码
  • 1xx（信息性响应）：
    • 如 100 Continue，表示客户端可以继续发送请求体。
  • 206 Partial Content：
    • 支持断点续传。
  • 409 Conflict：
    • 表示请求冲突。
  • 418 I’m a teapot：
    • 用于彩蛋，遵循 RFC 2324
• 压缩带宽
  • • 支持压缩内容，减少传输数据量：
      • Content-Encoding：如 gzip、deflate。
  • 支持范围请求，允许只请求部分资源：
    • Range：如 bytes=500-999。

HTTP/2.0

HTTP/2 是现代 Web 中广泛使用的超文本传输协议版本之一，于 2015 年由 RFC 7540 正式标准化发布。它是对 HTTP/1.1 的全面优化，旨在解决 HTTP/1.1 的性能瓶颈，同时保持与其语义兼容。

1. HTTP/2 的设计目标

• 提高传输效率和性能。
• 减少延迟，提升网页加载速度。
• 解决 HTTP/1.1 中的队头阻塞问题。
• 减少 TCP 连接数量，优化网络利用率。

2. HTTP/2 的关键特性

2.1 二进制协议

• HTTP/2 将 HTTP/1.1 的纯文本格式转换为 二进制帧（binary framing layer），提升解析效率。
• 二进制协议的优点：
  • 更高效的帧解析。
  • 减少了数据的冗余和错误解析的可能。

2.2 多路复用

• 同一个 TCP 连接中可以并发处理多个请求和响应，互不阻塞。
• 消除了 HTTP/1.1 的队头阻塞问题。
• 具体机制：
  • 不同请求和响应被分割为独立的帧。
  • 使用 流（stream） 和 流 ID 区分，所有流共享一个连接。

2.3 头部压缩

• HTTP/2 使用 HPACK 算法 对头部字段进行压缩，显著减少了传输的体积。
• 特点：
  • 使用动态表和静态表减少冗余。
  • 如重复的 User-Agent 或 Cookie 字段，不会多次传输。

2.4 服务器推送

• 服务器可以主动向客户端发送资源，而无需客户端显式请求。
• 应用场景：
  • 页面加载时，提前推送 CSS、JavaScript 或图片资源，减少等待时间。

2.5 流优先级

• 每个流可以设置优先级，客户端和服务器可以协商优化资源分配。
• 适用场景：
  • 页面渲染时，优先加载关键资源（如 CSS 文件）。

3. HTTP/2 的帧模型

HTTP/2 中所有通信基于帧（Frame），帧是最小的协议单位。

• 数据帧（DATA）：
  • 用于传输请求或响应的主体内容。
• 头部帧（HEADERS）：
  • 包含请求或响应的元信息。
• 优先级帧（PRIORITY）：
  • 用于指定流的优先级。
• 设置帧（SETTINGS）：
  • 用于初始化连接或修改参数。

4. HTTP/2 的工作流程

请求流程：

1. 客户端发起 HTTP 请求，将其转换为帧（HEADERS、DATA）。
2. 服务器接收帧，解析并处理请求。
3. 服务器返回响应帧（HEADERS、DATA）。
4. 帧通过 TCP 连接发送到客户端。

与 HTTP/1.1 的区别：

• HTTP/1.1：一个请求对应一个 TCP 连接（或通过持久连接复用），请求阻塞时其他请求需等待。
• HTTP/2：所有请求共享一个 TCP 连接，帧并发处理，效率更高。

5. HTTP/2 的优点

5.1 性能提升

• 多路复用减少了队头阻塞。
• 二进制传输和头部压缩降低了带宽使用。

5.2 延迟优化

• 单连接减少了延迟。
• 服务器推送缩短了资源加载时间。

5.3 网络利用率更高

• 减少了 TCP 连接的数量，优化了服务器资源。

5.4 兼容性

• 与 HTTP/1.1 的语义完全兼容。
• 已广泛支持，主流浏览器和服务器均支持 HTTP/2。

6. HTTP/2 的局限性

6.1 基于 TCP

• HTTP/2 虽然缓解了队头阻塞问题，但仍然受 TCP 的队头阻塞影响（如丢包）。
• 解决方法：HTTP/3 使用 QUIC（基于 UDP）协议消除了该问题。

6.2 复杂性增加

• 二进制协议引入了额外的解析复杂度。
• 流优先级等特性实现起来较为复杂。

6.3 需要 HTTPS

• 主流浏览器要求 HTTP/2 必须使用加密连接（TLS/1.2 或更高版本）。

HTTP/3.0

1. HTTP/3 的设计目标

• 彻底解决队头阻塞问题（包括 TCP 层的队头阻塞）。
• 进一步降低延迟，优化网络性能。
• 提供内置的加密支持（默认加密）。
• 在不可靠网络环境中表现更佳。

2. HTTP/3 的关键特性

2.1 基于 QUIC 协议

• QUIC 是基于 UDP 的新传输协议，集成了以下功能：
  • 多路复用。
  • 内建加密（TLS 1.3）。
  • 高效的连接建立（0-RTT 和 1-RTT 握手）。
  • 数据包级别的可靠性管理。

2.2 消除队头阻塞

• HTTP/2 的问题：
  • 虽然支持多路复用，但仍受限于 TCP 的队头阻塞。
  • 一旦 TCP 出现丢包，整个连接的所有流都会受影响。
• HTTP/3 的解决方案：
  • QUIC 通过在 UDP 上实现独立的流管理，丢包只影响单个流，不会阻塞其他流。

2.3 快速连接建立

• QUIC 支持 0-RTT 和 1-RTT 握手：
  • 0-RTT：客户端可以在首次握手后缓存加密参数，下次连接时直接发送数据。
  • 1-RTT：相比传统的 TCP + TLS 握手流程更快。
• 优点：
  • 减少了初始延迟，提升了页面加载速度。

2.4 内置加密

• HTTP/3 默认启用 TLS 1.3，数据传输始终加密。
• 安全性：
  • 消除了明文传输的可能性。
  • 提供了更好的抗流量分析和篡改能力。

2.5 更高的性能

• QUIC 使用 UDP 提供可靠性，同时支持流的独立管理。
• 更适合高丢包、低质量的网络环境，如移动网络。

2.6 流量控制和拥塞管理

• QUIC 内置高级的流量控制和拥塞控制算法。
• 允许每个流独立管理其流量，避免影响其他流。

3. HTTP/3 的帧模型

HTTP/3 使用帧（Frame）进行通信，帧在 QUIC 的流（Stream）上传输。

• HEADERS 帧：
  • 包含 HTTP 的头部字段。
• DATA 帧：
  • 包含 HTTP 的请求或响应主体。
• SETTINGS 帧：
  • 用于初始化连接和传输配置。

4. HTTP/3 的工作流程

1. 建立连接：
   • 客户端和服务器使用 QUIC 进行 0-RTT 或 1-RTT 握手，协商加密和传输参数。
2. 发送请求：
   • 客户端将 HTTP 请求分解为帧，通过 QUIC 流发送到服务器。
3. 接收响应：
   • 服务器解析请求并返回响应帧，帧通过独立流传输到客户端。

5. HTTP/3 的优势

5.1 更低的延迟

• QUIC 的快速连接建立和独立流特性显著减少了延迟。

5.2 更可靠

• 在高丢包网络中，QUIC 的单独重传机制能更好地应对丢包。

5.3 更安全

• 默认启用加密，确保数据隐私和完整性。

5.4 更灵活

• QUIC 通过流的独立性，支持更高效的多路复用。

5.5 更适合移动网络

• QUIC 支持连接迁移（Connection Migration），IP 或网络环境改变时无需重新建立连接。

6. HTTP/3 的局限性

6.1 部署难度

• 基于 QUIC 的架构需要服务器和客户端都支持 HTTP/3 和 QUIC。
• 部分网络环境可能限制 UDP 的使用（如防火墙配置）。

6.2 兼容性

• 需要客户端和服务器共同支持 HTTP/3，老旧系统可能无法升级。

6.3 复杂性增加

• QUIC 的实现比传统 TCP 更复杂，对调试和监控提出了更高要求。

总结

• ← Previous Post
• Next Post →