HTTP不同版本到底有什么区别

最新推荐文章于 2025-02-06 01:39:26 发布

听雨coding

最新推荐文章于 2025-02-06 01:39:26 发布

阅读量1k

点赞数 26

文章标签： http 网络协议网络

本文链接：https://blog.csdn.net/KING46000/article/details/144069991

版权

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 的工作流程

请求流程：

客户端发起 HTTP 请求，将其转换为帧（HEADERS、DATA）。
服务器接收帧，解析并处理请求。
服务器返回响应帧（HEADERS、DATA）。
帧通过 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 的工作流程

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

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 更复杂，对调试和监控提出了更高要求。

总结

特性	HTTP/1.0	HTTP/1.1	HTTP/2	HTTP/3
传输模式	文本	文本	二进制	二进制
持久连接	不支持	默认支持	默认支持	默认支持
多路复用	不支持	不支持	支持	支持
队头阻塞	存在	存在	TCP 队头阻塞	消除（基于 QUIC）
头部压缩	不支持	不支持	支持（HPACK）	支持（QPACK）
服务器推送	不支持	不支持	支持	支持
加密	不支持	配合 TLS	强制 TLS	内置加密（TLS 1.3）
连接迁移	不支持	不支持	不支持	支持