26

以下に基づいて、HTTP 経由でファイルをダウンロードしようとすると、大量の「ハング」が発生する理由について何か考えはありますか?

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

この時点で、これらのエラーをスローしているサーバーに異常があるように見えます。または、これは単なる通常のネットワーク動作であり、障害に対してより回復力のあるクライアントを使用 (または作成) する必要があるようです。

何かご意見は？

4

7 に答える 7

25

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

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

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

于 2009-05-06T23:10:47.420 に答える
0

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

于 2008-12-17T14:56:47.303 に答える
0

この問題に関するデータをさらに収集するには、wireshare またはネットワーク モニターを使用する必要があります。私は思う。

于 2008-12-16T20:25:13.380 に答える