ajax - 为什么在 WebSockets 可用时使用 AJAX？

Question

我已经使用 WebSockets 有一段时间了，我选择使用 Node 服务器和 WebSockets 为我在大学的最后一年项目创建一个敏捷项目管理工具。我发现使用 WebSockets 使我的应用程序每秒可以处理的请求数量增加了 624%。

然而，自从开始这个项目以来，我已经了解到安全漏洞，并且一些浏览器选择默认禁用 WebSockets..

这引出了我的问题:

当 WebSockets 似乎在降低延迟和资源开销方面做得如此出色时，为什么还要使用 AJAX，AJAX 有什么比 WebSockets 做得更好的吗？

Answer 1

WebSockets 并非旨在取代 AJAX，严格来说甚至不能替代 Comet/long-poll(尽管在很多情况下这是有意义的)。

WebSockets 的目的是在浏览器和服务器之间提供低延迟、双向、全双工和长时间运行的连接。 WebSockets 为浏览器应用程序开辟了新的应用程序域，而这些应用程序使用 HTTP 和 AJAX(交互式游戏、动态媒体流、桥接现有网络协议(protocol)等)是不可能实现的。

但是，WebSockets 和 AJAX/Comet 之间的目的肯定有重叠。例如，当浏览器想要收到服务器事件的通知(即推送)时，Comet 技术和 WebSockets 无疑都是可行的选择。如果您的应用程序需要低延迟推送事件，那么这将是支持 WebSockets 的一个因素。另一方面，如果您需要与现有框架和部署的技术(OAuth、RESTful API、代理、负载平衡器)共存，那么这将是支持 Comet 技术的一个因素(目前)。

如果您不需要 WebSockets 提供的特定好处，那么坚持使用 AJAX 和 Comet 等现有技术可能是一个更好的主意，因为这允许您重用现有的庞大工具、技术生态系统并与之集成、安全机制、知识库(即 stackoverflow 上知道 HTTP/Ajax/Comet 的人比 WebSockets 多得多)等。

另一方面，如果您要创建的新应用程序在 HTTP/Ajax/Comet 的延迟和连接限制下无法正常工作，那么请考虑使用 WebSockets。

此外，一些答案表明 WebSockets 的缺点之一是有限/混合的服务器和浏览器支持。让我稍微分散一下。虽然 iOS(iPhone、iPad)仍然支持旧协议(protocol)(Hixie)，但大多数 WebSockets 服务器同时支持 Hixie 和 HyBi/IETF 6455版本。大多数其他平台(如果它们还没有内置支持)可以通过 web-socket-js 获得 WebSockets 支持。 (基于 Flash 的 polyfill)。这涵盖了绝大多数网络用户。此外，如果您使用 Node 作为服务器后端，请考虑使用 Socket.IO其中包括 web-socket-js 作为后备，如果即使它不可用(或禁用)，那么它将回退到使用给定浏览器可用的任何 Comet 技术。

更新:iOS 6 现在支持当前的 HyBi/IETF 6455 标准。