先說明, 這是在微信公眾號看到的,不是自己所寫, 覺得別人總結的很好, 就拿過來了.對於學習, 做一個搬運工也不可恥了,將好的知識自己吸收. 在微信公眾號里, 沒有找到連接.
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 通訊協議比較
