缺点： - mqtt 需要搭 broker ，数据链路比较长，TCP 透传不用。 - mqtt 包比较长，TCP 透传包可以设计得短一点。 - mqtt 软件需要跑第三方库（当然也可以自己实现），TCP 透传可以自己设计得很简单。 优点： - mqtt 第三方库都做了重传和确认机制，TCP 透传需要自己实现。 - mqtt 有很多跨平台的库，使用起来比较方便，TCP 透传需要自己实现。 - mqtt 调试比较方便，一个 client 工具订阅一下就能看到交互的数据，TCP 透传需要抓包。 想方便使用和对接各个平台就上 mqtt ，不嫌麻烦想自己研究一套就用 TCP 透传自己实现，还可以了解一下另一个物联网协议叫 CoAP ，最小包长度为 4 字节。
MQTT 的劣势： 协议开销：MQTT 是基于 TCP 的协议，它在 TCP 基础上增加了一些特性，例如发布 /订阅模式、消息质量等。由于这些额外的特性，MQTT 协议可能会比纯 TCP 透传协议增加一些额外的开销。 依赖中间代理：MQTT 需要一个中间代理（ MQTT Broker ），它负责转发客户端之间的消息。这增加了一个潜在的故障点，如果代理出现问题，那么整个系统可能会受到影响。 TCP 透传的优势： 简单：TCP 透传协议相对简单，易于理解和实现。它不需要额外的代理服务器，客户端可以直接与服务器进行通信。 更低的延迟：TCP 透传协议由于缺少额外的特性和中间代理，可能具有更低的延迟。这在某些对实时性要求较高的场景中可能是一个优势。 更好的控制：使用 TCP 透传协议时，可以直接处理原始的字节流，这意味着对数据传输的控制更加灵活，可能更容易满足特定的应用需求。 关于您的第二个问题，采用 MQTT 协议时，通常会将数据解析放在设备端。MQTT 协议支持发布 /订阅模式，客户端（设备）会向代理发布主题（ Topic ）和消息（ Payload ），这些消息通常是结构化的数据（如 JSON ）。 这意味着，使用 MQTT 时，设备端会将数据解析和封装成结构化数据，然后通过 MQTT 发送给代理。代理收到数据后，会将其转发给订阅了相应主题的其他客户端。在这个过程中，数据已经是结构化的，因此服务端无需再进行额外的数据解析层。 但是，在某些情况下，设备端可能仍然会发送二进制数据（如字节码）。在这种情况下，服务端需要对这些数据进行解析。不过，这并不是 MQTT 协议的限制，而是设备端实现的选择。
我们是用的 JTT808 魔改的,结构按照他的,有的消息 ID 就跟他们的冲突了... 不过我们跟其他平台间有的就用 MQTT 传的. 优劣势的话么,我觉得自定义 TCP 协议的话,可操作性比较大吧. MQTT 依赖于 Broker 的实现(应该没人会想着自己实现一套吧). EMQX 的 Broker 不知道咋设置, 反正数据多的话, 且 Qos=2 时, 感觉就不行了. 对我们来说,最大的区别就是 MQTT 系统架构复杂度低, 集成也简单; 自定义 TCP 协议, 不可替代性强, 培训班不学这个(哈哈哈, :P)
