none
プロキシサーバ過負荷時のIEの挙動について RRS feed

  • 質問

  • プロキシサーバ過負荷時のIEの挙動について、ご教示ください。

    1) グループポリシーで「Internet Explorerのメンテナンスポリシー処理」を有効にします。

    2) グループポリシーで「グループポリシーオブジェクトが変更されていなくても処理する」を有効にします。

    3) グループポリシーで、プロキシサーバを指定します。

    4) グループポリシーで「自動構成の変更を許可しない」を有効にします。

    5) グループポリシーで「最初の実行時のカスタマイズの設定を実行できないようにする」を有効にします。

    上記条件で、クライアントのIEの接続設定を定義します。

    この状態で、プロキシサーバがたとえば過負荷などにより一定期間応答を返さなかった場合、IEはどのような挙動をとるのでしょう? 最終的に「ページを表示できません」となるのですが、「ページを表示できません」になるまでの間の挙動です。

    A) プロキシサーバの応答が返るまで一定の期間は待機する

    B) 他にプロキシサーバがないか探査を行う

    などを想像するのですが。

    ご教示くださいませ。

    2012年6月27日 5:02

回答

  • 単体での自動構成の設定と変わらない前提で書きますと、
     
    http://technet.microsoft.com/ja-jp/library/cc985352.aspx
    http://www.monyo.com/technical/windows/06.html

     
    事前に起動時に自動プロキシファイル(.pac)の場所を検出&読み込みしておいて、
    ネットワーク要求を行う単位で"接続に障害"検知時に、
    自動プロキシファイル(.pac)で指定された別のプロキシ サーバーへの接続するのだと思いました。
     
    重要そうなのは、
    A) WPADによる.pacファイルの自動探索と適用
    B) "接続に障害"の検知
    C) .pacファイルのreturn文字列によるアクティブスタンバイ切り替え(とロードバランス?)
     
    シーケンシャルに、A→B→Cがされると思いました。
    ※上の1文は、1要求内で処理を途中で保留したままオーバーラップするかどうかの話題のつもりで記載しています。
    (今のグループポリシー設定画面を見ていないため、足りなければご指摘お願いします)
     
    A) については、IETFのload_CFILE関数が参考になりました。(そこから色々改良があるようですが。)
    IE9ではフレームプロセス単位で管理するようになったようです。(翻訳版
     
    B) となる事象の候補として次を考えました。
     
    ①HTTPの輻輳系の応答をプロキシサーバが即時行う(503 Service Unavailableとか?) 
    ②TCPの接続は正常だったが、クライアントタイムアウト。(サーバ側タイムアウトの範囲内)
    ③TCPの接続は正常だったが、プロキシサーバ側のタイムアウト(クライアントタイムアウトの範囲内)
    ④TCPの接続要求の応答として輻輳系の応答をプロキシサーバが即時行う(接続キューフルですぐRST応答とか?)
    ⑤TCPの接続要求の応答がプロキシサーバ側からいつまでたってもされない(SYNリトライオーバー、21秒等)
     
    "接続の障害"だとすると④、⑤辺り思ったりします。(なんとなく)
     
    C) については、en.wikipediaから、次の設定イメージです。

     return "PROXY proxy1.example.com:8080; PROXY proxy2.example.com:8080";

    proxy1が"接続の障害"を検知した際に、proxy2に切り替わるのだ思いました。
    この切り替わり情報がフレームプロセスで保持(タブ間で共有)されるのかは、分かりませんが、
    そういうこともあるかもと思いました。
     
    実際は、同時並行リクエストされることが多いので、ユーザの見え方はさらにバリエーションがありそうです。

    2012年6月28日 14:39

すべての返信

  • 単体での自動構成の設定と変わらない前提で書きますと、
     
    http://technet.microsoft.com/ja-jp/library/cc985352.aspx
    http://www.monyo.com/technical/windows/06.html

     
    事前に起動時に自動プロキシファイル(.pac)の場所を検出&読み込みしておいて、
    ネットワーク要求を行う単位で"接続に障害"検知時に、
    自動プロキシファイル(.pac)で指定された別のプロキシ サーバーへの接続するのだと思いました。
     
    重要そうなのは、
    A) WPADによる.pacファイルの自動探索と適用
    B) "接続に障害"の検知
    C) .pacファイルのreturn文字列によるアクティブスタンバイ切り替え(とロードバランス?)
     
    シーケンシャルに、A→B→Cがされると思いました。
    ※上の1文は、1要求内で処理を途中で保留したままオーバーラップするかどうかの話題のつもりで記載しています。
    (今のグループポリシー設定画面を見ていないため、足りなければご指摘お願いします)
     
    A) については、IETFのload_CFILE関数が参考になりました。(そこから色々改良があるようですが。)
    IE9ではフレームプロセス単位で管理するようになったようです。(翻訳版
     
    B) となる事象の候補として次を考えました。
     
    ①HTTPの輻輳系の応答をプロキシサーバが即時行う(503 Service Unavailableとか?) 
    ②TCPの接続は正常だったが、クライアントタイムアウト。(サーバ側タイムアウトの範囲内)
    ③TCPの接続は正常だったが、プロキシサーバ側のタイムアウト(クライアントタイムアウトの範囲内)
    ④TCPの接続要求の応答として輻輳系の応答をプロキシサーバが即時行う(接続キューフルですぐRST応答とか?)
    ⑤TCPの接続要求の応答がプロキシサーバ側からいつまでたってもされない(SYNリトライオーバー、21秒等)
     
    "接続の障害"だとすると④、⑤辺り思ったりします。(なんとなく)
     
    C) については、en.wikipediaから、次の設定イメージです。

     return "PROXY proxy1.example.com:8080; PROXY proxy2.example.com:8080";

    proxy1が"接続の障害"を検知した際に、proxy2に切り替わるのだ思いました。
    この切り替わり情報がフレームプロセスで保持(タブ間で共有)されるのかは、分かりませんが、
    そういうこともあるかもと思いました。
     
    実際は、同時並行リクエストされることが多いので、ユーザの見え方はさらにバリエーションがありそうです。

    2012年6月28日 14:39
  • ご教示ありがとうございます。

    A)WPADによる.pacファイルの自動探索と適用

    上記がポイントになりそうですね。

    自身では調べきれなかった点や着眼点を頂きありがとうございます。

    2012年6月29日 8:14