對于軟件公司來說,，IoT 模式為其硬件設(shè)計以及所提供的服務(wù)帶來決定性的改變,。其中影響最大的一個方面是通信協(xié)議。

通信協(xié)議可以被認(rèn)為是一種語言,，即兩臺或兩臺以上的設(shè)備可以相互交流,。同時無規(guī)矩不成方圓，通信協(xié)議也遵循一組規(guī)則,，兩臺設(shè)備會將有意義的信息傳遞給對方,。在分布式系統(tǒng)中通信協(xié)議極為重要，相同的協(xié)議不同的部分在多個位置獨立運行,。系統(tǒng)在運行進(jìn)程時可能是多樣化的,，因此在系統(tǒng)中需要保證一組通用的指令來通信。

IoT 之所以可以掀起熱潮,，信息物理融合系統(tǒng)（Cyber-Physical Systems,，簡稱CPS）功不可沒。物理設(shè)備連接到互聯(lián)網(wǎng)和傳遞數(shù)據(jù)及接收數(shù)據(jù)的概念基于 IoT 解決方案的真正地實現(xiàn),。與此同時,，這也增加了現(xiàn)有的通信協(xié)議及互聯(lián)網(wǎng)的復(fù)雜性。

IoT 的發(fā)展歷程中帶來了很多可能性,，但其中唯一可行的是機器與機器（M2M）通過互聯(lián)網(wǎng)實現(xiàn)實時有效連接,。一臺設(shè)備被連接到互聯(lián)網(wǎng)僅被認(rèn)為是人際互動間的產(chǎn)物，而不是一個順其自然的結(jié)果,。因此,，協(xié)議與互聯(lián)網(wǎng)之間的通信總是在不可靠與緩慢的基礎(chǔ)上發(fā)展。

TCP/IP,、UDP、HTTP,、MQTT,、CoAP這五種協(xié)議的概述

除了通信協(xié)議,，互聯(lián)網(wǎng)協(xié)議體系結(jié)構(gòu)的另一個方面是 TCP / IP 堆棧,。它控制兩臺計算機之間的數(shù)據(jù)傳輸。其中采用三次握手建立一個連接,，其中涉及客戶端確認(rèn)數(shù)據(jù)的接收且發(fā)送確認(rèn)消息給服務(wù)器,。第二次握手是服務(wù)器端接收到客戶端的數(shù)據(jù)后,，返回確認(rèn)回單，第三次是客戶端也返回一個確認(rèn)回單給服務(wù)器端,，從而關(guān)閉通信通道,。

這種通信方法的優(yōu)點具有可靠性，可共享所有被發(fā)送的數(shù)據(jù),，但因為其過程都需要驗證,，所以消耗時間比較久。

用戶數(shù)據(jù)報協(xié)議（User Datagram Protocol,，簡稱UDP）是一種比較快的通信方式,，因為減少了確認(rèn)程序。它是面向非連接的協(xié)議,，它不與對方建立連接,，而是直接就把數(shù)據(jù)包發(fā)送過去。因此,，與 TCP/IP 相比,，UDP 的可靠性相對不高，但是比較快,。對于M2M 項目的快速原型，一個非常簡單的解決方案是使用 UDP,，因為就 UDP 頭包含很少的字節(jié),，比 TCP 負(fù)載消耗少。

在IoT 開發(fā)中協(xié)議最大的不同是在 OSI 模型的應(yīng)用程序?qū)印?/strong>這一層在通信網(wǎng)絡(luò)中指定了接口方法,。系統(tǒng)如何連接服務(wù)器且數(shù)據(jù)如何發(fā)送都由這一層來決定。

其實最受歡迎的通信協(xié)議莫過于超文本傳輸協(xié)議（Hyper Text Transfer Protocol,，簡稱HTTP）,。主要應(yīng)用于 web 瀏覽器。它運行在一個客戶/服務(wù)器模型上,，服務(wù)器響應(yīng)任何的客戶端需求,。因 web 網(wǎng)頁可能會加載很多內(nèi)容，因此該協(xié)議有必要建立在 TCP/IP 堆棧之上,。

MQ 遙測傳輸（MQ Telemetry Transport,，簡稱MQTT）是一個面向 IoT 應(yīng)用程序的輕量級連接協(xié)議。它基于 TCP/IP 網(wǎng)絡(luò)連接使用發(fā)布/訂閱方法來傳輸數(shù)據(jù),。設(shè)計思想是開放,、簡單、輕量,、易于實現(xiàn),，這也使它成為 IoT 開發(fā)的理想平臺。

MQTT 很多有用的功能適用面向 IoT 應(yīng)用程序,。簡而言之,，想象一個公告板，無論什么時候,，你都可以在上面記錄或招貼,。同時，對你所記錄的內(nèi)容感興趣的任何人都可以看到,。

MQTT 差不多就是這樣的功能,。

MQTT 包括代理和客戶端兩個部分?？蛻舳丝梢栽L問或修改設(shè)備的數(shù)據(jù),，代理是持有并傳遞數(shù)據(jù)。

MQTT 使用發(fā)布/訂閱消息模式,?？蛻舳丝梢栽谝粋€話題（Topic）下面發(fā)布特定參數(shù)數(shù)據(jù)給代理。另一個對此話題感興趣的客戶可以訂閱該話題,，并定期收到更新的消息,。

MQTT 提供一個有質(zhì)量的服務(wù)，從 IoT 角度來看,，其本質(zhì)是消息的優(yōu)先級,。在任何情況下一個重要的消息可以傳輸?shù)侥康牡兀虼擞辛朔?wù)質(zhì)量（QoS）,，雖然傳輸速度會變慢但是交付有了保證,。一個動態(tài)的數(shù)據(jù)源速度優(yōu)先于效率，然而分配一個較低的 QoS,，更像是一個“fire-and-forget”事件,，如 UDP。

在一個主題下,，MQTT 可以保留最后一個已收到的消息,，前提是它發(fā)送給訂閱者訂閱鏈已啟動。這允許訂閱者在一個存在的客戶端和代理網(wǎng)絡(luò)中異步連接。這也為檢查冗余及數(shù)據(jù)丟失提供了一個工具,。

MQTT 客戶端有一個屬性稱之為 Last Will a和 Testament,。該屬性允許客戶端在異常中斷的情況下發(fā)送通知給代理。這個快速的反饋有利于無線傳感器網(wǎng)絡(luò)自動再生,，同時檢測并修復(fù)缺失節(jié)點和異常值,，最終確保無線傳感器網(wǎng)絡(luò)中數(shù)據(jù)流完美循環(huán)。

CoAP 是一個基于 REST 模型的網(wǎng)絡(luò)傳輸協(xié)議,。主要用于輕量級 M2M 通信。由于物聯(lián)網(wǎng)中的很多設(shè)備都是資源受限型的,，即只有少量的內(nèi)存空間和有限的計算能力,，所以傳統(tǒng)的 HTTP 協(xié)議應(yīng)用在物聯(lián)網(wǎng)上就顯得過于龐大而不適用，CoAP 應(yīng)運而生,。

就用戶可見性而言,，CoAP 模擬了 HTTP 協(xié)議，并從這個角度來看,，讀數(shù)傳感器數(shù)據(jù)本質(zhì)上是像做一個 HTTP 請求,。

CoAP 被認(rèn)為是一種不會過時的技術(shù)協(xié)議，根據(jù) Grtner 預(yù)測,，500 億臺設(shè)備將會連接到互聯(lián)網(wǎng),，未來進(jìn)一步發(fā)展將迫切需要低成本、低能耗的設(shè)備,。CoAP協(xié)議被設(shè)計用于與 10 kb RAM 一樣的系統(tǒng),。

CoAP 更有趣的功能之一是能夠發(fā)現(xiàn)網(wǎng)絡(luò)中的節(jié)點,。這對于低功耗無線傳感器網(wǎng)絡(luò)的自治和自我修復(fù)設(shè)計非常有用,。關(guān)于無線傳感器網(wǎng)絡(luò)的可擴展性問題，可以使用 CoAP 協(xié)議來發(fā)現(xiàn)節(jié)點常規(guī)的冗余,。

CoAP 是建立在 UDP 棧上,，這是與 HTTP 或 MQTT 相比最主要的區(qū)別。它可以更加快速和更好的資源優(yōu)化,，而非資源密集型,。

然而，在 CoAP 協(xié)議下 QoS 因素保持不變情況下,，CoAP 相比 HTTP/MQTT 更加不可靠,。但是 4 字節(jié)的頭文件對于連續(xù)流系統(tǒng)如環(huán)境監(jiān)測傳感器網(wǎng)絡(luò)是一個不錯的選擇。

來源：電子發(fā)燒友