node.js - WebSocket 数据消耗

Question

我目前正在研究一个涉及网络服务器和一些树莓的项目。 挑战基本上是在 Web 界面上查看覆盆子的“状态”。

Raspberrys 通过 GSM 连接(主要是 3G)连接到 Internet。 我在客户端和服务器上都使用 Node.js 进行开发，我想通过 socket.io 使用 websockets 来观察树莓派的连接状态(实际上，这更像是在观察树莓派上传数据的能力通过我的应用程序)，处理“连接”和“断开连接”事件。

对于这样的用例，始终有效的 websocket 连接是否可靠？ websocket 是否旨在(或可靠地)保持打开状态？ 由于这是一个难以测试的情况，有没有人知道永远活跃的 websocket 的数据消耗估计？ 如果我走错了路，有没有人通过另一种可靠的方式处理过这样的用例？

Answer 1

Would an always-alive WebSocket connection be reliable for such a use-case ? Are WebSocket designed-to (or reliable-for) staying opened ?

是的，WebSocket 旨在保持开放，是的，它对您的用例来说是可靠的，WebSocket 连接只是一个以帧为单位传输数据的 TCP 连接。

Since this is a hard-testable situation, does anyone know an data-consumption estimate for an always-alive websocket ?

正如我所写，WebSocket 连接中的数据是使用帧传输的，每个帧都有一个 header 和有效负载。从客户端发送到服务器的数据总是被屏蔽，并且像这样向每个帧添加 4 个字节(屏蔽键)。 header 的长度取决于负载长度:

1. <=125 字节负载的 2 字节 header
2. <=65535 字节负载的 4 字节 header
3. <=2^64-1 字节负载的 10 字节 header (很少使用)

基本框架协议(protocol):https://www.rfc-editor.org/rfc/rfc6455#section-5.2

为了保持连接打开，服务器在特定的超时时间(取决于实现，通常是 ~30 秒)发送 2-127 字节长的 ping 帧，通常是 2 字节(只有header，没有有效负载)，客户端用同样为 2-127 字节长的 pong 帧进行响应。