3. 升级协议选择：HTTP/HTTPS、MQTT、CoAP、FTP在固件传输中的优劣对比

协议选型这事儿，我做了这么多年网关固件，每次新项目启动都会被拉去开会讨论。说白了，没有万能的协议，只有适不适合你的场景。你想想看，一个跑在2G猫上的水表网关，跟一个跑在千兆以太网上的工业边缘网关，能用同一套协议吗？显然不能。

今天我就把这四种最常见的固件传输协议——HTTP/HTTPS、MQTT、CoAP、FTP，掰开了揉碎了给你讲清楚。我会结合我踩过的坑，告诉你什么场景该选什么。

3.1 HTTP/HTTPS：最通用的选择，但别滥用

HTTP/HTTPS 是我个人用得最多的协议。为什么？因为它简单、成熟、几乎所有设备都有现成的库。你写个 HTTP 客户端，从服务器 GET 一个固件包，写到 flash 里，完事。

优点很明显：

• 穿透性好：防火墙基本都放行 80/443 端口，不需要额外配置。
• 支持断点续传：用 Range 头就能实现，我之前的项目就是靠这个救了命——设备升级到一半断电，重启后接着下，不用重头来。
• 生态成熟：CDN 加速、负载均衡、鉴权，现成的方案一大堆。

但坑也不少：

• 协议头开销大：一个 HTTP GET 请求，光头部就几百字节。对于 NB-IoT 这种按流量计费的场景，你传个 1MB 固件，光握手和头部就能吃掉你 10% 的流量预算。
• 服务端有状态：你得维护一个固件服务器，或者用对象存储。我曾经见过有人直接把固件放 GitHub Releases 里当升级源……嗯，后来被限速了。
• HTTPS 的握手开销：TLS 握手在资源受限的 MCU 上可能耗时 3-5 秒，甚至更长。如果设备频繁重连，这个开销不可忽视。

3.2 MQTT：物联网的宠儿，但固件传输不是它的主业

MQTT 是很多物联网平台的首选协议。轻量、发布/订阅模式、支持 QoS 等级。但我要说一句：MQTT 设计之初是用来传小数据的，不是用来传固件的。

优点：

• 长连接、低开销：建立一次连接后，后续消息的头部只有 2 字节。对于频繁上报的设备很友好。
• QoS 机制：QoS 1 和 QoS 2 能保证消息到达，适合需要确认的场景。
• 双向通信：服务器可以主动推送升级通知，设备不需要轮询。

缺点：

• Payload 大小限制：MQTT 协议本身不限制 payload 大小，但很多 Broker 默认限制在 256KB 以内。你要传一个 50MB 的固件，得自己分片、排序、重组。我在项目中就写过这个逻辑，说实话，挺麻烦的。
• 缺乏断点续传：MQTT 没有原生的断点续传机制。分片传输时，如果中间丢了一片，你得自己实现重传逻辑。
• 不适合大文件：Broker 需要缓存所有消息，大文件传输会占用大量内存，可能导致 Broker 崩溃。

3.3 CoAP：为受限设备而生，但生态不完善

CoAP 是 UDP 之上的 RESTful 协议，专门为资源受限的设备设计。如果你在做基于 6LoWPAN 或 NB-IoT 的网关，CoAP 值得一看。

优点：

• 极低的开销：基于 UDP，头部只有 4 字节。比 HTTP 轻量太多了。
• 支持观察模式：类似 MQTT 的订阅，服务器可以主动推送资源变化。
• 支持块传输：CoAP 的 Block 选项原生支持大文件分片传输，比 MQTT 自己实现分片要优雅得多。

缺点：

• 可靠性依赖重传：UDP 本身不可靠，CoAP 的可靠传输靠的是 Confirmable 消息和重传。在丢包率高的网络里，重传次数可能爆炸。
• 防火墙穿透难：很多企业防火墙会拦截 UDP 流量。你想想看，客户 IT 部门一听你要开 UDP 端口，脸都绿了。
• 生态不成熟：CoAP 的库和工具链远不如 HTTP 和 MQTT 丰富。出问题了，社区能给你的帮助有限。

3.4 FTP：老牌协议，但已不适合现代物联网

FTP 是文件传输的元老。稳定、成熟、支持断点续传、支持目录操作。但说实话，在物联网固件升级这个场景里，我几乎不用它。

优点：

• 传输效率高：FTP 的二进制传输模式没有额外开销，适合大文件。
• 断点续传成熟：REST 命令原生支持，实现简单。
• 支持被动模式：可以解决部分防火墙问题。

缺点：

• 安全性差：FTP 明文传输用户名和密码。用 FTPS 或 SFTP 可以解决，但增加了复杂度。
• 双通道问题：FTP 使用控制通道和数据通道分离的设计。主动模式下，服务器主动连接客户端的随机端口，防火墙根本没法配。被动模式稍微好点，但依然麻烦。
• 不适合低功耗设备：FTP 的会话管理开销大，设备频繁重连时效率极低。

3.5 协议对比总表

下面这张表是我自己整理的，每次做选型时都会拿出来看一眼。你直接拿去用。

维度	HTTP/HTTPS	MQTT	CoAP	FTP
传输层	TCP	TCP	UDP	TCP
头部开销	~800 字节 (HTTPS)	2 字节	4 字节	~50 字节
断点续传	原生支持 (Range)	需自行实现	Block 选项支持	原生支持 (REST)
防火墙穿透	优秀 (80/443)	良好 (8883 常见)	差 (UDP 常被拦截)	差 (双通道问题)
安全性	优秀 (TLS)	良好 (TLS)	可选 (DTLS)	差 (明文)
大文件传输	优秀	差 (Payload 限制)	一般 (需分块)	优秀
低功耗适配	差 (TCP 长连接)	良好 (长连接)	优秀 (UDP 无连接)	差
生态成熟度	极高	高	低	高
推荐场景	大固件、稳定网络	小固件、频繁升级	受限设备、专网	内网、大文件

3.6 选型决策流程

说了这么多，到底怎么选？我画了一张流程图，你跟着走一遍，基本就有答案了。

3.7 我的最终建议

做了这么多年固件升级，我个人的经验总结下来就三句话：

• 默认选 HTTPS：除非你有非常明确的理由不选它。安全、稳定、生态好，团队招人也容易。
• 不要只用一种协议：我见过最优雅的方案是 MQTT 做控制面（发升级通知、查版本号），HTTPS 做数据面（传固件包）。各取所长。
• 别为了炫技选冷门协议：CoAP 和 FTP 不是不能用，但你要想清楚后续的维护成本。团队里有人会调 CoAP 的 DTLS 参数吗？客户 IT 愿意开 UDP 端口吗？这些问题比技术本身更关键。