MQTT vs HTTP：谁更适合物联网？

媒介

随着物联网（IoT）技术的飞速发展中，其应用规模和使用场景正在持续扩大，但它关键的流程仍然是围绕数据传输来进行的，因此设备通信协议选择至关紧张。
作为两种紧张的通信协议，MQTT 协议和 HTTP 协议各自拥有独特的上风和应用场景：MQTT 完全围绕物联网设计，拥有更灵活的使用方式，和诸多专为物联网场景设计的特性；而 HTTP 的诞生比它更早，并且被广泛应用在各类非物联网应用中，用户可能拥有更加丰富的开发和使用经验。
本文将深入探究在物联网情况下，MQTT 和 HTTP 的不同特性、应用场景以及它们在现实应用中的表现。通过对这两种协议的比力分析，我们可以更好地理解如何根据具体需求选择符合的通信协议，以优化物联网体系的性能和可靠性。
MQTT 是什么

MQTT 是一种基于发布/订阅模式的轻量级消息传输协议，针对性地办理了物联网设备网络情况复杂而不可靠、内存和闪存容量小、处理惩罚器本领有限的题目，可以用极少的代码为联网设备提供实时可靠的消息服务。
在典范的 MQTT 使用方式中，全部需要通信的客户端（通常是硬件设备和应用服务）与同一个 MQTT 服务器（MQTT Broker）建立 TCP 长毗连。发送消息的客户端（发布者）与接收消息的客户端（订阅者）不需要建立直接的毗连，而是通过 MQTT 服务器实现消息的路由和分发工作。

实现这一操作的关键在于另一个概念 —— **主题（Topic），**主题是 MQTT 进行消息路由的基础，它类似 URL 路径，使用斜杠 / 进行分层，好比 sensor/1/temperature。订阅者订阅感兴趣的主题，当发布者向这个主题发布消息时，消息将按照主题进行转发。
一个主题可以有多个订阅者，服务器会将该主题下的消息转发给全部订阅者；一个主题也可以有多个发布者，服务将按照消息到达的序次转发。同一个客户端，既能作为发布者，也能作为订阅者，双方根据主题进行通信，因此 MQTT 能够实现一对一、一对多、多对一的双向通信。
HTTP 是什么

HTTP 是一种基于请求/相应模式的应用层协议，尽管它紧张针对传统的客户端-服务器架构而设计，但它在物联网应用中同样扮演着紧张脚色。
   特别阐明的是，本文对比的 HTTP 特指传统的请求/相应模式用例，基于 HTTP 协议扩展实现的 WebSocket 与 Server-Sent Events 协议不参与对比。
  在典范的 HTTP 使用方式中，客户端（通常是浏览器或其他网络应用）向服务器发送请求以获取资源或提交数据，服务器接收到请求后，需要处理惩罚请求并返回相应，例如将提交的数据生存到数据库中，等待另一个客户端来请求获取。

HTTP 协议使用 URL 来标识资源路径，类似于 MQTT 中的主题（Topic）。例如，HTTP 请求中的 URL 可能是 http://example.com/api/sensor，这与 MQTT 中的 sensor/1/temperature 主题有相似的分层结构。
HTTP 每次通信都通过独立的请求和相应流程完成，因此它需要额外的开销，并且两个客户端之间无法直接通信，在实时性上稍有欠缺。
资源消耗对比

MQTT 和 HTTP 都是非常简单的协议，许多物联网硬件设备和嵌入式体系都同时提供了对两者的支持。实时上资源体积与运行内存通常不会限制两者的使用，但 MQTT 设计初衷和使用特性是针对物联网设计，因此长期使用中，它具有更小的资源消耗。
首先，MQTT 在毗连方面具有较低的开销。MQTT 将协议本身占用的额外消耗最小化，消息头部最小只需要占用 2 个字节，毗连建立时的握手过程相对简单，可稳定运行在带宽受限的网络情况下。
一旦建立毗连，客户端和服务器之间可以保持长时间的持久毗连，多个消息可以在同一毗连上传输，从而减少了频仍建立和断开毗连的开销。以向 topic/1 主题发布 HelloWorld 内容为例，其报文信息如下：
字段巨细（字节）形貌固定头部1固定为 0b0011xxxx主题长度20x00 0x08主题9“topic/1”消息内容长度2"HelloWorld"长度消息内容10"HelloWorld"内容合计：24 HTTP 在每个请求-相应周期中都需要建立和断开毗连，会带来额外的服务器资源使用。相对来说，HTTP 协议较为复杂，消息头部较大。同时，由于它是无状态协议，因此每次毗连时客户端都需要携带额外的身份信息，这会进一步增长带宽消耗。
以向 http://localhost:3000/topic URL 传输 HelloWorld 内容为例，在不携带身份凭证的情况下，其报文信息如下：
字段巨细（字节）形貌请求行17POST /topic HTTP/1.1Host20Host: localhost:3000Content-Type24Content-Type: text/plainContent-Length18Content-Length: 10空行2用于分隔请求头和请求体请求体10HelloWorld 内容合计：91 字节 总结：

• MQTT 的毗连开销较低，毗连建立简单，报文头较小，适用于需要频仍通信或保持持久毗连的场景。
  
• 相比之下，HTTP 需要在每次请求-相应周期中建立和关闭毗连，报文头较大，在网络带宽有限的情况下可能会增长传输延迟和负担。
  

在报文尺寸和毗连开销方面，MQTT 通常比 HTTP 更为高效，特别是在需要频仍通信、保持长毗连或网络带宽有限的物联网场景下。
安全性对比

MQTT 和 HTTP 两者都是基于 TCP 的协议，并且在协议设计上都充分思量了安全性。
SSL/TLS 加密
两者都能支持通过 SSL/TLS 进行加密通信：

• 可以保护数据在传输过程中的机密性和完备性；
  
• 可以防止数据被窃听、篡改或伪造。
  

多样化的认证授权机制

• MQTT 提供了用户名/密码认证，可以扩展支持 JWT 认证，也支持客户端和服务器之间的 X.509 证书认证；在授权方面，可以支持基于主题的发布订阅授权检查，取决于MQTT 服务器的实现，。
  
• HTTP 则提供了更灵活的选项，包罗基本认证（Basic Auth）、令牌认证（Token Auth）、OAuth 认证；可以通过应用层的权限控制机制，通过访问令牌（Access Token）、会话管理等来控制资源的访问权限。
  

物联网特性对比

MQTT 协议是专为物联网而设计的通讯协议，内置了丰富的物联网场景特性，能够有效地资助用户实现设备间稳定可靠的通讯、实时数据传输功能，满足灵活的业务场景需求。
断线重连与持久会话
MQTT 支持持久毗连和断线重连，确保设备与服务器之间的稳定通信，即使在网络不稳定的情况下也能保持毗连。客户端可以选择是否创建持久会话，在断线重连时规复之前的会话状态，确保消息不会丢失。
QoS 控制
MQTT 提供三种 QoS 等级：

• QoS 0：最多一次通报，消息可能会丢失。
  
• QoS 1：至少一次通报，消息可能重复。
  
• QoS 2：只有一次通报，消息包管不丢失也不重复。
  

客户端可根据需求选择适当的 QoS 等级，确保消息通报的可靠性。
共享订阅
多个客户端可以订阅相同的主题，接收相同的消息，适用于多个设备间共享数据或订阅相同事件的场景。
保留消息
服务器可以保留指定主题最新的消息，当新的订阅者毗连时立即发送，确保新订阅者获取最新数据。
遗嘱消息
客户端可以设置遗嘱消息，当客户端非常断开毗连时，服务器会发布遗嘱消息，通知其他订阅者客户端已离线。
消息逾期间隔
可以设置消息的逾期时间，确保消息在一定时间内被消耗，克制逾期消息对体系造成不必要的负担。
尽管 HTTP 是 Web 应用中使用最广泛的协议之一，基于成熟的工具链和功能设计经验用户可以实现一些特性，但需要额外的开发工作。在物联网场景下，由于 MQTT 协议原生内置了许多适用于物联网的特性，使用 MQTT 可以降低开发成本，进步通信服从，更适合于物联网应用的需求。
对比总结

总而言之，MQTT 和 HTTP 在通信模型和物联网特性上有明显的区别：

• MQTT 基于发布订阅模型，HTTP 基于请求相应，因此 MQTT 支持双工通信。
  
• MQTT 可实时推送消息，但 HTTP 需要通过轮询获取数据更新。
  
• MQTT 是有状态的，但是 HTTP 是无状态的。
  
• MQTT 可从毗连非常断开中规复，HTTP 无法实现此目标。
  
• MQTT 支持更多开箱即用的物联网功能，HTTP 则没有针对性的设计。
  

这些差异将直接影响它们物联网中的使用场景选择：

• 实时通信： MQTT 在实时性要求较高的场景下更为适用。由于其基于发布/订阅模型，设备可以实时推送消息给服务器或其他设备，而不需要等待请求。例如，实时监测传感器数据、实时控制设备等场景下，MQTT 可以提供更快的相应速率。
  
• 轻量且频仍的通信： 对于带宽和资源有限的情况，MQTT 通常比 HTTP 更加高效。MQTT 不需要频仍建立毗连，且消息头相对较小，通信开销较低；而 HTTP 同步的请求/相应模式则显得服从低下，每次通信都需要完备的请求和相应头，导致带宽和资源的浪费。
  
• 网络波动的场景： MQTT 支持客户端与服务器之间的持久毗连，并且能够从毗连非常中规复，这意味着即使网络断开，设备重新毗连后也能够规复通信。而 HTTP 是无状态的，每次通信都是独立的，无法实现断线规复。
  

另一个想法：MQTT 与 HTTP 集成使用

到现在为止，我们讨论的都是在物联网设备上更应该选择哪个协议的题目。现实上，在一个复杂的物联网应用中，不但有硬件设备，还涉及到其他客户端脚色和业务流程。MQTT 和 HTTP 作为物联网和互联网中最广泛使用的两种协议，在许多场景下可以互相补充使用，进步体系的服从和灵活性。
例如，在一个典范的车联网应用中，用户侧更适合使用 HTTP 协议：用户可以通过 App 中的"打开车门"按钮来控制停在车库中的汽车。这个过程中，App 与服务器之间并不是双向通信，使用 HTTP 也能实现更复杂和灵活的安全与权限检查。而服务器到车辆之间则依赖实时的双向通信：车辆需要确保任何时候都能够相应来自用户的操作。
车辆可以通过 MQTT 协议周期性的上报自身状态，服务器将其生存下来，当用户需要获取时，在 App 上通过 HTTP 协议完成请求即可。
在知名的 MQTT 服务器 EMQX 中，可以轻松、灵活地实现 MQTT 协议和 HTTP 协议的集成，从而实现这一过程。
   EMQX 是一款大规模分布式 MQTT 物联网接入平台，为高可靠、高性能的物联网实时数据移动、处理惩罚和集成提供动力，助力企业快速构建物联网时代的关键应用。
  HTTP → MQTT：
应用体系通过调用 EMQX 提供的 API，将 HTTP 请求转换为 MQTT 消息发送到指定设备，实现应用体系向设备发送控制指令或通知。

1. curl -X POST 'http://localhost:18083/api/v5/publish' \
2.   -H 'Content-Type: application/json' \
3.   -u '<appkey>:<secret>'
4.   -d '{
5.   "payload_encoding": "plain",
6.   "topic": "cmd/{CAR_TYPE}/{VIN}",
7.   "qos": 1,
8.   "payload": "{ "oper": "unlock" }",
9.   "retain": false
10. }'

复制代码

MQTT → HTTP：
当设备发送 MQTT 消息到 EMQX 时，通过 EMQX 提供的 Webhook 可以将消息转发到 HTTP 服务器，实现设备数据的即时传输到应用体系。

设置界面如下：

在将来版本中，EMQX 还将提供提供扩展功能，能够将实时的 MQTT 消息生存到内置的消息队列（Message Queue）和流（Stream）中，并允许用户通过 HTTP 拉取的方式进行消耗，更好地支持复杂的物联网应用场景，提供更强盛的消息处理惩罚本领。
总结

总的来说，选择 MQTT 还是 HTTP 取决于具体的应用需求和场景特点。如果需要实时性好、双向通信、资源占用低的通信方式，可以选择 MQTT；只有简单的请求/相应通信，例如物联网客户端数据采集上报、主动拉取服务器数据，或者迫切希望使用现有的 Web 基础设施，那么可以选择 HTTP。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。