JP4208556B2 - 中継装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、クライアントとサーバ間の情報の一貫性を保つ技術（例えばＣｏｏｋｉｅ）を用いた情報通信において、クライアントとサーバとの間に位置し、データの中継を行う中継装置に関する。
【０００２】
【従来の技術】
現在のインターネットは、ＩＰ(Internet Protocol)網の上に構築されている。このＩＰ網上では、サーバとクライアントとの間の通信は、ＩＰパケット（以下、「パケット」と呼ぶ）というデータ単位で実行される。ＩＰ網はベストエフォート型のネットワークであるため、データの到着は完全に保障されない。一般的に、現在のインターネットでは、このデータの到着の保障は、ＴＣＰ(Transport Control Protocol)により実行される。ＴＣＰは、ＩＰ網上の通信で交換されるデータがクライアントとサーバとの間で正しく送受信されていることを保障する。
【０００３】
また、近年、クライアントがサーバにリクエストメッセージを送信しサーバはそれに対するリプライメッセージをクライアントに送信するという通信形態（例えばＷｅｂの通信形態）において、クライアントとサーバ（例えばＷｅｂサーバ）との間における情報の一貫性を保つ技術が用いられている。以下、リクエストメッセージ及びリプライメッセージを、それぞれを区別する必要がない場合は、単に「メッセージ」と呼ぶ。また、メッセージとは、ＨＴＴＰ(Hypertext Transfer Protocol)のレイヤにおけるデータの単位を指す。ＴＣＰによりメッセージが送信される場合、各メッセージは、パケットの最大長を超えない範囲で分割されることによりパケット化され、パケット単位で転送される。
【０００４】
このような、ＨＴＴＰというアプリケーションレイヤの通信においてクライアントとサーバとの間における情報の一貫性を保つ技術（情報共有の技術）の具体例として、Ｃｏｏｋｉｅという技術がある。この技術では、メッセージ中の特定の情報要素が使用される。Ｃｏｏｋｉｅは、サーバ（例えばＷｅｂサーバ）がコンテンツを含むリプライメッセージをクライアントへ送信する際に一般的に利用されているＨＴＴＰにおける技術の一つである。
【０００５】
クライアントとサーバとの間における通信では、ＴＣＰコネクションは通信のたびに切断と接続とが繰り返し実行される。このため、クライアントとサーバとの間でアプリケーションレイヤでの情報の一貫性が保たれない。しかし、Ｃｏｏｋｉｅが用いられることにより、ＴＣＰコネクションの切断や接続とは関係なく、アプリケーションレイヤで情報の一貫性が保たれる。
【０００６】
例えば、クライアントのユーザがサーバによって提供されるサイト内で買い物を行う場合、クライアントのユーザが何をいくつ購入したかという情報を、クライアントとサーバとの間で共有しなければならない。即ち、この情報はクライアントとサーバとの間で一貫性が保たれなくてはならない。
【０００７】
図２７は、クライアントＰ１と買い物サイトを運営するサーバＰ２との間で、Ｃｏｏｋｉｅが用いられた場合の通信処理の例を示す図である。サーバＰ２の買い物サイトでは、仮想的な買い物かごが設けられる。ユーザは、購入を希望する商品をこの買い物かごに入れる。この動作により、最終的に、全ての購入商品の支払手続がまとめて実行される。
【０００８】
クライアントＰ１のユーザがクライアントＰ１を用いて買い物ページのリンクをクリックすると、クライアントＰ１は、買い物用ページのデータを要求するリクエストメッセージをサーバＰ２へ送信する（ＰＳｅｑ１）。サーバＰ２は、このリクエストメッセージに対応する買い物用ページのデータをクライアントＰ１へ送信する（ＰＳｅｑ２）。
【０００９】
クライアントＰ１は、受信された買い物用ページのデータを、ディスプレイ等を通じて表示する。クライアントＰ１のユーザは、表示された買い物用ページを閲覧し、購入を希望する商品（例えば服や電気機器）を買い物かごへ入れるためのボタンをクリックする。クライアントＰ１は、買い物用ページにおいて、ユーザによって選択された商品を買い物かごへ入れたことを通知するためのリクエストメッセージをサーバＰ２へ送信する（ＰＳｅｑ３）。
【００１０】
サーバＰ２は、クライアントＰ１に対応するＩＤとして”Ａ”を発行する。サーバＰ２は、このＩＤと、クライアントＰ１から通知された商品（買い物かごへ入れられた商品）とを対応付けて記憶する。ここでは、服が買い物かごに入れられたと仮定する。そして、サーバＰ２は、この商品が買い物かごに入れられている場合の買い物用ページのデータを、クライアントＰ１へ送信する（ＰＳｅｑ４）。このとき、サーバＰ２は、発行されたＩＤ等の情報を、Ｃｏｏｋｉｅ情報としてクライアントＰ１に送信する。
【００１１】
クライアントＰ１は、サーバＰ２からＣｏｏｋｉｅ情報を通知された後は、リクエストメッセージをサーバＰ２へ送信する際に、サーバＰ２から通知されたＣｏｏｋｉｅ情報をリクエストメッセージに付加する。即ち、クライアントＰ１は、自身に発行されたＣｏｏｋｉｅ情報をリクエストメッセージに付加してサーバＰ２へ送信することにより、買い物サイトにアクセスする（ＰＳｅｑ５）。
【００１２】
サーバＰ２は、リクエストメッセージに付加されたＣｏｏｋｉｅ情報（ＩＤ等の情報）を基に、クライアントＰ１のユーザが買い物かごに入れている商品を検索する。即ち、サーバＰ２は、ＩＤ”Ａ”をもとに、クライアントＰ１のユーザの買い物かごの中身を確認する。そして、サーバＰ２は、クライアントＰ１のユーザが買い物かごに入れている商品などを反映した買い物用ページを作成し、この買い物用ページのデータをクライアントＰ１へ送信する（ＰＳｅｑ６）。
【００１３】
買い物の途中でＴＣＰコネクションが切断された後に再度接続された場合であっても、クライアントＰ１は、サーバＰ２に対するリクエストメッセージに、通知されたＣｏｏｋｉｅ情報を付加してサーバＰ２へ送信する。サーバＰ２は、Ｃｏｏｋｉｅ情報に含まれるＩＤと買い物かごの内容とを対応付けて記憶している。このため、Ｃｏｏｋｉｅ情報によって、アプリケーションレイヤの情報は、サーバＰ２とクライアントＰ１との間で一貫性が保たれる。即ち、この買い物サイトにおいては、買い物かごの内容は、サーバＰ２とクライアントＰ１との間で常に、ＴＣＰコネクションの切断や接続に関係なく一致される。
【００１４】
図２８は、クライアントＰ１とサーバＰ２との間でＣｏｏｋｉｅが用いられた場合の通信手順の概要を示す図である。次に、図２８を用いて、Ｃｏｏｋｉｅが用いられた場合の通信手順の概要を説明する。
【００１５】
サーバＰ２とクライアントＰ１との間の通信においてＣｏｏｋｉｅが利用される場合、通信手順として以下の３つの手順が実行される。まず、サーバＰ２は、Ｃｏｏｋｉｅ情報を発行し、このＣｏｏｋｉｅ情報が付加されたリプライメッセージをクライアントＰ１へ送信する（第一の通信手順）。次に、クライアントＰ１は、リプライメッセージを受信し、このリプライメッセージに付加されたＣｏｏｋｉｅ情報を、自身が記憶するローカルのＣｏｏｋｉｅ表に記録する（第二の通信手順）。以後、クライアントＰ１は、サーバＰ２に対するリクエストメッセージに対して、Ｃｏｏｋｉｅ表に記録されたＣｏｏｋｉｅ情報を付加し、このリクエストメッセージをサーバＰ２へ送信する（第三の通信手順）。次に、各通信手順について詳しく説明する。
【００１６】
第一の通信手順では、サーバＰ２は、クライアントＰ１に対して送信されるリプライメッセージのＨＴＴＰヘッダにＳｅｔ−Ｃｏｏｋｉｅコマンドを記入（付加）する。サーバＰ２は、リプライメッセージのＨＴＴＰヘッダにＳｅｔ−Ｃｏｏｋｉｅコマンドを付加することにより、Ｃｏｏｋｉｅ情報をリプライメッセージに付加する。Netscape Communications社の仕様では、Ｓｅｔ−Ｃｏｏｋｉｅコマンドの書式は以下の通りである。
【００１７】
Ｓｅｔ−Ｃｏｏｋｉｅ：ＮＡＭＥ＝ＶＡＬＵＥ；ｅｘｐｉｒｅｓ＝ＤＡＴＥ；ｐａｔｈ＝ＰＡＴＨ；ｄｏｍａｉｎ＝ＤＯＭＡＩＮ＿ＮＡＭＥ；ｓｅｃｕｒｅ
Ｓｅｔ−Ｃｏｏｋｉｅコマンドの書式において、サーバＰ２がＣｏｏｋｉｅ情報毎に違う値を記入する項目（フィールド）は、ＮＡＭＥ，ＶＡＬＵＥ，ＤＡＴＥ，ＰＡＴＨ，ＤＯＭＡＩＮ＿ＮＡＭＥである。
【００１８】
ＮＡＭＥ，ＶＡＬＵＥフィールドは、このＣｏｏｋｉｅ情報の実体を示す。サーバＰ２は、ＮＡＭＥフィールドにはＣｏｏｋｉｅ情報の名前を、ＶＡＬＵＥフィールドにはＣｏｏｋｉｅ情報に代入される値をそれぞれ設定する。サーバＰ２によって発行される上記ＩＤは、ＶＡＬＵＥフィールドの値（ＶＡＬＵＥ値）に相当する。例えば、ＮＡＭＥフィールドの値（ＮＡＭＥ値）が”ＩＤ”である場合、ＶＡＬＵＥ値にはＩＤの具体的な文字列や数字など（例えば”Ａ”）が設定される。
【００１９】
ｅｘｐｉｒｅフィールド以降のフィールドは、Ｃｏｏｋｉｅ情報に対する属性を示すフィールド、即ちオプションのフィールドである。以下、ｅｘｐｉｒｅフィールド以降の各フィールドについて説明する。
【００２０】
ＤＡＴＥフィールドはＣｏｏｋｉｅ情報の有効期限を示す。クライアントＰ１は、ＤＡＴＥフィールドの値（ＤＡＴＥ値）が示す日時を過ぎたＣｏｏｋｉｅ情報を、ローカルのＣｏｏｋｉｅ表から消去する。ＤＡＴＥ値が無い場合、クライアントＰ１は、このＣｏｏｋｉｅ情報を扱っているブラウザが終了した時点で、このＣｏｏｋｉｅ情報をローカルのＣｏｏｋｉｅ表から消去する。
【００２１】
ＰＡＴＨ，ＤＯＭＡＩＮ#ＮＡＭＥフィールドは、クライアントＰ１がＣｏｏｋｉｅ情報を付加する対象となるリクエストメッセージを特定するために利用される。ＤＯＭＡＩＮ＿ＮＡＭＥフィールドは、Ｃｏｏｋｉｅ情報が付加されるリクエストメッセージの送信先となるドメイン名を示す。ＰＡＴＨフィールドは、ドメイン名によって示されるホストにおけるロケーションを示す。例えば、Ｃｏｏｋｉｅ情報が付加されるリクエストメッセージが、”ｗｗｗ．ｘｘｘ．ｚｚｚ／ｃｏｎｔｅｎｔｓ／”というアドレスへのコンテンツ要求である場合、”ｗｗｗ．ｘｘｘ．ｚｚｚ”がＤＯＭＡＩＮ＿ＮＡＭＥフィールドの値（ＤＯＭＡＩＮ＿ＮＡＭＥ値）、”／ｃｏｎｔｅｎｔｓ／”がＰＡＴＨフィールドの値（ＰＡＴＨ値）に相当する。
【００２２】
第二の通信手順では、クライアントＰ１は、Ｓｅｔ−Ｃｏｏｋｉｅコマンドを含むリプライメッセージをサーバＰ２から受信する。そして、クライアントＰ１は、ローカルのＣｏｏｋｉｅ表に、リプライメッセージに含まれるＣｏｏｋｉｅ情報を逐次記録する。
【００２３】
図２９は、ローカルのＣｏｏｋｉｅ表の例を示す図である。図２９を用いてローカルのＣｏｏｋｉｅ表について説明する。
【００２４】
ローカルのＣｏｏｋｉｅ表のＤＯＭＡＩＮ＿ＮＡＭＥ，ＰＡＴＨ，ＮＡＭＥ，ＶＡＬＵＥには、受信されたＳｅｔ−Ｃｏｏｋｉｅコマンドにおける各値が記録される。また、ローカルのＣｏｏｋｉｅ表のＧＭＴ（Greenwich Mean Time）には、受信されたＳｅｔ−ＣｏｏｋｉｅコマンドにおけるＤＡＴＥ値が記録される。第三の通信手順では、クライアントＰ１は、リクエストメッセージを送信する際に、送信先のドメイン名（ＤＯＭＡＩＮ＿ＮＡＭＥ値）及びパス（ＰＡＴＨ値）に対応するＣｏｏｋｉｅ情報の有無を、ローカルのＣｏｏｋｉｅ表において確認する。対応するＣｏｏｋｉｅ情報が記録されている場合、クライアントＰ１は、このＣｏｏｋｉｅ情報をこのリクエストメッセージに付加する。一方、対応するＣｏｏｋｉｅ情報が無い場合、クライアントＰ１は、Ｃｏｏｋｉｅ情報の付加を実行しない。
【００２５】
図３０は、Ｓｅｔ−Ｃｏｏｋｉｅコマンドの各フィールドについてのクライアントＰ１とサーバＰ２との処理を示す図である。図３０を用いて、Ｓｅｔ−Ｃｏｏｋｉｅコマンドの各フィールドについてのクライアントＰ１とサーバＰ２との処理について説明する。
【００２６】
サーバＰ２は、Ｃｏｏｋｉｅ情報を発行する際に、ＤＯＭＡＩＮ＿ＮＡＭＥフィールドやＰＡＴＨフィールド等に値を代入し、Ｓｅｔ−Ｃｏｏｋｉｅコマンドをリプライメッセージに付加する。
【００２７】
クライアントＰ１は、ローカルのＣｏｏｋｉｅ表において、受信されたＳｅｔ−Ｃｏｏｋｉｅコマンドの各フィールドの値、即ち受信されたＣｏｏｋｉｅ情報とＮＡＭＥ値，ＤＯＭＡＩＮ＿ＮＡＭＥ値，及びＰＡＴＨ値が同一であるＣｏｏｋｉｅ情報を検索する。このとき、受信されたＣｏｏｋｉｅ情報にＤＯＭＡＩＮ＿ＮＡＭＥ値が定義されていない場合、クライアントＰ１は、受信されたＣｏｏｋｉｅ情報のＤＯＭＡＩＮ＿ＮＡＭＥ値として、このＣｏｏｋｉｅ情報を発行したサーバＰ２のドメイン名を用いる。また、受信されたＣｏｏｋｉｅ情報にＰＡＴＨ値が定義されていない場合、クライアントＰ１は、受信されたＣｏｏｋｉｅ情報のＰＡＴＨ値として、Ｓｅｔ−Ｃｏｏｋｉｅコマンドの発行元となるロケーションを用いる。
【００２８】
該当するＣｏｏｋｉｅ情報が検索された場合、クライアントＰ１は、検索されたＣｏｏｋｉｅ情報のＶＡＬＵＥ値，ＰＡＴＨ値，ＤＯＭＡＩＮ＿ＮＡＭＥ値，及びＤＡＴＥ値を、受信されたＣｏｏｋｉｅ情報を用いて上書きする。
【００２９】
一方、該当するＣｏｏｋｉｅ情報が検索されない場合、クライアントＰ１は、受信されたＣｏｏｋｉｅ情報を、ローカルのＣｏｏｋｉｅ表に記録する。このとき、受信されたＳｅｔ−ＣｏｏｋｉｅコマンドにＤＯＭＡＩＮ＿ＮＡＭＥ値が定義されていない場合、クライアントＰ１は、ＤＯＭＡＩＮ＿ＮＡＭＥ値として、このＣｏｏｋｉｅ情報を発行したサーバＰ２のドメイン名を記録する。また、受信されたＳｅｔ−ＣｏｏｋｉｅコマンドにＰＡＴＨの値が定義されていない場合、クライアントＰ１は、ＰＡＴＨの値として、Ｓｅｔ−Ｃｏｏｋｉｅコマンドの発行元となるロケーションを記録する。
【００３０】
クライアントＰ１は、リクエストメッセージを送信する際に、ローカルのＣｏｏｋｉｅ表を検索し、送信されるリクエストメッセージに付加されるべきＣｏｏｋｉｅ情報の有無を確認する。具体的には、クライアントＰ１は、リクエストメッセージの送信先となるＵＲＬ（Uniform Resource Locators）をキーとして、ローカルのＣｏｏｋｉｅ表に記録される全てのＣｏｏｋｉｅ情報について、ＰＡＴＨ値及びＤＯＭＡＩＮ＿ＮＡＭＥ値を検索する。
【００３１】
クライアントＰ１は、リクエストメッセージの送信先について、ＤｏｍａｉｎとＰａｔｈの両方が一致したときのみＣｏｏｋｉｅ表に記録されているＣｏｏｋｉｅ情報を読み出す。例えば、クライアントＰ１は、リクエストメッセージの送信先が、ローカルのＣｏｏｋｉｅ表に記録されるＤＯＭＡＩＮ＿ＮＡＭＥ値と後方一致するドメインであり、且つローカルのＣｏｏｋｉｅ表に記録されるＰＡＴＨの値で指定されたロケーションと前方一致するアドレスである場合、Ｃｏｏｋｉｅ表に記録されるＣｏｏｋｉｅ情報を読み出す。このとき、クライアントＰ１は、このＤＯＭＡＩＮ＿ＮＡＭＥ値及びＰＡＴＨ値に対応付けてＣｏｏｋｉｅ表に記録されるＣｏｏｋｉｅ情報を読み出す。
【００３２】
そして、クライアントＰ１は、読み出された全てのＣｏｏｋｉｅ情報を、リクエストメッセージのＨＴＴＰヘッダに記入し、このリクエストメッセージをサーバＰ２に送信する。リクエストメッセージのＨＴＴＰヘッダにおけるＣｏｏｋｉｅ情報の書式を以下に示す。
【００３３】
Ｃｏｏｋｉｅ： ＮＡＭＥ１＝ＶＡＬＵＥ１； ＮＡＭＥ２＝ＶＡＬＵＥ２；・・・
上記記載は、Netscape Communications社による仕様であるが、ＲＦＣ（Request For Comments）等の他の仕様を用いても良い。
【００３４】
次に、Ｃｏｏｋｉｅに基づいたサーバ負荷分散について説明する。近年、インターネットの利用者数の増大により、人気のあるコンテンツを公開しているサーバに対し、ＨＴＴＰのリクエストの集中が発生している。このようなサーバは、多くのリクエストメッセージに対して応答処理を行う必要があるため、ＣＰＵ負荷が上昇し処理能力が不足するという問題がある。
【００３５】
このような問題の対処方法として、負荷分散装置を用いる方法がある。図３１は、負荷分散装置Ｐ３が用いられたシステム（負荷分散システム）Ｐ５の概要を示す図である。図３１を用いて、負荷分散システムＰ５について説明する。
【００３６】
負荷分散システムＰ５は、複数台のサーバＰ２からなるサーバグループＰ４，１台以上のクライアントＰ１，及びクライアントＰ１とサーバグループＰ４との間に設置される負荷分散装置Ｐ３を用いて構成される。
【００３７】
負荷分散システムＰ５では、負荷分散装置Ｐ３は、サーバグループ単位に仮想的な代表アドレス（ＶＩＰ：Virtual IP address）を設定する。クライアントＰ１は、ＶＩＰ宛にリクエストメッセージを送信する。負荷分散装置Ｐ３は、ＶＩＰ宛に送信されたリクエストメッセージを受信し、受信されたリクエストメッセージを基に、リクエストメッセージの振り分け先となるサーバＰ２を、サーバグループＰ４に含まれる複数のサーバＰ２の中から決定する。そして、負荷分散装置Ｐ３は、振り分け先として決定されたサーバＰ２に、受信されたリクエストメッセージを転送する。このとき、負荷分散装置Ｐ３は、転送対象となるリクエストメッセージの送信先のアドレスを、ＶＩＰからサーバＰ２のアドレスに書き換える。
【００３８】
負荷分散システムＰ５では、負荷分散装置Ｐ３がクライアントＰ１からのリクエストメッセージを各サーバＰ２へ振り分ける。このため、応答処理の負荷が複数台のサーバＰ２に分散され、一台のサーバＰ２が担当する処理負荷が軽減される。
【００３９】
このような負荷分散システムＰ５において、Ｃｏｏｋｉｅ情報が用いられた場合、以下のような問題が発生する。負荷分散装置Ｐ３は、リクエストメッセージに付加されたＣｏｏｋｉｅ情報を考慮せずに振り分け先のサーバＰ２を決定する場合、このＣｏｏｋｉｅ情報を発行したサーバＰ２とは異なるサーバＰ２に対してこのリクエストメッセージを転送（中継）する可能性がある。この場合、リクエストメッセージを受信したサーバＰ２は、受信されたリクエストメッセージに含まれるＣｏｏｋｉｅ情報を認識できない。このため、リクエストメッセージを受信したサーバＰ２は、クライアントＰ１のユーザによる買い物の履歴が反映されていないページを作成しクライアントＰ１へ送信するという問題が発生する。
【００４０】
このような問題を解決する方法として、負荷分散装置がリクエストメッセージに付加されたＣｏｏｋｉｅ情報に基づいて、振り分け先となるサーバを決定する方法がある。図３２は、リクエストメッセージに付加されたＣｏｏｋｉｅ情報に基づいて振り分け先となるサーバＰ２を決定する負荷分散装置Ｐ３ａの機能ブロック図である。図３２を用いて、このような負荷分散装置Ｐ３ａについて説明する。
【００４１】
負荷分散装置Ｐ３ａは、Ｃｏｏｋｉｅ検出部Ｐ６，振り分け先サーバ決定部Ｐ７，サーバ・Ｃｏｏｋｉｅ用テーブルＰ８，ヘッダ更新・パケット送信部Ｐ９，Ｃｏｏｋｉｅ検出部Ｐ１０，Ｃｏｏｋｉｅ・サーバ記録部Ｐ１１，及びヘッダ更新・パケット送信部Ｐ１２を備える。
【００４２】
まず、クライアントＰ１が対応するＣｏｏｋｉｅ情報をローカルのＣｏｏｋｉｅ表に記録していないコンテンツへアクセスする場合の負荷分散装置Ｐ３ａの処理について説明する。
【００４３】
クライアントＰ１は、アクセス先に対応するＣｏｏｋｉｅ情報がローカルのＣｏｏｋｉｅ表に記録されていないため、Ｃｏｏｋｉｅ情報が付加されていないリクエストメッセージをＶＩＰ宛に送信する。Ｃｏｏｋｉｅ検出部Ｐ６は、ＶＩＰ宛に送信されたリクエストメッセージを受信する。Ｃｏｏｋｉｅ検出部Ｐ６は、受信されたリクエストメッセージについて文字列検索を行い、Ｃｏｏｋｉｅ情報の有無を調べる。この場合、リクエストメッセージにＣｏｏｋｉｅ情報は付加されていないため、Ｃｏｏｋｉｅ検出部Ｐ６はＣｏｏｋｉｅ情報が無いと判断する。このため、負荷分散装置Ｐ３ａは、Ｃｏｏｋｉｅ情報が無い場合の処理を実行する。即ち、振り分け先サーバ決定部Ｐ７は、Ｃｏｏｋｉｅ情報を考慮せずに、振り分け先となるサーバＰ２を決定する。このようなサーバＰ２の決定法には、例えばラウンドロビン等がある。
【００４４】
次に、ヘッダ更新・パケット送信部Ｐ９は、決定されたサーバＰ２へリクエストメッセージを転送するため、サーバＰ２との間にＴＣＰコネクションを作成する。ただし、既にサーバＰ２との間にＴＣＰコネクションがある場合、ヘッダ更新・パケット送信部Ｐ９は、このＴＣＰコネクションを利用するため、新たなＴＣＰコネクションを作成しなくともよい。ヘッダ更新・パケット送信部Ｐ９は、決定されたサーバＰ２のアドレスなどをもとに、転送されるリクエストメッセージを含むパケットのヘッダ部分の生成又は書き換えを実行する。そして、ヘッダ更新・パケット送信部Ｐ９は、決定されたサーバＰ２に対し、リクエストメッセージを転送する。即ち、ヘッダ更新・パケット送信部Ｐ９は、リクエストメッセージを含むパケットを転送する。
【００４５】
サーバＰ２は、リクエストメッセージを受信し、受信されたリクエストメッセージに対するリプライメッセージを送信する。
【００４６】
Ｃｏｏｋｉｅ検出部Ｐ１０は、サーバＰ２からリプライメッセージを受信する。Ｃｏｏｋｉｅ検出部Ｐ１０は、受信されたリプライメッセージに対して文字列検索を実行し、Ｃｏｏｋｉｅ情報の有無を調べる。この場合、リプライメッセージにＣｏｏｋｉｅ情報が付加されているため、Ｃｏｏｋｉｅ検出部Ｐ６はＣｏｏｋｉｅ情報を抽出する。このため、負荷分散装置Ｐ３ａは、Ｃｏｏｋｉｅ情報が有る場合の処理を実行する。即ち、Ｃｏｏｋｉｅ・サーバ記録部Ｐ１１は、このＣｏｏｋｉｅ情報及びこのＣｏｏｋｉｅ情報の発行元であるサーバを対応付けて、サーバ・Ｃｏｏｋｉｅ用テーブルＰ８に記録する。ヘッダ更新・パケット送信部Ｐ１２は、このリプライメッセージを含むパケットのヘッダ部分の生成又は書き換えを実行する。そして、ヘッダ更新・パケット送信部Ｐ１２は、クライアントＰ１に、このリプライメッセージを含むパケットを転送する。
【００４７】
次に、クライアントＰ１が対応するＣｏｏｋｉｅ情報をローカルのＣｏｏｋｉｅ表に記録しているコンテンツへアクセスする場合の負荷分散装置Ｐ３ａの処理について説明する。
【００４８】
クライアントＰ１は、アクセス先に対応するＣｏｏｋｉｅ情報がローカルのＣｏｏｋｉｅ表に記録されているため、このＣｏｏｋｉｅ情報が付加されたリクエストメッセージをＶＩＰ宛に送信する。Ｃｏｏｋｉｅ検出部Ｐ６は、ＶＩＰ宛に送信されたリクエストメッセージを受信する。Ｃｏｏｋｉｅ検出部Ｐ６は、受信されたリクエストメッセージについて文字列検索を行い、Ｃｏｏｋｉｅ情報の有無を調べる。この場合、リクエストメッセージにＣｏｏｋｉｅ情報が付加されているため、Ｃｏｏｋｉｅ検出部Ｐ６はこのＣｏｏｋｉｅ情報を抽出する。このため、負荷分散装置Ｐ３ａは、Ｃｏｏｋｉｅ情報が有る場合の処理を実行する。即ち、振り分け先サーバ決定部Ｐ７は、リクエストメッセージに含まれるＣｏｏｋｉｅ情報とサーバ・Ｃｏｏｋｉｅ用テーブルＰ８とを参照することにより、このＣｏｏｋｉｅ情報の発行元であるサーバＰ２を特定する。
【００４９】
次に、ヘッダ更新・パケット送信部Ｐ９は、決定されたサーバＰ２へパケットを転送するため、サーバＰ２との間にＴＣＰコネクションを作成する。ただし、既にサーバＰ２との間にＴＣＰコネクションがある場合、ヘッダ更新・パケット送信部Ｐ９は、このＴＣＰコネクションを利用するため、新たなＴＣＰコネクションを作成しなくともよい。ヘッダ更新・パケット送信部Ｐ９は、決定されたサーバＰ２のアドレスなどをもとに、転送されるリクエストメッセージを含むパケットのヘッダ部分の生成又は書き換えを実行する。そして、ヘッダ更新・パケット送信部Ｐ９は、決定されたサーバＰ２に対し、リクエストメッセージを含むパケットを転送する。
【００５０】
負荷分散装置Ｐ３ａは、このように動作することによって、リクエストメッセージに含まれるＣｏｏｋｉｅ情報の発行元であるサーバＰ２を検索し、このサーバＰ２をリクエストメッセージの振り分け先として決定する。
【００５１】
次に、サーバ・Ｃｏｏｋｉｅ用テーブルＰ８の構成における問題点について説明する。サーバ・Ｃｏｏｋｉｅ用テーブルＰ８が、サーバＰ２（図３３におけるＰ２ａ〜Ｐ２ｃ）のアドレス（ＩＰアドレス，ＭＡＣアドレスなど）とＣｏｏｋｉｅ情報とを対応付けて記録すると問題が生じる。図３３は、この問題の例を示す図である。即ち、複数のサーバＰ２ａとＰ２ｂとが、それぞれ異なるクライアントＰ１ａ，Ｐ１ｂに対して同一のＣｏｏｋｉｅ情報αを発行した場合に問題が生じる。この場合、負荷分散装置Ｐ３ａは、クライアントＰ１ａ又はＰ１ｂから送信されるリクエストメッセージについて、このリクエストメッセージに含まれるＣｏｏｋｉｅ情報のみによって振り分け先となるサーバを判断することができない。なぜなら、サーバ・Ｃｏｏｋｉｅ用テーブルＰ８は、同じＣｏｏｋｉｅ情報（α）について、複数のサーバＰ２のアドレス（サーバＰ２ａ，サーバＰ２ｂ）を記録しているためである。
【００５２】
このような問題を解決する方法として、サーバ・Ｃｏｏｋｉｅ用テーブルＰ８が、サーバＰ２のアドレスと、Ｃｏｏｋｉｅ情報及びクライアントＰ１（図３３におけるＰ１ａ〜Ｐ１ｃ）のＩＰアドレスとを対応付けて記録する方法がある。しかし、クライアントＰ１のＩＰアドレスが変更される場合がある（例えば、クライアントＰ１がダイヤルアップ回線などによる接続である場合）。この場合、負荷分散装置Ｐ３ａは、正しい振り分け先となるサーバＰ２を判断することができない。
【００５３】
従来、この問題を解決する方法として、Ｃｏｏｋｉｅ情報にサーバＰ２を一意に示すＩＤを付与する方法がある（第一の解決方法，第二の解決方法，第三の解決方法）。次に、３種類の方法について、負荷分散装置Ｐ３ａを用いた方法と異なる点についてのみ、それぞれ説明する。
【００５４】
図３４は、第一の解決方法を示す図である。第一の解決方法では、負荷分散装置Ｐ３ｂは、サーバＰ２からクライアントＰ１に送信されるリプライメッセージがＣｏｏｋｉｅ情報を含む場合、このリプライメッセージにサーバＰ２を一意に示すＩＤ（サーバＩＤ）を含む新たなＣｏｏｋｉｅ情報を挿入する（例えば、非特許文献１の”インサート・モード”参照）。
【００５５】
まず、リプライメッセージに対する処理について説明する。メッセージ構築部Ｐ１３が、サーバＰ２から受信されたパケットをもとにリプライメッセージを構築する。Ｃｏｏｋｉｅ生成部Ｐ１４は、サーバＰ２を示すサーバＩＤを含む新たなＣｏｏｋｉｅ情報を生成する。具体的には、ＮＡＭＥ値は、サーバＰ２により保持されるコンテンツの中で利用されていないＮＡＭＥ値であり、ＶＡＬＵＥ値は、サーバＩＤを示す。また、ＤＡＴＥ値，ＰＡＴＨ値，ＤＯＭＡＩＮ＿ＮＡＭＥ値は、サーバＰ２によって発行されたＣｏｏｋｉｅ情報と同じ値を持つ。
【００５６】
Ｃｏｏｋｉｅ挿入部Ｐ１５は、Ｃｏｏｋｉｅ生成部Ｐ１４によって生成されたＣｏｏｋｉｅ情報を、メッセージ構築部Ｐ１３によって構築されたリプライメッセージに挿入する。Ｃｏｏｋｉｅ・サーバ記録部Ｐ１１ｂは、Ｃｏｏｋｉｅ生成部Ｐ１４によって生成されたＣｏｏｋｉｅ情報とサーバＰ２とを対応付けてサーバ・Ｃｏｏｋｉｅ用テーブルＰ８ｂに記録する。例えば、Ｃｏｏｋｉｅ・サーバ記録部Ｐ１１ｂは、新たなＣｏｏｋｉｅ情報とサーバＰ２のアドレスとを対応付けて記録する。そして、メッセージ分割部Ｐ１６が、このリプライメッセージを再びパケットに分割する。
【００５７】
次に、リクエストメッセージに対する処理について説明する。振り分け先サーバ決定部Ｐ７は、クライアントＰ１から送信されるリクエストメッセージに含まれるＣｏｏｋｉｅ情報（このＣｏｏｋｉｅ情報はサーバＰ２を一意に示すサーバＩＤを含む）及びサーバ・Ｃｏｏｋｉｅ用テーブルＰ８をもとに、振り分け先となるサーバＰ２を決定する。
【００５８】
図３５は、第二の解決方法を示す図である。まず、リプライメッセージに対する処理について説明する。第二の解決方法では、負荷分散装置Ｐ３ｃのみならず、サーバＰ２も新たな設定がなされる（例えば、非特許文献１の”リライト・モード”参照）。具体的には、サーバＰ２は、自身が備えるコンテンツの中で利用されていないＮＡＭＥ値と、特に意味を持たないＶＡＬＵＥ値（例：”００００００００”）とを含むＣｏｏｋｉｅ情報（第一Ｃｏｏｋｉｅ情報）を発行するように設定される。また、サーバＰ２は、このような意味を持たないＣｏｏｋｉｅ情報の他に、クライアントＰ１等において実際に利用されるＣｏｏｋｉｅ情報（第二Ｃｏｏｋｉｅ情報）も発行する。このとき、第一のＣｏｏｋｉｅ情報におけるＤＡＴＥ値は、第二Ｃｏｏｋｉｅ情報のうち最も長い有効期限と同一の値である。また、第一のＣｏｏｋｉｅ情報におけるＰＡＴＨ値及びＤＯＭＡＩＮ＿ＮＡＭＥ値は、第二Ｃｏｏｋｉｅ情報における値と同じである。
【００５９】
負荷分散装置Ｐ３ｃは、サーバＰ２からクライアントＰ１に送信されるリプライメッセージが第一Ｃｏｏｋｉｅ情報を含む場合、この第一Ｃｏｏｋｉｅ情報のＶＡＬＵＥ値に、サーバＩＤを上書きする。
【００６０】
具体的には、Ｃｏｏｋｉｅ生成部Ｐ１４ｃは、サーバＰ２を一意に示すサーバＩＤを生成する。Ｃｏｏｋｉｅ上書き部Ｐ１７は、生成されたサーバＩＤを用いて第一Ｃｏｏｋｉｅ情報のＶＡＬＵＥ値を上書きする。Ｃｏｏｋｉｅ・サーバ記録部Ｐ１１ｃは、生成されたサーバＩＤとサーバＰ２とを対応付けてサーバ・Ｃｏｏｋｉｅ用テーブルＰ８ｃに記録する。
【００６１】
次に、リクエストメッセージに対する処理について説明する。振り分け先サーバ決定部Ｐ７は、クライアントＰ１から送信されるリクエストメッセージに含まれるＣｏｏｋｉｅ情報（このＣｏｏｋｉｅ情報はサーバＰ２を一意に示すサーバＩＤを含む）及びサーバ・Ｃｏｏｋｉｅ用テーブルＰ８をもとに、振り分け先となるサーバＰ２を特定する。
【００６２】
次に第三の解決方法について説明する。第三の解決方法では、サーバＰ２ｄにおけるＣｏｏｋｉｅ情報の発行ルールが変更される（例えば、非特許文献１の”パッシブ・モード”参照）。具体的には、サーバＰ２ｄは、Ｃｏｏｋｉｅ情報を発行する際にサーバＰ２ｄを一意に示すサーバＩＤを含むＣｏｏｋｉｅ情報も同時に発行する。第三の解決方法において、サーバＩＤを含むＣｏｏｋｉｅ情報のＮＡＭＥ値は、サーバＰ２ｄにより保持されるコンテンツの中で利用されていないＮＡＭＥ値である。また、このＣｏｏｋｉｅ情報のＶＡＬＵＥ値は、サーバＰ２ｄを一意に示すサーバＩＤである。また、このＣｏｏｋｉｅ情報のＤＡＴＥ値は、同時に発行される他のＣｏｏｋｉｅ情報のうち最も長い有効期限の値と同一の値である。
【００６３】
第三の解決方法では、サーバＰ２ｄがＣｏｏｋｉｅ情報の内容を決定する。このため、第一の解決方法及び第二の解決方法とは異なり、負荷分散装置Ｐ３は、サーバＰ２ｄから送信されるリプライメッセージにおけるＣｏｏｋｉｅ情報を変更しない。従って、負荷分散装置Ｐ３の構成は、図３２に示される通りとなる。
【００６４】
また、このようにユーザ情報（Ｃｏｏｋｉｅ情報）を用いて端末装置を特定する技術として、特許文献１や特許文献２がある。
【００６５】
【特許文献１】
特開平１０−１６４１７３号公報
【特許文献２】
特開２００１−２３６３２０号公報
【非特許文献１】
”Ｆ５ ネットワークス社のＢＩＧ−ＩＰコントローラが提供するクッキー・パーシステンス”、［online］、F5 Networks、［平成１４年９月１２日検索］、インターネット＜URL : http://www.f5networks.co.jp/ja/solutions/technicalbriefs/tb01.html＞
【００６６】
【発明が解決しようとする課題】
しかしながら、第一，第二，第三の解決方法は、実際のネットワークに適用される際に問題点が発生する。まず、第二，第三の解決方法における問題点について説明する。第二，第三の解決方法では、負荷分散システムに応じて特定のＣｏｏｋｉｅ情報を発行するようにサーバＰ２の設定を行う必要がある。しかし、実際のネットワークでは、このような設定を行うことが困難な場合がある。
【００６７】
実際のネットワークは、ネットワーク部分のみを提供するネットワーク事業者（例：ＩＤＣ（Internet Data Center））と、サーバ・コンテンツを設置・作成するコンテンツ事業者とが分業して構成される場合がある。図３６は、このように構成されたネットワークの概略を示す図である。
【００６８】
一般的に、コンテンツ事業者は、負荷分散装置Ｐ３によってサーバ振り分けが実行されることを考慮せずにコンテンツを作成する。また、例えばコンテンツ事業者によるディスクスペースのレンタルサービスのように、コンテンツ事業者以外の第三者がコンテンツを作成する場合もある。このような場合、ネットワーク事業者は、負荷分散装置Ｐ３によってサーバ振り分けが正しく実行されるように、コンテンツ事業者の持つコンテンツを書き換える、又は書き換えることをコンテンツ事業者に依頼する必要がある。しかし、このような手続は、明らかに時間やコストの無駄となる。
【００６９】
従って、負荷分散装置Ｐ３は、連携するサーバＰ２におけるコンテンツの設定変更を要件とすることなく、正しくサーバ振り分けを実行できるように構成されることが好ましい。
【００７０】
次に、第一の解決方法が適用された場合における問題点について説明する。第一の解決方法では、サーバＰ２のコンテンツが設定変更される必要が無いため、上記問題は発生しない。しかし、第一の解決方法では、負荷分散装置Ｐ３ｂがリプライメッセージに新たなＣｏｏｋｉｅ情報を挿入するため、クライアントＰ１において受信されたリプライメッセージとサーバＰ２において送信されたリプライメッセージとのデータサイズが一致しない。このため、第一の解決方法では以下のような問題が生じる。
【００７１】
図３７は、第一の解決方法が適用された場合に生じる問題を示す図である。第一の解決方法では、ＴＣＰによるパケットロス等の検出において問題が発生する。ＴＣＰでは、サーバＰ２において送信されたパケットのサイズとクライアントＰ１において受信されたパケットのサイズとを用いてデータの到達が保障される。即ち、サーバＰ２から送信されたパケットのサイズとクライアントＰ１によって受信されたパケットのサイズとが一致した場合に、データが正常に到達したと判断される。
【００７２】
従って、このデータサイズが一致しない場合、ネットワーク中で発生するパケットロスなどの問題が検出されない可能性がある。例えば、サーバＰ２が１〜１３までのデータ（第一のデータ）をクライアントＰ１に送信し、その後まもなくサーバＰ２が１３〜１６までのデータ（第二のデータ）をクライアントＰ１に送信したとする。負荷分散装置Ｐ３ｂによって第一のデータのデータサイズが１３から１６へ変更された場合、クライアントＰ１は第一のデータのみを受信した時点で１〜１６までのデータを受信したと判断する。このとき、クライアントＰ１は、サーバＰ２に対し、１〜１６までのデータを受信したことを通知するため、サーバＰ２は１〜１６までのデータ送信が終了したと判断する。この後、第二のデータについてパケットロスが発生した場合、クライアントＰ１及びサーバＰ２のいずれも、このパケットロスを検出することがない。
【００７３】
このような理由により、負荷分散装置装置Ｐ３ｂは、パケットのサイズを変更する場合、エンドホストと同様にＴＣＰの処理を行う必要がある。即ち、負荷分散装置Ｐ３ｂは、サーバＰ２及びクライアントＰ１のＴＣＰコネクションを終端し、それぞれを仲介するエンドホストとして動作する必要がある。
【００７４】
図３８は、ＴＣＰの処理を行う負荷分散装置Ｐ３ｂが用いられたネットワークの構成を示す図である。負荷分散装置Ｐ３ｂは、１〜１３までのデータをサーバＰ２から受信した場合、１３まで受信したことをサーバＰ２へ通知する。また、負荷分散装置Ｐ３ｂは、受信されたデータに新たなＣｏｏｋｉｅ情報を挿入し、このデータをクライアントＰ１へ送信する。
【００７５】
しかし、負荷分散装置Ｐ３ｂがＴＣＰの処理を全て実行するように構成されると、負荷分散装置Ｐ３ｂにおいて通信負荷が増大し、負荷分散処理の低速化を招く。
【００７６】
また、第一の解決方法における負荷分散装置Ｐ３ｂは、メッセージの再構築及びパケットへの再分割を実行する。この処理は、通常の負荷分散処理には必要がない処理であり、結果的に負荷分散処理によるパケット転送速度の低下を招く。
【００７７】
このように、負荷分散処理を高速化するためには、サーバ側のコンテンツにおいて負荷分散装置を考慮した設定を不要とし、パケットのサイズを変更せずにＣｏｏｋｉｅ情報に基づいたサーバ振り分け処理を実行することが必要となる。
【００７８】
このため、本発明は、サーバ側のコンテンツにおいて特に設定を必要とせず、パケットのような通信データのサイズを変更せずに、Ｃｏｏｋｉｅ情報のようなデータに基づいたサーバ振り分け処理を実行する中継装置（負荷分散装置を含む）を提供することを目的とする。
【００７９】
【課題を解決するための手段】
上記問題を解決するため、本発明は以下のような構成をとる。本発明の第一の態様は、中継装置であって、第一のデータを含む通信データをサーバから受信する第一の受信手段と、前記サーバを一意に識別するサーバ識別子を生成する生成手段と、前記第一のデータの一部分である部分データであって、前記サーバ識別子と同じデータ量の部分データを、前記サーバ識別子に置き換えることにより第二のデータを生成する第一の置換手段と、前記部分データと前記サーバ識別子と前記第一のデータを含む通信データの送信元であるサーバとを対応付けたエントリを記憶するサーバ識別子記憶手段と、前記第二のデータを含む通信データをクライアントへ送信する第一の送信手段と、前記第二のデータを含む通信データをクライアントから受信する第二の受信手段と、前記通信データから前記第二のデータを読み出す読出手段と、前記第二のデータに含まれる前記サーバ識別子を用いて、前記サーバ識別子記憶手段からサーバを特定する特定手段と、前記第二のデータに含まれる前記サーバ識別子を、前記サーバ識別子記憶手段にこのサーバ識別子と対応付けて記憶される部分データに置き換えることにより第一のデータを復元する第二の置換手段と、前記第二の置換手段によって復元された第一のデータを含む通信データを、前記特定手段によって特定されたサーバに対して送信する第二の送信手段とを含むように構成される。
【００８０】
本発明の第一の態様では、第一の受信手段は、サーバから第一のデータを含む通信データを受信する。このような第一のデータの例として、ＨＴＴＰメッセージで利用されるＣｏｏｋｉｅ情報がある。この場合、サーバはコンテンツサーバであり通信データはリプライメッセージとなる。
【００８１】
生成手段は、通信データの送信元となるサーバを自装置において一意に識別するためのサーバ識別子を生成する。第一の置換手段は、第一のデータにおける部分データとサーバ識別子とを置き換えることにより第二のデータを生成する。このとき、部分データとサーバ識別子とのデータ量は同量となる。即ち、第一のデータと第二のデータとはデータ量が同じとなる。
【００８２】
サーバ識別子記憶手段は、置き換えの対象となった部分データと、サーバ識別子と、この通信データの送信元であるサーバとを対応付けたエントリを記憶する。例えば、第一のデータがＣｏｏｋｉｅ情報である場合、この通信データの送信元であるサーバは、このＣｏｏｋｉｅ情報の発行元のサーバとなる。そして、第一の送信手段は、第二のデータを含む通信データをクライアントへ送信する。
【００８３】
第二の受信手段がクライアントから第二のデータを含む通信データを受信すると、読出手段は、この通信データから第二のデータを読み出す。特定手段は、読み出された第二のデータに含まれるサーバ識別子を用いて、この通信データが送信されるべきサーバを特定する。このとき、特定手段は、サーバ識別子記憶手段において、このサーバ識別子に対応付けて記憶されるサーバを、この通信データが送信されるべきサーバとして特定する。
【００８４】
第二の置換手段は、第二のデータに含まれるサーバ識別子を、サーバ識別子記憶手段において、このサーバ識別子に対応付けて記憶される部分データと置き換える。即ち、第二の置換手段は、第二のデータを用いて、この第二のデータに対応する第一のデータを復元する。そして、第二の送信手段は、復元された第一のデータを含む通信データを、特定手段によって特定されたサーバに対して送信する。
【００８５】
このため、本発明の第一の態様によれば、サーバから送信される通信データと、クライアントにおいて受信されるサーバ識別子を含んだ通信データとのデータ量が等しくなる。従って、サーバとクライアントにおけるＴＣＰの処理が正常に動作するため、中継装置がＴＣＰ処理を実行する必要が無くなる。よって、中継装置における負荷が軽減され、データ中継処理が高速に実行される。また、通信データのデータ量が等しくなるため、中継装置においてパケットの転送がなされる場合において、パケットの再構築処理を省略することが可能となる。
【００８６】
また、第一の置換手段は、サーバから送信される通信データにおける第一のデータの内容に依存することなく処理を実行しサーバ識別子を付加する。そして、特定手段は、第一の置換手段によって付加されたサーバ識別子を用いて、振り分け先となるサーバを特定する。このため、本発明の第一の態様が適用されたシステムでは、サーバにおいて、振り分け処理の実現のために特別に設定等がなされる必要がない。
【００８７】
また、本発明の第一の態様は、前記第二の置換手段の処理対象となる前記サーバ識別子と、この第二の置換手段によって生成された前記第一のデータに含まれこの第一のデータを識別するデータ識別子とを対応付けて記憶するデータ識別子記憶手段をさらに備え、前記第一の置換手段は、前記データ識別子記憶手段によって記憶されるデータ識別子と、前記第一の受信手段によって受信された通信データに含まれる第一のデータに含まれるデータ識別子とが一致する場合に、このデータ識別子と対応付けて記憶されるサーバ識別子を用いて第二のデータを生成するように構成されても良い。
【００８８】
また、本発明の第一の態様は、前記第一の置換手段による処理を行わない第一のデータを示すデータ識別子を記憶する識別子記憶手段と、前記第一の受信手段によって受信された通信データに含まれる第一のデータを示すデータ識別子が前記識別子記憶手段に記憶されているか否かを判断し、記憶されている場合に、この第一のデータに対する置き換え処理を行わないように前記第一の置換手段を制御する置換制御手段とをさらに備えるように構成されても良い。
【００８９】
また、本発明の第一の態様は、前記第一の置換手段による処理を行わない第一のデータに含まれ、この第一のデータが送信されるべきドメインを示すドメイン識別子を記憶するドメイン識別子記憶手段と、前記第一の受信手段によって受信された通信データに含まれる第一のデータに含まれるドメイン識別子が前記ドメイン識別子記憶手段に記憶されているか否かを判断し、記憶されている場合に、この第一のデータに対する処理を行わないように前記第一の置換手段を制御する置換制御手段とをさらに備えるように構成されても良い。
【００９０】
また、本発明による第一の態様は、前記サーバから複数の分割データに分割されて送信される前記第一のデータを含む通信データについて前記第一の置換手段による処理が終了した場合、この通信データの他の分割データに対する前記第一の置換手段の処理を省略するように制御する省略制御手段をさらに備えるように構成されても良い。
【００９１】
【発明の実施の形態】
〔発明の原理〕
次に、本発明による中継装置の原理について説明する。
【００９２】
〈第一の原理〉
上記第一の解決方法が採用されることで、サーバのコンテンツにおいて中継装置を考慮した設定が行われる必要が無くなる。しかし、第一の解決方法では、サーバから送信されるリプライメッセージのサイズとクライアントによって受信されるリプライメッセージのサイズとが相違する。このため、中継装置がＴＣＰの処理を実行する必要が生じ、中継装置におけるパケット転送速度が低下するという問題があった。
【００９３】
第一の原理による中継装置は、この問題を解決するため、受信されたリプライメッセージのサイズを変更せずに、サーバ識別子であるサーバＩＤをこのメッセージのＣｏｏｋｉｅ情報の一部に上書きする。即ち、第一の原理による中継装置は、受信されたリプライメッセージに含まれるＣｏｏｋｉｅ情報の一部のビット列と、このビット列と同じサイズのサーバＩＤであるビット列とを書き換える（入れ替える）。
【００９４】
図１は、第一の原理の概略を示す図である。第一の原理では、サーバ２によって発行されたＣｏｏｋｉｅ情報を含むリプライメッセージを中継装置３ａが受信する。中継装置３ａは、受信されたリプライメッセージのサイズを変更せずに、サーバＩＤであるビット列（Ａ）をこのリプライメッセージに含まれるＣｏｏｋｉｅ情報の一部のビット列（α）と書き換える。このとき、中継装置３ａは、サーバＩＤであるビット列（Ａ）と書き換えられたビット列（α）とサーバＩＤが示すサーバ２のアドレスを対応付けて記憶する。中継装置３ａは、書き換えられたリプライメッセージをクライアント１へ転送する。クライアント１は、書き換えられたＣｏｏｋｉｅ情報を、自身のＣｏｏｋｉｅ表に記録する。
【００９５】
また、第一の原理では、クライアント１から送信され、クライアント１のＣｏｏｋｉｅ表に記録されたＣｏｏｋｉｅ情報を含むリクエストメッセージを、中継装置３ａが受信する。中継装置３ａは、受信されたリクエストメッセージに含まれるＣｏｏｋｉｅ情報中のサーバＩＤであるビット列（Ａ）を、このＣｏｏｋｉｅ情報と対応付けて記録されたビット列（α）に書き換える。この時点で、リクエストメッセージに含まれるＣｏｏｋｉｅ情報は、サーバ２によって発行されたＣｏｏｋｉｅ情報と一致する。そして、中継装置３ａは、書き換えられたリクエストメッセージを、サーバＩＤと対応付けて記録されたアドレス、即ちサーバ２のアドレスへ転送する。
【００９６】
図２は、第一の原理に基づく中継装置３ａの機能ブロック図である。中継装置３ａは、ハードウェア的には、バスを介して接続されたＣＰＵ，主記憶（ＲＡＭ），補助記憶装置（ハードディスク，フラッシュメモリ）等を備えている。中継装置３ａは、補助記憶装置に記憶された各種のプログラム（ＯＳ，アプリケーション等）が主記憶にロードされＣＰＵにより実行されることによって、ビット列抽出部４，７，Ｃｏｏｋｉｅ情報書換部５ａ，ヘッダ更新・パケット送信部６，８等を含む装置として機能する。
【００９７】
ビット列抽出部４，７は、ＣＰＵやＲＡＭ等を用いて構成される。ビット列抽出部４，７は、それぞれ受信されたリクエストメッセージ，リプライメッセージからＣｏｏｋｉｅ情報を読み出す。
【００９８】
Ｃｏｏｋｉｅ情報書換部５ａは、ＣＰＵやＲＡＭ等を用いて構成される。Ｃｏｏｋｉｅ情報書換部５ａは、メッセージに含まれるＣｏｏｋｉｅ情報の一部のビット列を他のビット列に書き換える。Ｃｏｏｋｉｅ情報書換部５ａの動作は、リクエストメッセージに対する場合とリプライメッセージに対する場合とで異なる。
【００９９】
Ｃｏｏｋｉｅ情報書換部５ａは、リプライメッセージに対する処理を実行する場合、このリプライメッセージに含まれるＣｏｏｋｉｅ情報の一部のビット列を、サーバＩＤであるビット列に書き換える。このとき、Ｃｏｏｋｉｅ情報の一部のビット列とサーバＩＤであるビット列とは同じデータ長である。そして、Ｃｏｏｋｉｅ情報書換部５ａは、Ｃｏｏｋｉｅ情報の元のビット列とサーバＩＤとリプライメッセージの送信元アドレスとを対応付けて記憶する。
【０１００】
一方、Ｃｏｏｋｉｅ情報書換部５ａは、リクエストメッセージに対する処理を実行する場合、このリクエストメッセージに含まれるＣｏｏｋｉｅ情報のうちサーバＩＤであるビット列を他のビット列に書き換える。このとき、Ｃｏｏｋｉｅ情報書換部５ａは、サーバＩＤと対応付けて自身が記憶するビット列に書き換える。
【０１０１】
次に、リプライメッセージに対してＣｏｏｋｉｅ情報書換部５ａが実行するビット列の書換方法について説明する。ここでは、リプライメッセージに含まれるＣｏｏｋｉｅ情報が、ＮＡＭＥ＝ＶＡＬＵＥという書式のＣｏｏｋｉｅ情報である場合について説明する。この場合、Ｃｏｏｋｉｅ情報書換部５ａは、以下に示される二つの書換方法のうちいずれかの方法を採用する。
【０１０２】
第一の書換方法は、ＶＡＬＵＥフィールドのみを書き換える方法である。この方法では、Ｃｏｏｋｉｅ情報書換部５ａは、ＶＡＬＵＥフィールドの文字列（ビット列）のうち、あらかじめ定義された長さの文字列をサーバＩＤに書き換える。このとき、サーバＩＤの長さはあらかじめ定義された長さと等しい。
【０１０３】
第二の書換方法は、ＮＡＭＥフィールドを含むフィールドを書き換える方法である。ＮＡＭＥ＝ＶＡＬＵＥという書式において”＝”は必ず一つ以上必要となる。このため、第二の書換方法では、Ｃｏｏｋｉｅ情報書換部５ａは、あらかじめ定義された長さの文字列をサーバＩＤに書き換える際に、”＝”の数に変化がないようにする。具体的には、例えば書き換えられるＣｏｏｋｉｅ情報の文字列が”＝”を含む場合、あらかじめ定義された長さよりも１文字分長い文字列が、サーバＩＤ及び”＝”によって書き換えられる。例えば、書き換えられるＣｏｏｋｉｅ情報の文字列が”ａｂｃ＝ｄ”であり、サーバＩＤが”ＡＢＣＤ”である場合、”ａｂｃ＝ｄ”という文字列が、サーバＩＤに”＝”を含めた”ＡＢＣＤ＝”という文字列で書き換えられる。このため、”＝”の数は変化しない。
【０１０４】
一方、書き換えられる文字列が”＝”を含まない場合、あらかじめ定義された長さの文字列が、サーバＩＤによって書き換えられる。
【０１０５】
ヘッダ更新・パケット送信部６，８は、ＣＰＵやＲＡＭ等を用いて構成される。ヘッダ更新・パケット送信部６，８は、それぞれ、リクエストメッセージ，リプライメッセージを送信する。即ち、ヘッダ更新・パケット送信部６，８は、Ｃｏｏｋｉｅ情報が書き換えられたメッセージを含むパケットのヘッダ情報を書き換え、それぞれサーバ２，クライアント１へパケットを送信する。
【０１０６】
次に、図２を用いて、中継装置３ａの動作について説明する。なお、以下の説明では、サーバ２からクライアント１へ送信される（向かう）パケット，トラヒックを「下り」と記載する。一方、クライアント１からサーバ２へ送信される（向かう）パケット，トラヒックを「上り」と記載する。
【０１０７】
まず、中継装置３ａが下りのパケット（リプライメッセージを含むパケット）に対して行う処理について説明する。ビット列抽出部７は、受信されたパケットのペイロードから文字列”Ｓｅｔ−Ｃｏｏｋｉｅ”以下のＣｏｏｋｉｅ情報を示す文字列を抽出する。また、ビット列抽出部７は、サーバＩＤが書き込まれる位置を示す書き込み開始位置を特定する。この書き込み開始位置は、採用される書換方法によって異なる。
【０１０８】
Ｃｏｏｋｉｅ情報書換部５ａは、自装置内で一意となるサーバＩＤ（サーバ２を一意に示すＩＤ）を作成し、受信されたパケットの送信元サーバとこのサーバＩＤとを対応付けて記録する。Ｃｏｏｋｉｅ情報書換部５ａは、このサーバＩＤを用いて、受信されたパケットのＣｏｏｋｉｅ情報の一部を書き換える。Ｃｏｏｋｉｅ情報書換部５ａは、書き換え前のビット列とこのサーバＩＤとを対応付けてさらに記録する。
【０１０９】
ヘッダ更新・パケット送信部８は、受信されたパケットの送信元アドレスを自装置のアドレスに書き換え、この書き換えに伴って影響を受けるＴＣＰ及びＩＰヘッダのフィールドを書き換える。そして、ヘッダ更新・パケット送信部８は、クライアント１に向けてパケットを送信する。
【０１１０】
次に、中継装置３ａが上りのパケット（リクエストメッセージを含むパケット）に対して行う処理について説明する。ビット列抽出部４は、受信されたパケットのペイロードからサーバＩＤを抽出する。また、ビット列抽出部４は、このサーバＩＤであるビット列が他のビット列に書き換えられる位置を示す書き換え開始位置を特定する。この書き換え開始位置は、採用される書換方法によって異なる。
【０１１１】
Ｃｏｏｋｉｅ情報書換部５ａは、ビット列抽出部４によって抽出されたサーバＩＤと対応付けて記録された送信元サーバと書き換え前のビット列とを特定する。Ｃｏｏｋｉｅ情報書換部５ａは、受信されたＣｏｏｋｉｅ情報の書き換え開始位置以降のビット列を、他のビット列で書き換える。
【０１１２】
ヘッダ更新・パケット送信部６は、受信されたパケットの送信先アドレスを、Ｃｏｏｋｉｅ書換部５ａによって特定された送信元サーバのアドレスに書き換え、この書き換えに伴って影響を受けるＴＣＰおよびＩＰヘッダのフィールドを書き換える。そして、ヘッダ更新・パケット送信部６は、サーバ２に向けてパケットを送信する。
【０１１３】
本発明の第一の原理によれば、サーバ２によって発行されたＣｏｏｋｉｅ情報の内容に関わらず、Ｃｏｏｋｉｅ書換部Ｐ５ａがサーバＩＤを上書きするため、サーバ２のコンテンツについて中継装置３ａを考慮した設定が行われる必要がない。また、本発明の第一の原理によれば、サーバＩＤと書き換えられるビット列とが同じビット数であるため、パケットのサイズが変更されない。このため、サーバＩＤによって、Ｃｏｏｋｉｅ情報に応じた振り分け先サーバが判断されるとともに、中継装置３ａがエンドホストとしてＴＣＰ処理を行う必要がなくなる。
【０１１４】
〈第二の原理〉
本発明の第一の原理によれば、メッセージサイズ（パケットサイズ）が変更されずにＣｏｏｋｉｅ情報が書き換えられる。しかし、サーバによって発行されたＣｏｏｋｉｅ情報と異なるＣｏｏｋｉｅ情報がクライアントに届くため、クライアントにおいて問題が起こる場合がある。図３は、このような問題の例を示す図である。
【０１１５】
クライアント１は、過去に受信されたＣｏｏｋｉｅ情報、即ちローカルのＣｏｏｋｉｅ表に記録されたＣｏｏｋｉｅ情報と同一のＮＡＭＥ値を持つＣｏｏｋｉｅ情報を新たに得た場合、過去に受信されたＣｏｏｋｉｅ情報を新たに得られたＣｏｏｋｉｅ情報を用いて上書きする。このため、サーバ２から新たに発行されたＣｏｏｋｉｅ情報のＮＡＭＥ値（”ｎａｍｅＡ１”）が過去に発行されたＣｏｏｋｉｅ情報のＮＡＭＥ値（”ｎａｍｅＡ１”）と同一である場合、クライアント１において上書きが実行される必要がある。しかし、中継装置によってＣｏｏｋｉｅ情報の一部が書き換えられた結果、それぞれのＣｏｏｋｉｅ情報のＮＡＭＥ値が異なる値となった場合（”ａ（ｅ％Ａ１”，”ａ（ｅ＆Ａ１”）、クライアント１において上書きが実行されない。このため、それぞれのＣｏｏｋｉｅ情報のパス（ＤＯＭＡＩＮ＿ＮＡＭＥ値及びＰＡＴＨ値）が同一である場合、二つのＣｏｏｋｉｅ情報がサーバ２における同一のコンテンツに対して送信され、サーバ２の処理において不都合が生じる可能性がある。
【０１１６】
従って、中継装置は、過去に受信されたＣｏｏｋｉｅ情報と同一のＮＡＭＥ値を持つＣｏｏｋｉｅ情報を同じサーバから受信した場合、過去にクライアントに転送した際のＣｏｏｋｉｅ情報のＮＡＭＥ値と同一のＮＡＭＥ値を持つＣｏｏｋｉｅ情報となるように書き換えを行う必要がある。
【０１１７】
図４は、第二の原理の概略を示す図である。上記問題を解決するため、第二の原理では、リクエストメッセージ（矢印Ｂにおけるリクエストメッセージ）に含まれるＮＡＭＥ値のうち中継装置３ｂによって書き換えられたビット列（”ｎａｍｅ”）と同一のビット列をＮＡＭＥ値に持つリプライメッセージ（矢印Ｃにおけるリプライメッセージ）が受信された場合、このリクエストメッセージがクライアント１から送信される際に有していたサーバＩＤと同一のサーバＩＤ（”ａ（ｅ％”）を用いて書き換えが実行される。
【０１１８】
図５は、第二の原理に基づく中継装置３ｂの機能ブロック図である。第二の原理に基づく中継装置３ｂの構成について、第一の原理に基づく中継装置３ａと異なる構成についてのみ説明する。
【０１１９】
中継装置３ｂは、Ｃｏｏｋｉｅ情報書換部５ａに換えてＣｏｏｋｉｅ情報書換部５ｂを備える。また、中継装置３ｂは、同一ＮＡＭＥ判定部９を備える。
【０１２０】
同一ＮＡＭＥ判定部９は、ＣＰＵやＲＡＭ等を用いて構成される。同一ＮＡＭＥ判定部９は、リクエストメッセージに含まれるサーバＩＤと、このリクエストメッセージがサーバ２へ転送される際のＣｏｏｋｉｅ情報におけるＮＡＭＥ値とを対応付けて記録する。
【０１２１】
また、同一ＮＡＭＥ判定部９は、リプライメッセージに含まれるＣｏｏｋｉｅ情報の一部のビット列（例：”ｎａｍｅ”）が、サーバＩＤと対応付けて記録されているか否かを判断する。記録されている場合、同一ＮＡＭＥ判定部９は、上記のＣｏｏｋｉｅ情報の一部のビット列と対応付けて記録するサーバＩＤとともに同一判定報告をＣｏｏｋｉｅ情報書換部５ｂへ通知する。一方、記録されていない場合、同一ＮＡＭＥ判定部９は、相違判定報告をＣｏｏｋｉｅ情報書換部５ｂへ通知する。
【０１２２】
Ｃｏｏｋｉｅ情報書換部５ｂは、上りのパケット、即ちリクエストメッセージに対しては、Ｃｏｏｋｉｅ情報書換部５ａと同じ処理を行う。一方、Ｃｏｏｋｉｅ情報書換部５ｂは、下りのパケット、即ちリプライメッセージに対しては、Ｃｏｏｋｉｅ情報書換部５ａとは異なる処理を実行する。以下、Ｃｏｏｋｉｅ情報書換部５ｂのこの処理について説明する。
【０１２３】
Ｃｏｏｋｉｅ情報書換部５ｂは、同一ＮＡＭＥ判定部９から同一判定報告と共にサーバＩＤを通知された場合、このサーバＩＤを用いて、リプライメッセージに含まれるＣｏｏｋｉｅ情報の一部のビット列を上書きする。一方、Ｃｏｏｋｉｅ情報書換部５ｂは、同一ＮＡＭＥ判定部９から相違判定報告を通知された場合、自装置内で一意となるサーバＩＤを新たに作成し、このサーバＩＤを用いて、リプライメッセージに含まれるＣｏｏｋｉｅ情報の一部のビット列を上書きする。そして、Ｃｏｏｋｉｅ情報書換部５ｂは、Ｃｏｏｋｉｅ情報の元のビット列とサーバＩＤとを対応付けて記憶する。
【０１２４】
〈第三の原理〉
第一の原理に基づく中継装置３ａは、サーバ２によって発行されたＣｏｏｋｉｅ情報の一部を書き換えるため、クライアント１がサーバ２の期待するように動作しない場合がある。例えば、クライアント１がローカルで保存しているＣｏｏｋｉｅ情報を、サーバ２から転送されたプログラムが読み込む場合にこの問題が生じる。この場合、このプログラムが読み込むＣｏｏｋｉｅ情報は、中継装置３ａによって書き換えられたＣｏｏｋｉｅ情報である。一方、このプログラムは、サーバ２によって発行されたＣｏｏｋｉｅ情報を用いることを前提として作成されている。このため、このプログラムの動作が想定外のものとなる可能性がある。
【０１２５】
第三の原理では、このような問題を解決するため、サーバによって提供されるプログラムによって使用されるＣｏｏｋｉｅ情報を中継装置においてあらかじめ定義し、定義されたＣｏｏｋｉｅ情報については書き換えを実行しないように構成される。
【０１２６】
図６は、第三の原理に基づく中継装置３ｃの機能ブロック図である。第三の原理に基づく中継装置３ｃの構成について、第一の原理に基づく中継装置３ａと異なる構成についてのみ説明する。
【０１２７】
中継装置３ｃは、Ｃｏｏｋｉｅ情報書換部５ａに換えてＣｏｏｋｉｅ情報書換部５ｃを備える。また、中継装置３ｃは、ＮＡＭＥフィルタ部１０，１１を備える。
【０１２８】
ＮＡＭＥフィルタ部１０，１１は、ＣＰＵやＲＡＭや不揮発性記憶装置（ハードディスク，フラッシュメモリ等）等を用いて構成される。ＮＡＭＥフィルタ部１０，１１は、ビット列の書き換えの対象とならないＣｏｏｋｉｅ情報を自身の不揮発性記憶装置に記憶する。ＮＡＭＥフィルタ部１０，１１は、ビット列抽出部４によって抽出されたＣｏｏｋｉｅ情報が、ビット列の書き換えを実行しないＣｏｏｋｉｅ情報と定義されたものであるか否かを判断する。ＮＡＭＥフィルタ部１０，１１は、Ｃｏｏｋｉｅ情報のＮＡＭＥ値が、自身が記憶するＮＡＭＥ値に一致する場合に書換を実行しないＣｏｏｋｉｅ情報であると判断する。そして、ＮＡＭＥフィルタ部１０，１１は、判断の結果をＣｏｏｋｉｅ情報書換部５ｃに通知する。
【０１２９】
Ｃｏｏｋｉｅ情報書換部５ｃは、ＮＡＭＥフィルタ部１１からＣｏｏｋｉｅ情報の書き換えを実行すると通知された場合、自装置内で一意となるサーバＩＤを作成し、受信されたリプライメッセージの送信元サーバとこのサーバＩＤとを対応付けて記録する。また、この場合、Ｃｏｏｋｉｅ情報書換部５ｃは、このサーバＩＤを用いてＣｏｏｋｉｅ情報の一部（ビット列）を書き換える。また、この場合、Ｃｏｏｋｉｅ情報書換部５ｃは、書き換え前のビット列とこのサーバＩＤとを対応付けて記録する。
【０１３０】
Ｃｏｏｋｉｅ情報書換部５ｃは、ＮＡＭＥフィルタ部１０からＣｏｏｋｉｅ情報の書き換えを実行すると通知された場合、受信されたリクエストメッセージに含まれるサーバＩＤを、このサーバＩＤと対応付けて記録された書き換え前のビット列を用いて書き換える。
【０１３１】
一方、Ｃｏｏｋｉｅ情報書換部５ｃは、ＮＡＭＥフィルタ部１０，１１からＣｏｏｋｉｅ情報の書き換えを実行しないと通知された場合、処理を実行しない。
【０１３２】
第三の原理によれば、あらかじめ書き換えを実行しないように定義されたＣｏｏｋｉｅ情報は、ＮＡＭＥフィルタ部１０，１１によって検出されるため、結果的に、サーバ２によって発行されたＣｏｏｋｉｅ情報がそのままクライアント１に転送される。このため、このＣｏｏｋｉｅ情報を用いることを前提とされているプログラムは、想定通りの動作を行う事が可能となる。従って、Ｃｏｏｋｉｅ情報を用いて動作するプログラムにおいて、サーバ２が想定するプログラムの動作と、Ｃｏｏｋｉｅ情報を用いて動作する実際のプログラムの動作とを一致させることが可能となる。
【０１３３】
なお、書き換えが実行されないＣｏｏｋｉｅ情報のみを含むメッセージについては、このようなメッセージに対してのみ、第一の解決方法のような従来手法を適用することにより、Ｃｏｏｋｉｅ情報の発行元が考慮された適切なサーバにリクエストメッセージを転送することが可能となる。
【０１３４】
〈第四の原理〉
クライアントのユーザがあるページの中のバナー広告をクリックした場合、Ｃｏｏｋｉｅ情報によって、このクライアントのユーザが辿ってきたページをリンク先のサイトに通知することがある。このとき、バナー広告のあるサーバを中継装置３ａが管理しており、リンク先のサーバが中継装置３ａの管理外のネットワークに設置されている場合、第一の原理では以下に示す問題が発生する。即ち、中継装置３ａが管理していない他のドメインに転送されるＣｏｏｋｉｅ情報（ＤＯＭＡＩＮ＿ＮＡＭＥ値が中継装置３ａによって管理されていないドメイン名であるＣｏｏｋｉｅ情報）をクライアント１が受信すると、クライアント１は中継装置３ａを経由しない他のサーバへ送信されるリクエストメッセージに、中継装置３ａによって書き換えられたＣｏｏｋｉｅ情報を付加する。このため、他のサーバは、リクエストメッセージに含まれるＣｏｏｋｉｅ情報について正しく処理することができない。
【０１３５】
図７は、第四の原理に基づく中継装置３ｄの機能ブロック図である。第四の原理では、中継装置３ｄにおいて管理ドメインが定義される。そして、中継装置３ｄによって受信されたリプライメッセージに含まれるＣｏｏｋｉｅ情報のＤＯＭＡＩＮ＿ＮＡＭＥ値が、定義された管理ドメインと異なる場合、このリプライメッセージはＣｏｏｋｉｅ情報の書き換えが実行されずにクライアント１へ転送される。
【０１３６】
以下、第四の原理に基づく中継装置３ｄの構成について、第一の原理に基づく中継装置３ａと異なる構成についてのみ説明する。
【０１３７】
中継装置３ｄは、Ｃｏｏｋｉｅ情報書換部５ａに換えてＣｏｏｋｉｅ情報書換部５ｄを備える。また、中継装置３ｄは、ドメインフィルタ部１２を備える。
【０１３８】
ドメインフィルタ部１２は、ＣＰＵやＲＡＭや不揮発性記憶装置（ハードディスク，フラッシュメモリ等）等を用いて構成される。ドメインフィルタ部１２は、あらかじめ定義された管理ドメインを不揮発性記憶装置に記憶する。ドメインフィルタ部１２は、受信されたリプライメッセージに含まれるＣｏｏｋｉｅ情報のドメイン名（ＤＯＭＡＩＮ＿ＮＡＭＥ値）が、自身が記憶する管理ドメインと一致するか否かを判断する。ドメインフィルタ部１２は、この判断の結果をＣｏｏｋｉｅ情報書換部５ｄに通知する。
【０１３９】
Ｃｏｏｋｉｅ情報書換部５ｄは、ドメインフィルタ部１２から通知される内容に応じて動作する。管理ドメインとＣｏｏｋｉｅ情報のドメイン名とが一致すると通知された場合、Ｃｏｏｋｉｅ情報書換部５ｄは、自装置内で一意となるサーバＩＤを作成し、受信されたリプライメッセージの送信元サーバとこのサーバＩＤとを対応付けて記録する。また、このとき、Ｃｏｏｋｉｅ情報書換部５ｄは、このサーバＩＤを用いて、受信されたパケットのＣｏｏｋｉｅ情報の一部を書き換える。また、このとき、Ｃｏｏｋｉｅ情報書換部５ｄは、書き換え前のビット列とこのサーバＩＤとをさらに対応付けて記録する。
【０１４０】
一方、Ｃｏｏｋｉｅ情報書換部５ｄは、管理ドメインとＣｏｏｋｉｅ情報のドメイン名とが一致しないと通知された場合、処理を実行しない。
【０１４１】
第四の原理によれば、管理ドメイン以外のドメイン名を持つＣｏｏｋｉｅ情報を含んだリプライメッセージに対して、Ｃｏｏｋｉｅ情報の書き換えが実行されない。このため、結果的にサーバ２によって発行されたＣｏｏｋｉｅ情報がそのままクライアント１に転送される。従って、クライアント１がリクエストメッセージにこのＣｏｏｋｉｅ情報を付加した場合、このリクエストメッセージが中継装置３ｄを介さずにサーバに送信された場合であっても、正しいＣｏｏｋｉｅ情報がこのサーバへ通知される。
【０１４２】
なお、書き換えが実行されないＣｏｏｋｉｅ情報のみを含むメッセージについては、このようなメッセージに対してのみ、第一の解決方法のような従来手法を適用することにより、Ｃｏｏｋｉｅ情報の発行元が考慮された適切なサーバにリクエストメッセージを転送することが可能となる。
【０１４３】
〈第五の原理〉
第一の原理では、Ｃｏｏｋｉｅ情報書換部５ａは、サーバＩＤについてのエントリを記憶するが、このエントリの削除については特定されていない。しかし、サーバＩＤについてのエントリ数が有限である場合、エントリ数が満たされることにより、有効であるエントリが消去される可能性がある。
【０１４４】
第五の原理では、有効期限（ＤＡＴＥ値）が経過しているＣｏｏｋｉｅ情報に関するエントリを優先的に削除（エントリ消去）することにより、この問題を解決する。
【０１４５】
図８は、第五の原理に基づく中継装置３ｅの機能ブロック図である。第五の原理に基づく中継装置３ｅの構成について、第位置の原理に基づく中継装置３ａと異なる構成についてのみ説明する。
【０１４６】
中継装置３ｅは、Ｃｏｏｋｉｅ情報書換部５ａに換えてＣｏｏｋｉｅ情報書換部５ｅを備える。
【０１４７】
Ｃｏｏｋｉｅ情報書換部５ｅは、基本的にＣｏｏｋｉｅ情報書換部５ａと変わらない。ただし、Ｃｏｏｋｉｅ情報書換部５ｅは、書き換え前のビット列とサーバＩＤとを対応付けて記録する際に、Ｃｏｏｋｉｅ情報の有効期限をさらに対応付けて記録する。そして、Ｃｏｏｋｉｅ情報書換部５ｅは、エントリを消去する場合、この有効期限が満了しているエントリを優先的に消去する。
【０１４８】
第五の原理によれば、各エントリは、対応するＣｏｏｋｉｅ情報の有効期限に応じて消去される。このため、有効なエントリが無効となったエントリよりも先に消去されることがなくなる。ここで、有効なエントリとは、対応するＣｏｏｋｉｅ情報がクライアント１ａとサーバ２ａとの間で使用されるため、このエントリに基づいて振り分け先となるサーバが決定される可能性のあるエントリを示す。一方、無効なエントリとは、対応するＣｏｏｋｉｅ情報が有効期限切れのためにクライアント１ａとサーバ２ａとの間で使用されず、このエントリに基づいて振り分け先となるサーバが決定される可能性のないエントリを示す。
【０１４９】
〈第六の原理〉
Ｃｏｏｋｉｅ情報は、各メッセージのＨＴＴＰヘッダに書き込まれる。このため、あるＴＣＰコネクション上のリプライメッセージが複数のパケットで構成される場合、ＨＴＴＰヘッダ部分の終了が確認された時点で、以降のパケットにはＣｏｏｋｉｅ情報が含まれないことは明らかである。このため、以降のパケットは、Ｃｏｏｋｉｅ情報書換部５ａ，５ｂ，５ｃ，５ｄ，５ｅの処理対象とならない。
【０１５０】
しかし、第一から第五の原理によれば、全てのパケットをＣｏｏｋｉｅ情報書換部５ａ，５ｂ，５ｃ，５ｄ，５ｅの処理対象としていた。従って、不要な処理が増大し、装置全体のパケット転送能力が低下していた。
【０１５１】
第六の原理では、ＨＴＴＰヘッダの終了部分を判断し、以降のパケットについてはＣｏｏｋｉｅ情報書換部の処理対象とせずに次の処理を実行することによってこの問題を解決する。
【０１５２】
図９は、第六の原理に基づく中継装置３ｆの機能ブロック図である。第六の原理に基づく中継装置３ｆの構成について、第一の原理に基づく中継装置３ａと異なる構成についてのみ説明する。
【０１５３】
中継装置３ｆは、ヘッダ終了チェック部１３を備える。
【０１５４】
ヘッダ終了チェック部１３は、ＣＰＵやＲＡＭ等を用いて構成される。ヘッダ終了チェック部１３は、処理の対象としているパケットに係るコネクションにおいてＨＴＴＰヘッダを含むパケットについての処理が終了しているか否かを判断する。終了している場合、ヘッダ終了チェック部１３は、このパケット及び以降のパケットについて、ビット列抽出部７及びＣｏｏｋｉｅ情報書換部５ａをバイパスする。即ち、ヘッダ終了チェック部１３は、このパケット及び以降のパケットを、ヘッダ更新・パケット送信部８へ直接渡す。また、ヘッダ終了チェック部１３は、各トラヒック上のＨＴＴＰヘッダを含むパケットについての処理が全て終了したかどうかをチェックし、終了していた場合は記録する。
【０１５５】
〔実施形態の概要〕
次に、図を用いて本発明の中継装置の実施形態である負荷分散装置について説明する。なお、本実施形態の説明は例示であり、本発明の構成は以下の説明に限定されない。
【０１５６】
図１０は、本発明の実施形態における負荷分散装置１５を用いた負荷分散システム１４の概要を示す図である。負荷分散システム１４は、サーバグループ１６，負荷分散装置１５，クライアント１ａ，１ｂ，１ｃ，サーバ２ｄ等を用いて構成される。
【０１５７】
クライアント１ａ，１ｂ，１ｃは、パーソナルコンピュータやワークステーション等の情報処理装置を用いて構成される。クライアント１ａはＩＰアドレスとして”２０．０．０．１”を持つ。クライアント１ａ，１ｂ，１ｃは、インターネットに接続されており、負荷分散装置１５やサーバ２ｄ等の装置と通信可能に構成される。なお、クライアントは、クライアント１ａ，１ｂ，１ｃに限られる必要はなく、設置される数に限定はない。
【０１５８】
負荷分散装置１５は、パーソナルコンピュータやワークステーション等の情報処理装置や専用のハードウェア等を用いて構成される。負荷分散装置１５は、サーバグループ１６について負荷分散処理を実行する。負荷分散装置１５は、ＶＩＰとして”１０．０．０．１”を持つ。図１０における負荷分散装置１５は、以下に説明する第一実施形態から第六実施形態における負荷分散装置１５ａ，１５ｂ，１５ｃ，１５ｄ，１５ｅ，１５ｆを含む。なお、クライアント１ａ，１ｂ，１ｃと負荷分散装置１５、負荷分散装置１５とサーバ２ａ，２ｂ，２ｃ間のＴＣＰコネクション作成処理については、どのような処理によって実行されても良いため、説明を省略する。また、負荷分散装置１５では、サーバＩＤの書換方法として第二の書換方法が採用される。
【０１５９】
サーバグループ１６は、複数台のサーバを用いて構成される。例えば、サーバ２ａ，２ｂ，２ｃ等を用いて構成される。サーバグループ１６は、ドメイン名として”ｗｗｗ．ｎｅｔ．ｃｏｍ”が設定されている。サーバ２ａ，２ｂ，２ｃは、パーソナルコンピュータやワークステーション等の情報処理装置を用いて構成される。サーバ２ａ，２ｂ，２ｃは、それぞれ異なるＩＰアドレスを持つ。例えば、サーバ２ａは、”１９２．１６８．０．１”をＩＰアドレスとして持つ。また、サーバ２ａ，２ｂ，２ｃは、アクセスＵＲＬが”ｗｗｗ．ｎｅｔ．ｃｏｍ／ｃｏｎｔｅｎｔｓ／ｉｎｄｅｘ．ｃｇｉ”であるコンテンツを備える。なお、サーバは、サーバ２ａ，２ｂ，２ｃに限られる必要はなく、設置される数に限定は無い。
【０１６０】
サーバ２ｄは、パーソナルコンピュータやワークステーション等の情報処理装置を用いて構成される。サーバ２ｄは、ドメイン名として”ｗｗｗ．ｎｅｔｗｏｒｋ．ｏｒ．ｊｐ”が設定されている。また、サーバ２ｄは、”８０．０．０．１”をＩＰアドレスとして持つ。
【０１６１】
第六の原理によれば、ＨＴＴＰヘッダを含まない、即ちＣｏｏｋｉｅ情報を含まないパケットについては、Ｃｏｏｋｉｅ情報書換部における処理が省略される。このため、装置全体としてのパケット転送の高速化が可能となる。
【０１６２】
〔第一実施形態〕
〈システム形態〉
図１１は、本発明による負荷分散装置１５の第一実施形態、即ち負荷分散装置１５ａのブロック図である。負荷分散装置１５ａは、ハードウェア的には、バスを介して接続されたＣＰＵ，主記憶（ＲＡＭ），補助記憶装置（ハードディスク，フラッシュロム等）等を備えている。負荷分散装置１５ａは、補助記憶装置に記憶された各種のプログラム（ＯＳ，アプリケーション等）が主記憶にロードされＣＰＵにより実行されることによって、ビット列抽出部１７，２１，振り分け先サーバ決定部１８，ＩＤ・ビット列書換部１９，ヘッダ更新・パケット送信部２０，２５，書換用テーブル記憶部２２，ＩＤ生成部２３，ビット列・ＩＤ書換部２４等を含む装置として機能する。
【０１６３】
ビット列抽出部１７は、ＣＰＵやＲＡＭ等を用いて構成される。ビット列抽出部１７は、受信されたパケットのペイロードから、Ｃｏｏｋｉｅ情報のＮＡＭＥフィールド，ＶＡＬＵＥフィールド，ＤＡＴＥフィールド，ＰＡＴＨフィールド，ＤＯＭＡＩＮ＿ＮＡＭＥフィールドの値（各文字列）を抽出する。そして、ビット列抽出部１７は、ＮＡＭＥフィールド，ＶＡＬＵＥフィールドからサーバＩＤを抽出する。また、ビット列抽出部１７は、ＩＤ・ビット列書換部１９における書き換え時の書き込み開始位置を特定する。即ち、ビット列抽出部１７は、サーバＩＤの位置を特定する。
【０１６４】
振り分け先サーバ決定部１８は、ＣＰＵやＲＡＭ等を用いて構成される。振り分け先サーバ決定部１８は、受信されたパケットの中にＣｏｏｋｉｅ情報がある場合、ビット列抽出部１７によって抽出されたサーバＩＤをキーとして、書換用テーブル２２Ａを検索し、受信されたパケット及びこのパケットに含まれるリクエストメッセージを含む他のパケットの振り分け先となるサーバを決める。また、この場合、振り分け先サーバ決定部１８は、サーバＩＤに対応する書換前文字列を書換用テーブル２２Ａから読み出す。また、この場合、振り分け先サーバ決定部１８は、処理の対象となったパケット及び読み出された書換前文字列を、ＩＤ・ビット列書換部１９へ渡す。
【０１６５】
受信されたパケットの中にＣｏｏｋｉｅ情報がない場合、即ちビット列抽出部１７によってＣｏｏｋｉｅ情報が検出されなかった場合、振り分け先サーバ決定部１８は、他の振り分けルール（ラウンドロビン等）によって、このパケット及びこのパケットに含まれるリクエストメッセージを含む他のパケットの振り分け先となるサーバを決定する。この場合、振り分け先サーバ決定部１８は、処理の対象となったパケットをヘッダ更新・パケット送信部２０へ渡す。ただし、Ｃｏｏｋｉｅ情報を含まないパケットが、既に振り分け先サーバを決定されたリクエストメッセージを含むパケットである場合、このパケットについてはこの振り分け先サーバに従って振り分け先となるサーバが決定される。
【０１６６】
ＩＤ・ビット列書換部１９は、ＣＰＵやＲＡＭ等を用いて構成される。ＩＤ・ビット列書換部１９は、ビット列抽出部１７によって抽出されたサーバＩＤを、振り分け先サーバ決定部１８によって書換用テーブル２２Ａから読み出された書換前文字列で上書きする。
【０１６７】
ヘッダ更新・パケット送信部２０は、通信制御装置やＣＰＵやＲＡＭ等を用いて構成される。ヘッダ更新・パケット送信部２０は、クライアント側から自装置１５ａに入力された全てのパケットについてヘッダの更新を行う。ヘッダ更新・パケット送信部２０は、ヘッダの更新において、送信先のＩＰアドレスを、振り分け先サーバ決定部１８によって決定された送信先となるサーバのＩＰアドレスに変更する。また、ヘッダ更新・パケット送信部２０は、ヘッダの更新において、ＴＣＰ及びＩＰヘッダのチェクサムのように、送信先のＩＰアドレスの変更に伴って更新すべき値を更新する。ヘッダ更新・パケット送信部２０は、ヘッダの更新を行った後、相手先となるサーバのＩＰアドレスごとに、別々のインタフェースによってパケットを送出する。
【０１６８】
ビット列抽出部２１は、ＣＰＵやＲＡＭ等を用いて構成される。ビット列抽出部２１は、受信されたパケットのペイロードから、Ｃｏｏｋｉｅ情報のＮＡＭＥフィールドとＶＡＬＵＥフィールドとの値としてビット列（文字列）を抽出する。また、ビット列抽出部２１は、パケットのペイロードにおいて、ビット列・ＩＤ書換部２４によってサーバＩＤが書き込まれる位置、即ちサーバＩＤの書き込み開始位置を特定する。また、ビット列抽出部２１は、受信されたパケットにＣｏｏｋｉｅ情報が含まれない場合、ビット列・ＩＤ書換部２４をバイパスし、ヘッダ更新・パケット送信部２５へパケットを渡す。
【０１６９】
書換用テーブル記憶部２２は、ＲＡＭや不揮発性記憶装置等を用いて構成される。書換用テーブル記憶部２２は、書換用テーブル２２Ａを記憶する。図１２は、書換用テーブル２２Ａの例を示す図である。書換用テーブル２２Ａは、書き換えの記録を保持しておくテーブルである。即ち、ビット列・ＩＤ書換部２４によって実行される書き換え（上書き）処理における書き換え前の文字列と書き換え後の文字列、即ちサーバＩＤとを対応付けて持つ。また、書換用テーブル２２Ａには、さらに書き換え後の文字列であるサーバＩＤに対応するサーバ（パケットの振り分け先のサーバ）のＩＰアドレスを対応付けて持つ。即ち、書換用テーブル２２Ａは、書き換え前の文字列と書き換え後の文字列（サーバＩＤ）とサーバのＩＰアドレスとを持つエントリが記録される。なお、負荷分散装置１５ａでは、第二の書換方法が採用される。このため、書き換え前の文字列の文字数とサーバＩＤの文字列の文字数とは異なる場合がある。
【０１７０】
ＩＤ生成部２３は、ＣＰＵやＲＡＭ等を用いて構成される。ＩＤ生成部２３は、
自装置１５ａによって既に発行されたサーバＩＤと重複しないサーバＩＤを生成する。サーバＩＤは、特定の長さのビット列であり、自装置１５ａが管理するサーバグループ１６に含まれるサーバを一意に示す識別子である。ＩＤ生成部２３は、生成されたサーバＩＤを、ビット列・ＩＤ書換部２４に渡す。
【０１７１】
ビット列・ＩＤ書換部２４は、ＣＰＵやＲＡＭ等を用いて構成される。ビット列・ＩＤ書換部２４は、ビット列抽出部２１によって抽出された文字列とＩＤ生成部２３によって生成されたサーバＩＤと受信されたパケットの送信元となるサーバ２ａのＩＰアドレスとを対応付けて書換用テーブル記憶部２２へ記録する。即ち、ビット列・ＩＤ書換部２４は、この三つの情報を持つエントリを、書換用テーブル２２Ａに登録する。また、ビット列・ＩＤ書換部２４は、受信されたパケットに対し、ビット列抽出部２１によって特定された書き込み開始位置をもとに、ＩＤ生成部２３によって生成されたサーバＩＤを上書きする。
【０１７２】
ヘッダ更新・パケット送信部２５は、通信制御装置やＣＰＵやＲＡＭ等を用いて構成される。ヘッダ更新・パケット送信部２５は、サーバグループ１６側から自装置１５ａに入力された全てのパケットについてヘッダの更新を行う。ヘッダ更新・パケット送信部２５は、ヘッダの更新において、送信元のＩＰアドレスを自装置１５ａの管理するＶＩＰに変更する。また、ヘッダ更新・パケット送信部２５は、ヘッダの更新において、ＴＣＰ及びＩＰヘッダのチェクサムのように、送信元のＩＰアドレスの変更に伴って更新すべき値を更新する。ヘッダ更新・パケット送信部２５は、ヘッダの更新を行った後、相手先となるクライアントのＩＰアドレスごとに、別々のインタフェースによってパケットを送出する。
【０１７３】
〈動作シーケンス〉
図１３は、第一実施形態による負荷分散装置１５ａを用いた負荷分散システム１４における動作シーケンスの例を示す図である。クライアント１ａは、リクエストメッセージ（ＨＴＴＰリクエストメッセージ）を作成し、ＶＩＰ１宛にこのリクエストメッセージを送信する（ｓｅｑ１ａ）。このとき、リクエストメッセージの送信先アドレス及び送信先ポート番号、即ちリクエストメッセージを含むパケットのヘッダにおける送信先アドレス及び送信先ポート番号は、”１０．０．０．１”，”８０”である。また、リクエストメッセージの送信元アドレス及び送信元ポート番号は、”２０．０．０．１”，”５０００”である。
【０１７４】
負荷分散装置１５ａがクライアント１ａからリクエストメッセージを受信すると、まずビット列抽出部１７がＣｏｏｋｉｅ情報の抽出を行う。ここでは、リクエストメッセージにＣｏｏｋｉｅ情報が含まれないため、Ｃｏｏｋｉｅ情報は抽出されない。
【０１７５】
振り分け先サーバ決定部１８は、ビット列抽出部１７によってＣｏｏｋｉｅ情報が抽出されないため、ラウンドロビン等の振り分けルールを用いて、振り分け先となるサーバを決定する。ここでは、振り分け先のサーバとして、ＩＰアドレス”１９２．１６８．０．１”が設定されたサーバ２ａが決定されたと仮定する。また、ビット列抽出部１７によってＣｏｏｋｉｅ情報が抽出されないため、振り分け先サーバ決定部１８は、振り分け先が決定されたリクエストメッセージ（振り分け先が決定されたリクエストメッセージを含むパケット）を、ヘッダ更新・パケット送信部２０へ渡す。
【０１７６】
ヘッダ更新・パケット送信部２０は、処理対象のパケットのヘッダにおける送信先アドレスをサーバ２ａのＩＰアドレス”１９２．１６８．０．１”に変更する。そして、ヘッダ更新・パケット送信部２０は、このパケットをサーバ２ａに対して転送する。即ち、ヘッダ更新・パケット送信部２０は、このパケットに含まれるリクエストメッセージをサーバ２ａに転送する（ｓｅｑ２ａ）。
【０１７７】
サーバ２ａは、リクエストメッセージを受信すると、このリクエストメッセージ対するコンテンツからリプライメッセージを作成する。このとき、サーバ２ａは、リプライメッセージの中に、Ｃｏｏｋｉｅ情報を追加する。ここで、サーバ２ａは、Ｓｅｔ−Ｃｏｏｋｉｅコマンドとして、”Ｓｅｔ−Ｃｏｏｋｉｅ：Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１”を発行し、リプライメッセージに付加すると仮定する。そして、サーバ２ａは、このリプレイメッセージをクライアント１ａ宛に送信する。即ち、サーバ２ａは、このリプライメッセージを含むパケットをクライアント１ａ宛に送信する（ｓｅｑ３ａ）。このとき、このパケットの送信先アドレス及び送信先ポート番号は、”２０．０．０．１”及び”５０００”である。また、このとき、このパケットの送信元アドレス及び送信元ポート番号は”１９２．１６８．０．１”及び”８０”である。
【０１７８】
負荷分散装置１５ａがサーバ２ａからリプライメッセージを受信すると、ビット列抽出部２１はＣｏｏｋｉｅ情報の抽出を行う。ビット列抽出部２１は、”Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１”という文字列を抽出する。また、ビット列抽出部２１は、この文字列の先頭文字を書き換え開始位置として検出する。
【０１７９】
ＩＤ生成部２３は、サーバＩＤを生成する。ビット列・ＩＤ書換部２４は、ＩＤ生成部２３から、新しいサーバＩＤとして”ａ（ｅ％”を取得する。ビット列・ＩＤ書換部２４は、このサーバＩＤと、ビット列抽出部２１によって検出された書き換え開始位置以降の文字列とを置き換える。即ち、ビット列・ＩＤ書換部２４は、Ｃｏｏｋｉｅ情報を”ａ（ｅ％＝ｏｋｉｅＦｏｒＣｌｉｅｎｔ１”と書き換える。また、ビット列・ＩＤ書換部２４は、書換用テーブル２２Ａに、”Ｃ１＝Ｃｏ，ａ（ｅ％，１９２．１６８．０．１”というエントリを記録する。
【０１８０】
ヘッダ更新・パケット送信部２５は、パケットのヘッダにおける送信元アドレスをＶＩＰ１に変更し、クライアント１ａに対して転送する（ｓｅｑ４ａ）。
【０１８１】
クライアント１ａは、負荷分散装置１５ａからリプライメッセージを受信する。クライアント１ａは、受信されたリプライメッセージに含まれるＣｏｏｋｉｅ情報”ａ（ｅ％＝ｏｋｉｅＦｏｒＣｌｉｅｎｔ１”を、ローカルのＣｏｏｋｉｅ表に記録する。このとき、クライアント１ａは、未記入のパラメータについては、ｐａｔｈ＝／ｃｏｎｔｅｎｔｓ／、ｄｏｍａｉｎ＝ｗｗｗ．ｎｅｔ．ｃｏｍとして記録する。
【０１８２】
この後、クライアント１ａは、ｄｏｍａｉｎ＝ｗｗｗ．ｎｅｔ．ｃｏｍ，ｐａｔｈ＝／ｃｏｎｔｅｎｔｓ／に対応するコンテンツへリクエストメッセージを送信する場合、ローカルのＣｏｏｋｉｅ表から、このパスに対応付けて記録されたＣｏｏｋｉｅ情報”ａ（ｅ％＝ｏｋｉｅＦｏｒＣｌｉｅｎｔ１”を読み出す。そして、クライアント１ａは、読み出されたＣｏｏｋｉｅ情報”ａ（ｅ％＝ｏｋｉｅＦｏｒＣｌｉｅｎｔ１”を用いてリクエストメッセージを作成し、ＶＩＰ１宛にこのリクエストメッセージを含むパケットを送信する（ｓｅｑ５ａ）。このとき、このパケットの送信先アドレス及び送信先ポート番号は”１０．０．０．１”及び”８０”である。また、このとき、このパケットの送信元アドレス及び送信元ポート番号は、”２０．０．０．１”及び”５０００”である。
【０１８３】
負荷分散装置１５ａがクライアント１ａからこのリクエストメッセージを受信すると、まずビット列抽出部１７がＣｏｏｋｉｅ情報の抽出を実行する。ビット列抽出部１７は、Ｃｏｏｋｉｅ情報”ａ（ｅ％＝ｏｋｉｅＦｏｒＣｌｉｅｎｔ１”を抽出する。そして、ビット列抽出部１７は、サーバＩＤが”ａ（ｅ％”であると特定する。
【０１８４】
振り分け先サーバ決定部１８は、書換用テーブル２２Ａにおいて、サーバＩＤが”ａ（ｅ％”であるエントリを検索する。ここで、リプライメッセージの転送時に記録された”Ｃ１＝Ｃｏ，ａ（ｅ％，１９２．１６８．０．１”というエントリが検索される。このため、振り分け先サーバ決定部１８は、振り分け先となるサーバが、ＩＰアドレス”１９２．１６８．０．１”が設定されたサーバ２ａであることを特定する。また、振り分け先サーバ決定部１８は、文字列”ａ（ｅ％”の書き換えの際に使用される文字列が”Ｃ１＝Ｃｏ”であることを特定する。
【０１８５】
ＩＤ・ビット列書換部１９は、リクエストメッセージに含まれるＣｏｏｋｉｅ情報に対して書き換えを行い、”Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１”というＣｏｏｋｉｅ情報を生成する。即ち、ＩＤ・ビット列書換部１９は、サーバ２ａから発行されたＣｏｏｋｉｅ情報を復元する。
【０１８６】
ヘッダ更新・パケット送信部２０は、パケットのヘッダにおける送信先アドレスを、サーバ２ａのＩＰアドレスである”１９２．１６８．０．１”に変更する。そして、ヘッダ更新・パケット送信部２０は、サーバ２ａに対してリクエストメッセージを転送する（ｓｅｑ６ａ）。
【０１８７】
サーバ２ａは、リクエストメッセージを受信すると、このリクエストメッセージに対応するコンテンツからリプライメッセージを作成する。このとき、リプライメッセージに”Ｓｅｔ−Ｃｏｏｋｉｅ：Ｃ２＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ２”というＣｏｏｋｉｅ情報を付加すると仮定する。即ち、サーバ２ａは、受信されたリクエストメッセージに含まれるＣｏｏｋｉｅ情報と異なるＮＡＭＥ値を持つＣｏｏｋｉｅ情報を付加すると仮定する。そして、サーバ２ａは、クライアント１ａ宛に、このリプライメッセージを含むパケットを送信する（ｓｅｑ７ａ）。このとき、このパケットの送信先アドレス及び送信先ポート番号は、”２０．０．０．１”及び”５０００”である。また、このとき、このパケットの送信元アドレス及び送信元ポート番号は、”１９２．１６８．０．１”及び”８０”である。
【０１８８】
負荷分散装置１５ａがサーバ２ａからリプライメッセージを受信すると、ビット列抽出部２１がＣｏｏｋｉｅ情報の抽出を行う。そして、ビット列抽出部２１は、”Ｃ２＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ２”という文字列をＣｏｏｋｉｅ情報として抽出する。また、ビット列抽出部２１は、この文字列の先頭文字を書き換え開始位置として検出する。
【０１８９】
ビット列・ＩＤ書換部２４は、ＩＤ生成部２３から新しいサーバＩＤとして”ｂｅＰｅ”を取得する。ビット列・ＩＤ書換部２４は、このサーバＩＤと、ビット列抽出部２１によって検出された書き換え開始位置以降の文字列”Ｃ２＝Ｃｏ”を置き換え、Ｃｏｏｋｉｅ情報を”ｂｅＰｅ＝ｏｋｉｅＦｏｒＣｌｉｅｎｔ２”と書き換える。また、ビット列・ＩＤ書換部２４は、書換用テーブル２２Ａのエントリとして”Ｃ２＝Ｃｏ，ｂｅＰｅ，１９２．１６８．０．１”を記録する。
【０１９０】
ヘッダ更新・パケット送信部２５は、送信元アドレスをＶＩＰ１に変更し、クライアント１ａに対してリプライメッセージを転送する（ｓｅｑ８ａ）。
【０１９１】
クライアント１ａは、負荷分散装置１５ａからリプライメッセージを受信する。クライアント１ａは、受信されたリプライメッセージに含まれるＣｏｏｋｉｅ情報”ｂｅＰｅ＝ｏｋｉｅＦｏｒＣｌｉｅｎｔ２”を、ローカルのＣｏｏｋｉｅ表に記録する。このとき、クライアント１ａは、未記入のパラメータについては、ｐａｔｈ＝／ｃｏｎｔｅｎｔｓ／、ｄｏｍａｉｎ＝ｗｗｗ．ｎｅｔ．ｃｏｍとして記録する。
【０１９２】
〈作用・効果〉
本発明の第一実施形態によれば、ビット列・ＩＤ書換部２４が、サーバ２ａから発行されたＣｏｏｋｉｅ情報に対して、このＣｏｏｋｉｅ情報の発行元を示すサーバＩＤを上書きする。このとき、ビット列・ＩＤ書換部２４は、サーバＩＤと同じ長さ（”＝”を含まない状態で同じ長さ）のＣｏｏｋｉｅ情報の文字列に対してサーバＩＤを上書きする。そして、クライアント１ａは、サーバＩＤが上書きされたＣｏｏｋｉｅ情報を記憶し、リクエストメッセージを送信する際に、サーバＩＤが上書きされたＣｏｏｋｉｅ情報を添付する。このため、サーバＩＤが上書きされたＣｏｏｋｉｅ情報のサイズが変更されず、結果としてこのＣｏｏｋｉｅ情報を含むメッセージやパケットのサイズが変更されない。従って、サーバ２ａとクライアント１ａとの間でＴＣＰによるデータ到達の保障が実現され、負荷分散装置１５ａがＴＣＰによるデータ到達の保障を実施する必要がない。この結果、負荷分散装置１５ａにおいて負荷分散処理以外の処理に負荷を要しないため、Ｃｏｏｋｉｅ情報に応じた負荷分散処理によるパケット転送を高速に実現することが可能となる。
【０１９３】
〔第二実施形態〕
〈システム構成〉
図１４は、本発明による負荷分散装置１５の第二実施形態、即ち負荷分散装置１５ｂのブロック図である。負荷分散装置１５ｂについて、負荷分散装置１５ａと異なる構成についてのみ説明する。
【０１９４】
負荷分散装置１５ｂは、ＮＡＭＥビット列テーブル記憶部２６，ＮＡＭＥビット列記録部２７，ＮＡＭＥビット列比較部２８をさらに備える。
【０１９５】
ＮＡＭＥビット列テーブル記憶部２６は、ハードディスクやフラッシュメモリ等の不揮発性記憶装置やＲＡＭ等を用いて構成される。ＮＡＭＥビット列テーブル記憶部２６は、ＮＡＭＥビット列テーブル２６Ａを記憶する。図１５は、ＮＡＭＥビット列テーブル２６Ａの例を示す図である。ＮＡＭＥビット列テーブル２６Ａは、サーバ２ａに転送される時点のリクエストメッセージに含まれるＣｏｏｋｉｅ情報のＮＡＭＥ値と、クライアント１ａから受信された時点のリクエストメッセージに含まれるＣｏｏｋｉｅ情報におけるサーバＩＤとを対応付けたエントリを持つ。また、ＮＡＭＥビット列テーブル２６Ａにおけるエントリは、さらにクライアント１ａのＩＰアドレスとクライアント１ａのポート番号、即ちリクエストメッセージにおける送信元アドレスと送信元ポート番号とを対応付けて持つ。
【０１９６】
ＮＡＭＥビット列記録部２７は、ＣＰＵやＲＡＭ等を用いて構成される。ＮＡＭＥビット列記録部２７は、クライアント１ａから受信されたリクエストメッセージに含まれるサーバＩＤと、このリクエストメッセージがサーバ２ａに転送される時点でのＮＡＭＥ値とクライアント１ａのＩＰアドレス及びポート番号とを対応付けたエントリをＮＡＭＥビット列テーブル２６Ａに記録する。
【０１９７】
ＮＡＭＥビット列比較部２８は、ＣＰＵやＲＡＭ等を用いて構成される。ＮＡＭＥビット列比較部２８は、受信されたリプライメッセージに含まれるＣｏｏｋｉｅ情報のＮＡＭＥ値をキーとして、ＮＡＭＥビット列テーブル２６Ａを検索する。そして、ＮＡＭＥビット列比較部２８は、サーバ２ａから発行されたＣｏｏｋｉｅ情報に対し、新たなサーバＩＤを用いて上書きを行うか否かを判断する。即ち、受信されたリプライメッセージに含まれるＣｏｏｋｉｅ情報のＮＡＭＥ値が、過去に自装置１５ｂによって受信されたリクエストメッセージに含まれたＣｏｏｋｉｅ情報におけるＮＡＭＥ値と一致するか否かを判断する。
【０１９８】
ＮＡＭＥ値が一致した場合、ＮＡＭＥビット列比較部２８は、ＮＡＭＥ値に対応付けられたサーバＩＤを、ＮＡＭＥビット列テーブル２６Ａから取得する。そして、ＮＡＭＥビット列比較部２８は、ビット列・ＩＤ書換部２４ｂに対し、読み出されたサーバＩＤとともに同一判定報告を通知する。一方、一致するＮＡＭＥ値がＮＡＭＥビット列テーブル２６Ａに記録されていない場合、相違判定報告をビット列・ＩＤ書換部２４ｂに通知する。
【０１９９】
ビット列・ＩＤ書換部２４ｂは、ＮＡＭＥビット列比較部２８からサーバＩＤとともに同一判定報告を通知された場合、通知されたサーバＩＤを用いてＣｏｏｋｉｅ情報の上書きを実行する点で、ビット列・ＩＤ書換部２４と異なる。なお、ビット列・ＩＤ書換部２４ｂは、ＮＡＭＥビット列比較部２８から相違判定報告を通知された場合、ビット列・ＩＤ書換部２４と同様の処理を実行する。
【０２００】
〈動作シーケンス〉
図１６は、第二実施形態による負荷分散装置１５ｂを用いた負荷分散システム１４における動作シーケンスの例を示す図である。以下、第二実施形態における動作シーケンスについて、第一実施形態と異なる動作についてのみ説明する。
【０２０１】
ｓｅｑ１ｂ〜ｓｅｑ５ｂにおける処理は、第一実施形態におけるｓｅｑ１ａ〜ｓｅｑ５ａにおける処理と同様である。このため、説明を省略する。
【０２０２】
負荷分散装置１５ｂがクライアント１ａからリクエストメッセージを受信すると（ｓｅｑ５ｂ）、まずビット列抽出部１７が、受信されたリクエストメッセージに含まれるＣｏｏｋｉｅ情報を抽出する。そして、ビット列抽出部１７は、Ｃｏｏｋｉｅ情報 ”ａ（ｅ％＝ｏｋｉｅＦｏｒＣｌｉｅｎｔ１”を抽出し、サーバＩＤが”ａ（ｅ％”であると特定する。また、ビット列抽出部１７は、書き換え開始位置を特定する。
【０２０３】
振り分け先サーバ決定部１８は、書換用テーブル２２ＡにおいてサーバＩＤが”ａ（ｅ％”であるエントリを検索する。検索の結果、振り分け先サーバ決定部１８は、”Ｃ１＝Ｃｏ，ａ（ｅ％，１９２．１６８．０．１”というエントリを読み出す。即ち、振り分け先サーバ決定部１８は、上書きする文字列が”Ｃ１＝Ｃｏ”、振り分け先となるサーバのＩＰアドレスが”１９２．１６８．０．１”であると特定する。
【０２０４】
ＮＡＭＥビット列記録部２７は、サーバＩＤ，ＮＡＭＥ値，クライアントのＩＰアドレス，クライアントのポート番号夫々の値が”ａ（ｅ％”，”Ｃ１”，”２０．０．０．１”，”５０００”であるエントリをＮＡＭＥビット列テーブル２６Ａに記録する。
【０２０５】
ＩＤ・ビット列書換部１９は、リクエストメッセージに含まれるＣｏｏｋｉｅ情報に対して、振り分け先サーバ決定部１８によって読み出された文字列”Ｃ１＝Ｃｏ”を用いて、文字列”ａ（ｅ％”を上書きする。即ち、ＩＤ・ビット列書換部１９は、リクエストメッセージにおいて、サーバ２ａによって発行されたＣｏｏｋｉｅ情報”Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１”を復元する。
【０２０６】
ヘッダ更新・パケット送信部２０は、パケットのヘッダにおける送信先アドレスを、振り分け先サーバ決定部１８によって読み出されたＩＰアドレス”１９２．１６８．０．１”に変更する。即ち、ヘッダ更新・パケット送信部２０は、パケットの送信先をサーバ２ａと設定する。そして、ヘッダ更新・パケット送信部２０は、サーバ２ａに対してリクエストメッセージを転送する（ｓｅｑ６ｂ）。
【０２０７】
サーバ２ａはリクエストメッセージを受信すると、このリクエストメッセージに対応するコンテンツからリプライメッセージを作成する。このとき、サーバ２ａは、リプライメッセージにＳｅｔ−Ｃｏｏｋｉｅコマンドとして”Ｓｅｔ−Ｃｏｏｋｉｅ：Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ２”を付加すると仮定する。即ち、サーバ２ａは、受信されたリクエストメッセージと同じＮＡＭＥ値を持ち、異なるＶＡＬＵＥ値を持つＣｏｏｋｉｅ情報を付加すると仮定する。そして、サーバ２ａは、クライアント１ａ宛に、リプライメッセージを含むパケットを送信する（ｓｅｑ７ｂ）。このとき、このパケットの送信先アドレス及び送信先ポート番号は、”２０．０．０．１”及び”５０００”である。また、このとき、このパケットの送信元アドレス及び送信元ポート番号は、”１９２．１６８．０．１”及び”８０”である。
【０２０８】
負荷分散装置１５ｂがサーバ２ａからリプライメッセージを受信すると、ビット列抽出部２１がＣｏｏｋｉｅ情報を抽出する。ビット列抽出部２１は、Ｃｏｏｋｉｅ情報として、”Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ２”という文字列を抽出する。
【０２０９】
ＮＡＭＥビット列比較部２８は、抽出されたＣｏｏｋｉｅ情報のＮＡＭＥ値”Ｃ１”をキーとして、ＮＡＭＥビット列テーブル２６Ａを検索する。この結果、ＮＡＭＥビット列比較部２８は、ＮＡＭＥ値”Ｃ１”に対応するサーバＩＤとして”ａ（ｅ％”を読み出す。そして、ＮＡＭＥビット列比較部２８は、このサーバＩＤを示す文字列を、同一判定報告とともにビット列・ＩＤ書換部２４ｂに通知する。
【０２１０】
ビット列・ＩＤ書換部２４ｂは、ＮＡＭＥビット列比較部２８から、同一判定報告とともに、サーバＩＤ”ａ（ｅ％”を通知される。ビット列・ＩＤ書換部２４ｂは、このサーバＩＤ及び”＝”から構成される５文字の文字列と、リプライメッセージに含まれるＣｏｏｋｉｅ情報の先頭から５文字とを書き換える。そして、ビット列・ＩＤ書換部２４ｂは、リプライメッセージのＣｏｏｋｉｅ情報を”ａ（ｅ％＝ｋｉｅＦｏｒＣｌｉｅｎｔ２”と書き換える。また、ビット列・ＩＤ書換部２４ｂは、書換用テーブル２２Ａに、サーバＩＤ（書換後文字列），書換前文字列，及びサーバＩＰアドレスとして、”ａ（ｅ％”，”Ｃ２＝Ｃｏ”，”１９２．１６８．０．１”をもつエントリを記録する。
【０２１１】
ヘッダ更新・パケット送信部２５は、このリプライメッセージを含むパケットの送信元アドレスをＶＩＰ１に変更する。そして、ヘッダ更新・パケット送信部２５は、クライアント１ａに対してリプライメッセージを転送する。
【０２１２】
クライアント１ａは、リプライメッセージを負荷分散装置１５ｂから受信する。クライアント１ａは、受信されたリプライメッセージに含まれるＣｏｏｋｉｅ情報 ”ａ（ｅ％＝ｋｉｅＦｏｒＣｌｉｅｎｔ２”をローカルのＣｏｏｋｉｅ表に記録する。このとき、クライアント１ａは、既に記録されているＣｏｏｋｉｅ情報 ”ａ（ｅ％＝ｏｋｉｅＦｏｒＣｌｉｅｎｔ１”のエントリを上書きする。即ち、この二つのＣｏｏｋｉｅ情報のＮＡＭＥ値が一致しているため、クライアント１ａは、最新のＣｏｏｋｉｅ情報を用いて、エントリを上書きする。このとき、クライアント１ａは、未記入のパラメータについては、ｐａｔｈ＝／ｃｏｎｔｅｎｔｓ／、ｄｏｍａｉｎ＝ｗｗｗ．ｎｅｔ．ｃｏｍとして記録する。
【０２１３】
〈作用・効果〉
第二実施形態によれば、ＮＡＭＥビット列比較部２８が、過去に自装置１５ｂに受信されたリクエストメッセージに含まれたＣｏｏｋｉｅ情報におけるＮＡＭＥ値と同一のＮＡＭＥ値を持つリプライメッセージを検出する。ＮＡＭＥビット列比較部２８は、このＮＡＭＥ値に対応付けられたサーバＩＤをＮＡＭＥビット列テーブル２６Ａから読み出し、ビット列・ＩＤ書換部２４ｂに通知する。そして、ビット列・ＩＤ書換部２４ｂは、通知されたサーバＩＤを用いて、このリプライメッセージに含まれるＣｏｏｋｉｅ情報の書き換えを実行する。このため、同一のＮＡＭＥ値を持つＣｏｏｋｉｅ情報には同一のサーバＩＤが付与される。つまり、同一のＮＡＭＥ値を持つＣｏｏｋｉｅ情報は、同一のＮＡＭＥ値を持つＣｏｏｋｉｅ情報となるように、サーバＩＤが付加される。従って、サーバ２ａによって発行された同一のＮＡＭＥ値を持つＣｏｏｋｉｅ情報は、負荷分散装置１５ｂによってＣｏｏｋｉｅ情報の書き換えが実行されたとしても、同じＮＡＭＥ値のＣｏｏｋｉｅ情報としてクライアント１ａに転送される。
【０２１４】
〈変形例〉
ＮＡＭＥビット列テーブル２６Ａは、エントリの項目として、対応するＣｏｏｋｉｅ情報の有効期限を持つように構成されても良い。この場合、有効期限の切れたエントリは、ＮＡＭＥビット列テーブル２６Ａから消去される。
【０２１５】
〔第三実施形態〕
〈システム構成〉
図１７は、本発明による負荷分散装置１５の第三実施形態、即ち負荷分散装置１５ｃのブロック図である。負荷分散装置１５ｃについて、負荷分散装置１５ａと異なる構成についてのみ説明する。
【０２１６】
負荷分散装置１５ｃは、ＮＡＭＥフィルタ部２９，３０をさらに備える。また、負荷分散装置１５ｃは、ビット列・ＩＤ書換部２４に換えてビット列・ＩＤ書換部２４ｃを備える。また、負荷分散装置１５ｃは、ＩＤ・ビット列書換部１９に換えてＩＤ・ビット列書換部１９ｃを備える。また、負荷分散装置１５ｃは、振り分け先サーバ決定部１８に換えて振り分け先サーバ決定部１８ｃを備える。
【０２１７】
ＮＡＭＥフィルタ部２９，３０は、ＣＰＵやＲＡＭや不揮発性記憶装置等を用いて構成される。ＮＡＭＥフィルタ部２９，３０は、自身が備える不揮発性記憶装置に、Ｃｏｏｋｉｅ情報のＮＡＭＥ値を記憶する。ＮＡＭＥフィルタ部２９，３０は、書き換えの対象外となるＣｏｏｋｉｅ情報を判断するために、ＮＡＭＥ値を記憶する。ＮＡＭＥフィルタ部２９，３０は、受信されたメッセージに含まれるＣｏｏｋｉｅ情報のＮＡＭＥ値が、自身が記憶するＮＡＭＥ値と一致するか否かを判断する。一致する場合、ＮＡＭＥフィルタ部２９，３０は、このメッセージをビット列・ＩＤ書換部２４ｃに渡す。
【０２１８】
一方、ＮＡＭＥフィルタ部３０は、自身が記憶するＮＡＭＥ値と同じＮＡＭＥ値を持つＣｏｏｋｉｅ情報を含んだリプライメッセージについては、第一の解決方法を適用する。即ち、ＮＡＭＥフィルタ部３０は、サーバＩＤを含む新たなＣｏｏｋｉｅ情報（挿入Ｃｏｏｋｉｅ情報）をリプライメッセージに挿入するように、ビット列・ＩＤ書換部２４に通知する。
【０２１９】
ＮＡＭＥフィルタ部２９は、自身が記憶するＮＡＭＥ値と同じＮＡＭＥ値を持つＣｏｏｋｉｅ情報を含んだリクエストメッセージについては、挿入Ｃｏｏｋｉｅ情報からサーバＩＤを読み出すように、振り分け先サーバ決定部１８ｃに通知する。
【０２２０】
ビット列・ＩＤ書換部２４ｃは、ＮＡＭＥフィルタ部３０から挿入Ｃｏｏｋｉｅ情報を挿入するように通知された場合、リプライメッセージに挿入Ｃｏｏｋｉｅ情報を挿入する。
【０２２１】
振り分け先サーバ決定部１８ｃは、ＮＡＭＥフィルタ部２９から挿入Ｃｏｏｋｉｅ情報の読み出しを通知された場合、リクエストメッセージから挿入Ｃｏｏｋｉｅ情報を読み出し、この挿入Ｃｏｏｋｉｅ情報からサーバＩＤを抽出する。そして、振り分け先サーバ決定部１８ｃは、このサーバＩＤを用いて振り分け先となるサーバを決定する。このとき、振り分け先サーバ決定部１８ｃは、挿入Ｃｏｏｋｉｅ情報削除命令を、ＩＤ・ビット列書換部１９ｃに通知する。
【０２２２】
ＩＤ・ビット列書換部１９ｃは、挿入Ｃｏｏｋｉｅ情報削除命令を通知されると、リクエストメッセージから挿入Ｃｏｏｋｉｅ情報を削除する。ここで、挿入Ｃｏｏｋｉｅ情報は、ＮＡＭＥ値やＶＡＬＵＥ値をもって挿入Ｃｏｏｋｉｅ情報であると判断される。
【０２２３】
〈動作シーケンス〉
図１８は、第三実施形態による負荷分散装置１５ｃを用いた負荷分散システム１４における動作シーケンスの例を示す図である。以下、第三実施形態における動作シーケンスについて、第一実施形態と異なる動作についてのみ説明する。
【０２２４】
ここでは、サーバ２ａがｓｅｑ３ｃ及びｓｅｑ７ｃにおけるリプライメッセージに付加したＣｏｏｋｉｅ情報を、クライアント１ａで実行されるプログラム（例：ＪａｖａＳｃｒｉｐｔ）が利用すると仮定する。このため、負荷分散装置１５ｃは、ｓｅｑ３ｃ及びｓｅｑ７ｃにおけるリプライメッセージ、即ち”Ｃ１”というＮＡＭＥ値を持つＣｏｏｋｉｅ情報を含んだリプライメッセージについては書き換えを実行しないように設定される。この設定は、負荷分散装置１５ｃの管理者などによって実行される。
【０２２５】
ｓｅｑ１ｃ〜ｓｅｑ３ｃにおける処理は、第一実施形態におけるｓｅｑ１ａ〜ｓｅｑ３ａにおける処理と同様である。このため、説明を省略する。
【０２２６】
負荷分散装置１５ｃがサーバ２ａからリプライメッセージを受信すると（ｓｅｑ３ｃ）、ビット列抽出部２１がＣｏｏｋｉｅ情報を抽出する。そして、ビット列抽出部２１は、Ｃｏｏｋｉｅ情報として”Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１”という文字列を抽出する。
【０２２７】
ＮＡＭＥフィルタ部３０は、ビット列抽出部２１によって抽出されたＣｏｏｋｉｅ情報が書き換え対象外のＣｏｏｋｉｅ情報であるか否かを確認する。ここで、ＮＡＭＥ値”Ｃ１”は、書き換え対象外のＮＡＭＥ値として記憶されていると仮定する。即ち、ＮＡＭＥフィルタ部３０は、ＮＡＭＥ値”Ｃ１”を記憶していると仮定する。このため、ビット列・ＩＤ書換部２４ｃは、このリプライメッセージに対し、挿入Ｃｏｏｋｉｅ情報を挿入する。
【０２２８】
ヘッダ更新・パケット送信部２５は、パケットのヘッダにおける送信元アドレスをＶＩＰ１に変更する。そして、ヘッダ更新・パケット送信部２５は、クライアント１ａに対してこのリプライメッセージを転送する（ｓｅｑ４ｃ）。
【０２２９】
クライアント１ａは、負荷分散装置１５ｃからリプライメッセージを受信する。クライアント１ａは、受信されたリプライメッセージに含まれるＣｏｏｋｉｅ情報”Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１”及び挿入Ｃｏｏｋｉｅ情報をローカルのＣｏｏｋｉｅ表に記録する。このとき、クライアント１ａは、いずれのＣｏｏｋｉｅ情報についても、未記入のパラメータについては、ｐａｔｈ＝／ｃｏｎｔｅｎｔｓ／、ｄｏｍａｉｎ＝ｗｗｗ．ｎｅｔ．ｃｏｍとして記録する。
【０２３０】
クライアント１ａは、例えばＪａｖａＳｃｒｉｐｔのようなプログラムを実行し、このプログラムで用いられるＣｏｏｋｉｅ情報をローカルのＣｏｏｋｉｅ表から読み出す。ここでは、Ｃｏｏｋｉｅ情報”Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１”が読み出され、プログラムで用いられると仮定する。このため、クライアント１ａは、ローカルのＣｏｏｋｉｅ表から、ｓｅｑ４ｃにおいて受信されたリプライメッセージに含まれていたＣｏｏｋｉｅ情報”Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１”を読み出す。
【０２３１】
次に、クライアント１ａは、ＶＩＰ１宛のリクエストメッセージを送信する際に、Ｃｏｏｋｉｅ情報”Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１”及び挿入Ｃｏｏｋｉｅ情報を読み出し、リクエストメッセージを作成する。そして、クライアント１ａは、このリクエストメッセージを含むパケットをＶＩＰ１宛に送信する（ｓｅｑ５ｃ）。このとき、送信先アドレス及び送信先ポート番号は、”１０．０．０．１”及び”８０”である。また、このとき、送信元アドレス及び送信元ポート番号は、”２０．０．０．１”及び”５０００”である。
【０２３２】
負荷分散装置１５ｃがクライアント１ａからリクエストメッセージを受信すると、まずビット列抽出部１７がＣｏｏｋｉｅ情報を抽出する。この結果、ビット列抽出部１７は、Ｃｏｏｋｉｅ情報”Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１”及び挿入Ｃｏｏｋｉｅ情報を抽出する。
【０２３３】
ＮＡＭＥフィルタ部２９は、ビット列抽出部１７によって抽出されたリクエストメッセージに含まれるＣｏｏｋｉｅ情報のＮＡＭＥ値”Ｃ１”が、書き換え対象外として記憶されるＮＡＭＥ値と一致するか否かを判断する。ここで、ＮＡＭＥ値”Ｃ１”は、書き換え対象外のＮＡＭＥ値として記憶されているため、振り分け先サーバ決定部１８ｃは、挿入Ｃｏｏｋｉｅ情報からサーバＩＤを読み出す。このとき、挿入Ｃｏｏｋｉｅ情報は、例えばＮＡＭＥ値によって挿入Ｃｏｏｋｉｅ情報であると判断される。振り分け先サーバ決定部１８ｃは、読み出したサーバＩＤをもとに、振り分け先となるサーバを決定する。即ち、振り分け先サーバ決定部１８ｃサーバ２ａを振り分け先のサーバとして決定する。そして、振り分け先サーバ決定部１８ｃは、挿入Ｃｏｏｋｉｅ削除命令を、ＩＤ・ビット列書換部１９ｃに通知する。ＩＤ・ビット列書換部１９ｃは、挿入Ｃｏｏｋｉｅ情報をリクエストメッセージから削除する。
【０２３４】
ヘッダ更新・パケット送信部２０は、パケットのヘッダにおける送信先アドレスを、振り分け先のサーバであるサーバ２ａのＩＰアドレス”１９２．１６８．０．１”に変更する。そして、ヘッダ更新・パケット送信部２０は、サーバ２ａに対してリクエストメッセージを転送する（ｓｅｑ６ｃ）。
【０２３５】
サーバ２ａは、リクエストメッセージを受信すると、このリクエストメッセージに対応するコンテンツからリプライメッセージを作成する。このとき、サーバ２ａは、リプライメッセージに、Ｃｏｏｋｉｅ情報を付加する。ここで、サーバ２ａは、Ｓｅｔ−Ｃｏｏｋｉｅコマンドとして、”Ｓｅｔ−Ｃｏｏｋｉｅ：Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ２”を発行し、リプライメッセージに付加すると仮定する。そして、サーバ２ａは、このリプライメッセージをクライアント１ａ宛に送信する。即ち、サーバ２ａは、このリプライメッセージを含むパケットをクライアント１ａ宛に送信する（ｓｅｑ７ｃ）。
【０２３６】
以降、このリプライメッセージに関する負荷分散装置１５ｃ及びクライアント１ａの動作は、ｓｅｑ３ｃ及びｓｅｑ４ｃにおけるリプライメッセージに関する動作と同様（ただし、クライアント１ａのローカルのＣｏｏｋｉｅ表において、同一ＮＡＭＥ値を持つＣｏｏｋｉｅ情報の上書きは実行される）である。このため、説明を省略する。
【０２３７】
〈作用・効果〉
第三実施形態によれば、あらかじめＣｏｏｋｉｅ情報の書き換えの対象外とされるＣｏｏｋｉｅ情報のＮＡＭＥ値がＮＡＭＥフィルタ部２９，３０に登録される。そして、ＮＡＭＥフィルタ部２９，３０に登録されているＮＡＭＥ値を持つＣｏｏｋｉｅ情報については、ビット列・ＩＤ書換部２４ｃ，１９ｃ，振り分け先サーバ決定部１８ｃにおいて、Ｃｏｏｋｉｅ情報の書き換え等が実行されずに、従来技術である第一の解決方法を用いた処理が実行される。このため、ＮＡＭＥ値があらかじめＮＡＭＥ値フィルタ部２９，３０に設定されることにより、このＮＡＭＥ値を持つＣｏｏｋｉｅ情報は、サーバ２ａによって発行された状態でクライアント１ａに通知される。第三実施形態による負荷分散装置１５ｃは、クライアント１ａにおいて実行されるプログラム等が、サーバ２ａによって発行されるＣｏｏｋｉｅ情報を用いることを前提とされている場合などに有効である。
【０２３８】
〈変形例〉
Ｃｏｏｋｉｅ情報の書き換えを実行しない場合に適用される方法は、第三実施形態における作用・効果が失われない範囲内であれば、第一の解決方法とは異なる方法であっても良い。
【０２３９】
〔第四実施形態〕
〈システム構成〉
図１９は、本発明による負荷分散装置１５の第四実施形態、即ち負荷分散装置１５ｄのブロック図である。負荷分散装置１５ｄについて、負荷分散装置１５ａと異なる構成についてのみ説明する。
【０２４０】
負荷分散装置１５ｄは、ドメインフィルタ部３１をさらに備える。
【０２４１】
ドメインフィルタ部３１は、ＣＰＵやＲＡＭや不揮発性記憶装置等を用いて構成される。ドメインフィルタ部３１は、自身が備える不揮発性記憶装置に、書き換え対象となるＣｏｏｋｉｅ情報のＤＯＭＡＩＮ＿ＮＡＭＥ値を記憶する。ドメインフィルタ部３１は、自身が記憶するＤＯＭＡＩＮ＿ＮＡＭＥ値を持つＣｏｏｋｉｅ情報については、Ｃｏｏｋｉｅ情報の書き換えを実行するため、このＣｏｏｋｉｅ情報を含むパケットをビット列・ＩＤ書換部２４に渡す。一方、ドメインフィルタ部３１は、自身が記憶しないＤＯＭＡＩＮ＿ＮＡＭＥ値を持つＣｏｏｋｉｅ情報については、Ｃｏｏｋｉｅ情報の書き換えを実行しないため、このＣｏｏｋｉｅ情報を含むパケットを、ヘッダ更新・パケット送信部２５へバイパスする。
【０２４２】
〈動作シーケンス〉
図２０は、第四実施形態による負荷分散装置１５ｄを用いた負荷分散システム１４における動作シーケンスの例を示す図である。以下、第四実施形態における動作シーケンスについて、第一実施形態と異なる動作についてのみ説明する。
【０２４３】
ここでは、サーバ２ａによって発行されたＣｏｏｋｉｅ情報が、サーバ２ａと管理ドメインが異なるサーバ２ｄに対し、クライアント１ａによって送信される状況を仮定する。このために、負荷分散装置１５ｄは、自身１５ｄが管理するドメイン名として”ｗｗｗ．ｎｅｔ．ｃｏｍ”が設定される。この設定は、負荷分散装置１５ｄの管理者などによって実行される。
【０２４４】
ｓｅｑ１ｄ〜ｓｅｑ２ｄにおける処理は、第一実施形態におけるｓｅｑ１ａ〜ｓｅｑ２ａにおける処理と同様である。
【０２４５】
サーバ２ａは、ｓｅｑ２ｄにおけるリクエストメッセージを受信すると、このリクエストメッセージに対応するコンテンツからリプライメッセージを作成する。このとき、サーバ２ａは、リプライメッセージに、Ｃｏｏｋｉｅ情報を付加する。ここで、サーバ２ａは、Ｓｅｔ−Ｃｏｏｋｉｅコマンドとして、”Ｓｅｔ−Ｃｏｏｋｉｅ：Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１ ｄｏｍａｉｎ＝ｗｗｗ．ｎｅｔｗｏｒｋ．ｏｒ．ｊｐ”を発行し、リプライメッセージに付加すると仮定する。そして、サーバ２ａは、このリプライメッセージをクライアント１ａ宛に送信する。即ち、サーバ２ａは、このリプライメッセージを含むパケットをクライアント１ａ宛に送信する（ｓｅｑ３ｄ）。このとき、送信先アドレス及び送信先ポート番号は、”２０．０．０．１”及び”５０００”である。また、このとき、送信元アドレス及び送信元ポート番号は、”１９２．１６８．０．１”及び”８０”である。
【０２４６】
負荷分散装置１５ｄがサーバ２ａからリプライメッセージを受信すると、ビット列抽出部２１がＣｏｏｋｉｅ情報を抽出する。そして、ビット列抽出部２１は、Ｃｏｏｋｉｅ情報として”Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１ ｄｏｍａｉｎ＝ｗｗｗ．ｎｅｔｗｏｒｋ．ｏｒ．ｊｐ”という文字列を抽出する。
【０２４７】
ドメインフィルタ部３１は、ビット列抽出部２１によって抽出されたＣｏｏｋｉｅ情報のＤＯＭＡＩＮ＿ＮＡＭＥ値がバイパス対象のＤＯＭＡＩＮ＿ＮＡＭＥ値であるか否かを確認する。ここで、ＤＯＭＡＩＮ＿ＮＡＭＥ値”ｗｗｗ．ｎｅｔ．ｃｏｍ”は、バイパス対象外のＤＯＭＡＩＮ＿ＮＡＭＥ値として記憶されている。一方、ドメインフィルタ部３１は、ＤＯＭＡＩＮ＿ＮＡＭＥ値”ｗｗｗ．ｎｅｔｗｏｒｋ．ｏｒ．ｊｐ”を記憶していない。このため、このリプライメッセージについては、Ｃｏｏｋｉｅ情報を書き換える処理がバイパスされる。従って、ドメインフィルタ部３１は、このリプライメッセージをヘッダ更新・パケット送信部２５へバイパスする。
【０２４８】
ヘッダ更新・パケット送信部２５は、このパケットのヘッダにおける送信元アドレスをＶＩＰ１に変更する。そして、ヘッダ更新・パケット送信部２５は、クライアント１ａに対してこのリプライメッセージを転送する（ｓｅｑ４ｄ）。
【０２４９】
クライアント１ａは、負荷分散装置１５ｄからリプライメッセージを受信する。クライアント１ａは、受信されたリプライメッセージに含まれるＣｏｏｋｉｅ情報”Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１ ｄｏｍａｉｎ＝ｗｗｗ．ｎｅｔｗｏｒｋ．ｏｒ．ｊｐ”をローカルのＣｏｏｋｉｅ表に記録する。
【０２５０】
次に、クライアント１ａは、サーバ２ｄ宛のリクエストメッセージを送信する際に、Ｃｏｏｋｉｅ情報”Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１ ｄｏｍａｉｎ＝ｗｗｗ．ｎｅｔｗｏｒｋ．ｏｒ．ｊｐ”を読み出し、リクエストメッセージを作成する。そして、クライアント１ａは、このリクエストメッセージを含むパケットを、サーバ２ｄ宛に送信する（ｓｅｑ５ｄ）。このとき、送信先アドレス及び送信先ポート番号は”８０．０．０．１”及び”８０”である。また、このとき、送信元アドレス及び送信元ポート番号は、”２０．０．０．１”及び”５０００”である。
【０２５１】
サーバ２ｄは、クライアント１ａからＣｏｏｋｉｅ情報”Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１ ｄｏｍａｉｎ＝ｗｗｗ．ｎｅｔｗｏｒｋ．ｏｒ．ｊｐ”が付加されたリクエストメッセージを受信する。
【０２５２】
〈作用・効果〉
第四実施形態によれば、あらかじめＣｏｏｋｉｅ情報の置き換えの対象外とされるＣｏｏｋｉｅ情報のＤＯＭＡＩＮ＿ＮＡＭＥ値がドメインフィルタ部３１に登録される。そして、ＤＯＭＡＩＮ＿ＮＡＭＥフィルタ部３１は、登録されているＤＯＭＡＩＮ＿ＮＡＭＥ値を持つＣｏｏｋｉｅ情報については、書き換えが実行されないように、このＣｏｏｋｉｅ情報を含むパケットをヘッダ更新・パケット送信部２５へバイパスする。このため、ＤＯＭＡＩＮ＿ＮＡＭＥ値があらかじめドメインフィルタ部３１に設定されることにより、このＤＯＭＡＩＮ＿ＮＡＭＥ値を持つＣｏｏｋｉｅ情報は、サーバ２ａによって発行された状態でクライアント１ａ，サーバ２ｄに通知される。第四実施形態による負荷分散装置１５ｄは、サーバ２ａによって発行されたＣｏｏｋｉｅ情報が、クライアント１ａを経由して、負荷分散装置１５ｄの管理外となるドメインに設置されたサーバ２ｄに通知される場合などに有効である。
【０２５３】
〔第五実施形態〕
〈システム構成〉
図２１は、本発明による負荷分散装置１５の第五実施形態、即ち負荷分散装置１５ｅのブロック図である。負荷分散装置１５ｅについて、負荷分散装置１５ａと異なる構成についてのみ説明する。
【０２５４】
負荷分散装置１５ｅは、テーブルエントリ消去部３２をさらに備える。また、負荷分散装置１５ｅは、書換用テーブル記憶部２２に換えて書換用テーブル記憶部２２ｅを備える。また、負荷分散装置１５ｅは、ビット列・ＩＤ書換部２４に換えてビット列・ＩＤ書換部２４ｅを備える。
【０２５５】
書換用テーブル記憶部２２ｅは、書換用テーブル２２に換えて書換用テーブル２２Ｂを記憶する点で書換用テーブル記憶部２２と異なる。図２２は、書換用テーブル２２Ｂの例を示す図である。書換用テーブル２２Ｂは、エントリの項目として、ＬＲＵ用ビット及び有効期限をさらに持つ点で、書換用テーブル２２Ａと異なる。
【０２５６】
ＬＲＵ用ビットは、”０”又は”１”のいずれかの値を持ち、エントリが記録されたばかりの状態、即ち初期状態では”１”を持つ。また、書換用テーブル２２Ｂにおいてあるエントリが消去された場合に、全てのエントリにおけるＬＲＵ用ビットは”０”の値に書き換えられる。ＬＲＵ用ビットは、対応するエントリが、振り分け先サーバ決定部１８又はビット列・ＩＤ書換部２４ｅによってアクセス（読み込み）された場合、”１”に書き換えられる。このため、ＬＲＵ用ビットが”０”であるエントリは、前回のエントリ消去から一度もアクセスされていないことがわかる。
【０２５７】
有効期限の値は、対応するエントリの有効期限を示す値であり、日，月，年，時，分，秒の値を持つ。有効期限の値は、ＧＭＴ（Greenwich Mean Time）として記録されても良い。
【０２５８】
テーブルエントリ消去部３２は、ＣＰＵやＲＡＭ等を用いて構成される。テーブルエントリ消去部３２は、新たなサーバＩＤが発行されてＣｏｏｋｉｅ情報に対する上書きが実行される場合に、書換用テーブル２２Ｂのエントリから有効期限の切れているエントリを検索する。テーブルエントリ消去部３２は、有効期限の切れているエントリを検出した場合、このエントリに対して新たに書き込まれるエントリを上書きするようにビット列・ＩＤ書換部２４ｅに指示する。
【０２５９】
ビット列・ＩＤ書換部２４ｅは、テーブルエントリ消去部３２から受ける指示に応じて、新たなエントリを上書きする対象となるエントリを選択する点で、ビット列・ＩＤ書換部２４と異なる。即ち、ビット列・ＩＤ書換部２４ｅは、エントリを書換用テーブル２２Ｂへ記録する際に、テーブルエントリ消去部３２によって上書き用のエントリが指定されている場合、指定されたエントリに上書きすることによって新たなエントリを記録する。また、ビット列・ＩＤ書換部２４ｅは、テーブルエントリ消去部３２によるエントリの指定が無い場合、ＬＲＵ（Latest Recently Used）のアルゴリズムを用いて上書きするエントリを選択し、記録する。この場合、ビット列・ＩＤ書換部２４ｅは、書換用テーブル２２Ｂにおいて、ＬＲＵ用ビットが”０”であるエントリを上書きするエントリとして１つ選択し、このエントリに対して新たなエントリを上書きする。
【０２６０】
〈動作シーケンス〉
図２３は、第五実施形態による負荷分散装置１５ｅを用いた負荷分散システム１４における動作シーケンスの例を示す図である。以下、第五実施形態における動作シーケンスについて、第一実施形態と異なる動作についてのみ説明する。
【０２６１】
ここでは、ｓｅｑ３ｅにおけるリプライメッセージに付加されたＣｏｏｋｉｅ情報に有効期限が指定されており、この有効期限がｓｅｑ７ｅにおけるリプライメッセージが負荷分散装置１５ｅに受信された時点で切れるという状況を仮定する。
【０２６２】
ｓｅｑ１ｅ〜ｓｅｑ２ｅにおける処理は、第一実施形態におけるｓｅｑ１ａ〜ｓｅｑ２ａにおける処理と同様である。このため、説明を省略する。
【０２６３】
サーバ２ａは、ｓｅｑ２ｅにおけるリクエストメッセージを受信すると、このリクエストメッセージに対応するコンテンツからリプライメッセージを作成する。このとき、サーバ２は、リプライメッセージに、Ｃｏｏｋｉｅ情報を付加する。ここで、サーバ２ａは、Ｓｅｔ−Ｃｏｏｋｉｅコマンドとして、”Ｓｅｔ−Ｃｏｏｋｉｅ：Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１ ｅｘｐｉｒｅ＝Ｓａｔ，０４−Ａｐｒ−２００２ ０９：３０：３０ ＧＭＴ”を発行し、リプライメッセージに付加すると仮定する。そして、サーバ２ａは、このリプライメッセージをクライアント１ａ宛に送信する。即ち、サーバ２ａは、このリプライメッセージを含むパケットをクライアント１ａ宛に送信する（ｓｅｑ３ｅ）。このとき、送信先アドレス及び送信先ポート番号は、”２０．０．０．１”及び”５０００”である。また、このとき、送信元アドレス及び送信元ポート番号は、”１９２．１６８．０．１”及び”８０”である。
【０２６４】
負荷分散装置１５ｅがサーバ２ａからリプライメッセージを受信すると、ビット列抽出部２１がＣｏｏｋｉｅ情報を抽出する。そして、ビット列抽出部２１は、Ｃｏｏｋｉｅ情報として”Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１ ｅｘｐｉｒｅ＝Ｓａｔ， ０４−Ａｐｒ−２００２ ０９：３０：３０ ＧＭＴ”という文字列を抽出する。また、ビット列抽出部２１は、この文字列の先頭文字を書き換え開始位置として検出する。
【０２６５】
テーブルエントリ消去部３２は、有効期限の切れたエントリの有無を確認する。即ち、テーブルエントリ消去部３２は、書換用テーブル２２Ｂに記録された各エントリの有効期限を参照し、有効期限の切れたエントリを検索する。ここでは、有効期限の切れたエントリが無いと仮定する。このため、テーブルエントリ消去部３２は、ビット列・ＩＤ書換部２４ｅに対し通知を行わない。
【０２６６】
ビット列・ＩＤ書換部２４ｅは、ＩＤ生成部２３から新しいサーバＩＤ”ａ（ｅ％”を取得する。ビット列・ＩＤ書換部２４ｅは、このサーバＩＤと、ビット列抽出部２１によって検出された書き換え開始位置以降の文字列とを置き換える。即ち、ビット列・ＩＤ書換部２４ｅは、Ｃｏｏｋｉｅ情報を”ａ（ｅ％＝ｏｋｉｅＦｏｒＣｌｉｅｎｔ１ ｅｘｐｉｒｅ＝Ｓａｔ， ０４−Ａｐｒ−２００２
０９：３０：３０ ＧＭＴ”と書き換える。
【０２６７】
また、ビット列・ＩＤ書換部２４ｅは、書換用テーブル２２Ｂに、”Ｃ１＝Ｃｏ，ａ（ｅ％，１９２．１６８．０．１，１，０４−Ａｐｒ−２００２ ０９：３０：３０”という新たなエントリを記録する。このとき、ビット列・ＩＤ書換部２４ｅは、テーブルエントリ消去部３２によって指定されたエントリがある場合、このエントリに対して新たなエントリを上書きする。また、ビット列・ＩＤ書換部２４ｅは、テーブルエントリ消去部３２から指定されたエントリが無い場合、ＬＲＵのアルゴリズムを用いて上書きされるエントリを選択し、記録する。
【０２６８】
ヘッダ更新・パケット送信部２５は、パケットのヘッダにおける送信元アドレスをＶＩＰ１に変更し、クライアント１ａに対してリプライメッセージを転送する（ｓｅｑ４ｅ）。
【０２６９】
クライアント１ａは、負荷分散装置１５ｅからリプライメッセージを受信する。クライアント１ａは、受信されたリプライメッセージに含まれるＣｏｏｋｉｅ情報”ａ（ｅ％＝ｏｋｉｅＦｏｒＣｌｉｅｎｔ１ ｅｘｐｉｒｅ＝Ｓａｔ， ０４−Ａｐｒ−２００２ ０９：３０：３０ ＧＭＴ”を、ローカルのＣｏｏｋｉｅ表に記録する。このとき、クライアント１ａは、未記入のパラメータについては、ｐａｔｈ＝／ｃｏｎｔｅｎｔｓ／、ｄｏｍａｉｎ＝ｗｗｗ．ｎｅｔ．ｃｏｍとして記録する。
【０２７０】
この後、クライアント１ａは、サーバ２ａのコンテンツへリクエストメッセージを送信する場合、ローカルのＣｏｏｋｉｅ表から、サーバ２ａからのリプライメッセージ受信時に記録されたＣｏｏｋｉｅ情報”ａ（ｅ％＝ｏｋｉｅＦｏｒＣｌｉｅｎｔ１ ｅｘｐｉｒｅ＝Ｓａｔ， ０４−Ａｐｒ−２００２ ０９：３０：３０ ＧＭＴ”を読み出す。そして、クライアント１ａは、読み出されたＣｏｏｋｉｅ情報を用いてリクエストメッセージを作成し、ＶＩＰ１宛にこのリクエストメッセージを含むパケットを送信する（ｓｅｑ５ｅ）。このとき、このパケットの送信先アドレス及び送信先ポート番号は、”１０．０．０．１”及び”８０”である。また、このとき、このパケットの送信元アドレス及び送信元ポート番号は、”２０．０．０．１”及び”５０００”である。
【０２７１】
負荷分散装置１５ｅがクライアント１ａからこのリクエストメッセージを受信すると、まずビット列抽出部１７がＣｏｏｋｉｅ情報の抽出を実行する。ビット列抽出部１７は、Ｃｏｏｋｉｅ情報”ａ（ｅ％＝ｏｋｉｅＦｏｒＣｌｉｅｎｔ１”を抽出する。そして、ビット列抽出部１７は、サーバＩＤが”ａ（ｅ％”であると特定する。
【０２７２】
振り分け先サーバ決定部１８は、書換用テーブル２２Ｂにおいて、サーバＩＤが”ａ（ｅ％”であるエントリを検索する。ここで、リプライメッセージの転送時に記録された”Ｃ１＝Ｃｏ，ａ（ｅ％，１９２．１６８．０．１，０４−Ａｐｒ−２００２ ０９：３０：３０”というエントリが検索される。このため、振り分け先サーバ決定部１８は、振り分け先となるサーバが、ＩＰアドレス”１９２．１６８．０．１”が設定されたサーバ２ａであることを特定する。また、振り分け先サーバ決定部１８は、文字列”ａ（ｅ％”の書き換えの際に使用される文字列が”Ｃ１＝Ｃｏ”であることを特定する。
【０２７３】
ＩＤ・ビット列書換部１９は、リクエストメッセージに含まれるＣｏｏｋｉｅ情報に対して書き換えを行い、”Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１”というＣｏｏｋｉｅ情報を復元する。
【０２７４】
ヘッダ更新・パケット送信部２０は、パケットのヘッダにおける送信先アドレスを、サーバ２ａのＩＰアドレスである”１９２．１６８．０．１”に変更する。そして、ヘッダ更新・パケット送信部２０は、サーバ２ａに対してリクエストメッセージを転送する（ｓｅｑ６ｅ）。
【０２７５】
サーバ２ａは、リクエストメッセージを受信すると、このリクエストメッセージに対応するコンテンツからリプライメッセージを作成する。このとき、リプライメッセージに”Ｓｅｔ−Ｃｏｏｋｉｅ：Ｃ２＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ２”というＳｅｔ−Ｃｏｏｋｉｅコマンドを付加すると仮定する。即ち、サーバ２ａは、受信されたリクエストメッセージと異なるＮＡＭＥ値を持つＣｏｏｋｉｅ情報を付加すると仮定する。そして、サーバ２ａは、クライアント１ａ宛に、このリプライメッセージを含むパケットを送信する（ｓｅｑ７ｅ）。このときのこのパケットの送信先アドレス及び送信先ポート番号は、”２０．０．０．１”及び”５０００”である。また、このとき、このパケットの送信元アドレス及び送信元ポート番号は、”１９２．１６８．０．１”及び”８０”である。
【０２７６】
負荷分散装置１５ｅがサーバ２ａからリプライメッセージを受信すると、ビット列抽出部２１がＣｏｏｋｉｅ情報の抽出を行う。そして、ビット列抽出部２１は、”Ｃ２＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ２”という文字列をＣｏｏｋｉｅ情報として抽出する。
【０２７７】
テーブルエントリ消去部３２は、書換用テーブル２２Ｂを参照し、有効期限が切れているエントリを検索する。ここで、テーブルエントリ消去部３２は、”Ｃ１＝Ｃｏ，ａ（ｅ％，１９２．１６８．０．１、０４−Ａｐｒ−２００２ ０９：３０：３０”のエントリの有効期限が切れていると判断する。従って、テーブルエントリ消去部３２は、このエントリに対して新たなエントリを上書きすることをビット列・ＩＤ書換部２４ｅに指示する。
【０２７８】
ビット列・ＩＤ書換部２４ｅは、ＩＤ生成部２３から新しいサーバＩＤとして”ｂｅＰｅ”を取得する。ビット列・ＩＤ書換部２４ｅは、このサーバＩＤと、ビット列抽出部２１によって検出された書き換え開始位置以降の文字列”Ｃ２＝Ｃｏ”とを置き換え、Ｃｏｏｋｉｅ情報を”ｂｅＰｅ＝ｏｋｉｅＦｏｒＣｌｉｅｎｔ２”と置き換える。また、ビット列・ＩＤ書換部２４ｅは、書換用テーブル２２Ｂのエントリとして”Ｃ２＝Ｃｏ，ｂｅＰｅ，１９２．１６８．０．１，有効期限なし”を記録する。
【０２７９】
ヘッダ更新・パケット送信部２５は、送信元アドレスをＶＩＰ１に変更し、クライアント１ａに対してリプライメッセージを転送する（ｓｅｑ８ｅ）。
【０２８０】
クライアント１ａは、負荷分散装置１５ｅからリプライメッセージを受信する。クライアント１ａは、受信したリプライメッセージに含まれるＣｏｏｋｉｅ情報”ｂｅＰｅ＝ｏｋｉｅＦｏｒＣｌｉｅｎｔ２”を、ローカルのＣｏｏｋｉｅ表に記録する。このとき、クライアント１ａは、未記入のパラメータについては、ｐａｔｈ＝／ｃｏｎｔｅｎｔｓ／、ｄｏｍａｉｎ＝ｗｗｗ．ｎｅｔ．ｃｏｍとして記録する。
【０２８１】
〈作用・効果〉
第五実施形態によれば、書換用テーブル２２Ｂに新たなエントリが上書きされる場合、消去される（上書きされる）エントリをテーブルエントリ消去部３２が判断する。このとき、テーブルエントリ消去部３２は、エントリの項目として記録される有効期限（対応するＣｏｏｋｉｅ情報の有効期限）が切れたエントリを、消去されるエントリとして選択する。このため、有効期限の切れていないエントリ（今後も参照される可能性のあるエントリ）が、有効期限の切れたエントリ（今後は参照される可能性の無いエントリ）よりも先に消去されることが防止される。
【０２８２】
〔第六実施形態〕
〈システム構成〉
図２４は、本発明による負荷分散装置１５の第六実施形態、即ち負荷分散装置１５ｆのブロック図である。負荷分散装置１５ｆについて、負荷分散装置１５ａと異なる構成についてのみ説明する。
【０２８３】
負荷分散装置１５ｆは、ヘッダ終了チェック部３３，ヘッダ終了テーブル記憶部３４をさらに備える。
【０２８４】
ヘッダ終了チェック部３３は、ＣＰＵやＲＡＭ等を用いて構成される。ヘッダ終了チェック部３３は、各ＴＣＰコネクション上のトラヒックについて、ＨＴＴＰのヘッダ部分を含むパケットが通過したかどうかを判断する。即ち、ヘッダ終了チェック部３３は、各ＴＣＰコネクション上のトラヒックについて、ＨＴＴＰのヘッダ部分を含むパケットについての処理が終了したか否かを判断する。そして、ヘッダ終了チェック部３３は、ＨＴＴＰヘッダ部分を含む全てのパケットが通過したことをヘッダ終了テーブル３４Ａに記録する。このとき、ヘッダ終了チェック部３３は、ＨＴＴＰヘッダ部分を含む全てのパケットが通過したリプライメッセージについての送信元アドレス（サーバＩＰアドレス），送信元ポート番号（サーバポート番号），送信先アドレス（クライアントＩＰアドレス），送信先ポート番号（クライアントポート番号）を持つエントリをヘッダ終了テーブル３４Ａに記録する。
【０２８５】
また、ヘッダ終了チェック部３３は、ＨＴＴＰヘッダ部分を含む全てのパケットが通過したリプライメッセージを含むパケットについては、ビット列抽出部２１及びビット列・ＩＤ書換部２４をバイパスするように処理する。即ち、ヘッダ終了チェック部３３は、ヘッダ終了テーブル３４Ａに記録されたエントリと一致するヘッダ情報を有するパケットを、ヘッダ更新・パケット送信部２５へバイパスする（渡す）。また、ヘッダ終了チェック部３３は、リプライメッセージの転送が全て終了した時点で、このリプライメッセージに対応するエントリをヘッダ終了テーブル３４Ａから消去する。
【０２８６】
ヘッダ終了テーブル記憶部３４は、フラッシュメモリやハードディスク等の不揮発性記憶装置やＲＡＭ等を用いて構成される。ヘッダ終了テーブル記憶部３４は、ヘッダ終了テーブル３４Ａを記憶する。図２５は、ヘッダ終了テーブル３４Ａの例を示す図である。ヘッダ終了テーブル３４Ａは、クライアントＩＰアドレス，クライアントポート番号，サーバＩＰアドレス，サーバポート番号を対応付けたエントリを持つ。このエントリは、ＨＴＴＰヘッダ部分を含む全てのパケットが通過したリプライメッセージについてのエントリである。即ち、このエントリの各項目は、このリプライメッセージの送信先アドレス，送信先ポート番号，送信元アドレス，送信元ポート番号に相当する。
【０２８７】
〈動作シーケンス〉
図２６は、第六実施形態による負荷分散装置１５ｆを用いた負荷分散システム１４にける動作シーケンスの例を示す図である。以下、第六実施形態における動作シーケンスについて、第一実施形態と異なる動作についてのみ説明する。
【０２８８】
ここでは、サーバ２ａは、リプライメッセージを複数のパケット（第一パケット及び第二パケット）に分割して送信し、第一パケットにのみＨＴＴＰヘッダの情報が含まれると仮定する。
【０２８９】
ｓｅｑ１ｆ〜ｓｅｑ２ｆにおける処理は、第一実施形態におけるｓｅｑ１ａ〜ｓｅｑ２ａにおける処理と同様である。このため、説明を省略する。
【０２９０】
サーバ２ａは、ｓｅｑ２ｆにおけるリクエストメッセージを受信すると、このリクエストメッセージに対応するコンテンツからリプライメッセージを作成する。このとき、サーバ２ａは、リプライメッセージに、Ｃｏｏｋｉｅ情報を付加する。ここで、サーバ２ａは、Ｓｅｔ−Ｃｏｏｋｉｅコマンドとして、”Ｓｅｔ−Ｃｏｏｋｉｅ：Ｃ１＝ＣｏｋｉｅＦｏｒＣｌｉｅｎｔ１”を発行し、リプライメッセージに付加すると仮定する。サーバ２ａは、このリプライメッセージを、第一パケット及び第二パケットに分割する。そして、サーバ２ａは、二つのパケットをクライアント１ａ宛に送信する。このとき、二つのパケットの送信先アドレス及び送信先ポート番号は、”２０．０．０．１”及び”５０００”である。また、このとき、二つのパケットの送信元アドレス及び送信元ポート番号は、”１９２．１６８．０．１”及び”８０”である。
【０２９１】
負荷分散装置１５ｆがサーバ２ａからリプライメッセージを含むパケットを受信すると、ヘッダ終了チェック部３３がこのパケットのヘッダ情報を参照する。このとき、リプライメッセージを含む第一パケットが第二パケットよりも先に負荷分散装置１５ｆに受信されたと仮定する。このため、ヘッダ終了チェック部３３は、受信された第一パケットのヘッダ情報、即ち送信先アドレス，送信先ポート番号，送信元アドレス，送信元ポート番号を読み出す。そして、ヘッダ終了チェック部３３は、読み出された情報に該当するエントリをヘッダ終了テーブル３４Ａから検索する。この場合、このリプライメッセージについてのエントリはヘッダ終了テーブル３４Ａに記録されていないため、ヘッダ終了チェック部３３は、検索対象となるエントリを検索しない。
【０２９２】
次に、ヘッダ終了チェック部３３は、第一パケットにＨＴＴＰヘッダの終了部分が含まれるか否かを判断する。この場合、第一パケットにＨＴＴＰヘッダの全てが含まれているため、ヘッダ終了チェック部３３は、ＨＴＴＰヘッダの終了部分を第一パケットにおいて検出する。このため、ヘッダ終了チェック部３３は、このリプライメッセージについてのエントリをヘッダ終了テーブル３４Ａに記録する。このエントリは、具体的には”２０．０．０．１，５０００，１９２，１６８．０．１，８０”である。
【０２９３】
この後、第一パケットに対する負荷分散装置１５ｆによる処理（ｓｅｑ５ｆ）は、第一実施形態における処理と同様であるため、説明を省略する。
【０２９４】
負荷分散装置１５ｆがサーバ２ａから第二パケットを受信すると、ヘッダ終了チェック部３３は、第二パケットのヘッダ情報を読み出す。そして、ヘッダ終了チェック部３３は、読み出された情報に該当するエントリをヘッダ終了テーブル３４Ａから検索する。この場合、このリプライメッセージについてのエントリが既にヘッダ終了テーブル３４Ａに記録されている。このため、ヘッダ終了チェック部３３は、第二パケットを、ヘッダ更新・パケット送信部２５へバイパスする。
【０２９５】
ヘッダ更新・パケット送信部２５は、パケットのヘッダにおける送信元アドレスをＶＩＰ１に変更し、クライアント１ａに対して第二パケットを転送する（ｓｅｑ６ｆ）。
【０２９６】
クライアント１ａは、負荷分散装置１５ｆからリプライメッセージを受信する。即ち、クライアント１ａは、負荷分散装置１５ｆから、リプライメッセージを含む第一パケット及び第二パケットを受信する。クライアント１ａは、受信されたリプライメッセージに含まれるＣｏｏｋｉｅ情報”ａ（ｅ％＝ｏｋｉｅＦｏｒＣｌｉｅｎｔ１”を、ローカルのＣｏｏｋｉｅ表に記録する。このとき、クライアント１ａは、未記入のパラメータについては、ｐａｔｈ＝／ｃｏｎｔｅｎｔｓ／、ｄｏｍａｉｎ＝ｗｗｗ．ｎｅｔ．ｃｏｍとして記録する。
【０２９７】
〈作用・効果〉
第六実施形態によれば、既にＣｏｏｋｉｅ情報に対する書き換え等の処理が終了しているリプライメッセージを含むパケットについては、Ｃｏｏｋｉｅ情報に対する書き換え等の処理が省略される。このため、処理の高速化が図られる。
【０２９８】
〔その他〕
本発明は、以下のように特定することができる。
（付記１）第一のデータを含む通信データをサーバから受信する第一の受信手段と、
前記サーバを一意に識別するサーバ識別子を生成する生成手段と、
前記第一のデータの一部分である部分データであって、前記サーバ識別子と同じデータ量の部分データを、前記サーバ識別子に置き換えることにより第二のデータを生成する第一の置換手段と、
前記部分データと前記サーバ識別子と前記第一のデータを含む通信データの送信元であるサーバとを対応付けたエントリを記憶するサーバ識別子記憶手段と、
前記第二のデータを含む通信データをクライアントへ送信する第一の送信手段と、
前記第二のデータを含む通信データをクライアントから受信する第二の受信手段と、
前記通信データから前記第二のデータを読み出す読出手段と、
前記第二のデータに含まれる前記サーバ識別子を用いて、前記サーバ識別子記憶手段からサーバを特定する特定手段と、
前記第二のデータに含まれる前記サーバ識別子を、前記サーバ識別子記憶手段にこのサーバ識別子と対応付けて記憶される部分データに置き換えることにより第一のデータを復元する第二の置換手段と、
前記第二の置換手段によって復元された第一のデータを含む通信データを、前記特定手段によって特定されたサーバに対して送信する第二の送信手段と
を含む中継装置。
（付記２）送信された通信データのデータ量と受信された通信データのデータ量とを用いて相互に通信データの到着確認を実行する前記サーバと前記クライアントとの間に設置される
付記１に記載の中継装置。
（付記３）前記第二の置換手段の処理対象となる前記サーバ識別子と、この第二の置換手段によって生成された前記第一のデータに含まれこの第一のデータを識別するデータ識別子とを対応付けて記憶するデータ識別子記憶手段をさらに備え、
前記第一の置換手段は、前記データ識別子記憶手段によって記憶されるデータ識別子と、前記第一の受信手段によって受信された通信データに含まれる第一のデータに含まれるデータ識別子とが一致する場合に、このデータ識別子と対応付けて記憶されるサーバ識別子を用いて第二のデータを生成する
付記１又は２に記載の中継装置。
（付記４）前記データ識別子記憶手段は、前記第二のデータを含む通信データの送信元である前記クライアント及びこの通信データの送信先となるサーバをさらに対応付けて記憶し、
前記第一の置換手段は、さらに前記第一の受信手段によって受信された通信データの送信元となるサーバと前記データ識別子記憶手段に記憶されるサーバ、及び前記第一の受信手段によって受信された通信データの送信先となるクライアントと前記データ識別子記憶手段に記憶されるクライアントが一致する場合に、データ識別子と対応付けて記憶されるサーバ識別子を用いて第二のデータを生成する
付記３に記載の中継装置。
（付記５）前記サーバは複数のコンテンツを備え、
前記データ識別子記憶手段は、前記第二のデータを含む通信データの送信元である前記クライアント及びこの通信データの送信先となるコンテンツをさらに対応付けて記憶し、
前記第一の置換手段は、さらに前記第一の受信手段によって受信された通信データの送信元となるコンテンツと前記データ識別子記憶手段に記憶されるコンテンツ、及び前記第一の受信手段によって受信された通信データの送信先となるクライアントと前記データ識別子記憶手段に記憶されるクライアントが一致する場合に、データ識別子と対応付けて記憶されるサーバ識別子を用いて第二のデータを生成する
付記３に記載の中継装置。
（付記６）前記第一の置換手段による処理を行わない第一のデータを示すデータ識別子を記憶する識別子記憶手段と、
前記第一の受信手段によって受信された通信データに含まれる第一のデータを示すデータ識別子が前記識別子記憶手段に記憶されているか否かを判断し、記憶されている場合に、この第一のデータに対する置き換え処理を行わないように前記第一の置換手段を制御する置換制御手段と
をさらに備える付記１〜５のいずれかに記載の中継装置。
（付記７）前記第一の置換手段による処理を行わない第一のデータを示すデータ識別子を記憶する識別子記憶手段と、
前記第一の受信手段によって受信された通信データに含まれる第一のデータを示すデータ識別子が前記識別子記憶手段に記憶されているか否かを判断し、記憶されている場合に、この第一のデータに対する処理を行わないように前記第一の置換手段を制御する置換制御手段と
前記第一のデータを含み前記クライアントから受信される通信データに含まれる第一のデータを示すデータ識別子が前記識別子記憶手段に記憶されているか否かを判断し、記憶されている場合に、この第一のデータを第二のデータとみなして処理を行わないように前記第二の置換手段を制御する置換制御手段と
をさらに備える付記１〜５のいずれかに記載の中継装置。
（付記８）前記第一の置換手段による処理を行わない第一のデータに含まれ、この第一のデータが送信されるべきドメインを示すドメイン識別子を記憶するドメイン識別子記憶手段と、
前記第一の受信手段によって受信された通信データに含まれる第一のデータに含まれるドメイン識別子が前記ドメイン識別子記憶手段に記憶されているか否かを判断し、記憶されている場合に、この第一のデータに対する処理を行わないように前記第一の置換手段を制御する置換制御手段と
をさらに備える付記１〜５のいずれかに記載の中継装置。
（付記９）前記サーバ識別子記憶手段は、各エントリについて有効期限をさらに記憶し、
前記有効期限が満了したエントリを削除する削除手段をさらに備える
付記１〜８のいずれかに記載の中継装置。
（付記１０）前記サーバから複数の分割データに分割されて送信される前記第一のデータを含む通信データについて前記第一の置換手段による処理が終了した場合、この通信データの他の分割データに対する前記第一の置換手段の処理を省略するように制御する省略制御手段をさらに備える付記１〜９のいずれかに記載の中継装置。
（付記１１）前記省略制御手段は、
前記処理が終了した通信データについての情報を記憶する省略情報記憶手段と、
前記省略情報記憶手段に記憶された情報に該当する通信データの分割データについては、前記第一の置換手段による処理を省略するように制御する制御手段とを用いて構成される付記１０に記載の中継装置。
【０２９９】
【発明の効果】
本発明によれば、パケットのサイズを変更することなくメッセージの中継を行うため、従来必要であったパケット再構築処理が不要になる。このため、パケット転送処理を高速化することができる。また、パケット再構築処理が不要になることにより、副次的な効果としてＴＣＰの終端機能を削ることができるようになり、さらに高速化を図ることができる。
【図面の簡単な説明】
【図１】 第一の原理の概略を示す図である。
【図２】 第一の原理に基づく機能ブロック図である。
【図３】 第一の原理における問題点を示す図である。
【図４】 第二の原理の概略を示す図である。
【図５】 第二の原理に基づく機能ブロック図である。
【図６】 第三の原理に基づく機能ブロック図である。
【図７】 第四の原理に基づく機能ブロック図である。
【図８】 第五の原理に基づく機能ブロック図である。
【図９】 第六の原理に基づく機能ブロック図である。
【図１０】 負荷分散システムの概略を示す図である。
【図１１】 第一実施形態のブロック図である。
【図１２】 書換用テーブルの例を示す図である。
【図１３】 第一実施形態における動作シーケンスを示す図である。
【図１４】 第二実施形態のブロック図である。
【図１５】 ＮＡＭＥビット列テーブルの例を示す図である。
【図１６】 第二実施形態における動作シーケンスを示す図である。
【図１７】 第三実施形態のブロック図である。
【図１８】 第三実施形態における動作シーケンスを示す図である。
【図１９】 第四実施形態のブロック図である。
【図２０】 第四実施形態における動作シーケンスを示す図である。
【図２１】 第五実施形態のブロック図である。
【図２２】 書換用テーブルの例を示す図である。
【図２３】 第五実施形態における動作シーケンスを示す図である。
【図２４】 第六実施形態のブロック図である。
【図２５】 ヘッダ修了テーブルの例を示す図である。
【図２６】 第六実施形態における動作シーケンスを示す図である。
【図２７】 Ｃｏｏｋｉｅが用いられた買い物処理の例を示す図である。
【図２８】 Ｃｏｏｋｉｅが用いられた通信手順の概要を示す図である。
【図２９】 Ｃｏｏｋｉｅ表の例を示す図である。
【図３０】 Ｃｏｏｋｉｅが用いられた通信手順の概要を示す図である。
【図３１】 負荷分散システムの概要を示す図である。
【図３２】 Ｃｏｏｋｉｅ情報に基づいた振り分け処理の機能ブロック図である。
【図３３】 Ｃｏｏｋｉｅ情報に基づいた振り分け処理における問題点を示す図である。
【図３４】 第一の解決方法を示す図である。
【図３５】 第二の解決方法を示す図である。
【図３６】 実際のネットワークの構成例を示す図である。
【図３７】 第一の解決方法における問題点を示す図である。
【図３８】 エンドホストとして動作する中継装置を示す図である。
【符号の説明】
１，１ａ，１ｂ，１ｃ クライアント
２，２ａ，２ｂ，２ｃ，２ｄ サーバ
３，３ａ，３ｂ，３ｃ，３ｄ，３ｅ，３ｆ 中継装置
４ ビット列抽出部
５ａ，５ｂ，５ｃ，５ｄ，５ｅ Ｃｏｏｋｉｅ情報書換部
６ ヘッダ更新・パケット送信部
７ ビット列抽出部
８ ヘッダ更新・パケット送信部
９ 同一ＮＡＭＥ判定部
１０，１１ ＮＡＭＥフィルタ
１２ ドメインフィルタ
１３ ヘッダ終了チェック部
１４ 負荷分散システム
１５，１５ａ，１５ｂ，１５ｃ，１５ｄ，１５ｅ，１５ｆ 負荷分散装置
１６ サーバグループ
１７，２１ ビット列抽出部
１８，１８ｃ 振り分け先サーバ決定部
１９ ＩＤ・ビット列書換部
２０，２５ ヘッダ更新・パケット送信部
２２，２２ｅ 書換用テーブル記憶部
２２Ａ，２２Ｂ 書換用テーブル
２３ ＩＤ生成部
２４，２４ｂ，２４ｅ ビット列・ＩＤ書換部
２６ ＮＡＭＥビット列テーブル記憶部
２６Ａ ＮＡＭＥビット列テーブル
２７ ＮＡＭＥビット列記録部
２８ ＮＡＭＥビット列比較部
２９，３０ ＮＡＭＥフィルタ部
３１ ドメインフィルタ部
３２ テーブルエントリ消去部
３３ ヘッダ終了チェック部
３４ ヘッダ終了テーブル記憶部
３４Ａ ヘッダ終了テーブル
Ｐ１，Ｐ１ａ，Ｐ１ｂ，Ｐ１ｃ クライアント
Ｐ２，Ｐ２ａ，Ｐ２ｂ，Ｐ２ｃ サーバ
Ｐ３，Ｐ３ａ，Ｐ３ｂ，Ｐ３ｃ 負荷分散装置
Ｐ４，Ｐ４ａ，Ｐ４ｂ サーバグループ
Ｐ５ 負荷分散システム
Ｐ６，Ｐ１０ Ｃｏｏｋｉｅ検出部
Ｐ７ 振り分け先サーバ決定部
Ｐ８，Ｐ８ｂ，Ｐ８ｃ サーバ・Ｃｏｏｋｉｅ用テーブル
Ｐ９，Ｐ１２ ヘッダ更新・パケット送信部
Ｐ１１，Ｐ１１ｂ，Ｐ１１ｃ Ｃｏｏｋｉｅ・サーバ記録部
Ｐ１３ メッセージ構築部
Ｐ１４，Ｐ１４ｃ Ｃｏｏｋｉｅ生成部
Ｐ１５ Ｃｏｏｋｉｅ挿入部
Ｐ１６ メッセージ分割部
Ｐ１７ Ｃｏｏｋｉｅ上書き部

Claims (5)

1. 第一のデータを含む通信データをサーバから受信する第一の受信手段と、
   前記サーバを一意に識別するサーバ識別子を生成する生成手段と、
   前記第一のデータの一部分である部分データであって、前記サーバ識別子と同じデータ量の部分データを、前記サーバ識別子に置き換えることにより第二のデータを生成する第一の置換手段と、
   前記部分データと前記サーバ識別子と前記第一のデータを含む通信データの送信元であるサーバとを対応付けたエントリを記憶するサーバ識別子記憶手段と、
   前記第二のデータを含む通信データをクライアントへ送信する第一の送信手段と、
   前記第二のデータを含む通信データをクライアントから受信する第二の受信手段と、
   前記通信データから前記第二のデータを読み出す読出手段と、
   前記第二のデータに含まれる前記サーバ識別子を用いて、前記サーバ識別子記憶手段からサーバを特定する特定手段と、
   前記第二のデータに含まれる前記サーバ識別子を、前記サーバ識別子記憶手段にこのサーバ識別子と対応付けて記憶される部分データに置き換えることにより第一のデータを復元する第二の置換手段と、
   前記第二の置換手段によって復元された第一のデータを含む通信データを、前記特定手段によって特定されたサーバに対して送信する第二の送信手段と
   を含む中継装置。
2. 前記第二の置換手段の処理対象となる前記サーバ識別子と、この第二の置換手段によって生成された前記第一のデータに含まれこの第一のデータを識別するデータ識別子とを対応付けて記憶するデータ識別子記憶手段をさらに備え、
   前記第一の置換手段は、前記データ識別子記憶手段によって記憶されるデータ識別子と、前記第一の受信手段によって受信された通信データに含まれる第一のデータに含まれるデータ識別子とが一致する場合に、このデータ識別子と対応付けて記憶されるサーバ識別子を用いて第二のデータを生成する
   請求項１に記載の中継装置。
3. 前記第一の置換手段による処理を行わない第一のデータを示すデータ識別子を記憶する識別子記憶手段と、
   前記第一の受信手段によって受信された通信データに含まれる第一のデータを示すデータ識別子が前記識別子記憶手段に記憶されているか否かを判断し、記憶されている場合に、この第一のデータに対する置き換え処理を行わないように前記第一の置換手段を制御する置換制御手段と
   をさらに備える請求項１又は２に記載の中継装置。
4. 前記第一の置換手段による処理を行わない第一のデータに含まれ、この第一のデータが送信されるべきドメインを示すドメイン識別子を記憶するドメイン識別子記憶手段と、
   前記第一の受信手段によって受信された通信データに含まれる第一のデータに含まれるドメイン識別子が前記ドメイン識別子記憶手段に記憶されているか否かを判断し、記憶されている場合に、この第一のデータに対する処理を行わないように前記第一の置換手段を制御する置換制御手段と
   をさらに備える請求項１〜３のいずれかに記載の中継装置。
5. 前記サーバから複数の分割データに分割されて送信される前記第一のデータを含む通信データについて前記第一の置換手段による処理が終了した場合、この通信データの他の分割データに対する前記第一の置換手段の処理を省略するように制御する省略制御手段をさらに備える請求項１〜４のいずれかに記載の中継装置。

Images