首页 文章

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

提问于
浏览
43

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

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

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

这有意义吗?优点缺点?

3 回答

  • 6

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

    $.get('/api', sendData, returnFunction);socket.emit('sendApi', sendData); 更清洁 socket.on('receiveApi', returnFunction);

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

  • 47

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

    TL/DR; WebSocket replaces HTTP for applications!它是由谷歌在微软和许多其他领先公司的帮助下设计的 . 所有浏览器都支持它 . There are no cons.

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

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

    换句话说,AJAX是一个带有单个JavaScript函数的 document protocol (HTTP) .

    相比之下,WebSocket是一个 application protocol ,旨在完全取代HTTP . 升级HTTP连接时(通过请求WebSocket协议),您启用与服务器的双向全双工通信,并且不涉及任何协议握手 . 使用AJAX,您必须启用keep-alive(与SocketIO相同,只有旧协议),或者每次发出AJAX请求时强制新的HTTP握手,这会使服务器陷入困境 .

    运行在Node之上的SocketIO服务器可以使用仅4gb的ram和单个CPU在保持活动模式下处理100,000个 concurrent 连接,这个限制是由V8垃圾收集引擎而不是协议引起的 . 即使在你最疯狂的梦想中,你也永远无法用AJAX实现这一目标 .

    Why SocketIO so much faster and consumes so much fewer resources

    主要原因是,WebSocket对于应用程序来说是 designed ,而AJAX是一种解决方案,可以在文档协议之上启用应用程序 .

    如果你深入研究HTTP协议,并使用MVC框架,你会发现一个AJAX请求实际上只会将700-900字节的协议加载传输到一个URL(没有你自己的有效负载) . 与之形成鲜明对比的是,WebSocket使用大约10个字节,或者与服务器通信的数据减少约70倍 .

    由于SocketIO维护开放连接,因此没有握手,服务器响应时间仅限于服务器本身的往返或ping时间 .

    有错误的信息表明 socket 连接是 port 连接;它不是 . 套接字连接只是表中的一个条目 . 消耗的资源非常少,单个服务器可以提供1,000,000个WebSocket连接 . AWS XXL服务器可以并且确实承载1,000,000个SocketIO连接 .

    AJAX连接将gzip / deflate整个HTTP头,解码头,编码头,并启动HTTP服务器线程来处理请求,因为这是一个文档协议;服务器旨在一次吐出文档 .

    相比之下,WebSocket只是在表中存储一个条目用于连接,大约40-80字节 . 这就是字面意思 . 根本没有轮询 .

    WebSocket的规模是 designed .

    至于SocketIO是凌乱的......根本不是这样的 . AJAX很乱,你需要承诺/响应 .

    使用SocketIO,您只需要 Launcher 和接收器;他们甚至不需要了解彼此;不需要承诺系统:

    要请求用户列表,您只需向服务器发送消息...

    socket.emit("giveMeTheUsers");
    

    服务器准备就绪后,它会向您发送另一条消息 . 田田,你做完了 . 因此,要处理用户列表,您只需说明当您收到要查找的响应时该怎么做...

    socket.on("HereAreTheUsers", showUsers(data) );
    

    那个's it. Where is the mess? Well, there is none :) Separation of concerns? Done for you. Locking the client so they know they have to wait? They don' t必须等待:)你可以得到一个新的用户列表...服务器甚至可以用这种方式回放任何UI命令...客户端可以连接到 each other 甚至没有使用WebRTC的服务器...

    SocketIO中的聊天系统? 10 lines of code . 实时视频 Session ? 80 lines of code 是的......卢克......加入我吧 . 使用正确的协议来完成工作...如果您正在编写应用程序...请使用应用程序协议 .

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

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

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

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

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

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

    更新:

    最近有很多人问我如何使用WebSockets在2018年(现在很快到2019年)开始编写应用程序,屏障看起来非常高,一旦他们使用Socket.IO他们就不知道在哪里转或学什么 .

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

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

    注意:尽管Meteor是迄今为止最受欢迎的,但我将其排除在外,因为虽然它们是一个非常,资金充足的WebSocket框架,但是任何使用Meteor编写了几年的人都会告诉你,它不是很好 - 想了想,很快就会死 . 对不起流星人,但看看这两个与Meteor相比的其他项目,你会在同一天扔掉Meteor :)

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

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

    Moleculer不幸的是,Moleculer在后端比Feathers好一个数量级 . 虽然羽毛可以工作,并且让你可以扩展到无限,羽毛根本就没有用Feathers Build 一个 生产环境 API网关,Moleculer做得更好,更方便 . 与任何WebSocket框架相比,Moleculer在人气和新功能方面也是增长最快的 .

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

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

    ActionHero这里列出了一个可行的选择,但Feathers和Moleculer是更好的实现 . 如果有任何关于ActionHero的事情没有使用它;上面有两种更好的方法可以让你更快,更快 .

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

  • 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制作代码非常重要 .

相关问题