古法网络入门

• 结构 ── 第 1 行、头部、空行、正文。申请是头部 149 字节＋正文 54 字节（实测）
• 方法与状态 ── 要做什么，以及结果如何。本讲让服务器返回了 10 种状态码（实测）
• 加速的办法 ── 304 让正文 0 字节，gzip 把 2 MB 变成 6 KB，HTTP/2 在一条连接上同时进行（实测）
• 开发者的陷阱 ── Cookie 的三个标记，CORS 错误该由谁来修

按 TCP/IP 的分层，HTTP 属于第 7 层，是应用层最上面的约定。练习网络和第 9 讲相同：电脑，以及单程 20 毫秒的捣乱线对面的申请服务器（Node.js）。服务器在 HTTP（3000 号）、HTTPS（3443 号，同时支持 HTTP/1.1 和 HTTP/2）、不加密的 HTTP/2（3080 号，观察用）上等待。

为了看内容，先用不上锁的 HTTP 发送申请，用 curl -v 和 Wireshark 记录下来（Wireshark 的界面见封面照片）。

# 请求：第 1 行（方法、路径、版本）、头部、空行、正文
    POST /api/expenses HTTP/1.1
    Host: expenses.example:3000
    User-Agent: curl/8.5.0
    Accept: */*
    Content-Type: application/json
    Content-Length: 54
    
    {"date":"2026-10-25","item":"交通費","amount":1280}
# 响应：第 1 行（版本、状态码）、头部、空行、正文
    HTTP/1.1 201 Created
    Location: /api/expenses/EXP-2026-0012
    Content-Type: application/json
    Content-Length: 43
    Date: Sun, 25 Oct 2026 00:28:31 GMT
    Connection: keep-alive
    Keep-Alive: timeout=5
    
    {"id":"EXP-2026-0012","status":"submitted"}

请求的第 1 行是“做什么（POST）、对哪里（/api/expenses）、用哪个版本（HTTP/1.1）”。接下来的头部是“名字: 值”的行，Host 是目标的名字（一台服务器要负责好几个名字，所以必须写），Content-Type 是正文的种类，Content-Length 是正文的长度。空行表示头部结束，后面是 54 字节的 JSON。

第 6 讲说过，TCP 是没有分界的“流”。到哪里为止算一个申请，只能由上层决定。答案就在这里：到空行为止是头部，从那里起 Content-Length 字节是正文。服务器按这个规则切分数据流。

响应的第 1 行是“版本、状态码、说明”。201 Created 表示“已创建”，Location 里写着新申请的位置。最后的 Connection: keep-alive 和 Keep-Alive: timeout=5 的意思是“这条连接会保持 5 秒，下一个请求也可以用”。第 6 讲和第 8 讲看到的、省掉 TCP 和 TLS 寒暄的“连接复用”，就是在这里约定的。

第 1 行的第一个词是方法。同样是 /api/expenses，GET 是“给我看列表”，POST 是“新提交一个申请”。

重要的是右数第 2 列，幂等。意思是“同一个请求发多少次，结果都和发一次一样”。HTTP 规范（RFC 9110）把 GET、HEAD、OPTIONS 等安全方法以及 PUT、DELETE 定为幂等。幂等的话，即使没等到回复就超时了，也可以放心重发。

故意用各种方式向练习服务器发请求，把回复的第 1 行排在一起。

# 向同一个 API 发送各种请求时的回复（第 1 行和相关头部）
    GET /api/expenses                  → 200 OK
    POST /api/expenses（JSON）         → 201 Created Location: /api/expenses/EXP-2026-0013
    POST（JSON 损坏）                  → 400 Bad Request
    POST（Content-Type: text/plain）   → 415 Unsupported Media Type
    POST（amount 是字符串）            → 422 Unprocessable Entity
    PUT /api/expenses                  → 405 Method Not Allowed Allow: GET, POST
    GET /expenses（旧 URL）            → 301 Moved Permanently Location: /api/expenses
    GET /api/expenses/EXP-2026-9999    → 404 Not Found
    DELETE（没有钥匙）                 → 401 Unauthorized WWW-Authenticate: Bearer
    DELETE（带钥匙）                   → 204 No Content

三位数的第一个数字表示类别。2xx 是成功，3xx 是“去别处”，4xx 是“请求方的问题”，5xx 是“服务器的问题”。4xx 由发送方（前端）来改，5xx 由服务器一侧来改。出故障时首先看的，就是这一位数。

4xx 里也有区分。400 是 JSON 坏了读不了，415 是“只收 JSON，却来了 text/plain”，422 是“读得懂，但金额是字符串，内容不对”。401 是“不知道你是谁（请出示钥匙）”，用 WWW-Authenticate 附上钥匙的种类。知道是谁、但“不允许你”的是 403。

报销列表每次打开，返回的内容几乎都一样。每次都全部运送很浪费。于是服务器在返回列表的同时，附上内容的标记 ETag。

# 第 1 次：列表和内容的标记（ETag）一起返回
pc$ curl -D - http://expenses.example:3000/api/expenses
    HTTP/1.1 200 OK
    ETag: "41dc1e7dc5a9"
    Cache-Control: no-cache
    （正文 153 bytes）
# 第 2 次：附上“这个标记的我已经有了”再问
pc$ curl -D - -H 'If-None-Match: "41dc1e7dc5a9"' http://expenses.example:3000/api/expenses
    HTTP/1.1 304 Not Modified
    ETag: "41dc1e7dc5a9"
    （正文 0 bytes）

第 2 次用 If-None-Match 附上“这个标记的我已经有了”再问，服务器因为内容没变，用 304 Not Modified、正文 0 字节来回答。往返次数一样，但列表越大越有效。浏览器不用吩咐，就会自动这样做。

Cache-Control: no-cache 和名字相反，不是“别存”，而是“可以存，但每次使用前都要向服务器确认”（RFC 9111）。真的不想被存时用 no-store。max-age=600 是“10 分钟内不用问就可以用”，这期间连往返都没有了。

HTTP 在一个请求结束后就把一切忘掉（无状态）。那“已登录”是怎么记住的呢？从这里开始用 HTTPS（3443 号）来试。

# 登录前问“我是谁？”
pc$ curl https://expenses.example:3443/api/me
    {"error":"login required"}
# 登录后，服务器发给 Cookie
pc$ curl -c jar.txt -X POST … https://expenses.example:3443/login
    HTTP/2 200 
    set-cookie: sid=480df7…; Path=/; HttpOnly; Secure; SameSite=Lax
# 下一个请求带上 Cookie 再问
pc$ curl -b jar.txt https://expenses.example:3443/api/me
    {"user":"arai"}

登录后，服务器用 Set-Cookie 发一张号码牌（sid）。电脑把它收好，之后每次向同一台服务器发请求时都作为 Cookie 带上。服务器根据号码查出“是新井”。HTTP 本身依旧健忘，让它“假装”记得的就是 Cookie。第 8 讲看到的 OSI 第 5 层“会话管理”的职责，实际上就是在这里完成的。

号码牌后面的三个标记，是开发者最在意的地方。HttpOnly 让 JavaScript 读不到，Secure 只在 HTTPS 时发送，SameSite=Lax 在从别的网站跳过来时，大多数请求都不带上。号码牌就是钥匙本身，所以要让它不容易被偷、不容易被冒用。

假设页面放在 https://app.expenses.example，API 放在 https://expenses.example:3443。名字不同，所以两者是不同的 Origin（http/https、名字、端口的组合）。浏览器通常不允许某个页面的 JavaScript 读取另一个 Origin 的回复。由 API 一方回答允许与否的约定，就是 CORS。

POST JSON 时，浏览器会在正式请求之前先用 OPTIONS 做一次“预检”（preflight）。下面用 curl 重现了这个预检。

# 预检（preflight）：能否从 https://app.expenses.example 的页面发 POST
    OPTIONS /api/expenses
    Origin: https://app.expenses.example
    Access-Control-Request-Method: POST
    Access-Control-Request-Headers: content-type
  →
    HTTP/2 204 
    access-control-allow-origin: https://app.expenses.example
    access-control-allow-methods: GET, POST, DELETE
    access-control-allow-headers: Content-Type, Authorization
    access-control-max-age: 600
# 来自陌生 Origin（https://other.example）时，不附带许可的头部
  →
    HTTP/2 204 

对许可的 Origin 会带上 Access-Control-Allow-Origin 等头部，对不认识的 Origin 什么都不带。两者都是 204，请注意服务器并没有说“拒绝”。拦下来的是浏览器。没有许可的头部，浏览器就不发送正式请求，并在开发者工具的 Console 里显示 CORS 错误。

在限速到 10 Mbit/s 的线上，导出报销 CSV（2 MB）。

# 2 MB 的 CSV，原样／用 gzip（10 Mbit/s、单程 20 ms 的线）
pc$ curl https://expenses.example:3443/api/export.csv
    2,097,152 bytes   1.934 s
pc$ curl --compressed …   (Accept-Encoding: deflate, gzip, br, zstd → Content-Encoding: gzip)
        6,179 bytes   0.142 s

电脑用 Accept-Encoding 告诉对方“这些压缩方式我能读”，服务器用 Content-Encoding: gzip 压缩后返回。2,097,152 字节变成 6,179 字节，1.934 秒变成 0.142 秒。浏览器也会自动这样做。

不过这个 CSV 是同一行的重复，所以压得极小。另做一个编号、日期、金额各不相同的 2 MB CSV，同样用 gzip 压缩，是 428,597 字节，约五分之一。文字数据（HTML、JSON、CSV）压缩效果好，本来就压缩过的 JPEG 和视频几乎压不动。

一个页面通常由几十个请求组成。用 HTTPS 获取 6 个各需 100 毫秒的报告，做了比较。

# 6 个各需 100 ms 的报告（HTTPS、单程 20 ms）
    HTTP/1.1 依次          0.953 s   1条连接
    HTTP/1.1 同时          0.246 s   6条连接
    HTTP/2 同时            0.245 s   1条连接

HTTP/1.1 一条连接一次只能处理一个请求。依次进行的话，即使复用连接也要 0.953 秒。要加快只能多建几条连接，6 条是 0.246 秒。浏览器出于同样的原因，对同一个对象会建 6 条左右的连接。相应地，TCP 和 TLS 的寒暄也要 6 次。

HTTP/2 在一条连接上给请求编号（流），同时推进（多路复用）。仍是一条连接，0.245 秒。内容从文字行变成了二进制的帧，但方法、状态码、头部的含义都一样。

在 HTTPS 上，用哪个版本说话是在 TLS 握手时顺便决定的（ALPN。在第 8 讲看到的 Client Hello 里写上“我也会说 h2”发过去）。浏览器只在 HTTPS 时使用 HTTP/2，照片里不加密的 HTTP/2 是为了观察而做的特殊设置。

HTTP/2 仍留有弱点。下面的 TCP 是一条流，丢一个数据包，无关的流也要等重发（第 7 讲的“队头阻塞”）。于是 HTTP/3 搬到了 UDP 之上的 QUIC。QUIC 按每条流保证顺序，也内置了 TLS 1.3。浏览器通过回复里的 Alt-Svc 头部或 DNS 的 HTTPS 记录（第 9 讲）得知“这个对象也会说 HTTP/3”，之后就切换过去。

先打开平时常用的网站，看看 Network 标签吧。一个页面里有多少请求、用哪个版本、压缩了多少，一目了然。