TCP延迟需从连接状态、实时指标、双向抓包、内核参数四方面排查：ss查CLOSE_WAIT/SYN_RECV异常，ss -i看rto/cwnd/retrans定位拥塞或ACK不稳定，客户端与服务端同步抓包比对SYN→SYN-ACK时间差，再检查中断分布、卸载特性及tcp_timestamps等内核参数。
TCP 数据延迟过大，不是单看 ping 就能定位的问题。真正卡顿往往藏在三次握手、ACK 返回、拥塞控制或本地协议栈处理环节里。得从连接状态、实时指标、抓包比对、内核参数四方面入手，一层层往下挖。
先看连接状态是否异常
大量 CLOSE_WAIT 说明应用没主动关连接，socket 滞留；SYN_RECV 过多可能被 SYN Flood 攻击或服务端 accept 队列满；TIME_WAIT 太多但一般不直接导致延迟，除非复用不足影响新建连接。
- 运行 ss -tan | awk '{print $1}' | sort | uniq -c | sort -nr 查各状态数量
- CLOSE_WAIT 突增？检查应用代码是否漏调 close() 或异常退出后未清理 socket
- SYN_RECV 超过 net.ipv4.tcp_max_syn_backlog 值？说明半连接队列溢出，需调大该值并确认 net.core.somaxconn 与之匹配
用 ss -i 看真实连接行为
netstat -s 是累计统计，看不出当前连接的卡点。ss -i 能显示每个 ESTABLISHED 连接的 rtt、rto、cwnd 和 retrans，这才是判断延迟来源的关键。
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 :端口，重点关注 rto 是否持续 >1000ms、cwnd 是否反复归零、retrans 字段是否非零
- rto 拉长 + rttvar 突增 → ACK 返回不稳定，可能是中间设备限速、延迟 ACK 合并或路由不对称
- cwnd 骤降 + retrans 计数上升 → 触发了拥塞控制，需查是否丢包或网络抖动
两端同步抓包比时间戳
只在客户端抓包容易误判。比如 SYN 发出后 80ms 才收到 SYN-ACK，你以为是服务端慢，其实可能是返回路径延迟高。
- 客户端：tcpdump -i any -w client.pcap port 端口 -nn
- 服务端：tcpdump -i any -w server.pcap port 端口 -nn
- 用 Wireshark 打开两个文件，对齐 SYN 时间戳，看 SYN→SYN-ACK 的差值在哪边更大
- 重点过滤 tcp.analysis.retransmission（重传）和 tcp.analysis.ack_rtt（ACK 延迟），这两个字段直接对应瓶颈
检查内核与网卡底层配置
很多“网络延迟”其实是本机处理不过来：中断扎堆、卸载特性引入抖动、时间不同步让 TCP 时间戳失效。
- 查中断分布：cat /proc/interrupts | grep eth0，若全集中在 CPU0，启用 irqbalance 或手动绑定
- 关掉 TSO/GSO 测试：ethtool -K eth0 tso off gso off gro off，若延迟明显下降，说明驱动或卸载逻辑有问题
- 确认时间同步：chronyc tracking，时间跳变会导致 PAWS 判定失败，引发虚假超时
- 关键参数建议：net.ipv4.tcp_slow_start_after_idle=0（防空闲后慢启动）、net.ipv4.tcp_timestamps=1 & tcp_tw_reuse=1（支持快速复用）、net.ipv4.tcp_congestion_control=cubic（避免激进算法）
