做物联网方案的人几乎都会被同一个问题堵在方案评审会上“MQTT、TCP、HTTP 到底用哪个”百度一搜全是背书式的对比表参数列了一堆看完还是不知道怎么选。这个问题的难处在于三个协议压根不在同一条赛道上——HTTP 是请求响应式的TCP 是面向连接的裸管道MQTT 是发布订阅式的消息协议。硬要分高低不如问自己一个问题你的设备是在上报数据、接收指令还是两者都要把这句话想明白了选型其实就完成了一半。这篇文章不打算给你画那种三列对比的大表之后拍脑袋给结论。我会从“设备角色—网络环境—数据流”这三个维度拆解选型逻辑把三个协议的设计初衷、适用场景、参数取舍和混合组网方式讲透。内容适合正在做设备接入、劳动平台选型的嵌入式工程师、后端开发、产品经理也适合刚接触物联网、被各种协议名词绕晕的入门者。1. 选型前必须先想明白的三件事协议选型不是技术审美问题是需求翻译问题。同样一套硬件做智能插座和做工业数采网关选的协议完全不一样。动手之前先把下面三件事在文档里写清楚。1.1 你的设备到底是哪种角色设备在系统里扮演的角色决定了它“该说什么话”。物联网里的设备无非三种角色纯上报型传感器、电表、定位终端数据从设备单向流向平台偶尔接收配置更新。纯控制型继电器、灯光开关、阀门核心动作是接收平台或 App 下发的指令反向确认执行结果。双向互动型空调、路由器、智能门锁既频繁上报状态也要实时响应控制指令还可能涉及 OTA 升级这类大流量任务。纯上报型的项目HTTP 和 MQTT 都能做区别只在于设备数量和数据频率。纯控制型的项目TCP 或 MQTT 更合适因为 HTTP 的服务端主动下发能力天然受限。双向互动型基本就是 MQTT 的天下或者用 TCP 长连接自己包一层指令协议但后者开发成本更高。1.2 网络环境与资源约束有多苛刻这一条最容易被开发环境“欺骗”。很多工程师在办公室用千兆网线调试觉得什么协议都很快等设备部署到现场才傻眼。你要评估的是四个维度的约束带宽NBIoT 模组的带宽在几十 Kbps 级别4G Cat.1 大概 5MbpsWiFi 则按实际信号浮动。MQTT 头部压缩得很好一条 50 字节的 JSON 数据加上协议开销大概也就 100 字节上下。HTTP 的 Header 动不动几百字节相同数据量下传输效率差距在数倍以上。功耗带电池的设备通信模块是耗电大户。HTTP 每次请求都要经历建连、传输、断连连接开销和耗电都要计入。MQTT 的长连接虽然省了建连开销但如果 QoS 设置不当重传和应答也会显著拉高功耗。TCP 裸连接则要自己管理心跳逻辑心跳间隔设得太短电池一天就没了。网络抖动工业现场、地下管廊、车载环境网络波动是常态。MQTT 和 TCP 都带连接保活机制断线可以自动重连HTTP 通常是一次性请求请求失败重试就行反而对网络抖动不太敏感。设备数量级网关后面挂几百个传感器和平台直连几万个插座是完全不同的资源模型。普通 HTTP 服务扛几万个短连接没问题但几万台设备每 30 秒轮询一次后端压力就上来了这时候 MQTT 的 Broker 架构优势非常明显。1.3 数据流动方向与实时性要求画一张数据流图把“谁产生数据、谁消费数据、延迟容忍度是多少”标出来。这里有个常见的误判很多人觉得“我设备要实时响应必须用 TCP”其实多数场景下的“实时”并没有那么苛刻。如果数据流是“设备 → 平台”延迟要求是秒级HTTP 轮询完全够用。如果数据流是“设备 ↔ 平台”双向且下行指令需要在 1 秒内到达设备MQTT 或 TCP 长连接是合理选择。如果数据流是“设备间直接通信”比如车间里两台机器要联动MQTT 的发布订阅模式和 TCP 的点对点模式都能做但 MQTT 天然支持多点广播TCP 要自己建立完整的节点管理逻辑。一句话先梳理数据流再谈协议。上来先问“哪个协议好”的大概率还没把需求搞清楚。2. 三个协议的核心机制与适用边界好菜需要好食材。把三个协议的底层机制弄清你就能理解为什么有些场景用某个协议是“灾难”换一个就“真香”。2.1 HTTP请求响应模型下的物联网适配器HTTP 是互联网世界用得最多的协议最直白的特点是“一问一答”。设备上传数据到平台平台返回确认App 向平台请求数据平台返回结果。这种模式在浏览器场景下极其成熟但在物联网场景有两处硬伤第一服务端不好主动找设备。HTTP 是客户端发起请求、服务端送回响应。设备作为 HTTP 客户端接入后平台如果想主动控制设备就只能等设备下一次请求时把指令捎带回去或者引入 WebSocket 这类升级方案但那样就脱离了传统 HTTP 的范围。第二协议开销偏重。每一轮 HTTP 请求都可能携带 Method、URL、Header、Cookie 等信息即使你用 HTTP/2 的压缩头单次请求的协议开销也远高于 MQTT。对于每天只上报几次的温湿度传感器来说这不是问题但如果是高频回传的定位终端、每秒上报一次状态的工业设备流量和电量消耗就是实打实的成本。但 HTTP 在物联网里并非一无是处。恰恰相反设备管理、OTA、数据查询这类“低频、大包、弱实时”的场景HTTP 是最稳妥的方案。很多平台级设备接入规范里设备上线后的认证、固件下载、日志上报都走 HTTPS原因是生态成熟、工具链丰富、排查问题容易。2.2 TCP稳定可靠的私有协议基座TCP 是传输层协议HTTP 和 MQTT 都建立在它之上。物联网里直接讨论“用 TCP”时通常意思是“用 TCP 长连接 自定义应用层协议”。这种模式把数据包结构、心跳、编解码规则全部交给开发者自己定义灵活性最高也最难做好。TCP 长连接适合三种场景实时性要求严格的工业控制。比如运动控制器、机械臂的指令下发毫秒级延迟要求让 MQTT 的 Broker 转发链路都嫌多余。设备与平台之间需要保持稳定的双向数据通道。TCP 建立连接后两端可以随时互发数据不需要像 HTTP 那样每次重新握手。需要传输大量二进制数据的场景。自定义 TCP 协议可以用字节流方式传文件切片、音视频流省去 JSON 序列化和 XML 解析的开销。TCP 的“坑”也很明显你没有现成的语义规范需要自己设计消息边界。TCP 是流式传输多次 send 可能粘包一次 send 可能拆包这是所有自定义 TCP 协议必踩的坎。此外断线检测、心跳机制、重连策略都得自己造轮子写不好就容易出“假连接”问题——socket 还开着但设备已经失联。2.3 MQTT面向海量设备的轻量消息总线MQTT 的诞生背景是低带宽、高延迟、网络不稳定的卫星链路堪称“土路上跑运输”的设计典范。它的核心模型是发布订阅Pub/Sub多了一层消息代理Broker的角色。设备发布消息到某个主题Topic其他设备或后端服务订阅该主题就能收到消息。发布方和订阅方互不感知彻底解耦了设备与平台之间的依赖。举个例子一个停车场里有 500 个地磁传感器它们不需要知道平台管理服务的地址只管往“parking/status”这个主题发布数据平台端订阅这个主题就能统一接收。MQTT 三个特性在物联网场景里极其好用QoS 分级QoS0 最多发一次消息可能丢QoS1 保证送达但可能重复QoS2 保证只送达一次。选型者可以根据数据重要程度决定开销温湿度用 QoS0门锁控制用 QoS1 或 QoS2。遗嘱消息设备异常断线时Broker 会自动发布一条预设的遗嘱消息平台立刻就能感知设备掉线避免了 TCP 堆里长时间无法发现断线的问题。主题通配符和共享订阅后端服务可以订阅 “sensor//temperature” 这种带通配符的主题一次接入拿到所有传感器温度数据多台后端服务还可以组成共享订阅实现负载均衡。MQTT 的主要代价是引入了一个 Broker 中间件。运维上要多管一个服务调试时也要多一层转发链路。但在设备规模超过三位数、需要平台统一控制、消息来源类型复杂的情况下Broker 带来的解耦收益远大于运维成本。2.4 三者的定位对比用一个生活化的类比来区分HTTP 像打电话每次拨号通话说一句挂一句每次都有完整通话记录TCP 像拉了一条专线两端随时互发对讲但线怎么部署、断线怎么修复全靠自己打理MQTT 像邮局系统你只管写好地址投递邮局负责分发和转发不用关心对方在哪里。维度HTTPTCPMQTT模型请求/响应全双工流发布/订阅服务端推送能力弱需设备轮询强连接内任意互发强主题订阅即推送协议开销高低自定义封装低头部紧凑实时性秒级依赖轮询毫秒级百毫秒级经 Broker 转发可靠性机制依赖应用层重试需要自建心跳、重传QoS 0/1/2 内置典型应用设备认证、OTA、状态查询工业控制、二进制传输传感器数据采集、指令下发、车联网特别强调一点很多人觉得 HTTP 就不适合物联网这是误解。在设备量少、上报频率低、数据不敏感、平台无需实时下发的场景HTTP 反而是最省事的没有之一。3. 四步走把需求翻译成协议选型前两节讲了原理这一节给方法论。我在这几年接触的物联网方案里总结了一个四步决策流程照着走基本不会选错。3.1 第一步确定设备数量和上报频率设备规模直接决定架构选型。先统计一个大致的量级1 到 20 台设备怎么选都行选你团队最熟的。先跑通业务最重要后续可以重构。20 到 500 台设备HTTP 短连接或 TCP 长连接都能扛住但要提前考虑扩展性。这个阶段如果预测未来会快速增长直接上 MQTT 更稳妥。500 台以上强烈建议 MQTT。设备越多连接管理的复杂度越凸显Broker 帮你把“每个设备一条连接”的维护细节收走了。设备上报频率同样关键一万台设备每 5 秒上报一次每秒就有 2000 个请求用 HTTP 会让后端疲于建连而 MQTT 的 Broker 天然就是为高并发消息设计的。上报频率的计算也很简单QPS每秒请求数等于设备数量乘以上报频率。如果这个数字超过 1000HTTP 后端就要开始考虑连接复用、缓存、限流等手段了MQTT 的 Broker 在同类配置下处理能力高很多。3.2 第二步明确交互模式和控制需求只做单向采集不管是要控制设备还是双向互动选型方向完全不同。单向采集 平台侧数据展示HTTP 上报就够了平台存数据库前端拉数据展示技术栈最简单。单向采集 少量参数配置设备主动拉取HTTP 也能做平台存好配置设备每次上报后回读一下配置即可。双向控制 状态实时刷新低延迟MQTT 是最稳的选择指令走主题下发设备状态通过主题上报平台订阅状态主题即可实时更新。双向控制 断网场景也要可靠执行需要考虑本地策略 消息补发协议层面两者都能做但 MQTT 的 QoS1 和遗嘱机制省了很多自研功夫。这里要强调一个很容易犯的错误把“控制指令”强行设计成 HTTP 轮询。设备每 5 秒轮询一次平台把待执行指令放进队列设备轮询时取走。表面上功能实现了但实际上指令到达设备的最长时间是 5 秒如果要求 1 秒内响应轮询周期就得压到 1 秒以内每台设备每天多出几万次 HTTP 请求纯属浪费。控制类场景请直接考虑长连接。3.3 第三步评估网络环境和资源开销网络和资源约束直接决定协议的极限参数。带宽受限优先 MQTT。它的 PUBLISH 报文头在主题较短时可以控制在几个字节还能用主题别名进一步压缩。HTTP 则每次请求都带上一堆 Header在 NBIoT 网络下一次上报的在线时长都比实际传输时间长。弱网高丢包MQTT 的 QoS1 重传机制能显著降低数据丢失率但要注意重传会造成消息重复后端需要做去重。TCP 裸协议则必须自己实现确认号和超时重传。低功耗需要综合计算“连接维持成本”。HTTP 短连接在设备休眠时最省电不连网但唤醒上报时的建连开销大。MQTT 长连接需要定期发心跳保活心跳太久会被 Broker 断开太短则耗电。NBIoT 场景常见做法是把心跳和上报合并在同一报文里降低唤醒次数。资源开销这一块最容易踩的是 Flash 和 RAM。MQTT 客户端库比 HTTP 库大不少尤其在 MCU 上一个完整支持的 MQTT 客户端可能需要十几 KB 的 RAM。如果你的主控只有几十 KB 可用内存HTTP 反而更现实或者选择协议栈更轻的实现。3.4 第四步考虑团队技术栈和后期运维技术选型最终还是团队来维护。团队擅长 Web 开发后端全是 Spring Boot/Node.js引入 MQTT 需要额外学习 Broker 运维和消息语义。团队有嵌入式网络开发经验自定义 TCP 协议也未必是难事但要考虑后续新成员接手时的学习成本。MQTT 的运维重点是 Broker 的可用性和消息堆积。Broker 挂掉等于全盘瘫痪所以生产环境至少要搞主从或集群加上持久化策略。HTTP 集群的负载均衡、限流、监控体系已经很成熟公有云上开一个负载均衡器就能扛住压力。TCP 长连接则需要运维层面管理海量连接的活跃状态、内存占用和异常断开回收。另外还要考虑一个问题你所在行业的设备商是否已经默认了某种协议标准。跑去对接一个第三方平台如果对方平台只提供 MQTT 接入那技术栈再熟也得遵从对方规范。4. 混合架构实战协议不是单选题回到项目实战里一个复杂系统很少只用一个协议。最常见的方案是“HTTP 管管理面MQTT 管数据面TCP 管实时控制面”三者各司其职。4.1 为什么需要混合架构用一套协议打天下通常会在某个环节显得别扭。举个例子一个智能农业大棚项目大棚里有温湿度、土壤、光照传感器还有卷帘电机、水泵、通风设备。数据采集要做到秒级上报和实时预警控制指令要即时下发。同时平台需要对设备做批量固件升级、离线诊断和日志查询。如果只用 MQTT固件升级的二进制文件走主题分发Broker 要处理大数据包消息体里塞二进制内容极不优雅升级传输过程中还会占用主题通信的带宽。如果只用 TCP全部设备做长连接光连接管理就够运维喝一壶。如果只用 HTTP实时控制和大规模采集又无从谈起。实际方案是三者混合设备接入与实时控制走 MQTT设备侧订阅控制主题上报状态主题。固件升级、设备认证、日志上传走 HTTPS文件传输可靠断点续传有现成方案。网关与特定执行器之间的硬实时联动走 TCP 自定义协议降低转发延迟。这种混搭是物联网大厂司空见惯的架构。协议之间不是竞争关系而是各管一块。4.2 一个典型混合架构的数据流拆解以一套假想的“智慧园区能耗管理平台”为例梳理数据流能耗采集器电表、水表、气表通过 MQTT 上报能耗数据主题为energy/{building}/{meterId}/data消息体是 JSON 格式的{value: 12.5, ts: 1712345678}QoS1 保证不丢。控制指令远程断电、阈值设置平台发布到energy/{building}/{meterId}/command设备订阅该主题。指令下发用 QoS1收到后回发确认消息。开局配置设备首次注册、获取网关地址设备通过 HTTPS 调用注册接口服务端返回设备 ID 和 MQTT 接入凭证。OTA 升级平台生成升级任务通过 HTTP 预签名 URL 让设备下载固件包下载完成后设备通过 MQTT 上报升级结果。实时监控大屏前端通过 WebSocket 或 SSE 订阅平台内部的实时消息队列而不是直接连 MQTT避免前端直接暴露到物联网网络。这么做的好处是数据面和控制面隧道分离MQTT 只处理轻量高频消息不会因为 OTA 大流量导致控制指令延迟OTA 使用 HTTPS 可以利用 CDN 分发减轻平台带宽压力。整条链路里每个协议都待在它最擅长的位置。4.3 通信端点设计建议做混合架构时第一件事就是划分“接入域”和“应用域”。接入域是设备与平台之间的通信尽量保持统一入口建议所有设备都接入同一个 MQTT Broker 或者同一个接入网关应用域是平台内部和前端展示的通信选择 WebSocket、REST API、消息队列都行。两个域之间用后端服务做桥接不要让业务逻辑直接暴露给设备。这种分层的好处是当设备量增长你可以只扩容接入层当前端交互逻辑变化后端接口调整不会触达设备。设备侧代码则尽量简单稳定不随着 Web 端升级而变。5. 参数配置与调试要点实录选好协议后具体参数怎么设很多人栽在这里。我碰过的项目里因为心跳时间设置不当、QoS 选择错误、重连策略不合理导致的线上事故远比协议本身选错的要多。5.1 MQTT 的 KeepAlive 和心跳调参MQTT 的 KeepAlive保活间隔决定了设备多久发一次心跳包来证明自己还活着。服务端如果在 1.5 倍 KeepAlive 时间内没收到任何包就判定设备失联触发遗嘱消息。调参逻辑是KeepAlive 设得太大设备断线时服务端感知时间长设得太小设备频繁发心跳浪费流量和功耗。我见过一个最典型的低级错误设备接入的是 WiFi 网络网络本身很稳定但把 KeepAlive 设成了 5 秒电量以肉眼可见的速度掉。实际上 WiFi 环境下 30 到 60 秒的心跳完全足够没必要搞激进保活。在 NBIoT 等弱网环境KeepAlive 通常设到 120 秒以上减少频繁唤醒。一个实用技巧是把业务数据上报和心跳合并。如果设备本来就每 30 秒上报一次数据就不需要额外发心跳包因为最近一次上报的数据包就已经充当了保活消息。Broker 侧的判定是“最近一次收到客户端任何报文的时间”不限于心跳包。5.2 QoS 应该如何选很多初接触 MQTT 的人会把所有消息都设成 QoS2觉得“最可靠”结果把 Broker 和设备的资源几乎耗尽。QoS2 的报文交互次数是四次PUBLISH、PUBREC、PUBREL、PUBCOMP是 QoS1 的两倍设备越弱越容易在这个流程里出问题。我的建议是分层设 QoS传感器状态上报温度、湿度、电量QoS0。数据是周期性的偶尔丢一次下一轮就补上了完全没必要额外开销。控制指令开关灯、锁门、调温QoS1。必须保证到达消息重复也无所谓设备端做幂等处理。门禁授权、在线支付类型的指令业务敏感QoS2。很少见但一旦出现就要考虑设计到端到端的幂等。要把 QoS 和业务性质绑定起来不要“一刀切全都 QoS2”更不要“图省事全都 QoS0”。前者浪费资源后者控制指令可能丢失。5.3 TCP 心跳与超时设置自定义 TCP 协议的心跳设计比 MQTT 复杂得多因为没有统一规范。核心要处理两个价值的问题应用层心跳TCP 本身的 KeepAlive 默认 2 小时才探测一次不调整根本不够用。应用层心跳包应由设备周期发送例如每 30 秒发一个心跳服务端 90 秒没收到就断开连接。这里有个经验值公式服务端超时时间应至少设置为心跳周期的 3 倍避免网络抖动导致误杀。假设心跳 30 秒服务端 90 秒内没收到任何数据有心跳发心跳有业务数据发数据就判定连接失效。半开连接Half-open Connection这是 TCP 项目最常见的故障。设备断电或断网时可能来不及发 FIN 包服务端以为连接还在。解决方式是服务端在写数据时发现 socket 错误即关闭连接同时定期做探测主动发一个心跳请求设备不回就断开。5.4 HTTP 轮询周期的计算如果选了 HTTP 轮询轮询间隔就等于系统实时性的上限。比如一个车位锁项目车位状态变化需要 5 秒内反映到 App那么轮询间隔不能超过 2 秒留出网络延迟余量。这个情况下1000 台设备每 2 秒请求一次后端 QPS 就是 500除以机器承载能力得出需要几台后端实例。带宽的计算也要考虑。一个 HTTP 请求包含 Header、Cookie、JSON 数据按 1KB 计算1000 台设备每 2 秒一次每秒传输 500KB看起来不大但如果运行在 3G/NBIoT 网络这个频率就不合理了。轮询间隔是“实时性”和“流量”的杠杆多一个数量级的设备、少一个数量级的间隔效果天差地别。6. 常见问题排查与避坑实录最后这部分整理一些我在实际项目中踩过、帮别人排查过的坑。每一类问题都有典型的现场特征和检修思路建议收藏起来遇到同类问题时作参照。6.1 设备大批掉线Broker 端大量连接堆积现象后台显示设备心跳超时设备大量离线但设备端 log 显示“已连接”。重启 Broker 后恢复正常但几小时后问题复现。根因排查思路先看服务端连接数和设备端重连日志是否对得上。如果设备端没有掉线记录但 Broker 断开了它多半是心跳调整问题如果设备端反复重连成功又断开注意看一下是否触发了重连风暴——一波设备同时掉线、同时重连对 Broker 和网络产生过载导致更多设备超时。解决方案设备端增加随机延时重连机制重连间隔使用“基础间隔 随机抖动”比如 5 到 15 秒随机避免所有设备在同一时刻撞车。Broker 侧要限制单 IP 最大连接数防某个网关线异常把连接资源挤占。6.2 MQTT 消息重复消费导致数据错乱现象仪表读数偶尔出现“往前跳”比如电表用了 100 度平台却收到一条用了 70 度的旧消息。根因排查思路QoS1 消息语义是“至少一次”Broker 在未收到 PUBACK 时会重发客户端在网络抖动后可能收到重复消息。另外设备端重连后会从 Broker 的持久会话里拿到离线期间的“错位消息”如果设备侧没有带时间戳过滤旧的补发消息就可能覆盖新数据。解决方案在业务消息体里带上自增序号或时间戳消费端做“序号/时间戳单调递增”校验拒绝旧消息。控制指令则要做幂等比如“关闭 1 号灯”执行两次结果一致不会导致状态翻转。6.3 TCP 粘包拆包导致的指令解析错误现象设备收到的指令偶尔乱码、解析失败或者一次收到两条指令拆成半截。根因排查思路TCP 是字节流没有消息边界。你发 “COMMAND_A” 和 “COMMAND_B” 两个包对端可能一次收到 “COMMAND_ACOMMAND_B”也可能分三次收到。解析层如果没有进行正确的边界切分业务逻辑必然出错。解决方案设计自定义协议时加入长度字段。经典的格式是“帧头2字节 长度2字节 消息体 校验2字节”接收端先读满长度字段再按长度读消息体读完校验这样就能正确切分每个消息。不要用“特殊字符结尾”来切分二进制数据里可能出现任意字符。6.4 HTTP 轮询方案里突然多出 10 倍垃圾请求现象某天后端服务 CPU 暴涨监控发现每秒请求数从 100 跳到 1000排查发现全是设备发来的上报请求。根因排查思路多半是设备端代码里有“未处理的上报失败重试”。比如上报接口偶发超时设备端收到超时就立即重试造成了雪崩也可能设备端时间同步出错导致上报任务被重复调度。解决方案设备端重试必须用指数退避退避间隔按 1 秒、2 秒、4 秒递增并且限制最大重试次数。后端接口要按设备维度做限流单设备每分钟超过 N 次请求直接拒绝保护后端不被异常设备拖垮。同时给设备端加日志保证问题复现时能定位到是哪个设备的哪种异常触发。6.5 设备“假在线”TCP 连接还在但设备早已死机现象服务端显示设备在线但发送指令没有响应断开连接后设备也没有重新连上来。根因排查思路这属于典型的半开连接。设备死机或断网后TCP 连接没有正常释放服务端如果一直不写数据就永远发现不了连接已死。空闲连接长期占用 socket 资源最终拖垮服务。解决方案服务端做空闲巡检定期向连接发送探活请求同时缩短读取超时时间超过 N 秒无任何数据就主动 close。设备端也要做断线自检比如周期性检查 WiFi 是否断开断开了主动关闭 socket 重新拨号避免在无效链路上空等。6.6 协议选型后后悔了怎么平滑迁移如果项目已经启动甚至上线协议想换最好采用“双协议混合过渡”的策略保留原有协议接入同时新增第二种协议接入端点让一部分设备逐步迁移到新协议用灰度方式切流量。比如原系统是 HTTP 轮询想改成 MQTT。可以先让后端同时保留 HTTP 接口和 MQTT 订阅逻辑新设备走 MQTT老设备继续跑 HTTP等老设备固件升级完再下线 HTTP 接口。这个过程中注意 MQTT 和 HTTP 两套数据的格式保持一致避免下游业务针对两种协议写两套解析逻辑。我个人在实际项目中得到的体会是协议选型最怕的不是选错而是选完后不给自己留退路。任何协议都有适用范围把它们当工具而不是信仰架构上保证接入层可替换比反复争论“哪个协议最好”有用得多。如果看完还有拿不准的场景从设备角色和数据流入手画张图答案基本就浮出水面了。
