MQTT vs HTTP：谁更适合物联网？
Guowei Li
前言
随着物联网（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 |
| 主题长度 | 2 | 0x00 0x08 |
| 主题 | 9 | "topic/1" |
| 消息内容长度 | 2 | "HelloWorld"长度 |
| 消息内容 | 10 | "HelloWorld"内容 |
| 合计：24 |
HTTP 在每个请求-响应周期中都需要建立和断开连接，会带来额外的服务器资源使用。相对来说，HTTP 协议较为复杂，消息头部较大。同时，由于它是无状态协议，因此每次连接时客户端都需要携带额外的身份信息，这会进一步增加带宽消耗。
以向 http://localhost:3000/topic URL 传输 HelloWorld 内容为例，在不携带身份凭证的情况下，其报文信息如下：
| 字段 | 大小（字节） | 描述 |
|---|---|---|
| 请求行 | 17 | POST /topic HTTP/1.1 |
| Host | 20 | Host: localhost:3000 |
| Content-Type | 24 | Content-Type: text/plain |
| Content-Length | 18 | Content-Length: 10 |
| 空行 | 2 | 用于分隔请求头和请求体 |
| 请求体 | 10 | HelloWorld 内容 |
| 合计：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 消息发送到指定设备，实现应用系统向设备发送控制指令或通知。
curl -X POST 'http://localhost:18083/api/v5/publish' \
-H 'Content-Type: application/json' \
-u '<appkey>:<secret>'
-d '{
"payload_encoding": "plain",
"topic": "cmd/{CAR_TYPE}/{VIN}",
"qos": 1,
"payload": "{ \"oper\": \"unlock\" }",
"retain": false
}'
MQTT → HTTP：
当设备发送 MQTT 消息到 EMQX 时，通过 EMQX 提供的 Webhook 可以将消息转发到 HTTP 服务器，实现设备数据的即时传输到应用系统。
配置界面如下：
在未来版本中，EMQX 还将提供提供扩展功能，能够将实时的 MQTT 消息保存到内置的消息队列（Message Queue）和流（Stream）中，并允许用户通过 HTTP 拉取的方式进行消费，更好地支持复杂的物联网应用场景，提供更强大的消息处理能力。
总结
总的来说，选择 MQTT 还是 HTTP 取决于具体的应用需求和场景特点。如果需要实时性好、双向通信、资源占用低的通信方式，可以选择 MQTT；只有简单的请求/响应通信，例如物联网客户端数据采集上报、主动拉取服务器数据，或者迫切希望使用现有的 Web 基础设施，那么可以选择 HTTP。