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
|