windows x64 httpd 使用ie打开,一直在等待:无响应,不超时

正常的访问时间线应该是在1秒内结束,可惜出现这个怪现象时就不是,

因为从firefox中可以正常的使用,而当转用ie来访问时,有时会正常,比较刚启动httpd时,ie是首次打开的就可以,然后可能再刷新一下就出现这个现象了,接着firefox也因为ie出现问题而出现问题.

我怀疑是socket的实现不同触发了ms的socket实现上的bug,

从配置上看,已经把httpd的配置设置成,只配置必要的,其它的保持默认的,也就是排除了配置上的问题,

然后也尝试访问其它内容,也就是说完成排除了php问题的可能,从现象上看,已经可以确定是从浏览器到httpd和返回这块,就算php不使用,也存在问题,猜测可能在网络实现上存在问题,

之前安装的httpd是2.3版本,

现在下载的这个版本好像就不存在这个问题了.

从这个信息看来,编译者早就了解会存在这个问题,

给出如果出现问题时尝试使用以下配置试试,

Apache 2.4.4 Win32 and Win64 are now available here at the download pages. All flavors: VC9, VC10 and VC11

Changelog http://www.apachelounge.com/Changelog-2.4.html

Documentation: http://httpd.apache.org/docs/2.4/ attention there when you want to Upgrade to 2.4 from 2.2

When you have hangs, slow traffic and/or when having in your log entries like Asynchronous AcceptEx failed. You can try the following settings:

AcceptFilter http none
AcceptFilter https none
EnableSendfile Off
EnableMMAP off

从以下的运行命令显示来看,红字是关键

D:\web\apache>bin\httpd.exe -X
[Thu Mar 14 14:32:57.322270 2013] [core:warn] [pid 2216:tid 176] AH00098: pid file D:/web/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run?
[Thu Mar 14 14:32:57.353470 2013] [mpm_winnt:debug] [pid 2216:tid 176] mpm_winnt.c(1708): AH00453: Child process is running
[Thu Mar 14 14:32:57.353470 2013] [mpm_winnt:debug] [pid 2216:tid 176] child.c(955): AH00352: Child: Acquired the start mutex.
[Thu Mar 14 14:32:57.353470 2013] [mpm_winnt:notice] [pid 2216:tid 176] AH00354: Child: Starting 64 worker threads.
[Thu Mar 14 14:32:57.353470 2013] [mpm_winnt:debug] [pid 2216:tid 796] child.c(354): AH00334: Child: Accept thread listening on 127.0.0.1:80 using AcceptFilter data

从这上面的信息来看,我无法确定是什么原理导致的问题,

在写这个文章的,我还是能从overflowstack上面得到可能的原因

(I know the answer to this question. Posting this just to share the answer with the community)

My local (Windows 7) instance of Apache 2.4 experiences delaysor hang-ups when serving some URLs, depending on which browser I use to access these URLs.

With Firefox/Chrome, Apache is slow to respondon certain URLs. The sluggishness occurs about 20% of the time on any given URL. When it does occur, there's a 5-second delay during which Firefox displays a "Waiting for..." status.

With Internet Explorer 9, Apache simply hangsand stops serving any requests (with any browser) until it is restarted.

This seems to occur only with dynamic (PHP) requests, but not all of them. In fact, it only occurs on one specific site. Other PHP-based sites on the same machine work fine.

It may or may not be significant that the problematic site consists of a large number of subdomains (VirtualHosts).

Disabling the Windows Firewall and Comodo Firewall doesn't help.

The problem seems more frequent with "busier" pages (additional requests for IFRAMES etc.)

I've tried many changes to httpd.conf(such as disabling KeepAlive, EnableMMAP, HostnameLookups) but nothing seems to work.

Answer

Apparently, I am not allowed to post an actual answer (new user), so I'm posting it here for the time being:

The solution is to add the following to your httpd.conf:

AcceptFilter http noneAcceptFilter https none

On Windows, this has the effect of disabling the AcceptEx() API (part of WinSock), which offers some performance improvements, but probably conflicts with Comodo Firewall.

Putting Comodo Firewall in "Disabled" mode doesn't help because requests probably still go through Comodo's networking code. I think Comodo would have to be uninstalled completely to eliminate the problem (though I haven't tried it).

If you have a similar problem with Apache 2.2, you should use the Win32DisableAcceptEx directive instead.

References

Quoting from http://httpd.apache.org/docs/2.4/mod/core.html:

The default values on Windows are:

AcceptFilter http data

AcceptFilter https data

Window's mpm_winnt interprets the AcceptFilter to toggle the  AcceptEx() API, and does not support http protocol buffering. There  are two values which utilize the Windows AcceptEx() API and will  recycle network sockets between connections. data waits until data has  been transmitted as documented above, and the initial data buffer and  network endpoint addresses are all retrieved from the single  AcceptEx() invocation. connect will use the AcceptEx() API, also  retrieve the network endpoint addresses, but like none the connect  option does not wait for the initial data transmission.

On Windows, none uses accept() rather than AcceptEx() and will not  recycle sockets between connections. This is useful for network  adapters with broken driver support, as well as some virtual network  providers such as vpn drivers, or spam, virus or spyware filters.

See also: