HTTP 接口偶然响应慢问题排查

背景

生产环境中，某业务模块偶发性地出现 HTTP 接口响应缓慢的情况，平均耗时从正常的几百毫秒飙升至数十秒，严重影响用户体验。问题复现没有明显规律，忽快忽慢，让人捉摸不透。于是决定借助网络抓包和延迟分析工具，一层一层剥开网络的"洋葱"，找到真正的元凶。

一、准备工具

排查网络问题，工欲善其事，必先利其器。首先在容器内安装必要的网络诊断工具：

apt-get update && apt-get install -y tcpdump hping3 mtr traceroute iputils-ping --no-install-recommends

这几个工具各司其职：

tcpdump：抓取网络数据包，是网络排查的"照相机"
hping3：可以模拟 TCP 握手，精准测量网络延迟
mtr：结合了 traceroute 和 ping 的功能，实时展示路由路径和丢包情况
traceroute / ping：经典的网络连通性诊断工具

二、抓包：让数据包无处遁形

工具就绪后，开始对可疑的目标地址进行抓包，分别针对外部 API 和内部自建服务进行采集。

抓取访问外部 API 的数据包：

tcpdump -i eth0 host api.dify.ai -w capture.pcap

抓取访问内部自建服务的数据包：

tcpdump -i eth0 host sg-dify.yuhaowin.com -w capture.pcap

抓取本地回环接口的流量（排查内部服务调用）：

tcpdump -i lo port 6310 -w http.pcap

抓包完成后，将 .pcap 文件从 Pod 内复制到本地，用 Wireshark 进行可视化分析：

kubectl cp crm-qa-12579-7ff6459456-rzzz6:/app/bin/capture.pcap ~/Desktop/crm-qa.pcap

kubectl cp crm-qa-base-5799dbd479-kjxcv:/app/bin/capture.pcap ~/Desktop/crm-qa-1.pcap

打开 Wireshark，TCP 流的时序图一目了然——某些连接在握手阶段或数据传输阶段存在明显的停顿，嫌疑逐渐浮出水面。

三、用 hping3 测量 TCP 握手延迟

Wireshark 让我们看到了"症状"，但还需要更精准的手段来量化延迟。hping3 可以连续发送 100 个 SYN 包，统计 RTT（往返时延）：

hping3 -S -p 443 -c 100 api.dify.ai

通过统计结果，能清晰地看出网络 RTT 的分布情况——如果大部分包延迟正常，只有偶尔几个包出现异常高延迟，则更可能是服务端或中间网络节点的问题，而非稳定的网络链路问题。

四、用 curl 拆解每个阶段的耗时

网络请求从发出到收到响应，经历了 DNS 解析、TCP 连接、TLS 握手、等待服务端响应、数据传输等多个阶段。curl 的 -w 参数可以把每个阶段的耗时都打印出来，帮助精准定位瓶颈。

测试外部 API（HTTPS）：

curl -o /dev/null -s \
  -w "time_namelookup:\t%{time_namelookup}\ntime_connect:\t\t%{time_connect}\ntime_appconnect:\t%{time_appconnect}\ntime_pretransfer:\t%{time_pretransfer}\ntime_starttransfer:\t%{time_starttransfer}\ntime_total:\t\t%{time_total}\ntime_redirect:\t\t%{time_redirect}\n" \
  --location 'https://api.dify.ai/v1/chat-messages' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer fake-token' \
  --data '{
    "query": "校园食堂开通分账业务审批填写规范",
    "response_mode": "streaming",
    "user": "yuhao",
    "inputs": {}
  }'

测试内部自建服务（HTTP）：

curl -o /dev/null -s \
  -w "time_namelookup:\t%{time_namelookup}\ntime_connect:\t\t%{time_connect}\ntime_appconnect:\t%{time_appconnect}\ntime_pretransfer:\t%{time_pretransfer}\ntime_starttransfer:\t%{time_starttransfer}\ntime_total:\t\t%{time_total}\ntime_redirect:\t\t%{time_redirect}\n" \
  --location 'http://sg-dify.yuhaowin.com/v1/chat-messages' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer fake-token' \
  --data '{
    "query": "校园食堂开通分账业务审批填写规范",
    "response_mode": "streaming",
    "user": "yuhao",
    "inputs": {}
  }'

测试 GET 接口（数据集列表）：

curl -o /dev/null -s \
  -w "time_namelookup:\t%{time_namelookup}\ntime_connect:\t\t%{time_connect}\ntime_appconnect:\t%{time_appconnect}\ntime_pretransfer:\t%{time_pretransfer}\ntime_starttransfer:\t%{time_starttransfer}\ntime_total:\t\t%{time_total}\ntime_redirect:\t\t%{time_redirect}\n" \
  --location --request GET 'https://api.dify.ai/v1/datasets?page=1&limit=20' \
  --header 'Authorization: Bearer fake-token'

更直观的格式化输出版本：

curl -w "总时间: %{time_total}s\n名称解析时间: %{time_namelookup}s\n连接时间: %{time_connect}s\nTLS握手时间: %{time_appconnect}s\n等待时间: %{time_starttransfer}s\n数据传输时间: %{time_total}s\nHTTP状态码: %{http_code}\n" \
  -o /dev/null \
  --location 'https://api.dify.ai/v1/chat-messages' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer fake-token' \
  --data '{
    "query": "校园食堂开通分账业务审批填写规范",
    "response_mode": "streaming",
    "user": "yuhao",
    "inputs": {}
  }'

多次执行后，对比各阶段的耗时数据，time_starttransfer（首字节时间，即 TTFB）异常偏高，说明瓶颈在服务端处理阶段，而非网络链路本身。

五、参考资料

Docker 容器内使用 traceroute 和 tcpdump

总结

通过这次排查，形成了一套清晰的网络问题定位思路：

tcpdump 抓包 → 观察 TCP 连接的完整时序，定位是哪个阶段出现异常
hping3 测试 → 量化 TCP 握手延迟，判断网络链路质量
curl 分阶段计时 → 精准拆解每个请求阶段的耗时，找到真正的瓶颈

这次问题最终定位到服务端的响应处理延迟（TTFB 过高），而非网络链路问题。排查过程中，借助这套组合拳，把一个"偶然慢"的玄学问题变成了可量化、可复现、有数据支撑的工程问题，问题的边界也随之清晰起来。