物聯網常見通訊協議與通信協議梳理【上】- 通信協議

 

先說明, 這是在微信公衆號看到的,不是本身所寫, 以爲別人總結的很好, 就拿過來了.對於學習, 作一個搬運工也不可恥了,將好的知識本身吸取.  在微信公衆號裏, 沒有找到鏈接.

 

 

1  「通訊」與「通信」傻傻分得清

傳統意義上的「通信」主要指電話、電報、電傳。通信的「訊」指消息（Message）,媒體訊息經過通信網絡從一端傳遞到另一端。媒體訊息的內容主要是話音、文字、圖片和視頻圖像。其網絡的構成主要由電子設備系統和無線電系統構成，傳輸和處理的信號是模擬的。因此，「通信」一詞應特指採用電報、電話、網絡等媒體傳輸系統實現上述媒體信息傳輸的過程。「通信」重在內容形式，所以通信協議主要集中在ISO七層協議中的應用層。

「通訊」僅指數據通訊，即經過計算機網絡系統和數據通訊系統實現數據的端到端傳輸。通訊的「信」指的是信息（Information）,信息的載體是二進制的數據，數據則是能夠用來表達傳統媒體形式的信息，如聲音、圖像、動畫等。「通訊」重在傳輸手段或使用方式，從這個角度，「通訊」的概念包括了信息「傳輸」。所以通訊協議主要集中在ISO七層協議中的物理層、數據鏈路層、網絡層和傳輸層。

在物聯網應用中，通訊技術包括Wi-Fi、RFID、NFC、ZigBee、Bluetooth、LoRa、NB-IoT、GSM、GPRS、3/4/5G網絡、Ethernet、RS23二、RS48五、USB等。

相關的通訊協議（協議棧、技術標準）包括Wi-Fi（IEEE 802.11b）、RFID、NFC、ZigBee、Bluetooth、LoRa、NB-IoT、CDMA/TDMA、TCP/IP、WCDMA、TD-SCDMA、TD-LTE、FDD-LTE、TCP/IP、HTTP等。注：3GPP將5G技術標準制定分爲兩個階段，原計劃中第一階段的標準將在2018年末做爲R15的一部分公佈，將僅針對NR。第二階段的標準將在2019年末做爲R16的一部分，包括整個5G架構（包括核心網絡）。

物聯網技術框架體系中所使用到的通信協議主要有：AMQP、JMS、REST、HTTP/HTTPS、COAP、DDS 、MQTT等。

 

2 通信協議

2.1  HTTP/HTTPS

1、HTTP

HTTP是一個屬於應用層的面向對象的協議，因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。它於1990年提出，通過幾年的使用與發展，獲得不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規範化工做正在進行之中，並且HTTP-NG(Next Generation of HTTP)的建議已經提出。

HTTP協議的主要特色可歸納以下：

（1）支持客戶/服務器模式。

（2）簡單快速。客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

（3）靈活。HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

（4）無鏈接。無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

（5）無狀態。HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

 

2、HTTPS

HTTPS（Hypertext TransferProtocol over Secure Socket Layer，基於SSL的HTTP協議）使用了HTTP協議，但HTTPS使用不一樣於HTTP協議的默認端口及一個加密、身份驗證層（HTTP與TCP之間）。這個協議的最初研發由網景公司進行，提供了身份驗證與加密通訊方法，如今它被普遍用於互聯網上安全敏感的通訊。

客戶端在使用HTTPS方式與Web服務器通訊時有如下幾個步驟，如圖所示。

（1）客戶使用https的URL訪問Web服務器，要求與Web服務器創建SSL鏈接。

（2）Web服務器收到客戶端請求後，會將網站的證書信息（證書中包含公鑰）傳送一份給客戶端。

（3）客戶端的瀏覽器與Web服務器開始協商SSL鏈接的安全等級，也就是信息加密的等級。

（4）客戶端的瀏覽器根據雙方贊成的安全等級，創建會話密鑰，而後利用網站的公鑰將會話密鑰加密，並傳送給網站。

（5）Web服務器利用本身的私鑰解密出會話密鑰。

（6）Web服務器利用會話密鑰加密與客戶端之間的通訊。

 

2.2  WebService/REST

首先說明下，WebService和REST都不是一種協議，他們是基於HTTP/HTTPS的一種技術方式或風格，之因此放在這裏，是由於在物聯網應用服務對外接口方式常採用WebService和RESTful API。

 

1、WebService

WebService是一種跨編程語言和跨操做系統平臺的遠程調用技術。

XML+XSD,SOAP和WSDL就是構成WebService平臺的三大技術。

（1）XML+XSD

WebService採用HTTP協議傳輸數據，採用XML格式封裝數據（即XML中說明調用遠程服務對象的哪一個方法，傳遞的參數是什麼，以及服務對象的返回結果是什麼）。XML是WebService平臺中表示數據的格式。除了易於創建和易於分析外，XML主要的優勢在於它既是平臺無關的，又是廠商無關的。無關性是比技術優越性更重要的：軟件廠商是不會選擇一個由競爭對手所發明的技術的。

XML解決了數據表示的問題，但它沒有定義一套標準的數據類型，更沒有說怎麼去擴展這套數據類型。例如，整形數到底表明什麼？16位，32位，64位？這些細節對實現互操做性很重要。XML Schema(XSD)就是專門解決這個問題的一套標準。它定義了一套標準的數據類型，並給出了一種語言來擴展這套數據類型。WebService平臺就是用XSD來做爲其數據類型系統的。當你用某種語言(如VB.NET或C#)來構造一個Web service時，爲了符合WebService標準，全部你使用的數據類型都必須被轉換爲XSD類型。你用的工具可能已經自動幫你完成了這個轉換，但你極可能會根據你的須要修改一下轉換過程。

（2）SOAP

WebService經過HTTP協議發送請求和接收結果時，發送的請求內容和結果內容都採用XML格式封裝，並增長了一些特定的HTTP消息頭，以說明HTTP消息的內容格式，這些特定的HTTP消息頭和XML內容格式就是SOAP協議。SOAP提供了標準的RPC方法來調用Web Service。

SOAP協議 = HTTP協議 + XML數據格式

SOAP協議定義了SOAP消息的格式，SOAP協議是基於HTTP協議的，SOAP也是基於XML和XSD的，XML是SOAP的數據編碼方式。打個比喻：HTTP就是普通公路，XML就是中間的綠色隔離帶和兩邊的防禦欄，SOAP就是普通公路通過加隔離帶和防禦欄改造過的高速公路。

（3）WSDL

比如咱們去商店買東西，首先要知道商店裏有什麼東西可買，而後再來購買，商家的作法就是張貼廣告海報。 WebService也同樣，WebService客戶端要調用一個WebService服務，首先要有知道這個服務的地址在哪，以及這個服務裏有什麼方法能夠調用，因此，WebService務器端首先要經過一個WSDL文件來講明本身家裏有啥服務能夠對外調用，服務是什麼（服務中有哪些方法，方法接受的參數是什麼，返回值是什麼），服務的網絡地址用哪一個url地址表示，服務經過什麼方式來調用。

WSDL(Web Services Description Language)就是這樣一個基於XML的語言，用於描述Web Service及其函數、參數和返回值。它是WebService客戶端和服務器端都能理解的標準格式。由於是基於XML的，因此WSDL既是機器可閱讀的，又是人可閱讀的，這將是一個很大的好處。一些最新的開發工具既能根據你的Web service生成WSDL文檔，又能導入WSDL文檔，生成調用相應WebService的代理類代碼。

WSDL文件保存在Web服務器上，經過一個url地址就能夠訪問到它。客戶端要調用一個WebService服務以前，要知道該服務的WSDL文件的地址。WebService服務提供商能夠經過兩種方式來暴露它的WSDL文件地址：1.註冊到UDDI服務器，以便被人查找；2.直接告訴給客戶端調用者。

 

2、REST

REST (Representational State Transfer)，表徵狀態轉換，是基於HTTP 協議開發的一種通訊風格，目前還不是標準。

適用範圍：REST/HTTP 主要爲了簡化互聯網中的系統架構，快速實現客戶端和服務器之間交互的鬆耦合，下降了客戶端和服務器之間的交互延遲。所以適合在物聯網的應用層面，經過REST 開放物聯網中資源，實現服務被其餘應用所調用。它有如下特色：

（1）REST 指的是一組架構約束條件和原則。知足這些約束條件和原則的應用程序或設計就是RESTful；

（2）客戶端和服務器之間的交互在請求之間是無狀態的；

（3）在服務器端，應用程序狀態和功能能夠分爲各類資源，它向客戶端公開。資源的例子有：應用程序對象、數據庫記錄、算法等等。每一個資源都使用URI (Universal Resource Identifier) 獲得一個唯一的地址。全部資源都共享統一的界面，以便在客戶端和服務器之間傳輸狀態；

（4）使用的是標準的HTTP方法，好比GET、PUT、POST 和DELETE。

REST是互聯網中服務調用API 封裝風格，物聯網中數據採集到物聯網應用系統中，在物聯網應用系統中，能夠經過開放RESTAPI的方式，把數據服務開放出去，被互聯網中其餘應用所調用。

 

2.3  CoAP 協議

CoAP (Constrained Application Protocol)，受限應用協議，應用於無線傳感網中協議。

適用範圍：CoAP 是簡化了HTTP 協議的RESTfulAPI，CoAP 是6LowPAN 協議棧中的應用層協議，它適用於在資源受限的通訊的IP 網絡。它有如下特色：

（1）報頭壓縮。CoAP 包含一個緊湊的二進制報頭和擴展報頭。它只有短短的4B 的基本報頭，基本報頭後面跟擴展選項。一個典型的請求報頭爲10～20B。

（2）方法和URIs。爲了實現客戶端訪問服務器上的資源，CoAP 支持GET、PUT、POST 和DELETE 等方法。CoAP 還支持URIs，這是Web 架構的主要特色。

（3）傳輸層使用UDP 協議。CoAP 協議是創建在UDP 協議之上，以減小開銷和支持組播功能。它也支持一個簡單的中止和等待的可靠性傳輸機制。

（4）支持異步通訊。HTTP 對M2M(Machine-to-Machine)通訊不適用，這是因爲事務老是由客戶端發起。而CoAP 協議支持異步通訊，這對M2M 通訊應用來講是常見的休眠/喚醒機制。

（5）支持資源發現。爲了自主的發現和使用資源，它支持內置的資源發現格式，用於發現設備上的資源列表，或者用於設備向服務目錄公告本身的資源。它支持RFC5785 中的格式，在CoRE 中用/.well—known/core 的路徑表示資源描述。

（6）支持緩存。CoAP 協議支持資源描述的緩存以優化其性能。

CoAP協議主要實現：

（1）libcoap(C 語言實現)

（2）Californium(java 語言實現)

另外，CoAP 和6LowPan，這分別是應用層協議和網絡適配層協議，其目標是解決設備直接鏈接到IP 網絡，也就是IP 技術應用到設備之間、互聯網與設備之間的通訊需求。由於IPV6 技術帶來巨大尋址空間，不光解決了將來巨量設備和資源的標識問題，互聯網上應用能夠直接訪問支持IPV6 的設備，而不須要額外的網關。

 

2.4  MQTT 協議(低帶寬)

MQTT (Message Queuing Telemetry Transport )，消息隊列遙測傳輸，由IBM 開發的即時通信協議，相比來講比較適合物聯網場景的通信協議。MQTT 協議採用發佈/訂閱模式，全部的物聯網終端都經過TCP 鏈接到雲端，雲端經過主題的方式管理各個設備關注的通信內容，負責將設備與設備之間消息的轉發。

MQTT 在協議設計時就考慮到不一樣設備的計算性能的差別，因此全部的協議都是採用二進制格式編解碼，而且編解碼格式都很是易於開發和實現。最小的數據包只有2個字節，對於低功耗低速網絡也有很好的適應性。有很是完善的QOS 機制，根據業務場景能夠選擇最多一次、至少一次、恰好一次三種消息送達模式。運行在TCP 協議之上，同時支持TLS(TCP+SSL)協議，而且因爲全部數據通訊都通過雲端，安全性獲得了較好地保障。

適用範圍：在低帶寬、不可靠的網絡下提供基於雲平臺的遠程設備的數據傳輸和監控。

它具備如下特色：

（1）使用基於代理的發佈/訂閱消息模式，提供一對多的消息發佈；

（2）使用TCP/IP 提供網絡鏈接；

（3）小型傳輸，開銷很小(固定長度的頭部是2 字節)，協議交換最小化，以下降網絡流量；

（4）支持QoS，有三種消息發佈服務質量：「至多一次」， 「至少一次」， 「只有一次」。

協議主要實現和應用：

（1）已經有PHP，JAVA，Python，C，C#等多個語言版本的協議框架；

（2）IBM Bluemix 的一個重要部分是其IoTFoundation 服務，這是一項基於雲的MQTT實例；

（3）移動應用程序也早就開始使用MQTT，如Facebook Messenger 和com 等。

另外，MQTT 協議通常適用於設備數據採集到端(Device→Server，Device→Gateway)，集中星型網絡架構(hub-and-spoke)，不適用設備與設備之間通訊，設備控制能力弱，另外實時性較差，通常都在秒級。

 

2.5  DDS 協議(高可靠性、實時)

DDS(Data Distribution Service for Real-Time Systems)，面向實時系統的數據分佈服務，這是大名鼎鼎的OMG 組織提出的協議，其權威性應該能證實該協議的將來應用前景。

適用範圍：分佈式高可靠性、實時傳輸設備數據通訊。目前DDS 已經普遍應用於國防、民航、工業控制等領域。

它具備如下特色：

（1）以數據爲中心；

（2）使用無代理的發佈/訂閱消息模式，點對點、點對多、多對多；

（3）提供多大21 種QoS服務質量策略。

協議主要實現：

（1）OpenDDS 是一個開源的C++ 實現；

（2）OpenSplice DDS；

另外，DDS很好地支持設備之間的數據分發和設備控制，設備和雲端的數據傳輸，同時DDS的數據分發的實時效率很是高，能作到秒級內同時分發百萬條消息到衆多設備。DDS在服務質量(QoS)上提供很是多的保障途徑，這也是它適用於國防軍事、工業控制這些高可靠性、可安全性應用領域的緣由。但這些應用都工做在有線網絡下，在無線網絡，特別是資源受限的狀況下，沒有見到過實施案例。

 

 

2.6  AMQP 協議(互操做性)

AMQP(Advanced Message Queuing Protocol)，先進消息隊列協議，這是OASIS 組織提出的，該組織曾提出OSLC(Open Source Lifecyle)標準，用於業務系統例如PLM，ERP，MES等進行數據交換。

適用範圍：最先應用於金融系統之間的交易消息傳遞，在物聯網應用中，主要適用於移動手持設備與後臺數據中心的通訊和分析。

它有如下特色：

（1）Wire 級的協議，它描述了在網絡上傳輸的數據的格式，以字節爲流；

（2）面向消息、隊列、路由(包括點對點和發佈/訂閱)、可靠性、安全；

協議實現：

（1）Erlang 中的實現有RabbitMQ

（2）AMQP 的開源實現，用C 語言編寫OpenAMQ

（3）Apache Qpid

（4）stormMQ

 

2.7  XMPP 協議(即時通訊)

XMPP(Extensible Messaging and Presence Protocol)可擴展通信和表示協議，XMPP的前身是Jabber，一個開源形式組織產生的網絡即時通訊協議。XMPP目前被IETF 國際標準組織完成了標準化工做。

適用範圍：即時通訊的應用程序，還能用在網絡管理、內容供稿、協同工具、檔案共享、遊戲、遠端系統監控等。

它有如下特色：

（1）客戶機/服務器通訊模式；

（2）分佈式網絡；

（3）簡單的客戶端，將大多數工做放在服務器端進行；

（4）標準通用標記語言的子集XML的數據格式。

另外，XMPP 是基於XML 的協議，因爲其開放性和易用性，在互聯網及時通信應用中運用普遍。相對HTTP，XMPP 在通信的業務流程上是更適合物聯網系統的，開發者不用花太多心思去解決設備通信時的業務通信流程，相對開發成本會更低。可是HTTP 協議中的安全性以及計算資源消耗的硬傷並無獲得本質的解決。

 

2.8  JMS (JavaMessage Service)

JMS (Java Message Service)，JAVA 消息服務，這是JAVA 平臺中著名的消息隊列協議。

Java 消息服務(Java Message Service)應用程序接口，是一個Java 平臺中關於面向消息中間件(MOM)的API，用於在兩個應用程序之間，或分佈式系統中發送消息，進行異步通訊。Java 消息服務是一個與具體平臺無關的API，絕大多數MOM 提供商都對JMS 提供支持。

JMS 是一種與廠商無關的API，用來訪問消息收發系統消息，它相似於JDBC(Java DatabaseConnectivity)。這裏，JDBC 是能夠用來訪問許多不一樣關係數據庫的API，而JMS則提供一樣與廠商無關的訪問方法，以訪問消息收發服務。許多廠商都支持JMS，包括IBM的MQSeries、BEA 的Weblogic JMS service 和Progress 的SonicMQ。JMS可以經過消息收發服務(有時稱爲消息中介程序或路由器)從一個JMS 客戶機向另外一個JMS 客戶機發送消息。消息是JMS 中的一種類型對象，由兩部分組成：報頭和消息主體。報頭由路由信息以及有關該消息的元數據組成。消息主體則攜帶着應用程序的數據或有效負載。根據有效負載的類型來劃分，能夠將消息分爲幾種類型，它們分別攜帶：簡單文本(TextMessage)、可序列化的對象(ObjectMessage)、屬性集合(MapMessage)、字節流(BytesMessage)、原始值流(StreamMessage)，還有無有效負載的消息(Message)。

 

2.9 通信協議比較