相同點：
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