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

通信協(xié)議

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

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

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

TCP/IP 協(xié)議

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

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

UDP 協(xié)議

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

HTTP 協(xié)議

在IoT 開發(fā)中協(xié)議最大的不同是在 OSI 模型的應用程序層。這一層在通信網絡中指定了接口方法。系統(tǒng)如何連接服務器且數據如何發(fā)送都由這一層來決定。

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

MQTT 協(xié)議

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

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

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

MQTT 包括代理和客戶端兩個部分。客戶端可以訪問或修改設備的數據，代理是持有并傳遞數據。

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

MQTT 提供一個有質量的服務，從 IoT 角度來看，其本質是消息的優(yōu)先級。在任何情況下一個重要的消息可以傳輸到目的地，因此有了服務質量（QoS），雖然傳輸速度會變慢但是交付有了保證。一個動態(tài)的數據源速度優(yōu)先于效率，然而分配一個較低的 QoS，更像是一個“fire-and-forget”事件，如 UDP。

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

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

CoAP 協(xié)議

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

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

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

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

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

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