1. 程式人生 > >物聯網常見通訊協議與通訊協議梳理【上】- 通訊協議

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

 

先說明, 這是在微信公眾號看到的,不是自己所寫, 覺得別人總結的很好, 就拿過來了.對於學習, 做一個搬運工也不可恥了,將好的知識自己吸收.  在微信公眾號裡, 沒有找到連線.

 

 

 “通訊”與“通訊”傻傻分得清

傳統意義上的“通訊”主要指電話、電報、電傳。通訊的“訊”指訊息(Message),媒體訊息通過通訊網路從一端傳遞到另外一端。媒體訊息的內容主要是話音、文字、圖片和視訊影象。其網路的構成主要由電子裝置系統和無線電系統構成,傳輸和處理的訊號是模擬的。所以,“通訊”一詞應特指採用電報、電話、網路等媒體傳輸系統實現上述媒體資訊傳輸的過程。“通訊”重在內容形式,因此通訊協議主要集中在ISO七層協議中的應用層。

“通訊”僅指資料通訊,即通過計算機網路系統和資料通訊系統實現資料的端到端傳輸。通訊的“信”指的是資訊(Information),資訊的載體是二進位制的資料,資料則是可以用來表達傳統媒體形式的資訊,如聲音、影象、動畫等。“通訊”重在傳輸手段或使用方式,從這個角度,“通訊”的概念包括了資訊“傳輸”。因此通訊協議主要集中在ISO七層協議中的物理層、資料鏈路層、網路層和傳輸層。

在物聯網應用中,通訊技術包括Wi-Fi、RFID、NFC、ZigBee、Bluetooth、LoRa、NB-IoT、GSM、GPRS、3/4/5G網路、Ethernet、RS232、RS485、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

一、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協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊,則它必須重傳,這樣可能導致每次連線傳送的資料量增大。另一方面,在伺服器不需要先前資訊時它的應答就較快。

 

二、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。

 

一、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.直接告訴給客戶端呼叫者。

 

二、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 通訊協議比較