mqtt底层是socket(mqtt底层原理)

MQTT协议是广泛应用的物联网协议，使用测试MQTT协议需要MQTT的代理。有两种方法使用MQTT服务，一是租用现成的MQTT服务器，如阿里云，百度云，华为云等公用的云平台提供的MQTT服务，使用公用的MQTT服务器的好处是省事，但如果仅仅用于测试学习还需要注册帐号，灵活性差些，有的平台还需要付费。另一方法是自己使用开源的MQTT组件来搭建。 MQTT服务器非常多，如apache的ActiveMQ，emtqqd，HiveMQ，Emitter，Mosquitto，Moquette等等。这里介绍的是用轻量级的mosquitto开源项目来搭建一个属于自己的MQTT服务器。第一步：需要安装一台linux主机，这不多介绍，可以使用真机安装也可以使用虚拟机安装。如果仅仅是自己测试使用都可以。第二步：下载mosquitto需要的依赖sudo apt-get install libssl-devsudo apt-get install uuid-devsudo apt-get install cmake第三步：下载mosquitto并解压，现在mosquitto官网最新的版本是1.5.1tar xzvf mosquitto-1.5.1.tar.gz第四步：编译cd mosquitto-1.5.1/makemake install第五步：启动mosquitto./mosquitto -v1535473957: mosquitto version 1.5.1 starting1535473957: Using default config.1535473957: Opening ipv4 listen socket on port 1883.1535473957: Opening ipv6 listen socket on port 1883.这时候mosquitto就会以默认的参数启动。如果需要带配置文件可以修改配置文件mosquitto.conf，启动时候加上参数 -c，./mosquitto -c mosquitto.conf可以看到，mosquitto监听的端口为1883.这时候我们的MQTT服务器就搭建好了。可找一个mqtt客户端来测试一下。先发布一个主题“home/garden/fountain/2”内容是“hello world”这时候在mosquitto会打印出下面的log535474247: New connection from 192.168.1.105 on port 1883.1535474247: New client connected from 192.168.1.105 as MQTT_FX_Client (c1, k60).1535474247: No will message specified.1535474247: Sending CONNACK to MQTT_FX_Client (0, 0)1535474307: Received PINGREQ from MQTT_FX_Client1535474307: Sending PINGRESP to MQTT_FX_Client1535474339: Received PUBLISH from MQTT_FX_Client (d0, q0, r0, m0, 'home/garden/fountain/2', ... (12 bytes))1535474367: Received PINGREQ from MQTT_FX_Client1535474367: Sending PINGRESP to MQTT_FX_Client订阅主题“home/garden/fountain/2”可以看到收到了自己发布的消息。用wireshark抓包 可以看到抓到了一个MQTT的publish的报文。
云服务器内的防火墙设置了吗？mqtt的通讯端口是什么？云服务提供商的安全组设置了吗？如果都设置了，服务启动了吗？端口正常监听吗？ 按如下格式提供你的信息：系统版本：# 命令uname -a服务状态：# 命令systemctl status 服务名端口监听状态：# 命令netstat -antupl防火墙放行端口:# 命令firewall-cmd --list-port云服务商安全组设置 不然没法帮你判断问题出现的位置以及如何解决该问题
MQTT协议是广泛应用的物联网协议，使用测试MQTT协议需要MQTT的代理。有两种方法使用MQTT服务，一是租用现成的MQTT服务器，如阿里云，百度云，华为云等公用的云平台提供的MQTT服务，使用公用的MQTT服务器的好处是省事，但如果仅仅用于测试学习还需要注册帐号，灵活性差些，有的平台还需要付费。另一方法是自己使用开源的MQTT组件来搭建。 MQTT服务器非常多，如apache的ActiveMQ，emtqqd，HiveMQ，Emitter，Mosquitto，Moquette等等。这里介绍的是用轻量级的mosquitto开源项目来搭建一个属于自己的MQTT服务器。第一步：需要安装一台linux主机，这不多介绍，可以使用真机安装也可以使用虚拟机安装。如果仅仅是自己测试使用都可以。第二步：下载mosquitto需要的依赖sudo apt-get install libssl-devsudo apt-get install uuid-devsudo apt-get install cmake第三步：下载mosquitto并解压，现在mosquitto官网最新的版本是1.5.1tar xzvf mosquitto-1.5.1.tar.gz第四步：编译cd mosquitto-1.5.1/makemake install第五步：启动mosquitto./mosquitto -v1535473957: mosquitto version 1.5.1 starting1535473957: Using default config.1535473957: Opening ipv4 listen socket on port 1883.1535473957: Opening ipv6 listen socket on port 1883.这时候mosquitto就会以默认的参数启动。如果需要带配置文件可以修改配置文件mosquitto.conf，启动时候加上参数 -c，./mosquitto -c mosquitto.conf可以看到，mosquitto监听的端口为1883.这时候我们的MQTT服务器就搭建好了。可找一个mqtt客户端来测试一下。先发布一个主题“home/garden/fountain/2”内容是“hello world”这时候在mosquitto会打印出下面的log535474247: New connection from 192.168.1.105 on port 1883.1535474247: New client connected from 192.168.1.105 as MQTT_FX_Client (c1, k60).1535474247: No will message specified.1535474247: Sending CONNACK to MQTT_FX_Client (0, 0)1535474307: Received PINGREQ from MQTT_FX_Client1535474307: Sending PINGRESP to MQTT_FX_Client1535474339: Received PUBLISH from MQTT_FX_Client (d0, q0, r0, m0, 'home/garden/fountain/2', ... (12 bytes))1535474367: Received PINGREQ from MQTT_FX_Client1535474367: Sending PINGRESP to MQTT_FX_Client订阅主题“home/garden/fountain/2”可以看到收到了自己发布的消息。用wireshark抓包 可以看到抓到了一个MQTT的publish的报文。

MQTT跟WebSocket关系不大。他们不是在一个层级的。WebSocket 很多网站使用轮询实现推送技术。轮询是在特定的的时间间隔（比如1秒），由浏览器对服务器发出HTTP request，然后由服务器返回最新的数据给浏览器。轮询的缺点很明显，浏览器需要不断的向服务器发出请求，然而HTTP请求的header是非常长的，而实际传输的数据可能很小，这就造成了带宽和服务器资源的浪费。Comet使用了AJAX改进了轮询，可以实现双向通信。但是Comet依然需要发出请求，而且在Comet中，普遍采用了长链接，这也会大量消耗服务器带宽和资源。于是，WebSocket协议应运而生。 浏览器通过 JavaScript 向服务器发出建立 WebSocket 连接的请求，连接建立以后，客户端和服务器通过 TCP 连接直接交换数据。WebSocket 连接本质上是一个 TCP 连接。WebSocket在数据传输的稳定性和数据传输量的大小方面，具有很大的性能优势。Websocket.org 比较了轮询和WebSocket的性能优势：HTTP 轮训每次需要返回871个字节，websocket每次只需要2个字节Use Case A： 1,000个客户端每秒接受一个message，网络吞吐量 （2*1,000）=2,000 bytes = 16,000 每秒bitsUse Case B： 10,000个客户端每秒接受一个message，网络吞吐量 （2*10,000）=20,000 bytes = 160,000 每秒bitsUse Case C： 100,000个客户端每秒接受一个message，网络吞吐量 （2*100,000）=200,000 bytes = 1,600,000 每秒bitsMQTT 协议是为大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议，它具有以下主要的几项特性：非常小的通信开销（最小的消息大小为 2 字节），小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量。支持各种流行编程语言（包括 C，Java，Ruby，Python 等等）且易于使用的客户端；使用发布 / 订阅消息模式，提供一对多的消息发布，解除应用程序耦合。对负载内容屏蔽的消息传输。使用 TCP/IP 提供网络连接。有三种消息发布服务质量，让消息能按需到达目的地，适应在不稳定工作的网络传输需求 ："至多一次"，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。"至少一次"，确保消息到达，但消息重复可能会发生。"只有一次"，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。
简单回答一下, MQTT ( MQ Telemetry Transport ) 是针对物联网而设计的, 如手机对家里的智能开关, 而 WebSocket 是针对浏览器与服务器之间而设计的. 两者基本上是两个世界的东西. MQTT 只是一个接口, 让两个 "物件" 能够透过 TCP 协议通讯, 但并没有规定(在应用层面上)通讯中要怎样"对答", 如 pop3 邮件伺服器会有:S: 220 我是 xxx 服务器C: HELO myServerS: 250 Nice to meet youC: auth login....这些是没有硬性被定义的, 两个 "物件" 之间要怎麼"聊天", 由你自己来定.WebSocket 则是一个 http 协议中的伸延 (先这麼理解吧!), 而 http 协议, 基本上就是一个请求, 一个回答, 然後就自动挂线, 客端和服务器端不会婆婆妈妈. 但即使就前面说的, 一问一答, 当中便有大量的 header 字串来往, 如果要处理串流这样大的数据再 + 一大堆 header, 这样就是很庞大的负担, websocket 就开了这个婆妈之门, 客端和服务器端可以以 full duplex 的形式做大量 binary 的数据传输, 决省了一大堆 header, 其中一些安全机制也保证了大堆资料不被搞乱. 但无论如何, WebSocket 离不开 HTTP!!! 以上, 只是很概念的说法, 便於你理解, 详细你得自己翻下文献了.
MQTT 跟 Websocket 可以认为是不同层面的协议。MQTT 做原生设备的通信，MQTT over WebSocket 主要用于 MQTT 设备跟 Web 端通信。 MQTT是为了物联网场景设计的基于TCP的Pub/Sub协议，有许多为物联网优化的特性，比如适应不同网络的QoS、层级主题、遗言等等。WebSocket是为了HTML5应用方便与服务器双向通讯而设计的协议，HTTP握手然后转TCP协议，用于取代之前的Server Push、Comet、长轮询等老旧实现。两者之所有有交集，是因为一个应用场景：如何通过HTML5应用来作为MQTT的客户端，以便接受设备消息或者向设备发送信息，那么MQTT over WebSocket自然成了最合理的途径了。作者：张琪链接：http://www.zhihu.com/question/21816631/answer/81953429来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
根据你的描述： MQTT 跟 Websocket 可以认为是不同层面的协议。MQTT 做原生设备的通信，MQTT over WebSocket 主要用于 MQTT 设备跟 Web 端通信。

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是轻量级基于代理的发布/订阅的消息传输协议，设计思想是开放、简单、轻量、易于实现。这些特点使它适用于受限环境。例如： ①网络代价昂贵，带宽低、不可靠。②在嵌入设备中运行，处理器和内存资源有限。该协议的特点有：①使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。②对负载内容屏蔽的消息传输。③使用 TCP/IP 提供网络连接。④有三种消息发布服务质量：⑤"至多一次"，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。⑥"至少一次"，确保消息到达，但消息重复可能会发生。⑦"只有一次"，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。⑧小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量。⑨使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制。WebSocket则提供使用一个TCP连接进行双向通讯的机制，包括网络协议和API，以取代网页和服务器采用HTTP轮询进行双向通讯的机制。本质上来说，WebSocket是不限于HTTP协议的，但是由于现存大量的HTTP基础设施，代理，过滤，身份认证等等，WebSocket借用HTTP和HTTPS的端口。由于使用HTTP的端口，因此TCP连接建立后的握手消息是基于HTTP的，由服务器判断这是一个HTTP协议，还是WebSocket协议。 WebSocket连接除了建立和关闭时的握手，数据传输和HTTP没丁点关系了。由此可知两者的应用场景不一样：MQTT是为了物联网场景设计的基于TCP的Pub/Sub协议，有许多为物联网优化的特性，比如适应不同网络的QoS、层级主题、遗言等等。WebSocket是为了HTML5应用方便与服务器双向通讯而设计的协议，HTTP握手然后转TCP协议，用于取代之前的Server Push、Comet、长轮询等老旧实现。 两者之所有有交集，是因为一个应用场景：如何通过HTML5应用来作为MQTT的客户端，以便接受设备消息或者向设备发送信息，那么MQTT over WebSocket自然成了最合理的途径了。

1.Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，我们才能使用TCP/IP协议。 2.MQTT协议是应用层协议不依赖长连接，适合弱网络。通过topic缓存信息。符合物联网设备的使用场景。因为通过topic缓存信息，因此可以实现通过topic与多个端的一对多连接，而不是设备与设备的多对多连接，节省了能耗及带宽。MQTT的心跳，及非信息的报文，较Websocket更少，更节省带宽及能耗。更适用于物理网的多种网络协议。3.WebSocket和Http一样在应用层,提供使用一个TCP连接进行双向通讯的机制，包括网络协议和API，以取代网页和服务器采用HTTP轮询进行双向通讯的机制。本质上来说，WebSocket是不限于HTTP协议的，但是由于现存大量的HTTP基础设施，代理，过滤，身份认证等等，WebSocket借用HTTP和HTTPS的端口。由于使用HTTP的端口，因此TCP连接建立后的握手消息是基于HTTP的，由服务器判断这是一个HTTP协议，还是WebSocket协议。 WebSocket连接除了建立和关闭时的握手，数据传输和HTTP没丁点关系了。Socket 连接,至少需要一对套接字，分为 clientSocket，serverSocket 连接分为3个步骤:(1) 服务器监听:服务器并不定位具体客户端的套接字，而是时刻处于监听状态；(2) 客户端请求:客户端的套接字要描述它要连接的服务器的套接字，提供地址和端口号，然后向服务器套接字提出连接请求；(3) 连接确认:当服务器套接字收到客户端套接字发来的请求后，就响应客户端套接字的请求,并建立一个新的线程,把服务器端的套接字的描述发给客户端。一旦客户端确认了此描述，就正式建立连接。而服务器套接字继续处于监听状态，继续接收其他客户端套接字的连接请求.Socket为长连接：通常情况下Socket 连接就是 TCP 连接，因此 Socket 连接一旦建立,通讯双方开始互发数据内容，直到双方断开连接。在实际应用中，由于网络节点过多，在传输过程中，会被节点断开连接，因此要通过轮询高速网络，该节点处于活跃状态。很多情况下，都是需要服务器端向客户端主动推送数据，保持客户端与服务端的实时同步。若双方是 Socket 连接，可以由服务器直接向客户端发送数据。若双方是 HTTP 连接，则服务器需要等客户端发送请求后，才能将数据回传给客户端。因此，客户端定时向服务器端发送请求，不仅可以保持在线，同时也询问服务器是否有新数据，如果有就将数据传给客户端。MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是轻量级基于代理的发布/订阅的消息传输协议，设计思想是开放、简单、轻量、易于实现。这些特点使它适用于受限环境。例如：①网络代价昂贵，带宽低、不可靠。②在嵌入设备中运行，处理器和内存资源有限。该协议的特点有：①使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。②对负载内容屏蔽的消息传输。③使用 TCP/IP 提供网络连接。④有三种消息发布服务质量：⑤"至多一次"，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。⑥"至少一次"，确保消息到达，但消息重复可能会发生。⑦"只有一次"，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。⑧小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量。⑨使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制。实现MQTT协议需要客户端和服务器端通讯完成，在通讯过程中，MQTT协议中有三种身份：发布者（Publish）、代理（Broker）（服务器）、订阅者（Subscribe）。其中，消息的发布者和订阅者都是客户端，消息代理是服务器，消息发布者可以同时是订阅者。有三种消息发布服务质量：“至多一次”，消息发布完全依赖底层TCP/IP网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。这一种方式主要普通APP的推送，倘若你的智能设备在消息推送时未联网，推送过去没收到，再次联网也就收不到了。qos=0“至少一次”，确保消息到达，但消息重复可能会发生。qos=1“只有一次”，确保消息到达一次。在一些要求比较严格的计费系统中，可以使用此级别。在计费系统中，消息重复或丢失会导致不正确的结果。这种最高质量的消息发布服务还可以用于即时通讯类的APP的推送，确保用户收到且只会收到一次。qos=2Topic，可以理解为消息的类型，订阅者订阅（Subscribe）后，就会收到该主题的消息内容（payload）；payload，可以理解为消息的内容，是指订阅者具体要使用的内容。在MQTT协议中，一个MQTT数据包由：固定头（Fixed header）、可变头（Variable header）、消息体（payload）三部分构成。MQTT数据包结构如下：固定头（Fixed header）。存在于所有MQTT数据包中，表示数据包类型及数据包的分组类标识。可变头（Variable header）。存在于部分MQTT数据包中，数据包类型决定了可变头是否存在及其具体内容。消息体（Payload）。存在于部分MQTT数据包中，表示客户端收到的具体内容。 WebSocket则提供使用一个TCP连接进行双向通讯的机制，包括网络协议和API，以取代网页和服务器采用HTTP轮询进行双向通讯的机制。本质上来说，WebSocket是不限于HTTP协议的，但是由于现存大量的HTTP基础设施，代理，过滤，身份认证等等，WebSocket借用HTTP和HTTPS的端口。由于使用HTTP的端口，因此TCP连接建立后的握手消息是基于HTTP的，由服务器判断这是一个HTTP协议，还是WebSocket协议。 WebSocket连接除了建立和关闭时的握手，数据传输和HTTP没丁点关系了。由此可知两者的应用场景不一样：MQTT是为了物联网场景设计的基于TCP的Pub/Sub协议，有许多为物联网优化的特性，比如适应不同网络的QoS、层级主题、遗言等等。WebSocket是为了HTML5应用方便与服务器双向通讯而设计的协议，HTTP握手然后转TCP协议，用于取代之前的Server Push、Comet、长轮询等老旧实现。两者之所有有交集，是因为一个应用场景：如何通过HTML5应用来作为MQTT的客户端，以便接受设备消息或者向设备发送信息，那么MQTT over WebSocket自然成了最合理的途径了。

做法是通过socket.io做中转，websocket连接到socekt.io上，后台nodejs再连接到mqtt server上。
现在的activemq已经支持直接用js使用mqtt了，原理就是结合websocket,你下载最新的activemq，里面有个example，超级简单的