(57)【特許請求の範囲】
【請求項１】
インターフェースユニットであって、
クライアントからの要求を受信すると、該インターフェースユニットに対応するネットワークアドレスを用いて、該クライアントと該インターフェースユニットとの間の接続を開にする手段と、
該インターフェースユニットとサーバとの間で開である空いている接続がない場合に、該インターフェースユニットと該サーバとの間の接続を開にする手段であって、該サーバは、該ネットワークアドレスの関数として選択される、手段と、
該サーバに対応するパス名を用いてデータを検索する要求を受信する手段であって、該インターフェースユニットと該クライアントとの間の該接続の承認番号とシーケンス番号とを有するＧＥＴセグメントを受信する手段を含む手段と、
該クライアントが該接続を介して該サーバ上のデータに透過的にアクセスすることを可能にする手段であって、該データは、該パス名を用いて該サーバから検索され、該可能にする手段は、該インターフェースユニットと該クライアントとの間の該接続の承認番号とシーケンス番号とを該インターフェースユニットと該サーバとの間の該接続の承認番号とシーケンス番号とに変換し、該インターフェースユニットと該サーバとの間の該接続の承認番号とシーケンス番号とを該インターフェースユニットと該クライアントとの間の該接続の承認番号とシーケンス番号とに変換することにより、変換されたＧＥＴセグメントを生成し、「Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ」ヘッダを該変換されたＧＥＴセグメントに挿入する手段を含む、手段と、
該変換されたＧＥＴセグメントを該サーバに送信する手段と、
該データを該クライアントに送信する手段と、
該「Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ」ヘッダを該変換されたＧＥＴセグメントに挿入することによって加えられたバイト数を該サーバから受信した該承認番号と該シーケンス番号とから差し引き、該クライアントが該データに透過的にアクセスすることを可能にする手段と、
該変換されたＧＥＴセグメントに続くパケットを該サーバに送信する前に、該「Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ」ヘッダを該変換されたＧＥＴセグメントに挿入することによって加えられたバイト数を該承認番号と該シーケンス番号とに加え、該クライアントが該データに透過的にアクセスすることを継続的に可能にする手段と、
該インターフェースユニットと該サーバとの間の該接続を開に維持する一方で、該クライアントと該インターフェースユニットとの間の該接続を閉にする手段であって、別のクライアントは、該別のクライアントによる該サーバ上のデータへのアクセスの要求に応答して、該インターフェースユニットと該サーバとの間の該接続を再使用することが可能である、手段と
を備える、インターフェースユニット。
【請求項２】
更なるクライアントと前記インターフェースユニットとの間の接続を開にする手段と、
該更なるクライアントが、該更なるクライアントと該インターフェースユニットとの間の該接続、および、該インターフェースユニットと前記サーバとの間の前記接続を介して、該サーバ上の情報にアクセスすることを可能にする手段と
をさらに備える、請求項１に記載のインターフェースユニット。
【請求項３】
前記可能にする手段は、
更なるシーケンス番号と更なる承認番号とを有するＲＥＳＰセグメントを受信する手段と、
該更なる番号を変換することにより、変換されたＲＥＳＰセグメントを生成する手段と、
該変換されたＲＥＳＰセグメントを該クライアントに送信する手段と
をさらに備える、請求項１に記載のインターフェースユニット。
【請求項４】
前記可能にする手段は、
更なるシーケンス番号と更なる承認番号とを有する第１のＲＥＳＰセグメントを受信する手段と、
該更なる番号を変換することにより、更なる変換された番号を生成する手段と、
第２のＲＥＳＰセグメントを前記クライアントに送信する手段であって、該第２のＲＥＳＰセグメントは、該更なる変換された番号を有する、手段と
をさらに備える、請求項１に記載のインターフェースユニット。
【請求項５】
インターフェースユニットによって実行される方法であって、
クライアントからの要求を受信すると、該インターフェースユニットに対応するネットワークアドレスを用いて、該クライアントと該インターフェースユニットとの間の接続を開にするステップと、
該インターフェースユニットとサーバとの間で開である空いている接続がない場合に、該インターフェースユニットと該サーバとの間の接続を開にするステップであって、該サーバは、該ネットワークアドレスの関数として選択される、ステップと、
該サーバに対応するパス名を用いてデータを検索する要求を受信するステップであって、該インターフェースユニットと該クライアントとの間の該接続の承認番号とシーケンス番号とを有するＧＥＴセグメントを受信するステップを含むステップと、
該クライアントが該接続を介して該サーバ上のデータに透過的にアクセスすることを可能にするステップであって、該データは、該パス名を用いて該サーバから検索され、該可能にするステップは、該インターフェースユニットと該クライアントとの間の該接続の承認番号とシーケンス番号とを該インターフェースユニットと該サーバとの間の該接続の承認番号とシーケンス番号とに変換し、該インターフェースユニットと該サーバとの間の該接続の承認番号とシーケンス番号とを該インターフェースユニットと該クライアントとの間の該接続の承認番号とシーケンス番号とに変換することにより、変換されたＧＥＴセグメントを生成するステップと、「Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ」ヘッダを該変換されたＧＥＴセグメントに挿入するステップとを含む、ステップと、
該変換されたＧＥＴセグメントを該サーバに送信するステップと、
該データを該クライアントに送信するステップと、
該「Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ」ヘッダを該変換されたＧＥＴセグメントに挿入することによって加えられたバイト数を該サーバから受信した該承認番号と該シーケンス番号とから差し引き、該クライアントが該データに透過的にアクセスすることを可能にするステップと、
該変換されたＧＥＴセグメントに続くパケットを該サーバに送信する前に、該「Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ」ヘッダを該変換されたＧＥＴセグメントに挿入することによって加えられたバイト数を該承認番号と該シーケンス番号とに加え、該クライアントが該データに透過的にアクセスすることを継続的に可能にするステップと、
該インターフェースユニットと該サーバとの間の該接続を開に維持する一方で、該クライアントと該インターフェースユニットとの間の該接続を閉にするステップと、
別のクライアントが該サーバ上のデータにアクセスを試みることに応答して、該インターフェースユニットと該サーバとの間の該接続を再使用するステップと
を包含する、方法。
【請求項６】
更なるクライアントと前記インターフェースユニットとの間の接続を開にするステップと、
該更なるクライアントが、該更なるクライアントと該インターフェースユニットとの間の該接続、および、該インターフェースユニットと前記サーバとの間の前記接続とを介して、該サーバ上の情報にアクセスすることを可能にするステップと
をさらに包含する、請求項５に記載の方法。
【請求項７】
前記可能にするステップは、
更なるシーケンス番号と更なる承認番号とを有するＲＥＳＰセグメントを受信するステップと、
該更なる番号を変換することにより、変換されたＲＥＳＰセグメントを生成するステップと、
該変換されたＲＥＳＰセグメントを該クライアントに送信するステップと
をさらに包含する、請求項５に記載の方法。
【請求項８】
前記可能にするステップは、
更なる番号と更なる承認番号とを有する第１のＲＥＳＰセグメントを受信するステップと、
該更なる番号を変換することにより、更なる変換された番号を生成するステップと、
第２のＲＥＳＰセグメントを前記クライアントに送信するステップであって、該第２のＲＥＳＰセグメントは、該更なる変換された番号を有する、ステップと
をさらに包含する、請求項５に記載の方法。
【請求項９】
インターフェースユニットであって、
第１のクライアントがＴＣＰ／ＩＰパケットを介してサーバからのデータを要求することに応答して、該第１のクライアントとインターフェースユニットとの間の接続を開にする手段であって、該ＴＣＰ／ＩＰパケットは、ＩＰヘッダとＴＣＰヘッダとを有するＧＥＴセグメントであり、該ＩＰヘッダは、ソースアドレスと行き先アドレスとを含み、該ＴＣＰヘッダは、シーケンス番号と承認番号とを含み、該インターフェースユニットは、該第１のクライアントと該サーバとの間に位置している、手段と、
該インターフェースユニットと該サーバとの間で開である空いている接続がない場合に、該インターフェースユニットと該サーバとの間の接続を開にする手段と、
該第１のクライアントが該接続を介して該サーバ上のデータに透過的にアクセスすることを可能にする手段であって、該サーバ上のデータに透過的にアクセスすることは、該インターフェースユニットと該第１のクライアントとの間の該接続の承認番号とシーケンス番号とを該インターフェースユニットと該サーバとの間の該接続の承認番号とシーケンス番号とに変換し、該インターフェースユニットと該サーバとの間の該接続の承認番号とシーケンス番号とを該インターフェースユニットと該第１のクライアントとの間の該接続の承認番号とシーケンス番号とに変換することにより、変換されたＧＥＴセグメントを生成することを含み、該変換されたＧＥＴセグメントは、「Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ」ヘッダを含む、手段と、
該インターフェースユニットと該サーバとの間の該接続を開に維持する一方で、該第１のクライアントと該インターフェースユニットとの間の該接続を閉にする手段であって、第２のクライアントは、該インターフェースユニットとの接続が確立したことに応答して、該インターフェースユニットと該サーバとの間の該接続を再使用することが可能である、手段と
を備える、インターフェースユニット。
【請求項１０】
インターフェースユニットによって実行される方法であって、
第１のクライアントがＴＣＰ／ＩＰパケットを介してサーバからのデータを要求することに応答して、該第１のクライアントと該インターフェースユニットとの間の接続を開にするステップであって、該ＴＣＰ／ＩＰパケットは、ＩＰヘッダとＴＣＰヘッダとを有するＧＥＴセグメントであり、該ＩＰヘッダは、ソースアドレスと行き先アドレスとを含み、該ＴＣＰヘッダは、シーケンス番号と承認番号とを含み、該インターフェースユニットは、該第１のクライアントと該サーバとの間に位置している、ステップと、
該インターフェースユニットと該サーバとの間で開である空いている接続がない場合に、該インターフェースユニットと該サーバとの間の接続を開にするステップと、
該第１のクライアントが該接続を介して該サーバ上のデータに透過的にアクセスすることを可能にするステップであって、該サーバ上のデータに透過的にアクセスすることは、該インターフェースユニットと該第１のクライアントとの間の該接続の承認番号とシーケンス番号とを該インターフェースユニットと該サーバとの間の該接続の承認番号とシーケンス番号とに変換し、該インターフェースユニットと該サーバとの間の該接続の承認番号とシーケンス番号とを該インターフェースユニットと該第１のクライアントとの間の該接続の承認番号とシーケンス番号とに変換することにより、変換されたＧＥＴセグメントを生成することを含み、該変換されたＧＥＴセグメントは、「Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ」ヘッダを含む、ステップと、
該インターフェースユニットと該サーバとの間の該接続を開に維持する一方で、該第１のクライアントと該インターフェースユニットとの間の該接続を閉にするステップであって、第２のクライアントは、該インターフェースユニットとの接続が確立したことに応答して、該インターフェースユニットと該サーバとの間の該接続を再使用することが可能である、ステップと
を包含する、方法。
【請求項１１】
インターフェースユニットによって実行される方法であって、
第１のクライアントからの要求に応答してサーバへの接続を開にし、該接続を介してデータを転送するために使用されるシーケンス番号と承認番号とを確立するステップと、
ネットワークアドレスとパス名とを用いてデータを検索する要求を第２のクライアントから受信するステップであって、該第２のクライアントからの該要求は、シーケンス番号と承認番号とを含む、ステップと、
該インターフェースユニットと該第２のクライアントとの間の接続のシーケンス番号と承認番号とを該第１のクライアントからの該要求に応答して開にされた該インターフェースユニットと該サーバとの間の接続のシーケンス番号と承認番号とに変換することにより、変換されたＧＥＴセグメントを生成することによって、該第１のクライアントからの該要求に応答して開にされた該接続を用いて該サーバからの該データを要求するステップであって、該サーバからの該データを要求するステップは、「Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ」ヘッダを該変換されたＧＥＴセグメントに挿入するステップをさらに含む、ステップと、
該サーバからデータを受信するステップと、
該サーバから受信した該データにおける該第１のクライアントからの該要求に応答して開にされた該該インターフェースユニットと該サーバとの間の該接続のシーケンス番号と承認番号とを該インターフェースユニットと該第２のクライアントとの間の接続のシーケンス番号と承認番号とに変換することにより、変換されたシーケンス番号と変換された承認番号とを生成するステップと、
該変換されたシーケンス番号と該変換された承認番号とを用いて、該データを該第２のクライアントに送信するステップと
を包含する、方法。
【請求項１２】
インターフェースユニットであって、
パス名に基づいて、所定のポリシーの関数として、データを格納するサーバを選択する手段と、
該サーバの負荷に基づいて、所定のポリシーの関数として、該データを格納する該サーバを選択する手段と、
該サーバの状態に基づいて、所定のポリシーの関数として、該データを格納する該サーバを選択する手段と、
第１のクライアントからの要求に応答して、確立された該サーバへの既に開にされた接続を識別し、該接続に使用されるシーケンス番号および承認番号を識別する手段と、
ネットワークアドレスとパス名とを用いてデータを検索する要求を第２のクライアントから受信する手段であって、該第２のクライアントからの該要求は、シーケンス番号と承認番号とを有するＧＥＴセグメントを含む、手段と、
該インターフェースユニットと該第２のクライアントとの間の接続の該ＧＥＴセグメントにおけるシーケンス番号と承認番号とを確立された該インターフェースユニットと該サーバとの間の既に開にされた接続の承認番号とシーケンス番号とに変換することにより、変換されたＧＥＴセグメントを生成し、該変換されたＧＥＴセグメントを該サーバに送信することによって、該既に開にされた接続を用いて該サーバからの該データを要求する手段であって、該サーバからの該データを要求する手段は、「Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ」ヘッダを該変換されたＧＥＴセグメントに挿入する手段をさらに含む、手段と、
該サーバから該データを受信する手段、および、該データを該第２のクライアントに送信する手段と
のうちの少なくとも１つを備える、インターフェースユニット。
【請求項１３】
前記データを前記第２のクライアントに送信する前記手段は、変換されたシーケンスパラメータと承認パラメータとを生成することを前記サーバから受信すると、該データにおけるシーケンス番号と承認番号とを変換し、該変換されたシーケンス番号と該変換された承認番号とを用いて、該データを該第２のクライアントに送信する手段を備える、請求項１２に記載のインターフェースユニット。
【請求項１４】
前記接続において使用されるシーケンス番号および承認番号を識別する前記情報は、それぞれ、開始シーケンス番号および開始承認番号を備える、請求項１２に記載のインターフェースユニット。
【請求項１５】
前記受信する手段は、
前記ネットワークアドレスを用いてホストへの接続を開く要求を前記第２のクライアントから受信する手段と、
前記パス名を用いてデータを検索する要求を該第２のクライアントから受信する手段と
を備える、請求項１２に記載のインターフェースユニット。
【請求項１６】
前記ネットワークアドレスと更なるパス名とを用いて更なるデータを検索する更なる要求を受信する手段と、
該更なるパス名の関数として、更なるサーバを選択する手段と、
該更なるサーバから該更なるデータを検索する手段と
をさらに備える、請求項１２に記載のインターフェースユニット。
【請求項１７】
前記サーバからの前記データを要求する前記手段は、
「Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ」ヘッダを該変換されたＧＥＴセグメントに挿入することによって加えられたバイト数を前記サーバから受信した前記承認番号から差し引く手段と、
該変換されたＧＥＴセグメントに続くパケットを該サーバに送信する前に、該「Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ」ヘッダを該変換されたＧＥＴセグメントに挿入することによって加えられたバイト数を前記シーケンス番号に加える手段と
をさらに備える、請求項１２に記載のインターフェースユニット。
【請求項１８】
前記サーバからの前記データを要求する前記手段は、
更なるシーケンス番号と更なる承認番号とを有する第１のＲＥＳＰセグメントを受信する手段と、
該更なる番号を変換することにより、変換されたＲＥＳＰセグメントを生成する該インターフェース手段と、
該変換されたＲＥＳＰセグメントを該クライアントに送信する手段と
をさらに備える、請求項１２に記載のインターフェースユニット。
【請求項１９】
インターフェースユニットによって実行される方法であって、
第１のクライアントからの要求に応答してサーバへの接続を開にするステップであって、該サーバは、パス名、該サーバの負荷および該サーバの状態のうちの少なくとも１つを含む所定のポリシーの関数として選択される、ステップと、
接続と、該接続上のデータを受信する際に使用されるシーケンス番号および承認番号を識別するステップと、
データを検索する要求を第２のクライアントから受信するステップであって、該第２のクライアントからの該要求は、シーケンス番号と承認番号とを含む、ステップと、
該シーケンス番号と該承認番号とを該インターファースユニットと該サーバとの間の既に開にされたシーケンス番号と承認番号とに変換することにより、変換されたＧＥＴセグメントを生成することによって、該既に開にされた接続を用いて該サーバからの該データを要求するステップであって、該サーバからの該データを要求するステップは、「Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ」ヘッダを該変換されたＧＥＴセグメントに挿入するステップをさらに含む、ステップと、
該サーバからデータを受信するステップと、
該データを該第２のクライアントに送信するステップと
を包含する、方法。
【請求項２０】
前記受信するステップは、
前記ネットワークアドレスを用いてホストへの接続を開く要求を前記第２のクライアントから受信するステップと、
パス名を用いてデータを検索する要求を該第２のクライアントから受信するステップと
を包含する、請求項１９に記載の方法。
【請求項２１】
前記ネットワークアドレスと更なるパス名とを用いて更なるデータを検索する更なる要求を受信するステップと、
該更なるパス名の関数として、更なるサーバを選択するステップと、
該更なるサーバから該更なるデータを検索するステップと
をさらに包含する、請求項２０に記載の方法。
【請求項２２】
前記サーバからの前記データを要求する前記ステップは、
「Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ」ヘッダを該変換されたＧＥＴセグメントに挿入することによって加えられたバイト数を前記サーバから受信した前記承認番号から差し引くステップと、
該変換されたＧＥＴセグメントに続くパケットを該サーバに送信する前に、該「Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ」ヘッダを該変換されたＧＥＴセグメントに挿入することによって加えられたバイト数を前記シーケンス番号に加えるステップと
をさらに包含する、請求項１９に記載の方法。
【請求項２３】
更なるシーケンス番号と更なる承認番号とを有する第１のＲＥＳＰセグメントを受信するステップと、
該更なる番号を変換することにより、変換されたＲＥＳＰセグメントを生成するステップと、
該変換されたＲＥＳＰセグメントを該第２のクライアントに送信するステップと
をさらに包含する、請求項１９に記載の方法。
【請求項２４】
更なるシーケンス番号と更なる承認番号とを有する第１のＲＥＳＰセグメントを受信するステップと、
更なる番号を変換することにより、更なる変換された番号を生成するステップと、
第２のＲＥＳＰセグメントを前記第２のクライアントに送信するステップであって、該第２のＲＥＳＰセグメントは、該更なる変換されたパラメータを有している、ステップと
をさらに包含する、請求項２１に記載の方法。
【請求項２５】
データを検索する要求を受信する前記ステップは、シーケンス番号と承認番号とを有する第１のＧＥＴセグメントを受信するステップを包含し、
前記検索するステップは、該番号を変換することにより、変換された番号を生成し、第２のＧＥＴセグメントを該サーバに送信するステップであって、該第２のＧＥＴセグメントは、該変換された番号を有している、ステップを包含する、請求項１９に記載の方法。
【請求項２６】
前記接続上のデータを受信する際に使用される前記シーケンス番号および承認番号は、それぞれ、開始シーケンス番号および開始承認番号である、請求項１９に記載の方法。
【請求項２７】
前記データを前記第２のクライアントに送信する前記ステップは、変換されたシーケンス番号と承認番号とを生成することを前記サーバから受信すると、前記データにおけるシーケンス番号と承認番号とを変換し、該変換されたシーケンス番号と承認番号とを用いて、該データを該第２のクライアントに送信するステップを包含する、請求項１９に記載の方法。
【発明の詳細な説明】
【０００１】
（発明の背景）
（発明の分野）
本発明は概して、インターネットクライアントサーバアプリケーション、より詳細には、クライアントとサーバとの間のインターネットを通じたマルチプレクサ接続に関するものである。
【０００２】
（関連技術）
早い情報交換およびデータ交換の現代の経済に対する重要性は控え目に述べることはできない。これは、指数関数的に増加するインターネットの人気を説明する。インターネットは、相互接続されたコンピュータネットワークの世界的な集合である。そのコンピュータネットワークの集合は、量および種類が増大する情報に電子的にアクセスするために用いられ得る。
【０００３】
インターネット上の情報にアクセスするための一手法は、ワールドワイドウェブ（ｗｗｗまたは「ウェブ」）として公知である。そのウェブは、分散されたハイパーメディアシステムであり、クライアントサーバに基づいた情報提示システムとして機能する。ウェブ全体にわたってアクセス可能であるように意図される情報は、「サーバ」として公知の汎用コンピュータに「ページ」の形式で記憶されている。コンピュータのユーザは、そのページのユニフォームリソースロケータ（ＵＲＬ）を指定することによって、「クライアント」と呼ばれる汎用コンピュータを用いてウェブページにアクセスし得る。図１は、インターネットに接続された複数のクライアントおよびサーバを示したネットワークブロック図である。
【０００４】
クライアントがＵＲＬを特定する場合、ドメイン名として公知のＵＲＬの一部は、ネットワークアドレスに変換するためにドメインサーバ（ＤＮＳ）に渡される。そのネットワークアドレスは、意図したサーバのインターネットプロトコル（ＩＰ）アドレスを指定する。クライアント要求は、そのネットワークアドレスを有するサーバに渡される。そのサーバは、クライアントによって要求されたウェブページの位置を示すためにＵＲＬ中のパス名を用いる。次いで、ウェブページのコピーは、ユーザが見るためにクライアントに送信される。
【０００５】
上記されたクライアントサーバのパラダイムは、インターネットに非常に役立ってきた。しかしながら、いくつかの問題が存在する。１つの問題は、サーバ接続ローディングである。
【０００６】
サーバは、あることをうまく行なうように設計されている。サーバは、一般的なタスク、例えば、ファイル管理、アプリケーション処理、データベース処理などに対して最適化された汎用機である。サーバは、ネットワーク接続の開閉のようなタスク切換えを扱うようには最適化されていない。ある負荷条件下で、これらのタスクは、サーバの処理リソースの大部分のパーセンテージ（しばしば２０パーセント、時には５０パーセントまでのオーダ）を消費する、かなりのオーバーヘッドを表し得る。この問題は、本明細書では「接続ローディング」と呼ぶ。
【０００７】
ローディングをさらに説明すると、クライアントおよびサーバは、典型的に接続を設定するために３パケットの情報を交換しなければならない。一度その接続が確立されると、クライアントは、サーバにＵＲＬ（ページ）要求を送信する。このＵＲＬ（ページ）要求は、１パケットからなる。次いで、このサーバは、１つ以上のパケット応答を、クライアントへ返送する。一度要求および応答が、クライアントおよびサーバから交換されると、クライアントおよびサーバの両方は、それぞれの接続を閉にする。接続を閉にするには、さらに４つのパケット情報交換が必要である。上述されたように、１つのＵＲＬをダウンロードすることに関するかなりの量のオーバーヘッドがある（すなわち、７パケット）。ページは典型的に、複数のＵＲＬからなる。
【０００８】
接続ローディングに関するさらなる問題は、以下のことを含む。サーバに到達する各パケットは、サーバのＣＰＵに割り込み、ネットワークインターフェイスカード（ＮＩＣ）からサーバのメインメモリまでのそのパケットを移動させる。結果として、これはサーバのＣＰＵの生産性を損失する。従って、必要とされることは、サーバ側で貴重なＣＰＵ時間を消費することを回避する方法である。結果として、同じリソースがより多くのＵＲＬ（ページ）要求を処理するために適用され得る。従って、これによりサーバのＵＲＬ処理容量が改善される。
【０００９】
上記で議論されたように、接続の確立のために３つのパケットが必要である。さらに、接続の確立は、ＣＰＵ／メモリに関連したかなりのサーバリソースを消耗する。サーバ側で接続を確立するために、パケットは、ドライバ層によって処理されることが必要である。ここで、イーサネット（登録商標）特有の情報が扱われる。そのドライバ層は、より多く処理するためにＩＰ層にパケットを送信する。ここで、ＩＰ（インターネットプロトコル）に関連した処理の全てが扱われる。この後、パケットはＴＣＰ（伝送制御プロトコル）層に渡される。ここで、ＴＣＰ層に関連する情報が処理される。ＴＣＰ層は、接続テーブル等を作成するために、かなりのサーバリソースを消費する。従って、必要とされることは接続処理を回避して、それによって、かなりのＣＰＵ／メモリリソースをセーブするための方法である。
【００１０】
ウェブサーバは、処理されるべき入来接続のそれぞれに対するスレッドを作成する必要がある。接続とＵＲＬ要求が処理されると、そのスレッドは終了する。スレッドは、プロセスの型の１つであるライトウェイトプロセス（ＬＷＰ）である。スレッドは効率的であるけれども、スレッドを作成し、破壊するためにかなりのＣＰＵおよびメモリが必要である。従って、スレッドの作成を回避することにより、サーバリソースのかなりの量が温存され得る。続いて、そのサーバリソースのかなりの量は、ウェブ要求をより多く処理するために用いられ得る。
【００１１】
１つ以上のＣＰＵを有するサーバは、ＳＭＰ（対称型マルチプロセッシング）システムと呼ばれており、これらのシステムは、共通のメモリアーキテクチャを有する。そのＳＭＰシステムはまた、複数のＣＰＵを管理する１つのオペレイティングシステム（ＯＳ）を有する。１つのＯＳは、１つのネットワーキング／プロトコルスタックを意味する。複数のＣＰＵがカーネルプロトコルスタック中のデータ構造にアクセスする場合、１つ以上のＣＰＵがそのデータ構造に読み／書きをし得るので、データの破損に対して保護することが重要である。保護コードは、ＳＭＰシステムにパケット当たりのさらなるオーバーヘッドを負担させる。
【００１２】
最終的に、個々のサーバのスループットには、限界がある。従って、大量のインターネット要求を扱うことを望むデータの提供者は、しばしば、複数のサーバ上にコンテンツを複製し、次に、これらのサーバ間に要求を分散させるというアプローチに頼る。このアプローチは、たとえそのコンテンツが、まれにしかアクセスされなくても、各複製サーバにコンテンツの全体を複製する必要がある。これは、サーバリソースの浪費を示す。
【００１３】
（発明の要旨）
本発明は、ネットワーククライアントサーバのマルチプレッシングのためのシステム、方法、およびコンピュータプログラム製品である。好適な実施形態において、本発明は、インターネットに複数のサーバを接続するインターフェイスユニットの中で実行され、インターフェイスユニットは、次に、複数のクライアントに接続されている。
【００１４】
本発明の１つの局面によれば、その方法は、クライアントとインターフェイスユニットとの間の接続を開始するステップと、インターフェイスユニットとサーバとの間で開である、空いている接続がない場合、インターフェイスユニットとサーバとの間の接続を開にするステップと、クライアントがその接続を経由してサーバ上の情報にアクセスすることを可能にするステップと、インターフェイスユニットとサーバとの間の接続を開に維持する一方で、クライアントとインターフェイスユニットとの間の接続を閉にするステップとを含む。
【００１５】
本発明の別の局面によれば、その方法は、ネットワークアドレスおよびパス名を使用してデータを検索する要求をクライアントから受信するステップと、パス名、サーバの負荷、およびサーバの状態のうち少なくとも１つを含むあらかじめ定義された方針の機能としてデータを格納するサーバを選択するステップと、既に開にされた接続を使用してサーバからデータを検索するステップと、クライアントにそのデータを送信するステップとを含む。
【００１６】
本発明の１つの利点は、本明細書において「接続プーリング」として参照される技術によって、接続ローディング問題を解消するということである。
【００１７】
本発明の別の利点は、本明細書において「接続分散（ｃｏｎｎｅｃｔｉｏｎ  ｄｉｓｔｒｉｂｕｔｉｏｎ）」として参照される技術の使用によって、接続複製問題を解消するということである。
【００１８】
さらに本発明の別の利点は、本明細書において「接続マルチプレクシング」として参照される技術を使用して、サーバおよびクライアントからの接続を、ユーザに意識させないでスプライスする（ｓｐｌｉｃｅ）ということである。
【００１９】
本発明の特徴および利点は、図面を組合せることで、下記に示す詳細な記述により、より明白となる。図面にわたって、同じ参照文字は対応する要素を特定する。
【００２０】
（好適な実施形態の詳細な説明）
本発明は、ネットワーククライアントサーバのマルチプレクシングのためのシステム、方法、およびコンピュータプログラム製品である。
【００２１】
図２は、本発明の好適な実施形態に従うインターフェイスユニット２０２についてのネットワークコンテクストの図である。好適な実施形態において、インターフェイスユニットは、サーバ内のＣＰＵを有するインテリジェントネットワークインターフェイスカードである。インターフェイスユニットはまた、サーバの外に設置しているインテリジェントボックスであり得、この場合、１つ以上のサーバを取り扱い得る。インターフェイスユニット２０２はまた、クライアントとサーバとの間に設けられている負荷バランサ、バンド幅マネージャ、ファイアウォール、ルータ、スイッチ、コンピュータシステム、または他の任意のネットワークデバイスであり得る。
【００２２】
図２を参照すると、複数のクライアントＣ１、Ｃ２、Ｃ３は、インターネットに接続されており、複数のサーバＳ１、Ｓ２、Ｓ３は、インターフェイスユニット２０２によってインターネットに接続されている。複数のサーバＳ１、Ｓ２、Ｓ３は、ひとまとめにして「サーバファーム」と言われている。サーバファームとのすべてのインターネットトラフィックは、インターフェイスユニット２０２を通過する。本発明はインターネットに関して説明されるが、当該分野の当業者に明確なように、説明される概念はまた、別のタイプのネットワークにもあてはまるる。
【００２３】
本発明の１つの局面によると、インターフェイスユニット２０２は、各サーバとの１つ以上の接続を開にし、インターネットを介してクライアントが繰り返してデータにアクセスできるようにこれらの接続を維持することによって、クライアントへの接続を繰り返し開閉することで生じるサーバＳ１、Ｓ２、Ｓ３の多くの処理負荷を軽減する。この技術は、本明細書において「接続プーリング」と言われている。
【００２４】
図３は、好適な実施形態に従う本発明の接続プーリング局面の動作を示すフローチャートである。このプロセスは、クライアントが、インターフェイスユニット２０２によって管理されているサーバファームにおいて、１つのサーバへのアクセスを要求する場合に開始する。接続は、インターフェイスユニットと要求しているクライアントとの間で開であり、インターフェイスユニット２０２は、ステップ３０２で示されるように、サーバにアクセスするためのクライアント要求を受信する。インターフェイスユニット２０２は、ステップ３０４で示されるように、要求されたサーバのアイデンティティを決定する。１つの実施形態において、これは、クライアント要求によって特定されたデスティネーションネットワークアドレスを検査することによって達成される。別の実施形態において、これは、クライアント要求によって特定されたネットワークアドレスおよびパス名を検査することによって達成される。クライアント要求が向けられなければならないサーバのアイデンティティを決定した後、インターフェイスユニット２０２は、ステップ３０６で示されるように、サーバへの空いている（すなわち、使用されていない）接続が既に開であるかどうかを決定する。開であるなら、処理はステップ３１０で再開する。開でないなら、インターフェイスユニット２０２は、ステップ３０８で示されるように、サーバへの接続を開にする。次に、インターフェイスユニット２０２は、ステップ３１０で示され、以下の図４に関してより詳細に説明するように、クライアント要求を変換し、サーバにそれを渡す。サーバ処理の後、インターフェイスユニットは、ステップ３１２で示されるように、サーバからの応答を受信する。サーバ応答は、ステップ３１４で示され、以下にさらに説明されるように、交換され、要求しているクライアントに渡される。最終的に、インターフェイスユニット２０２は、ステップ３１６で示されるように、クライアントとの接続を閉にする。しかしながら、インターフェイスユニット２０２とサーバとの間の接続は、切断されない。サーバとの開である接続を維持すること、ならびに、必要に応じてクライアントとの接続を開閉することによって、インターネットを介して取り扱うクライアントに関する接続負荷のほとんどすべての問題をサーバから解放する。
【００２５】
図４は、ステップ３１０およびステップ３１４で示されるように、接続マルチプレクシングを達成するためにクライアントおよびサーバの要求を変換する際の、本発明の動作を示すフローチャートである。好適な実施形態において、メッセージトラフィックは、ＴＣＰ／ＩＰパケットの形式、当該分野で周知のプロトコル群の形式である。ＴＣＰ／ＩＰプロトコル群は、多くのアプリケーション、例えば、Ｔｅｌｎｅｔ、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＦＴＰ）、ｅ-ｍａｉｌ、Ｈｙｐｅｒ-Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）をサポートする。本発明は、ＨＴＴＰプロトコルに関して説明される。しかしながら、本明細書を読むことで、当該者に明確となるように、本発明の概念は、他のＴＣＰ／ＩＰアプリケーションにも同様にあてはまる。
【００２６】
各ＴＣＰパケットは、ＴＣＰヘッダおよびＩＰヘッダを備える。ＩＰヘッダは、３２ビットソースＩＰアドレス、および３２ビットデスティネーションＩＰアドレスを備える。ＴＣＰヘッダは、１６ビットソースポート番号、および１６ビットデスティネーションポート番号を備える。ソースＩＰアドレスおよびポート番号はひとまとめにして、ソースネットワークアドレスと呼ばれており、パケットのソースインターフェイスを一意に特定する。同様に、デスティネーションＩＰアドレスおよびポート番号はひとまとめにして、デスティネーションネットワークアドレスと呼ばれており、パケットに対するデスティネーションインターフェイスを一意に特定する。パケットのソースネットワークアドレスおよびデスティネーションネットワークアドレスは、接続を一意に特定する。ＴＣＰヘッダはまた、３２ビットシーケンス番号および３２ビット承認番号を含む。
【００２７】
パケットのＴＣＰの部分は、セグメントと呼ばれている。セグメントは、ＴＣＰヘッダおよびデータを含む。シーケンス番号は、送信ＴＣＰから受信ＴＣＰまでのデータの文字列でセグメントのデータの初めのバイトが表わすバイトを特定する。交換されたそれぞれのバイトが番号付けされるので、承認番号は、承認の送信側が受け取ると予期する次のシーケンス番号を含む。従って、これは、最後に正常に受信されたデータのバイトを加えたシーケンス番号である。チェックサムはＴＣＰセグメント、すなわち、ＴＣＰヘッダおよびＴＣＰデータをカバーする。これは、送信側によって計算され、記憶され、続いて、受信側によって確認されなければならない必須のフィールドである。
【００２８】
クライアントから意図したサーバまでインバウンドのパケットを正常にルーティングするために、または、サーバからクライアントまでアウトバウンドのパケットを正常にルーティングするために、インターフェイスユニット２０２は、「ネットワークアドレス変換」として公知のプロセスを使用する。ネットワークアドレス変換は、当該分野で周知であり、ｒｅｑｕｅｓｔ  ｆｏｒ  ｃｏｍｍｅｎｔｓ（ＲＦＣ）１６３１によって仕様が定められている。そのＲＦＣ１６３１は、ＵＲＬ  ｈｔｔｐ：／／ｗｗｗ．ｓａｆｅｔｙ．ｎｅｔ／ＲＦＣ１６３１.ｔｘｔで見出され得る。
【００２９】
しかしながら、クライアントおよびサーバ接続を連続的にスプライスするために、本発明はまた、本明細書中で「接続マルチプレクシング」と呼ばれる新しい変換技術を使用する。この技術によって、本発明は、ＴＣＰプロトコルレベルでパケットのシーケンス番号および承認番号を修正することによってパケットを変換する。この技術の重要な利点は、アプリケーション層相互作用が必要とされないということである。
【００３０】
図４を参照して、ステップ４０２に示されるように、パケットのネットワークアドレスが変換される。インバウンドパケット（すなわち、パケットがクライアントから受信された）の場合において、パケットのソースネットワークアドレスは、インターフェイスユニットの出力ポートのネットワークアドレスに変換され、デスティネーションネットワークアドレスは、意図したサーバのネットワークアドレスに変換される。アウトバンドパケット（すなわち、パケットがサーバから受信された）の場合において、ソースネットワークアドレスは、サーバのネットワークアドレスからインターフェイスユニットの出力ポートのネットワークアドレスに変換され、デスティネーションアドレスは、インターフェイスユニットのネットワークアドレスから要求しているクライアントのネットワークアドレスに変換される。パケットのシーケンス番号および承認番号もまた、ステップ４０４および４０６に示され、以下で詳細に記載されるように、変換される。最後に、パケットチェックサムは、ステップ４０８に示されるように、これらの変換を仕上げるために再計算される。
【００３１】
図５は、好適な実施形態に従う本発明の接続プーリング局面を示すメッセージフロー図である。図５は、サーバＳに２つのクライアントＣ１およびＣ２を接続したインターフェイスユニット２０２を示す。初めに、インターフェイスユニット２０２は、フロー５０２に示されるように、クライアントＣ１によって提供されたネットワークアドレス１を使用して、クライアントＣ１との接続を開にする。フローライン５０２は、２方向のフローとして示されている。なぜならば、ＴＣＰ／ＩＰプロトコルは、接続を開にするために多段式のハンドシェイクを使用するからである。
【００３２】
ひとたび接続が開にされると、インターフェイスユニット２０２は、フローライン５０４に示されるように、／ｓａｌｅｓ／ｆｏｒｅｃａｓｔ．ｈｔｍｌのパス名を指定するクライアントＣ１からのＧＥＴ要求を受信する。インターフェイスユニット２０２とサーバＳとの間に開である空いている接続がないために、インターフェイスユニット２０２はサーバＳとの接続を開にする。フローライン５０６に示されるように、インターフェイスユニット２０２は、サーバＳを特定するネットワークアドレス２にこの要求をマッピングする。インターフェイスユニット２０２はまた、フローライン５０８に示されるように、そのサーバにＧＥＴ要求を渡す。サーバＳは、フローライン５１０に示されるように、要求されたウェブページで応答する。インターフェイスユニット２０２は、フローライン５１２に示されるように、クライアントＣ１にウェブページを転送する。最後に、クライアントＣ１とインターフェイスユニット２０２との間の接続は、フローライン５１４に示されるように、閉にされる。ＴＣＰ／ＩＰプロトコルによれば、ネットワークの接続を閉にすることは、多段式のプロセスを包含し得る。従って、フローライン５１４は、双方向として示される。インターフェイスユニット２０２は、サーバＳとの接続を閉にせず、むしろ、さらなるデータフローを供給するために接続を開に維持することに注意することが重要である。
【００３３】
次に、接続は、フローライン５１６に示されるように、クライアントＣ２によって提供されたネットワークアドレス１を使用して、インターフェイスユニット２０２とクライアントＣ２との間で開にされる。続いて、インターフェイスユニット２０２は、フローライン５１８に示されるように、ウェブページ／ｓａｌｅｓ／ｆｏｒｅｃａｓｔ．ｈｔｍｌを指定するクライアントＣ２からのＧＥＴ要求を受信する。空いている接続がすでにインターフェイスユニット２０２とサーバＳとの間で開であるために、インターフェイスユニット２０２にとって、サーバＳにさらなる接続を開にする際にともなう処理負荷を負わせることが不要となる。インターフェイスユニット２０２は単に、空いている、開である接続を使用する。インターフェイスユニット２０２は、フローライン５２０に示されるように、サーバＳにＧＥＴ要求をマッピングし、ＧＥＴ要求を変換し、サーバＳにＧＥＴ要求を転送する。インターフェイスユニット２０２は、フローライン５２２に示されるように、サーバＳからの応答を受信し、フローライン５２４に示されるように、クライアントＣ２に応答を転送する。最後に、インターフェイスユニット２０２は、フローライン５２６に示されるように、クライアントＣ２との接続を閉にする。前と同じように、インターフェイスユニット２０２は、サーバＳとの接続を閉にしない。代わりに、インターフェイスユニット２０２は、さらなるデータフローを供給するために接続を開に維持する。
【００３４】
フローライン５２４に示されるように、インターフェイスユニット２０２が結果としてクライアントＣ２との接続を閉にするという多くのシナリオが存在する。例えば、クライアントは、ＦＩＮ（終了）コマンドを開始し得る。それは、ひとたびクライアントが要求したデータの全てを受信したときに生じる。クライアントはまた、ＲＳＴ（リセット）コマンドを開始し得る。インターフェイスユニット２０２とクライアントとの間の接続を閉にすることに加えて、ＲＳＴコマンドにより、サーバ側の接続を良好な順序に維持するために実行される多くのハウスキーピング動作が、結果として得られる。特に、ＴＣＰプロトコルは、ＲＳＴコマンドが正しいＳＥＱ（シーケンス）番号を有し、それにより、サーバが、セグメントを受取るということを保証する。しかしながら、ＲＳＴコマンドは、正しいＡＣＫ（承認）番号を有することが保証されない。このシナリオを処理するために、インターフェイスユニット２０２は、サーバによって送信されたデータのバイトおよびクライアントによって承認されたバイトを追跡する。クライアントが、サーバによるデータの全てをまだ承認していなかった場合、インターフェイスユニット２０２は、承認されていないバイトを計算し、サーバにＡＣＫを送信する。その上、サーバ側のＰＣＢは、任意の処理待ちのサーバデータトランスファを排出することを可能にするタイムアウトキューに配置され得る。
【００３５】
さらに、図５には示されていないが、サーバはまた、サーバ自身とインターフェイスユニット２０２との間の接続を閉にし得る。サーバは、インターフェイスユニット２０２にＦＩＮコマンドを送信する。このケースにおいて、サーバとインターフェイスユニット２０２との間の接続、およびインターフェイスユニット２０２とクライアントとの間の接続の両方は、閉にされる。
【００３６】
本発明の別の局面は、サーバが接続を閉じる機会を最小限にすることにより、サーバからの接続処理の負荷の除去を最大限にすることである。以下の３つの場合がある。
【００３７】
（１）プロトコルバージョンＨＴＴＰ／１．１が使用される場合。この場合、明示的なＫｅｅｐ−Ａｌｉｖｅヘッダは必要とされない。デフォルトにより、サーバは接続を開いたままにし、接続を閉じるのはクライアント次第である。本発明は、サーバ側接続を再利用することにより、サーバの負荷を取り除く。
【００３８】
（２）プロトコルバージョンＨＴＴＰ／１．０が使用され、かつ、クライアントにより“Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ”ヘッダが提供される場合。この場合、サーバは接続を開いたままにし、接続を閉じるのはクライアント次第である。本発明は、サーバ側接続を再利用することにより、サーバの負荷を取り除く。
【００３９】
（３）プロトコルバージョンＨＴＴＰ／１．０が使用され、かつ、クライアントにより“Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ”ヘッダが提供されない場合。この場合、サーバは、通常（本発明を使用せずに）、１つのＧＥＴ要求を完全に満たした後、接続を閉じる。サーバが各要求後に接続を閉じる場合、サーバは、そのインターフェイスユニット２０２に、サーバ側接続を再利用する機会を与えない。インターネットの多くが、依然として“Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ”なしでＨＴＴＰ／１．０を使用していることがわかる。従って、本発明は、この特定の、かつ重要な場合に、サーバ側接続の再使用を可能にする。インターフェイスユニット２０２は、ＧＥＴパケットを調べて、この状況を検出する。この場合が検出されると、インターフェイスユニット２０２は、ＧＥＴパケットに“Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ”を挿入する。これは、クライアントには見えない状態で行われるため、インターフェイスユニット２０２は、サーバ側接続での“Ｂｙｔｅｓ  Ａｄｄｅｄ”の数を把握しなければならない。“Ｂｙｔｅｓ  Ａｄｄｅｄ”は、ＧＥＴパケットにおけるシーケンス番号に影響を及ぼさない。なぜなら、シーケンス番号は、最初のバイトのものであるからである。しかし、インターフェイスユニット２０２は、クライアントからサーバへの後続パケットのシーケンス番号に、“Ｂｙｔｅｓ  Ａｄｄｅｄ”を追加しなければならない。逆に言えば、サーバは、追加バイトを承認するが、インターフェイスユニットは、これらのバイトが追加されたことを知らないクライアントに承認応答を送る前に、追加バイトを差し引かなければならない。
【００４０】
上記のように、接続マルチプレクシングは、シーケンス番号および承認番号を操作することにより達成される。インターフェイスユニット２０２により受け取られたセグメントのシーケンス番号および承認番号は、変更され、そして受け側により期待される値にマップされる。クライアントには、データは、サーバから入ってくるように見え、そしてその逆も同様である。たとえば、“Ｉｎｆｌｏｗ”が、インターフェイスユニット２０２により受け取られたセグメントを示し、“Ｏｕｔｆｌｏｗ”が対応する出力セグメントを示す場合、シーケンス番号および承認番号は、以下の態様で変えられる。
【００４１】
Ｏｕｔｆｌｏｗシーケンス番号＝Ｉｎｆｌｏｗシーケンス番号−Ｉｎｆｌｏｗ開始シーケンス番号＋Ｏｕｔｆｌｏｗ開始シーケンス番号
Ｏｕｔｆｌｏｗ承認番号＝Ｉｎｆｌｏｗ承認番号−Ｉｎｆｌｏｗ開始承認番号＋Ｏｕｔｆｌｏｗ開始承認番号
ＨＴＴＰ／１．０パケットの場合の“Ｃｏｎｎｅｃｔｉｏｎ：Ｋｅｅｐ−Ａｌｉｖｅ”ヘッダの追加に対処するために、インターフェイスユニット２０２は、接続の適切な側、この場合はサーバ側で、“Ｂｙｔｅｓ  Ａｄｄｅｄ”を追跡する。シーケンス番号および承認番号の式は、以下のように変えられる。
【００４２】
Ｏｕｔｆｌｏｗシーケンス番号＝Ｉｎｆｌｏｗシーケンス番号−Ｉｎｆｌｏｗ開始シーケンス番号＋Ｏｕｔｆｌｏｗ開始シーケンス番号＋Ｏｕｔｆｌｏｗ  Ｂｙｔｅｓ  Ａｄｄｅｄ
Ｏｕｔｆｌｏｗ承認番号＝Ｉｎｆｌｏｗ承認番号−Ｉｎｆｌｏｗ開始承認番号＋Ｏｕｔｆｌｏｗ開始承認番号−Ｉｎｆｌｏｗ  Ｂｙｔｅｓ  Ａｄｄｅｄ
これらの式を用いて達成される変換の具体的な実施例が、以下に示される。
【００４３】
図６Ａおよび図６Ｂは、好適な実施形態に従って図５の実施例において本発明により行われる承認番号およびシーケンス番号の変換を説明する詳細なフロー図である。図６Ａおよび図６Ｂにおける各フローのラベルは、Ｔ：Ｓ，Ａ（Ｌ）の形である。ここで、ＴはＴＣＰセグメントタイプを示し、Ｓはシーケンス番号であり、Ａは承認番号であり、Ｌは長さパラメータである。長さパラメータは、ＴＣＰセグメントにおけるデータのバイト数を示す。図６Ａのフローは、図５のフロー５０２〜５１４に対応する。
【００４４】
フロー６０２Ａ、Ｂ、Ｃは、フロー５０２に対応し、クライアントＣ１とインターフェイスユニット２０２との間の接続を開く１つの方法を示す。各フローは、ＴＣＰセグメントを示す。ＴＣＰセグメント６０２Ａにおいて、ＴＣＰヘッダのＳＹＮフラグがセットされ、クライアントＣ１からの新しい接続要求を示す。クライアントＣ１は、開始シーケンス番号２０００および承認番号２０００を確立している。インターフェイスユニット２０２は、フロー６０２Ｂで示されるように、開始シーケンス番号４０００を指定しかつ承認番号を２００１に増加するＳＹＮ  ＡＣＫセグメントで応答する。当該分野において周知のように、ネットワーク内の各エンティティ（例えば、クライアント、サーバ、インターフェイスユニット）は、そのエンティティ自体の固有のシーケンス番号および／または承認番号をセットする。クライアントＣ１は、フロー６０２Ｃで示されるように、シーケンス番号２００１を指定しかつ承認番号を４００１に増加するＡＣＫセグメントで応答する。次いで、クライアントＣ１は、フロー６０４で示されるように、４９バイト長を指定するＧＥＴセグメントを送る。
【００４５】
インターフェイスユニット２０２は、サーバＳとの間に空いている開いた接続はないと判定し、従って、フロー６０６Ａに示されるように、開始シーケンス番号１９５０を指定するＳＹＮセグメントをサーバＳに送る。サーバＳは、６０６Ｂに示されるように、開始シーケンス番号６０００を指定しかつ承認番号を１９５１に増加するＳＹＮ  ＡＣＫセグメントで応答する。インターフェイスユニット２０２は、フロー６０６Ｃで示されるように、ＡＣＫセグメントで応答する。次いで、インターフェイスユニット２０２は、フローライン６０８で示されるように、上記変換式に従ってシーケンス番号および承認番号を変更した後、クライアントＣ１からサーバＳにＧＥＴセグメントを送る。
【００４６】
サーバＳは、フロー６１０で示されるように、シーケンス番号６００１、承認番号２０００、および長さ９９９を指定する要求データで応答する。インターフェイスユニット２０２は、ＲＥＳＰセグメントを受け取り、シーケンス番号および承認番号を変換し、そしてフローライン６１２Ａで示されるように、ＲＥＳＰセグメントをクライアントＣ１に送る。クライアントＣ１は、フロー６１２Ｂで示されるように、ＲＥＳＰ  ＡＣＫセグメントで応答する。インターフェイスユニット２０２は、承認番号およびシーケンス番号を変更し、そしてフロー６１２Ｃに示されるように、ＲＥＳＰ  ＡＣＫセグメントをサーバＳに送る。
【００４７】
次いで、フロー６１４Ａ、Ｂ、Ｃ、Ｄに示されるように、クライアントＣ１とインターフェイスユニット２０２との間の接続が閉じられる。ただし、インターフェイスユニット２０２がサーバＳとの接続を維持することに注目することが重要である。
【００４８】
図６Ｂは、図６Ａの実施例の続きである。図６Ｂのフローは、図５のフロー５１６〜５２６に対応する。フロー６１６Ａ、Ｂ、Ｃはフロー５１６に対応し、クライアントＣ２とインターフェイスユニット２０２との間の接続を開く１つの方法を示す。ＴＣＰセグメント６１８Ａにおいて、ＴＣＰヘッダのＳＹＮフラグがセットされ、クライアントＣ２からの新しい接続要求を示す。クライアントＣ２は、開始シーケンス番号９９９および承認番号９９９を確立している。インターフェイスユニット２０２は、開始シーケンス番号４９９９を指定しかつ承認番号を１０００に増加するＳＹＮ  ＡＣＫセグメントで応答する。クライアントＣ２は、フロー６１６Ｃで示されるように、シーケンス番号１０００を指定しかつ承認番号を５０００に増加するＡＣＫセグメントで応答する。次いで、クライアントＣ２は、フロー６１８で示されるように、５０バイト長を指定するＧＥＴセグメントを送る。
【００４９】
インターフェイスユニット２０２は、サーバＳとの間に空いている開いた接続があると判定し、従って、インターフェイスユニット２０２は、その接続を使用する。サーバＳとの間に新しい接続を開く必要はない。インターフェイスユニット２０２が、サーバＳとの間の事前に開かれていた接続を使用しているため、インターフェイスユニット２０２は、その接続での以前の交換中に確立されたシーケンス番号および承認番号に従ってＧＥＴセグメントのシーケンス番号および承認番号を変換する。本実施例では、インターフェイスユニット２０２は、フロー６０６で確立された開始シーケンス番号および承認番号を使用し、最新フローであるフロー６１２Ｃで使用するシーケンス番号および承認番号で再開する。従って、インターフェイスユニット２０２は、フローライン６２０で示されるように、シーケンス番号２０００、承認番号７０００、および長さ５０を用いて、ＧＥＴセグメントを、クライアントＣ２からサーバＳに送る。
【００５０】
サーバＳは、フロー６２２で示されるように、シーケンス番号７０００、承認番号２０５０、および長さ５００を指定する要求データで応答する。インターフェイスユニット２０２は、ＲＥＳＰセグメントを受け取り、シーケンス番号および承認番号を変換し、そしてフローライン６２４Ａで示されるように、ＲＥＳＰセグメントをクライアントＣ２に送る。クライアントＣ２は、フロー６２４Ｂで示されるように、ＲＥＳＰ  ＡＣＫセグメントで応答する。インターフェイスユニット２０２は、承認番号およびシーケンス番号を変更し、そしてフロー６２４Ｃで示されるように、ＲＥＳＰ  ＡＣＫセグメントをサーバＳに送る。
【００５１】
次いで、フロー６２６Ａ、Ｂ、Ｃ、Ｄで示されるように、クライアントＣ２とインターフェイスユニット２０２との間の接続が閉じられる。インターフェイスユニット２０２がここでもサーバＳとの接続を維持することに注目することが重要である。
【００５２】
図７は、好適な実施形態に従う本発明の接続分散の特徴の動作を示すフローチャートである。この特徴によれば、インターフェイスユニット２０２は、複数のサーバとの接続を維持し、そして、クライアント要求において指定されたパス名に基づいて、クライアント要求をこれらのサーバに経路付けする。まず、ステップ７０２に示されるように、インターフェイスユニット２０２は、サーバとの間の接続を開く。次に、ステップ７０４に示されるように、クライアント要求に応答して、インターフェイスユニット２０２は、クライアントへの接続を開き、そしてクライアントから、パス名を用いてデータを検索する要求を受信する。ステップ７０６に示されるように、インターフェイスユニット２０２は、そのパス名により指定された内容を管理しているサーバを選択する。別の実施形態では、インターフェイスユニット２０２は、サーバの負荷およびサーバの状態、などのその他のあらかじめ規定された方針を考慮して、適切なサーバを選択する。インターフェイスユニット２０２は、インターフェイスユニット２０２が応対しているサーバおよびサーバファームのデータベースの管理および維持を行う。とりわけ、このデータベースの情報は、インターフェイスユニット２０２が入力パケットを正しいサーバに向けることを可能にする現在使用中のポリシーおよびルールを含む。所望のネットワーク状態およびサービスに依存して、これらのポリシーおよびルールは、非常に迅速に変わり得る。
【００５３】
次いで、ステップ７０８に示されるように、インターフェイスユニット２０２は、要求を変換し、そして、変換された要求を、選択されたサーバに渡す。この変換は、上で図４に関して大まかに説明されており、以下に詳細に説明される。
【００５４】
ステップ７１０に示されるように、インターフェイスユニットは、サーバから応答を受信する。次いで、ステップ７１２に示されるように、インターフェイスユニット２０２は、応答を変換し、そして変換された応答をクライアントに渡す。ステップ７０８と同様に、ステップ７１２の変換は、以下に詳細に説明される。最後に、ステップ７１４に示されるように、インターフェイスユニット２０２は、クライアントとの間の接続を閉じる。
【００５５】
図８は、好適な実施形態に従う本発明の接続分散の局面を説明するメッセージフロー図である。図８は、インターフェイスユニット２０２がクライアントＣ２を２つのサーバＳ１およびＳ２に接続する状態を示す。この実施例では、図７のステップ７０２で示されるように、サーバＳ１およびＳ２との接続が事前に開かれているものとする。
【００５６】
まず、インターフェイスユニット２０２は、フロー８０２で示されるように、クライアントＣ２により提供されたネットワークアドレス１を用いて、クライアントＣ２との間の接続を開く。一旦接続が開かれると、インターフェイスユニット２０２は、フローライン８０４で示されるように、クライアントＣ１から、パス名／ｓａｌｅｓ／ｆｏｒｅｃａｓｔ．ｈｔｍｌを指定するＧＥＴ要求を受信する。インターフェイスユニット２０２とサーバＳ１との間の空いている接続が開いているため、インターフェイスユニット２０２は、サーバＳ１との間に別の接続を開かない。
【００５７】
インターフェイスユニット２０２は、パス名を用いて、ＧＥＴ要求をサーバＳ２にマップする。例えば、インターフェイスユニット２０２は、サーバファームの各パス名を、対応するウェブページを含むサーバにマップするテーブルを含み得る。インターフェイスユニット２０２は、フローライン８０６で示されるように、ＧＥＴ要求をサーバＳ１に送る。サーバＳ１は、フローライン８０８で示されるように、要求されたウェブページで応答する。インターフェイスユニット２０２は、フローライン８１０で示されるように、ウェブページをクライアントＣ２に送る。本発明の接続プールの特徴に従って、インターフェイスユニット２０２は、サーバＳ１との接続を閉じないで開いたままにし、さらなるデータフローを受け入れる。
【００５８】
次に、フロー８１２に示されるように、別のＧＥＴ要求がクライアントＣ２から受け取られる。インターフェイスユニット２０２とクライアントＣ２との間の接続が、連続するＧＥＴ要求の間で閉じられるかどうかは、本実施例では重要ではない。このＧＥＴ要求が、前のＧＥＴ要求と同じクライアントから出されたものであるかどうかも、本実施例では重要ではない。重要なのは、クライアントからのＧＥＴ要求が、前のＧＥＴ要求と同じネットワークアドレス（ネットワークアドレス１）に向けられているのに、前の要求とは異なるサーバ（サーバＳ２）にマップされることである。本発明の接続多重化の特徴のため、このリダイレクションは、要求の発信元に対して透過性である。
【００５９】
インターフェイスユニット２０２は、クライアントＣ２からＧＥＴ要求を受信する。ＧＥＴ要求は、パス名／ｐｒｏｄｕｃｔｓ／ｎｅｗ．ｈｔｍｌを指定する。インターフェイスユニット２０２は、このパス名に対応するウェブページがサーバＳ２上にあると判定する。従って、図８のＧＥＴ要求は同じネットワークアドレスを指定しているが、これらのＧＥＴ要求は、それぞれのパス名を用いて、異なるサーバにマップされる。本実施例は、本発明の「接続分散」の局面を説明する。
【００６０】
インターフェイスユニット２０２とサーバＳ２との間の空いている接続がすでに開いているため、インターフェイスユニット２０２が、サーバＳ２に、別の接続を開く処理負荷を与えずにすむ。インターフェイスユニット２０２は単に、空いている開いた接続を使用するだけである。インターフェイスユニット２０２は、フローライン８１６で示されるように、サーバＳ２から応答を受け取り、フローライン８１８に示されるように、その応答をクライアントＣ２に送る。最後に、インターフェイスユニット２０２は、フロー８２０に示されるように、クライアントＣ２との接続を閉じる。この場合も、インターフェイスユニット２０２は、サーバＳ２との間の接続を閉じない。その代わりに、インターフェイスユニット２０２は、接続を開いたままにして、さらなるデータフローを受け入れる。
【００６１】
図９は、好適な実施形態に従って図８の実施例において本発明により行われる承認番号およびシーケンス番号の変換を説明する詳細なフロー図である。図９のフローは、図８のフロー８０２〜８２０に対応する。
【００６２】
フロー９０２Ａ、Ｂ、Ｃは、フロー８０２に対応し、クライアントＣ２とインターフェイスユニット２０２との間の接続を開く１つの方法を示す。クライアントＣ２は、開始シーケンス番号９９９および承認番号９９９を確立している。インターフェイスユニット２０２は、フロー９０２Ｂで示されるように、開始シーケンス番号４９９９を指定しかつ承認番号を１０００に増加するＳＹＮ  ＡＣＫセグメントで応答する。クライアントＣ２は、フロー９０２Ｃで示されるように、シーケンス番号１０００を指定しかつ承認番号を５０００に増加するＡＣＫセグメントで応答する。次いで、クライアントＣ２は、フロー９０４で示されるように、５０バイト長を指定するＧＥＴセグメントを送る。
【００６３】
サーバＳ１との間に空いている開いた接続があるため、インターフェイスユニット２０２は、新しい接続を開くのではなく、その接続を使用し、そして、その接続を介して伝送された前のセグメントからのシーケンス番号および承認番号を用いてＧＥＴセグメントのシーケンス番号および承認番号を変更する。本実施例では、それらのパラメータがそれぞれ２０００および７０００であるものとする。従って、インターフェイスユニット２０２は、フローライン９０６で示されるように、シーケンス番号２０００、承認番号７０００、および長さ５０を用いて、ＧＥＴセグメントをサーバＳ１に送る。
【００６４】
サーバＳ１は、フロー９０８で示されるように、シーケンス番号７０００、承認番号２０５０、および長さ５００を指定する要求データで応答する。インターフェイスユニット２０２は、ＲＥＳＰセグメントを受け取り、シーケンス番号および承認番号を変換し、そしてフローライン９１０Ａで示されるように、ＲＥＳＰセグメントをクライアントＣ２に送る。クライアントＣ２は、フロー９１０Ｂで示されるように、ＲＥＳＰ  ＡＣＫセグメントで応答する。インターフェイスユニット２０２は、承認番号およびシーケンス番号を変更し、そしてフロー９１０Ｃで示されるように、ＲＥＳＰ  ＡＣＫセグメントをサーバＳ１に送る。
【００６５】
次いで、インターフェイスユニット２０２は、クライアントＣ２から、５０バイト長を指定する別のＧＥＴセグメントを受け取る。上記のように、インターフェイスユニット２０２は、この要求をサーバＳ２にマップする。そのサーバとの間の空いている接続がすでに開いているため、インターフェイスユニット２０２は、その接続を使用し、そして、その接続を介して伝送された前のセグメントからのパラメータを用いてＧＥＴセグメントのシーケンスパラメータおよび承認パラメータを変換する。本実施例では、それらのパラメータがそれぞれ３０００および４０００であるものとする。従って、インターフェイスユニット２０２は、フローライン９１４で示されるように、シーケンス番号３０００、承認番号４０００、および長さ５０を用いて、ＧＥＴセグメントをサーバＳ２に送る。
【００６６】
サーバＳ２は、フロー９１６で示されるように、シーケンス番号４０００、承認番号３０５０、および長さ４００を指定する要求データで応答する。インターフェイスユニット２０２は、ＲＥＳＰセグメントを受け取り、シーケンス番号および承認番号を変換し、そしてフローライン９１８Ａで示されるように、ＲＥＳＰセグメントをクライアントＣ２に送る。クライアントＣ２は、フロー９１８Ｂで示されるように、ＲＥＳＰ  ＡＣＫセグメントで応答する。インターフェイスユニット２０２は、承認番号およびシーケンス番号を変更し、そしてフロー９１８Ｃで示されるように、ＲＥＳＰ  ＡＣＫセグメントをサーバＳ２に送る。最後に、フロー９２０Ａ、Ｂ、Ｃ、Ｄに示されるように、インターフェイスユニット２０２とクライアントＣ２との間の接続が閉じられる。
【００６７】
本発明は、ハードウェア、ソフトウェア、またはその組み合わせを用いて実現され得るとともに、コンピュータシステムまたはその他の処理システムにおいて実現され得る。実際に、１つの実施形態では、本発明は、本明細書に記載される機能を実行することができる１つ以上のコンピュータシステムに関する。例示的なコンピュータシステム１０００が、図１０に示される。コンピュータシステム１０００は、プロセッサ１００４などの１つ以上のプロセッサを含む。プロセッサ１００４は、通信バス１００６に接続される。この例示的なコンピュータシステムに関して、様々なソフトウェアの実施形態が説明される。本明細書を読めば、その他のコンピュータシステムおよび／またはコンピュータアーキテクチャを用いて本発明を実現する方法が、関連分野の当業者に明らかになる。
【００６８】
コンピュータシステム１０００はまた、メインメモリ１００８、好ましくはランダムアクセスメモリ（ＲＡＭ）を含み、二次メモリ１０１０も含み得る。二次メモリ１０１０は、例えば、ハードディスクドライブ１０１２および／またはリムーバブル格納ドライブ１０１４を含み得る。リムーバブル格納ドライブ１０１４は、フロッピー（登録商標）ディスクドライブ、磁気テープドライブ、光ディスクドライブなどを表す。リムーバブル格納ドライブ１０１４は、周知の態様でリムーバブル格納ユニット１０１８からの読み出しおよび／またはリムーバブル格納ユニット１０１８への書き込みを行う。リムーバブル格納ユニット１０１８は、リムーバブル格納ドライブ１０１４により読み出しおよび書き込みが行われる、フロッピー（登録商標）ディスク、磁気テープ、光ディスクなどを表す。リムーバブル格納ユニット１０１８は、コンピュータソフトウェアおよび／またはデータを格納している、コンピュータで使用可能な記憶媒体を含むことが認識される。
【００６９】
別の実施形態では、二次メモリ１０１０は、コンピュータプログラムまたはその他の命令がコンピュータシステム１０００にロードされることを可能にするためのその他の同様の手段を含み得る。そのような手段は、例えば、リムーバブル格納ユニット１０２２およびインターフェイス１０２０を含み得る。そのようなものの例は、プログラムカートリッジおよびカートリッジインターフェイス（ビデオゲームデバイスにみられるものなど）、リムーバブルメモリチップ（ＥＰＲＯＭまたはＰＲＯＭなど）および関連ソケット、ならびに、ソフトウェアおよびデータがリムーバブル格納ユニット１０１８からコンピュータシステム１０００に転送されることを可能にするその他のリムーバブル格納ユニット１０２２およびインターフェイス１０２０、を含み得る。
【００７０】
コンピュータシステム１０００はまた、通信インターフェイス１０２４を含み得る。通信インターフェイス１０２４は、ソフトウェアおよびデータが、コンピュータシステム１０００と外部デバイスとの間で転送されることを可能にする。通信インターフェイス１０２４の例は、モデム、ネットワークインターフェイス（イーサネット（登録商標）カードなど）、通信ポート、ＰＣＭＣＩＡスロットおよびカード、などを含み得る。通信インターフェイス１０２４を介して転送されたソフトウェアおよびデータは信号の形態であり、これらの信号は、電子、電磁、光学、または、通信インターフェイス１０２４により受け取られることが可能なその他の信号であり得る。これらの信号１０２６は、チャネル１０２８を介して通信インターフェイスに提供される。このチャネル１０２８は、信号１０２６を運び、ワイヤまたはケーブル、光ファイバ、電話回線、セルラーホンリンク、ＲＦリンク、およびその他の通信チャネルを用いて実現され得る。
【００７１】
本明細書において、「コンピュータプログラム媒体」および「コンピュータで使用可能な媒体」という用語は、リムーバブル格納デバイス１０１８、ハードディスクドライブ１０１２に取り付けられたハードディスク、および信号１０２６、などの媒体を総称するために用いられる。これらのコンピュータプログラムプロダクトは、コンピュータシステム１０００にソフトウェアを提供するための手段である。
【００７２】
コンピュータプログラム（コンピュータ制御論理とも呼ばれる）は、メインメモリおよび／または二次メモリ１０１０に格納される。コンピュータプログラムはまた、通信インターフェイス１０２４を介して受け取られ得る。そのようなコンピュータプログラムは、実行されると、コンピュータシステム１０００が本明細書において説明される本発明の特徴を実行することを可能にする。特に、コンピュータプログラムは、実行されると、プロセッサ１００４が本発明の特徴を実行することを可能にする。従って、そのようなコンピュータプログラムは、コンピュータシステム１０００のコントローラを表す。
【００７３】
ソフトウェアを用いて本発明が実現される実施形態では、ソフトウェアは、コンピュータプログラムプロダクトに格納され得、そして、リムーバブル格納ドライブ１０１４、ハードドライブ１０１２、または通信インターフェイス１０２４を用いて、コンピュータシステム１０００にロードされ得る。制御論理（ソフトウェア）は、プロセッサ１００４により実行されると、プロセッサ１００４に、本明細書に記載される本発明の機能を実行させる。
【００７４】
別の実施形態では、本発明は、例えば、特定用途向け集積回路（ＡＳＩＣ）などのハードウェアコンポーネントを用いて、主としてハードウェアにおいて実現される。本明細書に記載された機能を実行するようにハードウェアステートマシンを実現することは、関連分野の当業者に明らかである。さらに他の実施形態では、本発明は、ハードウェアおよびソフトウェアの両方の組み合わせを用いて実現される。
【００７５】
本発明は、サーバから接続処理オーバヘッドの負担を取り除く目的で、ファームのサーバに接続されるインターフェイスユニット２０２などのインターフェイスユニット内で実現される場合について具体的に説明されている。しかし、本発明はまた、クライアントとサーバとの間のネットワーク接続パスにあるその他の種類のデバイス内で適用され得る。ネットワークトラフィックがそのようなデバイスを通過するとき、それらのデバイスはすべて、本発明を適用して接続処理の負荷を取り除く機会を有する。そのようなデバイスのいくつかの例としては、以下のものがある。
【００７６】
−（局所的または地域分散型の）サーバファームのサーバの組の間でクライアントネットワーク接続を分配する負荷バランサ。本発明は、負荷バランシング機能と容易に組み合わされ得る。
【００７７】
−ネットワークトラフィックをモニタするとともに、パケットフローを計るバンド幅マネージャ。これらのデバイスはまた、本発明を使用し得る。
【００７８】
−ファイアウォールは、パケットをモニタし、そして、許可されたパケットだけが通過することを可能にする。本発明は、ファイアウォール内で追加の特徴を提供するために用いられ得る。
【００７９】
−ルータおよびスイッチはまた、ネットワークトラフィックのパスにある。産業トレンドは、追加の機能（負荷バランシング、バンド幅管理、およびファイアウォール機能など）を、これらのデバイス内に組み入れることである。従って、本発明は、ルータに容易に組み込まれ得る。
【００８０】
上記デバイスの各々への本発明の具体的な組み込みは、実現例に固有のものである。
【００８１】
本発明はまた、ネットワーク接続のエンドポイントであるコンピュータシステム内で適用され得る。この場合、本発明を実現するためにアドオンカードが使用され得、従って、アドオンカードは、コンピュータシステム内の主要な処理エレメントの負荷を取り除き得る。
【００８２】
（結論）
以上の好適な実施形態の説明は、任意の当業者が本発明を作製または使用することを可能にするために提供される。これらの実施形態の様々な改変例が当業者に容易に明らかとなり、本明細書において規定された一般原理は、発明力を用いずに、その他の実施形態に適用され得る。従って、本発明は、本明細書に示された実施形態に限定されるものではなく、本発明には、本明細書に開示された原理および新規な特徴と一致する最も広い範囲が与えられるものとする。
【図面の簡単な説明】
【図１】  インターネットに接続された複数のクライアントおよびサーバを示すネットワークブロック図である。
【図２】  本発明の好適な実施形態に従うインターフェイスユニットについてのネットワークコンテクストの図である。
【図３】  好適な実施形態に従う本発明の接続プーリング局面の動作を示すフローチャートである。
【図４】  接続マルチプレクシングを達成するために、クライアントおよびサーバの要求を変換する際の、本発明の動作を示すフローチャートである。
【図５】  好適な実施形態に従う本発明の接続プーリング局面を示すメッセージフロー図である。
【図６Ａ】  図５の例において、好適な実施形態に従う本発明によって実施される承認番号およびシーケンス番号の変換を示す詳細なフロー図である。
【図６Ｂ】  図５の例において、好適な実施形態に従う本発明によって実施される承認番号およびシーケンス番号の変換を示す詳細なフロー図である。
【図７】  好適な実施形態に従う本発明の接続分散特徴の動作を示すフローチャートである。
【図８】  好適な実施形態に従う本発明の接続分散局面を示すメッセージフロー図である。
【図９】  図８の例において、好適な実施形態に従う本発明によって実施される承認番号およびシーケンス番号の変換を示す詳細なフロー図である。
【図１０】  本発明が実行され得るコンピュータシステムの例を示す。
【図１】
0004312962.tif 000002
【図２】
0004312962.tif 000003
【図３】
0004312962.tif 000004
【図４】
0004312962.tif 000005
【図５】
0004312962.tif 000006
【図６Ａ】
0004312962.tif 000007
【図６Ｂ】
0004312962.tif 000008
【図７】
0004312962.tif 000009
【図８】
0004312962.tif 000010
【図９】
0004312962.tif 000011
【図１０】
0004312962.tif 000012