博客

  • CBOR (Concise Binary Object Representation)

    CBOR,全称是简明二进制对象表示(Concise Binary Object Representation),是一种编码方式,常用于物联网(IoT)领域。它的设计目标是提供一种体积更小、更高效的二进制格式,类似于 JSON,但更适合资源受限的环境,如物联网设备。

    CBOR 的特点

    • 紧凑性:CBOR 的编码格式比 JSON 更紧凑,减少了数据传输的体积和存储空间。
    • 高效性:由于其二进制格式,解析和生成 CBOR 数据通常比处理文本格式的 JSON 更高效。
    • 自描述性:CBOR 编码的数据包含类型信息,解析时无需额外的模式(schema)。
    • 广泛支持:大部分编程语言都有相应的 CBOR 编码和解码库,可以方便地处理 CBOR 数据。

    CBOR 与 JSON 的比较

    特性CBORJSON
    格式二进制文本
    数据体积较小较大
    解析效率较高较低
    自描述性
    适用场景物联网、嵌入式系统、网络协议等Web 服务、配置文件等

    示例

    以下是一个简单的 JSON 对象及其对应的 CBOR 编码表示:

    JSON 示例:

    {
      "name": "Alice",
      "age": 30,
      "is_student": false
    }

    CBOR 编码表示:

    A3                                      # map(3)
      64                                    # text(4)
        6E616D65                            # "name"
      65                                    # text(5)
        416C696365                          # "Alice"
      63                                    # text(3)
        616765                              # "age"
      18 1E                                 # unsigned(30)
      6A                                    # text(10)
        69735F73747564656E74                # "is_student"
      F4                                    # false

    CBOR 库

    大部分编程语言都有相应的 CBOR 库,可以方便地进行编码和解码操作。以下是一些常见语言的 CBOR 库:

    • Python: cbor2, cbor
    • JavaScript: cbor
    • Go: github.com/fxamacker/cbor
    • Java: com.fasterxml.jackson.dataformat.cbor
    • C/C++: libcbor

    使用示例

    Python 示例:

    import cbor2
    
    # 编码 JSON 对象为 CBOR
    data = {
        "name": "Alice",
        "age": 30,
        "is_student": False
    }
    encoded = cbor2.dumps(data)
    print(encoded)  # 输出 CBOR 二进制数据
    
    # 解码 CBOR 为 JSON 对象
    decoded = cbor2.loads(encoded)
    print(decoded)  # 输出 {'name': 'Alice', 'age': 30, 'is_student': False}

    结论

    CBOR 提供了一种紧凑、高效的二进制编码格式,适用于资源受限的环境,如物联网设备。通过使用现有的 CBOR 库,可以轻松地在各种编程语言中进行 CBOR 数据的编码和解码操作,在提高数据传输效率的同时,保持了对各种复杂数据结构的支持。

  • Server-Sent Events(服务器发送事件)和WebSocket(网络套接字)

    Server-Sent Events(服务器发送事件)和WebSocket(网络套接字)是两种常用的实时通信协议,用于在应用程序中进行快速高效的数据传输。它们在实时体验方面的期望随着时间的推移不断增长,随着技术的改进和对可能性的理解而不断提高。本文将比较这两种流行的实时协议——WebSockets和Server-Sent Event(SSE)API。您将了解到它们各自的功能、优缺点以及何时使用它们。

    WebSockets是建立在设备的TCP/IP协议栈之上的一种轻量级传输层,提供了服务器和浏览器之间全双工、低延迟、事件驱动的连接。这对于实时应用程序非常理想,因为在初始的HTTP握手之后,单个WebSocket连接可以处理一个会话的所有消息,无需进一步的握手。当会话结束时,连接应该作为清理的一部分关闭。[2]

    WebSockets的优点包括:

    • 使用自定义的ws协议传输消息,工作在比HTTP更低的层级上。
    • 连接是双向的,因此WebSockets非常适用于需要从服务器读取和写入数据的应用程序,例如聊天应用程序或多人游戏。
    • 它可以复杂地从头开始实现WebSocket,但有许多库可用于简化此过程。
    • 基于事件的,无需轮询即可获取消息,有助于减少延迟。
    • RFC 6455 – WebSocket协议于2011年发布在IETF网站上,现在所有主流浏览器都支持它。[2]

    WebSockets的缺点包括:

    • 防火墙阻塞:一些企业防火墙在处理WebSockets时可能会出现问题(特别是SophosXG防火墙、WatchGuard和McAfee Web Gateway)。
    • 没有内置的重新连接支持:当WebSocket连接关闭时(例如由于网络问题),客户端不会尝试重新连接到服务器,这意味着您需要编写额外的代码来轮询服务器,在可用时重新建立连接。或者,您可以使用Server-Sent Events或具有重新连接支持的库,如Socket.IO。[2]

    Server-Sent Events(SSE)基于Server-Sent DOM Events(服务器发送的DOM事件)。浏览器可以使用EventSource接口订阅服务器生成的事件流,每当发生新事件时,就会接收到更新。EventSource接受来自特定URL的HTTP事件流连接,并在检索到可用数据时保持连接打开。Server-Sent Events是一种标准,描述了服务器在建立初始客户端连接后如何保持数据传输到客户端。它提供了一种内存高效的XHR流实现。与原始的XHR连接不同,原始XHR连接在连接断开之前会缓冲整个接收到的响应,而SSE连接可以在不累积所有消息的情况下丢弃已处理的消息。[3]

    Server-Sent Events的优点包括:

    • 可以在不支持它的浏览器中使用JavaScript进行polyfill。这对于向后兼容性非常有用,因为您可以依赖现有的实现而不必编写替代实现。
    • 内置的重新连接支持:Server-Sent Event连接在连接丢失后会重新建立连接,这意味着需要编写的代码更少,以实现基本的行为。
    • 不会被防火墙阻塞:SSE在进行数据包检查的企业防火墙中没有问题,这对于在企业环境中支持应用程序非常重要。

    Server-Sent Events(SSE)是一种基于服务器发送的DOM事件的协议。浏览器可以通过EventSource接口订阅由服务器生成的事件流,每当发生新事件时,浏览器就会接收到更新。SSE使用XHR流传输消息,连接是单向的,适用于只需要从服务器读取数据的应用程序,例如实时股票或新闻滚动。

    WebSocket是建立在设备的TCP/IP协议栈之上的一种轻量级传输层,提供了全双工、低延迟、事件驱动的服务器与浏览器之间的连接。WebSocket适用于需要从服务器读取和写入数据的应用程序,例如聊天应用程序或多人游戏。

    下面是Server-Sent Events和WebSocket的一些比较:

    Server-Sent Events:

    • 使用XHR流传输消息,连接是单向的。
    • 不需要复杂的实现,但相关的库较少。
    • 事件驱动,无需轮询即可拦截消息。
    • 支持自动重新连接,当连接丢失时会重新建立连接。
    • 可以通过JavaScript进行polyfill,以支持不支持SSE的浏览器。
    • 不受企业防火墙的阻塞,适用于企业环境。

    WebSocket:

    • 使用自定义的ws协议传输消息,工作在比HTTP更低的层级。
    • 连接是双向的,适用于需要从服务器读取和写入数据的应用程序。
    • 实现WebSocket可能较为复杂,但有许多库可用于简化实现。
    • 事件驱动,无需轮询即可拦截消息。
    • 不受企业防火墙的阻塞,但某些企业防火墙可能无法处理WebSocket。
    • 没有内置的重新连接支持,需要额外的代码来重新建立连接。

    根据具体的应用场景和需求,可以选择使用Server-Sent Events或WebSocket。如果只需要从服务器读取数据,并且需要自动重新连接的功能,可以选择Server-Sent Events。如果需要双向通信,并且需要更高级的功能和更大的灵活性,可以选择WebSocket。


    Learn more:

    1. Server-sent events vs. WebSockets – LogRocket Blog
    2. WebSockets vs Server-Sent Events: Key differences and which to use in 2024
    3. WebSocket vs Server-Sent Events: In-Depth Comparison, Use Cases, Pros & Cons, and Best Practices for Real-Time Communication
人生梦想 - 关注前沿的计算机技术 acejoy.com 🐾 步子哥の博客 🐾 背多分论坛 🐾 借一步网
Page Stats: PV: 1 | UV: 1
Last updated: 2025-06-20 11:03:42
沪ICP备2024052574号-1