以前也有类似的问题，他们都得出了AJAX不会过时的结论。但是，ajax比websockets更好？使用websocket/socket.io在哪里Ajax会做的缺点是什么？
使用socket.io，很容易回退到闪存或长轮询，因此浏览器兼容性似乎不成问题。
Websockets是双向的。如果Ajax会发出异步请求，websocket客户端会向服务器发送消息。 POST/GET参数可以用JSON编码。
那么使用100％websockets有什么问题？如果每个访问者都保持与服务器的持久websocket连接，那么比在整个访问会话中提出几个ajax请求会更浪费？
关于它没有什么“错误”。
唯一的区别是大多数可读性。 Ajax的主要优点是它可以让您快速开发，因为大部分功能都是为您编写的。
每次打开套接字时都不必重新发明轮子，这是一个很大的优势。
我认为基于websocket的框架早晚会开始弹出，不仅仅是为了编写像web应用程序部分那样的实时聊天，而且也是作为独立的web框架。一旦创建永久连接，它就可以用于接收各种东西，包括现在通过AJAX请求提供的Web应用程序的UI部分。这种方法可能会以某种方式伤害SEO，尽管它可以减少包含冗余HTTP头的异步请求所产生的流量和负载量。
但是我怀疑websockets会替换或危及AJAX，因为有很多情况下永久连接是不必要或不需要的。例如，使用（一次性）基于REST的单一服务的混搭应用程序不需要与客户端永久连接。
我认为这会更浪费。对于每个连接的客户端，您需要某种对象/功能/代码/服务器上与该客户端配对的任何内容。套接字处理程序或文件描述符，或者您的服务器设置为处理连接。
使用AJAX，您不需要服务器端资源到客户端的1：1映射。您的＃个客户端可以比您的服务器端资源减少依赖性。即使node.js也有限制它可以处理并保持打开状态的连接数。
要考虑的另一件事是某些AJAX响应也可以被缓存。随着您向上扩展，您可以添加HTTP缓存来帮助减少频繁的AJAX请求的负载。
就我个人而言，我认为websockets将会越来越多地应用于web应用程序而不是AJAX。他们不太适合网站缓存和搜索引擎优化更受关注，但他们会为webapps创造奇迹。
DNode和socketstream等项目有助于消除复杂性并启用简单的RPC式编码。这意味着你的客户端代码只是在服务器上调用一个函数，将任何数据传递给它想要的函数。服务器可以在客户端调用一个函数并传递数据。你不需要关心TCP的基本问题。
此外，AJAX调用有很多开销。例如，需要建立一个连接并在每个请求中都传递HTTP标头（cookie等）。 Websockets消除了很多。有人说websockets更浪费，也许他们是对的。但我不相信这种差异真的很大。
我回答了另外一个相关的问题，包括很多相关资源的链接。你可能检查出来：
WS：//连接比 “AJAX” 请求开销少得多。
简答
保持一个积极的WebSocket拥有成本，为客户端和服务器，阿贾克斯是否有一个成本只有一次，这取决于你用它做什么。
长的答案
的WebSockets经常被误解，因为这个整体的“嘿，使用Ajax，会做！”。不，Websockets不能替代Ajax。他们可能会应用于相同的领域，但有些情况下使用Websocket是荒谬的。
我们来举一个简单的例子：在客户端加载页面后加载数据的动态页面。很简单，打一个Ajax电话。我们只需要一个方向，从服务器到客户端。客户端会询问这些数据，服务器将把它们发送给客户端，完成。你为什么要为这样的任务实现websockets？您不需要始终打开您的连接，您不需要客户端不断询问服务器，也不需要服务器通知客户端。连接将保持打开状态，这会浪费资源，因为要保持连接打开，您需要不断检查连接。
现在聊天应用程序的事情是完全不同的。您需要通过服务器通知您的客户端，而不是强制客户端每隔几秒或几毫秒询问一次服务器是否有新问题。这是没有意义的。
为了更好地理解，请参阅两个人。一个是服务器，一个是客户端。 Ajax就像发送一封信一样。客户端发送一封信，服务器回复另一封信。事实是，对于一个聊天应用程序，对话会是这样的：
“嘿服务器，得到的东西对我来说
- 第
- 嘿服务器，得到的东西对我来说
-
号？ - 嘿服务器，给我找点东西吗？
- 是的，就在这里。“
如果客户端从未要求答案，服务器实际上不能发送一封信给客户端。这是一个巨大的资源浪费。因为对于每个Ajax请求，即使它被缓存，您也需要在服务器端进行操作。
现在我前面讨论过使用Ajax加载数据的情况。想象一下，客户端正在与服务器通话。保持连接活动有成本。它耗费电力，你必须付钱给你的运营商。现在，如果你只是想让这个人告诉你三个字，你为什么还需要给某人打电话并让他打电话一个小时？发送一封该死的信。
总而言之，Websockets并非完全取代Ajax！
有时你会需要 Ajax其中Websocket的使用是荒谬的。
编辑：上证所情况下
技术是不使用很广泛，但它可能是有用的。正如其名称所述，Server-Sent Events是从服务器到客户端的单向推送。客户端不需要任何请求，服务器只是发送数据。
简而言之：
- 从客户端单向：阿贾克斯
- 单向从服务器：SSE
- 双向：WebSockets的
正如其他人说，保持连接打开可以在某些情况下是矫枉过正你不需要服务器到客户端的通知，或者客户端到服务器的请求发生在低频率的情况下。
但是另一个缺点是websockets是一种低级协议，一旦执行初始握手，就不会向TCP提供额外的功能。因此，当通过websockets实现请求 - 响应范例时，您可能会错过HTTP（一种非常成熟和极端的协议族）提供的功能，如缓存（客户端和共享缓存），验证（条件请求），安全和幂等这对代理的行为有影响），范围请求，内容类型，状态代码......
也就是说，你可以减少消息的大小。
所以我的选择是AJAX的请求 - 响应，如果你想服务器连接打开的WebSockets服务器推高频率低延迟消息
，如果连续轮询服务器将在那里，然后去插座否则你很适合与阿贾克斯一起去。
简单的类比： Ajax向服务器询问问题（请求），服务器给出这些问题的答案（回答）。现在，如果你想问不断的问题，那么Ajax不会工作，它有一个大的开销，这将需要资源在两端。
我相信这是正确的。在不需要双向通信的应用程序中，服务器上的ajax请求会更容易。另外，请考虑当HTML5脱机持久性变为可用时（与Websockets变得更加可用的时间基本相同），Web应用程序只会根据需要与服务器同步。 – badunk 2012-03-17 09:06:24