mqtt协议和tcp协议区别(mqtt与104协议区别)

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

TCP是美国国防部设计的两种传输协议之一，另一种是UDP。UDP是一种不可靠的网络服务，负载比较小，而TCP则是一种可靠的通信服务，负载相对而言比较大。TCP采用套接字（socket）或者端口（port）来建立通信。TCP给端口到端口通信提供了错误和流量控制机制，同时TCP还负责建立连接、处理终止和中断的端对端通信控制。 通常情况下我们认为TCP相比UDP具有更大的通信负载，UDP不具备TCP的控制特性，TCP用了大约20个字节来发送一个65Kbps的数据块，这个报头占整个数据块的比重也不过3%。总得来看，这个负载是合理的，何况还令通信具有了可靠性。

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在建立链接之后，谁都可能先开始通信。 如果采用两次握手，那么只要服务器发出确认数据包就会建立连接，但由于客户端此时并未响应服务器端的请求，那此时服务器端就会一直在等待客户端，这样服务器端就白白浪费了一定的资源。若采用三次握手，服务器端没有收到来自客户端的再此确认，则就会知道客户端并没有要求建立请求，就不会浪费服务器的资源。
TCP/IP协议是一个协议簇。里面包括很多协议的，UDP只是其中的一个， 之所以命名为TCP/IP协议，因为TCP、IP协议是两个很重要的协议，就用他两命名了。 TCP/IP协议集包括应用层,传输层，网络层，网络访问层。

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

物联网 (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