nodejs：Ajax与Socket.IO，优缺点
我想摆脱所有的客户端Ajax调用（jQuery），而是使用永久套接字连接（Socket.IO）。
因此，我会使用事件监听器/发射器客户端和服务器端。
防爆。 浏览器中的用户触发点击事件，客户端发射器通过套接字连接将事件推送到服务器。 服务器端侦听器对传入事件作出反应，并将“完成”事件返回给客户端。 客户端的侦听器通过淡入DIV元素对传入事件作出反应。
这有意义吗？ 优点缺点？
发送单向消息并向它们调用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制作代码非常重要。
