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

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

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

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

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

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

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

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

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

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

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

看到这个答案很容易想起一种设计模式，那就是发布订阅模式 从图中我们可以看出发布订阅模式的三种角色：发布者（Publisher）、订阅者（Subscriber）和经纪人（Broker）

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

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

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

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

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

MQTT协议有如下特点：

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

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

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

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

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

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

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

在这种场景下，请求响应模式就比较适合了。 请求响应模式很容易理解，看下图就知道了。 从上图我们可以看出请求响应模式有两个角色：客户端（Client）、服务器（Server）

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

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

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

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

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

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

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

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

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

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

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