与标准 HTTP 相比，WebSockets 如何扩展？答案

【问题标题】：How does WebSockets scale compared to standard HTTP?与标准 HTTP 相比，WebSockets 如何扩展？
【发布时间】：2013-01-10 12:41:12
【问题描述】：

与仅通过 AJAX 提供信息相比，使用 TCP 编程的站点（即站点上的某人连接到服务器并通过 TCP 交换信息）如何扩展？假设交换的信息是一样的。

试图澄清：我特别问的是规模：我已经读过，与仅静态提供信息相比，保持数千个 TCP 连接需要资源（哪个？）。我想知道这是否正确。

【问题讨论】：

你的问题有点泛滥。您提到了 TCP、WebSocket、AJAX 和 HTTP。您到底想与什么进行比较？
据我所知，WebSocket 是 TCP 上的一个薄层，而 Ajax 只是发出 HTTP 请求的一种方式。
最大的问题是：服务器主要需要向客户端推送事物的通知还是客户端主要需要询问服务器问题？在前一种情况下，WebSockets 要好得多。在后一种情况下，这无关紧要，减少 TCP 连接可以让服务器上的生活更轻松。
客户端确实需要定期与服务器交换少量信息；比如说，每个客户每分钟 3 条 3 字长的消息。这对每个客户的要求并不高； HTTP 请求可以正常工作。但是有人告诉我保持 TCP 连接要求很高。大约 1000 个之后就会开始出现问题，而提供 1000 个左右的静态文件就可以了。这就是我问的原因。这些信息正确吗？
WebSocket 以 HTTP 连接开始并升级为 websocket，这意味着它允许双向通信。您是否在问在标准 TCP 连接上使用 WebSockets 是否具有可扩展性的好处？需要保持相同数量的连接。

标签： javascript node.js http tcp websocket

【解决方案1】：

WebSockets 是一种允许服务器向客户端推送通知的技术。另一方面，AJAX 是一种拉取技术，这意味着客户端正在向服务器发送请求。

因此，例如，如果您有一个应用程序需要定期从服务器接收通知并更新其 UI，那么 WebSocket 更适合并且更好。使用 AJAX，您将不得不定期向服务器发送请求，以查看服务器上的某些状态是否发生了变化。使用 WebSockets，服务器会通知客户端服务器上发生的某些事件。这将在单个请求中发生。

所以我想这真的取决于您正在开发的应用程序的类型，但是 WebSockets 和 AJAX 是解决不同类型问题的两种完全不同的技术。选择哪一个取决于您的情况。

【讨论】：

WebSockets 和 AJAX 是不同的，是的。但它们通常用于解决我认为相同的问题。
AJAX 确实可以解决 WebSockets 设计的问题。但它以一种非常无效的方式解决了它。这就是创建 WebSockets 的原因 :-) 所以我不会说如果你拥有这两种技术，你就可以用它们来解决同样的问题。
不要将 XMLHttpRequest 与 AJAX 混淆。 AJAX 是编程技术的通用术语，其中浏览器与服务器交互同时避免页面刷新。这种类型的编程在 XMLHttpRequest 之前就已经存在。 WebSockets 无疑符合 AJAX 风格的编程。（我从不喜欢“AJAX”这个词，但这个词一直存在。它比“Web 2.0”好，但不如“远程脚本”）

【解决方案2】：

Websockets 不是一对一的 AJAX；它们提供了截然不同的功能。 Websockets 提供了向客户端“推送”数据的能力。 AJAX 通过“推送”数据并返回响应来工作。

WebSockets 的目的是在浏览器和服务器之间提供低延迟、双向、全双工和长时间运行的连接。 WebSockets 为以前使用 HTTP 或 AJAX 不可用的浏览器应用程序开辟了可能性。

但是，WebSockets 和 AJAX 之间的目的肯定有重叠。例如，当浏览器想要通知服务器事件（即推送）时，AJAX 或 WebSocket 都是可行的选择。如果您的应用程序需要低延迟推送事件，那么这将是支持 WebSockets 的一个因素，它在这种情况下肯定会更好地扩展。另一方面，如果您需要使用现有框架和已部署的技术（OAuth、RESTful API、代理等），那么 AJAX 更可取。

如果您不需要 WebSockets 提供的特定好处，那么坚持使用 AJAX 等现有技术可能是一个更好的主意，因为这允许您重用现有的工具、技术、安全机制生态系统并与之集成，在过去 7 年中开发的知识库。

但总体而言，Websockets 的性能将优于 AJAX。

【讨论】：

这都是真的，但并没有真正解决我的问题：我问的是规模：我已经读过保持数千个 TCP 连接是资源（哪个？）要求，与仅提供服务相比静态信息。我想知道这是否正确。

【解决方案3】：

我认为 WebSockets 和标准 TCP 连接之间的可扩展性没有任何区别。 WebSocket 是从静态单向管道到双工管道的升级。物理资源完全相同。

WebSockets 的主要优点是它们在 80 端口上运行，因此它避免了大多数防火墙问题，但您必须首先通过标准 HTTP 进行连接。

【讨论】：

你可以在 80 号锅上运行任何你想要的东西。有很多防火墙和类似的设备在做深度数据包检查，在 Web 套接字上咳嗽，就像它们在 80 号锅上运行的其他协议一样。幸运的是，随着时代的发展，这种情况正在慢慢改变。我想说的是，避免防火墙问题并不是“主要优势”，对于大多数应用程序来说，也不应该是决定使用什么的重要因素。

【解决方案4】：

这是一个很好的页面，它清楚地展示了 WebSocket API 与 Ajax 长轮询（尤其是大规模）相比的优势：http://www.websocket.org/quantum.html

这基本上归结为这样一个事实，即一旦建立了初始 HTTP 握手，数据可以更快地来回传输，因为标头开销大大减少（这就是大多数人所说的双向通信）。

顺便说一句，如果您只需要能够定期从服务器推送数据，但您不需要发出很多客户端发起的请求，那么可以使用 HTML5 server-sent events 和偶尔来自的 Ajax 请求客户端可能正是您所需要的，并且比 WebSocket API 更容易实现。

【讨论】：