第2章：网络基础与通信协议
各位同学，咱们今天聊点实在的。做物联网边缘计算，网络协议是绕不开的坎儿。我见过太多项目，硬件选型没问题，算法也写得漂亮，最后栽在通信协议上——要么数据传丢了，要么延迟高得离谱。说白了，协议选不对，努力全白费。
2.1 TCP/IP协议栈：物联网的骨架
先说说TCP/IP协议栈。这东西就像快递系统，分四层干活：
- 应用层：你发的数据长什么样（比如MQTT、HTTP）
- 传输层：怎么保证包裹不丢（TCP/UDP）
- 网络层：包裹该走哪条路（IP协议）
- 链路层：物理上怎么传（Wi-Fi、以太网）
我个人习惯把TCP/IP比作「层层封装」。你想想看，应用层发一句"温度25度"，到了传输层加个端口号，网络层加个IP地址，链路层再加个MAC地址。每一层只管自己的事，互不干扰。
避坑指南：我曾经在项目里遇到一个问题——设备上报数据时快时慢。查了半天，发现是TCP的Nagle算法在作祟。这个算法会把小包合并成大包再发，省带宽但增加延迟。如果你的设备上报频率高、数据量小，记得关掉它。
2.2 MQTT协议详解：物联网的"微信"
MQTT是我最常用的协议，没有之一。它为什么火？说白了就三个字：轻、快、稳。
MQTT的核心是发布/订阅模式。设备A发一条消息到某个"主题"，所有订阅了这个主题的设备都能收到。这比HTTP那种一问一答的模式灵活多了。
来看看MQTT的三个服务质量等级（QoS）：
| QoS等级 | 含义 | 适用场景 |
|---|---|---|
| 0 | 最多发一次，丢了不管 | 传感器高频数据，丢几个无所谓 |
| 1 | 至少发一次，可能重复 | 控制指令，重复了也能处理 |
| 2 | 恰好发一次，保证不丢不重 | 计费、交易等关键数据 |
嗯，这里要注意：QoS 2虽然最可靠，但开销也最大。我在做智能电表项目时，抄表数据用QoS 0，远程断电指令用QoS 2。别一刀切，得看场景。
我的经验：MQTT的遗嘱消息（Will Message）是个好东西。设备突然掉线时，服务器会自动发一条遗嘱消息，通知其他设备"我挂了"。我在做冷链监控时就用这个功能，冷柜断电后立刻报警，比心跳检测快多了。
2.3 HTTP/HTTPS对比：选哪个？
HTTP和HTTPS，区别就一个字母——S（Security）。但实际用起来差别大了去了。
HTTP是明文传输，数据包在网络上裸奔。HTTPS加了SSL/TLS加密，相当于给数据穿了个防弹衣。代价呢？握手时间多了2-3个RTT，CPU开销也大。
我建议这样选：
- 内网通信：HTTP就够了，省资源
- 公网通信：必须HTTPS，不然数据被截获你都不知道
- 资源受限设备：考虑MQTT over TLS，比HTTPS轻量
警告：别以为HTTPS就万无一失。证书过期、中间人攻击、弱加密套件，坑多着呢。我曾经遇到一个项目，设备用HTTPS上报数据，结果证书是自签名的，客户端没做校验——等于没加密。记住：HTTPS的安全取决于你配置得对不对。
2.4 CoAP协议简介：专为"小"设备而生
CoAP，全称受限应用协议。说白了，就是给那些内存只有几十KB、CPU跑不到100MHz的设备用的。
它基于UDP，比TCP轻量得多。但UDP不可靠怎么办？CoAP自己实现了重传机制，类似TCP的确认应答。它还支持资源发现，设备可以自动告诉别人"我能提供什么服务"。
CoAP和HTTP很像，都是RESTful风格，用GET/POST/PUT/DELETE操作资源。但CoAP的报文头只有4个字节，HTTP头至少几十个字节。你想想看，对于一次只传几个字节的传感器数据，这差距有多大。
实战对比：我在做智能路灯项目时，对比过MQTT和CoAP。MQTT适合需要持续连接、双向通信的场景；CoAP更适合"发完就睡"的低功耗设备。最后我们选了CoAP，因为路灯控制器大部分时间在休眠，用MQTT保持长连接太费电。
2.5 协议选型：我的决策框架
讲了这么多，到底怎么选？我总结了一个简单的决策树：
- 设备资源够不够？（RAM > 100KB，Flash > 1MB）→ 选MQTT或HTTPS
- 设备资源受限？（RAM < 50KB）→ 选CoAP或MQTT-SN
- 需要实时双向通信？→ MQTT
- 只是定时上报数据？→ HTTP或CoAP
- 数据安全性要求高？→ 加TLS
记住，没有最好的协议，只有最合适的。我在一个项目里同时用了MQTT（控制指令）和CoAP（传感器数据），各取所长，效果很好。
最后说一句：协议选型别光看技术文档。我建议你先搭个原型，跑几天看看实际表现。理论再漂亮，不如实际跑一跑。嗯，今天就到这里，下节课咱们聊边缘计算的数据同步策略。