HTTP、MQTT、Websocket、WebService區別

相同點：

HTTP、MQTT、Websocket均爲OSI 7層模型的【應用層協議】
注意. WebService並不是通訊協議，而是一種遠程接口調用（RPC）的框架技術。

不一樣點：

MQTT

MQTT協議是爲大量計算能力有限，且工做在低帶寬、不可靠的網絡的遠程傳感器和控制設備通信而設計的協議，它具備如下主要的幾項特性：

1，使用發佈/訂閱消息模式，提供一對多的消息發佈，解除應用程序耦合；
2，對負載內容屏蔽的消息傳輸；
3，使用 TCP/IP 提供網絡鏈接；
4，有三種消息發佈服務質量：
「至多一次」，消息發佈徹底依賴底層 TCP/IP 網絡。會發生消息丟失或重複。這一級別可用於以下狀況，環境傳感器數據，丟失一次讀記錄無所謂，由於不久後還會有第二次發送。
「至少一次」，確保消息到達，但消息重複可能會發生。
「只有一次」，確保消息到達一次。這一級別可用於以下狀況，在計費系統中，消息重複或丟失會致使不正確的結果。

HTTP

HTTP是一個屬於應用層的，基於TCP/IP通訊協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。

通訊方式：

1，瀏覽器做爲HTTP客戶端經過URL向HTTP服務端即WEB服務器發送請求。Web服務器根據接收到的請求後，向客戶端發送響應信息。
2，HTTP之請求消息Request：請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成。
3，HTTP之響應消息Response：HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。
4，若connection 模式爲close，則服務器會主動關閉TCP鏈接，客戶端被動關閉鏈接，釋放TCP鏈接;若connection 模式爲keepalive，則該鏈接會保持一段時間，在該時間內能夠繼續接收請求;

不足：

HTTP通訊方式問題，HTTP的請求/應答方式的會話都是客戶端發起的，缺少服務器通知客戶端的機制，在須要通知的場景，如聊天室，遊戲，客戶端應用須要不斷地輪詢服務器。

MQ屬於長鏈接，http屬於短連接

 

Websocket協議（非socket）

WebSocket協議是基於TCP的一種應用層網絡協議。它實現了瀏覽器與服務器全雙工(full-duplex)通訊——容許服務器主動發送信息給客戶端。
取代了網頁和服務器採用HTTP輪詢進行雙向通信的機制。

WebService：RPC框架的一種

XML+XSD,SOAP和WSDL就是構成WebService平臺的三大技術。
1，XML+XSD
1.1，WebService採用HTTP協議傳輸數據，採用XML格式封裝數據（即XML中說明調用遠程服務對象的哪一個方法，傳遞的參數是什麼，以及服務對象的 返回結果是什麼）。XML是WebService平臺中表示數據的格式。除了易於創建和易於分析外，XML主要的優勢在於它既是平臺無關的，又是廠商無關 的。無關性是比技術優越性更重要的：軟件廠商是不會選擇一個由競爭對手所發明的技術的。
1.2，XML解決了數據表示的問題，但它沒有定義一套標準的數據類型，更沒有說怎麼去擴展這套數據類型。例如，整形數到底表明什麼？16位，32位，64位？這 些細節對實現互操做性很重要。XML Schema(XSD)就是專門解決這個問題的一套標準。它定義了一套標準的數據類型，並給出了一種語言來擴展這套數據類型。WebService平臺就 是用XSD來做爲其數據類型系統的。當你用某種語言(如VB.NET或C#)來構造一個Web service時，爲了符合WebService標準，所 有你使用的數據類型都必須被轉換爲XSD類型。你用的工具可能已經自動幫你完成了這個轉換，但你極可能會根據你的須要修改一下轉換過程。
2，SOAP
2.1，WebService經過HTTP協議發送請求和接收結果時，發送的請求內容和結果內容都採用XML格式封裝，並增長了一些特定的HTTP消息頭，以說明 HTTP消息的內容格式，這些特定的HTTP消息頭和XML內容格式就是SOAP協議。SOAP提供了標準的RPC方法來調用Web Service。
2.2，SOAP協議 = HTTP協議 + XML數據格式
SOAP協議定義了SOAP消息的格式，SOAP協議是基於HTTP協議的，SOAP也是基於XML和XSD的，XML是SOAP的數據編碼方式。打個比 喻：HTTP就是普通公路，XML就是中間的綠色隔離帶和兩邊的防禦欄，SOAP就是普通公路通過加隔離帶和防禦欄改造過的高速公路。
3，WSDL

 

MQTT與HTTP：哪個最適合物聯網？

HTTP是最流行和最普遍使用的協議。但在過去幾年中，MQTT迅速得到了牽引力。當咱們談論物聯網開發時，開發人員必須在它們之間作出選擇。

設計和消息傳遞

MQTT以數據爲中心，而HTTP是以文檔爲中心的。HTTP是用於客戶端 – 服務器計算的請求 – 響應協議，並不老是針對移動設備進行優化。MQTT在這些術語中的主要優勢是輕量級（MQTT將數據做爲字節數組傳輸）和發佈/訂閱模型，這使其很是適合資源受限的設備並有助於節省電池。

此外，發佈/訂閱模型爲客戶提供了彼此獨立的存在，加強了整個系統的可靠性。當一個客戶端出現故障時，整個系統能夠繼續正常工做。

速度和交付

根據3G網絡的測量結果，MQTT的吞吐量比HTTP快93倍。

此外，與HTTP相比，MQTT協議確保了高傳輸保證。有3個級別的服務質量：

– 最多一次：保證盡力交付。

– 至少一次：保證消息至少傳送一次。可是消息也能夠不止一次傳遞。

– 剛好一次：保證每一個消息只被對方接收一次

MQTT還爲用戶提供Last will＆Testament和Retained消息的選項。第一個意味着在客戶端意外斷開鏈接的狀況下，全部訂閱的客戶端都將從代理得到消息。保留消息意味着新訂閱的客戶端將當即得到狀態更新。

HTTP協議沒有這些功能。

複雜性和消息大小

 MQTT具備至關短的規範。只有CONNECT，PUBLISH，SUBSCRIBE，UNSUBSCRIBE和DISCONNECT類型對開發人員很重要。而HTTP規範要長得多。

MQTT具備很是短的消息頭，而且最小的包消息大小爲2個字節。經過HTTP協議使用文本消息格式容許它組成冗長的標題和消息。它有助於消除麻煩，由於它能夠被人類閱讀，但同時它對於資源受限的設備是沒必要要的。

結論

MQTT協議易於使用。對於將來的解決方案，響應時間，吞吐量，更低的電池和帶寬使用率是第一位的，這一點相當重要。在間歇性鏈接的狀況下，它也是完美的。

HTTP是值得和可擴展的。可是當它被稱爲IoT開發時，MQTT更適合。

 

http接口主要用於服務端向客戶端提供消息，用在客戶端主動去服務器請求http接口調取數據，並無主動給客戶端推送消息功能。
mqtt主要是用於移動端主動向服務端推送消息，並無去請求消息的功能。

 

 

 

 

生產者(Producer)的Confirm模式

 

經過生產者的確認模式咱們是要保證消息準確達到Broker端，而與AMQP事務不一樣的是Confirm是針對一條消息的，而事務是能夠針對多條消息的。

 

發送原理圖大體以下：

 

 

 

 

爲了使用Confirm模式，client會發送confirm.select方法幀。經過是否設置了no-wait屬性，來決定Broker端是否會以confirm.select-ok來進行應答。一旦在channel上使用confirm.select方法，channel就將處於Confirm模式。處於 transactional模式的channel不能再被設置成Confirm模式，反之亦然。

這裏與前面的一些文章介紹的一致，發佈確認和事務二者不可同時引入，channel一旦設置爲Confirm模式就不能爲事務模式，爲事務模式就不能爲Confirm模式。

在生產者將信道設置成Confirm模式，一旦信道進入Confirm模式，全部在該信道上面發佈的消息都會被指派一個惟一的ID(以confirm.select爲基礎從1開始計數)，一旦消息被投遞到全部匹配的隊列以後，Broker就會發送一個確認給生產者（包含消息的惟一ID）,這就使得生產者知道消息已經正確到達目的隊列了，若是消息和隊列是可持久化的，那麼確認消息會將消息寫入磁盤以後發出，Broker回傳給生產者的確認消息中deliver-tag域包含了確認消息的序列號，此外Broker也能夠設置basic.ack的multiple域，表示到這個序列號以前的全部消息都已經獲得了處理。

Confirm模式最大的好處在於它是異步的，一旦發佈一條消息，生產者應用程序就能夠在等信道返回確認的同時繼續發送下一條消息，當消息最終獲得確認以後，生產者應用即可以經過回調方法來處理該確認消息，若是RabbitMQ由於自身內部錯誤致使消息丟失，就會發送一條basic.nack來代替basic.ack的消息，在這個情形下，basic.nack中各域值的含義與basic.ack中相應各域含義是相同的，同時requeue域的值應該被忽略。經過nack一條或多條消息， Broker代表自身沒法對相應消息完成處理，並拒絕爲這些消息的處理負責。在這種狀況下，client能夠選擇將消息re-publish。

在channel 被設置成Confirm模式以後，全部被publish的後續消息都將被Confirm（即 ack）或者被nack一次。可是沒有對消息被Confirm的快慢作任何保證，而且同一條消息不會既被Confirm又被nack。

A----->MQ-----B

正常狀況下，一旦A服務向mq成功推送了消息，mq就會返回一條basic.ack的消息告訴A我已經收到A推送的消息。
若是RabbitMQ由於自身內部錯誤致使消息丟失，就會發送一條basic.nack來代替basic.ack的消息。

若是A服務向mq成功推送了消息，可是沒有收到mq返回的「確認收到（ack/nack）」的消息，緣由多是：
1，mq服務出現了問題，mq根本就沒有收到A服務推送的消息
2，mq服務出現了問題，mq收到A推送的消息以後，尚未來得及告訴A「確認收到」，mq服務就出現了問題
3，網絡問題，mq收到A推送的消息以後，尚未來得及告訴A「確認收到」，網絡就出現了問題
4，RabbitMQ可能出現消息積壓：幾千萬條數據在RabbitMQ裏積壓了很長時間（幾個小時），RabbitMQ的Broker沒法再發送一個確認消息給生產者。

 解決策略：

若是A沒有收到mq返回的「確認收到（ack/nack）」的消息，能夠設置等待時間，好比1分鐘之內尚未收到的話，A就將消息re-publish。若是A連續10次re-publish都沒有收到ack/nack消息的話，能夠查看MQ服務的狀態，肯定是否是MQ服務掛了。

通常狀況下：

若是MQ服務有問題的話，A的connection狀態就是失敗的，A就沒法向MQ推送消息。

反之若是A的connection狀態是失敗的，極有可能的緣由是MQ服務有問題。

 

 

 

 

 

原文連接：https://blog.csdn.net/anumbrella/article/details/81321701
原文連接：https://blog.csdn.net/cpongo3/article/details/89327644

原文地址：https://blog.csdn.net/wzhqazcscs/article/details/79603261