为什么 HTTP 不适合当做 IoT 物联网设备的消息通信协议？

IoT智能设备发送的网络数据包在经过每一层时都要被对应的协议封装

随着物联网（IoT）技术的快速发展，大多数智能设备的通信模组都支持 TCP、UDP、MQTT、CoAP、HTTP、LwM2M 等网络通信协议，其中既有传输层协议，也有应用层的协议，不同协议适用的场景也不同。

应用层

MQTT：消息队列遥测传输

CoAP：受限应用协议

HTTP：超文本传输协议FTP：文件传输协议SMTP：简单邮件传送协议

传输层

网络层

网络层

链路层

我们在设计IoT硬件产品时，通常只需选择一种协议即可。那么，如何选择合适的通信协议对于构建高效、可靠的业务应用系统就显得尤为重要。

HTTP 协议

HTTP 协议是一种基于请求/响应模式的应用层协议，主要用于Web浏览器与服务器之间的数据交换。它具有以下特点：

无状态性：每个请求都是独立的，不保留会话信息。

丰富的工具支持：拥有大量开发库和调试工具，易于集成到现有Web架构中。

易于理解和使用：采用文本格式的消息，便于人类阅读和调试。

然而，在 IoT 物联网应用场景中?HTTP协议展现出了以下的局限性：

开销较大：每次通信都需要建立完整的TCP连接，发送较大的头部包，导致较高的网络带宽消耗。

实时性不足：HTTP是无状态的，无法主动推送消息给设备端，常用的轮询机制无法满足物联网的实时性。

对低功耗设备不友好：频繁的连接和断开操作无疑会增加能耗，这在电池供电的小型设备上尤为明显。

MQTT协议是一种轻量级的消息传输协议，专为低带宽、高延迟或不可靠网络环境设计，采用客户端/服务端架构的发布/订阅模式的消息传输协议。

它的设计思想是轻巧、开放、简单、规范，易于实现。这些特点使得它对很多场景来说都是很好的选择，特别是对于受限的环境如机器与机器的通信（M2M）以及物联网环境（IoT）。

MQTT协议特点

MQTT 协议的数据包格式非常简单，由固定报头（Fixed header）、可变报头（Variable header）、有效载荷（Payload）三个部分组成。它具有以下特点：

发布/订阅模型：允许设备通过一个中心节点——MQTT Broker进行消息交换，这种架构非常适合分布式系统中的实时数据流。

服务质量(QoS)：提供了三种等级的服务质量，从至多一次到恰好一次不等，保证消息的不同级别可靠性。

轻量级：MQTT的消息头部最小只需2个字节，适合带宽有限的网络环境。

心跳机制：业务应用不需要关心长连接保活心跳。

节省带宽：MQTT协议Payload采用二进制协议可以更节约流量。流量比HTTP协议要低

穿越防火墙：MQTT协议可以通过MQTT over websocket来穿越网络防火墙。

持久会话：支持断线重连，确保即使在网络不稳定的情况下也能保持消息的连续性。

遗嘱消息和保留消息：允许设置当客户端异常断开时发布的遗嘱消息，以及保存最新消息供新订阅者获取。

安全性：MQTT协议支持TLS安全，保证数据传输过程的安全性。

一对多的消息分发：MQTT协议支持一次发布，多个客户端订阅，这对于M2M场景很省电、省流量。

虽然MQTT协议因其轻量级特性和针对物联网优化的功能而被普遍推荐，但这并不意味着HTTP协议完全不适合用于物联网。

智能家居App：在这种场景下，用户通常不需要极高的实时性，且App界面友好性更为重要。HTTP协议可以很好地满足这类需求，尤其是与现有的Web基础设施相结合时。

远程监控：如果数据采集频率不高且对延迟要求较低，则HTTP仍然是一个可行的选择。但在需要频繁更新或实时反馈的场合，MQTT的优势更加明显。

总之，HTTP协议并不是完全不适合物联网应用。它在那些不要求极高实时性并且已有成熟的Web基础设施支持的情况下，仍然能够发挥重要作用。

在大多数典型的物联网项目中，考虑到性能、能耗及灵活性等方面的综合优势，MQTT协议往往是硬件设备更好的选择。

免责声明：本公众号所发布的内容来源于互联网，我们会尊重并维护原作者的权益。由于信息来源众多，若文章内容出现版权问题，或文中使用的图片、资料、下载链接等，如涉及侵权，请告知我们，我们将尽快处理。