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

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

時(shí)至今日，我們開始將著眼點(diǎn)放在開發(fā)作用于不同物聯(lián)網(wǎng)設(shè)備之間的通信協(xié)議——不過當(dāng)初構(gòu)建即時(shí)通訊解決方案時(shí)積累到的經(jīng)驗(yàn)仍然適用。目前物聞網(wǎng)設(shè)備所廣泛使用的三大實(shí)時(shí)協(xié)議包括：XMPP、CoAP以及MQTT。有趣的是，其中的XMPP早在Jabber時(shí)代就已經(jīng)作為一套開放即時(shí)通訊協(xié)議存在了。

XMPP

XMPP的全稱為可擴(kuò)展通訊與表示協(xié)議。這項(xiàng)立足于XML的TCP通信協(xié)議能夠以近實(shí)時(shí)方式在兩個(gè)甚至更多聯(lián)網(wǎng)功能實(shí)體之間進(jìn)行結(jié)構(gòu)化數(shù)據(jù)交換。XMPP當(dāng)中的現(xiàn)成功能包括表示信息以及聯(lián)系人名單維護(hù)。盡管這兩項(xiàng)功能最初都是針對(duì)即時(shí)通訊需求設(shè)計(jì)而成，但它們?cè)谖锫?lián)網(wǎng)應(yīng)用程序當(dāng)中仍然能夠起到不錯(cuò)的效果。鑒于其出色的開放特性并以XML為基礎(chǔ)，XMPP已經(jīng)被擴(kuò)展至各類公共訂閱系統(tǒng)當(dāng)中——而這也恰好適合物聯(lián)網(wǎng)應(yīng)用的實(shí)際需求。

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

遺憾的是，XMPP也存在著一些弊端。其***的問題之一就是缺少端到端加密機(jī)制。盡管在不少場(chǎng)景之下，這類加密機(jī)制基本算是可有可無，但歸根結(jié)底大多數(shù)物聯(lián)網(wǎng)設(shè)備仍然需要利用加密來保障安全。端到端加密機(jī)制的缺失無疑會(huì)令物聯(lián)網(wǎng)設(shè)備制造商陷入被動(dòng)當(dāng)中。

XMPP的另一個(gè)問題在于不具備服務(wù)質(zhì)量(簡(jiǎn)稱QoS)控制。在物聯(lián)網(wǎng)領(lǐng)域，確保消息交付的重要性甚至比即時(shí)通訊領(lǐng)域還要高。如果大家的警報(bào)系統(tǒng)沒能切實(shí)收到相關(guān)信息并正確觸發(fā)，那么接下來的后續(xù)影響可能會(huì)非?？膳隆?/p>

CoAP

CoAP的全稱為受限應(yīng)用協(xié)議，其開發(fā)目的在于允許資源相對(duì)有限的設(shè)備利用UDP而非TCP通過互聯(lián)網(wǎng)實(shí)現(xiàn)通信。開發(fā)人員可以同任意支持CoAP的設(shè)備進(jìn)行交互，具體方式與采用傳統(tǒng)REST API的設(shè)備完全一致。CoAP的主要適用場(chǎng)景包括低功耗傳感器以及需要通過互聯(lián)網(wǎng)加以控制的設(shè)備。

CoAP是一種簡(jiǎn)單的請(qǐng)求/響應(yīng)協(xié)議(與REST非常相似)，且遵循傳統(tǒng)的客戶端/服務(wù)器模式?？蛻舳丝梢悦嫦蛸Y源發(fā)出GET、PUT、POST以及DELETE等請(qǐng)求。CoAP數(shù)據(jù)包采用位字段以***限度提升內(nèi)存利用效率，且經(jīng)常將字符串映射至整數(shù)以降低數(shù)據(jù)包在設(shè)備內(nèi)部以及網(wǎng)絡(luò)中傳輸時(shí)所占用的帶寬。除了數(shù)據(jù)包體積極度小巧之外，CoAP的另一大優(yōu)勢(shì)在于其采用UDP;數(shù)據(jù)報(bào)文使得CoAP能夠在各類基于數(shù)據(jù)包的技術(shù)之上起效——例如短信。

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

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

MQTT

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

MQTT的***優(yōu)勢(shì)在于其公共訂閱消息隊(duì)列機(jī)制以及多對(duì)多廣播能力。有了指向MQTT代理端的長(zhǎng)效TCP連接的支持，以有限帶寬進(jìn)行消息收發(fā)變得簡(jiǎn)單而輕松。

MQTT的短板在于，其始終存在的連接限制了設(shè)備進(jìn)入休眠狀態(tài)的整體時(shí)長(zhǎng)。如果相關(guān)設(shè)備在運(yùn)行中多數(shù)處于休眠狀態(tài)，我們不妨優(yōu)先選擇另一種MQTT協(xié)議——MQTT-S，其利用UDP取代原始協(xié)議中的TCP。

MQTT的另一大弊端是缺少基礎(chǔ)協(xié)議層面的加密機(jī)制。MQTT被設(shè)計(jì)為一種輕量化協(xié)議，而內(nèi)置加密的方式會(huì)給傳輸連接增加很大負(fù)擔(dān)。雖然我們也能夠在應(yīng)用程序?qū)蛹?jí)添加定制化安全機(jī)制，但這可能需要進(jìn)行大量的調(diào)整工作。

物聯(lián)網(wǎng)基礎(chǔ)知識(shí)

對(duì)于每一位有意發(fā)揮物聯(lián)網(wǎng)技術(shù)全部固有優(yōu)勢(shì)的開發(fā)人員來說，了解底層協(xié)議都是必不可少的一環(huán)。隨著這一領(lǐng)域的不斷升溫，我們?cè)诓煌O(shè)備之間建立高效通信連接時(shí)將面臨更多技術(shù)難題。更重要的是，要想創(chuàng)建出不僅可以與設(shè)備交互、更能對(duì)其加以控制的API，實(shí)時(shí)通信的作用可謂不言而喻。當(dāng)初以幫助人們實(shí)現(xiàn)遠(yuǎn)程通信為目標(biāo)而誕生的互聯(lián)網(wǎng)，如今開始衍生出更多更加靈活的使用方式。

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

原文標(biāo)題：Know your real-time protocols for IoT apps