目錄
第一部分 物聯網的組成
第二部分 常見物聯網通信協議比較
第三部分 MQTT協議及開源實現
第四部分 IOT架構及設備接入實踐
1.物聯網的組成
生活中常見的共享單車、智能手環、智能家居等都是物聯網的實際引用。物聯網最初在1999年提出：即通過射頻識別（ RFID）、 紅外感應器、全球定位系統、激光掃描器、氣體感應
器等信息傳感設備，按約定的協議，把任何物品與互聯網連接起來，進行信息交換和通訊，以
實現智能化識別、定位、跟蹤、監控和管理的一種網絡。簡而言之，物聯網就是“物物相連的
互聯網”。
物聯網組成一般包括：(1)設備 通常含有各種傳感器，如圖像傳感器、光學傳感器、溫度傳感器、溼度傳感器、 加速
度傳感器、磁場傳感器等。
(2)網絡 近距離通信(藍牙、 RFID、 NFC)，遠距離蜂窩通信(GSM、 WCDMA、 LTE、 NB-IOT)，遠距
離非蜂窩通信(WiFi、 ZigBee)，有線通信。
(3)物聯網服務 數據的接收與發送，數據的處理與保存。
以膜拜單車開鎖流程爲例，膜拜智能鎖開鎖流程： 2.識別二維碼後自動向雲端發送解鎖請求 3.雲端系統識別用戶信息、校驗單車情況等 4.業務處理成功後雲端系統向智能鎖發送解鎖 5.智能鎖執行開鎖命令，並上報開鎖結果 6.膜拜APP開鎖進度更新，並開始計費 7.單車定時上報位置信息， APP端更新行駛 |  |
2.常見物聯網通信協議比較
IOT網絡中，通常設備和網絡是受限的。因此在選擇數據通信協議時需要考慮設備的計算、存儲、能耗，窄帶寬和網絡不穩定等因素。常見的數據通信協議有： HTTP、 XMPP、 COAP、 MQTT。
2.1.HTTP
自1990年出現的HTTP協議作爲web的標準協議已被廣泛使用，在物聯網中同樣可以採用HTTP協議。例如手機、 PC等終端設備。但是作爲適應瀏覽器場景的HTTP協議，並不適用於物聯網的其他備。適用範圍：開放物聯網中資源，實現服務被其他應用所調用。
優勢：
1.簡單的工作模式，請求/響應
2.完整的方法定義。
3.合理的狀態碼設計
4.友好的媒體類型支持。文本、圖片、視頻
缺點：1.單向傳輸，可以通過客戶端輪詢實現類似推送效果或者HTTP 2.0。
2.安全性不高， HTTP是明文協議，可以使用HTTPS傳輸
3.HTTP是文本協議，冗長的協議頭部，對於運算、存儲、帶寬資源受限的設備來說開銷大。
2.2.XMPP(Extensible Messaging and Presence Protocol可擴展消息與存在協議)
XMPP的前身是Jabber開源社區於1999年開發的Jabber協議， 用於即時通信、狀態信息(比如即時通信客戶端顯示用戶在線、忙碌、視頻中等)、通訊錄管理。通過類似郵箱地址的JID進行尋址(如[email protected])
適用範圍：即時通信的應用程序，還能用在網絡管理、 協同工具、檔案共享、遊戲、遠端系統監控等。
| 優勢： 1.去中心化，類似於郵件網絡架構。 2.安全，支持SASL安全認證和TLS加密。 3.靈活，基於XML的數據格式可以自定義功能。 4.應用廣泛，衆多的客戶端、服務端實現。 1.不支持服務質量(Qos) 2.基於文本協議的通信帶來高的網絡負載 3.二進制數據傳輸支持較差 |  |
2.3.CoAP (Constrained Application Protocol 受限的應用協議)
CoAP是爲了讓低功耗受限設備可以接入互聯網，由IETF組織制定的，它借鑑了HTTP大量成功經驗，同樣使用請求/響應工作模式。適用範圍：適用於局域網環境下一對一M2M通信。
優勢：1.採用和HTTP相似語義的請求和響應碼，並使用二進制報文減小了報文大小
2.傳輸層基於UDP協議，比TCP數據包小，並不需要建立連接帶來握手的開銷
3.資源發現支持，通過觀察者模式實現類似發佈/訂閱效果
缺點：1.基於UDP的不可靠傳輸，但通過四種報文類型的組合及重傳機制提高傳輸的可靠性。
2.基於UDP的無連接傳輸，不利於不同網絡間消息的回傳。
2.4.MQTT (Message Queuing Telemetry Transport 消息隊列遙測傳輸)
MQTT協議最初由IBM公司於1999年開發，用於將石油管道上的傳感器與衛星相連接。 2014年正式成爲OASIS開放標準。MQTT使用類似MQ常用的發佈/訂閱模式，起到應用程序解耦，異步消息，削峯填谷的作用。很多MQ中間件也支持MQTT協議，比如ActiveMQ、 RabbitMQ、 HiveMQ、 WebSphereMQ等。適用範圍：在低帶寬、不可靠的網絡下提供基於雲平臺的遠程設備的數據傳輸和監控。
優勢：1.使用發佈/訂閱模式，提供一對多的消息發佈，使消息發送者和接收者在時間和空間上解耦。
2.二進制協議， 網絡傳輸開銷非常小(固定頭部是2字節)。
3.靈活的Topic訂閱、 Qos、臨終遺言等特性。
缺點：
1.集中化部署，服務端壓力大，需要考慮流程控制及高可用。
2.對於請求/響應模式的支持需要在應用層根據消息ID做發佈主題和訂閱主題之間的關聯
總體來看， HTTP和XMPP網絡開銷大， CoAP和MQTT更適合物聯網受限環境中設備的通信。從市場應用層面看， MQTT發展相對成熟、應用相對廣泛，也比較適合設備的遠程監控與管理。
3. MQTT協議簡介及開源實現MQTT是基於發佈訂閱模式的，有主題過濾器、 Qos保證、臨終遺言、 Session持久化
等特性，下面我們一起通過報文來了解一下吧。
3.1.MQTT工作模式
3.2.MQTT協議報文組成(基於v3.1.1)
可變頭和消息體根據不同報文類型而不同， 可以看出：
1.MQTT協議最小報文僅有2個字節(只有固定頭且剩餘長度爲1個字節)，如心跳報文PINGREQ、PINGRESP
2.報文類型最多2^4=16。目前共有14種報文類型， 2個保留類型。下面着重看下連接、發佈、訂閱相關報文。
3.3.CONNECT報文整體結構
CONNECT報文的可變頭中存在以下非常重要的標誌位。
1.Clean Session作用：該標誌用於指定客戶端連接到服務端後，是否清除之前持久化的session信息(如果存在)，並且當連接斷開後是否持久化本次會話的session信息。
場景：由於網絡等原因造成設備臨時下線，當設備重新連接服務端時，如果上次連接CleanSession=1則之前訂閱的主題及設備下線期間發送的消息就會丟失，如果需要設備下線期間消息
不丟失可以設置Clean Session=0。
Session中存儲信息有哪些？1.ClientId用於識別客戶端
2.客戶端的訂閱的主題
3.已經發送或正在發送到客戶端的Qos1和Qos2消息，還沒有完全確認(發給訂閱者)
4.已經接收到客戶端發送的Qos2消息，還沒有完全確認(接收發布者)
5.在發送中的Qos0消息(可選)
2.Will Flag
作用：客戶端連接異常斷開時觸發服務端向訂閱客戶端發送消息通知。
場景：由於網絡異常導致客戶端下線，可使用臨終遺囑通知訂閱了該遺囑topic的客戶端，從而進行應對處理。
當Will Flag=1，連接建立後，服務端會保存Will Message。 當網絡連接關閉後(除服務端接收到DISCONNECT報文外)，遺囑消息會被髮布。服務端發佈遺囑消息時按照Will Qos和Will Retain(是否保留消息)標誌位發佈。
3.Will Qos(服務質量)
MQTT支持三種服務質量等級：Qos0:至多一次交付消息。接收方能否接收到消息完全依賴於網絡傳輸情況。一般用於實時性較高的情況下，如傳感器發送當前溫度數據，如果丟失一次數據也沒有影響，因爲馬上會有最新的數據到來。
Qos1:至少一次交付消息。接收方可能接收到重複消息。應用於確保消息到達，並有冪等處理的系統。
Qos2:準確一次交付消息。接收方只能接收到一次消息。應用於比較嚴格的如計費系統，重複或者丟失數據都會導致不正確的結果。需要注意的是Qos保證不是端到端的，而是客戶端和服務器之間的。訂閱者收到MQTT消息
的Qos級別，取決於發佈消息的Qos和訂閱主題的Qos，當二者不同是，會產生降級，以最低的
Qos級別爲準。
4.Retain作用：保存客戶端最新發布的消息。
場景：通常情況下，訂閱者需要在發佈者發佈消息前訂閱。使用Retain標誌位可以在服務端保
留最新的消息，當新的客戶端訂閱相關主題時可以立即收到該主題上的最新消息。
3.4.PUBLISH報文整體結構
1.PUBLISH報文固定頭中有三個重要的標誌位，其中Qos、 RETAIN和前面介紹的CONNECT報文可變頭中標誌位語義相同。
DUP flag是報文重傳標誌，在Qos1和Qos2的報文重傳過程中會把DUP flag置爲1。
2.不同Qos報文發送的過程(1)Qos0 消息發佈流
(2)Qos1 消息發佈流
(3)Qos2 消息發佈流
3.5.SUBSCRIBE報文整體結構
訂閱和發佈都是針對topic的， topic根據”/” 分隔爲不同的層級。一個PUBLISH報文中只能有一個topic，一個SUBCRIBE報文中可以有多個topic filter。 topic filter中可以使用通配符。
多層級通配符#(1)可以匹配父層級主題和任意數量子層級主題
(2)必須是主題過濾器的最後一個字符
單層級通配符-(1)匹配一個層級
(2)可以出現在主題過濾器的任意位置，也可以和#搭配使用
特殊情況： 以#或+通配符開頭的topic filter不匹配以$開頭的主題。通常以$SYS/前綴的主題用於獲取服務器相關的信息或者是控制API
3.6.MQTT的開源實現
1.客戶端 Eclipse Paho 支持Java、 C/C++、 Python、 Go、 JavaScript、 Rust
2.服務端 mosquitto、 emqttd、 Apache ActiveMQ、 RabbitMQ
4.IOT架構及設備接入實踐
4.1.IOT架構
目前，業界像BAT公司都提供了基於自家雲服務的IOT接入整套解決方案，如設備接入、通信與管理，安全認證，設備影子，消息存儲與分析計算等。大體架構如下：
4.1.設備影子
在IOT平臺中除了提供MQTT服務端外，還有一個重要概念——設備影子。設備影子是一個JSON文檔，用於存儲設備上報狀態、應用程序期望狀態信息。
場景1：設備在不穩定網絡中頻繁上下線，應用程序可能無法獲取到設備最新狀態信息。設備在狀態變化時存儲最新狀態信息到設備影子中，則應用程序從影子中獲取設備狀態即可。
場景2：應用程序多次請求獲取設備狀態，增加了設備的負載。使用設備影子減小設備的
壓力。
場景3：應用程序發送指令給設備，由於網絡不穩定，指令可能無法到達。若使用Qos1或2
則增加服務端的壓力，將指令加時間戳存在影子中，設備上線時根據時間戳來判斷是否執行指
令。
4.2.IOT設備接入實踐百度天工、阿里物接入等
4.3.Clean Session 實踐
1.客戶端連接時不勾選CleanSession，則CleanSession=false(0)
2.這裏使用emq broker，可以看到，服務端有一個session
4.再打開一個客戶端作爲發佈者，向/temperature主題發佈消息；訂閱者客戶端重新連接後，打開訂閱者log日誌，可以看雖然沒有重新訂閱/temperature，但訂閱者依然可以收到消息。
