JP2008521076A - クライアント識別情報をサーバに提供するための装置および方法 - Google Patents

Abstract

クライアント識別情報をサーバに提供するための装置はインテリジェント中間装置内にサーバに送信されるクライアント識別情報を含む、少なくとも１つのタグ付きパケットを生成するように構成されるタグ付加器と、少なくとも１つのタグ付きパケットからクライアント識別情報を取得し、このクライアント識別情報をサーバにあるアプリケーションに提供するように構成されるインターセプタとを備える。一実施例では、タグ付加器がクライアント識別情報を少なくとも１つのタグ付きパケットのデータ部に挿入するように構成される。別の実施例では、タグ付加器がクライアント識別情報を少なくとも１つのタグ付きパケットのプロトコル・ヘッダに挿入するように構成される。

Description

本発明は、一般に電子ネットワークに係り、特にクライアント識別情報をサーバに提供するための装置および方法に関する。

多くのクライアント−サーバ・ネットワークにおいて、クライアントとサーバとは少なくとも多様な中間装置を通して直接交信しない。ウェブ・プロクシのようなあるデバイスはクライアントからのコネクションを終了させ、新たなコネクションをサーバに対して開く。コンテンツを要求するために中間装置がクライアントに代わってサーバを使用してコネクションを確立するとき、サーバは仮に中間装置がないものとして、その要求の最初のソースあるいはインターネット・プロトコル（ＩＰ）アドレスのようなソースの他の属性を見出すのと同様な方法を用いても、それらを決定することができない。しばしばサーバはその要求に関係する直接のソースが中間装置であると理解する。

サーバがコンテンツを求める要求の、典型的にはクライアントである最初のソースに付けられたＩＰアドレスを確認しなければならない場面がある。たとえば、サーバはクライアントのＩＰアドレスに基づいて許可が下りる手順を実行しなればならず、あるいはサーバにあるアプリケーションがマーケッティング努力の有効性を評価するため唯一のヴィジタ識別名のようなクライアントＩＰアドレスを使用しなければならないことがある。別の例では、サーバはクライアントが実際にある場所に応じてクライアント向けコンテンツの送信を変更しなければならないことがある。このような場合、サーバは適切なコンテンツをクライアントに向けて送信するためクライアントのＩＰアドレスを確認する必要がある。

サーバはまたセキュリティを目的としてクライアントＩＰアドレスを使用する。たとえば、サーバは所定の信用が確保されたクライアントにだけデータを送信するように構成され、あるいはサーバは一定の地域または国に属するクライアントからの要求には応じないようにプログラムされる。しかしながら、これらの有効であるセキュリティ手段の場合、サーバは最初の要求者である、そのクライアントのＩＰアドレスを確認しなければならない。

クライアントのＩＰアドレスについてサーバに知らせる幾つかの中間装置で用いられる公知技術はＨＴＴＰプロトコルのＸ−フォワーデット−フォー・ヘッダ・ラインあるいは同様な目的を持つ別のヘッダを使用することである。このヘッダ・ラインは最初のソースのＩＰアドレスを含み、また最初のソースと中間装置との間に存在する他の中間装置のアドレスを含む。この技術では、サーバ・ソフトウエアは多様な目的のためにこのＩＰアドレスのリストを使用するように作成される。この技術の欠点はＨＴＴＰのような少数のプロトコルだけが利用できる点にあり、ＦＴＰのような他のプロトコルと共に使用することができない。第２の欠点は暗号化セキュア・コネクション（たとえば、ＳＳＬを使用するコネクション）の場合、プロクシは暗号に書き換えられたＨＴＴＰ−レベル・データを理解するだけで、ヘッダ・ラインを適切に修正することができない。第３の欠点はヘッダがそれまでに許可が下りないクライアントによって偽造されることである。第４の欠点は透明性の不足である。ここで、サーバ・ソフトウエアは翻訳し直し、新しいヘッダを使用するため再作成され、または再プログラムされる必要があり、このような新しいサーバへの変更は高価であるかまたは不可能である。

クライアントのＩＰアドレスをサーバに提供する、別の公知技術はクライアントの確認について中間装置に質問することである。この技術では、サーバ・ソフトウエアは中間装置へのコネクションを取るように作成され、クライアントのＩＰアドレスを要求する。この技術の欠点は要求−回答サイクルがある時間を必要とし、特にそのクライアントが求めるコンテンツを提供する前にサーバがクライアントのＩＰアドレスを確認する必要がある場合に遅れを伴うことである。この技術のさらなる欠点は透明性の不足である。ここで、サーバはこれらの質問を開始するようにプログラムされねばならず、回答が到着するまでの遅れに打ち勝てるように構成されねばならない。

クライアントＩＰアドレスをサーバに提供する、別の公知技術は中間装置からサーバへのアドレス情報についてオフラインで転送することである。この技術はクライアント−コネクションのログを保つため中間装置を必要とする。この技術はマーケット・リサーチの目的のためには有用であるが、許可を目的にサーバがクライアントＩＰアドレスを使用すること、さらにはサーバがクライアントの要求するコンテンツを修正することは許さない。この技術の欠点はサーバ・データ管理方法に関して透明性の不足があることである。

クライアント識別情報をサーバに提供するための装置はサーバ通信情報に含ませる少なくとも１つのタグ付きパケットを生成するインテリジェント中間装置にタグ付加器を備える。サーバは、好ましくは少なくとも１つのタグ付きパケットからクライアント識別情報を取得するインターセプタを備え、このクライアント識別情報をサーバにあるアプリケーションに提供する。一実施例では、インターセプタはこのアプリケーションから通信情報のソースの身元証明を要求しているオペレーティング・システムへのコールを傍受することによってクライアント識別情報をアプリケーションに提供するように構成される。

一実施例では、タグ付加器は通信情報データにクライアント識別情報を連結し、得られたデータをパケット化するように構成され、データ・フィールドにクライアント識別情報を含む、少なくとも１つのタグ付きパケットを生成する。別の実施例では、タグ付加器はクライアント識別情報を少なくとも１つのタグ付きパケットのプロトコル・ヘッダに含ませることによって少なくとも１つのタグ付きパケットを生成するように構成される。

クライアント識別情報をサーバに提供するための方法は通信情報に含ませるパケットとしてクライアント識別情報を含む少なくとも１つのタグ付きパケットを生成し、通信情報の一部としてタグ付きパケットをサーバに送信し、通信情報の少なくとも１つのタグ付きパケットを認識し、少なくとも１つのタグ付きパケットからクライアント識別情報を取得し、クライアント識別情報をアプリケーションに提供することを含む。クライアント識別情報をアプリケーションに提供するステップは、好ましくはアプリケーションから通信情報の身元証明を要求しているサーバのオペレーティング・システムへのコールを傍受し、この傍受したコールを通信情報のソースの身元証明に代わるクライアント識別情報を含む回答と共に応答することを含む。本発明の方法はさらに最初の通信情報データをサーバにあるアプリケーションに提供することを含む。

図１Ａは本発明に従う電子ネットワーク１００の一実施例のブロック図である。このネットワーク１００は、これに限られないが、クライアント１１０と、ネットワーク１１２と、インテリジェント中間装置１１４と、ネットワーク１１６と、ソース識別サーバ１１８とを備える。クライアント１１０は、典型的にはコンテンツを入手する要求を含むクライアント通信情報をネットワーク１１２を通してインテリジェント中間装置１１４に送信する。インテリジェント中間装置１１４はクライアント１１０からの通信情報を受信し、終了させ、その後、典型的にはコンテンツを入手する要求を含むサーバ通信情報をネットワーク１１６を経由し、別のコネクションを使用してソース識別サーバ１１８に送信する。ソース識別サーバ１１８はその要求に従ってコンテンツを生成し、その後生成したコンテンツをインテリジェント中間装置１１４に送信する。コンテンツはこの後クライアント１１０に送信される。図１Ａの実施例では、クライアント１１０とインテリジェント中間装置１１４とソース識別サーバ１１８とがトランスポート層およびネットワーク層においてＴＣＰ／ＩＰ（インターネット・プロトコルを使用するトランスミッション・コントロール・プロトコル）を有するプロトコル・スタックに従って通信する。インテリジェント中間装置１１４はクライアント−サーバ間に独立したコネクションを確立する、たとえばプロクシ、いずれかの形式の代用サーバ、サーバ・ロード・バランサおよびセキュア・ソケット・レイヤー（ＳＳＬ）ゲートウェイのようないずれかの形式のネットワーキング装置である。インテリジェント中間装置１１４の他の例は“ウェブ・コンテンツの高性能配信方法”の名称で出願された米国特許出願番号第０９／５３４，３２１号に記載されている。この明細書の開示は参照してここにその全体を取り入れる。

インテリジェント中間装置１１４はクライアント１１０の識別情報を含むようにソース識別サーバ１１８に送信されるサーバ通信情報を修正する。インテリジェント中間装置１１４はクライアント識別情報を含むように最初の通信情報データを修正し、またはクライアント識別情報を含むようにサーバ通信情報のプロトコル・ヘッダを修正し、あるいはこれの２つの組み合わせによる方法を修正する。好ましいインテリジェント中間装置１１４の具体的内容および機能は図２と共に以下に説明される。好ましいソース識別サーバ１１８はサーバ通信情報からクライアント識別情報を取得し、その情報を適切なアプリケーションに提供する。ソース識別サーバ１１８の具体的内容および機能は図４と共に以下に説明される。

図１Ｂは本発明に従う電子ネットワークの１２０の別の実施例のブロック図である。このネットワークは、これに限られないが、クライアント１２２と、クライアント１２４と、クライアント１２６と、ネットワーク１２８と、インテリジェント中間装置１１４と、ネットワーク１３０と、ソース識別サーバ１１８とを備える。図１Ｂの実施例では、インテリジェント中間装置１１４はクライアント１２２、１２４、１２６のいずれか１つからネットワーク１２８を通してクライアント通信情報を受信する。クライアント通信情報の１つ１つについてインテリジェント中間装置１１４はサーバ１３２、サーバ１３４あるいはソース識別サーバ１１８のうち、どのサーバがクライアントに代わってコンテンツを入手する要求のような情報を受信するかを決定し、次いでサーバ通信情報がクライアント識別情報を含むべきか、否かを決定する。ソース識別サーバ１１８に向けた情報の場合、インテリジェント中間装置１１４はクライアント識別情報を含むサーバ通信情報を作成する。サーバ１３２またはサーバ１３４に向けた情報の場合、インテリジェント中間装置１１４はサーバ１３２およびサーバ１３４がソース識別サーバではないので、クライアント識別情報を含まないサーバ通信情報を作成する。

図２は本発明に従う図１Ａのインテリジェント中間装置１１４の一実施例のブロック図である。このインテリジェント中間装置１１４は、これに限られないが、プロクシ２１０と、タグ付加器２１２と、ＯＳカーネル２１４とを備える。このプロクシ２１０はソース識別サーバ１１８用のプロクシとしての役割を果たし、ソース識別サーバ１１８に代わってコンテンツを入手する要求を受信し、応答する。インテリジェント中間装置１１４に記憶されないまたはソース識別サーバ１１８から呼び出されるべきコンテンツについてプロクシ２１０は望ましいコンテンツを要求するためソース識別サーバ１１８にコネクションを確立する。

クライアント１１０はインテリジェント中間装置１１４とのコネクションを確立し、コンテンツを入手する要求をインテリジェント中間装置１１４に送信する。このコネクションの確立では、クライアント１１０はＩＰアドレスを含む識別情報をインテリジェント中間装置１１４に連絡する。（クライアントのような）ある１つのポイントと（中間装置１１４のような）別のポイントとの間に直接のコネクションが存在するときはいつもポイントの１つ１つが別のＩＰアドレスを確認できるのがＩＰプロトコルの内蔵された特性である。しかしながら、それを使用することで生じる、特定の手段（ＩＰヘッダ内の標準専用フィールド）もまたコネクション内の直接のエンドポイントとして含まれない、他のホスト機器の身元証明を記録するためには使用することができない。プロクシ２１０はクライアント１１０からのコネクションを終了し、ソース識別サーバ１１８に送信されるべきコンテンツを入手する要求を含むサーバ通信情報を作成する。タグ付加器２１２はクライアント１１０の識別情報を含むようにサーバ通信情報を修正し、タグ付きデータを生成する。この後、タグ付きデータ流を生成するためタグ付きデータはＯＳカーネル２１４によってパケット化される。クライアント識別情報を含むタグ付きデータ流を生成する技術は図３Ａおよび図３Ｂと共に以下に説明される。タグ付加器２１２はハードウエア、ソフトウエア、ファームウエアあるいはこれらを組み合わせたものとして備えることができる。ソフトウエアを含むタグ付加器の実施内容では、ソフトウエアはＯＳカーネル２１４の内部装置のネットワーク・スタック・ソフトウエアの内部、ノン・カーネル・アプリケーションの内部またはこれらの組み合わせによるものに備えることができる。インテリジェント中間装置１１４の別の実施例では、タグ付加器２１２はプロクシ２１０と１つに統合される。

図３Ａは本発明の好ましい実施例に従うタグ付きパケット３１０の構成図である。タグ付きパケット３１０はタグ付きデータ流に含まれる最初のデータ・ベアリング・パケットである。本実施例では、タグ付加器２１２はクライアント識別情報を最初のサーバ通信情報データの前部に連結し、この後得られたタグ付きデータについてタグ付きデータ流を形成するためタグ付きデータをパケット化するＯＳカーネル２１４に転送する。タグ付きパケット３１０は、これに限られないが、データ・リンク・ヘッダ３１２と、ＩＰオプション・フィールド（図示せず）を含むＩＰヘッダ３１４と、ＴＣＰオプション・フィールド（図示せず）を含むＴＣＰヘッダ３１６と、データ・フィールド３１８とを備える。クライアントＩＰアドレス３２０、認識パターン３２２およびチェック・サム３２４を含むクライアント識別情報はタグ付きパケット３１０のデータ・フィールド３１８に存在する。クライアントＩＰアドレス３２０はある方法、すなわちソース識別サーバ１１８が、たとえば数字または名称を認識するように構成する方法でフォーマットされたクライアント１１０のＩＰアドレスである。フォーマッティング設計は認識パターン３２２とチェック・サム３２４とを備えており、他のフィールド（図示せず）を備えてもよい。認識パターン３２２はタグ付きパケット３１０をタグ付きデータ流の本質的部分であるパケットとして認識する際にソース識別サーバ１１８を支援する。チェック・サム３２４はクライアント識別情報が改ざんされてないことを確かめる際にソース識別サーバ１１８を支援する。

別の実施例では、認識パターン３２２とチェック・サム３２４とは改ざんに備えるため、さらには許可が得られまたは信用がある実体物が挿入されているとき、クライアント識別情報を認証するため暗号化した署名によって置き換え、または補足するようにしてもよい。これはソース識別サーバ１１８がタグ付きパケット３１０の属するデータがタグを付されたものであることを認識できるように暗号化する。本実施例では、公開鍵暗号法とディジタル署名技術とが使用される。

別の実施例では、認識パターン３２２およびチェック・サム３２４の一方または双方が省略される。たとえば、チェック・サム３２４は改ざんの機会が極めて小さいと見られるとき、省略してもよい。認識パターン３２２はソース識別サーバ１１８がクライアント識別情報を含むようにデータ流がタグを付けるものと決定しているとき、省略してもよい。仮に、認識パターン３２２およびチェック・サム３２４の双方を省略した場合、ソース識別サーバ１１８はインテリジェント中間装置１１４のＩＰアドレスに基づいてインテリジェント中間装置１１４を認識し、かつインテリジェント中間装置１１４からのデータ流が常にクライアント識別情報を含むことを保証するように構成される。これに代えて、ソース識別サーバ１１８は他の装置からのタグを付けないデータ流を受信する外、インテリジェント中間装置１１４からのタグ付きデータ流を異なるＴＣＰ／ＩＰポートによって受信するように構成してもよい。

再び図３Ａに戻って、クライアントＩＰアドレス３２０ならびに認識パターン３２２およびチェック・サム３２４用の関係するデータ・フィールドがタグ付きデータ流の初めのデータ・ベアリング・タグ付きパケット３１０内の最初のデータとして示される。ＴＣＰ／ＩＰの分割およびパケット化の標準方法によれば、単一パケットに適合する数と比べて明らかに多くのクライアント識別情報があるときにはむしろタグ付きデータ流の最初の数個のデータ・ベアリング・パケットを超える分割されるべきクライアント識別情報が生じると理解される。たとえば、タグ付きパケット３１０はこれを分割するネットワーク１１６内のＩＰルータを通過してより小さい２つのパケットになり、このパケットの１つ１つはタグ付きパケット３１０内にクライアント識別情報の一部を含む。これに代えて、データ・フィールド３１８はタグ付きパケット３１０の大きさによってはクライアント識別情報と一部の最初の通信情報データとを含むようにしてもよい。

タグ付きデータ流を生成するためクライアント識別情報を含むサーバ通信情報を図３Ａの実施例に従ってパケット化するとき、ソース識別サーバ１１８はクライアント識別情報を首尾よく取得する、カーネルのオペレーティング・システムに合わせた修正を必ずしも必要としない。タグ付加器２１２は最初の通信情報データの前に追加通信情報データとしてクライアント識別情報をデータ流に単純に書き込む。最初の通信情報データの内容およびフォーマットは重要でなく、たとえばデータは暗号に変えられる。

図３Ｂは本発明に従うタグ付きパケット１３１０の別の実施例の構成図である。本実施例では、タグ付加器２１２はタグ付きデータ流を生成するためパケット化されたサーバ通信情報のプロトコル・ヘッダを修正する。タグ付きパケット１３１０は、これに限られないが、データ・リンク・ヘッダ１３１２と、ＩＰオプション・フィールド１３３０を含むＩＰヘッダ１３１３と、ＴＣＰオプション・フィールド１３３２を含むＴＣＰヘッダ１３１６と、データ・フィールド１３１８とを備える。本実施例では、クライアント１１０の識別情報はＩＰオプション・フィールド１３３０またはＴＣＰオプション・フィールド１３３２に挿入される。本実施例では、ソース識別サーバ１１８のＯＳカーネルは適切なヘッダのオプション・フィールドにあるクライアント識別情報を識別し、それを取り出すように構成されねばならない。本実施例では、ＩＰオプション・フィールド１３３０またはＴＣＰオプション・フィールド１３３２に挿入されるクライアント識別情報は認識パターンおよびチェック・サムと共にクライアントＩＰアドレスとして図３Ａに示されるものに類似した方法でフォーマットされる。別の実施例では、この認識パターンおよびチェック・サムのどちらか一方または双方は省略してもよく、暗号化した署名または他の補助データが提供されるクライアント識別情報を信頼できる方法で確実に取得する際にソース識別サーバ１１８を支援するために使用される。

タグ付きパケット１３１０の別の実施例では、クライアント識別情報および関係する補助データのうち、幾つかまたはその全てがＩＰオプション・フィールド１３３０以外のＩＰヘッダ１３１３内の固定フィールド、またはＴＣＰオプション・フィールド１３３２以外のＴＣＰヘッダ１３１６内の固定フィールドに書き換えられる。たとえば、ＴＣＰ“至急の”フラッグ（ＴＣＰヘッダ１３１６の追加の１６ビット）と“至急の”ポインタ（ＴＣＰヘッダ１３１６の１ビット）とは本パケットがクライアント識別情報を含むタグ付きデータ流に属することを表わし、クライアント識別情報または補助データの幾つかの部分を書き換えるように使用される。パケット・ヘッダ内の固定フィールドはソース識別サーバ１１８がタグ付きデータ流を誤って解釈し、不正確に扱う機会がないと見極めたとき、上記方法で使用される。たとえば、ウェブ・サーバは、多くの場合、ＴＣＰ至急データを予期し、これを処理するようには設計されないが、クライアント識別情報を書き換えるような基準から外れた目的のためにそうした至急ビットおよび至急ポインタを使用することは多様なウェブの背景があるとしても、受け入れることができる。

図にはタグ付きパケット１３１０が１つだけ示されるが、クライアント識別情報はＩＰオプション・フィールド１３３０、ＴＣＰオプション・フィールド１３３２、インテリジェント中間装置１１４−ネットワーク１１６間のコネクションまたはノードの収容能力およびネットワーク１１６内のコネクションのサイズに応じてタグ付きパケットを数個以上に分割してもよい。

図４は本発明に従う図１Ａのソース識別サーバ１１８の一実施例のブロック図である。ソース識別サーバ１１８は、これに限られないが、アプリケーション４１２と、インターセプタ４１４と、オペレーティング・システム（ＯＳ）カーネル４１６とを備える。図４では、アプリケーション４１２とインターセプタ４１４とがＯＳカーネル４１６から完全に独立するように示されるが、別の実施例では、アプリケーション４１２は、典型的にはカーネルの要素ではないが、システムが呼び出しおよび割り込みを行うような手法によってカーネルの担う仕事をする。アプリケーション４１２はインテリジェント中間装置１１４のような遠隔装置にコンテンツを提供するように構成される。アプリケーション４１２の代表的実施内容にはＨＴＴＰアプリケーションとＳＭＴＰアプリケーションとＦＴＰアプリケーションとを含む。インターセプタ４１４はインテリジェント中間装置１１４から送信される通信情報を傍受し、クライアント識別情報を含むように構成される。本ソース識別サーバ１１８の実施例では、インターセプタ４１４は図３Ａの実施例に従ってタグ付加器２１２で生成したタグ付きデータ流を認識したとき、インターセプタ４１４はそのタグ付きデータ流からクライアント識別情報を取得する。インターセプタ４１４はこの後クライアント識別情報をアプリケーション４１２に提供し、またはクライアント識別情報について質問するアプリケーション４１２の代用手段に提供する。インターセプタ４１４はまたデータ流がそれ以前タグ付加器２１２によって処理されたとき、データ流の最初の通信情報データを修復する。インターセプタ４１４はこの後修復された最初の通信情報データをアプリケーションに送信する。

一実施例では、インターセプタ４１４はコネクションを通して信頼できるソースから送られるタグ付きデータ流をひたすら探す。たとえば、インテリジェント中間装置１１４はソース識別サーバ１１８用の公知のプロクシであり、信頼できるソースである。別の複数のネットワーク装置（図示せず）がソース識別サーバ１１８との間でコネクションを開いても、これらの装置が信頼できないソースであるならば、インターセプタ４１４はこれらのコネクションを通して入ってくるパケットには目を止めない。

典型的サーバでは、アプリケーションがＯＳカーネルの新しいコネクション列から次に利用できるコネクションを呼ぶためＯＳカーネルを呼び出す。たとえば、アプリケーションは新しいコネクションをアプリケーションに送信する、大部分で共通のインターフェースである“アクセプト”システム・コールを呼び出す。このＯＳカーネルは処理用コネクションからのデータを検索するためアプリケーションがコネクションの身元証明（たとえば、ソケット番号）を示してアクセプト・コールに応答する。このアプリケーションはまたコネクションを通してデータを遠隔装置、たとえばインテリジェント中間装置１１４に送信する。

通常、ＯＳカーネルが新しいコネクションを使ってアクセプト・コールに応答するとき、ＯＳカーネルはまた接続中の遠隔装置の身元証明（たとえば、ＩＰアドレス）を提供する。これに代えて、アプリケーションは接続中の遠隔装置の身元証明のようなコネクションの属性を求めてＯＳカーネルに問い合わせるため明示の質問システム・コールを使用してもよい。アクセプトのようなシステム・コールまたはコネクション属性を質問するシステム・コールは、典型的にはＯＳカーネルが接続中の遠隔装置の識別情報を書き込むべきバッファのアドレスを含む。通常、ＯＳカーネルはそのシステム・コールに応答し、接続中の遠隔装置の識別情報をバッファに書き込む。ＯＳカーネルに適合するシステム・コールの特定のフォーマットはＯＳカーネルの特定の実施内容に左右される。このアクセプト・コールは、通例では使用されるが、ネットワークにアクセスし、利用するためにアプリケーションで使用されるインタフェースの単なる具体例である。

ソース識別サーバ１１８において、アプリケーション４１２はＯＳカーネル４１６の新しいコネクション列から次に利用できるコネクションを呼ぶためＯＳカーネル４１６を呼び出す。インターセプタ４１４はこのコールを傍受し、次に利用できるコネクションを得るためＯＳカーネルに自身のコールを送信する。いずれかの利用できるコネクションがある場合、ＯＳカーネル４１６はそのうちの１つのコネクションの身元証明と接続中の遠隔装置のＩＰアドレスとを示して応答する。インターセプタ４１４はまた“ペンディング”コネクションの内部に保存された列を有する。ここで、この列は接続中の遠隔装置のコネクションの身元証明とＩＰアドレスとを記録している。ペンディング・コネクションとは未だアプリケーション４１２に報告されないＯＳカーネル４１６でインターセプタ４１４に前もって送信されたコネクションのことである。新たに報告された新しいコネクションまたはペンディング・コネクションのどちらの場合も、インターセプタ４１４は新しいコネクションから入ってくるデータを読むためＯＳカーネル４１６への別のシステム・コールを作成する。インターセプタ４１４はデータ流がクライアント識別情報と共にタグを付されているか、否かを決定するためコネクッションを通して入ってくるデータに注視する。本実施例では、インターセプタ４１４はコネクションによってカーネルのバッファ内部のペンディング・データを精査するが、カーネルのバッファからそのペンディング・データを除かないリード・システム・コールの“ピーク”・ヴァージョンを使用する。

仮に、データ流がクライアント識別情報を示さず、タグも付けられず、たとえばインターセプタ４１４がデータ中の正確な位置に正しい認識パターンを見出せないと決定すれば、インターセプタ４１４はＯＳカーネル４１６から接続中の遠隔装置の新しいコネクションの身元証明とＩＰアドレスとを受信したとき、その情報を正確にアプリケーション４１２に転送する。インターセプタ４１４が入ってくるデータに適切な認識パターンまたは他の識別マーカを認識し、書き込まれたクライアント識別情報が入ってくるデータに完全な形で存在するならば、インターセプタ４１４はＯＳカーネル４１６のペンディング・データ列からクライアント識別情報が除かれるようにリード・システム・コールのノン−ピーク・ヴァージョンを用いて入ってくるデータからクライアント識別情報を再び読み取る。インターセプタ４１４はこの後新しいコネクションの身元証明をアプリケーション４１２に転送し、ＯＳカーネル４１６から報告された接続中の遠隔装置のアドレスでなく、アプリケーション４１２が提供する取得したクライアント識別情報でバッファを満たす。インターセプタ４１４はまた内部ストレージに保存したコネクションの身元証明と取得したクライアント識別情報との間の対応関係を格納し、ノン−ペンディングとしてそのレコードに符号を付ける。

このコネクションのためにＯＳカーネル４１６のバッファに十分なペンディング・データがあり、インターセプタ４１４が一度にＯＳカーネル４１６から新しいコネクションを受信した場合、インターセプタ４１４はこのデータ流がタグを付されているか、否か、またはデータ流にタグが付されていてもクライアント識別情報が完全か、否かを決定するため新たなコネクションの身元証明をアプリケーション４１２には送信しないが、内部ストレージに保存された接続中の遠隔装置のコネクションの身元証明とアドレスとを記録し、ペンディングとしてそのレコードに符号を付ける。

アプリケーション４１２はまたコネクションの別の接続端によって遠隔装置の身元証明を要求するためＯＳカーネル４１６を呼び出す。これは“アクセプト”として次に利用できるコネクションを求める最初のコールの一部か、または独立したコールであり、ＯＳカーネル４１６の実施内容に左右される。インターセプタ４１４は遠隔装置の身元証明を求めてバッファのアドレスを含むコールを傍受する。インターセプタ４１４は提供されたコネクションの身元証明と関係のあるクライアント識別情報とによる正しい組み合わせのレコードを得るため内部記録に問い合わせる。そうしたレコードが見出された場合、インターセプタ４１４は記憶され、取得したクライアント識別情報でバッファを満たし、この情報をアプリケーション４１２に転送する。そうしたレコードが見出せない場合、インターセプタ４１４は遠隔装置の身元証明を求めてそのコールをＯＳカーネル４１６に転送し、ＯＳカーネル４１６がインテリジェント中間装置１１４の身元証明をバッファに書き込んで応答する。本実施例では、アプリケーション４１２側がそのときのコールに応じて受信する回答がインターセプタ４１４によって修正されたことを知らないので、インターセプタ４１４はクライアント識別情報をアプリケーション４１２に対して包み隠さず提供する。

インターセプタ４１４の別の実施例は代替的実施内容の細部を備える。ＯＳシステム・コールＡＰＩの細部基準および完全な支持が要求される程度によりインターセプタ４１４を使って傍受しなければならい多数のシステム・コールが存在する。たとえば、インターセプタ４１４がアプリケーション４１２による検索結果について受信し、タグの付かないデータをバッファに保存するように構成される場合、インターセプタ４１４はペンディング・データを読み込むためノン−ピーク・システム・コールを使用する。インターセプタ４１４の別の実施例によれば、インターセプタ４１４は読み込んでいるデータと関わりのあるシステム・コールを傍受することを必要とする場合があり、その上、インターセプタ４１４が内部ストレージから必要とするところにデータを送信する場合がある。

アプリケーション４１２はこの後いずれかの目的のためにバッファにあるクライアント１１０の識別情報を使用する。たとえば、アプリケーション４１２は要求に応じて適切なコンテンツを決定し、あるいは要求したコンテンツの受信に向けてクライアント１１０が許可できるか、否かを決定するためクライアント１１０の身元証明を使用する。アプリケーション４１２はまたクライアント１１０の身元証明を唯一のヴィジタのログに加えるようにしてもよい。

一実施例では、インターセプタ４１４は選択されたシステム・コールがライブラリ・コードで傍受されるようにアプリケーション４１２の始動シーケンスの中でプリロードされる共用ライブラリである。インターセプタ４１４の特定の実施内容はアプリケーション４１２で使用された特定の実施内容（たとえば、ＨＴＴＰウェブ・サーバまたはＳＭＴＰメール・サーバ）、さらにはＯＳカーネル４１６で使用された特定の実施内容（たとえば、ウィンドーズまたはリナックス）に従って各々インタフェースするように構成しなければならない。たとえば、ＯＳカーネル４１６の特定の実施内容は各々独自にフォーマットされたコールに応じて回答する。インターセプタ４１４を構成するにあたり、アプリケーション４１２およびＯＳカーネル４１６の特定の実施内容に従ってインタフェースする技術はこの技術分野では公知である。

本実施例に係るソース識別サーバ１１８では、クライアント１１０の身元証明をアプリケーション４１２に提供するのにアプリケーション４１２またはＯＳカーネル４１６に合わせた変更は必要としない。これはソース識別サーバ１１８にインターセプタ４１４を備えるように構成することを容易に可能にする。また、ソース識別サーバ１１８で受信した暗号化セキュア・データはインターセプタ４１４の機能によっては影響を受けない。別の実施例では、インターセプタ４１４の機能性がアプリケーション４１２のコードに合わせて修正して実施される。

クライアント識別情報が低レベル・パケット・ヘッダに埋め込まれている、図３Ｂのタグ付きパケット１３１０のようなタグ付きパケットを処理するためソース識別サーバ１１８は、典型的にはあるカーネル・レベルのアクセスを必要とする。代替的実施例のインターセプタ４１４はアプリケーション４１２から直接システム・コールを受信するように構成される、ローダブル・カーネル・モジュールであり、この後最初のシステム・コールをＯＳカーネル４１６に転送するか、あるいは上記のようにシステム・コールを修正するか、どちらかの方法を使用する。別の実施例では、ＯＳカーネル４１６は最初のシステム・コールの実施内容がインターセプタ４１４の機能性を備えて改良されるように修正される。

図５は本発明の一実施例に従うクライアント識別情報を取得するための方法を示すフローチャートである。ステップ５１２において、ソース識別サーバ１１８はコネクションをインテリジェント中間装置１１４に対して確立する。ステップ５１４において、ソース識別サーバ１１８はコネクションを通してデータ流のパケットを受信することを開始する。ステップ５１６において、インターセプタ４１４はパケットがタグを付されたパケットであるか、否かを決定するため最初のパケットにあるデータを注視する。インターセプタ４１４がタグ付きパケットを認識しない場合、本発明方法はステップ５１８へと続き、インターセプタ４１４が全てのデータを修正することなく、コネクションを通してパケットからアプリケーション４１２に転送する。

インターセプタ４１４が少なくとも１つのタグ付きパケットを認識した場合、ステップ５２０において、インターセプタ４１４は全てのクライアント識別情報が読み取られるまで、タグ付きパケットからクライアント識別情報を取り出す。ステップ５２２において、インターセプタ４１４は残りのデータをコネクションを通してパケットからアプリケーション４１２に転送する。

本発明が特定の実施例に対する参照と共に上記の通り説明された。しかしながら、添付の請求の範囲に記載のような本発明の本質と範囲とから離れることなく、多様な変更および変形がなし得ることは明らかである。したがって、上述の説明と図面とは限定の意味ではなく、具体例として考慮すべきである。

図１Ａは本発明に従う電子ネットワークの一実施例のブロック図である。 図１Ｂは本発明に従う電子ネットワークの他の実施例のブロック図である。 図２は本発明に従う図１Ａに示されるインテリジェント中間装置の一実施例のブロック図である。 図３Ａは本発明の好ましい実施例に従うタグ付きパケットの構成図である。 図３Ｂは本発明に従うタグ付きパケットの他の実施例の構成図である。 図４は本発明に従う図１Ａに示されるソース識別サーバの実施例のブロック図である。 図５は本発明の一実施例に従うクライアント識別情報を取得する方法に係るフローチャートである。

Claims (35)

1. 入力と出力とを有するインテリジェント中間装置と、
   前記インテリジェント中間装置の前記入力はクライアント識別情報を含むクライアント通信情報を受信することが可能であり、
   前記インテリジェント中間装置の前記出力はサーバ通信情報を送信することが可能であり、
   前記インテリジェント中間装置はクライアント識別情報を受信し、サーバ通信情報に含ませることができる、タグ付きデータ流を発生するタグ付加器を備えており、ここで、前記タグ付きデータ流は取り出せるクライアント識別情報を含んでおり、
   前記サーバ通信情報の前記タグ付きデータ流から前記クライアント識別情報を取得し、前記クライアント識別情報を前記サーバにあるアプリケーションに提供するように構成されるインターセプタと、
   を備える装置。
2. 前記タグ付加器がクライアント識別情報を少なくとも１つのタグ付きパケットのデータ・フィールドに挿入するように構成される請求項１記載の装置。
3. 前記タグ付加器がタグ付きデータ流を生成するためクライアント識別情報を通信情報データに連結するように構成される請求項１記載の装置。
4. 前記タグ付加器がクライアント識別情報を少なくとも１つのタグ付きパケットのプロトコル・ヘッダに挿入するように構成される請求項１記載の装置。
5. 前記タグ付加器がさらにクライアント識別情報を少なくとも１つのタグ付きパケットのＴＣＰヘッダに挿入するように構成される請求項４記載の装置。
6. 前記タグ付加器がさらにクライアント識別情報を少なくとも１つのタグ付きパケットのＩＰヘッダに挿入するように構成される請求項４記載の装置。
7. 前記クライアント識別情報がクライアントＩＰアドレスを含む請求項１記載の装置。
8. 前記インターセプタが前記アプリケーションから前記サーバのオペレーティング・システムへのサーバ通信情報のソースの身元証明を求める要求を含むコールを傍受し、この傍受したコールをサーバ通信情報のソースの身元証明に代わるクライアント識別情報を含む回答と共に応答することによってクライアント識別情報を前記アプリケーションに提供する請求項１記載の装置。
9. 前記インターセプタがさらにサーバ通信情報に含まれる通信データを前記アプリケーションに提供するように構成される請求項１記載の装置。
10. 入力としてクライアント通信情報を有し、クライアントに代わって送る出力としてサーバ通信情報を有するプロクシと、
    前記サーバ通信情報に含ませることができる、取り出せるクライアント識別情報を含む、少なくとも１つのタグ付きパケットを生成するタグ付加器と、
    を備えるインテリジェント中間装置。
11. 前記タグ付加器がクライアント識別情報を少なくとも１つのタグ付きパケットのデータ・フィールドに挿入するように構成される請求項１０記載のインテリジェント中間装置。
12. 前記タグ付加器がクライアント識別情報をサーバ通信データに連結し、クライアント識別情報が少なくとも１つのタグ付きパケットのデータ・フィールドに挿入されるように、得られたデータをパケット化するように構成される請求項１０記載のインテリジェント中間装置。
13. 前記タグ付加器がクライアント識別情報を少なくとも１つのタグ付きパケットのプロトコル・ヘッダに挿入するように構成される請求項１０記載のインテリジェント中間装置。
14. 前記タグ付加器がクライアント識別情報を少なくとも１つのタグ付きパケットのＴＣＰヘッダに挿入するように構成される請求項１３記載のインテリジェント中間装置。
15. 前記タグ付加器がクライアント識別情報を少なくとも１つのタグ付きパケットのＩＰヘッダに挿入するように構成される請求項１３記載のインテリジェント中間装置。
16. 前記クライアント識別情報がクライアントＩＰアドレスを含む請求項１０記載のインテリジェント中間装置。
17. インテリジェント中間装置からクライアント識別情報を含む、少なくとも１つのタグ付きパケットを有するサーバ通信情報を送信するように構成されるオペレーティング・システムと、
    サーバ通信情報からデータを受信するように構成されるアプリケーションと、
    タグ付きパケットからクライアント識別情報を取得するように構成されるインターセプタと、
    を備え、前記インターセプタがさらに前記アプリケーションから前記オペレーティング・システムへのサーバ通信情報のソースのクライアント識別情報を要求しているコールを傍受し、この傍受したコールをサーバ通信情報のソースに関するクライアント識別情報に代えてクライアント識別情報を含む回答と共に応答するように構成されるソース識別サーバ。
18. 前記アプリケーションがウェブ・サーバである請求項１７記載のソース識別サーバ。
19. 前記アプリケーションがｅ−メール・サーバである請求項１７記載のソース識別サーバ。
20. 前記クライアント識別情報がクライアントＩＰアドレスを含む請求項１７記載のソース識別サーバ。
21. 前記インテリジェント中間装置からのサーバ通信情報が暗号化セキュア・データを含む請求項１７記載のソース識別サーバ。
22. 前記少なくとも１つのタグ付きパケットがデータ・フィールドにクライアント識別情報を含む請求項１７記載のソース識別サーバ。
23. 前記少なくとも１つのタグ付きパケットがプロトコル・ヘッダにクライアント識別情報を含む請求項１７記載のソース識別サーバ。
24. 前記少なくとも１つのタグ付きパケットがＴＣＰヘッダにクライアント識別情報を含む請求項２３記載のソース識別サーバ。
25. 前記少なくとも１つのタグ付きパケットがＩＰヘッダにクライアント識別情報を含む請求項２３記載のソース識別サーバ。
26. 前記インターセプタが少なくとも１つの標準ライブラリ機能を優先するように環境を処理しているアプリケーションにインストールされる請求項１７記載のソース識別サーバ。
27. 前記インターセプタがオペレーティング・システムにローダブル・モジュールとしてインストールされる請求項１７記載のソース識別サーバ。
28. サーバに送信される通信情報に関するパケットとしてクライアント識別情報を含む、少なくとも１つのタグ付きパケットを生成し、
    前記通信情報を前記サーバに送信し、
    前記通信情報内の少なくとも１つのタグ付きパケットを認識し、
    前記少なくとも１つのタグ付きパケットからクライアント識別情報を取得し、
    前記クライアント識別情報を前記サーバにあるアプリケーションに提供する、
    ことを含む方法。
29. 前記少なくとも１つのタグ付きパケットを生成するステップが前記クライアント識別情報を前記少なくとも１つのタグ付きパケットのデータ・フィールドに挿入することを含む請求項２８記載の方法。
30. 前記少なくとも１つのタグ付きパケットを生成するステップが前記クライアント識別情報を通信情報データに連結し、前記クライアント識別情報が前記少なくとも１つのタグ付きパケットのデータ・フィールドに挿入されるように、得られたデータをパケット化することを含む請求項２８記載の方法。
31. 前記少なくとも１つのタグ付きパケットを生成するステップが前記クライアント識別情報を前記少なくとも１つのタグ付きパケットのプロトコル・ヘッダに挿入することを含む請求項２８記載の方法。
32. 前記少なくとも１つのタグ付きパケットを生成するステップが前記クライアント識別情報を前記少なくとも１つのタグ付きパケットのＴＣＰヘッダに挿入することを含む請求項３１記載の方法。
33. 前記少なくとも１つのタグ付きパケットを生成するステップが前記クライアント識別情報を前記少なくとも１つのタグ付きパケットのＩＰヘッダに挿入することを含む請求項３１記載の方法。
34. 前記クライアント識別情報を前記アプリケーションに提供するステップが
    前記アプリケーションから前記サーバのオペレーティング・システムへの前記通信情報のソースの身元証明を求める要求を含むコールを傍受し、
    この傍受したコールを前記通信情報のソースの身元証明に代わるクライアント識別情報を含む回答と共に応答する、
    ことを含む請求項２８記載の方法。
35. さらに、最初の通信情報データを前記アプリケーションに提供することを含む請求項２８記載の方法。

Images