长度字段与实际不符
声明的内容长度与实际传输的实体字节数不一致时会以两种形式暴露：实际少于声明值时，接收方一直等着剩余字节，最终超时；实际多于声明值时，连接边界错乱，多出来的字节会被当成下一条响应的开头，引发连锁的解析错误。
基本信息
| 适用平台 | Wireshark 的 HTTP 解析；代理、网关与源站都可能引入 |
|---|---|
| 判断依据 | 声明的长度与捕获到的实体字节数之差 |
| 前提条件 | 需先确认传输编码，分块传输时长度语义不同 |
| 典型表现 | 接收方长时间静默后超时，而不是立刻报错 |
典型使用场景
- 定位截断：确认响应体是否少于声明的长度
- 排查边界错乱：多余字节导致后续响应解析失败
- 区分压缩影响：压缩后长度指的是压缩后的字节数
- 对齐抓包点：两侧观察到的字节数应当一致
- 定位责任方：对比源站与网关两侧的数据
统计与核对
统计与核对
tshark -r http.pcap -Y 'http.response' -T fields -e http.content_length -e frame.len | head -20
# 对比声明的长度与实际捕获到的实体字节数
# 注意分块传输编码下长度语义不同不一致的两种形式
| 形式 | 表现 | 排查方向 |
|---|---|---|
| 实际少于声明 | 接收方等待剩余字节直至超时 | 中间设备截断或源站提前结束 |
| 实际多于声明 | 连接边界错乱 | 多发字节导致后续解析失败 |
| 分块传输 | 长度以分块为准 | 不要套用内容长度字段 |
| 压缩传输 | 长度为压缩后的字节数 | 先确认编码方式 |
使用分块传输编码时，内容长度字段的语义完全不同，判断完整性要看分块结束标记，而不是比对长度字段。动手核对之前先确认用了哪种编码。
在客户端侧与服务端侧同时抓包时，观察到的字节数可能不同。出现分歧时先对齐抓包位置，再讨论是哪一段引入了差异。
接收方等待缺失字节时的表现是长时间静默后超时，而不是立刻报错。看到这种「静默等待」的形态，优先怀疑实体长度不匹配。