1. Zephyr 网络协议栈概述
各位同学，咱们今天正式开讲 Zephyr 网络协议栈。说实话，我第一次接触 Zephyr 的网络子系统时，第一反应是——这玩意儿比我想象的复杂得多。但别担心，我会带着你一层层把它拆开，让你看清楚里面到底是怎么回事。
1.1 Zephyr 网络子系统架构
Zephyr 的网络子系统，说白了就是一个高度模块化的通信框架。它不像 Linux 那样庞大，但麻雀虽小五脏俱全。我个人习惯把它的架构分成三层来看：
- 应用层：你写的 Socket 代码、HTTP 客户端、MQTT 订阅者，都在这一层。
- 核心协议层：TCP/IP 协议栈、BSD Socket 兼容层、网络缓冲区管理。
- 驱动层：Wi-Fi、以太网、蜂窝模组、6LoWPAN 等物理接口的驱动。
嗯，这里要注意一点：Zephyr 的网络子系统是 可裁剪 的。你不需要把所有功能都编译进去。我在做一款低功耗传感器节点时，只启用了 UDP 和 6LoWPAN，整个协议栈只占了不到 30KB 的 Flash。这一点对资源受限的 MCU 来说，太关键了。
核心设计理念：Zephyr 网络子系统采用 分层 + 模块化 设计，每个协议层都可以独立开关，通过 Kconfig 配置。你不需要的功能，编译器根本不会把它带进来。
1.2 网络协议栈分层模型
Zephyr 的协议栈分层，其实跟经典的 TCP/IP 四层模型很像，但做了一些嵌入式场景下的优化。我画了一张图，你看一眼就明白了：
你看，这个分层模型跟 Linux 网络协议栈最大的区别在哪？Zephyr 在链路层下面直接对接的是各种 嵌入式外设接口，而不是通用的 PCIe 或 USB 网卡。我在调试一个 SPI 接口的以太网控制器时，就发现 Zephyr 的链路层驱动模型对 SPI 总线的支持非常友好，不需要像 Linux 那样写复杂的总线抽象层。
1.3 支持的协议族
Zephyr 支持的协议族，我列个表格给你看，这样更直观：
| 协议族 | 说明 | 典型应用场景 |
|---|---|---|
| AF_INET | IPv4 协议族 | 传统以太网、Wi-Fi 通信 |
| AF_INET6 | IPv6 协议族 | 6LoWPAN、Thread、物联网 |
| AF_PACKET | 原始数据包接口 | 抓包、自定义协议、诊断 |
| AF_CAN | CAN 总线协议族 | 车载网络、工业控制 |
| AF_BLUETOOTH | 蓝牙 BR/EDR 和 LE | 低功耗无线传感、可穿戴 |
| AF_NETLINK | 内核与用户空间通信 | 路由表管理、网络配置 |
我的经验：在 IoT 产品中，AF_INET6 + 6LoWPAN 的组合越来越常见。我曾经帮一个智能照明项目做方案选型，最终选择了 IPv6 + Thread 协议栈，原因很简单——每个灯泡都需要一个全球唯一的 IP 地址，NAT 根本扛不住。
1.4 支持的硬件平台
Zephyr 的网络协议栈能跑在哪些硬件上？这个问题我经常被问到。说实话，Zephyr 的硬件支持范围比大多数人想象的要广。我把它分成几类：
- MCU 平台：ARM Cortex-M 系列（M3/M4/M7/M33）、RISC-V、Xtensa（ESP32）、ARC、x86。
- 网络接口类型：内置以太网 MAC（如 STM32F4/F7/H7）、SPI 以太网控制器（如 W5500、ENC28J60）、Wi-Fi 模组（ESP8266/ESP32 AT 模式）、蜂窝模组（Quectel BG96、SIMCOM 系列）、6LoWPAN 射频（如 nRF52840 的 802.15.4）。
- 开发板：Nordic nRF52 系列、STM32 系列、NXP i.MX RT 系列、TI CC26xx/CC32xx、ESP32、Raspberry Pi Pico W。
嗯，这里有个坑我要提醒你。Zephyr 的网络驱动并不是所有平台都默认开启的。我记得有一次，我在 STM32F769 上调试以太网，折腾了半天才发现是 CONFIG_NET_L2_ETHERNET 这个 Kconfig 选项没打开。你想想看，驱动代码都在，但 L2 层没使能，数据根本传不上去。
避坑指南：在开始网络开发之前，务必确认三件事：1) 你的板子是否有对应的网络驱动；2) 驱动所需的 Kconfig 选项是否已开启；3) 硬件引脚配置（如 RMII 接口的 REF_CLK、TX_EN、CRS_DV 等）是否与驱动一致。我曾经因为 REF_CLK 极性配置错误，浪费了整整两天。
1.5 网络缓冲区管理
聊完分层和硬件，咱们得说说 Zephyr 网络协议栈里一个容易被忽视但极其重要的东西——网络缓冲区。
Zephyr 使用 net_buf 和 net_pkt 来管理网络数据包。简单来说：
net_buf：固定大小的内存块，用于存储数据。net_pkt：一个数据包的抽象，内部由多个net_buf组成链表。
这种设计的好处是什么？说白了就是避免内存碎片。在 MCU 上，动态内存分配很容易产生碎片，时间长了系统就挂了。Zephyr 的 net_buf 采用预分配的固定大小内存池，分配和释放都是 O(1) 的复杂度。
关键配置：CONFIG_NET_BUF_DATA_SIZE 和 CONFIG_NET_PKT_RX_COUNT 这两个参数直接影响你的网络吞吐量。如果缓冲区太小，高负载下会丢包；如果太大，又浪费 RAM。我一般建议根据 MTU 大小来算，比如以太网 1500 字节，每个 net_buf 设 512 字节，一个包需要 3 个 buffer。