mingdu.zheng at gmail dot com
http://blog.csdn.net/zoomdy/article/details/79093176
首先，MQTT和CoAP没有好不好的问题，只有适合什么应用场景的问题。
MQTT
MQTT的特点是可以保持长连接，具有一定的实时性，云端向设备端发送消息，设备端可以在最短的时间内接收到并作出响应，所以MQTT更适合需要实时控制的场合，更适合执行器。要保持长连接，那么就要时不时地发送心跳包，这就不会省电了。所以低功耗的场合并不适合MQTT。MQTT的长连接需要建立在TCP的基础上，TCP协议的复杂性决定了对设备的要求是比较高一些的，相比UDP。
CoAP
CoAP的特点是低功耗，数据发完就可以休眠了。所以CoAP更适合数据采集的场合，更适合纯粹的传感器设备，特别是电池供电的传感器设备。基于UDP协议，对设备的要求比较简单。华为出的NB-IoT芯片就只支持UDP和CoAP，华为的决策告诉我们CoAP和NB-IoT是一对。
对比
协议 核心特点 下层协议 应用场合 硬件要求
MQTT 长连接 TCP 实时控制/执行器 较高适合服务器之类
CoAP 低功耗 UDP 数据采集/传感器 较低适合嵌入式传感器开发
IoT物联网需要标准协议，针对小设备最有前景的两种是MQTT和CoAP。
MQTT和CoAP两者均：
开放标准；
比HTTP更适合于受限环境；
提供异步传输机制；
在IP上运行；
有很多种实现
MQTT在传输模式上更为灵活，对二进制数据而言就像是管道，CoAP为面向网络的设计。
MQTT
为轻量M2M通讯设计的一种发布/订阅消息协议，起初由IBM研发，现在是一种开放标准。
架构
客户端/服务器模型，其中每一个传感器为一个客户端，通过TCP连接到服务器，也称为代理。
MQTT以消息为导向，每个消息是具体的一组数据，对代理是透明的。
每个消息发布至一个地址，称为主题，客户端也许会订阅多种主题，订阅某个主题的每一个客户端会收到所有发布到主题的消息。举个例子说明，设想一个简单的网络，有一个中间代理和三个客户端。
所有三个客户端与代理建立TCP连接，客户端B、C订阅温度主题
稍后，客户端A给温度主题发布了一个值22.5，代理转发消息给所有订阅客户端。
发布/订阅模型允许MQTT客户端以一对一、一对多和多对一方式进行通讯。
主题匹配
MQTT中，主题是层次结构的，像文件系统（例如：kitchen/oven/temperature）。当注册订阅时允许通配符，但不是发布时，允许整个层次结构被客户端观察。
通配符+匹配任意单个目录名称，#匹配任意数量任意名称目录。
例如：主题kitchen/+/temperature可以匹配kitchen/foo/temperature，但是不能匹配
kitchen/foo/bar/temperature，而kitchen/# 可以匹配 kitchen/fridge/compressor/valve1/temperature。
应用级QoS
支持三种服务质量等级：触发而遗忘、至少传送一次、仅仅传送一次。
遗愿遗嘱
MQTT客户端可以注册一个典型的遗愿遗嘱消息，如果它们断开连接，由代理发送。这些消息可以用于向订阅者发出信号，当设备断开连接时。
持久化
MQTT支持在代理上存储持久化消息，当发布消息时，客户端也许会要求代理能够持久化消息。只有最近的持久消息会被存储。当客户端订阅一个主题时，任何持久化消息会被发送至客户端。
不像消息队列，MQTT代理不允许持久化消息在服务器内部备用。
安全
MQTT代理也许会要求用户名、密码认证，为确保隐私，TCP连接也许会用SSL/TLS加密。
MQTT-SN
虽然MQTT设计为轻量的，但是对于受限设备来说，有两个缺点。
每一个MQTT客户端必须支持TCP，任何时候都要求保持连接到代理。对于丢包很严重或者计算资源稀缺的环境来说，这会是一个问题。
MQTT主题名称通常是长字符串，使得其对802.15.4不切实际。
MQTT-SN协议解决这些问题，定义MQTT UDP映射，增加代理支持主题名称索引。
CoAP
来自CoRE(受限资源环境)IETF 组的受限应用协议
架构
类似HTTP，CoAP是文本输出协议，但是不像HTTP，CoAP为受限制的设备设计。
CoAP数据包比HTTP TCP流小得多，比特域与从字符串映射到整型广泛运用以节省空间。数据包易于生成，可以原位解析，不用消耗受限制设备内的额外RAM。
CoAP运行在UDP上，而不是TCP。客户端与服务器通过无连接的数据报进行通讯，在应用栈内实现重传与重排序。无需TCP也许会使得小型微处理器全部IP网络化，CoAP允许使用UDP广播与多播用于地址。
CoAP遵循客户端/服务器模型，客户端向服务器请求，服务器回送响应，客户端可以GET、PUT、POST和DELETE资源。
CoAP用于通过简单代理与HTTP、RESTFUL网络交互。
因为CoAP基于数据报文，也许会用于SMS或者其他基于分组的通讯协议之上。
应用级QoS
请求与响应也许会被标记为可确认的或者非确认的，可确认的消息必须由接收方通过ACK包进行确认。
非确认的消息是触发而忘记的。
内容协商
像HTTP，CoAP支持内容协商，客户端使用Accept选项表达倾向的资源表示，服务器回复Content-Type选项告知客户端它们接收的东西。和HTTP一样，这允许客户端与服务器独立演进，增加新的表达方式，而互不影响。
CoAP请求也许会使用查询字符串形式如?a=b&c=d，这些可以用于给客户端提供搜索、分页与其他特性。
安全
因为CoAP建立在UDP而不是TCP之上，SSL/TLS不可用于提供安全性。DTLS数据报传输层安全提供了与TLS同样的保证机制，但是针对UDP之上数据传输。通常来说，具备DTLS能力的CoAP设备支持RSA、AES或者ECC、AES。
观察
CoAP拓展了HTTP请求模型，有能力观察资源。当观察标记在CoAP GET请求之上设定时，服务器会继续应答在初始文档已经传输过后。这使得服务器能够将状态变化发生时流向客户端。两边一方结束会取消观察。
资源发现
CoAP为资源发现定义标准机制，服务端提供资源列表（同时包括相关的元数据）在/.well-known/core。这些链接以应用/链接格式媒介形式，允许客户端发现提供什么样的资源，并且它们是什么媒介形式。
NAT问题
CoAP, 传感器节点一般是一个服务器，而不是一个客户端（虽然有可能两者都是）。传感器（或者）提供客户端可以访问的资源，或者改变传感器状态。
虽然CoAP传感器是服务器，它们必须能够接收数据包。NAT后合理运行，设备也许会先发送一个请求，像在LWM2M中做的，允许路由器关联两者。虽然CoAP不需要IPV6，在设备直接路由的IP环境内最易于使用。
对比
MQTT和CoAP作为IoT协议都很有用，但是也有重要的区别。
MQTT是多对多通讯协议用于在不同客户端之间通过中间代理传送消息，解耦生产者与消费者，通过使得客户端发布，让代理决定路由并且拷贝消息。虽然MQTT支持一些持久化，最好还是作为实时数据通讯总线。
CoAP主要是一个点对点协议，用于在客户端与服务器之间传输状态信息。虽然支持观察资源，CoAP最好适合状态传输模型，不是完全基于事件。
MQTT客户端建立长连接TCP，这通常表示没有问题，CoAP客户端与服务器都发送与接收UDP数据包，在NAT环境中，隧道或者端口转发可以用于允许CoAP，或者像LWM2M，设备也许会先初始化前端连接。
MQTT不提供支持消息打类型标记或者其他元数据帮助客户端理解，MQTT消息可用于任何目的，但是所有的客户端必须知道向上的数据格式以允许通讯，CoAP，相反地，提供内置支持内容协商与发现，允许设备相互探测以找到交换数据的方式。
两种协议各有优缺点，选择合适的取决于自己的应用