相关疑难解决方法(0)

我运行一个网站,用户可以通过浏览器互相聊天(想想Facebook聊天).处理实时交互的最佳方式是什么？(现在我每隔30秒进行一次民意调查,以更新在线用户和新收到的消息,以及每秒在聊天页面上进行的另一次民意调查以获取新消息.)

我考虑过的事情:

• HTML5 Web套接字:没有使用它,因为它不适用于所有浏览器(仅限chrome).
• Flash套接字:没有使用它,因为我想最终支持移动网络.

现在,我正在使用短轮询,因为我不知道AJAX长度轮询的可扩展性如何.我正在从servint运行VPS服务器(运行apache).我应该使用长轮询还是短轮询？我不需要绝对的立即响应时间(对于聊天应用程序来说"足够好").是否有几十万用户要杀死我的服务器？我该如何扩展,请帮忙!

有人可以简要介绍这些看似相似的技术之间的区别吗？

• 的WebSocket
• 服务器发送事件(SSE)
• HTTP2的服务器推送

我知道所有这三个都是" 推动 "来自服务器的响应,而不是客户端的请求.

初看起来,似乎都是一样的.我需要更清楚地了解差异.

我的应用程序有一个页面,用户必须在该页面上相对实时地查看如何处理2个步骤.

现在这是通过ajax短轮询完成的.我想把它改成一些服务器重量较少的技术,我选择Faye gem和ajax long-polling.
Ajax长轮询更容易实现,不需要任何服务器入侵.它将需要4个ajax请求(用于完成2个步骤的页面).
Faye gem将发送3个请求,这并不是很少.它需要我设置我的nginx-passenger服务器,并且更难以实现和支持.

我会选择ajax长轮询,但我听说它需要一个完整的Rails实例运行,而请求是长轮询的,这将耗尽我的RAM.另一方面,从这个如何生产的rails服务器工作？我知道Rails在长轮询中可能没有这个问题.那么,这是真的, - 来自多个客户端的ajax长轮询需要许多并发应用程序处理(这可能会占用我的一些资源,不确定哪些)？

我已经阅读了很多关于实时推送通知的文章.简历是websocket通常是首选技术,只要您不关心100%的浏览器兼容性.然而,有一篇文章指出了这一点

长轮询 - 可能在您与服务器交换单个呼叫时,服务器正在后台进行一些工作.

这正是我的情况.用户按下一个按钮,在服务器端启动一些复杂的计算,一旦答案准备就绪,服务器就会向客户端发送推送通知.问题是,我们可以说,对于一次性响应的情况,长轮询是比websockets更好的选择吗？或者除非我们担心过时的浏览器支持,如果我要从头开始启动项目,那么在涉及推送协议时,websockets应该总是优先考虑长轮询？