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