1. 课程导论：为什么需要裁剪协议栈？MQTT在物联网中的位置。

各位同学，咱们直接开门见山。

做嵌入式物联网开发，你迟早会遇到一个灵魂拷问：我的设备内存就 256KB，Flash 就 2MB，凭什么要跑一个完整的 Linux TCP/IP 协议栈？

我早年做一款智能电表项目时，就吃过这个亏。当时图省事，直接把桌面端的 lwIP 配置搬了过去，结果设备上线后，内存碎片化严重，三天两头死机。后来一查，光协议栈的缓冲区就占了系统可用内存的 40%。

所以，裁剪协议栈不是炫技，是生存刚需。

1.1 物联网设备的资源困境

你想想看，一个典型的物联网终端长什么样？

• MCU：ARM Cortex-M 系列，主频几十到几百 MHz
• RAM：16KB ~ 512KB
• Flash：128KB ~ 2MB
• 网络接口：Wi-Fi / LoRa / NB-IoT / 以太网

这和你的笔记本电脑完全不是一个量级。完整的 TCP/IP 协议栈，比如 Linux 内核网络子系统，光代码量就几十万行，内存占用轻松上兆。你让一个 STM32 去跑，那不是开玩笑吗？

1.2 裁剪协议栈，到底在裁什么？

我个人习惯把裁剪分成三个层次：

1. 功能裁剪：去掉不需要的协议。比如你的设备只做数据上报，那 TCP 的重传、拥塞控制算法可以简化；不需要 IPv6，就砍掉。
2. 缓冲区裁剪：调整收发缓冲区大小、协议控制块数量。这是最直接的内存优化手段。
3. 代码裁剪：通过宏定义或条件编译，去掉调试信息、未使用的 API、冗余的校验逻辑。

裁剪层次	典型操作	节省资源
功能裁剪	关闭 IPv6、IGMP、DNS 客户端	Flash 减少 30%~50%
缓冲区裁剪	TCP 窗口从 64KB 降到 4KB	RAM 减少 60%~80%
代码裁剪	去掉 assert、调试打印	Flash 减少 10%~20%

1.3 MQTT 在物联网中的位置

好，协议栈裁完了，上层跑什么应用协议？

在物联网领域，MQTT 几乎是事实标准。为什么？

• 轻量级：协议头最小只有 2 字节，比 HTTP 的几百字节头小得多。
• 发布/订阅模型：解耦了数据生产者和消费者，非常适合传感器数据上报、命令下发。
• 三种 QoS 等级：从“最多一次”到“恰好一次”，按需选择。
• 持久会话：设备断线重连后，能继续接收离线期间的消息。

我举个例子。一个温湿度传感器，每 5 秒上报一次数据。如果用 HTTP，每次都要建立 TCP 连接、发送请求头、等待响应，光握手开销就占了一大半。用 MQTT，一条长连接搞定，数据净荷可能就 10 个字节。

1.4 裁剪 + MQTT 的典型架构

下面这张图，是我做项目时常用的分层结构。你可以看到，裁剪工作贯穿了网络层到传输层。

1.5 避坑指南：裁剪的代价

裁剪不是免费的午餐。我曾经在一个项目中，为了省内存，把 TCP 的接收窗口从 16KB 砍到了 2KB。结果呢？设备在弱网环境下，吞吐量直接掉到原来的十分之一，数据上报延迟飙升。

1.6 本课程能给你什么？

这门课，我会带你走一遍完整的裁剪与调优流程：

• 从 lwIP 和 uIP 这两个主流嵌入式协议栈入手，手把手教你配置裁剪选项。
• 然后，基于裁剪好的协议栈，搭建 MQTT 客户端，做性能测试。
• 最后，我会分享一些压箱底的调优技巧，比如内存池优化、中断处理、零拷贝等。