V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
unt
V2EX  ›  程序员

求问 MQTT 和 TCP 透传优劣

  •  
  •   unt · 2023-06-02 10:57:31 +08:00 · 4029 次点击
    这是一个创建于 524 天前的主题,其中的信息可能已经有所发展或是发生改变。
    目前本公司物联网平台对接了 10 多家设备,有些是采用 16 进制字节码 TCP 透传,有些是 MQTT 对接(已语义化解析)。MQTT 的优势自然不用多说,那请问它的劣势是什么,传统 TCP 透传的优势又是什么。


    另外请问,采用 MQTT 的话,是不是数据解析就直接做进设备里去了,而不会说是传输的实际上还是字节码,另外服务端再加一层数据解析层。
    37 条回复    2023-06-03 10:59:41 +08:00
    koloonps
        1
    koloonps  
       2023-06-02 10:59:53 +08:00
    设备不一定支持 MQTT
    "采用 MQTT 的话,是不是数据解析就直接做进设备里去了,而不会说是传输的实际上还是字节码,另外服务端再加一层数据解析层" 这个和 mqtt 没有关系吧?
    unt
        2
    unt  
    OP
       2023-06-02 11:02:42 +08:00
    @koloonps #1 我知道,MQTT 只是一种应用层协议,实际传输的东西它是不管的。

    我是想问一般公司对接物联网设备是怎么对接的,采用怎样的开发对接模式
    flyqie
        3
    flyqie  
       2023-06-02 11:12:37 +08:00 via Android
    非相关行业人员哈。

    自己在用的物联网设备好像基本都是 mqtt ,tcp 比较少。

    蹲个大佬。
    flyqie
        4
    flyqie  
       2023-06-02 11:14:23 +08:00 via Android
    @flyqie #3

    tcp 指的是像楼主描述那样的直接基于裸 tcp
    koloonps
        5
    koloonps  
       2023-06-02 11:15:39 +08:00
    @unt 看什么行业吧,收款语音播报这一些基本都是 mqtt.复杂一点的大多都是 hex.你可以参考下 JT808/JT809
    lopssh
        6
    lopssh  
       2023-06-02 11:17:14 +08:00
    这里的"透传"怎么理解?
    koloonps
        7
    koloonps  
       2023-06-02 11:20:42 +08:00
    @lopssh 应该是 DTU,将串口数据打包发送到服务器
    unt
        8
    unt  
    OP
       2023-06-02 11:27:07 +08:00
    @lopssh #6 不做任何解析,直接通过 TCP 给设备发规定好的字节码,设备返回的也是字节码
    Baloneo
        9
    Baloneo  
       2023-06-02 11:32:45 +08:00
    设备协议有很多 Modbus IEC DLT ,什么电表水表这些基本不支持 MQTT 的 就需要网关转发成 MQTT 报文或者自己写程序解析 一般都是通过网关转发 MQTT 由网关解析成设备需要的协议 设备本身支持 MQTT 的另说 设备直接实现 TCP 直连 /透传会比设备里写 MQTT 代码容易
    duke807
        10
    duke807  
       2023-06-02 11:33:55 +08:00
    mqtt 用不了 cloudflare 之类的免费 cdn
    gam2046
        11
    gam2046  
       2023-06-02 11:35:49 +08:00
    MQTT 主要是帮你做了很多可靠性的工作,比如确保消息送达,确保消息有且仅有收到一次,设备暂离时消息会在设备连线时重发、消息的广播等。在满足这些的情况下,同时 MQTT 对于带宽要求也很小(协议开销小)

    如果你的环境下,本身网络条件是没有可靠性问题,那我觉得 TCP 直接上也可以。
    mlhorizon
        12
    mlhorizon  
       2023-06-02 11:36:32 +08:00
    TCP 透传的优势是现场设备简单,便宜,少配置。
    这些就是 MQTT 的劣势。
    flyqie
        13
    flyqie  
       2023-06-02 11:37:17 +08:00 via Android
    @duke807 #10

    裸 tcp 也用不了吧。。

    cf 好像只支持 websocket 和 http 及其 tls 方式?
    cloudzhou
        14
    cloudzhou  
       2023-06-02 11:38:59 +08:00
    mqtt 主要是标准化,换个服务商继续还可以用
    duke807
        15
    duke807  
       2023-06-02 11:39:59 +08:00
    @flyqie 是的,所以目前很多项目用 http / https
    flyqie
        16
    flyqie  
       2023-06-02 11:41:16 +08:00 via Android
    @duke807 #15

    那长链接用啥? websocket ?

    倒是见过有厂商这么玩的,不过他们没用 cdn 。。
    masterclock
        17
    masterclock  
       2023-06-02 11:42:09 +08:00
    使用所谓 tcp 透传的,通常最终都会发明一套 mqtt

    mqtt 上的数据,常见 json ,自定义文本格式,也有玩点 cbor 啥的,但二进制也不少见
    opengps
        18
    opengps  
       2023-06-02 11:42:53 +08:00
    tcp 是自定义规则,就好比底层语言一样很基础
    mqtt 没怎么实际使用过,个人感觉只是规范了通信规则,通用的场景
    bfdh
        19
    bfdh  
       2023-06-02 11:49:32 +08:00
    MQTT 更耗资源,在服务端尤其明显,带机量、性能显著低于 tcp 。
    byte10
        20
    byte10  
       2023-06-02 11:49:54 +08:00
    @lopssh MQTT 是一个中间件,业务系统会去订阅这些消息的。如果透传,那就 IOT 设备直接推送消息到业务系统中了
    yolee599
        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 字节。
    wentx
        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 协议的限制,而是设备端实现的选择。
    tramm
        23
    tramm  
       2023-06-02 12:31:30 +08:00
    我们是用的 JTT808 魔改的,结构按照他的,有的消息 ID 就跟他们的冲突了...
    不过我们跟其他平台间有的就用 MQTT 传的.
    优劣势的话么,我觉得自定义 TCP 协议的话,可操作性比较大吧. MQTT 依赖于 Broker 的实现(应该没人会想着自己实现一套吧). EMQX 的 Broker 不知道咋设置, 反正数据多的话, 且 Qos=2 时, 感觉就不行了.
    对我们来说,最大的区别就是 MQTT 系统架构复杂度低, 集成也简单; 自定义 TCP 协议, 不可替代性强, 培训班不学这个(哈哈哈, :P)
    gujigujij
        24
    gujigujij  
       2023-06-02 12:47:38 +08:00
    tcp 透传的话,读取程序在服务器, 维护和调试比较方便。
    unt
        25
    unt  
    OP
       2023-06-02 13:07:26 +08:00
    @wentx #22 对对对,我要的这种回答,感谢
    unt
        26
    unt  
    OP
       2023-06-02 13:10:40 +08:00
    @yolee599 #21 感谢
    unt
        27
    unt  
    OP
       2023-06-02 13:13:08 +08:00
    每一层都已认真阅读,谢谢各位的解答
    winv87
        28
    winv87  
       2023-06-02 13:16:13 +08:00
    都支持,自家监控系统的直接透传。 设备需要对接第三方监控,用 MQTT 比较通用。
    jiny28
        29
    jiny28  
       2023-06-02 13:23:09 +08:00
    mqtt 可以解决设备没固定 ip 的情况,比如 4G 网卡。
    aguesuka
        30
    aguesuka  
       2023-06-02 14:17:52 +08:00
    首先透传是什么意思, 比如电表和服务器不直接通信, 而是电表通过电线载波通信到集中器, 再由集中器通信到应用程序. 注意载波通信是利用输电线通信的. 那么电表发给集中器的报文如果直接发送给服务器, 就是透传. 而集中器中途做处理就不是透传.

    抛开集中器的问题 mqtt 的缺点
    1. mqtt 是发布订阅模式, 但是业务模型绝大部分是 rpc 模型.
    2. mqtt 提供的功能看起来很美好, 比如一条消息只发一次, 最少发一次, 实际上没人敢依赖这个特性, 还是要实现幂等, 假设消息丢失.
    deepshe
        31
    deepshe  
       2023-06-02 14:35:02 +08:00
    mqtt 也要芯片厂商能支持吧,比如芯片厂做好 sdk 包,不然用不同的芯片就需要公司针对不同芯片实现 mqtt 协议
    tcp 的话直接用自己的协议就好了
    wentx
        32
    wentx  
       2023-06-02 14:40:51 +08:00
    @unt #25 不客气,毕竟这是 GPT4 给的答案..
    AnroZ
        33
    AnroZ  
       2023-06-02 15:21:34 +08:00
    MQTT 的协议层级比 TCP 高,你的问题可类比:TCP 和 HTTP 的优劣势。
    但总的来说,MQTT 定义的行为非常适合物联网场景。用 TCP 的话还要去额外实现类似 MQTT 功能,对于平台方来说,不是特别划算。
    建议,尽量往 MQTT 方向靠。

    至于第二个问题,应该跟 MQTT 和 TCP 无关。
    yazinnnn
        34
    yazinnnn  
       2023-06-02 15:33:44 +08:00
    如果你的 tcp 使用场景逐渐变得复杂和庞大, 你终究会把 tcp 包装成一个半吊子的 错误百出的 不完整的 mqtt 协议

    虽说 mqtt 一般场景是使用 broker, 但是你自己根据 mqtt 编码协议去实现一个 C/S 模式的服务是很简单的
    zunceng
        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 的
    kaneg
        36
    kaneg  
       2023-06-02 22:29:36 +08:00 via iPhone
    对于 mqtt ,设备的数量级上去之后就有优势了,要接受成千上万的设备的消息,如果自己写服务器,是很难保证可靠性和可用性的。术业有专攻,消息中间件可以专门负责接收,存储和转发消息,应用服务器也可以专注于自己的业务。所以,选不选 mqtt 就要看自己的的业务量是不是真的需要。业务量小的时候随便怎么搞都行。
    casper13
        37
    casper13  
       2023-06-03 10:59:41 +08:00
    tcp 面对面中指,mqtt 张小龙 fxxk
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5362 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 08:34 · PVG 16:34 · LAX 00:34 · JFK 03:34
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.