数据包从网卡到用户进程的关键路径是：网卡驱动 → NAPI poll → __netif_receive_skb_core → ip_rcv → tcp_v4_rcv/udp_rcv → socket 接收队列；该路径决定抓包失败时的排查层级。
数据包从网卡到用户进程的路径在哪
Linux 内核协议 栈不是黑盒，关键路径是：网卡驱动 → NAPI poll → __netif_receive_skb_core → ip_rcv → tcp_v4_rcv/udp_rcv → socket 接收队列。这个链路决定了你抓不到包时该查哪一层。
常见现象：tcpdump 能抓到包但应用 recv() 阻塞——大概率卡在 socket 接收队列 溢出或 sk_filter 丢包；若 tcpdump 也看不到，问题在 网卡驱动 或硬件中断没触发。
-
ethtool -S eth0查看rx_dropped、rx_missed_errors，确认是否网卡已丢包 -
cat /proc/net/snmp | grep -A1 Tcp看EstabResets或OutSegs异常飙升，反映内核已处理但连接异常 - 接收队列长度由
net.core.rmem_default和 socket 的SO_RCVBUF共同限制，ss -i可见rcv_space和实际rcv_ssthresh
send() 系统调用到底把数据交给了谁
send() 返回成功 ≠ 数据已发到对端，它只表示数据进入内核 sk_write_queue 或直接走 tcp_push_pending_frames() 进入发送队列。真正控制发包节奏的是 TCP 的拥塞窗口（cwnd）、接收窗口（rwnd）和 sk->sk_wmem_queued 剩余空间。
典型误判：应用层 send() 返回快，就认为“发出去了”。其实可能卡在：
- 路由 查找失败 →
ip_route_output_flow返回错误，send()直接 -ENETUNREACH - 本地 端口 耗尽 →
net.ipv4.ip_local_port_range被占满，connect()失败但sendto()UDP 可能静默丢弃 - TCP 发送队列满 →
sk_stream_is_writeable()返回 false，阻塞式 socket 挂起，非阻塞则返回 -EAGAIN
为什么 conntrack 会改写源端口或丢包
启用 nf_conntrack 后，所有新建连接都会被跟踪，而它的哈希表大小、超时策略、状态匹配逻辑直接影响转发行为。最 常见问题 是 SNAT 场景下，conntrack -L 显示 TIME_WAIT 条目堆积，导致新连接被拒绝或源端口被复用错乱。
关键配置项必须检查：
-
net.netfilter.nf_conntrack_max：默认 65536，高并发场景极易打满 -
net.netfilter.nf_conntrack_tcp_timeout_time_wait：默认 120 秒，短连接服务建议压到 30 -
net.ipv4.netfilter.ip_conntrack_tcp_be_liberal：设为 1 可缓解某些中间设备 RST 导致的状态不一致
调试时用 conntrack -E 实时监听事件，比翻日志快得多。
eBPF 如何安全观测协议栈关键点
传统 工具（如 tcpdump、ss）只能看到“结果”，eBPF 可在 tcp_v4_rcv、ip_finish_output、dev_hard_start_xmit 等函数入口插桩，且不修改内核代码。但要注意：不是所有函数都支持 kprobe，优先用 tracepoint（如 skb:kfree_skb）或 fentry（5.10+ 内核）。
一个实用观测点：
#!/usr/bin/env python3 from bcc import BPF bpf_text = """TRACEPOINT_PROBE(skb, kfree_skb) {if (args->reason == 10) {// SKB_DROP_REASON_NOT_SPECIFIED bpf_trace_printk("drop at %s\n", args->location); } return 0; }""" b = BPF(text=bpf_text) b.trace_print()注意：args->location 是内核符号地址，需配合 /proc/kallsyms 解析；生产环境避免用 bpf_trace_printk，改用 perf ring buffer。
协议栈里真正难定位的是跨 CPU 队列竞争、softirq 抢占延迟、RPS/RFS 配置失当——这些不会报错，只会让延迟毛刺变多、吞吐上不去。别只盯着函数路径，得看调度上下文。
