web-dev-qa-db-ja.com

IISファイルのダウンロードがハング/タイムアウトします-sc-win32-status = 64

次のことに基づいて、HTTP経由でファイルをダウンロードしようとすると、なぜ大量の「ハング」が発生する可能性があるのか​​についての考えはありますか？

  • サーバーはIIS 6
  • ダウンロードされるファイルは、Webページではなく、バイナリファイルです。
  • TrueUpdateおよびFlexNetWeb更新パッケージ、基本的なHttpWebRequest/HttpWebResponseロジックを実行し、応答ストリームを使用してダウンロードするカスタム.NETアプリなど、いくつかのクライアントがハングします。
  • 成功が2000 0の場合のIISログファイルの署名（sc-status sc-substatus sc-win32-status）
  • 失敗した場合、エラー署名は200 064です。
  • sc-win32-ステータス64は、「指定されたネットワーク名は使用できなくなりました」です。
  • FirefoxをURLにポイントして、毎回正常にダウンロードできます（おそらく、内部で再試行ロジックが発生しています）

この時点で、これらのエラーをスローしているサーバーに何かファンキーなものがあるか、これは単なる通常のネットワーク動作であり、障害に対してより回復力のあるクライアントを使用（または書き込み）する必要があるようです。

何かご意見は？

httpiisdownload
23
Sean Sexton

おそらくあなたの問題は、返信コメントで推測したように、ISPとの低レベルのネットワークの問題でした。 IISで、ログファイルに不思議な200 0 64行が表示されるという同様の問題が発生しています。これが、この投稿を見つけた方法です。記録として、これはsc-win32についての私の理解です。 -status = 64;私が間違っている場合、誰かが私を訂正してくれることを願っています。

  • sc-win32-status 64は、「指定されたネットワーク名は使用できなくなりました」という意味です。
  • IISがクライアントに最終応答を送信した後、クライアントからのACKメッセージを待ちます。
  • クライアントは、最終的なACKをサーバーに返送する代わりに、接続をリセットする場合があります。これは正常な接続のクローズではないため、IISは、中断を示すために「64」コードをログに記録します。
  • 多くのクライアントは、接続が終了すると接続をリセットして、ソケットをTIME_WAIT/CLOSE_WAITのままにする代わりに解放します。
  • プロキシは、個々のクライアントよりも頻繁にこれを行う傾向がある場合があります。
22
wweicker

私はこの問題を調査するために2週間を費やしました。私にとっては、断続的なランダムリクエストが途中で終了するというシナリオがありました。これにより、IISログのステータスコードは200ですが、win32-statusは64になります。

私たちのインフラストラクチャには、HAモードの2つのNetScalerロードバランサーの背後にある2つのWindows IISサーバーが含まれています。

私の特定のケースでは、問題は、NetScalerで「統合キャッシュ」と呼ばれる機能がオンになっていることでした（ http://support.citrix.com/proddocs/topic/ns-optimization-10-5-map/ ns-IC-gen-wrapper-10-con.html ）。

この機能を無効にした後、リクエストの中断は停止しました。そして、サイトは正常に動作しました。これがどのように、またはなぜ問題を引き起こしたのかはわかりませんが、問題はあります。

プロキシまたはロードバランサーを使用している場合は、それらがオンになっている機能を調査してください。私にとっての原因は、クライアントとサーバーの間でリクエストが中断されたことでした。

この説明が少なくとも他の誰かの時間を節約することを願っています。

6
infl3x

これに3日を費やしました。 4秒に設定されたのはタイムアウトでした（curl phpリクエスト）。解決策は、タイムアウト設定を増やすことでした。

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

サーバーとダウンロードクライアントの間に Fiddler を配置することをお勧めします。これにより、Firefoxと他のcientsの違いが明らかになるはずです。

0
mkoeller

この問題に関するより多くのデータを収集するには、ワイヤーシェアまたはネットワークモニターを使用する必要があります。私は思います。

0
Igal Serban

サーバーからのヘッダー、特にcontent-typeとcontent-lengthを確認してください。クライアントがバイナリファイルの形式を認識せず、決して来ないバイトを待っている間にハングするか、基になるTCP接続。これにより、IISがwin32ステータス64をログに記録する可能性があります。

0
Alessandro