IIS file download hangs/timeouts - sc-win32-status

问题:

Any thoughts on why I might be getting tons of "hangs" when trying to download a file via HTTP, based on the following?

• Server is IIS 6
• File being downloaded is a binary file, rather than a web page
• Several clients hang, including TrueUpdate and FlexNet web updating packages, as well as custom .NET app that just does basic HttpWebRequest/HttpWebResponse logic and downloads using a response stream
• IIS log file signature when success is 200 0 0 (sc-status sc-substatus sc-win32-status)
• For failure, error signature is 200 0 64
• sc-win32-status of 64 is "the specified network name is no longer available"
• I can point firefox at the URL and download successfully every time (perhaps some retry logic is happening under the hood)

At this point, it seems like either there's something funky with my server that it's throwing these errors, or that this is just normal network behavior and I need to use (or write) a client that is more resilient to the failures.

Any thoughts?

回答1:

Perhaps your issue was a low level networking issue with the ISP as you speculated in your reply comment. I am experiencing a similar problem with IIS and some mysterious 200 0 64 lines appearing in the log file, which is how I found this post. For the record, this is my understanding of sc-win32-status=64; I hope someone can correct me if I'm wrong.

• sc-win32-status 64 means “The specified network name is no longer available.”
• After IIS has sent the final response to the client, it waits for an ACK message from the client.
• Sometimes clients will reset the connection instead of sending the final ACK back to server. This is not a graceful connection close, so IIS logs the “64” code to indicate an interruption.
• Many clients will reset the connection when they are done with it, to free up the socket instead of leaving it in TIME_WAIT/CLOSE_WAIT.
• Proxies may have a tendancy to do this more often than individual clients.

回答2:

I've spent two weeks investigating this issue. For me I had the scenario in which intermittent random requests were being prematurely terminated. This was resulting in IIS logs with status code 200, but with a win32-status of 64.

Our infrastructure includes two Windows IIS servers behind two NetScaler load balancers in HA mode.

In my particular case, the problem was that the NetScaler had a feature called "Intergrated Caching" turned on (http://support.citrix.com/proddocs/topic/ns-optimization-10-5-map/ns-IC-gen-wrapper-10-con.html).

After disabling this feature, the request interruptions ceased. And the site operated normally. I'm not sure how or why this was causing a problem, but there it is.

If you use a proxy or a load balancer, do some investigation of what features they have turned on. For me the cause was something between the client and the server interrupting the requests.

I hope that this explanation will at least save someone else's time.

回答3:

Spent three days on this. It was the timeout that was set to 4 seconds (curl php request). Solution was to increase the timeout setting:

//curl_setopt($ch, CURLOPT_TIMEOUT, 4); // times out after 4s
curl_setopt($ch, CURLOPT_TIMEOUT, 60); // times out after 60s

回答4:

You will have to use wireshare or network monitor to gather more data on this problem. Me think.

回答5:

I suggest you put Fiddler in between your server and your download client. This should reveal the differences between Firefox and other cients.

回答6:

Check the headers from the server, especially content-type, and content-length, it's possible that your clients don't recognize the format of the binary file and hang while waiting for bytes that never come, or maybe they close the underlying TCP connection, which may cause IIS to log the win32 status 64.