JP2014082624A - プロキシ装置及び中継装置 - Google Patents

Abstract

【課題】中継装置とサーバとの通信において、ポート番号の枠による限界を超えてセッションを構築できるようにする。
【解決手段】ＬＡＮ側からのセッション確立要求件数が上限値を超えた場合、一のサーバと繋がるＷＡＮ側のセッションのうち、未使用状態のものに、そのＬＡＮ側セッションを割り当て、応答メッセージ受信後は、その紐付けを解除して、他のＬＡＮ側セッションがＷＡＮ側セッションを利用できるようにするプロキシ装置とする。
【選択図】図１

Description

この発明は、プロキシ装置に関し、具体的には、複数の中継装置が上位の巨大中継装置に集約されている際における、プロキシ装置の機能を有する下位の中継装置に関する。

ＩＰｖ４のグローバルＩＰアドレスは枯渇状態にあり、中継装置が有する一つのグローバルＩＰアドレスを、複数の端末や装置で共有することが一般的になっている。グローバルＩＰアドレスに限らず、一つのＩＰアドレスを複数の装置や端末で共有する方法として、ＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）又はＮＡＰＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｐｏｒｔ Ｔｒａｎｓｌａｔｉｏｎ）（以下、まとめて「ＮＡＰＴ」と呼称する場合がある。）が用いられている。中継装置がＮＡＰＴを実行する際には、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）側からＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）側へのパケットを受信したときに、ＬＡＮ側のどのアドレスから来たパケットをどのようにしてＷＡＮ側へ送出したかを記録するセッション管理テーブルを保持し、ＷＡＮ側からパケットを受信した際には、そのパケット情報を元にＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）側のどのアドレスへ中継するかを判断する。ＮＡＰＴとして一般的な５−ｔｕｐｌｅでは、ＷＡＮ側から受信したパケットの「送信元ＩＰアドレス」「送信元ポート番号」「宛先ＩＰアドレス」「宛先ポート番号」「プロトコル」の５つの情報によって、ＬＡＮ側のどのアドレスへ中継するかを判断する。

一方、個々の利用者の端末に繋がり、自身は閉域網に存在する複数の中継装置が、インターネットにアクセスするにあたっては、インターネットとの間に設けられたインターネットゲートウェイとなる上位中継装置が通信を集約し、インターネット上のサーバ等とは、その上位中継装置のグローバルＩＰアドレスによって通信するケースがある。前記の閉域網がＩＰｖ６で構築された環境である場合に、ＳＡＭ（Ｓｔａｔｅｌｅｓｓ Ａｄｄｒｅｓｓ Ｍａｐｐｉｎｇ）により、外部データベースなどを参照した変換ではなく、ＩＰｖ４とＩＰｖ６との自動的なアドレス変換を行う。言い換えれば、この変換を行う上位中継装置（Ｐｒｏｖｉｄｅｒ−Ｓｔａｔｅｌｅｓｓ Ａｄｄｒｅｓｓ Ｍａｐｐｉｎｇ装置：Ｐ−ＳＡＭ装置）の配下に接続された複数の中継装置は、この上位中継装置のグローバルＩＰアドレスを共有しており、全ての中継装置が同じＩＰアドレスを用いてインターネットとの通信を行うことになる。このため、それぞれの中継装置が、インターネット上にある同一のサーバに対して通信を行った場合、それらの通信がどの中継装置から発信されたものであるのか、それらの通信に対する応答をどの中継装置に対して転送すべきなのかを、上位中継装置が判断する材料は、ポート番号のみとなってしまう。

ここで、上記したＩＰｖ４の枯渇状態のため、インターネットに接続したいインターネットゲートウェイ装置（上位中継装置）の数に対して、十分なＰ−ＳＡＭ用ＩＰｖ４アドレスを用意することができず、インターネットゲートウェイ装置の数が限られることになる。この状況を簡略化した例を図１２に示す。一台のインターネットゲートウェイ装置に、限界に近い数の中継装置が接続されて、それらが一つのグローバルＩＰアドレス（図ではＧＷＩＰ「１００．１．１．１」）を共有することになる。具体的には、一台のインターネットゲートウェイ装置（Ｐ−ＳＡＭ１１）を、１０２４台の中継装置で共有するのが、実用的な限界の構成となる。
この場合、中継装置（ＨＧＷ）一台あたりに割り当てられるポート番号の枠は、６５５３５のポート番号を１０２４台で割ることになる。さらに、実際にはＷｅｌｌｋｎｏｗｎｐｏｒｔは用いることができないので、中継装置一台あたり６０ポート程度しか利用できなくなる（例では１０００１〜１００６０）。仮に一台あたり６０ポートとすると、端末（ＰＣ１，２）から要求を受けた一の中継装置（ＨＧＷ１：１９２．１６８．１．２）が一のサーバ（２００．１．１．１）に対して６１セッション以上のＴＣＰ接続を行おうとした場合、６１セッション目以降は破棄される。

そして、インターネット上でリッチコンテンツを提供する機会が増えた近年では、端末上のアプリケーションがインターネットから大量の情報を高速にダウンロードする目的で、一つのサーバに対して複数のセッションを張り、同時並行で通信を行うという実装が増えてきている。このため、インターネットゲートウェイの配下に多数の中継装置が接続される構成で、中継装置が（すなわち、それに繋がるさらに複数の端末が）インターネット上のサーバにアクセスしようとしても、インターネットゲートウェイ装置のポート番号の空きが足りなくなって、並行して要求したセッションの一部又は全部が確立できずに一部コンテンツが取得できず、情報が不十分となってしまうおそれがある。

これに対して、特許文献１には、複数のアプリケーションで、同じポート番号を共有する手法が提示されている。

また、特許文献２には、端末が同一サーバへの要求を一つのセッションとしてまとめて送信することで、セッション資源を節約する手法が記載されている。また、端末とサーバとの間にＰｒｏｘｙサーバを介在させる場合には、端末が複数サーバへの要求を一つのセッションとしてＰｒｏｘｙサーバに送信し、Ｐｒｏｘｙサーバにて宛先サーバを振り分けて送信を行うことで、セッション資源を節約する手法が記載されている。

特開２０１０−１５４５１８号公報 特開２００２−３７３１４９号公報

しかしながら、特許文献１に記載の手法は中継装置ではなく、中継装置に接続される端末やサーバにおいて、本来の実装から外れた処理を行わなければならず、一般化できる手法ではない。

また、特許文献２に記載の手法も、端末側で複数の要求を同一セッションにまとめる処理を行わなければならず、中継装置よりもさらに膨大な数に上る端末に手を加えなければならないため、実用に用いるのは容易ではなかった。

そこでこの発明は、端末側の対応が容易な手法で、インターネットゲートウェイ装置でのポート番号枠制限によるセッションの確立失敗を抑制することを目的とする。

この発明は、端末とインターネットゲートウェイ装置との間の通信を中継するプロキシ装置において、
上記インターネットゲートウェイを経由するインターネット上の一のサーバとの間のセッション数を、一定数以下でありかつ、上記一のサーバを宛先とする端末側とのセッション数以下に限定し、
端末側から上記一のサーバへの通信要求を新たに受信した際には、上記一のサーバとの間のセッションのうちその時点で通信を行っていないセッションを利用して、上記一のサーバとの通信を行うことで、上記の課題を解決したのである。

すなわち、サーバ側セッションと端末側セッションとを一対一対応させずに、それぞれを分離して扱い、端末側からの要求に応じて、空いているサーバ側へのセッションを適宜紐付け、応答が終わったらその紐付けを解消可能とする。ここで、単なる中継装置ではなくプロキシ装置であるのは、装置の端末側とサーバ側とでそれぞれセッションを別個に取り扱うためには、一旦この装置でセッションを終端させなければならないからである。プロキシ装置としてのＨＴＴＰサーバ及びＨＴＴＰクライアントとしての機能が、要求メッセージ及び応答メッセージを一旦終端して、メッセージを作成し直して端末とサーバとの間の通信を中継するので、必要に応じてそれらのセッションを使い分けて通信することができる。

例えば、ＨＴＴＰ１．１の通信ではＫｅｅｐ−Ａｌｉｖｅ機能により、通信を行っていない間もＴＣＰのセッションを張ったままにしている。しかし、このセッションは長時間維持されていても、実際には通信されていない時間帯が存在する。そこで、実際に送受信を必要とするセッションが、サーバ側とのセッション枠を一時的に利用し、通信が終わったら端末側のセッションは残しつつ、サーバ側のセッションは割り込み可能とすることで、サーバ側とのセッション枠を最大限に活用することが出来る。これにより、従来よりも少ないセッション枠で、サーバとのやり取りができるので、上位の中継装置であるインターネットゲートウェイ装置から、一台あたりのセッション枠（すなわち、ポート番号の割り当て数である）が限られている状況でも、割り当て枠が足りずに破棄されるセッションが生じることを抑制できる。

ＨＴＴＰという観点では、トランスポート部分であるＴＣＰレイヤの情報は特に区別する必要はない。そこで、ＨＴＴＰ通信を行っていないＴＣＰのセッション上で、別のＨＴＴＰ通信を行っても、ＨＴＴＰの処理上は特に問題がないということを利用して本発明は成立する。また、ＨＴＴＰに限らず、サーバ側と端末側とのそれぞれにセッションが存在し、それが継続的に張られる場合には、同様にそのセッションを必要に応じて繋ぎ変えることで、本発明の効果を得ることができる。

本発明にかかるプロキシ装置は、端末を配下に抱えるＬＡＮを、プロバイダ内ネットワークなどの閉域網と繋ぐ中継装置自体がその能力を持つものでもよいし、中継装置とは別に閉域網内に設けてあるものでもよい。また、上記のプロキシ装置の機能を、端末がローカルプロキシソフトウェアとして、パソコンなどの個人用端末上に実装する場合には、端末がＩＰｖ６のアドレスを有してＩＰｖ６で通信するにあたり、内部的に利用可能なポート（例えば１０００１〜１００６０）に変換する内部ＮＡＰＴとして実装することになる。

ここでプロキシ装置、或いは中継装置が、同一の宛先ＩＰアドレスに対して張ることが出来るセッションの数（すなわちポート番号の数）は、インターネットゲートウェイ装置が抱えるプロキシ装置や中継装置の数によって限定されるものであり、各プロキシ装置（中継装置）は、その限定された数の範囲で、一のサーバとのセッションを構築する。その一のサーバを宛先とする端末側のセッション数は、サーバ側のセッション数と同数又はそれ以上となり、より多数である端末側のセッションが、より少数であるサーバ側のセッションを共有することになる。ただし、端末側のセッションが減少したら、それを超える数のサーバ側のセッションを維持する必要はないので、サーバ側のセッションも適宜整理してよい。

この発明により、インターネットゲートウェイのＩＰアドレスを多数の端末や中継装置が共有する場合に、端末や中継装置一つあたりに割り当てられる限られた数のポート番号を、従来よりも効率よく運用することができ、インターネット上のサーバに対してセッションが張れなくなる障害の発生頻度を抑制することができる。

また、プロキシ装置が作業のほとんどを担うため、端末側での設定変更は必要ないか、必要だったとしても、プロキシ装置を指定する作業程度で済むため、個々の端末の利用者にかかる負荷は小さく、容易に導入することができる。

ＬＡＮとＷＡＮとの間に設ける中継装置と兼用するだけでなく、閉域網上に独立して設けたプロキシ装置として、端末や中継装置からのアクセスを中継するプロキシとして動作させることもできる。この場合は、特に多数のセッションを張る傾向にある利用者が、適宜端末の設定を書き換えて、そのプロキシ装置を経由するようにすることで、必要な箇所に最小限の作業で導入することができる。

この発明にかかるプロキシ装置の基本的な運用の概念図 この発明の運用形態例を示す概念図 この発明にかかるプロキシ装置の機能ブロック図 （ａ）（ｂ）図３のプロキシ装置で用いる応答管理テーブルの例図 図３のプロキシ装置で用いるセッション管理テーブルの例図 ＨＴＴＰ要求メッセージの送受信フロー 図６におけるセッション終端部選択部分のフロー 図６におけるセッション管理テーブルの更新部分のフロー ＨＴＴＰ応答メッセージの送受信フロー ＬＡＮ側からのセッション削除手段実行フロー ＷＡＮ側からのセッション削除手段実行フロー 従来のインターネットゲートウェイ利用時における問題点の概念図

以下、この発明にかかるプロキシ装置の実施形態について詳細に説明する。まず、この発明にかかるプロキシ装置の基本的な運用の概念を、図１を用いて説明する。この実施形態にかかるプロキシ装置１３は、サーバ１１と端末１４との間に設けられ、図では省略されているが、プロキシ装置１３とサーバ１１との間にはインターネットゲートウェイ１２が存在している。端末１４と繋がる方がＬＡＮ側、サーバ１１と繋がる側がＷＡＮ側である。プロキシ装置１３の左右に繋がるパイプはそれぞれを繋ぐセッションを表したものである。

まず、端末１４から発せられた要求メッセージを、ＬＡＮ側のセッションから受信する（図１（ａ））。プロキシ装置１３は、要求メッセージを受信したＬＡＮ側セッションと、無通信状態のＷＡＮ側セッションとを括り付け、そのＷＡＮ側セッションから要求メッセージを送信する（図１（ｂ））。プロキシ装置１３は、前記のＷＡＮ側セッションから応答メッセージを受け取ると、それを、当該ＷＡＮ側セッションに括り付けられたＬＡＮ側セッションから送信する（図１（ｃ））。応答メッセージを送信した後は、プロキシ装置１３はＬＡＮ側セッションとＷＡＮ側セッションとの括り付けを解除する（図１（ｄ））。これで元の状態に戻り、次に端末１４から別のＬＡＮ側セッションを通じて要求メッセージを受信した場合には、先に用いたＷＡＮ側セッションを利用して要求メッセージと応答メッセージを送受信する。

次に、この発明にかかるプロキシ装置の実施形態例を挙げて説明する。その実施形態例を図２（ａ）に示す。プロキシ装置１３（Ｎｏ．１〜１０２４）は、端末１４（Ｎｏ．１，２……）を抱えるローカルエリアネットワーク（図中「ＬＡＮ」と略記する。）３と、閉域網２との間のゲートウェイを兼ねた中継装置であり、閉域網２とインターネット１との間にはインターネットゲートウェイ（図中、「Ｐ−ＳＡＭ」と略記する。）１２が設けてある。端末１４は、プロキシ装置１３とインターネットゲートウェイ１２を通じて、インターネット１上のサーバ１１へアクセスする。

端末１４とは、パソコンやスマートフォン、その他の、ネットワーク機能を有する端末であり、ブラウザなどにより多数のセッションを張りうるものである。

プロキシ装置１３とは、プロキシサーバとしての機能を備えた装置であり、Ｅｔｈｅｒｎｅｔ（登録商標）端子のような物理的なネットワークインターフェースを少なくとも一つ有する。ネットワーク上にてそのアドレスを指定されて動作する独立したプロキシ装置でもよいし、ローカルエリアネットワーク３を抱えるゲートウェイとなる中継装置がプロキシサーバとしても動作する兼用の装置であってもよい。後者の場合、具体的には例えばルータとして機能するホームゲートウェイなどが挙げられ、ＬＡＮ（ローカルエリアネットワーク３）側と、ＷＡＮ側（インターネットゲートウェイ１２に通じるネットワーク側）との両方に対して通信可能な物理的なネットワークインターフェースをそれぞれ一つ以上有する。

プロキシとしては、セッションを一旦終端させる一般のプロキシでもよいし、セッションを終端させない透過型プロキシでもよい。一般的なプロキシの場合は、端末１４からの要求メッセージは一旦プロキシ装置１３宛に送信されるように設定され、プロキシ装置１３で一旦セッションが終端する。プロキシ装置１３はその要求メッセージを解析して、端末１４が通信しようとするサーバ１１への要求メッセージを作成しなおしてサーバ１１へ送信する。また、その要求メッセージに対するサーバ１１からの応答メッセージを送信するセッションを一旦終端して、端末１４への要求メッセージを作成し直して送信することとなる。プロキシ装置１３の端末側のセッションとサーバ側のセッションとは独立しており、それぞれを分離して扱うことができ、必要に応じたサーバ側セッションへの割り当てが可能となる。この一般的なプロキシの場合は、プロキシ装置１３はＬＡＮとＷＡＮとの間の中継装置であってもよいし、中継装置とは別の装置であって、インターネットゲートウェイ１２までのＷＡＮ内に設けられた装置であってもよい。

一方、透過型プロキシの場合は、端末１４においてはプロキシ装置１３を宛先としては認識せず、サーバ１１を直接に宛先として指定して運用される。この場合、プロキシ装置１３は端末１４からインターネットへ送られる通信を全て中継するＬＡＮとＷＡＮとの間の中継装置として設けられる。端末１４がサーバ１１宛に送信した要求メッセージについて、プロキシ装置１３が強制的にセッションを終端させ、サーバ１１に対して別途セッションを構築することで、端末側のセッションとサーバ側のセッションとを強制的に分離して扱うことで、必要に応じたサーバ側セッションへの割り当てが可能となる。ただし、端末１４側のセッションを維持するにあたっては、端末１４に対して、サーバ１１との間で直接セッションが構築されているように動作する必要がある。

インターネットゲートウェイ１２とは、ＮＡＴ（ＮＡＰＴ）機能を有する上位の中継装置であり、閉域網２からインターネット１への通信を全て中継するゲートウェイである。従って、ここにはプロキシ装置１３などの配下に接続しうるＨＧＷを初めとした中継装置全て、ひいてはそれに繋がる端末１４からインターネットへ繋がる通信の全てが集中する。

サーバ１１とは、インターネット１において要求に対してコンテンツを提供するものであり、例えばＷＥＢサーバが挙げられる。

インターネットゲートウェイ１２に繋がるプロキシ装置１３は１０２４台設置され、それぞれをＮｏ．１〜１０２４とする。プロキシ装置１３Ｎｏ．１のＬＡＮ３を構成する端末１４のＮｏ．１及び２……から要求をうけたこの発明にかかるプロキシ装置１３は、１０００１から始まり、合計で６０を超える数のセッションをサーバ１１に対して構築しようとしたときに、６１セッション目以降は既存の１〜６０のセッションの中から、通信を行っていないセッションを適当に選択して通信を行う。図２（ｂ）では、６１番目のセッションを、サーバとの間の２番目のセッションを用いて送信し、６２番目のセッションを、サーバとの間の６０番目のセッションを用いて送信している。このとき、それぞれのセッションが、プロキシ装置１３、インターネットゲートウェイ（Ｐ−ＳＡＭ）１２、サーバ１１のそれぞれを、指定しているかを図２（ｃ）に示す。閉域網２に対するプロキシ装置１３のＩＰは１９２．１６８．１．２で、そこからインターネットゲートウェイ１２を通じて、サーバ１１に対して、ポート番号１０００１〜１００６０を送信元ポート番号とし、１００．１．１．１を送信元ＩＰアドレスとし、サーバ１１のＩＰアドレスを宛先ＩＰアドレス、ＨＴＴＰのデフォルトである８０番を宛先ポート番号としている。直接にサーバ１１とセッションを張るインターネットゲートウェイ１２は、プロキシ装置１３からのセッションを中継し、自身のインターネット１におけるＩＰアドレス１００．１．１．１を送信元ＩＰアドレスとし、１０００１〜１００６０の番号でサーバ１１に対してセッションを構築している。すなわち、プロキシ装置１３は端末１４との間で、サーバ１１に対するセッションを６１以上有しているが、インターネットゲートウェイ１２とサーバ１１との間で、プロキシ装置１３に割り当てられたセッション数は６０個のままで、それぞれのセッションを続けている。さらに端末１４からサーバ１１に対してセッションが張られたとしても、プロキシ装置１３は、そのとき使っていないセッションをポート番号１０００１〜１００６０の間から探して、見つかればそのセッションを利用して通信するので、インターネットゲートウェイ１２としては、予め割り当てられた枠内でのセッションのみを受け付けて処理する。すなわち、この発明においては、プロキシ装置１３のみがこの発明に特有の機能を動作させればよく、端末１４とインターネットゲートウェイ１２とサーバ１１は従来通りの動作でよい。

このプロキシ装置１３と、端末１４（Ｎｏ．１，Ｎｏ．２……を１４ａ、１４ｂ……とする。）及びサーバ１１（１１ａ，１１ｂ）との間の機能ブロック図を図３に示し、その機能を説明する。ここでは、端末１４に通じるＬＡＮ３を抱える中継装置でもあるプロキシ装置１３が、透過型ではない、一般的なプロキシサーバとしても動作する例を示す。

プロキシ装置１３は、プロキシとしての基本機能として、受信したＴＣＰストリームからＨＴＴＰメッセージを取り出し、また、応答メッセージを送信するＨＴＴＰサーバ部６２と、その取り出されたＨＴＴＰメッセージを、適切なＩＰヘッダを付与して送信し、またその応答を受信するＨＴＴＰクライアント部６７とを有する。これらの機能部が果たす役割は、通常のプロキシサーバが果たすソフトウェア処理と同じである。すなわち、ＨＴＴＰサーバ部６２は取り出したＨＴＴＰメッセージから、当該要求メッセージの真の宛先であるサーバ名を求める。このサーバ名がＩＰｖ４やＩＰｖ６のアドレスではなくドメイン名で記載されている場合は、ＨＴＴＰクライアント部６７がＤＮＳサーバに対して名前の解決を要求し、サーバ１１のアドレスを求めた上で、そのサーバ１１のアドレスをＩＰヘッダの宛先に割り当てて送信することになる。最初からＨＴＴＰメッセージ内にＩＰｖ４やＩＰｖ６のアドレスで指定されている場合はそのままそのアドレスをＩＰヘッダの宛先に割り当てるが、そのような場合は少ない。なお、必要に応じてヘッダだけでなくＨＴＴＰメッセージの内容を書き換えてもよい。こうして指定されたＩＰヘッダの宛先を見て、中継管理部６３がセッションを張る先のサーバ１１を決定する。また、サーバ１１からの要求メッセージに対しては、ＨＴＴＰクライアント部６７がそれを受信して一旦セッションを終端し、ＨＴＴＰサーバ部６２が元々の要求元であった端末１４宛のメッセージを作成して送信する。

端末１４は、ＨＴＴＰ要求メッセージを送信するＨＴＴＰクライアント部５２を有しており、サーバ１１は、ＨＴＴＰ要求メッセージに対する応答を返すＨＴＴＰサーバ部７２を有している。

また、端末１４、プロキシ装置１３、サーバ１１は、それぞれとの間で構築するセッションの数だけ、セッション終端部を有する。端末１４の端末側セッション終端部５１ａ，ｂ……はプロキシ装置１３のＬＡＮ側セッション終端部６１ａ、ｂ……とセッションを構築しており、プロキシ装置１３のＷＡＮ側セッション終端部６６は、サーバ１１のサーバ側セッション終端部７１ａ，ｂ……とセッションを構築している。これらのセッション終端部とは、具体的な例を挙げればＴＣＰのソケットに相当し、自身と宛先のＩＰアドレス及びポート番号を有し、ネットワーク層での送受信を行う。

さらにプロキシ装置１３は、この発明にかかる特徴として、応答管理テーブル６４と、セッション管理テーブル６５とを有し、これらのテーブルの中身を書き換え、参照し、指定された宛先への送受信の指示とを行う中継管理部６３を有する。実質的には、中継管理部６３により、どのセッションを割り当てて使用するかが指定されることとなる。

応答管理テーブル６４は、いずれかのＷＡＮ側セッション終端部６６（すなわち、サーバ側セッション終端部７１）から受信した応答メッセージを、どのＬＡＮ側セッション終端部６１（すなわち、端末側セッション終端部５１）へ送信するかを管理しているテーブルである。図３の構成における、応答管理テーブル６４のある時点における例を図４（ａ）に、また、ＬＡＮ側が別の端末１４からの要求によって書き換えられた別の時点における例を図４（ｂ）に示す。このテーブルの主キーはＷＡＮ側の、サーバ及びクライアントのＩＰアドレス及びポート番号からなるセッション情報であり、ＬＡＮ側のセッションは必要に応じて書き換え可能となっている。

応答管理テーブル６４のそれぞれの項目は次の意味を有する。
ＷＡＮ側サーバIPアドレスはサーバ側セッション終端部７１のバインドされているＩＰアドレス（すなわち、サーバ１１のＩＰアドレス）である。
ＷＡＮ側サーバポート番号はサーバ側セッション終端部７１のバインドされているポート番号（ＨＴＴＰの場合、大抵は８０番）である。
ＷＡＮ側クライアントＩＰアドレスはＷＡＮ側セッション終端部６６のバインドされているＩＰアドレス（すなわち、プロキシ装置１３のＷＡＮ側ＩＰアドレス）である。
ＷＡＮ側クライアントポート番号はＷＡＮ側セッション終端部６６のバインドされているポート番号であり、この番号は不定である。
ただし、クライアントポート番号を除く３つの項目が全て一致するレコードの数は、最大でも、インターネットゲートウェイ１２によってプロキシ装置１３に割り当てられたポートの数以下である。もちろん、異なるＩＰアドレスを有するサーバ１１（例えば１５０．１．１．１のサーバ１１ｂ）を宛先とするレコードについては、また別個に割り当てられたポートの数だけ存在してよい。ただし、サーバ１１側から見たセッションは、間にインターネットゲートウェイ１２が入るため、宛先ＩＰアドレスはインターネットゲートウェイ１２のそれであり、ポート番号はインターネットゲートウェイ１２のＮＡＰＴ機能によって変換されたものとなる。

一方、ＬＡＮ側サーバIPアドレスはＬＡＮ側セッション終端部６１のバインドされているIPアドレス（すなわち、プロキシ装置１３のＬＡＮ側IPアドレス）である。
ＬＡＮ側サーバポート番号はＬＡＮ側セッション終端部６１のバインドされているポート番号（Proxyの待受けポートとして設定されたものであり、８０８０などが一般的）である。
ＬＡＮ側クライアントIPアドレスは端末側セッション終端部５１のバインドされているIPアドレス（すなわち、端末１４のIPアドレス）である。
ＬＡＮ側クライアントポート番号は端末側セッション終端部５１のバインドされているポート番号であり、このポート番号は１〜６５５３５の中で個数制限は特にない。

中継管理部６３は、ＷＡＮ側のＨＴＴＰセッション（ＷＡＮ側セッション終端部６６−サーバ側セッション終端部７１）を構築するＷＡＮ側セッション確立手段の実行とともに、応答管理テーブル６４に対して新たにエントリを生成するエントリ生成手段を実行する。その実行にあたっては、ＷＡＮ側サーバの情報を、ＬＡＮ側セッション終端部６１の受信したＨＴＴＰ要求メッセージのヘッダ部である要求ＨＴＴＰヘッダから取得する。このとき応答管理テーブル６４に登録するエントリの主キーが決定される。一方、当該エントリの主キーではないＬＡＮ側の情報として、そのＷＡＮ側のＨＴＴＰセッションに対応するＬＡＮ側のＨＴＴＰセッションの情報を登録する。ただし、ＬＡＮ側の情報は後述するエントリ空白化手段によりあとでクリアされる。

さらに、中継管理部６３は、ＬＡＮ側セッション終端部６１が受信したＨＴＴＰ要求メッセージについて、ＨＴＴＰクライアント部６７によりペイロードが書き換えられたＨＴＴＰメッセージ中で指定されるサーバ１１へ、ＷＡＮ側セッション終端部６６から送信させる要求メッセージ中継手段を実行する。その送信の際、中継管理部６３は、新たなＷＡＮ側のＨＴＴＰセッションを構築せずに、無通信状態にある既存のセッションを用いて送信する場合には、そのセッションに対応する応答管理テーブル６４の既に生成されてＷＡＮ側の情報が記入されたエントリにＬＡＮ側の情報を記入するエントリ記入手段を実行する。その実行にあたっては、ＬＡＮ側クライアントの情報を、ＬＡＮ側セッション終端部６１の受信したパケットの送信元ＩＰアドレスと送信元ポート番号から取得する。

さらにまた、ＨＴＴＰクライアント部６７は、サーバ１１へ送った要求メッセージに対するサーバ１１からプロキシ装置１３宛の応答メッセージを中継管理部６３から受け取り、ＨＴＴＰヘッダを解析して、自身が送った要求に対する応答であるかを確認する。また、さらに必要に応じてパケットの中身を解析する。またこのとき、中継管理部６３がその直前にＴＣＰレベルまで解析して検索した、当該応答メッセージの宛先であるＬＡＮ側セッション終端部６１の情報も受け取る。ＨＴＴＰサーバ部６２は、この応答メッセージの内容を取り出し、大元の要求メッセージの送信元である端末１４を宛先にしてヘッダに付与した応答メッセージを作成する応答メッセージを作成し、中継管理部６３から指定されたＬＡＮ側セッション終端部６１から端末側セッション終端部５１へ送信させる応答メッセージ中継手段を実行する。

なお、図示しないが、上記の一連の応答メッセージ中継手段を実行する際に、ＨＴＴＰクライアント部６７がＨＴＴＰヘッダを解析して、パケットの変更が必要である場合は、変更を行う。その後中継管理部６３にＨＴＴＰパケットを送る。これを受け取った中継管理部６３は、ＨＴＴＰパケットをペイロードとして、ＴＣＰ以下のヘッダを印加した上で、それ以降の動作は上記と同様にＬＡＮ側セッション終端部６１からパケットを送信する。

また、これら一連の要求及び応答メッセージのやりとりにおいて、ＨＴＴＰセッションを司るのは、ＷＡＮ側においてはＨＴＴＰクライアント部６７であり、ＬＡＮ側においてはＨＴＴＰサーバ部６２である。また、ＴＣＰセッションを司るのは中継管理部６３であり、ＷＡＮ側セッション終端部６６とＬＡＮ側セッション終端部６１で終端する。なお、この発明においてＨＴＴＰセッションと記載せずに単にセッションという場合には、基本的にはＴＣＰセッションを指す。

その送信の後、中継管理部６３は、応答管理テーブル６４における、当該エントリのＬＡＮ側の情報のみを削除するエントリ空白化手段を実行する。そのため、ＬＡＮ側サーバＩＰアドレス、ＬＡＮ側サーバポート番号、ＬＡＮ側クライアントＩＰアドレス、ＬＡＮ側クライアントポート番号の4項目は空白の場合もある。

さらにまた、中継管理部６３は、後述するセッション整理手段により当該ＷＡＮ側のＨＴＴＰセッションを切断する時に、併せて、当該セッションに対応するエントリを応答管理テーブル６４から削除するエントリ削除手段を実行する。

次に、セッション管理テーブル６５について説明する。一般的なＮＡＰＴ装置や一般的なＨＴＴＰプロキシでは、ＷＡＮ側とＬＡＮ側とで一対一に対応してアドレスとポート番号とを変換できるように、ＷＡＮ側とＬＡＮ側とのどちらについても、送信元及び宛先のＩＰアドレス及びポート番号が固定値となるセッション管理テーブルが用いられる。この場合は、ＬＡＮ側ＨＴＴＰセッションが削除されれば、それに対応するＷＡＮ側ＨＴＴＰセッションを、ＷＡＮ側ＨＴＴＰセッションが削除されれば、それに対応するＬＡＮ側ＨＴＴＰセッションを単純に削除するだけでよい。しかし、本発明の場合、ＬＡＮ側ＨＴＴＰセッションとＷＡＮ側ＨＴＴＰセッションは１対１対応していないため、既存のＨＴＴＰ-Proxyのような単純な管理を行う事は出来ない。そのため、本発明のプロキシ装置で用いるセッション管理テーブル６５は、ＷＡＮ側の情報が宛先となるサーバのＩＰアドレスとサーバのポート番号のみで、プロキシ装置のＷＡＮ側の送信元ポート番号は登録されない。本発明において、どのＷＡＮ側ポート番号を用いるかは動的であり、上記応答管理テーブル６４が一時的に記録する情報だからである。このセッション管理テーブル６５の例を図５に示す。

このようなセッション管理テーブル６５は、どのＬＡＮ側セッション終端部６１（端末側セッション終端部５１に通じる）が、どのサーバ１１を宛先としているかを管理するテーブルとして、中継管理部６３により参照される。すなわち、どのＬＡＮ側セッション終端部６１を、いずれのＷＡＮ側セッション終端部６６（サーバ側セッション終端部７１に通じる）にくくりつけ可能かを、その宛先であるサーバによって絞り込むことができる。また、ＷＡＮ側のＨＴＴＰセッション（ＷＡＮ側セッション終端部６６−サーバ側セッション終端部７１）や、ＬＡＮ側ＨＴＴＰセッション（端末側セッション終端部５１−ＬＡＮ側セッション終端部６１）を切断する際に、ＬＡＮ側における残りセッション数を管理するために使用される。

中継管理部６３は、新たな端末側セッション終端部５１からＬＡＮ側セッション終端部６１に「最初の」ＨＴＴＰ要求メッセージを受信したときに、セッション管理テーブル６５にエントリを追加するエントリ追加手段を実行する。また、基本的には、ＬＡＮ側ＨＴＴＰセッション（ＬＡＮ側セッション終端部６１−端末側セッション終端部５１）が削除されるタイミングで、中継管理部６３がセッション管理テーブル６５からエントリを抹消するエントリ抹消手段を実行する。また、ＷＡＮ側ＨＴＴＰセッションが削除されるタイミングで、そのサーバ１１を宛先として、サーバ１１のポート番号に該当するエントリが応答管理テーブル６４から全て削除されていたら、セッション管理テーブル６５から、該当するサーバ１１を宛先とし、該当するポート番号を有するエントリを全て削除する総合エントリ抹消手段を実行してもよい。

また、中継管理部６３は、ＬＡＮ側及びＷＡＮ側のセッションのそれぞれについて、切断可能なものがあるか否かを検索し、切断可能なセッションを適宜削除するセッション整理手段を実行する。このセッション整理手段としては、次のようなケースでの削除手段が挙げられる。

端末側セッション終端部５１からＬＡＮ側ＨＴＴＰセッションの削除が実施された場合には、当該ＬＡＮ側セッションを削除する、終了セッション削除手段を実行するとともに、当該端末側セッション終端部５１が通信先としていたサーバ１１（サーバ側セッション終端部７１）に対応するエントリを応答管理テーブル６４から検索し、当該サーバ側セッション終端部７１とセッションを確立しているＷＡＮ側ＨＴＴＰセッションの中から、通信に使用されていないＨＴＴＰセッションを適切に切断する単独セッション削除手段を実行する。ただし、ＷＡＮ側ＨＴＴＰセッションの数は、常に、ＬＡＮ側ＨＴＴＰセッションの数以下になるように調整する。ＬＡＮ側ＨＴＴＰセッションが削除されても、ＷＡＮ側ＨＴＴＰセッションの方が少なく、かつ、ＷＡＮ側ＨＴＴＰセッションの全てが使用されている場合には、ＷＡＮ側ＨＴＴＰセッションは削除しない。

逆に、サーバ側セッション終端部７１からＷＡＮ側ＨＴＴＰセッションが削除された場合、サーバ１１側からの要求には従わなければならないので、当該セッションはＬＡＮ側の状況にかかわらず削除する強制セッション削除手段を実行する。ただしそれに引き続き、当該サーバ側セッション終端部７１とＨＴＴＰセッションを確立しているＷＡＮ側セッション終端部６６が少なくとも1つ以上残っている場合には、ＬＡＮ側ＨＴＴＰセッションは削除しない。当該サーバ側セッション終端部７１とＨＴＴＰセッションを確立しているＷＡＮ側セッション終端部６６が無くなったタイミングで、当該サーバ側セッション終端部７１にくくりつけられたＬＡＮ側ＨＴＴＰセッションをすべて削除する総合セッション削除手段を実行する。なおこのとき、中継管理部６３は、セッション管理テーブル６５に残されていた、当該サーバ側セッション終端部７１に対応するエントリを全て削除する総合エントリ抹消手段を実行してもよい。エントリを残しておくと、キャッシュが利用可能であり、同一の通信が来た場合に毎回エントリを作成し削除するという手順を行わずに済むという利点がある一方で、エントリの数が多くなりすぎるとその分メモリの消費量が多くなるというデメリットを有する。プロキシ装置１３がＨＧＷなどのメモリが潤沢でない場合には、ここでエントリを削除することでメモリの消費量を抑えて動作を安定化させることができる。

このような構成からなるプロキシ装置１３の実際の処理フローの例を説明する。
ＨＴＴＰ要求メッセージを受信した際のフローを図６の例を用いて説明する。
まず（Ｓ１０１）、ＬＡＮ側セッション終端部６１ａ、６１ｂ等（以下、まとめて「ＬＡＮ側セッション終端部６１ｘ」とする）が、対応する端末の端末側セッション終端部５１ａ，５１ｂ等（以下、まとめて「端末側セッション終端部５１ｘ」とする。添え字ｘは６１と５１とで対応する。）から送信されてきたＴＣＰストリームを受信して、ＨＴＴＰ要求メッセージを取り出す（Ｓ１０２）。ＨＴＴＰサーバ部６２は、ＨＴＴＰ要求メッセージの内容を解析して、宛先などを判別して、ＨＴＴＰクライアント部６７に内容を渡す（Ｓ１０３）。一般的なプロキシ装置１３では、受信したＩＰパケットそのものの宛先がプロキシ装置１３自体となっている。本来の宛先であるサーバ１１のアドレスは、この段階で、ＨＴＴＰ要求メッセージの中のＨＴＴＰヘッダを読むことでようやく判別できる。ただし、読み取ったサーバ１１のアドレスはドメインネームで記載されていることがほとんどであるため、ＤＮＳの名前を解決してＩＰｖ４又はＩＰｖ６のアドレスを取得しなければならない。この名前の解決は一般的なＤＮＳプロキシ機能（図示せず）によって行うとよい。

受け取った上記の要求メッセージの内容を渡されたＨＴＴＰクライアント部６７は、プロキシの一般的動作と同様に、サーバ１１宛のＨＴＴＰ要求メッセージを作成し、解析されたＨＴＴＰヘッダのリクエストラインやＨｏｓｔヘッダフィールドから、サーバ１１のサーバ側セッション終端部７１ａ，７１ｂ等（以下、まとめて「サーバ側セッション終端部７１ｙ」とする）を包括的に指定することになる、宛先ＩＰアドレス及びポート番号を決定する（Ｓ１０４）。
なお、当然に宛先ＩＰアドレスはインターネット１上におけるサーバ１１のグローバルＩＰアドレスであり、ポート番号はＨＴＴＰであれば一般的には８０番を用いることが多い。

中継管理部６３は、この決定された情報のうち、宛先ＩＰアドレスから、ＨＴＴＰ要求メッセージを送信するためのＷＡＮ側セッション終端部６６ｙを選択、決定する（Ｓ１０５）。このとき、ＷＡＮ側セッション終端部６６ｙが既に存在している場合とまだ存在していない場合とがあり、また、セッション数が上限値に達しているか否かといった状況に応じて動作が異なる。詳しくは後述する。その上で中継管理部６３は、セッション管理テーブル６５の情報を更新するエントリ追加手段を実行する（Ｓ１０６）。その内容も後述する。選択されたＷＡＮ側セッション終端部６６ｙから、サーバ１１のサーバ側セッション終端部７１ｙに対して、ペイロードにＨＴＴＰ要求メッセージを内包したＴＣＰストリームを送信する（Ｓ１０７）。これで要求メッセージの処理は一旦終了し、応答メッセージの受信を待つことになる（Ｓ１０８）。

上記Ｓ１０５で行う、中継管理部６３によるセッション終端部の選択フローについて、図７を用いて説明する。なお、この直前のＳ１０４で、宛先となるサーバ１１のアドレスは確定している。
まず（Ｓ１３１）、中継管理部６３は、応答管理テーブル６４から、宛先のサーバ１１に対して確立されているセッションのうち、ＨＴＴＰの応答待ちではないセッションがあるか否かを検索する（Ｓ１３２）。すなわち、ここで、サーバ側セッション終端部７１ｙのＩＰアドレスとはサーバ１１のＩＰアドレスであり、主キーの一つであるＷＡＮ側サーバＩＰアドレスが宛先のサーバであって、ＬＡＮ側が空白になっているエントリがあるか否かを検索する。そのような空きエントリが存在しておらず（Ｓ１３３→Ｎｏ）、かつ、サーバ１１に対するＷＡＮ側セッション終端部６６の数が、インターネットゲートウェイ１２により制限されるポート番号の数の上限未満であれば（Ｓ１３４→Ｎｏ)、新たにセッションを構築する余地があるので、ＷＡＮ側セッション終端部６６ｙ（すなわち、ポート番号を割り当てたソケット）を作成し、サーバ１１のサーバ側セッション終端部７１ｙとセッションを確立するＷＡＮ側セッション確立手段を実行する（Ｓ１３５)。なお、サーバ１１との間に最初にセッションを張る場合もこの流れになる。その上で、この確立したセッションの情報を、応答管理テーブル６４に新規エントリとして作成するエントリ作成手段を実行する（Ｓ１３６）。このときできたＷＡＮ側の設定は固定であるが、ＬＡＮ側の設定として登録する、Ｓ１０２で受信した際の端末１４との間のセッション情報は、後でクリアされることになる。応答管理テーブル６４へのエントリ作成が終わったら、作成したＷＡＮ側セッション終端部６６ｙを引数として、次のＳ１０６へ移る（Ｓ１３７）。

一方、Ｓ１３３で該当するエントリが存在した場合、すなわち、ＷＡＮ側が該当し、ＬＡＮ側が後述するエントリ抹消手段によりクリアされた空きエントリが存在している場合（Ｓ１３３→Ｙｅｓ）、そのエントリのＬＡＮ側カラムに、ＬＡＮ側のＴＣＰセッションの両端点の情報を登録するエントリ記入手段を実行する（Ｓ１４１）。ＬＡＮ側セッション終端部６１ｘと端末側セッション終端部５１ｘとの両端点のＩＰアドレスとポート番号がわかれば、ＴＣＰセッションが唯一に決まる。これにより、主キーであるＷＡＮ側セッションに一時的に紐付けられるＬＡＮ側セッションが決定される。その上で、ＷＡＮ側のクライアントＩＰアドレスとＷＡＮ側クライアントポート番号に合致するＷＡＮ側セッション終端部６６ｙを選択し（Ｓ１４２）、これを引数として、次のＳ１０６に移る（Ｓ１３７）。すなわち、空いていたポート番号を選択し、そのポート番号に対応するセッションで送信する要求メッセージ中継手段の準備をする。

なお、ＷＡＮ側の情報が一致してＬＡＮ側がクリアされたエントリが存在せず、（Ｓ１３３→Ｎｏ）、サーバ１１（例えばサーバ１１ａ）に対するＷＡＮ側セッション終端部６６の数が上限に達していたら（Ｓ１３４→Ｙｅｓ)、この時点ではサーバ１１宛のセッションを張ることができないので、待機状態となって、エントリが空くまで待つ（Ｓ１３２）。

次に、上記Ｓ１０６で行う、中継管理部６３によるセッション管理テーブル６５の更新フローについて、図８を用いて説明する。まず（Ｓ１５１）、セッション管理テーブル６５の中に、宛先であるサーバ１１のサーバ側セッション終端部７１に対応するＩＰアドレス及びサーバポート番号が一致するとともに、ＬＡＮ側のセッションの情報とも一致するエントリがあるか否かを検索する（Ｓ１５２）。エントリが存在したら（Ｓ１５３→Ｙｅｓ）、そのサーバへのセッションはその前から引き続き通信されるものであるので、そのまま次のＳ１０７へ移って、Ｓ１０５で引数として渡されたＷＡＮ側セッション終端部６６ｙを通じて要求メッセージを送信する。エントリが存在しなかったら（Ｓ１５３→Ｎｏ）、そのサーバ１１へは初めて通信されるものであるため、エントリ追加手段を実行し（Ｓ１５４）、Ｓ１０５で引数として渡されたＷＡＮ側セッション終端部６６ｙを通じて要求メッセージを送信する。

上記のＳ１０７で送信された要求メッセージに対するサーバ１１からの応答メッセージを受信し、中継して送信する際のフローを、図９を用いて説明する。まず（Ｓ２０１）、ＷＡＮ側セッション終端部６６ｙが、サーバ１１のサーバ側セッション終端部７１ｙからＴＣＰストリームを受信し、ペイロードからＨＴＴＰ応答メッセージを取得する（Ｓ２０２）。中継管理部６３はこれを受けて、応答管理テーブル６４を検索して、ＷＡＮ側の情報が一致するエントリを検索し、そのエントリのＬＡＮ側情報を得る。これにより、今受信した応答メッセージに対応する要求メッセージを送信したＬＡＮ側のセッションを特定する。これにより、応答メッセージの返信先となる端末１４のアドレスと、クライアントポート番号が特定でき、すなわち、送信に用いるソケットである端末側セッション終端部５１ｘと、それに繋がるＬＡＮ側のＬＡＮ側セッション終端部６１ｘを特定する（Ｓ２０３）。その上で、プロキシ装置１３の基本的機能である、ＨＴＴＰクライアント部６７が、ＨＴＴＰ応答メッセージを解析し（Ｓ２０４）、同じくプロキシ装置１３の基本的機能であるＨＴＴＰサーバ部６２が、ＨＴＴＰ応答メッセージを作成する（Ｓ２０５）。これはすなわち、プロキシとしては、先に受信した要求メッセージに対する応答メッセージである。このＨＴＴＰ応答メッセージを、先にＳ２０３で特定したＬＡＮ側セッション終端部６１ｘから、セッションの先である端末１４の端末側セッション終端部５１ｘに対して、ペイロードにＨＴＴＰ要求メッセージを内包したＴＣＰストリームを送信する（Ｓ２０６）。これが完了したら、ひとまず要求に対する応答は終わったので、サーバ１１とのセッションはアクティブなものではなくなる。そこで、応答管理テーブル６４から、応答先の送信に用いたエントリのＬＡＮ側部分をクリアするエントリ空白化手段を実行する（Ｓ２０７）。これによりＬＡＮ側とＷＡＮ側とのセッションの括り付けは解除され、当該エントリに対応するＷＡＮ側のセッションは無通信状態となり、Ｓ１３２以降の処理で他のＬＡＮ側セッションが使用できるようになる。

上記のような工程で要求と応答がされるが、ＷＡＮ側のセッションは応答終了後に応答管理テーブル６４におけるＬＡＮ側の情報のみをクリアしておくだけでなく、不要になったらＷＡＮ側のセッションそのものを削除しておくことが好ましい。インターネットゲートウェイ１２が、各々のプロキシ装置１３に割り当てるポートの数を動的に変更する場合もあり、その場合には、どれかのプロキシ装置１３が無用なセッションを削除することによって、他のプロキシ装置１３が使えるセッションが増えることになるからである。また、ネットワーク処理自体の高速化のためにも、不要なセッションはＷＡＮ側、ＬＡＮ側ともに削除しておくことが好ましい。

まず、ＬＡＮ側ＨＴＴＰセッション切断時のフローについて図１０を用いて説明する。端末１４の端末側セッション終端部５１ｘと、プロキシ装置１３のＬＡＮ側セッション終端部６１ｘとの間で確立しているＨＴＴＴＰセッションの切断契機が発生した場合に（Ｓ３０２）、次のフローを実施する。ここで、ＬＡＮ側のセッションの切断契機とは、ＲＦＣの一般的な規定に従うものであり、具体的には、Ｋｅｅｐ−Ａｌｉｖｅのタイムアウトや、端末側セッション終端部５１ｘからのＴＣＰ−ＦＩＮを受信した場合などが挙げられる。このとき、セッション管理テーブル６５の中から、切断契機が発生したセッションのＩＰアドレス及びポート番号と、ＬＡＮ側の情報が一致するエントリを取得する（Ｓ３０３）。そのエントリのＷＡＮ側情報を参照して、切断しようとしているＬＡＮ側セッションが通信していたサーバ１１のアドレスを特定する（Ｓ３０４）。なお、基本的にサーバポート番号は８０番である状況を想定しているが、サーバポート番号として様々な番号を用いることを許容するサーバ１１であれば、このときにエントリに対応するポート番号も特定して、サーバ側セッション終端部７１ｙを特定する。その上で、そのサーバ１１と、同一サーバポート番号で通信しているＬＡＮ側セッションの数をセッション管理テーブル６５内でカウントして、Ｘとする（Ｓ３０５）。次に、応答管理テーブル６４において、同じサーバ１１と通信しているＷＡＮ側のセッションの数をカウントして、Ｙとする（Ｓ３０６）。すなわち、応答管理テーブル６４には、アクティブか非アクティブかに関わらず、ＷＡＮ側のセッションが全て記載されており、セッション管理テーブル６５には、ＷＡＮ側のポート番号を考慮することなく、各サーバ（及びサーバポート番号）に繋がるＬＡＮ側のセッションが全て記載されているので、それぞれをカウントしてＬＡＮ側をＸ，ＷＡＮ側をＹとする。

ここで、ＸよりＹが大きいか否かを判断する（Ｓ３０７）。すなわち、ＬＡＮ側よりＷＡＮ側のセッションの方が多ければ（Ｓ３０７→Ｙｅｓ）、ＷＡＮ側のセッションの数は、最大でもＬＡＮ側のセッション数あれば十分であるので、余分なセッションは削除する。このとき、応答管理テーブル６４で検索するのは、ＬＡＮ側のカラムが空白、すなわち、通信状態にはなく休止状態のセッションであり、該当するエントリを応答管理テーブル６４から一つ削除するとともに、それに対応するＷＡＮ側セッション終端部６６を一つ削除する単独セッション削除手段を実行する（Ｓ３１１）。このとき、該当するエントリ及びＷＡＮ側セッション終端部６６が対応していれば、どのエントリ（ＷＡＮ側セッション終端部６６）を削除してもよいが、例えば、セッションの生成が古いものから削除していくなどの一定の基準によって削除するとよい。一つ削除した後、Ｙをカウントし直して（Ｓ３１２→Ｓ３１３→Ｓ３０６）、再びＸとＹとを比較し（Ｓ３０７）、まだ該当するようであれば、さらにエントリとＷＡＮ側セッション終端部６６を削除する（Ｓ３１１）。

一方、ＸがＹより大きいか、あるいは同じ（Ｓ３１１によって同数になった場合を含む）である場合には（Ｓ３０７→Ｎｏ）、セッション管理テーブル６５から、Ｓ３０３で取得したエントリを削除し（Ｓ３０８）、それに対応するＬＡＮ側セッション終端部６１ｘを削除する終了セッション削除手段を実行して（Ｓ３０９）フローを終わる（Ｓ３１０）。

次に、ＷＡＮ側ＨＴＴＰセッション切断時のフローについて図１１を用いて説明する。
サーバ１１のサーバ側セッション終端部７１ｙと、プロキシ装置１３のＷＡＮ側セッション終端部６６ｙとの間で確立しているＨＴＴＰセッションの切断契機が発生した場合に（Ｓ３３２）、次のフローを実施する。ここで、ＷＡＮ側のセッションの切断契機とは、ＲＦＣの一般的な規定に従うものであり、具体的には、Ｋｅｅｐ−Ａｌｉｖｅのタイムアウトや、サーバ側セッション終端部７１ｙからのＴＣＰ−ＦＩＮを受信した場合などが挙げられる。サーバ１１側から切断の要求があった場合は、インターネットゲートウェイ１２側（すなわちプロキシ装置１３側）の事情にかかわらず、そのセッションは削除しなければならないためである。
まず、応答管理テーブル６４の中から、切断契機が発生したセッションのＩＰアドレス及びポート番号と、ＷＡＮ側の情報が一致するエントリを削除し（Ｓ３３３）、対応するＷＡＮ側セッション終端部６６ｙを削除する強制セッション削除手段を実行する（Ｓ３３４）。

さらにその上で、当該サーバ１１のＩＰアドレスと、先に削除したセッションのポート番号とが一致するエントリが、応答管理テーブル６４の中にあるか否かを検索する（Ｓ３３５）。すなわち、削除契機が発生したのと同じサーバ１１と、同じサーバポートで通信しているＷＡＮ側のＴＣＰセッションが存在するか否かを検索する。このエントリが存在しているならば（Ｓ３３６→Ｙｅｓ）、サーバ１１との間でのセッションは他にもまだ存在していて通信が継続される可能性があるので、ＬＡＮ側のセッションはひとまず削除せずにそのままとする。ＬＡＮ側セッションはそのまま通信が再開されることなく放置されたとしても、上記の通り、ＬＡＮ側セッション自体のタイムアウトなどによって、単独セッション削除手段により削除される。一方、エントリが存在していないならば（Ｓ３３６→Ｎｏ）、サーバ１１との間で通信することはひとまず無くなったことになるので、当該サーバ１１を宛先ＩＰアドレスとして指定するセッション管理テーブル６５のエントリを削除する総合エントリ抹消手段を実行するとともに、当該エントリに合致する端末側セッション終端部５１に接続しているＬＡＮ側セッション終端部６１を全て削除する、総合セッション削除手段を実行する（Ｓ３３７）。ただし、上記の通り、プロキシ装置１３のメモリが潤沢にある場合には、エントリを残していてもよいので、総合エントリ抹消手段は実行しなくてもよい。

なお、この図１１のフローのうち、実際の実装に当たって必須なのは、Ｓ３３４までであり、その他の部分（Ｓ３３７等）は実装しなくても運用が可能である。その場合、サーバ１１とのＷＡＮ側のセッションが全て切断されているにもかかわらず、ＬＡＮ側の端末はそれを検知していないという、ＷＡＮとＬＡＮとの状態不整合が発生する。しかし、ＷＡＮ側のセッションが全て削除されている状態で、ＬＡＮ側から要求メッセージを受信すれば、図６のＳ１０５（すなわち図７）のフローに従って、新しいＷＡＮ側セッションが確立されるため、状態の不整合が理由で通信が不可能になる危険はない。

なお、この発明はＨＴＴＰプロトコルに限らず、他のプロトコルであっても、送信した要求の順番に対して応答の順番が保証されている、すなわち、応答の順番が入れ替わることがないことが保証されており、端末側（すなわちＬＡＮ側）からの通信しか発生しないことが保証されているプロトコルであれば、同様に利用が可能である。

１ インターネット
２ 閉域網
３ ローカルエリアネットワーク
１１，１１ａ，１１ｂ サーバ
１２ インターネットゲートウェイ
１３ プロキシ装置
１４ 端末
５１，５１ａ，５１ｂ、５１ｘ 端末側セッション終端部
５２ ＨＴＴＰクライアント部
６１、６１ａ、６１ｂ、６１ｘ ＬＡＮ側セッション終端部
６２ ＨＴＴＰサーバ部
６３ 中継管理部
６４ 応答管理テーブル
６５ セッション管理テーブル
６６、６６ａ、６６ｂ、６６ｙ ＷＡＮ側セッション終端部
６７ ＨＴＴＰクライアント部
７１、７１ａ、７１ｂ、７１ｙ サーバ側セッション終端部
７２ ＨＴＴＰサーバ部

Claims (6)

1. インターネットゲートウェイと端末との間の通信を中継するプロキシ装置であって、
   上記インターネットゲートウェイを経由するインターネット上の一のサーバとの間のセッション数を、一定数以下でありかつ、上記一のサーバを宛先とする端末側とのセッション数以下に限定し、
   端末側から上記一のサーバへの通信要求を新たに受信した際には、上記一のサーバとの間のセッションのうちその時点で通信を行っていないセッションを利用して、上記一のサーバとの通信を行う、プロキシ装置。
2. 上記端末との間でＴＣＰストリームを送受信し、受信したＴＣＰストリームからＨＴＴＰ要求メッセージを取り出す、ポート番号ごとに存在する複数のＬＡＮ側セッション終端部と、
   上記サーバとの間でＴＣＰストリームを送受信し、受信したＴＣＰストリームからＨＴＴＰ応答メッセージを取り出す、ポート番号ごとに存在する複数のＷＡＮ側セッション終端部と、
   上記ＨＴＴＰ要求メッセージを解析して要求ＨＴＴＰヘッダを読み取り、かつ、上記ＨＴＴＰ応答メッセージの応答ＨＴＴＰヘッダから転送先となるＬＡＮ側セッション終端部を決定するＨＴＴＰサーバ部と、
   上記要求ＨＴＴＰヘッダから送信先となるＷＡＮ側セッション終端部のＩＰアドレスとポート番号とを決定して要求メッセージを作成し、かつ、受信したＨＴＴＰ応答メッセージを解析して上記応答ＨＴＴＰヘッダを読み取るＨＴＴＰクライアント部とを有し、
   上記ＬＡＮ側セッション終端部についての送信元及び宛先のアドレス及びポート番号と、そのセッションの宛先であるサーバのアドレス及びサーバポート番号とを対応させて記録するセッション管理テーブルと、
   上記要求メッセージを中継する上記ＷＡＮ側セッション終端部についての送信元及び宛先についてのアドレス及びポート番号を主キーとしてエントリを登録され、そのサーバ側セッションに一時的に結びつける端末側のセッション情報をエントリに一時的に登録され、上記ＬＡＮ側セッション終端部から上記ＨＴＴＰ応答メッセージを送信完了した際には、当該エントリから端末側のセッション情報のみを削除可能とした応答管理テーブルと、
   上記セッション管理テーブル及び上記応答管理テーブルの上記エントリを更新させ、かつそれらを参照して通信を中継させる中継管理部と
   を有する
   請求項１に記載のプロキシ装置。
3. 上記の中継管理部が、ＬＡＮ側及びＷＡＮ側のセッションのそれぞれについて、切断可能なものがあるか否かを検索し、切断可能な上記ＬＡＮ側セッション終端部、上記ＷＡＮ側セッション終端部又はその両方を削除するセッション整理手段を実行する、請求項２に記載のプロキシ装置。
4. 上記セッション整理手段として、
   上記中継管理部が、上記サーバとの間でＨＴＴＰの切断契機が発生した場合に、それに対応する上記ＷＡＮ側セッション終端部を削除する強制セッション削除手段を実行しうる、請求項３に記載のプロキシ装置。
5. 上記セッション整理手段として、
   上記中継管理部が、上記強制セッション削除手段を実行した後、応答管理テーブルから、ＷＡＮ側IPアドレス及びＷＡＮ側サーバポート番号が上記強制セッション削除手段により削除された上記ＷＡＮ側セッション終端部における当該情報と一致するエントリが存在するか否かを検索し、存在しなければ、上記セッション管理テーブルから、当該ＷＡＮ側ＩＰアドレス及びＷＡＮ側サーバポート番号に該当するエントリを検索し、そのエントリに該当する上記ＬＡＮ側セッション終端部を全て削除する総合セッション削除手段を実行しうる、
   請求項４に記載のプロキシ装置。
6. 上記セッション整理手段として、
   上記中継管理部が、同一のサーバを宛先としかつサーバポート番号が一致するＬＡＮ側のセッションの数とＷＡＮ側のセッションの数を比較し、ＷＡＮ側のセッションの数の方が多い場合に、上記ＷＡＮ側セッション終端部を少なくとも一つ削除する単独セッション削除手段を実行しうる、
   請求項３乃至５のいずれかに記載のプロキシ装置。

Images