必须用ss -ti查看真实业务流量RTT，因其直接读取内核TCP控制块中动态更新的rtt值（如rtt:0.858/0.46），而ss -i不输出RTT字段，仅显示重传、窗口等内部指标。
不能用 ss -i 提取 RTT —— 这是常见误解。RTT 只能通过 ss -ti 读取，-i 选项不输出 RTT 字段。内核中 TCP 连接的实时 RTT（含平滑值 srtt 和方差 rttvar）仅在 TCP 控制块中由 ACK 更新，并只对 ss -t 系列命令开放；-i 主要用于查看重传次数、拥塞状态、窗口参数等内部指标，但不含 RTT。
为什么 ss -i 看不到 RTT
ss -i 输出的是 TCP socket 的内部统计和控制信息，比如：
• retransmits（超时重传次数）
• rto（当前重传超时时间）
• snd_cwnd（发送拥塞窗口）
• snd_ssthresh（慢启动阈值）
• rcv_wnd（接收窗口大小）
• rmem_alloc / wmem_alloc（内存占用）
但没有 rtt: 字段。RTT 是动态估算值，只在 ss -t（TCP 专用）加 -i 或 -o 时才可能附带，而真正稳定输出 RTT 的唯一组合是 ss -ti。
用 ss -ti 正确提取实时 RTT 和窗口信息
运行 ss -ti 才能同时拿到 RTT 和关键窗口参数：
- RTT 显示为
rtt:0.858/0.46：前者是平滑 RTT（毫秒级，如 0.858ms），后者是 RTT 方差（反映抖动） - 发送窗口相关字段：
snd_cwnd（拥塞窗口）、snd_wnd（通告窗口）、wscale（窗口缩放因子） - 接收窗口字段：
rcv_wnd（当前接收窗口大小）、rcv_ssthresh（接收端慢启动阈值） - 连接状态字段如
timer（RTO 倒计时）、retrans（当前重传队列长度）可辅助判断链路是否持续丢包或拥塞
示例命令：
- 查所有已建立连接的 RTT 与窗口：
ss -ti state established - 查连向某数据库的连接：
ss -ti 'dst 10.0.3.15:3306' - 过滤出高 RTT 或小窗口连接：
ss -ti state established | awk '$2 ~ /rtt:/ && $3 > 50 {print}'（单位为毫秒）
结合 ss -ti 评估链路质量的关键逻辑
单看 RTT 数值意义有限，需交叉观察窗口与重传行为：
- RTT 持续升高 + snd_cwnd 缩小 → 可能遭遇显式拥塞（ECN）或丢包，触发快速恢复
- RTT 正常但 rcv_wnd 长期为 0 → 接收端应用读取慢，形成“零窗口”，发送端停发
- RTT 波动大（rttvar > srtt × 0.3）且 retransmits > 0 → 链路存在间歇性丢包或排队延迟不稳定
- snd_cwnd 远小于 snd_wnd → 拥塞控制主动限速，不是带宽瓶颈而是网络质量下降
补充：窗口大小怎么看是否合理
TCP 理想窗口 ≈ 带宽 × RTT（即 BDP，带宽时延积）。例如：
- 千兆链路（125MB/s）、RTT=10ms → 理想 BDP ≈ 1.25MB
- 若
snd_cwnd长期卡在 64KB，远低于 BDP → 可能受限于net.ipv4.tcp_rmem设置或未启用窗口缩放 - 检查是否开启：
sysctl net.ipv4.tcp_window_scaling应为 1；若为 0，则最大窗口被限制在 65535 字节
窗口过小会严重限制吞吐，即使 RTT 很低，也无法跑满带宽。
