序言

　　物聯(lián)網(wǎng)終端的種類非常多，包括物聯(lián)網(wǎng)網(wǎng)關(guān)、通信模塊以及大量的行業(yè)終端，其中尤以行業(yè)終端的種類最為豐富。通信模塊是物聯(lián)網(wǎng)應(yīng)用終端的基礎(chǔ)。物聯(lián)網(wǎng)的行業(yè)終端種類繁多，體積、處理能力、對(duì)外接口等各不相同，通信模塊將成為物聯(lián)網(wǎng)智能服務(wù)通道的統(tǒng)一承載體，嵌入各種行業(yè)終端，為各行各業(yè)提供物聯(lián)網(wǎng)的智能通道服務(wù)。而在通信中，通信協(xié)議尤其重要，是指雙方實(shí)體完成通信或服務(wù)所必須遵循的規(guī)則和約定，而且根據(jù)終端環(huán)境的不同對(duì)通信協(xié)議的要求完全不一致。

　　那么物聯(lián)網(wǎng)都有哪些通信協(xié)議？你都了解嗎？他們適用的環(huán)境又是如何？

　　與互聯(lián)網(wǎng)時(shí)代 TCP/IP，HTTP 一統(tǒng)天下的局面不同，物聯(lián)網(wǎng)的通信環(huán)境有 Ethernet， Wi-Fi， RFID， NFC(近距離無(wú)線通信)， Zigbee， 6LoWPAN(IPV6 低速無(wú)線版本)，Bluetooth， GSM， GPRS， GPS， 3G， 4G 等網(wǎng)絡(luò)，而每一種通信應(yīng)用協(xié)議都有一定適用范圍。AMQP、JMS、REST/HTTP 都是工作在以太網(wǎng)，COAP 協(xié)議是專門(mén)為資源受限設(shè)備開(kāi)發(fā)的協(xié)議，而 DDS 和 MQTT 的兼容性則強(qiáng)很多。

　　這兒舉個(gè)智能家居的例子，說(shuō)明下這些協(xié)議側(cè)重應(yīng)用方向。智能家居中智能燈光控制，可以使用 XMPP 協(xié)議控制燈的開(kāi)關(guān)；智能家居的電力供給，發(fā)電廠的發(fā)動(dòng)機(jī)組的監(jiān)控可以使用 DDS 協(xié)議；當(dāng)電力輸送到千家萬(wàn)戶時(shí)，電力線的巡查和維護(hù)，可以使用 MQTT 協(xié)議；家里的所有電器的電量消耗，可以使用 AMQP 協(xié)議，傳輸?shù)皆贫嘶蚣彝ゾW(wǎng)關(guān)中進(jìn)行分析；最后用戶想把自家的能耗查詢服務(wù)公布到互聯(lián)網(wǎng)上，那么可以使用 REST/HTTP 來(lái)開(kāi)放 API 服務(wù)。

　　下面我們將一一詳細(xì)介紹下這些協(xié)議：

　　1.REST(松耦合服務(wù)調(diào)用)

　　REST 即表述性狀態(tài)傳遞 (英文：Representational State Transfer，簡(jiǎn)稱 REST) 是 Roy Fielding 博士在 2000 年他的博士論文中提出來(lái)的一種軟件架構(gòu)風(fēng)格。它是一種針對(duì)網(wǎng)絡(luò)應(yīng)用的設(shè)計(jì)和開(kāi)發(fā)方式，可以降低開(kāi)發(fā)的復(fù)雜性，提高系統(tǒng)的可伸縮性。

　　而 REST 被應(yīng)用于物聯(lián)網(wǎng)主要是基于 HTTP web 服務(wù)的轉(zhuǎn)化，因?yàn)?REST 模式的 Web 服務(wù)與復(fù)雜的 SOAP 和 XML-RPC 對(duì)比來(lái)講明顯的更加簡(jiǎn)潔，越來(lái)越多的 web 服務(wù)開(kāi)始采用 REST 風(fēng)格設(shè)計(jì)和實(shí)現(xiàn)。

　　特點(diǎn)：

　　給一切物體一個(gè) ID

　　連接物體在一起

　　使用標(biāo)準(zhǔn)方法

　　資源多重表述

　　無(wú)狀態(tài)通信

　　REST 其實(shí)是互聯(lián)網(wǎng)中服務(wù)調(diào)用 API 封裝風(fēng)格，物聯(lián)網(wǎng)中數(shù)據(jù)采集到物聯(lián)網(wǎng)應(yīng)用系統(tǒng)中，在物聯(lián)網(wǎng)應(yīng)用系統(tǒng)中，可以通過(guò)開(kāi)放 REST API 的方式，把數(shù)據(jù)服務(wù)開(kāi)放出去，被互聯(lián)網(wǎng)中其他應(yīng)用所調(diào)用，所以它非常利于服務(wù)平臺(tái)與物聯(lián)終端的獨(dú)立開(kāi)發(fā)，但它的通訊數(shù)據(jù)量與 API 內(nèi)容密切相關(guān)，且是一種無(wú)狀態(tài)通信，對(duì)安全機(jī)制需要重新設(shè)計(jì)。

　　2.CoAP 協(xié)議

　　由于物聯(lián)網(wǎng)中的很多設(shè)備都是資源受限型的，即只有少量的內(nèi)存空間和有限的計(jì)算能力，所以傳統(tǒng)的 HTTP 協(xié)議應(yīng)用在物聯(lián)網(wǎng)上就顯得過(guò)于龐大而不適用。 IETF 的 CoRE 工作組提出了一種基于 REST 架構(gòu)的 CoAP 協(xié)議。

　　CoAP 是一種應(yīng)用層協(xié)議，它運(yùn)行于 UDP 協(xié)議之上而不是像 HTTP 那樣運(yùn)行于 TCP 之上。CoAP 協(xié)議非常的小巧，最小的數(shù)據(jù)包僅為 4 字節(jié)。

　　CoAP 協(xié)議是否可以替換 HTTP 協(xié)議?

　　CoAP 并不能替代 HTTP 協(xié)議，但是對(duì)于那些小設(shè)備 (256KB Flash 32KB RAM 20MHz 主頻) 而言 CoAP 的確是一個(gè)好的解決方案。

　　CoAP 消息類型

　　CoAP 采用和 HTTP 協(xié)議相同的請(qǐng)求響應(yīng)工作模式。CoAP 協(xié)議共有 4 中不同的消息類型。

　　CON——需要被確認(rèn)的請(qǐng)求，如果 CON 請(qǐng)求被發(fā)送，那么對(duì)方必須做出響應(yīng)。

　　NON——不需要被確認(rèn)的請(qǐng)求，如果 NON 請(qǐng)求被發(fā)送，那么對(duì)方不必做出回應(yīng)。

　　ACK——應(yīng)答消息，如果接受到 CON 消息的響應(yīng)。

　　RST——復(fù)位消息，當(dāng)接收者接受到的消息包含一個(gè)錯(cuò)誤，接受者解析消息或者不再關(guān)心發(fā)送者發(fā)送的內(nèi)容，那么復(fù)位消息將會(huì)被發(fā)送。

　　CoAP 消息結(jié)構(gòu)

　　一個(gè) CoAP 消息最小為 4 個(gè)字節(jié)，以下是 CoAP 協(xié)議不同部分的描述。

　　【版本 Version】：類似于 IPv6 和 IPv6，僅僅是一個(gè)版本號(hào)。

　　【消息類型 Message Type】：CON，NON，ACK，RST。這些消息類型相當(dāng)于 HTTP 協(xié)議的 PUTGET 等

　　【消息 ID Message ID】：每個(gè) CoAP 消息都有一個(gè) ID，在一次會(huì)話中 ID 總是保持不變。但是在這個(gè)會(huì)話之后該 ID 會(huì)被回收利用。

　　【標(biāo)記 Token】：標(biāo)記是 ID 的另一種表現(xiàn)、

　　【選項(xiàng) Options】：CoAP 選項(xiàng)類似于 HTTP 請(qǐng)求頭，它包括 CoAP 消息本身，例如 CoAP 端口號(hào)，CoAP 主機(jī)和 CoAP 查詢字符串等。

　　【負(fù)載 Payload】：真正有用的被交互的數(shù)據(jù)。

　　在當(dāng)前由 PC 機(jī)組成的世界，信息交換是通過(guò) TCP 和應(yīng)用層協(xié)議 HTTP 實(shí)現(xiàn)的。但是對(duì)于小型設(shè)備而言，實(shí)現(xiàn) TCP 和 HTTP 協(xié)議顯然是一個(gè)過(guò)分的要求。為了讓小設(shè)備可以接入互聯(lián)網(wǎng)，CoAP 協(xié)議被設(shè)計(jì)出來(lái)。

　　3.MQTT 協(xié)議 (低帶寬)

　　MQTT(Message Queuing Telemetry Transport，消息隊(duì)列遙測(cè)傳輸協(xié)議)，是一種基于發(fā)布 / 訂閱 (publish/subscribe) 模式的 “輕量級(jí)” 通訊協(xié)議，該協(xié)議構(gòu)建于 TCP/IP 協(xié)議上，由 IBM 在 1999 年發(fā)布。MQTT 最大優(yōu)點(diǎn)在于，可以以極少的代碼和有限的帶寬，為連接遠(yuǎn)程設(shè)備提供實(shí)時(shí)可靠的消息服務(wù)。做為一種低開(kāi)銷(xiāo)、低帶寬占用的即時(shí)通訊協(xié)議，使其在物聯(lián)網(wǎng)、小型設(shè)備、移動(dòng)應(yīng)用等方面有較廣泛的應(yīng)用。

　　MQTT 協(xié)議運(yùn)行在 TCP/IP 或其他網(wǎng)絡(luò)協(xié)議，提供有序、無(wú)損、雙向連接。其特點(diǎn)包括：

　　1) 使用的發(fā)布 / 訂閱消息模式，它提供了一對(duì)多消息分發(fā)，以實(shí)現(xiàn)與應(yīng)用程序的解耦。

　　2) 對(duì)負(fù)載內(nèi)容屏蔽的消息傳輸機(jī)制。

　　3) 對(duì)傳輸消息有三種服務(wù)質(zhì)量 (QoS)：

　　最多一次，這一級(jí)別會(huì)發(fā)生消息丟失或重復(fù)，消息發(fā)布依賴于底層 TCP/IP 網(wǎng)絡(luò)。即：<=1>=1

　　只有一次，確保消息只有一次到達(dá)。即：=1。在一些要求比較嚴(yán)格的計(jì)費(fèi)系統(tǒng)中，可以使用此級(jí)別

　　4) 數(shù)據(jù)傳輸和協(xié)議交換的最小化 (協(xié)議頭部只有 2 字節(jié))，以減少網(wǎng)絡(luò)流量

　　5) 通知機(jī)制，異常中斷時(shí)通知傳輸雙方

　　適用范圍：在低帶寬、不可靠的網(wǎng)絡(luò)下提供基于云平臺(tái)的遠(yuǎn)程設(shè)備的數(shù)據(jù)傳輸和監(jiān)控。

　　協(xié)議實(shí)現(xiàn)方式

　　實(shí)現(xiàn) MQTT 協(xié)議需要：客戶端和服務(wù)器端

　　MQTT 協(xié)議中有三種身份：發(fā)布者 (Publish)、代理 (Broker)(服務(wù)器)、訂閱者 (Subscribe)。其中，消息的發(fā)布者和訂閱者都是客戶端，消息代理是服務(wù)器，消息發(fā)布者可以同時(shí)是訂閱者。

　　MQTT 傳輸?shù)南⒎譃椋褐黝} (Topic) 和負(fù)載 (payload) 兩部分

　　Topic，可以理解為消息的類型，訂閱者訂閱 (Subscribe) 后，就會(huì)收到該主題的消息內(nèi)容(payload)

　　payload，可以理解為消息的內(nèi)容，是指訂閱者具體要使用的內(nèi)容

　　MQTT 協(xié)議一般適用于設(shè)備數(shù)據(jù)采集到端 (Device-》Server，Device-》Gateway)，集中星型網(wǎng)絡(luò)架構(gòu) (hub-and-spoke)，不適用設(shè)備與設(shè)備之間通信，設(shè)備控制能力弱，另外實(shí)時(shí)性較差，一般都在秒級(jí)。

　　4.DDS 協(xié)議 (高可靠性、實(shí)時(shí))

　　數(shù)據(jù)分發(fā)服務(wù) DDS(Data Distribution Service)是對(duì)象管理組織 (OMG) 在 HLA 及 CORBA 等標(biāo)準(zhǔn)的基礎(chǔ)上制定的新一代分布式實(shí)時(shí)通信中間件技術(shù)規(guī)范，DDS 采用發(fā)布 / 訂閱體系架構(gòu)，強(qiáng)調(diào)以數(shù)據(jù)為中心，提供豐富的 QoS 服務(wù)質(zhì)量策略，能保障數(shù)據(jù)進(jìn)行實(shí)時(shí)、高效、靈活地分發(fā)，可滿足各種分布式實(shí)時(shí)通信應(yīng)用需求。DDS 信息分發(fā)中間件是一種輕便的、能夠提供實(shí)時(shí)信息傳送的中間件技術(shù)。

　　特點(diǎn)：

　　靈活的發(fā)布 / 訂閱模式

　　完整 DDS 規(guī)范 QoS 服務(wù)質(zhì)量策略

　　已擴(kuò)展的 QoS 服務(wù)質(zhì)量策略

　　互操作

　　強(qiáng)實(shí)時(shí)

　　跨平臺(tái)

　　支持多種底層物理通信協(xié)議

　　仿真→測(cè)試→實(shí)裝的全生命周期支持

　　DDS 很好地支持設(shè)備之間的數(shù)據(jù)分發(fā)和設(shè)備控制，設(shè)備和云端的數(shù)據(jù)傳輸，同時(shí) DDS 的數(shù)據(jù)分發(fā)的實(shí)時(shí)效率非常高，能做到秒級(jí)內(nèi)同時(shí)分發(fā)百萬(wàn)條消息到眾多設(shè)備。DDS 在服務(wù)質(zhì)量 (QoS) 上提供非常多的保障途徑，這也是它適用于國(guó)防軍事、工業(yè)控制這些高可靠性、可安全性應(yīng)用領(lǐng)域的原因。但這些應(yīng)用都工作在有線網(wǎng)絡(luò)下，在無(wú)線網(wǎng)絡(luò)，特別是資源受限的情況下，沒(méi)有見(jiàn)到過(guò)實(shí)施案例。

　　5.AMQP 協(xié)議 (互操作性)

　　AMQP，即 Advanced Message Queuing Protocol, 一個(gè)提供統(tǒng)一消息服務(wù)的應(yīng)用層標(biāo)準(zhǔn)高級(jí)消息隊(duì)列協(xié)議, 是應(yīng)用層協(xié)議的一個(gè)開(kāi)放標(biāo)準(zhǔn), 為面向消息的中間件設(shè)計(jì)。基于此協(xié)議的客戶端與消息中間件可傳遞消息，并不受客戶端 / 中間件不同產(chǎn)品，不同的開(kāi)發(fā)語(yǔ)言等條件的限制。Erlang 中的實(shí)現(xiàn)有 RabbitMQ 等。

　　AMQP 協(xié)議是一個(gè)二進(jìn)制協(xié)議，擁有一些現(xiàn)代特點(diǎn)：多信道、協(xié)商式、異步、安全、跨平臺(tái)、中立、高效。

　　AMQP 通常被劃分為三層：

　　模型層定義了一套命令 (按功能分類)，客戶端應(yīng)用可以利用這些命令來(lái)實(shí)現(xiàn)它的業(yè)務(wù)功能。

　　會(huì)話層負(fù)責(zé)將命令從客戶端應(yīng)用傳遞給服務(wù)器，再將服務(wù)器的應(yīng)答傳遞給客戶端應(yīng)用，會(huì)話層為這個(gè)傳遞過(guò)程提供可靠性、同步機(jī)制和錯(cuò)誤處理。

　　傳輸層提供幀處理、信道復(fù)用、錯(cuò)誤檢測(cè)和數(shù)據(jù)表示。

　　實(shí)現(xiàn)者可以將傳輸層替換成任意傳輸協(xié)議，只要不改變 AMQP 協(xié)議中與客戶端應(yīng)用程序相關(guān)的功能。實(shí)現(xiàn)者還可以使用其他高層協(xié)議中的會(huì)話層。

　　AMQP 協(xié)議最早應(yīng)用于金融系統(tǒng)之間的交易消息傳遞，在物聯(lián)網(wǎng)應(yīng)用中，主要適用于移動(dòng)手持設(shè)備與后臺(tái)數(shù)據(jù)中心的通信和分析。

　　6.XMPP 協(xié)議 (即時(shí)通信)

　　XMPP 是一種基于標(biāo)準(zhǔn)通用標(biāo)記語(yǔ)言的子集 XML 的協(xié)議，它繼承了在 XML 環(huán)境中靈活的發(fā)展性。因此，基于 XMPP 的應(yīng)用具有超強(qiáng)的可擴(kuò)展性。經(jīng)過(guò)擴(kuò)展以后的 XMPP 可以通過(guò)發(fā)送擴(kuò)展的信息來(lái)處理用戶的需求，以及在 XMPP 的頂端建立如內(nèi)容發(fā)布系統(tǒng)和基于地址的服務(wù)等應(yīng)用程序。而且，XMPP 包含了針對(duì)服務(wù)器端的軟件協(xié)議，使之能與另一個(gè)進(jìn)行通話，這使得開(kāi)發(fā)者更容易建立客戶應(yīng)用程序或給一個(gè)配好系統(tǒng)添加功能。

　　特點(diǎn)：

　　客戶機(jī) / 服務(wù)器通信模式

　　分布式網(wǎng)絡(luò)

　　簡(jiǎn)單的客戶端，將大多數(shù)工作放在服務(wù)器端進(jìn)行

　　標(biāo)準(zhǔn)通用標(biāo)記語(yǔ)言的子集 XML 的數(shù)據(jù)格式

　　XMPP 協(xié)議是自由、開(kāi)放、公開(kāi)的，并且易于了解。而且在客戶端、服務(wù)器、組件、源碼庫(kù)等方面，都已經(jīng)各自有多種實(shí)現(xiàn)。但隨著通常超過(guò) 70% 的 XMPP 協(xié)議的服務(wù)器的數(shù)據(jù)流量的存在和近 60% 的被重復(fù)轉(zhuǎn)發(fā)，XMPP 協(xié)議目前擁有一個(gè)大型架空中存在的數(shù)據(jù)提供給多個(gè)收件人。適用于即時(shí)通信的應(yīng)用程序，還能用在網(wǎng)絡(luò)管理、內(nèi)容供稿、協(xié)同工具、檔案共享、游戲、遠(yuǎn)端系統(tǒng)監(jiān)控等。