两段式上传是怎么回事
当客户端请求头里带 Expect: 100-continue 时，它会先只发请求头询问服务端是否愿意接收实体，服务端认为可以就回一个 100 继续，客户端随即发送实体；服务端若不接受，可以直接回 4xx 让客户端省掉发送大体积数据。这条机制常见于大文件上传与需要鉴权的写接口。代价是多了一个往返，交互时间线上表现为「头部、临时响应、实体、最终响应」四段。
基本信息
| 适用平台 | Wireshark / tshark 解析的 HTTP/1.1 流量 |
|---|---|
| 过滤字段 | http.expect contains "100-continue" |
| 状态码 | 100 属于临时响应，不计入最终状态码统计 |
| 权衡 | 多一个往返换取提前拒绝，避免无谓传输大体积数据 |
典型使用场景
- 大文件上传出现额外延迟，确认是否由等待临时响应引起
- 排查上传被提前拒绝时的报文序列，定位服务端拒绝时机
- 对比客户端与网关的实现差异，解释「有的客户端更慢」
- 统计最终状态码时排除临时响应，避免分布统计失真
- 验证代理是否透传 Expect 头，判断链路上有无改写
- 为上传接口的超时配置提供依据
观察形态
观察形态
http.expect contains "100-continue"
# 报文序列: POST 头（无实体）→ 100 Continue → 实体发送 → 最终响应
# 若超时未收到 100，客户端按实现可能在等待后仍发送实体
# 部分实现直接省略等待，先发头再立刻发实体，属正常差异
# 最终状态码取实体发送之后的那一条响应时间线逐段读法
| 区段 | 含义 | 异常信号 |
|---|---|---|
| 头部到临时响应 | 服务端判断是否接收 | 耗时大说明服务端决策慢或存在排队 |
| 临时响应到实体 | 客户端等待与准备时间 | 显著偏长说明等待窗口设置过大 |
| 实体到最终响应 | 服务端处理与返回 | 偏大指向处理耗时而非网络 |
| 整体无临时响应 | 未等待直接发送 | 属实现差异，不代表故障 |
等待临时响应的超时由客户端实现设定，排查上传慢时这个等待窗口往往才是真正的延迟来源。
中间设备不支持该机制时可能直接转发实体，出现「未等待就发送」的形态属于正常实现差异。