物联网常用的网络协议：MQTT、AMQP、HTTP、CoAP、LwM2M

物联网设备间沟通的语言，就是网络协议。
设备间想相互交流，通信双方必须使用同一种“语言”。比如说你和中国人问好说’你好‘、日本人问好要说‘こんにちは’、和英国人问好要说‘hello’.
说起网络协议，你可能马上就想到了 HTTP 协议。是的，在日常的 Web 开发中，我们总是需要跟它打交道，因为 HTTP 协议是互联网的主流网络协议。类似地，应用在互联网中的网络协议，还有收发电子邮件的 POP3 、SMTP 和 IMAP 协议，以及用于区块链中的 P2P 协议。

具体需要用什么协议我们需要根据物联网的特点来做决定物联网的网络通信特点是物联网设备很大可能工作在不可靠、高延迟的网络环境中。
比如共享单车，使用 NB-IoT 这样的通信技术，本身的通信速率就只有不到几十 Kbps；要是被人停在城市的角落里，信号可能很不稳定。假设你使用 HTTP 协议，就需要单车先发出连接请求，然后等待服务器的响应（下发开锁指令）。这样一来，受网络通信质量的影响，很可能连接经常中断，而需要单车与服务器交互多次，那用户可能就要等很长时间。对于这种场景来说，不只是 HTTP，其他跟 HTTP 一样单向的、同步的网络协议，都不是理想的技术方案。

物联网系统中，设备数量多，而且交互非常复杂。比如家里的环境监测，温度、湿度、光照、二氧化碳、甲醛含量……这些都需要不同的设备测量，而且每个房间用到的设备也不同。如果让云平台的服务对每个设备分别做权限控制和数据阈值设置，这会非常麻烦。因为当数据的“生产者”和“消费者”直接交互时，要是没有中间角色基于共同的目标协调，双方的耦合度会很大，导致系统很难实现。这时候，需要把家为一个整体来处理，交互逻辑就会变得简单多了。设备经常需要根据实际使用环境做增加、减少等调整。

正是因为这些特点，物联网系统在选择网络通信的协议时，一般采用

发布 - 订阅模式

发布 - 订阅模式包含三个角色，分别是发布者、经纪人和订阅者，它们的关系如下图所示。

消息传递的过程可以分为三步：
1.发布者负责生产数据。发布者发送某个主题的数据给经纪人，发布者不知道订阅者。
2.订阅经纪人管理的某个或者某几个主题。
3.当经纪人接收到某个主题的数据时，将数据发送给这个主题的所有订阅者。

比如说当使用美团外卖点一分午餐，这时候发布订单给外卖订单中心服务器时，外卖订单中心收到订单之后，再把订单发送给店家

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

那么，具体有什么网络协议采用的是发布 - 订阅通信模式呢？MQTT 协议就是其中的佼佼者。

MQTT

MQTT它有三个主要特点：

1.采用二进制的消息内容编码格式，所以二进制数据、JSON 和图片等负载内容都可以方便传输。
2.协议头很紧凑，协议交互也简单，保证了网络传输流量很小。
3.支持 3 种 QoS（Quality of Service，服务质量）级别，便于应用根据不同的场景需求灵活选择。

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

AMQP

除了 MQTT 协议外，还有其他采用发布 - 订阅模式的网络协议，比如 AMQP 协议。
虽然 AMQP 协议拥有庞大的特性集，比较重，不适合计算资源有限、对功耗要求严苛的物联网设备，但是它可以满足后台系统对于可靠性和可扩展性的要求。因此，它在物联网的平台系统中应用广泛。

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

请求 - 响应模式。

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

HTTP

HTTP 就是请求 - 响应模式的的代表。HTTP/2 协议还引入了异步请求 - 响应模式，客户端可以对请求设置不同的优先级，服务器可以根据优先级决定先响应哪个请求。
虽然 HTTP 协议的报文格式非常重，光是报文头就能达到 KB 大小，不太适合资源有限的嵌入式设备。但在一些计算资源和网络资源都比较充足的物联网设备上，HTTP 协议仍然是一个可选项。而且它和现有的 Web 系统兼容，可以利用已有的 Web 服务器资源。

CoAP

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

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

CoAP 的消息采用二进制格式，支持可确认消息和不可确认消息两种 QoS 级别。可确认消息（Confirmable Message）与 MQTT 协议的 QoS 1 类似，不可确认消息（Non-confirmable Message）对应 MQTT 协议的 QoS 0 级别。
另外，CoAP 协议基于的传输层协议是 UDP，而不是 HTTP 、 MQTT 协议的 TCP 协议，所以对于设备的计算资源要求更低。传感器设备一般只需要上传数据，不用随时接收服务器的控制命令，这都说明 CoAP 协议适合电池供电的传感器设备。
LwM2M
说完 CoAP，我再介绍一下跟它有关

LwM2M

LwM2M 协议定义在 CoAP 协议之上，不过它在消息传输的基础上更进一步。因为它基于 IPSO （IP-base Smart Object）对设备模型进行了标准化，提供了一组轻量级设备管理和交互接口协议。
LwM2M 协议目前主要的实现是 C 语言的 Wakaama 和 Java 语言的 Leshan，相对来说应用还比较少。CoAP 协议的应用场景同样适合 LwM2M 协议，如果你希望在 CoAP 协议的基础上更方便地实现设备的管理，可以考虑 LwM2M 协议。
通信模式的共存

学习笔记总结自‘物联网开发实战’–郭朝斌
–笔记只用于学习交流，请不要用于商业用途。