基于浏览器的聊天需要特殊技术？答案

【问题标题】：Special technology needed for browser based chat?基于浏览器的聊天需要特殊技术？
【发布时间】：2010-04-07 05:43:41
【问题描述】：

在this post，我读到了有关 XMPP 的用法。这种事情有必要吗？更重要的是，我的主要问题扩展了：能否仅使用标准 HTTP 和浏览器技术高效构建聊天服务器和客户端（例如 PHP 和 JS，或 RoR 和 JS ， ETC）？或者，最好还是坚持使用 XMPP 等旧协议，并找到一种将它们与我的应用程序集成的方法？

我通过 LiveHTTPHeaders 和 Firebug 查看了CampFire 大约 5 分钟，它似乎使用 Ajax 发送一个请求，该请求在发生另一次聊天之前从未得到答复。这只是 CampFire 在服务器上打开一个新线程以侦听更新，然后在线程听到更新时返回对请求的响应吗？我注意到他们在特定端口上请求（8043，如果我没记错的话），这让我觉得他们正在做的事情比我提到的更复杂。另外，请求的 URL 以 /tcp/ 开头，我觉得这很有趣。

注意：我预计不会有超过 150 个用户同时在所有房间内进行实时聊天。我知道，如果我要为像 CampFire 这样的聊天服务构建托管付费服务，同时拥有数千名并发用户，我应该花时间研究特殊技术，而不是尝试在我的应用中以简单的方式重新发明轮子。

另外，如果您打算通过服务器轮询来做到这一点，您会多久亲自轮询一次以最大限度地提高响应而不会猛烈抨击服务器？

【问题讨论】：

标签： chat livechat

【解决方案1】：

该技术被广泛称为Comet，据说这是关于 Ajax 的一些搞笑双关语¹。

XmlHTTPResponse 变体似乎是最流行的。

XHR 版本本身并不是严格的轮询；正如你所说，客户端连接超时时间很长，服务器实际上并没有发送响应，直到有任何东西要发送。发送响应后，它会断开连接并重新连接客户端。他们称之为长轮询，因为客户端正在启动连接，但它与经典轮询的不同之处在于，即使没有任何变化，客户端也不会不断连接请求新内容（即没有“现在有消息吗？没有？如何现在呢？现在呢？”）

这更像是试图保持一个不断断开的连接打开。

是的，它绝对可以使用标准网络技术构建。

¹我更愿意将阿贾克斯视为强大的希腊战士而不是清洁产品，所以我对这个双关语非常不满。

【讨论】：

@kibibu +1 太好了，这正是我认为 CampFire 所做的。现在我在这个聊天游戏中感觉不像这样的n00b。知道服务器如何在不浪费资源的情况下等待这么长时间才回复吗？线程？
Apache 已经非常擅长线程。我认为在大多数网络语言中使用 sleep() 可以很好地在线程中与操作系统配合使用，因此您可以轮询（在服务器端！）如果没有新消息，则可以休眠。
再次感谢，这真的很有帮助。
既然你知道它有一个名字，你也可以在这里搜索一些非常有用的信息，例如stackoverflow.com/questions/603201/using-comet-with-php 建议 PHP+Apache 可能不是最好的方法。
我之前评论的快速附录 - 为此避免使用 Apache。 Apache 实际上在扩展方面很差。基于事件循环的服务器将比 Apache 更好地扩展很多。

【解决方案2】：

这首先取决于您的网络服务器负载平衡策略。通过无状态介质 (HTTP) 发布数据的 150 个并发用户通过少量脚本（客户端和服务器端）肯定是有效的。请记住，聊天应用程序只是多个客户端 -> 一个服务器策略，非常适合 Web。

【讨论】：