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.3.3 WebSocket

WebSocket是一種通信協議，用于在互聯網上實現套接字通信。它實現了Web瀏覽器和Web服務器間的數據雙向連續傳輸。

就HTTP協議而言，每次發送數據都必須生成發送數據用的通信路徑及連接。此外，一般情況下，客戶端沒有發出申請就不能進行通信。

相對而言，WebSocket就不同了。只要一開始根據客戶端發出的連接申請確立了連接，就能持續用同一個連接傳輸數據。另外，只要確立了連接，就算客戶端沒有發出申請，服務器也能給客戶端發送數據（圖2.7）。

這樣一來，在發送語音數據等連續的數據，以及發生與服務器的相互交換時，就能使用WebSocket了。WebSocket自身只提供服務器與客戶端的數據交換，因此需要使用者另外決定在應用層上使用的協議。

2.3.4 MQTT

MQTT（MQ Telemetry Transport，消息隊列遙測傳輸）是近年來出現的一種新型協議，物聯網領域會將其作為標準協議。MQTT原本是IBM公司開發的協議，現在則開源了，被人們不斷開發著。

MQTT是一種能實現一對多通信（人們稱之為發布或訂閱型）的協議。它由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

QoS是Quality of Service（服務質量）的簡稱。這個詞在網絡領域表示的是通信線路的品質保證。MQTT里存在3個等級的QoS。“發布者和中介之間”以及“中介和訂閱者之間”都分別定義了不同的QoS等級，以異步的方式運行。此外，當“中介與訂閱者之間”指定的QoS小于“發布者和中介之間”交換的QoS時，“中介與訂閱者之間”的QoS會被降級到指定的QoS。QoS 0指的是最多發送一次消息（at most once）（圖2.11），發送要遵循TCP/IP通信的“盡力服務”。消息分兩種情況，即到達了一次中介處，或沒有到達中介處。

接下來的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，向訂閱者傳遞接收到的消息。

此外，就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消息就會被傳遞給訂閱者。另外，還有一個標志叫作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）。

若指定Clean session為1并連接，中介就會廢棄以往保留的客戶端信息，將其當成一次“干凈”的連接來看待。此外，訂閱者斷開連接時，中介也會廢棄所有的信息。

我們可以用表2.1所示的幾種產品來實現MQTT。是否支持前文介紹的功能則取決于中介的種類。

除此之外，一個叫作Paho的庫還公開了發布者和訂閱者等客戶端功能。不僅Java、JavaScript、Python配備了Paho，連C語言和C++都配備了Paho。因此，我們能夠將其與設備結合起來并加以使用。

2.3.5 數據格式

前面我們圍繞用于接收數據的通信過程，即協議進行了講解。事實上，數據就是通過協議來進行交換的。當然，就如我們前文所說，這條規則在物聯網的世界里也是不變的。數據要經過協議進行交換，而數據的格式也很重要。通過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。

我們不能一口咬定哪種格式好，哪種格式不好，請各位根據要發送的數據的特性，來選擇符合目的的數據格式。