物聯(lián)網(wǎng)通信協(xié)議的詳解及選擇建議

　　通信對(duì)物聯(lián)網(wǎng)來(lái)說(shuō)十分關(guān)鍵，無(wú)論是近距離無(wú)線傳輸技術(shù)還是移動(dòng)通信技術(shù)，甚至是LPWAN都影響著物聯(lián)網(wǎng)的發(fā)展。通信協(xié)議是指雙方實(shí)體完成通信或服務(wù)所必須遵循的規(guī)則和約定。那么物聯(lián)網(wǎng)都有哪些通信協(xié)議？眾多的協(xié)議該如何選擇？

　　我們將物聯(lián)網(wǎng)通信協(xié)議分為兩大類，一類是接入?yún)f(xié)議，一類是通訊協(xié)議。接入?yún)f(xié)議一般負(fù)責(zé)子網(wǎng)內(nèi)設(shè)備間的組網(wǎng)及通信（文章《常見物聯(lián)網(wǎng)近距離無(wú)線通信技術(shù)解析》有詳細(xì)介紹）；通訊協(xié)議主要是運(yùn)行在傳統(tǒng)互聯(lián)網(wǎng)TCP/IP協(xié)議之上的設(shè)備通訊協(xié)議，負(fù)責(zé)設(shè)備通過(guò)互聯(lián)網(wǎng)進(jìn)行數(shù)據(jù)交換及通信。

　　本文羅列下市面上物聯(lián)網(wǎng)協(xié)議，總結(jié)下它們各自特點(diǎn)、特定的物聯(lián)網(wǎng)應(yīng)用場(chǎng)景等。

　　物聯(lián)網(wǎng)聯(lián)接的問題空間

　　上圖為物聯(lián)網(wǎng)聯(lián)接的問題空間，其中物聯(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é)議是專門為資源受限設(shè)備開發(fā)的協(xié)議，而DDS和MQTT的兼容性則強(qiáng)很多。

　　互聯(lián)網(wǎng)時(shí)代，TCP/IP協(xié)議已經(jīng)一統(tǒng)江湖，現(xiàn)在的物聯(lián)網(wǎng)的通信架構(gòu)也是構(gòu)建在傳統(tǒng)互聯(lián)網(wǎng)基礎(chǔ)架構(gòu)之上。在當(dāng)前的互聯(lián)網(wǎng)通信協(xié)議中，HTTP協(xié)議由于開發(fā)成本低，開放程度高，幾乎占據(jù)大半江山，所以很多廠商在構(gòu)建物聯(lián)網(wǎng)系統(tǒng)時(shí)也基于http協(xié)議進(jìn)行開發(fā)。包括google主導(dǎo)的physic web項(xiàng)目，都是期望在傳統(tǒng)web技術(shù)基礎(chǔ)上構(gòu)建物聯(lián)網(wǎng)協(xié)議標(biāo)準(zhǔn)。

　　HTTP協(xié)議是典型的CS通訊模式，由客戶端主動(dòng)發(fā)起連接，向服務(wù)器請(qǐng)求XML或JSON數(shù)據(jù)。該協(xié)議最早是為了適用web瀏覽器的上網(wǎng)瀏覽場(chǎng)景和設(shè)計(jì)的，目前在PC、手機(jī)、pad等終端上都應(yīng)用廣泛，但并不適用于物聯(lián)網(wǎng)場(chǎng)景。在物聯(lián)網(wǎng)場(chǎng)景中其有三大弊端：

　　1. 由于必須由設(shè)備主動(dòng)向服務(wù)器發(fā)送數(shù)據(jù)，難以主動(dòng)向設(shè)備推送數(shù)據(jù)。對(duì)于單單的數(shù)據(jù)采集等場(chǎng)景還勉強(qiáng)適用，但是對(duì)于頻繁的操控場(chǎng)景，只能推過(guò)設(shè)備定期主動(dòng)拉取的的方式，實(shí)現(xiàn)成本和實(shí)時(shí)性都大打折扣。

　　2. 安全性不高。web的不安全都是婦孺皆知，HTTP是明文協(xié)議，在很多要求高安全性的物聯(lián)網(wǎng)場(chǎng)景，如果不做很多安全準(zhǔn)備工作（如采用https等），后果不堪設(shè)想。

　　3. 不同于用戶交互終端如pc、手機(jī)，物聯(lián)網(wǎng)場(chǎng)景中的設(shè)備多樣化，對(duì)于運(yùn)算和存儲(chǔ)資源都十分受限的設(shè)備，http協(xié)議實(shí)現(xiàn)、XML/JSON數(shù)據(jù)格式的解析，都是不可能的任務(wù)。

　　REST/HTTP（松耦合服務(wù)調(diào)用）

　　REST （RepresentaTIonal State Transfer），表征狀態(tài)轉(zhuǎn)換，是基于HTTP協(xié)議開發(fā)的一種通信風(fēng)格，目前還不是標(biāo)準(zhǔn)；

　　適用范圍：REST/HTTP主要為了簡(jiǎn)化互聯(lián)網(wǎng)中的系統(tǒng)架構(gòu)，快速實(shí)現(xiàn)客戶端和服務(wù)器之間交互的松耦合，降低了客戶端和服務(wù)器之間的交互延遲。因此適合在物聯(lián)網(wǎng)的應(yīng)用層面，通過(guò)REST開放物聯(lián)網(wǎng)中資源，實(shí)現(xiàn)服務(wù)被其他應(yīng)用所調(diào)用。

　　特點(diǎn)：

　　· REST 指的是一組架構(gòu)約束條件和原則。滿足這些約束條件和原則的應(yīng)用程序或設(shè)計(jì)就是RESTful

　　· 客戶端和服務(wù)器之間的交互在請(qǐng)求之間是無(wú)狀態(tài)的

　　· 在服務(wù)器端，應(yīng)用程序狀態(tài)和功能可以分為各種資源，它向客戶端公開。資源的例子有：應(yīng)用程序?qū)ο蟆?shù)據(jù)庫(kù)記錄、算法等等。每個(gè)資源都使用 URI （Universal Resource IdenTIfier） 得到一個(gè)惟一的地址。所有資源都共享統(tǒng)一的界面，以便在客戶端和服務(wù)器之間傳輸狀態(tài)

　　· 使用的是標(biāo)準(zhǔn)的 HTTP 方法，比如 GET、PUT、POST 和 DELETE

　　點(diǎn)評(píng)： REST/HTTP其實(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ò)開放REST API的方式，把數(shù)據(jù)服務(wù)開放出去，被互聯(lián)網(wǎng)中其他應(yīng)用所調(diào)用。

　　CoAP協(xié)議

　　· CoAP （Constrained ApplicaTIon Protocol），受限應(yīng)用協(xié)議，應(yīng)用于無(wú)線傳感網(wǎng)中協(xié)議。

　　適用范圍：CoAP是簡(jiǎn)化了HTTP協(xié)議的RESTful API，CoAP是6LowPAN協(xié)議棧中的應(yīng)用層協(xié)議，它適用于在資源受限的通信的IP網(wǎng)絡(luò)。

　　特點(diǎn)：

　　報(bào)頭壓縮：CoAP包含一個(gè)緊湊的二進(jìn)制報(bào)頭和擴(kuò)展報(bào)頭。它只有短短的4B的基本報(bào)頭，基本報(bào)頭后面跟擴(kuò)展選項(xiàng)。一個(gè)典型的請(qǐng)求報(bào)頭為10～20B。

　　方法和URIs：為了實(shí)現(xiàn)客戶端訪問服務(wù)器上的資源，CoAP支持GET、PUT、POST和DELETE等方法。CoAP還支持URIs，這是Web架構(gòu)的主要特點(diǎn)。

　　傳輸層使用UDP協(xié)議：CoAP協(xié)議是建立在UDP協(xié)議之上，以減少開銷和支持組播功能。它也支持一個(gè)簡(jiǎn)單的停止和等待的可靠性傳輸機(jī)制。

　　支持異步通信：HTTP對(duì)M2M（Machine-to-Machine）通信不適用，這是由于事務(wù)總是由客戶端發(fā)起。而CoAP協(xié)議支持異步通信，這對(duì)M2M通信應(yīng)用來(lái)說(shuō)是常見的休眠／喚醒機(jī)制。

　　支持資源發(fā)現(xiàn)：為了自主的發(fā)現(xiàn)和使用資源，它支持內(nèi)置的資源發(fā)現(xiàn)格式，用于發(fā)現(xiàn)設(shè)備上的資源列表，或者用于設(shè)備向服務(wù)目錄公告自己的資源。它支持RFC5785中的格式，在CoRE中用／．well—known／core的路徑表示資源描述。

　　支持緩存：CoAP協(xié)議支持資源描述的緩存以優(yōu)化其性能。

　　協(xié)議主要實(shí)現(xiàn)：

　　· libcoap（C語(yǔ)言實(shí)現(xiàn)）

　　· Californium（java語(yǔ)言實(shí)現(xiàn)）

　　點(diǎn)評(píng)：CoAP和6LowPan，這分別是應(yīng)用層協(xié)議和網(wǎng)絡(luò)適配層協(xié)議，其目標(biāo)是解決設(shè)備直接連接到IP網(wǎng)絡(luò)，也就是IP技術(shù)應(yīng)用到設(shè)備之間、互聯(lián)網(wǎng)與設(shè)備之間的通信需求。因?yàn)镮PV6技術(shù)帶來(lái)巨大尋址空間，不光解決了未來(lái)巨量設(shè)備和資源的標(biāo)識(shí)問題，互聯(lián)網(wǎng)上應(yīng)用可以直接訪問支持IPV6的設(shè)備，而不需要額外的網(wǎng)關(guān)。

　　MQTT協(xié)議（低帶寬）

　　MQTT （Message Queuing Telemetry Transport ），消息隊(duì)列遙測(cè)傳輸，由IBM開發(fā)的即時(shí)通訊協(xié)議，相比來(lái)說(shuō)比較適合物聯(lián)網(wǎng)場(chǎng)景的通訊協(xié)議。MQTT協(xié)議采用發(fā)布/訂閱模式，所有的物聯(lián)網(wǎng)終端都通過(guò)TCP連接到云端，云端通過(guò)主題的方式管理各個(gè)設(shè)備關(guān)注的通訊內(nèi)容，負(fù)責(zé)將設(shè)備與設(shè)備之間消息的轉(zhuǎn)發(fā)。

　　MQTT在協(xié)議設(shè)計(jì)時(shí)就考慮到不同設(shè)備的計(jì)算性能的差異，所以所有的協(xié)議都是采用二進(jìn)制格式編解碼，并且編解碼格式都非常易于開發(fā)和實(shí)現(xiàn)。最小的數(shù)據(jù)包只有2個(gè)字節(jié)，對(duì)于低功耗低速網(wǎng)絡(luò)也有很好的適應(yīng)性。有非常完善的QOS機(jī)制，根據(jù)業(yè)務(wù)場(chǎng)景可以選擇最多一次、至少一次、剛好一次三種消息送達(dá)模式。運(yùn)行在TCP協(xié)議之上，同時(shí)支持TLS（TCP+SSL）協(xié)議，并且由于所有數(shù)據(jù)通信都經(jīng)過(guò)云端，安全性得到了較好地保障。

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

　　特點(diǎn)：

　　· 使用基于代理的發(fā)布/訂閱消息模式，提供一對(duì)多的消息發(fā)布

　　· 使用 TCP/IP 提供網(wǎng)絡(luò)連接

　　· 小型傳輸，開銷很?。ü潭ㄩL(zhǎng)度的頭部是 2 字節(jié)），協(xié)議交換最小化，以降低網(wǎng)絡(luò)流量

　　· 支持QoS，有三種消息發(fā)布服務(wù)質(zhì)量：“至多一次”， “至少一次”， “只有一次”

　　協(xié)議主要實(shí)現(xiàn)和應(yīng)用：

　　· 已經(jīng)有PHP，JAVA，Python，C，C#等多個(gè)語(yǔ)言版本的協(xié)議框架

　　· IBM Bluemix 的一個(gè)重要部分是其 IoT FoundaTIon 服務(wù)，這是一項(xiàng)基于云的 MQTT 實(shí)例

　　· 移動(dòng)應(yīng)用程序也早就開始使用MQTT，如 Facebook Messenger 和com等

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