日常做接口开发、物联网设备接入，经常用到 HTTP、HTTPS、MQTT、MQTTS。不少开发人员图省事，直接把明文端口暴露公网，存在明显安全隐患。本文从协议本质、端口、通信模型、适用场景做整理，作为项目选型参考。
核心一句话： HTTPS = HTTP + TLS 加密；MQTTS = MQTT + TLS 加密。 HTTPS 不改变 HTTP 请求响应逻辑，MQTTS 也不改动 MQTT 协议本身，只是在传输层增加 TLS 加密隧道。
一、HTTP 与 HTTPS
二者为请求 - 响应模型，多为短连接，客户端主动发起请求、服务端返回结果，协议本身不支持服务端主动推送，如需实时数据只能轮询。
| 项目 | HTTP | HTTPS |
|---|---|---|
| 默认端口 | 80 | 443 |
| 传输 | 明文传输，抓包可直接看到请求参数、返回内容 | TLS 加密传输，防窃听、报文篡改、服务端身份伪造 |
| 证书 | 无需证书 | 需要 SSL 证书，CA 签发证书用于正式环境，自签名证书多用于内部测试 |
| 通信模型 | 请求响应，一问一答 | 和 HTTP 一致，仅底层增加加密层 |
使用示例
- HTTP：内网设备 Web 管理页面
http://192.168.1.100、本地静态页面调试。 限制：仅封闭内网调试使用，禁止在外网传输账号、密码、token 等敏感信息。 - HTTPS：业务后端 REST 接口、网页访问、第三方登录、支付接口，例如
https://www.baidu.com。 正式公网业务接口、前端页面优先使用 HTTPS。
类比参考：HTTP 相当于明文信件，链路中可被直接阅读；HTTPS 是加密信件，同时可以校验通信对方身份。
二、MQTT 与 MQTTS（MQTT over TLS）
二者为发布订阅模型，主打长连接、小包传输，支持 QoS 消息等级、断线重连，服务端可以主动向在线设备下发消息，适合资源有限的物联网终端。
| 项目 | MQTT | MQTTS |
|---|---|---|
| 默认端口 | 1883 | 8883 |
| 传输 | 明文传输，用户名、密码、topic、payload 均可被抓包 | TLS 隧道加密，全部报文加密 |
| 证书 | 无需证书 | 需要 CA 证书，支持单向认证、双向证书认证 |
| 通信模型 | 发布订阅、长连接、支持 QoS、断线重连 | MQTT 协议逻辑不变，底层通道加密 |
使用示例
- MQTT：内网部署 Mosquitto broker，ESP32、采集终端局域网内上报温湿度、电表数据，地址
mqtt://192.168.1.10:1883。 限制：仅限内网调试，公网开放 1883 端口风险很高。 - MQTTS：公有云 IoT 平台设备接入，电表、采集终端远程上送电能数据、接收远程控制指令，地址
mqtts://xxx.iot-as-mqtt.cn-shanghai.aliyuncs.com:8883。 所有外网接入的物联网设备，优先采用 MQTTS。
类比参考：MQTT 是明文对讲；MQTTS 是加密对讲，通信内容不会被链路嗅探获取。
三、横向对比与选型建议
- HTTP/HTTPS：适合单次查询、表单提交、后端 API 调用。没有主动推送能力，要获取实时数据，客户端需要持续轮询。
- MQTT/MQTTS：适合周期性上报、远程控制、事件主动推送。长连接、报文体积小，流量开销低，适合 ESP32、STM32、智能电表这类低资源物联网终端。
选型总结： 网页、后端接口、单次查询业务 → HTTPS 物联网终端、传感器实时上报、远程控制、设备持续在线 → MQTTS
四、开发注意事项
HTTP、MQTT 明文协议，定位就是调试协议，只允许在内网隔离环境使用。 只要服务或设备暴露到公网，统一使用加密版本 HTTPS / MQTTS。 很多安全问题不是协议漏洞，而是开发阶段调试配置直接带到生产，明文端口对外开放，造成密钥、采集数据泄露、设备被非法控制。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/weixin_48867130/article/details/169632161
