简而言之，如果您的数据主要是服务器驱动的，然后需要发送给客户端，并且您希望在客户端看到新数据时等待相当长的等待时间，那么这正是webSockets所擅长的问题。在这种情况下，webSockets效果最佳，因为客户端不需要频繁轮询，服务器不需要处理来自许多客户端的常规轮询请求。取而代之的是，每个客户端都只建立一个持久的webSocket通信通道，服务器可以随时根据需要向下发送数据。
我对ajax的请求不会太多吗？想象一下，我想每分钟检查一次服务器，如果我们将应用程序扩展到100个用户，那么每分钟将给我100个查询。拥有套接字会在系统资源中“便宜”吗？
套接字在不活动时只需要很少的资源，因此，持久的webSocket比许多不断轮询的客户端更有效。这就是发明webSocket的原因，因为它们更擅长解决此特定问题。
对于移动设备，socket.io是否会成为问题？带宽和性能。服务器的响应始终是JSON格式的信息。
socket.io对于带宽或性能而言不是问题。尝试在后台使用webSockets存在一些移动问题，因为移动设备也试图进行主动电源管理，尽管客户端轮询也存在类似问题。
两种方法的缓存如何？我正在考虑为每个用户创建一个缓存文件，该文件将由服务器端的node.js进行更新。我猜想这可以与ajax一起很好地工作，但是socket.io呢？
不清楚您对缓存有什么要求？在webSocket实现中，服务器获取数据，然后将其发送给每个用户。通常不需要服务器端缓存。在客户端Ajax轮询实现中，服务器必须将数据存储在某个位置，然后“等待”每个客户端然后请求数据。对于webSocket或Ajax，没有“内置”缓存机制。
确实socket.io与许多浏览器根本不兼容吗？我的应用程序将更加专注于移动设备，我认为这可以让我考虑选择ajax。
socket.io与所有具有webSockets的浏览器完全兼容，除了IE9和更早版本，几乎所有当前使用的webSockets都使用。如果使用socket.io库，则如果不存在webSockets，它将自动退回长时间轮询。无论您是进行常规轮询还是webSocket，您的移动问题都可能会相似，因为移动设备希望对长期运行的设备进行电源管理，但又不想停止轮询。我认为这不是避免使用webSockets
/ socket.io的原因。socket.io在失去连接时具有一些非常好的自动重新连接逻辑，这很有用。
在移动世界中，我想您会发现，如果不使用某种可以插入设备上本机“推送”系统的本机应用程序组件，就无法在后台可靠地进行实时通知。这是唯一一个既能节省电池又能与电源管理完全兼容的系统。如果不是前台任务或设备处于空闲状态，则将对网页进行电源管理。
