物联网通信协议(物联网通信协议mqtt)

物联网七大通信协议是：REST/HTTP(松耦合服务调用）、CoAP协议、JMS、XMPP协议（即时通信）、AMQP协议（互操作性）、DDS协议（高可靠性、实时）、MQTT协议（低带宽）。特点：1、REST即表述性状态传递，是基于HTTP协议开发的一种通信风格。主要为了简化互联网中的系统架构，快速实现客户端和服务器之间交互的松耦合，降低了客户端和服务器之间的交互延迟。2、CoAP (Constrained Application Protocol)，受限应用协议，应用于无线传感网中协议。它适用于在资源受限的通信的IP网络。3、JMS (Java Message Service)，即消息服务，这是JAVA平台中著名的消息队列协议。Java消息服务应用程序接口，是一个Java平台中关于面向消息中间件（MOM)的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。4、XMPP(Extensible Messaging and Presence Protocol)可扩展通讯和表示协议，一个开源形式组织产生的网络即时通信协议。5、AMQP(Advanced Message Queuing Protocol)，先进消息队列协议，用于业务系统例如PLM，ERP，MES等进行数据交换。6、DDS(Data Distribution Service for Real-Time Systems)，面向实时系统的数据分布服务。7、MQTT (Message Queuing Telemetry Transport )，消息队列遥测传输，由IBM开发的即时通讯协议，相比来说比较适合物联网场景的通讯协议。

MQTT是非常流行的设备的接入协议，包括IBM、亚马逊、微软的IoT托管服务都有支持，而CoAP在这方面几乎没有露面的机会。感觉以下几点是MQTT优于CoAP的主要原因： MQTT基于TCP，在做反控设备的时候比UDP更可靠，比如CoAP走3G、4G的时候甚至需要实现CoAP over TCP，否则反控很不稳定甚至无法联通。MQTT异步Pub/Sub实现，好比发个微信，无需等待对方确认便可以继续，而不像CoAP那样必须等待对方应答才能返回的同步模式。MQTT为物联网提供了许多体贴的设计，比如QoS，比如“遗言”的设计。篇幅有限，无法完全枚举MQTT的优越性，建议参考以下文章：MQTT入门篇MQTT进阶篇MQTT安全篇MQTT实战篇 当然，CoAP在功耗方面有优势，不过随着物联网设备特别是网管的计算能力加强，这点应该不是主要矛盾。

常见的电力预制舱物联网通信技术这三种： Zigbee是基于IEEE802.15.4标准的低功耗个域网协议。根据这个协议规定的技术是一种短距离、低功耗的无线通信技术。其特点是近距离、低复杂度、自组织、低功耗、低数据速率、低成本。是一种便宜的，低功耗的近距离无线组网通讯技术。Zigbee使用频段为2.4G，868MHz以及915MHz。在不使用功率放大器的前提下，Zigbee的有效传输范围为10-75m。 Z-Wave是基于射频的、低成本、低功耗、高可靠、适于网络的短距离无线通信技术，由丹麦公司Zensys所一手主导的无线组网规格。工作频带为908.42MHz(美国)~868.42MHz(欧洲)，采用FSK(BFSK/GFSK)调制方式，数据传输速率为9.6 kbps，适合于窄宽带应用场合。

物联网是新一代信息技术的重要组成部分，也是「信息化」时代的重要发展阶段。其英文名称是：「Internet of things（IoT）」。顾名思义，物联网就是物物相连的互联网。这有两层意思：其一，物联网的核心和基础仍然是互联网，是在互联网基础上的延伸和扩展的网络；其二，其用户端延伸和扩展到了任何物品与物品之间，进行信息交换和通信，也就是物物相息。物联网通过智能感知、识别技术与普适计算等通信感知技术，广泛应用于网络的融合中，也因此被称为继计算机、互联网之后世界信息产业发展的第三次浪潮。物联网是互联网的应用拓展，与其说物联网是网络，不如说物联网是业务和应用。因此，应用创新是物联网发展的核心，以用户体验为核心的创新 2.0 是物联网发展的灵魂。
物联网是指通过信息传感设备，按约定的协议，将任何物体与网络相连接，物体通过信息传播媒介进行信息交换和通信，以实现智能化识别、定位、跟踪、监管等功能的一种网络。
你好，很高兴为你解答： 物联网即“万物相连的互联网”，是指通过各种信息传感器、射频识别技术、全球定位系统、红外感应器、激光扫描器等各种装置与技术，实时采集任何需要监控、连接、互动的物体或过程，采集其声、光、热、电、力学、化学、生物、位置等各种需要的信息，通过各类可能的网络接入，实现物与物、物与人的泛在连接，实现对物品和过程的智能化感知、识别和管理。
物联网即物物相连的互联网。物联网是由KevinAshton教授首次提出，它的基础与核心依旧是互联网，是在互联网的基础上延伸及拓展的网络
物联网是基于互联网、传统电信网等信息承载体，让所有能行使独立功能的普通物体实现互联互通的网络。

时间：2018-07-26Q: 什么是网络连接？A:网络连接是传输层定义的概念，在传输层以下只存在网络数据包的相互交换。所谓连接，其实也不是在网络上有一条真实存在的数据通道。只要通信双方在一段时间内持续保持数据包交换，就可以视为双方建立的连接并没有断开。连接的建立是依托于TCP协议的三次握手，一旦连接已经建立完毕，通信双方就可以复用这条虚拟通道进行数据交换。如果连接保持长时间工作一直没有被中断，那么这样的TCP连接就俗称为长连接。Message Queue Telemetry Transport ，中文直译：消息队列遥测传输协议。在MQTT协议被设计出来的年代，还没有物联网这么时髦的词汇，当年叫做遥测设备。MQTT协议真正开始声名鹊起的原因，是其正好恰恰踩中移动互联网发展的节拍，为消息推送场景提供了一个既简便又具有良好扩展性的现成解决方案。http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html可以看出，MQTT对消息头的规定十分精简，固定头部占用空间大小仅为1个字节，一个最小的报文占用的空间也只有两个字节（带一字节的长度标识位）。这也是MQTT协议针对不稳定及带宽低下的网络环境做出的特定设计 - - - -尽可能地节省一切不必要的网络开销。Q：为什么MQTT协议需要心跳报文(PINGREQ, PINGRESP)来维护连接状态，只监控该TCP的连接状态是否可以实现目的？A:TCP数据传输默认的超时时间过长，不符合应用层上细粒度的要求。TCP数据传输超时的情况可分成三种： 服务端断开 、 客户端断开 、 中间网络断开 。在前两种场景下，若断开操作是一方主动发起的，即表示为TCP连接正常结束，双方走四次挥手流程；若程序异常结束，则会触发被动断开事件，通信另一方也能立刻感知到本次连接所打开的 Socket 出现中断异常。唯独中间网络的状态是通信双方不能掌握的。在Linux系统下，TCP的连接超时由内核参数来控制，如果通信中的一方没有得到及时回复，默认会主动再尝试6次。如果还没有得到及时回应，那么其才会认定本次数据超时。连带首次发包与六次重试，Linux系统下这7次发包的超时时间分别为2的0次方至2的6次方，即1秒、2秒、4秒、8秒、16秒、32秒、64秒，一共127秒。MQTT协议认为如此长的超时时间对应用层而言粒度太大，因此其在应用层上还单独设计属于自身的心跳响应控制。常见的MQTT连接超时多被设定为 60秒 。扩展知识- TCP的KeepAlive机制： http://hengyunabc.github.io/why-we-need-heartbeat/由通信中的报文标识符(Packet Identifier )传达。Q：仅Publish与Pubrec能保证消息只被投递一次吗？A：业务上可以实现，但MQTT协议并没有如此设计，原因如下：每个消息都会拥有属于自己的报文标识符，但如果需要两次数据交换就实现消息仅只收到一次，就需要通信双方记录下每次使用的报文标识符，并且在处理每一条消息时都需要去重处理，以防消息被重复消费。但MQTT协议最初被设计的工作对象是轻量级物联设备，为此在协议的设计中报文标识符被约定为可重用，以减少对设备性能的消耗，换回的代价不得不使用四次网络数据交换，才能确保消息正好被消费一次。Q：两个不同客户端在发布与订阅同一Topic下的消息时，都可以提出通信Qos要求，此时以哪项为基准？A：伪命题，故意在分享时埋下坑，等人来踩。两个不同客户端的通信是需要 Broker 进行中转，而不是直连。因此，通信中存在两个不同的会话，双方的Qos要求仅仅作用于它们与 Broker 之间的会话，最终的Qos基准只会向最低要求方看齐。例：遗嘱消息的正确使用方式可参考此篇文章： https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament虽然可以借助Retain Message实现绑定一条消息至某个Topic，以达到消息的暂时保留目的。但首先Retain Message并不是为存储场景而设计的，再次MQTT协议并没有对消息的持久化作出规定，也就是说Broker重启后，现有保留消息也将丢失。Q：两种特殊消息的使用场景？A：遗嘱消息，多用于客户端间获取互相之间异常断线的消息通知；保留消息，可保存最近一条广播通知，多用于公告栏信息的发布。Eclipse Mosquitto ：MQTT协议的最小集实现有 EMQ ,HiveMQ ,RabbitMQ MQTT Adapter 等。Qos=2 消息保障的网络I/O次数过多，如果不是必需，尽少在程序里使用此类消息。毕竟当初其设计的目的是为了减少设备的性能占用，但若应用场景并不是物联网，而是用于手机、电脑或浏览器端等现在已不缺性能的设备上，最好在报文体中，使用UUID生成全局唯一的消息ID，然后自行在业务解析中判断此报文是否被消费过。或者，业务方在处理消息时保证其被消费的幂等性，也可消除重复消息对系统带来的影响。正如MQTT协议并没有依赖TCP连接状态，自己在应用层协议上实现心跳报文来控制连接状态，业务方作为MQTT协议的使用者，也不要完全依赖协议的工作状态，而是依托MQTT协议建立属于业务本身的信息汇报机制，以加强系统的稳健性。Retain Message 可视为客户端主动拉取的行为。如果业务系统采用HTTP+MQTT双协议描述业务过程，主动拉取的操作也可使用HTTP请求替代。作为一个长连接型的应用，上线前需要根据业务量级，评估对操作系统端口数与文件描述符的占用要求，以防服务器资源被打满。在服务端的配置文件和客户端的连接参数中，都拥有 max_inflight_messages 此项配置，来维护 Qos=1 or 2 消息是否被成功消费的状态。MQTT 最初被设计为物联网级的通信协议，因此此参数的默认配额较小（大多数情况下被限制到10至20）。但如果将MQTT协议应用至手机、PC或Web端的推送场景时，硬件性能已不在是瓶颈，在实际使用中推荐把此参数调大。Mosquitto提供Bridge功能，需要我们自己配置。Bridge 意为桥接，当我们把两台Broker桥接在一起时，只需要修改一台Broker的配置，填上另一台Broker的运行地址。前一台Broker将作为客户端发布与订阅后一台Broker的所有Topic，实现消息互通的目的。桥接带来的问题有以下几点：我的建议：Websockets协议被设计的目的是为浏览器提供一个全双工的通信协议，方便实现消息推送功能。在Websockets协议被设计出来前，受限于HTTP协议的一问一答模型，消息的推送只能靠轮询来实现，在资源消耗与时效性保障上，均难以达到令人满意的效果。Websockets协议复用了HTTP协议的头部信息，告知浏览器接下来的操作将触发协议升级，然后通信双方继续复用HTTP的Header，但报文内容已转变为双方均接受的新协议的格式。Websockets协议改进了网页浏览中的消息推送的方式，因此被广泛应用在聊天、支付通知等实时性要求比较高的场合下。MQTT协议重点在于消息队列的实现，其对消息投递的方式作出约定，并提供一些额外的通信保障。MQTT可采取原生的TCP实现，也有基于Websockets的实现版本。当然后者在网络字节的利用率上，不如前者那么精简。但浏览器端无法直接使用TCP协议，所以就只能基于Websockets协议开发。不过基于Websockets的应用也有方便之处：一是证书不需要额外配置，直接与网站共用一套基础设施；二是可使用Nginx等工具管理流量，与普通HTTP流量可共用一套配置方法。MQTT非常适合入门，原因如下：实际的应用场景远比理想中的复杂，无法一招走遍天下，必须做好取舍。MQTT协议在这方面做得很优秀，以后工作中可以作为参考，设计好自己负责的业务系统。