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