为什么要把 TCP 事件落到请求上
HTTP/2 把多个请求复用在一条 TCP 连接上，连接级的重传、乱序、窗口收缩会同时影响这条连接上的所有流。只看连接层指标，只能说「这条连接有问题」，回答不了「哪个请求被影响了」。把 tcp.analysis 事件与 http2.streamid 联合过滤，才能把连接级异常落到具体请求，给出可执行的结论。
基本信息
| 联合维度 | tcp.stream 定位连接，http2.streamid 定位该连接上的请求 |
|---|---|
| 连接级字段 | tcp.analysis.* 系列，如重传、重复确认、乱序、零窗 |
| 流级字段 | http2.streamid、http2.headers.* 头部字段 |
| 过滤写法 | 两个条件用 && 组合，互不干扰 |
| 前提条件 | 加密流量需解密后才能看到 HTTP/2 层字段 |
| 注意事项 | HTTP/2 流窗口与 TCP 窗口两套机制要分别看 |
典型使用场景
- 慢请求归因：区分是服务端处理慢，还是同连接上的邻居流把带宽与窗口吃掉了
- 丢包影响面评估：重传发生后，确认同连接上有哪些请求的响应被推迟
- 并发上限核对：观察同一连接上的流数量是否长期贴近服务端设置的上限
- 取消与中断：把 RST_STREAM 与连接的 RST 区分开，判断是上层取消还是连接被断
- 压测复盘：连接级异常与流级耗时的分布放到同一张表里对照
组合过滤
组合过滤
tshark -r a.pcap -Y 'tcp.stream == 7 && tcp.analysis.flags' -T fields -e frame.number -e _ws.col.info
tshark -r a.pcap -Y 'tcp.stream == 7 && http2.streamid == 5' -V | head -80
tshark -r a.pcap -Y 'tcp.stream == 7 && http2.headers.authority contains "api"' -T fields -e http2.streamid
tshark -r a.pcap -Y 'tcp.stream == 7 && http2.type == 3' -T fields -e frame.number # 该连接上的复位流组合过滤对照
| 过滤条件 | 回答的问题 | 判读提示 |
|---|---|---|
| tcp.stream == 7 | 这条连接发生了什么 | 先看连接级异常总量 |
| tcp.stream == 7 && http2.streamid == 5 | 这个请求的帧交互细节 | 看请求到响应的帧序列与耗时 |
| ... && tcp.analysis.flags | 异常落在哪些帧上 | 与请求的帧区间对照定位影响范围 |
| ... && http2.type == 3 | 哪些请求被主动取消 | 区分客户端取消与服务端拒绝 |
| ... && http2.headers.authority contains | 按域名挑出请求 | 确认问题集中在哪个后端 |
HTTP/2 的流级窗口更新与 TCP 的接收窗口是两个独立机制，同一个请求可能被其中任一层限速；两层都要看，只查一层容易把背压来源判错。
加密流量必须先解密才能使用这些字段；只解出 TLS 明文但未让 Wireshark 正确关联协议时，帧仍会显示为普通 TCP 载荷，需要检查解密配置与端口映射。