JP6503988B2 - セッション制御方法およびセッション制御プログラム - Google Patents

Description

本発明はセッション制御方法およびセッション制御プログラムに関する。

従来、クライアントとサーバの間の通信には、コネクションを長時間維持しないステートレスな通信プロトコルを用いることが多かった。例えば、ＨＴＴＰ（Hypertext Transfer Protocol）の場合、クライアントがＨＴＴＰメッセージを送信したいときにサーバとの間でＴＣＰ（Transmission Control Protocol）コネクションを確立し、ひとまとまりのＨＴＴＰメッセージの送信が完了するとＴＣＰコネクションを切断する。ステートレス型の通信プロトコルは、クライアントとサーバの間で頻繁にデータを送信する場合や、双方向にリアルタイムにデータを送信する場合に、通信コストが大きくなりやすい。

これに対し、クライアントとサーバの間の通信に、コネクションを長時間維持するステートフルな通信プロトコルを用いることもできる。例えば、ＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ（Request for Comments）６４５５に、Ｗｅｂソケットの仕様が定義されている。Ｗｅｂソケットでは、クライアントとサーバがＴＣＰコネクションを確立し、ＴＣＰコネクション上でＷｅｂソケットメッセージを相互に送信する。確立されたＴＣＰコネクションは、ひとまとまりのＷｅｂソケットメッセージの送信が完了してもすぐに切断しなくてよく、クライアントまたはサーバが次のＷｅｂソケットメッセージを送信する際に引き続き使用することができる。

クライアントとサーバが通信可能な状態を維持しなくてよくなったときは、一方から他方に対してクローズを示すＷｅｂソケットメッセージ（クローズメッセージ）を送信する。クローズメッセージが送信されると、Ｗｅｂソケットより下位の通信レイヤのコネクションであるＴＣＰコネクションは不要になるため、ＴＣＰコネクションが切断される。ステートフル型の通信プロトコルは、クライアントとサーバの間で頻繁にデータを送信する場合や、双方向にリアルタイムにデータを送信する場合に、ステートレス型の通信プロトコルと比べて通信コストを小さく抑えることができる。

なお、第２の端末と通信する端末を、通信中に第１の端末から第３の端末に切り替えることができるセッション制御方法が提案されている。提案のセッション制御方法では、第１の端末で実行されるローカルプロキシが、第１の端末と第２の端末の間のセッションについての制御情報を保存しておく。ローカルプロキシは、ユーザから端末の切り替えが指示されると、制御情報に基づいて、第２の端末に第３の端末とセッションを確立するよう要求する。ローカルプロキシは、セッション確立が完了した旨の通知を第２の端末から受信すると、第１の端末と第２の端末の間のセッションを切断する。

また、クライアントが送信するリクエストメッセージを複数のサーバに振り分ける切替装置（ロードバランサ）が提案されている。提案の切替装置は、クライアントとの間にＴＣＰコネクションを確立し、クライアントからリクエストメッセージを受信する。切替装置は、複数のサーバのうちの１つを選択し、選択したサーバとの間にＴＣＰコネクションを確立し、選択したサーバにリクエストメッセージを転送する。切替装置は、選択したサーバからＦＩＮパケットを受信すると、選択したサーバとの間のＴＣＰコネクションを切断する。また、切替装置は、ＦＩＮパケットをクライアントに転送し、クライアントとの間のＴＣＰコネクションを切断する。

また、コンテンツを再生する端末を第１の端末から第２の端末に切り替えることができるシステムが提案されている。提案のシステムでは、第１の端末がコンテンツサーバとの間にセッションを確立し、コンテンツサーバからコンテンツの受信を開始する。端末を切り替える場合、第１の端末は、コンテンツサーバにコンテンツ配信の停止を要求し、アプリケーションサーバにセッションＩＤを通知する。第２の端末は、第１の端末が使用していたセッションＩＤをアプリケーションサーバから取得し、取得したセッションＩＤを指定してコンテンツサーバにコンテンツ配信の再開を要求する。

また、クライアントからの要求に応じて、複数のサーバを用いてクライアントにサービスを提供するロードバランサが提案されている。提案のロードバランサは、クライアントとの間にＴＣＰコネクションを確立し、クライアントからサービス要求を受信する。ロードバランサは、ＴＣＰコネクションの識別情報を含む「インタレスト」を生成し、複数のサーバに同報送信する。ロードバランサは、インタレストに対する応答が最も早いサーバを選択し、選択したサーバとクライアントとの間にセッションが確立するよう制御する。

また、ＳＳＬ（Secure Socket Layer）によってカプセル化されたパケットを、使用されている上位プロトコルに応じてフィルタリングする中継装置が提案されている。提案の中継装置は、複数の上位プロトコルそれぞれについて宛先のサーバと通信を試行し、通信が成功した上位プロトコルを判定する。中継装置は、通信が成功した上位プロトコルを、クライアントが使用しようとしている上位プロトコルであると推定し、推定した上位プロトコルに応じてパケットを中継するか破棄するか決定する。

特開２００５−３２１７２号公報 国際公開第２００６／１２６４０３号 国際公開第２０１０／０４９８６３号 特開２０１２−３８２９９号公報 特開２０１２−１４７４１５号公報

ところで、２つの装置の間にコネクションが維持されているときに、負荷や保守などの都合で一方の装置を切り替えたい場合がある。例えば、クライアントとサーバとがＷｅｂソケット通信のためにＴＣＰコネクションを維持しているときに、クライアントと通信するサーバを切り替えたい場合がある。一方の装置を切り替えると、通信アドレスが変わってしまうため、切り替え前のコネクションをそのまま使用し続けることができない。このため、他方の装置はコネクションが切断されて通信不可になり、切り替え後の装置とコネクションを確立し直すことになる。このとき、切り替え後の装置へのアクセスにユーザの操作を要することがあり、ユーザの利便性が低下するおそれがある。

一方の装置の切り替えの影響を軽減する方法としては、２つの装置の通信経路上でリバースプロキシなどの中継プロセスを実行する方法が考えられる。中継プロセスは、一方の装置とコネクションを確立し、これとは別に他方の装置とコネクションを確立し、２つのコネクションの間でメッセージを転送する。

しかし、中継プロセスは通常、上位の通信レイヤのメッセージの内容に関係なく、一方のコネクションから受信したメッセージを他方のコネクションに転送するに過ぎない。このため、一方の装置から他方の装置に対して、上位の通信レイヤの切断指示メッセージが発行されると、その切断指示メッセージも中継プロセスを超えて送信されてしまう。その結果、切断指示メッセージを受けて他方の装置がコネクションを切断してしまうという問題がある。例えば、リバースプロキシは通常、Ｗｅｂソケットメッセージをそのまま転送するため、サーバからクライアントに対するクローズメッセージも転送する。クローズメッセージを受けて、クライアントはＴＣＰコネクションを切断してしまう。

すなわち、中継プロセスを実行することで２つの装置の間のコネクションを分割しても、上位の通信レイヤの指示によって両方のコネクションが切断されてしまうことがある。
１つの側面では、本発明は、通信相手を切り替える際のコネクションの切断を抑制できるセッション制御方法およびセッション制御プログラムを提供することを目的とする。

１つの態様では、第１の装置と第２の装置とが中継プロセスを介して通信可能であり、第３の装置と第２の装置とが中継プロセスを介して通信可能であるシステムが実行する、セッション制御方法が提供される。中継プロセスの第１の装置側に確立された第１のコネクションと、中継プロセスの第２の装置側に確立された第２のコネクションとを対応付けた制御情報を記憶する。第１の装置から第２の装置に対して、第１のコネクションおよび第２のコネクションより上位の通信レイヤの切断指示メッセージが発行された場合、中継プロセスにおいて切断指示メッセージを終端し、また、切断指示メッセージの発行に応じて制御情報を更新する。第１の装置から第３の装置への切り替えが通知され、かつ、切断指示メッセージが発行されたことを制御情報が示している場合、中継プロセスの第３の装置側に確立された第３のコネクションを使用可能にし、第２のコネクションと第３のコネクションとが対応付けられるように制御情報を更新する。

また、１つの態様では、セッション制御プログラムが提供される。

１つの側面では、通信相手を切り替える際のコネクションの切断を抑制できる。

第１の実施の形態の情報処理システムの例を示す図である。 第２の実施の形態の情報処理システムの例を示す図である。 Ｗｅｂサーバのハードウェア例を示すブロック図である。 第２の実施の形態のサーバアプリケーションの配備例を示す図である。 ＨＴＴＰパケットとＷｅｂソケットパケットの例を示す図である。 Ｗｅｂソケットによる第１の通信例を示すシーケンス図である。 Ｗｅｂソケットによる第２の通信例を示すシーケンス図である。 Ｗｅｂソケットによる第３の通信例を示すシーケンス図である。 第２の実施の形態の移動制御の通信例を示すシーケンス図である。 配備計画サーバの状態遷移例を示す図である。 第２の実施の形態のリバースプロキシの機能例を示すブロック図である。 リバースプロキシが有する制御テーブルの例を示す図である。 配備計画サーバが有する制御テーブルの例を示す図である。 上り通信転送の手順例を示すフローチャートである。 下り通信転送の手順例を示すフローチャートである。 プロキシ状態制御の手順例を示すフローチャートである。 第３の実施の形態のサーバアプリケーションの配備例を示す図である。 Ｗｅｂソケットによる第４の通信例を示すシーケンス図である。 Ｗｅｂソケットによる第４の通信例を示すシーケンス図（続き）である。 第３の実施の形態の移動制御の通信例を示すシーケンス図である。 第３の実施の形態のリバースプロキシの機能例を示すブロック図である。

以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の情報処理システムの例を示す図である。

第１の実施の形態の情報処理システムは、中継プロセス１０、装置２１（第１の装置）、装置２２（第２の装置）および装置２３（第３の装置）を有する。装置２１〜２３は、情報処理装置やコンピュータと呼ばれるものであってもよい。装置２１〜２３は、ユーザが操作する端末装置（クライアントコンピュータなど）でもよいし、端末装置からアクセスされるサーバ装置（サーバコンピュータなど）でもよい。一例として、装置２２が端末装置であり、装置２１，２３がサーバ装置である形態が考えられる。

装置２１と装置２２とは、中継プロセス１０を介して通信可能である。また、装置２３と装置２２とは、中継プロセス１０を介して通信可能である。中継プロセス１０は、装置２１，２３と装置２２との間でデータを転送する。中継プロセス１０は、リバースプロキシであってもよい。例えば、中継プロセス１０は、装置２２から具体的な通信相手（装置２１または装置２３）を隠蔽する。中継プロセス１０は、装置２１に配置されてもよいし、装置２３に配置されてもよいし、装置２１〜２３と異なる装置に配置されてもよい。

ここで、装置２２の通信相手が最初は装置２１であり、装置２２の通信相手を途中で装置２１から装置２３に切り替える場合を考える。装置２１から装置２３への切り替えは、例えば、装置２１の負荷が高い場合、中継プロセス１０と装置２１の間の通信路が輻輳している場合、装置２１の保守作業を行う場合などに実行され得る。このとき、装置２２と通信するアプリケーションプロセスを、装置２１から装置２３に移動してもよい。

装置２２の通信相手が装置２１であるとき、中継プロセス１０は、装置２１側にコネクション１１を確立し、装置２２側にコネクション１２を確立する。コネクション１１，１２は、例えば、ＴＣＰコネクションである。中継プロセス１０が装置２１，２２と異なる他の装置（装置２３でもよい）に配置されている場合、例えば、当該他の装置と装置２１との間にコネクション１１が確立され、当該他の装置と装置２２との間にコネクション１２が確立される。中継プロセス１０が装置２１に配置されている場合、中継プロセス１０の装置２１側のコネクション１１は、装置２１に配置されたアプリケーションプロセスと中継プロセス１０との間の同一装置内のコネクションを意味する。

中継プロセス１０は、コネクション１１とコネクション１２とを対応付けた制御情報１５を記憶する。制御情報１５は、例えば、中継プロセス１０が配置された装置が有する記憶装置に記憶される。記憶装置は、ＲＡＭ（Random Access Memory）などの揮発性の記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）などの不揮発性の記憶装置でもよい。

中継プロセス１０は、制御情報１５に基づいて、コネクション１１とコネクション１２との間でデータを転送する。すなわち、中継プロセス１０は、コネクション１１から受信したデータをコネクション１２に送信し、コネクション１２から受信したデータをコネクション１１に送信する。コネクション１１，１２上で送信されるデータには、コネクション１１，１２より上位の通信レイヤのメッセージが含まれる。例えば、コネクション１１，１２がＴＣＰコネクションである場合、ＴＣＰより上位の通信プロトコルであるＷｅｂソケットのメッセージが、コネクション１１，１２上で送信され得る。

装置２２の通信相手を装置２１から装置２３に切り替える場合、通信アドレス（例えば、ＩＰ（Internet Protocol）アドレスやＴＣＰポート番号）が変わるため、コネクション１１を装置２３に引き継ぐことはできない。このとき、装置２１が装置２２に対して、コネクション１１，１２より上位の通信レイヤの切断指示メッセージ１４を送信することがある。コネクション１１，１２がＴＣＰコネクションである場合、切断指示メッセージ１４は、ＴＣＰの制御パケットであるＦＩＮパケットとは異なる。切断指示メッセージ１４の例として、Ｗｅｂソケットのクローズメッセージなどが挙げられる。

中継プロセス１０は、コネクション１１から切断指示メッセージ１４を受信すると、切断指示メッセージ１４を終端する。すなわち、中継プロセス１０は、切断指示メッセージ１４を、指定された宛先（装置２２）に転送せずに破棄する。切断指示メッセージ１４が装置２２に転送されると、装置２２は、上位の通信レイヤのサービスが終了または中断されたと認識することになり、コネクション１２を切断してしまう。一方、切断指示メッセージ１４が中継プロセス１０でブロックされると、装置２２は、上位の通信レイヤのサービスが継続していると認識し、コネクション１２を切断しない。

ただし、中継プロセス１０は、装置２２の通信相手を切り替えようとしている場合のみ切断指示メッセージ１４を終端し、それ以外の場合は切断指示メッセージ１４を装置２２に転送するようにしてもよい。通信相手を切り替えようとしているか否かは、このシステムを管理する管理サーバが中継プロセス１０に通知してもよい。また、中継プロセス１０は、切断指示メッセージ１４を受信すると、制御情報１５を更新して、切断指示メッセージ１４を受信したことを制御情報１５に反映させる。例えば、中継プロセス１０は、切断指示メッセージ１４を受信したことを示す情報を、コネクション１１と対応付けて制御情報１５に記録する。また、例えば、中継プロセス１０は、コネクション１１が不要になったことまたはコネクション１１を切断したことを、制御情報１５に記録する。

その後、中継プロセス１０は、装置２１から装置２３への切り替えの通知を受け付ける。切り替えの通知は、例えば、このシステムを管理する管理サーバが中継プロセス１０に通知する。切り替えの通知は、装置２１から装置２３へのアプリケーションプロセスの移動が完了したことを示す通知であってもよい。中継プロセス１０は、切り替えの通知があり、かつ、制御情報１５が切断指示メッセージ１４を既に受信したことを示している場合、装置２３側に確立されたコネクション１３を使用可能にする。

コネクション１３は、コネクション１１，１２と同じ種類のコネクションであり、例えば、ＴＣＰコネクションである。中継プロセス１０が装置２３と異なる他の装置（装置２１でもよい）に配置されている場合、例えば、当該他の装置と装置２３との間にコネクション１３が確立される。中継プロセス１０が装置２３に配置されている場合、中継プロセス１０の装置２３側のコネクション１３は、装置２３に配置されたアプリケーションプロセスと中継プロセス１０との間の同一装置内のコネクションを意味する。

中継プロセス１０は、切り替えの通知を受け付けてからコネクション１３を確立してもよいし、切り替えの通知を受け付ける前に予めコネクション１３を確立しておいてもよい。前者の場合、コネクション１３を使用可能にすることは、コネクション１３を確立することを含んでもよい。後者の場合、コネクション１３を使用可能にすることは、装置２２にコネクション１３を割り当てることを含んでもよい。また、コネクション１３を使用可能にすることは、コネクション１３に上位の通信レイヤのサービスを対応付ける（例えば、コネクション１３上で上位の通信レイヤのハンドシェイクを行う）ことを含んでもよい。

中継プロセス１０は、コネクション１３を使用可能にすると、コネクション１２とコネクション１３とを対応付け、その対応関係を示すように制御情報１５を更新する。例えば、コネクション１１とコネクション１２の対応関係に代えて、コネクション１２とコネクション１３の対応関係が制御情報１５に登録される。以降、中継プロセス１０は、制御情報１５に基づいて、コネクション１２とコネクション１３との間でデータを転送する。すなわち、中継プロセス１０は、コネクション１２から受信したデータをコネクション１３に送信し、コネクション１３から受信したデータをコネクション１２に送信する。

第１の実施の形態の情報処理システムによれば、装置２２の通信相手を装置２１から装置２３に切り替えるとき、装置２１から装置２２に対して発行された上位の通信レイヤの切断指示メッセージ１４が、中継プロセス１０において終端される。これにより、上位の通信レイヤのサービスが継続していると装置２２に認識させることができ、切断指示メッセージ１４に反応して装置２２がコネクション１２を切断してしまうことを抑制できる。

そして、切り替え完了後は、コネクション１２とコネクション１３が対応付けられ、中継プロセス１０によって装置２２と装置２３との間でデータが中継される。これにより、装置２２は、切り替え前に確立したコネクション１２を切り替え後も使用し続けることができ、新たにコネクションを確立し直さなくてよい。よって、装置２２のユーザは、ログイン手続などの操作を行わずに切り替え後もサービスを継続して利用することができ、ユーザの利便性が低下しないようにすることができる。

［第２の実施の形態］
次に、第２の実施の形態を説明する。
図２は、第２の実施の形態の情報処理システムの例を示す図である。

第２の実施の形態の情報処理システムは、クラウド３０、拠点４０，５０およびネットワーク６０を含む。クラウド３０および拠点４０，５０は、互いに離れた場所に設置されており、広域のネットワーク６０を介して接続されている。

クラウド３０は、複数の拠点から利用できる共有の情報処理施設であり、例えば、データセンタを用いて実現される。拠点４０，５０は、組織のメンバーが業務を行う施設であり、例えば、会社の従業員が業務を行うオフィスや工場である。

クラウド３０は、Ｗｅｂサーバ１００ａおよび配備計画サーバ２００を含む。拠点４０は、端末装置４１，４２、ＤＮＳ（Domain Name System）サーバ４３およびＷｅｂサーバ１００を含む。端末装置４１，４２、ＤＮＳサーバ４３およびＷｅｂサーバ１００は、拠点４０内のローカルのネットワーク４４に接続されている。ネットワーク４４は、ネットワーク６０に接続されている。拠点５０は、端末装置５１，５２、ＤＮＳサーバ５３およびＷｅｂサーバ１００ｂを含む。端末装置５１，５２、ＤＮＳサーバ５３およびＷｅｂサーバ１００ｂは、拠点５０内のローカルのネットワーク５４に接続されている。ネットワーク５４は、ネットワーク６０に接続されている。

端末装置４１，４２，５１，５２は、ユーザが操作するクライアントコンピュータである。端末装置４１，４２，５１，５２は、Ｗｅｂブラウザなどのクライアントアプリケーションを実行し、Ｗｅｂサーバ１００，１００ａ，１００ｂで実行されるサーバアプリケーションと通信する。ＤＮＳサーバ４３，５３は、ドメイン名とＩＰアドレスとの対応関係を管理するサーバコンピュータである。ＤＮＳサーバ４３は、端末装置４１，４２からドメイン名を指定したアドレス解決要求を受信し、ドメイン名に対応するＩＰアドレスを回答する。同様に、ＤＮＳサーバ５３は、端末装置５１，５２からドメイン名を指定したアドレス解決要求を受信し、ドメイン名に対応するＩＰアドレスを回答する。

Ｗｅｂサーバ１００，１００ａ，１００ｂは、クライアントアプリケーションに対してサービスを提供するサーバアプリケーションを実行することができる。サーバアプリケーションは、ＵＲＬによって識別される。第２の実施の形態では、サーバアプリケーションは、Ｗｅｂサーバ１００，１００ａ，１００ｂの間で移動することができる。端末装置４１，４２，５１，５２がサーバアプリケーションの位置を認識しなくてよいように、Ｗｅｂサーバ１００，１００ｂは更にリバースプロキシを実行する。

サーバアプリケーションに対しては、当該サーバアプリケーションが配置されたＷｅｂサーバに依存する実ＵＲＬとは別に、Ｗｅｂサーバに依存しない仮想ＵＲＬが付与される。ＤＮＳサーバ４３は、仮想ＵＲＬに対してＷｅｂサーバ１００のＩＰアドレスを対応付ける。これにより、端末装置４１，４２のユーザが仮想ＵＲＬを指定すると、クライアントアプリケーションはＷｅｂサーバ１００にアクセスすることになる。Ｗｅｂサーバ１００のリバースプロキシは、仮想ＵＲＬに対応するサーバアプリケーションがＷｅｂサーバ１００に存在しない場合、適切なＷｅｂサーバにアクセスを転送する。

同様に、ＤＮＳサーバ５３は、仮想ＵＲＬに対してＷｅｂサーバ１００ｂのＩＰアドレスを対応付ける。これにより、端末装置５１，５２のユーザが仮想ＵＲＬを指定すると、クライアントアプリケーションはＷｅｂサーバ１００ｂにアクセスすることになる。Ｗｅｂサーバ１００ｂのリバースプロキシは、仮想ＵＲＬに対応するサーバアプリケーションがＷｅｂサーバ１００ｂに存在しない場合、適切なＷｅｂサーバにアクセスを転送する。これにより、端末装置４１，４２，５１，５２のクライアントアプリケーションは、サーバアプリケーションの位置を意識せずにサーバアプリケーションと通信できる。

配備計画サーバ２００は、Ｗｅｂサーバ１００，１００ａ，１００ｂへのサーバアプリケーションの配置を制御するサーバコンピュータである。サーバアプリケーションの配置は、クラウド３０と拠点４０，５０との間の通信状況、Ｗｅｂサーバ１００，１００ａ，１００ｂの負荷、Ｗｅｂサーバ１００，１００ａ，１００ｂの保守スケジュールなどに応じて決定される。例えば、最初は、クラウド３０内のＷｅｂサーバ１００ａにサーバアプリケーションが配置される。拠点４０から当該サーバアプリケーションへのアクセスが多く、ネットワーク６０の遅延が大きい場合、Ｗｅｂサーバ１００ａからＷｅｂサーバ１００にサーバアプリケーションを移動することが考えられる。

なお、サーバアプリケーションの配置は、サーバアプリケーション毎、すなわち、仮想ＵＲＬ毎に変更することが可能である。また、図２では配備計画サーバ２００をクラウド３０に設置したが、拠点４０または拠点５０に設置することもできる。

図３は、Ｗｅｂサーバのハードウェア例を示すブロック図である。
Ｗｅｂサーバ１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６および通信インタフェース１０７を有する。ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６および通信インタフェース１０７は、バス１０８に接続されている。なお、端末装置４１，４２，５１，５２、ＤＮＳサーバ４３，５３、Ｗｅｂサーバ１００ａ，１００ｂおよび配備計画サーバ２００も、Ｗｅｂサーバ１００と同様のハードウェアを用いて実現することができる。

ＣＰＵ１０１は、プログラムの命令を実行する演算回路を含むプロセッサである。ＣＰＵ１０１は、ＨＤＤ１０３に記憶されたプログラムやデータの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。なお、ＣＰＵ１０１は複数のプロセッサコアを備えてもよく、Ｗｅｂサーバ１００は複数のプロセッサを備えてもよく、以下で説明する処理を複数のプロセッサまたはプロセッサコアを用いて並列に実行してもよい。また、複数のプロセッサの集合（マルチプロセッサ）を「プロセッサ」と呼んでもよい。

ＲＡＭ１０２は、ＣＰＵ１０１が実行するプログラムやＣＰＵ１０１が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。なお、Ｗｅｂサーバ１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。

ＨＤＤ１０３は、ＯＳ（Operating System）やミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。プログラムには、セッション制御プログラムが含まれる。なお、Ｗｅｂサーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。

画像信号処理部１０４は、ＣＰＵ１０１からの命令に従って、Ｗｅｂサーバ１００に接続されたディスプレイ１１１に画像を出力する。ディスプレイ１１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、プラズマディスプレイ、有機ＥＬ（ＯＥＬ：Organic Electro-Luminescence）ディスプレイなどを用いることができる。ただし、ディスプレイ１１１が、Ｗｅｂサーバ１００の筐体と一体に形成されていてもよい。

入力信号処理部１０５は、Ｗｅｂサーバ１００に接続された入力デバイス１１２から入力信号を取得し、ＣＰＵ１０１に出力する。入力デバイス１１２としては、マウスやタッチパネルやタッチパッドやトラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、Ｗｅｂサーバ１００に、複数の種類の入力デバイスが接続されていてもよい。ただし、入力デバイス１１２が、Ｗｅｂサーバ１００の筐体と一体に形成されていてもよい。

媒体リーダ１０６は、記録媒体１１３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体１１３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）、半導体メモリなどを使用できる。媒体リーダ１０６は、例えば、記録媒体１１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。

通信インタフェース１０７は、ネットワーク４４に接続され、ネットワーク４４を介して他の情報処理装置と通信を行うインタフェースである。通信インタフェース１０７は、スイッチなどの通信装置とケーブルで接続される有線通信インタフェースでもよいし、基地局と無線リンクで接続される無線通信インタフェースでもよい。

図４は、第２の実施の形態のサーバアプリケーションの配備例を示す図である。
Ｗｅｂサーバ１００は、リバースプロキシ１２０および実行環境１５０を実行する。Ｗｅｂサーバ１００ａは、リバースプロキシ１２０ａおよび実行環境１５０ａを実行する。Ｗｅｂサーバ１００ｂは、リバースプロキシ１２０ｂおよび実行環境１５０ｂを実行する。サーバアプリケーション１４０が、最初はＷｅｂサーバ１００ａで実行されており、その後にＷｅｂサーバ１００に移動する場合を考える。なお、第２の実施の形態では、リバースプロキシ１２０，１２０ｂはサーバアプリケーション１４０と直接通信するため、Ｗｅｂサーバ１００ａはリバースプロキシ１２０ａを実行しなくてもよい。

Ｗｅｂサーバ１００のＩＰアドレスは「１０．ｘ．ｘ．４０」である。Ｗｅｂサーバ１００ａのＩＰアドレスは「１０．ｘ．ｘ．３０」である。Ｗｅｂサーバ１００ｂのＩＰアドレスは「１０．ｘ．ｘ．５０」である。サーバアプリケーション１４０がＷｅｂサーバ１００ａに配置されている場合、サーバアプリケーション１４０には「ｗｓ：／／１０．ｘ．ｘ．３０：８８８０」を含む実ＵＲＬが付与される。サーバアプリケーション１４０がＷｅｂサーバ１００に配置されている場合、サーバアプリケーション１４０には「ｗｓ：／／１０．ｘ．ｘ．４０：８８８０」を含む実ＵＲＬが付与される。

一方、リバースプロキシ１２０，１２０ｂには「ｗｓ：／／ｖｕｒｌ：８０」を含む仮想ＵＲＬが付与される。実行環境１５０，１５０ａ，１５０ｂは、受信したアクセスをＵＲＬに応じて振り分ける。実行環境１５０は、「ｗｓ：／／ｖｕｒｌ：８０」を含むアクセスをリバースプロキシ１２０に転送する。サーバアプリケーション１４０がＷｅｂサーバ１００に配置されている場合、実行環境１５０は、「ｗｓ：／／１０．ｘ．ｘ．４０：８８８０」を含むアクセスをサーバアプリケーション１４０に転送する。

サーバアプリケーション１４０がＷｅｂサーバ１００ａに配置されている場合、実行環境１５０ａは、「ｗｓ：／／１０．ｘ．ｘ．３０：８８８０」を含むアクセスをサーバアプリケーション１４０に転送する。実行環境１５０ｂは、「ｗｓ：／／ｖｕｒｌ：８０」を含むアクセスをリバースプロキシ１２０ｂに転送する。

リバースプロキシ１２０，１２０ｂは、「ｗｓ：／／ｖｕｒｌ：８０」を含むアクセスを受信すると、その仮想ＵＲＬをサーバアプリケーション１４０の実ＵＲＬに変換してアクセスを転送する。サーバアプリケーション１４０がＷｅｂサーバ１００ａに配置されている場合、リバースプロキシ１２０，１２０ａは、「ｗｓ：／／ｖｕｒｌ：８０」を「ｗｓ：／／１０．ｘ．ｘ．３０：８８８０」に変換してアクセスを転送する。一方、サーバアプリケーション１４０がＷｅｂサーバ１００に配置されている場合、リバースプロキシ１２０，１２０ａは、「ｗｓ：／／ｖｕｒｌ：８０」を「ｗｓ：／／１０．ｘ．ｘ．４０：８８８０」に変換してアクセスを転送する。これにより、仮想ＵＲＬを指定したアクセスがサーバアプリケーション１４０に到達する。

また、実行環境１５０，１５０ａ，１５０ｂは、配備計画サーバ２００からの指示に応じてサーバアプリケーション１４０を移動する。例えば、移動元のＷｅｂサーバの実行環境は、移動先のＷｅｂサーバの実行環境に対してサーバアプリケーション１４０のプログラムを送信する。また、第２の実施の形態では、サーバアプリケーション１４０の移動にあたって内部状態も引き継ぐようにする。このため、プログラムと併せて、サーバアプリケーション１４０の実行状況を示す一時データも送信する。移動元のＷｅｂサーバの実行環境は、サーバアプリケーション１４０を停止する。移動先のＷｅｂサーバの実行環境は、受信したプログラムとデータに基づいてサーバアプリケーション１４０を起動する。

ところで、端末装置４１，４２，５１，５２およびＷｅｂサーバ１００，１００ａ，１００ｂは、ネットワーク層の通信プロトコルとしてＩＰを使用することができる。また、端末装置４１，４２，５１，５２およびＷｅｂサーバ１００，１００ａ，１００ｂは、トランスポート層の通信プロトコルとしてＴＣＰを使用することができる。また、端末装置４１，４２，５１，５２およびＷｅｂサーバ１００，１００ａ，１００ｂは、更に上位の通信プロトコルとして、ＨＴＴＰおよびＷｅｂソケットを使用することができる。端末装置４１，４２，５１，５２のクライアントアプリケーションとサーバアプリケーション１４０とは、ＨＴＴＰおよびＷｅｂソケットを用いて通信する。

図５は、ＨＴＴＰパケットとＷｅｂソケットパケットの例を示す図である。
（Ａ）ＨＴＴＰパケット６１は、ＴＣＰコネクション上で送信される。ＨＴＴＰパケット６１は、ＩＰヘッダ、ＴＣＰヘッダ、ＨＴＴＰヘッダおよびＨＴＴＰペイロードを含む。ＩＰヘッダは、宛先ＩＰアドレスと送信元ＩＰアドレスを含む。ＴＣＰヘッダは、宛先ポート番号と送信元ポート番号を含む。ＨＴＴＰヘッダは、ＵｐｇｒａｄｅおよびＣｏｎｎｅｃｔｉｏｎを含む。更に、ＨＴＴＰリクエストのＨＴＴＰヘッダは、メソッドを含む。ＨＴＴＰレスポンスのＨＴＴＰヘッダは、ステータス番号を含む。ＨＴＴＰペイロードは、上り通信におけるＰＯＳＴデータや、下り通信におけるＨＴＭＬ（HyperText Markup Language）ファイルなどのデータを含む。

メソッドは、ＧＥＴやＰＯＳＴなどの命令とＵＲＬとを含む。例えば、ＧＥＴメソッドは、ＵＲＬが示すサーバアプリケーションに対してコンテンツを要求するときに用いられる。ＰＯＳＴメソッドは、ＵＲＬが示すサーバアプリケーションに対してデータをアップロードするときに用いられる。ステータス番号は、サーバアプリケーションの処理結果を示す。例えば、「２００」は、ＨＴＴＰリクエストが正常に処理されたことを示す。「１０１」は、通信プロトコルをＨＴＴＰから他のものに切り替えることを示す。

Ｕｐｇｒａｄｅの項目は、通信プロトコルを切り替える場合に切り替え後の通信プロトコルを示す。Ｃｏｎｎｅｃｔｉｏｎの項目は、そのＨＴＴＰメッセージの後にＴＣＰコネクションをどのように取り扱うかを示す。例えば、「Ｃｌｏｓｅ」は、ＴＣＰコネクションを切断することを示す。「Ｕｐｇｒａｄｅ」は、ＴＣＰコネクションを維持し、そのＴＣＰコネクション上で上位の通信プロトコルを変更することを示す。

（Ｂ）Ｗｅｂソケットパケット６２は、ＴＣＰコネクション上で送信される。Ｗｅｂソケットパケット６２は、ＩＰヘッダ、ＴＣＰヘッダ、Ｗｅｂソケットヘッダ（ＷＳヘッダ）およびＷｅｂソケットペイロード（ＷＳペイロード）を含む。ＩＰヘッダとＴＣＰヘッダは、ＨＴＴＰパケット６１と同じである。ＷＳヘッダは、ＨＴＴＰヘッダよりもサイズが小さく軽量なヘッダであり、ＯｐＣｏｄｅを含む。ＷＳペイロードは、クライアントアプリケーションとサーバアプリケーションの一方から他方に送信されるデータを含む。

ＯｐＣｏｄｅは、ＷＳペイロードの形式や、送信元から宛先に対する命令を示す。ＯｐＣｏｄｅは、４ビットで表現することができる。例えば、「０（０ｘ０）」は、ＷＳペイロードが前のパケットの続きであることを示す。「１（０ｘ１）」は、ＷＳペイロードがテキストデータを含むことを示す。「２（０ｘ２）」は、ＷＳペイロードがバイナリデータを含むことを示す。「８（０ｘ８）」は、Ｗｅｂソケットによる通信の終了（クローズ）を示す。「９（０ｘ９）」は、疎通確認（ｐｉｎｇ）を示す。「１０（０ｘＡ）」は、疎通応答（ｐｉｎｇに対する応答）を示す。

ＨＴＴＰでは、ひとまとまりのＨＴＴＰメッセージの送信が完了する毎に、クライアントアプリケーションとサーバアプリケーションとの間のＴＣＰコネクションが切断される。例えば、クライアントアプリケーションが一のＷｅｂページを要求するＨＴＴＰリクエストを送信し、サーバアプリケーションが要求されたＷｅｂページに関するデータを含むＨＴＴＰレスポンスを返信すると、両者の間のＴＣＰコネクションは切断される。別のＷｅｂページを要求する場合には、改めてＴＣＰコネクションを確立することになる。

これに対し、Ｗｅｂソケットでは、クライアントアプリケーションがサーバアプリケーションの利用を開始してから終了するまでの間、原則として両者の間にＴＣＰコネクションが維持される。サーバアプリケーションの利用を開始してから終了するまでの一連の通信をＷｅｂソケットセッション（ＷＳセッション）と言うことがある。Ｗｅｂソケットは、クライアントアプリケーションとサーバアプリケーションの間で小さなデータが頻繁に送信される場合や、サーバアプリケーションからクライアントアプリケーションに対してデータがプッシュされる場合に利用されることがある。サーバアプリケーションの一例として、チャットアプリケーションが挙げられる。

クライアントアプリケーションおよびサーバアプリケーションそれぞれから見て、１つのＷＳセッションは１つのＴＣＰコネクションと対応する。クライアントアプリケーションまたはサーバアプリケーションは、通信相手からＯｐＣｏｄｅ＝０ｘ８を含むＷｅｂソケットメッセージ（クローズ通知）を受信すると、ＷＳセッションが終了または中断されたと認識する。すると、クライアントアプリケーションまたはサーバアプリケーションは、そのＷＳセッションに対応するＴＣＰコネクションを切断する。

クライアントアプリケーションがクローズ通知を受信した後、再びサーバアプリケーションのサービスを利用したい場合、改めてサーバアプリケーションとの間にＴＣＰコネクションを確立することになる。クライアントアプリケーションは、ＴＣＰコネクション上でログインなどの手続を行うことが考えられる。このとき、前のＷＳセッションを再開できる（前の内部状態を引き継ぐことができる）場合もあるし、前のＷＳセッションは終了しており新たなＷＳセッションを開始することになる場合もある。

図６は、Ｗｅｂソケットによる第１の通信例を示すシーケンス図である。
ここでは、サーバアプリケーション１４０がＷｅｂサーバ１００ａに配置されており、端末装置４１がＷｅｂサーバ１００ａとＷｅｂソケットによって通信する場合を考える。また、端末装置４１とＷｅｂサーバ１００ａとが、リバースプロキシ１２０を経由せずに直接通信すると仮定する。例えば、端末装置４１のユーザがサーバアプリケーション１４０の実ＵＲＬを入力した場合に、図６のような通信が発生する。

端末装置４１は、Ｗｅｂサーバ１００ａとの間でＴＣＰの３ウェイハンドシェイク（ＴＣＰハンドシェイク）を実行することで、ＴＣＰコネクションを確立する（Ｓ１１０）。すなわち、端末装置４１は、ＳＹＮパケット（ＳＹＮ＝１，ＡＣＫ＝０のパケット）をＷｅｂサーバ１００ａに送信する。Ｗｅｂサーバ１００ａは、ＳＹＮ−ＡＣＫパケット（ＳＹＮ＝１，ＡＣＫ＝１のパケット）を端末装置４１に送信する。端末装置４１は、ＡＣＫパケット（ＳＹＮ＝０，ＡＣＫ＝１のパケット）をＷｅｂサーバ１００ａに送信する。ＳＹＮビットは接続要求を示し、ＡＣＫビットは接続要求に対する許可応答を示す。

端末装置４１は、ＴＣＰコネクション上でＷＳハンドシェイク要求をＷｅｂサーバ１００ａに送信する（Ｓ１１１）。ＷＳハンドシェイク要求は、ＨＴＴＰヘッダのＵｐｇｒａｄｅを「ｗｅｂｓｏｃｋｅｔ」に設定したＨＴＴＰリクエストである。Ｗｅｂサーバ１００ａは、ＷＳハンドシェイク要求を受信すると、ＴＣＰコネクション上でＷＳハンドシェイク応答を端末装置４１に送信する（Ｓ１１２）。ＷＳハンドシェイク応答は、ＨＴＴＰヘッダのステータス番号を「１０１」、Ｕｐｇｒａｄｅを「ｗｅｂｓｏｃｋｅｔ」、Ｃｏｎｎｅｃｔｉｏｎを「Ｕｐｇｒａｄｅ」に設定したＨＴＴＰレスポンスである。

なお、Ｗｅｂソケットハンドシェイク（ＷＳハンドシェイク）は、ＴＣＰコネクション上でＷｅｂソケットの通信を可能にする（ＷＳセッションを開始する）ための手続である。ＷＳハンドシェイクは、Ｏｐｅｎｉｎｇハンドシェイクと言うこともある。

これにより、以降は端末装置４１とＷｅｂサーバ１００ａの間で、アプリケーション層の通信プロトコルとしてＨＴＴＰに代えてＷｅｂソケットが使用される。例えば、端末装置４１は、ＴＣＰコネクション上で、ＷｅｂソケットのデータをＷｅｂサーバ１００ａに送信する（Ｓ１１３）。Ｗｅｂサーバ１００ａは、端末装置４１からのアクセスを待たずに端末装置４１にデータを送信することもできる。

Ｗｅｂソケットの通信を終了する場合、Ｗｅｂサーバ１００ａは、ＴＣＰコネクション上でクローズ通知を端末装置４１に送信する（Ｓ１１４）。クローズ通知は、前述の通り、ＷＳヘッダのＯｐＣｏｄｅを「０ｘ８」に設定したＷｅｂソケットメッセージである。端末装置４１は、Ｗｅｂサーバ１００ａからクローズ通知を受信すると、端末装置４１とＷｅｂサーバ１００ａとの間のＴＣＰコネクションを切断する（Ｓ１１５）。すなわち、端末装置４１は、Ｗｅｂサーバ１００ａにＦＩＮパケットを送信する。Ｗｅｂサーバ１００ａは、端末装置４１にＦＩＮパケットを返信する。

ＴＣＰコネクションは、ステップＳ１１０でＴＣＰハンドシェイクが行われてから、ステップＳ１１５で切断されるまで維持されることになる。ＴＣＰコネクション上に形成されるＷＳセッションは、ステップＳ１１２でＷＳハンドシェイクが完了してからステップＳ１１４でクローズ通知が送信されるまで維持されることになる。

次に、端末装置４１がサーバアプリケーション１４０との間にＴＣＰコネクションを維持しているときに、サーバアプリケーション１４０を移動する場合の問題点を説明する。
図７は、Ｗｅｂソケットによる第２の通信例を示すシーケンス図である。

ここでは、サーバアプリケーション１４０は最初にＷｅｂサーバ１００ａに配置されており、その後にＷｅｂサーバ１００に移動するものとする。また、図６と同様に、端末装置４１とＷｅｂサーバ１００，１００ａとが、リバースプロキシ１２０を経由せずに直接通信すると仮定する。

端末装置４１は、Ｗｅｂサーバ１００ａとＴＣＰハンドシェイクを行い、端末装置４１とＷｅｂサーバ１００ａとの間にＴＣＰコネクションを確立する（Ｓ１２０）。端末装置４１は、ＨＴＴＰによりＷＳハンドシェイク要求をＷｅｂサーバ１００ａに送信する（Ｓ１２１）。Ｗｅｂサーバ１００ａは、ＨＴＴＰによりＷＳハンドシェイク応答を端末装置４１に送信する（Ｓ１２２）。端末装置４１は、ＷＳセッションの中でＷｅｂソケットのデータをＷｅｂサーバ１００ａに送信する（Ｓ１２３）。

ここで、配備計画サーバ２００がサーバアプリケーション１４０をＷｅｂサーバ１００ａからＷｅｂサーバ１００に移動すると決定したとする。配備計画サーバ２００がＷｅｂサーバ１００ａに移動を指示すると、上記のＴＣＰコネクションを維持できないため、Ｗｅｂサーバ１００ａはクローズ通知を端末装置４１に送信する（Ｓ１２４）。端末装置４１は、クローズ通知を受信するとＴＣＰコネクションを切断する（Ｓ１２５）。

クローズ通知を受信すると、端末装置４１からは、サーバアプリケーション１４０側の都合によってサービスが突然利用できなくなった（例えば、サービスから強制的にログアウトさせられた）ように見える。端末装置４１のクライアントアプリケーションは、例えば、サービスが利用不可になったことをユーザに通知する。サーバアプリケーション１４０のサービスを再び利用したい場合、端末装置４１は、Ｗｅｂサーバ１００にアクセスすることになる。このとき、端末装置４１のユーザが、適切なＵＲＬを入力する、ユーザＩＤとパスワードを指定してログインするなどの操作を要する場合がある。

端末装置４１は、Ｗｅｂサーバ１００とＴＣＰハンドシェイクを行い、端末装置４１とＷｅｂサーバ１００との間にＴＣＰコネクションを確立する（Ｓ１２６）。端末装置４１は、ＨＴＴＰによりＷＳハンドシェイク要求をＷｅｂサーバ１００に送信する（Ｓ１２７）。Ｗｅｂサーバ１００は、ＨＴＴＰによりＷＳハンドシェイク応答を端末装置４１に送信する（Ｓ１２８）。端末装置４１は、ＷＳセッションの中でＷｅｂソケットのデータをＷｅｂサーバ１００に送信する（Ｓ１２９）。

正常にＷＳセッションを終了する場合、Ｗｅｂサーバ１００は、クローズ通知を端末装置４１に送信する（Ｓ１３０）。端末装置４１は、クローズ通知を受信するとＴＣＰコネクションを切断する（Ｓ１３１）。ただし、端末装置４１からＷｅｂサーバ１００にクローズ通知を送信することも可能である。

ステップＳ１２０からステップＳ１２５まで１つのＴＣＰコネクションが維持され、ステップＳ１２６からステップＳ１３１まで１つのＴＣＰコネクションが維持されている。一方、ステップＳ１２５とステップＳ１２６の間はＴＣＰコネクションが存在しない。

また、端末装置４１から見て、ステップＳ１２２からステップＳ１２４までとステップＳ１２８からステップＳ１３０までは、ＷＳセッションが維持されている。一方、端末装置４１から見て、ステップＳ１２５とステップＳ１２６の間はＷＳセッションが利用不可である。なお、端末装置４１からは、ステップＳ１２４でＷＳセッションが終了し、ステップＳ１２８で新たなＷＳセッションが開始されたように見えることがある。また、端末装置４１からは、ステップＳ１２４でＷＳセッションが中断され、ステップＳ１２８で当該ＷＳセッションが再開されたように見えることがある。

このように、Ｗｅｂソケット通信を行うサーバアプリケーション１４０を移動すると、端末装置４１のユーザの利便性が低下するおそれがある。そこで、第２の実施の形態では、リバースプロキシ１２０を利用することで、端末装置４１からＴＣＰコネクションの切断を隠蔽し、移動中もＷＳセッションが継続しているように見せるようにする。

図８は、Ｗｅｂソケットによる第３の通信例を示すシーケンス図である。
ここでは、図７と同様に、サーバアプリケーション１４０が最初にＷｅｂサーバ１００ａに配置されており、その後にＷｅｂサーバ１００に移動するものとする。ただし、端末装置４１は、リバースプロキシ１２０経由でサーバアプリケーション１４０と通信する。

端末装置４１は、リバースプロキシ１２０とＴＣＰハンドシェイクを行い、端末装置４１とリバースプロキシ１２０との間にＴＣＰコネクションを確立する（Ｓ１４０）。端末装置４１は、サーバアプリケーション１４０の仮想ＵＲＬを指定したＷＳハンドシェイク要求をリバースプロキシ１２０に送信する（Ｓ１４１）。リバースプロキシ１２０は、仮想ＵＲＬをサーバアプリケーション１４０の実ＵＲＬに変換する。

リバースプロキシ１２０は、Ｗｅｂサーバ１００ａに配置されたサーバアプリケーション１４０とＴＣＰハンドシェイクを行い、リバースプロキシ１２０とサーバアプリケーション１４０との間にＴＣＰコネクションを確立する（Ｓ１４２）。リバースプロキシ１２０は、サーバアプリケーション１４０の実ＵＲＬを指定したＷＳハンドシェイク要求をサーバアプリケーション１４０に送信する（Ｓ１４３）。

サーバアプリケーション１４０は、ＷＳハンドシェイク応答をリバースプロキシ１２０に送信する。リバースプロキシ１２０は、ＷＳハンドシェイク応答を端末装置４１に転送する（Ｓ１４４）。端末装置４１は、Ｗｅｂソケットのデータをリバースプロキシ１２０に送信する。リバースプロキシ１２０は、Ｗｅｂソケットのデータをサーバアプリケーション１４０に転送する（Ｓ１４５）。

ここで、配備計画サーバ２００がサーバアプリケーション１４０をＷｅｂサーバ１００ａからＷｅｂサーバ１００に移動すると決定したとする。配備計画サーバ２００がサーバアプリケーション１４０に移動指示を送信すると、サーバアプリケーション１４０はクローズ通知をリバースプロキシ１２０に送信する（Ｓ１４６）。リバースプロキシ１２０は、受信したクローズ通知を終端する。すなわち、リバースプロキシ１２０は、クローズ通知を端末装置４１に転送せずに破棄する。なお、後述するように、リバースプロキシ１２０は、配備計画サーバ２００から移動開始通知を受信した場合のみクローズ通知を終端し、それ以外の場合は通常のＷｅｂソケットメッセージと同様に転送することになる。

リバースプロキシ１２０は、クローズ通知を受信すると、リバースプロキシ１２０とサーバアプリケーション１４０との間のＴＣＰコネクションを切断する（Ｓ１４７）。一方、リバースプロキシ１２０は、端末装置４１とリバースプロキシ１２０との間のＴＣＰコネクションは切断しない。クローズ通知が端末装置４１に転送されないため、端末装置４１によっても当該ＴＣＰコネクションは切断されない。

端末装置４１は、ＷＳセッションが継続していると認識しているため、Ｗｅｂソケットのデータをリバースプロキシ１２０に送信する（Ｓ１４８）。リバースプロキシ１２０は、リバースプロキシ１２０とサーバアプリケーション１４０との間にＴＣＰコネクションが存在しないため、受信したデータをバッファに保存しておく。

そして、リバースプロキシ１２０は、後述するように配備計画サーバ２００から移動完了通知を受信すると、Ｗｅｂサーバ１００に移動したサーバアプリケーション１４０とＴＣＰハンドシェイクを行い、ＴＣＰコネクションを確立する（Ｓ１４９）。このＴＣＰコネクションは、Ｗｅｂサーバ１００の内部に形成されたコネクションである。リバースプロキシ１２０は、ＷＳハンドシェイク要求をサーバアプリケーション１４０に送信する（Ｓ１５０）。サーバアプリケーション１４０は、ＷＳハンドシェイク応答をリバースプロキシ１２０に送信する（Ｓ１５１）。リバースプロキシ１２０は、バッファに保存されたデータをサーバアプリケーション１４０に転送する（Ｓ１５２）。

なお、前述のように、サーバアプリケーション１４０をＷｅｂサーバ１００ａからＷｅｂサーバ１００に移動するとき、ＷＳセッションの状態を示す一時データ（セッションデータ）も移動する。このため、サーバアプリケーション１４０は、ステップＳ１４６のクローズ通知を送信する前の文脈（コンテキスト）を引き継ぐことができる。

正常にＷＳセッションを終了する場合、サーバアプリケーション１４０は、クローズ通知をリバースプロキシ１２０に送信する。リバースプロキシ１２０は、配備計画サーバ２００から移動開始通知を受信していないため、通常のＷｅｂソケットメッセージと同様にクローズ通知を端末装置４１に転送する（Ｓ１５３）。また、リバースプロキシ１２０は、リバースプロキシ１２０とサーバアプリケーション１４０との間のＴＣＰコネクションを切断する。端末装置４１は、クローズ通知を受信すると、端末装置４１とリバースプロキシ１２０との間のＴＣＰコネクションを切断する（Ｓ１５４）。

サーバアプリケーション１４０から見て、ステップＳ１４２からステップＳ１４７まで１つのＴＣＰコネクションが維持され、ステップＳ１４９からステップＳ１５４まで１つのＴＣＰコネクションが維持されている。サーバアプリケーション１４０から見て、ステップＳ１４７とステップＳ１４９の間はＴＣＰコネクションが存在しない。

これに対し、端末装置４１から見て、ステップＳ１４０からステップＳ１５４までＴＣＰコネクションが切断されずに維持されている。また、端末装置４１からは、ステップＳ１４４からステップＳ１５３までＷＳセッションが継続しているように見える。また、サーバアプリケーション１４０の移動の際にはセッションデータも移動する。よって、端末装置４１は、サーバアプリケーション１４０の移動を意識せずに通信を継続できる。

図９は、第２の実施の形態の移動制御の通信例を示すシーケンス図である。
配備計画サーバ２００は、サーバアプリケーション１４０をＷｅｂサーバ１００ａからＷｅｂサーバ１００に移動することを決定する。すると、配備計画サーバ２００は、Ｗｅｂサーバ１００のリバースプロキシ１２０とＷｅｂサーバ１００ｂのリバースプロキシ１２０ｂに、移動開始通知を送信する（Ｓ１６０）。移動開始通知は、移動するサーバアプリケーション１４０を特定できるように仮想ＵＲＬを含む。リバースプロキシ１２０，１２０ｂは、移動開始通知に対する応答を配備計画サーバ２００に送信する（Ｓ１６１）。

配備計画サーバ２００は、サーバアプリケーション１４０に停止指示を送信する。サーバアプリケーション１４０は、Ｗｅｂソケットのために維持しているＴＣＰコネクション毎にクローズ通知を送信する（Ｓ１６２）。例えば、サーバアプリケーション１４０は、リバースプロキシ１２０，１２０ｂに１または２以上のクローズ通知を送信する。このクローズ通知は、図８のステップＳ１４６のクローズ通知に対応する。

配備計画サーバ２００は、Ｗｅｂサーバ１００ａの実行環境１５０ａに移動指示を送信する。実行環境１５０ａは、サーバアプリケーション１４０のプログラムとその内部状態を示すセッションデータをＷｅｂサーバ１００に送信する（Ｓ１６３）。実行環境１５０ａは、サーバアプリケーション１４０を停止させる。Ｗｅｂサーバ１００の実行環境１５０は、プログラムとセッションデータによりサーバアプリケーション１４０を起動する。

配備計画サーバ２００は、リバースプロキシ１２０，１２０ｂに移動完了通知を送信する（Ｓ１６４）。移動完了通知は、移動したサーバアプリケーション１４０を特定できるように仮想ＵＲＬを含む。また、移動完了通知は、メッセージをサーバアプリケーション１４０に転送できるように移動後の実ＵＲＬ（移動前のものとは異なる）を含む。

図１０は、配備計画サーバの状態遷移例を示す図である。
配備計画サーバ２００は、最初は起動されていない停止状態７１にある。配備計画サーバ２００は、起動されると停止状態７１から定常状態７２に遷移する。定常状態７２は、サーバアプリケーションの現在の配置を維持している状態である。配備計画サーバ２００は、定常状態７２において、Ｗｅｂサーバ１００，１００ａ，１００ｂの負荷やサーバアプリケーションの通信の遅延時間などを示す負荷情報を収集する。

配備計画サーバ２００は、負荷情報に基づいてサーバアプリケーションの移動を要すると判断すると、定常状態７２から移動計画中状態７３に遷移する。配備計画サーバ２００は、移動計画中状態７３において、移動するサーバアプリケーションと移動先のＷｅｂサーバを示す移動計画を決定する。移動計画が決定すると、配備計画サーバ２００は、移動計画中状態７３から移動開始通知状態７４に遷移する。

配備計画サーバ２００は、移動開始通知状態７４において、各リバースプロキシに移動開始通知を送信し、移動開始通知に対する応答を待つ。全てのリバースプロキシから移動開始通知に対する応答を受信すると、配備計画サーバ２００は、移動開始通知状態７４から移動中状態７５に遷移する。配備計画サーバ２００は、移動中状態７５において、移動するサーバアプリケーションに対して停止指示を送信する。また、配備計画サーバ２００は、移動元のＷｅｂサーバに対して移動指示を送信する。

サーバアプリケーションの移動が完了すると、配備計画サーバ２００は、移動中状態７５から移動完了通知状態７６に遷移する。配備計画サーバ２００は、移動完了通知状態７６において、各リバースプロキシに移動完了通知を送信する。そして、配備計画サーバ２００は、移動完了通知状態７６から定常状態７２に遷移する。このようにして、配備計画サーバ２００は、サーバアプリケーションの配置を継続的に見直し、Ｗｅｂサーバ１００，１００ａ，１００ｂへのサーバアプリケーションの配置を最適化する。

次に、リバースプロキシ１２０，１２０ｂの機能について説明する。以下では、リバースプロキシ１２０，１２０ｂのうち代表してリバースプロキシ１２０を説明する。リバースプロキシ１２０ｂも、リバースプロキシ１２０と同様の機能を有する。

図１１は、第２の実施の形態のリバースプロキシの機能例を示すブロック図である。
リバースプロキシ１２０は、制御情報記憶部１２１、データ記憶部１２２および状態制御部１２３を有する。また、リバースプロキシ１２０は、サーバ機能部１３１、ソケット検索部１３２，１３８、端末情報保存部１３３、データ保留部１３４、宛先解決部１３５、ＵＲＬ書換部１３６、クライアント機能部１３７およびクローズ無効化部１３９を有する。制御情報記憶部１２１およびデータ記憶部１２２は、例えば、ＲＡＭ１０２またはＨＤＤ１０３に確保した記憶領域を用いて実装される。他のユニットは、例えば、ＣＰＵ１０１が実行するプログラムモジュールを用いて実装される。

制御情報記憶部１２１は、ＨＴＴＰメッセージやＷｅｂソケットメッセージの転送に用いられる各種の制御情報を記憶する。制御情報の詳細は後述する。データ記憶部１２２は、サーバアプリケーション１４０が移動中である場合に、端末装置４１，４２から受信したメッセージを一時的に格納するバッファである。状態制御部１２３は、配備計画サーバ２００から、移動開始通知や移動完了通知などの各種の通知を受信する。状態制御部１２３は、受信した通知に応じて、制御情報記憶部１２１に記憶された制御情報を更新する。

サーバ機能部１３１は、端末装置４１，４２に対してサーバアプリケーションとして振る舞う。サーバ機能部１３１は、端末装置４１，４２からの要求に応じて端末装置４１，４２との間にＴＣＰコネクションを確立する。サーバ機能部１３１は、ＴＣＰコネクション毎に、論理的な通信インタフェースであるソケットを生成する。サーバ機能部１３１は、ソケットの番号によってＴＣＰコネクションを区別する。サーバ機能部１３１は、ソケットから（端末装置４１，４２から）メッセージを受信する。また、サーバ機能部１３１は、ソケットを指定して（端末装置４１，４２に対して）メッセージを送信する。

ソケット検索部１３２は、サーバ機能部１３１がメッセージを受信すると、制御情報記憶部１２１に記憶された制御情報を参照して、メッセージが受信されたソケットに対応するクライアント機能部１３７側のソケットを検索する。検索されるソケットは、リバースプロキシ１２０とサーバアプリケーション１４０との間のＴＣＰコネクションに対応するソケットである。端末情報保存部１３３は、受信されたメッセージがＨＴＴＰメッセージである場合、ＨＴＴＰヘッダを制御情報記憶部１２１に保存する。

データ保留部１３４は、制御情報記憶部１２１に記憶された制御情報を参照して、サーバアプリケーション１４０が移動中であるか判定する。サーバアプリケーション１４０が移動中である場合、データ保留部１３４は、受信されたメッセージをデータ記憶部１２２に保存する。サーバアプリケーション１４０の移動が完了すると、データ保留部１３４は、データ記憶部１２２に記憶されているメッセージを、サーバアプリケーション１４０に転送すべきメッセージとして取り出す。ただし、記憶されたメッセージがＷｅｂソケットメッセージである場合、データ保留部１３４は、それに先立ってサーバアプリケーション１４０に送信すべきＨＴＴＰメッセージとして、ＷＳハンドシェイク要求を生成する。ＷＳハンドシェイク要求には、リバースプロキシ１２０が端末装置４１，４２であるかのように振る舞うため、端末情報保存部１３３が保存したＨＴＴＰヘッダが付加される。

宛先解決部１３５は、転送すべきメッセージがＨＴＴＰメッセージである場合、制御情報記憶部１２１に記憶された制御情報を参照して、ＨＴＴＰメッセージに含まれる仮想ＵＲＬに対応する実ＵＲＬを検索する。また、宛先解決部１３５は、転送すべきメッセージがＷｅｂソケットメッセージである場合、制御情報記憶部１２１に記憶された制御情報を参照して、サーバアプリケーション１４０との通信に用いられるクライアント機能部１３７側のソケットを検索する。ＵＲＬ書換部１３６は、ＨＴＴＰメッセージに含まれる仮想ＵＲＬを、宛先解決部１３５が検索した実ＵＲＬに書き換える。

クライアント機能部１３７は、サーバアプリケーション１４０に対してクライアントアプリケーションとして振る舞う。クライアント機能部１３７は、サーバアプリケーション１４０との間にＴＣＰコネクションを確立する。クライアント機能部１３７は、クライアント機能部１３７は、ＴＣＰコネクション毎に、論理的な通信インタフェースであるソケットを生成する。クライアント機能部１３７は、ソケットを指定して（サーバアプリケーション１４０に対して）メッセージを送信する。また、クライアント機能部１３７は、ソケットから（サーバアプリケーション１４０から）メッセージを受信する。

なお、リバースプロキシ１２０は、サーバ機能部１３１側が使用するソケットの番号の範囲と、クライアント機能部１３７が使用するソケットの番号の範囲とを予め決めておく。リバースプロキシ１２０は、メッセージが受信されたソケットの番号から、そのメッセージがサーバ機能部１３１によって処理されるべきものか、クライアント機能部１３７によって処理されるべきものか区別することができる。

ソケット検索部１３８は、クライアント機能部１３７がメッセージを受信すると、制御情報記憶部１２１に記憶された制御情報を参照して、メッセージが受信されたソケットに対応するサーバ機能部１３１側のソケットを検索する。

クローズ無効化部１３９は、制御情報記憶部１２１に記憶された制御情報を参照して、受信されたメッセージがＷｅｂソケットメッセージであり、かつ、サーバアプリケーション１４０が移動中であるか判定する。すなわち、クローズ無効化部１３９は、サーバアプリケーション１４０の移動時のクローズ通知を受信したか判定する。上記条件に該当する場合、クローズ無効化部１３９は、受信されたクローズ通知を終端する。すなわち、クローズ無効化部１３９は、クローズ通知をサーバ機能部１３１に出力せずに破棄する。なお、クローズ通知が受信された場合、クライアント機能部１３７は、サーバアプリケーション１４０との間のＴＣＰコネクションを切断してソケットを削除する。

配備計画サーバ２００は、制御情報記憶部２２１、移動制御部２３１、移動開始通知部２３２および移動完了通知部２３３を有する。制御情報記憶部２２１は、例えば、ＲＡＭまたはＨＤＤに確保した記憶領域を用いて実装される。移動制御部２３１、移動開始通知部２３２および移動完了通知部２３３は、例えば、ＣＰＵが実行するプログラムモジュールを用いて実装される。

制御情報記憶部２２１は、サーバアプリケーション１４０の移動の制御に用いられる各種の制御情報を記憶する。制御情報の詳細は後述する。移動制御部２３１は、Ｗｅｂサーバ１００，１００ａ，１００ｂの負荷やサーバアプリケーション１４０の通信遅延を監視する。移動制御部２３１は、負荷や通信遅延が所定条件を満たすと、サーバアプリケーション１４０を移動すること、および、移動先のＷｅｂサーバを決定する。

移動開始通知部２３２は、サーバアプリケーション１４０の移動を開始する前に、リバースプロキシ１２０，１２０ｂに対して移動開始通知を送信する。移動完了通知部２３３は、サーバアプリケーション１４０の移動が完了すると、リバースプロキシ１２０，１２０ｂに対して移動完了通知を送信する。

図１２は、リバースプロキシが有する制御テーブルの例を示す図である。
端末情報テーブル１２４、ソケット対応テーブル１２５、移動管理テーブル１２６およびＵＲＬ対応テーブル１２７が、制御情報記憶部１２１に記憶されている。

端末情報テーブル１２４は、端末側ソケットとＨＴＴＰヘッダの項目を有する。端末側ソケットの項目には、サーバ機能部１３１側のソケットの番号が登録される。ＨＴＴＰヘッダの項目には、端末側ソケットの項目が示すソケットから受信されたＨＴＴＰメッセージに含まれるＨＴＴＰヘッダが登録される。１つのソケットから複数のＨＴＴＰメッセージが受信された場合には、ＨＴＴＰヘッダの項目には、最新のＨＴＴＰメッセージに含まれるＨＴＴＰヘッダのみ登録されていればよい。

ソケット対応テーブル１２５は、端末側ソケット、Ｕｐｇｒａｄｅ状態、サーバ側ソケットおよびポインタの項目を有する。端末側ソケットの項目には、サーバ機能部１３１側のソケットの番号が登録される。Ｕｐｇｒａｄｅ状態の項目には、端末側ソケットの項目が示すソケット上の通信プロトコルが、ＨＴＴＰからＷｅｂソケットにアップグレードされたか否かを示すフラグが登録される。Ｕｐｇｒａｄｅ状態の初期値はＦａｌｓｅである。Ｕｐｇｒａｄｅ状態がＦａｌｓｅであることは、通信プロトコルがＨＴＴＰであることを示す。Ｕｐｇｒａｄｅ状態がＴｒｕｅであることは、通信プロトコルがＷｅｂソケットであることを示す。

サーバ側ソケットの項目には、クライアント機能部１３７側のソケットの番号が登録される。サーバ機能部１３１側の１つのソケットに対して、クライアント機能部１３７側の１つのソケットが対応付けられる。すなわち、リバースプロキシ１２０の端末装置４１，４２側の１つのＴＣＰコネクションに対して、リバースプロキシ１２０のサーバアプリケーション１４０側の１つのＴＣＰコネクションが対応付けられる。ポインタの項目には、移動管理テーブル１２６の１つのレコードを指す識別情報が登録される。識別情報として、後述する移動管理テーブル１２６のインデックスが用いられる。

移動管理テーブル１２６は、インデックス、仮想ＵＲＬおよび移動状態の項目を有する。インデックスは、移動管理テーブル１２６のレコードを識別する番号である。仮想ＵＲＬの項目には、サーバアプリケーション１４０に付与された仮想ＵＲＬが登録される。仮想ＵＲＬは、例えば、配備計画サーバ２００により決定される。移動状態の項目には、サーバアプリケーション１４０が移動中か否かを示すフラグが登録される。移動状態の初期値はＦａｌｓｅである。移動状態がＦａｌｓｅであることは、サーバアプリケーション１４０が移動中でないことを示す。移動状態がＴｒｕｅであることは、サーバアプリケーション１４０が移動中であることを示す。

ＵＲＬ対応テーブル１２７は、仮想ＵＲＬおよび実ＵＲＬの項目を有する。仮想ＵＲＬの項目には、サーバアプリケーション１４０に付与された仮想ＵＲＬが登録される。実ＵＲＬの項目には、サーバアプリケーション１４０に付与された実ＵＲＬが登録される。実ＵＲＬは、サーバアプリケーション１４０が配置されるＷｅｂサーバに依存する。

図１３は、配備計画サーバが有する制御テーブルの例を示す図である。
プロトコルテーブル２２２、配備管理テーブル２２３およびプロキシ管理テーブル２２４が、制御情報記憶部２２１に記憶されている。

プロトコルテーブル２２２は、アプリケーションＩＤおよびプロトコルの項目を有する。アプリケーションＩＤの項目には、サーバアプリケーション１４０を識別する識別情報が登録される。アプリケーションＩＤは、仮想ＵＲＬまたは実ＵＲＬに含まれるパス名であってもよい。プロトコルの項目には、サーバアプリケーション１４０が使用し得るアプリケーション層の通信プロトコルの名称が登録される。サーバアプリケーション１４０がＷｅｂソケットを使用し得る場合、プロトコルの項目にＷｅｂソケットが登録される。

配備管理テーブル２２３は、アプリケーションＩＤ、仮想ＵＲＬおよびサーバＩＤの項目を有する。アプリケーションＩＤの項目には、サーバアプリケーション１４０を識別する識別情報が登録される。仮想ＵＲＬの項目には、サーバアプリケーション１４０に付与された仮想ＵＲＬが登録される。サーバＩＤの項目には、サーバアプリケーション１４０が配置されたＷｅｂサーバを識別する識別情報が登録される。サーバＩＤは、Ｗｅｂサーバのホスト名またはＩＰアドレスであってもよい。

プロキシ管理テーブル２２４は、サーバＩＤおよびプロキシＵＲＬの項目を有する。サーバＩＤの項目には、リバースプロキシ１２０，１２０ａ，１２０ｂそれぞれについて、当該リバースプロキシが配置されたＷｅｂサーバを識別する識別情報が登録される。サーバＩＤは、Ｗｅｂサーバのホスト名またはＩＰアドレスであってもよい。プロキシＵＲＬの項目には、リバースプロキシ１２０，１２０ａ，１２０ｂそれぞれについて、当該リバースプロキシに付与された実ＵＲＬが登録される。なお、第２の実施の形態では、リバースプロキシ１２０，１２０ｂはサーバアプリケーション１４０と直接通信するため、各リバースプロキシの実ＵＲＬはリバースプロキシ１２０，１２０ｂに通知されない。

次に、リバースプロキシ１２０の処理手順について説明する。リバースプロキシ１２０ｂも、リバースプロキシ１２０と同様の処理を実行し得る。
図１４は、上り通信転送の手順例を示すフローチャートである。

（Ｓ２１０）サーバ機能部１３１は、メッセージを受信する。ソケット検索部１３２は、ソケット対応テーブル１２５から、メッセージが受信されたソケットの番号（受信ソケット番号）を端末側ソケットとして含むレコードを検索する。

（Ｓ２１１）ソケット検索部１３２は、ステップＳ２１０において該当するレコードが検索されたか判断する。該当するレコードが検索された場合はステップＳ２１２に処理が進み、検索されなかった場合はステップＳ２１３に処理が進む。

（Ｓ２１２）ソケット検索部１３２は、検索されたレコードに含まれるＵｐｇｒａｄｅ状態がＴｒｕｅであるか判断する。Ｕｐｇｒａｄｅ状態がＴｒｕｅである場合はステップＳ２１９に処理が進み、Ｆａｌｓｅである場合はステップＳ２１３に処理が進む。

（Ｓ２１３）端末情報保存部１３３は、受信されたメッセージがＨＴＴＰメッセージであると判断する。端末情報保存部１３３は、受信されたＨＴＴＰメッセージに含まれるＨＴＴＰヘッダを、受信ソケット番号と対応付けて端末情報テーブル１２４に登録する。

（Ｓ２１４）データ保留部１３４は、受信されたＨＴＴＰメッセージによって指定されたＵＲＬ（仮想ＵＲＬ）を抽出する。データ保留部１３４は、移動管理テーブル１２６から、抽出した仮想ＵＲＬを含むレコードを検索する。

（Ｓ２１５）データ保留部１３４は、ステップＳ２１４で検索されたレコードに含まれる移動状態がＴｒｕｅであるか判断する。移動状態がＴｒｕｅである場合はステップＳ２１６に処理が進み、Ｆａｌｓｅである場合はステップＳ２１７に処理が進む。

（Ｓ２１６）データ保留部１３４は、受信されたＨＴＴＰメッセージをデータ記憶部１２２に格納して転送を保留する。データ保留部１３４は、ステップＳ２１４で検索されたレコードの移動状態を監視し、移動状態がＴｒｕｅからＦａｌｓｅに変わるのを待つ。

（Ｓ２１７）宛先解決部１３５は、ＨＴＴＰメッセージによって指定された仮想ＵＲＬを抽出する。宛先解決部１３５は、ＵＲＬ対応テーブル１２７から、抽出した仮想ＵＲＬに対応する実ＵＲＬを検索する。ＵＲＬ書換部１３６は、ＨＴＴＰメッセージに含まれる仮想ＵＲＬを、検索された実ＵＲＬに置換する。

（Ｓ２１８）クライアント機能部１３７は、ソケット対応テーブル１２５から、受信ソケット番号を端末側ソケットとして含むレコードを検索する。クライアント機能部１３７は、検索されたレコードに、サーバ側ソケットが登録済みであるか判断する。サーバ側ソケットが登録済みである場合はステップＳ２２５に処理が進み、サーバ側ソケットがまだ登録されていない場合はステップＳ２２３に処理が進む。

（Ｓ２１９）データ保留部１３４は、受信されたメッセージがＷｅｂソケットメッセージであると判断する。データ保留部１３４は、ステップＳ２１０で検索されたレコードに含まれるポインタを辿り、ポインタが指すレコードを移動管理テーブル１２６から取得する。データ保留部１３４は、取得したレコードに含まれる移動状態を確認する。

（Ｓ２２０）データ保留部１３４は、ステップＳ２１９で確認した移動状態がＴｒｕｅであるか判断する。移動状態がＴｒｕｅである場合はステップＳ２２２に処理が進み、Ｆａｌｓｅである場合はステップＳ２２１に処理が進む。

（Ｓ２２１）宛先解決部１３５は、ソケット対応テーブル１２５から、受信ソケット番号を端末側ソケットとして含むレコードを検索する。宛先解決部１３５は、検索されたレコードにサーバ側ソケットとして含まれるソケット番号（サーバ側ソケット番号）を取得する。そして、ステップＳ２２５に処理が進む。

（Ｓ２２２）データ保留部１３４は、受信されたＷｅｂソケットメッセージをデータ記憶部１２２に格納して転送を保留する。データ保留部１３４は、ステップＳ２１９の移動状態を監視し、移動状態がＴｒｕｅからＦａｌｓｅに変わるのを待つ。

（Ｓ２２３）クライアント機能部１３７は、メッセージの転送先のサーバアプリケーションとの間にＴＣＰコネクションを確立し、サーバ側ソケットを生成する。ＴＣＰコネクションは、ＴＣＰの３ウェイハンドシェイクによって確立される。すなわち、クライアント機能部１３７は、ＳＹＮパケットを送信し、ＳＹＮ−ＡＣＫパケットを受信し、ＡＣＫパケットを送信する。ＳＹＮパケットの宛先ＩＰアドレスには、実ＵＲＬに含まれるホスト名からＤＮＳによって変換されるＩＰアドレス、または、実ＵＲＬに含まれるＩＰアドレスが用いられる。ＳＹＮパケットの宛先ポート番号には、実ＵＲＬに含まれるポート番号（省略されている場合は８０番）が用いられる。

（Ｓ２２４）クライアント機能部１３７は、ステップＳ２２３で生成したサーバ側ソケットの番号を、受信ソケット番号と対応付けてソケット対応テーブル１２５に登録する。また、クライアント機能部１３７は、登録したサーバ側ソケット番号に対応するポインタが空であるか（このレコードが今回新規に追加されたものか）判断する。ポインタが空である場合、クライアント機能部１３７は、ステップＳ２１４で検索された移動管理テーブル１２６のレコードに含まれるインデックスを、登録したサーバ側ソケット番号に対応するポインタとしてソケット対応テーブル１２５に登録する。

（Ｓ２２５）クライアント機能部１３７は、ステップＳ２１８で検索されたソケット、ステップＳ２２３で生成したソケット、または、ステップＳ２２１で検索されたソケットを用いて、メッセージを送信する。なお、後述するように、送信するメッセージには、サーバ機能部１３１が受信したメッセージの他、データ保留部１３４が生成したＷＳハンドシェイク要求が含まれることがある。

図１５は、下り通信転送の手順例を示すフローチャートである。
（Ｓ２３０）クライアント機能部１３７は、メッセージを受信する。ソケット検索部１３８は、ソケット対応テーブル１２５から、メッセージが受信されたソケットの番号（受信ソケット番号）をサーバ側ソケットとして含むレコードを検索する。

（Ｓ２３１）クローズ無効化部１３９は、検索されたレコードに含まれるＵｐｇｒａｄｅ状態がＴｒｕｅであるか判断する。Ｕｐｇｒａｄｅ状態がＴｒｕｅである場合はステップＳ２３４に処理が進み、Ｆａｌｓｅである場合はステップＳ２３２に処理が進む。

（Ｓ２３２）サーバ機能部１３１は、受信されたメッセージがＨＴＴＰメッセージであると判断する。サーバ機能部１３１は、受信されたＨＴＴＰメッセージに含まれるＨＴＴＰヘッダからＵｐｇｒａｄｅの値を抽出し、Ｕｐｇｒａｄｅが「ｗｅｂｓｏｃｋｅｔ」であるか判断する。Ｕｐｇｒａｄｅが「ｗｅｂｓｏｃｋｅｔ」である場合はステップＳ２３３に処理が進み、それ以外の場合はステップＳ２３６に処理が進む。

（Ｓ２３３）サーバ機能部１３１は、ステップＳ２３０で検索されたレコードのＵｐｇｒａｄｅ状態をＴｒｕｅに更新する。そして、ステップＳ２３６に処理が進む。
（Ｓ２３４）クローズ無効化部１３９は、受信されたメッセージがＷｅｂソケットメッセージであると判断する。クローズ無効化部１３９は、ステップＳ２３０で検索されたレコードのポインタを辿り、ポインタが指すレコードを移動管理テーブル１２６から取得する。クローズ無効化部１３９は、取得したレコードに含まれる移動状態を確認する。

（Ｓ２３５）クローズ無効化部１３９は、ステップＳ２３４で確認した移動状態がＴｒｕｅであるか判断する。移動状態がＴｒｕｅである場合はステップＳ２３７に処理が進み、Ｆａｌｓｅである場合はステップＳ２３６に処理が進む。

（Ｓ２３６）サーバ機能部１３１は、ステップＳ２３０で検索されたレコードが示す端末側ソケットを用いてメッセージを転送する。そして、下り通信転送が終了する。
（Ｓ２３７）クローズ無効化部１３９は、受信されたＷｅｂソケットメッセージ（クローズ通知）を終端する。すなわち、クローズ無効化部１３９は、クローズ通知をサーバ機能部１３１に出力せずに破棄する。

（Ｓ２３８）サーバ機能部１３１は、ステップＳ２３０で検索されたレコードのサーバ側ソケット番号をソケット対応テーブル１２５から削除する。
（Ｓ２３９）クライアント機能部１３７は、Ｗｅｂソケットメッセージを受信したソケットに対応するＴＣＰコネクションを切断する。すなわち、クライアント機能部１３７は、当該ソケットを指定してＦＩＮパケットを送信し、応答としてＦＩＮパケットを受信する。クライアント機能部１３７は、当該ソケットを削除する。

図１６は、プロキシ状態制御の手順例を示すフローチャートである。
（Ｓ２４０）状態制御部１２３は、配備計画サーバ２００から通知を受信する。
（Ｓ２４１）状態制御部１２３は、ステップＳ２４０で受信した通知が移動開始通知であるか判断する。受信した通知が移動開始通知である場合はステップＳ２４２に処理が進み、それ以外の場合はステップＳ２４６に処理が進む。

（Ｓ２４２）状態制御部１２３は、受信した移動開始通知に含まれている仮想ＵＲＬ（指定された仮想ＵＲＬ）を抽出する。状態制御部１２３は、移動管理テーブル１２６から、抽出した仮想ＵＲＬを含むレコードを検索する。

（Ｓ２４３）状態制御部１２３は、ステップＳ２４２で検索されたレコードに含まれる移動状態をＴｒｕｅに更新する。
（Ｓ２４４）状態制御部１２３は、ＵＲＬ対応テーブル１２７から、ステップＳ２４２で抽出した仮想ＵＲＬを含むレコードを検索する。

（Ｓ２４５）状態制御部１２３は、ステップＳ２４４で検索されたレコードに含まれる実ＵＲＬを削除する。そして、プロキシ状態制御が終了する。
（Ｓ２４６）状態制御部１２３は、ステップＳ２４０で受信した通知が移動完了通知であるか判断する。受信した通知が移動完了通知である場合はステップＳ２４７に処理が進み、それ以外の場合はプロキシ状態制御が終了する。

（Ｓ２４７）状態制御部１２３は、受信した移動完了通知に含まれている仮想ＵＲＬ（指定された仮想ＵＲＬ）を抽出する。状態制御部１２３は、ＵＲＬ対応テーブル１２７から、抽出した仮想ＵＲＬを含むレコードを検索する。

（Ｓ２４８）状態制御部１２３は、受信した移動完了通知に含まれている実ＵＲＬ（指定された実ＵＲＬ）を抽出する。状態制御部１２３は、ステップＳ２４７で検索されたレコードに、抽出した実ＵＲＬを登録する。

（Ｓ２４９）データ保留部１３４は、ＷＳハンドシェイク要求としてのＨＴＴＰメッセージを生成する。このとき、生成するＨＴＴＰメッセージのＨＴＴＰヘッダには、端末情報テーブル１２４に登録されたＨＴＴＰヘッダを使用する。

（Ｓ２５０）状態制御部１２３は、移動管理テーブル１２６から、ステップＳ２４７で抽出した仮想ＵＲＬを含むレコードを検索する。
（Ｓ２５１）状態制御部１２３は、ステップＳ２５０で検索されたレコードに含まれる移動状態をＦａｌｓｅに更新する。

次に、図１４〜１６に示した処理を、図８のシーケンスに沿って説明する。
端末装置４１は、サーバアプリケーション１４０の仮想ＵＲＬ「ｗｓ：／／ｖｕｒｌ：８０／ａｐｐ１」が入力されると、「ｖｕｒｌ」をＤＮＳサーバ４３に問い合わせ、これに対応するＩＰアドレス「１０．ｘ．ｘ．４０」を取得する。その結果、サーバ機能部１３１は、端末装置４１からの要求に応じてＴＣＰコネクションを確立し、ｓｏｃｋｅｔ１を生成する。そして、サーバ機能部１３１は、ｓｏｃｋｅｔ１から仮想ＵＲＬ「ｗｓ：／／ｖｕｒｌ：８０／ａｐｐ１」を指定したＷＳハンドシェイク要求を受信する。

ソケット検索部１３２は、ソケット対応テーブル１２５からｓｏｃｋｅｔ１を含むレコードを検索する。ここでは、ｓｏｃｋｅｔ１から受信する最初のメッセージであるため、該当するレコードは検索されない。端末情報保存部１３３は、受信されたＷＳハンドシェイク要求のＨＴＴＰヘッダを、ｓｏｃｋｅｔ１と対応付けて端末情報テーブル１２４に登録する。データ保留部１３４は、移動管理テーブル１２６から、指定された仮想ＵＲＬを含むレコードを検索し、移動状態がＦａｌｓｅであることを確認する。

宛先解決部１３５は、ＵＲＬ対応テーブル１２７から、指定された仮想ＵＲＬを含むレコードを検索し、当該仮想ＵＲＬに対応する実ＵＲＬ「ｗｓ：／／１０．ｘ．ｘ．３０：８８８０／ａｐｐ１」を取得する。ＵＲＬ書換部１３６は、ＷＳハンドシェイク要求に含まれる仮想ＵＲＬを実ＵＲＬに書き換える。

クライアント機能部１３７は、ｓｏｃｋｅｔ１を含むレコードがソケット対応テーブル１２５に存在しないため、実ＵＲＬが示すサーバアプリケーション１４０とＴＣＰコネクションを確立し、ｓｏｃｋｅｔ１０を生成する。クライアント機能部１３７は、ソケット対応テーブル１２５に、ｓｏｃｋｅｔ１とｓｏｃｋｅｔ１０とを対応付けたレコードを追加する。Ｕｐｇｒａｄｅ状態はＦａｌｓｅに設定しておく。また、クライアント機能部１３７は、仮想ＵＲＬを含む移動管理テーブル１２６のレコードのインデックス「＃１」を、ｓｏｃｋｅｔ１，ｓｏｃｋｅｔ１０と対応付けてポインタとして登録する。

クライアント機能部１３７は、ｓｏｃｋｅｔ１０からＷＳハンドシェイク要求を送信する。その後、クライアント機能部１３７は、ｓｏｃｋｅｔ１０から、Ｕｐｇｒａｄｅ＝ｗｅｂｓｏｃｋｅｔに設定されたＷＳハンドシェイク応答を受信する。

ソケット検索部１３８は、ソケット対応テーブル１２５からｓｏｃｋｅｔ１０を含むレコードを検索する。クローズ無効化部１３９は、ｓｏｃｋｅｔ１０に対応するＵｐｇｒａｄｅ状態がＦａｌｓｅであることを確認する。サーバ機能部１３１は、受信されたＷＳハンドシェイク応答のＨＴＴＰヘッダにＵｐｇｒａｄｅ＝ｗｅｂｓｏｃｋｅｔが含まれることを確認する。すると、サーバ機能部１３１は、ｓｏｃｋｅｔ１０に対応するＵｐｇｒａｄｅ状態をＴｒｕｅに更新する。そして、サーバ機能部１３１は、ｓｏｃｋｅｔ１０と対応付けられたｓｏｃｋｅｔ１からＷＳハンドシェイク応答を送信する。

サーバ機能部１３１は、ｓｏｃｋｅｔ１からＷｅｂソケットメッセージを受信する。ソケット検索部１３２は、ソケット対応テーブル１２５からｓｏｃｋｅｔ１を含むレコードを検索し、Ｕｐｇｒａｄｅ状態がＴｒｕｅであることを確認する。データ保留部１３４は、ｓｏｃｋｅｔ１に対応するポインタから移動管理テーブル１２６のインデックス「＃１」のレコードにアクセスし、移動状態がＦａｌｓｅであることを確認する。

宛先解決部１３５は、ソケット対応テーブル１２５からｓｏｃｋｅｔ１と対応付けられたｓｏｃｋｅｔ１０を取得する。クライアント機能部１３７は、ｓｏｃｋｅｔ１０からＷｅｂソケットメッセージを送信する。その後、クライアント機能部１３７は、ｓｏｃｋｅｔ１０からＷｅｂソケットメッセージを受信する。

ソケット検索部１３８は、ソケット対応テーブル１２５からｓｏｃｋｅｔ１０を含むレコードを検索する。クローズ無効化部１３９は、ｓｏｃｋｅｔ１０に対応するＵｐｇｒａｄｅ状態がＴｒｕｅであることを確認する。すると、クローズ無効化部１３９は、ｓｏｃｋｅｔ１０に対応するポインタから移動管理テーブル１２６のインデックス「＃１」のレコードにアクセスし、移動状態がＦａｌｓｅであることを確認する。この場合、クローズ無効化部１３９は、クローズ通知の終端は不要であると判断する。サーバ機能部１３１は、ｓｏｃｋｅｔ１０と対応付けられたｓｏｃｋｅｔ１からＷＳソケットメッセージを送信する。

サーバアプリケーション１４０の移動が決定されると、移動開始通知部２３２は、仮想ＵＲＬ「ｗｓ：／／ｖｕｒｌ：８０／ａｐｐ１」を指定した移動開始通知をリバースプロキシ１２０に送信する。状態制御部１２３は、移動管理テーブル１２６から当該仮想ＵＲＬを含むレコードを検索し、当該仮想ＵＲＬに対応する移動状態をＴｒｕｅに更新する。また、状態制御部１２３は、ＵＲＬ対応テーブル１２７から当該仮想ＵＲＬを含むレコードを検索し、当該仮想ＵＲＬに対応する実ＵＲＬを削除する（ＮＵＬＬに更新する）。

配備計画サーバ２００は、Ｗｅｂサーバ１００ａ上のサーバアプリケーション１４０に停止指示を送信する。すると、サーバアプリケーション１４０は、Ｗｅｂソケットのクローズ通知を各ＴＣＰコネクション上で送信する。クライアント機能部１３７は、ｓｏｃｋｅｔ１０からクローズ通知を受信する。

ソケット検索部１３８は、ソケット対応テーブル１２５からｓｏｃｋｅｔ１０を含むレコードを検索する。クローズ無効化部１３９は、ｓｏｃｋｅｔ１０に対応するＵｐｇｒａｄｅ状態がＴｒｕｅであることを確認する。すると、クローズ無効化部１３９は、ｓｏｃｋｅｔ１０に対応するポインタから移動管理テーブル１２６のインデックス「＃１」のレコードにアクセスし、移動状態がＴｒｕｅであることを確認する。すると、クローズ無効化部１３９は、クローズ通知を破棄してサーバ機能部１３１に出力しない。

サーバ機能部１３１は、ソケット対応テーブル１２５からｓｏｃｋｅｔ１０を削除する。クライアント機能部１３７は、サーバアプリケーション１４０との間のＴＣＰコネクションを切断し、ｓｏｃｋｅｔ１０を削除する。

端末装置４１とリバースプロキシ１２０との間のＴＣＰコネクションは切断されていないため、サーバ機能部１３１は、ｓｏｃｋｅｔ１からＷｅｂソケットメッセージを受信する。ソケット検索部１３２は、ソケット対応テーブル１２５からｓｏｃｋｅｔ１を含むレコードを検索し、Ｕｐｇｒａｄｅ状態がＴｒｕｅであることを確認する。データ保留部１３４は、ｓｏｃｋｅｔ１に対応するポインタから移動管理テーブル１２６のインデックス「＃１」のレコードにアクセスし、移動状態がＴｒｕｅであることを確認する。すると、データ保留部１３４は、データ記憶部１２２にＷｅｂソケットメッセージを保存する。

サーバアプリケーション１４０がＷｅｂサーバ１００ａからＷｅｂサーバ１００に移動すると、移動完了通知部２３３は、リバースプロキシ１２０に移動完了通知を送信する。移動完了通知には、仮想ＵＲＬ「ｗｓ：／／ｖｕｒｌ：８０／ａｐｐ１」と実ＵＲＬ「ｗｓ：／／１０．ｘ．ｘ．４０：８８８０／ａｐｐ１」とが含まれる。

状態制御部１２３は、ＵＲＬ対応テーブル１２７から当該仮想ＵＲＬを含むレコードを検索し、当該仮想ＵＲＬと対応付けて通知された実ＵＲＬを登録する。また、状態制御部１２３は、移動管理テーブル１２６から当該仮想ＵＲＬを含むレコードを検索し、当該仮想ＵＲＬに対応する移動状態をＦａｌｓｅに更新する。

データ保留部１３４は、移動状態がＴｒｕｅからＦａｌｓｅに変化すると、データ記憶部１２２に記憶されたＷｅｂソケットメッセージを転送するため、ＷＳハンドシェイク要求を生成する。このとき、データ保留部１３４は、ＷＳハンドシェイク要求のＨＴＴＰヘッダに、端末情報テーブル１２４に登録されたＨＴＴＰヘッダを使用する。データ保留部１３４は、ＷＳハンドシェイク要求に続いて、データ記憶部１２２に記憶されたＷｅｂソケットメッセージを出力する。なお、データ保留部１３４が移動管理テーブル１２６に登録された移動状態を監視する代わりに、移動状態がＦａｌｓｅに変わったことを状態制御部１２３がデータ保留部１３４に通知するようにしてもよい。

クライアント機能部１３７は、ｓｏｃｋｅｔ１に対応するサーバ側ソケットがソケット対応テーブル１２５に登録されていないため、実ＵＲＬが示すサーバアプリケーション１４０とＴＣＰコネクションを確立し、ｓｏｃｋｅｔ１１を生成する。クライアント機能部１３７は、ソケット対応テーブル１２５に、ｓｏｃｋｅｔ１と対応付けてｓｏｃｋｅｔ１１を登録する。クライアント機能部１３７は、データ保留部１３４が生成したＷＳハンドシェイク要求をｓｏｃｋｅｔ１１から送信し、ＷＳハンドシェイク応答をｓｏｃｋｅｔ１１から受信する。その後、クライアント機能部１３７は、データ記憶部１２２から取り出されたＷｅｂソケットメッセージをｓｏｃｋｅｔ１１から送信する。

第２の実施の形態の情報処理システムによれば、サーバアプリケーション１４０が移動するとき、サーバアプリケーション１４０が発行したクローズ通知がリバースプロキシ１２０，１２０ｂによって終端される。これにより、端末装置４１，４２，５１，５２に対してＷＳセッションが継続していると認識させることができ、クローズ通知に反応して端末装置４１，４２，５１，５２がＴＣＰコネクションを切断してしまうのを抑制できる。

そして、移動完了後は、リバースプロキシ１２０，１２０ｂによって、端末装置４１，４２，５１，５２側のＴＣＰコネクションとサーバアプリケーション１４０側のＴＣＰコネクションとが対応付けられ、両者の間でＷｅｂソケットメッセージが転送される。これにより、端末装置４１，４２，５１，５２は、サーバアプリケーション１４０が移動する前に確立したＴＣＰコネクションを移動後も使用し続けることができ、ＴＣＰコネクションを確立し直さなくてよい。よって、端末装置４１，４２，５１，５２のユーザは、ログイン手続などの操作を行わずに移動後もサーバアプリケーション１４０のサービスを継続して利用することができ、ユーザの利便性が低下しないようにすることができる。

また、サーバアプリケーション１４０の移動時にはＷＳセッションのデータも移動するため、サーバアプリケーション１４０は移動前の通信のコンテキストを引き継ぐことができ、ＷＳセッションを継続することができる。また、リバースプロキシ１２０，１２０ｂは、サーバアプリケーション１４０が移動中であるときはクローズ通知を終端する一方、サーバアプリケーション１４０が移動中でないときはクローズ通知を終端せずに転送する。これにより、通常時のＷｅｂソケット通信を正常に行うことができる。

［第３の実施の形態］
次に、第３の実施の形態を説明する。第２の実施の形態との違いを中心に説明し、第２の実施の形態と同様の事項については説明を省略することがある。

第２の実施の形態では、サーバアプリケーションを移動した後に、遠隔のＷｅｂサーバの間でＴＣＰコネクションを確立した。これに対し、第３の実施の形態では、サーバアプリケーションを移動する前に、予め遠隔のＷｅｂサーバの間でＴＣＰコネクションを確立しておく。事前のＴＣＰコネクションは、異なるＷｅｂサーバ上のリバースプロキシの間で確立しておく。これにより、サーバアプリケーション１４０のサービスが実質的に中断される時間を短縮することができる。

図１７は、第３の実施の形態のサーバアプリケーションの配備例を示す図である。
第３の実施の形態の情報処理システムは、第２の実施の形態のＷｅｂサーバ１００，１００ａ，１００ｂに代えて、Ｗｅｂサーバ１００ｃ，１００ｄ，１００ｅを含む。Ｗｅｂサーバ１００ｃは、拠点４０に設置されている。Ｗｅｂサーバ１００ｄは、クラウド３０に設置されている。Ｗｅｂサーバ１００ｅは、拠点５０に設置されている。

Ｗｅｂサーバ１００ｃは、リバースプロキシ１２０ｃおよび実行環境１５０ｃを実行する。Ｗｅｂサーバ１００ｄは、リバースプロキシ１２０ｄおよび実行環境１５０ｄを実行する。Ｗｅｂサーバ１００ｅは、リバースプロキシ１２０ｅおよび実行環境１５０ｅを実行する。サーバアプリケーション１４０が、最初はＷｅｂサーバ１００ｄで実行されており、その後にＷｅｂサーバ１００ｅに移動する場合を考える。

Ｗｅｂサーバ１００ｃのＩＰアドレスは「１０．ｘ．ｘ．４０」である。Ｗｅｂサーバ１００ｄのＩＰアドレスは「１０．ｘ．ｘ．３０」である。Ｗｅｂサーバ１００ｅのＩＰアドレスは「１０．ｘ．ｘ．５０」である。サーバアプリケーション１４０がＷｅｂサーバ１００ｄに配置されている場合、サーバアプリケーション１４０には「ｗｓ：／／１０．ｘ．ｘ．３０：８８８０」を含む実ＵＲＬが付与される。サーバアプリケーション１４０がＷｅｂサーバ１００ｅに配置されている場合、サーバアプリケーション１４０には「ｗｓ：／／１０．ｘ．ｘ．５０：８８８０」を含む実ＵＲＬが付与される。

リバースプロキシ１２０ｃ，１２０ｅには「ｗｓ：／／ｖｕｒｌ：８０」を含む仮想ＵＲＬが付与される。また、リバースプロキシ１２０ｃには、仮想ＵＲＬとは別に、「ｗｓ：／／１０．ｘ．ｘ．４０：８０」を含む実ＵＲＬが付与されている。リバースプロキシ１２０ｅには、仮想ＵＲＬとは別に、「ｗｓ：／／１０．ｘ．ｘ．５０：８０」を含む実ＵＲＬが付与されている。リバースプロキシ１２０ｄには、「ｗｓ：／／１０．ｘ．ｘ．３０：８０」を含む実ＵＲＬが付与されている。第３の実施の形態では、リバースプロキシ１２０ｃ，１２０ｅは、他のＷｅｂサーバに配置されたサーバアプリケーションとは直接通信せず、他のリバースプロキシを経由して通信する。リバースプロキシ１２０ｃ，１２０ｄ，１２０ｅの実ＵＲＬは、リバースプロキシ間の通信に用いられる。

サーバアプリケーション１４０がＷｅｂサーバ１００ｄに配置されている場合、リバースプロキシ１２０ｃは、仮想ＵＲＬを含むアクセスを受信すると、仮想ＵＲＬをリバースプロキシ１２０ｄの実ＵＲＬに変換し、アクセスをリバースプロキシ１２０ｄに転送する。リバースプロキシ１２０ｄは、リバースプロキシ１２０ｄの実ＵＲＬをサーバアプリケーション１４０の実ＵＲＬに変換し、アクセスをサーバアプリケーション１４０に転送する。また、サーバアプリケーション１４０がＷｅｂサーバ１００ｅに配置されている場合、リバースプロキシ１２０ｃは、仮想ＵＲＬをリバースプロキシ１２０ｅの実ＵＲＬに変換し、アクセスをリバースプロキシ１２０ｅに転送する。リバースプロキシ１２０ｅは、リバースプロキシ１２０ｅの実ＵＲＬをサーバアプリケーション１４０の実ＵＲＬに変換し、アクセスをサーバアプリケーション１４０に転送する。

図１８は、Ｗｅｂソケットによる第４の通信例を示すシーケンス図である。
端末装置４１は、リバースプロキシ１２０ｃとＴＣＰハンドシェイクを行い、端末装置４１とリバースプロキシ１２０ｃとの間にＴＣＰコネクションを確立する（Ｓ１７０）。端末装置４１は、サーバアプリケーション１４０の仮想ＵＲＬを指定したＷＳハンドシェイク要求をリバースプロキシ１２０ｃに送信する（Ｓ１７１）。リバースプロキシ１２０ｃは、仮想ＵＲＬをリバースプロキシ１２０ｄの実ＵＲＬに変換する。

リバースプロキシ１２０ｃは、リバースプロキシ１２０ｄとＴＣＰハンドシェイクを行い、リバースプロキシ１２０ｃとリバースプロキシ１２０ｄとの間にＴＣＰコネクションを確立する。リバースプロキシ１２０ｄは、サーバアプリケーション１４０とＴＣＰハンドシェイクを行い、リバースプロキシ１２０ｄとサーバアプリケーション１４０との間にＴＣＰコネクションを確立する（Ｓ１７２）。

リバースプロキシ１２０ｃは、ＷＳハンドシェイク要求をリバースプロキシ１２０ｄに転送する。リバースプロキシ１２０ｄは、リバースプロキシ１２０ｄの実ＵＲＬをサーバアプリケーション１４０の実ＵＲＬに変換し、ＷＳハンドシェイク要求をサーバアプリケーション１４０に転送する（Ｓ１７３）。サーバアプリケーション１４０は、ＷＳハンドシェイク応答をリバースプロキシ１２０ｄに送信する。リバースプロキシ１２０ｄは、ＷＳハンドシェイク応答をリバースプロキシ１２０ｃに転送する。リバースプロキシ１２０ｃは、ＷＳハンドシェイク応答を端末装置４１に転送する（Ｓ１７４）。

端末装置４１は、Ｗｅｂソケットメッセージをリバースプロキシ１２０ｃに送信する。リバースプロキシ１２０ｃは、Ｗｅｂソケットメッセージをリバースプロキシ１２０ｄに転送する。リバースプロキシ１２０ｄは、Ｗｅｂソケットメッセージをサーバアプリケーション１４０に転送する（Ｓ１７５）。

ここで、配備計画サーバ２００ａ（後述する）が、サーバアプリケーション１４０をＷｅｂサーバ１００ｄからＷｅｂサーバ１００ｅに移動すると決定したとする。配備計画サーバ２００ａがリバースプロキシ１２０ｃに移動準備通知を送信すると、リバースプロキシ１２０ｃは事前に、移動先のＷｅｂサーバ１００ｅのリバースプロキシ１２０ｅとＴＣＰハンドシェイクを行い、ＴＣＰコネクションを確立しておく（Ｓ１７６）。

その後、配備計画サーバ２００ａがサーバアプリケーション１４０に移動指示を送信すると、サーバアプリケーション１４０はクローズ通知をリバースプロキシ１２０ｄに送信する。リバースプロキシ１２０ｄは、クローズ通知をリバースプロキシ１２０ｃに転送する。リバースプロキシ１２０ｃは、受信したクローズ通知を終端する（Ｓ１７７）。

リバースプロキシ１２０ｃは、クローズ通知を受信すると、リバースプロキシ１２０ｃとリバースプロキシ１２０ｄとの間のＴＣＰコネクションを切断する。また、リバースプロキシ１２０ｄは、クローズ通知を受信すると、リバースプロキシ１２０ｄとサーバアプリケーション１４０との間のＴＣＰコネクションを切断する（Ｓ１７８）。

図１９は、Ｗｅｂソケットによる第４の通信例を示すシーケンス図（続き）である。
端末装置４１は、ＷＳセッションが継続していると認識しているため、Ｗｅｂソケットメッセージをリバースプロキシ１２０ｃに送信する（Ｓ１７９）。リバースプロキシ１２０ｃは、リバースプロキシ１２０ｃとリバースプロキシ１２０ｅとの間にＴＣＰコネクションが存在しないため、受信したＷｅｂソケットメッセージをバッファに保存しておく。

そして、リバースプロキシ１２０ｃは、配備計画サーバ２００ａから移動完了通知を受信すると、ＷＳハンドシェイク要求を生成してリバースプロキシ１２０ｅに送信する（Ｓ１８０）。このＷＳハンドシェイク要求の送信には、上記ステップＳ１７６で事前に確立したＴＣＰコネクションが用いられる。よって、移動完了通知を受けてからＷｅｂサーバ１００ｃとＷｅｂサーバ１００ｅとの間でＴＣＰハンドシェイクを行わなくてよい。

リバースプロキシ１２０ｅは、サーバアプリケーション１４０とＴＣＰハンドシェイクを行い、リバースプロキシ１２０ｅとサーバアプリケーション１４０との間にＴＣＰコネクションを確立する（Ｓ１８１）。このＴＣＰコネクションは、Ｗｅｂサーバ１００ｅの内部に形成されるコネクションである。よって、ステップＳ１８１のＴＣＰハンドシェイクのコストは、ステップＳ１７６のＴＣＰハンドシェイクのコストより十分に小さい。

リバースプロキシ１２０ｅは、リバースプロキシ１２０ｃから受信したＷＳハンドシェイク要求をサーバアプリケーション１４０に転送する（Ｓ１８２）。サーバアプリケーション１４０は、ＷＳハンドシェイク応答をリバースプロキシ１２０ｅに送信する。リバースプロキシ１２０ｅは、ＷＳハンドシェイク応答をリバースプロキシ１２０ｃに転送する（Ｓ１８３）。リバースプロキシ１２０ｃは、バッファに保存されたＷｅｂソケットメッセージをリバースプロキシ１２０ｅに転送する。リバースプロキシ１２０ｅは、Ｗｅｂソケットメッセージをサーバアプリケーション１４０に転送する（Ｓ１８４）。

正常にＷＳセッションを終了する場合、サーバアプリケーション１４０は、クローズ通知をリバースプロキシ１２０ｅに送信する。リバースプロキシ１２０ｅは、クローズ通知をリバースプロキシ１２０ｃに転送する。リバースプロキシ１２０ｃは、クローズ通知を端末装置４１に転送する（Ｓ１８５）。端末装置４１は、端末装置４１とリバースプロキシ１２０ｃとの間のＴＣＰコネクションを切断する。リバースプロキシ１２０ｃは、リバースプロキシ１２０ｃとリバースプロキシ１２０ｅとの間のＴＣＰコネクションを切断する。リバースプロキシ１２０ｅは、リバースプロキシ１２０ｅとサーバアプリケーション１４０との間のＴＣＰコネクションを切断する（Ｓ１８６）。

サーバアプリケーション１４０から見て、ステップＳ１７２からステップＳ１７８まで１つのＴＣＰコネクションが維持され、ステップＳ１８１からステップＳ１８６まで１つのＴＣＰコネクションが維持されている。サーバアプリケーション１４０から見て、ステップＳ１７８とステップＳ１８１の間はＴＣＰコネクションが存在しない。

これに対し、端末装置４１から見て、ステップＳ１７０からステップＳ１８６までＴＣＰコネクションが切断されずに維持されている。また、端末装置４１からは、ステップＳ１７４からステップＳ１８５までＷＳセッションが継続しているように見える。また、サーバアプリケーション１４０の移動の際にはセッションデータも移動する。よって、端末装置４１は、サーバアプリケーション１４０の移動を意識せずに通信を継続できる。

図２０は、第３の実施の形態の移動制御の通信例を示すシーケンス図である。
配備計画サーバ２００ａは、サーバアプリケーション１４０をＷｅｂサーバ１００ｄからＷｅｂサーバ１００ｅに移動することを決定する。すると、配備計画サーバ２００ａは、Ｗｅｂサーバ１００ｃのリバースプロキシ１２０ｃとＷｅｂサーバ１００ｅのリバースプロキシ１２０ｅに、移動準備通知を送信する（Ｓ１９０）。移動準備通知は、サーバアプリケーション１４０を識別する仮想ＵＲＬと、移動先のＷｅｂサーバ１００ｅに配置されたリバースプロキシ１２０ｅの実ＵＲＬとを含む。

リバースプロキシ１２０ｃは、サーバアプリケーション１４０に関して確立されているＴＣＰコネクション１つにつき、新たなＴＣＰコネクション１つをリバースプロキシ１２０ｅと確立する。異なるＷｅｂサーバ間のＴＣＰハンドシェイクが終わると、リバースプロキシ１２０ｃ，１２０ｅは、配備計画サーバ２００ａに応答を送信する（Ｓ１９１）。

移動準備通知に対する応答を全てのリバースプロキシから受信すると、配備計画サーバ２００ａは、リバースプロキシ１２０ｃ，１２０ｅに移動開始通知を送信する（Ｓ１９２）。移動開始通知は、仮想ＵＲＬを含む。リバースプロキシ１２０ｃ，１２０ｅは、配備計画サーバ２００ａに応答を送信する（Ｓ１９３）。

配備計画サーバ２００ａは、サーバアプリケーション１４０に停止指示を送信する。サーバアプリケーション１４０は、Ｗｅｂソケットのために維持しているＴＣＰコネクション毎にクローズ通知を送信する（Ｓ１９４）。例えば、サーバアプリケーション１４０は、リバースプロキシ１２０ｃ，１２０ｅに１または２以上のクローズ通知を送信する。このクローズ通知は、図１８のステップＳ１７７のクローズ通知に対応する。

配備計画サーバ２００ａは、Ｗｅｂサーバ１００ｄの実行環境１５０ｄに移動指示を送信する。実行環境１５０ｄは、サーバアプリケーション１４０のプログラムとセッションデータをＷｅｂサーバ１００ｅに送信する（Ｓ１９５）。実行環境１５０ｄは、サーバアプリケーション１４０を停止させる。Ｗｅｂサーバ１００ｅの実行環境１５０ｅは、プログラムとセッションデータによりサーバアプリケーション１４０を起動する。

配備計画サーバ２００ａは、リバースプロキシ１２０ｃ，１２０ｅに移動完了通知を送信する（Ｓ１９６）。移動完了通知は、仮想ＵＲＬと、移動先のＷｅｂサーバ１００ｅに配置されたリバースプロキシ１２０ｅの実ＵＲＬとを含む（Ｓ１９６）。

図２１は、第３の実施の形態のリバースプロキシの機能例を示すブロック図である。
リバースプロキシ１２０ｃは、制御情報記憶部１２１、データ記憶部１２２、状態制御部１２３およびコネクションプール部１２８を有する。また、リバースプロキシ１２０ｃは、サーバ機能部１３１、ソケット検索部１３２、端末情報保存部１３３、データ保留部１３４、宛先解決部１３５、ＵＲＬ書換部１３６、クライアント機能部１３７ｃ、ソケット検索部１３８およびクローズ無効化部１３９を有する。リバースプロキシ１２０ｄ，１２０ｅも、リバースプロキシ１２０ｃと同様のモジュールにより実装できる。

制御情報記憶部１２１は、第２の実施の形態と同様に、端末情報テーブル１２４、ソケット対応テーブル１２５、移動管理テーブル１２６およびＵＲＬ対応テーブル１２７を有する。ただし、ソケット対応テーブル１２５のサーバ側ソケットの項目には、他のリバースプロキシとの間に確立したＴＣＰコネクションに対応するソケットの番号が登録されることがある。また、ＵＲＬ対応テーブル１２７の実ＵＲＬの項目には、他のリバースプロキシの実ＵＲＬが登録されることがある。

コネクションプール部１２８は、配備計画サーバ２００ａから移動準備通知を受信すると、移動管理テーブル１２６から、指定された仮想ＵＲＬを含むレコードを検索し、検索されたレコードのインデックスを取得する。コネクションプール部１２８は、ソケット対応テーブル１２５から、取得したインデックスを含むレコードを検索し、検索されたレコードをカウントする。すなわち、コネクションプール部１２８は、指定された仮想ＵＲＬに関して、現在存在するＴＣＰコネクションをカウントする。そして、コネクションプール部１２８は、移動準備通知に含まれる実ＵＲＬが示すリバースプロキシとの間に、カウントした数のＴＣＰコネクションを確立してプールしておく。

クライアント機能部１３７ｃは、サーバアプリケーション１４０が移動した直後に他のリバースプロキシと通信するときは、新たなＴＣＰコネクションを確立する代わりにプールされているＴＣＰコネクションを選択して使用する。クライアント機能部１３７ｃは、選択したＴＣＰコネクションに対応するソケットの番号を、サーバ機能部１３１側のソケットと対応付けてソケット対応テーブル１２５に登録する。

配備計画サーバ２００ａは、制御情報記憶部２２１、移動制御部２３１、移動開始通知部２３２、移動完了通知部２３３ａおよび移動準備通知部２３４を有する。
移動完了通知部２３３ａは、サーバアプリケーション１４０の移動が完了すると、リバースプロキシ１２０ｃ，１２０ｅに対して移動完了通知を送信する。移動完了通知は、サーバアプリケーション１４０を識別する仮想ＵＲＬと、移動先のＷｅｂサーバのリバースプロキシに付与された実ＵＲＬとが含まれる。

移動準備通知部２３４は、サーバアプリケーション１４０の移動が決定されると、移動開始通知に先立って、リバースプロキシ１２０ｃ，１２０ｅに対して移動準備通知を送信する。移動準備通知は、サーバアプリケーション１４０を識別する仮想ＵＲＬと、移動先のＷｅｂサーバのリバースプロキシに付与された実ＵＲＬとが含まれる。

なお、サーバアプリケーション１４０の移動前に新たなＴＣＰコネクションを確立すると、一時的に、古いＴＣＰコネクションと新たなＴＣＰコネクションとが併存し、第２の実施の形態の方法の２倍のＴＣＰコネクションを維持することになる。よって、Ｗｅｂサーバ１００ｃ，１００ｅの負荷が過大になるおそれがある。そこで、Ｗｅｂサーバ１００ｃ，１００ｅの負荷を監視し、負荷に応じて、サーバアプリケーション１４０の移動前に新たなＴＣＰコネクションを確立するか、サーバアプリケーション１４０の移動後に新たなＴＣＰコネクションを確立するかを選択するようにしてもよい。

例えば、配備計画サーバ２００ａは、Ｗｅｂサーバ１００ｃ，１００ｅのメモリ使用量を監視する。Ｗｅｂサーバ１００ｃ，１００ｅの空きメモリ量が閾値以上ある場合、配備計画サーバ２００ａは、Ｗｅｂサーバ１００ｃ，１００ｅに移動準備通知を送信する。これにより、サーバアプリケーション１４０の移動前に新たなＴＣＰコネクションが確立される。一方、Ｗｅｂサーバ１００ｃ，１００ｅの空きメモリ量が閾値未満である場合、配備計画サーバ２００ａは、Ｗｅｂサーバ１００ｃ，１００ｅに移動準備通知を送信しない。これにより、サーバアプリケーション１４０の移動後に新たなＴＣＰコネクションが確立される。ただし、配備計画サーバ２００ａは、Ｗｅｂサーバ１００ｃ，１００ｅのＣＰＵ使用率を監視し、ＣＰＵ使用率が閾値以下の場合は移動準備通知を送信し、ＣＰＵ使用率が閾値を超える場合は移動準備通知を送信しないようにしてもよい。また、判断基準として、ＣＰＵ使用率とメモリ使用量の両方を用いてもよい。

第３の実施の形態の情報処理システムによれば、第２の実施の形態の情報処理システムと同様の効果が得られる。更に、第３の実施の形態の情報処理システムによれば、サーバアプリケーション１４０がクローズ通知を送信してから再びサーバアプリケーション１４０にＷｅｂソケットメッセージを転送可能になるまでの時間を短縮できる。よって、端末装置４１，４２，５１，５２から見て実質的にサーバアプリケーション１４０のサービスが中断されている時間を短縮でき、ユーザの利便性を向上させることができる。

なお、前述のように、第１の実施の形態の情報処理は、コンピュータにプログラムを実行させることで実現できる。第２の実施の形態の情報処理は、Ｗｅｂサーバ１００，１００ａ，１００ｂおよび配備計画サーバ２００にプログラムを実行させることで実現できる。第３の実施の形態の情報処理は、Ｗｅｂサーバ１００ｃ，１００ｄ，１００ｅおよび配備計画サーバ２００ａにプログラムを実行させることで実現できる。

プログラムは、コンピュータ読み取り可能な記録媒体（例えば、記録媒体１１３）に記録しておくことができる。記録媒体として、例えば、磁気ディスク、光ディスク、光磁気ディスク、半導体メモリなどを使用できる。磁気ディスクには、ＦＤおよびＨＤＤが含まれる。光ディスクには、ＣＤ、ＣＤ−Ｒ（Recordable）／ＲＷ（Rewritable）、ＤＶＤおよびＤＶＤ−Ｒ／ＲＷが含まれる。プログラムは、可搬型の記録媒体に記録されて配布されることがある。その場合、可搬型の記録媒体から他の記録媒体（例えば、ＨＤＤ１０３）にプログラムをコピーして実行してもよい。

１０ 中継プロセス
１１，１２，１３ コネクション
１４ 切断指示メッセージ
１５ 制御情報
２１，２２，２３ 装置

Claims (5)

1. 第１の装置と第２の装置とが中継プロセスを介して通信可能であり、第３の装置と前記第２の装置とが前記中継プロセスを介して通信可能であるシステムが実行する、セッション制御方法であって、
   前記中継プロセスの前記第１の装置側に確立された第１のコネクションと、前記中継プロセスの前記第２の装置側に確立された第２のコネクションとを対応付けた制御情報を記憶し、
   前記第１の装置から前記第２の装置に対して、前記第１のコネクションおよび前記第２のコネクションより上位の通信レイヤの切断指示メッセージが発行された場合、前記中継プロセスにおいて前記切断指示メッセージを終端し、また、前記切断指示メッセージの発行に応じて前記制御情報を更新し、
   前記第１の装置から前記第３の装置への切り替えが通知され、かつ、前記切断指示メッセージが発行されたことを前記制御情報が示している場合、前記中継プロセスの前記第３の装置側に確立された第３のコネクションを使用可能にし、前記第２のコネクションと前記第３のコネクションとが対応付けられるように前記制御情報を更新する、
   セッション制御方法。
2. 前記切断指示メッセージが、前記切り替えが通知される前であって前記第１の装置から前記第３の装置への切り替えの開始が通知された後に発行された場合には、前記中継プロセスにおいて前記切断指示メッセージを終端し、
   前記切断指示メッセージが、前記切り替えの開始が通知される前に発行された場合には、前記第２の装置に前記切断指示メッセージを転送する、
   請求項１記載のセッション制御方法。
3. 前記切り替えが通知される前に、前記中継プロセスと前記第３の装置との間に前記第３のコネクションを確立する、
   請求項１記載のセッション制御方法。
4. 前記中継プロセスが実行される装置の負荷に応じて、前記切り替えが通知される前に前記第３のコネクションを確立するか、前記切り替えが通知された後に前記第３のコネクションを確立するかを選択する、
   請求項１記載のセッション制御方法。
5. コンピュータに、
   第１の装置側に確立された第１のコネクションと、第２の装置側に確立された第２のコネクションとを対応付けた制御情報を記憶し、
   前記第１の装置から、前記第１のコネクションおよび前記第２のコネクションより上位の通信レイヤのメッセージであって前記第２の装置宛ての切断指示メッセージを受信した場合、前記切断指示メッセージを終端し、また、前記切断指示メッセージの受信に応じて前記制御情報を更新し、
   前記第１の装置から第３の装置への切り替えが通知され、かつ、前記切断指示メッセージを受信したことを前記制御情報が示している場合、前記第３の装置側に確立された第３のコネクションを使用可能にし、前記第２のコネクションと前記第３のコネクションとが対応付けられるように前記制御情報を更新する、
   処理を実行させるセッション制御プログラム。

Images