WebSocket真的应该由Web服务器处理吗？

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

---

所以我想知道的是：WebSocket的理想用途是什么？使用专用WebSocket服务器实现服务有意义吗？还是重新考虑在启用WebSocket的Web服务器上运行更好？

WebSocket协议设计时考虑了三种模式：

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

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

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

另一方面，如果您有一个通用的WebSocket服务，可以从许多不同的web站点使用（例如，您可以从WebSocket服务器获得连续的低延迟流量更新），那么您可能希望将WebSocket服务器与任何web服务器分开运行

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

有些约束可能会强制一个模型或另一个模型：

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

---

卡纳卡再次给出了精彩的答案。同样地，我喜欢在编写代码时遵循这个想法，我也喜欢在架构中遵循这个想法。在某些情况下，插件模型是不错的，但是当涉及到构建更大的应用程序时，或者如果消息速率达到某个级别，那么将web服务器（用于web应用程序功能）和WebSocket服务器（用于实时双向功能）分离是一个好主意。这是我对所有使用node.js和socket.io构建的应用程序的担忧。@leggetter，另一方面，如果web服务和WebSocket是同一个担忧的一部分，则应用程序将推动它们保持在一起。例如，如果初始页面加载是通过HTTPS进行的，然后使用通过WebSocket发送的数据实时更新页面的部分内容，并且新数据与最初通过HTTPS提供的内容密切相关（并且具有相同的访问控制等），那么将web服务和WebSocket作为一个内聚单元可能更有意义。同意。有些架构正朝着这个方向发展。一种可能是单页风格的应用程序。我还没有在这方面做过很多研究，但我认为这可能符合要求，尽管它们确实允许您交换底层的通信机制（socket.io/Pusher）。