当客户端断开连接时,HTTP 代理/FastCGI/SCGI 不会关闭连接 - 错误还是功能?

发布于 2024-08-03 04:37:11 字数 994 浏览 3 评论 0原文

我正在为 Comet 支持 “http://cppcms.sourceforge.net/” rel="nofollow noreferrer">CppCMS 框架通过长 XMLHttpRequest 轮询。在许多情况下,在服务器给出任何响应之前,客户端会关闭此类请求 - 例如页面关闭、用户移动到其他页面或刚刚刷新。

在服务器端,我希望收到连接断开的通知。我通过 3 个连接器测试了该应用程序:FastCGI、SCGI 和简单的 HTTP 代理。

3个主要的UNIX Web服务器,Apache2,lighttpd和Nginx,只有最后一个关闭了 连接按预期允许我的应用程序从等待队列中删除请求——这适用于 FastCGI 和 HTTP 代理连接器。 (Nginx 默认没有 scgi 模块)。

其他,Apache和Lighttpd不会关闭连接或通知后端已断开连接 客户端,就像客户端仍然在线一样继续进行。所有 3 个受支持的 API 都会发生这种情况:FastCGI、SCGI 和 HTTP 代理。

我已经为 Lighttpd 提出了一个问题,但是什么 我更关心的是 Apache —— 成熟且得到良好支持的 Web 服务器,如 lighttpd 并且不透露客户端所在的服务器后端。

问题:

  1. 这是一个错误还是一个功能?有什么理由不关闭Web服务器和应用程序后端之间的连接吗?
  2. 是否有现实生活中的 Comet 应用程序通过 FastCGI/SCGI/HTTP-Proxy 后端在这些服务器后面工作?
  3. 如果上述情况属实,他们如何处理这个问题?我知道我可以每 10 秒超时所有连接,但我想让它们在客户端监听时保持空闲状态 - 因为这可以更轻松地扩展 - 每个连接都非常便宜 - 成本只是打开的套接字。

谢谢!

I'm working on Comet support for CppCMS framework via long XMLHttpRequest polls. In many cases, such request is closed by client before any response from server was given -- for example the page is closed, user moves to other page or it is just refeshed.

At the server side I expect that I would recieve the notification that connection is dropped. I tested the application via 3 connectors: FastCGI, SCGI and simple HTTP Proxy.

From 3 major UNIX web servers, Apache2, lighttpd and Nginx, only the last one had closed
connection as expected allowing my application to remove the request from wait queue -- this worked for both FastCGI and HTTP Proxy connectors. (Nginx does not have scgi module by default).

Others, Apache and Lighttpd do not close connection or inform the backend about disconnected
clients, the proceed as if the client is still on line. This happens for all 3 supported APIs: FastCGI, SCGI and HTTP Proxy.

I had opened an issue for Lighttpd, but what
more conserns me is the fact that Apache -- mature and well supported web server as lighttpd
and does not discloses the server backend that client had gone.

Questions:

  1. Is this a bug or this is a feature? Is there any reason not to close the connection between web server and application backend?
  2. Are there real life Comet application working behind these servers via FastCGI/SCGI/HTTP-Proxy backends?
  3. If the above true, how do they deal with this issue? I understand that I can timeout all connections every 10 seconds, but I would like to keep them idle as far as client listens -- because this allows easier scale up -- each connection is very cheep -- the cost is only the opended socket.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

浮华 2024-08-10 04:37:11

(一)特点。或者,更具体地说,是实施细节的影响。

TCP/IP 连接不涉及持续的来回流量。因此,如果没有(a)客户端告诉您它正在关闭连接或(b)超时,就无法知道客户端已经消失。

(2) 我对 Comet 或 CppCMS 不是特别熟悉。但是,是的,上面提到的 Web 服务器后面运行着各种各样的 CMS 服务器,它们都必须处理这个问题(是的,这很痛苦)。

(3) 暂停是唯一的方法,但可以这么说,你可以减轻痛苦。当没有任何活动时,让客户端每 N 秒通过连接对服务器执行 ping 操作。无需执行任何操作,您可以在回复中添加内容;并发编辑或任何您需要的通知。

您是正确的,令人惊讶的是 mod_fastcgi 不支持告诉后端 Apache 已检测到断开连接或连接超时。你并不是第一个感到沮丧的人。

此页面上的第二个补丁应该修复该特定问题:

http: //osdir.com/ml/web.fastcgi.devel/2006-02/msg00015.html

(1) Feature. Or, more specifically, fallout from an implementation detail.

A TCP/IP connection does not involve a constant flow of traffic back and forth. Thus, there is no way to know that a client is gone without (a) the client telling you it is closing the connection or (b) a timeout.

(2) I'm not specifically familiar with Comet or CppCMS. But, yes, there are all kinds of CMS servers running behind the mentioned web servers and they all have to deal with this issue (and, yes, it is a pain).

(3) Timeouts are the only way, but you can mitigate the pain, so to speak. Have the client ping the server across the connection every N seconds when there is otherwise no activity. Doesn't have to do anything and you can tack stuff on the reply; notifications of concurrent edits or whatever you need.

You are correct in that it is surprising that mod_fastcgi doesn't support telling the backend that Apache has detected the disconnect or the connection timed out. And you aren't the first to be dismayed.

The second patch on this page should fix that particular issue:

http://osdir.com/ml/web.fastcgi.devel/2006-02/msg00015.html

纸短情长 2024-08-10 04:37:11

http://ncannasse.fr/blog/tora_comet

我没有任何具体信息给你,但本文确实提到他们可以检测客户端何时与 Apache 断开连接。请参阅tora.Queue。听起来 neko CVS 中提供了源代码,因此您也许可以在那里找到一些线索。祝你好运。

http://ncannasse.fr/blog/tora_comet

I don't have any concrete information for you, but this article does mention that they can detect when the client has disconnected from Apache. See tora.Queue. And it sounds like the source is available in the neko CVS, so you might be able to find some clues there. Good luck.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文