nodejs:Ajax vs Socket.IO,优点和缺点

Question

我想要摆脱所有客户端Ajax调用(jQuery),而是使用永久套接字连接(Socket.IO).

因此,我将使用事件侦听器/发射器客户端和服务器端.

防爆.用户在浏览器中触发click事件,客户端发射器通过套接字连接将事件推送到服务器.服务器端侦听器对传入事件做出反应,并将"完成"事件推送回客户端.客户端的侦听器通过DIV元素中的淡入淡出对传入事件做出反应.

这有道理吗？优点缺点？

Answer 1

这个帖子中有很多常见的错误信息是非常不准确的.

TL/DR; WebSocket 替换了应用程序的HTTP!它是由谷歌在微软和许多其他领先公司的帮助下设计的.所有浏览器都支持它.没有缺点.

SocketIO构建于WebSocket协议(RFC 6455)之上.它旨在完全取代 AJAX.它没有可扩展性问题.它比AJAX工作得更快,同时消耗的资源量减少了一个数量级.

AJAX已有10年历史,它基于单个JavaScript XMLHTTPRequest函数构建,该函数已添加到允许回调服务器而无需重新加载整个页面.

换句话说,AJAX是一种具有单一JavaScript功能的文档协议(HTTP).

相比之下,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行代码 是...... Luke ...加入我.使用正确的协议来完成工作...如果您正在编写应用程序...请使用应用程序协议.

我认为这里的问题和困惑来自于习惯使用AJAX的人,并认为他们需要客户端上的所有额外承诺协议和后端的REST API ......嗯,你没有.:)它不再需要了:)

是的,你读得正确......当你决定切换到WebSocket时,不再需要REST API.REST实际上已经过时了.如果您编写桌面应用程序,是否使用REST与对话框进行通信？不:)那真是愚蠢.

SocketIO,利用WebSocket为你做同样的事情......你可以开始认为客户端就像你的应用程序的对话框一样简单.你根本不再需要REST.

事实上,如果你在使用WebSocket时尝试使用REST,那就像使用REST作为桌面对话的通信协议一样愚蠢......根本没有任何意义.

你说蒂米是什么意思？那些想要使用你的应用的其他应用呢？你应该让他们访问REST？Timmy ... WebSocket已经推出4年了......只需让他们使用WebSocket连接到您的应用程序,并让他们使用该协议请求消息...它将消耗50倍的资源,更快,10倍更容易发展......为什么在创造未来时支持过去？

当然,REST有一些用例,但它们都适用于较旧和过时的系统......大多数人还不知道.

更新:

一个地段的人都在问我最近怎么他们开始在2018年写一个应用程序(现在快2019)使用的WebSockets,该屏障似乎真的很高,一旦他们与Socket.IO发挥他们不知道还有什么地方转或学什么.

幸运的是,过去3年对WebSockets非常友好......

现在有3个主要框架支持BOTH REST和WebSocket,甚至是物联网协议或其他最小/快速协议,如ZeroMQ,你不必担心任何问题; 你只需获得开箱即用的支持.

注意:尽管Meteor是迄今为止最受欢迎的,但我将其排除在外,因为虽然它们是一个非常,资金充足的WebSocket框架,任何使用Meteor编码几年的人都会告诉你,这是一个内部混乱和一个噩梦扩大规模.有点像WordPress是PHP,它在那里,它很受欢迎,但它不是很好.它没有经过深思熟虑,很快就会消亡.对不起流星人,但看看这些与Meteor相比的其他3个项目,你会在同一天扔掉Meteor :)

使用以下所有框架,您只需编写一次服务,即可获得REST和WebSocket支持.更重要的是,它是几行配置代码,几乎可以在任何后端数据库之间进行交换.

羽毛最容易使用,在前端和后端工作相同,并支持大多数功能,Feathers是现有工具如快递的轻量包装的集合.使用诸如feathers-vuex等令人敬畏的工具,您可以创建完全可模拟的不可变服务,支持REST,WebSocket和其他协议(使用Primus),并获得免费的完整CRUD操作,包括搜索和分页,无需一行代码(只需一些配置).使用生成的数据(如json-schema-faker)也非常有用,因此您不仅可以完全模拟事物,还可以使用随机但有效的数据进行模拟.您可以连接应用程序以支持预先键入搜索,创建,删除和编辑,无需代码(只需配置).正如你们中的一些人可能知道的那样,正确的code-through-config是自修改代码的最大障碍.Feathers是正确的,并将在应用程序设计的未来推动你走向前沿.

不幸的是,Moleculer Moleculer在后端比Feathers好一个数量级.虽然羽毛可以工作,并且让你可以扩展到无限,但羽毛甚至不会开始考虑生产集群,实时服务器控制台,容错,开箱即用的管道日志或API网关(当我建造时)作为Feathers的生产API网关,Moleculer做得更好,方式更好.与任何WebSocket框架相比,Moleculer在人气和新功能方面也是增长最快的.

与Moleculer一起获胜的罢工是你可以使用带有Moleculer后端的Feathers或ActionHero前端,虽然你丢失了一些发电机,但你可以获得很多的生产质量.

因此,我建议在前端和后端学习Feathers,一旦你制作了第一个应用程序,尝试将后端切换到Moleculer.Moleculer很难开始使用,但仅仅因为它解决了所有缩放问题,而且这些信息可能会让新用户感到困惑.

ActionHero在此列为可行的替代方案,但Feathers和Moleculer是更好的实现.如果有关于ActionHero的任何内容与您没有Jive,请不要使用它; 上面有两种更好的方式可以让你更快,更快.

注意: API网关是未来,上述所有3个都支持它们,但Moleculer确实为您提供了开箱即用的功能.通过API网关,您可以按摩客户端交互,从而允许单个平台组件处理缓存,记忆,客户端到客户端消息传递,黑名单,注册,容错以及所有其他扩展问题.将您的API网关与Kubernetes相结合,您可以在尽可能少的问题的情况下扩展到无限.这是可扩展应用程序的最佳设计方法.

Answer 2

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制作代码可能很重要.

Answer 3

发送单向消息并向其调用回调可能会变得非常混乱.

$.get('/api', sendData, returnFunction); 比...更干净 socket.emit('sendApi', sendData); socket.on('receiveApi', returnFunction);

这就是为什么dnode和nowjs构建在socket.io之上以使事情易于管理的原因.仍然是事件驱动但没有放弃回调.