求问 MQTT 和 TCP 透传优劣

[unt]

目前本公司物联网平台对接了 10 多家设备，有些是采用 16 进制字节码 TCP 透传，有些是 MQTT 对接（已语义化解析）。MQTT 的优势自然不用多说，那请问它的劣势是什么，传统 TCP 透传的优势又是什么。


另外请问，采用 MQTT 的话，是不是数据解析就直接做进设备里去了，而不会说是传输的实际上还是字节码，另外服务端再加一层数据解析层。

[yolee599]

缺点：
- mqtt 需要搭 broker ，数据链路比较长，TCP 透传不用。
- mqtt 包比较长，TCP 透传包可以设计得短一点。
- mqtt 软件需要跑第三方库（当然也可以自己实现），TCP 透传可以自己设计得很简单。

优点：
- mqtt 第三方库都做了重传和确认机制，TCP 透传需要自己实现。
- mqtt 有很多跨平台的库，使用起来比较方便，TCP 透传需要自己实现。
- mqtt 调试比较方便，一个 client 工具订阅一下就能看到交互的数据，TCP 透传需要抓包。

想方便使用和对接各个平台就上 mqtt ，不嫌麻烦想自己研究一套就用 TCP 透传自己实现，还可以了解一下另一个物联网协议叫 CoAP ，最小包长度为 4 字节。

[wentx]

MQTT 的劣势：

协议开销：MQTT 是基于 TCP 的协议，它在 TCP 基础上增加了一些特性，例如发布 /订阅模式、消息质量等。由于这些额外的特性，MQTT 协议可能会比纯 TCP 透传协议增加一些额外的开销。
依赖中间代理：MQTT 需要一个中间代理（ MQTT Broker ），它负责转发客户端之间的消息。这增加了一个潜在的故障点，如果代理出现问题，那么整个系统可能会受到影响。
TCP 透传的优势：

简单：TCP 透传协议相对简单，易于理解和实现。它不需要额外的代理服务器，客户端可以直接与服务器进行通信。
更低的延迟：TCP 透传协议由于缺少额外的特性和中间代理，可能具有更低的延迟。这在某些对实时性要求较高的场景中可能是一个优势。
更好的控制：使用 TCP 透传协议时，可以直接处理原始的字节流，这意味着对数据传输的控制更加灵活，可能更容易满足特定的应用需求。
关于您的第二个问题，采用 MQTT 协议时，通常会将数据解析放在设备端。MQTT 协议支持发布 /订阅模式，客户端（设备）会向代理发布主题（ Topic ）和消息（ Payload ），这些消息通常是结构化的数据（如 JSON ）。

这意味着，使用 MQTT 时，设备端会将数据解析和封装成结构化数据，然后通过 MQTT 发送给代理。代理收到数据后，会将其转发给订阅了相应主题的其他客户端。在这个过程中，数据已经是结构化的，因此服务端无需再进行额外的数据解析层。

但是，在某些情况下，设备端可能仍然会发送二进制数据（如字节码）。在这种情况下，服务端需要对这些数据进行解析。不过，这并不是 MQTT 协议的限制，而是设备端实现的选择。

[tramm]

我们是用的 JTT808 魔改的,结构按照他的,有的消息 ID 就跟他们的冲突了...
不过我们跟其他平台间有的就用 MQTT 传的.
优劣势的话么,我觉得自定义 TCP 协议的话,可操作性比较大吧. MQTT 依赖于 Broker 的实现(应该没人会想着自己实现一套吧). EMQX 的 Broker 不知道咋设置, 反正数据多的话, 且 Qos=2 时, 感觉就不行了.
对我们来说,最大的区别就是 MQTT 系统架构复杂度低, 集成也简单; 自定义 TCP 协议, 不可替代性强, 培训班不学这个(哈哈哈, :P)

[gujigujij]

tcp 透传的话，读取程序在服务器， 维护和调试比较方便。

[unt]

@wentx #22 对对对，我要的这种回答，感谢

[unt]

@yolee599 #21 感谢

[unt]

每一层都已认真阅读，谢谢各位的解答

[winv87]

都支持，自家监控系统的直接透传。 设备需要对接第三方监控，用 MQTT 比较通用。

[jiny28]

mqtt 可以解决设备没固定 ip 的情况，比如 4G 网卡。

[aguesuka]

首先透传是什么意思, 比如电表和服务器不直接通信, 而是电表通过电线载波通信到集中器, 再由集中器通信到应用程序. 注意载波通信是利用输电线通信的. 那么电表发给集中器的报文如果直接发送给服务器, 就是透传. 而集中器中途做处理就不是透传.

抛开集中器的问题 mqtt 的缺点
1. mqtt 是发布订阅模式, 但是业务模型绝大部分是 rpc 模型.
2. mqtt 提供的功能看起来很美好, 比如一条消息只发一次, 最少发一次, 实际上没人敢依赖这个特性, 还是要实现幂等, 假设消息丢失.

[deepshe]

mqtt 也要芯片厂商能支持吧，比如芯片厂做好 sdk 包，不然用不同的芯片就需要公司针对不同芯片实现 mqtt 协议
tcp 的话直接用自己的协议就好了

[wentx]

@unt #25 不客气，毕竟这是 GPT4 给的答案..

[AnroZ]

MQTT 的协议层级比 TCP 高，你的问题可类比：TCP 和 HTTP 的优劣势。
但总的来说，MQTT 定义的行为非常适合物联网场景。用 TCP 的话还要去额外实现类似 MQTT 功能，对于平台方来说，不是特别划算。
建议，尽量往 MQTT 方向靠。

至于第二个问题，应该跟 MQTT 和 TCP 无关。

[yazinnnn]

如果你的 tcp 使用场景逐渐变得复杂和庞大, 你终究会把 tcp 包装成一个半吊子的 错误百出的 不完整的 mqtt 协议

虽说 mqtt 一般场景是使用 broker, 但是你自己根据 mqtt 编码协议去实现一个 C/S 模式的服务是很简单的

[zunceng]

由于“reserve RPC”不是一个 well-known 的词， 我们可以定义一下是指服务器端主动调用客户端的函数或方法。在标准的 RPC 模型中，通常是客户端调用服务器上的函数或过程，但在某些情况下，服务器可能需要向客户端发送请求或回调，这就是反向 RPC 的应用场景。

HTTP 模式是 req/rep 不太适合 reserve RPC 的场景，如果有大量的服务端向客户端查询的业务 那肯定是消息队列更加合适，当然这种情况 用 websocket 或者 tcp 自己做一个 reverse RPC 肯定也是 OK 的

[kaneg]

对于 mqtt ，设备的数量级上去之后就有优势了，要接受成千上万的设备的消息，如果自己写服务器，是很难保证可靠性和可用性的。术业有专攻，消息中间件可以专门负责接收，存储和转发消息，应用服务器也可以专注于自己的业务。所以，选不选 mqtt 就要看自己的的业务量是不是真的需要。业务量小的时候随便怎么搞都行。

[casper13]

tcp 面对面中指，mqtt 张小龙 fxxk