是否有不需要在服务器端修改的情况下轮询的 ajax 替代方案？

Posted 2023-04-14

【中文标题】是否有不需要在服务器端修改的情况下轮询的 ajax 替代方案？

【英文标题】：Is there an alternative of ajax that does not require polling without server side modifications?

【发布时间】：2009-01-09 12:16:41

【问题描述】：

我正在尝试创建一个小型且基本的基于“ajax”的多人游戏。对象的坐标由 php“处理程序”给出。这个 handler.php 文件每 200 毫秒被轮询一次，使用 ajax。

既然什么都没有发生就不需要轮询，我想知道，有没有什么东西可以在没有频繁轮询的情况下做同样的事情？例如。 Comet，虽然我听说你需要为 Comet 配置服务器端应用程序。这是一个共享的网络服务器，所以我不能这样做。

如果客户端无需更改任何内容，可能会阻止 handler.php 文件甚至返回响应，这可能吗？然后，即使某些事情还没有改变，您仍然会让客户无用地要求响应。基本上，它应该只在需要告诉客户某些事情时才使用带宽和服务器资源，例如。物体坐标的变化。

【参考方案1】：

Comet 通常用于此类事情，它可能是一个脆弱的设置，因为它不是一种特别常见的技术，因此很容易不“做对”。也就是说，现在可用的资源比我大约 2 年前上次尝试时要多。

我不认为你可以做你想做的事，并且 handler.php 根本不返回任何东西并停止执行：Web 服务器将保持连接打开并阻止任何进一步的轮询，直到 handler.php 执行某些操作（终止或提供输出）。当它发生时，您仍在处理响应。

您可以尝试一种长轮询技术，您的 AJAX 允许非常大的超时时间（例如 30 秒），并且 handler.php 旋转而不响应，直到它有要报告的内容，然后返回。 （您需要确保旋转不是资源密集型的）。如果 handler.php “过期”并且没有任何反应，让它退出并让 AJAX 再次轮询。由于它仅每 30 秒发生一次，因此它将是每秒约 5 次的巨大改进。这将使您的投票保持在最低限度。

但这就是 Comet 的设计目标。

【参考方案2】：

由于 Ajax 只为您提供客户端服务器请求模型（通常称为 pull，而不是 push），因此从服务器获取数据的唯一方法是通过请求。然而，解决此问题的常用技术是服务器仅在有新数据时才响应。因此，客户端发出请求，服务器挂起该请求，直到发生某些事情然后回复。即使数据没有更改，这也解决了频繁轮询的需要，因为您只需要客户端在收到响应后发送一个新请求。

由于您使用的是 PHP，一种简单的方法可能是让 PHP 代码在检查数据更改之间一次调用 sleep 命令 200 毫秒，然后在数据发生更改时将数据返回给客户端。

编辑：我还建议对请求进行超时。因此，如果 2 秒内没有任何反应，则会发回一条“无变化”消息。这样客户端就知道服务器还活着并且正在处理它的请求。

【讨论】：

有趣 - 但是，如果某些东西在例如内部发生变化怎么办。 200 毫秒？那么新检查完成之前需要相对较长的时间，因为间隔很长，对吧？有什么办法可以解决这个问题，还是我误解了你？

【参考方案3】：

由于这被标记为“html5”：HTML5 有<eventsource> 和WebSocket，但在实践中实现方面仍处于将来时态。

Opera 实现了旧版本的 <eventsource>，称为 <event-source>。

【讨论】：

EventSource 规范自 2009 年以来发生了变化，dev.w3.org/html5/eventsource，EventSource 是标准化的彗星

【参考方案4】：

这是一个解决方案 - 使用 SaaS comet 提供商，例如 WebSync On-Demand。无需担心服务器资源，无论是否共享托管，因为它已全部卸载，您可以根据需要推送信息。

由于它是 SaaS，它可以与任何服务器语言一起使用。对于 PHP，已经有一个已经编写好的发布者可以使用了。

【讨论】：

我已经接受了它，但我不会使用它，因为它不是免费的也不是开源的。

如果您只有少量用户，如果您愿意，您可以永远免费使用 10 个免费用户，但我知道，如果它是个人项目，则没有相关成本的解决方案总是可行的。

@Tom，SaaS 至少有硬件和维护成本，完全没有软件许可。

【参考方案5】：

服务器必须参与其中。请与托管服务提供商核实可用的模块。或者尝试说服他们支持 Comet。

也许您应该为此考虑使用小型虚拟专用服务器 (VPS)。

【参考方案6】：

在长轮询建议中补充一点：如果您在共享服务器上，此解决方案的可扩展性将有限，因为每个活动的长轮询将保持连接（以及为该连接提供服务的服务器端进程）积极的。您的提供商很可能对您一次可以打开的连接数量有限制（政策定义的或事实上的），因此如果您的会话/窗口多于同时播放的数量，您将碰壁。