物联网通信的特点

  1. 物联网设备很大可能工作在不可靠, 高延迟的网络环境

比如共享单车, 对于这种场景http就不适合, 单向同步的网络协议, 都不是理想的技术方案

  1. 物联网系统中, 设备数量多, 而且交付非常复杂

比如温度, 光照, 二氧化碳传感器, 需要不同设备.每个房间设备还不一样.
如果是让云平台做这些权限控制和数据阈值设置, 这会很麻烦. 因为数据生产者和消费者直接交互时, 要是没有中间角色基于共同目标协调, 双方的耦合粒度很大, 导致系统很难实现

如果把家作为一个整体, 那么交互就简单了很多

  1. 设备经常需要做增加和减少操作

比如原来设备测量温度的坏了, 你要换一个. 你肯定不希望这个设备ID的变化, 就要去修改判断房屋的逻辑代码.
这就需要设备具有可伸缩性(或者可扩展性), 设备增减不会导致逻辑的调整.
所以选择通信协议的时候, 一般会选择发布-订阅的通信模式

发布订阅

发布订阅包含三个角色, 分别是发布者（Publisher）、经纪人（Broker）和订阅者（Subscriber）.
image.png
他们之间的消息交互, 主要是基于主题. 主题用于消息的过滤(或者说路由), 它确定了消息的不同类别. 消息传递过程可以分为三步:

  1. 发布者负责生产数据, 发给某个主题
  2. 订阅某个或者某几个主题
  3. 当经纪人接收到某个主题的数据时, 将数据发送给这个主题的所有订阅者

为什么发布订阅适合物联网?
因为物联网场景中, 一个传感器需要触发多个服务或者终端执行动作.
比如红外传感器，当它检测到有人体靠近时，就需要触发一系列动作：通知摄像头拍照，声光报警器执行报警，推送消息给主人的手机等。怎么满足这种需求呢？我们最好让摄像头、声光报警器和手机都订阅“人体靠近”这个主题消息。当红外传感器被触发时，它发送人体靠近的消息，然后这些设备就能同时收到这个消息，接着完成系统定义的那些动作。这就是发布 - 订阅模式的工作方式.

发布订阅减少了发布者和订阅者之间的耦合度, 网络不稳定的情况下不会影响彼此工作, 也更容易扩展.
那些网络协议采用的是发布-订阅模型呢? MQTT

MQTT

它是轻量的网络通信协议

  1. 采用二进制的消息内容编码格式
  2. 协议头很紧凑, 协议交互简单, 保证网络传输流量小
  3. 支持三种QOS（Quality of Service，服务质量）级别，便于应用根据不同的场景需求灵活选择。

QoS: 通信双方关于消息传送可靠程度的协商。
QoS 0，消息只发送一次，消息可能丢失；
QoS 1 呢，发送方会接收反馈，保证消息的送达，但是可能消息会重复。
QoS 2 级别，通过发送方和接收方的多次交互，保证消息有且只有一次。

所以MQTT成为了物联网事实上的标准

AMQP

它也是发布订阅模式
虽然它有庞大的特性集, 比较重, 不适合计算资源有限, 功耗要求严格的物联网设备, 但是它可以满足后台系统对于可靠性和可扩展性的要求。因此，它在物联网的平台系统中应用广泛。比如，在分布式系统中应用广泛的 RabbitMQ 消息中间件软件，就是基于 AMQP 实现的。

和MQTT一样, 也是基于TCP, 采用二进制格式, 也支持3个QOS级别.
MQP 1.0 和 AMQP 0.9.1 这两个版本，在设计上有很大的差异。你在查询资料或者应用这两个版本的 AMQP 协议时，一定要注意看版本，避免用错。

请求-响应

但是有些场景不适合发布订阅.
比如，现在小区里面都有智能快递柜，当你输入取件码后，服务器会向对应的柜门发送开门指令。
在发布 - 订阅模式下，服务器知道指令发送成功了，但是它无法知道柜门是否真的打开了。这时，你就需要让柜门能够向服务器反馈一下命令的执行结果

当然，你也可以让服务器订阅一个“柜门关闭”的主题消息，然后等待柜门发布这个消息。但是这样的话就非常繁琐、不够直接

请求响应模式:
请求 - 响应模式是无状态的通信方式，每个完整的请求 - 响应都是相互独立的。进一步细分的话，它还可以分为同步和异步两种
image.png

http

HTTP 就是典型的代表。HTTP/2 协议还引入了异步请求 - 响应模式，客户端可以对请求设置不同的优先级，服务器可以根据优先级决定先响应哪个请求。

虽然 HTTP 协议的报文格式非常重，光是报文头就能达到 KB 大小，不太适合资源有限的嵌入式设备。但在一些计算资源和网络资源都比较充足的物联网设备上，HTTP 协议仍然是一个可选项。而且它和现有的 Web 系统兼容，可以利用已有的 Web 服务器资源。

COAP

跟 HTTP 协议类似，但是设计轻量，可以用于资源受限的物联网设备的协议

CoAP 协议同样有 GET、POST、PUT、DELETE 等方法和响应状态码，同样使用 URI 而不是 Topic 来标识资源。

例如访问服务器 iotdemo.com 下面的 bedroom/temp 这个资源

  1. coap://iotdemo.com:5683/bedroom/temp

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

另外，CoAP 协议基于的传输层协议是 UDP.

通信模式共存

有没有网络协议可以同时拥有这两种通信模式呢？
有的, MQTT 5.0 中增加了请求 - 响应模式的新特性；AMQP 1.0 版本也定义了请求 - 响应模式。而 CoAP 协议呢，在新的初稿版本（Draft）中也增加了发布 - 订阅模式特性。