Linux ss -o state 怎样查看 TCP 定时器状态

Linux 中查看 TCP 定时器，可以先用 ss -t -n -o state established筛选已建立连接，再读取附加的 timer:(名称,剩余时间,重传计数)。-o负责显示定时器，state负责筛选连接状态；两者不是同一种条件。查看其他阶段时，把 established 换成 syn-sent、fin-wait-1 或 time-wait。

上游手册地址：https://raw.githubusercontent.com/iproute2/iproute2/main/man/man8/ss.8。本地发行版可能使用较早的 iproute2，具体支持的字段以本机 man ss为准。

连接变慢时先缩小需要观察的范围

假设一个服务访问上游时偶发等待，但日志只记录了请求耗时。此时列出所有套接字，很容易把监听端口、已连接会话和等待关闭的条目混在一起。更有用的起点是一个明确问题：是在等待建连，还是已建立连接迟迟没有进展？这里使用假设场景说明判断方法，不把示例当作实际故障记录。

ss 提供了可组合的状态、地址和端口过滤，适合应用开发者定位某个依赖，也适合运维人员观察主机侧连接。它解决的是“当前看到了哪些套接字信息”，不能独自解释整个请求链的耗时，更不能把一次采样变成链路健康证明。

连接状态描述 TCP 会话所处阶段，定时器描述当前显示的计时活动。ESTABLISHED 连接可以存在重传相关计时，也可能在某次采样没有 timer 字段。TIME-WAIT 则是协议关闭过程中的一种状态，看到它本身不代表服务泄漏。把两类信息分开，后面的过滤才有意义。

按状态和端口读取定时器

# 只看 TCP，端口使用数字，并附加定时器信息
ss -t -n -o state established

# 观察主动连接尚未建立的条目
ss -t -n -o state syn-sent

# 观察关闭阶段，状态名使用 ss 支持的连字符写法
ss -t -n -o state fin-wait-1
ss -t -n -o state time-wait

先观察目标阶段，再加业务过滤。比如从本机访问远端 443 端口，用 dport；观察本机提供的 8443 服务，用 sport。这里的源与目标是套接字端点语义，不是抓包中某一个报文的临时方向。

# 本机作为客户端，筛选远端 443 端口的已建立连接
ss -t -n -o state established '( dport = :443 )'

# 本机作为服务端，筛选本地 8443 端口的已建立连接
ss -t -n -o state established '( sport = :8443 )'

# 需要同时覆盖两侧端口时，将整个表达式交给 ss 解析
ss -t -n -o state established '( sport = :8443 or dport = :8443 )'

单引号让括号与布尔表达式作为参数传入 ss，避免 shell 提前解释。命令均为查询操作，不需要为了读取定时器去修改系统 TCP 参数。输出为空时，应先确认当前确实有匹配连接、端口方向和网络命名空间是否正确；不要直接得出“连接全部消失”的结论。

拆开 timer 字段再判断含义

字段的概念格式是 timer:(timer_name,expire_time,retrans)。第一项是类别，第二项表示距离计时到期还有多久，第三项是该显示格式提供的重传计数。它不是请求持续时间，也不是所有丢包或整个应用生命周期的累计统计。

例如遇到 on，可以把“存在发送侧重传或探测相关活动”当作后续调查线索，但不能立即宣布网络丢包。看到 persist，则可以进一步调查对端接收窗口及其应用消费情况；这仍是排查方向，不是根据一个字段完成根因定性。

显示的剩余时间会变化，也可能因计时器重新安排而变大。不同类别的第三项不应被合并成一个统一的全站重传指标。写采集脚本时，应保存完整端点、状态、类别和采样时刻，避免只提取最后一个数字。

结合连续观察决定下一步

# 对同一过滤范围补充 TCP 内部信息，字段随版本和连接情况变化
ss -t -n -o -i state established '( dport = :443 )'

# 记录工具版本，方便对照发行版提供的手册
ss -V

# 查看当前系统所带的参数与字段说明
man ss

-i可以补充 rto、rtt、cwnd 等信息；它们和 -o的 timer 不是同一个字段。关联分析时，先确认是在比较同一对端点的连接，再观察计数、队列与业务耗时是否一起变化。同一个远端服务可能有多条连接，不能把不同连接的两次输出当成一条连接的演变。

采用这套方式的收益是先缩小范围，减少盲目调整超时和连接池的动作。代价是短命连接容易在两次采样之间消失，采样本身也不是原子化的全局历史。对于高频问题，应使用有明确采样窗口的观测方案，结合应用日志与网络侧证据；本文没有运行这些命令或制造连接，未提供实际观测结论。

没有 timer 字段是不是没有异常？不是。只能说明这次输出没有呈现相应计时信息，仍需结合连接阶段、版本及其他指标。

为什么加了 -p 仍看不到进程？进程可见性、权限和套接字生命周期会影响显示。读取定时器不依赖进程名，不要把进程信息缺失误判为 timer 失效。

可以按 timer 名称直接写 state keepalive 吗？不可以。state 后面是 TCP 状态过滤，keepalive 是定时器类别。应先选连接范围，再解读其 timer 字段。

把状态过滤、端口方向和字段含义对应起来后，ss -o 更适合作为“下一步应该调查哪里”的入口。是否需要调整配置，应由连续观测和业务约束决定。