我考虑过摆脱所有客户端Ajax调用（jQuery），而是使用永久套接字连接（Socket.IO）。
因此我会使用事件监听器/发射器客户端和服务器端。
实施例。用户在浏览器中触发click事件，客户端发射器通过套接字连接将事件推送到服务器。服务器端侦听器对传入事件做出反应，并将“完成”事件推送回客户端。客户端的侦听器通过DIV元素中的淡出来对传入事件做出反应。
这有意义吗？ 优点＆amp;缺点
答案 0 :(得分：54)
这个帖子中有很多常见的错误信息非常不准确。
<强> TL / DR; WebSocket 取代 HTTP应用程序！它是由谷歌在微软和许多其他领先公司的帮助下设计的。所有浏览器都支持它。 没有缺点。
SocketIO构建于WebSocket协议（RFC 6455）之上。它旨在完全替换 AJAX。它没有可扩展性问题。它比AJAX工作得更快，同时消耗的资源量减少了一个数量级。
AJAX已有10年历史，它基于单个JavaScript XMLHTTPRequest函数构建，该函数已添加到允许回调服务器而无需重新加载整个页面。
换句话说，AJAX是一个文档协议（HTTP），只有一个JavaScript函数。
相比之下，WebSocket是一个应用程序协议，旨在完全取代HTTP。当您升级HTTP连接时（通过请求WebSocket协议），您启用与服务器的双向全双工通信，并且不涉及任何协议握手。使用AJAX，您必须启用keep-alive（与SocketIO相同，只与旧协议相同），或者每次发出AJAX请求时强制新的HTTP握手，这会使服务器陷入困境。
运行在Node之上的SocketIO服务器只能使用4gb ram和一个CPU来处理保持活动模式下的100,000个并发连接，这个限制是由V8垃圾收集引擎引起的，不是协议。即使在你最疯狂的梦想中，你也永远无法用AJAX实现这一目标。
为什么SocketIO速度更快，消耗的资源更少
主要原因是，WebSocket的应用程序设计，而AJAX是一种解决方案，可以在文档协议之上启用应用程序。
如果您深入了解HTTP协议并使用MVC框架，您将看到单个AJAX请求实际上只会将700-900字节的协议加载传输到AJAX到URL（没有任何自己的负载） 。与之形成鲜明对比的是，WebSocket使用大约10个字节，或者与服务器通信的数据减少约70倍。
由于SocketIO维持开放连接，因此没有握手，服务器响应时间仅限于服务器本身的往返或ping时间。
错误信息套接字连接是端口连接;它不是。套接字连接只是表中的一个条目。消耗的资源非常少，单个服务器可以提供1,000,000多个WebSocket连接。 AWS XXL服务器可以并且确实托管1,000,000多个SocketIO连接。
AJAX连接将gzip / deflate整个HTTP头，解码头，编码头，然后启动HTTP服务器线程来处理请求，因为这是一个文档协议;服务器设计用于一次吐出文档。
相比之下，WebSocket只是在表中存储一个连接条目，大约40-80字节。这就是字面意思。根本没有轮询。
WebSocket 设计可扩展。
至于SocketIO凌乱......事实并非如此。 AJAX很乱，你需要承诺/响应。
使用SocketIO，你只需要发射器和接收器;他们甚至不需要了解彼此;不需要承诺系统：
要请求用户列表，您只需向服务器发送消息...
socket.emit("giveMeTheUsers");
当服务器准备就绪时，它会发回另一条消息。田田，你做完了。因此，要处理用户列表，您只需说明当您收到回复时该怎么做......
socket.on("HereAreTheUsers", showUsers(data) );
那就是它。一团糟在哪里？好吧，没有:)关注点分离？为你做了。锁定客户，让他们知道他们必须等待？他们不必等待:)你可以随时获得一个新的用户列表......服务器甚至可以以这种方式回放任何UI命令...客户端可以连接到彼此甚至没有使用WebRTC的服务器...
SocketIO中的聊天系统？ 10行代码。实时视频会议？ 80行代码是的......卢克......加入我吧。使用正确的协议来完成工作...如果您正在编写应用程序......请使用应用程序协议。
我认为这里的问题和困惑来自于习惯使用AJAX和思考的人他们需要客户端上的所有额外承诺协议和后端的REST API ...嗯，你不是。 :)它不再需要了:)）
是的，你读得对了......当你决定切换到WebSocket时，不再需要REST API了。 REST实际上已经过时了。如果您编写桌面应用程序，是否使用REST与对话框进行通信？不，那真是愚蠢。
SocketIO，利用WebSocket为您做同样的事情......您可以开始认为客户端就像您的应用程序的对话框一样简单。你根本不再需要REST。
事实上，如果你在使用WebSocket时尝试使用REST，那就像使用REST作为桌面对话的通信协议一样愚蠢......根本没有任何意义。
你说蒂米是什么意思？那些想要使用你的应用的其他应用呢？你应该让他们访问REST？ Timmy ... WebSocket已经推出4年了......让他们使用WebSocket连接到你的应用程序，然后让他们使用那个协议来请求消息......它将消耗50倍的资源，更快，更容易开发...为什么在你创造未来时支持过去？
当然，REST有一些用例，但它们都适用于较旧和过时的系统......大多数人还不知道。
更新：
很多的人最近一直在问我如何使用WebSockets在2018年（现在很快2019年）开始编写应用程序，这个障碍看起来非常高，一旦他们玩Socket .IO他们不知道还有什么地方可以转向或学习什么。
幸运的是，过去3年对WebSockets非常友好......
现在有3个主要框架支持 BOTH REST和WebSocket，甚至是物联网协议或其他最小/快速协议，如ZeroMQ，你不必担心任何一个;你只需获得开箱即用的支持。
注意：尽管Meteor是迄今为止最受欢迎的，但我将其排除在外，因为尽管它们是一个非常，资金充足的WebSocket框架，但任何使用Meteor编码了几年的人会告诉你，这是一场内部混乱，也是一场规模化的噩梦。有点像WordPress是PHP，它在那里，它很受欢迎，但它不是很好。它没有经过深思熟虑，很快就会消亡。对不起Meteor人员，但是看看这两个与Meteor相比的其他项目，你会在同一天抛出Meteor：）
使用以下所有框架，您只需编写一次服务，即可获得REST和WebSocket支持。更重要的是，它是在几乎任何后端数据库之间交换的单行配置代码。
Feathers最容易使用，在前端和后端工作相同，并支持大多数功能，Feathers是现有工具（如express）的轻量包装器的集合。使用诸如feathers-vuex等令人敬畏的工具，您可以创建完全可模拟的不可变服务，支持REST，WebSocket和其他协议（使用Primus），并获得免费的完整CRUD操作，包括搜索和分页，无需一行代码（只需一些配置）。使用json-schema-faker之类的生成数据也非常有效，因此您不仅可以完全模拟事物，还可以使用随机但有效的数据进行模拟。您可以使用无代码（仅配置）连接应用程序以支持预先键入搜索，创建，删除和编辑。正如你们中的一些人可能知道的那样，正确的code-through-config是自修改代码的最大障碍。 Feathers是正确的，并将在应用程序设计的未来推动你走向前沿。
Moleculer不幸的是，Moleculer在后端比Feathers好一个数量级。虽然羽毛会起作用，并且让你可以扩展到无限，但羽毛根本就不会开始考虑诸如生产集群，实时服务器控制台，容错，开箱即用的管道日志或API网关等事情（而我和＃ 39; ve用Feathers构建了一个生产API网关，Moleculer做得更好，方式更好。与任何WebSocket框架相比，Moleculer在人气和新功能方面也是增长最快的。
Moleculer的获胜罢工是你可以使用带有Moleculer后端的Feathers或ActionHero前端，虽然你丢失了一些发电机，但你可以获得很多的生产质量。
因此，我建议在前端和后端学习Feathers，一旦你制作了第一个应用程序，尝试将后端切换到Moleculer。 Moleculer很难开始使用，但这只是因为它解决了所有缩放问题，而这些信息可能会让新用户感到困惑。
ActionHero这里列出了一个可行的选择，但Feathers和Moleculer是更好的实现。如果有任何关于ActionHero与你没有关系的事情，请不要使用它;上面有两种更好的方法可以让你更快，更快。
注意： API网关是未来，上述所有3个都支持它们，但Moleculer确实为您提供了开箱即用的功能。通过API网关，您可以按摩客户端交互，从而允许单个平台组件处理缓存，记忆，客户端到客户端消息传递，黑名单，注册，容错以及所有其他扩展问题。将您的API网关与Kubernetes相结合，您可以在尽可能少的问题的情况下扩展到无限。这是可扩展应用程序的最佳设计方法。
答案 1 :(得分：21)
Socket.IO使用客户端和服务器之间的持久连接，因此您将根据服务器端的资源达到并发连接的最大限制，而更多的Ajax异步请求可以使用相同的资源提供。
Socket.IO主要用于客户端和服务器之间的实时和双向连接，在某些应用程序中，不需要保持永久连接。另一方面，Ajax异步连接应该通过HTTP连接设置阶段，并在每次请求时发送头数据和所有cookie。
Socket.IO被设计为单个进程服务器，并且可能存在可伸缩性问题，具体取决于您所绑定的服务器资源。
当您更好地缓存客户端请求的结果时，Socket.IO不适合应用程序。
Socket.IO应用程序面临SEO优化和搜索引擎索引的困难。
Socket.IO不是标准，也不等同于W3C Web Socket API，它使用当前的Web Socket API（如果浏览器支持），由一个人创建的socket.io来解析实时应用程序中的跨浏览器兼容性并且非常年轻，大约1岁。它的学习曲线，与ajax / jquery相比较少的开发人员和社区资源，长期维护以及将来需求或更好的选择对于开发人员团队根据socket.io制作代码可能很重要。
答案 2 :(得分：6)
发送单向消息并向其调用回调可能会非常混乱。
$.get('/api', sendData, returnFunction);比...更清洁
socket.emit('sendApi', sendData); socket.on('receiveApi', returnFunction);
这就是为什么dnode和nowjs构建在socket.io之上以使事情易于管理的原因。仍然是事件驱动但没有放弃回调。