为什么在WebSockets可用时使用AJAX？
我已经使用了一段时间的WebSockets，我已经select使用Node服务器和WebSockets为我在大学的最后一年项目创build一个敏捷项目pipe理工具。 我发现使用WebSocket提供的应用程序可以处理的每秒请求数量增加了624％。
然而，自从开始我已经读过安全漏洞的项目，一些浏览器默认select禁用WebSocket。
这导致我的问题：
为什么在WebSockets似乎在降低延迟和资源开销方面做得如此出色时，使用AJAX有没有AJAX比WebSocket更好的方法？
WebSockets并不是要取代AJAX，并不是要取代Comet / long-poll（虽然在很多情况下这是有道理的）。
WebSockets的目的是在浏览器和服务器之间提供低延迟，双向，全双工和长期运行的连接。 WebSockets为浏览器应用程序打开了新的应用程序域，这些应用程序使用HTTP和AJAX（交互式游戏，dynamic媒体stream，桥接到现有networking协议等）是不太可能的。
但是，WebSockets和AJAX / Comet之间确实存在重叠的目的。 例如，当浏览器想要通知服务器事件（即推送）时，Comet技术和WebSockets肯定是可行的select。 如果您的应用程序需要低延迟的推送事件，那么这将是一个有利于WebSockets的因素。 另一方面，如果您需要与现有的框架和部署的技术（OAuth，RESTful API，代理，负载平衡器）共存，那么这将成为Comet技术（现在）的一个有利因素。
如果您不需要WebSockets提供的特定优势，那么坚持使用AJAX和Comet等现有技术可能是一个更好的主意，因为这允许您重用和整合现有的大量工具，技术，安全机制，知识库（即比stackoverflow更多的人知道比WebSockets的HTTP / Ajax / Comet），等等。
另一方面，如果你正在创build一个新的应用程序，在HTTP / Ajax / Comet的延迟和连接约束内工作不好，那么就考虑使用WebSocket。
此外，一些答案表明，WebSockets的缺点之一是服务器和浏览器支持受限/混合。 让我稍微分散一下。 尽pipeiOS（iPhone，iPad）仍然支持旧协议（Hixie），但大多数WebSockets服务器都支持Hixie和HyBi / IETF 6455版本。 大多数其他平台（如果他们还没有内置支持）可以通过web-socket-js （基于Flash的polyfill）获得WebSockets支持。 这涵盖了绝大多数networking用户。 此外，如果您使用Node作为服务器后端，那么请考虑使用包含web-socket-js的Socket.IO作为后备，如果连这个都不可用（或禁用），那么它将回退到使用任何Comet技术可用于给定的浏览器。
更新 ：iOS 6现在支持当前的HyBi / IETF 6455标准。
除了老版本的浏览器（包括IE9，因为从IE10开始支持WebSocket）的问题之外，networking中介还不支持WebSocket，包括透明代理，反向代理和负载均衡。 有一些移动运营商完全阻止了WebSocketstream量（也就是在HTTP UPGRADE命令之后）。
随着时间的推移，WebSockets将越来越受到支持，但同时你应该总是有一个基于HTTP的回退方法来向浏览器发送数据。
大多数抱怨我已经阅读过有关websockets和安全的知识，来自web浏览器安全和防火墙安全工具的安全厂商。 问题是他们不知道如何做websocketsstream量的安全分析，因为一旦它完成了从HTTP到websocket二进制协议的升级，数据包的内容及其含义就是应用程序特定的（根据你的程序）。 这显然是这些公司的物stream噩梦，这些公司的生计基于对所有互联网stream量进行分析和分类。 🙂
WebSocket在旧的Web浏览器中不起作用，而那些支持它的 WebSocket往往有不同的实现。 这几乎是为什么他们没有使用所有的时间来取代AJAX的唯一的好理由。
