我已经使用WebSockets一段时间了，我选择使用Node服务器和WebSockets为大学的最后一年项目创建一个敏捷项目管理工具 . 我发现使用WebSockets提供的应用程序每秒可处理的请求数量增加了624％ .
然而，自从启动项目以来，我已经阅读了安全漏洞，并且一些浏览器默认选择禁用WebSockets .
This leads me to the question:
当WebSockets似乎在降低延迟和资源开销方面做得如此出色时，为什么要使用AJAX呢？AJAX比WebSockets做得更好吗？
7 回答
WebSockets并不是要取代AJAX，也不是Comet / long-poll的替代品（尽管有很多情况下这是有意义的） .
WebSockets的目的是在浏览器和服务器之间提供低延迟，双向，全双工和长时间运行的连接 . WebSockets为浏览器应用程序开辟了新的应用程序域，这些应用程序使用HTTP和AJAX（交互式游戏，动态媒体流，桥接到现有网络协议等）实际上是不可能的 .
但是，WebSockets和AJAX / Comet之间的目的肯定存在重叠 . 例如，当浏览器想要通知服务器事件（即推送）时，Comet技术和WebSockets肯定都是可行的选择 . 如果您的应用程序需要低延迟推送事件，那么这将是支持WebSockets的一个因素 . 另一方面，如果您需要与现有框架和已部署的技术（OAuth，RESTful API，代理，负载 balancer 器）共存，那么这将是支持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技术可用于给定的浏览器 .
Update ：iOS 6现在支持当前的HyBi / IETF 6455标准 .
快进到2017年12月，Websockets are supported by (practically) every browser和他们的使用非常普遍 .
但是，这并不意味着Websockets设法取代AJAX，至少不完全，尤其是当HTTP / 2适应正在增加时 .
简而言之，即使使用Websockets，AJAX仍然适用于大多数REST应用程序 . 但上帝在细节中，所以...：
AJAX用于民意调查？
The use of AJAX for polling (or long polling) is dying out（应该是），但由于两个很好的理由（主要针对较小的网络应用程序），它仍然在使用中：
对于许多开发人员来说，AJAX更容易编码，特别是在编写和设计后端时 .
使用HTTP / 2，消除了与AJAX（ Build 新连接）相关的最高成本，允许AJAX调用非常高效，特别是对于发布和上传数据 .
但是，Websocket push is far superior to AJAX（无需重新验证或重新发送标头，不需要"no data"往返等） . 这个was discussed多次 .
用于REST的AJAX？
更好地使用AJAX是REST API调用 . 此用法简化了代码库并防止Websocket连接阻塞（特别是在中等大小的数据上载中） .
有很多compelling reasons to prefer AJAX for REST API calls和数据上传：
AJAX API实际上是为REST API调用而设计的，非常适合 .
使用AJAX的REST调用和上传在客户端和后端都非常容易编码 .
随着数据有效负载的增加，Websocket连接可能会被阻止，除非对消息碎片/多路复用逻辑进行编码 .
如果在单个Websocket
send调用中执行上载，它可能会阻止Websocket流，直到上载完成 . 这会降低性能，尤其是在较慢的客户端上 .常见的设计使用通过Websockets传输的小型bidi消息，而REST和数据上传（客户端到服务器）利用AJAX的易用性来防止Websocket从阻塞 .
但是，在大型项目中，Websockets提供的灵活性以及代码复杂性和资源管理之间的 balancer 将有利于Websockets .
例如，基于Websocket的上传可以提供在连接被删除和重新 Build 后恢复大型上传的能力（还记得要上传的5GB电影吗？） .
通过对上传碎片逻辑进行编码，可以轻松恢复中断的上传（困难的部分就是对事物进行编码） .
HTTP / 2推送怎么样？
我应该补充一点，HTTP / 2推送功能不会（也可能不会）替换Websockets .
这之前已经是discussed here，但足以提到单个HTTP / 2连接服务于整个浏览器（所有选项卡/窗口），因此HTTP / 2推送的数据不具备替代Websocket直接将数据推送到的能力的能力 . 特定的浏览器选项卡/窗口 .
虽然Websockets非常适合小型双向数据通信，但AJAX仍然具有许多优势 - 特别是在考虑更大的有效载荷（上传等）时 .
和安全？
嗯，一般来说，为程序员提供的信任和控制越多，工具就越强大......而且越多的安全问题就越多 .
AJAX本质上会占上风，因为它的安全性内置于浏览器的代码中（有时候会有问题，但它仍然存在） .
另一方面，AJAX调用更容易受到“中间人”攻击，而Websockets安全问题通常是引入安全漏洞的应用程序代码中的错误（通常后端验证逻辑是您可以找到它们的地方） .
就个人而言，我并不觉得这有什么大不同，如果有什么我认为Websockets稍微好一点，特别是当你知道你在做什么的时候 .
我的拙见
恕我直言，我会使用Websockets进行REST API调用 . 大数据上传我会在可能的情况下分段并通过Websockets发送 .
轮询，恕我直言，应该是非法的，网络流量的成本是可怕的，Websocket推送很容易管理，即使是新开发人员 .
除了旧版浏览器的问题（包括IE9，因为从IE10开始支持WebSockets），网络中介还没有支持WebSockets的问题，包括透明代理，反向代理和负载均衡器 . 有些移动运营商完全阻止了WebSocket流量（即HTTP UPGRADE命令之后） .
随着时间的推移，WebSockets将得到越来越多的支持，但与此同时，您应始终使用基于HTTP的回退方法将数据发送到浏览器 .
我读到的关于websockets和安全性的大多数抱怨来自Web浏览器安全和防火墙安全工具的安全供应商 . 问题是他们不知道如何对websockets流量进行安全性分析，因为一旦完成从HTTP到websocket二进制协议的升级，数据包内容及其含义就是特定于应用程序（基于你编程的任何内容） . 这显然是这些公司的后勤噩梦，这些公司的生计基于对所有互联网流量进行分析和分类 . :)
WebSockets在旧版Web浏览器中不起作用，the ones that do support it通常具有不同的实现 . 's pretty much the only good reason why they aren' t一直用来代替AJAX .
Websockets是以近乎实时的方式处理长寿命双向数据流的绝佳选择，而REST非常适合偶尔进行通信 . 使用websockets是一项相当大的投资，因此对偶尔的连接来说太过分了 .
您可能会发现Websockets在高负载存在时表现更好，在某些情况下HTTP速度稍快，因为它可以利用缓存 . 将REST与Websockets进行比较就像将苹果与橙子进行比较 .
我们应该检查哪一个为我们的应用程序提供了更好的解决方案，哪一个最适合我们的用例获胜 .
HTTP和Websockets之间差异的一个示例，它是客户端大小的lib形式，可以处理Websocket endpoints ，如REST API和RESTful endpoints ，如客户端上的Websockets . https://github.com/mikedeshazer/sockrest此外，对于那些试图在客户端上使用websocket API的人，反之亦然 . libs / sockrest.js几乎清楚地表明了差异（或者说应该是这样） .