ss -ti 是唯一能读取内核TCP连接实时RTT估算值的命令，输出如 rtt:0.858/0.46，反映真实业务流量延迟；而ping测ICMP路径，不受TCP拥塞控制等影响，二者不可等同。
Linux 查看当前网络连接的 RTT，不能靠 ping，得用 ss —— 因为只有 ss -ti 能读取内核 TCP 连接态里的实时 RTT 估算值，而 ping 测的是 ICMP 路径，和你正在跑的 HTTP/MySQL/SSH 连接不是一回事。
为什么 ping 的 RTT ≠ 当前 TCP 连接的 RTT
ping 发的是 ICMP 包，走的是独立路径，不经过 TCP 栈，也不受拥塞控制、重传、SACK、TSO/GSO 等影响；而真实业务流量是 TCP 流，RTT 由内核在每个 ACK 中动态更新，ss -ti 直接读的就是这个值。常见误区是看到 ping 延迟 5ms 就以为服务快，结果 curl 却卡 800ms —— 很可能就是那条 TCP 连接实际 RTT 已飙升到 400ms+，但 ping 完全反映不出来。
- ICMP 可能被中间设备限速或丢弃，TCP 流量却正常（尤其云厂商防火墙）
- 同一台机器上多个 TCP 连接的 RTT 可能差异极大（比如一个连 CDN，一个连数据库）
- ping 的 TTL 和 TCP 的 MSS、窗口缩放、时间戳选项无关，无法模拟真实传输行为
用 ss -ti 精确抓取指定 TCP 连接的 RTT
ss -ti 是唯一能在运行时读取内核 TCP 控制块中 rtt 字段的命令，输出形如 rtt:0.858/0.46，其中前者是平滑 RTT（srtt），后者是 RTT 方差（rttvar）。
- 查本机所有 ESTAB 连接的 RTT：
ss -ti state established - 查特定目标 IP 和端口的 RTT：
ss -ti 'dst 192.168.0.224:20007' - 查本地某端口发起的连接：
ss -ti 'src :8080' - 配合
watch动态观察：watch -n1 'ss -ti state established | grep -v "rtt:" | head -5'
注意：ss -ti 输出中的 cubic 或 reno 表示拥塞控制算法，它会影响 RTT 估算方式；若没看到 rtt: 字段，说明该连接尚未收到足够 ACK（比如刚建连），需稍等或触发一次数据交互。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
traceroute + ss 组合定位 RTT 异常节点
单看 ss 知道“这条连接 RTT 高”，但不知道“高在哪一段”。这时候要结合 traceroute 找出延迟跳点，再用 ss -ti 确认是否仅该路径上的 TCP 连接受影响。
- 先跑
traceroute -T -p 443 example.com（强制 TCP traceroute，绕过 ICMP 屏蔽） - 发现第 5 跳延迟突增（比如从 12ms → 210ms），记下该跳 IP
- 立刻执行
ss -ti 'dst '，看是否也出现高 RTT —— 如果是，说明问题就在那个中间设备（如运营商 QoS 设备） - 对比
ping -c3：若 ping 延迟正常但 TCP RTT 高，大概率是该设备对 TCP 流量做了深度检测或限速
别依赖 mtr 的“平均延迟”——它默认用 ICMP，且统计窗口太宽，容易掩盖瞬时抖动；而 ss -ti 每次调用都是即时快照，更敏感。
ss -ti 的局限与替代方案
ss -ti 只能看已建立的 TCP 连接，且依赖内核版本（Linux ≥ 4.1 支持完整字段）。它不适用于 UDP、监听中（LISTEN）或已关闭（CLOSE_WAIT）状态的连接。
- UDP 应用（如 DNS、VoIP）无 RTT 概念，只能用
tcpdump抓包算应用层往返（如 DNS query → reply 时间差） - 想测新建连接首包 RTT？用
tcpdump -i any port -w trace.pcap，然后用 Wireshark 的TCP Analysis Graphs → Round Trip Time Graph - 需要长期监控？写个脚本每秒跑一次
ss -ti state established并提取rtt:后数值，避免用netstat（它不暴露 RTT）
最易被忽略的一点：ss -ti 显示的 RTT 是内核估算值，不是物理链路延迟；它包含排队、处理、重传等待等全部开销。所以当你看到 rtt:120.5/22.3，真正要盯的是那个 120.5 是否持续 >100ms，而不是纠结小数点后几位准不准。
