HTTP 再邂逅：报文结构、请求方法、状态码与 Cookie/Session
摘要：上一篇我们跑通了一次 HTTP 事务的完整旅程。这一篇深入报文的"内部构造"：请求报文与响应报文长什么样？六种请求方法有何语义差异？五类状态码分别代表什么？无状态的 HTTP 如何靠 Cookie 与 Session 记住"你是谁"？全部用真实命令与输出拆解，读完你就能像读一封信一样读懂任意一条 HTTP 报文。
一、背景：报文，是 HTTP 的全部
HTTP 是一个"报文驱动"的协议。客户端与服务器之间所有的语义------要什么资源、用什么方法、结果如何、带了什么元信息------都写在报文字段里。因此，读懂报文是理解 HTTP 的必经之路。
在拆报文之前，先厘清一个容易混淆的概念：
-
URL / URI ：URI（统一资源标识符，RFC 3986）是资源的"身份证"，URL 是 URI 最常见的一种（能定位到资源）。一个典型 URL 形如：
bashhttp://user:pass@www.example.com:8080/path/to?name=alice#frag └┬─┘ └─────┬──────┘ └──────┬──────┘ └──┬──┘ └───┬────┘ └──┬─┘ scheme userinfo host port path query fragment而在 HTTP 请求行里，我们通常只发送"路径 + 查询"这一部分（称为 origin-form），主机与端口放在
Host头里------这是反向代理场景的常见形式；正向代理则用"绝对 URI"形式，相关差异见第 3 篇"特性进阶"。
本文的实验环境与上一篇相同（root@124.70.99.96，Ubuntu 24.04.4 LTS），依赖 curl、nc、telnet、Python 均已就绪。
二、分步骤实验
实验 1：请求报文与响应报文的结构拆解
基于上一篇采集到的真实报文，把请求、响应逐字段拆开。
请求报文结构：
text
GET / HTTP/1.1 ← 请求行：方法 + 请求目标(路径) + 协议版本
Host: 127.0.0.1:9000 ← 请求头：目标主机与端口（HTTP/1.1 必需）
User-Agent: curl/8.5.0 ← 请求头：客户端标识
Accept: */* ← 请求头：可接受的响应类型
← 空行（\r\n\r\n，头与体的分界）
（无请求体） ← GET 通常无 body| 字段 | 含义 |
|---|---|
GET |
请求方法，表示"获取资源" |
/ |
请求目标，即资源的路径 |
HTTP/1.1 |
协议及版本号 |
Host |
必填，指定虚拟主机/端口 |
User-Agent |
发起请求的客户端程序标识 |
Accept |
客户端愿意接收的媒体类型，*/* 表示任意 |
响应报文结构（以上一篇手写响应为例）：
text
HTTP/1.1 200 OK ← 状态行：版本 + 状态码 + 原因短语
Date: Sat, 19 Sep 2026 05:07:53 GMT ← 响应头：生成时间
Server: MiniHTTP/1.0 ← 响应头：服务器软件标识
Content-Type: text/html; charset=utf-8 ← 响应头：正文 MIME 类型与编码
Content-Length: 87 ← 响应头：正文字节长度
Connection: close ← 响应头：本次响应后关闭连接
← 空行
<h1>Hello HTTP/1.1</h1>... ← 响应体| 字段 | 含义 |
|---|---|
200 |
状态码，表示成功 |
OK |
原因短语，状态码的文本说明 |
Content-Type |
告知客户端按什么格式解析正文 |
Content-Length |
正文精确长度，供客户端判断"收完没" |
Connection: close |
短连接：响应后即断开 |
讲解 ：HTTP 报文 =「起始行（请求行/状态行）+ 若干头部 + 空行 + 可选实体」。起始行说"干什么/结果如何"，头部说"这件事的元信息"，空行是固定分界符，实体承载真正的数据。理解了这三段，任何 HTTP 报文都能读。注意一个关键对：Content-Length 与 Transfer-Encoding: chunked 二者通常只出现一个------已知长度用前者，边生成边发用后者（见第 3 篇）。
实验 2：六种请求方法的语义
测试服务器 /root/lab/fullserver.py 会打印收到的每个原始请求，并按方法回显。
可复现命令：
bash
python3 /root/lab/fullserver.py 9100 &
B=http://127.0.0.1:9100
curl -s $B/hello # GET
curl -s -X POST -d "name=alice&age=20" $B/submit # POST（带表单体）
curl -s -X PUT -d '{"name":"bob"}' $B/resource/1 # PUT
curl -s -X DELETE $B/resource/1 # DELETE
curl -s -I $B/anything # HEAD（-I 即 HEAD）
curl -s -X OPTIONS $B/echo # OPTIONS真实输出摘录 ------ 服务端收到的六种请求行：
text
[server] 127.0.0.1:35944 GET /hello HTTP/1.1
[server] 127.0.0.1:35960 POST /submit HTTP/1.1
[server] 127.0.0.1:35968 PUT /resource/1 HTTP/1.1
[server] 127.0.0.1:35982 DELETE /resource/1 HTTP/1.1
[server] 127.0.0.1:35986 HEAD /anything HTTP/1.1
[server] 127.0.0.1:35990 OPTIONS /echo HTTP/1.1HEAD 的响应（只有头，无正文）：
text
HTTP/1.1 200 OK
Date: Sat, 19 Sep 2026 05:09:07 GMT
Server: FullHTTP/1.0
Content-Length: 0
Connection: closePOST 完整请求报文（体现请求体与报文差异）：
text
> POST /api/submit HTTP/1.1
> Host: 127.0.0.1:9100
> User-Agent: curl/8.5.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 30
>
[server] body (30 bytes): {"user":"zhangsan","score":95}讲解：六种方法语义不同------
GET：获取（无副作用，不应改状态）；POST：提交数据（携带Content-Type/Content-Length+ 请求体）；PUT：完整替换或创建资源；DELETE：删除资源；HEAD：只取响应头不取正文（上面Content-Length: 0佐证）；OPTIONS：查询服务器支持哪些方法（常用于 CORS 预检）。
有无请求体、响应是否含正文，是它们在报文层面最直观的差异。
实验 3：五类状态码（1xx ~ 5xx）
测试服务器提供 /code/<NNN> 路由，直接返回对应状态码。
可复现命令：
bash
python3 /root/lab/fullserver.py 9100 &
B=http://127.0.0.1:9100
curl -sv -H "Expect: 100-continue" -d "payload=abc" $B/code/200 # 1xx 100 Continue
for c in 200 201 204; do curl -s -i $B/code/$c | head -6; done # 2xx
curl -s -i $B/redirect | head -8 # 3xx 302 + Location
curl -sL $B/redirect -w "%{http_code} %{url_effective}\n" # 跟随重定向
for c in 400 403 404; do curl -s -o /dev/null -w "$c=%{http_code}\n" $B/code/$c; done # 4xx
for c in 500 502 503; do curl -s -o /dev/null -w "$c=%{http_code}\n" $B/code/$c; done # 5xx真实输出摘录：
text
# 1xx：100 Continue（先 100 再上正文，再 200）
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
# 2xx：成功类
-- /code/200 -- HTTP/1.1 200 OK
-- /code/201 -- HTTP/1.1 201 Created
-- /code/204 -- HTTP/1.1 204 No Content （注意：无响应体 Content-Length: 0）
# 3xx：重定向
HTTP/1.1 302 Found
Location: /code/200
# 用 -L 跟随：最终状态 200，URL 跳到 http://127.0.0.1:9100/code/200
# 4xx：客户端错误
-- /code/400 -- HTTP状态码=400
-- /code/403 -- HTTP状态码=403
-- /code/404 -- HTTP状态码=404
# HTTP/1.1 404 Not Found
# 5xx：服务端错误
-- /code/500 -- HTTP状态码=500
-- /code/502 -- HTTP状态码=502
-- /code/503 -- HTTP状态码=503
# HTTP/1.1 500 Internal Server Error讲解：五大类状态码职责分明------
| 类别 | 含义 | 代表 | 说明 |
|---|---|---|---|
| 1xx | 临时/信息 | 100 | 先告知"可以继续发" |
| 2xx | 成功 | 200/201/204 | 201 新建、204 成功但无内容 |
| 3xx | 重定向 | 302 | 靠 Location 头指出新地址，curl -L 才自动跟随 |
| 4xx | 客户端错误 | 400/403/404 | 请求有误/禁止/资源不存在 |
| 5xx | 服务端错误 | 500/502/503 | 内部错误/网关坏/服务不可用 |
浏览器看到具体状态码会采取不同动作------这正是 HTTP 语义化的体现。
实验 4：用 telnet / nc 手工构造原始 HTTP 请求
HTTP 请求就是一段以 \r\n\r\n 结尾的纯文本，任何人都能手工敲出来。
可复现命令：
bash
python3 /root/lab/fullserver.py 80 & # 让服务监听标准 80 端口
ss -tlnp | grep ":80 " # 确认监听
# ① 用 nc 手工发 GET 请求
printf "GET /hello HTTP/1.1\r\nHost: lab.local\r\nX-Custom: handcrafted\r\n\r\n" | nc 127.0.0.1 80
# ② 用 telnet 手工发请求
( printf "GET /code/404 HTTP/1.1\r\nHost: lab.local\r\nConnection: close\r\n\r\n"; sleep 1 ) | telnet 127.0.0.1 80真实输出摘录：
text
# 80 端口监听确认
LISTEN 0 20 0.0.0.0:80 0.0.0.0:* users:(("python3",pid=9556,fd=3))
# nc 手工构造请求 → 完整响应
HTTP/1.1 200 OK
Date: Sat, 19 Sep 2026 05:10:18 GMT
Server: FullHTTP/1.0
Content-Length: 48
Connection: close
<h1>echo</h1><p>method=GET</p><p>path=/hello</p>
# telnet 连接过程
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.
# 服务端日志证实：telnet 发来的手工请求确实到达
[server] 127.0.0.1:54186 GET /hello HTTP/1.1
GET /hello HTTP/1.1
Host: lab.local
X-Custom: handcrafted
[server] 127.0.0.1:54190 GET /code/404 HTTP/1.1
GET /code/404 HTTP/1.1
Host: lab.local
Connection: close讲解：nc 的演示完整证明了"手工输入请求行 + 头部 → 服务器照常响应"；telnet 也成功建立连接、发送请求（服务端日志为证）。注：脚本化管道下 telnet 客户端自身不把响应回显到 stdout（表现为只有连接提示），而 nc 能完整回显------这是两款工具的行为差异，不影响"手工构造 HTTP"这一结论。通过这种方式，可以在不借助浏览器的情况下直接与任何 HTTP 服务器对话，是排查协议问题的利器。
实验 5：Cookie 与 Session------无状态协议如何"记住你"
HTTP 本身是无状态的：每一次请求都是独立的，服务器默认不记得你上次来过。Cookie 与 Session 就是为"记住状态"而生的两种机制。我们用 Flask 实现来拆解。
可复现代码 （/root/lab/flaskapp.py）：
python
from flask import Flask, request, make_response, session, redirect
app = Flask(__name__)
app.secret_key = "lab-secret-key-2026" # 用于给 session cookie 签名
@app.route("/")
def index():
user = request.cookies.get("username")
v = session.get("visits", 0)
return f"欢迎回来 {user}, session visits={v}" if user else "请登录 <a href=/login>"
@app.route("/login")
def login():
resp = make_response(redirect("/"))
resp.set_cookie("username", "alice", max_age=3600) # ① 普通明文 cookie
session["user"] = "alice"; session["visits"] = 0 # ② 服务端签名 session cookie
return resp
@app.route("/count")
def count():
session["visits"] = session.get("visits", 0) + 1
return f"session visits = {session['visits']}"可复现命令与真实输出：
bash
# ① 登录，观察 Set-Cookie
curl -s -i http://127.0.0.1:5000/login | grep -iE "^HTTP|^Location|^Set-Cookie"
text
HTTP/1.1 302 FOUND
Location: /
Set-Cookie: username=alice; Expires=Sat, 19 Sep 2026 06:12:00 GMT; Max-Age=3600; Path=/
Set-Cookie: session=eyJ1c2VyIjoiYWxpY2UiLCJ2aXNpdHMiOjB9.aq4ZoA.gZAm97_J_D5dL6sj0wMoFShYH0Y; HttpOnly; Path=/
bash
# ② cookie jar 保存与回传
curl -s -c /tmp/cj.txt -o /dev/null http://127.0.0.1:5000/login
cat /tmp/cj.txt
curl -s -b /tmp/cj.txt http://127.0.0.1:5000/
text
# cookie jar 内容（Netscape 格式，username 明文，session 为签名值）
127.0.0.1 FALSE / FALSE 1789798320 username alice
#HttpOnly_127.0.0.1 FALSE / FALSE 0 session eyJ1c2VyIjoiYWxpY2UiLCJ2aXNpdHMiOjB9....
# 回传后，服务端识别出身份
欢迎回来, alice / 服务端 session['user'] = alice / session['visits'] = 0
bash
# ③ session 保持：连续访问 /count，计数在客户端 cookie 中递增
curl -s -b /tmp/cj.txt -c /tmp/cj.txt -i http://127.0.0.1:5000/count | grep -iE "Set-Cookie|visits"
curl -s -b /tmp/cj.txt -c /tmp/cj.txt -i http://127.0.0.1:5000/count | grep -iE "Set-Cookie|visits"
text
第1次：Set-Cookie: session=eyJ1c2VyIjoiYWxpY2UiLCJ2aXNpdHMiOjF9.aq4Zsg.vi6svd...; HttpOnly; Path=/
本次访问后 session['visits'] = 1
第2次：Set-Cookie: session=eyJ1c2VyIjoiYWxpY2UiLCJ2aXNpdHMiOjJ9.aq4Zsg.cmL2Rz...; HttpOnly; Path=/
本次访问后 session['visits'] = 2真实输出摘录 ------ Flask session cookie 三段式结构拆解：
text
session cookie 完整值:
eyJ1c2VyIjoiYWxpY2UiLCJ2aXNpdHMiOjJ9.aq4ZzQ._wJRSqvjXu3j3QzLDHLcbiGunKo
[第1段] payload (base64url，解码即会话数据):
原文: eyJ1c2VyIjoiYWxpY2UiLCJ2aXNpdHMiOjJ9
解码: {"user":"alice","visits":2}
[第2段] timestamp: aq4ZzQ
[第3段] HMAC 签名: _wJRSqvjXu3j3QzLDHLcbiGunKo讲解：
- Cookie ：服务器通过
Set-Cookie把状态写入浏览器，浏览器在后续请求中自动用Cookie头带回。上面username=alice是明文，任何人都能改；而HttpOnly标记使sessioncookie 无法被 JS 读取，降低 XSS 窃取风险。 - Session ：Flask 默认把会话数据存回客户端 cookie（"客户端会话"），因此值必须是防篡改的------它由「base64(JSON 数据) . 时间戳 . HMAC 签名」三段构成。上面真实拆解可见：payload 解码后就是
{"user":"alice","visits":2}，计数变化立刻反映在 cookie 值里；一旦有人篡改 payload，签名就对不上，服务端会拒绝。 - 对比：
username明文 cookie 适合非敏感偏好；session签名 cookie 适合需要完整性的会话状态。
三、原理解析
把本篇知识点归纳为一张"读懂报文"的心智模型：
起始行（请求行/状态行） → 做了什么 / 结果如何
头部（多行） → 关于这件事的元信息
空行（\r\n\r\n） → 固定分界符
实体（可选） → 真正的数据再叠加三个维度：
- 方法维度（GET/POST/PUT/DELETE/HEAD/OPTIONS）决定动作语义，也决定是否携带/返回实体；
- 状态码维度（1xx~5xx）是服务器的"结构化回答"，浏览器据此采取下一步动作；
- 状态维度（Cookie/Session）弥补 HTTP 无状态的天生短板，让"你是谁"得以跨越多次请求传递。
四、最佳实践与避坑
Content-Length与Transfer-Encoding二选一：两者同时出现或都不出现都可能导致客户端解析混乱，这是常见协议 bug 来源。HEAD不等于"更快的 GET"：它只省正文，服务器仍需按 GET 逻辑计算头部（如准确的长度），别指望它一定省事。- 重定向要区分 301/302/303/307/308：本文演示的 302 是"临时跳转"，浏览器/爬虫会缓存 301（永久）导致后续不走原地址，生产环境改跳转策略时务必选对。
- Cookie 明文可被篡改 ：任何存进客户端明文 cookie 的值都不应被信任；涉及身份/权限用签名（或干脆服务端 Session），并加
HttpOnly/Secure/SameSite（详见第 7 篇 Web 安全）。 - 手工发报文是做协议调试的利器 ：遇到"框架/工具不按预期"时，用
nc发一条最小请求，能立刻区分是客户端问题还是服务端问题。
五、小结
本文把 HTTP 报文"拆到骨头"：
- 请求报文 = 请求行 + 请求头 + 空行 +（可选实体）；
- 响应报文 = 状态行 + 响应头 + 空行 +（可选实体）；
- 六种请求方法各有明确语义，报文层面差异在"有没有 body、返不返回正文"；
- 五类状态码是服务器的结构化回应，浏览器据此行动；
- Cookie 存状态、Session 保证完整性，
HttpOnly是重要安全属性； - 报文是可读文本，
nc/telnet手工发请求是这项特性的直接证明。
下一篇《HTTP 渐进：编码、认证、连接、缓存与内容协商》将进入 HTTP/1.1 的高级特性，看它如何让传输"更小、更快、更聪明"。
本文所有命令均在 root@124.70.99.96（Ubuntu 24.04.4 LTS）上真实执行，输出为原文截取。