应优先用hping3测tcp握手延迟以避开icmp被过滤干扰，再结合ss -i查看实时拥塞状态（如rto>1000ms、cwnd异常），而非仅依赖ping平均值或netstat -s累计统计。
网络延迟高，不能只看 ping 输出的平均值——90% 的误判源于混淆了网络层 RTT 和应用层耗时。
用 hping3 测 TCP 握手延迟，避开 ICMP 被过滤的坑
很多生产环境禁用 ICMP，ping 返回超时或高延迟，不代表真实网络不通。此时必须换 TCP 层探测：
-
hping3 -c 3 -S -p 443 target_ip：发 3 个 SYN 包，看rtt=值，这是服务端响应 SYN-ACK 的单向延迟，乘以 2 可粗估 RTT -
hping3 -c 3 -2 -p 53 8.8.8.8：对 DNS 用 UDP 模式，验证是否是协议被策略拦截 - 若
rtt波动极大（比如 5ms → 200ms），说明中间设备（如防火墙、负载均衡）在限速或做连接检查
用 ss -i 查单连接实时拥塞状态，别只盯 netstat -s
netstat -s 看的是累计统计，对瞬时高延迟定位帮助有限；ss -i 才能反映当前活跃连接的真实行为：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
ss -tin state established | grep :80：筛选 HTTP 连接，关注rtt、rto、cwnd字段 - 若
rto持续 >1000ms 且cwnd -
retrans计数非零 +rttvar突增，说明 ACK 返回不稳定，可能是延迟 ACK 合并或中间设备干扰
两端同时 tcpdump 抓包比对时间戳，锁定延迟发生环节
只在客户端抓包会误导判断——延迟可能出在服务端响应慢、中间设备策略、甚至本机协议栈处理上：
- 客户端：
tcpdump -i any -w client.pcap port 80 -nn - 服务端：
tcpdump -i any -w server.pcap port 80 -nn - Wireshark 中打开两个文件，同步查看 SYN→SYN-ACK 时间差：若 client.pcap 里 SYN 发出后 50ms 才收到 SYN-ACK，但 server.pcap 显示 SYN 在 5ms 内就到达并立即回了 SYN-ACK，则问题在返回路径（如路由不对称、ACL 限速）
- 重点过滤
tcp.analysis.retransmission和tcp.analysis.ack_rtt，这两个字段直接对应重传和 ACK 延迟
检查网卡中断分布和卸载特性，虚拟化环境下尤其关键
在 KVM、Docker 或云主机中，高延迟常来自软中断堆积或驱动卸载异常，而非网络本身：
-
cat /proc/interrupts | grep eth0：若所有中断都集中在 CPU 0，而其他核空闲，说明irqbalance未生效或被禁用 -
ethtool -k eth0查看tso、gso、gro是否开启；某些旧版 virtio 驱动在开启 TSO 时会引入 10–50μs 不等的抖动 - 临时关闭测试：
ethtool -K eth0 tso off gso off gro off，观察延迟是否收敛——若明显改善，需升级内核或调整驱动参数
真正难排查的延迟，往往卡在“看起来正常”的环节：时间不同步导致 TCP 时间戳误判、ring buffer 溢出丢包却不报错、虚拟化下 vCPU 调度延迟被算进网络耗时。这些不会出现在 ping 或 mtr 里，只能靠两端抓包+内核态指标交叉验证。
