JP2004525558A - 信頼性のないプロトコルを利用して確実なストリーミングデータ送信機能を提供するための方法および装置 - Google Patents
信頼性のないプロトコルを利用して確実なストリーミングデータ送信機能を提供するための方法および装置 Download PDFInfo
- Publication number
- JP2004525558A JP2004525558A JP2002564846A JP2002564846A JP2004525558A JP 2004525558 A JP2004525558 A JP 2004525558A JP 2002564846 A JP2002564846 A JP 2002564846A JP 2002564846 A JP2002564846 A JP 2002564846A JP 2004525558 A JP2004525558 A JP 2004525558A
- Authority
- JP
- Japan
- Prior art keywords
- computer
- record
- ssl
- proxy server
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/12—Transmitting and receiving encryption devices synchronised or initially set up in a particular manner
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0457—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply dynamic encryption, e.g. stream encryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/166—Implementing security features at a particular protocol layer at the transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
Abstract
【課題】ユーザ・データグラム・プロトコルなどの信頼性のない通信プロトコルを利用してデータを確実に送信するための方法および装置を提供する。
【解決手段】ある変形態様においては、本発明は、従来のセキュア・ソケット・レイヤ（ＳＳＬ）プロトコルおよびＳＯＣＫＳプロトコルとの互換性を維持し、従来のＳＯＣＫＳ処理と同様の方法により、プロキシサーバとクライアントコンピュータとの間で確実なＵＤＰデータグラムを送信できる。ＴＣＰなどの保証配信サービスに依存し、以前に送信されたデータレコードを参照して連続的なデータレコードを暗号化する従来のＳＳＬ処理とは対照的に、暗号化は、各送信データレコードに埋め込まれたノンスを用いて実行される。このノンスは、レコードの暗号化／暗号解読のための初期化ベクトルおよび一意的な識別子としての役割を果たし、レコードの認証を行う。
【選択図】図５Ａ
【解決手段】ある変形態様においては、本発明は、従来のセキュア・ソケット・レイヤ（ＳＳＬ）プロトコルおよびＳＯＣＫＳプロトコルとの互換性を維持し、従来のＳＯＣＫＳ処理と同様の方法により、プロキシサーバとクライアントコンピュータとの間で確実なＵＤＰデータグラムを送信できる。ＴＣＰなどの保証配信サービスに依存し、以前に送信されたデータレコードを参照して連続的なデータレコードを暗号化する従来のＳＳＬ処理とは対照的に、暗号化は、各送信データレコードに埋め込まれたノンスを用いて実行される。このノンスは、レコードの暗号化／暗号解読のための初期化ベクトルおよび一意的な識別子としての役割を果たし、レコードの認証を行う。
【選択図】図５Ａ
Description
【技術分野】
【０００１】
本発明は、一般的に、データ送信方式およびプロトコルに関する。特に、本発明は、ユーザ・データグラム・プロトコル（ＵＤＰ）などの信頼性のないプロトコルを利用して、２つ以上のコンピュータノード間で確実にデータを送信するための方法および装置を提供する。さらに、本発明は、本発明の確実な送信を利用したコンピュータとの通信セッションを、新たなセッションを生成する必要なく、別のコンピュータに切り換えることができる方法および装置を提供する。
【背景技術】
【０００２】
本願は、２００１年２月１２日出願、発明者マーク・ファン・ハイニンゲン（Marc van Heyningen）、名称「信頼性のないプロトコルを利用して確実なストリーミングデータ送信機能を提供するための方法および装置（Method And Apparatus For Providing Secure Streaming Data Transmission Facilities Using Unreliable Protocols）」の同時係属米国特許出願の一部継続出願に関連し、この一部継続出願はその全体が本願に引用により組み込まれている。また、本願は、２００１年２月１３日出願、発明者ロジャー・エリクソン（Rodger Erickson）、名称「状態転送動作のための分散型キャッシュ（Distributed Cache For State Transfer Operations）」の同時係属米国特許出願に関連し、この米国特許出願もその全体が本願に引用により組み込まれている。
【０００３】
周知のトランスミッション・コントロール・プロトコル／インタネット・プロトコル（ＴＣＰ／ＩＰ）は、コンピュータ間でデータパケットを送信するために長年使用されてきた。ＴＣＰは、データパケットの保証配信／配列方式を提供し、ＴＣＰを使用する２以上のコンピュータは、このプロトコルに依存して、任意のパケットが、送信された順序でその宛先に到達することを保証する。インタネット・プロトコル（ＩＰ）は、一般的に、保証配信なしにポイント間パケット送信サービスを提供する。図１Ａは、従来のプロトコルスタックに従ってＴＣＰ／ＩＰ上にアプリケーションプログラムを積み上げる方法を示す。一般的なハイパーテキスト・トランスポート・プロトコル（ＨＴＴＰ）は、ウェブページの取出しと表示のために、クライアントのブラウザとサーバコンピュータとの間のＴＣＰ接続の存在に依存している。
【０００４】
ＴＣＰは、内蔵メカニズムを利用して保証配信機能を提供する（すなわち、各アプリケーションは、信頼性の詳細に関わる必要がない）が、ＴＣＰの使用の欠点は、データストリームを送信するときに遅延などの副作用を招く可能性があることである。例えば、２つのコンピュータが、ＴＣＰを使用してパケット化されたビデオストリームを送信すると、パケットを受信パケットストリームへと再配列する前に、喪失または脱落したパケットを再送信しなければならないので、受信パケットが「ギクシャク」して見える。結果的に、ＴＣＰは、ビデオ会議アプリケーションなどのデータストリーミングにとって良い候補とはならない。
【０００５】
周知のユーザ・データグラム・プロトコル（ＵＤＰ）は、クライアントコンピュータおよびサーバコンピュータといった２つのコンピュータ間で通信するためのパケット志向型の送信サービスを提供する。ＴＣＰなどの保証配信プロトコルとは対照的に、ＵＤＰを使用して送信されたパケットは、宛先のコンピュータに到達することが保証されない。さらに、特定の順序で送信されたパケットが、宛先のコンピュータに順不同で到達する場合もある。したがって、ＵＤＰは、「信頼性のない」転送プロトコルと称されている。しかし、ＴＣＰなどの保証配信プロトコルとは対照的に、ＵＤＰは、時間重視の配信方式を提供し、ビデオデータなどのストリーミングメディアにとってより好適である。
【０００６】
ビデオ会議などのアプリケーションにより、ストリーミングメディアの重要性が高まり、確実なストリーミング送信機能を提供する必要性がある。例えば、数多くの企業において、本社設備と１以上の遠隔地オフィスとの間でストリーミングビデオを送信する必要性がある。送信には、会社が意図しない受信者や盗聴から保護する必要のある機密情報が含まれている場合がある。ＴＣＰもＵＤＰもこの様なセキュリティを提供しないので、この様な送信には不十分である。
【０００７】
近年、保証配信プロトコルを暗号手法で強化することによって確実な送信機能を提供するために、様々な試みがなされてきた。例えば、セキュア・ソケット・レイヤ（ＳＳＬ）は、サーバコンピュータおよびクライアントコンピュータといった２つの装置間の確実なチャネルを提供するプロトコルである。この様な確実なチャネルは、透過性があり（トランスペアレントであり）、かつ、クライアントとサーバとの間で暗号化され、ＴＣＰ上で実行可能な殆ど全てのプロトコルが、最小限の修正によりＳＳＬ上で実行可能となっている。確かに、ＳＳＬ／ＴＬＳセキュリティおよび障害検出は、ＴＣＰ（または同様の保証配信プロトコル）に依存して、パケットの配列と保証配信とを行っている。様々な修正を経て、ＳＳＬは、トランスポート・レイヤ・セキュリティ（ＴＬＳ）と改名され、ＲＦＣ２２４６に反映されているように、インタネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）に採用されている。（ＳＳＬ／ＴＬＳという用語は、これら２つの緊密に関係するプロトコルを一括して称するために使用される。）ＳＳＬ／ＴＬＳの主なアプリケーションは、オンラインショッピングであり、オンラインショッピングでは、消費者は、ＨＴＴＰプロトコルやウェブブラウザを安全に利用してクレジットカード機密情報を送信する。
【０００８】
大抵のインタネットプロトコルはＴＣＰ接続上で動作するので、ＳＳＬ／ＴＬＳは、クライアントコンピュータおよびサーバコンピュータなどの２つ以上のコンピュータ間で確実にデータを送信する便利な方式を提供する。図１Ｂは、アプリケーションが、ＳＳＬ／ＴＬＳを使用してＴＣＰなどの信頼性のある接続上で確実なデータを送信する方法を構造的に示している。従来どおり、ＳＳＬ／ＴＬＳを利用して確実にデータを送信するステップは、一般的に以下のステップを含んでいる。
（１） クライアントが、サーバコンピュータとのＴＣＰ接続を確立する。
（２） クライアントとサーバが、ＳＳＬ／ＴＬＳプロトコルを使用して、信任情報（ＳＳＬ／ＴＬＳハンドシェイク、プロトコルメカニズムの取り決め、接続毎のキーの確立など）を交換する。
（３） 各ＨＴＴＰ要求（例えば、ＧＥＴ）が、暗号内容を有するＳＳＬ／ＴＬＳレコードに変換される。
【０００９】
図１Ｃは、サンプルのＳＳＬ／ＴＬＳレコードを示し、これは、ヘッダ（ＨＤＲ）と、暗号化データまたは暗号テキストと、ＭＡＣ（メッセージ認証チェック）とを含んでいる。ＭＡＣは、強力なチェックサムと同様のキー付きハッシュによりメッセージの完全性を保証し、一般的に、関数ＭＡＣ＝ｈ（キー，プレインテキスト，連番）として演算される。ここで、連番は、連続レコード用の１増分カウンターである。連番は、ハッカーがＴＬＳ使用のコンピュータ間の確実な通信を暗号解読または破壊しようとしてパケットの傍受や再配列を試みた場合に発生するいわゆる「スプライシング攻撃」を防止するので、ＴＬＳにより演算されたＭＡＣの重要な側面を構成する。受信側ＴＬＳが受信レコードに不正確な連番を検出した場合、故意の侵害としてそのレコードを拒絶し、接続を終了する。これにより、送信側および受信側は、別のＴＣＰ接続を再確立しなければならず、結果的に時間とリソースの浪費となる。
【００１０】
透過性のある性質上、ＴＣＰベースのプロトコル（例えば、ＨＴＴＰ、ＦＴＰなど）または同様の保証配信プロトコルは、ＴＬＳ上で動作可能である。ＳＳＬおよびＴＬＳの更なる詳細については、下記非特許文献１に記載されている。
しかし、ＴＣＰなどの保証配信プロトコルに対する依存により、ＳＳＬ／ＴＬＳは、ＴＣＰと同様の性能問題の影響を受けやすい。例えば、ＳＳＬ／ＴＬＳを用いてストリーミングビデオデータを送信すると、その基礎となっているＴＣＰと同様の犠牲と不利益を招く（例えば、「ギクシャク」したビデオとなることがある）。ＳＳＬ／ＴＬＳは、パケットが脱落したり順不同に受信された場合に接続を終了するので、その性質上、ＴＣＰにより提供されるような信頼性のある接続の利用が必要である。
【００１１】
近年、プライベート・コミュニケーション・テクノロジー（ＰＣＴ）として知られているプロトコルが提案されているが、商業的な成功を収めていない。ＰＣＴは、（いわゆる「ストリーム暗号」を用いた）確実なデータグラムトラフィックへとＳＳＬを拡張する試みである。例えば、ＰＣＴは、ＳＳＬ（５バイト、１レコードタイプ、２バージョン番号、２レングス）とは異なるヘッダフォーマット（４バイト、２レングス、２レコードタイプ）を使用していた。また、ハンドシェークメッセージ本体には、異なる開始フォーマットが含まれていた。すなわち、ＳＳＬは、１バイト（ハンドシェークタイプ）しか使用しないが、ＰＣＴは、４バイト（２ハンドシェークタイプ、２レコードフラグ）を使用している。ＰＣＴデータグラムサポートは、以下のフォーマットを使用している。
【００１２】
2 bytes of key_length
(key_length) bytes of key data
(data_length) bytes of encrypted data
(mac_length) bytes of MAC data
一方、ＳＳＬのデータグラムサポートは以下のようなフォーマットである。
【００１３】
(data_length) bytes of encrypted data
(mac_length) bytes of MAC
(padding_length) bytes of padding
1 byte of padding_length
(nonce_length) bytes of nonce
ＰＣＴは、各データグラムが、ENCRYPTED_KEY_1_DATA（DK_ENCRYPTED_KEY_DATAの一部である各レコードにランダム値が割り当てられる）によりマスタキーをハッシュすることによって生成された新たな暗号化キーを有するメカニズムを指定する。
【００１４】
提案されたＰＣＴメカニズムは、様々な性能的な犠牲を強いる。例えば、ＰＣＴメカニズムは、ストリーム暗号と共に使用可能であるが、各レコードを処理するための更なるハッシュとキースケジュール生成により、処理速度がかなり遅くなる。すなわち、データグラム毎に異なるキーを使用するので、演算上の犠牲が大きい。キースケジュール設定は、ブロック暗号にとって高価である。さらに、ＰＣＴは、ＳＯＣＫＳなどのマルチプロトコルプロキシとの統合メカニズムを提供していなかった。
【００１５】
従来、ＵＤＰが確実な通信には不適切であるといわれてきた。例えば、下記非特許文献１のレスコーラの著書は、特に、「ＵＤＰは、（信頼性のある伝送を提供しないので）レコードの喪失や再配列が自由に起こり、まるでＳＳＬ実施に対する積極的な攻撃のようであるので、ＳＳＬをＵＤＰ上でうまく実行することができない。」と記述している。結局、先行技術は、確実なデータ送信のためにＳＳＬと共にＵＤＰを使用することを避けるように提言している。それでも、ＵＤＰは、数々のストリーミングメディアアプリケーションにとって適合性が良く、時折発生するデータパケットの脱落を許容するが、ＴＣＰで発生する遅延を許容することはない。例えば、リアルタイムで放映されるビデオ会議は、時折失われるビデオフレームを許容するが、失われたパケットの再送信や再配列のときに発生する「ギクシャクした動き」を許容しない。さらに、標準ＳＳＬ上で送られる標準ＵＤＰでは、ユーザセッションの終了が頻繁に起こる。
【００１６】
プロトコルの中には、ビデオまたはオーディオストリーミングなどの高性能データを送信するために、ＴＣＰとＵＤＰの両方に依存するものもある。例えば、ＲＥＡＬＡＵＤＩＯは、ＴＣＰおよびＵＤＰの両方を使用していると考えられており、ＴＣＰを使用して信号発信（例えば、開始／停止）を行う一方、ＵＤＰを使用してストリーミング内容のデータパケットを送信するようになっている。しかし、ＵＤＰデータグラムは、自由に送信されるので、傍受や攻撃を受けやすい。
【００１７】
ＫＥＲＢＥＲＯＳとして知られているプロトコルは、主にアカデミックサークルで使用されているが、ＵＤＰデータグラムの暗号化によりセキュリティを提供する。ＫＥＲＢＥＲＯＳがデータグラムセキュリティ提供のために使用するメカニズムは、ＲＦＣ１９６４に記載されている。しかし、これは、ＳＳＬ／ＴＬＳプロトコルと互換性がないので、広く普及していない。ＫＥＲＢＥＲＯＳが商業的な成功を収めていない主要な理由の１つに、動作が複雑で、ネットワーク処理に広く使用できるほど合理化されていないことが挙げられる。特に、ネットワークベースのセキュリティソフトウェアは、ユーザのアクセスの制御と保護のためにウェブサーバおよびプロキシサーバと効率よく相互動作しなければならない。一般的に、単純なプロトコルは、高速処理／分散システムに有利である。
【００１８】
また、ＫＥＲＢＥＲＯＳは、確実なＵＤＰ／ＴＣＰトラフィックを通信するために、別個の暗号化メカニズム、すなわち、キー確立ハンドシェイクを使用する。しかし、ＳＯＣＫＳなどのマルチプロトコルプロキシサーバ標準上で実行されるＳＳＬなどの単一標準セキュリティプロトコルの下でこれらを統合することによって、演算／ネットワークトラフィックのオーバヘッドを低減することが望ましい。さらに、ＫＥＲＢＥＲＯＳは、暗号化アルゴリズムを初期化する目的で、データレコードを従来の方法で拡張するために、パケット識別のためのランダムキーフィールドを追加している。しかし、ＫＥＲＢＥＲＯＳがデータレコード内に個別の連番を有するので、これにより、更なる演算／ネットワークトラフィックが必要となる。あるシステムにとっては、両方の目的を果たす単一のフィールドを有することが好適である。
【００１９】
ＵＤＰおよびＳＳＬは、ソフトウェア産業では標準となっている。ＵＤＰは、データグラム処理に使用され、ＳＳＬは、確実な通信を提供する。同時に、一般的なＳＯＣＫＳプロトコルを実行するものなど、マルチプロトコルプロキシサーバの採用は、システム内でＴＣＰやＵＤＰなどの産業用標準通信プロトコルを組み合わせる手段を提供する。ＵＤＰとＳＳＬとの互換性がないので、最近までこれは不可能であった。ＳＯＣＫＳなどの単一のプロキシサーバプロトコルの下でネットワーク通信を管理するために発生したこの問題と制約とを理解するためには、先ず、ＳＯＣＫＳの情報処理方法を理解する必要がある。
【００２０】
ＳＯＣＫＳプロトコルは、ファイアウォルなどの境界を設定するための一般的なプロキシプロトコルを提供する。ＩＥＴＦ ＲＦＣ１９２８に記載されているこのプロトコルのバージョン５は、認証、ＵＤＰサポートなどの機能を提供する。図２は、プロキシサーバおよびＳＯＣＫＳプロトコルにより、ファイアウォルを介してサーバと接続するための従来の方策を示している。図２に示すように、クライアントコンピュータ２０１は、プロキシサーバ２０２を介してアプリケーションサーバ２０３と通信する。このシステムは、ネットワーク間のアプリケーションレイヤゲートウェイの役割を果たすファイアウォル（図示せず）を備えている場合もある。アプリケーションサーバ２０３は、通常、ＴＥＬＮＥＴ、ＦＴＰ、ＳＭＴＰ、ＨＴＴＰアクセスを提供する。クライアントコンピュータ２０１は、アプリケーション２０１１（例えば、ウェブブラウザ）と、ＳＯＣＫＳクライアント２０１２とを備えている。プロキシサーバ２０２は、ＳＯＣＫＳサーバ２０２１と、プロキシ機能２０２２とを備えている。セキュリティ機能を提供するＳＯＣＫＳバージョン５によれば、クライアントアプリケーション２０１１は、以下のようにサーバ２０３からのサービスを得ることができる
先ず、クライアントアプリケーション２０１１は、サーバ２０３への接続要求をする。次に、ＳＯＣＫＳクライアント２０１２は、要求された接続を検出し、プロキシサーバ２０２を介してサーバ２０３との通信に対処すべきことを認識する。結果的に、ＳＯＣＫＳクライアント２０１２は、ＴＣＰ接続を確立するためにＳＯＣＫＳサーバ２０２１に要求を送信する。プロキシ機能２０２２は、サーバ２０３との接続を確立し、クライアントアプリケーション２０１１とサーバ２０３との間の以降の通信は、ＳＯＣＫＳサーバ２０２１およびプロキシ機能２０２２を介して行われる。従来と同様に、ＳＯＣＫＳは、クライアント２０１との確実な接続を確立するためにＳＳＬ／ＴＬＳを使用し、接続確立を許容する前にパスワードを要求する。図２のアーキテクチャは、１つのポイント（例えば、プロキシサーバ２０２）でサーバ２０３へのアクセスを制限し、ファイアウォルを貫通するような方法でサーバ２０３との通信負荷の一部を負担する。セキュリティを提供するためにＳＳＬ／ＴＬＳに依存しているので、図２の接続は、必ずＴＣＰ（同様の保証配信プロトコル）に依存する。
【００２１】
図２のアーキテクチャは、不確実なＵＤＰデータグラムの送信のためにも利用可能である。この方式には、ポートを介して不確実なＵＤＰデータグラムを送信する一方、確実なＳＳＬ／ＴＬＳ／ＴＣＰ接続を介して確実なコマンドを送信するように、クライアント２０１とプロキシサーバ２０２との間のＵＤＰポート「接続」を取り決めることが含まれている。この様な方式は、ＵＤＰデータグラムが不確実であるということを反映して「無防備なＵＤＰ」モードと称されることもある。この手法を採用しているシステムは、数年にわたり、ワシントン、シアトルのアベンテイル社から市販されてきた。一般的に、ＳＯＣＫＳクライアント２０１２は、クライアント２０１から送信される各レコードにＳＯＣＫＳヘッダを付与し、ＳＯＣＫＳヘッダは、サーバ２０３に送信される前にＳＯＣＫＳサーバ２０２１により取り除かれる。
【００２２】
上述のように、ＳＳＬ／ＴＬＳは信頼性のある接続サービスを提供するためにＴＣＰに依存しているので、ＳＳＬ／ＴＬＳのコンテキストでＵＤＰデータグラムを確実に送信することは不可能である。しかし、図２の方式で確実なＵＤＰサービスを提供することは有利であり、プロキシサーバ２０２は、データセキュリティを犠牲にすることなく、クライアント２０１とサーバ２０３との間の高性能ビデオストリーミングを円滑にできる。結局、課題は、好ましくは、ＳＳＬをセキュリティレイヤとして使用し、ＳＯＣＫＳをマルチプロトコルプロキシサーバとして使用して、プロキシサーバ２０２を介して確実なＴＣＰおよび確実なＵＤＰを実施するための方法を見出すことである。一般的には、ＴＣＰに対する依存によるオーバヘッドおよび不都合を招くことなく、ＳＳＬ／ＴＬＳ標準との互換性を維持する方法を見出すことが望まれる。
【００２３】
ＳＳＬ／ＴＬＳプロトコルは、ＵＤＰ上でうまく実行できないことに加えて、更に別の欠点がある。上記の例では、クライアント装置２０１は、プロキシサーバ２０２との完全ＳＳＬ／ＴＬＳ「ハンドシェイク」を完了することによって、プロキシサーバ２０２との確実なプロトコルセッションを開始する。このハンドシェイク中に、クライアントコンピュータ２０１およびプロキシサーバ２０２は、ＳＳＬ／ＴＬＳバージョン番号、暗号設定、セッション特定データ、認証証明など、ＳＳＬ／ＴＬＳプロトコルを利用して互いに通信すべき情報を交換する。この様な情報を利用して、クライアントコンピュータ２０１およびプロキシサーバ２０２は、同一のマスタシークレットキーを生成し、それを用いて個々のセッションキーを生成する。これらのセッションキーは、セッション中に交換した個々の情報グループの暗号化と暗号解読とを行い、交換情報の完全性を確認するために用いる対称キーである。
【００２４】
当業者に理解されるように、ＳＳＬ／ＴＬＳセッションを開始するために完全ＳＳＬ／ＴＬＳハンドシェイクを実行するには、時間がかかり、ネットワーク通信トラフィックに関しても、クライアント装置２０１とプロキシサーバ２０２との処理時間に関しても、ネットワークのリソースに大きな負荷をかける。しかし、プロキシサーバ２０２が、完全ＳＳＬ／ＴＬＳハンドシェイクにおいて必要なＳＳＬ／ＴＬＳセッション情報を受信すると、プロキシサーバ２０２は、部分ＳＳＬ／ＴＬＳハンドシェイクのみを利用してクライアントコンピュータ２０１とのそのＳＳＬ／ＴＬＳセッションを再開する。好適にも、部分ＳＳＬ／ＴＬＳハンドシェイクは、完全ＳＳＬ／ＴＬＳハンドシェイクよりもかなり迅速であり、消費するネットワークリソースも少ない。
【００２５】
しかし、クライアントコンピュータ２０１とプロキシサーバ２０２との間の接続が終了し、クライアントコンピュータ２０１が、別のプロキシサーバ２０２を介してアプリケーションサーバ２０３との通信を確立しようした場合に、この構成に関して問題が発生する。例えば、最初のプロキシサーバ２０２が機能せず、利用不可能となるか、または、負荷バランサが最初のプロキシサーバ２０２の通信負荷を低減するために、新たな接続をクライアント装置２０１から新たなプロキシサーバ２０２へと単にルーティングする場合がある。いずれの場合も、新たなプロキシサーバ２０２は、クライアントコンピュータ２０１とのＳＳＬ／ＴＬＳセッションを再開するために必要なＳＳＬ／ＴＬＳセッション情報を有していない。したがって、クライアント装置２０１および新たなプロキシサーバ２０２は、新たなＳＳＬ／ＴＬＳ通信セッションを確立するために完全ＳＳＬ／ＴＬＳハンドシェイクを実行しなければならない。このプロセスは時間がかかり、クライアントコンピュータ２０１および新たなプロキシサーバ２０２にとっては多大な処理時間を要する。さらに、クライアント装置２０１とプロキシサーバ２０２との間の元のセッションの状態によっては、前のセッションの状態の喪失が代替不可能である場合もある。例えば、前のセッションの状態が、複製不可能なデータの交換により確立されていた場合、そのセッションの再生は不可能である。
【００２６】
この問題を解決するために、クライアントコンピュータ２０１とその関連のプロキシサーバ２０２との間で終了された接続を、新たなプロキシサーバ装置２０２に対してではなく、元のプロキシサーバ２０２に対して再確立するようにしたネットワークシステムがある。例えば、クライアント装置２０１が特定のプロキシサーバ２０２に対してセッションを確立した時点を認識し、以降の全ての接続をクライアントコンピュータ２０１からプロキシサーバ２０２へとルーティングするように負荷バランサを設計しているシステムがある。しかし、この解決策は、数々の欠点を有する。負荷バランサが非常に複雑化し、様々な機能を果たすことが要求される。さらに、元のプロキシサーバ２０２が利用不可能になった場合、例えば、元のプロキシサーバが機能せず、クライアントコンピュータ２０１との接続の再確立が不可能になった場合に発生する状況に対処するものではない。また、最初のプロキシサーバ２０２が、他のクライアントコンピュータとの接続により過負荷となった場合の状況に対処するものではない。事実、この解決策により、負荷バランサは負荷バランス機能を果たせなくなる。
【非特許文献１】
アディソン・ウェスレイ（Addison Wesley）発行、エリック・レスコーラ（Eric Rescorla）による著書「ＳＳＬとＴＬＳ：確実なシステムの設計と構築（SSL and TLS: Designing and Building Secure Systems）」ISBN0-201-61598-3
【発明の開示】
【発明が解決しようとする課題】
【００２７】
信頼性のある通信プロトコルに本質的に伴う不都合とオーバヘッドとを招くことなく確実なデータ送信機能を提供するための従来の試みの失敗を鑑み、確実なビデオ会議など、高帯域のアプリケーションをサポートするために、この様な機能を提供する必要性がある。さらに、ＳＳＬ／ＴＬＳとの互換性を維持しながら、確実なデータ送信サービスを提供する必要性がある。さらに、クライアントコンピュータと第１のプロキシサーバとの間で確立されたＳＳＬ／ＴＬＳセッションの状態を維持しながら、クライアントコンピュータが、第１のプロキシサーバとの通信接続を第２のプロキシサーバへと切り換えることができるネットワーク構成が必要である。好ましくは、第１のプロキシサーバが機能不全などの問題により利用不可能になった場合でも、ネットワーク構成は、第１のプロキシサーバとの接続から第２のプロキシサーバとの接続へのこの様な切り換えが可能でなければならない。
【課題を解決するための手段】
【００２８】
本発明は、ＵＤＰなどの信頼性のないプロトコル上で暗号化データを送信するための方法および装置を提供することによって前述の問題を克服する。ある変形態様においては、特殊ビットがデータレコード内に設定され、プロキシサーバで受信されたときに、レコードは特殊な処理に回される。この特殊な処理には、繰り返しレコードの存在を検出するためのノンスの使用や、他のレコードのデータを参照することなくプロキシサーバにレコードを暗号解読させる初期化ベクトルの使用が含まれる。特殊なビットセットを有さないデータレコードは、従来のＳＳＬ／ＴＬＳ処理に従って処理される。
【００２９】
さらに、本発明は、複数の異なるロケーションにコピーを分散させたキャッシュを用いるネットワーク構成を提供する。本発明によれば、任意のプロキシサーバとのセッションに関するＳＳＬ／ＴＬＳセッション情報がキャッシュに格納されるので、少なくとも１つの他のプロキシサーバに対してアクセス可能である。クライアント装置が、第１のプロキシサーバとの接続から第２のプロキシサーバとの接続へと切り換えるとき、この構成を利用して、第２のプロキシサーバは、クライアント装置と第１のプロキシサーバとのＳＳＬ／ＴＬＳ通信セッションに対応するキャッシュから、ＳＳＬ／ＴＬＳセッション情報を検索することができる。そして、第２のプロキシサーバは、検索されたＳＳＬ／ＴＬＳセッション情報を用いて、クライアント装置とのセッションを引き受けることができる。本発明のある実施形態によれば、キャッシュの同一コピーがこのネットワーク構成の各プロキシサーバのために格納され、各プロキシサーバは、キャッシュのそれ自体のコピーにアクセスして必要なＳＳＬ／ＴＬＳセッション情報を得る。本発明の他の実施形態においては、このネットワーク構成における全てのプロキシサーバにアクセス可能な単一のソース（例えば、冗長なキャッシュ記憶装置セット）においてキャッシュのコピーが保持される。
【００３０】
本発明のその他の特徴および利点は、以下の詳細な説明および図面を参照することにより明らかになるであろう。
【発明を実施するための最良の形態】
【００３１】
図３Ａは、本発明のある変形態様に係る、送出方向の（例えば、クライアントからアプリケーションサーバへの）改良ＳＯＣＫＳプロトコルを用いたシステムを示す。図３Ａに示すように、クライアントコンピュータ３０１は、プロキシサーバ３０２を介してアプリケーションサーバ３０３と通信する。図２の従来のシステムと同様に、クライアントコンピュータは、ＳＯＣＫＳクライアント３０１２と交信するクライアントアプリケーション３０１１を備えている。しかし、図２の従来のシステムとは対照的に、ＳＯＣＫＳ処理は、以下に詳述するように、図２のシステムとは更に異なる機能を実行するように改良されている。アプリケーションサーバ３０３は、図２を参照して説明した方法と同じ方法で動作する。
【００３２】
図２のシステムとは対照的に、プロキシサーバ３０２は、２つのタイプのＳＯＣＫＳ処理機能、すなわち、従来のＳＯＣＫＳ処理機能３０２２および改良ＳＯＣＫＳ処理機能３０２３を備えている。レコード検出器３０２１は、ＳＯＣＫＳクライアント３０１２からのサーバ向けのレコードを受信し、レコードが「確実なＵＤＰ」レコードであることを示す特定のビットが設定されているか否かにより、ソフトウェアスイッチを介して従来のＳＯＣＫＳ処理機能３０２２または改良ＳＯＣＫＳ処理機能３０２３にレコードをルーティングする。以下、改良ＳＯＣＫＳ処理機能３０２３の詳細について説明する。
【００３３】
図３Ａに示すアーキテクチャによって、プロキシサーバ３０２は、図２のＳＯＣＫＳクライアント２０１２などの従来のＳＯＣＫＳクライアント、または、暗号化データの送信のためにＵＤＰなどの信頼性のないプロトコルを用いる本発明の原則に従って動作するように改良されたＳＯＣＫＳクライアント（改良ＳＯＣＫＳクライアント３０１２）と共に動作することができる。さらに、両タイプのクライアントを同時に収容することができる。ある実施形態において、ＵＤＰプロトコルおよびＴＣＰプロトコルは、同一のプロキシサーバ上で動作可能である。以下、改良処理を更に詳述する。プロキシ機能３０２４は、図２のプロキシ機能２０２２とほぼ同じ方法で動作する。
【００３４】
図３Ａのアーキテクチャに関して、本発明の原則の範囲内に属する数々の変形態様がある。一例として、レコード検出器３０２１は、任意とすることができる。また、別の例として、クライアント３０１およびプロキシサーバ３０２が、初期化シーケンス中に、ここに記載されている改良暗号化方式に従って以降の全てのＵＤＰデータグラムを両者間で送信することに同意すると、何れのプロトコルに準拠しているかを決定するために、各レコードにフラグを立てたり評価したりする必要はない。もちろん、他のフィールドによりレコードタイプを暗に指定して、レコードタイプ（そして、結果的な処理）が他のフィールドから明確となるようにすることも可能である。もちろん、「無防備なＵＤＰ」と同様に、確実なＵＤＰをサポートするキーやその他の暗号化レコードを含めるために、確実なＴＣＰメッセージを本発明と組み合わせることもできる。さらに、プロキシサーバ３０２の機能をサーバ３０３や他のコンピュータに組み込むことができ、これらの機能を実行するための別個のプロキシサーバは必要ない。結局、双方向の確実な通信経路が確立されるように、暗号化レコードをクライアントコンピュータ３０１からプロキシサーバ３０２へと、または、その逆に送信可能であることは明白である。
【００３５】
図３Ｂは、送入（サーバからクライアントへの）フロー方向に関する図３Ａのシステムを示す。プロキシ機能３０２４を介して受信されるレコードは、ＳＯＣＫＳ処理機能３０２５に転送され、クライアント側レコード検出器機能３０１５に転送される。レコード検出器３０１５は、確実なＵＤＰビットセットを有するレコードを検出すれば、それに応答して、この様なレコードを改良ＳＯＣＫＳ処理機能３０１４へとルーティングし、そうでなければ、従来のＳＯＣＫＳ処理機能３０１３に送信する。なお、本発明の原則から逸脱しない限り、クライアント３０１、プロキシサーバ３０２、または、別のコンピュータに様々なＳＯＣＫＳ処理機能を配置可能であると解釈される。
【００３６】
図４Ａは、暗号を使用するＳＳＬ／ＴＬＳレコードを生成するための従来の手法を示す。本発明の暗号化原理の適用方法を説明する前に、先ず、ＳＳＬ／ＴＬＳによる暗号化および暗号解読の実行方法について簡単に概説する必要がある。
図４Ａに示すように、従来のデータ・エンクリプション・スタンダード（ＤＥＳ）などの暗号化機能４０４を使用して、プレインテキスト４０１の最初のバイトを暗号化する。送信側および受信側（例えば、ＳＯＣＫＳクライアント２０１２およびＳＯＣＫＳサーバ２０２１）で共有されるセッション暗号化キー４０２ならびに初期化ベクトル（ＩＶ）４０３が、暗号化機能４０４に入力され、結果的に暗号化暗号テキスト４０５が生成される。ＳＳＬ／ＴＬＳ標準によれば、この暗号テキストは、キー４０７、プレインテキスト、レコード毎に増分される連番の関数としてのハッシュ機能４１１により生成されるＭＡＣと、ヘッダとを含むレコード４１０に埋め込まれる。得られたレコード４１０は、クライアント３０１とプロキシサーバ３０２との最初のハンドシェイクの一部として以前に確立されたＴＣＰ接続を介してプロキシサーバ３０２に送信される。最初の初期化ベクトル４０３は、初期化中に送信側と受信側との間で合意される。
【００３７】
ＳＳＬ／ＴＬＳ標準によれば、同一のキー４０２を使用して、以前に送信されたレコードから生成された暗号テキスト４０５を２番目の初期化ベクトルとして使用して、次のプレインテキスト４０６を暗号化する。これによって、連続するレコード間の「リンク」が形成されるが、リンクが壊れた場合（パケットの喪失や破壊があった場合）には、この方式は機能しなくなる。
【００３８】
図４Ｂは、受信側での逆のプロセスを示す。受信側（例えば、プロキシサーバ２０２）において、第１のレコード４１０が以下のように暗号解読される。暗号テキストは、以前に共有されたセッションキー４１４と以前に共有された初期化ベクトル４１５とを使用して、暗号解読機能４１３において暗号解読される。ハッシュ機能４１７において、プレインテキストをキー４２０および（受信側で独立して増分される）１増分連番と組み合わせて使用し、送入レコードのＭＡＣに一致すべきＭＡＣを生成する。ＭＡＣが一致しない場合、そのレコードは廃棄される。
【００３９】
第２の（次の）送入レコード４１１は、セッションキー４１４を使用して暗号解読されるが、初期化ベクトル４１５の代わりに暗号テキスト４１０Ａを初期化ベクトルとして使用する。これは、図４Ａに示す対応する暗号化方式に適合する。上記のように、受信側がレコード４１０を受信しなかった場合（または、順不同に受信された場合）、暗号解読は、暗号解読に必要な「連結」初期化ベクトルに依存しているため、適切に行われない。暗号解読されたプレインテキスト４２１は、送入レコードのＭＡＣに一致するＭＡＣを生成しないので、ＭＡＣ比較機能４２３によりエラーが検出される。
【００４０】
上述のように、以前に送信されたデータレコードに対する従来のＳＳＬ／ＴＬＳの依存により、その基礎となるパケット送信メカニズムが完璧な信頼性を有することが必要となる。これは、「暗号ブロック連結」と称され、連続する各データレコードが、以前に生成されたレコードに依存して暗号化されるので、信頼性のあるレコード送信が必要となる（ＤＥＳに関しては、暗号ブロック連結はＦＩＰＳ８１により定義される）。結果的に、レコードが順不同に受信された場合や、データレコードが脱落した場合には、暗号化方式は失敗し、連番は一致しなくなる。この様なことが発生すれば、従来のＳＳＬ／ＴＬＳ方式では、ＴＣＰ接続は終了し、データ送信を再確立するために新たな接続が必要となる。このセキュリティ機能は、ハッカーが、クライアントとプロキシサーバとの間でのデータレコードの挿入や操作により確実な送信方式を妨害できないようにする意図がある。上述のように、図４Ａおよび図４Ｂの方式によりＵＤＰなどの信頼性のないプロトコルを用いてデータを送信した場合には、レコードの喪失や順不同によって直ちに接続が失われる。単純化の目的で、図４Ａおよび図４Ｂのレコード４１０には、暗号テキストの１ブロックしか示していない。実際には、１つのレコードに多数のブロックが含まれており、「暗号ブロック連結」は、１つのレコード内の連続するブロックの間で行われる。
【００４１】
図５Ａおよび図５Ｂは、本発明のある変形態様に従って使用可能な改良暗号化／暗号解読方式を示す。この変形態様によると、若干改良されたＳＳＬ／ＴＬＳレコードのフォーマット５０７を使用する。特殊ビット（ＵＤＰ）は、従来のヘッダに埋め込まれ、これは、レコードが暗号化ＵＤＰデータを含み、改良ＳＯＣＫＳ処理機能３０２３に従って処理されるべきであることを示す。レコード検出器３０２１または３０１５は、このビットを使用して、任意のＳＳＬ／ＴＬＳレコードを従来のＳＯＣＫＳ処理機能３０２２または３０１３にルーティングすべきか、それとも、改良ＳＯＣＫＳ処理機能３０２３または３０１４にルーティングすべきかを決定することができる。この機能により、既存のＳＳＬ／ＴＬＳ／ＳＯＣＫＳプロトコルに準拠するシステムと共に本発明の原則を適用できる一方、ＵＤＰデータグラムを送信するときに強化セキュリティ条件を使用できる。
【００４２】
図５Ａに示すように、プレインテキスト５０１は、従来のＤＥＳ暗号化アルゴリズムなどの暗号化機能５０８を使用して暗号化される。暗号化は、共有セッションキー５０２と第１の初期化ベクトル５０３を用いて実行され、その結果、暗号テキスト５０５が得られ、これを用いて改良ＳＳＬ／ＴＬＳレコード５０７を生成する。また、プレインテキスト５０１を別のキー５３０および第１のノンス値５０４と共に使用し、ハッシュ機能５０６を用いてＭＡＣ５０９を生成する。図４Ａの暗号化方式とは対照的に、レコード５０７には、ノンス値５０４および初期化ベクトル５０３が含まれており、これらは、好ましくは一意的な値（例えば、ランダム数）からなる。ある実施形態によれば、複合ノンス／ＩＶ値は、強力なランダム数生成装置（例えば、Ｘ９．６２標準により定義され、市販のＲＳＡ ＢＳＡＦＥ ＣＲＹＰＴＯ−Ｃ機能により生成されるもの）を使用して生成される。
【００４３】
従来のＳＳＬ／ＴＬＳ方式とは対照的に、ノンス／ＩＶ値は、明示的に各レコードの一部として含まれるので、以前に送信されたレコードに依存せずに、レコードを暗号解読することができる。ある実施形態において、連番および初期化ベクトルは、単一の値（ノンス）に統合可能であり、この値は、任意の数値またはランダムに生成された数値である。ある実施形態において、ノンスは、ＳＳＬにおける連番と同じサイズ（例えば、８バイト）であり、各値は一意的なものである（すなわち、受信側が、以前に受信されたレコードのリストと照合することができる）。初期化ベクトルは、暗号のブロックと同じサイズ（例えば、８バイト）を有し、各値は一意的なものとすることができる。ある変形態様において、異なる初期化ベクトル間のハミング距離が大きいこと（例えば、各ビットが５０％の変化の確率を有するランダム数であること）が好ましい。別個のノンスや初期化ベクトルを付加する代わりに、複合ノンス／ＩＶ値を使用することができる。ＲＳＡセキュリティ社から販売されているＲＳＡ ＢＳＡＦＥ ＣＲＹＰＴＯ−Ｃ製品など、暗号的に強力なランダム数生成装置を用いて、この様な数値を生成することができる。
【００４４】
図５Ａの右側において、プレインテキスト５１０は、同様の方法で暗号化され、別のノンス５１３および初期化ベクトル５１４を用いて、データレコード５１６が生成される。
図５Ｂを参照して、次に、レコード５０７、５１６の暗号解読について説明する。レコード５０７からの暗号テキストは、共有セッションキー５０２およびデータレコードから抽出された初期化ベクトル５０８を用いて暗号解読され、プレインテキスト５０１を生成する。プレインテキストは、キー５１８およびデータレコードから抽出されたノンス５０８と共に、ハッシュ機能を介して供給され、レコードから抽出されたＭＡＣ５０９と比較可能なＭＡＣを生成する。
【００４５】
第２のレコード５１６は、暗号解読を実行するために以前に送信されたレコード５０７中の値に依存しないことを除き、同様の方法で暗号解読される。この様に、脱落または順不同のレコードでも対処可能である。
図５Ｃに示す本発明の変形態様によれば、複数の暗号ブロック５２１を１つのレコードに含めることができ、前の暗号ブロックを参照して、各ブロックの暗号テキストを暗号解読することができる。暗号解読機能５２６において初期化ベクトル５２４を用いて第１の暗号テキストを暗号解読する一方、前のブロックの暗号テキストを用いて一連の暗号テキストブロックを暗号解読する（一般的に、暗号化は逆の方法で実行される）。連結されたプレインテキストブロック５３１、５３２、５３３に基づいて、単一のＭＡＣ値を演算することができる。
【００４６】
上述のように、ノンスおよびＩＶを１つの値に統合できるので、同一の値をＩＶおよびＭＡＣ演算の一意的な識別子として使用する。
ある変形態様においては、明示的に送信されたノンスを使用して、以前に送信されたレコードが２度目に受信されたかどうかを決定する。もし、そうであれば、この様な状況は、いわゆる「再生パケット」によるハッカー攻撃を意味するので、プロトコルは、選択的に、接続を終了するか、または、警告を発する。なお、後者は、連番が順不同に受信された場合に接続を終了する従来のＳＳＬ／ＴＬＳとは異なる。さらに、ある実施形態において、連番チェックは、無効にされるか、または、使用されない。
【００４７】
従来のＳＳＬ／ＴＬＳとは対照的に、本発明のある側面によれば、初期化ベクトルはレコードにまたがって連結されることはない。各レコードは、一意的な初期化ベクトルを含み、暗号テキストブロックは、従来のようにレコード内で連結される。
特殊ＵＤＰビットの使用は、レコードを従来のＳＳＬ／ＴＬＳレコードまたは改良ＳＳＬ／ＴＬＳレコードとして識別するための一手法にすぎない。ある実施形態においては、ビットは全く必要とされず、ここに記述されているように全てのレコードが改良ＳＳＬ／ＴＬＳプロトコルに準拠するものと仮定されている。他の実施形態において、特定のレコードを上記の改良方式に従って処理すべきであることを示すために、異なるフラグまたは方法を用いることができる。一例として、クライアントとプロキシサーバとの間に起こる最初のハンドシェイクの間に、メッセージを送信して、以降のレコードが前記のプロトコルに従って受信されることを示すことができる。別の実施形態においては、確実なＴＣＰを使用して、データレコードの比較と識別のためにノンスと同等のＭＡＣ値またはＩＶ値の集合を交換することができる。
【００４８】
ＵＤＰ以外の信頼性のないプロトコルを利用して、本発明の原則を実施することもでき、本発明がＵＤＰデータグラムに限定されないことを認識すべきである。さらに、ＤＥＳ以外の他の暗号化アルゴリズム（例えば、ＡＥＳ）を使用することもでき、本発明がこの点において限定されないことを理解すべきである。
図６は、本発明の原則を実施するために使用可能な方法の各ステップを示す。なお、プロキシサーバ３０２の使用は、総じて任意であり、図示の機能は、もちろんクライアントコンピュータ３０１、サーバコンピュータ３０３、その他のコンピュータで実施することができる。または、ＳＯＣＫＳプロトコルの制約がなくても、信頼性のないパケット送信を提供するプロトコル（例えば、インタネットプロトコル）を利用して、本発明の原則を実施することもできる。上記の例は、クライアント３０１からサーバ３０３への確実なＵＤＰデータの送信を反映しているが、図６の例では、サーバ３０３がプロキシサーバ３０２にＵＤＰデータグラムを送信し、プロキシサーバ３０２がＵＤＰデータグラムを暗号化してクライアント３０１に送信すると仮定する。
【００４９】
クライアントは、図３Ｂに示すアーキテクチャを利用してアプリケーションサーバから確実なビデオデータを受信することを所望していると仮定する。つまり、サーバ３０３は、ＵＤＰを用いて信頼性なく送信されたデータストリームを、プロキシサーバ３０２を介してクライアント３０１に送信し、これにより、レコードを暗号化した状態でクライアント３０１に確実に送信する。先ず、ステップ６０１において、クライアントとプロキシサーバとが、ＴＣＰ接続を確立する。このステップは、従来のものであり、ＳＯＣＫＳプロトコルに準拠している。ステップ６０２において、クライアントとプロキシサーバとは、従来のＳＳＬ方式に従って、信任情報を交換する（例えば、セキュリティパラメータを取り決める）。本発明のある変形態様において、クライアント３０１とプロキシサーバ３０２とは、上記の原則に従ってＵＤＰデータグラムを暗号化した状態で送信することにも同意する。これは、（新たな）ＴＣＰパケットを送信することにより実現でき、特定のポートを利用して確実なＵＤＰデータグラムを送信することを示している。また、クライアントは、目的のアプリケーションサーバに関するサーバ情報（例えば、ＩＰアドレスやポート）を送信することもできる。なお、ステップ６０１、６０２は、信頼性のあるプロトコルを用いて実行されるものとして説明したが、もちろん、暗号化ステップに必要な情報を何らかの方法でコンピュータ間で共有または通信できる限り、信頼性のないプロトコルを用いて実行することができる。
【００５０】
ステップ６０３において、例えば、ランダム数発生装置を用いて、ノンス／ＩＶを生成する。ステップ６０４において、ノンスを使用して、サーバ３０３から受信されたＵＤＰデータグラムを暗号化し、必要に応じて、図５Ａ、図５Ｂ、および図５Ｃに示すその他のフィールドを生成する。例えば、前のバイトからのプレインテキストを初期化ベクトルとして用いて、暗号テキストの各ブロックを連結ブロック暗号化し、ＭＡＣを従来通り生成することができる。さらに、図５Ａ、図５Ｂ、および図５Ｃに示すように、ノンスをレコードに付加することができる。
【００５１】
ステップ６０５において、改良ＳＳＬ／ＴＬＳ／ＳＯＣＫＳプロトコルに従ってレコードを暗号化したことを示すために、「確実ＵＤＰ」ビットをレコードヘッダに設定する。上述のように、暗号化情報はその他様々な方法で示すことができるので、このビットは任意である。最後に、ステップ６０６において、レコードをプロキシサーバ３０２からクライアント３０１に送信する。ステップ６０７において、レコードをレコード検出器３０１５において受信し、確実ＵＤＰビットが設定されていれば、ステップ６０９において、上記の改良ＳＯＣＫＳ処理に従ってレコードを暗号解読する。そうでなければ、ステップ６０８において、従来のＳＯＣＫＳ処理に従ってレコードを暗号解読する。
【００５２】
以上、ＵＤＰなどの信頼性のないプロトコルを用いて確実にデータを送信するためのシステムおよび方法について説明してきた。本発明は、ビデオ会議、ストリーミングメディア（オーディオ、ビデオ、または、その両方）、ファイルのバルク転送、インタネットを介したコンピュータゲーム（準リアルタイムゲームシステムなど）、インタネットテレフォニ、携帯電話送信、無線ＬＡＮなどのシステムを含む広範なシステムおよびアプリケーションに利用可能である。本質的に複雑でない信頼性のない通信プロトコル（例えば、ＵＤＰ、ＩＰなど）の使用により、データを確実に送信するために必要なオーバヘッドや処理が低減されるので、本発明は、低電力消費や低コンピュータ処理という形で利点を提供する。本発明は、インタネットを介した通信だけでなく、ローカルエリアネットワーク（例えば、イーサネット(登録商標)）、ピアツーピアネットワークなど、その他のコンピュータネットワークにおける用途にも利用可能である。また、本発明の主な用途は、ストリーミングメディアのためにＵＤＰトラフィックと共に用いられるものであるが、非ストリーミングメディアなど、様々なデータタイプを保護するためにも適している。
【００５３】
本発明の実施形態を採用可能なネットワーク構成７０１を図７Ａに示す。図７Ａに示すネットワーク７０１は、多数のクライアントコンピュータ３０１Ａ、３０１Ｂ、３０１Ｃ、３０１Ｄ．．．３０１θと、アプリケーションサーバ３０３にそれぞれ接続された複数のプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φとを備えている。また、各クライアントコンピュータ３０１（３０１Ａ、３０１Ｂ、３０１Ｃ、３０１Ｄ．．．３０１θ）からの接続は、通信媒体７０２を介し、ファイアウォル７０３を介して、負荷バランサ７０４に対して維持され、アプリケーションサーバ３０３への中継のために、通信を各クライアントコンピュータ３０１からプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φの１つにルーティングする。上記のように、サーバ／クライアントコンピュータを、単一演算ユニット上で実施することもできるし、多数の演算ユニット全体に分散することもできる。また、多数のクライアント／サーバ装置を単一の演算装置上で実施してもよい。
【００５４】
理解を容易にするために図７Ａには１つのアプリケーションサーバ３０３しか示されていないが、ネットワーク７０１は、多数のプロキシサーバ３０２（３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φ）と同時通信する多数のアプリケーションサーバ３０３を備えることができる。ネットワーク７０１内の各プロキシサーバ３０２と通信するクライアントコンピュータ３０１の数は、例えば、１００を越えるものとすることができる。同様に、このネットワークは、各アプリケーションサーバ３０３と通信する多数の（１００を越える）プロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φを備えたものとすることができる。通信媒体７０２は、適当な媒体でよい。例えば、クライアントコンピュータ３０１Ａがウェブベースの通信プログラム（例えば、ブラウザ）を利用してプロキシサーバ３０２Ａと通信するように構成されている場合、通信媒体７０２はインタネットであってもよい。また、クライアントコンピュータ３０１Ｄが遠隔ダイヤルアップ通信プログラムを利用してプロキシサーバ３０２Ｂと通信するように構成されている場合、通信媒体７０２は、ダイレクト・プレイン・オールド・テレフォン・システム（ＰＯＴＳ）接続であってもよい。
【００５５】
この例において、クライアントコンピュータ３０１Ａ、３０１Ｂ、３０１Ｃ、３０１Ｄ．．．３０１θは、信頼性のある通信プロトコルのための従来のＳＳＬ／ＴＬＳプロセス、または、上記で詳述した信頼性のない通信プロトコルのための改良ＳＳＬ／ＴＬＳプロセスを利用して、複数のプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φと通信する。下記の説明から明らかなように、ネットワーク構成７０１は、従来のＳＳＬ／ＴＬＳプロセスを利用したセッションに対しても、上記の信頼性のないプロトコルのための改良ＳＳＬ／ＴＬＳプロセスを利用したセッションに対しても、新たなＳＳＬ／ＴＬＳセッションを生成する必要なく、クライアントコンピュータからプロキシサーバへの確実なＳＳＬ／ＴＬＳセッション接続を別のプロキシサーバに切り換えることができる。
【００５６】
ネットワーク７０１内のプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φは、それぞれ、キャッシュメモリ７０５（７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φ）を備えている。本発明によれば、キャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φは、それぞれ、キャッシュ７０６のコピーを収容している。キャッシュ７０６は、多数のクライアントコンピュータ３０１Ａ、３０１Ｂ、３０１Ｃ、３０１Ｄ．．．３０１θと多数のプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φとの間の様々なＳＳＬ／ＴＬＳ通信セッションに基づくＳＳＬ／ＴＬＳセッション情報の集合を含んでいる。例えば、キャッシュ７０６は、クライアントコンピュータ３０１Ａとプロキシサーバ３０２Ａとの間のＳＳＬ／ＴＬＳセッションに対応するＳＳＬ／ＴＬＳセッション情報を収容している。
【００５７】
ＳＳＬ／ＴＬＳセッションのためのＳＳＬ／ＴＬＳセッション情報には、プロキシサーバ３０２が、新たなＳＳＬ／ＴＬＳセッションを生成する必要なく、クライアントコンピュータ３０１とのＳＳＬ／ＴＬＳセッションを再開するために必要な情報の全てが含まれていることが好ましい。例えば、ＳＳＬ／ＴＬＳセッション情報には、プロキシサーバ３０２が、部分ＳＳＬ／ＴＬＳハンドシェイク動作のみでクライアントコンピュータ３０１とのＳＳＬ／ＴＬＳセッションを再開するために必要な情報の全てが含まれている。したがって、ＳＳＬ／ＴＬＳセッション情報には、セッション中に交換されたデータの暗号化／暗号解読のためのセッションキーを生成するために使用されるマスタシークレットキーを含めるべきである。本発明の様々な実施形態において、ＳＳＬ／ＴＬＳセッション情報には、クライアントコンピュータ３０１やクライアントコンピュータ３０１のユーザを認証するために使用されるピア信任情報も含めるべきである。
【００５８】
さらに、ＳＳＬ／ＴＬＳセッション情報には、セッションを識別するためのセッション識別子（例えば、能動または再開可能セッションを識別するためにプロキシアプリケーション９０１が選択した任意のバイトシーケンス）、クライアントコンピュータ３０１およびプロキシアプリケーション９０１が使用するバルクデータ暗号化アルゴリズム（ヌル、ＤＥＳなど）、メッセージ認証チェック（ＭＡＣ）アルゴリズム（ＭＤ５、ＳＨＡなど）、暗号属性（ハッシュサイズなど）を指定する暗号仕様も含まれる。さらに、ＳＳＬ／ＴＬＳ情報には、暗号化の前にデータを圧縮するために用いるアルゴリズム、および新たな接続を開始するためにそのセッションを用いることができるか否かを示すフラグ情報も含まれる。
【００５９】
なお、ここで用いられているＳＳＬ／ＴＬＳセッションという用語は、信頼性のある通信プロトコルのための従来のＳＳＬ／ＴＬＳプロセスおよび上記の信頼性のない通信プロトコルのための改良ＳＳＬ／ＴＬＳプロセスを利用して生成されたセッションの両方を言う。もちろん、プロキシサーバ３０２が、新たなＳＳＬ／ＴＬＳセッションを生成することなく、ＳＳＬ／ＴＬＳセッションを再開するために、元々のセッション生成に使用されていたＳＳＬ／ＴＬＳ手法のタイプに固有の情報をＳＳＬ／ＴＬＳセッション情報に含めてもよい。したがって、ＳＳＬ／ＴＬＳセッションが、上記の信頼性のない通信プロトコルのための改良ＳＳＬ／ＴＬＳプロセスを利用して生成されている場合、セッション中に交換される以降の全てのレコードが改良ＳＳＬ／ＴＬＳプロセスにより処理されることが、クライアントコンピュータ３０１とプロキシサーバ３０２との間で同意されていることを示すデータ（例えば、フラグ）をＳＳＬ／ＴＬＳセッションに含めてもよい。
【００６０】
したがって、各キャッシュ７０６は、多数のクライアントコンピュータ３０１Ａ、３０１Ｂ、３０１Ｃ、３０１Ｄ．．．３０１θと多数のプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φとの間の（従来のＳＳＬ／ＴＬＳプロセスおよび上記の改良ＳＳＬ／ＴＬＳプロセスにより生成された）ＳＳＬ／ＴＬＳセッションの再開に必要な情報を格納している。この様に、キャッシュ７０６は、クライアントコンピュータ３０１Ａとプロキシサーバ３０２Ａとの間のＳＳＬ／ＴＬＳセッションを再開するために必要なＳＳＬ／ＴＬＳ情報を含んでいる。各プロキシサーバ３０２は、対応するキャッシュメモリ７０５にキャッシュ７０６のコピーを有しているので、クライアントコンピュータ３０１とプロキシサーバ３０２Ａとの接続が終了すると、クライアントコンピュータ３０１Ａは、クライアントコンピュータ３０１Ａとプロキシサーバ３０２Ａとの間の前のセッションと同じＳＳＬ／ＴＬＳセッション情報を有するその他の如何なるプロキシサーバ３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φとも新たなセッションを確立することができる。
【００６１】
本発明のある実施形態においては、各キャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φは、キャッシュ７０６の完全なコピーを収容している。各プロキシサーバ３０２は、クライアントコンピュータ３０１との新たなセッションのための新たなＳＳＬ／ＴＬＳセッション情報を得るか、または、クライアントコンピュータ３０１との既存のセッションのための更新されたＳＳＬ／ＴＬＳセッション情報を得るので、プロキシサーバ３０２は、格納のために新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報をキャッシュ７０６の各コピーに送信する。
【００６２】
本発明を実施するネットワーク７０１は、従来のネットワーク構成を超越する利点を提供する。クライアントコンピュータ３０１は、前のセッション中に得られたＳＳＬ／ＴＬＳセッション情報を利用して、プロキシサーバ３０２とのセッションを確立することができるので、負荷バランサ７０４は、クライアントコンピュータ３０１から以前にセッションを確立していたプロキシサーバ３０２に接続をルーティングし直す必要がない。この様に、負荷バランサ７０４の機能が単純化されて、クライアントコンピュータ３０１Ａ、３０１Ｂ、３０１Ｃ、３０１Ｄ．．．３０１θからの入力通信を、利用可能なプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φ間で均一に分散することができる。さらに、プロキシサーバ３０２が全く利用不可能になっても（すなわち、完全に機能不全に陥っても）、クライアントコンピュータ３０１は、別のプロキシサーバ３０２に対して新たなセッションを確立することができ、前のセッションで得られたＳＳＬ／ＴＬＳセッション情報を再生する必要がない。
【００６３】
上記の実施形態は、各キャッシュメモリ７０５にキャッシュ７０６の完全コピーを保持するようになっているが、本発明の他の実施形態では、図７Ｂに示すように各キャッシュメモリ７０５にキャッシュ７０６のほんの一部分のコピーを保持するようになっている。しかし、この様な実施形態では、各プロキシサーバ３０２がＳＳＬ／ＴＬＳセッション情報にアクセスできるように、多数のキャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φの内の他のキャッシュメモリに各セッションのＳＳＬ／ＴＬＳセッション情報を格納しなければならない。例えば、クライアント３０１Ａとプロキシサーバ３０２Ａとの間のセッションのＳＳＬ／ＴＬＳセッション情報を、キャッシュメモリ７０５Ａ（プロキシサーバ３０２Ａに対応）、キャッシュメモリ７０５Ｂ（プロキシサーバ３０２Ｂに対応）、キャッシュメモリ７０５Ｃ（プロキシサーバ３０２Ｃに対応）にのみ格納するようにしてもよい。その後、プロキシサーバ３０２Ａが利用不可能となり、クライアントコンピュータ３０１Ａがプロキシサーバ３０２Ｂとの接続に切り換えられると、プロキシサーバ３０２Ｂは、それ自体のメモリキャッシュ７０６Ｂから検索されたＳＳＬ／ＴＬＳセッション情報を利用してクライアントコンピュータ３０１Ａとのセッションを確立することができる。
【００６４】
さらに、クライアントコンピュータ３０１Ａが、キャッシュメモリ内にＳＳＬ／ＴＬＳセッション情報のないプロキシサーバ（例えば、プロキシサーバ３０２Ｄ）との接続に切り換えられた場合でも、そのプロキシサーバは、キャッシュメモリ７０５に適切なＳＳＬ／ＴＬＳセッション情報を有する別の利用可能なプロキシサーバ３０２（例えば、プロキシサーバ３０２Ｂ）からのＳＳＬ／ＴＬＳセッション情報を要求することができる。例えば、クライアントコンピュータ３０１Ａとの接続が、プロキシサーバ３０２Ｄへと切り換えられると、そのプロキシサーバ３０２Ｄは、ＳＳＬ／ＴＬＳセッション情報を応答受信するまで、その他の利用可能なプロキシサーバ３０２からのＳＳＬ／ＴＬＳセッション情報を順次要求することができる。または、プロキシサーバ３０２Ｄが、その他の利用可能なプロキシサーバ３０２の全てに対して要求を同時に送信し、例えば、最初に受信した応答のＳＳＬ／ＴＬＳセッション情報を採用するようにしてもよい。
【００６５】
本発明の上記の実施形態は、プロキシサーバ３０２のみがキャッシュ７０６の保持に関する責務を負うので、ピア構成型実施形態と呼ばれる。本発明のこの様なピア構成型実施形態において、各キャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φに全キャッシュ７０６のコピー（またはキャッシュ７０６の重複する部分コピー）を保持するには、各プロキシサーバ３０２が、書込プロセスにおいて新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報を多数のキャッシュメモリ７０５に送信しなければならない。好ましくは、受信側装置からの肯定確認を必要とする信頼性のある通信手法を利用してこの書込プロセスを実行するので、各プロキシサーバ３０２は、その関連のキャッシュメモリ７０５が新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報を処理したことを確認できる。ネットワーク内のプロキシサーバ３０２の数が比較的少なく、プロキシサーバ３０２によりセーブされるＳＳＬ／ＴＬＳセッション情報のタイプおよび量が比較的安定しており、キャッシュ７０６内のＳＳＬ／ＴＬＳセッション情報の総量が比較的少ない場合、信頼性のある肯定確認ベースの通信手法を利用するこの構成において、各キャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φに必要なＳＳＬ／ＴＬＳセッション情報を書き込むことは、ネットワーク７０１に対する大きなリソースオーバーヘッドとはならない。例えば、ネットワーク７０１が９個のプロキシサーバ３０２しか備えていない場合、各プロキシサーバ３０２に対する新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報の書き込みにより、ネットワークリソースが多大に浪費されることはない。
【００６６】
一方、キャッシュ７０６に格納されたＳＳＬ／ＴＬＳセッション情報のタイプを頻繁に更新しなければならない場合、または、ネットワークが多数のプロキシサーバ３０２（例えば、９個を越えるプロキシサーバ）を備えている場合には、信頼性のある肯定確認ベースの通信手法を利用したネットワーク内の各プロキシサーバ３０２に対する新ＳＳＬ／ＴＬＳセッション情報もしくは更新ＳＳＬ／ＴＬＳセッション情報の書き込みには、ネットワーク７０１からかなりのリソースが流用される。例えば、クライアントコンピュータ３０１の数が増加すると、各クライアントコンピュータ３０１のための多数のキャッシュメモリ７０５に対する低頻度の更新にも、ネットワーク７０１からかなりのリソースが流用される。同様に、プロキシサーバ３０２の数が増加すると、信頼性のある肯定確認ベースの通信手法を利用した各プロキシサーバ３０２のキャッシュメモリに対する新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報の書き込みにも、ネットワーク７０１からかなりのリソースが流用される。さらに、キャッシュ７０６があまりにも大きくなると、プロキシサーバ３０２のキャッシュメモリ７０５にキャッシュの完全コピーを格納することが困難になる。
【００６７】
これに対応して、本発明の更に別の実施形態を実施するネットワーク８０１を図８Ａに示す。前述のネットワーク構成７０１と同様に、ネットワーク８０１は、複数のクライアントコンピュータ３０１Ａ、３０１Ｂ、３０１Ｃ、３０１Ｄ．．．３０１θと、アプリケーションサーバ３０３にそれぞれ接続される複数のプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φとを備えている。前述の通り、各クライアントコンピュータ３０１は、通信媒体７０２およびファイアウォル７０３を介して負荷バランサ７０４に接続されている。負荷バランサ７０４は、各クライアントコンピュータ３０１からプロキシサーバ３０２の１つへと（例えば、図示のようにクライアントコンピュータ３０１Ａからプロキシサーバ３０２Ａへと）接続をルーティングする。図７Ａおよび図７Ｂに示すネットワーク７０１と同様に、ネットワーク８０１内のプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φも、それぞれ対応するキャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φを備えている。
【００６８】
しかし、本発明のこの実施形態は、キャッシュ７０６の１以上のコピーを格納するためのキャッシュ格納庫８０２を更に備えている。以下の説明から理解されるように、この実施形態は、本発明の前述の実施形態のようなピア構成ではなく、キャッシュ７０６の格納に関して２階層構成となっている。すなわち、この実施形態は、プロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φのキャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φにより提供される第１の階層のＳＳＬ／ＴＬＳセッション情報記憶装置と、キャッシュ格納庫８０２により提供される第２の階層のＳＳＬ／ＴＬＳセッション情報記憶装置とを備えている。
【００６９】
図８Ａに示すように、キャッシュ格納庫８０２は、２つのキャッシュメモリサーバ装置８０３、８０４を備えている。これらのキャッシュメモリサーバ装置８０３、８０４は、それぞれ、キャッシュ７０６の完全コピーを格納する。しかし、キャッシュ格納庫８０２は、冗長性のために２つのキャッシュメモリサーバ装置８０３、８０４を備えている。したがって、キャッシュメモリサーバ装置８０３、８０４の一方が機能しなくなったり、利用不可能となった場合でも、キャッシュ格納庫８０２は、他方のキャッシュメモリサーバ装置内にキャッシュ７０６の完全コピーを備えている。また、本発明の他の実施形態において、冗長性が所望でない場合には格納庫８０２として単一のキャッシュメモリサーバ装置を使用してもよいし、冗長性を優先する場合には３個以上のキャッシュメモリサーバ装置を使用してもよい。
【００７０】
図８Ａの実施形態におけるキャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φは、全キャッシュ７０６のコピーを格納しないこともある。その代わりに、キャッシュ７０６がキャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φの記憶容量よりも大きな場合には、各キャッシュメモリ７０５は、対応するプロキシサーバ３０２に関連するキャッシュ７０６の一部分のみを格納する。例えば、キャッシュメモリ７０５Ａにコピーされたキャッシュ７０６の一部分に、プロキシサーバ装置３０２Ａ、３０２Ｂに対して確立されたセッションのＳＳＬ／ＴＬＳセッション情報のみが含まれるようにしてもよい。したがって、クライアントコンピュータ３０１Ａが、プロキシサーバ３０２Ａとの接続を失い、プロキシサーバ３０２Ｂとの新たなセッションを確立しようとする場合、キャッシュメモリ７０５Ｂは、プロキシサーバ３０２Ａとの前のセッションに関するＳＳＬ／ＴＬＳセッション情報を保持していないこともある。
【００７１】
しかし、この実施形態では、プロキシサーバ３０２が、そのメモリキャッシュ７０５にＳＳＬ／ＴＬＳセッション情報のないクライアントコンピュータ３０１とのセッションを確立する要求を受信すると、プロキシサーバ３０２は、キャッシュ格納庫８０２から関連ＳＳＬ／ＴＬＳセッション情報を得ることができる。したがって、上記の例において、プロキシサーバ３０２Ｂは、クライアントコンピュータ３０１Ａの前のセッションに関するＳＳＬ／ＴＬＳセッション情報をキャッシュ格納庫８０２から得る。そして、新たなプロキシサーバ３０２は、そのＳＳＬ／ＴＬＳセッション情報を使用して、前のセッションと同一のＳＳＬ／ＴＬＳセッション情報で新たなセッションを確立することができる。
【００７２】
キャッシュ７０６のサイズが大きすぎて、キャッシュ７０６の全コピーをプロキシサーバ３０２のキャッシュメモリ７０５に効率よく格納することができない場合に有用であることに加えて、キャッシュ格納庫８０２を採用する本発明のこの実施形態は、通常、非常に多くのプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φを備えたネットワーク（キャッシュ７０６に格納されたＳＳＬ／ＴＬＳセッション情報が、キャッシュ７０６を頻繁に更新する必要のあるタイプであるか否かにもよるが、例えば、１０を越えるプロキシサーバを備えたネットワーク）にとって更に効率がよい。この実施形態において、各プロキシサーバ３０２は、通常、新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報をキャッシュ格納庫８０２にのみ書き込むために信頼性のある肯定確認通信手法を利用する必要があり、（書込動作およびその確認により発生する）通信トラフィック量がネットワーク全体で減少する。そして、ネットワーク内の他のプロキシサーバ３０２は、後述のように、信頼性の低い通信手法により、または、キャッシュ格納庫８０２から直接的に、新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報を得ることができる。
【００７３】
なお、図８Ａに示す２階層構成は例示である。当業者にとっては、キャッシュ７０６の全体サイズにより、３階層、４階層などマルチ階層構成も採用可能であることが理解できるであろう。例えば、キャッシュ７０６のサイズがあまりにも大きく、単一のキャッシュメモリサーバ装置８０３、８０４に効率よく格納できない場合は、キャッシュ７０６の異なる部分を格納する２以上のキャッシュ格納庫８０２を採用することができる。キャッシュ７０６の全コピーを、各キャッシュ格納庫８０２にアクセス可能な比較的効率の悪い記憶装置（例えば、一連の磁気ディスク記憶装置）に格納してもよい。また、各プロキシサーバ３０２を特定のキャッシュ格納庫８０２と関連付けて、関連するキャッシュ格納庫８０２に保持されているキャッシュ７０６の全部または一部を格納するようにしてもよい。当業者にとっては、その他、様々な実施形態が明らかであろう。以下、「マルチ階層」という用語を使用して、少なくともキャッシュ７０６の一部分を格納する２階層以上の階層レベルの装置を備えた本発明の実施形態に言及する。
【００７４】
なお、本発明の更なる実施形態において、キャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φに格納されているキャッシュ７０６Ａ、７０６Ｂ、７０６Ｃ、７０６Ｄ．．．７０６φの異なる部分が、重複していてもよい。例えば、キャッシュ７０５Ａの一部分は、キャッシュ７０５Ｂの一部分およびキャッシュ７０５Ｃの一部分にも格納されているＳＳＬ／ＴＬＳセッション情報を収容していてもよい。プロキシサーバ３０２は、接続を求めている新たなクライアントコンピュータ３０１のためのＳＳＬ／ＴＬＳセッション情報を既に有していることもあるので、キャッシュ７０６の異なる部分である程度の重複があることにより、ネットワークトラフィック量が減少する。さらに、図８Ｂに示すように、各キャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φは、キャッシュ７０６全体のコピーを収容していてもよい。本発明のこの実施形態は、例えば、キャッシュ７０６のサイズが充分小さく、キャッシュメモリ７０５にその全体を格納できる場合、図８Ａに示す実施形態にとって好適である。
【００７５】
次に、プロキシサーバ３０２の考え得る実施形態について、図９を参照しながら説明する。図示のように、プロキシサーバ３０２は、プロキシアプリケーション９０１と、分散キャッシュアプリケーション・プログラミング・インタフェース（ＡＰＩ）９０２と、分散キャッシュアプリケーション９０３と、通信機アプリケーション９０４と、キャッシュメモリ７０５とを備えている。以下に詳述するように、プロキシアプリケーション９０１は、プロキシサーバ３０２の主要な機能を実行し、レコード検出器３０２１と、従来のＳＯＣＫＳ処理機能３０２２と、改良ＳＯＣＫＳ処理機能３０２３と、プロキシ機能３０２４とを備えている。すなわち、プロキシアプリケーション９０１は、クライアントコンピュータ３０１との確実な通信を確立し、クライアントコンピュータ３０１とアプリケーションサーバ３０３との間でメッセージを中継する。また、プロキシアプリケーション９０１は、クライアントコンピュータ３０１とのセッションのＳＳＬ／ＴＬＳセッション情報を、分散キャッシュＡＰＩ９０２を介して分散キャッシュアプリケーション９０３に送信する。
【００７６】
分散キャッシュＡＰＩ９０２は、キャッシュメモリ７０５から情報を検索し、分散キャッシュアプリケーション９０３を介して情報を送信することによって、キャッシュメモリ７０５への情報送信の要求やキャッシュメモリ７０５からの情報削除の要求を円滑にする。分散キャッシュアプリケーション９０３は、キャッシュメモリ７０５に情報を格納し、キャッシュメモリ７０５と他のプロキシサーバ３０２（適用可能であれば、キャッシュ格納庫８０２）との情報の交換も制御する。分散キャッシュアプリケーション９０３は、通信機アプリケーション９０４を介して、他のプロキシサーバ３０２（適用可能であれば、キャッシュ格納庫８０２）と通信する。
【００７７】
したがって、完全ＳＳＬ／ＴＬＳハンドシェイクが完了した後、プロキシアプリケーション９０１は、格納のため、完全ＳＳＬ／ＴＬＳハンドシェイクから得たＳＳＬ／ＴＬＳセッション情報をキャッシュメモリ７０５に送信する。
特に、プロキシアプリケーション９０１は、ＳＳＬ／ＴＬＳ再開情報を有するデータフィールド、およびＳＳＬ／ＴＬＳセッション識別子を有するキーフィールドを含むキャッシュ７０６に格納するレコードを生成する。レコードには、そのレコードが失効してキャッシュから削除されるべき時点を有する有効期限フィールドも含まれる。さらに、後述のように、キー情報（すなわち、セッション識別子）に付加されるレコード識別子もレコードに含まれる。プロキシアプリケーション９０１は、キャッシュメモリ７０５に格納するために、分散キャッシュＡＰＩ９０２を介して分散キャッシュアプリケーション９０３にこのレコードを送る。
【００７８】
プロキシアプリケーション９０１がクライアントコンピュータ３０１からの要求を受信してセッションを開始するとき、そのクライアントコンピュータ３０１がプロキシアプリケーション９０１（その要求を現在受信している同一のプロキシアプリケーション９０１または別のプロキシアプリケーション９０１）とのＳＳＬ／ＴＬＳ通信を既に確立していれば、その要求にはＳＳＬ／ＴＬＳセッション識別子が含まれている。プロキシアプリケーション９０１は、サーチキーとしてＳＳＬ／ＴＬＳセッション識別子をキャッシュＡＰＩ９０２上に送るので、ＡＰＩ９０２は、分散キャッシュアプリケーション９０３に対して、ＳＳＬ／ＴＬＳセッション識別子に対応するキャッシュメモリ７０５からＳＳＬ／ＴＬＳ情報を検索するように要求する。
【００７９】
前述のように、分散キャッシュＡＰＩ９０２の機能は、ＧＥＴ演算を用いてキャッシュメモリ７０５から既存のレコードを検索するものである。さらに、本発明のある実施形態では、分散キャッシュＡＰＩ９０２は、この様なコマンドを分散キャッシュアプリケーション９０３上に送ることによって、レコードを追加、削除、または修正するための要求を円滑にする。この様にして、分散キャッシュアプリケーション９０３は、キャッシュメモリ７０５上でＡＤＤ、ＤＥＬＥＴＥ、およびＵＰＤＡＴＥ演算を実行する。好ましくは、そのキーに関するレコードがキャッシュメモリ７０５に既に存在するものであっても、ＡＤＤ演算は、そのレコードのキーフィールド内の情報に基づいてレコードをキャッシュメモリ７０５に追加する。ＤＥＬＥＴＥ演算は、キャッシュメモリ７０５からレコードを削除し、ＵＰＤＡＴＥ演算は、キャッシュメモリ７０５に既に存在するレコードを更新する。また、分散キャッシュアプリケーション９０３は、各キャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φのパージを強制する機能も有する。
【００８０】
なお、キャッシュＡＰＩ９０２は、まず、キャッシュ７０６のローカルコピー（またはキャッシュ７０６の一部分のコピー）からの要求レコードをキャッシュメモリ７０５から得ることによって、ＧＥＴ演算の完了を試みる。本発明のある好適な実施形態においては、各キャッシュメモリ７０５はキャッシュ７０６の完全コピーを格納しているので、この要求は直ちに成功する。しかし、要求レコードがローカルキャッシュメモリ７０５内に見つからない場合（例えば、キャッシュメモリ７０５に、要求レコードを含まないキャッシュ７０６の一部分、または、崩壊したキャッシュ７０６のコピーしか含まれていない場合）、キャッシュＡＰＩ９０２は、別のソースからレコードを得るために、分散キャッシュアプリケーション９０３に関わりを持つ。図７Ａおよび図７Ｂに示す本発明のピア構成の実施形態において、分散キャッシュアプリケーション９０３は、その他のプロキシサーバ３０２の１以上から要求レコードを検索しようとする。しかし、図８Ａおよび図８Ｂに示す本発明のマルチ階層構成の実施形態においては、分散キャッシュアプリケーション９０３は、キャッシュ格納庫８０２から要求レコードを検索しようとする。
【００８１】
同様に、分散キャッシュアプリケーション９０３がそのローカルキャッシュ７０５からのレコードを追加、更新、または削除するときは、対応する追加、更新、または削除コマンドをネットワーク内の他の装置に中継する。例えば、図７Ａおよび図７Ｂに示す本発明のピア構成の実施形態において、分散キャッシュアプリケーション９０３は、その他のプロキシサーバ３０２のそれぞれにコマンドを中継する。しかし、図８Ａおよび図８Ｂに示す本発明のマルチ階層構成の実施形態においては、分散キャッシュアプリケーション９０３は、キャッシュ格納庫８０２にコマンドを中継する。そして、キャッシュ格納庫８０２は、その他のプロキシサーバ３０２の１以上にコマンドを中継する。この様に、あるプロキシサーバ３０２のプロキシアプリケーション９０１が得た新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報は、クライアントコンピュータ３０１との以降のセッションに使用するために、その他のプロキシサーバ３０２に送信される。
【００８２】
次に、分散キャッシュアプリケーション９０３によるキャッシュ７０６へのＳＳＬ／ＴＬＳセッション情報の格納について説明する。当業者に理解されるように、プロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φの数の増加に伴い、クライアントコンピュータとプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φとの間で可能なセッションの数も増加する。したがって、キャッシュに格納されるＳＳＬ／ＴＬＳセッション情報量も増加する。これは、図７Ａおよび図７Ｂに代表されるピア分散キャッシュの実施形態にも、図８Ａおよび図８Ｂに代表されるマルチ階層分散キャッシュの実施形態にも当てはまる。したがって、ＳＳＬ／ＴＬＳセッション情報は、必要なときに迅速かつ効率よく検索可能なようにキャッシュ７０６に格納されなければならない。したがって、本発明のある好適な実施形態においては、キャッシュ７０６を実施するためにハッシュテーブルを用い、ＳＳＬ／ＴＬＳセッション情報を格納してハッシュテーブルから検索するためにハッシュ機能を利用する。
【００８３】
上記のごとく当業で公知のように、各ＳＳＬ／ＴＬＳセッション情報は、レコードの一部としてキャッシュ７０６に格納される。ハッシュテーブルにレコードを入力する場合、分散キャッシュアプリケーション９０３は、キーデータを数値にマップするために、キーフィールド（例えば、ＳＳＬ／ＴＬＳセッション識別子）内のキーデータに対して算術アルゴリズムまたは「ハッシュ」演算を実行する。そして、キーデータにより識別されたＳＳＬ／ＴＬＳセッション情報は、キーデータがハッシュ演算によりマップされた数値に対応する位置（「バケット」ともいう）においてハッシュテーブルに格納される。
【００８４】
なお、異なるキー値を同じハッシュ値にハッシュしてもよい。この様に、異なるレコードをハッシュ値の同じ位置またはバケットに格納してもよい。したがって、ハッシュ演算は、可能なキーデータ値の全範囲に対してハッシュ値の均一な分布が得られるように選択されることが好ましい。これにより、ハッシュテーブル内の特定の位置にレコードが数量的に不均衡に格納されることはない。すなわち、ハッシュテーブル内にレコードを均一に分布させるハッシュ演算を採用することが好ましい。この様に、レコードを検索する際に、ハッシュテーブル内の如何なる位置からのレコード検索の平均時間も、ハッシュテーブル内の他の位置からのものと僅差または同一にしなければならい。
【００８５】
本発明のある好適な実施形態によれば、ＳＳＬ／ＴＬＳセッション情報レコードをキャッシュ７０６内に均一に分布させるために、「ＢＵＺｈａｓｈ」ハッシュアルゴリズムが採用される。このハッシュアルゴリズムは、本発明にその全体が引用により組み込まれている、ロバート・ウズガリス（Robert Uzgalis）による「ハッシュ概念およびＪａｖａプログラミング言語（Hashing Concepts and the Java Programming Language）」(Ｊａｖａは登録商標)(C)１９９６に記載されている。この著書に記載されているとおり、ＢＵＺｈａｓｈアルゴリズムは、従来、Ｓｋｅｔｃｈｙアルゴリズム言語を用いて以下のように演算する。
【００８６】
もちろん、当業者に理解されるように、キャッシュ７０６の異なる構成（例えば、異なるキー範囲）に対応してＢＵＺｈａｓｈアルゴリズムを変更できる。
【００８７】
ウズガリスの著書に記載されているように、ＢＵＺｈａｓｈアルゴリズムは、２進キー値に適用される場合、任意のキー値からランダム数を生成したり、テーブル内で可能な範囲のキー値を均一に分布させたりする際に特に有効である。しかし、当業者に理解されるように、ＳＳＬ／ＴＬＳセッション情報をキャッシュ７０６に格納するために、当業で公知のその他のハッシュアルゴリズムを利用してもよい。また、ＳＳＬ／ＴＬＳセッション情報をキャッシュ７０６に格納するために使用可能な新たなハッシュアルゴリズムを開発してもよいことも明白である。
【００８８】
なお、分散キャッシュアプリケーション９０３は、全てのキー値を非透過的に（オペークに）処理して、全てのキー値を一意的なものと仮定して演算する。すなわち、一意的なキーは、キャッシュ７０６内の単一のレコードのみを識別することができる。既存のレコードと同一のキーデータを用いて別のレコードをキャッシュ７０６に追加すると、一方のレコードのみが生き残る。しかし、同一キーデータを用いて異なるレコードを参照するようにすることが望ましい。例えば、前述のように、ＳＳＬ／ＴＬＳセッション識別子をキーデータとして用いて、レコードをＳＳＬ／ＴＬＳ再開情報と同定するようにしてもよい。また、クライアントコンピュータ３０１のユーザのための認証情報（例えば、クライアントコンピュータのユーザがアプリケーションサーバ３０３からアクセスできるデータを決定するために使用される認証情報）を有するレコードなど、別のレコードを識別するために、ＳＳＬ／ＴＬＳセッション識別子を用いることが望ましい。
【００８９】
したがって、本発明の様々な実施形態において、キャッシュＡＰＩ９０２は、同一のキーデータを共有する２つの異なるレコードを区別するテーブル識別子を使用することができる。本発明のこれら様々な実施形態において、プロキシアプリケーション９０１は、キーデータの指定に関わるキャッシュＡＰＩ９０２を介した全コールの一部として、キーデータに付加されたテーブル識別値を指定する。事実、これにより、プロキシアプリケーション９０１は、特定キーにより識別されたレコードの書き込みと読み出しとを行うべき仮想テーブルを特定することができる。もちろん、当業者に理解されるように、上記のようにキャッシュ７０６の全レコードを単一のハッシュテーブルに格納するので、これはロジック構成にすぎない。
【００９０】
好ましくは、プロキシアプリケーション９０１は、各テーブル識別値が適切に生成されて一貫して適用されるように保証する責務を負う。プロキシアプリケーション９０１は、キーに対してテーブル識別子を付加し、そのキーをキャッシュＡＰＩ９０２に送る。または、バッファ割当演算やコピー演算を省略するために、プロキシアプリケーション９０１はキャッシュＡＰＩ９０２にテーブル識別子を送り、キャッシュＡＰＩ９０２はテーブル識別子を付加する。キャッシュＡＰＩ９０２は、キーデータの一部としてテーブル識別子を処理するので、プロキシアプリケーション９０１は、この値のサイズを可能な限り縮小することが好ましい。テーブル識別子のサイズの縮小により、最適なメモリ使用と最適なハッシュ性能とが可能となる。
【００９１】
キャッシュメモリ７０５は、如何なるタイプのメモリ媒体であってもよい。しかし、当業者に理解されるように、キャッシュメモリ７０５は、ＲＡＭまたはメインメモリと一般的に呼ばれている読出可能／書換可能半導体メモリ装置として実施することが好ましく、この様なタイプのメモリ装置は、迅速な情報格納および検索が可能である。現在、サーバ装置として従来使用されているコンピュータは、２ギガバイトから４ギガバイトの情報を格納できるこの様なメモリを備えている。したがって、各プロキシサーバ３０２用のこのタイプのメモリ装置に２００万〜４００万キロバイト程度のレコードを格納することができる。もちろん、磁気媒体や光媒体などの他のタイプのメモリ媒体を代替として利用することもできる。
【００９２】
本発明のある実施形態によれば、通信機アプリケーション９０４は、ネットワーク内の装置間において、ユニキャストやＴＣＰ／ＩＰのような通信など（受信確認ベースの）ポイント間通信が可能である。このタイプの通信は、例えば、新たに開始されたキャッシュメモリ７０５と既存のキャッシュメモリ７０５との間でＳＳＬ／ＴＬＳセッション情報を同期させたり、ＳＳＬ／ＴＬＳセッション情報の全てが、対応するプロキシアプリケーション９０１により使用される前に、新たなキャッシュメモリ７０５に正確にコピーされることを保証するのに有用である。
【００９３】
通信機アプリケーション９０４により提供されるこのタイプのポイント間通信（例えば、ユニキャストまたはＴＣＰ／ＩＰのような通信）は、また、他のプロキシサーバ３０２のキャッシュメモリ７０５内の個々のレコードの更新や追加のために、分散キャッシュアプリケーション９０３により使用される。しかし、上述のように、図７Ａおよび図７Ｂに示す本発明の実施形態においては、プロキシサーバ３０２の数の増大に伴って、各キャッシュメモリ７０５にＳＳＬ／ＴＬＳセッション情報を書き込むためのネットワークリソースに対するオーバヘッドが増大する。これは、各プロキシサーバ３０２が、別個の書込プロセスを用いて各キャッシュメモリ７０５に新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報を書き込み、各キャッシュメモリ７０５から書込コマンド受領確認を応答受信しなければならないからであり、ネットワーク７０１内の各プロキシサーバ３０２にとっては、多大なネットワークトラフィック量および処理時間を要する。より具体的には、通信を受信する装置（例えば、プロキシサーバ３０２）の数をＮとすると、各通信で送信すべきデータパケット数は２Ｎとなる。
【００９４】
したがって、例えば、ポイント間メッセージ送信を用いて、通信機アプリケーション９０４からのメッセージをネットワーク内の適切な各受信側装置に個々に配信できる一方で、このタイプの通信は、本発明の有効性および速度を制約する。それに対応して、本発明のある好適な実施形態においては、通信機アプリケーション９０４は、信頼性のあるマルチキャスト通信も提供する。当業で公知のように、通信手法は、（ａ）この手法により送信されるデータパケットが正確に配列され、重複を受信側で廃棄可能な場合や、（ｂ）この手法により、受信側が送信中のデータパケットの喪失時点を検出できる場合、（ｃ）この手法により、送信中に喪失したデータパケットを得るために受信側に修復機構が提供されている場合に、信頼性があると判断される。当業で周知のように、マルチキャストは、異なるネットワーク装置が単一のネットワークアドレスに送信されたメッセージを受信する手順である。
【００９５】
したがって、通信機アプリケーション９０４は、ネットワーク内の適切な装置に対してＳＳＬ／ＴＬＳセッション情報の追加、更新、または削除を行うために、信頼性のあるマルチキャスト送信を利用してもよい。信頼性のあるマルチキャストを利用することによって、本発明のこれらの実施形態において、ＳＳＬ／ＴＬＳセッション情報を単一の共有マルチキャストアドレスに送信するだけで、同時に多数の異なる装置にＳＳＬ／ＴＬＳセッション情報を良好に送信する。前述のように、マルチキャストプロセスは当業で周知であり、マルチキャスト通信を円滑にするために、マルチキャスト・トランスファ・プロトコル（ＭＴＰ）など幾つかのマルチキャストプロトコルが確立されている。
【００９６】
信頼性のあるマルチキャスト通信手法の１タイプとして、肯定アプリケーション確認を有するマルチキャスト通信がある。この手法によると、マルチキャスト送信を受信するアプリケーションは、送信されたデータを成功裏に処理した後、マルチキャスト送信を発信した装置に対して確認を送り返す。このタイプの信頼性のあるマルチキャスト通信は、ピア構成の実施形態においては、他のキャッシュメモリ７０５（マルチ階層構造の実施形態においてはキャッシュ格納庫８０２）にＳＳＬ／ＴＬＳセッション情報を追加するために、分散キャッシュアプリケーション９０３からのＡＤＤコマンドを中継する場合に、通信機アプリケーション９０４により採用されることが好ましい。ピア構成の実施形態においては、通信を受信する装置（例えば、プロキシサーバ３０２）の数をＮとすると、信頼性のある肯定確認マルチキャスト通信手法を使用することによって、各通信のためにネットワーク全体に送信すべきデータパケットの数が１＋Ｎに低減される。すなわち、１つの通信がＮ個の装置のそれぞれにマルチキャストされ、Ｎ個の肯定確認が発信側装置に送り返される。
【００９７】
信頼性のある肯定確認マルチキャストによって、多数の装置が、同時に更新ＳＳＬ／ＴＬＳセッション情報または新ＳＳＬ／ＴＬＳセッション情報を確実に受信することができる一方で、ピア構成での実施のためにはかなりのネットワークリソースが必要となる。マルチキャストメッセージを受信する各装置は、メッセージの発信元のネットワーク装置に対して通信受信確認を個別に行う必要があるので、多数のプロキシサーバ３０２を有するネットワークにおいては（すなわち、Ｎが大きな場合には）、信頼性のある肯定確認マルチキャストを利用した各プロキシサーバ３０２へのＳＳＬ／ＴＬＳセッション情報送信は、ネットワークの性能を著しく劣化させる。
【００９８】
しかし、本発明の様々な用途において、上記のマルチ階層構成の実施形態は、ネットワークリソースの使用を更に低減することができる。この様な実施形態において、新状態情報や更新状態情報は、信頼性のある肯定確認ベースの通信手法を利用して、キャッシュ格納庫８０２にのみ送信すればよい。すると、プロキシサーバ３０２は、信頼性の低い（ネットワークリソースに関しては安価な）通信手法を利用して新状態情報や更新状態情報を得たり、必要な場合にはキャッシュ格納庫８０２から新状態情報や更新状態情報を得ることができる。この様にマルチ階層構成を利用することによって、新状態情報や更新状態情報を受信するキャッシュ格納庫８０２の数をｎとした場合、新状態情報や更新状態情報を追加する度にネットワーク全体に送信すべきパケットの数を更に１＋ｎへと低減することができる。本発明においては、通常、キャッシュ格納庫８０２の数ｎはプロキシサーバ３０２の数Ｎよりもはるかに小さいので、マルチ階層構成の利用により、新状態情報や更新状態情報のキャッシュに必要なネットワークリソースの使用を、個々のリソースのネットワークトラフィックおよび処理時間に関して、大幅に低減することができる。
【００９９】
本発明のマルチ階層構成の実施形態において、プロキシサーバ３０２は、信頼性のあるマルチキャスト通信を提供するために、上記の肯定確認手法の代わりに、例えば、否定確認（ＮＡＣＫ）手法を利用して、新状態情報または更新状態情報を受信してもよい。否定確認マルチキャスト手順によれば、マルチキャストメッセージを受信する装置は、メッセージを受信しても発信元装置に確認を送信しない。その代わり、各受信側装置は、マルチキャスト通信の一部分を喪失したと決定したときのみ、発信元装置に応答する。
【０１００】
例えば、通信プロトコルの中には、通信の各データセグメントに連続番号を付与する必要があるものもある。否定確認手順によれば、この様なプロトコルにより通信を受信する装置は、データセグメントの１つが受信されていないことを認識した時（すなわち、連番のデータセグメントの喪失を決定した時）のみ、発信元装置に応答する。したがって、本発明の様々な実施形態によれば、通信機アプリケーション９０４は、この手法を用いて、ネットワーク内の別の装置からのデータが受信されていないことを認識した時に、その装置に否定確認を与える。
【０１０１】
この様に、本発明のマルチ階層構成の実施形態において、否定確認型の信頼性のあるマルチキャスト構成を利用して、新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報を各プロキシサーバ３０２に配信することができ、装置間の通信トラフィック量を低減することができる。もちろん、関連する受信側装置の全てにおいて、単一のマルチキャスト送信を利用して、肯定確認マルチキャスト通信および否定確認マルチキャスト通信を達成可能である。送信側の装置は、別のマルチキャスト送信の前に、肯定確認手法を利用して通信するように指定された全ての装置からの肯定確認を受信するまで待機する。そして、送信側装置は、適切な否定確認マルチキャスト通信プロトコルにより受信した否定確認にも応答する。
【０１０２】
しかし、従来の否定確認型の信頼性のあるマルチキャスト通信手法には、「オーバーラン」とも呼ばれる更なる問題がある。この状況下、送信側装置は、１以上の受信側装置の処理能力よりも速くデータを送信するので、送信されたデータの一部が失われる結果となる。さらに、送信側装置は、あまりにも大量の情報を送信するので、他の装置から否定確認を受信することができず、これは、通信の一部が失われるということを意味する。しかし、この問題の程度は、ネットワーク全体の通信トラフィックフロー速度に依存する。ただし、ネットワークの通信トラフィックがほとんどない場合、マルチキャスト通信を発信した装置は、受信装置をオーバーランさせることなく、否定確認を失うことなく、高速で情報を送信することができる。同様に、ネットワークの通信トラフィックが多くなると、マルチキャスト通信を発信した装置は、受信装置のオーバーランや否定確認の喪失を回避するために、より低速でデータを送信しなければならない。
【０１０３】
この問題を解決するために、先行技術の否定確認マルチキャストシステムは、マルチキャスト通信においてデータを送信する速度に絶対的な制限を設定し、あらゆる状況下で他の装置からの否定確認を受信できるように保証することを提案している。しかし、この先行技術の定速による解決策は、ネットワーク全体において変化する通信トラフィックフローを考慮していない。その代わり、全ての否定確認の受信を保証するために、可能な限り低効率で動作する。その他、「マスタ」や「トークン」構成の決定論的な手法を利用する先行技術のシステムもあるが、この様なシステムは、比較的低速かつ非効率的であり、複雑である。
【０１０４】
それに対応して、本発明のある好適な実施形態において、通信機アプリケーション９０４は、ネットワーク全体の通信トラフィックフローを決定するためのトラフィックフロー速度検出プロセスと共に、否定確認型の信頼性のあるマルチキャスト通信を提供する。ネットワーク全体の通信トラフィックフローを正確に検出することによって、通信機アプリケーション９０４は、信頼性のある否定確認マルチキャスト通信におけるデータ送信速度を相応に上げたり下げたりすることができる。以下、このフロー速度検出プロセスについて、図１０Ａおよび図１０Ｂを参照しながら説明する。
【０１０５】
図示のように、通信機アプリケーション９０４は、データインタフェース部１００１を有する。インタフェース１００１は、ネットワーク内の他の装置にマルチキャストされるデータセグメント１００３を収容する出力キュー１００２を備えている。インタフェース１００１は、他の装置からマルチキャスト通信により受信されたデータセグメント１００５を収容する入力キュー１００４を更に有する。本発明のこの様な好適な実施形態によれば、通信機アプリケーション９０４は、それ自体のマルチキャスト送信の受信者でもある。したがって、通信機アプリケーション９０４は、ネットワーク内のその他の装置へ送信したデータセグメントを受信する。最新の送信データパケットが通信機アプリケーション９０４で受信された時点を決定することによって、通信機アプリケーション９０４は、ネットワーク内のトラフィックフローレベルを決定することができる。例えば、本発明のある好適な実施形態において、通信機アプリケーション９０４は、以前に送信されたデータセグメントをその入力キュー１００４に受信するまで、出力キュー１００２からの別のデータセグメントの出力を控える。
【０１０６】
当業者に理解されるように、このフロー速度検出手法に対して数々の変形態様が可能である。例えば、通信機アプリケーション９０４は、直前の送信データセグメント（例えば、データ１）を入力キュー１００４（図１０Ｂ参照）に受信するまで、新たなデータセグメント（例えば、図１０Ａおよび図１０Ｂに示すデータ２）の送信を延期する。または、通信機アプリケーション９０４は、ネットワーク全体のトラフィックの現在のフロー状況を確認するために、それ自体の送信データセグメント間に発生する入力キュー１００４内のデータセグメントの平均数を決定する。ネットワーク全体のトラフィックのフロー状況の決定のために、自己送信データセグメントの受信を利用して、その他数々の改良態様が可能である。さらに、この手法は、マルチキャストされない通信にも採用可能である。例えば、通信機アプリケーション９０４は、ポイント間メッセージのコピーをフィードバックループ上でそれ自体に送信することができる。通信機アプリケーション９０４は、ネットワーク上でトラフィック量を決定するために、通信機アプリケーション９０４がそれ自体に送信したメッセージが入力キュー１００４内に現れることを利用する。
【０１０７】
また、前述のように、肯定確認マルチキャスト通信手法および否定確認マルチキャスト通信手法を利用してメッセージを配信するために、同じマルチキャスト送信を使用することができる。なお、否定確認マルチキャスト通信手法をフロー検出と共に利用した場合、否定確認マルチキャスト手法と共に用いたフロー制御機能により、肯定確認マルチキャスト手法の動作を制御する。つまり、送信側装置は、肯定確認マルチキャスト通信手法で通信する装置を含め、如何なる装置に対しても、フロー制御機能により許容される速度よりも高速でマルチキャスト送信を行うことはしない。
【０１０８】
したがって、このフロー制御否定確認マルチキャスト通信手法は、本発明のマルチ階層構成において、ネットワークトラフィックに関しても、送信側装置および受信側装置での処理時間に関しても、ネットワークリソースの使用を大幅に増大することなく、新ＳＳＬ／ＴＬＳセッション情報および更新ＳＳＬ／ＴＬＳセッション情報をプロキシサーバ３０２に配信するために、通信アプリケーション９０４によって提供されることが好ましい。もちろん、通信機アプリケーション９０４は、プロキシサーバ３０２の様々な管理機能のために、信頼性のない通信手法も提供する。
【０１０９】
したがって、信頼性のあるマルチキャスト通信手法（すなわち、肯定確認マルチキャスト通信手法およびフロー制御否定確認マルチキャスト通信手法）を利用して、多数の装置にＳＳＬ／ＴＬＳセッション情報を同時配信することによって、プロキシサーバ３０２とクライアントコンピュータ３０１との間のセッションのＳＳＬ／ＴＬＳセッション情報を、複数の異なるキャッシュメモリ７０５およびキャッシュ格納庫８０２に効率よくキャッシュ可能となる。クライアントコンピュータ３０１とあるプロキシサーバ３０２との間の接続が終了した場合、キャッシュされたＳＳＬ／ＴＬＳセッション情報を利用して、別のプロキシサーバ３０２が、クライアント装置とのセッションを再開することができる。
【０１１０】
以上、本発明の特定の実施形態について説明してきたが、様々な変形態様、変更態様、代替構成、および均等物も本発明の範囲に包含される。例えば、上記のＳＳＬ／ＴＬＳセッション情報の格納に加えて、その他の情報も、キャッシュ７０６に好都合に格納することができる。例えば、クライアントコンピュータ３０１およびプロキシサーバ３０２が、暗号化データの送信に使用する１以上のポートを指定する場合、これらのポートをキャッシュ７０６に格納して、クライアントコンピュータ３０１とのＳＳＬ／ＴＬＳセッションの再開を円滑化することができる。また、クライアントコンピュータ３０１が目的のアプリケーションサーバ３０３のＩＰアドレスおよびポートを提供する場合、この情報をキャッシュ７０６に好都合に格納して、クライアントコンピュータ３０１とのＳＳＬ／ＴＬＳセッションの再開を円滑化することができる。さらに、改良ＳＳＬ／ＴＬＳにより生成されたＳＳＬ／ＴＬＳセッションに対して、そのセッション中に交換されたノンスをキャッシュ７０６に格納することもできる。したがって、別のプロキシサーバ３０２とのセッションを再開すると、この新たなサーバ３０２は、前のデータグラムの受信時点を検出することができる。
【０１１１】
なお、上記の発明は、ある特定のデータ処理環境内での運用に限定されるものではなく、分散コンピュータネットワーク環境、単一の独立型コンピュータシステム環境などのコンピュータ環境等、複数のデータ処理環境内で自由に運用できる。さらに、特定の一連のトランザクションやステップを用いて本発明を説明してきたが、当業者にとっては、本発明の範囲が前記の一連のトランザクションやステップに限定されるものではないことが明らかであろう。
【０１１２】
本発明をプログラミングするために使用されるロジック、システムフロー、テーブル、およびデータ構成の生成には、本質的な自由度がある。演算を行うデータ構成やデータ値は、本発明の趣旨を逸脱するもの、または、本発明の範囲を制限するものでない限り、明示的なものでも、他のデータから導出されたものでも、他のソースから取り込まれたものでも、プログラム演算またはロジック演算の結果でもよい。この特許における索引付け、検索、データ処理のためのアルゴリズムは、本発明の趣旨を逸脱するもの、または、本発明の範囲を制限するものでない限り、様々な性能／システムインテグレーション要件をサポートするために、置換または変更されてもよい。
【０１１３】
さらに、本発明について、ハードウェアとソフトウェアとの特定の組み合わせを用いて説明したが、ハードウェアとソフトウェアとのその他の組み合わせも、本発明の範囲内であると認識すべきである。本発明は、ハードウェアのみ、もしくは、ソフトウェアのみ、または、その組み合わせを用いて実施してもよい。
この明細書および図面は、限定的ではなく例示的な意味合いと見なされるものとする。しかし、特許請求の範囲に記載されている本発明のより広範な趣旨および範囲から逸脱することなく、本発明に対して、追加、除去、削除、その他の改良や変更が可能であることは明白である。
【０１１４】
添付の方法に関する請求項においてステップを識別する参照番号は、単に便宜上のものであり、ステップの必須の順序を暗示するためのものではない。したがって、本発明は、添付の特許請求の範囲内において、上記以外の方法で実施してもよいと理解される。いずれの請求項も、「ミーンズ・プラス・ファンクション」形式であると解釈してはならない。
【図面の簡単な説明】
【０１１５】
【図１Ａ】ＴＣＰまたはＵＤＰをＩＰと共に利用してデータパケットを送信するための従来の方策を示す。
【図１Ｂ】ＳＳＬ／ＴＬＳをＴＣＰ／ＩＰと共に利用して確実なデータを送信するための従来の方策を示す。
【図１Ｃ】ヘッダフィールドと、暗号化暗号テキストフィールドと、メッセージ認証チェック（ＭＡＣ）とを含むＳＳＬ／ＴＬＳレコードのための従来のレコードフォーマットを示す。
【図２】ＳＯＣＫＳプロトコルを利用して、プロキシサーバ２０２を介してクライアントコンピュータ２０１をサーバコンピュータ２０３にインタフェースするための従来の方策を示す。
【図３Ａ】本発明のある変形態様に係る、送出フロー方向の改良ＳＯＣＫＳプロトコルを用いたシステムを示す。
【図３Ｂ】本発明のある変形態様に係る、送入フロー方向の改良ＳＯＣＫＳプロトコルを用いたシステムを示す。
【図４Ａ】暗号化を用いてＳＳＬ／ＴＬＳレコードを生成する従来の手法を示す。
【図４Ｂ】以前に暗号解読されたレコードに依存してＳＳＬ／ＴＬＳレコードを暗号解読する従来の手法を示す。
【図５Ａ】以前に送信されたレコードとは独立して各レコードを暗号化する本発明のある変形態様に係る改良暗号化方式を示す。
【図５Ｂ】以前に受信されたレコードとは独立して各レコードを暗号解読する本発明のある変形態様に係る改良暗号解読方式を示す。
【図５Ｃ】単一のレコード内に多数の暗号ブロックを含む改良暗号解読方式を示す。
【図６】本発明の様々な原則に従って、暗号化レコードの生成および送信に使用可能な方法の各ステップを示す。
【図７Ａ】本発明のある実施形態に係る２つのネットワークを示す。
【図７Ｂ】本発明のある実施形態に係る２つのネットワークを示す。
【図８Ａ】本発明の別の実施形態に係る２つのネットワークを示す。
【図８Ｂ】本発明の別の実施形態に係る２つのネットワークを示す。
【図９】本発明のある実施形態に係るプロキシサーバ装置を示す。
【図１０Ａ】本発明のある実施形態に係るネットワークフローレベル検出手法を示す。
【図１０Ｂ】本発明のある実施形態に係るネットワークフローレベル検出手法を示す。
【０００１】
本発明は、一般的に、データ送信方式およびプロトコルに関する。特に、本発明は、ユーザ・データグラム・プロトコル（ＵＤＰ）などの信頼性のないプロトコルを利用して、２つ以上のコンピュータノード間で確実にデータを送信するための方法および装置を提供する。さらに、本発明は、本発明の確実な送信を利用したコンピュータとの通信セッションを、新たなセッションを生成する必要なく、別のコンピュータに切り換えることができる方法および装置を提供する。
【背景技術】
【０００２】
本願は、２００１年２月１２日出願、発明者マーク・ファン・ハイニンゲン（Marc van Heyningen）、名称「信頼性のないプロトコルを利用して確実なストリーミングデータ送信機能を提供するための方法および装置（Method And Apparatus For Providing Secure Streaming Data Transmission Facilities Using Unreliable Protocols）」の同時係属米国特許出願の一部継続出願に関連し、この一部継続出願はその全体が本願に引用により組み込まれている。また、本願は、２００１年２月１３日出願、発明者ロジャー・エリクソン（Rodger Erickson）、名称「状態転送動作のための分散型キャッシュ（Distributed Cache For State Transfer Operations）」の同時係属米国特許出願に関連し、この米国特許出願もその全体が本願に引用により組み込まれている。
【０００３】
周知のトランスミッション・コントロール・プロトコル／インタネット・プロトコル（ＴＣＰ／ＩＰ）は、コンピュータ間でデータパケットを送信するために長年使用されてきた。ＴＣＰは、データパケットの保証配信／配列方式を提供し、ＴＣＰを使用する２以上のコンピュータは、このプロトコルに依存して、任意のパケットが、送信された順序でその宛先に到達することを保証する。インタネット・プロトコル（ＩＰ）は、一般的に、保証配信なしにポイント間パケット送信サービスを提供する。図１Ａは、従来のプロトコルスタックに従ってＴＣＰ／ＩＰ上にアプリケーションプログラムを積み上げる方法を示す。一般的なハイパーテキスト・トランスポート・プロトコル（ＨＴＴＰ）は、ウェブページの取出しと表示のために、クライアントのブラウザとサーバコンピュータとの間のＴＣＰ接続の存在に依存している。
【０００４】
ＴＣＰは、内蔵メカニズムを利用して保証配信機能を提供する（すなわち、各アプリケーションは、信頼性の詳細に関わる必要がない）が、ＴＣＰの使用の欠点は、データストリームを送信するときに遅延などの副作用を招く可能性があることである。例えば、２つのコンピュータが、ＴＣＰを使用してパケット化されたビデオストリームを送信すると、パケットを受信パケットストリームへと再配列する前に、喪失または脱落したパケットを再送信しなければならないので、受信パケットが「ギクシャク」して見える。結果的に、ＴＣＰは、ビデオ会議アプリケーションなどのデータストリーミングにとって良い候補とはならない。
【０００５】
周知のユーザ・データグラム・プロトコル（ＵＤＰ）は、クライアントコンピュータおよびサーバコンピュータといった２つのコンピュータ間で通信するためのパケット志向型の送信サービスを提供する。ＴＣＰなどの保証配信プロトコルとは対照的に、ＵＤＰを使用して送信されたパケットは、宛先のコンピュータに到達することが保証されない。さらに、特定の順序で送信されたパケットが、宛先のコンピュータに順不同で到達する場合もある。したがって、ＵＤＰは、「信頼性のない」転送プロトコルと称されている。しかし、ＴＣＰなどの保証配信プロトコルとは対照的に、ＵＤＰは、時間重視の配信方式を提供し、ビデオデータなどのストリーミングメディアにとってより好適である。
【０００６】
ビデオ会議などのアプリケーションにより、ストリーミングメディアの重要性が高まり、確実なストリーミング送信機能を提供する必要性がある。例えば、数多くの企業において、本社設備と１以上の遠隔地オフィスとの間でストリーミングビデオを送信する必要性がある。送信には、会社が意図しない受信者や盗聴から保護する必要のある機密情報が含まれている場合がある。ＴＣＰもＵＤＰもこの様なセキュリティを提供しないので、この様な送信には不十分である。
【０００７】
近年、保証配信プロトコルを暗号手法で強化することによって確実な送信機能を提供するために、様々な試みがなされてきた。例えば、セキュア・ソケット・レイヤ（ＳＳＬ）は、サーバコンピュータおよびクライアントコンピュータといった２つの装置間の確実なチャネルを提供するプロトコルである。この様な確実なチャネルは、透過性があり（トランスペアレントであり）、かつ、クライアントとサーバとの間で暗号化され、ＴＣＰ上で実行可能な殆ど全てのプロトコルが、最小限の修正によりＳＳＬ上で実行可能となっている。確かに、ＳＳＬ／ＴＬＳセキュリティおよび障害検出は、ＴＣＰ（または同様の保証配信プロトコル）に依存して、パケットの配列と保証配信とを行っている。様々な修正を経て、ＳＳＬは、トランスポート・レイヤ・セキュリティ（ＴＬＳ）と改名され、ＲＦＣ２２４６に反映されているように、インタネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）に採用されている。（ＳＳＬ／ＴＬＳという用語は、これら２つの緊密に関係するプロトコルを一括して称するために使用される。）ＳＳＬ／ＴＬＳの主なアプリケーションは、オンラインショッピングであり、オンラインショッピングでは、消費者は、ＨＴＴＰプロトコルやウェブブラウザを安全に利用してクレジットカード機密情報を送信する。
【０００８】
大抵のインタネットプロトコルはＴＣＰ接続上で動作するので、ＳＳＬ／ＴＬＳは、クライアントコンピュータおよびサーバコンピュータなどの２つ以上のコンピュータ間で確実にデータを送信する便利な方式を提供する。図１Ｂは、アプリケーションが、ＳＳＬ／ＴＬＳを使用してＴＣＰなどの信頼性のある接続上で確実なデータを送信する方法を構造的に示している。従来どおり、ＳＳＬ／ＴＬＳを利用して確実にデータを送信するステップは、一般的に以下のステップを含んでいる。
（１） クライアントが、サーバコンピュータとのＴＣＰ接続を確立する。
（２） クライアントとサーバが、ＳＳＬ／ＴＬＳプロトコルを使用して、信任情報（ＳＳＬ／ＴＬＳハンドシェイク、プロトコルメカニズムの取り決め、接続毎のキーの確立など）を交換する。
（３） 各ＨＴＴＰ要求（例えば、ＧＥＴ）が、暗号内容を有するＳＳＬ／ＴＬＳレコードに変換される。
【０００９】
図１Ｃは、サンプルのＳＳＬ／ＴＬＳレコードを示し、これは、ヘッダ（ＨＤＲ）と、暗号化データまたは暗号テキストと、ＭＡＣ（メッセージ認証チェック）とを含んでいる。ＭＡＣは、強力なチェックサムと同様のキー付きハッシュによりメッセージの完全性を保証し、一般的に、関数ＭＡＣ＝ｈ（キー，プレインテキスト，連番）として演算される。ここで、連番は、連続レコード用の１増分カウンターである。連番は、ハッカーがＴＬＳ使用のコンピュータ間の確実な通信を暗号解読または破壊しようとしてパケットの傍受や再配列を試みた場合に発生するいわゆる「スプライシング攻撃」を防止するので、ＴＬＳにより演算されたＭＡＣの重要な側面を構成する。受信側ＴＬＳが受信レコードに不正確な連番を検出した場合、故意の侵害としてそのレコードを拒絶し、接続を終了する。これにより、送信側および受信側は、別のＴＣＰ接続を再確立しなければならず、結果的に時間とリソースの浪費となる。
【００１０】
透過性のある性質上、ＴＣＰベースのプロトコル（例えば、ＨＴＴＰ、ＦＴＰなど）または同様の保証配信プロトコルは、ＴＬＳ上で動作可能である。ＳＳＬおよびＴＬＳの更なる詳細については、下記非特許文献１に記載されている。
しかし、ＴＣＰなどの保証配信プロトコルに対する依存により、ＳＳＬ／ＴＬＳは、ＴＣＰと同様の性能問題の影響を受けやすい。例えば、ＳＳＬ／ＴＬＳを用いてストリーミングビデオデータを送信すると、その基礎となっているＴＣＰと同様の犠牲と不利益を招く（例えば、「ギクシャク」したビデオとなることがある）。ＳＳＬ／ＴＬＳは、パケットが脱落したり順不同に受信された場合に接続を終了するので、その性質上、ＴＣＰにより提供されるような信頼性のある接続の利用が必要である。
【００１１】
近年、プライベート・コミュニケーション・テクノロジー（ＰＣＴ）として知られているプロトコルが提案されているが、商業的な成功を収めていない。ＰＣＴは、（いわゆる「ストリーム暗号」を用いた）確実なデータグラムトラフィックへとＳＳＬを拡張する試みである。例えば、ＰＣＴは、ＳＳＬ（５バイト、１レコードタイプ、２バージョン番号、２レングス）とは異なるヘッダフォーマット（４バイト、２レングス、２レコードタイプ）を使用していた。また、ハンドシェークメッセージ本体には、異なる開始フォーマットが含まれていた。すなわち、ＳＳＬは、１バイト（ハンドシェークタイプ）しか使用しないが、ＰＣＴは、４バイト（２ハンドシェークタイプ、２レコードフラグ）を使用している。ＰＣＴデータグラムサポートは、以下のフォーマットを使用している。
【００１２】
2 bytes of key_length
(key_length) bytes of key data
(data_length) bytes of encrypted data
(mac_length) bytes of MAC data
一方、ＳＳＬのデータグラムサポートは以下のようなフォーマットである。
【００１３】
(data_length) bytes of encrypted data
(mac_length) bytes of MAC
(padding_length) bytes of padding
1 byte of padding_length
(nonce_length) bytes of nonce
ＰＣＴは、各データグラムが、ENCRYPTED_KEY_1_DATA（DK_ENCRYPTED_KEY_DATAの一部である各レコードにランダム値が割り当てられる）によりマスタキーをハッシュすることによって生成された新たな暗号化キーを有するメカニズムを指定する。
【００１４】
提案されたＰＣＴメカニズムは、様々な性能的な犠牲を強いる。例えば、ＰＣＴメカニズムは、ストリーム暗号と共に使用可能であるが、各レコードを処理するための更なるハッシュとキースケジュール生成により、処理速度がかなり遅くなる。すなわち、データグラム毎に異なるキーを使用するので、演算上の犠牲が大きい。キースケジュール設定は、ブロック暗号にとって高価である。さらに、ＰＣＴは、ＳＯＣＫＳなどのマルチプロトコルプロキシとの統合メカニズムを提供していなかった。
【００１５】
従来、ＵＤＰが確実な通信には不適切であるといわれてきた。例えば、下記非特許文献１のレスコーラの著書は、特に、「ＵＤＰは、（信頼性のある伝送を提供しないので）レコードの喪失や再配列が自由に起こり、まるでＳＳＬ実施に対する積極的な攻撃のようであるので、ＳＳＬをＵＤＰ上でうまく実行することができない。」と記述している。結局、先行技術は、確実なデータ送信のためにＳＳＬと共にＵＤＰを使用することを避けるように提言している。それでも、ＵＤＰは、数々のストリーミングメディアアプリケーションにとって適合性が良く、時折発生するデータパケットの脱落を許容するが、ＴＣＰで発生する遅延を許容することはない。例えば、リアルタイムで放映されるビデオ会議は、時折失われるビデオフレームを許容するが、失われたパケットの再送信や再配列のときに発生する「ギクシャクした動き」を許容しない。さらに、標準ＳＳＬ上で送られる標準ＵＤＰでは、ユーザセッションの終了が頻繁に起こる。
【００１６】
プロトコルの中には、ビデオまたはオーディオストリーミングなどの高性能データを送信するために、ＴＣＰとＵＤＰの両方に依存するものもある。例えば、ＲＥＡＬＡＵＤＩＯは、ＴＣＰおよびＵＤＰの両方を使用していると考えられており、ＴＣＰを使用して信号発信（例えば、開始／停止）を行う一方、ＵＤＰを使用してストリーミング内容のデータパケットを送信するようになっている。しかし、ＵＤＰデータグラムは、自由に送信されるので、傍受や攻撃を受けやすい。
【００１７】
ＫＥＲＢＥＲＯＳとして知られているプロトコルは、主にアカデミックサークルで使用されているが、ＵＤＰデータグラムの暗号化によりセキュリティを提供する。ＫＥＲＢＥＲＯＳがデータグラムセキュリティ提供のために使用するメカニズムは、ＲＦＣ１９６４に記載されている。しかし、これは、ＳＳＬ／ＴＬＳプロトコルと互換性がないので、広く普及していない。ＫＥＲＢＥＲＯＳが商業的な成功を収めていない主要な理由の１つに、動作が複雑で、ネットワーク処理に広く使用できるほど合理化されていないことが挙げられる。特に、ネットワークベースのセキュリティソフトウェアは、ユーザのアクセスの制御と保護のためにウェブサーバおよびプロキシサーバと効率よく相互動作しなければならない。一般的に、単純なプロトコルは、高速処理／分散システムに有利である。
【００１８】
また、ＫＥＲＢＥＲＯＳは、確実なＵＤＰ／ＴＣＰトラフィックを通信するために、別個の暗号化メカニズム、すなわち、キー確立ハンドシェイクを使用する。しかし、ＳＯＣＫＳなどのマルチプロトコルプロキシサーバ標準上で実行されるＳＳＬなどの単一標準セキュリティプロトコルの下でこれらを統合することによって、演算／ネットワークトラフィックのオーバヘッドを低減することが望ましい。さらに、ＫＥＲＢＥＲＯＳは、暗号化アルゴリズムを初期化する目的で、データレコードを従来の方法で拡張するために、パケット識別のためのランダムキーフィールドを追加している。しかし、ＫＥＲＢＥＲＯＳがデータレコード内に個別の連番を有するので、これにより、更なる演算／ネットワークトラフィックが必要となる。あるシステムにとっては、両方の目的を果たす単一のフィールドを有することが好適である。
【００１９】
ＵＤＰおよびＳＳＬは、ソフトウェア産業では標準となっている。ＵＤＰは、データグラム処理に使用され、ＳＳＬは、確実な通信を提供する。同時に、一般的なＳＯＣＫＳプロトコルを実行するものなど、マルチプロトコルプロキシサーバの採用は、システム内でＴＣＰやＵＤＰなどの産業用標準通信プロトコルを組み合わせる手段を提供する。ＵＤＰとＳＳＬとの互換性がないので、最近までこれは不可能であった。ＳＯＣＫＳなどの単一のプロキシサーバプロトコルの下でネットワーク通信を管理するために発生したこの問題と制約とを理解するためには、先ず、ＳＯＣＫＳの情報処理方法を理解する必要がある。
【００２０】
ＳＯＣＫＳプロトコルは、ファイアウォルなどの境界を設定するための一般的なプロキシプロトコルを提供する。ＩＥＴＦ ＲＦＣ１９２８に記載されているこのプロトコルのバージョン５は、認証、ＵＤＰサポートなどの機能を提供する。図２は、プロキシサーバおよびＳＯＣＫＳプロトコルにより、ファイアウォルを介してサーバと接続するための従来の方策を示している。図２に示すように、クライアントコンピュータ２０１は、プロキシサーバ２０２を介してアプリケーションサーバ２０３と通信する。このシステムは、ネットワーク間のアプリケーションレイヤゲートウェイの役割を果たすファイアウォル（図示せず）を備えている場合もある。アプリケーションサーバ２０３は、通常、ＴＥＬＮＥＴ、ＦＴＰ、ＳＭＴＰ、ＨＴＴＰアクセスを提供する。クライアントコンピュータ２０１は、アプリケーション２０１１（例えば、ウェブブラウザ）と、ＳＯＣＫＳクライアント２０１２とを備えている。プロキシサーバ２０２は、ＳＯＣＫＳサーバ２０２１と、プロキシ機能２０２２とを備えている。セキュリティ機能を提供するＳＯＣＫＳバージョン５によれば、クライアントアプリケーション２０１１は、以下のようにサーバ２０３からのサービスを得ることができる
先ず、クライアントアプリケーション２０１１は、サーバ２０３への接続要求をする。次に、ＳＯＣＫＳクライアント２０１２は、要求された接続を検出し、プロキシサーバ２０２を介してサーバ２０３との通信に対処すべきことを認識する。結果的に、ＳＯＣＫＳクライアント２０１２は、ＴＣＰ接続を確立するためにＳＯＣＫＳサーバ２０２１に要求を送信する。プロキシ機能２０２２は、サーバ２０３との接続を確立し、クライアントアプリケーション２０１１とサーバ２０３との間の以降の通信は、ＳＯＣＫＳサーバ２０２１およびプロキシ機能２０２２を介して行われる。従来と同様に、ＳＯＣＫＳは、クライアント２０１との確実な接続を確立するためにＳＳＬ／ＴＬＳを使用し、接続確立を許容する前にパスワードを要求する。図２のアーキテクチャは、１つのポイント（例えば、プロキシサーバ２０２）でサーバ２０３へのアクセスを制限し、ファイアウォルを貫通するような方法でサーバ２０３との通信負荷の一部を負担する。セキュリティを提供するためにＳＳＬ／ＴＬＳに依存しているので、図２の接続は、必ずＴＣＰ（同様の保証配信プロトコル）に依存する。
【００２１】
図２のアーキテクチャは、不確実なＵＤＰデータグラムの送信のためにも利用可能である。この方式には、ポートを介して不確実なＵＤＰデータグラムを送信する一方、確実なＳＳＬ／ＴＬＳ／ＴＣＰ接続を介して確実なコマンドを送信するように、クライアント２０１とプロキシサーバ２０２との間のＵＤＰポート「接続」を取り決めることが含まれている。この様な方式は、ＵＤＰデータグラムが不確実であるということを反映して「無防備なＵＤＰ」モードと称されることもある。この手法を採用しているシステムは、数年にわたり、ワシントン、シアトルのアベンテイル社から市販されてきた。一般的に、ＳＯＣＫＳクライアント２０１２は、クライアント２０１から送信される各レコードにＳＯＣＫＳヘッダを付与し、ＳＯＣＫＳヘッダは、サーバ２０３に送信される前にＳＯＣＫＳサーバ２０２１により取り除かれる。
【００２２】
上述のように、ＳＳＬ／ＴＬＳは信頼性のある接続サービスを提供するためにＴＣＰに依存しているので、ＳＳＬ／ＴＬＳのコンテキストでＵＤＰデータグラムを確実に送信することは不可能である。しかし、図２の方式で確実なＵＤＰサービスを提供することは有利であり、プロキシサーバ２０２は、データセキュリティを犠牲にすることなく、クライアント２０１とサーバ２０３との間の高性能ビデオストリーミングを円滑にできる。結局、課題は、好ましくは、ＳＳＬをセキュリティレイヤとして使用し、ＳＯＣＫＳをマルチプロトコルプロキシサーバとして使用して、プロキシサーバ２０２を介して確実なＴＣＰおよび確実なＵＤＰを実施するための方法を見出すことである。一般的には、ＴＣＰに対する依存によるオーバヘッドおよび不都合を招くことなく、ＳＳＬ／ＴＬＳ標準との互換性を維持する方法を見出すことが望まれる。
【００２３】
ＳＳＬ／ＴＬＳプロトコルは、ＵＤＰ上でうまく実行できないことに加えて、更に別の欠点がある。上記の例では、クライアント装置２０１は、プロキシサーバ２０２との完全ＳＳＬ／ＴＬＳ「ハンドシェイク」を完了することによって、プロキシサーバ２０２との確実なプロトコルセッションを開始する。このハンドシェイク中に、クライアントコンピュータ２０１およびプロキシサーバ２０２は、ＳＳＬ／ＴＬＳバージョン番号、暗号設定、セッション特定データ、認証証明など、ＳＳＬ／ＴＬＳプロトコルを利用して互いに通信すべき情報を交換する。この様な情報を利用して、クライアントコンピュータ２０１およびプロキシサーバ２０２は、同一のマスタシークレットキーを生成し、それを用いて個々のセッションキーを生成する。これらのセッションキーは、セッション中に交換した個々の情報グループの暗号化と暗号解読とを行い、交換情報の完全性を確認するために用いる対称キーである。
【００２４】
当業者に理解されるように、ＳＳＬ／ＴＬＳセッションを開始するために完全ＳＳＬ／ＴＬＳハンドシェイクを実行するには、時間がかかり、ネットワーク通信トラフィックに関しても、クライアント装置２０１とプロキシサーバ２０２との処理時間に関しても、ネットワークのリソースに大きな負荷をかける。しかし、プロキシサーバ２０２が、完全ＳＳＬ／ＴＬＳハンドシェイクにおいて必要なＳＳＬ／ＴＬＳセッション情報を受信すると、プロキシサーバ２０２は、部分ＳＳＬ／ＴＬＳハンドシェイクのみを利用してクライアントコンピュータ２０１とのそのＳＳＬ／ＴＬＳセッションを再開する。好適にも、部分ＳＳＬ／ＴＬＳハンドシェイクは、完全ＳＳＬ／ＴＬＳハンドシェイクよりもかなり迅速であり、消費するネットワークリソースも少ない。
【００２５】
しかし、クライアントコンピュータ２０１とプロキシサーバ２０２との間の接続が終了し、クライアントコンピュータ２０１が、別のプロキシサーバ２０２を介してアプリケーションサーバ２０３との通信を確立しようした場合に、この構成に関して問題が発生する。例えば、最初のプロキシサーバ２０２が機能せず、利用不可能となるか、または、負荷バランサが最初のプロキシサーバ２０２の通信負荷を低減するために、新たな接続をクライアント装置２０１から新たなプロキシサーバ２０２へと単にルーティングする場合がある。いずれの場合も、新たなプロキシサーバ２０２は、クライアントコンピュータ２０１とのＳＳＬ／ＴＬＳセッションを再開するために必要なＳＳＬ／ＴＬＳセッション情報を有していない。したがって、クライアント装置２０１および新たなプロキシサーバ２０２は、新たなＳＳＬ／ＴＬＳ通信セッションを確立するために完全ＳＳＬ／ＴＬＳハンドシェイクを実行しなければならない。このプロセスは時間がかかり、クライアントコンピュータ２０１および新たなプロキシサーバ２０２にとっては多大な処理時間を要する。さらに、クライアント装置２０１とプロキシサーバ２０２との間の元のセッションの状態によっては、前のセッションの状態の喪失が代替不可能である場合もある。例えば、前のセッションの状態が、複製不可能なデータの交換により確立されていた場合、そのセッションの再生は不可能である。
【００２６】
この問題を解決するために、クライアントコンピュータ２０１とその関連のプロキシサーバ２０２との間で終了された接続を、新たなプロキシサーバ装置２０２に対してではなく、元のプロキシサーバ２０２に対して再確立するようにしたネットワークシステムがある。例えば、クライアント装置２０１が特定のプロキシサーバ２０２に対してセッションを確立した時点を認識し、以降の全ての接続をクライアントコンピュータ２０１からプロキシサーバ２０２へとルーティングするように負荷バランサを設計しているシステムがある。しかし、この解決策は、数々の欠点を有する。負荷バランサが非常に複雑化し、様々な機能を果たすことが要求される。さらに、元のプロキシサーバ２０２が利用不可能になった場合、例えば、元のプロキシサーバが機能せず、クライアントコンピュータ２０１との接続の再確立が不可能になった場合に発生する状況に対処するものではない。また、最初のプロキシサーバ２０２が、他のクライアントコンピュータとの接続により過負荷となった場合の状況に対処するものではない。事実、この解決策により、負荷バランサは負荷バランス機能を果たせなくなる。
【非特許文献１】
アディソン・ウェスレイ（Addison Wesley）発行、エリック・レスコーラ（Eric Rescorla）による著書「ＳＳＬとＴＬＳ：確実なシステムの設計と構築（SSL and TLS: Designing and Building Secure Systems）」ISBN0-201-61598-3
【発明の開示】
【発明が解決しようとする課題】
【００２７】
信頼性のある通信プロトコルに本質的に伴う不都合とオーバヘッドとを招くことなく確実なデータ送信機能を提供するための従来の試みの失敗を鑑み、確実なビデオ会議など、高帯域のアプリケーションをサポートするために、この様な機能を提供する必要性がある。さらに、ＳＳＬ／ＴＬＳとの互換性を維持しながら、確実なデータ送信サービスを提供する必要性がある。さらに、クライアントコンピュータと第１のプロキシサーバとの間で確立されたＳＳＬ／ＴＬＳセッションの状態を維持しながら、クライアントコンピュータが、第１のプロキシサーバとの通信接続を第２のプロキシサーバへと切り換えることができるネットワーク構成が必要である。好ましくは、第１のプロキシサーバが機能不全などの問題により利用不可能になった場合でも、ネットワーク構成は、第１のプロキシサーバとの接続から第２のプロキシサーバとの接続へのこの様な切り換えが可能でなければならない。
【課題を解決するための手段】
【００２８】
本発明は、ＵＤＰなどの信頼性のないプロトコル上で暗号化データを送信するための方法および装置を提供することによって前述の問題を克服する。ある変形態様においては、特殊ビットがデータレコード内に設定され、プロキシサーバで受信されたときに、レコードは特殊な処理に回される。この特殊な処理には、繰り返しレコードの存在を検出するためのノンスの使用や、他のレコードのデータを参照することなくプロキシサーバにレコードを暗号解読させる初期化ベクトルの使用が含まれる。特殊なビットセットを有さないデータレコードは、従来のＳＳＬ／ＴＬＳ処理に従って処理される。
【００２９】
さらに、本発明は、複数の異なるロケーションにコピーを分散させたキャッシュを用いるネットワーク構成を提供する。本発明によれば、任意のプロキシサーバとのセッションに関するＳＳＬ／ＴＬＳセッション情報がキャッシュに格納されるので、少なくとも１つの他のプロキシサーバに対してアクセス可能である。クライアント装置が、第１のプロキシサーバとの接続から第２のプロキシサーバとの接続へと切り換えるとき、この構成を利用して、第２のプロキシサーバは、クライアント装置と第１のプロキシサーバとのＳＳＬ／ＴＬＳ通信セッションに対応するキャッシュから、ＳＳＬ／ＴＬＳセッション情報を検索することができる。そして、第２のプロキシサーバは、検索されたＳＳＬ／ＴＬＳセッション情報を用いて、クライアント装置とのセッションを引き受けることができる。本発明のある実施形態によれば、キャッシュの同一コピーがこのネットワーク構成の各プロキシサーバのために格納され、各プロキシサーバは、キャッシュのそれ自体のコピーにアクセスして必要なＳＳＬ／ＴＬＳセッション情報を得る。本発明の他の実施形態においては、このネットワーク構成における全てのプロキシサーバにアクセス可能な単一のソース（例えば、冗長なキャッシュ記憶装置セット）においてキャッシュのコピーが保持される。
【００３０】
本発明のその他の特徴および利点は、以下の詳細な説明および図面を参照することにより明らかになるであろう。
【発明を実施するための最良の形態】
【００３１】
図３Ａは、本発明のある変形態様に係る、送出方向の（例えば、クライアントからアプリケーションサーバへの）改良ＳＯＣＫＳプロトコルを用いたシステムを示す。図３Ａに示すように、クライアントコンピュータ３０１は、プロキシサーバ３０２を介してアプリケーションサーバ３０３と通信する。図２の従来のシステムと同様に、クライアントコンピュータは、ＳＯＣＫＳクライアント３０１２と交信するクライアントアプリケーション３０１１を備えている。しかし、図２の従来のシステムとは対照的に、ＳＯＣＫＳ処理は、以下に詳述するように、図２のシステムとは更に異なる機能を実行するように改良されている。アプリケーションサーバ３０３は、図２を参照して説明した方法と同じ方法で動作する。
【００３２】
図２のシステムとは対照的に、プロキシサーバ３０２は、２つのタイプのＳＯＣＫＳ処理機能、すなわち、従来のＳＯＣＫＳ処理機能３０２２および改良ＳＯＣＫＳ処理機能３０２３を備えている。レコード検出器３０２１は、ＳＯＣＫＳクライアント３０１２からのサーバ向けのレコードを受信し、レコードが「確実なＵＤＰ」レコードであることを示す特定のビットが設定されているか否かにより、ソフトウェアスイッチを介して従来のＳＯＣＫＳ処理機能３０２２または改良ＳＯＣＫＳ処理機能３０２３にレコードをルーティングする。以下、改良ＳＯＣＫＳ処理機能３０２３の詳細について説明する。
【００３３】
図３Ａに示すアーキテクチャによって、プロキシサーバ３０２は、図２のＳＯＣＫＳクライアント２０１２などの従来のＳＯＣＫＳクライアント、または、暗号化データの送信のためにＵＤＰなどの信頼性のないプロトコルを用いる本発明の原則に従って動作するように改良されたＳＯＣＫＳクライアント（改良ＳＯＣＫＳクライアント３０１２）と共に動作することができる。さらに、両タイプのクライアントを同時に収容することができる。ある実施形態において、ＵＤＰプロトコルおよびＴＣＰプロトコルは、同一のプロキシサーバ上で動作可能である。以下、改良処理を更に詳述する。プロキシ機能３０２４は、図２のプロキシ機能２０２２とほぼ同じ方法で動作する。
【００３４】
図３Ａのアーキテクチャに関して、本発明の原則の範囲内に属する数々の変形態様がある。一例として、レコード検出器３０２１は、任意とすることができる。また、別の例として、クライアント３０１およびプロキシサーバ３０２が、初期化シーケンス中に、ここに記載されている改良暗号化方式に従って以降の全てのＵＤＰデータグラムを両者間で送信することに同意すると、何れのプロトコルに準拠しているかを決定するために、各レコードにフラグを立てたり評価したりする必要はない。もちろん、他のフィールドによりレコードタイプを暗に指定して、レコードタイプ（そして、結果的な処理）が他のフィールドから明確となるようにすることも可能である。もちろん、「無防備なＵＤＰ」と同様に、確実なＵＤＰをサポートするキーやその他の暗号化レコードを含めるために、確実なＴＣＰメッセージを本発明と組み合わせることもできる。さらに、プロキシサーバ３０２の機能をサーバ３０３や他のコンピュータに組み込むことができ、これらの機能を実行するための別個のプロキシサーバは必要ない。結局、双方向の確実な通信経路が確立されるように、暗号化レコードをクライアントコンピュータ３０１からプロキシサーバ３０２へと、または、その逆に送信可能であることは明白である。
【００３５】
図３Ｂは、送入（サーバからクライアントへの）フロー方向に関する図３Ａのシステムを示す。プロキシ機能３０２４を介して受信されるレコードは、ＳＯＣＫＳ処理機能３０２５に転送され、クライアント側レコード検出器機能３０１５に転送される。レコード検出器３０１５は、確実なＵＤＰビットセットを有するレコードを検出すれば、それに応答して、この様なレコードを改良ＳＯＣＫＳ処理機能３０１４へとルーティングし、そうでなければ、従来のＳＯＣＫＳ処理機能３０１３に送信する。なお、本発明の原則から逸脱しない限り、クライアント３０１、プロキシサーバ３０２、または、別のコンピュータに様々なＳＯＣＫＳ処理機能を配置可能であると解釈される。
【００３６】
図４Ａは、暗号を使用するＳＳＬ／ＴＬＳレコードを生成するための従来の手法を示す。本発明の暗号化原理の適用方法を説明する前に、先ず、ＳＳＬ／ＴＬＳによる暗号化および暗号解読の実行方法について簡単に概説する必要がある。
図４Ａに示すように、従来のデータ・エンクリプション・スタンダード（ＤＥＳ）などの暗号化機能４０４を使用して、プレインテキスト４０１の最初のバイトを暗号化する。送信側および受信側（例えば、ＳＯＣＫＳクライアント２０１２およびＳＯＣＫＳサーバ２０２１）で共有されるセッション暗号化キー４０２ならびに初期化ベクトル（ＩＶ）４０３が、暗号化機能４０４に入力され、結果的に暗号化暗号テキスト４０５が生成される。ＳＳＬ／ＴＬＳ標準によれば、この暗号テキストは、キー４０７、プレインテキスト、レコード毎に増分される連番の関数としてのハッシュ機能４１１により生成されるＭＡＣと、ヘッダとを含むレコード４１０に埋め込まれる。得られたレコード４１０は、クライアント３０１とプロキシサーバ３０２との最初のハンドシェイクの一部として以前に確立されたＴＣＰ接続を介してプロキシサーバ３０２に送信される。最初の初期化ベクトル４０３は、初期化中に送信側と受信側との間で合意される。
【００３７】
ＳＳＬ／ＴＬＳ標準によれば、同一のキー４０２を使用して、以前に送信されたレコードから生成された暗号テキスト４０５を２番目の初期化ベクトルとして使用して、次のプレインテキスト４０６を暗号化する。これによって、連続するレコード間の「リンク」が形成されるが、リンクが壊れた場合（パケットの喪失や破壊があった場合）には、この方式は機能しなくなる。
【００３８】
図４Ｂは、受信側での逆のプロセスを示す。受信側（例えば、プロキシサーバ２０２）において、第１のレコード４１０が以下のように暗号解読される。暗号テキストは、以前に共有されたセッションキー４１４と以前に共有された初期化ベクトル４１５とを使用して、暗号解読機能４１３において暗号解読される。ハッシュ機能４１７において、プレインテキストをキー４２０および（受信側で独立して増分される）１増分連番と組み合わせて使用し、送入レコードのＭＡＣに一致すべきＭＡＣを生成する。ＭＡＣが一致しない場合、そのレコードは廃棄される。
【００３９】
第２の（次の）送入レコード４１１は、セッションキー４１４を使用して暗号解読されるが、初期化ベクトル４１５の代わりに暗号テキスト４１０Ａを初期化ベクトルとして使用する。これは、図４Ａに示す対応する暗号化方式に適合する。上記のように、受信側がレコード４１０を受信しなかった場合（または、順不同に受信された場合）、暗号解読は、暗号解読に必要な「連結」初期化ベクトルに依存しているため、適切に行われない。暗号解読されたプレインテキスト４２１は、送入レコードのＭＡＣに一致するＭＡＣを生成しないので、ＭＡＣ比較機能４２３によりエラーが検出される。
【００４０】
上述のように、以前に送信されたデータレコードに対する従来のＳＳＬ／ＴＬＳの依存により、その基礎となるパケット送信メカニズムが完璧な信頼性を有することが必要となる。これは、「暗号ブロック連結」と称され、連続する各データレコードが、以前に生成されたレコードに依存して暗号化されるので、信頼性のあるレコード送信が必要となる（ＤＥＳに関しては、暗号ブロック連結はＦＩＰＳ８１により定義される）。結果的に、レコードが順不同に受信された場合や、データレコードが脱落した場合には、暗号化方式は失敗し、連番は一致しなくなる。この様なことが発生すれば、従来のＳＳＬ／ＴＬＳ方式では、ＴＣＰ接続は終了し、データ送信を再確立するために新たな接続が必要となる。このセキュリティ機能は、ハッカーが、クライアントとプロキシサーバとの間でのデータレコードの挿入や操作により確実な送信方式を妨害できないようにする意図がある。上述のように、図４Ａおよび図４Ｂの方式によりＵＤＰなどの信頼性のないプロトコルを用いてデータを送信した場合には、レコードの喪失や順不同によって直ちに接続が失われる。単純化の目的で、図４Ａおよび図４Ｂのレコード４１０には、暗号テキストの１ブロックしか示していない。実際には、１つのレコードに多数のブロックが含まれており、「暗号ブロック連結」は、１つのレコード内の連続するブロックの間で行われる。
【００４１】
図５Ａおよび図５Ｂは、本発明のある変形態様に従って使用可能な改良暗号化／暗号解読方式を示す。この変形態様によると、若干改良されたＳＳＬ／ＴＬＳレコードのフォーマット５０７を使用する。特殊ビット（ＵＤＰ）は、従来のヘッダに埋め込まれ、これは、レコードが暗号化ＵＤＰデータを含み、改良ＳＯＣＫＳ処理機能３０２３に従って処理されるべきであることを示す。レコード検出器３０２１または３０１５は、このビットを使用して、任意のＳＳＬ／ＴＬＳレコードを従来のＳＯＣＫＳ処理機能３０２２または３０１３にルーティングすべきか、それとも、改良ＳＯＣＫＳ処理機能３０２３または３０１４にルーティングすべきかを決定することができる。この機能により、既存のＳＳＬ／ＴＬＳ／ＳＯＣＫＳプロトコルに準拠するシステムと共に本発明の原則を適用できる一方、ＵＤＰデータグラムを送信するときに強化セキュリティ条件を使用できる。
【００４２】
図５Ａに示すように、プレインテキスト５０１は、従来のＤＥＳ暗号化アルゴリズムなどの暗号化機能５０８を使用して暗号化される。暗号化は、共有セッションキー５０２と第１の初期化ベクトル５０３を用いて実行され、その結果、暗号テキスト５０５が得られ、これを用いて改良ＳＳＬ／ＴＬＳレコード５０７を生成する。また、プレインテキスト５０１を別のキー５３０および第１のノンス値５０４と共に使用し、ハッシュ機能５０６を用いてＭＡＣ５０９を生成する。図４Ａの暗号化方式とは対照的に、レコード５０７には、ノンス値５０４および初期化ベクトル５０３が含まれており、これらは、好ましくは一意的な値（例えば、ランダム数）からなる。ある実施形態によれば、複合ノンス／ＩＶ値は、強力なランダム数生成装置（例えば、Ｘ９．６２標準により定義され、市販のＲＳＡ ＢＳＡＦＥ ＣＲＹＰＴＯ−Ｃ機能により生成されるもの）を使用して生成される。
【００４３】
従来のＳＳＬ／ＴＬＳ方式とは対照的に、ノンス／ＩＶ値は、明示的に各レコードの一部として含まれるので、以前に送信されたレコードに依存せずに、レコードを暗号解読することができる。ある実施形態において、連番および初期化ベクトルは、単一の値（ノンス）に統合可能であり、この値は、任意の数値またはランダムに生成された数値である。ある実施形態において、ノンスは、ＳＳＬにおける連番と同じサイズ（例えば、８バイト）であり、各値は一意的なものである（すなわち、受信側が、以前に受信されたレコードのリストと照合することができる）。初期化ベクトルは、暗号のブロックと同じサイズ（例えば、８バイト）を有し、各値は一意的なものとすることができる。ある変形態様において、異なる初期化ベクトル間のハミング距離が大きいこと（例えば、各ビットが５０％の変化の確率を有するランダム数であること）が好ましい。別個のノンスや初期化ベクトルを付加する代わりに、複合ノンス／ＩＶ値を使用することができる。ＲＳＡセキュリティ社から販売されているＲＳＡ ＢＳＡＦＥ ＣＲＹＰＴＯ−Ｃ製品など、暗号的に強力なランダム数生成装置を用いて、この様な数値を生成することができる。
【００４４】
図５Ａの右側において、プレインテキスト５１０は、同様の方法で暗号化され、別のノンス５１３および初期化ベクトル５１４を用いて、データレコード５１６が生成される。
図５Ｂを参照して、次に、レコード５０７、５１６の暗号解読について説明する。レコード５０７からの暗号テキストは、共有セッションキー５０２およびデータレコードから抽出された初期化ベクトル５０８を用いて暗号解読され、プレインテキスト５０１を生成する。プレインテキストは、キー５１８およびデータレコードから抽出されたノンス５０８と共に、ハッシュ機能を介して供給され、レコードから抽出されたＭＡＣ５０９と比較可能なＭＡＣを生成する。
【００４５】
第２のレコード５１６は、暗号解読を実行するために以前に送信されたレコード５０７中の値に依存しないことを除き、同様の方法で暗号解読される。この様に、脱落または順不同のレコードでも対処可能である。
図５Ｃに示す本発明の変形態様によれば、複数の暗号ブロック５２１を１つのレコードに含めることができ、前の暗号ブロックを参照して、各ブロックの暗号テキストを暗号解読することができる。暗号解読機能５２６において初期化ベクトル５２４を用いて第１の暗号テキストを暗号解読する一方、前のブロックの暗号テキストを用いて一連の暗号テキストブロックを暗号解読する（一般的に、暗号化は逆の方法で実行される）。連結されたプレインテキストブロック５３１、５３２、５３３に基づいて、単一のＭＡＣ値を演算することができる。
【００４６】
上述のように、ノンスおよびＩＶを１つの値に統合できるので、同一の値をＩＶおよびＭＡＣ演算の一意的な識別子として使用する。
ある変形態様においては、明示的に送信されたノンスを使用して、以前に送信されたレコードが２度目に受信されたかどうかを決定する。もし、そうであれば、この様な状況は、いわゆる「再生パケット」によるハッカー攻撃を意味するので、プロトコルは、選択的に、接続を終了するか、または、警告を発する。なお、後者は、連番が順不同に受信された場合に接続を終了する従来のＳＳＬ／ＴＬＳとは異なる。さらに、ある実施形態において、連番チェックは、無効にされるか、または、使用されない。
【００４７】
従来のＳＳＬ／ＴＬＳとは対照的に、本発明のある側面によれば、初期化ベクトルはレコードにまたがって連結されることはない。各レコードは、一意的な初期化ベクトルを含み、暗号テキストブロックは、従来のようにレコード内で連結される。
特殊ＵＤＰビットの使用は、レコードを従来のＳＳＬ／ＴＬＳレコードまたは改良ＳＳＬ／ＴＬＳレコードとして識別するための一手法にすぎない。ある実施形態においては、ビットは全く必要とされず、ここに記述されているように全てのレコードが改良ＳＳＬ／ＴＬＳプロトコルに準拠するものと仮定されている。他の実施形態において、特定のレコードを上記の改良方式に従って処理すべきであることを示すために、異なるフラグまたは方法を用いることができる。一例として、クライアントとプロキシサーバとの間に起こる最初のハンドシェイクの間に、メッセージを送信して、以降のレコードが前記のプロトコルに従って受信されることを示すことができる。別の実施形態においては、確実なＴＣＰを使用して、データレコードの比較と識別のためにノンスと同等のＭＡＣ値またはＩＶ値の集合を交換することができる。
【００４８】
ＵＤＰ以外の信頼性のないプロトコルを利用して、本発明の原則を実施することもでき、本発明がＵＤＰデータグラムに限定されないことを認識すべきである。さらに、ＤＥＳ以外の他の暗号化アルゴリズム（例えば、ＡＥＳ）を使用することもでき、本発明がこの点において限定されないことを理解すべきである。
図６は、本発明の原則を実施するために使用可能な方法の各ステップを示す。なお、プロキシサーバ３０２の使用は、総じて任意であり、図示の機能は、もちろんクライアントコンピュータ３０１、サーバコンピュータ３０３、その他のコンピュータで実施することができる。または、ＳＯＣＫＳプロトコルの制約がなくても、信頼性のないパケット送信を提供するプロトコル（例えば、インタネットプロトコル）を利用して、本発明の原則を実施することもできる。上記の例は、クライアント３０１からサーバ３０３への確実なＵＤＰデータの送信を反映しているが、図６の例では、サーバ３０３がプロキシサーバ３０２にＵＤＰデータグラムを送信し、プロキシサーバ３０２がＵＤＰデータグラムを暗号化してクライアント３０１に送信すると仮定する。
【００４９】
クライアントは、図３Ｂに示すアーキテクチャを利用してアプリケーションサーバから確実なビデオデータを受信することを所望していると仮定する。つまり、サーバ３０３は、ＵＤＰを用いて信頼性なく送信されたデータストリームを、プロキシサーバ３０２を介してクライアント３０１に送信し、これにより、レコードを暗号化した状態でクライアント３０１に確実に送信する。先ず、ステップ６０１において、クライアントとプロキシサーバとが、ＴＣＰ接続を確立する。このステップは、従来のものであり、ＳＯＣＫＳプロトコルに準拠している。ステップ６０２において、クライアントとプロキシサーバとは、従来のＳＳＬ方式に従って、信任情報を交換する（例えば、セキュリティパラメータを取り決める）。本発明のある変形態様において、クライアント３０１とプロキシサーバ３０２とは、上記の原則に従ってＵＤＰデータグラムを暗号化した状態で送信することにも同意する。これは、（新たな）ＴＣＰパケットを送信することにより実現でき、特定のポートを利用して確実なＵＤＰデータグラムを送信することを示している。また、クライアントは、目的のアプリケーションサーバに関するサーバ情報（例えば、ＩＰアドレスやポート）を送信することもできる。なお、ステップ６０１、６０２は、信頼性のあるプロトコルを用いて実行されるものとして説明したが、もちろん、暗号化ステップに必要な情報を何らかの方法でコンピュータ間で共有または通信できる限り、信頼性のないプロトコルを用いて実行することができる。
【００５０】
ステップ６０３において、例えば、ランダム数発生装置を用いて、ノンス／ＩＶを生成する。ステップ６０４において、ノンスを使用して、サーバ３０３から受信されたＵＤＰデータグラムを暗号化し、必要に応じて、図５Ａ、図５Ｂ、および図５Ｃに示すその他のフィールドを生成する。例えば、前のバイトからのプレインテキストを初期化ベクトルとして用いて、暗号テキストの各ブロックを連結ブロック暗号化し、ＭＡＣを従来通り生成することができる。さらに、図５Ａ、図５Ｂ、および図５Ｃに示すように、ノンスをレコードに付加することができる。
【００５１】
ステップ６０５において、改良ＳＳＬ／ＴＬＳ／ＳＯＣＫＳプロトコルに従ってレコードを暗号化したことを示すために、「確実ＵＤＰ」ビットをレコードヘッダに設定する。上述のように、暗号化情報はその他様々な方法で示すことができるので、このビットは任意である。最後に、ステップ６０６において、レコードをプロキシサーバ３０２からクライアント３０１に送信する。ステップ６０７において、レコードをレコード検出器３０１５において受信し、確実ＵＤＰビットが設定されていれば、ステップ６０９において、上記の改良ＳＯＣＫＳ処理に従ってレコードを暗号解読する。そうでなければ、ステップ６０８において、従来のＳＯＣＫＳ処理に従ってレコードを暗号解読する。
【００５２】
以上、ＵＤＰなどの信頼性のないプロトコルを用いて確実にデータを送信するためのシステムおよび方法について説明してきた。本発明は、ビデオ会議、ストリーミングメディア（オーディオ、ビデオ、または、その両方）、ファイルのバルク転送、インタネットを介したコンピュータゲーム（準リアルタイムゲームシステムなど）、インタネットテレフォニ、携帯電話送信、無線ＬＡＮなどのシステムを含む広範なシステムおよびアプリケーションに利用可能である。本質的に複雑でない信頼性のない通信プロトコル（例えば、ＵＤＰ、ＩＰなど）の使用により、データを確実に送信するために必要なオーバヘッドや処理が低減されるので、本発明は、低電力消費や低コンピュータ処理という形で利点を提供する。本発明は、インタネットを介した通信だけでなく、ローカルエリアネットワーク（例えば、イーサネット(登録商標)）、ピアツーピアネットワークなど、その他のコンピュータネットワークにおける用途にも利用可能である。また、本発明の主な用途は、ストリーミングメディアのためにＵＤＰトラフィックと共に用いられるものであるが、非ストリーミングメディアなど、様々なデータタイプを保護するためにも適している。
【００５３】
本発明の実施形態を採用可能なネットワーク構成７０１を図７Ａに示す。図７Ａに示すネットワーク７０１は、多数のクライアントコンピュータ３０１Ａ、３０１Ｂ、３０１Ｃ、３０１Ｄ．．．３０１θと、アプリケーションサーバ３０３にそれぞれ接続された複数のプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φとを備えている。また、各クライアントコンピュータ３０１（３０１Ａ、３０１Ｂ、３０１Ｃ、３０１Ｄ．．．３０１θ）からの接続は、通信媒体７０２を介し、ファイアウォル７０３を介して、負荷バランサ７０４に対して維持され、アプリケーションサーバ３０３への中継のために、通信を各クライアントコンピュータ３０１からプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φの１つにルーティングする。上記のように、サーバ／クライアントコンピュータを、単一演算ユニット上で実施することもできるし、多数の演算ユニット全体に分散することもできる。また、多数のクライアント／サーバ装置を単一の演算装置上で実施してもよい。
【００５４】
理解を容易にするために図７Ａには１つのアプリケーションサーバ３０３しか示されていないが、ネットワーク７０１は、多数のプロキシサーバ３０２（３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φ）と同時通信する多数のアプリケーションサーバ３０３を備えることができる。ネットワーク７０１内の各プロキシサーバ３０２と通信するクライアントコンピュータ３０１の数は、例えば、１００を越えるものとすることができる。同様に、このネットワークは、各アプリケーションサーバ３０３と通信する多数の（１００を越える）プロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φを備えたものとすることができる。通信媒体７０２は、適当な媒体でよい。例えば、クライアントコンピュータ３０１Ａがウェブベースの通信プログラム（例えば、ブラウザ）を利用してプロキシサーバ３０２Ａと通信するように構成されている場合、通信媒体７０２はインタネットであってもよい。また、クライアントコンピュータ３０１Ｄが遠隔ダイヤルアップ通信プログラムを利用してプロキシサーバ３０２Ｂと通信するように構成されている場合、通信媒体７０２は、ダイレクト・プレイン・オールド・テレフォン・システム（ＰＯＴＳ）接続であってもよい。
【００５５】
この例において、クライアントコンピュータ３０１Ａ、３０１Ｂ、３０１Ｃ、３０１Ｄ．．．３０１θは、信頼性のある通信プロトコルのための従来のＳＳＬ／ＴＬＳプロセス、または、上記で詳述した信頼性のない通信プロトコルのための改良ＳＳＬ／ＴＬＳプロセスを利用して、複数のプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φと通信する。下記の説明から明らかなように、ネットワーク構成７０１は、従来のＳＳＬ／ＴＬＳプロセスを利用したセッションに対しても、上記の信頼性のないプロトコルのための改良ＳＳＬ／ＴＬＳプロセスを利用したセッションに対しても、新たなＳＳＬ／ＴＬＳセッションを生成する必要なく、クライアントコンピュータからプロキシサーバへの確実なＳＳＬ／ＴＬＳセッション接続を別のプロキシサーバに切り換えることができる。
【００５６】
ネットワーク７０１内のプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φは、それぞれ、キャッシュメモリ７０５（７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φ）を備えている。本発明によれば、キャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φは、それぞれ、キャッシュ７０６のコピーを収容している。キャッシュ７０６は、多数のクライアントコンピュータ３０１Ａ、３０１Ｂ、３０１Ｃ、３０１Ｄ．．．３０１θと多数のプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φとの間の様々なＳＳＬ／ＴＬＳ通信セッションに基づくＳＳＬ／ＴＬＳセッション情報の集合を含んでいる。例えば、キャッシュ７０６は、クライアントコンピュータ３０１Ａとプロキシサーバ３０２Ａとの間のＳＳＬ／ＴＬＳセッションに対応するＳＳＬ／ＴＬＳセッション情報を収容している。
【００５７】
ＳＳＬ／ＴＬＳセッションのためのＳＳＬ／ＴＬＳセッション情報には、プロキシサーバ３０２が、新たなＳＳＬ／ＴＬＳセッションを生成する必要なく、クライアントコンピュータ３０１とのＳＳＬ／ＴＬＳセッションを再開するために必要な情報の全てが含まれていることが好ましい。例えば、ＳＳＬ／ＴＬＳセッション情報には、プロキシサーバ３０２が、部分ＳＳＬ／ＴＬＳハンドシェイク動作のみでクライアントコンピュータ３０１とのＳＳＬ／ＴＬＳセッションを再開するために必要な情報の全てが含まれている。したがって、ＳＳＬ／ＴＬＳセッション情報には、セッション中に交換されたデータの暗号化／暗号解読のためのセッションキーを生成するために使用されるマスタシークレットキーを含めるべきである。本発明の様々な実施形態において、ＳＳＬ／ＴＬＳセッション情報には、クライアントコンピュータ３０１やクライアントコンピュータ３０１のユーザを認証するために使用されるピア信任情報も含めるべきである。
【００５８】
さらに、ＳＳＬ／ＴＬＳセッション情報には、セッションを識別するためのセッション識別子（例えば、能動または再開可能セッションを識別するためにプロキシアプリケーション９０１が選択した任意のバイトシーケンス）、クライアントコンピュータ３０１およびプロキシアプリケーション９０１が使用するバルクデータ暗号化アルゴリズム（ヌル、ＤＥＳなど）、メッセージ認証チェック（ＭＡＣ）アルゴリズム（ＭＤ５、ＳＨＡなど）、暗号属性（ハッシュサイズなど）を指定する暗号仕様も含まれる。さらに、ＳＳＬ／ＴＬＳ情報には、暗号化の前にデータを圧縮するために用いるアルゴリズム、および新たな接続を開始するためにそのセッションを用いることができるか否かを示すフラグ情報も含まれる。
【００５９】
なお、ここで用いられているＳＳＬ／ＴＬＳセッションという用語は、信頼性のある通信プロトコルのための従来のＳＳＬ／ＴＬＳプロセスおよび上記の信頼性のない通信プロトコルのための改良ＳＳＬ／ＴＬＳプロセスを利用して生成されたセッションの両方を言う。もちろん、プロキシサーバ３０２が、新たなＳＳＬ／ＴＬＳセッションを生成することなく、ＳＳＬ／ＴＬＳセッションを再開するために、元々のセッション生成に使用されていたＳＳＬ／ＴＬＳ手法のタイプに固有の情報をＳＳＬ／ＴＬＳセッション情報に含めてもよい。したがって、ＳＳＬ／ＴＬＳセッションが、上記の信頼性のない通信プロトコルのための改良ＳＳＬ／ＴＬＳプロセスを利用して生成されている場合、セッション中に交換される以降の全てのレコードが改良ＳＳＬ／ＴＬＳプロセスにより処理されることが、クライアントコンピュータ３０１とプロキシサーバ３０２との間で同意されていることを示すデータ（例えば、フラグ）をＳＳＬ／ＴＬＳセッションに含めてもよい。
【００６０】
したがって、各キャッシュ７０６は、多数のクライアントコンピュータ３０１Ａ、３０１Ｂ、３０１Ｃ、３０１Ｄ．．．３０１θと多数のプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φとの間の（従来のＳＳＬ／ＴＬＳプロセスおよび上記の改良ＳＳＬ／ＴＬＳプロセスにより生成された）ＳＳＬ／ＴＬＳセッションの再開に必要な情報を格納している。この様に、キャッシュ７０６は、クライアントコンピュータ３０１Ａとプロキシサーバ３０２Ａとの間のＳＳＬ／ＴＬＳセッションを再開するために必要なＳＳＬ／ＴＬＳ情報を含んでいる。各プロキシサーバ３０２は、対応するキャッシュメモリ７０５にキャッシュ７０６のコピーを有しているので、クライアントコンピュータ３０１とプロキシサーバ３０２Ａとの接続が終了すると、クライアントコンピュータ３０１Ａは、クライアントコンピュータ３０１Ａとプロキシサーバ３０２Ａとの間の前のセッションと同じＳＳＬ／ＴＬＳセッション情報を有するその他の如何なるプロキシサーバ３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φとも新たなセッションを確立することができる。
【００６１】
本発明のある実施形態においては、各キャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φは、キャッシュ７０６の完全なコピーを収容している。各プロキシサーバ３０２は、クライアントコンピュータ３０１との新たなセッションのための新たなＳＳＬ／ＴＬＳセッション情報を得るか、または、クライアントコンピュータ３０１との既存のセッションのための更新されたＳＳＬ／ＴＬＳセッション情報を得るので、プロキシサーバ３０２は、格納のために新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報をキャッシュ７０６の各コピーに送信する。
【００６２】
本発明を実施するネットワーク７０１は、従来のネットワーク構成を超越する利点を提供する。クライアントコンピュータ３０１は、前のセッション中に得られたＳＳＬ／ＴＬＳセッション情報を利用して、プロキシサーバ３０２とのセッションを確立することができるので、負荷バランサ７０４は、クライアントコンピュータ３０１から以前にセッションを確立していたプロキシサーバ３０２に接続をルーティングし直す必要がない。この様に、負荷バランサ７０４の機能が単純化されて、クライアントコンピュータ３０１Ａ、３０１Ｂ、３０１Ｃ、３０１Ｄ．．．３０１θからの入力通信を、利用可能なプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φ間で均一に分散することができる。さらに、プロキシサーバ３０２が全く利用不可能になっても（すなわち、完全に機能不全に陥っても）、クライアントコンピュータ３０１は、別のプロキシサーバ３０２に対して新たなセッションを確立することができ、前のセッションで得られたＳＳＬ／ＴＬＳセッション情報を再生する必要がない。
【００６３】
上記の実施形態は、各キャッシュメモリ７０５にキャッシュ７０６の完全コピーを保持するようになっているが、本発明の他の実施形態では、図７Ｂに示すように各キャッシュメモリ７０５にキャッシュ７０６のほんの一部分のコピーを保持するようになっている。しかし、この様な実施形態では、各プロキシサーバ３０２がＳＳＬ／ＴＬＳセッション情報にアクセスできるように、多数のキャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φの内の他のキャッシュメモリに各セッションのＳＳＬ／ＴＬＳセッション情報を格納しなければならない。例えば、クライアント３０１Ａとプロキシサーバ３０２Ａとの間のセッションのＳＳＬ／ＴＬＳセッション情報を、キャッシュメモリ７０５Ａ（プロキシサーバ３０２Ａに対応）、キャッシュメモリ７０５Ｂ（プロキシサーバ３０２Ｂに対応）、キャッシュメモリ７０５Ｃ（プロキシサーバ３０２Ｃに対応）にのみ格納するようにしてもよい。その後、プロキシサーバ３０２Ａが利用不可能となり、クライアントコンピュータ３０１Ａがプロキシサーバ３０２Ｂとの接続に切り換えられると、プロキシサーバ３０２Ｂは、それ自体のメモリキャッシュ７０６Ｂから検索されたＳＳＬ／ＴＬＳセッション情報を利用してクライアントコンピュータ３０１Ａとのセッションを確立することができる。
【００６４】
さらに、クライアントコンピュータ３０１Ａが、キャッシュメモリ内にＳＳＬ／ＴＬＳセッション情報のないプロキシサーバ（例えば、プロキシサーバ３０２Ｄ）との接続に切り換えられた場合でも、そのプロキシサーバは、キャッシュメモリ７０５に適切なＳＳＬ／ＴＬＳセッション情報を有する別の利用可能なプロキシサーバ３０２（例えば、プロキシサーバ３０２Ｂ）からのＳＳＬ／ＴＬＳセッション情報を要求することができる。例えば、クライアントコンピュータ３０１Ａとの接続が、プロキシサーバ３０２Ｄへと切り換えられると、そのプロキシサーバ３０２Ｄは、ＳＳＬ／ＴＬＳセッション情報を応答受信するまで、その他の利用可能なプロキシサーバ３０２からのＳＳＬ／ＴＬＳセッション情報を順次要求することができる。または、プロキシサーバ３０２Ｄが、その他の利用可能なプロキシサーバ３０２の全てに対して要求を同時に送信し、例えば、最初に受信した応答のＳＳＬ／ＴＬＳセッション情報を採用するようにしてもよい。
【００６５】
本発明の上記の実施形態は、プロキシサーバ３０２のみがキャッシュ７０６の保持に関する責務を負うので、ピア構成型実施形態と呼ばれる。本発明のこの様なピア構成型実施形態において、各キャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φに全キャッシュ７０６のコピー（またはキャッシュ７０６の重複する部分コピー）を保持するには、各プロキシサーバ３０２が、書込プロセスにおいて新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報を多数のキャッシュメモリ７０５に送信しなければならない。好ましくは、受信側装置からの肯定確認を必要とする信頼性のある通信手法を利用してこの書込プロセスを実行するので、各プロキシサーバ３０２は、その関連のキャッシュメモリ７０５が新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報を処理したことを確認できる。ネットワーク内のプロキシサーバ３０２の数が比較的少なく、プロキシサーバ３０２によりセーブされるＳＳＬ／ＴＬＳセッション情報のタイプおよび量が比較的安定しており、キャッシュ７０６内のＳＳＬ／ＴＬＳセッション情報の総量が比較的少ない場合、信頼性のある肯定確認ベースの通信手法を利用するこの構成において、各キャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φに必要なＳＳＬ／ＴＬＳセッション情報を書き込むことは、ネットワーク７０１に対する大きなリソースオーバーヘッドとはならない。例えば、ネットワーク７０１が９個のプロキシサーバ３０２しか備えていない場合、各プロキシサーバ３０２に対する新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報の書き込みにより、ネットワークリソースが多大に浪費されることはない。
【００６６】
一方、キャッシュ７０６に格納されたＳＳＬ／ＴＬＳセッション情報のタイプを頻繁に更新しなければならない場合、または、ネットワークが多数のプロキシサーバ３０２（例えば、９個を越えるプロキシサーバ）を備えている場合には、信頼性のある肯定確認ベースの通信手法を利用したネットワーク内の各プロキシサーバ３０２に対する新ＳＳＬ／ＴＬＳセッション情報もしくは更新ＳＳＬ／ＴＬＳセッション情報の書き込みには、ネットワーク７０１からかなりのリソースが流用される。例えば、クライアントコンピュータ３０１の数が増加すると、各クライアントコンピュータ３０１のための多数のキャッシュメモリ７０５に対する低頻度の更新にも、ネットワーク７０１からかなりのリソースが流用される。同様に、プロキシサーバ３０２の数が増加すると、信頼性のある肯定確認ベースの通信手法を利用した各プロキシサーバ３０２のキャッシュメモリに対する新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報の書き込みにも、ネットワーク７０１からかなりのリソースが流用される。さらに、キャッシュ７０６があまりにも大きくなると、プロキシサーバ３０２のキャッシュメモリ７０５にキャッシュの完全コピーを格納することが困難になる。
【００６７】
これに対応して、本発明の更に別の実施形態を実施するネットワーク８０１を図８Ａに示す。前述のネットワーク構成７０１と同様に、ネットワーク８０１は、複数のクライアントコンピュータ３０１Ａ、３０１Ｂ、３０１Ｃ、３０１Ｄ．．．３０１θと、アプリケーションサーバ３０３にそれぞれ接続される複数のプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φとを備えている。前述の通り、各クライアントコンピュータ３０１は、通信媒体７０２およびファイアウォル７０３を介して負荷バランサ７０４に接続されている。負荷バランサ７０４は、各クライアントコンピュータ３０１からプロキシサーバ３０２の１つへと（例えば、図示のようにクライアントコンピュータ３０１Ａからプロキシサーバ３０２Ａへと）接続をルーティングする。図７Ａおよび図７Ｂに示すネットワーク７０１と同様に、ネットワーク８０１内のプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φも、それぞれ対応するキャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φを備えている。
【００６８】
しかし、本発明のこの実施形態は、キャッシュ７０６の１以上のコピーを格納するためのキャッシュ格納庫８０２を更に備えている。以下の説明から理解されるように、この実施形態は、本発明の前述の実施形態のようなピア構成ではなく、キャッシュ７０６の格納に関して２階層構成となっている。すなわち、この実施形態は、プロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φのキャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φにより提供される第１の階層のＳＳＬ／ＴＬＳセッション情報記憶装置と、キャッシュ格納庫８０２により提供される第２の階層のＳＳＬ／ＴＬＳセッション情報記憶装置とを備えている。
【００６９】
図８Ａに示すように、キャッシュ格納庫８０２は、２つのキャッシュメモリサーバ装置８０３、８０４を備えている。これらのキャッシュメモリサーバ装置８０３、８０４は、それぞれ、キャッシュ７０６の完全コピーを格納する。しかし、キャッシュ格納庫８０２は、冗長性のために２つのキャッシュメモリサーバ装置８０３、８０４を備えている。したがって、キャッシュメモリサーバ装置８０３、８０４の一方が機能しなくなったり、利用不可能となった場合でも、キャッシュ格納庫８０２は、他方のキャッシュメモリサーバ装置内にキャッシュ７０６の完全コピーを備えている。また、本発明の他の実施形態において、冗長性が所望でない場合には格納庫８０２として単一のキャッシュメモリサーバ装置を使用してもよいし、冗長性を優先する場合には３個以上のキャッシュメモリサーバ装置を使用してもよい。
【００７０】
図８Ａの実施形態におけるキャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φは、全キャッシュ７０６のコピーを格納しないこともある。その代わりに、キャッシュ７０６がキャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φの記憶容量よりも大きな場合には、各キャッシュメモリ７０５は、対応するプロキシサーバ３０２に関連するキャッシュ７０６の一部分のみを格納する。例えば、キャッシュメモリ７０５Ａにコピーされたキャッシュ７０６の一部分に、プロキシサーバ装置３０２Ａ、３０２Ｂに対して確立されたセッションのＳＳＬ／ＴＬＳセッション情報のみが含まれるようにしてもよい。したがって、クライアントコンピュータ３０１Ａが、プロキシサーバ３０２Ａとの接続を失い、プロキシサーバ３０２Ｂとの新たなセッションを確立しようとする場合、キャッシュメモリ７０５Ｂは、プロキシサーバ３０２Ａとの前のセッションに関するＳＳＬ／ＴＬＳセッション情報を保持していないこともある。
【００７１】
しかし、この実施形態では、プロキシサーバ３０２が、そのメモリキャッシュ７０５にＳＳＬ／ＴＬＳセッション情報のないクライアントコンピュータ３０１とのセッションを確立する要求を受信すると、プロキシサーバ３０２は、キャッシュ格納庫８０２から関連ＳＳＬ／ＴＬＳセッション情報を得ることができる。したがって、上記の例において、プロキシサーバ３０２Ｂは、クライアントコンピュータ３０１Ａの前のセッションに関するＳＳＬ／ＴＬＳセッション情報をキャッシュ格納庫８０２から得る。そして、新たなプロキシサーバ３０２は、そのＳＳＬ／ＴＬＳセッション情報を使用して、前のセッションと同一のＳＳＬ／ＴＬＳセッション情報で新たなセッションを確立することができる。
【００７２】
キャッシュ７０６のサイズが大きすぎて、キャッシュ７０６の全コピーをプロキシサーバ３０２のキャッシュメモリ７０５に効率よく格納することができない場合に有用であることに加えて、キャッシュ格納庫８０２を採用する本発明のこの実施形態は、通常、非常に多くのプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φを備えたネットワーク（キャッシュ７０６に格納されたＳＳＬ／ＴＬＳセッション情報が、キャッシュ７０６を頻繁に更新する必要のあるタイプであるか否かにもよるが、例えば、１０を越えるプロキシサーバを備えたネットワーク）にとって更に効率がよい。この実施形態において、各プロキシサーバ３０２は、通常、新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報をキャッシュ格納庫８０２にのみ書き込むために信頼性のある肯定確認通信手法を利用する必要があり、（書込動作およびその確認により発生する）通信トラフィック量がネットワーク全体で減少する。そして、ネットワーク内の他のプロキシサーバ３０２は、後述のように、信頼性の低い通信手法により、または、キャッシュ格納庫８０２から直接的に、新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報を得ることができる。
【００７３】
なお、図８Ａに示す２階層構成は例示である。当業者にとっては、キャッシュ７０６の全体サイズにより、３階層、４階層などマルチ階層構成も採用可能であることが理解できるであろう。例えば、キャッシュ７０６のサイズがあまりにも大きく、単一のキャッシュメモリサーバ装置８０３、８０４に効率よく格納できない場合は、キャッシュ７０６の異なる部分を格納する２以上のキャッシュ格納庫８０２を採用することができる。キャッシュ７０６の全コピーを、各キャッシュ格納庫８０２にアクセス可能な比較的効率の悪い記憶装置（例えば、一連の磁気ディスク記憶装置）に格納してもよい。また、各プロキシサーバ３０２を特定のキャッシュ格納庫８０２と関連付けて、関連するキャッシュ格納庫８０２に保持されているキャッシュ７０６の全部または一部を格納するようにしてもよい。当業者にとっては、その他、様々な実施形態が明らかであろう。以下、「マルチ階層」という用語を使用して、少なくともキャッシュ７０６の一部分を格納する２階層以上の階層レベルの装置を備えた本発明の実施形態に言及する。
【００７４】
なお、本発明の更なる実施形態において、キャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φに格納されているキャッシュ７０６Ａ、７０６Ｂ、７０６Ｃ、７０６Ｄ．．．７０６φの異なる部分が、重複していてもよい。例えば、キャッシュ７０５Ａの一部分は、キャッシュ７０５Ｂの一部分およびキャッシュ７０５Ｃの一部分にも格納されているＳＳＬ／ＴＬＳセッション情報を収容していてもよい。プロキシサーバ３０２は、接続を求めている新たなクライアントコンピュータ３０１のためのＳＳＬ／ＴＬＳセッション情報を既に有していることもあるので、キャッシュ７０６の異なる部分である程度の重複があることにより、ネットワークトラフィック量が減少する。さらに、図８Ｂに示すように、各キャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φは、キャッシュ７０６全体のコピーを収容していてもよい。本発明のこの実施形態は、例えば、キャッシュ７０６のサイズが充分小さく、キャッシュメモリ７０５にその全体を格納できる場合、図８Ａに示す実施形態にとって好適である。
【００７５】
次に、プロキシサーバ３０２の考え得る実施形態について、図９を参照しながら説明する。図示のように、プロキシサーバ３０２は、プロキシアプリケーション９０１と、分散キャッシュアプリケーション・プログラミング・インタフェース（ＡＰＩ）９０２と、分散キャッシュアプリケーション９０３と、通信機アプリケーション９０４と、キャッシュメモリ７０５とを備えている。以下に詳述するように、プロキシアプリケーション９０１は、プロキシサーバ３０２の主要な機能を実行し、レコード検出器３０２１と、従来のＳＯＣＫＳ処理機能３０２２と、改良ＳＯＣＫＳ処理機能３０２３と、プロキシ機能３０２４とを備えている。すなわち、プロキシアプリケーション９０１は、クライアントコンピュータ３０１との確実な通信を確立し、クライアントコンピュータ３０１とアプリケーションサーバ３０３との間でメッセージを中継する。また、プロキシアプリケーション９０１は、クライアントコンピュータ３０１とのセッションのＳＳＬ／ＴＬＳセッション情報を、分散キャッシュＡＰＩ９０２を介して分散キャッシュアプリケーション９０３に送信する。
【００７６】
分散キャッシュＡＰＩ９０２は、キャッシュメモリ７０５から情報を検索し、分散キャッシュアプリケーション９０３を介して情報を送信することによって、キャッシュメモリ７０５への情報送信の要求やキャッシュメモリ７０５からの情報削除の要求を円滑にする。分散キャッシュアプリケーション９０３は、キャッシュメモリ７０５に情報を格納し、キャッシュメモリ７０５と他のプロキシサーバ３０２（適用可能であれば、キャッシュ格納庫８０２）との情報の交換も制御する。分散キャッシュアプリケーション９０３は、通信機アプリケーション９０４を介して、他のプロキシサーバ３０２（適用可能であれば、キャッシュ格納庫８０２）と通信する。
【００７７】
したがって、完全ＳＳＬ／ＴＬＳハンドシェイクが完了した後、プロキシアプリケーション９０１は、格納のため、完全ＳＳＬ／ＴＬＳハンドシェイクから得たＳＳＬ／ＴＬＳセッション情報をキャッシュメモリ７０５に送信する。
特に、プロキシアプリケーション９０１は、ＳＳＬ／ＴＬＳ再開情報を有するデータフィールド、およびＳＳＬ／ＴＬＳセッション識別子を有するキーフィールドを含むキャッシュ７０６に格納するレコードを生成する。レコードには、そのレコードが失効してキャッシュから削除されるべき時点を有する有効期限フィールドも含まれる。さらに、後述のように、キー情報（すなわち、セッション識別子）に付加されるレコード識別子もレコードに含まれる。プロキシアプリケーション９０１は、キャッシュメモリ７０５に格納するために、分散キャッシュＡＰＩ９０２を介して分散キャッシュアプリケーション９０３にこのレコードを送る。
【００７８】
プロキシアプリケーション９０１がクライアントコンピュータ３０１からの要求を受信してセッションを開始するとき、そのクライアントコンピュータ３０１がプロキシアプリケーション９０１（その要求を現在受信している同一のプロキシアプリケーション９０１または別のプロキシアプリケーション９０１）とのＳＳＬ／ＴＬＳ通信を既に確立していれば、その要求にはＳＳＬ／ＴＬＳセッション識別子が含まれている。プロキシアプリケーション９０１は、サーチキーとしてＳＳＬ／ＴＬＳセッション識別子をキャッシュＡＰＩ９０２上に送るので、ＡＰＩ９０２は、分散キャッシュアプリケーション９０３に対して、ＳＳＬ／ＴＬＳセッション識別子に対応するキャッシュメモリ７０５からＳＳＬ／ＴＬＳ情報を検索するように要求する。
【００７９】
前述のように、分散キャッシュＡＰＩ９０２の機能は、ＧＥＴ演算を用いてキャッシュメモリ７０５から既存のレコードを検索するものである。さらに、本発明のある実施形態では、分散キャッシュＡＰＩ９０２は、この様なコマンドを分散キャッシュアプリケーション９０３上に送ることによって、レコードを追加、削除、または修正するための要求を円滑にする。この様にして、分散キャッシュアプリケーション９０３は、キャッシュメモリ７０５上でＡＤＤ、ＤＥＬＥＴＥ、およびＵＰＤＡＴＥ演算を実行する。好ましくは、そのキーに関するレコードがキャッシュメモリ７０５に既に存在するものであっても、ＡＤＤ演算は、そのレコードのキーフィールド内の情報に基づいてレコードをキャッシュメモリ７０５に追加する。ＤＥＬＥＴＥ演算は、キャッシュメモリ７０５からレコードを削除し、ＵＰＤＡＴＥ演算は、キャッシュメモリ７０５に既に存在するレコードを更新する。また、分散キャッシュアプリケーション９０３は、各キャッシュメモリ７０５Ａ、７０５Ｂ、７０５Ｃ、７０５Ｄ．．．７０５φのパージを強制する機能も有する。
【００８０】
なお、キャッシュＡＰＩ９０２は、まず、キャッシュ７０６のローカルコピー（またはキャッシュ７０６の一部分のコピー）からの要求レコードをキャッシュメモリ７０５から得ることによって、ＧＥＴ演算の完了を試みる。本発明のある好適な実施形態においては、各キャッシュメモリ７０５はキャッシュ７０６の完全コピーを格納しているので、この要求は直ちに成功する。しかし、要求レコードがローカルキャッシュメモリ７０５内に見つからない場合（例えば、キャッシュメモリ７０５に、要求レコードを含まないキャッシュ７０６の一部分、または、崩壊したキャッシュ７０６のコピーしか含まれていない場合）、キャッシュＡＰＩ９０２は、別のソースからレコードを得るために、分散キャッシュアプリケーション９０３に関わりを持つ。図７Ａおよび図７Ｂに示す本発明のピア構成の実施形態において、分散キャッシュアプリケーション９０３は、その他のプロキシサーバ３０２の１以上から要求レコードを検索しようとする。しかし、図８Ａおよび図８Ｂに示す本発明のマルチ階層構成の実施形態においては、分散キャッシュアプリケーション９０３は、キャッシュ格納庫８０２から要求レコードを検索しようとする。
【００８１】
同様に、分散キャッシュアプリケーション９０３がそのローカルキャッシュ７０５からのレコードを追加、更新、または削除するときは、対応する追加、更新、または削除コマンドをネットワーク内の他の装置に中継する。例えば、図７Ａおよび図７Ｂに示す本発明のピア構成の実施形態において、分散キャッシュアプリケーション９０３は、その他のプロキシサーバ３０２のそれぞれにコマンドを中継する。しかし、図８Ａおよび図８Ｂに示す本発明のマルチ階層構成の実施形態においては、分散キャッシュアプリケーション９０３は、キャッシュ格納庫８０２にコマンドを中継する。そして、キャッシュ格納庫８０２は、その他のプロキシサーバ３０２の１以上にコマンドを中継する。この様に、あるプロキシサーバ３０２のプロキシアプリケーション９０１が得た新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報は、クライアントコンピュータ３０１との以降のセッションに使用するために、その他のプロキシサーバ３０２に送信される。
【００８２】
次に、分散キャッシュアプリケーション９０３によるキャッシュ７０６へのＳＳＬ／ＴＬＳセッション情報の格納について説明する。当業者に理解されるように、プロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φの数の増加に伴い、クライアントコンピュータとプロキシサーバ３０２Ａ、３０２Ｂ、３０２Ｃ、３０２Ｄ．．．３０２φとの間で可能なセッションの数も増加する。したがって、キャッシュに格納されるＳＳＬ／ＴＬＳセッション情報量も増加する。これは、図７Ａおよび図７Ｂに代表されるピア分散キャッシュの実施形態にも、図８Ａおよび図８Ｂに代表されるマルチ階層分散キャッシュの実施形態にも当てはまる。したがって、ＳＳＬ／ＴＬＳセッション情報は、必要なときに迅速かつ効率よく検索可能なようにキャッシュ７０６に格納されなければならない。したがって、本発明のある好適な実施形態においては、キャッシュ７０６を実施するためにハッシュテーブルを用い、ＳＳＬ／ＴＬＳセッション情報を格納してハッシュテーブルから検索するためにハッシュ機能を利用する。
【００８３】
上記のごとく当業で公知のように、各ＳＳＬ／ＴＬＳセッション情報は、レコードの一部としてキャッシュ７０６に格納される。ハッシュテーブルにレコードを入力する場合、分散キャッシュアプリケーション９０３は、キーデータを数値にマップするために、キーフィールド（例えば、ＳＳＬ／ＴＬＳセッション識別子）内のキーデータに対して算術アルゴリズムまたは「ハッシュ」演算を実行する。そして、キーデータにより識別されたＳＳＬ／ＴＬＳセッション情報は、キーデータがハッシュ演算によりマップされた数値に対応する位置（「バケット」ともいう）においてハッシュテーブルに格納される。
【００８４】
なお、異なるキー値を同じハッシュ値にハッシュしてもよい。この様に、異なるレコードをハッシュ値の同じ位置またはバケットに格納してもよい。したがって、ハッシュ演算は、可能なキーデータ値の全範囲に対してハッシュ値の均一な分布が得られるように選択されることが好ましい。これにより、ハッシュテーブル内の特定の位置にレコードが数量的に不均衡に格納されることはない。すなわち、ハッシュテーブル内にレコードを均一に分布させるハッシュ演算を採用することが好ましい。この様に、レコードを検索する際に、ハッシュテーブル内の如何なる位置からのレコード検索の平均時間も、ハッシュテーブル内の他の位置からのものと僅差または同一にしなければならい。
【００８５】
本発明のある好適な実施形態によれば、ＳＳＬ／ＴＬＳセッション情報レコードをキャッシュ７０６内に均一に分布させるために、「ＢＵＺｈａｓｈ」ハッシュアルゴリズムが採用される。このハッシュアルゴリズムは、本発明にその全体が引用により組み込まれている、ロバート・ウズガリス（Robert Uzgalis）による「ハッシュ概念およびＪａｖａプログラミング言語（Hashing Concepts and the Java Programming Language）」(Ｊａｖａは登録商標)(C)１９９６に記載されている。この著書に記載されているとおり、ＢＵＺｈａｓｈアルゴリズムは、従来、Ｓｋｅｔｃｈｙアルゴリズム言語を用いて以下のように演算する。
【００８６】
【００８７】
ウズガリスの著書に記載されているように、ＢＵＺｈａｓｈアルゴリズムは、２進キー値に適用される場合、任意のキー値からランダム数を生成したり、テーブル内で可能な範囲のキー値を均一に分布させたりする際に特に有効である。しかし、当業者に理解されるように、ＳＳＬ／ＴＬＳセッション情報をキャッシュ７０６に格納するために、当業で公知のその他のハッシュアルゴリズムを利用してもよい。また、ＳＳＬ／ＴＬＳセッション情報をキャッシュ７０６に格納するために使用可能な新たなハッシュアルゴリズムを開発してもよいことも明白である。
【００８８】
なお、分散キャッシュアプリケーション９０３は、全てのキー値を非透過的に（オペークに）処理して、全てのキー値を一意的なものと仮定して演算する。すなわち、一意的なキーは、キャッシュ７０６内の単一のレコードのみを識別することができる。既存のレコードと同一のキーデータを用いて別のレコードをキャッシュ７０６に追加すると、一方のレコードのみが生き残る。しかし、同一キーデータを用いて異なるレコードを参照するようにすることが望ましい。例えば、前述のように、ＳＳＬ／ＴＬＳセッション識別子をキーデータとして用いて、レコードをＳＳＬ／ＴＬＳ再開情報と同定するようにしてもよい。また、クライアントコンピュータ３０１のユーザのための認証情報（例えば、クライアントコンピュータのユーザがアプリケーションサーバ３０３からアクセスできるデータを決定するために使用される認証情報）を有するレコードなど、別のレコードを識別するために、ＳＳＬ／ＴＬＳセッション識別子を用いることが望ましい。
【００８９】
したがって、本発明の様々な実施形態において、キャッシュＡＰＩ９０２は、同一のキーデータを共有する２つの異なるレコードを区別するテーブル識別子を使用することができる。本発明のこれら様々な実施形態において、プロキシアプリケーション９０１は、キーデータの指定に関わるキャッシュＡＰＩ９０２を介した全コールの一部として、キーデータに付加されたテーブル識別値を指定する。事実、これにより、プロキシアプリケーション９０１は、特定キーにより識別されたレコードの書き込みと読み出しとを行うべき仮想テーブルを特定することができる。もちろん、当業者に理解されるように、上記のようにキャッシュ７０６の全レコードを単一のハッシュテーブルに格納するので、これはロジック構成にすぎない。
【００９０】
好ましくは、プロキシアプリケーション９０１は、各テーブル識別値が適切に生成されて一貫して適用されるように保証する責務を負う。プロキシアプリケーション９０１は、キーに対してテーブル識別子を付加し、そのキーをキャッシュＡＰＩ９０２に送る。または、バッファ割当演算やコピー演算を省略するために、プロキシアプリケーション９０１はキャッシュＡＰＩ９０２にテーブル識別子を送り、キャッシュＡＰＩ９０２はテーブル識別子を付加する。キャッシュＡＰＩ９０２は、キーデータの一部としてテーブル識別子を処理するので、プロキシアプリケーション９０１は、この値のサイズを可能な限り縮小することが好ましい。テーブル識別子のサイズの縮小により、最適なメモリ使用と最適なハッシュ性能とが可能となる。
【００９１】
キャッシュメモリ７０５は、如何なるタイプのメモリ媒体であってもよい。しかし、当業者に理解されるように、キャッシュメモリ７０５は、ＲＡＭまたはメインメモリと一般的に呼ばれている読出可能／書換可能半導体メモリ装置として実施することが好ましく、この様なタイプのメモリ装置は、迅速な情報格納および検索が可能である。現在、サーバ装置として従来使用されているコンピュータは、２ギガバイトから４ギガバイトの情報を格納できるこの様なメモリを備えている。したがって、各プロキシサーバ３０２用のこのタイプのメモリ装置に２００万〜４００万キロバイト程度のレコードを格納することができる。もちろん、磁気媒体や光媒体などの他のタイプのメモリ媒体を代替として利用することもできる。
【００９２】
本発明のある実施形態によれば、通信機アプリケーション９０４は、ネットワーク内の装置間において、ユニキャストやＴＣＰ／ＩＰのような通信など（受信確認ベースの）ポイント間通信が可能である。このタイプの通信は、例えば、新たに開始されたキャッシュメモリ７０５と既存のキャッシュメモリ７０５との間でＳＳＬ／ＴＬＳセッション情報を同期させたり、ＳＳＬ／ＴＬＳセッション情報の全てが、対応するプロキシアプリケーション９０１により使用される前に、新たなキャッシュメモリ７０５に正確にコピーされることを保証するのに有用である。
【００９３】
通信機アプリケーション９０４により提供されるこのタイプのポイント間通信（例えば、ユニキャストまたはＴＣＰ／ＩＰのような通信）は、また、他のプロキシサーバ３０２のキャッシュメモリ７０５内の個々のレコードの更新や追加のために、分散キャッシュアプリケーション９０３により使用される。しかし、上述のように、図７Ａおよび図７Ｂに示す本発明の実施形態においては、プロキシサーバ３０２の数の増大に伴って、各キャッシュメモリ７０５にＳＳＬ／ＴＬＳセッション情報を書き込むためのネットワークリソースに対するオーバヘッドが増大する。これは、各プロキシサーバ３０２が、別個の書込プロセスを用いて各キャッシュメモリ７０５に新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報を書き込み、各キャッシュメモリ７０５から書込コマンド受領確認を応答受信しなければならないからであり、ネットワーク７０１内の各プロキシサーバ３０２にとっては、多大なネットワークトラフィック量および処理時間を要する。より具体的には、通信を受信する装置（例えば、プロキシサーバ３０２）の数をＮとすると、各通信で送信すべきデータパケット数は２Ｎとなる。
【００９４】
したがって、例えば、ポイント間メッセージ送信を用いて、通信機アプリケーション９０４からのメッセージをネットワーク内の適切な各受信側装置に個々に配信できる一方で、このタイプの通信は、本発明の有効性および速度を制約する。それに対応して、本発明のある好適な実施形態においては、通信機アプリケーション９０４は、信頼性のあるマルチキャスト通信も提供する。当業で公知のように、通信手法は、（ａ）この手法により送信されるデータパケットが正確に配列され、重複を受信側で廃棄可能な場合や、（ｂ）この手法により、受信側が送信中のデータパケットの喪失時点を検出できる場合、（ｃ）この手法により、送信中に喪失したデータパケットを得るために受信側に修復機構が提供されている場合に、信頼性があると判断される。当業で周知のように、マルチキャストは、異なるネットワーク装置が単一のネットワークアドレスに送信されたメッセージを受信する手順である。
【００９５】
したがって、通信機アプリケーション９０４は、ネットワーク内の適切な装置に対してＳＳＬ／ＴＬＳセッション情報の追加、更新、または削除を行うために、信頼性のあるマルチキャスト送信を利用してもよい。信頼性のあるマルチキャストを利用することによって、本発明のこれらの実施形態において、ＳＳＬ／ＴＬＳセッション情報を単一の共有マルチキャストアドレスに送信するだけで、同時に多数の異なる装置にＳＳＬ／ＴＬＳセッション情報を良好に送信する。前述のように、マルチキャストプロセスは当業で周知であり、マルチキャスト通信を円滑にするために、マルチキャスト・トランスファ・プロトコル（ＭＴＰ）など幾つかのマルチキャストプロトコルが確立されている。
【００９６】
信頼性のあるマルチキャスト通信手法の１タイプとして、肯定アプリケーション確認を有するマルチキャスト通信がある。この手法によると、マルチキャスト送信を受信するアプリケーションは、送信されたデータを成功裏に処理した後、マルチキャスト送信を発信した装置に対して確認を送り返す。このタイプの信頼性のあるマルチキャスト通信は、ピア構成の実施形態においては、他のキャッシュメモリ７０５（マルチ階層構造の実施形態においてはキャッシュ格納庫８０２）にＳＳＬ／ＴＬＳセッション情報を追加するために、分散キャッシュアプリケーション９０３からのＡＤＤコマンドを中継する場合に、通信機アプリケーション９０４により採用されることが好ましい。ピア構成の実施形態においては、通信を受信する装置（例えば、プロキシサーバ３０２）の数をＮとすると、信頼性のある肯定確認マルチキャスト通信手法を使用することによって、各通信のためにネットワーク全体に送信すべきデータパケットの数が１＋Ｎに低減される。すなわち、１つの通信がＮ個の装置のそれぞれにマルチキャストされ、Ｎ個の肯定確認が発信側装置に送り返される。
【００９７】
信頼性のある肯定確認マルチキャストによって、多数の装置が、同時に更新ＳＳＬ／ＴＬＳセッション情報または新ＳＳＬ／ＴＬＳセッション情報を確実に受信することができる一方で、ピア構成での実施のためにはかなりのネットワークリソースが必要となる。マルチキャストメッセージを受信する各装置は、メッセージの発信元のネットワーク装置に対して通信受信確認を個別に行う必要があるので、多数のプロキシサーバ３０２を有するネットワークにおいては（すなわち、Ｎが大きな場合には）、信頼性のある肯定確認マルチキャストを利用した各プロキシサーバ３０２へのＳＳＬ／ＴＬＳセッション情報送信は、ネットワークの性能を著しく劣化させる。
【００９８】
しかし、本発明の様々な用途において、上記のマルチ階層構成の実施形態は、ネットワークリソースの使用を更に低減することができる。この様な実施形態において、新状態情報や更新状態情報は、信頼性のある肯定確認ベースの通信手法を利用して、キャッシュ格納庫８０２にのみ送信すればよい。すると、プロキシサーバ３０２は、信頼性の低い（ネットワークリソースに関しては安価な）通信手法を利用して新状態情報や更新状態情報を得たり、必要な場合にはキャッシュ格納庫８０２から新状態情報や更新状態情報を得ることができる。この様にマルチ階層構成を利用することによって、新状態情報や更新状態情報を受信するキャッシュ格納庫８０２の数をｎとした場合、新状態情報や更新状態情報を追加する度にネットワーク全体に送信すべきパケットの数を更に１＋ｎへと低減することができる。本発明においては、通常、キャッシュ格納庫８０２の数ｎはプロキシサーバ３０２の数Ｎよりもはるかに小さいので、マルチ階層構成の利用により、新状態情報や更新状態情報のキャッシュに必要なネットワークリソースの使用を、個々のリソースのネットワークトラフィックおよび処理時間に関して、大幅に低減することができる。
【００９９】
本発明のマルチ階層構成の実施形態において、プロキシサーバ３０２は、信頼性のあるマルチキャスト通信を提供するために、上記の肯定確認手法の代わりに、例えば、否定確認（ＮＡＣＫ）手法を利用して、新状態情報または更新状態情報を受信してもよい。否定確認マルチキャスト手順によれば、マルチキャストメッセージを受信する装置は、メッセージを受信しても発信元装置に確認を送信しない。その代わり、各受信側装置は、マルチキャスト通信の一部分を喪失したと決定したときのみ、発信元装置に応答する。
【０１００】
例えば、通信プロトコルの中には、通信の各データセグメントに連続番号を付与する必要があるものもある。否定確認手順によれば、この様なプロトコルにより通信を受信する装置は、データセグメントの１つが受信されていないことを認識した時（すなわち、連番のデータセグメントの喪失を決定した時）のみ、発信元装置に応答する。したがって、本発明の様々な実施形態によれば、通信機アプリケーション９０４は、この手法を用いて、ネットワーク内の別の装置からのデータが受信されていないことを認識した時に、その装置に否定確認を与える。
【０１０１】
この様に、本発明のマルチ階層構成の実施形態において、否定確認型の信頼性のあるマルチキャスト構成を利用して、新ＳＳＬ／ＴＬＳセッション情報または更新ＳＳＬ／ＴＬＳセッション情報を各プロキシサーバ３０２に配信することができ、装置間の通信トラフィック量を低減することができる。もちろん、関連する受信側装置の全てにおいて、単一のマルチキャスト送信を利用して、肯定確認マルチキャスト通信および否定確認マルチキャスト通信を達成可能である。送信側の装置は、別のマルチキャスト送信の前に、肯定確認手法を利用して通信するように指定された全ての装置からの肯定確認を受信するまで待機する。そして、送信側装置は、適切な否定確認マルチキャスト通信プロトコルにより受信した否定確認にも応答する。
【０１０２】
しかし、従来の否定確認型の信頼性のあるマルチキャスト通信手法には、「オーバーラン」とも呼ばれる更なる問題がある。この状況下、送信側装置は、１以上の受信側装置の処理能力よりも速くデータを送信するので、送信されたデータの一部が失われる結果となる。さらに、送信側装置は、あまりにも大量の情報を送信するので、他の装置から否定確認を受信することができず、これは、通信の一部が失われるということを意味する。しかし、この問題の程度は、ネットワーク全体の通信トラフィックフロー速度に依存する。ただし、ネットワークの通信トラフィックがほとんどない場合、マルチキャスト通信を発信した装置は、受信装置をオーバーランさせることなく、否定確認を失うことなく、高速で情報を送信することができる。同様に、ネットワークの通信トラフィックが多くなると、マルチキャスト通信を発信した装置は、受信装置のオーバーランや否定確認の喪失を回避するために、より低速でデータを送信しなければならない。
【０１０３】
この問題を解決するために、先行技術の否定確認マルチキャストシステムは、マルチキャスト通信においてデータを送信する速度に絶対的な制限を設定し、あらゆる状況下で他の装置からの否定確認を受信できるように保証することを提案している。しかし、この先行技術の定速による解決策は、ネットワーク全体において変化する通信トラフィックフローを考慮していない。その代わり、全ての否定確認の受信を保証するために、可能な限り低効率で動作する。その他、「マスタ」や「トークン」構成の決定論的な手法を利用する先行技術のシステムもあるが、この様なシステムは、比較的低速かつ非効率的であり、複雑である。
【０１０４】
それに対応して、本発明のある好適な実施形態において、通信機アプリケーション９０４は、ネットワーク全体の通信トラフィックフローを決定するためのトラフィックフロー速度検出プロセスと共に、否定確認型の信頼性のあるマルチキャスト通信を提供する。ネットワーク全体の通信トラフィックフローを正確に検出することによって、通信機アプリケーション９０４は、信頼性のある否定確認マルチキャスト通信におけるデータ送信速度を相応に上げたり下げたりすることができる。以下、このフロー速度検出プロセスについて、図１０Ａおよび図１０Ｂを参照しながら説明する。
【０１０５】
図示のように、通信機アプリケーション９０４は、データインタフェース部１００１を有する。インタフェース１００１は、ネットワーク内の他の装置にマルチキャストされるデータセグメント１００３を収容する出力キュー１００２を備えている。インタフェース１００１は、他の装置からマルチキャスト通信により受信されたデータセグメント１００５を収容する入力キュー１００４を更に有する。本発明のこの様な好適な実施形態によれば、通信機アプリケーション９０４は、それ自体のマルチキャスト送信の受信者でもある。したがって、通信機アプリケーション９０４は、ネットワーク内のその他の装置へ送信したデータセグメントを受信する。最新の送信データパケットが通信機アプリケーション９０４で受信された時点を決定することによって、通信機アプリケーション９０４は、ネットワーク内のトラフィックフローレベルを決定することができる。例えば、本発明のある好適な実施形態において、通信機アプリケーション９０４は、以前に送信されたデータセグメントをその入力キュー１００４に受信するまで、出力キュー１００２からの別のデータセグメントの出力を控える。
【０１０６】
当業者に理解されるように、このフロー速度検出手法に対して数々の変形態様が可能である。例えば、通信機アプリケーション９０４は、直前の送信データセグメント（例えば、データ１）を入力キュー１００４（図１０Ｂ参照）に受信するまで、新たなデータセグメント（例えば、図１０Ａおよび図１０Ｂに示すデータ２）の送信を延期する。または、通信機アプリケーション９０４は、ネットワーク全体のトラフィックの現在のフロー状況を確認するために、それ自体の送信データセグメント間に発生する入力キュー１００４内のデータセグメントの平均数を決定する。ネットワーク全体のトラフィックのフロー状況の決定のために、自己送信データセグメントの受信を利用して、その他数々の改良態様が可能である。さらに、この手法は、マルチキャストされない通信にも採用可能である。例えば、通信機アプリケーション９０４は、ポイント間メッセージのコピーをフィードバックループ上でそれ自体に送信することができる。通信機アプリケーション９０４は、ネットワーク上でトラフィック量を決定するために、通信機アプリケーション９０４がそれ自体に送信したメッセージが入力キュー１００４内に現れることを利用する。
【０１０７】
また、前述のように、肯定確認マルチキャスト通信手法および否定確認マルチキャスト通信手法を利用してメッセージを配信するために、同じマルチキャスト送信を使用することができる。なお、否定確認マルチキャスト通信手法をフロー検出と共に利用した場合、否定確認マルチキャスト手法と共に用いたフロー制御機能により、肯定確認マルチキャスト手法の動作を制御する。つまり、送信側装置は、肯定確認マルチキャスト通信手法で通信する装置を含め、如何なる装置に対しても、フロー制御機能により許容される速度よりも高速でマルチキャスト送信を行うことはしない。
【０１０８】
したがって、このフロー制御否定確認マルチキャスト通信手法は、本発明のマルチ階層構成において、ネットワークトラフィックに関しても、送信側装置および受信側装置での処理時間に関しても、ネットワークリソースの使用を大幅に増大することなく、新ＳＳＬ／ＴＬＳセッション情報および更新ＳＳＬ／ＴＬＳセッション情報をプロキシサーバ３０２に配信するために、通信アプリケーション９０４によって提供されることが好ましい。もちろん、通信機アプリケーション９０４は、プロキシサーバ３０２の様々な管理機能のために、信頼性のない通信手法も提供する。
【０１０９】
したがって、信頼性のあるマルチキャスト通信手法（すなわち、肯定確認マルチキャスト通信手法およびフロー制御否定確認マルチキャスト通信手法）を利用して、多数の装置にＳＳＬ／ＴＬＳセッション情報を同時配信することによって、プロキシサーバ３０２とクライアントコンピュータ３０１との間のセッションのＳＳＬ／ＴＬＳセッション情報を、複数の異なるキャッシュメモリ７０５およびキャッシュ格納庫８０２に効率よくキャッシュ可能となる。クライアントコンピュータ３０１とあるプロキシサーバ３０２との間の接続が終了した場合、キャッシュされたＳＳＬ／ＴＬＳセッション情報を利用して、別のプロキシサーバ３０２が、クライアント装置とのセッションを再開することができる。
【０１１０】
以上、本発明の特定の実施形態について説明してきたが、様々な変形態様、変更態様、代替構成、および均等物も本発明の範囲に包含される。例えば、上記のＳＳＬ／ＴＬＳセッション情報の格納に加えて、その他の情報も、キャッシュ７０６に好都合に格納することができる。例えば、クライアントコンピュータ３０１およびプロキシサーバ３０２が、暗号化データの送信に使用する１以上のポートを指定する場合、これらのポートをキャッシュ７０６に格納して、クライアントコンピュータ３０１とのＳＳＬ／ＴＬＳセッションの再開を円滑化することができる。また、クライアントコンピュータ３０１が目的のアプリケーションサーバ３０３のＩＰアドレスおよびポートを提供する場合、この情報をキャッシュ７０６に好都合に格納して、クライアントコンピュータ３０１とのＳＳＬ／ＴＬＳセッションの再開を円滑化することができる。さらに、改良ＳＳＬ／ＴＬＳにより生成されたＳＳＬ／ＴＬＳセッションに対して、そのセッション中に交換されたノンスをキャッシュ７０６に格納することもできる。したがって、別のプロキシサーバ３０２とのセッションを再開すると、この新たなサーバ３０２は、前のデータグラムの受信時点を検出することができる。
【０１１１】
なお、上記の発明は、ある特定のデータ処理環境内での運用に限定されるものではなく、分散コンピュータネットワーク環境、単一の独立型コンピュータシステム環境などのコンピュータ環境等、複数のデータ処理環境内で自由に運用できる。さらに、特定の一連のトランザクションやステップを用いて本発明を説明してきたが、当業者にとっては、本発明の範囲が前記の一連のトランザクションやステップに限定されるものではないことが明らかであろう。
【０１１２】
本発明をプログラミングするために使用されるロジック、システムフロー、テーブル、およびデータ構成の生成には、本質的な自由度がある。演算を行うデータ構成やデータ値は、本発明の趣旨を逸脱するもの、または、本発明の範囲を制限するものでない限り、明示的なものでも、他のデータから導出されたものでも、他のソースから取り込まれたものでも、プログラム演算またはロジック演算の結果でもよい。この特許における索引付け、検索、データ処理のためのアルゴリズムは、本発明の趣旨を逸脱するもの、または、本発明の範囲を制限するものでない限り、様々な性能／システムインテグレーション要件をサポートするために、置換または変更されてもよい。
【０１１３】
さらに、本発明について、ハードウェアとソフトウェアとの特定の組み合わせを用いて説明したが、ハードウェアとソフトウェアとのその他の組み合わせも、本発明の範囲内であると認識すべきである。本発明は、ハードウェアのみ、もしくは、ソフトウェアのみ、または、その組み合わせを用いて実施してもよい。
この明細書および図面は、限定的ではなく例示的な意味合いと見なされるものとする。しかし、特許請求の範囲に記載されている本発明のより広範な趣旨および範囲から逸脱することなく、本発明に対して、追加、除去、削除、その他の改良や変更が可能であることは明白である。
【０１１４】
添付の方法に関する請求項においてステップを識別する参照番号は、単に便宜上のものであり、ステップの必須の順序を暗示するためのものではない。したがって、本発明は、添付の特許請求の範囲内において、上記以外の方法で実施してもよいと理解される。いずれの請求項も、「ミーンズ・プラス・ファンクション」形式であると解釈してはならない。
【図面の簡単な説明】
【０１１５】
【図１Ａ】ＴＣＰまたはＵＤＰをＩＰと共に利用してデータパケットを送信するための従来の方策を示す。
【図１Ｂ】ＳＳＬ／ＴＬＳをＴＣＰ／ＩＰと共に利用して確実なデータを送信するための従来の方策を示す。
【図１Ｃ】ヘッダフィールドと、暗号化暗号テキストフィールドと、メッセージ認証チェック（ＭＡＣ）とを含むＳＳＬ／ＴＬＳレコードのための従来のレコードフォーマットを示す。
【図２】ＳＯＣＫＳプロトコルを利用して、プロキシサーバ２０２を介してクライアントコンピュータ２０１をサーバコンピュータ２０３にインタフェースするための従来の方策を示す。
【図３Ａ】本発明のある変形態様に係る、送出フロー方向の改良ＳＯＣＫＳプロトコルを用いたシステムを示す。
【図３Ｂ】本発明のある変形態様に係る、送入フロー方向の改良ＳＯＣＫＳプロトコルを用いたシステムを示す。
【図４Ａ】暗号化を用いてＳＳＬ／ＴＬＳレコードを生成する従来の手法を示す。
【図４Ｂ】以前に暗号解読されたレコードに依存してＳＳＬ／ＴＬＳレコードを暗号解読する従来の手法を示す。
【図５Ａ】以前に送信されたレコードとは独立して各レコードを暗号化する本発明のある変形態様に係る改良暗号化方式を示す。
【図５Ｂ】以前に受信されたレコードとは独立して各レコードを暗号解読する本発明のある変形態様に係る改良暗号解読方式を示す。
【図５Ｃ】単一のレコード内に多数の暗号ブロックを含む改良暗号解読方式を示す。
【図６】本発明の様々な原則に従って、暗号化レコードの生成および送信に使用可能な方法の各ステップを示す。
【図７Ａ】本発明のある実施形態に係る２つのネットワークを示す。
【図７Ｂ】本発明のある実施形態に係る２つのネットワークを示す。
【図８Ａ】本発明の別の実施形態に係る２つのネットワークを示す。
【図８Ｂ】本発明の別の実施形態に係る２つのネットワークを示す。
【図９】本発明のある実施形態に係るプロキシサーバ装置を示す。
【図１０Ａ】本発明のある実施形態に係るネットワークフローレベル検出手法を示す。
【図１０Ｂ】本発明のある実施形態に係るネットワークフローレベル検出手法を示す。
Claims (46)
- コンピュータネットワークを介して確実にデータを送信する方法であって、
（１）第１のコンピュータと第２のコンピュータとの間に通信経路を確立するステップと、
（２）信頼性のない通信プロトコルを利用して、前記第１のコンピュータと前記第２のコンピュータとの間で、データレコードを暗号化して送信するステップであって、以前に送信されたデータレコードを参照することなく、各データレコードを暗号化するステップと、
（３） 前記第２のコンピュータにおいて、以前に受信されたデータレコードを参照することなく、前記ステップ（２）で送信された前記データレコードを受信して暗号解読するステップと
（４） 前記第２のコンピュータにおいて、前記データレコードを暗号化および暗号解読するためのセッション情報を第３のコンピュータに送信するステップとを含む方法。 - 前記ステップ（１）の前に、前記第１のコンピュータと前記第２のコンピュータとの間に信頼性のある通信経路を確立し、前記信頼性のある通信経路を介してセキュリティ信任情報を交換するステップを更に含む請求項１の方法。
- 前記セキュリティ信任情報を交換するステップが、前記ステップ（２）において前記データレコードの暗号化に使用される暗号化キーを交換するステップを含む請求項２の方法。
- 前記セッション情報に、前記セキュリティ信任情報の少なくとも一部が含まれている請求項２の方法。
- 前記ステップ（２）が、前記ステップ（３）において前記各データレコードを暗号解読するために、前記第２のコンピュータが以前に共有した暗号化キーと共に使用するノンスを、各データレコードに組み込むステップを含む請求項１の方法。
- 前記ノンスが、ランダム数を含む請求項５の方法。
- 前記第２のコンピュータにおいて、以前に送信されたデータレコード内に、前記ノンスが前もって受信されていないことを確認するステップを更に含む請求項５の方法。
- 前記ステップ（２）が、以前に送信されたデータレコードを参照せずにレコードを暗号化する暗号化方式に従って、前記データレコードが暗号化されたことを示す指標を、前記各データレコード内に埋め込むステップを含み、
前記ステップ（３）が、各レコードに前記指標が存在するか否かを決定し、前記指標が存在しないことの決定に応答して、前記指標が設定されている場合とは異なる方法で、各レコードを処理するステップを含む請求項１の方法。 - 前記ステップ（１）が、トランスミッション・コントロール・プロトコルを利用して実行され、前記ステップ（２）が、ユーザ・データグラム・プロトコルを利用して実行される請求項１の方法。
- 前記ステップ（２）が、別のサーバから受信されたデータレコードを暗号化するプロキシサーバにより実行される請求項１の方法。
- 前記第３のコンピュータが、
前記第１のコンピュータとの通信経路を確立し、
信頼性のない通信プロトコルを利用して、データレコードを暗号化して前記第１のコンピュータに送信し、
各データレコードが、以前に送信されたデータレコードを参照することなく、前記セッション情報を用いて暗号化される請求項１の方法。 - 第４のコンピュータが、
前記第３のコンピュータから前記セッション情報を検索し、
前記第１のコンピュータとの通信経路を確立し、
信頼性のない通信プロトコルを利用して、データレコードを暗号化して前記第１のコンピュータに送信し、
各データレコードが、以前に送信されたデータレコードを参照することなく、前記セッション情報を用いて暗号化される請求項１の方法。 - 前記セッション情報が、ＳＳＬまたはＴＬＳセッション情報である請求項１の方法。
- 前記セッション情報が、ＳＳＬまたはＴＬＳセッション識別子を含む請求項１の方法。
- 前記セッション情報が、前記ステップ（２）におけるデータレコードの暗号化に使用される暗号化キーを含む請求項１の方法。
- 前記セッション情報が、前記第３のコンピュータにより、ハッシュ機能を用いてキャッシュメモリに格納される請求項１の方法。
- 前記ハッシュ機能が、ＢＵＺｈａｓｈ関数である請求項１６の方法。
- 前記第２のコンピュータが、マルチキャスト通信を利用して前記セッション情報を前記第３のコンピュータに送信する請求項１の方法。
- 前記マルチキャスト通信が、否定確認マルチキャスト通信である請求項１８の方法。
- 信頼性のない通信プロトコルを利用して、クライアントコンピュータとプロキシサーバとの間で複数のデータレコードを確実に送信する方法であって、
（１）前記クライアントコンピュータと前記プロキシサーバとの間に信頼性のある接続を確立するステップと、
（２）前記信頼性のある接続を介して前記クライアントコンピュータと前記プロキシサーバとの間で暗号化信任情報を交換するステップと、
（３）複数のデータレコードのそれぞれのためにノンスを生成するステップであって、各ノンスが、前記複数のデータレコードの内の対応する１つを暗号解読するために必要な初期化ベクトルを含むステップと、
（４）前記ノンスを用いて、前記複数のデータレコードのそれぞれを暗号化し、前記複数のデータレコードのそれぞれに前記ノンスを付加するステップと、
（５）信頼性のない通信プロトコルを利用して、前記ステップ（４）において暗号化された前記複数のデータレコードを、前記クライアントコンピュータから前記プロキシサーバに送信するステップと、
（６）前記プロキシサーバにおいて、各データレコードから抽出された対応するノンスと、以前に共有された暗号化キーとを用いて、前記複数の暗号化データレコードのそれぞれを暗号解読するステップと、
（７）前記プロキシサーバにおいて、前記複数のデータレコードの暗号解読に使用される前記の以前に共有された暗号化キーを含むセッション情報を、別のサーバに送信するステップとを含む方法。 - 前記ステップ（６）が、信頼性のない確実な送信フォーマットに従って、前記クライアントコンピュータから受信された各データレコードがフォーマットされているか否かを決定するためにチェックし、ある特定のレコードが信頼性のない確実な送信フォーマットに従ってフォーマットされていない場合には、前記対応するノンスを用いた前記暗号解読を回避するステップを含む請求項２０の方法。
- 前記ステップ（３）が、ランダム数を各ノンスとして生成するステップを含む請求項２０の方法。
- 前記ステップ（３）が、一意的な数値を各ノンスとして生成するステップを含む請求項２０の方法。
- 前記ステップ（１）が、トランスミッション・コントロール・プロトコルを利用して実行され、前記ステップ（５）が、ユーザ・データグラム・プロトコルを利用して実行される請求項２０の方法。
- 前記ステップ（６）が、信頼性のある通信プロトコルを利用して以前に共有された暗号化キーを用いて実行される請求項２０の方法。
- 前記信頼性のある通信プロトコルが、トランスミッション・コントロール・プロトコルである請求項２５の方法。
- 前記別のサーバが、第２のプロキシサーバである請求項２０の方法。
- 前記第２のプロキシサーバにおいて、各データレコードから抽出された対応するノンスと、前記第１のプロキシサーバから送信された前記セッション情報とを用いて、前記クライアントコンピュータからの暗号化データレコードを暗号解読することを更に含む請求項２７の方法。
- 前記別のプロキシサーバが、キャッシュメモリサーバである請求項２０の方法。
- 第２のプロキシサーバにおいて、
前記キャッシュメモリサーバから前記セッション情報を得ることと、
各データレコードから抽出された対応するノンスと、前記セッション情報とを用いて、前記クライアントコンピュータからの暗号化データレコードを暗号解読することを更に含む請求項２９の方法。 - 前記セッション情報が、ＳＳＬまたはＴＬＳセッション情報である請求項２０の方法。
- 前記セッション情報が、ＳＳＬまたはＴＬＳセッション識別子を含む請求項２０の方法。
- 前記セッション情報が、前記クライアントコンピュータのユーザのための認証情報を含む請求項２０の方法。
- 前記セッション情報が、前記別のサーバにより、ハッシュ機能を用いてキャッシュメモリに格納される請求項２０の方法。
- 前記ハッシュ機能が、ＢＵＺｈａｓｈ関数である請求項３４の方法。
- 前記別のプロキシサーバが、マルチキャスト通信を利用して前記セッション情報を別のサーバに送信する請求項２０の方法。
- 前記マルチキャスト通信が、否定確認マルチキャスト通信である請求項３６の方法。
- 信頼性のないプロトコルを利用して確実にデータを送信するシステムであって、
信頼性のないプロトコルを利用してデータレコードを確実に送信するために、アプリケーションプログラムと共に動作可能な通信プロトコルクライアント機能を備えた第１のコンピュータと、
前記第１のコンピュータと連結され、前記信頼性のない通信プロトコルを利用して確実にデータレコードを受信するために、前記通信プロトコルクライアント機能と共に動作可能な通信プロトコルサーバ機能を備えた第２のコンピュータとを備え、
前記通信プロトコルクライアント機能が、ノンスおよび暗号化キーを用いて各データレコードを暗号化し、前記暗号化データレコードのそれぞれに前記ノンスを付加し、
前記通信プロトコルサーバ機能が、前記付加されたノンスおよび前記暗号化キーを用いてデータレコードのそれぞれを暗号解読し、
さらに、前記第２のコンピュータと連結され、少なくとも前記暗号化キーを格納するためのキャッシュメモリを有する第３のコンピュータを備えたシステム。 - 前記通信プロトコルクライアント機能が、信頼性のある通信プロトコルを利用して、前記通信プロトコルサーバ機能と暗号化信任情報を交換する請求項３８のシステム。
- 前記信頼性のない通信プロトコルが、ユーザ・データグラム・プロトコルを含み、前記信頼性のある通信プロトコルが、トランスミッション・コントロール・プロトコルを含む請求項３９のシステム。
- 前記通信プロトコルクライアント機能および前記通信プロトコルサーバ機能が、ＳＯＣＫＳ通信プロトコルと互換性がある請求項３８のシステム。
- 前記通信プロトコルクライアント機能および前記通信プロトコルサーバ機能が、ＳＳＬ／ＴＬＳ通信プロトコルと互換性がある請求項３８のシステム。
- 前記第２のコンピュータが、前記第１のコンピュータから受信された暗号解読レコードを、サーバコンピュータに転送するプロキシサーバを含む請求項３８のシステム。
- 前記第２のコンピュータが、前記第１のコンピュータから受信された各データレコードに指標が設定されているか否かを決定するレコード検出器を備え、前記指標が設定されていなければ、前記サーバコンピュータでの暗号解読を回避する請求項３８のシステム。
- 前記第３のコンピュータが、プロキシコンピュータであって、
前記第１のコンピュータから暗号化レコードを受信可能であり、
前記キャッシュメモリに格納されている少なくとも前記暗号化キーを用いて、前記受信されたレコードを暗号解読可能であり、
前記第１のコンピュータから受信された暗号解読レコードをサーバコンピュータに転送可能なプロキシサーバである請求項３８のシステム。 - 前記第３のコンピュータが、メモリキャッシュサーバであり、
第４のコンピュータであって、
前記第３のコンピュータの前記キャッシュメモリに格納されている少なくとも前記暗号化キーを取得可能であり、
前記第１のコンピュータから暗号化レコードを受信可能であり、
前記キャッシュメモリに格納されている少なくとも前記暗号化キーを用いて、前記受信されたレコードを暗号解読可能であり、
前記第１のコンピュータから受信された前記暗号解読レコードをサーバコンピュータに転送可能な第４のコンピュータを更に備えた請求項３８のシステム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/783,146 US7360075B2 (en) | 2001-02-12 | 2001-02-13 | Method and apparatus for providing secure streaming data transmission facilities using unreliable protocols |
| PCT/US2002/003625 WO2002065650A2 (en) | 2001-02-13 | 2002-02-08 | Method and apparatus for providing secure streaming data transmission facilities using unreliable protocols |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004525558A true JP2004525558A (ja) | 2004-08-19 |
Family
ID=25128312
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002564846A Pending JP2004525558A (ja) | 2001-02-13 | 2002-02-08 | 信頼性のないプロトコルを利用して確実なストリーミングデータ送信機能を提供するための方法および装置 |
Country Status (6)
| Country | Link |
|---|---|
| US (4) | US7360075B2 (ja) |
| EP (1) | EP1362427A2 (ja) |
| JP (1) | JP2004525558A (ja) |
| AU (1) | AU2002236978A1 (ja) |
| CA (1) | CA2438180A1 (ja) |
| WO (1) | WO2002065650A2 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008538266A (ja) * | 2005-03-10 | 2008-10-16 | インテル コーポレイション | 非互換的トランスポートのセキュリティプロトコル |
| JP2015505994A (ja) * | 2011-12-16 | 2015-02-26 | アカマイ テクノロジーズ インコーポレイテッド | ローカルにアクセス可能な秘密鍵を用いないｓｓｌ接続の終了 |
Families Citing this family (174)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7360075B2 (en) | 2001-02-12 | 2008-04-15 | Aventail Corporation, A Wholly Owned Subsidiary Of Sonicwall, Inc. | Method and apparatus for providing secure streaming data transmission facilities using unreliable protocols |
| US7383329B2 (en) | 2001-02-13 | 2008-06-03 | Aventail, Llc | Distributed cache for state transfer operations |
| US7353380B2 (en) * | 2001-02-12 | 2008-04-01 | Aventail, Llc, A Subsidiary Of Sonicwall, Inc. | Method and apparatus for providing secure streaming data transmission facilities using unreliable protocols |
| US20020194501A1 (en) * | 2001-02-25 | 2002-12-19 | Storymail, Inc. | System and method for conducting a secure interactive communication session |
| US7640582B2 (en) | 2003-04-16 | 2009-12-29 | Silicon Graphics International | Clustered filesystem for mix of trusted and untrusted nodes |
| US7536546B2 (en) * | 2001-08-28 | 2009-05-19 | Acme Packet, Inc. | System and method for providing encryption for rerouting of real time multi-media flows |
| US7991006B2 (en) * | 2001-08-02 | 2011-08-02 | Oracle America, Inc. | Filtering redundant packets in computer network equipments |
| US20040024808A1 (en) * | 2002-08-01 | 2004-02-05 | Hitachi, Ltd. | Wide area storage localization system |
| US7600118B2 (en) * | 2002-09-27 | 2009-10-06 | Intel Corporation | Method and apparatus for augmenting authentication in a cryptographic system |
| US8909926B2 (en) * | 2002-10-21 | 2014-12-09 | Rockwell Automation Technologies, Inc. | System and methodology providing automation security analysis, validation, and learning in an industrial controller environment |
| US9009084B2 (en) | 2002-10-21 | 2015-04-14 | Rockwell Automation Technologies, Inc. | System and methodology providing automation security analysis and network intrusion protection in an industrial environment |
| US7240214B2 (en) * | 2002-10-25 | 2007-07-03 | Yahoo!, Inc. | Centrally controllable instant messaging system |
| US7542471B2 (en) * | 2002-10-30 | 2009-06-02 | Citrix Systems, Inc. | Method of determining path maximum transmission unit |
| US8233392B2 (en) | 2003-07-29 | 2012-07-31 | Citrix Systems, Inc. | Transaction boundary detection for reduction in timeout penalties |
| US8270423B2 (en) | 2003-07-29 | 2012-09-18 | Citrix Systems, Inc. | Systems and methods of using packet boundaries for reduction in timeout prevention |
| US7630305B2 (en) * | 2003-07-29 | 2009-12-08 | Orbital Data Corporation | TCP selective acknowledgements for communicating delivered and missed data packets |
| US7616638B2 (en) | 2003-07-29 | 2009-11-10 | Orbital Data Corporation | Wavefront detection and disambiguation of acknowledgments |
| US7587598B2 (en) * | 2002-11-19 | 2009-09-08 | Toshiba America Research, Inc. | Interlayer fast authentication or re-authentication for network communication |
| US7362780B2 (en) * | 2002-12-11 | 2008-04-22 | Nokia Corporation | Avoiding compression of encrypted payload |
| US20040193456A1 (en) * | 2003-03-28 | 2004-09-30 | The Ohio Casualty Insurance Company | Out-of-sequence endorsement processing in insurance policy management system |
| US9106479B1 (en) * | 2003-07-10 | 2015-08-11 | F5 Networks, Inc. | System and method for managing network communications |
| US8437284B2 (en) | 2003-07-29 | 2013-05-07 | Citrix Systems, Inc. | Systems and methods for additional retransmissions of dropped packets |
| US8432800B2 (en) | 2003-07-29 | 2013-04-30 | Citrix Systems, Inc. | Systems and methods for stochastic-based quality of service |
| US7656799B2 (en) | 2003-07-29 | 2010-02-02 | Citrix Systems, Inc. | Flow control system architecture |
| US7698453B2 (en) | 2003-07-29 | 2010-04-13 | Oribital Data Corporation | Early generation of acknowledgements for flow control |
| US8238241B2 (en) | 2003-07-29 | 2012-08-07 | Citrix Systems, Inc. | Automatic detection and window virtualization for flow control |
| US8464353B2 (en) * | 2003-10-03 | 2013-06-11 | Hewlett-Packard Development Company, L. P. | Method and system for content downloads via an insecure communications channel to devices |
| US7617531B1 (en) | 2004-02-18 | 2009-11-10 | Citrix Systems, Inc. | Inferencing data types of message components |
| US20050204139A1 (en) * | 2004-03-10 | 2005-09-15 | Helland Patrick J. | Service broker security |
| US8213422B2 (en) * | 2004-06-04 | 2012-07-03 | Rockstar Bidco, LP | Selective internet priority service |
| US9621473B2 (en) | 2004-08-18 | 2017-04-11 | Open Text Sa Ulc | Method and system for sending data |
| GB2417391B (en) * | 2004-08-18 | 2007-04-18 | Wecomm Ltd | Transmitting data over a network |
| US8224966B2 (en) * | 2004-08-24 | 2012-07-17 | Cisco Technology, Inc. | Reproxying an unproxied connection |
| GB0419479D0 (en) * | 2004-09-02 | 2004-10-06 | Cryptomathic Ltd | Data certification methods and apparatus |
| JP4520840B2 (ja) * | 2004-12-02 | 2010-08-11 | 株式会社日立製作所 | 暗号化通信の中継方法、ゲートウェイサーバ装置、暗号化通信のプログラムおよび暗号化通信のプログラム記憶媒体 |
| US8042165B2 (en) * | 2005-01-14 | 2011-10-18 | Citrix Systems, Inc. | Method and system for requesting and granting membership in a server farm |
| US20060236385A1 (en) * | 2005-01-14 | 2006-10-19 | Citrix Systems, Inc. | A method and system for authenticating servers in a server farm |
| KR100846868B1 (ko) * | 2005-01-17 | 2008-07-17 | 엘지전자 주식회사 | Ｓｕｐｌ 기반의 위치정보 시스템에서의 ｔｌｓ 세션관리방법 |
| US7900039B2 (en) * | 2005-01-17 | 2011-03-01 | Lg Electronics, Inc. | TLS session management method in SUPL-based positioning system |
| US9118717B2 (en) * | 2005-02-18 | 2015-08-25 | Cisco Technology, Inc. | Delayed network protocol proxy for packet inspection in a network |
| WO2006104438A1 (en) * | 2005-03-31 | 2006-10-05 | Telefonaktiebolaget Lm Ericsson (Publ) | Protection of data delivered out-of-order |
| KR100595714B1 (ko) * | 2005-04-01 | 2006-07-03 | 엘지전자 주식회사 | Ｓｕｐｌ 기반의 위치정보 시스템에서 ｓｕｐｌ 초기화메시지 및 이를 이용한 ｓｕｐｌ 처리방법 |
| US20060277596A1 (en) * | 2005-06-06 | 2006-12-07 | Calvert Peter S | Method and system for multi-instance session support in a load-balanced environment |
| US7627681B2 (en) * | 2005-07-20 | 2009-12-01 | Microsoft Corporation | Relaying messages through a firewall |
| US7921463B2 (en) * | 2005-09-30 | 2011-04-05 | Intel Corporation | Methods and apparatus for providing an insertion and integrity protection system associated with a wireless communication platform |
| AU2006324920B2 (en) * | 2005-12-14 | 2010-08-12 | Nds Limited | Method and system for usage of block cipher encryption |
| US8447695B2 (en) * | 2006-01-05 | 2013-05-21 | International Business Machines Corporation | System and method for processing feedback entries received from software |
| US8782393B1 (en) * | 2006-03-23 | 2014-07-15 | F5 Networks, Inc. | Accessing SSL connection data by a third-party |
| US8151323B2 (en) | 2006-04-12 | 2012-04-03 | Citrix Systems, Inc. | Systems and methods for providing levels of access and action control via an SSL VPN appliance |
| US8004973B2 (en) * | 2006-04-25 | 2011-08-23 | Citrix Systems, Inc. | Virtual inline configuration for a network device |
| US20070255861A1 (en) * | 2006-04-27 | 2007-11-01 | Kain Michael T | System and method for providing dynamic network firewall with default deny |
| US20080002695A1 (en) * | 2006-06-28 | 2008-01-03 | Motorola, Inc. | Preservation of session information on a communications network |
| US8677007B2 (en) * | 2006-08-03 | 2014-03-18 | Citrix Systems, Inc. | Systems and methods for bypassing an appliance |
| US7953889B2 (en) * | 2006-08-03 | 2011-05-31 | Citrix Systems, Inc. | Systems and methods for routing VPN traffic around network disruption |
| US8281392B2 (en) * | 2006-08-11 | 2012-10-02 | Airdefense, Inc. | Methods and systems for wired equivalent privacy and Wi-Fi protected access protection |
| US7689547B2 (en) * | 2006-09-06 | 2010-03-30 | Microsoft Corporation | Encrypted data search |
| US20080077976A1 (en) * | 2006-09-27 | 2008-03-27 | Rockwell Automation Technologies, Inc. | Cryptographic authentication protocol |
| US8091124B2 (en) * | 2007-02-23 | 2012-01-03 | Microsoft Corporation | Caching public objects with private connections |
| JP4851585B2 (ja) * | 2007-02-28 | 2012-01-11 | 富士通株式会社 | クライアント装置と複数のサーバ装置からなるシステムの通信方法、その通信プログラム、クライアント装置及びサーバ装置 |
| JP4802123B2 (ja) * | 2007-03-07 | 2011-10-26 | 富士通株式会社 | 情報送信装置、情報送信方法、情報送信プログラムおよび該プログラムを記録した記録媒体 |
| US8504775B2 (en) | 2007-03-12 | 2013-08-06 | Citrix Systems, Inc | Systems and methods of prefreshening cached objects based on user's current web page |
| US7783757B2 (en) | 2007-03-12 | 2010-08-24 | Citrix Systems, Inc. | Systems and methods of revalidating cached objects in parallel with request for object |
| US7706266B2 (en) * | 2007-03-12 | 2010-04-27 | Citrix Systems, Inc. | Systems and methods of providing proxy-based quality of service |
| US8701010B2 (en) | 2007-03-12 | 2014-04-15 | Citrix Systems, Inc. | Systems and methods of using the refresh button to determine freshness policy |
| US7720936B2 (en) | 2007-03-12 | 2010-05-18 | Citrix Systems, Inc. | Systems and methods of freshening and prefreshening a DNS cache |
| US7584294B2 (en) | 2007-03-12 | 2009-09-01 | Citrix Systems, Inc. | Systems and methods for prefetching objects for caching using QOS |
| US8103783B2 (en) * | 2007-03-12 | 2012-01-24 | Citrix Systems, Inc. | Systems and methods of providing security and reliability to proxy caches |
| US8000467B2 (en) * | 2007-03-19 | 2011-08-16 | Stmicroelectronics Sa | Data parallelized encryption and integrity checking method and device |
| US8190875B2 (en) * | 2007-03-22 | 2012-05-29 | Cisco Technology, Inc. | Reducing processing load in proxies for secure communications |
| JP5002337B2 (ja) * | 2007-05-31 | 2012-08-15 | 株式会社東芝 | ネットワークアクセスを認証または中継する通信システム、中継装置、認証装置、および通信方法 |
| US8397027B2 (en) * | 2007-08-10 | 2013-03-12 | Emc Corporation | Methods and systems for multi-caching |
| US7979563B2 (en) * | 2007-08-16 | 2011-07-12 | International Business Machines Corporation | Method and system for dynamic client/server network management using proxy servers |
| WO2009045963A1 (en) * | 2007-10-01 | 2009-04-09 | Viasat, Inc. | Methods and systems for secure data transmission between a client and a server via a proxy |
| US8347374B2 (en) * | 2007-11-15 | 2013-01-01 | Red Hat, Inc. | Adding client authentication to networked communications |
| US8929369B1 (en) * | 2007-12-31 | 2015-01-06 | Emc Corporation | System and method for striping / mirroring data |
| US8145768B1 (en) * | 2008-02-26 | 2012-03-27 | F5 Networks, Inc. | Tuning of SSL session caches based on SSL session IDS |
| WO2009117384A2 (en) * | 2008-03-17 | 2009-09-24 | Broadcom Corporation | Method and system for secure block acknowledgement (block ack) with protected mac sequence number |
| US7877503B2 (en) * | 2008-07-02 | 2011-01-25 | Verizon Patent And Licensing Inc. | Method and system for an intercept chain of custody protocol |
| US7949894B2 (en) * | 2008-08-11 | 2011-05-24 | International Business Machines Corporation | Self-healing capabilities in a directory server |
| US8737220B2 (en) * | 2008-09-23 | 2014-05-27 | The Trustees Of Columbia University In The City Of New York | Systems for providing feedback to sending entities |
| CA2739914A1 (en) * | 2008-10-07 | 2010-04-15 | University Of South Florida | Architecture and two-layered protocol for real-time location-aware applications |
| US9008314B2 (en) * | 2008-11-18 | 2015-04-14 | Verizon Patent And Licensing Inc. | Secure wireless communications |
| KR20100064585A (ko) * | 2008-12-05 | 2010-06-15 | 삼성전자주식회사 | 데이터송수신장치 및 그 방법 |
| JP5374752B2 (ja) * | 2009-01-19 | 2013-12-25 | 株式会社東芝 | 保護制御計測システムと装置、およびデータ伝送方法 |
| FR2943198B1 (fr) * | 2009-03-16 | 2011-05-20 | Groupe Des Ecoles De Telecommunications Get Ecole Nationale Superieure Des Telecommunications Enst | Procede de production de donnees de securisation, dispositif et programme d'ordinateur correspondant |
| JP5321221B2 (ja) * | 2009-04-22 | 2013-10-23 | 富士通株式会社 | 管理装置、管理方法、およびプログラム |
| US8082351B1 (en) * | 2009-05-26 | 2011-12-20 | Adobe Systems Incorporated | Software load balancing for session requests that maintain state information |
| US10424000B2 (en) | 2009-05-30 | 2019-09-24 | Edmond K. Chow | Methods and systems for annotation of digital information |
| US20150294377A1 (en) | 2009-05-30 | 2015-10-15 | Edmond K. Chow | Trust network effect |
| US20110307490A1 (en) * | 2010-06-15 | 2011-12-15 | Usm China/Hong Kong Limited | Context Level Protocols And Interfaces |
| US20110055552A1 (en) * | 2009-09-02 | 2011-03-03 | Max Planck Gesellschaft Zur Foerderung Der Wissenschaften | Private, accountable, and personalized information delivery in a networked system |
| US20110060812A1 (en) * | 2009-09-10 | 2011-03-10 | Level 3 Communications, Llc | Cache server with extensible programming framework |
| US8560604B2 (en) | 2009-10-08 | 2013-10-15 | Hola Networks Ltd. | System and method for providing faster and more efficient data communication |
| US8909863B2 (en) * | 2009-11-16 | 2014-12-09 | Microsoft Corporation | Cache for storage and/or retrieval of application information |
| US9479480B2 (en) * | 2010-01-29 | 2016-10-25 | Citrix Systems, Inc. | Systems and methods of using SSL pools for WAN acceleration |
| US8700892B2 (en) | 2010-03-19 | 2014-04-15 | F5 Networks, Inc. | Proxy SSL authentication in split SSL for client-side proxy agent resources with content insertion |
| US8615651B1 (en) * | 2010-05-17 | 2013-12-24 | Google Inc. | Offline shared security key calculation |
| US8707088B2 (en) * | 2010-05-19 | 2014-04-22 | Cleversafe, Inc. | Reconfiguring data storage in multiple dispersed storage networks |
| US10015286B1 (en) | 2010-06-23 | 2018-07-03 | F5 Networks, Inc. | System and method for proxying HTTP single sign on across network domains |
| US10817555B2 (en) * | 2010-07-03 | 2020-10-27 | Edmond K. Chow | Resource hubs for heterogeneous groups |
| US20120023241A1 (en) * | 2010-07-26 | 2012-01-26 | Cisco Technology, Inc. | SSL Cache Session Selection |
| CN102045201B (zh) * | 2010-12-27 | 2013-03-27 | 北京锐安科技有限公司 | 一种内网服务器集群自动升级方法及其系统 |
| RU2445692C1 (ru) * | 2011-01-21 | 2012-03-20 | Государственное образовательное учреждение высшего профессионального образования Академия Федеральной службы охраны Российской Федерации (Академия ФСО России) | Способ обеспечения информационной безопасности при доступе пользователя к внешним информационным ресурсам через интернет |
| US8776207B2 (en) * | 2011-02-16 | 2014-07-08 | Fortinet, Inc. | Load balancing in a network with session information |
| US9130935B2 (en) * | 2011-05-05 | 2015-09-08 | Good Technology Corporation | System and method for providing access credentials |
| US8725788B2 (en) | 2011-05-27 | 2014-05-13 | Adobe Systems Incorporated | System and method for decryption of content including partial-block discard |
| US8687809B2 (en) * | 2011-05-27 | 2014-04-01 | Adobe Systems Incorporated | System and method for decryption of content including disconnected encryption chains |
| US8707391B2 (en) * | 2011-08-18 | 2014-04-22 | Qualcomm Incorporated | Supporting a server-arbitrated group communication session over a local wireless network via a wireless wide area network proxy client |
| US9753797B1 (en) * | 2011-08-26 | 2017-09-05 | Amazon Technologies, Inc. | Reliable intermediate multicast communications |
| US9386127B2 (en) | 2011-09-28 | 2016-07-05 | Open Text S.A. | System and method for data transfer, including protocols for use in data transfer |
| US9009473B2 (en) * | 2011-10-13 | 2015-04-14 | International Business Machines Corporation | Providing consistent cryptographic operations across several applications |
| US8813189B2 (en) * | 2011-11-18 | 2014-08-19 | Blue Coat Systems, Inc. | System and method for capturing network traffic |
| CN103166913B (zh) * | 2011-12-09 | 2015-10-21 | 华为技术有限公司 | 加密媒体流的录制方法及交换控制设备 |
| CN103188074B (zh) * | 2011-12-28 | 2016-08-10 | 上海格尔软件股份有限公司 | 一种增强浏览器ssl算法强度的代理方法 |
| US20130297513A1 (en) * | 2012-05-04 | 2013-11-07 | Rawllin International Inc. | Multi factor user authentication |
| US8843738B2 (en) | 2012-05-14 | 2014-09-23 | Sierra Wireless, Inc. | TLS abbreviated session identifier protocol |
| DE102012209408A1 (de) * | 2012-06-04 | 2013-12-05 | Siemens Aktiengesellschaft | Sichere Übertragung einer Nachricht |
| US9075953B2 (en) | 2012-07-31 | 2015-07-07 | At&T Intellectual Property I, L.P. | Method and apparatus for providing notification of detected error conditions in a network |
| US8966179B1 (en) * | 2012-09-10 | 2015-02-24 | Google Inc. | Volatile memory storage for private web browsing |
| CN102970166B (zh) * | 2012-11-21 | 2015-10-07 | 大唐移动通信设备有限公司 | 一种监听网元设备告警事件的方法及系统 |
| US9390052B1 (en) | 2012-12-19 | 2016-07-12 | Amazon Technologies, Inc. | Distributed caching system |
| US9621399B1 (en) | 2012-12-19 | 2017-04-11 | Amazon Technologies, Inc. | Distributed caching system |
| US10642738B1 (en) | 2012-12-19 | 2020-05-05 | Amazon Technologies, Inc. | Distributed caching system |
| US9166862B1 (en) * | 2012-12-19 | 2015-10-20 | Amazon Technologies, Inc. | Distributed caching system |
| US9118645B2 (en) * | 2012-12-19 | 2015-08-25 | Jive Software, Inc. | Distributed authentication using persistent stateless credentials |
| US9264222B2 (en) * | 2013-02-28 | 2016-02-16 | Apple Inc. | Precomputing internal AES states in counter mode to protect keys used in AES computations |
| US9438638B2 (en) * | 2013-03-15 | 2016-09-06 | Silicon Graphics International Corp. | Method for transparently connecting augmented network socket operations |
| US9467283B2 (en) | 2013-06-24 | 2016-10-11 | Blackberry Limited | Securing method for lawful interception |
| US9241044B2 (en) | 2013-08-28 | 2016-01-19 | Hola Networks, Ltd. | System and method for improving internet communication by using intermediate nodes |
| US9396338B2 (en) | 2013-10-15 | 2016-07-19 | Intuit Inc. | Method and system for providing a secure secrets proxy |
| US9602498B2 (en) * | 2013-10-17 | 2017-03-21 | Fortinet, Inc. | Inline inspection of security protocols |
| US9467477B2 (en) | 2013-11-06 | 2016-10-11 | Intuit Inc. | Method and system for automatically managing secrets in multiple data security jurisdiction zones |
| US9894069B2 (en) | 2013-11-01 | 2018-02-13 | Intuit Inc. | Method and system for automatically managing secret application and maintenance |
| US9444818B2 (en) | 2013-11-01 | 2016-09-13 | Intuit Inc. | Method and system for automatically managing secure communications in multiple communications jurisdiction zones |
| WO2015183151A1 (en) * | 2014-05-28 | 2015-12-03 | Telefonaktiebolaget L M Ericsson (Publ) | Methods and arrangements for cloud caching |
| EP2961207A1 (en) * | 2014-06-24 | 2015-12-30 | Gemalto SA | Method, server and telecommunications system for establishing, through an OTA server, a secured communication channel between an administrative agent comprised in a device and a third party server |
| WO2016007333A1 (en) * | 2014-07-09 | 2016-01-14 | Seven Networks, Inc. | Secure handling of secure socket layer ("ssl") traffic |
| US20160012399A1 (en) * | 2014-07-09 | 2016-01-14 | Uniloc Luxembourg S.A. | Secure two-stage transactions |
| TWI543570B (zh) * | 2014-08-14 | 2016-07-21 | 明基電通股份有限公司 | 傳送郵件資料的系統及其方法 |
| KR102208072B1 (ko) * | 2014-09-01 | 2021-01-27 | 삼성전자주식회사 | 데이터 처리 시스템 |
| EP3201783B1 (en) * | 2014-09-29 | 2020-11-11 | Akamai Technologies, Inc. | Https request enrichment |
| US10834065B1 (en) | 2015-03-31 | 2020-11-10 | F5 Networks, Inc. | Methods for SSL protected NTLM re-authentication and devices thereof |
| US10063590B1 (en) * | 2015-04-23 | 2018-08-28 | Amazon Technologies, Inc. | Secure message protocol |
| US11057446B2 (en) | 2015-05-14 | 2021-07-06 | Bright Data Ltd. | System and method for streaming content from multiple servers |
| US10091649B2 (en) | 2015-07-12 | 2018-10-02 | Qualcomm Incorporated | Network architecture and security with encrypted client device contexts |
| US10904332B2 (en) | 2015-12-29 | 2021-01-26 | Akamai Technologies, Inc. | Caching content securely within an edge environment |
| US10904229B2 (en) | 2015-12-29 | 2021-01-26 | Akamai Technologies, Inc. | Caching content securely within an edge environment, with pre-positioning |
| US10404698B1 (en) | 2016-01-15 | 2019-09-03 | F5 Networks, Inc. | Methods for adaptive organization of web application access points in webtops and devices thereof |
| CN107070998B (zh) * | 2017-03-20 | 2019-11-29 | 广东工业大学 | 一种安全的物联网通讯协议及方法 |
| US10936711B2 (en) | 2017-04-18 | 2021-03-02 | Intuit Inc. | Systems and mechanism to control the lifetime of an access token dynamically based on access token use |
| CN107197000B (zh) * | 2017-05-04 | 2020-07-31 | 微梦创科网络科技（中国）有限公司 | 静态动态混合缓存方法、装置及系统 |
| GB201710168D0 (en) * | 2017-06-26 | 2017-08-09 | Microsoft Technology Licensing Llc | Introducing middleboxes into secure communications between a client and a sever |
| LT3767494T (lt) | 2017-08-28 | 2023-03-10 | Bright Data Ltd. | Būdas pagerinti turinio parsisiuntimą, pasirenkant tunelinius įrenginius |
| US10904224B2 (en) | 2017-09-29 | 2021-01-26 | Rolls-Royce Corporation | Aircraft engine monitoring system |
| US10635829B1 (en) | 2017-11-28 | 2020-04-28 | Intuit Inc. | Method and system for granting permissions to parties within an organization |
| US11416852B1 (en) * | 2017-12-15 | 2022-08-16 | Worldpay, Llc | Systems and methods for generating and transmitting electronic transaction account information messages |
| US10778642B2 (en) | 2017-12-23 | 2020-09-15 | Mcafee, Llc | Decrypting transport layer security traffic without man-in-the-middle proxy |
| US10911409B2 (en) | 2018-05-21 | 2021-02-02 | Cisco Technology, Inc. | Engagement and disengagement of transport layer security proxy services with encrypted handshaking |
| US11057157B2 (en) * | 2018-06-29 | 2021-07-06 | Hewlett Packard Enterprise Development Lp | Transmission frame counter |
| CN109152091B (zh) * | 2018-10-12 | 2022-02-15 | 广州雷迅创新科技有限公司 | 一种可用于无人机集群控制的通信系统 |
| CN109327520B (zh) * | 2018-10-19 | 2021-04-30 | 中国银行股份有限公司 | 建立终端与服务器节点连接的方法及装置 |
| CN111355695B (zh) * | 2018-12-24 | 2022-07-01 | 中移（杭州）信息技术有限公司 | 一种安全代理方法和装置 |
| CN109818736A (zh) * | 2018-12-24 | 2019-05-28 | 顺丰科技有限公司 | Ssl解密装置、解密系统、解密方法 |
| EP3780557B1 (en) | 2019-02-25 | 2023-02-15 | Bright Data Ltd. | System and method for url fetching retry mechanism |
| EP4030318A1 (en) | 2019-04-02 | 2022-07-20 | Bright Data Ltd. | System and method for managing non-direct url fetching service |
| CN110233774B (zh) * | 2019-05-28 | 2020-12-29 | 华中科技大学 | 一种Socks代理服务器的探测方法、分布式探测方法和系统 |
| CN110730168B (zh) * | 2019-09-29 | 2022-06-14 | 佛山市兴颂机器人科技有限公司 | 一种通信控制方法、装置及服务端设备 |
| CN110855700A (zh) * | 2019-11-20 | 2020-02-28 | 杭州端点网络科技有限公司 | 一种跨公网实现多云管控的安全认证方法 |
| CN111585976B (zh) * | 2020-04-09 | 2021-11-23 | 北京理工大学 | 通信方法、装置、存储介质和电子设备 |
| US11411997B2 (en) * | 2020-08-13 | 2022-08-09 | Salesforce, Inc. | Active fingerprinting for transport layer security (TLS) servers |
| CN112511377B (zh) * | 2020-11-16 | 2022-02-01 | 成都云智天下科技股份有限公司 | 一种基于arq和udp协议的tcp网络加速方法 |
| CN113518080B (zh) * | 2021-06-23 | 2021-11-19 | 北京观成科技有限公司 | 一种tls加密流量检测方法、装置和电子设备 |
| CN114499848B (zh) * | 2022-01-26 | 2023-05-30 | 无锡融卡科技有限公司 | 会话密钥生成装置及方法 |
| US11895182B1 (en) | 2023-01-23 | 2024-02-06 | Bank Of America Corporation | Systems, methods, and apparatuses for dynamically determining data center transmissions by implementing load balancers in an electronic network |
Family Cites Families (102)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6345288B1 (en) * | 1989-08-31 | 2002-02-05 | Onename Corporation | Computer-based communication system and method using metadata defining a control-structure |
| FR2686755A1 (fr) * | 1992-01-28 | 1993-07-30 | Electricite De France | Procede de chiffrement de messages transmis entre reseaux interconnectes, appareil de chiffrement et dispositif de communication de donnees chiffrees mettant en óoeuvre un tel procede. |
| JPH05281906A (ja) * | 1992-04-02 | 1993-10-29 | Fujitsu Ltd | 暗号鍵共有方式 |
| US5436972A (en) * | 1993-10-04 | 1995-07-25 | Fischer; Addison M. | Method for preventing inadvertent betrayal by a trustee of escrowed digital secrets |
| GB2288519A (en) * | 1994-04-05 | 1995-10-18 | Ibm | Data encryption |
| JPH09510596A (ja) * | 1994-06-08 | 1997-10-21 | エイチイー・ホールディングス・インコーポレーテッド・ディー ビーエー・ヒューズ・エレクトロニクス | ハイブリッドネットワークアクセスのための装置および方法 |
| US5566297A (en) * | 1994-06-16 | 1996-10-15 | International Business Machines Corporation | Non-disruptive recovery from file server failure in a highly available file system for clustered computing environments |
| US5553083B1 (en) * | 1995-01-19 | 2000-05-16 | Starburst Comm Corp | Method for quickly and reliably transmitting frames of data over communications links |
| US5673319A (en) * | 1995-02-06 | 1997-09-30 | International Business Machines Corporation | Block cipher mode of operation for secure, length-preserving encryption |
| US5657390A (en) * | 1995-08-25 | 1997-08-12 | Netscape Communications Corporation | Secure socket layer application program apparatus and method |
| US5754651A (en) * | 1996-05-31 | 1998-05-19 | Thomson Consumer Electronics, Inc. | Processing and storage of digital data and program specific information |
| US5822531A (en) * | 1996-07-22 | 1998-10-13 | International Business Machines Corporation | Method and system for dynamically reconfiguring a cluster of computer systems |
| US5692124A (en) * | 1996-08-30 | 1997-11-25 | Itt Industries, Inc. | Support of limited write downs through trustworthy predictions in multilevel security of computer network communications |
| US5884316A (en) | 1996-11-19 | 1999-03-16 | Microsoft Corporation | Implicit session context system with object state cache |
| US6125186A (en) * | 1996-11-28 | 2000-09-26 | Fujitsu Limited | Encryption communication system using an agent and a storage medium for storing that agent |
| US6029245A (en) * | 1997-03-25 | 2000-02-22 | International Business Machines Corporation | Dynamic assignment of security parameters to web pages |
| US6038677A (en) * | 1997-03-31 | 2000-03-14 | International Business Machines Corporation | Automatic resource group formation and maintenance in a high availability cluster configuration |
| US6317729B1 (en) * | 1997-04-08 | 2001-11-13 | Linda J. Camp | Method for certifying delivery of secure electronic transactions |
| JP3354433B2 (ja) * | 1997-04-25 | 2002-12-09 | 株式会社日立製作所 | ネットワーク通信システム |
| US5907678A (en) | 1997-05-07 | 1999-05-25 | International Business Machines Corporation | Client/server system in which protocol caches for multiple sessions are selectively copied into a common checkpoint cache upon receiving a checkpoint request |
| US6167438A (en) * | 1997-05-22 | 2000-12-26 | Trustees Of Boston University | Method and system for distributed caching, prefetching and replication |
| US6199110B1 (en) | 1997-05-30 | 2001-03-06 | Oracle Corporation | Planned session termination for clients accessing a resource through a server |
| US6490610B1 (en) | 1997-05-30 | 2002-12-03 | Oracle Corporation | Automatic failover for clients accessing a resource through a server |
| JP3589863B2 (ja) * | 1997-07-23 | 2004-11-17 | 株式会社日立製作所 | 構造体および摩擦攪拌接合方法 |
| US5991810A (en) * | 1997-08-01 | 1999-11-23 | Novell, Inc. | User name authentication for gateway clients accessing a proxy cache server |
| US6061796A (en) * | 1997-08-26 | 2000-05-09 | V-One Corporation | Multi-access virtual private network |
| US6288739B1 (en) * | 1997-09-05 | 2001-09-11 | Intelect Systems Corporation | Distributed video communications system |
| US6141749A (en) * | 1997-09-12 | 2000-10-31 | Lucent Technologies Inc. | Methods and apparatus for a computer network firewall with stateful packet filtering |
| US6094485A (en) * | 1997-09-18 | 2000-07-25 | Netscape Communications Corporation | SSL step-up |
| US6119230A (en) | 1997-10-01 | 2000-09-12 | Novell, Inc. | Distributed dynamic security capabilities |
| US5996086A (en) | 1997-10-14 | 1999-11-30 | Lsi Logic Corporation | Context-based failover architecture for redundant servers |
| US6145089A (en) | 1997-11-10 | 2000-11-07 | Legato Systems, Inc. | Server fail-over system |
| US6148405A (en) * | 1997-11-10 | 2000-11-14 | Phone.Com, Inc. | Method and system for secure lightweight transactions in wireless data networks |
| US6070245A (en) * | 1997-11-25 | 2000-05-30 | International Business Machines Corporation | Application interface method and system for encryption control |
| US6018805A (en) | 1997-12-15 | 2000-01-25 | Recipio | Transparent recovery of distributed-objects using intelligent proxies |
| US6333983B1 (en) * | 1997-12-16 | 2001-12-25 | International Business Machines Corporation | Method and apparatus for performing strong encryption or decryption data using special encryption functions |
| US6385596B1 (en) * | 1998-02-06 | 2002-05-07 | Liquid Audio, Inc. | Secure online music distribution system |
| US6263437B1 (en) * | 1998-02-19 | 2001-07-17 | Openware Systems Inc | Method and apparatus for conducting crypto-ignition processes between thin client devices and server devices over data networks |
| US5974144A (en) * | 1998-02-25 | 1999-10-26 | Cipheractive Ltd. | System for encryption of partitioned data blocks utilizing public key methods and random numbers |
| US6185695B1 (en) | 1998-04-09 | 2001-02-06 | Sun Microsystems, Inc. | Method and apparatus for transparent server failover for highly available objects |
| US6185567B1 (en) * | 1998-05-29 | 2001-02-06 | The Trustees Of The University Of Pennsylvania | Authenticated access to internet based research and data services |
| US7025209B2 (en) * | 1998-05-29 | 2006-04-11 | Palmsource, Inc. | Method and apparatus for wireless internet access |
| US6505253B1 (en) * | 1998-06-30 | 2003-01-07 | Sun Microsystems | Multiple ACK windows providing congestion control in reliable multicast protocol |
| US6816968B1 (en) * | 1998-07-10 | 2004-11-09 | Silverbrook Research Pty Ltd | Consumable authentication protocol and system |
| US6119244A (en) | 1998-08-25 | 2000-09-12 | Network Appliance, Inc. | Coordinating persistent status information with multiple file servers |
| US6351539B1 (en) * | 1998-09-18 | 2002-02-26 | Integrated Device Technology, Inc. | Cipher mixer with random number generator |
| US6317831B1 (en) * | 1998-09-21 | 2001-11-13 | Openwave Systems Inc. | Method and apparatus for establishing a secure connection over a one-way data path |
| US6178441B1 (en) | 1998-09-21 | 2001-01-23 | International Business Machines Corporation | Method and system in a computer network for the reliable and consistent ordering of client requests |
| US6606663B1 (en) * | 1998-09-29 | 2003-08-12 | Openwave Systems Inc. | Method and apparatus for caching credentials in proxy servers for wireless user agents |
| US6519636B2 (en) * | 1998-10-28 | 2003-02-11 | International Business Machines Corporation | Efficient classification, manipulation, and control of network transmissions by associating network flows with rule based functions |
| US6502135B1 (en) * | 1998-10-30 | 2002-12-31 | Science Applications International Corporation | Agile network protocol for secure communications with assured system availability |
| US6826616B2 (en) * | 1998-10-30 | 2004-11-30 | Science Applications International Corp. | Method for establishing secure communication link between computers of virtual private network |
| US6275588B1 (en) * | 1998-11-12 | 2001-08-14 | I-Data International A/S | Apparatus and method for performing and controlling encryption/decryption for data to be transmitted on local area network |
| US6006259A (en) * | 1998-11-20 | 1999-12-21 | Network Alchemy, Inc. | Method and apparatus for an internet protocol (IP) network clustering system |
| US6078957A (en) * | 1998-11-20 | 2000-06-20 | Network Alchemy, Inc. | Method and apparatus for a TCP/IP load balancing and failover process in an internet protocol (IP) network clustering system |
| US6643260B1 (en) * | 1998-12-18 | 2003-11-04 | Cisco Technology, Inc. | Method and apparatus for implementing a quality of service policy in a data communications network |
| US7430757B1 (en) * | 1999-01-08 | 2008-09-30 | International Business Machines Corporation | Oblivious proxying using a secure coprocessor |
| US20030167403A1 (en) * | 1999-03-02 | 2003-09-04 | Mccurley Kevin Snow | Secure user-level tunnels on the internet |
| US6415031B1 (en) * | 1999-03-12 | 2002-07-02 | Diva Systems Corporation | Selective and renewable encryption for secure distribution of video on-demand |
| US6192417B1 (en) * | 1999-03-30 | 2001-02-20 | International Business Machines Corporation | Multicast cluster servicer for communicating amongst a plurality of nodes without a dedicated local area network |
| US6792424B1 (en) * | 1999-04-23 | 2004-09-14 | International Business Machines Corporation | System and method for managing authentication and coherency in a storage area network |
| US7197547B1 (en) | 1999-05-11 | 2007-03-27 | Andrew Karl Miller | Load balancing technique implemented in a data network device utilizing a data cache |
| EP1063811B1 (en) * | 1999-06-22 | 2008-08-06 | Hitachi, Ltd. | Cryptographic apparatus and method |
| US6505192B1 (en) * | 1999-08-12 | 2003-01-07 | International Business Machines Corporation | Security rule processing for connectionless protocols |
| US6754832B1 (en) * | 1999-08-12 | 2004-06-22 | International Business Machines Corporation | Security rule database searching in a network security environment |
| US6775772B1 (en) * | 1999-10-12 | 2004-08-10 | International Business Machines Corporation | Piggy-backed key exchange protocol for providing secure low-overhead browser connections from a client to a server using a trusted third party |
| US6449719B1 (en) * | 1999-11-09 | 2002-09-10 | Widevine Technologies, Inc. | Process and streaming server for encrypting a data stream |
| US7526533B1 (en) | 1999-11-30 | 2009-04-28 | Cisco Technology, Inc. | Active call context reconstruction for primary/backup resource manager servers |
| US20020073167A1 (en) | 1999-12-08 | 2002-06-13 | Powell Kyle E. | Internet content delivery acceleration system employing a hybrid content selection scheme |
| US6832316B1 (en) * | 1999-12-22 | 2004-12-14 | Intertrust Technologies, Corp. | Systems and methods for protecting data secrecy and integrity |
| US7954144B1 (en) | 2000-01-18 | 2011-05-31 | Novell, Inc. | Brokering state information and identity among user agents, origin servers, and proxies |
| US7024692B1 (en) * | 2000-01-21 | 2006-04-04 | Unisys Corporation | Non pre-authenticated kerberos logon via asynchronous message mechanism |
| US20020023209A1 (en) * | 2000-02-14 | 2002-02-21 | Lateca Computer Inc. N.V.United | Encryption and decryption of digital messages in packet transmitting networks |
| US7058723B2 (en) * | 2000-03-14 | 2006-06-06 | Adaptec, Inc. | Congestion control for internet protocol storage |
| US6947992B1 (en) | 2000-05-01 | 2005-09-20 | International Business Machines Corporation | Maintaining HTTP session affinity in a cluster environment |
| US20020083148A1 (en) | 2000-05-12 | 2002-06-27 | Shaw Venson M. | System and method for sender initiated caching of personalized content |
| US6766373B1 (en) * | 2000-05-31 | 2004-07-20 | International Business Machines Corporation | Dynamic, seamless switching of a network session from one connection route to another |
| US6894976B1 (en) * | 2000-06-15 | 2005-05-17 | Network Appliance, Inc. | Prevention and detection of IP identification wraparound errors |
| US20080040550A1 (en) | 2000-07-07 | 2008-02-14 | Lindner David J | Method and apparatus for providing enhanced access to a lightweight directory access protocol (ldap) directory server |
| EP1305931B1 (en) * | 2000-08-04 | 2006-06-28 | Avaya Technology Corp. | Method and system for demand driven recognition of connection oriented transactions |
| US7046802B2 (en) * | 2000-10-12 | 2006-05-16 | Rogaway Phillip W | Method and apparatus for facilitating efficient authenticated encryption |
| US7304951B2 (en) * | 2000-11-21 | 2007-12-04 | North Carolina State University | Methods and systems for rate-based flow control between a sender and a receiver |
| US20020099829A1 (en) | 2000-11-27 | 2002-07-25 | Richards Kenneth W. | Filter proxy system and method |
| US6931128B2 (en) * | 2001-01-16 | 2005-08-16 | Microsoft Corporation | Methods and systems for generating encryption keys using random bit generators |
| US7360075B2 (en) | 2001-02-12 | 2008-04-15 | Aventail Corporation, A Wholly Owned Subsidiary Of Sonicwall, Inc. | Method and apparatus for providing secure streaming data transmission facilities using unreliable protocols |
| US7353380B2 (en) | 2001-02-12 | 2008-04-01 | Aventail, Llc, A Subsidiary Of Sonicwall, Inc. | Method and apparatus for providing secure streaming data transmission facilities using unreliable protocols |
| US7383329B2 (en) | 2001-02-13 | 2008-06-03 | Aventail, Llc | Distributed cache for state transfer operations |
| US7269736B2 (en) * | 2001-02-28 | 2007-09-11 | Microsoft Corporation | Distributed cryptographic methods and arrangements |
| US7870258B2 (en) | 2001-08-08 | 2011-01-11 | Microsoft Corporation | Seamless fail-over support for virtual interface architecture (VIA) or the like |
| US7028089B2 (en) | 2001-09-21 | 2006-04-11 | International Business Machines Corporation | Method and apparatus for caching subscribed and non-subscribed content in a network data processing system |
| US7631084B2 (en) * | 2001-11-02 | 2009-12-08 | Juniper Networks, Inc. | Method and system for providing secure access to private networks with client redirection |
| US7149809B2 (en) | 2001-11-13 | 2006-12-12 | One Touch Systems | System for reducing server loading during content delivery |
| US7296077B2 (en) | 2002-12-12 | 2007-11-13 | International Business Machines Corporation | Method and system for web-based switch-user operation |
| US7346925B2 (en) | 2003-12-11 | 2008-03-18 | Microsoft Corporation | Firewall tunneling and security service |
| US20050273849A1 (en) * | 2004-03-11 | 2005-12-08 | Aep Networks | Network access using secure tunnel |
| US7665127B1 (en) | 2004-06-30 | 2010-02-16 | Jp Morgan Chase Bank | System and method for providing access to protected services |
| US20060155857A1 (en) | 2005-01-06 | 2006-07-13 | Oracle International Corporation | Deterministic session state management within a global cache array |
| US20060291452A1 (en) * | 2005-06-24 | 2006-12-28 | Motorola, Inc. | Method and apparatus for providing reliable communications over an unreliable communications channel |
| CA2513016A1 (en) | 2005-07-22 | 2007-01-22 | Research In Motion Limited | A secure method of synchronizing cache contents of a mobile browser with a proxy server |
| CN101984778B (zh) | 2008-01-26 | 2014-08-13 | 思杰系统有限公司 | 用于细粒度策略驱动的cookie代理的系统和方法 |
| US20120023241A1 (en) | 2010-07-26 | 2012-01-26 | Cisco Technology, Inc. | SSL Cache Session Selection |
| US8762718B2 (en) * | 2012-08-03 | 2014-06-24 | Palo Alto Research Center Incorporated | Broadcast deduplication for satellite broadband |
-
2001
- 2001-02-13 US US09/783,146 patent/US7360075B2/en not_active Expired - Fee Related
-
2002
- 2002-02-08 WO PCT/US2002/003625 patent/WO2002065650A2/en not_active Application Discontinuation
- 2002-02-08 EP EP02703352A patent/EP1362427A2/en not_active Withdrawn
- 2002-02-08 AU AU2002236978A patent/AU2002236978A1/en not_active Abandoned
- 2002-02-08 JP JP2002564846A patent/JP2004525558A/ja active Pending
- 2002-02-08 CA CA002438180A patent/CA2438180A1/en not_active Abandoned
-
2007
- 2007-10-29 US US11/927,362 patent/US7870380B2/en not_active Expired - Fee Related
-
2011
- 2011-01-11 US US13/004,812 patent/US8533457B2/en not_active Expired - Fee Related
-
2013
- 2013-08-19 US US13/970,550 patent/US9467290B2/en not_active Expired - Fee Related
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008538266A (ja) * | 2005-03-10 | 2008-10-16 | インテル コーポレイション | 非互換的トランスポートのセキュリティプロトコル |
| JP4712861B2 (ja) * | 2005-03-10 | 2011-06-29 | インテル コーポレイション | 非互換的トランスポートのセキュリティプロトコル |
| JP2015505994A (ja) * | 2011-12-16 | 2015-02-26 | アカマイ テクノロジーズ インコーポレイテッド | ローカルにアクセス可能な秘密鍵を用いないｓｓｌ接続の終了 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20130346739A1 (en) | 2013-12-26 |
| WO2002065650A2 (en) | 2002-08-22 |
| US8533457B2 (en) | 2013-09-10 |
| WO2002065650A3 (en) | 2003-03-13 |
| CA2438180A1 (en) | 2002-08-22 |
| US20080104390A1 (en) | 2008-05-01 |
| EP1362427A2 (en) | 2003-11-19 |
| US7870380B2 (en) | 2011-01-11 |
| US20110173436A1 (en) | 2011-07-14 |
| US7360075B2 (en) | 2008-04-15 |
| AU2002236978A1 (en) | 2002-08-28 |
| US9467290B2 (en) | 2016-10-11 |
| US20020112152A1 (en) | 2002-08-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004525558A (ja) | 信頼性のないプロトコルを利用して確実なストリーミングデータ送信機能を提供するための方法および装置 | |
| EP3635939B1 (en) | Seamless mobility and session continuity with tcp mobility option | |
| US8984268B2 (en) | Encrypted record transmission | |
| US9813520B2 (en) | Distributed cache for state transfer operations | |
| US8510549B2 (en) | Transmission of packet data over a network with security protocol | |
| US7149892B2 (en) | Secure sockets layer proxy architecture | |
| US7228412B2 (en) | Bufferless secure sockets layer architecture | |
| US7853781B2 (en) | Load balancing secure sockets layer accelerator | |
| US20030014623A1 (en) | Secure sockets layer cut through architecture | |
| Mosko et al. | Mobile sessions in content-centric networks |