物联网中设备与服务器通信使用什么网络协议？

HTTP协议互联网中最常用的网络协议。当然还有其他协议，如收发电子邮件使用POP3、SMTP和IMAP协议，如区块链使用P2P协议。那么在物联网中设备与服务器通信使用什么协议呢？

物联网通信的特点

• 设备工作在不可靠、高延迟的网络环境

比如共享单车，使用NB-IoT通信技术，介绍常用的无线通信技术
这篇文章中介绍了NB-IoT的NB-IoT带宽180KHz，上行速率16.9Kbps，下行速率26Kbps，可见通信速率非常慢。如果单车被人停在了信号不好的地方，那么这辆车很有可能与服务器失联，这将给共享单车公司造成损失。

• 物联网系统中，设备数量多，且交互复杂

比如智能家居系统中，有灯、开关、插座、门锁、摄像头、人体感应器、声光报警器、背景音乐等，这么多设备怎么和服务器通信呢？如果每个设备都直接和服务器直接通信，那么每个设备都要编写和服务器通信的代码，且服务器要针对每个设备进行解析协议，可以想象下双方的耦合度多大啊，这样实现起来太麻烦了。

所以在智能家居中，都有一个网关设备来作为中间角色，服务器和网关通信，网关和设备通信。这样大大降低了复杂度和耦合度。

根据以上特点，我们可以首先排除HTTP协议，因为HTTP的包大，且单向同步，肯定不适合。

发布订阅模式

我们先来确定设备与服务器采用什么通信模式合适？再来分析基于这种通信模式的网络协议哪种合适。

物联网系统中最简单的功能就是查看和控制设备了，一些复杂的交互是必不可少的。

如场景（回家、离家、睡觉、起床等），对于场景的就需要涉及多个设备的联动控制。如在面板上按下回家按键，打开灯、打开窗帘、打开空调等；

再比如人体感应器，当红外传感器检测到人体靠近时，执行摄像头拍照，且同时执行声光报警器报警，然后将消息推送到用户手机上。

这些复杂的控制怎么实现呢？
答：人体靠近人体感应器，人体感应器告诉网关有人靠近，然后网关告诉摄像头和声光报警器，进行拍照和报警。

看到这个答案很容易想起一种设计模式，那就是发布订阅模式

从图中我们可以看出发布订阅模式的三种角色：发布者（Publisher）、订阅者（Subscriber）和经纪人（Broker）

发布订阅模式的流程是这样的：

1. 发布者只需告诉Broker，我要发的消息，topic是AAA；
2. 订阅者只需告诉Broker，我要订阅topic是AAA的消息；
3. 于是，当Broker收到发布者发过来消息，并且topic是AAA时，就会把消息推送给订阅了topic是AAA的订阅者。当然也有可能是订阅者自己过来拉取，看具体实现。

也就是说，发布订阅模式里，发布者和订阅者，不是松耦合，而是完全解耦的，是没有关系的。
物联网系统中如果使用这种模式，那么设备与设备之间就不会彼此影响工作。这些优势正好适合于物联网的通信特点。

MQTT

前面我们确定了设备和服务器通信模式，那么网络协议中哪些协议是用发布订阅通信模式的呢？

我们比较熟悉的MQTT协议就是采用发布订阅通信模式。
MQTT协议是为硬件性能低下的远程设备以及网络状况糟糕的情况下而设计的发布/订阅型消息协议。

MQTT(消息队列遥测传输)(英语：Message Queuing Telemetry Transport)
是ISO 标准(ISO/IEC PRF 20922)下基于发布/订阅范式的消息协议。它工作在 TCP/IP协议族上，是为硬件性能低下的远程设备以及网络状况糟糕的情况下而设计的发布/订阅型消息协议，为此，它需要一个消息中间件 。
MQTT是一个基于客户端-服务器的消息发布/订阅传输协议。MQTT协议是轻量、简单、开放和易于实现的，这些特点使它适用范围非常广泛。在很多情况下，包括受限的环境中，如：机器与机器（M2M）通信和物联网（IoT）。其在，通过卫星链路通信传感器、偶尔拨号的医疗设备、智能家居、及一些小型化设备中已广泛使用。

MQTT协议有如下特点：

• 采用二进制的消息内容编码格式
• 协议头很紧凑，协议交互简单，保证了网络传输流量小
• 支持3中Qos（Quantity of Service，服务质量）级别，便于应用根据不同场景灵活选择

Qos值得是消息传输的可靠程度。
分如下几个级别：

• Qos 0：消息只发送一次，消息可能会丢失
• Qos 1：保证消息送达，但可能会重复接受到消息
• Qos 2：通过发送方和接收方多次交互，但保证消息不会重复接受

MQTT协议的这些特点使得它非常适合计算能力有限、网路带宽低、信号不稳定的远程设备，是物联网系统的网络协议标准。

AMQP

采用发布订阅模式的协议除了MQTT，还有AMQP协议

AMQP，即Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。Erlang中的实现有RabbitMQ等。

AMQP和MQTT都是基于TCP协议，拥有一样的特性。

但是AMQP协议比较重，不适合计算资源有限、对功耗要求严苛的物联网设备，但是它可以满足后台系统对于可靠性和可扩展性的要求。
因此，它在物联网平台系统中应用广泛。
比如在分布式系统中广泛的RabbitMQ消息中间件软件，就是基于AMQP实现的。

请求响应模式

虽然物联网系统中通信适合用发布订阅模式，但是在某些场景下并不适合。
比如小区里面的智能快递柜，当你输入取件码后，服务器会向对应的柜门发送开门指令。在发布订阅模式下，服务器知道了指令发送成功了，但是它无法知道柜门是否真的打开了。
当然，你可以让服务器订阅一个“柜门开关”的主题消息，但是这样做就非常繁琐了、不够直接。

在这种场景下，请求响应模式就比较适合了。
请求响应模式很容易理解，看下图就知道了。

从上图我们可以看出请求响应模式有两个角色：客户端（Client）、服务器（Server）

HTTP

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

但是HTTP协议的报文格式非常重，光报文头就达到了KB大小，不太适合资源有限的嵌入式设备。
但是，在一些计算资源和网络资源比较充足的物联网设备上，HTTP协议仍然是一个可选项。

COAP

那么有没有跟HTTP协议类似，但是设计轻量，适合资源受限的物联网设备的协议呢？

有的，那就是 CoAP（Constrained Application Protocol）协议。

• 它同样有GET、POST、PUT、DELETE等方法和响应状态码
• 同样使用URI而不是Topic来标识资源
• 采用二进制格式
• 支持可确认消息和不可确认消息两种QoS级别
  可确认消息与MQTT协议的QoS1类似，不可确认消息与MQTT协议的QoS0类似
• 它基于的传输层协议是UDP，而不是HTTP、MQTT协议使用的TCP协议
  所以对计算资源要求更低

因为传感器设备一般只需要上传数据，不用随时接收服务器控制命令，所以COAP协议适合电池供电的传感器设备。

LwM2M

LwM2M 协议定义在 CoAP 协议之上，不过它在消息传输的基础上更进一步。因为它基于 IPSO （IP-base Smart Object）对设备模型进行了标准化，提供了一组轻量级设备管理和交互接口协议。

LwM2M 协议目前主要的实现是 C 语言的 Wakaama 和 Java 语言的 Leshan，相对来说应用还比较少。CoAP 协议的应用场景同样适合 LwM2M 协议，如果你希望在 CoAP 协议的基础上更方便地实现设备的管理，可以考虑 LwM2M 协议。

通信模式共存

很多时候我们不仅仅只用到发布订阅模式或请求响应模式，两种模式共存才能把物联网系统做好。

那么有没有这样的网络协议呢？
有的

• MQTT 5.0中增加了请求响应模式
• AMQP 1.0中也增加了请求响应模式
• COAP最新的协议初稿中也增加了发布订阅模式

怎么选择网络协议

• 物联网设备通常需要运行在网络不太可靠的环境中，而且在功耗、体积和计算资源方面也有诸多限制，所以我们在设备的开发中可以考虑使用 MQTT 和 CoAP 协议。
• 云平台各服务之间需要快速、可靠地进行消息转发，这种情况可以选择 AMQP 协议。
• 一些应用需要兼容 Web 系统的 RESTful 架构，比如通过 REST 开放物联网中的资源能力，供其他应用调用，这时 HTTP 和 CoAP 协议是合适的选择。

支持🤟

🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟

• 我会持续编写文章，保持每周至少一篇文章。💪
• 有时候编写一篇文章需要大量时间。💪
• 您只需一秒即可完成【点赞👍或关注❤️】。💪
• 您的支持将给与我更大的动力。💪

🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟🤟