nodejs:Ajax与Socket.IO,优缺点

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

因此,我会使用事件监听器/发射器客户端和服务器端。

防爆。 浏览器中的用户触发点击事件,客户端发射器通过套接字连接将事件推送到服务器。 服务器端侦听器对传入事件作出反应,并将“完成”事件返回给客户端。 客户端的侦听器通过淡入DIV元素对传入事件作出反应。

这有意义吗? 优点缺点?

3 Solutions collect form web for “nodejs:Ajax与Socket.IO,优缺点”

发送单向消息并向它们调用callback会变得非常混乱。

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

这就是为什么dnode和nowjs是build立在socket.io的基础之上的,以使事情变得易于pipe理。 仍然是事件驱动,但没有放弃callback。

在这个线程中有很多常见的错误信息是非常不准确的。

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

SocketIObuild立在WebSocket协议( RFC 6455 )之上。 它旨在完全取代 AJAX。 它没有什么可扩展性问题。 它的工作速度比AJAX快,而消耗的资源却less了一个数量级。

AJAX已经有10年的历史了,它build立在一个JavaScript XMLHTTPRequest函数的基础之上,它被添加来允许callback服务器而不用重新加载整个页面。

换句话说,AJAX是一个具有JavaScriptfunction的文档协议 (HTTP)。

相反,WebSocket是一个应用程序协议 ,旨在完全取代HTTP。 当您升级HTTP连接(通过请求WebSocket协议)时,您启用与服务器的双向全双工通信,并且不涉及任何协议握手。 使用AJAX,您必须启用保持活动状态(与SocketIO相同,仅适用于较旧的协议),或者每次发出AJAX请求时强制执行新的HTTP握手,从而导致服务器停止响应。

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

为什么SocketIO要快得多,消耗的资源如此之less

主要原因是WebSocket是为应用程序devise的,而AJAX是一个解决scheme,可以在文档协议上启用应用程序。

如果你深入到HTTP协议,并使用MVC框架,你会看到一个单一的AJAX请求实际上会传输700-900字节的协议负载只是为了AJAX到一个URL(没有任何你自己的有效载荷)。 与之形成鲜明对比的是,WebSocket使用大约10个字节,或者less了约70倍的数据与服务器交谈。

由于SocketIO保持开放连接,所以没有握手,服务器响应时间仅限于服务器本身的往返或ping时间。

有错误的信息, 套接字连接是一个端口连接; 不是这样。 套接字连接只是表中的一个条目。 只消耗很less的资源,一台服务器可以提供100万个以上的WebSocket连接。 AWS XXL服务器可以并且可以承载1,000,000个以上的SocketIO连接。

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

相比之下,WebSocket仅仅在一个连接表中存储一个约40-80字节的条目。 这就是字面意思。 根本没有轮询发生。

WebSocket的devise是为了扩展。

至于SocketIO是混乱的…这不是这种情况。 AJAX是凌乱的,你需要承诺/回应。

使用SocketIO,你只需要有发射器和接收器; 他们甚至不需要知道彼此; 不需要承诺系统:

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

 socket.emit("giveMeTheUsers"); 

当服务器准备就绪时,它会向您发回另一条消息。 田田,你做完了 所以,要处理一个用户列表,你只需要说出当你得到一个你正在寻找的响应时该怎么做…

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

而已。 混乱在哪里? 那么,没有:)分离的担忧? 为你做了。 locking客户,让他们知道他们必须等待? 他们不必等待:)无论何时,您都可以得到一个新的用户列表…服务器甚至可以以这种方式回放任何UI命令…客户端可以连接到对方 ,甚至不需要使用WebRTC服务器。 。

SocketIO中的聊天系统? 10行代码 。 实时video会议? 80行代码是…卢克…join我。 使用正确的协议工作…如果你正在编写一个应用程序…使用应用程序协议。

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

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

SocketIO,利用WebSocket为你做同样的事情…你可以开始把客户端视为简单的应用程序对话框。 根本不需要REST。

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

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

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

Socket.IO使用客户端和服务器之间的持久连接,因此,根据服务器端的资源,您将达到并发连接的最大限制,同时可以使用相同的资源提供更多的Ajaxasynchronous请求。

Socket.IO主要用于客户端和服务器之间的实时和双向连接,在某些应用中不需要保持永久连接。 另一方面,Ajaxasynchronous连接应该通过HTTP连接设置阶段,并发送标题数据和所有的cookie与每个请求。

Socket.IO被devise为一个单一的进程服务器,并可能有可扩展性问题,取决于你绑定的服务器资源。

当您更好地caching客户端请求的结果时,Socket.IO不适合应用程序。

Socket.IO应用程序面临着SEO优化和search引擎索引的困难。

Socket.IO不是W3C的Web Socket API的标准,它使用当前的Web Socket API,如果浏览器支持的话,由一个人创build的socket.io在实时应用程序中parsing跨浏览器的兼容性,是如此年轻,大约1年旧。 与ajax / jquery相比,它的学习曲线,较less的开发人员和社区资源,长期维护以及未来更less的需求或更好的select可能对开发人员团队基于socket.io制作代码非常重要。

  • Node.js,Socket.io,Redis pub / sub高容量,低延迟困难
  • socket.io房间或命名空间?
  • Socket.IO文档
  • 如何在socket.io中重用redis连接?
  • 用于socket.io服务器的Node.js客户端
  • Socket.IO问题与控制字符
  • socket.io客户端库在哪里?
  • 如果持久模型(服务器数据库)由外部应用程序更改,AngularJS是否可以自动更新视图?
  • 如何从快速应用程序中删除debugging?
  • 哪个websocket库与Node.js一起使用?
  • 用socket.io和node.js发送消息给特定的客户端