javascript 多个 websocket 连接
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/9247971/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Multiple websocket connections
提问by Christian
Is there any advantages of having two distinct websocket connections to the same server from the same client? To me this seems a bad design choice, but is there any reason why/where it should work out better?
从同一个客户端到同一个服务器有两个不同的 websocket 连接有什么好处吗?对我来说,这似乎是一个糟糕的设计选择,但是有什么理由为什么/哪里应该做得更好?
回答by kanaka
There are several reasons why you mightwant to do that but they probably aren't too common (at least not yet):
您可能想要这样做的原因有很多,但它们可能不太常见(至少现在还没有):
- You have both encrypted and unencrypted data that you are sending/receiving (e.g. some of the data is bulky but not sensitive).
- You have both streaming data and latency sensitive data: imagine an interactive game that occasionally has streamed video inside the game. You don't want large media streams to delay receipt of latency sensitive normal game messages.
- You have both textual (e.g. JSON control messages) and binary data (typed arrays or blobs) and don't want to bother with adding your own protocol layer to distinguish since WebSockets already does this for you.
- You have multiple WebSocket sub-protocols (the optional setting after the URI) that you support and the page wants to access more than one (each WebSocket connection is limited to a single sub-protocol).
- You have several different WebSocket services sitting behind the same web server and port. The way the client chooses per connection might depend on URI path, URI scheme (ws or wss), sub-protocol, or perhaps even the first message from client to server.
- 您有正在发送/接收的加密和未加密数据(例如,某些数据很大但不敏感)。
- 您同时拥有流数据和延迟敏感数据:想象一个互动游戏,它偶尔会在游戏中传输视频。您不希望大型媒体流延迟接收延迟敏感的正常游戏消息。
- 您同时拥有文本(例如 JSON 控制消息)和二进制数据(类型化数组或 blob),并且不想费心添加自己的协议层来区分,因为 WebSockets 已经为您做了这件事。
- 您有多个支持的 WebSocket 子协议(URI 后的可选设置),并且页面想要访问多个(每个 WebSocket 连接仅限于一个子协议)。
- 您有多个不同的 WebSocket 服务位于同一个 Web 服务器和端口后面。客户端为每个连接选择的方式可能取决于 URI 路径、URI 方案(ws 或 wss)、子协议,甚至可能是从客户端到服务器的第一条消息。
I'm sure there are other reasons but that's all I can think of off the top of my head.
我敢肯定还有其他原因,但这就是我能想到的全部。
回答by lex82
I found that it can make client logic much simpler when you are only subscribing to updates of certain objects being managed by the server. Instead of devising a custom subscription protocol for a single channel, you can just open a socket for each element.
我发现当您只订阅服务器管理的某些对象的更新时,它可以使客户端逻辑更加简单。无需为单个频道设计自定义订阅协议,您只需为每个元素打开一个套接字即可。
Let's say you obtained a collection of elements via a REST API at
假设您通过 REST API 在
http://myserver/api/some-elements
You could subscribe to updates of a single element using a socket url like this:
您可以使用这样的套接字 url 订阅单个元素的更新:
ws://myserver/api/some-elements/42/updates
Of course one can argue that this doesn't scale for complex pages. However, for small and simple appications it might make your life a lot easier.
当然,有人会争辩说这不适用于复杂页面。但是,对于小而简单的应用程序,它可能会让您的生活更轻松。