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