TCP、UDP、MQTT、JT808：设备到底在跟谁说话
TCP 和 UDP 是传输方式，MQTT 是应用层的消息协议，JT/T 808 是行业规约，四者不在同一层。选型时要先确认平台收什么，再定设备用什么，而不是挑一个听起来更高级的。
设备上线了、平台也开着，就是看不到数据，问题常常不在任何一方，而在两边说的不是同一套话。早些年一台终端对着一台服务器，把一串字节按约定格式发过去就算完事；后来车辆多了、平台换了几茬，人们才把这件事分层：底下管怎么把包送到，TCP、UDP 是这一层；上面管包里写的是什么，JT808 这类行业协议或 MQTT 这类消息格式是另一层。寄信可以打个比方，信封上写地址，信里写内容，邮局只管把信封送到，拆开看不看得懂是收信人的事。地址写错，信会退回；格式不对，信送到了也没人认。所以「设备离线」和「上线但没点位」是两层毛病，排查时得分开问。平台选型也一样，先问对方收哪套协议、字段表长什么样，再回头看自家终端发得出什么，比先谈界面功能实际。
这四个词常被并列成“四种协议让人选一个”，其实它们不在同一层：TCP、UDP 是传输层（transport layer）的连接方式，MQTT 是跑在传输层之上的应用层消息协议，JT/T 808 是面向特定行业监管场景的规约，规定了消息结构、字段与交互流程。真正的选型问题不是“哪个更好”，而是“你的平台要求哪一套”。
先分层，再谈取舍，最后给你一条能落到纸面的判断线。
一、四个词分层对比
| 名称 | 属于哪一层 | 解决什么 | 特点 | 典型顾虑 |
|---|---|---|---|---|
| TCP | 传输控制协议 (Transmission Control Protocol) | 可靠、有序的字节流 | 有连接、有确认与重传 | 弱网下重连与保活要设计好 |
| UDP | 用户数据报协议 (User Datagram Protocol) | 无连接的轻量数据报 | 开销小、时延低 | 不保证送达，需业务层自己兜底 |
| MQTT | 消息队列遥测传输 (Message Queuing Telemetry Transport) | 发布/订阅式消息交互 | 主题、会话、心跳机制清晰 | 需要服务端支持，字段结构仍要另定 |
| JT/T 808 | 道路运输车辆卫星定位系统终端通讯协议及数据格式 | 行业规约：消息 ID、字段、流程 | 便于接入对应监管平台 | 适用范围与版本需按项目确认 |
表里不给端口号、报文长度、消息 ID 等具体数值：这些属于协议文档与项目约定，写死容易错，也和选型判断无关。需要时请索取对应版本的协议文档，并以书面版本为准。
三个要点：
- MQTT 通常跑在 TCP 之上，所以“选 TCP 还是选 MQTT”这个问法本身就不成立；它们是上下层关系。
- JT/T 808 规定的是“说什么、怎么说”，底层承载仍要选传输方式；把规约和传输方式对立起来，是方案文档里常见的技术错误。
- 同一台设备在不同项目里可能配不同协议，通常通过配置切换；具体支持范围需向商务确认，不能按产品页的通用描述推定。
站内短信配置页公开了设备侧地址、端口与传输方式类的配置口径，页面里的地址与端口为占位示例，必须按平台给的真实值替换；产品总览可逐款核对型号。某个型号是否支持某种协议、适用的规约版本与字段表，站内没有完整公开清单，需向商务或平台方索取书面确认。
二、平台选型的判断线
按这个顺序问，能避免“设备买了接不进平台”：
| 顺序 | 要问的问题 | 为什么先问它 |
|---|---|---|
| 1 | 平台接收哪套规约 / 字段格式 | 决定设备能不能被读懂，是硬门槛 |
| 2 | 平台的接入地址、端口、鉴权方式 | 决定连接能不能建立 |
| 3 | 底层传输方式与保活、重连要求 | 决定弱网下的表现 |
| 4 | 上报字段里有没有定位来源、精度标识 | 决定轨迹能否正确解释 |
| 5 | 是否有白名单、专网或定向访问限制 | 决定卡与网络怎么配 |
第 1 步是硬门槛：字段对不上，连接再稳也只是“连上了但没人懂”。第 5 步最常被漏，往往等设备装上车才发现卡被限制访问。
还有一条现实建议：如果项目要接行业监管平台，先把平台方的接入规范拿到手，再回头选设备。反过来先买设备再问平台，容易陷入“要不要加一台转换器”的被动局面。
三、几个常被混淆的说法
- “我们支持 TCP”：只说明能建连接，不代表业务报文能被解析。
- “我们支持 MQTT”：还要确认主题（topic）命名、消息体字段、QoS 等级与会话策略由谁定。
- “我们支持 808”：要确认适用的规约版本、以及是否包含项目要求的具体消息与附加字段。
- “换个协议就行”：若涉及固件能力、字段表与平台改造，通常不是改一条配置能解决的，需评估工作量。
把这几句写进需求确认单，让对方逐条书面回，比口头说“都支持”可靠得多。设备侧参数配置完成后，可用串口工具查看带时间戳的回执留痕，便于和平台侧日志对齐时间点。
四、平台选型按哪几条问
如果你在做自建平台或第三方 IoT 平台接入，先把字段表与鉴权方式谈定，传输方式按平台既有能力选，不必另起炉灶。如果你在做需要接入行业监管平台的项目，规约版本与检测要求排在首位，其余都往后排。
如果你在做一批只上报位置与状态、后续可能换平台的非部标设备，选“字段表书面留存 + 配置可改”的方案，把可迁移性留出来；但像 TM800 这类部标一体机不适用——协议由 JT/T 808 固定，能谈的只有平台是否支持对应版本，不存在改协议这条路。如果平台已定且短期不会变，就按平台规范一次配到位，把精力放在重连与补报策略上。
让平台方先给一份字段表样张：每条上报里有哪些字段、单位是什么、时间戳按谁的时钟、断线补传怎么标。拿这张表去对设备侧能发出的内容，逐行打勾，缺的项写清由谁补。联调时留一份原始报文和对应的平台解析结果，两边各存一份；日后换平台或升固件，这对样本就是最快的对照。协议文档与字段表需向商务索取书面版本，别靠口头描述定接口。
