物聯網基礎

總體結構

物聯網大致上有 3 個構成要素，如圖 2.1 所示。一個是設備，另外一個是網關，再來就是服務器。

圖 2.1　物聯網的總體結構

2.1.2　網關

如圖 2.1 左下所示，物聯網使用的設備中，有 3 臺設備不能直接鏈接到互聯網。網關就負責把這些設備轉發到互聯網。

網關指的是能鏈接多臺設備，並具有直接鏈接到互聯網的功能的機器和軟件（圖 2.2）。現在，市面上有不少種網關。在多數狀況下，網關憑藉 Linux 操做系統來運行。

圖 2.2　選擇網關的標準

選擇網關時有幾項重要的標準，咱們來一塊兒看一下。

◉ 接口

第一重要的是用於鏈接網關和設備的接口。網關的接口決定了能鏈接的設備，所以重點在於選擇一個適配設備的接口。

有線鏈接方式包括串行通訊和 USB 鏈接。串行通訊中常常用的是一種叫做 D-SUB 9 針（pin）的鏈接器，而 USB 鏈接中用到的 USB 鏈接器則種類繁多。

無線鏈接中用的接口是藍牙和 Wi-Fi（IEEE 802.11）。此外，還有采用 920 MHz 頻段的 Zigbee 標準，以及各製造商們的專屬協議。第 3 章會詳細講解這些規格各自的特徵，重點在於根據設備對應的標準來選擇接口。

◉ 網絡接口

咱們用以太網或是 Wi-Fi、3G/LTE 來鏈接外部網絡。網絡接口會影響到網關的設置場所。以太網採用有線鏈接，通訊環境穩定。然而正由於採用的是有線鏈接，因此必須把 LAN 電纜佈線到網關的設置場所。所以，在設置場所方面就會在某種程度上受到限制。

對 3G/LTE 鏈接而言，設置場所就比較自由了，但通訊的質量會受信號強弱影響，因此通訊不若有線鏈接穩定。所以，有時很難在信號不良的大樓和工廠等封閉環境中設置。不過，3G/LTE 鏈接有個好處，即只使用網關就能完成和外部的通訊，所以操做起來很簡單。此外，想使用 3G/LTE 時，須要和電信運營商簽定協議並獲取 SIM 卡，這點就跟使用手機同樣。

網關的做用

就如咱們前面說的那樣，網關是一臺用於把不能直接鏈接到互聯網的設備轉發鏈接到互聯網的設備。再往細了說，網關是由 3 種功能構成的（圖 2.4）。

圖 2.4　網關的功能

2.1.3　服務器的結構

在功能方面，物聯網服務大致上可分爲 3 個部分，本書分別稱它們爲前端部分、處理部分，以及數據庫部分（圖 2.3）。

圖 2.3　物聯網服務的 3 個功能

首先，前端部分包括數據接收服務器和數據發送服務器。數據接收服務器接收設備和網關發來的數據，轉交給後續的處理部分。數據發送服務器則恰好相反，它負責把從處理服務器接收到的內容發送給設備。

一般狀況下，Web 服務的前端部分只接受 HTTP 協議。而物聯網服務的前端部分則須要根據鏈接設備的不一樣來匹配 HTTP 之外的協議。使用者須要考慮到協議的實時性和通訊的輕量化，以及可否以服務器爲起點發送數據。咱們會在 2.2 節從新講解這些協議。

處理部分負責處理從前端部分接收到的數據。這裏的「處理」指的是分解數據、存儲數據、分析數據、生成發給設備的通知內容，等等。數據處理包括批處理和流處理等，批處理即把數據存入數據庫以後一併進行處理，而流處理是逐次處理從前端部分收到的數據。使用者須要根據處理內容和數據特性來靈活使用這些「處理」。

最後是數據庫。這裏的數據庫不僅會用到關係數據庫，還會用到 NoSQL 數據庫。固然，使用者須要根據想存儲的數據和想使用的方法來選擇數據庫。

2.3.1　HTTP 協議

HTTP 協議提供的是最大衆化且最簡易的方法。使用通常的 Web 框架就能夠製做數據接收服務器。設備用 HTTP 的 GET 方法和 POST 方法訪問服務器，把數據存入請求參數和 BODY 併發送（圖 2.6）。

圖 2.6　經過 HTTP 協議發送和接收數據

HTTP 協議是 Web 的標準協議，這一點自不用說。所以 HTTP 協議和 Web 的兼容性很是強。此外，由於 HTTP 協議有很是多的技術訣竅，因此咱們必須在製做實際系統時審視服務器的結構，應用程序的架構以及安全性等。關於這點，有不少事例值得參考。另外，HTTP 協議還準備了 OSS 的框架，方便人們使用。

2.3.3　WebSocket

WebSocket 是一種通訊協議，用於在互聯網上實現套接字通訊。它實現了 Web 瀏覽器和 Web 服務器間的數據雙向連續傳輸。

就 HTTP 協議而言，每次發送數據都必須生成發送數據用的通訊路徑及鏈接。此外，通常狀況下，客戶端沒有發出申請就不能進行通訊。

相對而言，WebSocket 就不一樣了。只要一開始根據客戶端發出的鏈接申請確立了鏈接，就能持續用同一個鏈接傳輸數據。另外，只要確立了鏈接，就算客戶端沒有發出申請，服務器也能給客戶端發送數據（圖 2.7）。

圖 2.7　經過 WebSocket 協議傳輸數據

這樣一來，在發送語音數據等連續的數據，以及發生與服務器的相互交換時，就能使用 WebSocket 了。WebSocket 自身只提供服務器與客戶端的數據交換，所以須要使用者另外決定在應用層上使用的協議。

2.3.4　MQTT

MQTT（MQ Telemetry Transport，消息隊列遙測傳輸）是近年來出現的一種新型協議，物聯網領域會將其做爲標準協議。MQTT 本來是 IBM 公司開發的協議，如今則開源了，被人們不斷開發着。

MQTT 是一種能實現一對多通訊（人們稱之爲發佈或訂閱型）的協議。它由 3 種功能構成，分別是中介（broker）、發佈者（publisher）和訂閱者（subscriber）（圖 2.8）。

圖 2.8　經過 MQTT 傳輸消息

◉ QoS

QoS 是 Quality of Service（服務質量）的簡稱。這個詞在網絡領域表示的是通訊線路的品質保證。MQTT 裏存在 3 個等級的 QoS。「發佈者和中介之間」以及「中介和訂閱者之間」都分別定義了不一樣的 QoS 等級，以異步的方式運行。此外，當「中介與訂閱者之間」指定的 QoS 小於「發佈者和中介之間」交換的 QoS 時，「中介與訂閱者之間」的 QoS 會被降級到指定的 QoS。QoS 0 指的是最多發送一次消息（at most once）（圖 2.11），發送要遵循 TCP/IP 通訊的「盡力服務」。消息分兩種狀況，即到達了一次中介處，或沒有到達中介處。

圖 2.11　QoS 0（最多隻能發送一次）

接下來的 QoS 1 是至少發送一次消息（at least once）（圖 2.12）。

圖 2.12　QoS 1（至少發送一次消息）

中介一接收到消息就會向發佈者發送一個叫做「PUBACK 消息」的響應，除此以外還會根據訂閱者指定的 QoS 發送消息。當發生故障，或通過必定時間後仍沒能確認 PUBACK 消息時，發佈者會從新發送消息。若是中介接收了發佈者發來的消息卻沒有返回 PUBACK，那麼中介會重複收到消息。

最後是 QoS 2，它指的是準確發送一次消息（exactly once）。把它跟 QoS 1 合在一塊兒使用，就能避免接收到重複的消息（圖 2.13）。用 QoS 2 發送的消息裏面含有消息 ID。中介收到消息後會將消息保存，而後給發佈者發送 PUBREC 消息。發佈者再給中介發送 PUBREL 消息，而後中介會給發佈者發送 PUBCOMP 消息。接下來中介纔會依據訂閱者指定的 QoS，向訂閱者傳遞接收到的消息。

圖 2.13　QoS 2（只發送一次消息）

此外，就 QoS 2 而言，有時使用的中介會影響消息的傳遞時間。

人們一般使用的是 QoS 0，只有要確保信息發送成功時才使用 QoS 1 和 QoS 2，這樣一來能夠減小網絡的負擔。後文將會講到 Clean session，其中 QoS 的設定也是很是重要的。

◉ Retain

訂閱者只能接收在訂閱以後發佈的消息，但若是發佈者事先發布了帶有 Retain 標誌的消息，那麼訂閱者就能在訂閱後立刻收到消息。

當發佈者發佈了帶有 Retain 標誌的消息時，中介會把消息傳遞給訂閱了主題的訂閱者，同時保存帶有 Retain 標誌的最新的消息。此時，若別的訂閱者訂閱了主題，就能立刻收到帶有 Retain 標誌的新消息（圖 2.14）。

圖 2.14　Retain

◉ Will

Will 有「遺言」的意思。因爲中介的 I/O 錯誤或網絡故障等狀況，發佈者可能會忽然從中介斷開，Will 就是專門針對於這種狀況的一個機構，它用於定義中介向訂閱者發送的消息（圖 2.15）。

圖 2.15　Will

發佈者在鏈接中介時會用到 CONNECT（鏈接）消息，鏈接時對其指定 Will 標誌、要發送的消息以及 QoS。這樣一來，若是鏈接意外斷開，Will 消息就會被傳遞給訂閱者。另外，還有一個標誌叫做 Will Retain。經過指定這個標誌，就能跟前面說的 Retain 達到一樣的效果，即在中介處保存消息。

當發佈者使用 DISCONNECT（斷開鏈接）消息明確代表鏈接已斷開時，Will 消息就不會被髮送給訂閱者。

◉ Clean session

Clean session 用於指定中介是否保留了訂閱者的已訂閱狀態。用 CONNECT 消息鏈接時，訂閱者把 Clean session 標誌設定爲 0 或 1。0 是保留 session，1 是不保留 session。

若指定 Clean session 爲 0 且中介已經鏈接上了訂閱者，則中介須要在訂閱者斷開鏈接後保留訂閱的消息。另外，若是訂閱者的鏈接已經斷開，且發佈者已經發布了 QoS 一、QoS 2 的消息給已訂閱的主題時，中介則會把消息保存，等訂閱者再次鏈接時發送給訂閱者（圖 2.16）。

圖 2.16　Clean session

若指定 Clean session 爲 1 並鏈接，中介就會廢棄以往保留的客戶端信息，將其當成一次「乾淨」的鏈接來看待。此外，訂閱者斷開鏈接時，中介也會廢棄全部的信息。

咱們能夠用表 2.1 所示的幾種產品來實現 MQTT。是否支持前文介紹的功能則取決於中介的種類。

表 2.1　MQTT 的實現

除此以外，一個叫做 Paho 的庫還公開了發佈者和訂閱者等客戶端功能。不只 Java、JavaScript、Python 配備了 Paho，連 C 語言和 C++ 都配備了 Paho。所以，咱們可以將其與設備結合起來並加以使用。

數據格式

前面咱們圍繞用於接收數據的通訊過程，即協議進行了講解。事實上，數據就是經過協議來進行交換的。固然，就如咱們前文所說，這條規則在物聯網的世界裏也是不變的。數據要通過協議進行交換，而數據的格式也很重要。經過 Web 協議來使用的數據格式中，具備表明性的包括 XML 和 JSON（圖 2.17）。

數據處理

很顯然，處理服務器就是處理接收到的數據的地方。「處理」是一個抽象的詞語，例如保存數據，以及轉換數據以使其看上去更易懂，還有從多臺傳感器的數據中發現新的數據，這些都是處理。使用者的目的不一樣，處理服務器的內容也各異。不過說到數據的處理方法，它能夠概括成如下 4 種：數據分析、數據加工、數據保存以及向設備發出指令（圖 2.20）。

圖 2.20　數據的處理

關於數據的分析和加工，有兩種典型的處理方式，分別叫做「批處理」和「流處理」。首先就來講說這個「批處理」和「流處理」。

批處理

◉ Apache Hadoop

Apache Hadoop 是一個對大規模數據進行分佈式處理的開源框架。Hadoop 有一種叫做 MapReduce 的機制，用來高效處理數據。MapReduce 是一種專門用於在分佈式環境下高效處理數據的機制，它基本由 Map、Shuffle、Reduce 這 3 種處理構成（圖 2.21）。

圖 2.21　經過 Hadoop MapReduce 執行批處理

◉ Apache Spark

Apache Spark 也和 Hadoop 同樣，是一個分佈式處理大規模數據的開源框架。Spark 用一種叫做 RDD（Resilient Distributed Dataset，彈性分佈數據集）的數據結構來處理數據（圖 2.22）。

圖 2.22　經過 Spark 執行批處理

　流處理

批處理是把數據攢起來，一次性進行處理的方法。相對而言，流處理是不保存數據，按照到達處理服務器的順序對數據依次進行處理。

想實時對數據作出反應時，流處理是一個頗有效的處理方法。由於批處理是把數據積攢以後隔一段時間進行處理，因此從數據到達以後處處理完畢爲止，會出現時間延遲。所以，流處理這種把到達的數據逐次進行處理的思路就變得很重要了。此外，流處理基本上是不會保存數據的。只要是被使用過的數據，若是不必保存，就會直接丟棄。

◉ Spark Streaming

Spark Streaming 是做爲 Apache Spark（在「批處理」部分介紹過）的庫被公開的。經過 Spark Streaming，就可以把 Apache Spark 拿到流處理中來使用（圖 2.23）。

圖 2.23　經過 Spark Streaming 執行流處理

◉ Apache Storm

Apache Storm 是用於實現流處理的框架，結構如圖 2.24 所示。

本文思惟導圖概覽

物聯網的基本架構包括三個層面：感知層、網絡層和應用層。

物聯網架構圖

物聯網架構圖

感知層經過傳感器採集某些數據(聲、光、電等)，基於網絡層的終端模組，對接到網絡層的基站，實現數據採集後的傳輸。

網絡層負責將感知層採集的數據進行回傳，基於不一樣特色採用不一樣的通訊協議技術進行回傳相當重要，這也是本文重點所討論的內容。

應用層能夠理解爲物聯網的數據平臺和業務平臺。數據平臺做爲全部物聯網終端數據的集合點，負責數據的統一存儲、分析等，北向經過標準的API接口提供給業務平臺作數據調用;業務平臺基於數據平臺的原始數據實現各類業務邏輯，對外呈現的是服務。

其中，聚焦於網絡層的通訊協議，則是羣雄逐鹿，百家爭鳴。

當下最流行的Wi-Fi技術數據傳輸速度飛快，尤爲802.11ax技術即將誕生，理論上8條流不是夢。然而伴隨速度的提高，耗電量急劇增大，且傳輸距離也成爲難題，長距離傳輸須要每隔必定距離放一個AP進行橋接，這必將大幅提高成本。所以，Wi-Fi技術更適合供PC及PDA等終端應用的室內無線上網場景。

藍牙技術與Wi-Fi在2.4G頻段上有交接，因此同頻段會有一些干擾問題的產生。藍牙的耗電狀況比Wi-Fi稍微低一些， 而傳輸速度遠不及Wi-Fi。在資產追蹤、定位標籤以及醫療傳感器等場景下應用較多，如智能手錶，藍牙定位等。

Zigbee技術的功耗比較小，通訊距離也比較短，是一種短距離低功耗的技術，主要應用於無線傳感器及醫療場景等。

UWB超寬帶技術頻段較爲乾淨，沒有其餘頻段的干擾，在高精度定位的場景下應用更多。

通訊協議對比

以上技術更適合近距離場景的數據傳輸，那麼在遠距離場景下又有哪些技術呢?

運營商提供的4G網絡，是人們生活中應用最多的，甚至超過Wi-Fi。它能夠作到長距離傳輸，不管在室內仍是室外，速度都很可觀。這種技術看起來很優越，但其功耗較大，只能應用於終端可自取電的物聯網場景，如某公司的共享單車，利用太陽能電池板進行取電。

在遠距離場景下，若是終端不能解決供電問題，那麼須要一種具備更低功耗，覆蓋範圍更大的技術來知足這個場景下的物聯網通訊需求。因而在業務和技術的驅動下，一些專家和企業爲了解決這個問題，研究出一種新型的通訊技術——LPWAN，即低功耗廣域網技術。

LPWAN的目標是爲物聯網應用中的M2M(設備到設備)通訊場景而優化的遠距離無線網絡通信技術。LPWAN技術的優點主要體如今：低速率、超低功耗、長距離、低吞吐、強覆蓋。這些特色剛好說明，此項技術正是針對物聯網在長距離傳輸的場景下開發的。具體應用如：城區覆蓋、遠程抄表、井蓋檢測以及近海漁船檢測等。

LPWAN技術特色

LPWAN做爲一個新的技術陣營，其內部分爲兩大派系：受權頻段和非受權頻段。受權頻段又分爲EC-GSM、eMTC以及NB-IoT;而非受權頻段的「頭牌」則是LoRa。

　EC-GSM

隨着LPWAN的興起，傳統的GRPS應用於物聯網的劣勢愈發明顯。2014年，3GPP研究項目提出，將窄帶(200kHz)物聯網技術遷移到GSM上，尋求比傳統GPRS高20dB的更廣的覆蓋範圍，並提出五大目標：提高室內覆蓋性能、支持大規模設備鏈接、減少設備複雜性、減少功耗和時延。到了2015年，TSG GERAN #67會議報告表示，EC-GSM已知足5大目標。但隨着R13 NB-IoT標準凍結以後，人們將更多精力投入到了從新定義的標準當中。

eMTC

eMTC的概念在R13中被正式命名，之前的R12被稱爲Low-Cost MTC，它是基於LTE演進的物聯網技術。eMTC基於蜂窩網進行部署，用戶設備經過支持1.4MHz的射頻和基帶帶寬，可直接接入現有的LTE網絡。eMTC的關鍵能力在於速率高(相較於GPRS、zigbee等)、可移動、可定位以及支持語音。。

　NB-IoT

最近特別火熱的NB-IoT實際上是NB-CIoT和NB-LTE二者的融合。NB-CIoT提出了全新的空口技術，較傳統LTE網絡改動較大，他知足於TSG GERAN#67會議上提出的五大目標，其亮點在於通訊模塊成本低於GSM及NB-LTE的模塊。而NB-LTE則與現有的LTE兼容，特色是利於部署。在激烈的爭論後，終於對二者加以融合，造成了NB-IoT的技術標準。

NB-IoT全稱爲窄帶物聯網，能夠直接部署於LTE網絡，良好的兼容性下降了部署的成本。其自己具備更低的功耗，理論上估算，承載NB-IoT的終端模組基於電池的待機時間可達10年之久。模塊成本的下降，也讓市場更多的公司開始應用這項技術，風靡全國的共享單車就是其一。某公司第三代的智能鎖就採用了NB-IoT的模組，一方面是運營商的大力推廣，另外一方面也確實帶來了價值。

LoRa

與NB-IoT齊頭並進發展的就是LoRa，與之不一樣的是LoRa技術使用非受權頻段。它是由Semtech公司採用和推廣的一種基於擴頻技術的超遠距離無線傳輸技術。LoRa全稱是Long Range，顧名思義，LoRa能夠支持長距離傳輸。在中國，LoRa可使用的頻段有兩個：CN779-787以及CN470-CN510。因爲CN779-787最大發射功率只有10dBm(10mW)，並無「實用」的價值。因此人們更青睞於CN470-CN510這個頻段，它的最大發射功率能夠達到17dBm(50mW)。

類比於Wi-Fi聯盟，LoRa也有對應的LoRa聯盟，旨爲共同創建標準和規範，LoRaWAN就是這樣的產物。

LoRa與NB-IoT對比

基於成本的考慮，LoRa的模組單價在8-10美圓左右，並且非受權頻段也不須要支付額外的頻譜成本，相比於NB-IoT而言，成本方面具備較大優點。在電池性能方面，因爲NB-IoT在蜂窩受權頻譜上工做，因此須要定時進行網絡同步，會消耗相應的電量，而LoRa則無此擔心，但NB-IoT的這個特性也受到共享單車的熱烈歡迎，能夠基於此來作車輛的實時定位工做。另外，從商業模式上來看，NB-IoT屬於運營商建網，業務方不須要本身來考慮基站的部署，比較省心;但與此同時，網絡的質量、安全都是不可控的風險，且企業自身的增值也會受到必定阻礙。反觀LoRa，屬於企業自建網絡，基站需本身部署，後續需本身運維、優化等，覆蓋的點位、網絡質量及安全等維度都要本身負責。

截止目前，沒有哪一個物聯網技術可以成爲真正的主流，對技術自己而言，沒有絕對的完美;從業務出發，更是須要結合業務特色、商業模式去選擇更適合的物聯網技術。

物聯網技術的發展伴隨各方「豪傑」羣雄逐鹿，將來會不會三足鼎立或由新的勢力一統天下，讓咱們拭目以待。

以上是關於物聯網中-物聯網通訊協議紛爭：羣雄逐鹿 百家爭鳴的相關介紹，若是想要了解更多相關信息，請多多關注eeworld，eeworld電子工程將給你們提供更全、更詳細、更新的資訊信息。

Stay hungry，Stay foolish！