这是一个创建于 548 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前本公司物联网平台对接了 10 多家设备，有些是采用 16 进制字节码 TCP 透传，有些是 MQTT 对接（已语义化解析）。MQTT 的优势自然不用多说，那请问它的劣势是什么，传统 TCP 透传的优势又是什么。
另外请问，采用 MQTT 的话，是不是数据解析就直接做进设备里去了，而不会说是传输的实际上还是字节码，另外服务端再加一层数据解析层。
另外请问，采用 MQTT 的话，是不是数据解析就直接做进设备里去了，而不会说是传输的实际上还是字节码，另外服务端再加一层数据解析层。
 |
1
koloonps 2023-06-02 10:59:53 +08:00
设备不一定支持 MQTT
"采用 MQTT 的话，是不是数据解析就直接做进设备里去了，而不会说是传输的实际上还是字节码，另外服务端再加一层数据解析层" 这个和 mqtt 没有关系吧? |
 |
2
unt OP |
 |
3
flyqie 2023-06-02 11:12:37 +08:00 via Android
非相关行业人员哈。
自己在用的物联网设备好像基本都是 mqtt ，tcp 比较少。 蹲个大佬。 |
|
5
koloonps 2023-06-02 11:15:39 +08:00
@unt 看什么行业吧,收款语音播报这一些基本都是 mqtt.复杂一点的大多都是 hex.你可以参考下 JT808/JT809
|
 |
6
lopssh 2023-06-02 11:17:14 +08:00
这里的"透传"怎么理解？
|
 |
9
Baloneo 2023-06-02 11:32:45 +08:00
设备协议有很多 Modbus IEC DLT ，什么电表水表这些基本不支持 MQTT 的 就需要网关转发成 MQTT 报文或者自己写程序解析 一般都是通过网关转发 MQTT 由网关解析成设备需要的协议 设备本身支持 MQTT 的另说 设备直接实现 TCP 直连 /透传会比设备里写 MQTT 代码容易
|
 |
10
duke807 2023-06-02 11:33:55 +08:00
mqtt 用不了 cloudflare 之类的免费 cdn
|
 |
11
gam2046 2023-06-02 11:35:49 +08:00
MQTT 主要是帮你做了很多可靠性的工作，比如确保消息送达，确保消息有且仅有收到一次，设备暂离时消息会在设备连线时重发、消息的广播等。在满足这些的情况下，同时 MQTT 对于带宽要求也很小（协议开销小）
如果你的环境下，本身网络条件是没有可靠性问题，那我觉得 TCP 直接上也可以。 |
 |
12
mlhorizon 2023-06-02 11:36:32 +08:00
TCP 透传的优势是现场设备简单，便宜，少配置。
这些就是 MQTT 的劣势。 |
|
13
flyqie 2023-06-02 11:37:17 +08:00 via Android
|
 |
14
cloudzhou 2023-06-02 11:38:59 +08:00
mqtt 主要是标准化，换个服务商继续还可以用
|
|
16
flyqie 2023-06-02 11:41:16 +08:00 via Android
|
 |
17
masterclock 2023-06-02 11:42:09 +08:00
使用所谓 tcp 透传的，通常最终都会发明一套 mqtt
mqtt 上的数据，常见 json ，自定义文本格式，也有玩点 cbor 啥的，但二进制也不少见 |
 |
18
opengps 2023-06-02 11:42:53 +08:00
tcp 是自定义规则，就好比底层语言一样很基础
mqtt 没怎么实际使用过，个人感觉只是规范了通信规则，通用的场景 |
 |
19
bfdh 2023-06-02 11:49:32 +08:00
MQTT 更耗资源，在服务端尤其明显，带机量、性能显著低于 tcp 。
|
 |
21
yolee599 2023-06-02 12:12:19 +08:00  2
缺点：
- mqtt 需要搭 broker ，数据链路比较长，TCP 透传不用。 - mqtt 包比较长，TCP 透传包可以设计得短一点。 - mqtt 软件需要跑第三方库（当然也可以自己实现），TCP 透传可以自己设计得很简单。 优点： - mqtt 第三方库都做了重传和确认机制，TCP 透传需要自己实现。 - mqtt 有很多跨平台的库，使用起来比较方便，TCP 透传需要自己实现。 - mqtt 调试比较方便，一个 client 工具订阅一下就能看到交互的数据，TCP 透传需要抓包。 想方便使用和对接各个平台就上 mqtt ，不嫌麻烦想自己研究一套就用 TCP 透传自己实现，还可以了解一下另一个物联网协议叫 CoAP ，最小包长度为 4 字节。 |
 |
22
wentx 2023-06-02 12:18:11 +08:00 1
MQTT 的劣势：
协议开销：MQTT 是基于 TCP 的协议，它在 TCP 基础上增加了一些特性，例如发布 /订阅模式、消息质量等。由于这些额外的特性，MQTT 协议可能会比纯 TCP 透传协议增加一些额外的开销。 依赖中间代理：MQTT 需要一个中间代理（ MQTT Broker ），它负责转发客户端之间的消息。这增加了一个潜在的故障点，如果代理出现问题，那么整个系统可能会受到影响。 TCP 透传的优势： 简单：TCP 透传协议相对简单，易于理解和实现。它不需要额外的代理服务器，客户端可以直接与服务器进行通信。 更低的延迟：TCP 透传协议由于缺少额外的特性和中间代理，可能具有更低的延迟。这在某些对实时性要求较高的场景中可能是一个优势。 更好的控制：使用 TCP 透传协议时，可以直接处理原始的字节流，这意味着对数据传输的控制更加灵活，可能更容易满足特定的应用需求。 关于您的第二个问题，采用 MQTT 协议时，通常会将数据解析放在设备端。MQTT 协议支持发布 /订阅模式，客户端（设备）会向代理发布主题（ Topic ）和消息（ Payload ），这些消息通常是结构化的数据（如 JSON ）。 这意味着，使用 MQTT 时，设备端会将数据解析和封装成结构化数据，然后通过 MQTT 发送给代理。代理收到数据后，会将其转发给订阅了相应主题的其他客户端。在这个过程中，数据已经是结构化的，因此服务端无需再进行额外的数据解析层。 但是，在某些情况下，设备端可能仍然会发送二进制数据（如字节码）。在这种情况下，服务端需要对这些数据进行解析。不过，这并不是 MQTT 协议的限制，而是设备端实现的选择。 |
 |
23
tramm 2023-06-02 12:31:30 +08:00
我们是用的 JTT808 魔改的,结构按照他的,有的消息 ID 就跟他们的冲突了...
不过我们跟其他平台间有的就用 MQTT 传的. 优劣势的话么,我觉得自定义 TCP 协议的话,可操作性比较大吧. MQTT 依赖于 Broker 的实现(应该没人会想着自己实现一套吧). EMQX 的 Broker 不知道咋设置, 反正数据多的话, 且 Qos=2 时, 感觉就不行了. 对我们来说,最大的区别就是 MQTT 系统架构复杂度低, 集成也简单; 自定义 TCP 协议, 不可替代性强, 培训班不学这个(哈哈哈, :P) |
 |
24
gujigujij 2023-06-02 12:47:38 +08:00
tcp 透传的话，读取程序在服务器， 维护和调试比较方便。
|
|
27
unt OP 每一层都已认真阅读，谢谢各位的解答
|
 |
28
winv87 2023-06-02 13:16:13 +08:00
都支持，自家监控系统的直接透传。 设备需要对接第三方监控，用 MQTT 比较通用。
|
 |
29
jiny28 2023-06-02 13:23:09 +08:00
mqtt 可以解决设备没固定 ip 的情况，比如 4G 网卡。
|
 |
30
aguesuka 2023-06-02 14:17:52 +08:00
首先透传是什么意思, 比如电表和服务器不直接通信, 而是电表通过电线载波通信到集中器, 再由集中器通信到应用程序. 注意载波通信是利用输电线通信的. 那么电表发给集中器的报文如果直接发送给服务器, 就是透传. 而集中器中途做处理就不是透传.
抛开集中器的问题 mqtt 的缺点 1. mqtt 是发布订阅模式, 但是业务模型绝大部分是 rpc 模型. 2. mqtt 提供的功能看起来很美好, 比如一条消息只发一次, 最少发一次, 实际上没人敢依赖这个特性, 还是要实现幂等, 假设消息丢失. |
 |
31
deepshe 2023-06-02 14:35:02 +08:00
mqtt 也要芯片厂商能支持吧，比如芯片厂做好 sdk 包，不然用不同的芯片就需要公司针对不同芯片实现 mqtt 协议
tcp 的话直接用自己的协议就好了 |
 |
33
AnroZ 2023-06-02 15:21:34 +08:00
MQTT 的协议层级比 TCP 高，你的问题可类比：TCP 和 HTTP 的优劣势。
但总的来说，MQTT 定义的行为非常适合物联网场景。用 TCP 的话还要去额外实现类似 MQTT 功能，对于平台方来说，不是特别划算。 建议，尽量往 MQTT 方向靠。 至于第二个问题，应该跟 MQTT 和 TCP 无关。 |
 |
34
yazinnnn 2023-06-02 15:33:44 +08:00
如果你的 tcp 使用场景逐渐变得复杂和庞大, 你终究会把 tcp 包装成一个半吊子的 错误百出的 不完整的 mqtt 协议
虽说 mqtt 一般场景是使用 broker, 但是你自己根据 mqtt 编码协议去实现一个 C/S 模式的服务是很简单的 |
 |
35
zunceng 2023-06-02 15:36:12 +08:00
由于“reserve RPC”不是一个 well-known 的词， 我们可以定义一下是指服务器端主动调用客户端的函数或方法。在标准的 RPC 模型中，通常是客户端调用服务器上的函数或过程，但在某些情况下，服务器可能需要向客户端发送请求或回调，这就是反向 RPC 的应用场景。
HTTP 模式是 req/rep 不太适合 reserve RPC 的场景，如果有大量的服务端向客户端查询的业务 那肯定是消息队列更加合适，当然这种情况 用 websocket 或者 tcp 自己做一个 reverse RPC 肯定也是 OK 的 |
 |
36
kaneg 2023-06-02 22:29:36 +08:00 via iPhone
对于 mqtt ，设备的数量级上去之后就有优势了，要接受成千上万的设备的消息，如果自己写服务器，是很难保证可靠性和可用性的。术业有专攻，消息中间件可以专门负责接收，存储和转发消息，应用服务器也可以专注于自己的业务。所以，选不选 mqtt 就要看自己的的业务量是不是真的需要。业务量小的时候随便怎么搞都行。
|
 |
37
casper13 2023-06-03 10:59:41 +08:00
tcp 面对面中指，mqtt 张小龙 fxxk
|
Select Language