MQTT是非常流行的设备的接入协议，包括IBM、亚马逊、微软的IoT托管服务都有支持，而CoAP在这方面几乎没有露面的机会。感觉以下几点是MQTT优于CoAP的主要原因：

• MQTT基于TCP，在做反控设备的时候比UDP更可靠，比如CoAP走3G、4G的时候甚至需要实现CoAP over TCP，否则反控很不稳定甚至无法联通。
• MQTT异步Pub/Sub实现，好比发个微信，无需等待对方确认便可以继续，而不像CoAP那样必须等待对方应答才能返回的同步模式。
• MQTT为物联网提供了许多体贴的设计，比如QoS，比如“遗言”的设计。

篇幅有限，无法完全枚举MQTT的优越性，建议参考以下文章：[list=1]

MQTT入门篇

MQTT进阶篇

MQTT安全篇

MQTT实战篇

当然，CoAP在功耗方面有优势，不过随着物联网设备特别是网管的计算能力加强，这点应该不是主要矛盾。

我现在认为CoAP和MQTT的协议除了考虑设备的TCP/UDP堆栈实现能力和对设备的压力之外，更加重点的考虑点是：

1. 服务器架构和开发成本？
2. 应用本身数据流向，流量，频率，持久的需求？
3. 长连接还是短连接？
4. 数据分享API的需求？

MQTT，其实就是IBM把服务器间异步通讯用的消息队列Message Queue（MQ）中间件前置到IOT接入而已。天生适合多对多（服务器对服务器，设备对服务器，设备对APP），异步，后台应用，以及即时通讯（多客户端对等）场景。不过就是约定了报文头而已。自己用Redis PubSub/MQ也可以构建。最简单的IOT架构：Device+MQTT+APP，如果不存储数据的话。需要数据持久可以是：Device+MQTT+Web/APP+DB（NoSQL/NewSQL/BigData/Lambda）+APP。 CoAP，基于UDP接口，参考HTTP上的REST API，适合数据采集这种多（设备）对一（服务器） 场景，系统架构类似于传统Web。但是CoAP UDP不是面对连接的，所以方向控制需要高层构建协议。CoAP支持多播，也可以实现一对多场景，但是好像和MQTT不一样。应该是局域网内的多播？了解的兄弟请提点一下。但总的网站架构迎来类似于传统Web：CoAP+Web+DB+APP。弱势是，数据必须流经DB转给第三方。当然，如果Web内部有MQ，可以通过REST API暴露给第三方。变成： CoAP + Web + DB + APP + Redis/MQ + REST + APP 请观察最近的BAT动向，都把MQTT作为物联网前置接入套件单列出来作为标准云服务提供。阿里云物联网套件，百度开放云物联网服务IOT，腾讯QQ物联平台，中移动OneNet开放云，Amazon IOT服务......更别提环信，野狗之类原来做IM云服务的，都将MQTT作为IM/IOT共享的接入服务了。 MQTT还有一点：长连接。采用长连接MQTT还是无连接CoAP，和应用数据属性有关。是维持大量非活动长连接消耗大，还是大量UDP包对于服务器消耗大，我一直没有得到结论。反正我从Windows发起大量UDP压测，总是报给我操作系统端口不够的一个错误。 我之前的架构是：Socket + Web + DB（Redis/SQL）+ APP，现在不得不将Redis作为沟通Socket/Web的通道，和第三方APP/Sever的通道。但用Redis PubSub构建实现起来很麻烦。而且也不是标准实现，客户实施的周期反而不如MQTT。所以准备改造成为上述MQTT协议方式。 【更新】 CoAP大体上是采用数据报方式，可以基于UDP，短消息，以及6LowPAN等传输层。而且大体上在WSN内部可以使用。不过由于CoAP也可以用于网关与云之间通讯，所以现在出现了CoAP over TCP的草案。不过，我觉得该草案受到CoAP RFC7252的约束太多，所以我和客户约定了一个版本，私底下命名为CoTCP（CoAP over TCP）。呵呵，私有的协议。但是保留了面向资源的REST风格。

物联网 ？ 就举个例子，你知道 STM32 F103 等等嵌入式设备他们的痛苦吗？他们内存低，速度也不算快，还要进行底层的功能逻辑处理。 公司为了节省成本，使用什么样的单片机，都是有可能的，很难用一套所谓的标准协议通打天下。 所以很多公司都开发自己的协议，因为适合自己的，才是最好的。 我就几条报文交互，LWIP加上TCP几条报文就搞定了，有时候，并不会选择这些略重的协议。 嵌入式的同学们已经够苦逼了，不要再为难他们了。

物联网通信标准协议 《---这个词不应该是一个正常通信专业的人说出来的。

CoAP不仅在反向控制上要求助于TCP，如果做DTLS加密连接也会存在问题。3G、4G设备通过一个NAT网关后，设备的IP、Port如果发生变化，服务器是无法处理的。除非IPv6在中国全面铺开，否则NAT是CoAP绕不过去的坎。

什么时候mqtt和coap成“物联网通信协议”还加上“标准”了，让zigbee,bluetooth,lora等情何以堪？？？

Coap无法做反向控制

我一直认为物联网的技术标准取决于通用智能机器人的操作系统，物联网真正对接的应该是各种机器人，只有通用智能机器人的技术标准有资格成为物联网的技术标准，否则谁都可以自定一套，谁也无法说服谁，一统江湖，但谁有资格成为通用智能机器人的操作系统，目前还不明朗。

现在已经有针对arduino使用的MQTT库文件了，好像，也有了OpenWRT上安装的MQTT服务器端了，我感觉，自己弄个路由器绑定一个动态域名，应该就可以当作自己家的物联网中心使用了吧。最近还有个ESP8266（自带wifi的单片机）比较火，有人做了一个esp8266 core for arduino。感觉，DIY一套智能家居好像已经很简单了… ------------------------------------------------------------------------------------------------------------------------------------------- 补充一下，现在的MQTT服务器已经很多了，百度搞了一个，我已经试用过了，很好用，阿里也在搞，还没试用。除此之外还有difiot也在搞，我也试用过，不比百度、阿里差。还有个青岛老乡elinkchina 也支持MQTT，至于CoAP，我就没听说过这是个啥…… 再补充一下，最近在学习代码，还是有一点进步的…… 2016-11-08

目前仅二者比较的话，应该是mqtt比较有优势。 只不过，这个问题本身就有点问题。这只是两种应用层协议，还远远上升不到能成为物联网通信标准的高度。