📚 课程目录第4章延迟诊断工具链

4. 延迟诊断工具链：tcpdump、Wireshark、curl、httpstat、mtr 在 Ingress 场景下的使用

在 Ingress 控制器延迟问题定位中，单一工具往往只能提供局部视角。本章构建一套从网络抓包到应用层耗时拆解、再到路径拓扑验证的完整工具链，覆盖数据平面与控制平面的关键诊断环节。

4.1 工具链全景与适用场景

下表列出五种核心工具在 Ingress 延迟诊断中的定位、数据来源及典型问题类型：

工具	诊断层次	数据来源	典型延迟问题
tcpdump	网络包级（L3-L4）	网卡原始报文	TCP 重传、零窗口、握手延迟
Wireshark	协议分析（L4-L7）	pcap 文件	TLS 握手耗时、HTTP 队头阻塞
curl	应用层（L7）	HTTP 请求/响应	DNS 解析、首字节时间（TTFB）
httpstat	请求阶段拆解	curl 内部计时	连接复用、SSL 协商、传输耗时
mtr	网络路径（L3）	ICMP/TCP 探测	中间跳数丢包、不对称路由

诊断顺序建议：先使用 mtr 排除网络路径问题，再用 curl + httpstat 快速定位耗时阶段，最后用 tcpdump + Wireshark 深入分析协议细节。

4.2 tcpdump：Ingress 数据平面抓包

在 Ingress 控制器 Pod 所在节点或直接进入 Pod 网络命名空间抓取经过 iptables/IPVS 规则后的真实流量。

# 抓取 Ingress 控制器 80 和 443 端口流量，保存为 pcap
tcpdump -i any -s 0 -w ingress_traffic.pcap \
  'tcp port 80 or tcp port 443'

# 实时过滤：只显示与特定后端 Service IP 的交互
tcpdump -i eth0 -nn 'host 10.96.0.10 and tcp port 8080'

关键过滤表达式：

TCP 握手延迟：tcp[tcpflags] & (tcp-syn) != 0
重传包：tcp[13] & 4 != 0
零窗口通告：tcp[14:2] == 0

4.3 Wireshark：协议级延迟分析

将 tcpdump 生成的 pcap 文件导入 Wireshark，使用以下分析技巧定位 Ingress 延迟根因：

分析目标	Wireshark 方法	延迟指标
TLS 握手耗时	过滤 `tls.handshake.type == 1`，查看 Client Hello 到 Server Hello 时间差	> 100ms 需关注证书链或密码套件
HTTP 请求排队	统计 > 会话 > 流量图，观察请求间隔	连续请求间隔 > RTT 表明队头阻塞
TCP 重传率	分析 > 专家信息 > 重传/快速重传	重传率 > 2% 需排查丢包
零窗口事件	过滤 `tcp.window_size == 0`	出现即表示接收端应用处理慢

注意：Wireshark 分析 Ingress 流量时，务必在 TLS 解密后查看 HTTP 层。可在 Ingress 控制器上配置 SSLKEYLOGFILE 环境变量导出会话密钥，或使用 (http.request or tls.handshake.type == 1) 过滤未加密的 HTTP/2 流量。

4.4 curl：快速验证与阶段计时

使用 -w 参数输出详细耗时变量，适合在 CI/CD 或监控脚本中集成：

curl -o /dev/null -s -w \
  "time_namelookup: %{time_namelookup}s\n\
time_connect: %{time_connect}s\n\
time_appconnect: %{time_appconnect}s\n\
time_starttransfer: %{time_starttransfer}s\n\
time_total: %{time_total}s\n" \
  https://ingress.example.com/api/health

输出字段与延迟阶段对应关系：

time_namelookup：DNS 解析耗时，若 > 50ms 需检查 CoreDNS 或外部 DNS 响应。
time_connect：TCP 三次握手耗时，反映客户端到 Ingress 控制器的网络 RTT。
time_appconnect：TLS 握手耗时，包含证书验证和密钥交换。
time_starttransfer：从请求发出到收到第一个响应字节，即 TTFB，包含 Ingress 路由匹配、后端转发、业务处理时间。

4.5 httpstat：可视化请求阶段拆解

httpstat 是对 curl 计时功能的封装，以 ASCII 图表直观展示每个阶段的耗时占比：

# 安装
pip install httpstat

# 执行
httpstat https://ingress.example.com/api/v1/users

# 输出示例
DNS Lookup   TCP Connect   TLS Handshake   Server Processing   Content Transfer
[   5ms    |    12ms     |     45ms      |      120ms        |       2ms       ]
    |           |              |                |                  |
    v           v              v                v                  v
   2.74%      6.58%         24.66%           65.75%             1.10%

在 Ingress 场景中，Server Processing 阶段占比过高通常意味着后端应用响应慢或 Ingress 控制器内部路由处理存在瓶颈。若 TLS Handshake 占比超过 30%，应考虑启用会话复用或调整密码套件。

4.6 mtr：网络路径与丢包探测

mtr 结合 traceroute 和 ping，持续探测从诊断节点到 Ingress 控制器及后端 Pod 的每一跳延迟和丢包率：

# 探测到 Ingress 控制器 VIP
mtr -r -c 10 10.96.0.10

# 探测到后端 Pod IP（需通过 Ingress 控制器网络命名空间）
mtr -r -c 10 --tcp -P 8080 10.244.1.25

输出解读要点：

Loss% 列：任何一跳出现非零丢包，需排查对应节点或网络设备。
Last/Avg/Best/Wrst 列：平均延迟突增 > 50% 可能表明路径切换或拥塞。
跳数变化：多次探测跳数不一致，说明存在不对称路由或 ECMP 哈希冲突。

  实战案例：某生产环境 Ingress 延迟从 5ms 飙升至 200ms。使用 mtr 发现第 3 跳（Kubernetes 节点间隧道）丢包 15%，同时 tcpdump 在该节点抓包确认大量 TCP 重传。最终定位为 Calico 的 IPIP 模式 MTU 配置不当导致分片，调整后延迟恢复。

4.7 工具链集成工作流

下图展示在 Ingress 延迟诊断中，各工具如何协同形成闭环：

4.8 常见延迟模式与工具对应

根据生产环境经验，将 Ingress 延迟问题归纳为四种典型模式，并给出推荐的工具组合：

延迟模式	现象	首选工具	辅助工具
首包延迟高	TTFB 大但后续请求正常	httpstat	tcpdump（检查 SYN 超时）
间歇性超时	部分请求延迟飙升	mtr	Wireshark（分析重传模式）
TLS 握手慢	time_appconnect 占比高	curl -w	Wireshark（查看证书链长度）
吞吐量低	并发请求时延迟线性增长	tcpdump	Wireshark（统计窗口缩放因子）

效率建议：将常用诊断命令封装为 Shell 函数或 kubectl 插件，例如 kubectl ingress-diag <ingress-name> 自动执行 mtr + curl + httpstat 并输出汇总报告，减少人工切换工具的开销。