ss 命令无法直接显示抖动，仅提供当前平滑 RTT 和 RTTVAR（单位微秒），二者用于 RTO 计算而非抖动评估；抖动需多次采样后自行计算标准差，或改用 tcpping、tcpdump+tshark 等工具。
ss 命令本身不直接显示 RTT 和抖动
ss 是 Linux 网络诊断的轻量级工具，底层依赖 tcp_info 结构体，但内核仅通过 ss 暴露部分字段——rtt（当前平滑 RTT）、rttvar（RTT 方差）可查，而“抖动”（Jitter）需自行推导，且**没有往返延迟历史序列，无法计算真实抖动**。你看到的 ss -i 输出里的 rtt:123/45，其实是 rtt:123000/45000（单位是微秒），前者是 smoothed RTT，后者是 RTTVAR（不是标准差，是用于 RTO 计算的中间值）。
常见误操作是以为 ss -i 能像 mtr 或 ping 那样持续测抖动——它不能。它只是一次性快照。
用 ss -i 查看连接的当前 RTT 与 RTTVAR
执行以下命令可查看 ESTABLISHED 连接的实时 RTT 相关字段：
ss -ti 'dst 192.168.1.100:443'
关键输出字段示例：
ts sack cubic wscale:7,7 rto:204 rtt:123000/45000 ato:40 mss:1448 pmtu:1500
-
rtt:123000/45000→ 平滑 RTT = 123 ms，RTTVAR = 45 ms（注意：这不是抖动，是 TCP 内部用于 RTO 计算的方差估计） -
rto:204→ 重传超时时间（毫秒），由 RTT + 4×RTTVAR 推导而来（204 ≈ 123 + 4×45 = 203，吻合） - 仅对 TCP 连接有效；UDP、监听套接字、TIME-WAIT 状态等不显示这些字段
- 必须有 root 权限或
cap_net_admin才能读取所有连接的详细信息（普通用户可能看不到rtt字段）
想估算抖动？得靠多次采样 + 自行计算
因为 ss -i 不提供历史 RTT 序列，若真要观察抖动趋势，只能定时抓取并解析：
while true; do ss -ti 'dst 192.168.1.100:443' 2>/dev/null | grep -o 'rtt:[0-9]*/[0-9]*' | cut -d: -f2 | cut -d/ -f1; sleep 1; done
这会每秒输出一次当前 smoothed RTT（单位微秒）。后续可用 awk 或 Python 统计标准差：
awk '{if(NR>1){diff=$1-prev; print diff}; prev=$1}' | awk '{sum+=$1; sumsq+=$1*$1} END{print "avg:",sum/NR,"jitter_std:",sqrt(sumsq/NR - (sum/NR)^2)}'
- 注意：TCP 的 smoothed RTT 是低通滤波结果，变化慢，不适合反映瞬时抖动；真实网络抖动应基于应用层发包/收包时间戳
- 如果连接刚建立，
rtt可能为 0 或极小值（尚未完成三次握手后的初始 RTT 测量） - 某些内核版本（如 4.15+）在
ss -i中新增了rttvar显示，但依然不等于抖动
更靠谱的替代方案：用 tcpping 或 tcpdump + tshark
如果目标是诊断真实链路延迟波动，ss 不是合适工具：
-
tcpping -x 10 example.com 443→ 类似 ping，但走 TCP SYN，输出每次往返时间，可直接算 min/avg/max/mdev（即抖动） -
tcpdump -i any host 192.168.1.100 and port 443 -w trace.pcap+tshark -r trace.pcap -T fields -e frame.time_epoch -e tcp.seq -e tcp.ack→ 获取精确时间戳，自行对齐请求/响应计算单向延迟和抖动 - 应用层埋点（如 HTTP
Server-Timing、gRPCgrpc-timeout）比内核层 RTT 更贴近业务感知
真正容易被忽略的是：TCP 的 rtt 是发送端单向估算值，不包含接收端处理延迟、队列排队、ACK 延迟等因素；所谓“抖动”若指端到端体验波动，必须跳出 ss 的范畴，回到真实流量观测。
