0 摘要
前面笔者简单谈了在实际的mqtt产品实现时，客户端和服务端分别如何实现，选择了参考文献[1]mosquitto服务端实现和[2]华为鸿蒙mqtt客户端实现，两个比较典型的项目作为例子对产品级的实现进行了解析。在实际的工程项目中，经常还需要根据应用场景，选择合适的物联网协议，那针对众多的物联网协议（MQTT/AMQP/CoAP/HTTP/LwM2M）应该如何做出选择，判断和选型的依据时什么呢？本文笔者从物联网的特点入手，提出了一些通信中需要考虑的要点，然后根据这些要点，梳理出各个协议的差异，希望对读者有一定的指导意义。
1、物联网特点
以典型的物联网场景为例，在实际的工程项目中，如何做好协议的选型。我们首先再来审视一下物联网（IOT）的通信特点，如下图所示，是笔者总结参考文献[3]学习笔记和过往工程实践经验所得。下面将详细解释为何具有这样的特点，针对这些特点在做技术和协议选择时，需要考虑哪些点。
为何具有这样的特点，我们来一一分析一下：
1）不可靠/高延迟：物联网设备的工作环境通常是复杂多样的，有些设备会被放置在偏远的地方（如共享单车、共享充电宝等），网络不稳定，频繁中断，加之设备本身的资源有限，执行性能差，势必会带来通信上的可靠性差和延迟高问题。
2）带宽有限：物联网设备的终端通常是一些小型设备，如传感器等，本身产生的数据量比较少，传输需要的带宽有限。另外这些设备通常采用蓝牙、zigbee等无线接入技术，即可满足自身小数据量的传输需求，本身不具备上网能力，需要借助网关才能联网，上传数据的频度也比较低。综合以上两点，没有必要分配较大的带宽。
3）设备种类多，交互复杂：物联网设备的终端是复杂多样的，既有大型设备（工控机器人、机械臂、无人机等）又包括各种小型器件（智能水杯、智能灯泡、智慧浇水等），产生的数据量也有大有小，采用的接入网技术和协议也是千差万别，连接的设备种类和交互的复杂度不是当前移动互联网时代所能比拟的，因此需要对众多的设备和交互方式在上云前进行归一化。
4）客户端处理能力差：物联网设备的客户端如传感器类只是采集数据，功能单一，不需要太多的计算资源，这样在成本上才具有优势。稍微复杂的设备如智能音箱等，产生和处理的数据量也是比较少的，采用mcu等处理器已经足够，并不需要动辄大几M数据的处理能力。所以这种处理能力差并不是一种缺点，而是在特定场景下，需求、资源和成本的综合考虑的产物。
5）设备经常变更：与云端设备的集中、数量少、固定场景相比，物联网设备的终端数量多、分布分散、移动性更大，在连接的末梢经常会因为设备故障或者新的需求，增加和更换终端设备，设备变更的灵活性和机动性更强。
6）百万级IOT客户端：这一点应该是显而易见的，在移动互联网时代，我们单个云端设备接入网络的设备数量不过十几万个。在万物互联时代，所有的物都上网，这个数量级势必会带来每台设备要连接的百万级客户端的剧增。亿级的设备数量势必是未来物联网的一个基本的单位。
7）低功耗，结构简单，电池供电：物联网设备的终端，如智能电表、智能水表、智能门锁、智能烟感器等，这些设备使用频率低，数据量少，在硬件构造上也比较简单，并不需要复杂的硬件器件，通信方面也可以选择诸如低功耗的蓝牙等技术，一颗纽扣电池就可以工作数年之久，能耗较低。
8）硬件上的异构性：物联网设备的数量多、种类繁多、使用场景多样化、环境复杂等特点，并没有一种统一的技术能够实现满足所有的要求，这也带来丰富多样的硬件和体系结构，这些硬件会用不同的方式产生数据，有些会在本地处理执行，有些通过不同的通信技术上网，被上送到云端，做进一步的处理，这些硬件上的异构性，需要软件方面做好屏蔽。
2、物联网通信实现要点
针对以上物联网的8个特点，笔者分别总结了每个特点在技术方面的实现要点，如下图所示。该图与上图中的每个特点是一一对应的。
1）在应对网络的不可靠和高延迟的问题上，现有的解决方案是采用双向异步通信，这样可以保证通信双方不必相互等待彼此的状态，服务端数据发送出去后，就可以去做别的事情，待处理性能较差的客户端完成后，回应相关的信息过来即可。至于如何保证消息不丢，则可以通过QOS一类的通信质量管理机制保障，对丢失的消息进行重传，对重复的消息进行剔除等。当出现断链的情况时，则通过重连机制将其链接起来。
2）在应对带宽有限的问题上，则需要使用的通信协议在设计或者选择时尽可能的简单，不需要功能就不要强行加入；发送的报文要尽可能的短小，主要是体现在报文头上的简短，这样就可以充分利用较小的带宽实现数据的快速发送。
3）物联网终端设备类型众多，通常会采用不同的接入协议，比如5G/wifi/蓝牙/光纤等等，需要在上云前，将所有的这些协议归一化，通过一种协议传输数据，因此承载和归一的协议要尽量做到通用，基于现有的基础网络架构，如tcp/ip，协议的转换方式上也要尽可能的简单，不能过于复杂。
4）物联网客户端处理能力差的特点，需要协议在计算资源上耗费尽可能的少，不能有过于复杂的协议封装和处理，在编码的格式上也要考虑简单、精减，比如文本类的编码格式在诸如传感器一类的设备上就不合适，这种场景下就要考虑二进制的编码方式。
5）终端设备的移动性和分散性对于变更的影响，需要设计更加灵活的架构方案，计算、网络和存储各类的资源要做到随时随地的可卸载，应用上做到灵活部署，在资源的标识上也要做到更加简单，这样当发生某个设备的变更时，可以快速的入网，不必有复杂的配置过程。
6）面对数量庞大的终端设备，协议连接必须要支持同步多点接入，如果是每个设备单点接入，则性能上无法满足要求；同时建链的方式也要尽可能的简单，实现快速建链。
7）物联网的场景是多种多样的，设备的供电方式也以电池供电为主，因此在协议的设计和选择上需要注意协议的耗电情况，对于功耗要求较高的协议，就不适合在低功耗一类的设备上使用，但是并不是说这类功耗较高的协议在物联网场景就无用武之地，比如后台一类的设备，对于功耗并没有太多的关注，完全可以采用功能特性更加完善的协议。
8）对于硬件上的异构性，要软件上做屏蔽，其中在通信方面最重要的一点就是要做到通用性更强，协议虽然简单但是却很强大，因此私有的协议往往不在我们做协议选择之列。
3、创建物联网协议选型
上面从8个方面针对物联网的特点提出了一些技术思路，归结起来就是根据不同的应用场景，选择和设计的物联网协议实现尽可能轻量、报文简短、耗费资源少、功耗低、有完善的通信可靠性保障机制。
当前满足这些条件或者部分满足的并不只有MQTT协议，像是AMQP协议、CoAP协议、HTTP协议和LwM2M协议，在某些物联网场景下也有广泛的应用，而且这些协议也具有上述说描述的一些优点，如AMQP也是发布/订阅的模式，CoAP也具有低功耗和二进制编码，支持电池供电的使用场景。那在实际的工程应用种如何做选择呢？笔者进一步梳理上面的8个实现要点，将这5种协议进行了3个视角（通信、资源和协议）的横向对比，列表如下，希望能够在协议选型时有所帮助。 
如上表所示，从整个的通信架构视角看，MQTT和AMQP都属于发布/订阅的消息模式，支持双向（上下行）通信，都支持异步和多对多的通信模式，连接后可以保持较长的时间，不需要每次通信都重新连接一次；CoAP、HTTP和LwM2M属于请求/响应模式，http协议只支持单向的通信，因此CoAP和LwM2M为了支持物联网场景，特地优化成支持双向通信，支持同步/异步、点对点和点对多点的通信模式，每次通信都需要重新连接一次，在实际的应用中需要根据业务需求和场景进行选择。
从资源使用的视角看，MQTT和CoAP（LwM2M）分别是两种模式下带宽资源、计算资源和功耗较少的协议，可以用在低功耗、终端结构比较简单的设备上，其他协议虽然不能用在终端，但是在服务端仍然具有很大优势。
从协议和报文视角看，MQTT和AMQP都是基于简单的topic标识资源，而其他三种协议则是基于相对复杂的URI；MQTT协议在所有协议中最为轻量，特别是报文头仅占有2个字节，通信质量的保障上也有3个QOS等级，编码格式采用二进制，更加简单；其他的协议也基于物联网的使用场景，应用在前台或者后台等特性，提供了相对轻量的报文头和编码格式等，在服务质量上也有不同的QOS等级。
参考文献：
[1]MQTT协议产品化实现-mosquitto开源产品（1）_linus_ben的博客-CSDN博客
[2]mqtt协议产品化实现-华为鸿蒙实现mqtt客户端_linus_ben的博客-CSDN博客
[3]学习笔记总结自‘物联网开发实战’–郭朝斌
文章评论