为什么要拆段
一次请求到响应的总时长可以拆成四段：去程链路、服务端排队与处理、回程链路，以及重传或流控造成的额外等待。抓包时间戳直接给出的只有首尾两端的差，中间段必须靠两端对照或应用日志补齐。拆段的意义在于先把责任范围定下来——是网络往返被拉长，还是服务端处理变慢——否则双方只能各自举证、来回推诿，问题却停在原地。
基本信息
| 适用平台 | 客户端侧抓包为主，服务端侧抓包用于补中间段 |
|---|---|
| 可用指标 | tcp.analysis.ack_rtt 给出往返参考 |
| 拆分口径 | 总时长 = 去程传输 + 服务端排队与处理 + 回程传输 + 重传等待 |
| 前提 | 两端时间戳需先核对时钟偏移，否则不能直接相减 |
典型使用场景
- 接口变慢需要判断是网络还是服务端，避免责任划分靠猜
- 大请求体上传慢，确认瓶颈在发送侧带宽还是服务端读取
- 跨地域访问与同城访问做同一接口的对照测量
- 验证扩容或加缓存后延迟是否真的下降
- 排查偶发的长尾请求，找出长尾出现在哪一段
- 为客户端埋点与应用日志提供网络侧交叉验证
分段口径
分段口径
tcp.analysis.ack_rtt > 0.1 # 先筛出高往返片段
tcp.time_delta > 1 # 帧间间隔异常处
# 客户端侧: 去程与回程合在一起，无法直接分开
# 服务端侧: 报文到达与响应首字节的差，近似服务端处理+排队
# 两侧对齐后: 总时长 - 服务端段 = 网络段往返分段逐项读法
| 区段 | 涵盖内容 | 数据来源 |
|---|---|---|
| 网络往返 | 去程加回程的链路时延 | 客户端侧时间戳、或两侧配对相减 |
| 服务端排队 | 请求在应用或中间件队列等待 | 应用日志与线程池指标 |
| 服务端处理 | 业务逻辑与后端依赖耗时 | 应用侧日志与调用链 |
| 额外等待 | 重传、流控与延迟确认 | 抓包中的重传与零窗标注 |
把「网络总往返」与「服务端处理」分开是拆解的关键一步，只用一个端到端数字无法支撑任何责任划分。
延迟确认会让低流量的小事务出现稳定的毫秒级附加等待，这部分属于协议行为，不应当计入链路时延。