在networking服务器上增加408个“请求超时”数目为null

从我做的一些研究中，这些是导致408消息的一些可能性。 您可以testing每个标识为您的案件相关的一个。

1）非常低的Apache TIMEOUT值 – 您的Web服务器可能会在客户端甚至有机会发送请求之前结束会话。

访问日志中的错误代码太多了

2） browser predictive optimization – 你可以很容易地testing这与不同的浏览器。 只要使用tail -f /var/log/apache2/access.log ，同时使用相关的关键词，这将在第一个search页面上显示您的网站，hover在指向您的网站的链接上，检查网站预览是否出现… ..所有这些没有点击打开您的网站的链接。

http://forum.linode.com/viewtopic.php?f=10&t=8048

3） denial of service attack – ddos​​温暖，如slow loris可以打开太多的连接到服务器，而不用发送一个单一的再见捆绑所有的Apache进程。

http://blog.spiderlabs.com/2011/07/advanced-topic-of-the-week-mitigating-slow-http-dos-attacks.html

来自上面linke的报价 –

“诀窍是打开与服务器的连接，但不发送单个字节，打开连接和等待几乎不需要攻击者的资源，但是它永久性地绑定了一个Apache进程，耐心等待请求。超时到期，然后closures连接从Apache 1.3.31开始，请求行超时被logging到访问日志中（状态码为408），请求行超时消息出现在错误日志中，并带有关卡信息。不会将这些消息logging到错误日志中，但正在努力添加与1.x分支中相同的function。

大部分的408代码服务器响应似乎是由于客户端超时，而不是向前看。 我正在排除所提到的情况下拒绝服务，我的服务器和引用的文章，因为点击次数很less。 我已经尝试过，但一直未能通过在OS X的Safari浏览器，Chrome浏览器或火狐浏览器的前瞻再现任何408错误。我也不会看到他们在大多数月份在本地（非公共）服务器，我期望，如果他们是正常的浏览器行为。 这可能是浏览器通过打开连接向前看，从来没有使用它们的请求，但我没有看到这种行为，足以说明这些公共服务器上408的数量。 虽然用空请求打开连接确实可以使连接开始，但是更有意义的是前瞻性地抓取资源或使用OPTIONS（我只能在罕见的跨站点和蜘蛛情况下才能看到）。

我在收到408个响应的IP地址列表上进行了一次DNS主机查询，而在轻微使用的公共服务器的日志中没有标识的资源，代理或请求大小。 我忽略了另外的67个IP，它们只与最后一个元组有区别，并且在每个元组中用第一个代表它们。 所以这是47个不同的客户端networking/ ISP。 Apache的TimeOut是默认的60秒。 在这47，20个生产的机器名称。 在这些机器中，中国大陆有10个（50％），美国有5个（25％，所有OH，OK和NH），巴西，英国，意大利和台湾之间有5个。 我也怀疑在27个IP地址中没有一个机器名的很大一部分也在中国，但是不能certificate这一点。

在67个被忽视的IP中，已经有63个被代表的是百度蜘蛛：baiduspider – *。crawl.baidu.com（如果这看起来太过分了，现在每月search量大于雅虎或者Bing，只有谷歌）。

如果是现代浏览器行为导致他们，我会预期在美国的比例更高。 我login的服务器在湾区。 相反，我认为这主要是networking拥塞导致连接花费很长时间来设置，并允许在连接被Apache丢弃或超时之前发送和接收完整的请求。 特别是由于需求增长造成的极度拥堵，中国跨境带宽不足和国家防火墙基础设施。 这也可能是故意伪造的连接重置，但没有理由期待这一点。 其余的是家庭用户，在其他地方连接不良或者不幸的设备情况。

我认为这个问题主要是客户端连接问题，但是您可能希望有一个和解的，非graphics的408错误页面。 虽然根据出站响应日志中显示的0大小来判断，但Apache并没有使用错误页面。

在我的情况下，Apache被超载。 答案是closuresKeepAlive并增加apache.conf中的MaxClients。

当我修改我的FastCGI服务器的Apacheconfiguration时，我遇到了这个问题。

将-idle-timeout值从60增加到900，给了我几个不眠之夜，因为我无法追踪这个小变化的408个错误。

很高兴我终于修复它回到这个60。