被低估的物联网协议：CoAP的蛰伏与翻盘可能

不是MQTT替代品，CoAP从生下来就是另一条路

很多人会把CoAP和MQTT放在一起比，说哪个更好，其实从根上定位就不一样。

CoAP全称是受限应用协议，天生就是给资源受限物联网节点做的。什么叫资源受限？就是一块纽扣电池要跑五年，内存只有几KB，带宽每秒不到一百K的那种小节点，你让它跑完整的HTTP，头都大了，跑MQTT其实也有额外的开销。

它基于UDP做传输，核心设计思路是照搬HTTP的REST架构，就是面向资源，GET/POST/PUT/DELETE那套，开发者上手几乎不用学新的范式，同时把协议头压缩到了最小，最小的CoAP报文头只有4个字节，比HTTP小了几十倍，甚至比MQTT的报文头也小不少。还自带了观察机制，就是节点状态变了主动推给客户端，也支持块传输，传大文件也没问题。

很多人会问，那它和MQTT到底选哪个？简单说，你要做一堆设备往平台发消息，需要中心转发，选MQTT没问题。你要做单个低功耗节点直接和云端或者网关做交互，不需要中间转发，CoAP的优势拉满。说实话，我见过太多工程师上来就选MQTT，根本不管自己的场景是什么，最后做出来的设备续航比预期少了三分之一，才回头找协议层的问题，晚了。

产业落地：明明好用，为什么没火？

其实CoAP从来没有离开过产业界，你每天用的水、电、燃气，大概率就是通过CoAP传到运营商平台的，只是你不知道而已。国内三大运营商的NB-IoT网络，从商用第一天就把CoAP列为标准接入协议，现在国内超过一半的NB-IoT表计都是走CoAP接入的。

但是你翻开源社区，搜CoAP的开发框架，成熟能用的没几个，技术文章也少得可怜，和MQTT那种全栈工具链铺好的状态比，差了不止一个档次。

瓶颈其实很清楚。第一个就是生态太贫瘠。MQTT有EMQX这样成熟的开源平台，各种语言的客户端库全得很，调试工具一抓一大把，CoAP呢？主流的开源框架好几年没更新了，出了问题连个问的地方都没有，哪个做项目的敢赌？第二个是NAT穿透和网络适配的问题。UDP本身穿透NAT就比TCP麻烦，CoAP虽然有解决方案，但运营商网络五花八门，很多地方还是会出现丢包连不上的问题，早年很多厂商踩过坑，我就知道国内某头部表计厂商，早年推全CoAP方案，结果全国上线后三分之一的节点离线，最后不得不改成节点用CoAP本地交互，网关转MQTT上云，折腾掉大半年的工期，你说糟心不糟心。

不过话说回来，最近两年CoAP的处境其实在变好。低功耗广域网的规模起来了，NB-IoT连接数早就突破十亿了，大部分连接都是CoAP，运营商也慢慢把网络侧的坑填得差不多了，现在新的项目很少再出早年那种大面积连不上的问题。

未来3-5年，CoAP的机会在哪里？

我最近和几个做无源物联网的朋友聊，他们几乎都在看CoAP，核心原因就是现在的物联网节点越来越极端了。

接下来要铺的智慧城市感知节点，环境监测节点，很多要求十年不换电池，甚至靠环境能量采集供电，对每一个字节的开销都卡得要死，CoAP比MQTT小得多的报文开销，直接就是续航优势，这东西就是硬竞争力。

另外，现在AIoT的边缘计算普及，很多边缘网关需要直接和几百个终端传感器节点交互，用CoAP的REST架构，直接访问节点资源，不用做额外的协议转换，开发效率高很多。

当然，风险也很明显。CoAP用DTLS做安全握手，开销还是不小，对于资源特别小的节点来说，依然吃不消，轻量级安全标准现在还没完全统一。另外，UDP本身的无连接特性，很容易被利用做DDoS放大攻击，大规模部署之后，网络层的治理压力不小，这个问题现在还没找到特别完美的解决方案。

我个人判断，未来三到五年，CoAP的连接数会翻至少两到三倍，主要增长来自低功耗表计、环境感知、无源物联网这些场景，它不会取代MQTT，也不会取代HTTP，就是在自己的赛道里慢慢吃下所有适合它的场景。

很多人觉得协议层的战争十几年前就打完了，其实不对，物联网的渗透才刚刚开始，之前没那么多极端约束的场景，现在有了，自然就会给当年设计精准的协议留足空间。

说白了，适合的，才会留下来。