(57)【要約】【課題】中継装置とサーバとの通信において、ポート番号の枠による限界を超えてセッションを構築できるようにする。【解決手段】同一ドメイン名で異なるＩＰアドレスを有する冗長化サーバ群へのアクセスにあたっては、それら冗長化サーバ群のうちの一の冗長化サーバに対するセッション数が上限に達したときに、他の冗長化サーバへの通信とするように、中継装置でパケットの宛先を変更する。【選択図】図２
2014045245.tif 000002
【特許請求の範囲】
【請求項１】
ＬＡＮ側からの通信に対して、ドメイン名解決を行うＤＮＳ−ＰＲＯＸＹ機能部と、
ＬＡＮ側とＷＡＮ側とを行き来するパケットについて、アドレス及びポート番号を変更して中継するＮＡＰＴ機能部と、
そのＮＡＰＴ機能を実行するためにＬＡＮ側とＷＡＮ側との両方における宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ポート番号、送信元ポート番号を記録したセッション管理テーブルとを有する中継装置であって、
一のドメイン名に対するドメイン名解決の際に、冗長化された複数のサーバからなる冗長化サーバ群のそれぞれのサーバを指定する複数のＩＰアドレスを返却された際に、それら複数のＩＰアドレスを前記ドメイン名と結びつけて保持可能なＤＮＳキャッシュを有し、
ＬＡＮ側からの新たなセッションを構築しようとするパケットが、上記ＤＮＳキャッシュに同一ドメイン名で複数のＩＰアドレスを有するうちの一つのＩＰアドレスを宛先ＩＰアドレスとして指定するものであるか否かを判断する宛先ＩＰ判定機能部を有し、
該当する場合は、上記ＮＡＰＴ機能部に、その宛先ＩＰアドレスを、上記ＤＮＳキャッシュに同一ドメイン名についてのＩＰアドレスとして保持された他の冗長化サーバのＩＰアドレスに変更させる中継装置。
【請求項２】
受信したパケットに対して上記宛先ＩＰ判定機能部の判定により宛先ＩＰアドレスの変更を実行した上で中継する条件が、
上記セッション管理テーブルにおいて、ＬＡＮ側から受信したパケットの宛先ＩＰアドレスと、送信先である冗長化サーバを指定するＩＰアドレスとが合致するエントリの数が、予め指定された上限値を超過する場合である、請求項１に記載の中継装置。
【請求項３】
受信したパケットに対して上記宛先ＩＰ判定機能部の判定により宛先ＩＰアドレスの変更を実行した上で中継する条件が、
上記セッション管理テーブルにおいて、上記冗長化サーバ群のうちの一の冗長化サーバのＩＰアドレスを宛先ＩＰアドレスとするエントリが、上記冗長化サーバ群のうちの他の冗長化サーバのＩＰアドレスを宛先ＩＰアドレスとするエントリに対して、予め定めた差以上となった場合である
請求項１に記載の中継装置。
【請求項４】
請求項２に記載の中継装置が複数設けられ、インターネットに繋がる上位中継装置が設けられた閉域網の運用方法であって、
上記上限値が、上記上位中継装置から上記中継装置に割り当てられたポート番号数に対応する数である、閉域網の運用方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ＩＰｖ４を利用する環境下で複数の中継装置が上位の巨大中継装置に集約されている際における、通信の効率化に関する。
【背景技術】
【０００２】
ＩＰｖ４のグローバルＩＰアドレスは枯渇状態にあり、中継装置が有する一つのグローバルＩＰアドレスを、複数の端末や装置で共有することが一般的になっている。グローバルＩＰアドレスに限らず、一つのＩＰアドレスを複数の装置や端末で共有する方法として、ＮＡＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ）又はＮＡＰＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｐｏｒｔ  Ｔｒａｎｓｌａｔｉｏｎ）（以下、まとめて「ＮＡＴ」と呼称する。）が用いられている。中継装置がＮＡＴを実行する際には、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）側からＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）側へのパケットを受信したときに、ＬＡＮ側のどのアドレスから来たパケットをどのようにしてＷＡＮ側へ送出したかを記録するセッション管理テーブルを保持し、ＷＡＮ側からパケットを受信した際には、そのパケット情報を元にＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）側のどのアドレスへ中継するかを判断する。
【０００３】
ＮＡＴとして一般的な５−ｔｕｐｌｅでは、ＷＡＮ側から受信したパケットの「送信元ＩＰアドレス」「送信元ポート番号」「宛先ＩＰアドレス」「宛先ポート番号」「プロトコル」の５つの情報によって、ＬＡＮ側のどのアドレスへ中継するかを判断する。この５−ｔｕｐｌｅのように、ポート番号とアドレスとで中継を管理する場合、中継装置に繋がる端末が特定のサーバの同じポートに対して複数のセッションを確立するには、中継装置のＷＡＮ側ポート番号は、端末ごとに異なるものでなくてはならない。そのため、中継装置の配下に複数の端末が接続されていると、１つの端末が利用できる中継装置のＷＡＮ側ポート番号の数は、端末数に反比例して少なくなる。中継装置が利用可能なポート番号は０〜６５５３５までの６５５３６種類に限定されており、それを配下に抱える端末間で共有しなければならないからである。仮に中継装置に直結する配下の端末を６５５とすると、一端末あたりのポート番号は１００にまで制限されてしまう。しかし実際にはポート番号の共有は一様ではなく、一つの端末が多くのポート番号を占有してしまうことがある。これに対して、配下の端末をグループに分けて、特定のグローバルネットワーク上のサーバとの間のセッション数をグループ毎に制限する方法が特許文献１に提案されている。ただし、これは端末を利用する利用者間の不公平感を無くす方法であり、割り当て可能なポート番号の上限を解決するための方法ではない。
【０００４】
ところで、ＩＰｖ４アドレスの枯渇に伴い、ＩＰｖ６で構築されたネットワークが使われるようになってきているが、依然としてＩＰｖ４でしか接続できないネットワークも多数残っているため、ＩＰｖ６ネットワークでＩＰｖ４アドレスを利用するアドレス変換が行われている。例えば、ＩＰｖ６で構築された閉域網で、ＩＰｖ４のグローバルＩＰアドレスを有する上位の中継装置が有し、その配下にＩＰｖ４のローカルＩＰアドレスを割り当てられた宅内用の中継装置が多数接続され、さらにその宅内用中継装置に、宅内中継装置によって管理されるＩＰｖ４のローカルＩＰアドレスを有する複数の端末が繋がるという構成が実際に存在している。このようにＩＰｖ６ネットワークでＩＰｖ４を利用する場合には、上位の中継装置は、配下の中継装置に割り当てるＩＰｖ６アドレスを、所定のプレフィックスの後に続く半ばや末尾にＩＰｖ４のアドレスを配したものという構成に限定することで、ＩＰｖ４とＩＰｖ６とのアドレス変換を、変換テーブルなどを設けることなく自動的に行うＳＡＭ（Ｓｔａｔｅｌｅｓｓ  Ａｄｄｒｅｓｓ  Ｍａｐｐｉｎｇ）が用いられる場合がある。配下に抱える端末の数が多くなり、それら全てについていちいちテーブルを参照して変換していたのでは、上位の中継装置にかかる負荷が大きくなりすぎるためである。
【０００５】
しかし、このような上位の中継装置（ＬＳＮ：ＬａｒｇｅＳｃａｌｅＮＡＴ）が配下に宅内中継装置を抱えるような場合には、ＬＳＮのポート番号を複数の宅内中継装置に割り当てる形で共有し、さらにそれぞれの宅内中継装置に割り当てられたポートを、配下の端末に割り当てることになるため、各端末が確立可能なセッション数の上限は非常に小さいものとなってしまう。そのような環境下では、管理すべきセッションの数が多すぎてメモリ開放待ち時間のカウントが間に合わず、開放できるはずのセッションを開放できなくなる場合がある。これに対して、ＴＣＰのセッションが許容量を超えた場合には、通常は使用中として開放されないＴＩＭＥ＿ＷＡＩＴ状態のセッションに上書きすることでその状況を凌ぐ方法が特許文献２に記載されている。
【０００６】
また、一つのポートを複数の端末で共有するために、ＷＡＮ側からＬＡＮ側へパケットを送出する際に、アプリケーションレイヤに端末を特定する情報を付与する方法が特許文献３に記載されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１０−１０３７０９号公報
【特許文献２】特開２０１１−１７２２０１号公報
【特許文献３】特開２００９−１４６３０６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、特許文献２の方法ではＴＣＰセッションがＷＡＩＴではなく実際に使用中の場合は上書きできないため、実際に一つのサーバへのアクティブな通信が集中している場合には適用できず、状況を解決することができなかった。
【０００９】
また、特許文献３の方法では、アプリケーションレイヤに情報を組み込むため、パケット処理が低速になり、中継装置にかかる負荷が増加してしまうという問題があった。
【００１０】
そして、インターネット上でリッチコンテンツを提供する機会が増えた近年では、端末上のアプリケーションがインターネットから大量の情報を高速にダウンロードする目的で、一つのサーバに対して複数のセッションを張り、同時並行で通信を行うという実装が増えてきている。このため、上位の中継装置の配下に宅内中継装置が複数連なる構成で、上位の中継装置のポートを多段に繋がる多数の端末で共有する際に、ポートが重複してセッションが確立できない現象がさらに発生しやすくなっている。
【００１１】
そこでこの発明は、中継装置とサーバとの通信において、ポート番号の枠による限界を超えてセッションを構築できるようにすることを目的とする。
【課題を解決するための手段】
【００１２】
この発明は、配下に端末を抱えてＤＮＳ−ＰＲＯＸＹ機能を有する中継装置に、
一のドメイン名に対するドメイン名解決の際に、冗長化された複数のサーバからなる冗長化サーバ群のそれぞれのサーバを指定する複数のＩＰアドレスを返却された際に、それら複数のＩＰアドレスを保持可能なＤＮＳキャッシュと、
ＬＡＮ側からの新たなセッションを構築しようとするパケットが、上記ＤＮＳキャッシュに同一ドメイン名で複数のＩＰアドレスを有するうちの一つのＩＰアドレスを宛先ＩＰアドレスとして指定するものであるか否かを判断する宛先ＩＰ判定機能部を持たせ、
該当する場合は、ＮＡＰＴ機能部に、その宛先ＩＰアドレスを、上記ＤＮＳキャッシュに同一ドメイン名についてのＩＰアドレスとして保持された他の冗長化サーバのＩＰアドレスに変更させることで、上記の課題を解決したのである。
【００１３】
これは、アクセス数の多いポータルサイトなどでは、単一のサーバではアクセスを処理できないため、同一ドメインを有するサーバを複数設けることで、負荷分散を図っていることを利用している。このような冗長化サーバ群は、同じドメイン名を持ちながらＩＰアドレスが異なる複数のサーバからなり、サーバとして提供するコンテンツは基本的に同一となるように設定されている。このため、これらの冗長化サーバ群のいずれにアクセスしても、端末としては同一の結果が得られる。このような冗長化サーバ群のＩＰアドレスはＤＮＳサーバに複数まとめて登録されており、ＤＮＳの名前の解決要求に対して、複数のＩＰアドレスを返却する。
【００１４】
そこで、ＤＮＳ−ＰＲＯＸＹ機能を持つ中継装置に、その複数のＩＰアドレスをまとめて保持可能なＤＮＳキャッシュを持たせる。通常ならばＤＮＳキャッシュとしては一つのドメイン名に対して一つのＩＰアドレスを記録しておけば済むが、本発明では一つのドメイン名に対して登録された冗長化サーバ群の複数のＩＰアドレスを記録しておくことで、それらのＩＰアドレスの間で、宛先となるＩＰアドレスを変更できるようにする。これにより、冗長化サーバ群のうち、一つの冗長化サーバに対するセッション数が、割り当てられたポート番号数の限界に達している状況でさらにセッションを構築しようとした場合、同じドメイン名の冗長化サーバ群に対する通信を、別のＩＰアドレスを有する他の冗長化サーバに対するセッションに差し替えることで、その限界を超えてセッションを構築することができる。あるいは、その限界に達する前に、冗長化サーバ群を構成する冗長化サーバの個々に対して、セッション数ができるだけ均等になるように、中継装置が宛先を差し替えてもよい。
【００１５】
この発明を実施するにあたり、中継装置が抱える端末の利用者は特に何も意識することはない。端末としてはあるドメイン名を有するサーバへのアクセスを行うにあたり、ＤＮＳ−ＰＲＯＸＹとなる中継装置にＤＮＳの名前の解決を要求し、返却されてきたＩＰアドレスを宛先としてパケットを送出する。これを受けた中継装置が、適宜必要に応じて当該パケットの宛先ＩＰアドレスを変更して中継し、また、そうして差し替えた先である他の冗長化サーバから返ってきた返答のパケットの送信元ＩＰアドレスを、当該端末が元々指定していた一の冗長化サーバのＩＰアドレスに変更した上で、当該パケットを端末へ送信することになる。
【００１６】
ここで中継装置が同一の宛先ＩＰアドレスに対して張ることが出来るセッションの数（すなわちポート番号の数）は、より上位の中継装置（例えばＬＳＮ）が抱える下位の中継装置の数によって限定されるものであり、その割り当てられる数は、予め上位の中継装置から指定された上でその数に従ってセッションを張っても良い。また、中継装置がより上位の中継装置に対してセッションを構築しようとした要求が拒絶されることで、セッション数が限界に達していることを検知して、宛先ＩＰ判定機能によりＩＰアドレスの変更を実施してもよい。なお、中継装置がインターネットに直接接続している場合には、上位の中継装置が存在しないが、この場合には同一ＩＰアドレスのサーバに対して張ることが出来るセッションの数は、規定通りの６５５３６となる。
【発明の効果】
【００１７】
この発明により、上位中継装置に多数の下位中継装置が接続されている環境で、一のサーバに対して個々の下位中継装置及びそれに繋がる端末に配分可能なポート番号の数が限定されている環境で、セッション数の上限を実質的に拡張することができる。下位中継装置側（すなわち端末側）から一のサーバに対して新たなセッションを構築しようとする際に、そのサーバが一のドメイン名に複数の冗長化サーバ群が割り当てられていれば、その冗長化サーバ群のいずれかへのセッションの構築に変更することで、実質的にセッションの上限値は冗長化サーバ群を構成するサーバの数を乗じただけ向上させることが出来る。
【図面の簡単な説明】
【００１８】
【図１】この発明にかかる中継装置を設置するネットワークの例図
【図２】この発明にかかる中継装置の機能ブロック図
【図３】ＤＮＳキャッシュの例図
【図４】セッション管理テーブルの例図
【図５】この発明にかかる中継装置がＤＮＳの名前を解決する際のフロー例図
【図６】この発明にかかる中継装置がＬＡＮ側からＷＡＮ側へのパケットを処理する際のフロー例図
【図７】図６の延長
【図８】この発明にかかる中継装置がＷＡＮ側からＬＡＮ側へのパケットを処理する際のフロー例図
【発明を実施するための形態】
【００１９】
以下、この発明にかかる中継装置の実施形態について詳細に説明する。まず、この発明にかかる中継装置による効果が好適に得られる状況を、図１を用いて例示する。
【００２０】
インターネット１上には、同一のドメイン（例として、「www.example.co.jp」とする。）を有する冗長化サーバ群１１があり、それぞれのサーバ１１ａ，１１ｂ……等はいずれも異なるＩＰｖ４のグローバルＩＰアドレスを有している（仮に、「２０．２０．２０．２０」と「３０．３０．３０．３０」とする。）。また、インターネット１と、ＩＰｖ６で構成された閉域網２との間には、上位中継装置１２が設けてある。上位中継装置１２は、一つのＩＰｖ４のグローバルＩＰアドレスを有している（仮に、「４０．４０．４０．４０」とする。閉域網２に接続するホームゲートウェイなどの下位の中継装置１３は、いずれもインターネット１に対しては、その一つのＩＰｖ４グローバルＩＰアドレス（４０．４０．４０．４０）を共有する。個々の中継装置１３が抱えるローカルエリアネットワーク３に接続される個々の端末１４も同様に、そのＩＰｖ４グローバルＩＰアドレスを共有する。
【００２１】
上位中継装置１２とは、ＮＡＴ（ＮＡＰＴ）機能を有する上位の中継装置であり、閉域網２からインターネット１への通信を全て中継するゲートウェイである。従って、ここには中継装置１３の全て、ひいてはそれに繋がる端末１４からインターネットへ繋がる通信の全てが集中する。
【００２２】
中継装置１３とは、例えばルータとして機能するホームゲートウェイなどの、ローカルエリアネットワーク３を抱えるゲートウェイ装置であり、この発明にかかる中継装置として後述する必要な機能を有する。
【００２３】
中継装置１３の機能ブロック図を図２に示す。端末１４に通じるＬＡＮ側にはＬＡＮ側送受信機能部２１があり、上位中継装置１２に通じるＷＡＮ側にはＷＡＮ側送受信機能部２２がある。これら送受信機能部は、具体的には、物理的なネットワークインターフェースとそれを制御するためのドライバ等のソフトからなり、パケットの送受信を行う。
【００２４】
また、中継装置１３は、端末１４側からのＤＮＳの名前の解決要求に対して、ＤＮＳリゾルバとして機能するＤＮＳ−ｐｒｏｘｙ機能部３１を有する。ＤＮＳ−ｐｒｏｘｙ機能部３１は、インターネット１上にあるＤＮＳサーバ（図示せず）に対してドメイン名の解決を行う。中継装置１３は、その解決されたドメイン名とＩＰアドレスとを記録するＤＮＳキャッシュ３２を有する。
【００２５】
このＤＮＳキャッシュ３２の例を図３に示す。ＦＱＤＮはＩＰアドレスに対応するドメイン名を指す。ＩＰアドレスは、ＷＡＮ側に存在するサーバのＩＰアドレスである。更新時間は、当該エントリ情報が更新された時刻である。一のドメイン名に対してＤＮＳサーバが返したＩＰアドレスが複数ある場合には、そのうちの一つだけを記録するのではなく、少なくとも二つ記録しておく。同一ドメイン名のレコード数は特に上限はなく、返されてきたＩＰアドレスの全てを記録しておいてもよい。ただし、ＤＮＳキャッシュ３２の検索負荷が許容できる範囲であると好ましい。
【００２６】
さらに、中継装置１３は、閉域網２とローカルエリアネットワーク３との間でやりとりされるパケットについてアドレス及びポート番号の変換を行うＮＡＰＴ機能部３５を有し、ＮＡＰＴ機能部３５がＬＡＮ側からＷＡＮ側へのパケット変換の際に記録し、ＷＡＮ側からＬＡＮ側へのパケット変換の際に参照するセッション管理テーブル３６を有する。
【００２７】
このセッション管理テーブル３６の例を図４に示す。LAN側の送信元アドレスは端末１４のローカルIPアドレスであり、宛先アドレスは冗長化サーバ群１１のドメイン名を問い合わせて得られた冗長化サーバ１１ａ（２０．２０．２０．２０）のＩＰアドレスである。ただし、設定された限界ポート番号数（ここでは１００）を越えるセッションについては、ＤＮＳキャッシュ３２に記録された第二のアドレスである冗長化サーバ１１ｂ（３０．３０．３０．３０）のＩＰアドレスとなっている。
【００２８】
そしてさらに中継装置１３は、ＬＡＮ側からの新たなセッション構築を求めるパケットが、冗長化サーバ群１１のうちの一の冗長化サーバ１１ａ（例えば「２０．２０．２０．２０」）のＩＰアドレスを宛先として指定するものであるか否かを判定し、なおかつそれが所定の条件に合致する場合、その宛先ＩＰアドレスを、上記ＤＮＳキャッシュに保持された当該冗長化サーバ群の他の冗長化サーバ１１ｂのＩＰアドレス（例えば「３０．３０．３０．３０」）に変更した上でＮＡＰＴ機能部３５にパケットを渡す宛先ＩＰ判定機能部３８を有する。ただし、この宛先ＩＰ判定機能部３８は、LAN側からWAN側へのパケットを受信した際には、常に判定を実行するとよいが、その結果としてIPアドレスの変更を行うか否かの条件は状況に応じて適宜変更してよい。
【００２９】
その、アドレスを変更する場合の条件について、図１の例の状況とともに説明する。
この中継装置１３の閉域網２側のアドレスは、上位中継装置１２又はそれの付属サーバによって割り当てられたＩＰｖ６のＩＰアドレスである。中継装置１３で区切られたローカルエリアネットワーク３では、中継装置１３によって個々の端末にＩＰｖ４でのローカルＩＰアドレスが割り当てられてネットワークを構築している。仮にここでは、中継装置１３がＮｏ．１からＮｏ．６５５までの６５５台接続されている状況を例にとる。
【００３０】
上位中継装置１２が冗長化サーバ群１１に対してアクセスする際に、送信元ポート番号として使用可能なポート番号は最大で６５５３５であり、ここではそれぞれの中継装置１３（Ｎｏ．１〜Ｎｏ．６５５）が、固定値で１００ずつの番号を割り当てられているものとする。なお、実際にはこの数は接続される中継装置１３の数によって変化するし、中継装置１３ごとに優先順位が設けられて割り当てられるポート番号数が変動してもよい。仮に１００ずつの固定値だとすると、一つの中継装置１３から、インターネット１上の単独サーバ（図示せず）に対して構築することのできるセッションの数は、上位中継装置１２において割り当てられた数である１００が限界数となる。しかし、冗長化サーバ群１１に対しては、個々の冗長化サーバ１１ａ，１１ｂ……に対して１００ずつセッションを構築できるので、（冗長化サーバ１１ａ等の数×１００）だけセッションを構築することができる。
【００３１】
ところで、基本的には端末１４が有するブラウザなどのアプリケーションがドメイン名の解決を要求する際には、一つのドメイン名に対して一つのＩＰアドレスを受け取ってセッションを構築する。従って、端末１４からの要求に対してＤＮＳリゾルバとして動作するＤＮＳ−ｐｒｏｘｙ機能部３１は、端末１４から問い合わせられた一のドメイン名についてＤＮＳサーバより複数のＩＰアドレスを受け取ってＤＮＳキャッシュ３２に記録した場合でも、端末１４に対して返答するＩＰアドレスはそのうちの一つでよい。このため、端末１４のアプリケーションはその一つのＩＰアドレス（仮に20.20.20.20）に対してセッションの構築を試みて、中継装置１３にパケットを送る。これを受けた中継装置１３では、冗長化サーバ群１１宛のセッションとして、まずその第一のＩＰアドレスに対応する冗長化サーバ１１ａ宛のセッションが構築されていき、割り当てられたポート番号数の枠を使っていくことになる。
【００３２】
第一の実施形態としては、宛先ＩＰ判定機能部３８は、ＬＡＮ側からの新たなセッション構築を求めるパケットを受け取った際に、一の冗長化サーバ１１ａについてのセッション数、すなわちセッション管理テーブル３６に記録される冗長化サーバ１１ａを宛先とするレコードの数が、その中継装置１３に割り当てられた限界数に達しているか否かをまず判定する。限界に達していたら、当該ＩＰアドレスでＤＮＳキャッシュ３２を検索し、同一ドメイン名で異なるＩＰアドレスがあるか否かを調べる。この異なるＩＰアドレスとはすなわち、優先順位が下位で、端末１４には返答されなかったアドレスである。それがあれば、冗長化サーバ１１ａ宛のパケットを、ＤＮＳキャッシュ３２に記録された同一ドメイン名に対応する別のアドレスである冗長化サーバ１１ｂ宛のパケットに変更してＷＡＮ側へ送出する。すなわち、一つの冗長化サーバ１１ａ宛のセッションの割り当て数を使い切ったら、次の冗長化サーバ１１ｂ宛のセッションを順に構築していくという実施形態である。また、３以上の冗長化サーバ１１ａ，１１ｂ，１１ｃ……からなる冗長化サーバ群１１である場合には、上記と同様に、冗長化サーバ１１ｂ宛のセッションの割り当て数を使い切ったら、次の冗長化サーバ１１ｃ，１１ｄ……宛のセッションを順に構築していく。セッション管理テーブル３６には、図４の例に示すように、宛先ＩＰ判定機能部３８によって変更されたアドレスにてセッションが登録され、変更された宛先である冗長化サーバ１１ｂからのパケットをＮＡＰＴ機能部３５が通常と同じように処理する。
【００３３】
第二の実施形態としては、宛先ＩＰ判定機能部３８は、ＬＡＮ側からＷＡＮ側への新たなセッション構築を求めるパケットを受信した場合、そのパケットがＤＮＳキャッシュ３２に一つのドメイン名を共有する複数のＩＰアドレスとして登録されたものの一つであるか否かを検索する。それに合致する、すなわちそれが冗長化サーバ１１ａ宛のパケットであるならば、セッション管理テーブル３６に記録された、一の冗長化サーバ１１ａ宛のセッション数と、他の冗長化サーバ１１ｂ、１１ｃ……宛のセッション数を比較し、他よりもセッション数が特に多くなっている冗長化サーバ宛である場合には、セッション数がより少ない他の冗長化サーバ宛のパケットに変更する。すなわち、セッション数のリソースを分散させて、それぞれの冗長化サーバへ分散してアクセスを行うように計らうという実施形態である。冗長化サーバ群１１の負荷分散という点ではこの実施形態の方が好ましい。他よりもセッション数が特に多くなっているか否かの判断としては、セッション数の差が閾値（例えば３，５、１０程度）以上である場合が挙げられる。なお、この第二の実施形態の場合も、それぞれの冗長化サーバ１１ｘ宛のセッション数が上記の限界数に到達していないかチェックしておくと好ましく、限界数に達した冗長化サーバ１１ｘ宛のパケットであれば、無条件に他の冗長化サーバ１１ｘ宛のパケットに差し替えるとよい。また、全ての冗長化サーバ１１ｘについて限界数に達していたら、そのパケットは破棄するしかない。
【００３４】
さらに、第二の実施形態の応用形態として、ＤＮＳキャッシュ３２に１のドメイン名に対応するものとして複数のＩＰアドレスが並記されたうちの一つに該当する宛先のパケットであるならば、セッション管理テーブル３６におけるセッション数の差に拘わらず、ランダムで他の冗長化サーバ１１ｘにアドレスを変更するものであってもよい。
【００３５】
これらのいずれの実施形態にしても、中継装置１３が同一のサーバに対して構築することが出来るセッション数は上位中継装置１２によって決定されることになる。従って、このような上位中継装置１２と中継装置１３とからなる閉域網２を運用するにあたっては、中継装置１３が上記のいずれの実施形態であるにせよ、限られたポート番号数の範囲のリソースを有効活用できるように、その限界数を最適に調整して各々の中継装置１３に伝達するとよい。
【００３６】
次に、この発明にかかる中継装置１３の具体的な動作形態例を、図５以下のフロー図を用いて説明する。ただし、具体的な実装形態はこのフローに限られるものではなく、上記のように冗長化サーバ群１１の範囲でアドレスの変更を行いうるものであればよい。
【００３７】
まず、ＤＮＳ−ｐｒｏｘｙ機能部３１によるキャッシュ更新動作について図５を用いて説明する。まず（Ｓ１０１）、端末１４が新たにサーバ（冗長化サーバ群１１を含む）にアクセスするにあたり発信したDNSの名前解決の要求メッセージを、ＬＡＮ側送受信機能部２１を介して受信する（Ｓ１０２）。ＤＮＳ−ｐｒｏｘｙ機能部３１は、ＷＡＮ側送受信機能部２２へ、予め設定されたＤＮＳサーバ宛に、ＤＮＳの名前の解決を要求するメッセージを送信する（Ｓ１０３）。ＷＡＮ側からＤＮＳの応答メッセージを受信したら（Ｓ１０４）、その応答メッセージを解析して、ＦＱＤＮと対応するＩＰアドレスを取得する（Ｓ１０５）。
【００３８】
その上で、応答メッセージから取得したそれぞれのＦＱＤＮとＩＰアドレスとの組み合わせについて、ＤＮＳキャッシュ３２の更新処理を行う（Ｓ１１１〜Ｓ１１８）。その中身は、まず、ＤＮＳキャッシュ３２から、ＦＱＤＮが応答メッセージから取得したＦＱＤＮに一致し、かつＩＰアドレスが応答メッセージから取得したＩＰアドレスに一致するエントリを検索する（Ｓ１１２）。条件に合致するエントリが既にあるのならば（Ｓ１１３→Ｙｅｓ）、当該エントリの更新時刻に現在時刻を設定してデータを更新する（Ｓ１１７）。すなわち、すでに直近のタイミングで問い合わせがあったアドレスへの問い合わせであったため、日時を更新するだけとなる。条件に合致するエントリがＤＮＳキャッシュ３２に存在しなければ（Ｓ１１３→Ｎｏ）、そのエントリを登録することになる。ただし、その際に、ＤＮＳキャッシュ３２のエントリ数が上限未満か否かを判断する（Ｓ１１４）。上限に到達してなければそのまま進むが（Ｓ１１４→Ｙｅｓ）、上限に到達していれば（Ｓ１１４→Ｎｏ）、予め更新時刻が最も古いエントリを削除する（Ｓ１１５）。その上で、ＤＮＳキャッシュ３２に、新規エントリを追加し、応答メッセージから取得したＦＱＤＮとＩＰアドレスの値を設定する（Ｓ１１６）。その上で、設定したエントリの更新時刻に現在の時刻を設定する（Ｓ１１７）。以上の処理を、応答メッセージから取得した全てのＦＱＤＮとＩＰアドレスの組について実施する（Ｓ１１８→Ｓ１１１）。すなわち、問い合わせたＦＱＤＮについて複数のＩＰアドレスが返ってきたら、その個数だけ上記の工程を繰り返す。キャッシュの更新が終わったら、端末１４へＤＮＳの応答メッセージを送信する（Ｓ１１９）。受け取った端末１４は、そのメッセージを受けとってＤＮＳの名前を解決し、新たなセッションを構築しようとすることになる（Ｓ１２０）。このとき、端末１４は、複数のＩＰアドレスを受け取った場合、その中で先頭のＩＰアドレスのみを用いてセッション構築を試みるのが一般的なパソコンなどにおける動作である。
【００３９】
次に、ＤＮＳの名前を解決した端末１４からインターネット１へ向けてパケットが送出される際の中継工程を図６及び図７のフローを用いて説明する。まず（Ｓ２０１）、ＬＡＮ側送受信機能部２１にて、パケットを受信する（Ｓ２０２）。宛先ＩＰ判定機能部３８は、セッション管理テーブル３６を検索して、そのパケットのプロトコル、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号と、エントリのプロトコル、ＬＡＮ側送信元アドレス、ＬＡＮ側宛先アドレス、ＬＡＮ側送信元ポート番号、ＬＡＮ側宛先ポート番号とのそれぞれに一致するエントリがあるか否かを検索する（Ｓ２０４）。条件に合致するエントリが存在すれば（Ｓ２０５→Ｙｅｓ）、そのエントリに従って中継すればよいので、そのままＮＡＰＴ機能部３５に渡して、パケットのヘッダ情報を次のように変更する（Ｓ２０６）。すなわち、パケットの宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ポート番号、送信元ポート番号を、それぞれ、当該エントリのＷＡＮ側送信元アドレス、ＷＡＮ側宛先アドレス、ＷＡＮ側送信元ポート番号、ＷＡＮ側宛先ポート番号に変更する。このＮＡＰＴ変換したパケットを、ＷＡＮ側送受信機能部２２から送信する（Ｓ２０７）。すなわち、既にセッションが確立している通信では、特にこの発明にかかるＩＰアドレスの変換を行う必要はない。通常通りの中継装置としてパケットを中継して終わる（Ｓ２０９）。
【００４０】
一方、受け取ったパケットに合致するエントリが無い（Ｓ２０５→Ｎｏ）、すなわち、新たなセッションを構築しようとするものである場合、本発明として必要な処理へと移る。宛先ＩＰ判定機能部３８は、セッション管理テーブル３６を検索して、次のようなエントリの数を調べる（Ｓ２１１）。すなわち、パケットのプロトコル、宛先ＩＰアドレス、宛先ポート番号が、それぞれ、エントリのプロトコル、ＷＡＮ側送信元アドレス、ＷＡＮ側送信元ポート番号に一致し、かつ、そのエントリのＷＡＮ側宛先アドレスが、中継装置１３自体のＷＡＮ側アドレスに一致するエントリがあるか、あるのならば幾つあるかということである。これはつまり、当該エントリのＷＡＮ側情報のうち、宛先ポート番号だけが、そのパケットの送信元ポート番号と一致していない、セッションがあるか否かということであり、同一サーバへの別セッションが既に存在しているか否かということでもある。そのヒットしたエントリ数が、上位中継装置１２に依存する上限値に到達していれば（Ｓ２１２→Ｎｏ）、後述するＳ２３１以下のフローへ移る（Ｓ２１３，図７）。なお、この上限値は上記の上位中継装置１２から割り当て数として通知される値である。
【００４１】
一方、ヒットしたエントリ数が上限に達していなければ（Ｓ２１２→Ｙｅｓ）、条件に合致する各エントリにおいてＷＡＮ側宛先ポート番号として使用されていないポート番号を任意に選択する。なお、合致するエントリが０である場合は、当然に０〜６５５３５までの範囲で任意にポート番号を選択できる（Ｓ２１４）。その選択の上で、セッション管理テーブル３６に新たなエントリを追加する（Ｓ２１６）。その内容は次の通りである。エントリのプロトコルにはパケットのプロトコルを設定する。エントリのＬＡＮ側の送信元アドレス、宛先アドレス、送信元ポート番号、宛先ポート番号に、それぞれパケットの送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号を設定する。エントリのＷＡＮ側の送信元アドレス、宛先アドレス、送信元ポート番号、宛先ポート番号に、それぞれ、パケットのＩＰアドレス、中継装置１３のＷＡＮ側アドレス、パケットの宛先ポート番号、上記の選択したポート番号、を設定する（Ｓ２１６）。
【００４２】
なお、ここでは図４に記載の例の通り、ＷＡＮ側の情報は、中継装置１３がＷＡＮ側で受信する時点における送信、受信、という概念でテーブル内の項目を定義した例を示しているが、実装上はここの送受信の項目が逆であってもよい。ただし、セッション管理テーブル３６を参照するのは後述するＷＡＮ側からの受信の際であるので、ＷＡＮ側基準でエントリを登録しておく方が、処理がわかりやすくなる。
【００４３】
その上で（Ｓ２１７→Ｓ２０３）、その時点で中継装置１３が扱っている当該パケットについては、当然にＬＡＮ側の情報とパケットの情報が一致するエントリを生成したばかりなので、セッション管理テーブル３６に条件合致するエントリが存在することになり（Ｓ２０４→Ｓ２０５→Ｙｅｓ）、直前に登録したエントリの情報に従って、ＮＡＰＴ機能部３５がパケットのヘッダ情報を変更して（Ｓ２０６）、ＷＡＮ側送受信機能部２２から送信する（Ｓ２０７→Ｓ２０９）。ここまでの処理のうち、上限値に到達しているかのチェックが入る以外は通常の中継処理と基本的には変わらない。
【００４４】
次に、Ｓ２１１において、条件に合致するエントリ数が上限値に到達している場合（Ｓ２１２→Ｎｏ→Ｓ２１３）、すなわち、宛先であるサーバについて、上位中継装置１２から割り当てられるポート番号の枠を使い切っている場合について説明する。フローは主に図７へ移る（Ｓ２３１）。
【００４５】
処理前にエラーチェックを行う。ＤＮＳキャッシュ３２から、当該パケットの宛先ＩＰアドレスと、エントリのＬＡＮ側宛先ＩＰアドレスに一致するエントリがあるか否かを居検索する（Ｓ２３２）。もしエントリが存在しなければ、セッション管理テーブル３６に記録があるにも拘わらずＤＮＳキャッシュ３２にエントリが無いという不自然な状態であり、なおかつ、本発明にかかるＩＰアドレスの変更もできないので送信のしようもないので、当該パケットについては破棄して（Ｓ２３４）、フローを終了する（Ｓ２３５→Ｓ２０８→Ｓ２０９、終了）。エントリがＤＮＳキャッシュ３２に存在するのであれば、当該エントリのＦＱＤＮの値を、内部変数「宛先ドメイン名」に代入する（Ｓ２４１）。その上で、ＤＮＳキャッシュに記載のある範囲で変更の検討を行う（Ｓ２４２〜）。まず、ｉ＝１として（Ｓ２４２）、ＤＮＳキャッシュ３２のｉ番目（ここでは１番目）のエントリのＦＱＤＮが「宛先ドメイン名」と一致しているか否かを調べる（Ｓ２４３）。一致していなければ（Ｓ２４３→Ｎｏ）、ＤＮＳキャッシュのエントリが残る限り（Ｓ２４８→Ｙｅｓ）、ｉ＋１して次の番目のエントリについて（Ｓ２４９）、同様にチェックする（Ｓ２４３）。一致していれば、セッション管理テーブル３６から、次の条件に合致するエントリがあるか否かを検索する（Ｓ２４４）。すなわち、エントリのプロトコルがパケットのプロトコルと一致し、ＷＡＮ側送信元アドレスが、取り扱い中のＤＮＳキャッシュのｉ番目のエントリのＩＰアドレスに一致し、ＷＡＮ側宛先アドレスが中継装置１３のＷＡＮ側アドレスに一致し、ＷＡＮ側送信元ポート番号が、パケットの宛先ポート番号に一致するエントリの数をカウントする。
【００４６】
このエントリが存在するものの（Ｓ２４５→Ｙｅｓ）、そのエントリ数が上記の上限値に到達していたら（Ｓ２４６→Ｎｏ）、そのｉ番目のエントリのＩＰアドレスは、既に上位中継装置１２から割り当てられたポート番号の枠を使い切っているので、次のｉ＋１番目のチェックに移る（Ｓ２４９〜）。これに該当するのは、元々上限値に到達しているパケットのＩＰアドレスである場合の他に、この発明によって別のＩＰアドレスへの振り分けとなる変更を行った別のＩＰアドレスについてもポート番号枠を使い切ってしまった場合も該当する。
【００４７】
一方、合致するエントリ数が０である場合には（Ｓ２４５→Ｎｏ）、そのｉ番目のエントリのＩＰアドレスは、ポート番号枠から溢れた分の振り分け先として、ポート番号がまだ使われておらず、十分な空き枠があるということであり、そのＩＰアドレスを宛先とすることができる。また、合致するエントリが存在し（Ｓ２４５→Ｙｅｓ）、そのエントリ数が上記の上限値に達していないのであれば（Ｓ２４６→Ｙｅｓ）、そのｉ番目のエントリのＩＰアドレスは、振り分け先として一部のポート番号が使われているものの、上位中継装置１２から割り当てられた枠をまだ使い切っていないので、そのＩＰアドレスを宛先とすることができる。この、振り分け先となるＩＰアドレスは、変数「宛先ドメイン名」を元のパケットの宛先ＩＰアドレスと共有するものであり、すなわち、同一のコンテンツを提供できるサーバということである。
【００４８】
そこで、そのｉ番目のエントリのＩＰアドレスが振り分け先として利用できるものであるとわかった場合（Ｓ２４７→Ｓ２１５）、宛先ＩＰ判定機能部３８は、使えるポート番号を任意に選択した上で（Ｓ２１４）、セッション管理テーブル３６に当該パケットのエントリを追加する。その内容は上記のＳ２１６と基本的には同一であるが、ＷＡＮ側送信元アドレスだけは、当該ｉ番目のエントリのＩＰアドレスとなる。すなわち、図４の下段に記載されているエントリのように、ＬＡＮ側宛先アドレスと、ＷＡＮ側の送信元アドレスとが一致しないエントリが生成される（Ｓ２１６）。その上で（Ｓ２１７→Ｓ２０３→Ｓ２０４→Ｓ２０５→Ｙｅｓ）、当該エントリに則ってＮＡＰＴ変換が行われ（Ｓ２０６）、当該パケットは端末１４が指定した冗長化サーバではなく、そのサーバとドメイン名を同じくする別の冗長化サーバへ送信される（Ｓ２０７）。
【００４９】
なお、最終的に、最後のエントリまで検索しても変更可能なエントリが見つからなければ（Ｓ２４８→Ｎｏ）、そのパケットは送信しても上位中継装置１２で中継できないので、その場で破棄して（Ｓ２５１）、当該パケットの処理を終了する（Ｓ２５２→Ｓ２０８→Ｓ２０９）。
【００５０】
次に、ＷＡＮ側からパケットが返送されてきた際の処理について、図８のフローを用いて説明する。まず（Ｓ３０１）、ＷＡＮ側送受信機能部２２にてパケットを受信したら（Ｓ３０２）、ＮＡＰＴ機能部３５が、セッション管理テーブル３６から、ＷＡＮ側の情報が、受け取ったパケットと一致するエントリがあるか否かを検索する（Ｓ３０３）。存在していなければ（Ｓ３０４→Ｎｏ）、不明なパケットとして破棄する（Ｓ３０５→Ｓ３０８）。存在していれば、ＮＡＰＴ機能部３５は、そのパケットの宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ポート番号、送信元ポート番号を、当該エントリのＬＡＮ側送信元アドレス、ＬＡＮ側宛先アドレス、ＬＡＮ側送信元ポート番号、ＬＡＮ側宛先ポート番号に変換する。すなわち、上記の宛先ＩＰ判定機能部３８によって、宛先となるサーバのアドレスを変更したエントリに従って送出されたパケットの返答パケットは、ここで、セッション管理テーブル３６に登録されている元の宛先ＩＰアドレスからの返答パケットであるようにヘッダを書き換えられた上で、ＬＡＮ側に送信される（Ｓ３０７→Ｓ３０８）。宛先ＩＰ判定機能部３８によって宛先を変えられていないパケットは、元の宛先であるサーバからのパケットであるので、実際には送信元ＩＰアドレスを変更されることなく、ＬＡＮ側へ送信される。このため、端末１４では中継装置１３が果たした宛先サーバの変更の有無について一切考慮することなく、当初指定して期待した通りのコンテンツを得ることができる。
【００５１】
この発明を実施する環境では、上位中継装置１２では、一の中継装置１３から同一のＩＰアドレス宛で、宛先ポート番号が同じながら送信元ポート番号が異なるパケットが来たら、その中継装置１３に割り当てたポート番号の数だけ受け付けた上でＮＡＰＴ変換し、既に上限値に達しているのであれば、接続不可としてパケットを破棄することになる。ただし、この発明にかかる中継装置１３によって上位中継装置１２へ送るパケットの宛先ＩＰアドレスを変更することによって、そのようなパケット破棄に至る件数を大幅に減らすことができる。
【００５２】
なお、判断する処理の概念上、宛先ＩＰ判定機能部３８とＮＡＰＴ機能部３５とを分けて記載したが、この発明を実装するにあたっては、これらの機能部は一体化してフローを処理するものであってもよい。
【００５３】
また、上記では説明の例として、閉域網２を介して上位中継装置１２が存在する場合を説明したが、上位中継装置１２を介することなく中継装置１３自体がインターネット１に直接接続されていて、配下に多数の端末１４を有する場合でも、この発明は利用可能である。多数の端末１４から、６５５３６のポートを使い切るほどのセッションが一の冗長化サーバ１１ａに対して張られた場合、同様に、まだセッションを張っていない、同一ドメイン名である冗長化サーバ１１ｂへのパケットとすることで、中継装置１３は冗長化サーバ群１１に対して安定的な接続が可能となる。
【符号の説明】
【００５４】
１  インターネット
２  閉域網
３  ローカルエリアネットワーク
１１  冗長化サーバ群
１１ａ，１１ｂ，１１ｃ，１１ｘ  冗長化サーバ
１２  上位中継装置
１３  中継装置
１４  端末
２１  ＬＡＮ側送受信機能部
２２  ＷＡＮ側送受信機能部
３１  ＤＮＳ−ｐｒｏｘｙ機能部
３２  ＤＮＳキャッシュ
３５  ＮＡＰＴ機能部
３６  セッション管理テーブル
３８  宛先ＩＰ判定機能部
【図１】
2014045245.tif 000003
【図２】
2014045245.tif 000004
【図３】
2014045245.tif 000005
【図４】
2014045245.tif 000006
【図５】
2014045245.tif 000007
【図６】
2014045245.tif 000008
【図７】
2014045245.tif 000009
【図８】
2014045245.tif 000010