【轉】物聯網常見通訊協議
1 “通訊”與“通訊”傻傻分得清
傳統意義上的“通訊”主要指電話、電報、電傳。通訊的“訊”指訊息（Message）,媒體訊息通過通訊網路從一端傳遞到另外一端。媒體訊息的內容主要是話音、文字、圖片和視訊影象。其網路的構成主要由電子裝置系統和無線電系統構成，傳輸和處理的訊號是模擬的。所以，“通訊”一詞應特指採用電報、電話、網路等媒體傳輸系統實現上述媒體資訊傳輸的過程。“通訊”重在內容形式，因此通訊協議主要集中在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.1HTTP/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 Transfer
Protocol 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.2WebService/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封裝風格，物聯網中資料採集到物聯網應用系統中，在物聯網應用系統中，可以通過開放REST
API的方式，把資料服務開放出去，被網際網路中其他應用所呼叫。
2.3CoAP協議
CoAP (Constrained Application Protocol)，受限應用協議，應用於無線感測網中協議。
適用範圍：CoAP是簡化了HTTP協議的RESTful
API，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.4MQTT協議(低頻寬)
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的一個重要部分是其IoT
Foundation服務，這是一項基於雲的MQTT例項；
（3）移動應用程式也早就開始使用MQTT，如Facebook Messenger和com等。
另外，MQTT協議一般適用於裝置資料採集到端(Device→Server，Device→Gateway)，集中星型網路架構(hub-and-spoke)，不適用裝置與裝置之間通訊，裝置控制能力弱，另外實時性較差，一般都在秒級。
2.5DDS協議(高可靠性、實時)
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.6AMQP協議(互操作性)
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.7XMPP協議(即時通訊)
XMPP(Extensible Messaging and Presence Protocol)可擴充套件通訊和表示協議，XMPP的前身是Jabber，一個開源形式組織產生的網路即時通訊協議。XMPP目前被IETF國際標準組織完成了標準化工作。
適用範圍：即時通訊的應用程式，還能用在網路管理、內容供稿、協同工具、檔案共享、遊戲、遠端系統監控等。
它有以下特點：
（1）客戶機/伺服器通訊模式；
（2）分散式網路；
（3）簡單的客戶端，將大多數工作放在伺服器端進行；
（4）標準通用標記語言的子集XML的資料格式。
另外，XMPP是基於XML的協議，由於其開放性和易用性，在網際網路及時通訊應用中運用廣泛。相對HTTP，XMPP在通訊的業務流程上是更適合物聯網系統的，開發者不用花太多心思去解決裝置通訊時的業務通訊流程，相對開發成本會更低。但是HTTP協議中的安全性以及計算資源消耗的硬傷並沒有得到本質的解決。
2.8JMS (JavaMessage Service)
JMS (Java Message Service)，JAVA訊息服務，這是JAVA平臺中著名的訊息佇列協議。
Java訊息服務(Java Message Service)應用程式介面，是一個Java平臺中關於面向訊息中介軟體(MOM)的API，用於在兩個應用程式之間，或分散式系統中傳送訊息，進行非同步通訊。Java訊息服務是一個與具體平臺無關的API，絕大多數MOM提供商都對JMS提供支援。
JMS是一種與廠商無關的API，用來訪問訊息收發系統訊息，它類似於JDBC(Java Database
Connectivity)。這裡，JDBC是可以用來訪問許多不同關係資料庫的API，而JMS則提供同樣與廠商無關的訪問方法，以訪問訊息收發服務。許多廠商都支援JMS，包括IBM的MQSeries、BEA的Weblogic JMS service和Progress的SonicMQ。JMS能夠通過訊息收發服務(有時稱為訊息中介程式或路由器)從一個JMS客戶機向另一個JMS客戶機發送訊息。訊息是JMS中的一種型別物件，由兩部分組成：報頭和訊息主體。報頭由路由資訊以及有關該訊息的元資料組成。訊息主體則攜帶著應用程式的資料或有效負載。根據有效負載的型別來劃分，可以將訊息分為幾種型別，它們分別攜帶：簡單文字(TextMessage)、可序列化的物件(ObjectMessage)、屬性集合(MapMessage)、位元組流(BytesMessage)、原始值流(StreamMessage)，還有無有效負載的訊息(Message)。
2.9通訊協議比較
