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