物聯網的體系結構

目前被廣泛認可的物聯網參考體系架構分為三層，分別是感知層、網絡層和應用層。

感知層：包括二維碼標簽和識讀器、RFID標簽和讀寫器、攝像頭、GPS、傳感器、M2M終端、傳感器網絡和傳感器網關等，主要功能是識別物體、采集信息。

網絡層：首先包括各種通信網絡與互聯網形成的融合網絡，除此之外還包括物聯網管理中心、信息中心、云計算平臺、專家系統等對海量信息進行智能處理的部分。

應用層：將物聯網技術與行業專業技術相結合，實現廣泛智能化應用的解決方案集。物聯網通過應用層最終實現信息技術與行業的深度融合，實現行業智能化。

就目前國內外物聯網的發展來看，并未能夠有效地指導整個物聯網產業，使之進入快速發展的通道。部分原因在于，該架構對于網絡層的描述過于概括，并且網絡層本身從語義上也容易讓人與互聯網協議中的網絡層產生混淆，因此一定程度上阻礙了人們對物聯網體系架構的認識。從現狀來看，目前業界對網絡層認識還處于相對粗淺的層次，物聯網產業界還沒有充分發展網絡層中對物聯網業務發展起到重大推動作用的物聯網支撐平臺，大多數應用仍只是把網絡層當作物聯網數據的傳輸通道，尚未利用網絡層所提供的物聯網運營支撐能力和業務支撐能力。

對于物聯網體系架構的理解不能僅從網絡的視角觸發，而應該把物聯網當作一個完整的系統來看待，從全局的角度觸發，系統地考慮物聯網建設與發展過程中，需要涉及的各個環節、所在的層級及它們之間的聯系。結合信息流的流向，以及產業關聯對象來梳理物聯網架構中各個層次，可以將物聯網架構分為四個層次，分別是感知及控制層、網絡層、平臺服務層和應用服務層。

物聯網平臺是物聯網產業鏈的樞紐，向下接入分散的物聯網傳感層，匯集傳感數據，向上面向應用服務提供商提供應用開發的基礎性平臺和面向底層網絡的統一數據接口，支持具體的基于傳感數據的物聯網應用。

感知與控制層：通過從傳感器、計量器等器件獲取環境、資產或者運營狀態信息，在進行適當的處理之后，通過傳感器傳輸網關將數據傳遞出去；同時通過傳感器接收網關接收控制指令信息，在本低傳遞給控制器件達到控制資產、設備及運營的目的。在此層次中，感知及控制器件的管理、傳輸與接收網關、本低數據及信號處理是重要的技術。

網絡層：通過公網或者專網以無線或者有線的通信方式將信息、數據與指令在感知與控制層、平臺服務層、應用層服務之間傳遞，主要由運營商提供的各種廣域IP通信網絡組成，包括ATM、xDSL、光纖等有線網絡，以及GPRS、3G、4G、NB-IoT等移動通信網絡。

平臺服務層：物聯網平臺是物聯網網絡架構和產業鏈條中的關鍵環節，通過它不僅實現對終端設備和資產的“管、控、營”一體化，向下連接感知層，向上面向應用服務提供商提供應用開發能力和統一接口，并未各行各業提供通用的服務能力，如數據路由、數據處理與挖掘、仿真與優化、業務流程和應用整合、通信管理、應用開發設備維護服務等。

應用服務層：豐富的應用是物聯網的最終目標，未來基于政府、企業、消費者三類群體將衍生出多樣化的物聯網應用，創造巨大的社會價值。根據企業業務需要，在平臺服務層之上建立相關的物聯網應用，例如，城市交通情況的分析與預測，城市資產狀態監控與分析，環境狀態監控、分析與預警（如風力、雨量、滑坡），健康狀況監測與醫療方案建議等。

物聯網三大協議

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

要說起實時通信技術的發展演變，我們就不能不提即時通訊方案的出現。從歷史角度講，即時通訊產品可以算是最早出現的客戶友好型聯網實時通信客戶端。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被設計為一種輕量化協議，而內置加密的方式會給傳輸連接增加很大負擔。雖然我們也能夠在應用程序層級添加定制化安全機制，但這可能需要進行大量的調整工作。