数据包从网卡到用户进程的关键路径是：网卡驱动 → 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 配置失当——这些不会报错，只会让延迟毛刺变多、吞吐上不去。别只盯着函数路径，得看调度上下文。