MQTT的优势

Posted 2020-12-12 wllgo

最近在开发新产品时，新产品支持的协议HTTPS/MQTT等标准协议，有人问我为什么一定要选择MQTT？我自己思考了下，也没有很清晰的概念，到网上找了MQTT相关资料，记录如下。

①低协议开销
MQTT 的独特之处在于，它的每消息标题可以短至 2 个字节。MQ 和 HTTP 都拥有高得多的每消息开销。对于 HTTP，为每个新请求消息重新建立 HTTP 连接会导致重大的开销。MQ 和 MQTT 所使用的永久连接显著减少了这一开销。
 ②对不稳定网络的容忍
MQTT 和 MQ 能够从断开等故障中恢复，而且没有进一步的代码需求。但是，HTTP 无法原生地实现此目的，需要客户端重试编码，这可能增加幂等性问题。
 ③低功耗
MQTT 是专门针对低功耗目标而设计的。HTTP 的设计没有考虑此因素，因此增加了功耗。
 ④数百万个连接的客户端
在 HTTP 堆栈上，维护数百万个并发连接，需要做许多的工作来提供支持。尽管可以实现此支持，但大多数商业产品都为处理这一数量级的永久连接而进行了优化。IBM 提供了 IBM MessageSight，这是一个单机架装载服务器，经过测试能处理多达 100 万个通过 MQTT 并发连接的设备。相反，MQ 不是为大量并发客户端而设计的。
 ⑤推送通知
您需要能够及时地将通知传递给客户。为此，必须采用某种定期轮询或推送方法；从电池、系统负载和带宽角度讲，推送是最佳解决方案。
我们的企业可能需要在没有第三方中介的情况下发送敏感的信息。这降低了特定于操作系统的解决方案（比如 Apple ios、Google Play 通知）作为主要传输机制的价值。
HTTP 只允许使用一种称为COMET 的方法，使用持久的 HTTP 请求来执行推送。从客户端和服务器的角度讲，此方法都很昂贵。MQ 和 MQTT 都支持推送，这是它们的一个基本特性。
⑥客户端平台差异
HTTP 和 MQTT 客户端都已在大量平台上实现。MQTT 的简单性有助于以极少的精力在额外的客户端上实现 MQTT。
⑦ 防火墙容错
一些企业防火墙将出站连接限制到一些已定义的端口。这些端口通常被限制为 HTTP（80 端口）、HTTPS（443 端口）等。HTTP 显然可以在这些情况下运行。MQTT 可封装在一个 WebSockets 连接中，显示为一个 HTTP 升级请求，从而允许在这些情况下运行。MQ 不允许采用这种模式。
事实上，MQTT的应用非常之广泛，几乎现在随便找一家大型的硬件、互联网企业，都可以找到MQTT的身影，例如Facebook、BP、alibaba、baidu等等
————————————————
针对我这个开发的产品，我认为第四个功能是很重要的，也解释问什么要用MQTT，随着客户端设备越来越多，HTTPS在多台设备并发时，响应不够快，轮询时间长等。

http使用TCP 三次握手建立连接，客户端和服务器需要交换3个包，https除了 TCP 的三个包，还要加上 ssl握手需要的9个包，所以一共是12个包。http 建立连接，按照下面链接中针对Computer Science House的测试，是114毫秒；https建立连接，耗费436毫秒。ssl 部分花费322毫秒，包括网络延时和ssl 本身加解密的开销（服务器根据客户端的信息确定是否需要生成新的主密钥；服务器回复该主密钥，并返回给客户端一个用主密钥认证的信息；服务器向客户端请求数字签名和公开密钥）。
————————————————
版权声明：本文为CSDN博主「yy-captain」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/makenothing/java/article/details/78378293

原文链接：https://blog.csdn.net/anxianfeng55555/java/article/details/80908958