Keep-Alive 复用判读
HTTP/1.1 默认使用持久连接，同一条 TCP 连接上可以连续承载多次请求响应。抓包里若看到同一五元组上多次请求响应交替出现，说明复用正常；复用率低意味着每次交互都要重新付出握手与慢启动的成本，页面加载时间会明显变长。
基本信息
| 适用平台 | Wireshark 与 tshark，分析 HTTP/1.x 连接 |
|---|---|
| 观察维度 | 一条 TCP 流内出现的请求次数 |
| 协议依据 | RFC 9112（持久连接与连接管理） |
| 影响因素 | 客户端策略、服务端配置、中间设备空闲超时 |
典型使用场景
- 评估复用效果：统计每条连接承载了多少次请求
- 定位退出原因：看是哪一端先发 FIN 或关闭连接
- 排查超时不匹配：中间设备比客户端更早回收空闲连接
- 关联性能：复用率低时握手与慢启动开销被反复支付
- 灰度对比：改动前后对比连接数与平均请求数
统计每连接请求数
统计每连接请求数
tshark -r http.pcap -Y 'http.request' -T fields -e tcp.stream | sort | uniq -c | sort -rn | head
tshark -r http.pcap -Y 'http.request' -T fields -e http.request.method -e tcp.stream | head
# 观察连接结束：看 FIN 或关闭动作由哪一端发出连接复用判读
| 现象 | 含义 | 下一步 |
|---|---|---|
| 一条流上多次请求 | 复用正常 | 关注每次交互的耗时 |
| 每条流只有一个请求 | 复用未生效 | 查看请求头与两端策略 |
| 连接被主动关闭 | 对端放弃复用 | 确认是哪端先发 FIN |
| 空闲后被断开 | 存在超时不匹配 | 对比两端与中间设备的超时值 |
空闲超时不对称是复用率低的常见原因：哪一端先发 FIN，就说明那一端的超时更短。排查时把客户端、服务端与中间设备的空闲超时值都拉出来对比。
统计连接数时要先排除健康检查与埋点流量。它们自成一路，会把平均值拉低，掩盖真实业务连接的复用情况。
同一五元组被回收之后再次建连会形成两条独立的流。如果只按五元组统计，很容易把两条短连接误算成一条高复用连接。