http、websocket与MQTT协议

发布于：2025-02-27 ⋅ 阅读:(12) ⋅ 点赞:(0)

网络通讯协议

1、http、websocket与MQTT协议

核心区别

特点	http	websocket	MQTT协议
协议模型	请求-响应（单项）	全双工双向通讯	发布/订阅（多对多）
连接状态	无状态（断连接或长连接需要要手东维护）	持久长连接，需要手动断开	基于Broker的之久连接
头部开销	高（每次请求携带完整头部信息）	低（握手后仅需2-14字节控制数据帧）	极低（最小2字节）
实时性	低（依赖轮询或长连接模拟）	高（毫秒及延迟）	极高（依赖Qos级别）
设备资源需求	高（需要处理复杂协议栈）	中等（需要维护长连接）	极低（专为资源受限设备涉及）
典型应用	网页加载、REST API	实时聊天、在线游戏、web通讯	物联网设备通讯、工业监控

2、优缺点

1、http
- 优点：
  - 兼容性极强：所有浏览器和服务器原生支持
  - 无状态特想：天然支持水平宽展和负载均衡
- 缺点：
  - 高延迟：频繁建立连接导致资源浪费
  - 头部冗余：每次请求需要携带完整的Cookie和Headers，带宽效率低
- 场景：静态资源加载（HTML/JS/CSS）、表单提交、低频API交互
2、websocket
- 优点：
  - 双向实时通讯：服务器和客户端都可以主动推送数据，无需客户端轮询
  - 低协议开销：相比HTTP长轮询，能寄生90%的贷款
- 缺点：
  - 连接维护成本高：需要处理心跳检测、冲连机制
  - 防火墙限制：部分企业网络可能拦截非标准端口，需要WSS加密
- 场景：实时聊条、股票行情推送、多人在线游戏
3、MQTT：
- 优点：
  - 超低资源消耗：最小消息头仅需2字节
  - 高可靠性：支持Qos分级（0-最多一次；1-至少一次；2-恰好一次）
  - 大规模扩展：通过Broker集权支持百万级设备连接
- 缺点：
  - 协议复杂度高：需要部署Broker服务器，开发成本高
  - 实时性受限：Qos2时严格限制一次交付会引入额外延时
- 场景：智能家居传感器、车连网数据同步、工业物联网监控

3、典型应用场景

1、HTTP

网页加载：浏览器请求HTML/CSS/JS等静态资源
RESTful API：移动端与后端服务的数据交换（用户登陆、订单查询）
文件传输：下载图片、文档等未实时数据

2、WebSocket

实时通讯：在线客服系统、视频会议中的音视频传输
交互式应用：协同编辑工具（如腾讯文档）、实时表盘更新
高频数据推送：体育赛事比分直播、在线教育白板互动

3、MQTT

物联网设备：智能家居中温湿度传感器数据上传
工业监控：工厂PLC设备状态采集与远程控制
车辆汪：车辆GPS位置同步、故障争端数据上传

4、混合使用建议

现代系统常结合多种协议以平衡性能与成本：

HTTP + WebSocket
- 用 HTTP 加载初始页面，WebSocket 处理实时聊天
MQTT + WebSocket
- 物联网设备通过 MQTT 上报数据，WebSocket 向用户端推送告警
HTTP API 网关 + MQTT Broker
- 设备管理接口使用 HTTP，设备通信使用 MQTT 以降低带宽

5、数据交换格式

XML

优点
- 可扩展性强，支持自定义标签和树形结构
- 适合复杂数据表示（如设备配置、跨平台数据交换）
- 通过解析器（如xmltodict）可轻松提取数据
缺点
- 冗余标签导致数据体积大，传输效率低；
- 语法严格，容错性差。
场景：工业协议（如NETCONF）、跨系统数据交换

JSON（JavaScript对象表示法）

优点
- 轻量级，结构简洁（键值对、数组），兼容JavaScript
- 解析速度快，适合REST API和Web应用
- 支持Python等语言的序列化与反序列化
缺点
- 不支持注释，数据类型有限（如无日期类型）
- 严格的语法要求（如双引号、true/false）。
场景：前后端交互、物联网设备状态同步。

YAML（YAML Ain’t Markup Language）

优点
- 可读性极强，通过缩进表示层级
- 支持复杂数据类型（对象、数组、纯量）
- 适合配置文件和文档存储。
缺点
- 严格的缩进要求易导致格式错误；
- 传输效率低，不适合高频通信。
场景：Kubernetes配置、自动化脚本参数定义。

总结

选择 HTTP：需兼容性优先、无实时性要求的场景。
选择 WebSocket：需双向实时通信且客户端为浏览器/移动端。
选择 MQTT：资源受限设备、大规模物联网部署或需高可靠消息传递的场景