實時通信技術作為一項根本性前提，在物聯網應用程序的開發工作中扮演著核心角色。想象一下，如果我們能夠利用手機與家居環境內的各種小裝置進行通信，那么科幻電影中的種種場景將很快變成現實。但如果整個通信過程需要數秒才能完成，那么使用體驗無疑會大打折扣。

要說起實時通信技術的發展演變，我們就不能不提即時通訊方案的出現。從歷史角度講，即時通訊產品可以算是最早出現的客戶友好型聯網實時通信客戶端。AOL IM、ICQ以及Jabber正是各類支持實時通信的即時通訊方案中的典型代表。而這一切早在上世紀九十年代就已然出現了。

時至今日，我們開始將著眼點放在開發作用于不同物聯網設備之間的通信協議——不過當初構建即時通訊解決方案時積累到的經驗仍然適用。目前物聞網設備所廣泛使用的三大實時協議包括：XMPP、CoAP以及MQTT。有趣的是，其中的XMPP早在Jabber時代就已經作為一套開放即時通訊協議存在了。

XMPP

XMPP的全稱為可擴展通訊與表示協議。這項立足于XML的TCP通信協議能夠以近實時方式在兩個甚至更多聯網功能實體之間進行結構化數據交換。XMPP當中的現成功能包括表示信息以及聯系人名單維護。盡管這兩項功能最初都是針對即時通訊需求設計而成，但它們在物聯網應用程序當中仍然能夠起到不錯的效果。鑒于其出色的開放特性并以XML為基礎，XMPP已經被擴展至各類公共訂閱系統當中——而這也恰好適合物聯網應用的實際需求。

利用XMPP作為物聯網通信協議，我們能夠享受到幾大突出優勢。首先就是XMPP的分散特性。XMPP的運作方式與電子郵件比較相似，游走于由傳輸代理構建而成的分布式網絡當中，而非高度依賴于單一中央服務器或者代理節點(CoAP與MQTT皆屬于這種情況)。與電子郵件一樣，每個人都能夠輕松運行屬于自己的XMPP服務器，這就使得設備制造商以及API供應方能夠創建并管理自己的設備網絡體系。而由于大家都有能力運行自己的服務器，所以出于安全考慮，我們可以在必要時利用內置TLS加密機制將該服務器隔離在企業內網的安全驗證協議之下。

遺憾的是，XMPP也存在著一些弊端。其***的問題之一就是缺少端到端加密機制。盡管在不少場景之下，這類加密機制基本算是可有可無，但歸根結底大多數物聯網設備仍然需要利用加密來保障安全。端到端加密機制的缺失無疑會令物聯網設備制造商陷入被動當中。

XMPP的另一個問題在于不具備服務質量(簡稱QoS)控制。在物聯網領域，確保消息交付的重要性甚至比即時通訊領域還要高。如果大家的警報系統沒能切實收到相關信息并正確觸發，那么接下來的后續影響可能會非常可怕。

CoAP

CoAP的全稱為受限應用協議，其開發目的在于允許資源相對有限的設備利用UDP而非TCP通過互聯網實現通信。開發人員可以同任意支持CoAP的設備進行交互，具體方式與采用傳統REST API的設備完全一致。CoAP的主要適用場景包括低功耗傳感器以及需要通過互聯網加以控制的設備。

CoAP是一種簡單的請求/響應協議(與REST非常相似)，且遵循傳統的客戶端/服務器模式。客戶端可以面向資源發出GET、PUT、POST以及DELETE等請求。CoAP數據包采用位字段以***限度提升內存利用效率，且經常將字符串映射至整數以降低數據包在設備內部以及網絡中傳輸時所占用的帶寬。除了數據包體積極度小巧之外，CoAP的另一大優勢在于其采用UDP;數據報文使得CoAP能夠在各類基于數據包的技術之上起效——例如短信。

所有CoAP消息皆可被標記為“確認”或者“未確認”，并作為應用層級的QoS機制。盡管SSL/TLS加密無法在UDP之上實現，但CoAP使用數據傳輸層安全(簡稱DTLS)作為替代——其可以算是TLS的TCP版本。默認加密級別相當于一條3072位的RSA密鑰。盡管包含這些強大的安全保障能力，CoAP仍然能夠運行在內存僅為10 KB的微控制器當中。

CoAP的弊端之一在于，它屬于一對一協議。盡管我們可以通過擴展方式實現組廣播，但這種廣播能力并非原生存在。除此之外，CoAP的另一大缺陷在于不提供公共訂閱消息隊列。

MQTT

MQTT的全稱為消息隊列遙測傳輸，這是一種公共訂閱消息收發協議。與CoAP類似，它在設計當中同樣考慮到運行設備資源有限的狀況。MQTT采用輕量級數據包結構設計，旨在***程度節約內存使用量及運行功耗。聯網設備以訂閱方式監聽托管在MQTT代理端的話題。每一次在其它設備或者服務向該話題發送數據，所有參與訂閱的設備都將自動獲取到這一更新信息。

MQTT的***優勢在于其公共訂閱消息隊列機制以及多對多廣播能力。有了指向MQTT代理端的長效TCP連接的支持，以有限帶寬進行消息收發變得簡單而輕松。

MQTT的短板在于，其始終存在的連接限制了設備進入休眠狀態的整體時長。如果相關設備在運行中多數處于休眠狀態，我們不妨優先選擇另一種MQTT協議——MQTT-S，其利用UDP取代原始協議中的TCP。

MQTT的另一大弊端是缺少基礎協議層面的加密機制。MQTT被設計為一種輕量化協議，而內置加密的方式會給傳輸連接增加很大負擔。雖然我們也能夠在應用程序層級添加定制化安全機制，但這可能需要進行大量的調整工作。

物聯網基礎知識

對于每一位有意發揮物聯網技術全部固有優勢的開發人員來說，了解底層協議都是必不可少的一環。隨著這一領域的不斷升溫，我們在不同設備之間建立高效通信連接時將面臨更多技術難題。更重要的是，要想創建出不僅可以與設備交互、更能對其加以控制的API，實時通信的作用可謂不言而喻。當初以幫助人們實現遠程通信為目標而誕生的互聯網，如今開始衍生出更多更加靈活的使用方式。

作為開發人員，我們有責任探索所有值得發掘的使用方式。了解各類協議及其優缺點將幫助我們構建起出色的解決方案。不過值得強調的是，將實時通信機制添加到技術堆棧當中也將加快我們的開發流程。目前已經有多種后端即服務平臺提供現成的實時通信機制。在大多數情況下，我們都能夠利用Firebase、Socket.io或者Built.io構建起自己的物聯網平臺，而且這種方式也能為大家節省下大量開發時間。不過為了盡可能多地收集相關選項并找到最適合當下需求的技術堆棧，我們也有理由對各類現有方案進行深入了解。

原文標題：Know your real-time protocols for IoT apps