HTTP 协议深度解析

#网络 · #网络协议 · #HTTP · #REST · #缓存 · #状态码

HTTP 是万维网的基石。本文从 HTTP 消息格式出发，深入请求/响应模型、头部语义、状态码体系、缓存机制，以及 HTTP/1.0 → 1.1 → 2 → 3 的演进路线。

1. HTTP 消息格式

1.1 请求格式

GET /api/users?page=1 HTTP/1.1          ← 请求行 (Method URI Version)
Host: example.com                        ← 头部字段 (Headers)
Accept: application/json
Authorization: Bearer eyJhbG...
User-Agent: Mozilla/5.0
                                        ← 空行 (CRLF)
{"name": "Alice"}                        ← 消息体 (Body, 可选)

请求行格式: METHOD SP URI SP VERSION CRLF
示例:        POST /api/users HTTP/1.1\r\n

方法	语义	幂等	安全	可缓存
GET	获取资源	✅	✅	✅
POST	创建资源/提交数据	❌	❌	条件
PUT	全量更新资源	✅	❌	❌
PATCH	部分更新资源	❌	❌	❌
DELETE	删除资源	✅	❌	❌
HEAD	同 GET 但不返回 Body	✅	✅	✅
OPTIONS	查询支持的方法	✅	✅	❌
TRACE	回显请求（调试）	✅	✅	❌
CONNECT	建立隧道（HTTPS 代理）	❌	❌	❌

1.2 响应格式

HTTP/1.1 200 OK                           ← 状态行 (Version Code Reason)
Content-Type: application/json            ← 头部字段
Content-Length: 27
Cache-Control: max-age=3600
Set-Cookie: session_id=abc123; HttpOnly   ← Cookie
                                          ← 空行
{"id": 1, "name": "Alice"}               ← 消息体

状态行格式: VERSION SP STATUS_CODE SP REASON CRLF
示例:        HTTP/1.1 404 Not Found\r\n

1.3 状态码分类

范围	类别	记忆口诀
1xx	Informational 信息	收到了，继续
2xx	Success 成功	搞定了
3xx	Redirection 重定向	去别的地方找
4xx	Client Error 客户端错误	你搞错了
5xx	Server Error 服务端错误	我搞错了

常用状态码速查：

状态码	含义	场景
200 OK	成功	GET/PUT 正常返回
201 Created	已创建	POST 创建资源成功
204 No Content	成功但无返回体	DELETE 成功
301 Moved Permanently	永久重定向	域名迁移
302 Found	临时重定向	登录跳转
304 Not Modified	缓存有效	协商缓存命中
400 Bad Request	请求格式错误	参数校验失败
401 Unauthorized	未认证	未登录
403 Forbidden	无权限	已登录但权限不够
404 Not Found	资源不存在	URL 错误
405 Method Not Allowed	方法不允许	POST 接口用了 GET
429 Too Many Requests	请求过多	限流
500 Internal Server Error	服务内部错误	代码异常
502 Bad Gateway	网关错误	上游服务挂了
503 Service Unavailable	服务不可用	过载/维护
504 Gateway Timeout	网关超时	上游服务超时

2. HTTP 头部（Headers）

这是 HTTP 面试最常问的知识点之一。HTTP 是无状态协议——每个请求都是独立的。为了记住"你是谁"，浏览器和服务端发展出了三套机制：

mermaid

flowchart TB
    subgraph Cookie["Cookie 机制"]
        C1["浏览器自动携带"]
        C2["存储在客户端 (4KB)"]
        C3["每次请求都发送"]
        C4["HttpOnly/Secure/SameSite"]
    end

    subgraph Session["Session 机制"]
        S1["Session ID 存 Cookie"]
        S2["数据存服务端 (内存/Redis)"]
        S3["安全（数据不出客户端）"]
        S4["❌ 分布式需共享 Session"]
    end

    subgraph Token["Token 机制 (JWT)"]
        T1["Header.Payload.Signature"]
        T2["存储在客户端 (LocalStorage/Cookie)"]
        T3["Authorization: Bearer <token>"]
        T4["✅ 无状态（自带信息）"]
        T5["❌ 无法主动失效"]
    end

维度	Cookie	Session (Cookie-based)	Token (JWT)
存储位置	浏览器（4KB/domain）	服务端（内存/Redis/DB）	客户端（LocalStorage/Cookie）
安全性	🟡 HttpOnly+Secure+SameSite	✅✅ 核心数据在服务端	🟡 Payload 仅 base64 编码（非加密！）
服务端开销	无	❌ 需要查 Session 存储	✅ 无（验证签名即可）
分布式友好	✅	❌ 需共享 Session（Sticky Session/Redis）	✅✅ 完全无状态
主动失效	✅ 客户端可删除	✅ 服务端 Delete Session	❌ 需黑名单或短 TTL
跨域	❌ Cookie 受同源限制	❌ 同上	✅ Header 不受同源限制
移动端/API	❌ 不适合	🟡 需传 Session ID	✅✅ 天然适合

JWT 不是银弹：Payload 仅 base64 不是加密！绝不要在 JWT 中存密码。JWT 适合分布式微服务间认证（无状态），但一旦签发就无法主动撤销——只能靠短 TTL + refresh token 来弥补。

3. HTTP/1.0 → HTTP/3 完整演进对比

mermaid

timeline
    title HTTP 协议演进 (1996 - 2022)
    1996 : HTTP/1.0 (RFC 1945) : 每请求一连接, 无 Host 头
    1997 : HTTP/1.1 (RFC 2068→7230) : 持久连接, Host 头, 管线化, Chunked
    2015 : HTTP/2 (RFC 7540) : 二进制帧, 多路复用, HPACK, Server Push
    2022 : HTTP/3 (RFC 9114) : QUIC/UDP, 0-RTT, 连接迁移, 无 TCP HoL

维度	HTTP/1.0	HTTP/1.1	HTTP/2	HTTP/3 (QUIC)
传输层	TCP	TCP	TCP	UDP (QUIC)
连接模型	每请求一连接	持久连接 (Keep-Alive)	单连接多 Stream	单连接多 Stream
多路复用	❌	🟡 管线化(响应有序, HoL)	✅ Stream 级复用 (应用层无 HoL)	✅✅ Stream 级复用 (传输层也无 HoL)
头部压缩	❌ 不压缩	❌ 不压缩	✅ HPACK (静态表+动态表)	✅ QPACK (无 HoL 的 HPACK)
加密	可选 (TLS)	可选 (TLS)	强制 (TLS 1.2+)	内建 (TLS 1.3)
握手延迟	TCP 1RTT + TLS 2RTT	同左	同左	0-RTT (恢复) / 1-RTT (首次)
服务器推送	❌	❌	✅ PUSH_PROMISE	✅
连接迁移	❌ (IP 变→断连)	❌	❌	✅ Connection ID
流量控制	❌	❌	✅ Stream + Connection 级	✅ Stream + Connection 级
队头阻塞	❌ 每请求一连接无此问题	❌ 管线化响应有序	🟡 TCP 层仍有 HoL	✅ 完全消除
推出年份	1996	1997	2015	2022

HTTP/1.1 的痛点为何到了 2015 年才被 HTTP/2 解决？

不是技术做不到，而是当时的 Web 场景没逼到这个程度。2005 年的网页平均只有 10-30 个资源，HTTP/1.1 的 6 个并发连接够用了。到了 2015 年，单页应用、自动播放视频、实时推送让一个页面动辄 100+ 个资源请求——6 个连接成了瓶颈。HTTP/2 的多路复用在这个背景下才真正成为刚需。

2.1 通用头部（General Headers）

头部	说明
`Cache-Control`	缓存策略：`max-age=3600`, `no-cache`, `no-store`
`Connection`	`keep-alive` / `close`
`Transfer-Encoding`	`chunked` 分块传输
`Date`	消息生成时间
`Upgrade`	协议升级（HTTP → WebSocket）

2.2 请求头部

头部	说明
`Host`	目标主机（HTTP/1.1 必需！虚拟主机依赖它）
`Accept`	接受的 MIME 类型：`application/json`
`Accept-Encoding`	接受的压缩：`gzip, br`
`Authorization`	认证信息：`Bearer <token>`, `Basic <base64>`
`Cookie`	发送 Cookie
`User-Agent`	客户端标识
`Referer`	来源页面 URL
`Origin`	跨域请求来源
`If-None-Match`	协商缓存 ETag
`If-Modified-Since`	协商缓存时间

2.3 响应头部

头部	说明
`Content-Type`	响应体 MIME 类型 + 编码：`text/html; charset=utf-8`
`Content-Length`	响应体字节数（非 chunked 模式）
`Content-Encoding`	压缩方式：`gzip`
`Set-Cookie`	设置 Cookie：`session=abc; HttpOnly; Secure; SameSite=Lax`
`ETag`	资源版本标识（强校验）
`Last-Modified`	资源最后修改时间（弱校验）
`Access-Control-Allow-Origin`	CORS 允许的来源
`Location`	重定向目标 URL (301/302)
`Server`	服务端软件信息
`X-Forwarded-For`	代理链中的客户端 IP

属性	作用
`HttpOnly`	JavaScript 不可访问，防 XSS 偷 Cookie
`Secure`	仅 HTTPS 传输
`SameSite=Strict`	跨站不发送，防 CSRF
`SameSite=Lax`	允许顶级导航（GET）发送
`Domain`	作用域名范围
`Path`	作用路径范围
`Max-Age`	过期时间（秒）

3. HTTP 缓存

mermaid

flowchart TD
    REQ["浏览器请求资源"] --> CHECK{"有本地缓存?"}
    CHECK -->|"否"| FETCH["向服务器请求"]
    CHECK -->|"是"| EXPIRED{"强缓存过期?"}

    EXPIRED -->|"否<br/>Cache-Control: max-age 未到"| USE["直接使用缓存 ✅<br/>状态码: 200 (from disk cache)"]
    EXPIRED -->|"是"| NEGO["协商缓存"]

    NEGO --> ETAG{"有 ETag?"}
    ETAG -->|"是"| SEND_ETAG["发送 If-None-Match"]
    SEND_ETAG -->|"304 Not Modified"| USE_NEGO["使用缓存 ✅"]
    SEND_ETAG -->|"200 OK"| FETCH_NEW["返回新数据"]

    ETAG -->|"否"| LMOD{"有 Last-Modified?"}
    LMOD -->|"是"| SEND_LM["发送 If-Modified-Since"]
    SEND_LM -->|"304"| USE_NEGO
    SEND_LM -->|"200"| FETCH_NEW

    style USE fill:#4CAF50,color:#fff
    style USE_NEGO fill:#2196F3,color:#fff
    style FETCH fill:#FF9800,color:#fff
    style FETCH_NEW fill:#FF9800,color:#fff

策略	机制	响应头	请求头
强缓存	时间内不请求	`Cache-Control: max-age=3600`	无
协商缓存 (ETag)	版本对比	`ETag: "abc123"`	`If-None-Match: "abc123"`
协商缓存 (Last-Modified)	时间对比	`Last-Modified: Tue, ...`	`If-Modified-Since: Tue, ...`

4. HTTP/1.0 vs HTTP/1.1

4.1 HTTP/1.0 (RFC 1945, 1996)

局限性：
  - 每个请求一个 TCP 连接 → 请求完即关闭
  - 无 Host 头 → 一个 IP 只能一个站点
  - 无 chunked 编码 → 必须知道 Content-Length
  - 无管线化

4.2 HTTP/1.1 (RFC 2616 → 7230-7235, 1997)

核心改进：

特性	说明
持久连接 (Keep-Alive)	默认不复用 TCP，`Connection: keep-alive`
Host 头	必选！支持虚拟主机（一个 IP 多个域名）
分块传输 (Chunked)	`Transfer-Encoding: chunked`，无需预先知道 Content-Length
管线化 (Pipelining)	一个连接上并发多个请求（但响应必须按序，队头阻塞）
范围请求 (Range)	`Range: bytes=0-1023`，断点续传
缓存增强	`Cache-Control`, `ETag`, `If-None-Match`
新增方法	PUT, PATCH, DELETE, OPTIONS, TRACE, CONNECT
100 Continue	大请求先询问服务器是否接受

4.3 HTTP/1.1 的队头阻塞 (Head-of-Line Blocking)

连接: [Req1 →                 ] [Res1 ←                 ]
      必须等 Req1 响应完才能发 Req2！

解决: 浏览器开 6 个并发 TCP 连接（Chrome 限制）

5. HTTP/2 (RFC 7540, 2015)

mermaid

flowchart LR
    subgraph H1["HTTP/1.1"]
        H1C1["连接1: Req1 → Res1 → Req2 → Res2"]
        H1C2["连接2: Req3 → Res3"]
        H1C3["连接3: Req4 → Res4"]
    end

    subgraph H2["HTTP/2 单连接"]
        H2M["多路复用"]
        H2S1["Stream 1: HEADERS + DATA"]
        H2S2["Stream 2: HEADERS + DATA"]
        H2S3["Stream 3: HEADERS + DATA"]
        H2S1 -.->|"交错发送"| H2S2 -.-> H2S3
    end

    H1 -.->|"进化"| H2

    style H2M fill:#4CAF50,color:#fff

5.1 二进制分帧

HTTP/2 最小传输单位: Frame (帧)

帧格式 (9 字节头部):
+-----------------------------------------------+
|         Length (24)        |  Type (8) |Flags(8)|
+-----------------------------------------------+
|R|              Stream Identifier (31)          |
+-----------------------------------------------+
|                   Frame Payload                |
+-----------------------------------------------+

帧类型	作用
HEADERS	HTTP 头部（压缩后）
DATA	请求/响应体
PRIORITY	流优先级
RST_STREAM	终止流
SETTINGS	连接参数协商
PUSH_PROMISE	服务器推送承诺
PING	心跳/测 RTT
GOAWAY	优雅关闭
WINDOW_UPDATE	流量控制

5.2 多路复用 (Multiplexing)

一个 TCP 连接承载多个 Stream
每个 Stream 有独立 ID（客户端奇数，服务端偶数）
帧交错发送，接收端按 Stream ID 重组
彻底解决 HTTP/1.1 的队头阻塞（应用层）

⚠️ 但 TCP 层的队头阻塞仍然存在：一个 TCP 丢包 → 所有 Stream 等待重传 → HTTP/3 用了 QUIC (UDP) 来解决。

5.3 头部压缩 (HPACK)

HTTP/1.1: 每个请求/响应都要发送完整头部 → ~500B-2KB
HTTP/2:   用 HPACK 压缩 → ~50B-200B

核心技巧:
  1. 静态表: 预定义 61 个常见头部字段
  2. 动态表: 连接期间动态学习
  3. Huffman 编码: 压缩字符串

5.3.1 HTTP 各版本通信协议性能量化对比

═══════════════════════════════════════════════════════════════
帧开销对比: HTTP/1.1 vs HTTP/2 vs HTTP/3
═══════════════════════════════════════════════════════════════

HTTP/1.1 文本协议开销:
  请求行:    "GET /api/users HTTP/1.1\r\n"          = 26B
  Host:      "Host: api.example.com\r\n"             = 24B
  Accept:    "Accept: application/json\r\n"          = 30B
  Cookie:    "Cookie: session=abc...xyz\r\n"         = 50-500B
  其他头部:  User-Agent, Accept-Encoding, ...        = 200-400B
  空行:      "\r\n"                                  = 2B
  ─────────────────────────────────────────────────────────
  典型请求头总大小: 400B ~ 1.5KB (文本格式，未压缩)

HTTP/2 二进制帧开销:
  帧头:      9B (固定)
  HEADERS 帧: 9B + HPACK 压缩后的头部 (~50-200B)
  DATA 帧:   9B + 数据
  ─────────────────────────────────────────────────────────
  典型请求头总大小: 60B ~ 210B (HPACK 压缩后)
  压缩率: 70-95% (相比 HTTP/1.1)

HTTP/3 QUIC 帧开销:
  QUIC 包头:  1-20B (短头部 1B + 连接ID + 包号)
  QUIC 帧头:  1-3B (类型 + 长度)
  HTTP/3 帧:  类似 HTTP/2 但用 QPACK
  ─────────────────────────────────────────────────────────
  典型请求头总大小: 55B ~ 200B (QPACK 压缩后)

═══════════════════════════════════════════════════════════════
实际场景性能对比 (加载 100 个资源的网页)
═══════════════════════════════════════════════════════════════

假设: 100 个资源, 每个 10KB, RTT=50ms, 带宽=100Mbps

HTTP/1.1 (6 个并发连接):
  握手: 6 × 1.5RTT = 6 × 75ms = 450ms (但并行，实际 75ms)
  传输: 100 个请求 / 6 连接 = 17 轮
        每轮: RTT + 传输时间 = 50ms + 10KB/100Mbps ≈ 51ms
        总传输: 17 × 51ms ≈ 867ms
  头部开销: 100 × 800B = 80KB (未压缩)
  总时间: ~75ms + 867ms ≈ 942ms

HTTP/2 (1 个连接, 多路复用):
  握手: 1 × 1.5RTT = 75ms
  传输: 100 个 Stream 并行发送
        所有请求一次性发出 → 1 RTT 后开始收数据
        总数据: 100 × 10KB = 1MB → 1MB/100Mbps = 80ms
  头部开销: 100 × 100B = 10KB (HPACK 压缩)
  总时间: ~75ms + 50ms + 80ms ≈ 205ms ✅ (快 4.6×)

HTTP/3 (QUIC, 0-RTT 恢复):
  握手: 0-RTT (恢复连接) 或 1-RTT (首次)
  传输: 同 HTTP/2 但无 TCP 队头阻塞
        丢包只影响单个 Stream → 其他 Stream 不等待
  头部开销: 100 × 95B = 9.5KB (QPACK)
  总时间: ~0ms + 50ms + 80ms ≈ 130ms ✅ (快 7.2×)

  丢包场景 (1% 丢包率):
    HTTP/2: 一个 TCP 包丢失 → 所有 100 个 Stream 等待重传
            额外延迟: ~RTT = 50ms → 总时间 ~255ms
    HTTP/3: 丢包只影响 1 个 Stream → 其他 99 个不受影响
            额外延迟: 只有 1 个资源多等 50ms → 总时间 ~135ms

═══════════════════════════════════════════════════════════════
HPACK 压缩效果的量化分析
═══════════════════════════════════════════════════════════════

  第 1 个请求: 头部 800B → HPACK 压缩后 ~200B (压缩率 75%)
    原因: 静态表匹配 + Huffman 编码

  第 2-10 个请求 (同一连接): 头部 800B → ~50B (压缩率 94%)
    原因: 动态表已学习了大部分头部字段
          只需发送索引号 (1-2B) 而非完整字段

  第 11-100 个请求: 头部 800B → ~30B (压缩率 96%)
    原因: 动态表已经非常完善，几乎所有字段都能命中

  总节省: 100 个请求 × 800B = 80KB → 压缩后 ~5KB
         节省 75KB 带宽 + 减少传输时间

5.4 服务器推送 (Server Push)

客户端请求 index.html
→ 服务器主动推送 style.css, script.js
→ 不需要客户端再次请求

5.5 流量控制

HTTP/2 在 Stream 级别和 Connection 级别都有流量控制（类似 TCP 滑动窗口），防止接收端被淹没。

6. HTTP/3 (QUIC)

维度	HTTP/2	HTTP/3 (QUIC)
传输层	TCP	UDP
加密	TLS 1.2+	TLS 1.3（内建）
多路复用	Stream (TCP HoL 阻塞)	Stream (无 HoL 阻塞)
连接建立	1-RTT (TCP+TLS)	0-RTT (缓存) / 1-RTT
连接迁移	❌	✅（Connection ID，切换网络不断连）

7. 常见问题与实战

7.1 请求过程全景

mermaid

sequenceDiagram
    participant DNS as DNS
    participant B as 浏览器
    participant S as 服务器

    B->>DNS: 解析 example.com
    DNS-->>B: 93.184.216.34

    B->>S: TCP 三次握手
    B->>S: TLS 握手 (HTTPS)
    B->>S: GET / HTTP/1.1<br/>Host: example.com
    S-->>B: HTTP/1.1 200 OK<br/>Content-Type: text/html<br/><html>...</html>

    B->>B: 解析 HTML → 发现 style.css, app.js, logo.png
    B->>S: (重用连接) GET /style.css
    B->>S: GET /app.js
    B->>S: GET /logo.png

    S-->>B: 200 OK (各资源)
    B->>B: 渲染页面 ✅

7.2 curl 调试

bash

# 完整请求过程
curl -v https://example.com/api/users

# 只看响应头
curl -I https://example.com

# 指定方法 + JSON Body
curl -X POST https://example.com/api/users \
  -H "Content-Type: application/json" \
  -d '{"name":"Alice"}'

# 跟踪重定向
curl -L https://example.com

# 显示时间明细
curl -w "dns: %{time_namelookup}, connect: %{time_connect}, tls: %{time_appconnect}, ttfb: %{time_starttransfer}, total: %{time_total}\n" https://example.com

8. 工程实践：HTTP 真正决定体验的是连接复用、超时预算和背压传播

8.0 一眼看懂：服务端 HTTP 为什么会越慢越堆

mermaid

flowchart LR
    A["HTTP 请求进入"] --> B["handler / goroutine 占用"]
    B --> C["RPC / DB / cache 下游等待"]
    C --> D["连接与队列回收变慢"]
    D --> E["RT / 503 / 504 上升"]

现象	优先怀疑	常见误判
TTFB 高	下游慢、业务处理慢	只怪 Web 框架
总时长高但业务很快	慢客户端、写回阻塞	只看 handler 耗时
连接数上涨	keep-alive、慢请求、慢写出	只怪流量变大
503/超时增多	背压、连接池、队列积压	只怪网关配置

8.1 对服务端来说，HTTP 不只是报文格式，而是一条资源占用链

一次 HTTP 请求在线上通常会占用：

一个客户端连接
服务端 goroutine / 请求上下文
若干下游连接（Redis / MySQL / RPC）
可能还会占用线程池、连接池、发送缓冲和日志 I/O

所以 HTTP 变慢，往往不是“协议慢”，而是这条链上某一段开始排队。

8.2 `Keep-Alive` 的价值，不只是少握手，而是减少系统整体抖动

连接复用能带来：

少一次 TCP/TLS 握手
减少短连接风暴
降低 TIME_WAIT 和端口消耗
提高下游代理和应用的稳态吞吐

但 keep-alive 不是越久越好。过长也可能带来：

空闲连接占住 fd
负载均衡分布不均
某些实例囤积太多长连接

所以它本质上是一个 吞吐、资源占用、负载均衡稳定性 的平衡问题。

8.3 服务端超时配置，真正要防的是“慢连接把资源拖死”

在 Go net/http 或反向代理场景里，常见超时包括：

读请求头超时
读请求体超时
写响应超时
Idle 连接超时
整体请求预算超时

这些超时不是“多配几个数字”这么简单，而是在防：

慢客户端长期占连接
半开连接和恶意连接拖住服务
下游超时后上游还在继续无意义等待
业务超时传播不完整导致资源迟迟不释放

8.4 很多 HTTP 问题，最后都会变成背压传播

mermaid

flowchart LR
    A["下游变慢 / DB锁等待 / RPC抖动"] --> B["应用处理时间变长"]
    B --> C["HTTP连接占用时间变长"]
    C --> D["accept队列 / goroutine / 连接池堆积"]
    D --> E["RT上升、超时、502/504/503"]

用户看到的是 HTTP RT 变高，但根因往往不在 HTTP 本身。

8.5 大响应、流式响应和慢客户端，是最容易被低估的成本

服务端往客户端写响应时，如果客户端读得慢，会出现：

写阻塞时间变长
goroutine 长时间挂在 Write
发送缓冲积压
连接长期不释放

这在以下场景尤其明显：

导出大文件
日志流 / SSE
图片、视频、大 JSON
跨公网、弱网、移动端下载

所以“接口逻辑已经执行完了”并不代表这个请求已经便宜地结束了。

8.6 一个典型故障链：`client -> http server -> rpc -> mysql`

mermaid

sequenceDiagram
    participant C as Client
    participant H as HTTP Server
    participant R as RPC
    participant M as MySQL

    C->>H: HTTP 请求
    H->>R: 调下游 RPC
    R->>M: SQL 查询
    Note over M: 慢 SQL / 锁等待 / flush 抖动
    M-->>R: 返回变慢
    R-->>H: RPC 超时边缘
    Note over H: 请求 goroutine 与连接占用时间变长
    H-->>C: RT 飙升 / 504 / 503

8.7 常见误判

现象	容易误判为	实际可能是
HTTP RT 高	Web 框架性能差	下游 RPC / DB 慢
503 增多	服务挂了	过载保护或连接/线程资源耗尽
CPU 不高但很慢	机器空闲	连接、锁、I/O 或下游等待在排队
只有导出接口慢	业务逻辑重	慢客户端写出和大响应传输成本
超时很多	网络差	超时预算没分层传播，重试放大

8.8 排障顺序

现象	优先看什么
TTFB 高	下游调用、业务处理、数据库等待
总时长高但处理很快	响应写出、慢客户端、网络传输
连接数高	keep-alive、慢请求、慢客户端、负载均衡
503/超时增多	goroutine、fd、连接池、队列积压
某个接口特别抖	是否大包体、是否流式、是否重试放大

8.9 一个实战原则

text

把 HTTP 看成“连接管理 + 超时预算 + 背压传播”的入口层，
不要只把它看成请求行、Header 和状态码。

9. HTTP 客户端工程实践：真正影响稳定性的，是连接复用、超时拆账和错误重试

9.0 一眼看懂：客户端一次请求真正花时间在哪

mermaid

flowchart LR
    A["DNS"] --> B["connect"]
    B --> C["TLS"]
    C --> D["写请求 / 等首包"]
    D --> E["读响应体 / 决定是否回池"]

现象	优先看什么	常见误判
请求整体慢	DNS / connect / TLS / TTFB 拆分	直接怪服务端慢
connect 比例高	连接复用率、响应体是否收尾	直接怪网络差
少量超时后雪崩	重试策略、剩余 deadline	把重试当稳定性开关
下游连接数飙升	连接没回池、短连接过多	只看连接池大小

9.1 客户端一次请求，往往比“发一个 GET”复杂得多

一次客户端请求通常至少经历：

DNS 解析
TCP connect
TLS 握手（HTTPS）
写请求头 / 请求体
等待首包（TTFB）
读取响应体
决定是否复用连接

所以很多“HTTP 接口慢”的问题，其实慢点根本不在服务端业务逻辑，而在客户端前置链路和连接管理。

9.2 `http.Client` / 连接池真正管理的是“连接生命周期”，不是一个简单对象

对于客户端来说，一条连接可能经历：

新建连接
成功复用空闲连接
因超时、EOF、RST 被丢弃
因请求体/响应体未正常收尾而无法复用
因空闲超时或连接上限被回收

所以连接池问题的本质不是“池子太小”，而是：

连接为什么没有复用起来？
哪些连接在错误路径里提前失效了？
哪些请求把连接长时间占住了？

9.3 `Keep-Alive` 和 Idle 连接的价值，是把 DNS / connect / TLS 成本摊薄

连接复用能显著减少：

重复 DNS 解析
重复 TCP 三次握手
重复 TLS 握手
短连接导致的 TIME_WAIT 和端口压力

但如果 Idle 连接策略不合理，也会导致：

某些热点实例囤积太多长连接
连接长期闲置却占住 fd
负载均衡不均匀
某些已失效连接在复用时才暴露错误

9.4 超时要拆账，而不是只配一个总超时

客户端真正需要关注的时间预算通常包括：

DNS 超时
connect 超时
TLS 握手超时
等待响应头超时
读取整个响应体的总预算
整体请求 deadline

如果只设置一个很粗的总超时，经常会出现：

某一段过慢却不易定位
connect/TLS 已经吃光预算，业务处理只能被动超时
重试时没有剩余时间预算，导致第二次请求也大概率失败

9.5 重试不是稳定性开关，而是最容易制造放大的地方

客户端常见错误做法：

任何错误都重试
超时后立刻并发重试
不区分幂等与非幂等请求
上游已经快超时了还继续重试

mermaid

flowchart LR
    A["下游开始变慢"] --> B["客户端超时增多"]
    B --> C["重试次数上升"]
    C --> D["下游收到更多流量"]
    D --> E["排队更严重"]
    E --> F["超时继续上升"]

所以重试策略必须同时考虑：

幂等性
剩余 deadline
抖动退避
最大并发与最大重试次数

9.6 响应体如果没有正确读取或关闭，连接复用就会悄悄失效

客户端里一个非常常见但隐蔽的问题是：

没有读完响应体
出错路径忘记 Close
提前返回导致连接不能回池

线上后果通常不是立即报错，而是：

新建连接比例升高
connect/TLS 耗时变多
下游连接数飙升
P99 抖动逐渐恶化

9.7 一个典型故障链：`http client -> gateway -> app`

mermaid

sequenceDiagram
    participant C as HTTP Client
    participant G as Gateway
    participant A as App

    C->>G: 发起请求
    Note over C: DNS/connect/TLS 已消耗部分预算
    G->>A: 转发请求
    Note over A: 处理变慢或下游依赖抖动
    A-->>G: 返回变慢
    G-->>C: TTFB 升高
    Note over C: 超时、重试、连接不能稳定复用

9.8 常见误判

现象	容易误判为	实际可能是
客户端 RT 高	服务端慢	DNS/connect/TLS 或连接复用失效
connect 比例高	网络差	响应体未收尾、连接没回池、短连接过多
少量超时后快速恶化	对方服务挂了	重试放大、连接池被打穿
某实例调用异常多	服务发现有问题	keep-alive 粘连、空闲连接分布不均
P50 正常 P99 很差	应用抖动	连接新建、重传、重试和尾延迟叠加

9.9 排障顺序

现象	优先看什么
请求整体慢	DNS / connect / TLS / TTFB 是否拆分监控
connect 比例升高	Idle 连接复用率、是否频繁新建连接
超时后雪崩	重试策略、deadline 剩余预算、是否幂等
下游连接数飙升	响应体是否读完关闭、连接是否正常回池
某些实例热点	keep-alive 分布、负载均衡策略、连接粘连

9.10 一个实战原则

text

客户端稳定性问题，优先看"连接有没有复用起来、预算有没有拆清楚、重试有没有放大"，
不要一上来就把所有慢请求都归因于服务端业务代码。

10. HTTP 连接池故障专题

10.1 Stale Connection（过期连接）问题

TCP 连接空闲时间过长，中间网络设备（NAT/防火墙/负载均衡器）可能已经断开连接，但客户端连接池不知道：

mermaid

sequenceDiagram
    participant C as Client (连接池)
    participant N as NAT / LB
    participant S as Server

    Note over C,S: 连接空闲 5 分钟
    N-->>N: NAT 映射超时, 连接失效
    C->>C: 从连接池取连接 (以为还活着)
    C->>S: 发送请求
    Note over N: NAT 丢弃包 (无映射)
    C-->>C: 等待超时 → connection reset / timeout
    Note over C: 用户请求失败!

各语言/框架的解决方案：

组件	参数	含义	建议
Go `http.Transport`	`IdleConnTimeout`	空闲连接最大保留时间	90s（一般小于 LB 的空闲超时）
Go `http.Transport`	`MaxIdleConnsPerHost`	每个 host 最大空闲连接数	2-10
Nginx `keepalive_timeout`	保持连接多久	60-75s
AWS ELB	空闲超时	默认 60s，最大 4000s
阿里云 SLB	空闲超时	默认 60s

// Go 客户端防 stale connection 配置
transport := &http.Transport{
    MaxIdleConns:          100,
    MaxIdleConnsPerHost:   10,
    IdleConnTimeout:       90 * time.Second,  // < LB 超时
    DisableKeepAlives:     false,
}
// 关键: IdleConnTimeout 必须小于 LB/NAT 的空闲超时！

10.2 代理提前关闭 502/504 排查

text

502 Bad Gateway:
  最常见原因: Nginx/Envoy 连接池中的 upstream 连接是 stale connection
  → 发送请求时发现连接已断 → 返回 502

504 Gateway Timeout:
  最常见原因: upstream 处理超时 (proxy_read_timeout 默认 60s)
  → Nginx 等了 60s 没收到响应 → 主动断开 → 504

Connection Reset / Broken Pipe:
  最常见原因: 服务端关闭连接时, 客户端还在往上面写数据
  → 或者客户端写了请求, 服务端已经关闭了

10.3 Go `http.Transport` / Nginx / Envoy 参数对比

参数	Go http.Transport	Nginx	Envoy
连接池大小	`MaxIdleConnsPerHost`	`keepalive 1000` (per worker)	`max_connections`
空闲超时	`IdleConnTimeout`	`keepalive_timeout`	`idle_timeout`
连接最大存活时间	`MaxConnAge` (Go 1.12+)	无内置	`max_connection_duration`
连接最大请求数	`MaxConnsPerHost` (Go 1.11+)	`keepalive_requests`	`max_requests_per_connection`
DNS 刷新	默认 OS resolver	需 `resolver` 指令 + `valid`	`dns_refresh_rate`

10.4 连接池故障检查清单

bash

# 1. 看当前连接状态
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

# 2. 看 Go 进程的 goroutine 和 fd
curl http://localhost:6060/debug/pprof/goroutine?debug=2 | grep -c "http\.transport"
ls /proc/<PID>/fd | wc -l

# 3. 看是否 stale connection
# 如果有 502 偶发 + 连接池空闲超时 > LB 超时 → 典型 stale connection

11. 从浏览器输入 URL 到页面渲染 — 全链路解析

这是面试出现频率最高的综合题，串联了 DNS、TCP、TLS、HTTP、解析、渲染六大环节。

mermaid

sequenceDiagram
    participant B as 浏览器
    participant D as DNS
    participant S as 服务器
    participant GPU as GPU/渲染

    B->>D: 1. DNS 解析域名 → IP
    D-->>B: 返回 IP 地址

    B->>S: 2. TCP 三次握手 (SYN/SYN-ACK/ACK)
    S-->>B: 连接建立 (~1 RTT)

    B->>S: 3. TLS 握手 (ClientHello/ServerHello/...)
    S-->>B: 加密通道建立 (~1-2 RTT)

    B->>S: 4. HTTP 请求 (GET /index.html)
    S-->>B: 5. HTTP 响应 (HTML)

    B->>B: 6. 解析 HTML → DOM Tree
    B->>S: 7. 遇到 CSS/JS → 发起子请求 (可能复用连接)
    S-->>B: CSS/JS 文件
    B->>B: 8. 解析 CSS → CSSOM Tree
    B->>B: 9. DOM + CSSOM → Render Tree
    B->>B: 10. Layout (布局/回流) → 计算位置大小
    B->>B: 11. Paint (绘制) → 光栅化
    GPU-->>B: 12. Composite (合成) → 屏幕显示

11.1 各阶段耗时分析

阶段	典型耗时	优化方向
DNS 解析	10-50ms	DNS 预解析、HTTPDNS、CDN
TCP 握手	1 RTT (10-100ms)	连接复用 (Keep-Alive)、TFO
TLS 握手	1-2 RTT	TLS 1.3 (1-RTT)、Session Resumption
HTTP 请求	1 RTT	HTTP/2 多路复用、减小传输量
HTML 解析	10-50ms	减少 DOM 深度、流式渲染
资源加载	数百ms-数s	CDN、压缩、合并、缓存
渲染 (Layout/Paint)	10-200ms	减少回流、GPU 加速、懒加载

11.2 关键路径优化

text

首次内容绘制 (FCP) 的关键路径:
  HTML 下载 → HTML 解析 → 首次 CSS 加载 → 首次 Paint

最大内容绘制 (LCP) 的优化:
  1. 预加载关键资源 (<link rel="preload">)
  2. 内联关键 CSS (首屏 CSS 放入 HTML)
  3. 延迟非关键 JS (async/defer)
  4. 服务端渲染 (SSR) 减少客户端渲染开销

可交互时间 (TTI) 的优化:
  1. Code splitting (按路由拆分 JS)
  2. Tree shaking (删除未使用代码)
  3. 图片懒加载 (loading="lazy")

11.3 浏览器内部解析流程

text

HTML 字节流
  → Tokenizer (词法分析: 识别标签、属性、文本)
  → Tree Construction (语法分析: 构建 DOM 树)
  → 遇到 <script> 时: 暂停解析，下载+执行 JS (阻塞 DOM)
  → 遇到 <link> 时: 并行下载 CSS (不阻塞 DOM，但阻塞渲染)
  → CSSOM 构建完成后: DOM + CSSOM → Render Tree
  → Layout: 计算每个节点的几何位置 (盒模型)
  → Paint: 将布局转换为像素图
  → Composite: 将多个图层合并显示

回流 (Reflow) vs 重绘 (Repaint)：

操作	触发时机	代价
回流	修改布局属性 (width/height/padding/margin/display)	⭐⭐⭐ 高
重绘	修改外观属性 (color/background/visibility)	⭐⭐ 中
合成	修改 transform/opacity (不触发布局和绘制)	⭐ 低

css

/* ❌ 两次回流 */
el.style.width = '100px';
el.style.height = '200px';

/* ✅ 批量修改，一次回流 */
el.style.cssText = 'width: 100px; height: 200px';

/* ✅ 使用 transform 而非 left，只触犯合成 */
/* 差: */ el.style.left = '10px';
/* 好: */ el.style.transform = 'translateX(10px)';

html

<!-- ✅ 用 CSS will-change 提示浏览器准备 GPU 加速 -->
<style>.carousel { will-change: transform; }</style>

12. 同源策略与 CORS 完整机制

12.1 同源策略定义

同源 = 协议相同 + 域名相同 + 端口相同。三个条件必须全部满足。

https://example.com:443/page  与  https://example.com:443/api   → ✅ 同源
https://example.com           与  http://example.com             → ❌ 协议不同
https://example.com           与  https://api.example.com        → ❌ 子域名不同
https://example.com:443       与  https://example.com:8080       → ❌ 端口不同

同源策略限制了三个行为：

DOM 访问：不同源的脚本不能操作彼此的 DOM
Cookie/LocalStorage：不能读取不同源的 Cookie
AJAX 请求：不能向不同源发送请求 (这是 CORS 要解决的)

CORS 是 W3C 标准，允许浏览器向跨源服务器发起受控的 XMLHttpRequest。

简单请求 vs 预检请求

简单请求（不需要预检，浏览器直接发送）：

同时满足三个条件：
  1. 方法: GET / HEAD / POST
  2. 头部: 仅包含 Accept, Accept-Language, Content-Language, Content-Type
  3. Content-Type: text/plain / multipart/form-data / application/x-www-form-urlencoded

http

# 简单请求的交互
GET /api/users HTTP/1.1
Host: api.example.com
Origin: https://www.example.com

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Credentials: true

预检请求（复杂请求，先发 OPTIONS 探测）：

http

# 1. 浏览器先发 OPTIONS 预检
OPTIONS /api/users HTTP/1.1
Host: api.example.com
Origin: https://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Authorization, X-Custom

# 2. 服务器响应允许
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization, X-Custom
Access-Control-Max-Age: 86400   ← 24h 内不再预检

# 3. 浏览器发实际请求
PUT /api/users/1 HTTP/1.1
Host: api.example.com
Origin: https://www.example.com
Authorization: Bearer xyz

CORS 响应头完整列表

头部	含义
`Access-Control-Allow-Origin`	允许的源 (不能为 `*` 同时 `credentials=true`)
`Access-Control-Allow-Methods`	允许的 HTTP 方法
`Access-Control-Allow-Headers`	允许的请求头 (自定义头必须在此)
`Access-Control-Allow-Credentials`	是否允许携带 Cookie
`Access-Control-Expose-Headers`	允许 JS 读取的响应头
`Access-Control-Max-Age`	预检缓存时间 (秒)

javascript

// 前端：声明使用凭据
fetch('https://api.example.com/user', {
    credentials: 'include'   // 携带同源 Cookie
});

http

# 服务端必须响应：
Access-Control-Allow-Origin: https://www.example.com   # 不能是 *
Access-Control-Allow-Credentials: true

常见跨域解决方案对比

方案	原理	适用场景	限制
CORS	服务端设置头部	✅ 现代标准方案	需服务端配合
JSONP	`<script>` 不跨域	仅 GET、老旧系统	安全风险、不支持 POST
代理	同源服务端转发	开发环境、无法改服务端	增加一跳延迟
postMessage	跨窗口/iframe 通信	窗口间通信	需要双方协作
Nginx 反向代理	`/api/` → 后端统一域名	生产环境最常用	增加代理层

nginx

# Nginx 反向代理解决跨域 — 生产最常用
location /api/ {
    proxy_pass http://backend:8080/api/;

    # 或者加 CORS 头
    add_header Access-Control-Allow-Origin $http_origin;
    add_header Access-Control-Allow-Credentials true;
}

# 也处理 OPTIONS 预检
if ($request_method = 'OPTIONS') {
    add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE';
    add_header Access-Control-Allow-Headers 'Authorization, Content-Type';
    add_header Access-Control-Max-Age 86400;
    return 204;
}

Go HTTP 编程

服务端

package main

import (
    "context"
    "fmt"
    "log"
    "net/http"
    "time"
)

// 自定义 Handler
type apiHandler struct{}

func (h *apiHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    switch r.URL.Path {
    case "/api/users":
        if r.Method == http.MethodGet {
            fmt.Fprintf(w, `{"users": [{"id":1,"name":"Alice"}]}`)
        }
    default:
        http.NotFound(w, r)
    }
}

// 中间件链
func loggingMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        next.ServeHTTP(w, r)
        log.Printf("%s %s %v", r.Method, r.URL.Path, time.Since(start))
    })
}

func timeoutMiddleware(timeout time.Duration) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            ctx, cancel := context.WithTimeout(r.Context(), timeout)
            defer cancel()
            next.ServeHTTP(w, r.WithContext(ctx))
        })
    }
}

func main() {
    mux := http.NewServeMux()
    mux.Handle("/api/", &apiHandler{})

    // 中间件链
    handler := loggingMiddleware(timeoutMiddleware(5*time.Second)(mux))

    srv := &http.Server{
        Addr:         ":8080",
        Handler:      handler,
        ReadTimeout:  10 * time.Second,
        WriteTimeout: 15 * time.Second,
        IdleTimeout:  60 * time.Second,
    }
    log.Fatal(srv.ListenAndServe())
}

客户端

func httpClient() {
    client := &http.Client{
        Timeout: 10 * time.Second,
        Transport: &http.Transport{
            MaxIdleConns:        100,
            MaxIdleConnsPerHost: 10,
            IdleConnTimeout:     90 * time.Second,
        },
    }

    // GET
    resp, err := client.Get("https://api.example.com/users")
    if err != nil {
        return
    }
    defer resp.Body.Close()
    body, _ := io.ReadAll(resp.Body)

    // POST JSON
    payload := strings.NewReader(`{"name":"Bob"}`)
    req, _ := http.NewRequest("POST", "https://api.example.com/users", payload)
    req.Header.Set("Content-Type", "application/json")
    req.Header.Set("Authorization", "Bearer token123")
    resp, err = client.Do(req)
}

// 带 context 超时的请求
func fetchWithTimeout(ctx context.Context, url string) ([]byte, error) {
    ctx, cancel := context.WithTimeout(ctx, 3*time.Second)
    defer cancel()

    req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()
    return io.ReadAll(resp.Body)
}

超时类型	配置	作用
`http.Client.Timeout`	10s	整个请求生命周期上限
`http.Server.ReadTimeout`	10s	读取完整请求的时间
`http.Server.WriteTimeout`	15s	写入完整响应的时间
`http.Server.IdleTimeout`	60s	Keep-Alive 连接最大空闲时间
`http.Transport.IdleConnTimeout`	90s	连接池中空闲连接保留时间

HTTP 协议深度解析 ​

1. HTTP 消息格式 ​

1.1 请求格式 ​

1.2 响应格式 ​

1.3 状态码分类 ​

2. HTTP 头部（Headers） ​

2.4 Cookie、Session、Token — 三大身份机制对比 ​

3. HTTP/1.0 → HTTP/3 完整演进对比 ​

HTTP/1.1 的痛点为何到了 2015 年才被 HTTP/2 解决？ ​

2.1 通用头部（General Headers） ​

2.2 请求头部 ​

2.3 响应头部 ​

2.5 Cookie 属性 ​

3. HTTP 缓存 ​

4. HTTP/1.0 vs HTTP/1.1 ​

4.1 HTTP/1.0 (RFC 1945, 1996) ​

4.2 HTTP/1.1 (RFC 2616 → 7230-7235, 1997) ​

4.3 HTTP/1.1 的队头阻塞 (Head-of-Line Blocking) ​

5. HTTP/2 (RFC 7540, 2015) ​

5.1 二进制分帧 ​

5.2 多路复用 (Multiplexing) ​

5.3 头部压缩 (HPACK) ​

5.3.1 HTTP 各版本通信协议性能量化对比 ​

5.4 服务器推送 (Server Push) ​

5.5 流量控制 ​

6. HTTP/3 (QUIC) ​

7. 常见问题与实战 ​

7.1 请求过程全景 ​

7.2 curl 调试 ​

8. 工程实践：HTTP 真正决定体验的是连接复用、超时预算和背压传播 ​

8.0 一眼看懂：服务端 HTTP 为什么会越慢越堆 ​

8.1 对服务端来说，HTTP 不只是报文格式，而是一条资源占用链 ​

8.2 Keep-Alive 的价值，不只是少握手，而是减少系统整体抖动 ​

8.3 服务端超时配置，真正要防的是“慢连接把资源拖死” ​

8.4 很多 HTTP 问题，最后都会变成背压传播 ​

8.5 大响应、流式响应和慢客户端，是最容易被低估的成本 ​

8.6 一个典型故障链：client -> http server -> rpc -> mysql ​

8.7 常见误判 ​

8.8 排障顺序 ​

8.9 一个实战原则 ​

9. HTTP 客户端工程实践：真正影响稳定性的，是连接复用、超时拆账和错误重试 ​

9.0 一眼看懂：客户端一次请求真正花时间在哪 ​

9.1 客户端一次请求，往往比“发一个 GET”复杂得多 ​

9.2 http.Client / 连接池真正管理的是“连接生命周期”，不是一个简单对象 ​

9.3 Keep-Alive 和 Idle 连接的价值，是把 DNS / connect / TLS 成本摊薄 ​

9.4 超时要拆账，而不是只配一个总超时 ​

9.5 重试不是稳定性开关，而是最容易制造放大的地方 ​

9.6 响应体如果没有正确读取或关闭，连接复用就会悄悄失效 ​

9.7 一个典型故障链：http client -> gateway -> app ​

9.8 常见误判 ​

9.9 排障顺序 ​

9.10 一个实战原则 ​

10. HTTP 连接池故障专题 ​

10.1 Stale Connection（过期连接）问题 ​

10.2 代理提前关闭 502/504 排查 ​

10.3 Go http.Transport / Nginx / Envoy 参数对比 ​

10.4 连接池故障检查清单 ​

11. 从浏览器输入 URL 到页面渲染 — 全链路解析 ​

11.1 各阶段耗时分析 ​

11.2 关键路径优化 ​

11.3 浏览器内部解析流程 ​

12. 同源策略与 CORS 完整机制 ​

12.1 同源策略定义 ​

12.2 CORS (Cross-Origin Resource Sharing) ​

简单请求 vs 预检请求 ​

CORS 响应头完整列表 ​

携带 Cookie ​

常见跨域解决方案对比 ​

Go HTTP 编程 ​

服务端 ​

客户端 ​

参考 ​

💬 文章评论

HTTP 协议深度解析

1. HTTP 消息格式

1.1 请求格式

1.2 响应格式

1.3 状态码分类

2. HTTP 头部（Headers）

2.4 Cookie、Session、Token — 三大身份机制对比

3. HTTP/1.0 → HTTP/3 完整演进对比

HTTP/1.1 的痛点为何到了 2015 年才被 HTTP/2 解决？

2.1 通用头部（General Headers）

2.2 请求头部

2.3 响应头部

2.5 Cookie 属性

3. HTTP 缓存

4. HTTP/1.0 vs HTTP/1.1

4.1 HTTP/1.0 (RFC 1945, 1996)

4.2 HTTP/1.1 (RFC 2616 → 7230-7235, 1997)

4.3 HTTP/1.1 的队头阻塞 (Head-of-Line Blocking)

5. HTTP/2 (RFC 7540, 2015)

5.1 二进制分帧

5.2 多路复用 (Multiplexing)

5.3 头部压缩 (HPACK)

5.3.1 HTTP 各版本通信协议性能量化对比

5.4 服务器推送 (Server Push)

5.5 流量控制

6. HTTP/3 (QUIC)

7. 常见问题与实战

7.1 请求过程全景

7.2 curl 调试

8. 工程实践：HTTP 真正决定体验的是连接复用、超时预算和背压传播

8.0 一眼看懂：服务端 HTTP 为什么会越慢越堆

8.1 对服务端来说，HTTP 不只是报文格式，而是一条资源占用链

8.2 `Keep-Alive` 的价值，不只是少握手，而是减少系统整体抖动

8.3 服务端超时配置，真正要防的是“慢连接把资源拖死”

8.4 很多 HTTP 问题，最后都会变成背压传播

8.5 大响应、流式响应和慢客户端，是最容易被低估的成本

8.6 一个典型故障链：`client -> http server -> rpc -> mysql`

8.7 常见误判

8.8 排障顺序

8.9 一个实战原则

9. HTTP 客户端工程实践：真正影响稳定性的，是连接复用、超时拆账和错误重试

9.0 一眼看懂：客户端一次请求真正花时间在哪

9.1 客户端一次请求，往往比“发一个 GET”复杂得多

9.2 `http.Client` / 连接池真正管理的是“连接生命周期”，不是一个简单对象

9.3 `Keep-Alive` 和 Idle 连接的价值，是把 DNS / connect / TLS 成本摊薄

9.4 超时要拆账，而不是只配一个总超时

9.5 重试不是稳定性开关，而是最容易制造放大的地方

9.6 响应体如果没有正确读取或关闭，连接复用就会悄悄失效

9.7 一个典型故障链：`http client -> gateway -> app`

9.8 常见误判

9.9 排障顺序

9.10 一个实战原则

10. HTTP 连接池故障专题

10.1 Stale Connection（过期连接）问题

10.2 代理提前关闭 502/504 排查

10.3 Go `http.Transport` / Nginx / Envoy 参数对比

10.4 连接池故障检查清单

11. 从浏览器输入 URL 到页面渲染 — 全链路解析

11.1 各阶段耗时分析

11.2 关键路径优化

11.3 浏览器内部解析流程

12. 同源策略与 CORS 完整机制

12.1 同源策略定义

12.2 CORS (Cross-Origin Resource Sharing)

简单请求 vs 预检请求

CORS 响应头完整列表

携带 Cookie

常见跨域解决方案对比

Go HTTP 编程

服务端

客户端

参考