排查网络延迟关键在于分析各环节毫秒级耗时，聚焦协议阶段耗时（如syn→syn-ack）、单向传输延迟（如ttfb）和包间时序异常（如重传间隔），通过捕获过滤锁定目标流、time-sequence图看rtt、expert info识别重传与dup ack，结合正常耗时参照系定位瓶颈。
排查网络延迟，关键不是看“有没有包”，而是看“每个环节花了多少时间”。Wireshark 的优势在于它能把一次完整通信拆解成毫秒级的时间切片，让你看清 DNS 解析、TCP 握手、TLS 协商、HTTP 请求响应等每一步的真实耗时。重点不是堆砌功能，而是聚焦三类时间指标：协议阶段耗时（如 SYN→SYN-ACK）、单向传输延迟（如请求发出到首字节返回）、以及包间时序异常（如 ACK 滞后、重传间隔）。
抓对流量：先锁定目标会话再分析
盲目抓全量包会淹没关键路径。建议分两步操作：
- 用捕获过滤器缩小范围，例如：tcp and host 10.20.30.40 and port 443（只抓目标服务器的 HTTPS 流量）
- 抓包过程中触发一次明确的操作（如浏览器访问某个 API），确保流量有始有终
- 抓完后，用显示过滤器 tcp.stream eq 5 快速定位该次交互对应的 TCP 流（Wireshark 自动编号，可在 Packet Details 面板里点 TCP 层查看 stream index）
看懂耗时：从三次握手和首字节延迟入手
用户感知的“卡”，往往卡在连接建立或首屏加载。这两个时间点最能反映底层延迟：
- TCP 握手时延：选中第一个 [SYN] 包 → 右键 → Follow → TCP Stream → 切换到 Time-Sequence Graph (Stevens)，图中第一个垂直线段就是 SYN 到 SYN-ACK 的 RTT
- 首字节时延（TTFB）：在 HTTP 流中找到 GET 请求包 → 找到它对应响应的第一个 [PSH, ACK] 包 → 看底部状态栏的 Time 差值，或右键该响应包 → Protocol Preferences → TCP → Calculate conversation timestamps 启用后直接显示 “Time since request”
- 若握手 RTT 正常但 TTFB 很高，问题大概率在服务端处理或 TLS 协商；若两者都高，则链路层延迟或中间设备（如代理、WAF）介入较深
识别异常模式：用专家信息和流图定位隐形瓶颈
有些延迟不体现在单个数值上，而是由重复行为累积而成：
- 打开 Expert Info（底部标签页），重点关注黄色警告中的 Retransmission 和 Duplicate ACK：频繁重传说明丢包或路径拥塞，而连续多个 Dup ACK 往往预示着接收端窗口停滞或乱序严重
- 使用 Statistics → TCP Stream Graph → Round Trip Time 查看 RTT 曲线：如果 RTT 在某段时间内持续抬升（非偶发抖动），可能是中间链路出现限速、队列积压或 QoS 策略生效
- 对比同一会话中不同请求的延迟：如果前几个请求慢、后续变快，可能是 TLS 会话复用未生效；如果越往后越慢，可能是服务端连接池耗尽或客户端滑动窗口收缩
不复杂但容易忽略：延迟分析的本质是比对预期与实际的时间差。Wireshark 提供的是原始时间戳，真正有用的是你心里那张“正常流程耗时地图”——比如本地局域网握手应在 1–3ms，跨省 HTTPS 应在 30–80ms。有了参照系，数字才真正开口说话。
