在物联网项目里我被问过最多的问题就是“MQTT和CoAP到底选哪个”。每次听到这个问题我都想先说一句这不是一道二选一的选择题而是一道“先搞清楚自己系统长什么样再决定用什么协议”的判断题。MQTT和CoAP都诞生于物联网早期目的都是解决“设备资源有限、网络质量不稳定”下的通信问题但设计思路完全走的是两条路。一个像“邮局系统”所有消息通过中心节点中转讲究发布订阅、消息可靠一个像“电话直拨”设备之间点对点交谈讲究轻量请求、资源约束。这篇文章我就把两边的底子都拆开从协议机制、网络模型、可靠性、安全性、实际落地成本几个维度讲透最后给出一套可以直接照着做的选型思路。不管你是做智能硬件、工业数据采集还是云端设备管理平台这篇都能给你一个相对完整的判断框架。1. 先搞清楚一件事这两个协议根本不在同一个赛道很多人把MQTT和CoAP放在一起对比是因为它们经常出现在同一个需求文档里显得像是“竞争对手”。但如果你扒开底层设计去看会发现它们解决的是不同层次的问题。选型之前先得理解它们各自的出身和设计哲学。1.1 MQTT的出身消息中间件下沉到物联网MQTT全称Message Queuing Telemetry Transport最早是1999年IBM为石油管道遥测系统设计的。注意这个背景——石油管道远程、窄带、链路不稳定、设备无人值守。这种场景下你需要什么你可能需要把几千个传感器数据源源不断传到中心系统中心系统可能还要反向下发控制指令。传感器不需要知道数据发给谁中心系统也不需要逐个维护和每个传感器的连接状态。所以MQTT从骨子里就是一套“消息分发系统”的思维。它有一个中心节点叫Broker所有设备都连到Broker上通过“主题”来标识消息的类别。发送方只管往某个主题发消息接收方自己对感兴趣的主题做订阅Broker负责把消息匹配、路由、推送给订阅者。这种模式最大的好处是解耦发送方和接收方不需要知道彼此存在不需要建立点对点链路设备上下线对彼此透明。这个设计放到今天的物联网里正好契合了很多平台化需求。一个智能家居App要控制全屋几十个设备app只需要往某个主题发一条控制指令对应设备收到后就执行设备不需要知道app是谁、在哪。反过来几十个设备上报状态也是往主题一丢平台统一订阅就能全部拿到。这种“一对多、松耦合、可扩展”的特征让MQTT几乎成了云端设备接入事实标准。1.2 CoAP的出身为受限节点打造的HTTP替代品CoAP全称Constrained Application Protocol是IETF CoRE工作组搞出来的标准编号RFC 7252。设计目标非常明确给那些内存只有几十KB、CPU主频只有几十兆赫兹、经常需要电池供电跑好几年的“极受限设备”提供一种类似HTTP的应用层通信方式。HTTP太胖了这不用多说。一个完整的HTTP请求头动不动几百字节还得跑在TCP上TCP三次握手、四次挥手对睡眠型设备来说简直是噩梦。但物联网设备又不是不需要“请求-响应”这种语义比如传感器被问“你现在的温度是多少”设备就需要回答一个“读数”。CoAP就把这一套东西搬到了UDP上用二进制格式压缩报文头部只占4个字节大幅度降低了解析开销和传输流量。另外CoAP原生支持资源的发现、观察等机制。它像是一个“为了低功耗低资源设备重新设计的HTTP协议”面向的是设备间直接通信、设备与网关通信这类场景。所以在很多LPWAN网络如NB-IoT、LoRaWAN的接入层设计里CoAP的出现频率很高。1.3 各自的主战场一句话总结目前我自己经手的项目里看到的分工MQTT适合中心化物联网平台设备量大、需要统一管理、需要平台下发控制、需要历史消息回溯、需要与业务系统深度集成。CoAP适合设备端互联和受限网络直接采集节点资源紧张、网络带宽极窄、设备间点对点通信、深度睡眠省电场景。这两个协议的主战场定位决定了你在做架构选型时先看自己的数据流形态再看设备能力最后才看协议本身。下面两节我把各自的关键机制拆开讲清楚选型时必须理解的底层逻辑。2. MQTT选型必须吃透的四个底层机制很多初学者对MQTT的理解停留在“发布订阅”四个字上但真正到选型和部署阶段有几个机制是绕不开的。这四个机制直接决定了系统架构和运维成本提前想清楚能省不少后面返工的精力。2.1 Broker中心化架构它的价值和它带来的约束MQTT必须有一个Broker这是它的立身之本。所有客户端设备也好、App也好、后端服务也好都长连接到这个Broker上消息收发全靠它中转。市面上常见的Broker有开源的Mosquitto、EMQX、VerneMQ商业的有HiveMQ等选型本身又是一套学问。这种中心化架构带来的好处非常直接消息的路由、过滤、分发逻辑都被收敛到一处要扩容就加Broker节点要做权限控制就在Broker层统一做要审计和监控也方便集中采集数据。你不需要去管两个设备之间怎么互相发现、怎么建立连接连上Broker就可以了。但“所有设备都连中心”也意味着两件事。第一Broker是系统的单点依赖一旦Broker挂了所有设备之间即使网络正常也无法通信。第二设备必须先连上Broker才能收发消息这个“连接”本身是TCP长连接对设备端的网络稳定性、心跳保活都有要求。在实际项目中我见过不少团队为了省事把Broker部署在云上然后设备走公网连上来。看起来没什么问题但设备网络差的时候TCP连接频繁断开重连Broker端的连接状态管理压力会非常大。如果设备量大还需要考虑Broker的集群部署和消息持久化方案。这些都是MQTT选型里要提前计算进去的隐性成本。2.2 QoS三级到底是怎么“可靠”的MQTT的QoSQuality of Service是选型时经常被拿出来讨论的点。它分三级QoS 0消息最多发一次发完不管可能丢失。QoS 1消息至少发一次保证送达但可能重复。QoS 2消息恰好发一次通过四步握手保证不丢不重。我见过很多刚接触MQTT的人第一反应是“那我都用QoS 2不就行了最可靠”。但在真正的工程里QoS 2的代价和复杂程度远高于它带来的收益。QoS 2为什么需要四步握手因为它要在发送方和接收方之间维护一个完整的去重状态确保消息只被处理一次。这意味着Broker要为每条消息做状态记录接收方也要做相应的去重判断。在高吞吐场景下这个开销会被放大得非常明显。所以实际项目中绝大部分场景用QoS 1就够了——保证消息送达重复的问题在业务侧做幂等处理。只有像支付、指令下发这类绝对不能重复执行的操作才值得考虑QoS 2。从选型角度看你要评估的是我的业务能容忍丢消息吗能容忍重复处理吗如果两者都不能那么你要解决的不仅仅是选QoS几的问题还需要在应用层做消息幂等和补偿机制不能把所有可靠性都压在协议上。2.3 主题树、遗嘱消息、保留消息这些“附加能力”除了最基本的发布订阅MQTT还有几个非常实用的机制选型时不能忽视。主题Topic不是简单的字符串它是有层级结构的比如home/room1/temperature和home/room2/temperature。订阅方可以用通配符#和来做多级匹配。这个能力在实际项目中非常关键它允许你用一套主题规则把设备分组、按区域路由也可以做权限控制比如某个设备只允许往device/001/data这个主题发消息不允许往device/002/data发。在设计主题树的时候一定要提前规划好层级含义因为后期改主题结构比重构数据库还痛苦。遗嘱消息Last Will and TestamentLWT是另一个容易被忽略的功能。设备在连接时可以指定一条遗嘱消息如果设备异常离线比如网络断开、断电Broker会代替它发布这条遗嘱消息。这个机制在做设备在线状态监控时非常有用等于协议层就帮你实现了“心跳超时通知”的功能。保留消息Retained Message则解决了“新订阅者想拿到最近一次状态”的问题。比如一个温度传感器每次上报完温度Broker可以保留这个主题的最后一条消息新的订阅者一订阅立刻就能拿到最新温度不用等下一次上报。对智能家居这种需要App打开就看到设备状态的场景保留消息几乎是标配。2.4 从选型角度看MQTT的隐藏成本说了这么多机制背后其实都有成本。MQTT协议自身的报文头虽然很小固定头最小2字节但为了保证长连接的稳定客户端得定期发送心跳包PINGREQBroker端也要维护海量连接的会话状态。设备越多Broker的内存和CPU消耗就越明显。另外MQTT跑在TCP之上而TCP在弱网环境下的表现并不好。TCP的拥塞控制、重传机制在丢包率高的网络中会大幅降低吞吐还会带来“队头阻塞”问题。如果你的设备长期处于信号差、链路抖动的环境TCP的劣势会被放大。这也是为什么有些团队宁可放弃MQTT的生态也要在设备端选择基于UDP的CoAP。我举一个具体的例子有一个做共享设备的项目设备用的是4G Cat.1模组网络信号不稳定原来用MQTT协议设备经常出现掉线重连Broker端同一时间维护的连接数虚高消息延迟也不稳定。后来把设备端的接入协议换成CoAP虽然要自己处理可靠重传但整体通信稳定性和功耗都得到明显改善。这个案例后面讲选型框架时还会提到。3. CoAP选型必须吃透的三个设计取舍CoAP的好处不是看一眼文档就能完全感受到的。它的设计非常强调“受限”二字很多选择都是在资源约束下做出的权衡。理解这一点你才真正知道CoAP适合什么、不适合什么。3.1 基于UDP与4字节头部意味着什么CoAP默认跑在UDP上默认端口5683DTLS加密后是5684。整个消息的头部固定为4字节包含版本、类型、Token长度、代码和消息ID等关键信息。对比一下TCP的握手开销和HTTP的头部体积差距是非常可观的。UDP是面向无连接的没有握手、没有状态维护。对设备来说这意味着几点不需要维持一个长连接用完了就结束省电没有TCP的拥塞控制逻辑发送行为简单直接可以任意时刻发消息不用考虑连接是否断开。但UDP的不可靠性怎么弥补CoAP设计了两层机制。第一消息类型区分CONConfirmable需要确认和NONNon-confirmable不需要确认。CON消息如果没收到ACK发送方会按指数退避策略重传NON消息则发完即止。第二CoAP的可靠传输在应用层做而不是像TCP那样在内核里做应用可以根据业务需要控制重传策略。这里要特别提一个细节CoAP虽然默认UDP但也支持通过TCP和WebSocket传输RFC 8323。只不过目前实际应用中绝大多数还是UDP方式因为背后的核心优势就是省电和低开销。如果改成TCP这些优势基本就没了。3.2 请求响应模式与观察模式的使用边界CoAP的通信模型和HTTP非常像是标准的请求响应模式。一个CoAP客户端向服务器发一个GET请求比如coap://device/temperature服务器回一个响应带上温度值。这种模式简单直接适合一问一答的场景比如上位机查询仪表读数、App查询传感器状态。但物联网里还有另一种常见的交互持续订阅某个状态变化。对HTTP来说只能靠轮询对MQTT来说有现成的订阅机制CoAP对应的方案是观察Observe模式客户端可以“订阅”一个资源服务器在资源变化时主动推送通知。这里有个比较tricky的点Observe模式虽然好用但因为是UDP上的应用层订阅网络路径上如果存在NAT网关网关的映射超时可能导致设备收不到通知。后面讲NAT时会专门展开。你要判断自己的业务里客户端主要是“主动查”还是“被动等”。如果大量是主动查CoAP的请求响应模式非常自然几乎没有额外学习成本。如果是被动等CoAP的Observe能用但在公网环境下需要配合其他机制来保活。3.3 资源发现与受限网络什么时候CoAP是加分项CoAP还有一个HTTP没有的设计特性资源发现Resource Discovery。一个CoAP服务器可以通过访问/.well-known/core来列出自己支持的所有资源路径。比如一个传感器节点可能会返回/sensors/temp;rttemperature-c;ifsensor/sensors/humidity;rthumidity-c;ifsensor。相当于每个设备自带一份“接口文档”应用层可以动态发现设备能力而不是靠硬编码的地址表。这个能力在开源硬件、动态组网场景里非常实用。比如你用开发板搭了一套环境监测系统新加一个节点平台不需要预先配置它的接口地址直接通过资源发现拿它的能力描述即可。另外CoAP原生适配IPv6和6LoWPAN网络报文压缩、分片都有对应的规范。对运行在LoRaWAN、NB-IoT这类极窄带网络上的设备CoAP的报文体积优势是MQTT无法比拟的。实测下来一个完整的CoAP GET请求加上响应总字节数往往能控制在几十字节内这在按流量计费或带宽极有限的环境里完全是碾压性的优势。4. 一张表看穿关键差异但别只看表做选型对比表格是最直观的。我先把核心差异列出来然后逐项展开讲那些表格里看不出来的深层影响。对比维度MQTTCoAP传输层TCP/TLS也可跑WebSocketUDP/DTLS也可跑TCP/WebSocket通信模型发布/订阅Broker中转请求/响应点对点可观察消息头部固定头最小2字节实际报文较长固定头4字节报文紧凑可靠性QoS 0/1/2 三层语义CON/NON 确认重传中心节点必须Broker不需要可设备直连消息路由主题树匹配URI资源路径设备沉睡长连接前提耗电较高无连接适合睡眠唤醒服务发现无内建机制需额外设计内建资源发现安全TLS8883端口DTLS5684端口典型场景设备接入云端平台、App控制设备间直连、受限网络采集生态成熟度极高Broker、客户端、工具链丰富中等主要在嵌入式/专网领域4.1 通信模型的分水岭数据是“推”还是“拉”上面的表格里我认为最值得你盯住的是第二行通信模型。这一行基本决定了八成以上的选型走向。MQTT是“推”模式。设备把消息推到BrokerBroker再推给订阅者。整个过程消息是主动流转的发送方不需要等接收方来要。CoAP是“拉”模式本质上是客户端发起请求服务器给响应。虽然Observe模式可以做到服务器持续推送但前提还是客户端先发起订阅请求而且推送的持续性受网络路径状态影响。用生活类比MQTT像订报纸你订了之后报社每天定时把报纸送上门不用你去问CoAP像打电话问天气你想知道的时候拨个电话问一下对方告诉你答案。前者适合频繁、持续、多对多的数据流后者适合低频、按需、一问一答的场景。所以当你判断自己的业务时先问一句消息是设备主动上报给平台还是平台主动来问设备如果两者都有再看哪部分是主量。主量是上报MQTT更顺手主量是查询CoAP更轻便。4.2 NAT和网络穿透一个容易被忽视的硬伤很多设备都部署在家庭路由器、企业防火墙后面私网IP地址对外不可见。这时候设备能否被平台主动访问就取决于NAT映射的打通和保持。MQTT在这件事上的优势来自Broker中心化。设备主动向外发起TCP连接在NAT设备上建立映射然后保持这个长连接不退。只要连接不断平台随时可以通过Broker向设备下发消息不需要反向穿透。TCP连接本身有状态NAT设备通常会长期保持这个映射配合MQTT的心跳包连接可以稳定维持很长时间。CoAP就麻烦了。CoAP基于UDPUDP的NAT映射通常是无状态的网关设备里的映射条目空闲几十秒到几分钟就可能被回收。设备如果深度睡眠或者很长时间不发包平台侧想主动发送CON请求给设备经常找不到设备——因为NAT映射已经失效了。这个问题在设备部署在运营商级NATCGNAT后面时尤其明显。所以在公网环境下用CoAP基本需要自己实现心跳保活机制或者配合设备主动发起请求的“反向”通信模式。CoAP那套资源发现、观察模式在局域网、专网里很好用一放到公网就会被NAT问题掣肘。这是选型时最容易被忽略的现实约束。4.3 安全性选型TLS和DTLS的实际权衡两个协议的安全方案也截然不同。MQTT跑TCP用TLS加密CoAP跑UDP用DTLS。两者虽然同源但工程化现状差别很大。MQTT加TLS的生态非常成熟证书签发、双向认证、Broker端TLS终止、负载均衡器SSL卸载这些东西在互联网基础设施里已经练了二十年资料和方案一抓一大把。做IoT平台时设备端烧录CA证书、服务端配置双向认证这些都是标准操作。DTLS相对就“原始”很多。它基于UDP实现TLS语义但UDP的乱序、丢包、重放问题让DTLS在弱网下的握手成功率不如TLS稳定。更麻烦的是很多现成的CoAP协议栈对DTLS的支持性能一般在资源受限的MCU上做DTLS握手内存和CPU开销都不小。还有一点DTLS使用的PSK预共享密钥模式在设备量产时要处理好密钥的分发和更新如果密钥硬编码到固件里后期更新密钥就是一场运维噩梦。安全选型的结论是如果你的设备需要上公网、需要对接云端平台TLSMQTT的组合在工程上最省心如果你只在私有网络内通信对安全要求是内部级别CoAP可以配合DTLS或应用层加密使用。5. 选型决策框架遇到具体项目可以照做前面的机制拆解都是为了让这一节的决策框架“有据可依”。下面我把自己在实际项目中反复用过的一套判断流程分享出来。你不需要精通两个协议的所有细节只需要顺着这个流程回答几个关键问题基本能得出一个不后悔的结论。5.1 四个能直接问自己的关键问题在做任何技术选型时我习惯先画一张最简单的系统拓扑图设备在哪里平台在哪里数据怎么流控制指令怎么下。然后依次问这四件事设备能和中心直接保持长连接吗如果设备部署在用户家庭、野外、移动载体上网络情况不可控长期维持长连接的成本高不高如果维持不了MQTT的推送优势就发挥不出来。消息的主要方向是什么设备持续上报数据给平台还是平台经常主动查询设备状态前者倾向于MQTT后者倾向于CoAP。设备资源有多紧张MCU内存只有几十KB、Flash只有几百KB、用纽扣电池供电那CoAP的报文体积优势就非常关键如果设备用的是Linux系统模组资源充裕MQTT的生态优势更能发挥作用。系统的维护主体是谁你是否有能力维护自建的Broker集群是否愿意自己处理CoAP上的可靠重传和NAT保活如果团队规模有限优先选择社区成熟、方案完备的协议可以省下大量排坑时间。这四个问题不是孤立回答而是要交叉起来看。举几个我实际遇到过的典型组合。5.2 典型场景的选型结论第一个场景智能家居设备接云平台。设备是WiFi插座、灯泡、传感器家中有路由器云端有控制平台App需要随时下发开关指令。这时候设备通常可以保持长连接数据方向既有上报也有下发设备用的是ESP32这类资源相对充裕的WiFi模组。选MQTT几乎是唯一合理的选择。基于WiFi的TCP长连接稳定可靠MQTT生态里成熟的Broker和SDK可以省掉大量开发时间。实测下来连上之后控制指令延迟能做到毫秒级。第二个场景农田环境监测。设备是太阳能供电的低功耗传感器通过LoRaWAN网关上送数据每隔一小时上报一次土壤墒情。数据方向以上报为主偶尔的平台配置指令对实时性要求不高设备长期处于休眠状态。这种场景用CoAP就有明显优势因为无连接的设计让设备可以发送完就睡不需要维护长连接报文体积也小大大降低了LoRaWAN空口占用时间。第三个场景工业数据采集。车间里几十台设备通过工业网关把PLC、仪表的数据采集上来再传到工厂的管理平台。工厂内网环境稳定带宽也够数据是高频持续上报同时平台需要对产线做一些启停控制。MQTT非常适合Broker部署在工厂机房或私有云上设备接入稳定而且主题树可以按车间、产线、设备类型做精细化权限管理方便多角色使用。第四个场景车联网信息上报。车辆在移动网络中部署4G/5G网络状态会不断变化频繁切换基站会导致TCP连接中断。如果用MQTT设备会频繁触发重连Broker端连接管理压力很大。我见过的车联网项目里也有不少方案在采集链路上采用MQTT但要么依赖MQTT的自动重连机制要么在网络层做一些优化。如果是上报低频车辆状态数据到云端CoAP反而更合适无连接的特性让它天然不怕基站切换。5.3 混合部署是常态别非此即彼大多数成熟项目的真实情况是不是整个系统只选一个协议而是在不同层次用不同协议通过网关转换实现融合。典型的分层结构是感知层设备之间或设备与边缘网关之间用CoAP网关到云端平台用MQTT。物联设备内部资源有限和网关距离近网络稳定用CoAP可以快速建立通信、低功耗交互网关是“永远在线”的角色和云端保持长连接用MQTT保证云端指令能实时下达到网关。两个协议在网关内部完成转换各取所长。还有一种做法同一设备上同时跑两个协议栈。设备用CoAP供局域网内的其他设备直接发现和查询同时用MQTT接入云端平台。这种方案适合既要做局域网互联又要上云的产品。不过对设备资源要求更高协议栈要维护两套建议在方案确定前先做一次设备选型评估。6. 从选型到落地估算、实测与踩过的坑再好的选型落到实际工程里也一定会有计划外的状况。最后一节我分享一些实测经验和踩坑记录都是常规文档里很少写的内容。6.1 小细节导致的大问题内存、报文、心跳选型时容易忽视的第一个细节是报文体积。MQTT看起来固定头只有2字节但一个真实的Publish报文要包含主题名、消息体、可能还有报文标识符、属性等。在高频上报场景下一份完整MQTT报文很容易超过百字节再加上TCP/IP的头部开销空口数据量比预想大很多。CoAP同样携带URI路径但整体还是要紧凑得多。第二个细节是客户端的内存占用。我用过一个在主流MCU上跑MQTT的开源库静态配置下缓冲区就占了约8KB RAM和我的整个业务逻辑内存预算差不多。而一个轻量CoAP实现可以做到远小于这个数字。如果你的设备选型时内存本来就抠得很紧这个差距可能会直接决定你的MCU要不要升一个档位。第三个细节是心跳频率。MQTT的Keep Alive机制需要在设计时设置合理的心跳周期一般建议是业务上能容忍检测到掉线的最长时长的1.5倍。心跳设太短会增加功耗和网络流量设太长又会导致掉线发现不及时。CoAP本身没有这种长连接保活需求但如果有NAT映射需要维持还是得在应用层设计类似的保活包。这里要结合运营商NAT超时时间来做不同运营商差异挺大。6.2 踩过的坑三则真实案例案例一某共享设备项目4G Cat.1模组开始用了标准的MQTT over TCP方案。没想到这个型号模组的TCP/IP协议栈在弱网环境中表现不佳基站信号弱时发送缓冲区阻塞一段时间后TCP连接被Broker断掉设备进入反复重连的循环。后来把设备端改成嵌入式CoAP网关侧用Java写了一个简单的协议转换服务把CoAP请求转成MQTT消息接入平台。改完之后设备重连问题消失了而且待机功耗明显下降。这个案例给我的教训用MQTT还是CoAP要看设备所在网络到底稳不稳定不能只看平台侧方便。案例二一个使用EMQX Broker的物联网平台设备量到几万台后发现Broker CPU使用率飙升。排查后发现大量设备设置了过短的心跳周期且QoS全部用了2。很多设备其实不需要那么高的可靠性但开发时图省事统一用QoS 2导致Broker维护了大量会话状态和消息去重数据。把大部分主题降级到QoS 1、心跳周期按实际需求调整后Broker负载降了一半多。教训QoS选择要在业务需求和系统开销之间取平衡越高的QoS不等于越好的系统。案例三局域网智能照明系统当场演示故障。设备端用了CoAP手机App连上局域网直接向设备发控制命令。演示时发现部分设备“失灵”App发命令没响应。一开始以为是设备固件问题排查后定位到原因路由器开启了“AP隔离”功能局域网内的设备间通信被隔离。CoAP这种点对点通信在这种网络配置下直接失效而如果走MQTT设备都连同一个BrokerAP隔离影响就小很多。教训局域网部署的环境隔离策略也是选型必须考虑的实际因素。6.3 本地快速搭建测试环境的方法选型不能只看文档强烈建议花半天时间把两边都跑起来用你自己的业务数据做个简单压测。MQTT的本地测试非常简单。下载一个Mosquitto启动之后默认监听1883端口。用命令行工具mosquitto_pub和mosquitto_sub可以快速验证发布订阅流程。想要图形化一点可以用MQTT X这个客户端工具支持多主题订阅、报文查看和脚本测试排查问题非常方便。CoAP的测试可以用libcoap自带的coap-client也可以直接用Python的aiocoap库写几行脚本。最简单的验证方式是在本机跑一个coap-server然后用coap-client发一个GET请求。看报文大小和响应时间很快就能直观感受到CoAP的轻量特性。强烈建议在测试环境里同时模拟弱网条件用网络损伤模拟工具或者直接在路由器上做丢包、限速然后观察两个协议在相同丢包率下的表现差异。实测丢包率超过一定比例后TCP上的MQTT会发生明显的拥塞退避和重连而CoAP的UDP无连接特性反而可能表现得更好。这类实测数据最后都会成为你向上汇报选型结论时最有说服力的依据。我从一个共享设备项目的协议切换开始接触到CoAP当时第一反应也是“为什么不直接用MQTT”等到真正把设备端报文体积、功耗、弱网表现拉出来对比之后才意识到物联网协议选型从来没有银弹只有最合适的方案。希望这篇文章能帮你在做MQTT和CoAP选型时少走一些弯路。如果条件允许最好把你的真实设备、真实网络环境拿来进行一轮小规模实测那种踩出来的经验比任何选型文档都值钱。