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

通信協(xié)議

通信協(xié)議可以被認為是一種語言，即兩臺或兩臺以上的設(shè)備可以相互交流。同時無規(guī)矩不成方圓，通信協(xié)議也遵循一組規(guī)則，兩臺設(shè)備會將有意義的信息傳遞給對方。在分布式系統(tǒng)中通信協(xié)議極為重要，相同的協(xié)議不同的部分在多個位置獨立運行。系統(tǒng)在運行進程時可能是多樣化的，因此在系統(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)僅被認為是人際互動間的產(chǎn)物，而不是一個順其自然的結(jié)果。因此，協(xié)議與互聯(lián)網(wǎng)之間的通信總是在不可靠與緩慢的基礎(chǔ)上發(fā)展。
 

 

TCP/IP 協(xié)議

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

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

UDP 協(xié)議

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

HTTP 協(xié)議

在IoT 開發(fā)中協(xié)議最大的不同是在 OSI 模型的應(yīng)用程序?qū)?。這一層在通信網(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 堆棧之上。

MQTT 協(xié)議

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 協(xié)議

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 被認為是一種不會過時的技術(shù)協(xié)議，根據(jù) Grtner 預(yù)測，500 億臺設(shè)備將會連接到互聯(lián)網(wǎng)，未來進一步發(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ò)是一個不錯的選擇。