HTTP 各个版本的差异

HTTP 1.0 (1996 年)

特点：- 无连接：每次请求都需要建立新的 TCP 连接，请求完成后立即关闭 - 无状态：服务器不保存客户端的状态信息 - 简单：协议相对简单，功能有限 - 只支持 GET、POST、HEAD 方法

存在的问题：- 频繁建立/关闭连接，性能开销大。- 无法复用连接 - 完全串行，有队头阻塞问题

HTTP1.1 (1997 年)

主要改进：

1. 持久连接 （Keep-Alive）

   Connection: keep-alive

   • 默认启用持久连接
   • 可以在一个 TCP 上连续发送多个请求，但服务端的响应时串行的。
   • 减少建立连接的开销

2. 管道化

   • 可以在同一连接上发送多个请求，不需要等待前一个请求的相应。
   • 但存在队头阻塞问题
     • HTTP1.1 规定同一个链接上的响应必须按照请求顺序返回。因为 HTTP1.1 并没有给每个请求/响应单独设置标识，客户端只能按照响应顺序区分哪个响应属于哪个请求。
     • 所以，如果前面响应慢了，会阻塞后面的响应。
     • http1.1 在同一链接上的请求，必须按顺序返回，所以 浏览器为了提升并发性能，只能对同一域名并行建立多个 TCP 链接 （6～8个）

3. 新增了一些请求方法

   • PUT、DELETE、OPTIONS、TRACE、CONNECT

4. 缓存机制

   • 引入 Cache-Control 头
   • 更精细的缓存策略

   Cache-Control: max-age-3600 控制缓存事件
   ETag: '*****' 资源变化验证
   If-None-Match: '*****'

5. 分块传输编码

   • 支持流式传输

   Transfer-Encoding: chunked

仍然存在的问题：

• 队头阻塞：前面的响应会阻塞后续的响应。

HTTP 2.0 (2015 年)

1. 二进制分帧

   • 不再使用文本协议，使用二进制格式
   • 将多个请求消息分解为独立的帧（Frame），每个帧都带有流标识符（StreamID）
     • 每个请求-响应，对应一个独立的 “流”
     • 流有唯一的ID
     • 多个流之间相互独立，互不影响。

2. 多路复用

   • 不再需要多个连接
   • 单个 TCP 连接可以并行处理多个请求/响应，不再需要按顺序响应，服务端先处理完哪个就先响应哪个。
   • 解决 http1.1 队头阻塞问题

     • 没有彻底解决，因为 TCP 有一个重要的特征：按序交付。

       HTTP2.0 可能会发生这样的情况：
        
       发送端发送 TCP 数据包：
       包1 [seq=100] ──► 成功到达
       包2 [seq=200] ──► 丢失 ❌
       包3 [seq=300] ──► 成功到达
       包4 [seq=400] ──► 成功到达
        
       接收端的处理：
       ✓ 包1：交付给应用层（HTTP/2.0）
       ✗ 包2：丢失，等待重传
       ✓ 包3：已收到，但必须等待包2
       ✓ 包4：已收到，但必须等待包2
           ↓
       即使包3、包4已经到达，TCP 也不会交付给应用层
       必须等待包2重传成功后，才能按顺序交付 2、3、4
        
       一个包的丢失会阻塞整个连接上的所有流。

3. 头部压缩

   • 使用 HPACK 算法压缩头部
   • 维护头部表，避免传输重复
   • 显著减少宽带占用

4. 服务器推送

   • 服务器可以主动向客户端推送资源
   • 减少往返时间
   • 提高页面加载速度

5. 流优先级

   • 可以为不同的流设置优先级
   • 重要资源有限传输
   • 更好的资源调度

HTTP 3.0 (2021 年)

1. 基于 QUIC (Quick UDP Internet Connections)： 使用 UDP 而非 TCP
2. 内置加密： 默认 TLS 1.3 加密
3. 彻底解决队头阻塞问题

   • 虽然 UDP 没有内置的可靠性保证，所以 QUIC 自己实现一套基于流级别的可靠性传输逻辑。

     Stream 1 的数据包 ──► 独立确认、独立重传
     Stream 2 的数据包 ──► 独立确认、独立重传
     Stream 3 的数据包 ──► 独立确认、独立重传
      
     如果 Stream2 的某个包丢失：
     Stream1 不受影响，正常交付。
     Stream 2 只阻塞自己，等待重传。
     Stream 3: 不受影响，正常交付

备注：

• HTTP 3.0 是怎么解决 HTTP 2.0 的队头阻塞问题的？
  HTTP 2.0 是基于 TCP 的，TCP协议是字节流协议，它要求“按顺序交付”，如果中间某个包丢了，后面的包即使收到了，TCP 也不会交给上层应用，必须等丢失的包重传，补上。
  虽然 HTTP 2.0 在应用层实现了多路复用（一个 TCP 连接上跑多个流），但是只要底层的 TCP 有丢包，所有的流都被阻塞，这就是应用层看到的“队头阻塞”。

  HTTP 3.0 不再基于 TCP, 而是基于 QUIC (UDP 之上实现的传输层协议) QUIC 自己实现了可靠的传输、流量控制、加密（基于 TLS 1.3）, 但和 TCP 有以下不同点：- 每个流的数据包都独立确认、独立重传。- 某个流丢包的时候，只阻塞这个流，其他流不受影响。

• 为什么实际工程中，使用 SSE 时，使用 http1.1 比 http2.0 好

  • 在 HTTP/1.1 下，同一域名通常会建立多个 TCP 连接。SSE 占用其中一条长连接，即使发生阻塞或丢包，也只影响该连接，不会影响其他请求。
  • 而在 HTTP/2 下，同一域名通常只使用一个 TCP 连接，多路复用多个请求。SSE 作为一个长期存在的 stream，一旦在 TCP 层或流量控制层出现问题，可能会影响该连接上的所有请求。