none
レスポンスにContent-Lengthを含めない、もしくはクライアントをTIME_WAIT状態にさせない方法 RRS feed

  • 全般的な情報交換

  • ASP.NET 3.5で、テキストベースのWebサービスを作っています。
    (テキストベースの、というのは、asmxのようなSOAP Webサービスではなく、IHttpHandlerを拡張して自前でレスポンスを返すサービスだということです)

    これにアクセスするクライアントがMFCアプリケーションで、CHttpConnection, CHttpFileクラスを使っているのですが、ひとつ問題が出ています。

    ク ライアントがWebサービスにアクセスしレスポンスを受け取ったあと、クライアント側のソケットがTIME_WAIT状態で残ってしまうのです。 Content-Length分だけレスポンスを受け取ったらクライアントがソケットを閉じるので、TIME_WAIT状態になるのは当たり前の動作なの ですが…

    まれに、ポート番号をTIME_WAITで食い尽くしてしまってアクセスができなくなることがあり、負荷テストも途中で止まってしまいます。これでは困るので、

    ●クライアント側にソケットを閉じさせないようなHTTPレスポンスの仕方はないでしょうか?
    ●レスポンスにContent-Lengthが含まれなければサーバ主導でクローズできると思うのですが、Content-Lengthが自動で負荷されてしまうのを止める方法はないでしょうか?

    できれば、ASP.NET側だけで解決したいと思っています。

    ---------------------------------------
    (追記)
    クライアントもサーバもConnectionヘッダを付けないことで、(HTTP/1.1なので)自動的に持続的接続になることは確認できました。
    しかし、HTTPS通信にすると毎回クライアント側から切ってしまうようです。これはどうしたものでしょう。
    • 編集済み miuras_net 2010年1月21日 6:02 追記
    • 種類を変更済み miuras_net 2010年3月1日 6:41 フォーラムにふさわしい質問でなかったので
    2010年1月21日 4:13

すべての返信

  • もしかして、「ASP.NET 開発サーバー」を使用して、Webサービスをホストしていませんでしょうか?
    もしそうなら、IIS でホストして確認してみてください。
    2010年1月21日 8:37
  • 書き遅れました。アプリケーションサーバはIIS7.5です。

    しかし、Content-Lengthを付けないというのはサーバの動作としては無法ですよね。HTTPSの場合に切断してしまうクライアントの方に問題があるという気がしてきました。

    しばらくしたらこの質問はキャンセルするかもしれません。
    2010年1月22日 2:43
  • 切断しているのは、クライアントではなく、サーバーかもしれませんよね。
    ネットワークモニタを使って、最初の Fin または Rst パケットをどちら側から送信しているのか、確認してみてください。
    2010年1月22日 4:02
  • FINを送出しているのはクライアントです。
    ただ、MFCが切っているのかSSL/TLS層が切っているのかはわかりません。

    ASP.NETの質問ではなくなってきてしまいました。
    2010年2月8日 1:44