物联网 MQTT协议和本地socket区别

简述

MQTT Broker 是在普通 Socket 之上实现了完整的 MQTT 协议，让你获得了发布/订阅、QoS、遗嘱消息、保留消息等高级特性，而不必自己从零实现这些复杂逻辑

概念层面的区别

维度本地启动一个普通 SocketMQTT Broker（如 Moquette）
底层通信TCP SocketTCP Socket（底层相同）
协议层级自定义应用层协议（或无协议，只传字节流）标准 MQTT 协议（遵循规范）
客户端要求能用 Socket 编程（或 telnet）即可连接必须用 MQTT 客户端库（如 Paho）连接
消息模型点对点：A 发什么，B 收到的就是原始数据发布/订阅：按 Topic 分发，一对多
消息路由你自己写代码实现（如根据首几个字节分发）Broker 内置，自动将消息发送给所有订阅者
服务质量（QoS）无，TCP 保证送达，但无法处理离线、重发等问题0/1/2，支持离线消息暂存和重试
客户端状态管理你需要自己记录每个连接的身份、订阅关系Broker 自动管理会话、持久化、遗嘱消息
保留消息无，后上线的客户端收不到历史消息支持，新订阅者可立即收到最后一条保留消息
心跳/保持连接你自己实现 keepalive 机制标准 MQTT 心跳，Broker 自动检测掉线
开发工作量从零实现所有逻辑（订阅表、重发、离线队列…）直接使用现成组件，只需配置 + 少量客户端代码

基于普通Socket

  • 极简场景

只有两个点通信（A <-> B），不需要一对多分发

  • 自定义二进制协议

你需要极致性能，且消息格式完全不兼容 MQTT

  • 学习实验

想了解 TCP 编程的基本原理

多个客户端、动态订阅、不同服务质量要求、离线消息 等，普通 Socket 会让你陷入无尽的底层实现细节中

基于MQTT中订阅和发布

硬件设备（传感器、执行器、网关、智能家电等）与云端或边缘平台通信时，发布/订阅模式天然适配“多对多、动态、低耦合”的通信需求

硬件视角

  • 解耦：

传感器只管发布数据，不管谁接收；控制端只管发布指令，不管哪个执行器响应

  • 节省功耗：

MQTT 基于 TCP，但设计轻量，且 Broker 可缓存离线消息，设备可休眠

  • 灵活扩展：

添加新设备时，只需让新设备订阅相关主题，无需修改其他设备

  • 天然支持一对多：

一个指令可以同时控制一组设备（如所有客厅灯具）

案例说明

  • 智能家居（控制指令 + 状态反馈）
硬件：智能灯泡、智能插座、窗帘电机、空调红外控制器
模式：既发布（状态上报）也订阅（控制指令）
主题设计：
    控制：cmd/light/livingroom/set（payload: {"state":"ON"}）
    状态反馈：stat/light/livingroom（payload: {"state":"ON","brightness":80}）
工作流：
    手机 App 发布 cmd/light/livingroom/set
    灯泡订阅该主题，收到指令后动作，并发布状态到 stat/light/livingroom
    其他设备（如语音助手、自动化规则引擎）可订阅状态主题，实现联动。
MQTT 特性利用：QoS 1（确保指令送达），遗嘱消息（设备离线时通知）

总结

简单传感器（只上报）：纯发布者，利用 QoS 0/1，保留消息
执行器（灯、开关）：订阅控制主题，发布状态反馈
智能设备（摄像头、网关）：既是订阅者也是发布者，处理复杂的规则联动
移动硬件（手机、车载）：频繁移动，利用自动重连和遗嘱消息

发布/订阅模式让硬件开发者只需关心自己的数据主题，而不用处理设备间直接寻址、在线状态、消息缓存等底层细节，显著降低物联网系统的复杂度

快速理解

发布 = 硬件 → 服务端（上报数据，如温度、电量、GPS）
订阅 = 服务端 → 硬件（下发指令，如开灯、调整阀门、升级固件）
最近更新:
Contributors: kcnf