设备连上网之后，数据到底该怎么"传"？这就绕不开传输层的两位老搭档——TCP 和 UDP。很多刚接触物联网的朋友在这两者之间反复纠结：要保证数据不丢，是不是只能选 TCP？要实时性，是不是只能选 UDP？答案其实没这么简单。这篇文章把两者的区别讲透，再聊聊物联网里绕不开的"心跳保活"机制。
一、TCP 和 UDP 的本质区别
一句话比喻：
- TCP 像打电话——先拨号接通、确认对方在听，说一句对方应一句，保证内容完整、顺序不乱。
- UDP 像寄信——写好就投进邮筒，至于对方收到没有、几封到达、顺序对不对，一概不保证。
落到技术层面，区别如下：
| 维度 | TCP | UDP |
|---|---|---|
| 是否需要建立连接 | 需要（三次握手） | 不需要，直接发 |
| 可靠性 | 保证送达、不丢不重 | 不保证，可能丢包 |
| 数据顺序 | 保证有序 | 不保证，可能乱序 |
| 传输速度 | 较慢（有确认开销） | 快、开销小 |
| 资源占用 | 较高 | 较低 |
| 典型用途 | 网页、文件、远程控制 | 直播、语音、游戏、DNS |
二、什么时候用 TCP
当你的数据一条都不能丢、顺序不能乱时，选 TCP。典型场景：
- 文件传输、软件下载
- 网页浏览（HTTP/HTTPS 底层就是 TCP）
- 远程控制指令（开关门、启停设备）
- Modbus TCP 工业通信
- MQTT 消息协议（默认走 TCP）
对物联网而言，凡是涉及"控制"和"计费"的，几乎都要用 TCP——你绝不希望一条"开门"指令在半路丢了。
三、什么时候用 UDP
当实时性优先、且能容忍少量丢包时，选 UDP。典型场景：视频直播、语音通话、在线游戏、DNS 域名查询、局域网设备发现广播。
注意一个常见误区：UDP 快，不代表它"更先进"。UDP 把可靠性的担子甩给了应用层——如果你用 UDP 传重要数据，就得自己在代码里做"确认 + 重传"，等于手动造了个简易 TCP。
四、物联网常用协议速览
1. Modbus（工业设备的"普通话"）
工业现场最常见的是 Modbus RTU（走串口）和 Modbus TCP（走以太网）。一条 Modbus 指令由"设备地址 + 功能码 + 数据 + 校验"组成，例如一条开门指令：
01 06 00 02 00 01 E9 CA
拆开看：
- 01 —— 从站设备地址
- 06 —— 功能码（写单个保持寄存器）
- 00 02 —— 寄存器地址
- 00 01 —— 写入的值（此处为"开锁"动作）
- E9 CA —— CRC16 校验码，用于保证数据完整性
2. MQTT（物联网首选消息协议）
MQTT 采用发布/订阅模式：设备把数据"发布"到某个主题，云端"订阅"该主题就能收到。它协议头极小、省流量、支持弱网，是物联网消息通信的事实标准。
3. HTTP / HTTPS（与云端 API 交互）
设备主动向云端接口发请求、取指令，是最简单直接的接入方式。比如一个智能电话通知终端，通过 HTTPS 请求云端接口 https://xxx.com/api/notify，拿到待通知的任务列表再逐一执行。
五、心跳保活：为什么设备会"假在线"
很多物联网项目都会遇到一个诡异现象：设备明明显示"在线"，指令却发不过去。原因通常是——设备与服务器之间的连接，其实早就断了，但双方都还不知道。
TCP 虽然可靠，但中间的链路断了它不一定马上知道（比如设备断电、网络切换、运营商踢掉空闲连接）。这时候就需要心跳（Heartbeat）：设备定期给服务器发一个"我还活着"的小数据包，服务器据此判断设备是否真的在线。
一个简单的心跳设计思路：
设备端：
每隔 30 秒 → 发送心跳包（附上当前时间戳）
服务器端：
每收到一次心跳 → 更新该设备的 last_seen 时间
定时扫描 → 若 当前时间 - last_seen > 90 秒 → 判定设备离线，触发告警
这里有几个设计要点：
- 心跳间隔：太频繁浪费流量，太稀疏反应迟钝，常见 30~60 秒。
- 超时判定：一般设为心跳间隔的 2~3 倍，避免偶尔一次网络抖动就误判。
- 时间戳：心跳里带上时间戳，能帮你发现"设备时钟不准""心跳数据陈旧"这类隐蔽问题。
- 断线重连：设备检测到自己掉线后，要能自动重连，而不是傻等。
真实案例：某门锁 DTU 设备出现过"心跳时间戳陈旧"的问题——设备在线，但服务器收到的却是旧时间戳，导致状态判断异常。排查后发现是设备端时钟漂移，同步时钟后解决。这类问题往往要结合心跳数据里的时间戳才能定位。
六、内网穿透与公网访问
很多设备本身在局域网里（比如接在路由器后面的控制柜），那外网怎么访问它？常见有三种方案：
- 路由器端口映射：把公网某个端口转发到内网设备的端口，适合有固定公网 IP 的场景。
- 内网穿透工具（如 frp、花生壳）：设备主动连到一台有公网 IP 的中转服务器，适合没有公网 IP 的场景。
- 云平台中转：设备主动连到云端，云端再下发指令，最省心，也最主流。
真实案例：一台 TCP 服务器同时承载 Modbus RTU 和 JSON 文本 两种协议，共用同一个 8899 端口。设备按约定的帧格式区分协议类型，服务器据此分发处理。多协议共用端口能省资源，但协议解析要格外严谨，否则容易串数据。
写在最后
记住一个判断口诀：要可靠、要控制，选 TCP；要实时、能丢一点，选 UDP；设备要长期在线，一定要做心跳保活。下一篇，我们换个视角，聊聊这些联网设备和网站都会面临的安全问题——从 HTTPS 到 SQL 注入，把防护做扎实。
评论一下？