HTTP 规范解读

October 23, 2024November 2, 2024

http

省略 HTTP/0.9，因为它没有被 RFC 标准化。

HTTP/1.0

RFC 1945

HTTP/1.0 是一个基于 TCP 的简单请求-响应式协议。

RFC 规定每个连接都由客户端在请求之前建立，并在发送响应后由服务器关闭。

注意 RFC 全文中并没有表述 Connection: keep-alive 标头，也没有规定长连接机制。（因此网络上的说法是无迹可寻的）
不过根据 RFC9112 C.2.2，这确实属于实验性功能。

RFC 正文中仅定义了 HEAD/GET/POST 方法。注意 HTTP/1.0 已支持正文编码（即 Content-Encoding，用于对内容编码以压缩数据），但不支持响应分块。

另外注意 RFC 中已经对代理/网关等角色做了表述，不过在 HTTP/1.1 增加了更多标头来做精细化控制。
此外，RFC 附录中包含一些方法和标头的扩展。

HTTP/1.1

1997 RFC2068
1999 RFC2616
2014 RFC7230-7235
2022 RFC9110-9112
下文基于现行 RFC9110-9112
读者可参考：https://yieldray.github.io/rfc-http/

HTTP/1.1 强制要求客户端发送 Host 标头。

HTTP/1.1 通过 Transfer-Encoding 支持响应分块。
与 Content-Encoding 不同，Transfer-Encoding 指定的是 HTTP 消息本身如何在网络上逐跳（单次连接）传输（而代理不应重传或缓存）。
特殊点在于通过 Transfer-Encoding: chunked 能够支持分块传输。

相对于 HTTP/1 主要依赖于 Expires 头部字段，HTTP/1.1 引入了更精细的缓存控制机制，
包括 Cache-Control 头部字段，支持更多缓存指令，如 max-age、no-cache、private 等，可更灵活地控制缓存行为。

默认情况下 HTTP/1.1 使用持久化连接，无需 keep-alive，但允许指定 Connection: close 来关闭。
注意 RFC 没有表述 HTTP 是如何通过底层的传输协议连接的。

由于发生在一个连接上， HTTP/1.1 是串行的（即请求流水线）。规范要求请求和响应必须相关联，因此对于非法响应，客户端必须断开连接。

HTTP/2

2015 RFC7540
2020 RFC8740
2022 RFC9113

HTTP/2 引入头部压缩（HPACK）和多路复用（多流并发），可更有效地利用网络资源（减少 TCP 连接数）并减少延迟。
多路复用即将每个 HTTP 请求/响应交换与流关联起来，多流并发自然又带来了流量控制（WINDOW_UPDATE）和请求优先级的问题。

如何建立 HTTP/2 连接呢？
对于 HTTPS，客户端发送的 TLS 请求带有应用层协议协商（ALPN）扩展（使用 h2 为标识符）。
对于 HTTP，对 HTTP/2 的服务发现实际上比较困难，规范弃用了 Upgrade: h2c 标头的做法。
另外注意，所有主流浏览器都只实现了 HTTP/2 over HTTPS。

帧

HTTP/2 帧是 HTTP/2 协议的基本单位，所有在客户端和服务器之间传输的数据都被封装在帧中。帧提供了在单个 TCP 连接上多路复用多个请求和响应的功能。

一个 HTTP/2 帧由一个 9 字节的帧头和可变长度的有效载荷组成。

DATA Frame {
  Length (24),
  Type (8) = 0x00,

  Unused Flags (4),
  PADDED Flag (1),
  Unused Flags (2),
  END_STREAM Flag (1),

  Reserved (1),
  Stream Identifier (31),

  [Pad Length (8)],
  Data (..),
  Padding (..2040),
}

HEADERS Frame {
  Length (24),
  Type (8) = 0x01,

  Unused Flags (2),
  PRIORITY Flag (1),
  Unused Flag (1),
  PADDED Flag (1),
  END_HEADERS Flag (1),
  Unused Flag (1),
  END_STREAM Flag (1),

  Reserved (1),
  Stream Identifier (31),

  [Pad Length (8)],
  [Exclusive (1)],
  [Stream Dependency (31)],
  [Weight (8)],
  Field Block Fragment (..),
  Padding (..2040),
}

PRIORITY Frame {
  Length (24) = 0x05,
  Type (8) = 0x02,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31),

  Exclusive (1),
  Stream Dependency (31),
  Weight (8),
}

RST_STREAM Frame {
  Length (24) = 0x04,
  Type (8) = 0x03,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31),

  Error Code (32),
}

SETTINGS Frame {
  Length (24),
  Type (8) = 0x04,

  Unused Flags (7),
  ACK Flag (1),

  Reserved (1),
  Stream Identifier (31) = 0,

  Setting (48) ...,
}

Setting {
  Identifier (16),
  Value (32),
}

PUSH_PROMISE Frame {
  Length (24),
  Type (8) = 0x05,

  Unused Flags (4),
  PADDED Flag (1),
  END_HEADERS Flag (1),
  Unused Flags (2),

  Reserved (1),
  Stream Identifier (31),

  [Pad Length (8)],
  Reserved (1),
  Promised Stream ID (31),
  Field Block Fragment (..),
  Padding (..2040),
}

PING Frame {
  Length (24) = 0x08,
  Type (8) = 0x06,

  Unused Flags (7),
  ACK Flag (1),

  Reserved (1),
  Stream Identifier (31) = 0,

  Opaque Data (64),
}

GOAWAY Frame {
  Length (24),
  Type (8) = 0x07,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31) = 0,

  Reserved (1),
  Last-Stream-ID (31),
  Error Code (32),
  Additional Debug Data (..),
}

WINDOW_UPDATE Frame {
  Length (24) = 0x04,
  Type (8) = 0x08,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31),

  Reserved (1),
  Window Size Increment (31),
}

CONTINUATION Frame {
  Length (24),
  Type (8) = 0x09,

  Unused Flags (5),
  END_HEADERS Flag (1),
  Unused Flags (2),

  Reserved (1),
  Stream Identifier (31),

  Field Block Fragment (..),
}

HTTP/3

2022 RFC9114
参考：https://www.infoq.cn/article/Lddlsa5f21StY04LI3hP

HTTP/3 通过 QUIC 协议承载。QUIC 基于 UDP，这样就可以完成在用户态对协议栈的实现（相对于 TCP 集成在了内核态实现）。

QUIC 提供协议协商、基于流的复用和流量控制。

对于传统的 HTTPS，实际上是 TLS over TCP，因此需要做 TCP 和 TLS 两次握手。

QUIC 建立在 TLS>=1.3 之上，并将这两个握手合并。

另外，HTTP/2 虽解决了 HTTP 队头阻塞，但没有解决 TCP 队头阻塞。使用 UDP 也能够解决此问题。

如何建立 HTTP/3 连接？
服务端通过 HTTP/2 ALTSVC 帧或响应头 Alt-Svc: h3=":端口号"，可通告 HTTP/3 端点可用。

HTTP/3 使用 QPACK（HPACK 的一种变体）实现头部压缩。
HTTP/3 为请求定义了以下伪标头字段：:method :scheme :authority :path 为响应定义了 :status 伪标头。

HTTP 帧由 QUIC 流承载。HTTP/3 帧与 HTTP/2 类似，但也存在区别。

YieldRay

HTTP 规范解读

Preview: