ss命令只能查看套接字当前瞬时状态（如established、syn_recv），无法直接追踪状态变迁过程；其数据源自内核sk->sk_state字段，不保存历史记录或时间戳，真正观测变迁需依赖tcpdump抓包、/proc/net/tcp轮询比对或ebpf跟踪。
Linux 无法直接“查看套接字的状态变迁”过程（比如从 SYN_RECV 到 ESTABLISHED 的实时跳变），因为内核不记录单个套接字的历史状态轨迹；但你可以通过组合工具，捕获关键状态快照、比对变化，或借助内核接口间接推断变迁行为。
ss 命令只能看当前状态，不是状态机日志
ss 输出的是某一时刻的瞬时状态，例如 TCP_LISTEN、TCP_ESTABLISHED、TCP_TIME_WAIT，这些值来自内核 sk->sk_state 字段。它不保存历史，也不提供时间戳标记。所以：
- 运行
ss -tn state established只能看到此刻哪些连接处于已建立状态 - 连续执行
ss -tn state syn-recv并不能还原某次握手全过程，只能碰巧捕获到极短命的TCP_SYN_RECV状态 -
ss -i可显示重传、RTT、拥塞窗口等连接级指标，但仍是当前值，非变迁记录
/proc/net/{tcp,tcp6,udp,udp6} 是底层原始状态源
这些文件是 ss 和 netstat 的数据来源，每行对应一个套接字，第4列是十六进制状态码（如 0A = TCP_LISTEN，01 = TCP_ESTABLISHED）。你可以用脚本轮询并 diff 差异来模拟“变迁观察”：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 用
awk '{print $1,$4}' /proc/net/tcp提取 inode + 状态码 - 配合
inotifywait -m /proc/net/tcp不现实（该路径不可 inotify）；实际需定时采样 +diff - 注意：/proc/net/tcp 每次读取都触发内核遍历，高频轮询会增加开销
真正能反映变迁的只有连接建立/关闭事件流
若你关心的是“某个端口上的连接如何从监听→接收SYN→完成三次握手→传输→关闭”，唯一可靠方式是抓包 + 进程上下文关联：
- 用
tcpdump -i any port <code>8080-nn -S 抓原始 TCP 标志位（SYN/ACK/FIN），这是最接近状态变迁的证据 - 结合
ss -tunp | grep <code>8080确认监听进程 PID，再用lsof -i :<code>8080辅助验证 - 注意：
TCP_SYN_RECV在高并发下极难被ss捕获，因内核处理极快；而TCP_TIME_WAIT因默认持续 60 秒，更容易观测到
listen() 调用后的监听队列状态可间接验证
调用 listen() 后，套接字进入 TCP_LISTEN，内核维护两个队列：syn queue（未完成握手）和 accept queue（已完成三次握手、等待 accept()）。可通过以下方式确认其存在与积压：
-
ss -lnt输出中Recv-Q列：对监听套接字，显示当前accept queue中已建立但未被accept()的连接数 -
ss -lnt输出中Send-Q列：显示syn queue当前长度（即半连接数） - 当
Recv-Q持续 > 0 且应用不及时accept()，说明连接已成功建立但被阻塞在队列里——这就是监听态向已连接态变迁的“滞留证据”
真正容易被忽略的是：状态变迁本身发生在内核协议栈深处，用户空间工具只能采样、推断、或旁路抓包；没有命令能输出「这个 socket 在 13:45:22.112 进入 ESTABLISHED，在 13:45:27.893 进入 CLOSE_WAIT」这样的日志——那需要 eBPF 或内核模块级别的跟踪支持。
