之前有人问过类似的问题，他们都得出了 AJAX 不会过时的结论。但是ajax在哪些方面比websockets好呢？
使用 socket.io，很容易退回到 flash 或 long polling，因此浏览器兼容性似乎不是问题。
Websockets 是双向的。 ajax 会发出异步请求，websocket 客户端会向服务器发送消息。 POST/GET 参数可以用 JSON 编码。
那么使用 100% websockets 有什么问题呢？如果每个访问者都与服务器保持持久的 websocket 连接，那会比在整个访问会话中发出一些 ajax 请求更浪费吗？
【问题讨论】：
标签： ajax node.js websocket socket.io
我认为这会更浪费。对于每个连接的客户端，您都需要服务器上与该客户端配对的某种对象/函数/代码/任何内容。套接字处理程序或文件描述符，或者您的服务器已设置为处理连接。
使用 AJAX，您不需要服务器端资源到客户端的 1:1 映射。与服务器端资源相比，您的客户端数量可以更少地扩展。即使是 node.js 也有它可以处理和保持打开的连接数的限制。
要考虑的另一件事是某些 AJAX 响应也可以被缓存。随着您的扩展，您可以添加 HTTP 缓存以帮助减少频繁 AJAX 请求的负载。
【讨论】：
简答题
对于客户端和服务器来说，保持 websocket 处于活动状态是有成本的，Ajax 是否只会产生一次成本，这取决于你用它做什么。
长答案
Websockets 经常被误解，因为整个“嘿，使用 Ajax，就可以了！”。不，Websockets 不能替代 Ajax。它们可以潜在地应用于相同的领域，但在某些情况下使用 Websocket 是荒谬的。
让我们举个简单的例子：一个动态页面，它在页面加载到客户端后加载数据。很简单，进行 Ajax 调用。我们只需要一个方向，从服务器到客户端。客户端将请求这些数据，服务器将它们发送给客户端，完成。你为什么要为这样的任务实现 websockets？你不需要一直打开你的连接，你不需要客户端不断地询问服务器，你不需要服务器通知客户端。连接将保持打开状态，这将浪费资源，因为要保持连接打开，您需要不断检查它。
现在对于聊天应用程序来说，情况完全不同了。您需要服务器通知您的客户端，而不是强制客户端每隔 x 秒或毫秒询问服务器是否有新内容。这没有任何意义。
为了更好地理解，将其视为两个人。两者之一是服务器，一个是客户端。 Ajax 就像发送一封信。客户端发送一封信，服务器回复另一封信。事实是，对于聊天应用程序，对话是这样的：
“嘿服务器，有东西给我吗？
- 没有。
- 嘿服务器，有东西给我吗？
- 没有。
- 嘿服务器，有东西给我吗？
- 是的，就在这里。”
如果客户端从未请求过答复，服务器实际上无法向客户端发送一封信。这是对资源的巨大浪费。因为对于每一个Ajax请求，即使被缓存了，也需要在服务器端进行操作。
现在是我之前讨论的使用 Ajax 加载数据的情况。想象一下客户端正在与服务器通话。保持连接处于活动状态是有代价的。它需要电费，您必须向运营商付款。现在，如果您只想让那个人告诉您三个字，为什么还要打电话给某人并让他保持一个小时的电话？发一封该死的信。
总之，Websockets 并不是 Ajax 的完全替代品！
有时您会需要 Ajax，而Websocket 的使用是荒谬的。
编辑：SSE 案例
该技术的使用不是很广泛，但它可能很有用。顾名思义，服务器发送事件是从服务器到客户端的单向推送。客户端不请求任何东西，服务器只是发送数据。
简而言之：
- 来自客户端的单向：Ajax
- 来自服务器的单向：SSE
- 双向：Websockets
【讨论】：
我个人认为websockets会越来越多地用在web应用中，而不是AJAX。它们不太适合缓存和 SEO 更受关注的网站，但它们会为 web 应用创造奇迹。
DNode 和 socketstream 等项目有助于消除复杂性并启用简单的 RPC 样式编码。这意味着您的客户端代码只需调用服务器上的一个函数，将任何数据传递给它想要的函数。服务器可以调用客户端上的函数并将数据传递给它。您无需关心 TCP 的细节。
此外，AJAX 调用有很多开销。例如，需要建立一个连接，并且每次请求都会传递 HTTP 标头（cookie 等）。 Websockets 消除了大部分。有人说websockets比较浪费，也许他们是对的。但我不相信差异真的那么大。
我详细回答了另一个相关问题，包括许多相关资源的链接。你可以去看看：
【讨论】：
我认为基于 websocket 的框架迟早会开始出现，不仅用于编写实时聊天（如 web 应用程序的一部分），还可以作为独立的 web 框架。一旦创建了永久连接，它就可以用于接收各种东西，包括现在通过 AJAX 请求提供服务的 Web 应用程序的 UI 部分。这种方法可能会在某种程度上损害 SEO，尽管它可以减少由包含冗余 HTTP 标头的异步请求产生的流量和负载。
但是我怀疑 websocket 会取代或危及 AJAX，因为在许多情况下永久连接是不必要或不需要的。例如，使用（一次性）基于 REST 的单一用途服务的 mashup 应用程序不需要与客户端永久连接。
【讨论】：
这并没有什么“错误”。
唯一的区别主要是可读性。 Ajax 的主要优势在于它允许您快速开发，因为大部分功能都是为您编写的。
每次打开套接字时都不必重新发明轮子，这是一个很大的优势。
【讨论】：
WS:// 连接的开销远低于“AJAX”请求。
【讨论】：
正如其他人所说，在您不需要服务器到客户端通知或客户端到服务器请求发生频率较低的某些情况下，保持连接打开可能有点过头了。
但另一个缺点是 websockets 是一个低级协议，一旦执行初始握手，就不会为 TCP 提供额外的功能。因此，在通过 websocket 实现请求-响应范例时，您可能会错过 HTTP（一个非常成熟和扩展的协议系列）提供的功能，例如缓存（客户端和共享缓存）、验证（条件请求） 、安全性和幂等性（对代理行为的影响）、范围请求、内容类型、状态码……
也就是说，减少消息大小是有代价的。
所以我的选择是用于请求响应的 AJAX、用于服务器推送和高频低延迟消息的 websockets
【讨论】：
如果您希望打开与服务器的连接，并且如果可以持续轮询服务器，那么请使用套接字，否则您最好使用 ajax。
简单的类比： Ajax 向服务器提出问题（请求），服务器对这些问题给出答案（响应）。现在，如果您想提出连续的问题，那么 ajax 将无法工作，它的开销很大，两端都需要资源。
【讨论】：