物联网相关协议MQTT，AMQP，Modbus，CoAp

因为最近项目涉及到与外部设备交互，所以有必要了解一下目前市面上的物联网相关协议。

一、MQTT

MQTT（Message Queuing Telemetry Transport）消息队列遥测传输，是一种发布/订阅（Publish/Subscribe）模式的轻量级、可扩展的物联网传输协议。

MQTT是基于二进制消息的发布/订阅编程模式的消息协议，最早由IBM提出的，如今已经成为OASIS规范。由于规范很简单，非常适合需要低功耗和网络带宽有限的IoT场景，比如：遥感数据，汽车，智能家居，智慧城市，医疗医护等。

 MQTT它有三个主要特点。

1.采用二进制的消息内容编码格式，所有二进制数据、JSON 和图片等负载内容都可以方便传输。

2.协议头很紧凑，协议交互也简单，保证了网络传输流量很小。
3.支持 3 种 QoS（Quality of Service，服务质量）级别，便于应用根据不同的场景需求灵活选择。

这三个特点，让 MQTT 协议非常适合计算能力有限、网络带宽低、信号不稳定的远程设备，所以它成为了物联网系统事实上的网络协议标准。

所以MQTT遵循以下设计原则：

1. 精简，不添加可有可无的功能。
2. 发布/订阅（Pub/Sub）模式，方便消息在传感器之间传递。
3. 允许用户动态创建主题，零运维成本。
4. 把传输量降到最低以提高传输效率。
5. 把低带宽、高延迟、不稳定的网络等因素考虑在内。
6. 支持连续的会话控制。
7. 理解客户端计算能力可能很低。
8. 提供服务质量管理。
9. 假设数据不可知，不强求传输数据的类型与格式，保持灵活性。

运用MQTT协议，设备可以很方便地连接到物联网云服务，管理设备并处理数据，最后应用到各种业务场景。

发布/订阅模式

与请求/回答这种同步模式不同，发布/定义模式解耦了发布消息的客户（发布者）与订阅消息的客户（订阅者）之间的关系，这意味着发布者和订阅者之间并不需要直接建立联系。打个比方，你打电话给朋友，一直要等到朋友接电话了才能够开始交流，是一个典型的同步请求/回答的场景；而给一个好友邮件列表发电子邮件就不一样，你发好电子邮件该干嘛干嘛，好友们到有空了去查看邮件就是了，是一个典型的异步发布/订阅的场景。它带来了这些好处：

• 发布者与订阅者不比了解彼此，只要认识同一个消息代理即可。
• 发布者和订阅者不需要交互，发布者无需等待订阅者确认而导致锁定。
• 发布者和订阅者不需要同时在线，可以自由选择时间来消费消息。

 服务质量

为了满足不同的场景，MQTT支持三种不同级别的服务质量（Quality of Service，QoS）为不同场景提供消息可靠性：

• 级别0：尽力而为。消息发送者会想尽办法发送消息，但是遇到意外并不会重试。
• 级别1：至少一次。消息接收者如果没有知会或者知会本身丢失，消息发送者会再次发送以保证消息接收者至少会收到一次，当然可能造成重复消息。
• 级别2：恰好一次。保证这种语义肯待会减少并发或者增加延时，不过丢失或者重复消息是不可接受的时候，级别2是最合适的。

服务质量是个老话题了。级别2所提供的不重不丢很多情况下是最理想的，不过往返多次的确认一定对并发和延迟带来影响。级别1提供的至少一次语义在日志处理这种场景下是完全OK的，所以像Kafka这类的系统利用这一特点减少确认从而大大提高了并发。级别0适合鸡肋数据场景，食之无味弃之可惜，就这么着吧。

消息类型

MQTT拥有14种不同的消息类型：

1. CONNECT：客户端连接到MQTT代理
2. CONNACK：连接确认
3. PUBLISH：新发布消息
4. PUBACK：新发布消息确认，是QoS 1给PUBLISH消息的回复
5. PUBREC：QoS 2消息流的第一部分，表示消息发布已记录
6. PUBREL：QoS 2消息流的第二部分，表示消息发布已释放
7. PUBCOMP：QoS 2消息流的第三部分，表示消息发布完成
8. SUBSCRIBE：客户端订阅某个主题
9. SUBACK：对于SUBSCRIBE消息的确认
10. UNSUBSCRIBE：客户端终止订阅的消息
11. UNSUBACK：对于UNSUBSCRIBE消息的确认
12. PINGREQ：心跳
13. PINGRESP：确认心跳
14. DISCONNECT：客户端终止连接前优雅地通知MQTT代理

 二、AMQP

除了 MQTT 协议外，还有其他采用发布 - 订阅模式的网络协议，比如 AMQP 协议。AMQP的全称为：Advanced Message Queuing Protocol（高级消息队列协议）

虽然 AMQP 协议拥有庞大的特性集，比较重，不适合计算资源有限、对功耗要求严苛的物联网设备，但是它可以满足后台系统对于可靠性和可扩展性的要求。因此，它在物联网的平台系统中应用广泛。

MQTT的发布 - 订阅模式的很多好处，但是凡事都有例外，也有一些物联网应用场景，并不适合使用这种模式。比如，现在小区里面都有智能快递柜，当你输入取件码后，服务器会向对应的柜门发送开门指令。在发布 - 订阅模式下，服务器知道指令发送成功了，但是它无法知道柜门是否真的打开了。这时，你就需要让柜门能够向服务器反馈一下命令的执行结果。当然，你也可以让服务器订阅一个“柜门关闭”的主题消息，然后等待柜门发布这个消息。但是这样的话就非常繁琐、不够直接。在这种场景下，另一种通信模式就能派上用场了，那就是请求 - 响应模式。

请求 - 响应模式有两个角色，一个是客户端，另一个是服务器。
客户端是请求数据或者服务的一方。服务器则用来接收客户端的请求，并提供相应的数据或者服务。服务器在收到请求后，会获取数据，对资源数据（比如数据库）进行加工处理，准备好响应，然后返回给客户端。
请求 - 响应模式是无状态的通信方式，每个完整的请求 - 响应都是相互独立的。进一步细分的话，它还可以分为同步和异步两种。

三、Modbus

什么是Modbus？

Modbus是MODICON公司最先倡导的一种软的通讯规约，经过大多数公司 的实际应用，逐渐被认可，成为一种标准的通讯规约，只要按照这种规约进行数据通讯或传输，不同的系统就可以通讯。目前，在RS232/RS485通讯过程中，更是广泛采用这种规约。    常用的Modbus通讯规约有两种，一种是ModbusASCII，一种是Modbus RTU。
 一般来说，通讯数据量少而且主要是文本的通讯则采用Modbus ASCII规约，通讯数据数据量大而且是二进制数值时，多采用Modbus RTU规约。

在实际的应用过程中，为了解决某一个特殊问题，人们喜欢自己修改Modbus规约来满足自己的需要（事实上，人们经常使用自己定义的规约来通讯，这样能解决问题，但不太规范）。更为普通的用法是，少量修改规约，但将规约格式附在软件说明书一起，或直接放在帮助中，这样就方便了用户的通讯。Modbus-TCP主要应用于基于以太网TCP/IP通信的控制网络中。

 

通过此协议，控制器相互之间、或控制器经由网络(如以太网)可以和其它设备之间进行通信。Modbus协议使用的是主从通讯技术，即由主设备主动查询和操作从设备。一般将主控设备方所使用的协议称为Modbus Master，从设备方使用的协议称为Modbus Slave。典型的主设备包括工控机和工业控制器等;典型的从设备如PLC可编程控制器等。Modbus通讯物理接口可以选用串口(包括RS232和RS485)，也可以选择以太网口。其通信遵循以下的过程：

 

●　主设备向从设备发送请求

 

●　从设备分析并处理主设备的请求，然后向主设备发送结果

 

●　如果出现任何差错，从设备将返回一个异常功能码

Modbus协议具有以下几个特点：

(1)标准、开放，用户可以免费、放心地使用Modbus协议，不需要交纳许可证费，也不会侵犯知识产权。

(2)Modbus可以支持多种电气接口，如RS-232、RS-485等，还可以在各种介质上传送，如双绞线、光纤、无线等。

(3)Modbus的帧格式简单、紧凑，通俗易懂。用户使用容易，厂商开发简单。

 

四、CoAp

CoAP（Constrained Application Protocol）约束应用协议。跟 HTTP 协议类似，但是设计轻量，可以用于资源受限的物联网设备的协议。跟 HTTP 协议一样，CoAP 协议同样有 GET、POST、PUT、DELETE 等方法和响应状态码，同样使用 URI 而不是 Topic 来标识资源。比如我们需要访问服务器 test.com 下面的 abc/temp 这个资源，那完整的资源地址是：test.com/abc/temp。

CoAP 的消息采用二进制格式，支持可确认消息和不可确认消息两种 QoS 级别。可确认消息（Confirmable Message）与 MQTT 协议的 QoS 1 类似，不可确认消息（Non-confirmable Message）对应 MQTT 协议的 QoS 0 级别。

另外，CoAP 协议基于的传输层协议是 UDP，而不是 HTTP 、 MQTT 协议的 TCP 协议，所以对于设备的计算资源要求更低。传感器设备一般只需要上传数据，不用随时接收服务器的控制命令，这都说明 CoAP 协议适合电池供电的传感器设备。