tcpdump 默认在 netif_receive_skb() 后、协议栈分发前捕获，属于链路层入口后、ip层解析前的位置，可看到 vlan tag 和 mac 头，但看不到 softirq 调度前的 skb 入队细节；实操需加 -e 显示 mac 层、禁用 gro/tso，并注意 bpf 优化影响。
怎么用 tcpdump 抓到进入协议栈前的原始包
想看数据包在内核里“走哪条路”，第一步不是翻源码，而是确认你抓的包是否足够早——tcpdump 默认用 libpcap，底层调用的是 AF_PACKET socket，它在 netif_receive_skb() 之后、协议栈分发前捕获，属于“链路层入口后、IP层解析前”的位置。这意味着你能看到 VLAN tag、MAC 地址、未解封装的 GRE/ERSPAN 头，但看不到 softirq 调度前的 skb 入队细节。
实操要点：
- 加
-e显示 MAC 层头：tcpdump -i eth0 -e -n - 避免内核过滤干扰：加
-B（禁用 BPF 编译优化）或直接用sudo tcpdump -i eth0 -w dump.pcap后用 Wireshark 分析，防止 BPF 过滤器提前丢弃某些字段 - 注意网卡 offload：如果启用了
GRO或LSO，tcpdump可能抓到的是合并后的大包（GRO）或未分片的 TCP 段（TSO），需临时关掉：ethtool -K eth0 gro off tso off
怎么用 perf 跟踪内核函数调用路径
要真正看到 skb 在内核里被哪些函数处理，得进内核态。最轻量的方式是用 perf trace 系统调用和 kprobe，比如跟踪一个 SYN 包从网卡中断到 tcp_v4_do_rcv() 的全过程：
先查函数符号是否导出：grep tcp_v4_do_rcv /proc/kallsyms（没输出说明被 kptr_restrict 挡住了，需设 sudo sysctl kernel.kptr_restrict=0）
然后运行：
sudo perf record -e 'kprobe:tcp_v4_do_rcv' -e 'kprobe:ip_rcv' -e 'kprobe:__netif_receive_skb_core' -g -a
触发连接后 Ctrl+C，再用 perf report --call-graph 看调用栈。注意：__netif_receive_skb_core 是软中断入口，ip_rcv 是 IP 层起点，tcp_v4_do_rcv 是 TCP 状态机入口——这三者串起来就是典型 IPv4 TCP 包的内核流向主干。
cat /proc/net/snmp 和 /proc/net/netstat 能看出什么流向线索
这两个文件不展示单个包路径，但能暴露协议栈各层的丢包/错误计数，间接反映流向瓶颈。比如：
-
InCsumErrors高 → IP 层校验失败，可能在ip_rcv()就被丢弃 -
TCPSynRetrans高但TCPInCwndReduced低 → 问题大概率在路由或防火墙（SYN 出去了没回来），而非内核 TCP 处理逻辑 -
UdpInCsumErrors和UdpIgnoredMulti同时上升 → 可能是网卡多播地址配置错，导致 UDP 包在udp_rcv()前就被ip_check_mc()过滤
它们的价值在于帮你排除“是不是走到某一层就没了”，而不是告诉你“走到了哪一行代码”。别指望靠这个定位 skb->dev 或 skb->sk 的变化点。
为什么 iptables TRACE 不适合看真实流向
iptables -t raw -A PREROUTING -j TRACE 看起来很直观，但它只在 netfilter 框架注册的 hook 点打日志，而 netfilter 是嵌在协议栈里的“插件”，不是流向本身。比如：
- 包根本没进
PREROUTING（如被 XDP 程序 drop）→ TRACE 完全无输出 - 启用
CONFIG_BRIDGE_NETFILTER=y时，桥接流量会额外经过nf_bridge_pre_routing()，TRACE 日志顺序可能错乱 - TRACE 日志写入
dmesg，高吞吐下容易丢失，且无法关联 skb 地址或时间戳
真要定位 netfilter 行为，不如直接用 perf probe 打点：sudo perf probe 'nf_hook_slow:%return'，再结合 skbaddr 参数看具体哪个 hook 返回了非零值。
内核网络流向不是线性流水线，而是由软中断、工作队列、RPS/RFS、XDP、tc、netfilter 多重交织的路径。抓包、perf、proc 统计三者必须交叉验证——单独依赖任何一种，都容易把“没看到”当成“没发生”。
