但是，从启动项目，我已经阅读了安全漏洞，一些浏览器选择默认禁用WebSockets。
这导致我的问题：
为什么使用AJAX当WebSockets似乎做这样伟大的工作降低延迟和资源开销，有什么AJAX比WebSockets更好吗？
WebSockets的目的是在浏览器和服务器之间提供低延迟，双向，全双工和长时间运行的连接。 WebSockets为浏览器应用程序开辟了新的应用程序域，使用HTTP和AJAX(互动游戏，动态媒体流，桥接到现有网络协议等)是不可能的。
然而，WebSockets和AJAX / Comet之间的目的肯定有重叠。例如，当浏览器想要通知服务器事件(即推送)时，彗星技术和WebSockets当然是可行的选择。如果你的应用程序需要低延迟推送事件，这将是一个有利于WebSockets的因素。另一方面，如果您需要与现有框架和已部署的技术(OAuth，RESTful API，代理，负载平衡器)共存，那么这将是一个有利于Comet技术(现在)的因素。
如果你不需要WebSockets提供的特定好处，那么使用AJAX和Comet等现有技术可能是一个更好的主意，因为这允许您重用并集成到一个巨大的现有生态系统的工具，技术，安全机制，知识库(即在stackoverflow上的人员比WebSockets知道的HTTP / Ajax / Comet更多)等。
另一方面，如果您正在创建一个新的应用程序，只是在HTTP / Ajax / Comet的延迟和连接约束下无法正常工作，那么请考虑使用WebSockets。
此外，一些答案表明WebSockets的缺点之一是有限/混合服务器和浏览器支持。让我只是散了一点。虽然iOS(iPhone，iPad)仍然支持旧协议(Hixie)，但大多数WebSockets服务器都支持Hixie和HyBi / IETF 6455版本。大多数其他平台(如果他们还没有内置支持)可以通过web-socket-js(基于Flash的polyfill)获取WebSockets支持。这涵盖了绝大多数的网络用户。此外，如果您使用Node作为服务器后端，则考虑使用包含web-socket-js的Socket.IO作为后备，如果即使这不可用(或禁用)，那么它将回到使用可用的任何Comet技术给定的浏览器。
更新：iOS 6现在支持当前HyBi / IETF 6455标准。
