周五晚上十一点多，线上告警突然响成一片，所有走某个内部接口的下单流程都在报错，错误码清一色是 502 Bad Gateway。我第一反应是后端服务挂了，可登录服务器看了一圈，进程活得好好的；应用日志里只有一行刺眼的upstream returned http 403 forbidden；再翻接入层配置，发现一个入口服务的健康检查路径下午刚被人改过。最后真正定位到根因，花了将近三个小时——问题不在业务代码，而在一个响应头、一个状态码的语义理解上。
也是从那天起，我把 HTTP/HTTPS 协议从"用过"变成了"吃透"。这篇内容不是协议名词的堆砌，而是把我这些年踩过的坑、抓过的包、排过的障揉进去，把请求头、响应头、状态码、数据包结构这四块讲透。它适合这几类人：后端开发，动不动就要排查"为什么接口返回404/403/502"；前端，被跨域和下载文件折腾过；测试同学，用 JMeter 录脚本、压接口；运维，天天和网关、状态码打交道；还有刚开始玩 CTF 的安全爱好者，因为很多 Web 题本质就是考你会不会构造一个 HTTP 请求。
1. HTTP与HTTPS的本质差异：明信片、信封与保险箱
1.1 先看HTTP在通信模型里的位置
HTTP（HyperText Transfer Protocol，超文本传输协议）是应用层协议，它只关心"客户端和服务端之间怎么约定请求和响应的格式"，不关心数据怎么跨过千山万水到达对端。真正负责传输的是下层的 TCP/IP：IP 负责寻址（把数据包送到哪台机器），TCP 负责可靠传输（保证数据不丢、不乱序、不重复），HTTP 则负责解释"这段数据到底是什么意思"。
用寄信类比就好懂得多：IP 是门牌地址系统，TCP 是那个保证挂号信不丢的邮政体系，HTTP 是你写在信纸上的格式约定——"你好，请给我某某资源"。这个层级关系非常重要，因为很多诡异问题都出在"跨层"上。比如你访问一个页面白屏，按 F12 看到请求 pending 很久最后超时；这时候先别怀疑 HTTP 报文写错了，很可能是 TCP 连不上、DNS 解析失败，甚至网络本身断了。排查的第一步，永远先确认"问题出在哪一层"。
1.2 HTTPS到底改了什么：TLS握手的情况
先说结论：HTTPS 并不是一种全新的协议，它是"HTTP over TLS"——HTTP 报文外面再套一层 TLS（Transport Layer Security，传输层安全）加密通道。默认端口从 80 变成 443，URL scheme 从 http 变成 https，仅此而已；请求头、响应头、状态码、报文结构，在进入加密通道之后，和 HTTP 一模一样。
TLS 要解决三个问题：
- 机密性：数据加密，防止被偷看。HTTP 本身是"明信片"，所有内容（URL、请求头、body）都可以被沿途设备直接读取，这是 HTTP 最大的隐私短板。
- 完整性：数据在传输中被篡改，接收方能发现。
- 身份认证：确认你连的服务器确实是它自称的那台，而不是中间某个冒牌货。
TLS 握手简化成四步：第一步 ClientHello，客户端告诉服务器自己支持的 TLS 版本、加密套件列表、随机数；第二步 ServerHello 加证书，服务器选一个加密套件，返回自己的数字证书（包含公钥和域名信息）；第三步证书校验与密钥交换，客户端校验证书是否可信（是否由受信任的 CA 签发、域名是否匹配、是否过期），然后生成"预主密钥"用服务器公钥加密后发过去；第四步双方生成会话密钥，之后所有 HTTP 数据都用对称加密的方式加解密。
这里有个很多人误解的点：TLS 握手阶段用的非对称加密（RSA/ECDSA）性能开销大，所以只用来安全地协商出"会话密钥"；真正传输数据时用的是 AES 这类对称加密，速度快得多。换句话说，公钥加密负责"安全地递钥匙"，对称加密负责"用钥匙锁好一整箱信"。
1.3 一次完整请求的端到端旅程
把整条链路串起来看，一次 HTTPS 请求大概是这样的：
- 浏览器解析域名，走 DNS 查询拿到服务器 IP。
- TCP 三次握手建立连接（SYN、SYN-ACK、ACK）。
- TLS 握手，协商出会话密钥（HTTPS 才有这一步，HTTP 直接跳过）。
- 发送 HTTP 请求：请求行加请求头加空行加请求体，明文写好，然后用会话密钥加密成密文发出。
- 服务器解密、解析、处理业务，生成 HTTP 响应，同样加密后返回。
- 浏览器解密、解析响应，渲染页面或触发后续动作。
每一步失败，表现出来的症状都不同：DNS 失败是域名解析错误；TCP 失败是连接超时；TLS 失败是证书错误或握手失败；只有最后到了 HTTP 层，才会出现 404、403、502 这些状态码。所以看到状态码之前，先想想它到底是在哪一层被"定义"出来的，排障方向才不会跑偏。
2. 客户端在"说什么"：请求头的组成与实战用法
2.1 请求行与报文格式
HTTP 请求报文长得非常规整，由四部分组成：请求行、请求头、空行、请求体。空行必不可少，它是"头结束了"的标记，没有空行，服务器就不知道头到哪结束、body 从哪开始。
POST /api/login HTTP/1.1 Host: example.com Content-Type: application/json User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Content-Length: 36 {"username":"tom","password":"123"}请求行三个字段：方法（POST）、请求目标（/api/login）、协议版本（HTTP/1.1）。方法常见的有 GET（取数据）、POST（提交数据）、PUT（整体替换）、PATCH（部分更新）、DELETE（删除）、HEAD（只取响应头不取 body）、OPTIONS（探测服务器支持哪些方法，CORS 预检就靠它）。
注意这个例子里，{"username":"tom","password":"123"}正好是 36 个字节，所以 Content-Length 是 36。服务器读取时靠 Content-Length 知道 body 读多少，才不会把下一个请求的内容混进来。这就是"HTTP 连接复用"能成立的前提——同一个 TCP 连接上连续发多个请求，如果没法精确切分每个请求的边界，必然串包。
2.2 高频请求头逐个说清
请求头字段很多，但业务里真正天天打交道的就下面这些：
| 请求头 | 作用 | 实战要点 |
|---|---|---|
| Host | 目标主机和端口 | HTTP/1.1 起必须携带，一个服务器挂多个域名靠它区分 |
| User-Agent | 客户端身份标识 | 反爬、统计、内容协商都看它，非常容易被伪造 |
| Referer | 来源页面 URL | 防盗链、统计来源用，注意和 Origin 区分 |
| Origin | 发起请求的来源（协议+域名+端口） | CORS 场景必看，不带路径 |
| Cookie | 会话凭证 | 浏览器自动携带，注意 HttpOnly 属性 |
| Authorization | 认证凭据 | 常用 Bearer Token、Basic 认证 |
| Content-Type | 请求体格式 | application/json、x-www-form-urlencoded、multipart/form-data |
| Content-Length | 请求体字节数 | 与 Transfer-Encoding 互斥 |
| Accept | 期望的响应格式 | 告诉服务器希望返回 JSON 还是 XML |
| Accept-Encoding | 支持的压缩算法 | gzip、br；不写可能返回未压缩大包 |
| Range | 请求资源的一部分 | 断点续传、视频拖动播放靠它 |
| If-Modified-Since / If-None-Match | 条件请求 | 配合 304 做协商缓存 |
| X-Forwarded-For | 原始客户端 IP | 由网关/负载均衡追加，可伪造，不能直接信任 |
挑几个重点展开。
Host：为什么 URL 里已经有域名了，请求头还要带 Host？因为 HTTP/1.1 允许一台服务器（同一个 IP）上部署成百上千个虚拟主机。服务器收到请求后，靠 Host 字段决定把请求交给哪个站点。所以"Host 头"和"服务器上的域名"如果不匹配，就会得到 404 或默认站点页面。这个字段也是 Host 头攻击的核心目标。
User-Agent：我以前排查过一个诡异问题，某个内部爬虫每天固定时间被第三方接口 403，手动用浏览器访问完全正常。最后发现是爬虫的 User-Agent 没有伪装，被对方 WAF 按"非浏览器请求"拦了。把 UA 改成和浏览器一致后，问题消失。所有反爬第一步几乎都是看 UA。
Referer 和 Origin：Referer 会带上完整路径，还可能带了敏感 query 参数；Origin 只在跨域请求和 POST 请求里普遍携带，值只有协议加域名加端口。为了安全，很多框架会对 Referer 做校验来防 CSRF，结果就是第三方页面里嵌入你的链接时 Referer 为空，如果后端强制校验 Referer 就直接误杀，这类问题要把 Referrer-Policy 策略配置对才能解决。
2.3 "a标签下载带不上token"的三种解法
我经常看到有人问，"用 a 标签下载视频，接口要求带 token，怎么带？"答案是：a 标签做不到。它的下载请求是浏览器直接发起的，能自动带的只有 Cookie、Referer 这类由浏览器管理的头，你没办法在 href 里塞一个自定义请求头。
推荐的三种方案：
- fetch + blob 下载：先用 fetch 请求接口并带上 Authorization 等自定义头，拿到响应后转成 blob，再用 URL.createObjectURL 生成临时 URL，最后动态创建 a 标签触发下载。
- token 放 Cookie：如果视频接口和页面同源，可以让接口从 Cookie 里读 token，这样 a 标签、video 标签都能直接用。缺点是 Cookie 有大小限制（4KB 左右）、在第三方场景容易泄漏，需要配合 HttpOnly 和 SameSite 使用。
- token 放短时效签名 URL：把 token 或签名拼到 query 参数上，生成一个几分钟内有效的下载地址，适合分享给第三方播放器的场景。缺点是 URL 会出现在访问日志里，签名一定要短时效，最好再绑定 IP。
给一个方案 1 的示例代码：
async function downloadWithToken(url, token, filename) { const resp = await fetch(url, { headers: { 'Authorization': `Bearer ${token}` } }) if (!resp.ok) throw new Error('download failed: ' + resp.status) const blob = await resp.blob() const objectUrl = URL.createObjectURL(blob) const a = document.createElement('a') a.href = objectUrl a.download = filename || 'download.bin' document.body.appendChild(a) a.click() a.remove() URL.revokeObjectURL(objectUrl) }注意事项：大视频用 blob 方式会整段加载进内存，容易把页面搞崩；更稳妥的是以流式方式写入文件（配合 File System Access API 或分片下载）。文件名最好从响应头 Content-Disposition 解析，而不是硬编码。还要确保服务端允许这个接口跨域访问，否则 fetch 会先死在 CORS 上。
2.4 用curl构造带请求头的请求
curl 是排查 HTTP 问题的首选工具，比起浏览器，它能看到和控制的细节多得多。最常用的一组命令：
curl -v 'https://api.example.com/v1/users' \ -H 'Authorization: Bearer my_token' \ -H 'User-Agent: DebugClient/1.0' \ -H 'Content-Type: application/json' \ -d '{"page":1,"size":20}'-v 会把请求头、响应头、TLS 握手过程全部打印出来，我排查任何一个接口问题都会先跑一遍这个命令。真实开发中，-H 可以写多个；同一个头写两遍，大部分服务端会取最后一个，也有会合并的，所以调试时不要指望靠重复头来模拟"多值头"。
curl 还有一个常被忽略的点：默认 curl 对多个 URL 会尽量复用 TCP 连接（HTTP/1.1 Keep-Alive），当你用curl URL1 URL2这种方式连续请求同一个站点时，可以在输出里看到 "Re-using existing connection" 的字样，这就是 HTTP 连接复用。理解了这个，你就明白为什么服务器端的"连接数"不等于"请求数"——一个连接上可以跑成百上千个请求，这也是 HTTP/1.1 相比 1.0 最大的性能改进。到了 HTTP/2，更进一步，一个连接上多个请求可以同时并行，不用排队等前一个结束。
2.5 不止浏览器：嵌入式与桌面端怎么发HTTP
很多人以为 HTTP 只有浏览器和服务器才用，其实嵌入式、桌面端也大量在发 HTTP。STM32 这类 MCU 上，常用 lwIP 协议栈里的 http client 组件，或者用 cJSON 拼 JSON、自己按报文格式拼字符串再通过 socket 发送；要求高一点会用 mbedTLS 做 HTTPS。Qt 桌面应用则直接用 QNetworkAccessManager，一行request.setRawHeader("Authorization", token)就能给请求加头。前端 uni-app 生态里的 luch-request 请求库，GET 请求配请求头也是在 header 对象里加字段，比如request.get(url, { header: { Authorization: token } })，原理和 curl 的 -H 完全一样。
在这些场景里，最容易犯的错是忘了 Host 头、忘了 Content-Length 要算准、以及 HTTP 头必须以\r\n而不是\n结尾。很多 C/C++ 手写 HTTP 的 Bug，最后都出在这三个点上。
3. 服务端的"回话"里藏着什么：响应头拆解
3.1 响应行与状态码串起来读
HTTP 响应报文结构和请求报文对称：响应行、响应头、空行、响应体。
HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Content-Length: 38 Cache-Control: no-store Set-Cookie: session=abc123; Path=/; HttpOnly {"status":"ok","data":{"id":10086}}响应行三要素：版本（HTTP/1.1）、状态码（200）、原因短语（OK）。状态码是机器读的，原因短语是人读的；不同服务器对同一状态码的原因短语可能略有不同（比如有的返回200 Why Not），但状态码本身是标准化的，这就是为什么排障时要"看码"而不是"看字"。
3.2 高频响应头逐个说清
| 响应头 | 作用 | 实战要点 |
|---|---|---|
| Content-Type | 响应体 MIME 类型和编码 | 浏览器渲染错误/乱码，90% 和它有关 |
| Content-Length | 响应体字节数 | 和请求一样，用于切分报文边界 |
| Transfer-Encoding: chunked | 分块传输 | 服务端不能预知长度时使用，以 0 长度块结束 |
| Set-Cookie | 服务端种 Cookie | 属性 HttpOnly、Secure、SameSite |
| Cache-Control | 缓存策略 | no-store、no-cache、max-age、public/private |
| ETag | 资源版本标识 | 配合 If-None-Match 做协商缓存 |
| Last-Modified | 资源最后修改时间 | 配合 If-Modified-Since |
| Location | 重定向目标地址 | 配合 301/302/303/307/308 |
| Server | 服务器软件标识 | 生产环境建议隐藏或伪装 |
| Access-Control-* | CORS 跨域控制 | 见 3.3 |
| Strict-Transport-Security | HSTS 强制 HTTPS | 告诉浏览器以后只能走 HTTPS |
| Content-Security-Policy | CSP 内容安全策略 | 大幅降低 XSS 风险 |
| X-Content-Type-Options | 禁止 MIME 嗅探 | 建议固定为 nosniff |
| X-Frame-Options | 禁止页面被 iframe 嵌入 | 防点击劫持 |
挑几个重要的说。
Content-Type 与乱码：响应头写作charset=utf-8，但页面仍乱码，通常是因为 HTML 里又写了一个不同的 meta charset，或者服务端实际输出的字节流编码和声明不一致。浏览器解码时，响应头的 charset 优先级高于 HTML meta 标签。所以你的服务端如果统一输出 UTF-8，别在业务代码里再造一个 GBK 的字符串出来。
Cache-Control 与 ETag 的配合：强缓存（max-age）是"过期前根本不发请求"；协商缓存是"每次发请求问服务器，资源变没变"，没变返回 304，变了返回 200 加新资源。ETag 是内容哈希，Last-Modified 是时间戳，一般 ETag 更准——Last-Modified 最低精度是秒，同一秒内改了两次内容，时间戳根本发现不了。
Set-Cookie 属性：HttpOnly 让 JavaScript 读不到（防 XSS 偷 Cookie），Secure 只允许 HTTPS 下携带，SameSite=Lax/Strict 用来防 CSRF。我见过太多把 Session 放 Cookie 但没设这些属性的老系统，基本等于把钥匙挂在门把手上。
3.3 跨域场景下的响应头博弈
跨域（CORS）是前端天天遇到的东西，本质是浏览器基于"同源策略"做的一道安全检查。页面在 a.com，用 fetch 请求 b.com 的接口，浏览器会先看响应头里有没有允许 a.com 的Access-Control-Allow-Origin，没有就报blocked by CORS policy，虽然服务器其实已经返回了数据。
对于非简单请求（比如带自定义头 Authorization、Content-Type 为 application/json 的 POST），浏览器还会先发一个 OPTIONS 预检请求，问服务器"允不允许我用这个方法、带这些头"，服务器用Access-Control-Allow-Methods和Access-Control-Allow-Headers回答。预检通过后才会发真实请求。
开发时遇到 CORS 报错，正确的排查顺序：
- 打开 DevTools，看到底是预检失败还是真实请求失败。
- 看响应头里是否带了
Access-Control-Allow-*。 - 看这几个头的值是否覆盖了请求的 Origin、Method、Headers。
- 注意
Access-Control-Allow-Origin不能是*的同时又带Access-Control-Allow-Credentials: true，只要带 Cookies 就不能用通配符。
3.4 自定义业务响应头与常见坑
业务里经常用X-前缀定义自己的头，比如X-Trace-Id（链路追踪）、X-RateLimit-Remaining（限流剩余量）。好处是调试特别方便——一个接口慢了，看响应头里的 TraceId 就能去日志里捞全链路。
三个坑必须知道：
- HTTP 头有大小限制：常见 Web 服务器默认单个头 8KB 到 16KB，加起来几十 KB 就会报 431 Request Header Fields Too Large。别把大的业务数据放头里。
- 头字段只能是 ASCII 字符：中文字符要 URL 编码或 Base64 后放进去，直接放中文会触发畸形请求。
- 头会被中间层改写：经过网关/负载均衡时，部分头可能被丢弃、合并或追加（尤其是 X-Forwarded-* 和 Cookie）。自定义头命名别和标准头、网关保留头冲突，否则你在服务端读到的和客户端发的可能完全不一样。
4. 状态码实战手册：从200到524一次讲透
4.1 五类状态码的整体认知
状态码第一位数字决定类别：
- 1xx（信息）：请求已收到，继续处理。常见的 100 Continue 表示"body 可以发了"；101 Switching Protocols 用于 WebSocket 升级。
- 2xx（成功）：请求成功。200、201、204、206。
- 3xx（重定向）：需要进一步操作。301、302、303、304、307、308。
- 4xx（客户端错误）：请求有问题，是客户端（或调用方）的责任。
- 5xx（服务器错误）：请求没错，是服务器和上游的责任。
记住这个分类后，排障的第一步就能先划分责任：4xx 先查自己发的请求，5xx 先查服务器和上游。很多人拿到 403 就猛查服务器，其实是自己 UA 被拦了，方向完全反了。
4.2 高频状态码逐一定义与场景
2xx
- 200 OK：最正常。但注意，很多接口即使业务失败也返回 200 加错误码，这是国内 API 的常见风格。判断业务成败不能只看 HTTP 状态码。
- 201 Created：创建成功，通常配合 Location 指向新资源。
- 204 No Content：成功但没有 body。删除操作、保存操作常用，避免传一个空 JSON。
- 206 Partial Content：部分内容。Range 头请求的视频切片、断点续传靠它。
3xx
- 301 Moved Permanently：永久重定向。换域名、http 跳 https 常用。搜索引擎会把权重转到新地址。
- 302 Found：临时重定向。语义上是"这次先去别处，下次还来原来地址"。
- 303 See Other：POST 之后让你去 GET 结果页（PRG 模式），防刷新重复提交。
- 304 Not Modified：协商缓存命中，没有新的 body，浏览器直接用自己的缓存。
- 307/308：和 302/301 语义相同，但规定重定向时不能把 POST 改成 GET。老系统改接口地址时，别把 POST 的 307/308 处理成 301，否则请求体丢了。
4xx
- 400 Bad Request：报文格式错误或参数非法。服务端解析不了 body、JSON 格式错了，都会给 400。
- 401 Unauthorized：未认证。没登录或 token 失效。规范做法是响应头带
WWW-Authenticate提示客户端怎么认证。 - 403 Forbidden：已认证但无权限，或者服务器就是不让你访问。UA 被 WAF 拦截、IP 被拉黑、目录无权限，都可能 403。
- 404 Not Found：路径不存在。可能是路由没配、资源被删、前端请求路径写错，也可能是服务端故意用 404 掩盖资源存在（防目录探测）。
- 405 Method Not Allowed：方法不对。接口只接受 POST，你发了 GET 就 405。响应头 Allow 字段会列出允许的方法。
- 408 Request Timeout：服务器等请求等了太久。
- 409 Conflict：资源冲突，常见于并发创建同名资源、版本号冲突。
- 413 Payload Too Large：body 太大，超过了上传限制。
- 429 Too Many Requests：限流了。看响应头 Retry-After 能知道多久后再试。
5xx
- 500 Internal Server Error：服务器内部异常，代码抛异常、进程崩溃都可能。
api call failed after 3 retries: http 500: llama-server process has terminated这种报错，就是本地推理服务进程挂掉了，上游调用方重试三次全撞上 500。 - 502 Bad Gateway：网关/入口拿不到上游的合法响应。常见原因：上游进程挂了、端口不对、防火墙拦截、上游响应格式非法（比如 HTTP 头少个
\r\n）。 - 503 Service Unavailable：服务暂时不可用。常见于启动中、过载保护、主动下线的实例。配合 Retry-After 告诉客户端什么时候再来。
- 504 Gateway Timeout：网关连上了上游，但上游在规定时间内没返回。和 502 的区别就是"连没连上"。
- 524 A Timeout Occurred：这个状态码不在 RFC 标准里，是 CDN 厂商自创的——网关等源站响应等到了超时阈值之上，主动断开连接。看到 524，基本就是源站太慢，该让源站背锅。
4.3 三组最容易混的状态码对比
| 对比组 | 区分要点 |
|---|---|
| 301 vs 302 | 永久 vs 临时；301 会被客户端缓存，302 通常不会 |
| 302 vs 303 vs 307 | 302 允许把 POST 变 GET（各浏览器处理不一致）；303 强制改 GET；307 强制保留原方法 |
| 401 vs 403 | 401=你没证明你是谁；403=服务器知道你是谁，但你不许进 |
| 502 vs 504 | 502=上游连接失败/响应非法；504=连接建立了但超时了 |
| 403 vs 429 | 403=权限/规则拒绝；429=你请求太频繁被限流 |
4.4 用状态码定位线上问题的完整思路
结合几个真实报错讲案例。
案例一：unavailableinvalidchannel: http 403 forbidden for channel anaconda/pkgs/main。我装 Python 环境时经常看到，conda 配了不存在的 channel 地址，镜像源直接返回 403。解法不是去改权限，而是把 channel 地址改成官方或镜像站的有效地址，再清 conda 缓存。
案例二：unexpected status 502 bad gateway: unknown error, url: http://127.0.0.1:1572。本地调试工具请求本机端口返回 502。这时候我会先问：端口上到底有没有服务在监听？没有就是服务没起来；有就再看是不是服务只监听了 IPv6 而请求走了 IPv4（或反过来），或者本机防火墙拦了回环流量。
案例三：imaauthapi start http 524。认证 API 启动后请求直接 524，说明源站进程可能根本没监听端口，或握手后不响应。优先看源站启动日志，而不是反复重启。
完整排查思路：
- 先用 curl -v 复现，记录状态码、响应头、响应体。
- 判断责任方是客户端、网关还是源站：4xx 看请求，5xx 看服务。
- 有响应体先读响应体，很多框架的错误信息写得比状态码细得多。
- 看响应头的 Server 字段，判断是哪个组件返回的这个错误（Nginx 返回的 502 和 Spring Boot 自带错误页的格式完全不同）。
- 查网关/接入层日志和上游日志，把 TraceId 对上。
- 修完后用同样的 curl 命令验证，并把结果存档。
5. 数据包结构：从以太网帧到TLS密文
5.1 HTTP报文在TCP流中的真实形态
当抓包工具抓到一段 HTTP 明文时，你会看到它就是一段 ASCII 文本，字段之间用\r\n分隔：
GET /index.html HTTP/1.1\r\n Host: example.com\r\n User-Agent: curl/8.0\r\n Accept: */*\r\n \r\n注意是\r\n（CRLF），不是\n。很多手写 HTTP 的 C 程序只发了\n，严格解析的服务器会认为报文畸形。请求头结束后的空行本身就是\r\n，表示"头结束了，下面如果有 body 就是 body"。与直觉相反，GET 请求通常没有 body，但请求头后面依然有一个空行。
5.2 在Wireshark里看数据包的分层
用 Wireshark 打开一个 HTTP 抓包文件，选中一个包，协议树从上到下一般是：
| 层 | 作用 | 和 HTTP 的关系 |
|---|---|---|
| Frame | 物理帧信息 | 包含抓包时间、帧长度 |
| Ethernet II | 以太网帧头 | 源/目的 MAC 地址，局域网转发用 |
| IPv4 | 网络层 | 源/目的 IP，跨网段寻址 |
| TCP | 传输层 | 源/目的端口、序号、确认号，HTTP 载荷在这里 |
| HTTP | 应用层 | 请求行、请求头、body 的明文内容 |
Wireshark 里几个常用过滤表达式：http（所有 HTTP 包）、http.request（只看 HTTP 请求）、http.response（只看 HTTP 响应）、tcp.port == 443（只看 443 端口流量）、tcp.stream eq 0（追踪某条 TCP 连接的全部包）。
5.3 HTTPS为什么抓到的是"密文"：TLS记录层结构
HTTPS 抓包抓到的不是 HTTP 明文，而是 TLS 记录层（TLS Record Layer）。每个 TLS 记录开头有 5 个字节的明文头：类型（1 字节）、版本（2 字节）、长度（2 字节），后面跟着载荷。在 Wireshark 里看，TLS 协议树大概是TLS -> TLSv1.3 Record Layer: Handshake / Application Data。
TLS 记录类型常见五种：
- Handshake（22）：握手消息，如 ClientHello、ServerHello、Certificate。
- ChangeCipherSpec（20）：表示"从下一条开始要加密了"。TLS 1.3 里实际已基本废弃，仅保留兼容。
- ApplicationData（23）：加密后的业务数据，也就是被保护的 HTTP 报文。
- Alert（21）：告警，比如证书错误、关闭通知。
- Heartbeat（24）：心跳检测。
抓包时你能看到握手的 ClientHello、ServerHello 里大部分字段还是明文的（比如域名、加密套件），但从 ChangeCipherSpec 之后，所有 ApplicationData 都是密文——这就是"HTTPS 抓包抓到一堆看不懂的字节"的原因。
5.4 解密HTTPS流量两大常用手法
调试自己的客户端、服务端时，有两种正经手段能看到 HTTPS 明文。
手法一：本地中间人调试工具。我用过的 Charles、Fiddler 这类工具会生成一个本地根证书，你把它安装到系统信任区后，工具会和目标服务器建立一条 TLS 连接，和你再建立一条 TLS 连接，于是它可以同时看到两个方向的明文。本质上是把一条 TLS 拆成两段。注意，这只允许用在调试自己客户端或测试环境，如果在公共网络里安装来路不明的根证书，等于把 HTTPS 的信任链拱手让人。
手法二：导出会话密钥给 Wireshark。现代浏览器和多数网络库支持设置环境变量SSLKEYLOGFILE，把每次 TLS 握手生成的会话密钥写进文件；Wireshark 在协议设置里指定这个文件，就能把抓到的密文用密钥解出来。这个方式不用装根证书，对原生程序调试很友好。缺点是密钥文件非常敏感，谁拿到它谁就能解密对应会话，用完立刻删。
5.5 HTTP/2、HTTP/3的数据包结构变化
HTTP/1.1 是文本协议，肉眼可读；HTTP/2 改成二进制分帧，一个 TCP 连接里可以同时跑多个请求（流），每个流由多个帧组成。常见帧类型有 HEADERS（头部）、DATA（数据）、SETTINGS（设置）、PING、RST_STREAM 等。头部还会用 HPACK 压缩，所以抓包看 HTTP/2 时，请求头不是一行行明文，而是"HEADERS 帧"里的键值列表。这也是为什么浏览器和很多站点已经用 h2，但你抓包感觉不像以前那么"直白"了。
HTTP/3 则更进一步，把传输层从 TCP 换成了基于 UDP 的 QUIC，连 TLS 握手也和连接建立合并在一起（0-RTT/1-RTT），进一步减少了握手延迟。数据包结构上，HTTP/3 的帧再套 QUIC 的封装，再套 UDP 头。虽然结构复杂了，但排障思路没变——依然先分清哪一层出问题。
6. 实战复盘：三个状态码串起来的十小时排障
6.1 第一轮：502与网关后端失联
某天下午，测试环境所有走网关的接口陆续开始报 502 Bad Gateway。我第一反应是后端服务挂了，但登录服务器用 curl 直连后端 IP 加端口，发现返回 200 完全正常。这说明问题不在后端应用，而在网关和后端之间。
接着看网关的错误日志，里面出现大量upstream returned http 403 forbidden。这个报错的意思是，网关向上游转发请求时，上游返回了 403，网关把这次异常回复转成了对客户端的 502。继续排查发现，网关配置的健康检查路径被改成了/healthz，而后端服务根本没有这个路径，健康检查返回 404，网关就认为后端不可用，把请求全部判失败。
最后定位到根因，是下午有人改配置时把健康检查路径写错了。改回来之后，502 立刻消失。这轮排障花了三个小时，教训就一句话：502 出现时，先分清是谁报的 502；直连后端能通，那问题就在网关和后端的连接判断上。
6.2 第二轮：403与访问控制
同一个体系里，另一个接口报 403。仔细看 403 响应体，里面有个 JSON 提示是 WAF 拦截，理由是 User-Agent 命中黑名单。原来同事写了个内部工具，把 UA 写成了python-requests/2.31.0，测试环境的 WAF 规则对常见脚本 UA 做拦截，于是整个工具都被 403。
这个案例和前面 conda 的 403 本质上一样——403 不一定是你没权限，也可能是你"看起来不像人"。遇到 403，先别急着改权限，把响应体读完，看看是 WAF 拦的、应用层拦截的，还是真没权限。
6.3 第三轮：524与源站超时
还有一类情况：接口偶尔返回 524。这个状态码是 CDN 厂商特有的，含义是"CDN 节点等源站响应等到了超时上限"。查源站日志，请求其实到了，但处理了接近 60 秒，超过了 CDN 的等待阈值。
再看代码，接口里有个同步调用第三方服务的逻辑，第三方服务抖动时，整个接口就卡住。最后方案：把第三方调用改成异步加缓存，接口本身控制在 2 秒内返回。调整之后 524 再也没出现过。
6.4 复盘：排障顺序与工具清单
把三件事串起来，背后是一个通用的排查顺序：
- 复现：能稳定复现的问题都好查；稳定复现不了，先抓现场（日志、抓包、监控）。
- 分层：DNS/TCP/TLS/HTTP 逐层确认故障层。
- 看状态码分类：4xx 查请求，5xx 查服务。
- 看响应头：Server 字段判断是谁返回的，TraceId 对日志。
- 看响应体：很多时候错误信息就写在 body 里。
- 查上下游日志：把网关日志、应用日志、依赖服务日志对齐。
工具清单：
- curl -v：最优先，能复现、能看到完整头。
- 浏览器 DevTools Network：看前端请求、CORS、时序。
- tcpdump：服务器上抓包取证。
- Wireshark：分析抓包文件，看 TCP/TLS/HTTP 分层。
- JMeter：压测与录制脚本。JMeter 录制 HTTPS 时，要先把录制组件的根证书导入 JVM 的信任库，再把浏览器或客户端的流量指向 JMeter 监听端口，才能录到 HTTPS 请求，否则录到的全是 TLS 握手和 CONNECT。
7. 请求头里的攻防：从一道CTF题看HTTP头注入
7.1 头注入是怎么发生的
HTTP 头以\r\n作为字段分隔符，如果服务端把用户输入直接拼进响应头，且没有过滤\r\n，攻击者就能"注入"新的响应头甚至响应体。
举个典型场景，一个重定向接口这样拼 Location：
Location: http://example.com/redirect?url=用户输入如果用户输入的是/safe\r\nSet-Cookie: admin=1，拼出来的响应头就变成了两行，攻击者可以因此种 Cookie、注入任意响应头，甚至直接注入响应体内容（两个\r\n\r\n之后就是响应体）造成 XSS。这就是 CRLF 注入，也叫 HTTP 响应拆分。
7.2 从"[极客大挑战 2019] http"看这类题型
CTF 里很多送分 Web 题，就是欺负你没认真看过请求头。比如极客大挑战这题，考点就是服务端检查了 User-Agent、Referer、X-Forwarded-For，要求你依次改成指定值才给 flag。
解题思路很简单：
- 先用 curl -v 访问，看响应提示它"想要什么"。
- 按提示加对应请求头：
curl -v http://target.challenge/ \ -H 'User-Agent: ClueBrowser/1.0' \ -H 'Referer: https://clue.example.com' \ -H 'X-Forwarded-For: 127.0.0.1'- 如果响应要求"必须从本地访问"，就把 X-Forwarded-For 或 X-Real-IP 改成 127.0.0.1。
这类题真正考的是协议熟悉度：知道 Host、UA、Referer、XFF 各自是干嘛的，会手写 curl 请求头，就能解。这也是我建议所有 Web 方向的同学把 HTTP 报文格式吃透的原因——安全题的入口，往往就是你对协议字段的理解。
7.3 生产环境的头注入防护清单
用真实项目经验说，防 CRLF 注入就三件事：
- 所有要拼进响应头的用户输入，先做校验，把
\r\n直接拒绝。 - 能用框架 API 设置头，就不要自己拼字符串。主流框架对设置 Header 的 API 会做换行过滤，但如果你是用底层 socket 手写响应头，必须自己处理。
- 安全响应头建议全开：Content-Security-Policy、X-Content-Type-Options: nosniff、X-Frame-Options: DENY、Strict-Transport-Security。前两个能挡住很大一部分和头注入相关的 XSS 与 MIME 嗅探风险。
从我自己的经验说，学 HTTP/HTTPS 最有效的方式不是背字段，而是带着问题去抓包、去改请求头、去看响应头。每次排查问题，我都会把完整的请求头、响应头复制到笔记里，存够一两个月再回头看，很多规律自己就浮出来了。建议新手从浏览器 DevTools 的"Copy as cURL"开始，先把一个正常请求完整还原出来，再逐字段删掉，看服务端反馈变化，感受每个头的分量。遇到 504/524 这类和时间相关的状态码，记得先问一句：这个超时到底是被谁定义的？答案通常不在浏览器里，而在网关和源站的配置中。
