关于this post ，我读到了XMPP的用法。这种事情有必要吗？更重要的是，我的主要问题扩展了:能否仅使用标准 HTTP 和浏览器技术来高效构建聊天服务器和客户端(例如 PHP 和 JS，或者 RoR 和 JS) ， ETC)？或者，最好坚持使用 XMPP 等旧协议(protocol)，找到一种将它们与我的应用程序集成的方法？
我调查了CampFire通过 LiveHTTPHeaders 和 Firebug 大约 5 分钟，它似乎使用 Ajax 发送一个请求，该请求在另一次聊天发生之前永远不会得到答复。这只是 CampFire 在服务器上打开一个新线程来监听更新，然后在线程听到更新时返回对请求的响应吗？我注意到他们正在请求特定端口(8043，如果我没记错的话)，这让我认为他们正在做一些比我提到的更复杂的事情。另外，请求的 URL 以 /tcp/ 开头，我觉得这很有趣。
注意:我预计所有房间中同时实时聊天的用户数量不会超过 150 名。我知道，如果我正在构建像 CampFire 这样具有数千个并发用户的托管付费聊天服务，那么我应该花时间研究特殊技术，而不是尝试在我的应用程序中以简单的方式重新发明轮子。
此外，如果您打算通过服务器轮询来完成此操作，您个人会多久进行一次轮询，以在不影响服务器的情况下最大化响应？
最佳答案
该技术被广泛称为Comet ，这被认为是 Ajax1 上的一些搞笑双关语。
XmlHTTPResponse 变体似乎是最流行的。
XHR 版本本身并不是严格的轮询；正如您所说，客户端连接时超时很长，服务器实际上不会发送响应，直到有任何内容要发送。发送响应后，它会断开连接并客户端重新连接。他们称其为长轮询，因为客户端正在启动连接，但它与经典轮询不同，即使没有任何更改，客户端也不会不断连接请求新内容(即没有“现在有消息吗？没有？怎么办？”现在呢？现在呢？”)
这更像是试图保持一个不断断开的连接打开。
是的，它绝对可以使用标准网络技术来构建。
1我更喜欢将 Ajax 视为强大的希腊战士，而不是清洁产品，所以我对这个双关语非常皱眉。
关于chat - 基于浏览器的聊天需要特殊技术吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2590249/