mqtt协议和tcp协议区别(mqtt协议和modbus协议区别)

udp 和tcp 是 OSI 模型中的运输层中的协议。tcp 提供可靠的通信传输，而 udp 则常被用于让广播和细节控制交给应用的通信传输。两者的区别大致如下：tcp 面向连接，udp 面向非连接即发送数据前不需要建立链接；tcp 提供可靠的服务（数据传输），udp 无法保证；tcp 面向字节流，udp 面向报文；tcp 数据传输慢，udp 数据传输快； tcp 为什么要三次握手，为什么？ 我们假设A和B是通信的双方。我理解的握手实际上就是通信，发一次信息就是进行一次握手。第一次握手：A给B打电话说，你可以听到我说话吗？第二次握手：B收到了A的信息，然后对A说：我可以听得到你说话啊，你能听得到我说话吗？第三次握手：A收到了B的信息，然后说可以的，我要给你发信息啦！在三次握手之后，A和B都能确定这么一件事：我说的话，你能听到；你说的话，我也能听到。这样，就可以开始正常通信了。 注意：HTTP是基于TCP协议的，所以每次都是客户端发送请求，服务器应答，但是TCP还可以给其他应用层提供服务，即可能A、B在建立链接之后，谁都可能先开始通信。如果采用两次握手，那么只要服务器发出确认数据包就会建立连接，但由于客户端此时并未响应服务器端的请求，那此时服务器端就会一直在等待客户端，这样服务器端就白白浪费了一定的资源。若采用三次握手，服务器端没有收到来自客户端的再此确认，则就会知道客户端并没有要求建立请求，就不会浪费服务器的资源。

物联网 (internet of thing)，表示的是可以把一些带某些传感器的设备(终端)，接入到互联网的行为。通过互联网连接这些设备，这些设备就能够互相协作。而MQTT就是这些设备之间数据通信的一个基于 TCP/IP 的协议。每个终端都和实现了MQTT协议的代理/服务器相连。通过publishedMQTT 代理服务器的某个主题发送数据。通过subscription从 MQTT 代理服务器获取自己订阅的主题数据。MQTT 协议是一种轻量级的、灵活的网络协议。并且非常适合 IOT 的场景。大多数开发人员已经熟悉了 HTTP WEB 协议。那么为什么不让 IOT 设置链接到 WEB 服务？设备可以采用 HTTP 请求的形式发送数据，并采用 HTTP 响应的形式从服务器获取数据，接受更新。因为对于 IOT 的设备来说，这种主动请求--> 被动等待应答的数据传输模型存在严重的局限性：那么，MQTT 为什么如此轻便且灵活？MQTT 协议的一个关键的特性是发布/订阅模型。它将数据的发布者和接受者分离。一个设备终端既可以是数据的发布者(published)也可以是数据的订阅者(subscription)。一个设备如果要发布数据，只需要往代理服务器中相应的主题发布数据内容即可。一个设备如果需要接受到数据，只需要在代理服务器中，提前订阅自己需要关注的主题即可。MQTT 最基本的体验，就是使用mosquitto 。Mosquitto是一款实现了 MQTT v3.1 协议的开源消息代理软件，提供轻量级的，支持发布/订阅的的消息推送模式，使设备对设备之间的短消息通信简单易用。它可以理解成一个 MQTT 的代理服务器。基本步骤如下：安装成功截图使用brew services start mosquitto启动 MQTT 服务运行截图然后再打开另外两个终端窗口，模拟两个IOT设备。A 订阅 MQTT 服务。B 向 MQTT 的服务发送数据。A订阅当前MQTT的某个服务。B向 MQTT 服务器发布(published) 数据。然后，我们就可以在A控制台里看到由 B 通过 MQTT 服务发送的数据了。基本流程图控制台 A 向 MQTT 服务器订阅dw/demo服务，并被动的等待 MQTT 服务器返回数据。控制台 B 主动的向 MQTT 服务器的dw/demo服务发送published数据，之后。服务器会主动向事先订阅了dw/demo的终端分发此消息。MQTT 是一种链接协议，它指定了如何组织数据字节并通过 TCP/IP 网络传输它们。但实际上，开发人员并不需要链接这个链接协议的具体细节。我们只需要知道，每条消息都有一个命令和数据有效负载。该命令定义消息类型(比如 CONNECT 消息或者 SUB SCRIBE 消息)。所有的 MQTT 库和工具都提供了直接处理这些消息的基本方法，并且能自动填充一些必要的字段(在数据包的对应字节填充)，比如消息和客户端 ID。首先客户端发送一条CONNECT消息来链接代理。CONNECT 消息要求建立从客户端到代理服务器的链接。CONNECT 命令的基本参数当客户端向代理服务器发送一条CONNECT命令之后，服务器会调用CONNACK命令，告知服务链接的状态。CONNACK 命令的基本参数当客户端和服务器建立连接之后，客户端就可以向服务器订阅某些主题的。(发送一条或多条SUBSCRIBE消息)。表明当服务器接受到其他终端推送的此主题数据时，服务器会默认发送给它。SUBSCRIBE 参数列表当客户端成功的向服务器订阅某个主题之后，服务器会返回一条SUBACK的消息，其中包含一个或者多个 returnCode 参数。SUBACK消息参数returnCode: 值 0 - 2 ，表示成功订阅，并返回这个订阅消息的 QOS。值 128 ： 订阅失败。既然客户端可以向服务器订阅某个主题，当然也可以取消订阅。与SUBSCRIBE订阅命令相反的命令是UNSUBSCRIBE取消订阅命令。此命令非常简单。只有一个topic(主题)参数。上面讲的是订阅，订阅是需要有消息从服务器发送过来的。但是服务器本身基本不产生数据，那数据从何而来呢？通过另外一个客户端执行PUBLISH命令，往代理服务器发送数据。并最终通过代理服务器将数据传递给订阅了此服务的客户端。PUBLISH 消息参数对于 MQTT 的一张基本理解图基本流程图：最后总结参考资料： 初识 MQTT

两者的应用场景不一样： MQTT是为了物联网场景设计的基于TCP的Pub/Sub协议，有许多为物联网优化的特性，比如适应不同网络的QoS、层级主题、遗言等等。WebSocket是为了HTML5应用方便与服务器双向通讯而设计的协议，HTTP握手然后转TCP协议，用于取代之前的Server Push、Comet、长轮询等老旧实现。 两者之所有有交集，是因为一个应用场景：如何通过HTML5应用来作为MQTT的客户端，以便接受设备消息或者向设备发送信息，那么MQTT over WebSocket自然成了最合理的途径了。

时间：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协议在这方面做得很优秀，以后工作中可以作为参考，设计好自己负责的业务系统。

定义不同： UDP:用户数据报协议。TCP:传输控制协议连接方式不同：UDP：无连接 TCP:建立连接首部长度不同：UDP:8位 TCP:20位可靠性不同： UDP：不可靠 TCP：全双工通信的的可靠连接协议
tcp：提供面向连接的服务，数据传输前先建立连接，传输完毕后释放连接，提供可靠连接； udp：发送数据前不需要先建立连接，发送后也不需要释放连接，减少开销和延迟，但不保证可靠交付。
TCP 先建立连接再传输 A：我给你发点东西，你接收一下B：好的，你发吧A：好的，正在发送UDP 不用建立连接直接传输 A：我给你发点东西，爱要不要，反正我已经发过去去了