WebSockets 真的要由 Web 服务器处理吗？答案

【问题标题】：Are WebSockets really meant to be handled by Web servers?WebSockets 真的要由 Web 服务器处理吗？
【发布时间】：2012-01-03 03:29:17
【问题描述】：

WebSocket 标准尚未获得批准，但从草案来看，该技术似乎旨在在 Web 服务器中实现。 pywebsocket 实现了一个 WebSocket 服务器，可以专用或作为 Apache 插件加载。

所以我想知道的是：WebSockets 的理想用途是什么？使用专用的 WebSocket 服务器来实现服务是否有意义，或者重新考虑它以在支持 WebSocket 的 Web 服务器之上运行是否更好？

【问题讨论】：

标签： websocket

【解决方案1】：

WebSocket 协议在设计时考虑了三个模型：

完全独立于任何 Web 服务器运行的 WebSocket 服务器。
WebSocket 服务器与 Web 服务器分开运行，但流量从 Web 服务器代理到 WebSocket 服务器（允许 WebSocket 和 HTTP 流量共存于同一端口上）
在 Web 服务器中作为插件运行的 WebSocket 服务器。

您选择的模型实际上取决于您尝试构建的应用程序以及可能限制您选择的其他一些约束。

例如，如果您的应用程序将由单个 Web 服务器提供服务，并且 WebSocket 连接将始终返回到同一台服务器，那么将 WebSocket 服务器作为插件/模块运行可能是有意义的网络服务器。

另一方面，如果您有一个可从许多不同网站使用的通用 WebSocket 服务（例如，您可以从 WebSocket 服务器获得持续的低延迟流量更新），那么您可能想要运行 WebSocket服务器独立于任何 Web 服务器。

基本上，您的 WebSocket 服务和您的 Web 服务之间的集成越紧密，您就越有可能希望在同一个端口上同时运行它们。

有一些约束可能会强制使用一种或另一种模型：

如果您控制服务器而不是传入防火墙规则，那么您可能别无选择，只能在与 HTTP/HTTPS 服务器相同的端口（例如 80 和 443）上运行 WebSocket 服务器。在这种情况下，您将不得不使用 Web 服务器插件或代理到真正的 WebSocket 服务器。
另一方面，如果您在运行 WebSocket 服务器的服务器上没有超级用户权限，那么您可能无法使用端口 80 和 443（低于 1024 通常是特权端口范围)，在这种情况下，是否在同一个端口上运行 HTTP/S 和 WebSocket 服务器并不重要。
如果您在 Web 服务器中有基于 cookie 的身份验证（例如 OAuth），并且您希望将其重新用于 WebSocket 连接，那么您可能希望将它们一起运行（紧密集成的特殊情况）。李>

【讨论】：

又是一个很棒的答案@kanaka。同样，我在编写代码时喜欢separation of concerns 的想法，我也喜欢将这个想法贯彻到架构中。在某些情况下，插件模型很好，但是当涉及构建更大的应用程序时，或者如果消息速率达到一定水平，将 Web 服务器分开，用于 Web 应用程序功能，和 WebSocket 服务器，用于实时双向功能，恕我直言，这是个好主意。这是我对使用 node.js 和 socket.io 构建的所有应用程序的担忧。
@leggetter，另一方面，如果 Web 服务和 WebSocket 是同一关注点的一部分，那么 principle of functional cohesion 适用并将推动将它们保持在一起。例如，如果初始页面加载是通过 HTTPS 进行的，然后使用通过 WebSockets 发送的数据实时更新页面的某些部分，并且新数据与最初提供的数据密切相关（并且具有相同的访问控制等）通过 HTTPS，那么将 Web 服务和 WebSockets 作为一个有凝聚力的单元可能更有意义。
同意。一些架构正朝着这个方向发展。一个可能是单页样式的应用程序。我还没有在这方面做很多研究，但我认为SocketStream 可能符合要求，尽管它们确实让你换掉底层通信机制（socket.io/Pusher）。