MQTT和Websocket的区别是什么?

MQTT和Websocket的区别是什么?,第1张

MQTT(Message Queuing Telemetry Transport,消息队列遥测传输)是轻量级基于代理的发布/订阅的消息传输协议,设计思想是开放、简单、轻量、易于实现。这些特点使它适用于受限环境。例如:
①网络代价昂贵,带宽低、不可靠。
②在嵌入设备中运行,处理器和内存资源有限。
该协议的特点有:
①使用发布/订阅消息模式,提供一对多的消息发布,解除应用程序耦合。
②对负载内容屏蔽的消息传输。
③使用 TCP/IP 提供网络连接。
④有三种消息发布服务质量:
⑤"至多一次",消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况,环境传感器数据,丢失一次读记录无所谓,因为不久后还会有第二次发送。
⑥"至少一次",确保消息到达,但消息重复可能会发生。
⑦"只有一次",确保消息到达一次。这一级别可用于如下情况,在计费系统中,消息重复或丢失会导致不正确的结果。
⑧小型传输,开销很小(固定长度的头部是 2 字节),协议交换最小化,以降低网络流量。
⑨使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制。
WebSocket则提供使用一个TCP连接进行双向通讯的机制,包括网络协议和API,以取代网页和服务器采用>

简单回答一下,MQTT(MQTelemetryTransport)是针对物联网而设计的,如手机对家里的智能开关,而WebSocket是针对浏览器与服务器之间而设计的两者基本上是两个世界的东西

MQTT只是一个接口,让两个"物件"能够透过TCP协议通讯,但并没有规定(在应用层面上)通讯中要怎样"对答",如pop3邮件伺服器会有:

S:220我是xxx服务器

C:HELOmyServer

S:250Nicetomeetyou

C:authlogin

这些是没有硬性被定义的,两个"物件"之间要怎_"聊天",由你自己来定

WebSocket则是一个>

以上,只是很概念的说法,便於你理解,详细你得自己翻下文献了

首先,物联网界,万物都疯了,苦于它们没有生命,没有嘴。自己想表达的信息只能通过各种通讯协议传达给人类和世界各地。

NB-IoT,4G对比:

WIFI和zigbee对比:

ZigBee、Wi-Fi、蓝牙和几种无线技术的对比如下表所示:

在2015年9月的RAN #69会议上经过激烈撕逼后协商统一,NB-IoT可认为是NB-CIoT和NB-LTE的融合。

物联网的应用场景相当广泛,比如,智能泊车、自行车联网防盗、车联网、智慧城市、智慧建筑、环境监控…

——完——

MQTT协议是为大量计算能力有限,且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议。
而WebSocket则是浏览器与服务器全双工通信
(MQTTMessage Queuing Telemetry Transport,消息队列遥测传输)是IBM开发的一个即时通讯协议,有可能成为物联网的重要组成部分。该协议支持所有平台,几乎可以把所有联网物品和外部连接起来,被用来当做传感器和致动器(比如通过Twitter让房屋联网)的通信协议。
WebSocket protocol 是HTML5一种新的协议。它实现了浏览器与服务器全双工通信(full-duplex)。一开始的握手需要借助>1、 什么是MQTT

MQTT(MessageQueueing Telemetry Transport Protocol)的全称是消息队列遥感传输协议的缩写,是由IBM公司推出的一种基于轻量级代理的发布/订阅模式的消息传输协议,运行在TCP协议栈之上,为其提供有序、可靠、双向连接的网络连接保证。由于其开放、简单和易于实现所以能够应用在资源受限的环境中,对于M2M和物联网应用程序来说是一个相当不错的选择。

2、 为什么要用MQTT?

MQTT协议是针对如下情况设计的:

M2M(Machine to Machine) communication,机器端到端通信,比如传感器之间的数据通讯 因为是Machine to Machine,需要考虑: Machine,或者叫设备,比如温度传感器,硬件能力很弱,协议要考虑尽量小的资源消耗,比如计算能力和存储等 M2M可能是无线连接,网络不稳定,带宽也比较小

MQTT的特点:

发布/订阅消息模式,提供一对多的消息发布,解除应用程序耦合。这一点很类似于1 这里是列表文本XMPP,但是MQTT的信息冗余远小于XMPP

对负载内容屏蔽的消息传输。

使用TCP/IP提供网络连接。主流的MQTT是基于TCP连接进行数据推送的,但是同样有基于UDP的版本,叫做MQTT-SN。这两种版本由于基于不同的连接方式,优缺点自然也就各有不同了。

三种消息传输方式QoS:

0代表“至多一次”,消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况,环境传感器数据,丢失一次读记录无所谓,因为不久后还会有第二次发送。

1代表“至少一次”,确保消息到达,但消息重复可能会发生。

2代表“只有一次”,确保消息到达一次。这一级别可用于如下情况,在计费系统中,消息重复或丢失会导致不正确的结果。 备注:由于服务端采用Mosca实现,Mosca目前只支持到QoS 1

如果发送的是临时的消息,例如给某topic所有在线的设备发送一条消息,丢失的话也无所谓,0就可以了(客户端登录的时候要指明支持的QoS级别,同时发送消息的时候也要指明这条消息支持的QoS级别),如果需要客户端保证能接收消息,需要指定QoS为1,如果同时需要加入客户端不在线也要能接收到消息,那么客户端登录的时候要指定session的有效性,接收离线消息需要指定服务端要保留客户端的session状态。

mqtt基于订阅者模型架构,客户端如果互相通信,必须在同一订阅主题下,即都订阅了同一个topic,客户端之间是没办法直接通讯的。订阅模型显而易见的好处是群发消息的话只需要发布到topic,所有订阅了这个topic的客户端就可以接收到消息了。

发送消息必须发送到某个topic,重点说明的是不管客户端是否订阅了该topic都可以向topic发送了消息,还有如果客户端订阅了该主题,那么自己发送的消息也会接收到。

小型传输,开销很小(固定长度的头部是2字节),协议交换最小化,以降低网络流量。这就是为什么在介绍里说它非常适合“在物联网领域,传感器与服务器的通信,信息的收集”,要知道嵌入式设备的运算能力和带宽都相对薄弱,使用这种协议来传递消息再适合不过了。

使用Last Will和Testament特性通知有关各方客户端异常中断的机制。Last Will:即遗言机制,用于通知同一主题下的其他设备发送遗言的设备已经断开了连接。Testament:遗嘱机制,功能类似于Last Will 。

物模型是云平台为物联网产品定义的数据模型,用于描述产品的功能。将产品抽象成数据的集合,方便云端进行控制。

物模型从 属性 服务 事件 三个维度,分别描述了该实体是什么、能做什么、可以对外提供哪些信息。定义了物模型的这三个维度,即完成了产品功能的定义。

TSL 格式是一个 JSON 格式的文件,完整的 TSL 格式可以参考: 阿里云物模型 。

嵌入式端开发固件往往只需要关注少数几个参数,可以在产品的 功能定义 页面,单击 物模型TSL 精简物模型 里面查看。

需要关注的有 "properties","events","services",在 JSON 格式里,这三者都是数组,分别存储了该物模型的数据,事件和服务,在 C-SDK 里也就分别是 IOT_Linkkit_Report() 上报属性, IOT_Linkkit_TriggerEvent() 触发事件和注册为 ITE_SERVICE_REQUEST 的回调函数。

在上报属性时,只需要关注 "identifier" 名称对应的值(字符串),此时表示该属性在产品下的唯一标识。例如一个精简物模型属性为:

则上报的数据只需要为 {"count":10} 即可,需满足 JSON 字符串的格式,字符串内有一个名称/值对,名称为 "count"(物模型里 "identifier" 的值),值对为 10(满足物模型里数据类型为 int 的要求)。

触发事件需要关注 "identifier" 名称对应的值(字符串),表示该事件在产品下的唯一标识;还需要关注 "outputData",表示上报事件的输出值。一个精简物模型例子如下:

"outputData" 数组的使用与属性上报一致,这里就不介绍了。

服务调用需要同时关注 "identifier","inputData" 和 "outputData" 这三个名称,分别表示该服务在产品下的唯一标识,服务的输入参数,服务的输出参数。与函数调用有输入值和输出值类似,服务调用也有这些特征。

物模型数据校验方式目前有两种, 弱校验 免校验

也就是说,弱校验针对产品设备的上报数据,只要 idetifier 是一致的,且 dataType 字段满足要求,就接收该数据,并且在其他云端产品流转。

为什么云端可以设置和获取接入设备的属性呢?为什么接入设备可以上报事件给云端呢?又为什么云端可以调用接入设备提供的服务呢?这就是这一小节解释的内容。

物模型基于 MQTT 协议,MQTT 协议的介绍不在此处展开。

云端定义了一系列的 Topic,在设备接入云端时,C-SDK 向 MQTT broker 订阅了一些的 Topic,而云端需要与设备交互时,就向 MQTT broker 发布相应的 Topic,这样就完成了交互过程。同理,云端也会订阅一些 Topic,设备可以向这些 Topic 发布消息。

接入设备端订阅发布的 Topic 列表如下:

其中 ${productKey} 会替换为实际的产品名,${deviceName} 会替换为实际的设备名,${tsleventidentifier} 是事件的标识符,${tslserviceidentifier} 是服务的标识符,最大限度地保证了 Topic 的唯一性。

这些 Topic 的作用在后面用时序来描述。

运用了MQTT通信协议,数据库管理,Web框架技术。
1、MQTT通信协议:Python可以使用MQTT协议与传感器和设备进行通信,以实现数据的传输和控制。
2、数据库管理:Python可以使用各种数据库,如MySQL、SQLite等,管理物联网智能家居系统中的数据。
3、Web框架:Python中的Web框架,如Flask和Django等,可以用于构建智能家居系统的Web界面,方便用户进行远程控制和监控。

MQTT协议广泛应用于物联网、移动互联网、智能硬件、车联网、电力能源等领域。

物联网M2M通信,物联网大数据采集

Android消息推送,WEB消息推送

移动即时消息,例如Facebook Messenger

智能硬件、智能家具、智能电器

车联网通信,电动车站桩采集

智慧城市、远程医疗、远程教育

电力、石油与能源等行业市场


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/dianzi/13281017.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-07-07
下一篇 2023-07-07

发表评论

登录后才能评论

评论列表(0条)

保存