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