诊断“请求超时” HttpException
在 StackOverflow 上，我们每天都会看到一些“请求超时”异常。
事实：
- 请求超时默认为 90 秒
- 仅在 POST 上
- 发生 发布的数据是文本，通常很小（< 1KB），但范围可以达到几 KB
- 服务器变量中没有捕获表单数据
- 客户端 UA 多种多样：IE5.5 - 7、Firefox 3.0.5、iPhone、Chrome
- 客户端位置多种多样：英国、法国、美国 - 北卡罗来纳州、俄亥俄州、内布拉斯加州、印第安纳州
我们测试了基于服务器的超时（即使用 Thread.Sleep）和所有表单变量在异常日志中被正确捕获 - 这使我们相信客户端在分配的时间内发送请求时遇到问题。
关于如何捕获/调试这种情况的任何想法都非常受欢迎！
Here on StackOverflow, we're seeing a few "Request timed out" exceptions every day.
The facts:
- Request timeout is the default 90 seconds
- Occurs only on POSTs
- Data posted is text, usually small (< 1KB), but can range to a few KB
- No Form data is captured in server variables
- Client UAs are diverse: IE5.5 - 7, Firefox 3.0.5, iPhone, Chrome
- Client locations are diverse: UK, France, USA - NC, OH, NE, IN
We've tested a server-based timeout (i.e. using Thread.Sleep) and all form variables are correctly captured in the exception log - this leads us to believe the client is having issues sending the request in the allotted time.
Any thoughts on how to trap/debug this condition are very welcome!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我在使用小型 AJAX Web 服务的生产服务器上也遇到了同样的问题。 在防火墙外进行数据包捕获后，我们发现服务的 POST 分为两个 TCP 段，而第二个段从未到达我们手中。 （第一个数据包仅包含标头，第二个丢失的数据包应该是 json 正文）所以基本上 IIS 只是坐在那里等待 POST 的其余部分。 配置的超时后，服务器向客户端发送 RST 数据包并记录“请求超时”错误 - 这是正确的行为。
我们试图获得客户端重现，但运气不佳，但在我们的例子中，这似乎完全与网络相关（或者可能是某些不喜欢帖子内容的“安全”软件）。
I've got the same problem on our production servers that use a small AJAX webservice. After doing packet captures outside our firewall, we found that the POST to the service was coming in two TCP segments and the second segment never got to us. (first packet only contains headers, the second missing packet should be the json body) So basically IIS is just sitting there waiting for the rest of the POST. After the configured timeout, the server sends a RST packet to the client and logs the "Request timed out" error - which is correct behavior.
We are trying to get a client repro without much luck, but in our case this appears to be completely network related (or possibly some "security" software that doesn't like the contents of the post).
如果您运行的是 IIS 7，则可以使用 请求跟踪失败。 我实际上并没有将它用于超时，我主要将其设置为仅捕获特定的 http 错误代码。 但我知道你可以让它转储任何花费超过 X 时间的请求的痕迹。
If you are running IIS 7 you could use the Failed Request Tracing. I haven't actually used it for timeouts, I mostly have set it up to capture just specific http error codes. But I know you can get it to dump traces of any request taking more than X amount of time.
您是否尝试过通过 telnet 手动发布，但根本没有完成发布。 我很想看看您是否可以复制您所看到的行为。 鉴于该网站的性质，如果您故意收到一些格式错误的 POST 来尝试破解系统，我不会感到惊讶。
我注意到有时我需要重新启动 Safari 才能在某些操作挂起后再次工作，但我认为这是我的问题。
Have you tried posting manually via telnet and simply not completing the POST. I'd be interested to see if you could replicate the behavior you are seeing. Given the nature of the site, I wouldn't be surprised if you were getting a few malformed POSTs intentionally to try and hack the system.
I have noticed on occasion that I need to restart Safari in order to get SO working again after some action hangs, but I assumed it was my problem.
本文介绍如何使用 Windbg 捕获此问题：
http://blogs.msdn.com/b/asiatech/archive/2012/06/21/how-to-troubleshoot-httpexception -请求超时-asp-net-4-0-64-bit.aspx
This article describes how to catch this using windbg:
http://blogs.msdn.com/b/asiatech/archive/2012/06/21/how-to-troubleshoot-httpexception-request-timed-out-asp-net-4-0-64-bit.aspx
我们过去经常在我们的高流量网络客户端中看到这些——想知道它是否相关。 据称发生的情况是 HttpWebRequest（我假设您在 HttpWebResponse 方面遇到问题？也许他们也有同样的问题）在幕后使用了一些混乱的线程池，即使您的请求是同步的。有时会出现死锁，因为堆栈中较高的其他 .NET 对象正在使用相同的系统线程池，并且一个对象会使另一个对象挨饿，最终导致超时。 我认为这个问题在这里更好地描述： http: //www.deez.info/sengelha/2005/03/03/beware-threadpools-and-httpwebrequest/
We used to see those a lot with our very high traffic web client -- wonder if it's related. What supposedly was happening was the HttpWebRequest (I'm assuming you're having problems with HttpWebResponse? Maybe they have the same issues) uses some janky thread pool underneath the covers, even when your requests are synchronous. Every now and then something would deadlock because some other .NET object higher in the stack was using the same system threadpool and one would starve the other out, eventually causing a timeout. I think the issue is better described here: http://www.deez.info/sengelha/2005/03/03/beware-threadpools-and-httpwebrequest/
我还会扫描您日志中的 IP 地址，看看是否是同一个人重复出现问题。 您知道，有些人可能仍在使用拨号帐户，或者他们的终端可能存在其他网络问题。 但是，当然，不要在没有进行尽可能多的调查的情况下就将其注销。
I would also scan the IP addresses in your logs to see if it's the same people having issues repeatedly. You know, it's just possible that some people are still using dial up accounts, or there may be other networking issues on their end. But, of course, don't just write it off without investigating as much as you can.
从 IIS6 切换到 IIS7 后，我们的网络服务器遇到了同样的“请求超时”问题。 我相信这个问题是 IIS7 特有的。 我的猜测是，在将请求传递给 ASP.Net 进行处理之前，这些错误在 IIS6 的处理链中被进一步吞没或忽略。 我今天将打开“失败请求跟踪”，看看是否可以捕获有关该问题的更多信息。 到目前为止，您对客户端原因的解释似乎是最有效的。
We are experiencing the same "Request timed out" issue with our webservers after switching from IIS6 to IIS7. I believe the issue is IIS7-specific. My guess is that these errors were swallowed or ignored further up the processing chain in IIS6, before the request was handed-off to ASP.Net for processing. I am turning on Failed Request Tracing today to see if I can trap any more information about the issue. So far it seems that your explanation of client-side causes seems the most valid.