Linux網(wǎng)絡(luò)棧從網(wǎng)卡驅(qū)動通過netif_rx()/NAPI將包入softnet_data隊列；2. net_rx_action()處理並分發(fā)到協(xié)議層如ip_rcv()，支持eBPF過濾；3. IP層校驗、路由查找，本地則送傳輸層，否則轉(zhuǎn)發(fā)；4. TCP/UDP根據(jù)socket隊列交付應(yīng)用，rmem_max影響UDP收包性能。理解此流程可精準定位丟包、調(diào)優(yōu)性能，是實戰(zhàn)必備基礎(chǔ)。

The Linux kernel networking stack is a powerful, modular, and highly optimized subsystem that handles everything from packet reception and transmission to routing, filtering, and socket operations. Whether you're debugging network performance issues, writing a network driver, or building a high-performance application, understanding how the stack works under the hood is essential.

Here's a practical deep dive—no fluff, just what matters:

1. Where It All Starts: The Network Device Interface (NDIS-like layer in Linux)

When a packet arrives from hardware (like a NIC), the driver calls netif_rx() or uses NAPI (New API) for high-throughput scenarios (eg, napi_schedule() ).

• NAPI reduces interrupt overhead by switching to polling mode when traffic is heavy—critical for avoiding CPU saturation.
• Drivers register with the kernel via register_netdev() , and packets flow into the per-CPU softnet_data structure (found in net/core/dev.c ).

Pro tip: Use cat /proc/softirqs | grep NET_RX to see how many packets your CPU is handling via softirqs—uneven distribution may indicate RSS (Receive Side Scaling) isn't configured right.

2. Packet Flow: From Driver to Protocol Handlers

Once in the softnet backlog, packets are processed by net_rx_action() —a softirq handler that:

• Pulls packets from the queue
• Checks for protocol handlers via ptype_base (a hash table of packet types like ETH_P_IP, ETH_P_ARP)
• Calls the right handler, eg, ip_rcv() for IPv4

This is where BPF (Berkeley Packet Filter) programs can hook in—either via classic socket filters or modern eBPF (used by tools like Cilium or tcpdump).

Example: If you run tcpdump , it attaches a BPF filter to the socket, which runs before the packet hits the IP layer—so you can drop packets early and save CPU.

3. IP Layer: Routing, Forwarding, and Local Delivery

Inside ip_rcv() , the kernel:

• Validates the IP header
• Applies netfilter hooks (think iptables): NF_INET_PRE_ROUTING
• Looks up the route using the FIB (Forwarding Information Base)
• If destination is local → passes to transport layer (TCP/UDP)
• If not local and forwarding is on → sends to ip_forward()

Key files:

• net/ipv4/ip_input.c – packet input logic
• net/core/rtnetlink.c – route table management

Watch out: Misconfigured iptables rules or missing routes can silently drop packets here—use tcpdump -i any to see if packets reach the IP layer.

4. Socket Layer: From Transport to User Space

For TCP:

• tcp_v4_rcv() processes the packet
• Checks socket state, updates receive buffer
• Wakes up waiting processes via sk_data_ready() callback

For UDP:

• udp_rcv() delivers to the correct socket via 4-tuple lookup
• Uses per-socket receive queues ( sk_receive_queue )

Performance tip: If your app is slow receiving UDP packets, check netstat -su for “receive buffer errors”—you might need to increase net.core.rmem_max .

Bonus: Tools to Inspect the Stack

• ss -lntp – see listening TCP sockets and their states
• cat /proc/net/softnet_stat – per-CPU packet processing stats (look for dropped packets)
• ethtool -S eth0 – driver-level counters (eg, rx_missed_errors)
• perf record -g -a sleep 10 && perf script – profile kernel functions in the stack

Understanding the Linux networking stack isn't just academic—it's how you debug latency, tune performance, and avoid “why is my service dropping packets?” at 2 AM.
The code is in net/ in the kernel tree—start with dev.c and core/ —it's readable once you know the flow.

Basically, it's a pipeline: driver → softirq → protocol → socket → app.
Mess with one stage, and the whole thing feels it.

以上是深入研究Linux內(nèi)核網(wǎng)絡(luò)堆棧的詳細內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！