‘壹’ MQTT和Websocket的区别是什么
简单回答一下, MQTT ( MQ Telemetry Transport ) 是针对物联网而设计的, 如手机对家里的智能开关, 而 WebSocket 是针对浏览器与服务器之间而设计的. 两者基本上是两个世界的东西.
MQTT 只是一个接口, 让两个 "物件" 能够透过 TCP 协议通讯, 但并没有规定(在应用层面上)通讯中要怎样"对答", 如 pop3 邮件服务器会有:
S: 220 我是 xxx 服务器
C: HELO myServer
S: 250 Nice to meet you
C: auth login
....
这些是没有硬性被定义的, 两个 "物件" 之间要怎么"聊天", 由你自己来定.
WebSocket 则是一个 http 协议中的伸延 (先这麼理解吧!), 而 http 协议, 基本上就是一个请求, 一个回答, 然后就自动挂线, 客端和服务器端不会婆婆妈妈. 但即使就前面说的, 一问一答, 当中便有大量的 header 字串来往, 如果要处理串流这样大的数据再 + 一大堆 header, 这样就是很庞大的负担, websocket 就开了这个婆妈之门, 客端和服务器端可以以 full plex 的形式做大量 binary 的数据传输, 决省了一大堆 header, 其中一些安全机制也保证了大堆资料不被搞乱. 但无论如何, WebSocket 离不开 HTTP!!!
以上, 只是很概念的说法, 便于你理解, 详细你得自己翻下文献了.
‘贰’ 如何通过php实现mqtt协议
MQTT是一个轻量级的消息发布/订阅协议，它是实现基于手机客户端的消息推送服务器的理想解决方案。
我们可以从这里下载该项目的实例代码，并且可以找到一个采用PHP书写的服务器端实现。
架构如下所示：
‘叁’ MQTT 基本认知
物联网 (internet of thing) ，表示的是可以把一些带某些传感器的设备(终端)，接入到互联网的行为。
通过互联网连接这些设备，这些设备就能够互相协作。
而 MQTT 就是这些设备之间数据通信的一个基于 TCP/IP 的协议。
每个终端都和实现了 MQTT 协议的代理/服务器相连。
通过 published MQTT 代理服务器的某个 主题 发送数据。
通过 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协议解读及使用经验
时间：2018-07-26
Q: 什么是网络连接？
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协议在这方面做得很优秀，以后工作中可以作为参考，设计好自己负责的业务系统。
‘伍’ web 物联网用什么开发
物联网中最常用的编程语言，即Java，C，C ++，Python，JavaScript和Go。
Java：物联网技术最流行的编程语言
Java有多个应用领域，从后端编程到Android的移动应用。根据 Eclipse基金会执行的2017年物联网开发者调查，Java首次提供了用于物联网开发的编程语言列表，专门用于网关和云。
使用Java进行物联网开发的一个主要好处是便携性。Java没有任何硬件限制，这意味着您可以在计算机上编写和调试Java代码，并将其部署到几乎任何运行Java虚拟机的设备上。出于这个原因，许多公司选择聘请Java开发人员进行物联网项目。
C：嵌入式设备的关键编程语言
C编程语言接下来成为物联网IoT堆栈最喜欢的语言。然而，根据Eclipse基金会的说法，它被认为是受限设备开发的领先技术。
该编程语言提供对低级硬件API的直接访问。由于其与机器语言的相似性，C非常快速且灵活，使其成为处理能力有限的物联网系统的完美选择。
C ++：Linux的第一语言
与其前身C一样，C ++已广泛用于嵌入式系统开发。但是，C ++的主要优势在于处理能力，在任务更加复杂时使其成为C的有用替代方案。
C ++最适合编写硬件特定的代码。它可与Linux，第一大物联网技术操作系统配合使用。但是，与Java相比，它具有有限的可移植性。
Python：面向数据的物联网系统的解决方案
作为最受欢迎的网络编程语言之一，以及科学计算的前沿技术，Python在物联网开发中也获得了巨大的推动力。 对于数据密集型应用程序，Python是一个不错的选择，特别是在管理和组织复杂数据时。
JavaScript：事件驱动物联网应用的最佳解决方案
根据年度StackOverflow开发者调查显示，JavaScript是过去五年来最流行的编程语言之一，是现代Web开发中的核心技术。
在许多其他应用领域中，JavaScript是物联网编程语言中最常用的构建事件驱动系统。它可以管理连接设备的大型网络，并且在需要处理多个任务而无需等待其他任务完成时可以胜任。JavaScript对IoT的主要优势之一是非常节约资源。
Go：坚固的技术堆栈为复杂的物联网网络提供动力
Go是一款开源编程语言，由Google创建。尽管它不能像语言那样拥有同样广泛的用途，但我们之前专注于这一点，它是在您的物联网系统内建立通信层的强大技术。
Go语言关于物联网的主要优势是并发性和同时运行多个进程（数据输入和输出）的能力。这使得构建由多个传感器和设备组成的复杂IoT网络变得更加容易。
‘陆’ 关于stm32与服务器通信的问题
你是想用web远程监控单片机的运行，但是不知道怎么把单片机的信息上传到服务器，转化成web页面展示出来，我做过一个是通过阿里云IOT实现的
单片机内加入MQTT协议，与阿里云服务器通信，可以通过IOT studio快速配置生成web
官方给到历程是都是通过ESP的WiFi来联网。我做的是通过W5500联网的
把C语言Link Kit SDK移植到stm32单片机中，web由IOT studio生成。
‘柒’ 如何实现消息推送功能
?可以用第三方软件极光推送来实现。对于定制化需求较强的，或者想拥有自己推送平台的开发者，极光提供全功能的私有云方案。极光推送快速开始步骤: 1、到极光推送官方网站注册开发者帐号；
2、登录进入管理控制台，创建应用程序，得到 Appkey（SDK 与服务器端通过 Appkey 互相识别）；
3、在推送设置中给 Android 设置包名、给 iOS 上传证书、启用 WinPhone，根据你的需求进行选择；
4、下载 SDK 集成到 App 里。
客户端初始化 JPush 成功后，JPush 服务端会分配一个 Registration ID，作为此设备的标识（同一个手机不同 App 的 Registration ID 是不同的）。开发者可以通过指定具体的 Registration ID 来进行对单一设备的推送。