分块传输是怎么回事
当响应长度无法事先确定时，服务端会用 Transfer-Encoding: chunked 把实体拆成若干块陆续发出，每块前面是十六进制的长度，最后以一个长度为 0 的块收尾。这是流式接口、服务端推数据、边算边发的典型做法。判断响应是否完整，关键看有没有收到结尾的 0 块；只有中途断开、缺少结尾标记，才说明传输没有走完。
基本信息
| 适用平台 | Wireshark / tshark 解析的 HTTP/1.1 流量 |
|---|---|
| 过滤字段 | http.transfer_encoding contains "chunked" |
| 结束标记 | 长度为 0 的块，其后可跟可选的尾部字段 |
| 与长度头关系 | 使用分块传输时通常不再出现 Content-Length |
典型使用场景
- 流式接口迟迟没有返回完整数据，确认传输是否正常结束
- 排查客户端解析报错，判断是分块格式问题还是内容问题
- 验证网关是否对分块响应做了缓冲，压缩了流式的意义
- 统计首块到达时间，量化服务端首个字节的响应速度
- 确认长连接上多次响应之间是否被正确切分
- 为「下载进度不动但连接仍在」类问题提供证据
观察要点
观察要点
http.transfer_encoding contains "chunked"
# 分块头部形如: 1a3\r\n……数据……\r\n （1a3 为十六进制长度）
# 结尾: 0\r\n\r\n，其后可能有 trailer 或直接结束
# Wireshark 的 Dechunked 视图可直接查看重组后的实体
# 缺少 0 块即视为未正常结束，需与连接关闭原因一起看观察项逐项读法
| 观察项 | 含义 | 正常与异常 |
|---|---|---|
| Transfer-Encoding | 声明分块传输 | 与 Content-Length 同时出现属可疑 |
| 分块长度行 | 十六进制表示的本块字节数 | 出现非法字符即格式异常 |
| 0 块 | 实体结束标志 | 缺失说明传输未完成 |
| 首块到达时间 | 服务端首字节耗时 | 偏大指向服务端处理或缓冲 |
| 连接关闭方式 | 流结束后的收尾 | 被重置关闭说明有中断方 |
分块大小与网络分片无关：一个块可能跨多个 TCP 报文段，按段计块会得出错误的块数。
分块传输的耗时统计要基于块到达时间而非仅首尾之差，否则会漏掉分块之间的应用侧停顿。