第1章：Linux网络协议栈架构
各位同学好，我是老李。在车载嵌入式Linux领域摸爬滚打了十几年，今天咱们来聊聊网络协议栈的架构。说实话，我刚入行那会儿，看着网络数据在协议栈里流转，感觉就像看天书一样。后来踩了不少坑，才慢慢摸清了门道。
网络协议栈，说白了就是Linux内核里负责网络通信的那一套机制。你想想看，你的车载娱乐系统要上网、要跟CAN总线通信、要处理OTA升级，这些全都离不开它。我习惯把协议栈比作一个多层蛋糕，每一层都有自己的职责。
1.1 内核网络子系统分层
Linux网络协议栈从上到下分为四层：Socket层、传输层、网络层、驱动层。每一层都只跟相邻层打交道，这种设计让代码维护起来特别清爽。
1.1.1 Socket层
这是最靠近用户空间的一层。应用程序通过socket()、bind()、send()这些系统调用跟内核打交道。我刚开始做车载项目时，经常看到同事在应用层直接操作原始socket，结果调试起来特别痛苦。
核心职责：
- 提供统一的编程接口（BSD Socket API）
- 管理socket数据结构
- 处理协议族（AF_INET、AF_PACKET等）
嗯，这里要注意：Socket层其实是个"翻译官"。它把用户发来的请求，转成内核能理解的数据结构。我见过不少新手，在应用层疯狂创建socket却不关闭，最后把系统fd耗尽了——这坑我年轻时也踩过。
1.1.2 传输层
传输层负责端到端的通信。TCP和UDP是这里的两个主角。TCP提供可靠连接，UDP只管发不管收。在车载场景下，我建议这样选：
| 协议 | 适用场景 | 我的经验 |
|---|---|---|
| TCP | OTA升级、日志上传 | 重传机制在弱网环境下很关键 |
| UDP | 音视频流、传感器数据 | 丢包可以忍，延迟不能忍 |
我曾经在调试车载摄像头视频流时，发现UDP丢包率高达30%。后来排查发现是传输层的接收缓冲区太小——默认值只有64KB，对于高清视频流来说根本不够用。
1.1.3 网络层
网络层负责路由选择和IP分片。IP协议是这里的核心。我记得有一次，客户反馈车机在4G网络下经常断连。查了半天，发现是IP分片导致的——某些基站不支持大包分片。
避坑指南：我曾经在MTU设置上吃过亏。车载环境下的MTU值建议设为1400，而不是标准的1500。因为要预留一些空间给隧道协议和VLAN标签。
1.1.4 驱动层
这是最底层，直接跟网卡硬件打交道。驱动层负责收发原始数据帧。说实话，这一层我平时接触不多，但每次出问题都特别难排查。
驱动层的关键是中断处理。网卡收到数据后，通过中断通知CPU。如果中断频率太高，CPU就忙着处理中断，没空干别的了。这就是所谓的"中断风暴"。我建议用NAPI（New API）来缓解这个问题——它把中断和轮询结合起来，效率高很多。
1.2 关键数据结构
协议栈里有两个数据结构，你必须得吃透：sk_buff和net_device。我面试新人时，就爱问这两个东西。
1.2.1 sk_buff：网络数据的"快递箱"
sk_buff是协议栈里最重要的数据结构，没有之一。每个网络数据包，从驱动层到应用层，都装在这个"箱子"里。它的结构很复杂，但核心就几个字段：
struct sk_buff {
struct sk_buff *next; // 链表指针
struct sk_buff *prev;
struct sock *sk; // 所属socket
struct net_device *dev; // 网卡设备
unsigned int len; // 数据长度
unsigned int data_len; // 分片数据长度
__u16 protocol; // 协议类型
// 指针操作区
unsigned char *head; // 缓冲区起始
unsigned char *data; // 数据起始
unsigned char *tail; // 数据结束
unsigned char *end; // 缓冲区结束
};你看，head和end是固定的，data和tail会随着协议层处理而移动。数据从驱动层上来时，data指向MAC头；到了网络层，data指向IP头；到了传输层，data指向TCP头。这种设计避免了数据拷贝，效率很高。
注意：我曾经在项目中遇到sk_buff泄漏的问题。每次收发包都分配sk_buff，但释放不及时，最后系统内存耗尽。排查时发现是某个驱动模块在异常路径上忘了调用kfree_skb()。这种bug特别隐蔽，建议用kmemleak工具定期检查。
1.2.2 net_device：网卡的"身份证"
每个网卡设备在内核里都对应一个net_device结构体。它记录了网卡的所有信息：
- 硬件信息：MAC地址、IRQ号、IO端口
- 状态信息：链路状态、MTU、广播标志
- 操作函数：open、stop、start_xmit、do_ioctl
- 统计信息：收发包计数、错误计数
我习惯用ip命令查看net_device的信息：
# ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff看到那个qlen 1000了吗？这是发送队列长度。在车载环境下，如果网络波动大，我建议把这个值调大一些，比如2000。否则队列满了，数据包就直接丢了。
1.3 数据包的"奇幻漂流"
咱们来走一遍数据包的完整旅程。假设车机要发送一个HTTP请求：
- 应用层：调用send()系统调用
- Socket层：创建sk_buff，填充socket信息
- 传输层：添加TCP头，计算校验和
- 网络层：添加IP头，查找路由表
- 驱动层：添加MAC头，通过DMA发送到网卡
接收路径正好相反。我刚开始做车载项目时，总以为数据包在每一层都要拷贝一次。其实不是的——sk_buff的指针操作让数据包在内存里只存一份，各层通过移动指针来访问自己的头部。这种"零拷贝"设计，是Linux网络性能的关键。
总结一下：
- 协议栈四层架构：Socket、传输、网络、驱动
- sk_buff是数据载体，理解指针操作是关键
- net_device是网卡抽象，调优参数都在这里
- 数据包在协议栈里只存一份，通过指针移动实现分层处理
好了，第一章就讲到这里。下一章咱们聊聊协议栈的初始化流程，看看内核是怎么把这些模块串起来的。记住，理解架构是优化的前提——你连蛋糕有几层都不知道，怎么知道该切哪一层呢？