整体结构
物联网大体上有 3 个构成要素，如图 2.1 所示。一个是设备，另一个是网关，再来就是服务器。
图 2.1 物联网的整体结构
2.1.2 网关
如图 2.1 左下所示，物联网使用的设备中，有 3 台设备不能直接连接到互联网。网关就负责把这些设备转发到互联网。
网关指的是能连接多台设备，并具备直接连接到互联网的功能的机器和软件（图 2.2）。如今，市面上有很多种网关。在多数情况下，网关凭借 Linux 操作系统来运行。
图 2.2 选择网关的标准
选择网关时有几项重要的标准，我们来一起看一下。
◉ 接口
第一重要的是用于连接网关和设备的接口。网关的接口决定了能连接的设备，因此重点在于选择一个适配设备的接口。
有线连接方式包括串行通信和 USB 连接。串行通信中经常用的是一种叫作 D-SUB 9 针（pin）的连接器，而 USB 连接中用到的 USB 连接器则种类繁多。
无线连接中用的接口是蓝牙和 Wi-Fi（IEEE 802.11）。此外，还有采用 920 MHz 频段的 Zigbee 标准，以及各制造商们的专属协议。第 3 章会详细讲解这些规格各自的特征，重点在于根据设备对应的标准来选择接口。
◉ 网络接口
我们用以太网或是 Wi-Fi、3G/LTE 来连接外部网络。网络接口会影响到网关的设置场所。以太网采用有线连接，通信环境稳定。然而正因为采用的是有线连接，所以必须把 LAN 电缆布线到网关的设置场所。因此，在设置场所方面就会在某种程度上受到限制。
对 3G/LTE 连接而言，设置场所就比较自由了，但通信的质量会受信号强弱影响，所以通信不如有线连接稳定。因此，有时很难在信号不良的大楼和工厂等封闭环境中设置。不过，3G/LTE 连接有个好处，即只使用网关就能完成和外部的通信，因此操作起来很简单。此外，想使用 3G/LTE 时，需要和电信运营商签订协议并获取 SIM 卡，这点就跟使用手机一样。
网关的作用
就如我们前面说的那样，网关是一台用于把不能直接连接到互联网的设备转发连接到互联网的设备。再往细了说，网关是由 3 种功能构成的（图 2.4）。
图 2.4 网关的功能
2.1.3 服务器的结构
在功能方面，物联网服务大体上可分为 3 个部分，本书分别称它们为前端部分、处理部分，以及数据库部分（图 2.3）。
图 2.3 物联网服务的 3 个功能
首先，前端部分包括数据接收服务器和数据发送服务器。数据接收服务器接收设备和网关发来的数据，转交给后续的处理部分。数据发送服务器则刚好相反，它负责把从处理服务器接收到的内容发送给设备。
通常情况下，Web 服务的前端部分只接受 HTTP 协议。而物联网服务的前端部分则需要根据连接设备的不同来匹配 HTTP 以外的协议。使用者需要考虑到协议的实时性和通信的轻量化，以及能否以服务器为起点发送数据。我们会在 2.2 节重新讲解这些协议。
处理部分负责处理从前端部分接收到的数据。这里的“处理”指的是分解数据、存储数据、分析数据、生成发给设备的通知内容，等等。数据处理包括批处理和流处理等，批处理即把数据存入数据库之后一并进行处理，而流处理是逐次处理从前端部分收到的数据。使用者需要根据处理内容和数据特性来灵活使用这些“处理”。
最后是数据库。这里的数据库不只会用到关系数据库，还会用到 NoSQL 数据库。当然，使用者需要根据想存储的数据和想使用的方法来选择数据库。
2.3.1 HTTP 协议
HTTP 协议提供的是最大众化且最简易的方法。使用一般的 Web 框架就可以制作数据接收服务器。设备用 HTTP 的 GET 方法和 POST 方法访问服务器，把数据存入请求参数和 BODY 并发送（图 2.6）。
图 2.6 通过 HTTP 协议发送和接收数据
HTTP 协议是 Web 的标准协议，这一点自不用说。因此 HTTP 协议和 Web 的兼容性非常强。此外，因为 HTTP 协议有非常多的技术诀窍，所以我们必须在制作实际系统时审视服务器的结构，应用程序的架构以及安全性等。关于这点，有很多事例值得参考。另外，HTTP 协议还准备了 OSS 的框架，方便人们使用。
2.3.3 WebSocket
WebSocket 是一种通信协议，用于在互联网上实现套接字通信。它实现了 Web 浏览器和 Web 服务器间的数据双向连续传输。
就 HTTP 协议而言，每次发送数据都必须生成发送数据用的通信路径及连接。此外，一般情况下，客户端没有发出申请就不能进行通信。
相对而言，WebSocket 就不同了。只要一开始根据客户端发出的连接申请确立了连接，就能持续用同一个连接传输数据。另外，只要确立了连接，就算客户端没有发出申请，服务器也能给客户端发送数据（图 2.7）。
图 2.7 通过 WebSocket 协议传输数据
这样一来，在发送语音数据等连续的数据，以及发生与服务器的相互交换时，就能使用 WebSocket 了。WebSocket 自身只提供服务器与客户端的数据交换，因此需要使用者另外决定在应用层上使用的协议。
2.3.4 MQTT
MQTT（MQ Telemetry Transport，消息队列遥测传输）是近年来出现的一种新型协议，物联网领域会将其作为标准协议。MQTT 原本是 IBM 公司开发的协议，现在则开源了，被人们不断开发着。
MQTT 是一种能实现一对多通信（人们称之为发布或订阅型）的协议。它由 3 种功能构成，分别是中介（broker）、发布者（publisher）和订阅者（subscriber）（图 2.8）。
图 2.8 通过 MQTT 传输消息
◉ QoS
QoS 是 Quality of Service（服务质量）的简称。这个词在网络领域表示的是通信线路的品质保证。MQTT 里存在 3 个等级的 QoS。“发布者和中介之间”以及“中介和订阅者之间”都分别定义了不同的 QoS 等级，以异步的方式运行。此外，当“中介与订阅者之间”指定的 QoS 小于“发布者和中介之间”交换的 QoS 时，“中介与订阅者之间”的 QoS 会被降级到指定的 QoS。QoS 0 指的是最多发送一次消息（at most once）（图 2.11），发送要遵循 TCP/IP 通信的“尽力服务”。消息分两种情况，即到达了一次中介处，或没有到达中介处。
图 2.11 QoS 0（最多只能发送一次）
接下来的 QoS 1 是至少发送一次消息（at least once）（图 2.12）。
图 2.12 QoS 1（至少发送一次消息）
中介一接收到消息就会向发布者发送一个叫作“PUBACK 消息”的响应，除此之外还会根据订阅者指定的 QoS 发送消息。当发生故障，或经过一定时间后仍没能确认 PUBACK 消息时，发布者会重新发送消息。如果中介接收了发布者发来的消息却没有返回 PUBACK，那么中介会重复收到消息。
最后是 QoS 2，它指的是准确发送一次消息（exactly once）。把它跟 QoS 1 合在一起使用，就能避免接收到重复的消息（图 2.13）。用 QoS 2 发送的消息里面含有消息 ID。中介收到消息后会将消息保存，然后给发布者发送 PUBREC 消息。发布者再给中介发送 PUBREL 消息，然后中介会给发布者发送 PUBCOMP 消息。接下来中介才会依据订阅者指定的 QoS，向订阅者传递接收到的消息。
图 2.13 QoS 2（只发送一次消息）
此外，就 QoS 2 而言，有时使用的中介会影响消息的传递时间。
人们通常使用的是 QoS 0，只有要确保信息发送成功时才使用 QoS 1 和 QoS 2，这样一来可以减少网络的负担。后文将会讲到 Clean session，其中 QoS 的设定也是非常重要的。
◉ Retain
订阅者只能接收在订阅之后发布的消息，但如果发布者事先发布了带有 Retain 标志的消息，那么订阅者就能在订阅后马上收到消息。
当发布者发布了带有 Retain 标志的消息时，中介会把消息传递给订阅了主题的订阅者，同时保存带有 Retain 标志的最新的消息。此时，若别的订阅者订阅了主题，就能马上收到带有 Retain 标志的新消息（图 2.14）。
图 2.14 Retain
◉ Will
Will 有“遗言”的意思。由于中介的 I/O 错误或网络故障等情况，发布者可能会突然从中介断开，Will 就是专门针对于这种情况的一个机构，它用于定义中介向订阅者发送的消息（图 2.15）。
图 2.15 Will
发布者在连接中介时会用到 CONNECT（连接）消息，连接时对其指定 Will 标志、要发送的消息以及 QoS。这样一来，如果连接意外断开，Will 消息就会被传递给订阅者。另外，还有一个标志叫作 Will Retain。通过指定这个标志，就能跟前面说的 Retain 达到同样的效果，即在中介处保存消息。
当发布者使用 DISCONNECT（断开连接）消息明确表明连接已断开时，Will 消息就不会被发送给订阅者。
◉ Clean session
Clean session 用于指定中介是否保留了订阅者的已订阅状态。用 CONNECT 消息连接时，订阅者把 Clean session 标志设定为 0 或 1。0 是保留 session，1 是不保留 session。
若指定 Clean session 为 0 且中介已经连接上了订阅者，则中介需要在订阅者断开连接后保留订阅的消息。另外，如果订阅者的连接已经断开，且发布者已经发布了 QoS 1、QoS 2 的消息给已订阅的主题时，中介则会把消息保存，等订阅者再次连接时发送给订阅者（图 2.16）。
图 2.16 Clean session
若指定 Clean session 为 1 并连接，中介就会废弃以往保留的客户端信息，将其当成一次“干净”的连接来看待。此外，订阅者断开连接时，中介也会废弃所有的信息。
我们可以用表 2.1 所示的几种产品来实现 MQTT。是否支持前文介绍的功能则取决于中介的种类。
表 2.1 MQTT 的实现
除此之外，一个叫作 Paho 的库还公开了发布者和订阅者等客户端功能。不仅 Java、JavaScript、Python 配备了 Paho，连 C 语言和 C++ 都配备了 Paho。因此，我们能够将其与设备结合起来并加以使用。
数据格式
前面我们围绕用于接收数据的通信过程，即协议进行了讲解。事实上，数据就是通过协议来进行交换的。当然，就如我们前文所说，这条规则在物联网的世界里也是不变的。数据要经过协议进行交换，而数据的格式也很重要。通过 Web 协议来使用的数据格式中，具有代表性的包括 XML 和 JSON（图 2.17）。
数据处理
很显然，处理服务器就是处理接收到的数据的地方。“处理”是一个抽象的词语，例如保存数据，以及转换数据以使其看上去更易懂，还有从多台传感器的数据中发现新的数据，这些都是处理。使用者的目的不同，处理服务器的内容也各异。不过说到数据的处理方法，它可以归纳成以下 4 种：数据分析、数据加工、数据保存以及向设备发出指令（图 2.20）。
图 2.20 数据的处理
关于数据的分析和加工，有两种典型的处理方式，分别叫作“批处理”和“流处理”。首先就来说说这个“批处理”和“流处理”。
批处理
◉ Apache Hadoop
Apache Hadoop 是一个对大规模数据进行分布式处理的开源框架。Hadoop 有一种叫作 MapReduce 的机制，用来高效处理数据。MapReduce 是一种专门用于在分布式环境下高效处理数据的机制，它基本由 Map、Shuffle、Reduce 这 3 种处理构成（图 2.21）。
图 2.21 通过 Hadoop MapReduce 执行批处理
◉ Apache Spark
Apache Spark 也和 Hadoop 一样，是一个分布式处理大规模数据的开源框架。Spark 用一种叫作 RDD（Resilient Distributed Dataset，弹性分布数据集）的数据结构来处理数据（图 2.22）。
图 2.22 通过 Spark 执行批处理
流处理
批处理是把数据攒起来，一次性进行处理的方法。相对而言，流处理是不保存数据，按照到达处理服务器的顺序对数据依次进行处理。
想实时对数据做出反应时，流处理是一个很有效的处理方法。因为批处理是把数据积攒之后隔一段时间进行处理，所以从数据到达之后到处理完毕为止，会出现时间延迟。因此，流处理这种把到达的数据逐次进行处理的思路就变得很重要了。此外，流处理基本上是不会保存数据的。只要是被使用过的数据，如果没必要保存，就会直接丢弃。
◉ Spark Streaming
Spark Streaming 是作为 Apache Spark（在“批处理”部分介绍过）的库被公开的。通过 Spark Streaming，就能够把 Apache Spark 拿到流处理中来使用（图 2.23）。
图 2.23 通过 Spark Streaming 执行流处理
◉ Apache Storm
Apache Storm 是用于实现流处理的框架，结构如图 2.24 所示。
本文思维导图概览
物联网的基本架构包括三个层面：感知层、网络层和应用层。
物联网架构图
物联网架构图
感知层通过传感器采集某些数据(声、光、电等)，基于网络层的终端模组，对接到网络层的基站，实现数据采集后的传输。
网络层负责将感知层采集的数据进行回传，基于不同特点采用不同的通信协议技术进行回传至关重要，这也是本文重点所讨论的内容。
应用层可以理解为物联网的数据平台和业务平台。数据平台作为所有物联网终端数据的集合点，负责数据的统一存储、分析等，北向通过标准的API接口提供给业务平台做数据调用;业务平台基于数据平台的原始数据实现各种业务逻辑，对外呈现的是服务。
其中，聚焦于网络层的通信协议，则是群雄逐鹿，百家争鸣。
当下最流行的Wi-Fi技术数据传输速度飞快，尤其802.11ax技术即将诞生，理论上8条流不是梦。然而伴随速度的提升，耗电量急剧增大，且传输距离也成为难题，长距离传输需要每隔一定距离放一个AP进行桥接，这必将大幅提升成本。因此，Wi-Fi技术更适合供PC及PDA等终端应用的室内无线上网场景。
蓝牙技术与Wi-Fi在2.4G频段上有交接，所以同频段会有一些干扰问题的产生。蓝牙的耗电情况比Wi-Fi稍微低一些， 而传输速度远不及Wi-Fi。在资产追踪、定位标签以及医疗传感器等场景下应用较多，如智能手表，蓝牙定位等。
Zigbee技术的功耗比较小，通信距离也比较短，是一种短距离低功耗的技术，主要应用于无线传感器及医疗场景等。
UWB超宽带技术频段较为干净，没有其他频段的干扰，在高精度定位的场景下应用更多。
通信协议对比
以上技术更适合近距离场景的数据传输，那么在远距离场景下又有哪些技术呢?
运营商提供的4G网络，是人们生活中应用最多的，甚至超过Wi-Fi。它可以做到长距离传输，无论在室内还是室外，速度都很可观。这种技术看起来很优越，但其功耗较大，只能应用于终端可自取电的物联网场景，如某公司的共享单车，利用太阳能电池板进行取电。
在远距离场景下，如果终端不能解决供电问题，那么需要一种具有更低功耗，覆盖范围更大的技术来满足这个场景下的物联网通信需求。于是在业务和技术的驱动下，一些专家和企业为了解决这个问题，研究出一种新型的通信技术——LPWAN，即低功耗广域网技术。
LPWAN的目标是为物联网应用中的M2M(设备到设备)通信场景而优化的远距离无线网络通讯技术。LPWAN技术的优势主要体现在：低速率、超低功耗、长距离、低吞吐、强覆盖。这些特点恰好说明，此项技术正是针对物联网在长距离传输的场景下开发的。具体应用如：城区覆盖、远程抄表、井盖检测以及近海渔船检测等。
LPWAN技术特点
LPWAN作为一个新的技术阵营，其内部分为两大派系：授权频段和非授权频段。授权频段又分为EC-GSM、eMTC以及NB-IoT;而非授权频段的“头牌”则是LoRa。
EC-GSM
随着LPWAN的兴起，传统的GRPS应用于物联网的劣势愈发明显。2014年，3GPP研究项目提出，将窄带(200kHz)物联网技术迁移到GSM上，寻求比传统GPRS高20dB的更广的覆盖范围，并提出五大目标：提升室内覆盖性能、支持大规模设备连接、减小设备复杂性、减小功耗和时延。到了2015年，TSG GERAN #67会议报告表示，EC-GSM已满足5大目标。但随着R13 NB-IoT标准冻结之后，人们将更多精力投入到了重新定义的标准当中。
eMTC
eMTC的概念在R13中被正式命名，以前的R12被称为Low-Cost MTC，它是基于LTE演进的物联网技术。eMTC基于蜂窝网进行部署，用户设备通过支持1.4MHz的射频和基带带宽，可直接接入现有的LTE网络。eMTC的关键能力在于速率高(相较于GPRS、zigbee等)、可移动、可定位以及支持语音。。
NB-IoT
最近特别火热的NB-IoT其实是NB-CIoT和NB-LTE两者的融合。NB-CIoT提出了全新的空口技术，较传统LTE网络改动较大，他满足于TSG GERAN#67会议上提出的五大目标，其亮点在于通信模块成本低于GSM及NB-LTE的模块。而NB-LTE则与现有的LTE兼容，特点是利于部署。在激烈的争论后，终于对两者加以融合，形成了NB-IoT的技术标准。
NB-IoT全称为窄带物联网，可以直接部署于LTE网络，良好的兼容性降低了部署的成本。其本身具有更低的功耗，理论上估算，承载NB-IoT的终端模组基于电池的待机时间可达10年之久。模块成本的降低，也让市场更多的公司开始应用这项技术，风靡全国的共享单车就是其一。某公司第三代的智能锁就采用了NB-IoT的模组，一方面是运营商的大力推广，另一方面也确实带来了价值。
LoRa
与NB-IoT齐头并进发展的就是LoRa，与之不同的是LoRa技术使用非授权频段。它是由Semtech公司采用和推广的一种基于扩频技术的超远距离无线传输技术。LoRa全称是Long Range，顾名思义，LoRa可以支持长距离传输。在中国，LoRa可以使用的频段有两个：CN779-787以及CN470-CN510。由于CN779-787最大发射功率只有10dBm(10mW)，并没有“实用”的价值。所以人们更青睐于CN470-CN510这个频段，它的最大发射功率可以达到17dBm(50mW)。
类比于Wi-Fi联盟，LoRa也有对应的LoRa联盟，旨为共同建立标准和规范，LoRaWAN就是这样的产物。
LoRa与NB-IoT对比
基于成本的考虑，LoRa的模组单价在8-10美元左右，而且非授权频段也不需要支付额外的频谱成本，相比于NB-IoT而言，成本方面具有较大优势。在电池性能方面，由于NB-IoT在蜂窝授权频谱上工作，所以需要定时进行网络同步，会消耗相应的电量，而LoRa则无此担忧，但NB-IoT的这个特性也受到共享单车的热烈欢迎，可以基于此来做车辆的实时定位工作。另外，从商业模式上来看，NB-IoT属于运营商建网，业务方不需要自己来考虑基站的部署，比较省心;但与此同时，网络的质量、安全都是不可控的风险，且企业自身的增值也会受到一定阻碍。反观LoRa，属于企业自建网络，基站需自己部署，后续需自己运维、优化等，覆盖的点位、网络质量及安全等维度都要自己负责。
截止目前，没有哪个物联网技术能够成为真正的主流，对技术本身而言，没有绝对的完美;从业务出发，更是需要结合业务特点、商业模式去选择更适合的物联网技术。
物联网技术的发展伴随各方“豪杰”群雄逐鹿，未来会不会三足鼎立或由新的势力一统天下，让我们拭目以待。
以上是关于物联网中-物联网通信协议纷争：群雄逐鹿 百家争鸣的相关介绍，如果想要了解更多相关信息，请多多关注eeworld，eeworld电子工程将给大家提供更全、更详细、更新的资讯信息。