Linux怎么查看封包在协议栈中的流向-LINUX-PHP中文网

封包在linux内核中流向由协议栈硬逻辑决定：接收路径为网卡驱动→netif_receive_skb()→ip_rcv()→tcp_v4_rcv()/udp_rcv()→sock_queue_rcv()→应用层read()；发送路径反之。验证需依赖tracepoint（如bpftrace打点net:netif_receive_skb）、/proc/net/snmp与/proc/net/netstat计数器比对，而非ifconfig/ss等状态快照工具。

linux怎么查看封包在协议栈中的流向

怎么看封包在内核里走了哪几层

封包在 Linux 内核里的流向不是靠“看日志”猜出来的，而是由网络协议栈的固定路径决定的。接收方向是：网卡驱动 → netif_receive_skb() → ip_rcv() → tcp_v4_rcv()/udp_rcv() → sock_queue_rcv() → 应用层 read()；发送方向反过来，从 write() 进入套接字层，经 tcp_transmit_skb() 或 udp_send_skb()，最终到 dev_queue_xmit() 交给驱动发出去。

这个路径不依赖用户配置，是内核编译时确定的硬逻辑。想验证某条路径是否走通，不能只看 /proc/net/，得结合函数入口点或 tracepoint —— 比如用 bpftrace 打点 net:netif_receive_skb 和 sock:inet_sock_set_state，就能确认封包是否进了 IP 层、有没有被 TCP 模块接手。

为什么 ifconfig / ss / netstat 看不到流向细节

ifconfig 只读 /sys/class/net/ 下设备统计，ss 和 netstat 查的是 /proc/net/{tcp,udp}，它们反映的是连接状态快照，不是封包实时路径。比如一个 SYN 包卡在防火墙规则里没进 IP 层，ss -tln 根本不会显示它，但 iptables -L -v 的计数器会涨。

封包被 iptables 的 INPUT 链 DROP，它根本不会走到 ip_rcv()
封包进了 ip_rcv() 但校验和失败，会被静默丢弃，不进后续流程
UDP 包目的端口无监听进程，会触发 ICMP port unreachable，但不会出现在 /proc/net/udp 的任何一行里

用 cat /proc/net/nf_conntrack 能看出流向吗

能，但只限于经过 conntrack 的连接（即启用了 NAT 或 stateful 防火墙的场景）。/proc/net/nf_conntrack 记录的是连接跟踪表项，每行含 src=、dst=、proto=6（TCP）、state=ESTABLISHED、timeout= 等字段，说明该连接已通过 nf_conntrack_invert_tuple() 建立跟踪，并被 nf_conntrack_find_get() 复用过。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

但它不告诉你封包是否经过 br_netfilter（桥接转发）、是否触发了 xt_owner 模块、有没有被 tc ingress 的 clsact 过滤 —— 这些都发生在 conntrack 之前或之后，需用 tc filter show dev eth0 ingress 或 cat /proc/sys/net/bridge/bridge-nf-call-iptables 辅助判断。

最轻量的流向验证方式：查 /proc/net/snmp 和 /proc/net/netstat

/proc/net/snmp 按协议分组统计收发错误，比如 TcpInSegs 是进入 TCP 层的段数，TcpOutSegs 是发出的段数，TcpRetransSegs 是重传段数；而 /proc/net/netstat 更细，含 TcpExtDirectCopyFromBacklog（直接从 backlog 拷贝）、TcpExtListenOverflows（全连接队列溢出）等。

对比这两组数字，能快速定位瓶颈在哪一层：