我问答网那天，我盯着屏幕上的报错日志，想砸了手里的开发板。不就是让一个破温度传感器把数据传到云端吗？结果一整天过去了，数据要么丢包，要么延迟十几秒——而这设备本应该每5秒报一次警的。
然后我查了代码… 靠，用的HTTP长轮询。那个瞬间我明白了一个真理：物联网选错协议，无异于开跑车去耕地。 后来被同事嘲笑了一周，我痛定思痛，把几个主流协议扒了个遍。今天干脆写出来，省得你们再被坑。❗
那些协议简写，像黑话一样劝退
刚接触物联网那会儿，听见MQTT、CoAP、AMQP、XMPP… 脑子嗡嗡的。这都啥玩意儿？不就是把数据从A传到B吗，搞这么复杂。说实话，当时我甚至觉得用串口直接怼都行——别笑，真的有人这么干过，然后设备一多就疯了。
但后来我懂了，这些协议背后其实是对不同场景的妥协。你要在电量只有一粒纽扣的传感器上跑TCP？连三次握手那点功耗都嫌多。你要让工厂的上千台设备毫秒级同步？让它们慢慢轮询就等着事故吧。所以，选协议本质上是在功耗、实时性、开发爽度之间找平衡。✅
MQTT：低带宽卧龙凤雏，但没那么神
MQTT这几年火得没边。发布/订阅模型，topic分级，三两行代码就能让设备跟服务器勾搭上。我最早拿它做农业大棚监控，野外4G信号差得要命，但MQTT硬是靠极小的包头和QoS把数据挤了出去。爽的时候是真爽，特别是QoS 1（至少一次送达）——你知道，搞农业的要是不小心丢了一条灌溉指令，那作物可就… 唉。
但别被冲昏头脑。QoS 2（精确一次）的交互流程复杂得令人发指，四次握手，我一哥们儿用它在带宽不足的LoRa上跑，丢包率直接从1%飙到30%。而且，MQTT的broker中心化架构，在大规模分布式场景下简直是个单点炸弹。有一次我broker挂了，整个猪场的监控黑屏半小时，老板以为猪跑了… 啧，教训。💡
CoAP：一个浑身RESTful范儿的精简怪物
如果你玩过嵌入式，肯定对资源受限有刻骨铭心的感受。8KB RAM，2MHz主频，跑个TCP/IP协议栈都费劲。这时候CoAP就闪亮登场了——基于UDP，报文极小，而且天生跟HTTP交互顺畅，URL、GET、POST那套直接搬过来。我曾经用它在Zigbee节点上跑，简直像给蚊子装上了喷气发动机。
但是！UDP的丢包问题让你想骂娘。哪怕CoAP自带重传和CON/ACK机制，碰上网络波动一样抓瞎。有回我拿它做工业震动传感器，结果一个关键数据包因为拥塞控制被丢弃，导致客户误判设备状态。从那以后，我给自己立了个规矩：只要涉及生命财产安全，就算设备资源再少，也得咬牙上个可靠传输层。 别指望CoAP那点重传能救命。
跑偏的吐槽和一点真心话
扯远了，回到选协议这件事。这几年物联网圈子里有个怪现象：不管什么项目，先上MQTT再说。甚至有人用MQTT传视频… 我见过，真的，卡得跟幻灯片似的。还有一次，听说某团队在传感器用AMQP，功耗大到电池一周换一次，直接被客户怼到怀疑人生。所以啊，别盲从。📌
我的私人决策表是这样：
- 需要双向控制、设备成千上万、网络不可靠？MQTT是绕不开的。
- 设备傻到只有几字节内存、能耗抠门到极致？试试CoAP，配合LwM2M用起来。
- 数据吞吐量巨大、不在乎延迟？也许RSocket或者简单的WebSocket就够了。
当然，这行当变化快得离谱。前阵子看到QUIC也开始渗透进来，不知道以后会不会又一堆新坑。写到这里，我突然想起自己踩坑最惨的那次——因为协议选择错误，整个项目延期三个月，年终奖泡汤。从那以后，我再也不敢说“协议不就传个数据么”。😭
如果你正纠结于选哪个，别光看文档，拿板子实际跑一跑。一个上午的测试比一周的论文都管用。真的。