2.3 接收数据
2.3.1 数据接收服务器的作用
数据接收服务器就跟它的字面意思一样，负责接收从设备发送来的数据。它在设备和系统之间起着桥梁作用。有很多种方法可以从设备把数据发送给服务器，其中具有代表性的包括以下两种方法。
● 准备一个使用了HTTP协议的Web API来访问设备（如通常的Web系统）
● 执行语音和视频的实时通信（如WebSocket和WebRTC）
除此之外，还出现了一种名为MQTT的、专门针对物联网的新型通信协议。
本章将为大家介绍HTTP协议、WebSocket、MQTT这几个典型协议。
2.3.2 HTTP协议
HTTP协议提供的是最大众化且最简易的方法。使用一般的Web框架就可以制作数据接收服务器。设备用HTTP的GET方法和POST方法访问服务器，把数据存入请求参数和BODY并发送（图2.6）。
HTTP协议是Web的标准协议，这一点自不用说。因此HTTP协议和Web的兼容性非常强。此外，因为HTTP协议有非常多的技术诀窍，所以我们必须在制作实际系统时审视服务器的结构，应用程序的架构以及安全性等。关于这点，有很多事例值得参考。另外，HTTP协议还准备了OSS的框架，方便人们使用。
图2.6 通过HTTP协议发送和接收数据
COLUMN REST API
设备应该如何访问物联网服务呢？用HTTP协议访问的时候，也得从GET和POST中选择一种合适的方法来访问。除了物联网服务，一般Web服务中公开的API也应格外重视这个问题。
在Web服务的世界里，有一种思路叫作RESTful。REST是一种接口，它为特定的URL指定参数并执行访问，作为其响应来获取结果。它通过用多个HTTP方法访问一个URL，来对一个URL执行获取和注册数据。这样一来，URL的作用就易于理解了。
例如，使用GET方法访问/sensor/temperature就能获取温度传感器的值。使用POST方法一并访问传感器数据，就会追加新的传感器数据。
如果想用除了RESTful以外的方法实现同样的功能，就需要生成用于获取以往数据的URL和追加数据的URL，并决定其分别用GET方法访问还是用POST方法访问。RESTful的思路保证了URL设计的简单性，请大家务必审视一下RESTful的思路。
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传输消息
中介承担着转发MQTT通信的服务器的作用。相对而言，发布者和订阅者则起着客户端的作用。发布者是负责发送消息的客户端，而订阅者是负责接收消息的客户端。MQTT交换的消息都附带“主题”地址，各个客户端把这个“主题”视为收信地址，对其执行传输消息的操作。形象地比喻一下，中介就是接收邮件的邮箱。
再来详细看一下MQTT通信的机制（图2.9）。首先，中介在等待各个客户端对其进行连接。订阅者连接中介，把自己想订阅的主题名称告诉中介。这就叫作订阅。
图2.9 MQTT通信的机制
然后发布者连接中介，以主题为收信地址发送消息。这就是发布。
发布者一发布主题，中介就会把消息传递给订阅了该主题的订阅者。如图2.9所示，如果订阅者订阅了主题A，那么只有在发布者发布了主题A的情况下，中介才会把消息传递给订阅者。订阅者和中介总是处于连接状态，而发布者则只需在发布时建立连接，不过要在短期内数次发布时，就需要保持连接状态了。因为中介起着转发消息的作用，所以各个客户端彼此之间没有必要知道对方的IP地址等网络上的收信地址。
又因为多个客户端可以订阅同一个主题，所以发布者和订阅者是一对多的关系。在设备和服务器的通信中，设备相当于发布者，服务器则相当于订阅者。
主题采用的是分层结构。用“#”和“+”这样的符号能指定多个主题。如图2.10所示，/Sensor/temperature/#中使用了“#”符号，这样就能指定所有开头为/Sensor/temperature/的主题。此外，/Sensor/+/room1中使用了符号“+”，这样一来就能指定所有开头是/Sensor/、结尾是/room1的主题。
图2.10 MQTT的主题示例
像这样借助于中介的发布/订阅型通信，MQTT就能实现物联网服务与多台设备之间的通信。另外，MQTT还实现了轻量型协议。因此它还能在网络带宽低、可靠性低的环境下运行；又因为消息小、协议机制简单，所以在硬件资源（设备、CPU和内存等）受限的条件下也能运行，可以说是为物联网量身定做的协议。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）。
中介一接收到消息就会向发布者发送一个叫作“PUBACK消息”的响应，除此之外还会根据订阅者指定的QoS发送消息。当发生故障，或经过一定时间后仍没能确认PUBACK消息时，发布者会重新发送消息。如果中介接收了发布者发来的消息却没有返回PUBACK，那么中介会重复收到消息。
最后是QoS 2，它指的是准确发送一次消息（exactly once）。把它跟QoS 1合在一起使用，就能避免接收到重复的消息（图2.13）。用QoS 2发送的消息里面含有消息ID。中介收到消息后会将消息保存，然后给发布者发送PUBREC消息。发布者再给中介发送PUBREL消息，然后中介会给发布者发送PUBCOMP消息。接下来中介才会依据订阅者指定的QoS，向订阅者传递接收到的消息。
图2.12 QoS 1（至少发送一次消息）
图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）。
发布者在连接中介时会用到CONNECT（连接）消息，连接时对其指定Will标志、要发送的消息以及QoS。这样一来，如果连接意外断开，Will消息就会被传递给订阅者。另外，还有一个标志叫作Will Retain。通过指定这个标志，就能跟前面说的Retain达到同样的效果，即在中介处保存消息。
图2.15 Will
当发布者使用DISCONNECT（断开连接）消息明确表明连接已断开时，Will消息就不会被发送给订阅者。
Clean session
Clean session用于指定中介是否保留了订阅者的已订阅状态。用CONNECT消息连接时，订阅者把Clean session标志设定为0或1。0是保留session,1是不保留session。
若指定Clean session为0且中介已经连接上了订阅者，则中介需要在订阅者断开连接后保留订阅的消息。另外，如果订阅者的连接已经断开，且发布者已经发布了QoS 1、QoS 2的消息给已订阅的主题时，中介则会把消息保存，等订阅者再次连接时发送给订阅者（图2.16）。
若指定Clean session为1并连接，中介就会废弃以往保留的客户端信息，将其当成一次“干净”的连接来看待。此外，订阅者断开连接时，中介也会废弃所有的信息。
图2.16 Clean session
我们可以用表2.1所示的几种产品来实现MQTT。是否支持前文介绍的功能则取决于中介的种类。
表2.1 MQTT的实现
除此之外，一个叫作Paho的库还公开了发布者和订阅者等客户端功能。不仅Java、JavaScript、Python配备了Paho，连C语言和C++都配备了Paho。因此，我们能够将其与设备结合起来并加以使用。
2.3.5 数据格式
前面我们围绕用于接收数据的通信过程，即协议进行了讲解。事实上，数据就是通过协议来进行交换的。当然，就如我们前文所说，这条规则在物联网的世界里也是不变的。数据要经过协议进行交换，而数据的格式也很重要。通过Web协议来使用的数据格式中，具有代表性的包括XML和JSON（图2.17）。
图2.17 具有代表性的格式
从物联网的角度来说，使用者也能很方便地使用XML和JSON。举个例子，假设设备要发送传感器的值，此时除了发送传感器的值以外，还要一并发送数据接收时间、设备的机器信息以及用户信息等数据。自然，设备还会通知多个传感器的值和机器的状态。这样一来，使用者就需要好好地把从设备发送来的数据结构化。
图2.18用XML和JSON分别表示了两台传感器的信息、设备的状态、获取数据的时间，以及发送数据的设备名称等。
图2.18 传感器信息的示例（XML和JSON）
比较二者可知，XML的格式比JSON更容易理解。然而XML的字符数较多，数据量较大。相对而言，JSON比XML字符数少，数据量也小。
XML和JSON这两种数据格式都在每种语言中实现了各自的库，使用者通过程序就能很轻松地使用这些库。那么到底使用哪种才好呢？关于这点我们不能一概而论，不过JSON数据量小，更适合使用移动线路等低速线路通信的情况。
设备传来的数据和Web不一样，大多是传感器、图像、语音等数值数据。相较于文本而言，这样的数据更适合用二进制来处理。不过，我们前文介绍的XML和JSON都是用文本格式来处理数据的。
基于物联网服务处理这些格式时，要把文本数据转换成数值数据和二进制数据。因此需要进行两项工作，即解析XML和JSON格式，以及把解析结果从文本格式转换到二进制形式。这样一来，就需要分两步来处理。
如果能直接以二进制形式接收数据，是不是就能更迅速地处理数据了呢？由此，一种数据格式应运而生，它就是MessagePack（图2.19）。
图2.19 使用MessagePack格式的传感器数据示例以及与JSON的对比
MessagePack的数据格式虽然跟JSON相似，其数据却保留了二进制的形式。因此，虽然这种数据格式不方便人们直接阅读，但计算机却能很容易地处理。
又因为MessagePack发送的是二进制数据，所以比起以文本形式发送数据的JSON，数据更加紧凑。MessagePack跟XML和JSON一样，都提供了面向多种编程语言的库，另外，近年来多个OSS（开源软件）也都采用了MessagePack。
我们不能一口咬定哪种格式好，哪种格式不好，请各位根据要发送的数据的特性，来选择符合目的的数据格式。
COLUMN
图像、语音、视频数据的处理
“传感器数据、文本数据”和“图像、语音、视频”的数据格式差别很大。拿图像、语音、视频来说，一条数据之巨大远远超过传感器数据，而且这些数据是二进制数据，很难转换成字符串，所以就很难用前面介绍的XML和JSON格式对它们进行处理。
用HTTP发送图像数据时，可以用XML或JSON格式记录拍摄时间和设备的信息，用multi-part/form-data格式来发送图像数据。然而，换成语音和视频时，就是一种时间上连续的数据。因此，我们在发送语音和视频数据时需要下一番工夫。
例如，需要把语音和视频分割成一个个小文件来发送。在用HTTP协议进行这项操作时，每次发送一个小数据都会生成一个会话。这样一来就能通过有效应用WebSocket等协议来减轻给物联网服务造成的负担了。这种情况下，使用者或许需要使用MessagePack，或是定义一个专门用于处理二进制的格式。再或者，还能以用物联网服务进行语音和数据分析为前提，只在设备处提取用于分析的特征并发送，而不是把所有数据一并进行发送。大家在试图实现包含语音和视频数据的服务时，不妨考虑一下本专栏的思路。