通信装置及び通信システム
【課題】 従来、送受信するパケット量を増加させても、必要なメモリ容量が増加させず低コストとし、メモリ帯域の消費量が増加しないで、オフローダの性能を向上させること。
【解決手段】 端末８０１が前記パケット処理装置８００に向けてパケットＡの後にパケットＢを送信し、パケットＡの蓄積をせず、パケットＢの到着順がパケットＡよりも先になった場合のみ、パケットＢを蓄積する受信バッファ８０９を備え、パケットＡの処理終了時に、パケットＢが受信バッファ８０９に蓄積されている場合に、パケットＢを読み出すことで、受信バッファ８０９に読み書きするパケットを到着順に誤りのあるパケットに限定し、受信バッファへのパケットデータの読み書き回数を削減しつつ、端末が送信した順番にパケットの到着順を揃える。
【解決手段】 端末８０１が前記パケット処理装置８００に向けてパケットＡの後にパケットＢを送信し、パケットＡの蓄積をせず、パケットＢの到着順がパケットＡよりも先になった場合のみ、パケットＢを蓄積する受信バッファ８０９を備え、パケットＡの処理終了時に、パケットＢが受信バッファ８０９に蓄積されている場合に、パケットＢを読み出すことで、受信バッファ８０９に読み書きするパケットを到着順に誤りのあるパケットに限定し、受信バッファへのパケットデータの読み書き回数を削減しつつ、端末が送信した順番にパケットの到着順を揃える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置及び通信システムに係り、特に、メッセージ処理を高速化する通信装置及び通信システムに関する。
本発明は、例えば、サーバとクライアントの間に設置され、サーバから受信した平文データを暗号化してクライアントに送信し、クライアントから受信した暗号データを復号化してサーバに送信する通信装置を用いて、サーバの暗号化通信のための演算処理を肩代わりすると共に、サーバとクライアントとの間の暗号化通信を高速化するための技術に関する。
【背景技術】
【０００２】
インターネットを通じた商取引拡大を背景に，ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）／ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）を利用した暗号化通信のニーズが高まっている。
暗号化通信は，サーバと多数のクライアントの間で実施される。サーバに接続するクライアントの数が多くなり，送受信するデータ量が増加すると，サーバへの演算負荷が高まり，処理速度が低下するという課題があった。
そこで、サーバに代わって暗号化通信を終端し，高速にデータを暗号・復号化する機能から成るＴＬＳ／ＳＳＬオフローダ機能を，サーバ前段に配置する通信装置に追加して，サーバの処理速度を向上させる必要がでてきた。
ＴＬＳオフローダ機能付き通信装置として、例えば、特許文献１のようなプロトコル処理装置が用いられる。
本プロトコル処理装置では、全パケットが受信バッファに蓄積される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−２１５０１３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
図１に、ＴＬＳ／ＳＳＬオフローダ機能付き通信装置の概要を示す。
ＴＬＳ／ＳＳＬオフローダ機能付き通信装置（以下、オフローダ）１００は、サーバ１０１とクライアント１０２の間に配置される。
サーバ１０１とオフローダ１００の間には、通常のＴＣＰコネクションが作成される。クライアント１０２とオフローダ１００の間には、ＳＳＬセッション１０４が作成され、その中に複数のＴＣＰコネクションおよびＴＬＳ／ＳＳＬコネクションが作成される。
オフローダ１００は、クライアント１０２とサーバ１０１との間で、ＴＣＰのハンドシェーク処理を仲介する。クライアントからのＳＹＮパケット（接続要求パケット）をサーバ１０１に送信してから、サーバからのＳＹＮ−ＡＣＫパケット（接続要求受取り確認応答パケット）をクライアント１０２に送信し、更に、クライアントからのＡＣＫパケットをサーバ１０１に送信する。
ＴＣＰコネクション確立のシーケンスが完了すると、クライアントとの間でＴＬＳ／ＳＳＬコネクション確立のシーケンス処理を、オフローダ１００がサーバに代わって実行する。
ＴＬＳ／ＳＳＬコネクション確立のシーケンス処理では、まず初めに、クライアント１０２からＣｌｉｅｎｔ Ｈｅｌｌｏメッセージ（利用可能な暗号方式の候補を複数指定）を含むパケットが、サーバに向けて送信される。
オフローダは、Ｃｌｉｅｎｔ Ｈｅｌｌｏパケットを受け取ると、Ｓｅｒｖｅｒ Ｈｅｌｌｏメッセージ（利用する暗号方式を１つ指定）と、公開鍵を含むＣｅｒｔｉｆｉｃａｔｅメッセージと、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを含むパケットをクライアント１０２に送信する。
【０００５】
クライアントは、上記パケットを受信すると、秘密鍵となるプリマスターシークレットを生成し、公開鍵を用いて暗号化する。更に、暗号化したマスターシークレットを含むＫｅｙＥｘｃｈａｎｇｅメッセージと、暗号化通信の開始を通知するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、これまでのメッセージをベリファイするためのＦｉｎｉｓｈｅｄメッセージを含むパケットをサーバ１０１に向けて送信する。なお、ＫｅｙＥｘｃｈａｎｇｅメッセージと、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、Ｆｉｎｉｓｈｅｄメッセージは、同一のパケットに含まれる場合と、別々のパケットに含まれる場合がある。
オフローダ１００は、上記パケットを受け取ると、暗号化通信の開始を通知するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、これまでのメッセージをベリファイするためのＦｉｎｉｓｈｅｄメッセージを含むパケットをクライアント１０２に向けて送信する。
以上記載したＴＬＳ／ＳＳＬコネクション確立のシーケンスが完了すると、ＴＬＳ／ＳＳＬによる暗号化通信が開始される。
なお、クライアントが、もう一つ別のＴＬＳ／ＳＳＬコネクションを作成する際には、ＴＣＰのハンドシェークを行った上で、すでに合意した暗号方式と、すでにやり取りしたマスターシークレットを再利用する旨（以降、セッションの再利用と呼ぶ）を指定したＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを、サーバ１０１に向けて送信する。
オフローダ１００は、セッションの再利用を指定するＣｌｉｅｎｔ Ｈｅｌｌｏメッセージ付パケットを受信すると、Ｓｅｒｖｅｒ Ｈｅｌｌｏメッセージ（利用する暗号方式を１つ指定）と、暗号化通信の開始を通知するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、これまでのメッセージをベリファイするためのＦｉｎｉｓｈｅｄメッセージを含むパケットをクライアントに向けて送信する。公開鍵を含むＣｅｒｔｉｆｉｃａｔｅメッセージは送信されない。
上記パケットを受け取ったクライアントは、暗号化通信の開始を通知するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、これまでのメッセージをベリファイするためのＦｉｎｉｓｈｅｄメッセージを含むパケットをサーバ１０１に向けて送信する。なお、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、Ｆｉｎｉｓｈｅｄメッセージは、同一のパケットに含まれる場合と、別々のパケットに含まれる場合がある。
【０００６】
オフローダ１００が上記Ｆｉｎｉｓｈｅｄメッセージを含むパケットを受け取ると、ＴＬＳ／ＳＳＬコネクションが確立し、暗号化通信が開始される。
ＴＬＳ／ＳＳＬによる暗号化通信では、クライアントからの暗号化パケットが、オフローダ１００によって復号化され、平文パケットがサーバ１０１に向けて送信される。また、サーバからの平文パケットが、オフローダによって復号化され、暗号化パケットがクライアント１０２に向けて送信される。
暗号化通信が完了すると、オフローダ１００は、ＴＣＰコネクションのクローズシーケンスを仲介する。クライアント１０２からのＦＩＮ−ＡＣＫパケット（接続切断要求）をサーバ１０１に送信してから、サーバ１０１からのＦＩＮ−ＡＣＫパケット（接続切断要求への応答）をクライアント１０２に送信し、更に、クライアント１０２からのＡＣＫパケットをサーバ１０１に送信する。
【０００７】
以下に、上記ＴＬＳ／ＳＳＬのシーケンスを、従来型の汎用ＣＰＵを用いた装置において処理する場合の課題について述べる。
上記装置では、汎用ＣＰＵ上で、ＴＣＰ／ＩＰレイヤの処理を行うＴＣＰ／ＩＰレイヤ処理プロセスと、ＴＬＳ／ＳＳＬレイヤの処理を行うＴＬＳ／ＳＳＬメッセージ処理プロセスが実行されている。
ＴＣＰ／ＩＰレイヤ処理プロセスは、ＴＣＰ／ＩＰコネクションが生成される毎に、対となるＴＬＳ／ＳＳＬメッセージ処理プロセスと送信バッファと受信バッファを生成し、受信パケットが含むメッセージをすべて、ＴＬＳ／ＳＳＬメッセージ処理プロセス毎に用意された受信バッファに蓄積する。
ＴＬＳ／ＳＳＬメッセージ処理プロセスは、受信バッファのメッセージを１つずつ読みだして、シーケンシャルに処理を行う。
また、ＴＬＳ／ＳＳＬメッセージ処理プロセスが生成した返信メッセージは全て、プロセス毎に確保された送信バッファに蓄積される。ＴＣＰ／ＩＰレイヤ処理プロセスは、送信バッファのメッセージをＴＣＰ／ＩＰヘッダでカプセル化して、パケットを送信する。
なお、汎用ＣＰＵ上のＴＬＳ／ＳＳＬメッセージ処理プロセスが行う処理の一部を、外部に接続した暗号アクセラレータが肩代わりするケースもある。この場合は、ＴＬＳ／ＳＳＬメッセージ中の一部の暗号化された鍵データや、暗号化データや、平文データや、改竄チェック用のＭＡＣ値が、暗号アクセラレータとの間でやりとりされる。
【０００８】
なお、改竄チェック用のＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｆｉｃａｔｉｏｎ Ｃｏｄｅ：メッセージ認証コード）値とは、例えば、暗号化前のメッセージによるハッシュ値を使って計算する値であり、メッセージを受け取った端末が、通信経路上でメッセージが改竄されていないかを判定するために用いられる。
以上述べてきた従来型の汎用ＣＰＵを用いた装置では、全てのメッセージデータが、受信バッファと送信バッファを必ず往復する。オフローダ１００の性能を向上させるために、送受信するパケット量を増加させると、必要なメモリ容量が増加し高コストとなるだけでなく、メモリ帯域の消費量が増加し、性能が劣化するという課題があった。
【０００９】
本発明は、以上の点に鑑み、到着順に誤りのある一部のパケットのみを受信バッファに読み書きすることで、端末が送信した順番にパケットのメッセージ処理を行うことを実現することを目的とする。
また、本発明は、メッセージ単位ではなくパケット単位での処理を実現することを他の目的とする。
また、本発明は、クライアント送信バッファ及び／又はサーバ送信バッファからのパケット読出し回数の抑制を実現することを他の目的とする。
【課題を解決するための手段】
【００１０】
本発明は、これらの課題を解決するため、例えば、
ＴＣＰコネクション毎に、どこまで受信したかを記録しておくＴＣＰ／ＩＰコネクションテーブルと、
ＴＣＰ／ＩＰコネクションテーブルから、受信パケットに対応するＴＣＰ状態を読出し、受信パケットが、受信済みデータの最後尾直後から後続しているか否かを判定するＴＣＰ状態遷移判定部と、を備える通信装置において、
端末が、パケットＡの後にパケットＢを送信し、
パケットＡの蓄積はせず、パケットＢの到着順がパケットＡよりも先になった場合のみ、パケットＢを蓄積する受信バッファと、
前記ＴＣＰ状態遷移判定部が、パケットＢがパケットＡよりも先に到着したことを検出した場合のみ、パケットＢを受信バッファに蓄積するＡＣＫ不一致パケット処理部と、
メッセージ処理するメッセージ処理部と、
前記メッセージ処理部におけるパケットＡの処理終了時に、パケットＢが受信バッファに蓄積されている場合に、パケットＢを読み出してメッセージ処理部に出力する後続パケット再入力部と、を備え、
到着順に誤りのある一部のパケットのみを受信バッファに読み書きすることで、端末が送信した順番にパケットがメッセージ処理部に到着することを実現する通信装置が提供される。
【００１１】
また、前記通信装置において、
メッセージ処理部がＴＬＳ／ＳＳＬメッセージを処理する場合に、
メッセージ処理部に、１つまたは複数または分割されたＴＬＳ／ＳＳＬメッセージを含むパケットが入力され、どのようなメッセージが含まれるかを判定するための、パケットタイプ判定部を備え、
パケットタイプ判定部の判定結果に基づいて、
入力パケットが、クライアントが送信するハンドシェークメッセージを１つまたは複数含む場合は、受信した１つまたは複数のハンドシェークメッセージに対応するハンドシェークメッセージを含むパケットを作成し、
入力パケットが、サーバが送信する平文データを含むパケットだった場合は、平文データを暗号化したクライアント宛パケットを作成し、
入力パケットが、クライアントが送信する暗号データを含み改竄チェック用のＭＡＣ値を含まないパケットだった場合は、暗号データを複号化したサーバ宛パケットと改竄チェック用のＭＡＣ値の途中結果を作成し、
入力パケットが、クライアントが送信する暗号データを含み改竄チェック用のＭＡＣ値を含むパケットだった場合は、暗号データを複号化したサーバ宛パケットと改竄チェック用のＭＡＣ値を作成し、改竄チェック用のＭＡＣ値の整合性をチェックすることで、
メッセージ単位ではなくパケット単位での処理を実現する。
【００１２】
更に、前記通信装置において、
メッセージ処理部が作成したクライアント宛パケットをＡＣＫ未受信の情報と共に蓄積するクライアント向け送信バッファと、
クライアントから応答ＡＣＫを受信したときに、前記クライアント向け送信バッファの対応するパケットのＡＣＫ未受信の情報をＡＣＫ応答済みの情報に変更し、
重複ＡＣＫを受信したときに、前記クライアント向け送信バッファの対応するパケットを読み出して再送するクライアント送信ＡＣＫ処理部を備えることで、
クライアント送信バッファからのパケット読出し回数の抑制を実現する。
【００１３】
更に、前記通信装置において、
サーバ宛パケットをＡＣＫ未受信およびベリファイ未完了の情報と共に蓄積するサーバ向け送信バッファと、
ＴＬＳ／ＳＳＬメッセージ処理部から、改竄チェック用のＭＡＣ値を含まない復号化済みパケットを受け取ったときに、ＡＣＫ未受信およびベリファイ未完了の情報と共に前記送信バッファに蓄積し、
ＴＬＳ／ＳＳＬメッセージ処理部から、正しい改竄チェック用のＭＡＣ値を含む復号化済みパケットを受け取ったときに、前記送信バッファに蓄積したベリファイ未完了のパケットをベリファイ完了とした上で読み出して送信してから、正しい改竄チェック用のＭＡＣ値を含む復号化済みパケットを送信し、
ＴＬＳ／ＳＳＬメッセージ処理部から、誤った改竄チェック用のＭＡＣ値を含む復号化済みパケットを受け取ったときに、前記送信バッファに蓄積したベリファイ未完了のパケットを消去するサーバ向け平文パケット作成部と、
サーバから、応答ＡＣＫを受信したときに、前記サーバ向け送信バッファの対応するパケットのＡＣＫ未受信の情報をＡＣＫ受信済みに変更し、
サーバから、重複ＡＣＫを受信したときに、前記サーバ向け送信バッファの対応するパケットを読み出して再送するサーバＡＣＫ処理部と、を備えることで、
サーバ送信バッファからのパケット読出し回数の抑制を実現する。
【００１４】
本発明の第１の解決手段によると、
クライアント端末とサーバ端末との間に設置され、前記サーバ端末から受信した平文データを暗号化して前記クライアント端末に送信し、前記クライアント端末から受信した暗号データを復号化して前記サーバ端末に送信するために、暗号化通信のコネクション確立シーケンスを前記サーバ端末に代わって実行するための通信装置において、
端末識別情報に対応して、端末が通信装置に送信してきたデータ量を表すための値である第１端末シーケンス情報と、端末が送信してきたデータのうち、実際に通信装置が受信して確認応答を端末に返信したデータ量を表す第１確認シーケンス情報と、通信装置が端末に送信したデータ量を表すための値である第２端末シーケンス情報と、通信装置が実際に端末からのＡＣＫを受信済みのデータ量である第２確認シーケンス情報と、を含むコネクション状態データを記憶し、コネクション毎にどこまで受信したかを記録するためのコネクション状態テーブルと、
パケットの到着順が逆転した場合に、後に到着すべきパケットを蓄積するための受信バッファと、
前記コネクション状態テーブルから、受信パケットに対応するコネクション状態を読出し、受信パケットが、受信済みデータの最後尾直後から後続しているか否かを判定し、パケットの到着順が逆転した場合に、後に到着すべきパケットを前記受信バッファに蓄積するためのパケット処理部と
を備え、
前記パケット処理部は、
端末から、送信元識別情報、送信シーケンス情報、宛先シーケンス情報、ペイロード長を含む、暗号化通信のコネクション確立のための第１の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第１の受信パケットの送信元識別情報が一致するコネクション状態データを求め、
該コネクション状態データについて、前記端末からの前記第１の受信パケットの送信シーケンス情報Ａと、第１確認シーケンス情報Ａが一致する場合、第１端末シーケンス情報Ａにペイロード長Ｌを加算して Ａ＋Ｌ に更新し、第１確認シーケンス情報Ａにペイロード長Ｌを加算して Ａ＋Ｌ に更新し、シーケンス情報 Ａ＋Ｌ を宛先シーケンス情報としたペイロード長０の第１の送信パケットを、前記端末に向けて送信し、
一方、前記端末から、送信シーケンス情報 Ａ＋Ｌ 及びペイロード長Ｌの第２の受信パケットが送られたが、該第２の受信パケットを受信する前に、続けて前記端末から送信された、送信シーケンス情報 Ａ＋２Ｌ 及びペイロード長Ｌの第３の受信パケットを受信したとき、
前記コネクション状態テーブルを参照し、前記第３の受信パケットに含まれる送信シーケンス情報 Ａ＋２Ｌ と、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ が異なる場合、該第３のパケットのペイロード長が０より大きければ該第３の受信パケットを前記受信バッファに蓄積し、該第３の受信パケットに含まれる送信シーケンス情報 Ａ＋２Ｌ を、第１端末シーケンス情報として前記コネクション状態テーブルを更新し、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ を宛先シーケンス情報としたペイロード長０の第２の送信パケットを作成し、該第２の送信パケットを前記端末に向けて送信し、
前記端末は、前記第２の送信パケットを受け取ると、宛先シーケンス情報 Ａ＋Ｌ により、前記第２の受信パケットが前記通信装置で受信されていないことを判定することにより、前記端末から、送信シーケンス情報を Ａ＋Ｌ 及びペイロード長Ｌの前記第２の受信パケット又は前記第２の受信パケットと同じ内容の第４の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第２又は第４の受信パケットの送信シーケンス情報 Ａ＋Ｌ と、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ が一致することを確認すると、第１確認シーケンス情報 Ａ＋Ｌ に、前記第４の受信パケットのペイロード長Ｌを加算して Ａ＋２Ｌ に更新し、シーケンス情報 Ａ＋２Ｌ を宛先シーケンス情報としたペイロード長０の第３の送信パケットを作成し、該第３の送信パケットを前記端末に向けて送信する
前記通信装置が提供される。
【００１５】
本発明の第２の解決手段によると、
クライアント端末とサーバ端末との間に設置され、前記サーバ端末から受信した平文データを暗号化して前記クライアント端末に送信し、前記クライアント端末から受信した暗号データを復号化して前記サーバ端末に送信するために、暗号化通信のコネクション確立シーケンスを前記サーバ端末に代わって実行するための通信装置において、
端末識別情報に対応して、端末が通信装置に送信してきたデータ量を表すための値である第１端末シーケンス情報と、端末が送信してきたデータのうち、実際に通信装置が受信して確認応答を端末に返信したデータ量を表す第１確認シーケンス情報と、通信装置が端末に送信したデータ量を表すための値である第２端末シーケンス情報と、通信装置が実際に端末からのＡＣＫを受信済みのデータ量である第２確認シーケンス情報と、を含むコネクション状態データを記憶し、コネクション毎にどこまで受信したかを記録するためのコネクション状態テーブルと、
パケットの到着順が逆転した場合に、後に到着すべきパケットを蓄積するための受信バッファと、
前記コネクション状態テーブルから、受信パケットに対応するコネクション状態を読出し、受信パケットが、受信済みデータの最後尾直後から後続しているか否かを判定し、パケットの到着順が逆転した場合に、後に到着すべきパケットを前記受信バッファに蓄積するためのパケット処理部と
を備え、
前記パケット処理部は、
端末へ、送信元識別情報、送信シーケンス情報、宛先シーケンス情報、ペイロード長を含む、暗号化通信のコネクション確立のための第１の送信パケットを送信し、
前記コネクション状態テーブルを参照し、前記第１のパケットの送信元識別情報が一致するコネクション状態データを求め、
該コネクション状態データについて、ペイロード長Ｌの前記第１の送信パケットの送信シーケンス情報Ｂと、第２端末シーケンス情報Ｂが一致する場合、第２端末シーケンス情報Ｂにペイロード長Ｌを加算して Ｂ＋Ｌ に更新し、
前記第１の送信パケットに応答して、前記端末から、宛先シーケンス情報を Ｂ＋Ｌ としたペイロード長０の第１の受信パケットを受け取ると、前記コネクション状態テーブルの第２確認シーケンス情報に、前記第１の受信パケットに含まれる宛先シーケンス情報 Ｂ＋Ｌ を記憶し、
一方、前記端末に向けて、前記コネクション状態テーブルを参照し、第２端末シーケンス情報と同じ送信シーケンス情報 Ｂ＋Ｌ 及びペイロード長Ｌの第２の送信パケットを送り、第２端末シーケンス情報 Ｂ＋Ｌ に、第２の送信パケットのペイロード長Ｌを加算して、Ｂ＋２Ｌ に更新し、
続けて、第２端末シーケンス情報と同じ送信シーケンス情報 Ｂ＋２Ｌ を持つペイロード長Ｌの第３の送信パケットを送り、第２端末シーケンス情報 Ｂ＋２Ｌ に、該第３の送信パケットのペイロード長Ｌを加算し、Ｂ＋３Ｌ に更新し、
前記端末は、前記第２の送信パケットを受け取る前に前記第３の送信パケットを受け取った場合、送信シーケンス情報 Ｂ＋２Ｌ より、その前の前記第２の送信パケットが受信できなかったことを判定することにより、前記端末から送信された、前記第２の送信パケットの再送を促すため、宛先シーケンス情報を Ｂ＋Ｌ としたペイロード長０の第２の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第２の受信パケット又は該第２の受信パケットと同じ内容のパケットを、所定回数連続して受信した場合、前記第２の送信パケットが途中で廃棄されてしまったことを判定し、送信シーケンス情報 Ｂ＋Ｌ 及びペイロード長Ｌの前記第２の送信パケットを再送又は前記第２の送信パケットと同じ内容の第４の送信パケットを送信し、
前記第２又は第４の送信パケットに応答して、前記端末から、宛先シーケンス情報を Ｂ＋３Ｌ としたペイロード長０の第３の受信パケットを受信する
前記通信装置が提供される。
【００１６】
本発明の第３の解決手段によると、
クライアント端末とサーバ端末との間に設置され、前記サーバ端末から受信した平文データを暗号化して前記クライアント端末に送信し、前記クライアント端末から受信した暗号データを復号化して前記サーバ端末に送信するために、暗号化通信のコネクション確立シーケンスを前記サーバ端末に代わって実行するための通信装置を備えた通信システムにおいて、
前記通信装置は、
端末識別情報に対応して、端末が通信装置に送信してきたデータ量を表すための値である第１端末シーケンス情報と、端末が送信してきたデータのうち、実際に通信装置が受信して確認応答を端末に返信したデータ量を表す第１確認シーケンス情報と、通信装置が端末に送信したデータ量を表すための値である第２端末シーケンス情報と、通信装置が実際に端末からのＡＣＫを受信済みのデータ量である第２確認シーケンス情報と、を含むコネクション状態データを記憶し、コネクション毎にどこまで受信したかを記録するためのコネクション状態テーブルと、
パケットの到着順が逆転した場合に、後に到着すべきパケットを蓄積するための受信バッファと、
前記コネクション状態テーブルから、受信パケットに対応するコネクション状態を読出し、受信パケットが、受信済みデータの最後尾直後から後続しているか否かを判定し、パケットの到着順が逆転した場合に、後に到着すべきパケットを前記受信バッファに蓄積するためのパケット処理部と
を備え、
前記パケット処理部は、
端末から、送信元識別情報、送信シーケンス情報、宛先シーケンス情報、ペイロード長を含む、暗号化通信のコネクション確立のための第１の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第１の受信パケットの送信元識別情報が一致するコネクション状態データを求め、
該コネクション状態データについて、前記端末からの前記第１の受信パケットの送信シーケンス情報Ａと、第１確認シーケンス情報Ａが一致する場合、第１端末シーケンス情報Ａにペイロード長Ｌを加算して Ａ＋Ｌ に更新し、第１確認シーケンス情報Ａにペイロード長Ｌを加算して Ａ＋Ｌ に更新し、シーケンス情報 Ａ＋Ｌ を宛先シーケンス情報としたペイロード長０の第１の送信パケットを、前記端末に向けて送信し、
一方、前記端末から、送信シーケンス情報 Ａ＋Ｌ 及びペイロード長Ｌの第２の受信パケットが送られたが、該第２の受信パケットを受信する前に、続けて前記端末から送信された、送信シーケンス情報 Ａ＋２Ｌ 及びペイロード長Ｌの第３の受信パケットを受信したとき、
前記コネクション状態テーブルを参照し、前記第３の受信パケットに含まれる送信シーケンス情報 Ａ＋２Ｌ と、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ が異なる場合、該第３のパケットのペイロード長が０より大きければ該第３の受信パケットを前記受信バッファに蓄積し、該第３の受信パケットに含まれる送信シーケンス情報 Ａ＋２Ｌ を、第１端末シーケンス情報として前記コネクション状態テーブルを更新し、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ を宛先シーケンス情報としたペイロード長０の第２の送信パケットを作成し、該第２の送信パケットを前記端末に向けて送信し、
前記端末は、前記第２の送信パケットを受け取ると、宛先シーケンス情報 Ａ＋Ｌ により、前記第２の受信パケットが前記通信装置で受信されていないことを判定することにより、前記端末から、送信シーケンス情報を Ａ＋Ｌ 及びペイロード長Ｌの前記第２の受信パケット又は前記第２の受信パケットと同じ内容の第４の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第２又は第４の受信パケットの送信シーケンス情報 Ａ＋Ｌ と、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ が一致することを確認すると、第１確認シーケンス情報 Ａ＋Ｌ に、前記第４の受信パケットのペイロード長Ｌを加算して Ａ＋２Ｌ に更新し、シーケンス情報 Ａ＋２Ｌ を宛先シーケンス情報としたペイロード長０の第３の送信パケットを作成し、該第３の送信パケットを前記端末に向けて送信する
前記通信システムが提供される。
【図面の簡単な説明】
【００１７】
【図１】ＴＬＳ／ＳＳＬオフローダの説明図。
【図２】本実施の形態の通信装置が、サーバおよびクライアントとやりとりするパケットのシーケンス図（ＳＳＬの基本シーケンス）（１）。
【図３】本実施の形態の通信装置が、サーバおよびクライアントとやりとりするパケットのシーケンス図（ＳＳＬの基本シーケンス）（２）。
【図４】本実施の形態の通信装置が、サーバおよびクライアントとやりとりするパケットのシーケンス図（ＳＳＬコネクション確立の変則シーケンス）（１）。
【図５】本実施の形態の通信装置が、サーバおよびクライアントとやりとりするパケットのシーケンス図（ＳＳＬコネクション確立の変則シーケンス）（２）。
【図６】本実施の形態の通信装置が、サーバおよびクライアントとやりとりするパケットのシーケンス図。
【図７】本実施の形態の通信装置が、サーバおよびクライアントとやりとりするパケットのシーケンス図。
【図８】本実施の形態の通信装置のアーキテクチャの一例のブロック図。
【図９】本実施の形態の通信装置の一部のブロック図。
【図１０】本実施の形態の通信装置の一部のブロック図。
【図１１】本実施の形態における通信装置とクライアントとサーバの間でやりとりされるパケットフォーマットの説明図。
【図１２】本実施の形態におけるＴＣＰコネクションの状態を格納するテーブルのフォーマットの一例の説明図。
【図１３】本実施の形態の通信装置の一部のブロックにおいて行われる処理のフローチャート図。
【図１４】本実施の形態の通信装置の一部のブロックにおいて行われる処理のフローチャート図。
【図１５】本実施の形態の通信装置の一部のブロックにおいて行われる処理のフローチャート図。
【図１６】本実施の形態の通信装置の一部のブロックにおいて行われる処理のフローチャート図。
【図１７】本実施の形態における通信装置とクライアントとサーバの間でやりとりされるパケットが含むペイロードフォーマットの説明図。
【図１８】本実施の形態の通信装置の一部のブロックにおいて行われる処理のフローチャート図。
【図１９】本実施の形態におけるＴＬＳ／ＳＳＬコネクションの状態を格納するテーブルのフォーマットの一例の説明図。
【図２０】クライアントがペイロード長Ｌのパケットを送信するときの説明図。
【図２１】オフローダがクライアントに向けてペイロード長Ｌのパケットを送信するときの説明図。
【図２２】サーバがペイロード長Ｌのパケットを送信するときの説明図。
【図２３】オフローダがサーバに向けてペイロード長Ｌのパケットを送信するときの説明図。
【図２４】Ｃｌｉｅｎｔ Ｓｅｑと、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑの関係を表す説明図。
【図２５】Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔと、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔの関係を表す説明図。
【図２６】Ｓｅｒｖｅｒ Ｓｅｑと、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑの関係を表す説明図。
【図２７】Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒと、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒの関係を表す説明図。
【図２８】メッセージ処理部のブロック図。
【発明を実施するための形態】
【００１８】
以下、本発明の実施の形態を、図面を用いて説明する。
１．ＴＬＳ／ＳＳＬコネクション確立シーケンス
まず初めに、図２及び図３に、ＴＬＳ／ＳＳＬコネクション確立までのシーケンス処理（ＳＳＬの基本シーケンス）を示す。また、図４及び図５に、ＴＬＳ／ＳＳＬコネクション確立の変則シーケンスを示す。
オフローダ１００は、クライアント１０２とサーバ１０１との間で、ＴＣＰのハンドシェーク処理を仲介する。クライアントからのＳＹＮパケット２００をサーバ１０１に送信してから（２０１）、サーバからのＳＹＮ−ＡＣＫパケット２０２をクライアント１０２に送信し（２０３）、更に、クライアントからのＡＣＫ２０４パケットをサーバ１０１に送信（２０５）する。
ＴＣＰコネクション確立のシーケンスが完了すると、クライアントとの間でＴＬＳ／ＳＳＬコネクション確立のシーケンス処理を、サーバに代わって実行する。
ＴＬＳ／ＳＳＬコネクション確立のシーケンス処理では、まず初めに、クライアント１０２からＣｌｉｅｎｔ Ｈｅｌｌｏメッセージ２０６（利用可能な暗号方式の候補を複数指定）を含むパケットが、サーバに向けて送信される。
オフローダは、Ｃｌｉｅｎｔ Ｈｅｌｌｏパケット２０６を受け取ると、Ｓｅｒｖｅｒ Ｈｅｌｌｏメッセージ（利用する暗号方式を１つ指定）と、公開鍵を含むＣｅｒｔｉｆｉｃａｔｅメッセージと、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを含むパケット２０７をクライアント１０２に送信する。
クライアントは、上記パケットを受信すると、秘密鍵となるマスターシークレットを生成し、公開鍵を用いて暗号化する。更に、暗号化したマスターシークレットを含むＫｅｙＥｘｃｈａｎｇｅメッセージと、暗号化通信の開始を通知するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、これまでのメッセージをベリファイするためのＦｉｎｉｓｈｅｄメッセージを含むパケット２０８をサーバ１０１に向けて送信する。なお、図４及び図５の３０３〜３０５、３０９、３１０、３１４、３１５に示すように、ＫｅｙＥｘｃｈａｎｇｅメッセージと、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、Ｆｉｎｉｓｈｅｄメッセージは、同一のパケットに含まれる場合と、別々のパケットに含まれる場合がある。
オフローダ１００は、上記パケット２０８を受け取ると、暗号化通信の開始を通知するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、これまでのメッセージをベリファイするためのＦｉｎｉｓｈｅｄメッセージを含むパケット２０９をクライアント１０２に向けて送信する。
以上記載したＴＬＳ／ＳＳＬコネクション確立のシーケンスが完了すると、ＴＬＳ／ＳＳＬによる暗号化通信が開始される。
【００１９】
ＴＬＳ／ＳＳＬによる暗号化通信では、クライアントからの暗号化パケット２１３が、オフローダ１００によって復号化され、平文パケット２１４がサーバ１０１に向けて送信される。また、サーバからの平文パケット２１６が、オフローダによって復号化され、暗号化パケット２１５がクライアント１０２に向けて送信される。
暗号化通信が完了すると、オフローダ１００は、ＴＣＰコネクションのクローズシーケンスを仲介する。クライアント１０２からのＦＩＮ−ＡＣＫパケット２１７をサーバ１０１に送信してから（２１８）、サーバ１０１からのＦＩＮ−ＡＣＫパケット２２０をクライアント１０２に送信し（２１９）、更に、クライアント１０２からのＡＣＫパケット２２１をサーバ１０１に送信（２２２）する。
【００２０】
なお、図３に示されるように、クライアントが、もう一つ別のＴＬＳ／ＳＳＬコネクションを作成する際には、ＴＣＰのハンドシェークを行った上で、すでに合意した暗号方式と、すでにやり取りしたマスターシークレットを再利用する旨（以降、セッションの再利用と呼ぶ）を指定したＣｌｉｅｎｔ Ｈｅｌｌｏメッセージ２１０を、サーバ１０１に向けて送信する。
オフローダ１００は、セッションの再利用を指定するＣｌｉｅｎｔ Ｈｅｌｌｏメッセージ付パケット２１０を受信すると、Ｓｅｒｖｅｒ Ｈｅｌｌｏメッセージ（利用する暗号方式を１つ指定）と、暗号化通信の開始を通知するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、これまでのメッセージをベリファイするためのＦｉｎｉｓｈｅｄメッセージを含むパケット２１１をクライアントに向けて送信する。公開鍵を含むＣｅｒｔｉｆｉｃａｔｅメッセージは送信されない。
上記パケットを受け取ったクライアントは、暗号化通信の開始を通知するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、これまでのメッセージをベリファイするためのＦｉｎｉｓｈｅｄメッセージを含むパケット２１２をサーバ１０１に向けて送信する。なお、図５の３１９、３２０等に示すように、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、Ｆｉｎｉｓｈｅｄメッセージは、同一のパケットに含まれる場合と、別々のパケットに含まれる場合がある。
オフローダ１００が上記パケット２１２を受け取ると、ＴＬＳ／ＳＳＬコネクションが確立し、暗号化通信が開始される。
【００２１】
２．オフローダの概要
図８には、本実施の形態のオフローダ８００のアーキテクチャを示す。
オフローダ８００は、クライアントやサーバ等の装置外部とパケットをやり取りするネットワークインターフェース８０２と、パケット処理部８０３と、メモリ８０５と、を備える。
パケット処理部８０３は、ＴＣＰ／ＩＰレイヤ処理部８０７と、ＴＬＳ／ＳＳＬメッセージ処理部８１２と、テーブルサイズ／アドレス範囲指定レジスタ８０６と、暗号アクセラレータ８１４とを備える。
メモリ８０５は、ＴＣＰの状態を管理するＴＣＰコネクションテーブル８０８と、ＡＣＫ不一致の受信パケットのみを蓄積する受信バッファ８０９と、ＡＣＫ未受信のクライアント宛パケットを蓄積するクライアント宛送信バッファ８１０と、ＭＡＣベリファイが未済みでＡＣＫ未受信のサーバ向けパケットを蓄積するサーバ宛送信バッファ８１１と、ＴＬＳ／ＳＳＬの状態を管理するＴＬＳ／ＳＳＬ状態テーブル８１３を、内部に備える。
ＴＣＰ／ＩＰレイヤ処理部８０７と、ＴＬＳ／ＳＳＬメッセージ処理部８１２は、テーブルサイズ／アドレス範囲指定レジスタ８０６記載の値に従って、メモリ８０５のアドレス空間に、ＴＣＰコネクションテーブル８０８と、受信バッファ８０９と、クライアント宛送信バッファ８１０と、サーバ宛送信バッファ８１１と、ＴＬＳ／ＳＳＬ状態テーブル８１３と、の領域を確保する。
図１１には、ネットワークインターフェース８０２が送受信するパケットデータのフォーマットの一例を示す。
パケットデータは、Ｌｅｎ１１００と、Ｐｒｏｔｏ１１０１と、ＳＩＰ１１０２と、ＤＩＰ１１０３と、Ｓｐｏｒｔ１１０４と、Ｄｐｏｒｔ１１０５と、ＳＳｅｑ１１０６と、ＤＳｅｑ１１０７と、Ｆｌａｇ１１０８と、Ｏｔｈｅｒｓ１１０９と、Ｐａｙｌｏａｄ１１１０と、ＤＭＡＣ１１１１と、ＳＭＡＣ１１１２と、Ｔｙｐｅ１１１３とを含む。
Ｌｅｎ１１００は、ＩＰ層のパケット長を格納する。Ｐｒｏｔｏ１１０１は、トランスポート層のプロトコルを識別するための識別番号を格納する。ＳＩＰ１１０２は、送信元アドレス、すなわち、送信側の端末のアドレスである送信元ＩＰアドレスを格納する。ＤＩＰ１１０３は、宛先アドレス、すなわち、受信側の端末のアドレスである宛先ＩＰアドレスを格納する。Ｓｐｏｒｔ１１０４は、ＴＣＰの送信元ポートを格納する。Ｄｐｏｒｔ１１０５は、ＴＣＰの宛先ポートを格納する。ＳＳｅｑ１１０６は、送信元シーケンス番号を格納する。ＤＳｅｑ１１０７は、宛先シーケンス番号を格納する。Ｆｌａｇ１１０８はＴＣＰフラグ番号を格納する。Ｏｔｈｅｒｓ１１０９は、その他のＩＰ／ＴＣＰヘッダデータを格納する。Ｐａｙｌｏａｄ１１１０は、パケットヘッダ以外のデータを格納する。ＤＭＡＣ１１１１は、物理層の宛先ＭＡＣアドレスを格納する。ＳＭＡＣ１１１２は、物理層の送信元ＭＡＣアドレスを格納する。Ｔｙｐｅ１１１３は、パケットデータのタイプを表す。なお、ＭＡＣとは、Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｆｒａｍｅのことをあらわし、物理層を流れるパケットのことをＭＡＣフレームと呼ぶ。ＳＳＬのＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｆｉｃａｔｉｏｎ Ｃｏｄｅ：メッセージ認証コード）とは異なるものである。
【００２２】
また、Ｐａｙｌｏａｄ１１１０が、最大で３つのＴＬＳ／ＳＳＬのメッセージを含むことがある。メッセージ長を格納するＳＳＬ Ｌｅｎ１１１４／１１１８／１１２２と、メッセージタイプを格納するＭｓｇ Ｔｙｐｅ１１１５／１１１９／１１２３と、その他のＳＳＬヘッダデータを格納するＳＳＬ Ｏｔｈｅｒｓ１１１６／１１２０／１１２４と、ＴＬＳ／ＳＳＬメッセージ本体を格納するＳＳＬ Ｍｅｓｓａｇｅ１１１７／１１２１／１１２５とを含む。これらをすべて含む場合もあれば、部分的に含む場合もある。
図１２には、オフローダ１００がクライアント１０２およびサーバ１０１との間で作成するＴＣＰコネクションの状態（以下、ＴＣＰ状態と呼ぶ）を記録するＴＣＰコネクション状態格納テーブル８０８の１エントリに記載されるＴＣＰ状態のフォーマットの一例を示す。
ＴＣＰ状態は、クライアントのＩＰアドレスを格納するＣｌｉｅｎｔ ＩＰ１２０１と、オフローダがクライアント側に対して公開しているＩＰアドレスを格納するＯｆｆｌｏａｄｅｒ ＩＰ ｆｏｒ Ｃｌｉｅｎｔ１２０２と、クライアント１０２のＴＣＰのポート番号を格納するＣｌｉｅｎｔ Ｐｏｒｔ１２０３と、オフローダ１００のクライアント側のＴＣＰのポート番号を格納するＰｏｒｔ ｆｏｒ Ｃｌｉｅｎｔ１２０４と、クライアントが送信してきたデータのシーケンス番号を格納するＣｌｉｅｎｔ Ｓｅｑ１２０５（第１端末シーケンス情報）と、オフローダ１００がクライアント側に向けて送信済みのデータのシーケンス番号を格納するＳｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６（第２端末シーケンス情報）と、クライアントの送信済みデータに対してオフローダ１００がＡＣＫを返信済みのシーケンス番号を格納するＡｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７（第１確認シーケンス情報）と、オフローダ１００がクライアント側に向けて送信済みのデータに対してクライアントがＡＣＫを返信済みのシーケンス番号を格納するＡｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８（第２確認シーケンス情報）と、クライアント１０２とのＴＣＰコネクションの状態を格納するＣｌｉｅｎｔ Ｓｔａｔｅ１２０９と、サーバのＩＰアドレスを格納するＳｅｒｅｒ ＩＰ１２１１と、オフローダがサーバ側に対して公開しているＩＰアドレスを格納するＯｆｆｌｏａｄｅｒ ＩＰ ｆｏｒ Ｓｅｒｅｒ１２１２と、サーバ１０１のＴＣＰのポート番号を格納するＳｅｒｅｒ Ｐｏｒｔ１２１３と、オフローダ１００のサーバ側のＴＣＰポート番号を格納するＰｏｒｔ ｆｏｒ Ｓｅｒｖｅｒ１２１４と、サーバの送信済みデータのシーケンス番号を格納するＳｅｒｖｅｒ Ｓｅｑ１２１５（第１端末シーケンス情報）と、オフローダ１００がサーバ側に向けて送信済みのデータのシーケンス番号を格納するＳｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６（第２端末シーケンス情報）と、サーバの送信済みデータに対してオフローダ１００がＡＣＫを返信済みのシーケンス番号を格納するＡｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７（第１確認シーケンス情報）と、オフローダ１００がサーバ側に向けて送信済みのデータに対してサーバがＡＣＫを返信済みのシーケンス番号を格納するＡｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８（第２確認シーケンス情報）と、サーバ１０１とのＴＣＰコネクションの状態を格納するＳｅｒｖｅｒ Ｓｔａｔｅ１２１９と、を含む。
【００２３】
図２４には、Ｃｌｉｅｎｔ Ｓｅｑ１２０５と、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７の関係を表す説明図を示す。
Ｃｌｉｅｎｔ Ｓｅｑ１２０５は、クライアントがオフローダに送るべきデータ量のうち、クライアントがオフローダに送信してきたデータ量を表すための値である。一方、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７は、クライアントが送信してきたデータのうち、実際にオフローダが受信してＡＣＫをクライアントに返信したデータ量を表す。Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７と、Ｃｌｉｅｎｔ Ｓｅｑ１２０５の差は、クライアントが送信したが、オフローダがまだ受信していないデータ量を表す。
図２５には、Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６と、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８の関係を表す説明図を示す。
Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６は、オフローダがクライアントに送るべきデータ量のうち、オフローダが送信したデータ量を表すための値である。一方、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８は、オフローダが実際にクライアントからのＡＣＫを受信済みのデータ量である。Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６と、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８の差は、オフローダが送信したが、クライアントの受信が確認されていないデータ量を表す。
図２６には、Ｓｅｒｖｅｒ Ｓｅｑ１２１５と、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７の関係を表す説明図を示す。
Ｓｅｒｖｅｒ Ｓｅｑ１２１５は、サーバがオフローダに送るべきデータ量のうち、サーバがオフローダに送信してきたデータ量を表すための値である。一方、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７は、サーバが送信してきたデータのうち、実際にオフローダが受信してＡＣＫをサーバに返信したデータ量を表す。Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７と、Ｓｅｒｖｅｒ Ｓｅｑ１２１５の差は、サーバが送信したが、オフローダがまだ受信していないデータ量を表す。
【００２４】
図２７には、Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６と、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８の関係を表す説明図を示す。
Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６は、オフローダがサーバに送るべきデータ量のうち、オフローダが送信したデータ量を表すための値である。一方、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８は、オフローダが実際にサーバからのＡＣＫを受信済みのデータ量である。Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６と、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｅｒ１２１８の差は、オフローダが送信したが、サーバの受信が確認されていないデータ量を表す。
図２０〜２３には、ＴＣＰ状態に記載されるシーケンス番号（Ｃｌｉｅｎｔ Ｓｅｑ１２０５、Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８、Ｓｅｒｖｅｒ Ｓｅｑ１２１５、Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８）と、パケットに記載されるシーケンス番号との関係を表す説明図を示す。
【００２５】
図２０には、クライアントがペイロード長Ｌのパケットを送信するときの説明図を示す。
オフローダは、クライアントからのパケット２００１の送信シーケンス番号（Ａ）と、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７（Ａ）が一致する場合、Ｃｌｉｅｎｔ Ｓｅｑ１２０５（Ａ）に、ペイロード長Ｌを加算する（２００８）。更に、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７（Ａ）に、ペイロード長Ｌを加算して（２００９）、シーケンス番号（Ａ＋Ｌ）を宛先シーケンス番号としたペイロード長０のパケット２００２を、クライアントに向けて送信する。
次に、クライアントからオフローダに、送信シーケンス番号をＡ＋Ｌとしたペイロード長Ｌのパケット２００３が送られ、途中で廃棄されてしまったとする。
クライアントは、パケット２００３が廃棄されたことが分からないため、続けて、送信シーケンス番号をＡ＋２Ｌとしたペイロード長Ｌのパケット２００４を、オフローダに向けて送信する。
オフローダは、パケット２００４記載の送信シーケンス番号（Ａ＋２Ｌ）と、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７記載のシーケンス番号（Ａ＋Ｌ）が異なる場合、オフローダは、ペイロード長が‘０’より大きければ、パケットを受信バッファ８０９に蓄積する。そしてオフローダは、パケット２００４記載の送信シーケンス番号（Ａ＋２Ｌ）を、Ｃｌｉｅｎｔ Ｓｅｑ１２０５に記載し（２０１０）、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７記載のシーケンス番号（Ａ＋Ｌ）を宛先シーケンス番号としたペイロード長０のパケット２００５を、クライアントに向けて送信する。
クライアントは、パケット２００５を受け取ると、宛先シーケンス番号の値（Ａ＋Ｌ）により、パケット２００３が廃棄されてしまったことを知り、送信シーケンス番号をＡ＋Ｌとしたペイロード長Ｌのパケット２００６（パケット２００３と同じパケット）を、オフローダに向けて再度送信する。
オフローダは、パケット２００６の送信シーケンス番号（Ａ＋Ｌ）と、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７記載のシーケンス番号（Ａ＋Ｌ）が一致することを確認すると、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７記載のシーケンス番号（Ａ＋Ｌ）に、パケット２００６のペイロード長Ｌを加算して（２０１１）、シーケンス番号（Ａ＋２Ｌ）を宛先シーケンス番号としたペイロード長０のパケット２００７を、クライアントに向けて送信する。
【００２６】
図２１には、オフローダがクライアントに向けてペイロード長Ｌのパケットを送信するときの説明図を示す。
オフローダがクライアントに送るペイロード長Ｌのパケット２１０１の送信シーケンス番号（Ｂ）と、Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６（Ｂ）が一致する場合、Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６（Ｂ）に、ペイロード長Ｌを加算する（２１０８）。
その後、オフローダが、クライアントから、宛先シーケンス番号をＢ＋Ｌとしたペイロード長０のパケット２１０２を受け取ると、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８に、パケット記載の宛先シーケンス番号（Ｂ＋Ｌ）を記載する（２１０９）。
次に、オフローダからクライアントに向けて、Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６と同じ送信シーケンス番号（Ｂ＋Ｌ）で送ったペイロード長Ｌのパケット２１０３が、途中で廃棄されてしまったとする。Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６（Ｂ＋Ｌ）には、パケット２１０３のペイロード長Ｌが加算される（２１１０）。
オフローダは、パケット２１０３が途中で廃棄されたことを知らないため、続けて、Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６と同じ送信シーケンス番号（Ｂ＋２Ｌ）を持つペイロード長Ｌのパケット２１０４を送る。Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６（Ｂ＋２Ｌ）には、パケット２１０４のペイロード長Ｌが加算される（２１１１）。
クライアントは、パケット２１０４を受け取ると、送信シーケンス番号の値（Ｂ＋２Ｌ）より、その前のパケット２１０３が途中で廃棄されてしまったことを知る。パケット２１０３の再送をオフローダに促すため、宛先シーケンス番号をＢ＋Ｌとしたペイロード長０のパケット２１０５とパケット２１０６を、オフローダに向けて送信する。
オフローダは、パケット２１０５記載の宛先シーケンス番号が、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８の値と同じパケット２１０５とパケット２１０６を、連続して受け取った場合、パケット２１０３が途中で廃棄されてしまったことを知り、送信シーケンス番号（Ｂ＋Ｌ）でペイロード長Ｌのパケット２１０７（パケット２１０３と同じパケット）を再度送信する。
クライアントは、パケット２１０７を受け取ると、宛先シーケンス番号をＢ＋３Ｌとしたペイロード長０のパケット２１０８を、オフローダに向けて送信する。
【００２７】
図２２には、サーバがペイロード長Ｌのパケットを送信するときの説明図を示す。
オフローダは、サーバからのパケット２２０１の送信シーケンス番号（Ａ）と、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７（Ａ）が一致する場合、Ｓｅｒｖｅｒ Ｓｅｑ１２１５（Ａ）に、ペイロード長Ｌを加算する（２２０８）。更に、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７（Ａ）に、ペイロード長Ｌを加算して（２２０９）、シーケンス番号（Ａ＋Ｌ）を宛先シーケンス番号としたペイロード長０のパケット２２０２を、サーバに向けて送信する。
次に、サーバからオフローダに、送信シーケンス番号をＡ＋Ｌとしたペイロード長Ｌのパケット２２０３が送られ、途中で廃棄されてしまったとする。
サーバは、パケット２２０３が廃棄されたことが分からないため、続けて、送信シーケンス番号をＡ＋２Ｌとしたペイロード長Ｌのパケット２２０４を、オフローダに向けて送信する。
オフローダは、パケット２２０４記載の送信シーケンス番号（Ａ＋２Ｌ）と、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７記載のシーケンス番号（Ａ＋Ｌ）が異なる場合、パケット２２０４記載の送信シーケンス番号（Ａ＋２Ｌ）を、Ｓｅｒｖｅｒ Ｓｅｑ１２１５に記載し（２２１０）、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７記載のシーケンス番号（Ａ＋Ｌ）を宛先シーケンス番号としたペイロード長０のパケット２２０５を、サーバに向けて送信する。
サーバは、パケット２２０５を受け取ると、宛先番号の値（Ａ＋Ｌ）により、パケット２２０３が廃棄されてしまったことを知り、送信シーケンス番号をＡ＋Ｌとしたペイロード長Ｌのパケット２２０６（パケット２２０３と同じパケット）を、オフローダに向けて再度送信する。
オフローダは、パケット２２０６の送信シーケンス番号（Ａ＋Ｌ）と、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７記載のシーケンス番号（Ａ＋Ｌ）が一致することを確認すると、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７記載のシーケンス番号（Ａ＋Ｌ）に、パケット２２０６のペイロード長Ｌを加算して（２２１１）、シーケンス番号（Ａ＋２Ｌ）を宛先シーケンス番号としたペイロード長０のパケット２２０７を、サーバに向けて送信する。
【００２８】
図２３には、オフローダがサーバに向けてペイロード長Ｌのパケットを送信するときの説明図を示す。
オフローダがサーバに送るペイロード長Ｌのパケット２３０１の送信シーケンス番号（Ｂ）と、Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６（Ｂ）が一致する場合、Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６（Ｂ）に、ペイロード長Ｌを加算する（２３０８）。
その後、オフローダが、サーバから、宛先シーケンス番号をＢ＋Ｌとしたペイロード長０のパケット２３０２を受け取ると、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８に、パケット記載の宛先シーケンス番号（Ｂ＋Ｌ）を記載する（２３０９）。
次に、オフローダからサーバに向けて、Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６と同じ送信シーケンス番号（Ｂ＋Ｌ）で送ったペイロード長Ｌのパケット２３０３が、途中で廃棄されてしまったとする。Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６（Ｂ＋Ｌ）には、パケット２３０３のペイロード長Ｌが加算される（２３１０）。
オフローダは、パケット２３０３が途中で廃棄されたことを知らないため、続けて、Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６と同じ送信シーケンス番号（Ｂ＋２Ｌ）を持つペイロード長Ｌのパケット２３０４を送る。Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６（Ｂ＋２Ｌ）には、パケット２３０４のペイロード長Ｌが加算される（２３１１）。
サーバは、パケット２３０４を受け取ると、送信シーケンス番号の値（Ｂ＋２Ｌ）より、その前のパケット２３０３が途中で廃棄されてしまったことを知る。パケット２３０３の再送をオフローダに促すため、宛先シーケンス番号をＢ＋Ｌとしたペイロード長０のパケット２３０５とパケット２３０６を、オフローダに向けて送信する。
オフローダは、パケット２３０５記載の宛先シーケンス番号が、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８の値と同じパケット２３０５とパケット２３０６を、連続して受け取った場合、パケット２３０３が途中で廃棄されてしまったことを知り、送信シーケンス番号（Ｂ＋Ｌ）でペイロード長Ｌのパケット２３０７（パケット２３０３と同じパケット）を再度送信する。
サーバは、パケット２３０７を受け取ると、宛先シーケンス番号をＢ＋３Ｌとしたペイロード長０のパケット２３０８を、オフローダに向けて送信する。
【００２９】
３．ＴＣＰ／ＩＰレイヤ処理部（１／２）
図９には、ＴＣＰ／ＩＰレイヤ処理部８０７の内部のブロック図を示す。
ＴＣＰ／ＩＰレイヤ処理部８０７は、ＴＣＰの状態遷移判定部９０５と、ＡＣＫ不一致パケット処理部９１１と、後続パケット再入力部９２１と、クライアント送信ＡＣＫ処理部９２２と、サーバ送信ＡＣＫ処理部９２４と、サーバ宛平文パケット処理部９２６と、クライアント宛暗号パケット処理部９２７と、を備える。
図１３には、ＴＣＰの状態遷移判定部９０５の実施するフローチャートを示す。
ＴＣＰの状態遷移判定部９０５は、パケット９０１を受信すると、パケット記載のＰｒｏｔｏ１１０１にＴＣＰを表す値が格納されているか否かを確認する（ステップ１３０１）。ＴＣＰを表す値でない場合は廃棄する（ステップ１３０２）。次に、パケット記載の１１０２〜１１０５（送信元アドレス、宛先アドレス、送信元ポート、宛先ポート）と、１２０１〜１２０４または１２１１〜１２１４が一致するエントリが、ＴＣＰコネクション状態格納テーブル８０８に存在するか否かを判定する（ステップ１３０３）。存在しない場合は、受信パケットのＦｌａｇ１１０８がＳＹＮか否かを判定する（ステップ１３１３）。ＳＹＮでない場合は、廃棄する（ステップ１３０４）。ＳＹＮの場合は、新たなエントリ（１２０１〜１２０５にパケットの１１０２〜１１０６を記載した上で、Ｃｌｉｅｎｔ Ｓｅｑ１２０５に‘１’を加算したエントリ）を作成して、ＴＣＰコネクション状態格納テーブル８０８へ書込み（９４８）、ＤＩＰ１１０３とＤｐｏｒｔ１１０５に、サーバのＩＰアドレスとポート番号を記載したサーバ宛ＳＹＮパケット（９４９）を作成する（ステップ１３１４）。ステップ１３０３にて、一致するエントリが存在する場合は、一致するエントリを読み出す（９０７）（ステップ１３０５）。更に、受信パケット記載の１１０２〜１１０５が、読み出したＴＣＰ状態記載の１２０１〜１２０４に一致する場合は、受信パケット記載の送信シーケンス番号１１０６がＴＣＰ状態記載のＡｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７よりも大きいか否かを判定し、一方、受信パケット記載の１１０２２〜１１０５がＴＣＰ状態記載の１２１１〜１２１４に一致する場合は、受信パケット記載の送信シーケンス番号１１０６がＴＣＰ状態記載のＡｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７よりも大きいか否かを判定する（ステップ１３０６）。大きい場合は、ＡＣＫ不一致パケット処理部９１１へとパケットおよび読み出したＴＣＰ状態を送信する（ステップ１３０９）。大きくない場合は、一致するか否かを判定する（ステップ１３０７）。一致しない場合は、廃棄する（ステップ１３０８）。一致する場合は、受信パケットにペイロードデータが存在するか否かを判定する（ステップ１３１０）。存在する場合は、ＴＬＳ／ＳＳＬメッセージ処理部８１２へと、パケットおよび読み出したＴＣＰ状態を送信する（ステップ１３１２）。存在しない場合は、クライアント／サーバ送信ＡＣＫ処理部９２２／９２４へと、パケットおよび読み出したＴＣＰ状態を送信する（ステップ１３１１）。
【００３０】
図１４には、ＡＣＫ不一致パケット処理部９１１の実施するフローチャートを示す。
ＡＣＫ不一致パケット処理部９１１は、ＴＣＰの状態遷移判定部９０５からパケットおよびＴＣＰ状態を受け取ると、パケットのＴＣＰペイロード長が‘０’よりも大きいか否かを判定する（ステップ１４０１）。大きい場合は、パケットを受信バッファ８０９に蓄積する（ステップ１４０２）。更に、パケットの送信シーケンス番号が、ＴＣＰ状態記載のＣｌｉｅｎｔ／Ｓｅｒｖｅｒ Ｓｅｑ１２０５／１２１５よりも大きいか否かを判定する（ステップ１４０３）。大きい場合は、ＴＣＰ状態記載のＣｌｉｅｎｔ／Ｓｅｒｖｅｒ Ｓｅｑ１２０５／１２１５を、パケットの送信シーケンス番号ＳＳｅｑ１１０６へと更新する（ステップ１４０４）。更に、ＴＣＰ状態記載のＡｃｋｅｄ Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ Ｓｅｑ１２０７／１２１７を宛先シーケンス番号とし、Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ１２０６／１２１６を送信元シーケンス番号としたＡＣＫパケットを作成する（ステップ１４０５）。新たに作成したＴＣＰ状態は、ＴＣＰコネクション状態格納テーブル８０８へと書き込む（９１０）。新たに作成したパケットは、集約部９０４へと出力する（９１２）。
以上、ＡＣＫ不一致パケット処理部９１１が、図１４のフローチャートに従って処理することで、到着順が逆転した一部のパケットのみを受信バッファ８０９に書き込むことが可能となる。
また、図１３のステップ１３１２において、パケットとＴＣＰ状態がＴＬＳ／ＳＳＬメッセージ処理部８１２へ転送され、ＴＬＳ／ＳＳＬメッセージ処理部８１２での処理が終了すると、Ａｃｋｅｄ Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ Ｓｅｑ１２０７／１２１７に、ＴＣＰペイロード長を加算して、新たなＴＣＰ状態８３１が作成される。
【００３１】
図１５には、後続パケット再入力部９２１の実施するフローチャートを示す。
後続パケット再入力部９２１は、ＴＣＰ状態８３１を受け取ると、ＴＣＰ状態記載のＡｃｋｅｄ Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ Ｓｅｑ１２０７／１２１７と一致する送信シーケンス番号を持つパケットが、受信バッファ８０９に蓄積されているか否かを判定する（ステップ１５０１）。蓄積されていない場合は終了する（ステップ１５０２）。蓄積されている場合は、受信バッファから前記パケットを読出し（９１７）、受信バッファ８０９から消去する（９１８）。更に、ＴＣＰ状態と読み出したパケットをＴＬＳ／ＳＳＬメッセージ処理部８１２へと出力する（ステップ１５０３）。
図７には、クライアント１０２が送信する暗号化パケットが、オフローダ１００によって復号化され、サーバ１０１に送られるシーケンス図を示す。
クライアント１０２が送信する暗号化パケット７０１は、オフローダのＴＬＳ／ＳＳＬメッセージ処理部８１２において復号化される。復号化された平文パケットは、改竄チェック用のＭＡＣ値を持たない場合、サーバ宛平文パケット処理部９２６において、サーバ宛送信バッファ８１１に蓄積される。更に、ＡＣＫパケット７０２をクライアント１０２に向けて送信する。
クライアント１０２が送信する暗号化パケット７０３が廃棄され、次に送信した暗号化パケット７０４がオフローダ１００に到着した場合、オフローダ１００は、パケット７０３が途中で廃棄されたものとみなし、重複ＡＣＫ７０５、７１７を連続してクライアント１０２へ送信する。クライアントは、重複ＡＣＫ７０５、７１７を２回受け取ると、パケット７０３が途中で廃棄されたことを知り、パケット７０３と同じパケット７０６を再送する。オフローダ１００は、再送パケット７０６を受け取ると、通常のＡＣＫパケット７０７をクライアント１０２へ返信する。
オフローダ１００が、改竄チェック用のＭＡＣ値を持つ暗号化パケット７０８を受け取った場合は、ＴＬＳ／ＳＳＬメッセージ処理部８１２において復号化し、サーバ宛平文パケット処理部９２６において、これまでに蓄積したサーバ宛平文パケットを読み出して送信した（７１２〜７１４）後で、復号化したパケットを送信する（７１５）。
以上、後続パケット再入力部９２１が、図１５のフローチャートに従って処理することで、受信バッファを経由するパケットを、到着順に誤りのある一部のパケットのみに限定しつつ、端末が送信した順番にパケットをＴＬＳ／ＳＳＬメッセージ処理部８１２に到着させることが可能となる。
【００３２】
クライアント宛パケット処理部９２７は、ＴＬＳ／ＳＳＬメッセージ処理部８１２が出力するクライアント宛パケットでＴＣＰペイロード長が０より大きいパケットを、クライアント宛送信バッファ８１０に蓄積した上で、クライアント宛パケットを集約部９０４に出力する（９４１）。更に、ＴＣＰ状態に記載の、オフローダ１００がサーバ側に向けて送信済みのパケットのシーケンス番号を格納するＳｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６を送信シーケンス番号に、サーバの送信済みパケットに対してオフローダ１００がＡＣＫを返信済みのシーケンス番号を格納するＡｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７を宛先シーケンス番号に用いて、サーバ向けのＡＣＫパケットを作成し、集約部９０４に出力する（９４１）。
【００３３】
図１６には、クライアント送信ＡＣＫ処理部９２２の実施するフローチャートを示す。
クライアント送信ＡＣＫ処理部９２２は、クライアントからのＡＣＫパケットを受信すると、受信パケットの宛先シーケンス番号ＤＳｅｑ１１０７が、ＴＣＰ状態記載のＡｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８よりも小さいか否かを判定する（ステップ１６０１）。小さい場合は、処理を終了して、パケットを廃棄する（ステップ１６０２）。大きい場合は、受信パケットの宛先シーケンス番号ＤＳｅｑ１１０７が、ＴＣＰ状態記載のＡｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８よりも大きいか否かを判定する（ステップ１６０３）。大きい場合は、受信パケットの宛先シーケンス番号ＤＳｅｑ１１０７よりも、送信元シーケンス番号が小さなパケットをクライアント宛送信バッファ８１０から削除し、ＴＣＰ状態記載のＡｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８に、受信パケット記載の宛先シーケンス番号ＤＳｅｑ１１０７を記入して、ＴＣＰコネクション状態格納テーブル８０８へ書き込む（９４６）（ステップ１６０４）。一致する場合は、ＴＣＰ状態記載のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９をみて、２回目に一致する重複ＡＣＫの場合か否かを判定する（ステップ１６０５）。２回目に一致する重複ＡＣＫでない場合は、ＴＣＰ状態記載のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９に、１回目に一致する重複ＡＣＫであることを記入する（ステップ１６０６）。２回目に一致する重複ＡＣＫである場合は、受信パケットの宛先シーケンス番号Ｄｓｅｑ１１０７と同一の送信元シーケンス番号を持つパケットをクライアント宛送信バッファ８１０から読み出す（ステップ１６０７）。読み出したパケットは、集約部９０４へと出力される（９４５）。なお、ここでは一例として２回としたが、適宜の回数に設定することができる。
【００３４】
図６には、サーバ１０１が送信する平文パケットが、オフローダ１００によって暗号化され、クライアント１０２に送られるシーケンス図を示す。
サーバが送信する平文パケット６０１／６０４は、オフローダのＴＬＳ／ＳＳＬメッセージ処理部８１２において暗号化される。暗号化されたパケットは、クライアント宛パケット処理部９２７において、クライアント宛送信バッファ８１０に蓄積されると同時に、クライアント１０２に向けて送信される（６０２／６０５）。更に、ＡＣＫパケット６０３／６０６をサーバに向けて送信する。
クライアントは、クライアントに向けて送信された暗号化パケット６０２を受け取ると、ＡＣＫパケット６０７をオフローダに向けて送信する。
クライアントに向けて送信された暗号化パケット６０５が廃棄されると、図２０で説明したように、宛先シーケンス番号がＡＣＫパケット６０７と同じＡＣＫパケット（重複ＡＣＫと呼ぶ）６０８、６０９が送られる。
オフローダは、重複ＡＣＫを２回受け取ったことを判定すると、暗号化パケット６０５が途中で廃棄されたことを知る。クライアント送信ＡＣＫ処理部９２２が、クライアント宛送信バッファ８１０から暗号化パケット６０５を読み出し、暗号化パケット６０５と同じ暗号化パケット６１０を再送する。クライアント送信ＡＣＫ処理部９２２は、１回目の重複ＡＣＫ６０８を受信したとき何も再送せず、２回目の重複ＡＣＫ６０９を受信したときに、クライアント１０２へ暗号化パケット６１０を再送する。クライアント１０２は、暗号化パケット６１０が再送されると、ＡＣＫパケット６１１を返信する。
なお、オフローダ１００は、再送された暗号化パケット６１０に対するＡＣＫパケット６１１を受け取る前・後にかかわらず、サーバ１０１から平文パケット６０４の次の平文パケット６１３を受け取ると、ＴＬＳ／ＳＳＬメッセージ処理部８１２において暗号化したパケット６１３を、クライアント宛パケット処理部９２７において、クライアント宛送信バッファ８１０に蓄積すると同時に、クライアント１０２に向けて送信する。更に、ＡＣＫパケット６１４をサーバに向けて送信する。
以上のように、クライアント送信ＡＣＫ処理部９２２が図１６に示すフローチャートに従って処理することで、クライアント宛送信バッファからのパケット読出しを２回目の重複ＡＣＫを受信したときに限定し、読出し回数を抑制することが可能となる。
【００３５】
４．ＴＬＳ／ＳＳＬメッセージ処理部
図１７には、受信パケットのペイロード１１１０が、複数のＴＬＳ／ＳＳＬメッセージを含むケース（１７０１）、１つのＴＬＳ／ＳＳＬメッセージを含むケース（１７０２）、一部のＴＬＳ／ＳＳＬメッセージを含むケース（１７０３〜１７０５）を示す。
一部のＴＬＳ／ＳＳＬメッセージを含むケース（１７０３〜１７０５）では、ＴＬＳ／ＳＳＬヘッダを除く部分が暗号化されている場合がある。更に、後尾部分を含むケース（１７０５）では、最後尾に改竄チェック用のＭＡＣ値（メッセージが改竄されているか否かを判定するための値）が付加されている。改竄チェック用のＭＡＣ値を計算するためには、先頭部分から後尾部分までのメッセージ全体のハッシュ値が必要であるため、正しいメッセージを受け取ったかどうかを判定するためには、メッセージ最後尾のパケットの到着を待つ必要がある。
図１０には、ＴＬＳ／ＳＳＬメッセージ処理部８１２のブロック図を示す。
ＴＬＳ／ＳＳＬメッセージ処理部８１２は、ＴＬＳ／ＳＳＬ状態格納テーブルから対応するＴＬＳ／ＳＳＬ状態の読出しを行う状態読出し部１００２と、パケットタイプ判定部１００３と、パケットタイプの判定結果に基づいてメッセージの処理を行い返信パケットの作成と新たなＴＬＳ／ＳＳＬ状態の作成を行いＴＬＳ／ＳＳＬ状態格納テーブルへの書込みを行うメッセージ処理部１００９とを備える。
状態読出し部１００２は、ＴＣＰ状態に対応したＴＬＳ／ＳＳＬ状態を、ＴＬＳ／ＳＳＬ状態格納テーブル８１３から読み出す。
図１９には、ＴＬＳ／ＳＳＬ状態格納テーブル８１３の１エントリに記載されるＴＬＳ／ＳＳＬ状態のフォーマットの一例を示す。
ＴＬＳ／ＳＳＬ状態格納テーブル８１３は、ＴＬＳ／ＳＳＬコネクション状態を格納する領域８１３−１と、ＴＬＳ／ＳＳＬセッション状態を格納する領域８１３−２に分割される。
ＴＬＳ／ＳＳＬコネクション状態を格納する領域８１３−１の１エントリは、サーバ側の鍵状態を格納するＳｅｒｖｅｒ Ｋｅｙ１９０１と、クライアント側の鍵状態を格納するＣｌｉｅｎｔ Ｋｅｙ１９０２と、サーバ側のＭＡＣ書込みシークレットを格納するＳｅｒｖｅｒ ＭＡＣ Ｋｅｙ１９０３と、クライアント側のＭＡＣ書込みシークレットを格納するＣｌｉｅｎｔ ＭＡＣ Ｋｅｙ１９０４と、サーバ側のシーケンス番号を格納するＳｅｒｖｅｒ Ｓｅｑ１９０５と、クライアント側のシーケンス番号を格納するＣｌｉｅｎｔ Ｓｅｑ１９０６と、サーバランダムを格納するＳｅｒｖｅｒ Ｒａｎｄｏｍ１９０７と、クライアントランダムを格納するＣｌｉｅｎｔ Ｒａｎｄｏｍ１９０８と、ＶｅｒｉｆｙやＭＡＣなどの途中結果を格納するＩｎｔｅｒｉｍ Ｈａｓｈ１９０９と、セッション状態を格納するエントリへのポインタを格納するＳｅｓｓｉｏｎ Ｐｏｉｎｔｅｒ１９１０を含む。
ＴＬＳ／ＳＳＬセッション状態を格納する領域８１３−２の１エントリは、マスターシークレットを格納するＭａｓｔｅｒ Ｓｅｃｒｅｔ１９１１と、セッションＩＤを格納するＳｅｓｓｉｏｎ ＩＤ１９１２と、暗号方式を格納するＣｉｐｈｅｒ Ｓｕｉｔｅ１９１３とを含む。
【００３６】
パケットタイプ判定部１００３は、ＴＬＳ／ＳＳＬ第１〜３ヘッダタイプ特定部１００４〜１００６とタイプ判定部１００８と、パケットが２つ以上のＴＬＳ／ＳＳＬメッセージをから構成される場合に、２番目のメッセージの位置を判定する第２メッセージ位置判定部１０１０と、パケットが３つ以上のＴＬＳ／ＳＳＬメッセージをから構成される場合に、３番目のメッセージの位置を判定する第３メッセージ位置判定部１０１１とを備える。
第２メッセージ位置判定部１０１０は、ＴＣＰ／ＩＰヘッダ内のＬｅｎ１１００の値が、一番目のＴＬＳ／ＳＳＬヘッダ内のＳＳＬ Ｌｅｎ１１１４の値とＳＳＬヘッダ長とＴＣＰ／ＩＰヘッダ長の和と一致しない場合に、２番目のＴＬＳ／ＳＳＬメッセージの位置を判定して、ＴＬＳ／ＳＳＬ第２ヘッダタイプ特定部１００５に通知する。さらに、ＴＣＰ／ＩＰヘッダ内のＬｅｎ１１００の値と、一番目のＴＬＳ／ＳＳＬヘッダ内のＳＳＬ Ｌｅｎ１１１４の値とＳＳＬヘッダ長とＴＣＰ／ＩＰヘッダ長の和との差を、第３メッセージ位置判定部１０１１へ通知する。
第３メッセージ位置判定部１０１１は、第２メッセージ位置判定部１０１０から通知された差が、２番目のＴＬＳ／ＳＳＬヘッダ内のＳＳＬ Ｌｅｎ１１１８の値とＳＳＬヘッダ長の和と一致しない場合に、３番目のＴＬＳ／ＳＳＬメッセージの位置を判定して、ＴＬＳ／ＳＳＬ第３ヘッダタイプ特定部１００４に通知する。
【００３７】
ＴＬＳ／ＳＳＬ第１〜３ヘッダタイプ特定部１００４〜１００６は、図１７に示すように、ペイロードが最大３つのＴＬＳ／ＳＳＬメッセージを含む場合に、各メッセージのタイプの種類を判定する。ＴＬＳ／ＳＳＬ第１ヘッダタイプ特定部１００６の判定するメッセージタイプは、クライアントが送信するハンドシェークメッセージ（Ｃｌｉｅｎｔ Ｈｅｌｌｏ，ＫｅｙＥｘｃｈａｎｇｅ，ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ，Ｆｉｎｉｓｈｅｄ），サーバが送信する平文データ，クライアントからの暗号データ（先頭部分，中盤，最後尾）（図１７の１７０３〜１７０５のケース）、のいずれかとなる。ＴＬＳ／ＳＳＬ第２ヘッダタイプ特定部１００５の判定するメッセージタイプは、クライアントが送信するハンドシェークメッセージ（ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ，Ｆｉｎｉｓｈｅｄ）のいずれかとなる。ＴＬＳ／ＳＳＬ第３ヘッダタイプ特定部１００４の判定するメッセージタイプは、Ｆｉｎｉｓｈｅｄのみとなる。
タイプ判定部１００８は、ＴＬＳ／ＳＳＬ第２ヘッダタイプ特定部１００５と、ＴＬＳ／ＳＳＬ第３ヘッダタイプ特定部１００４の判定結果を、ＴＬＳ／ＳＳＬ第１ヘッダタイプ特定部１００６の判定結果に統合して、判定結果を出力する。たとえば、ＴＬＳ／ＳＳＬ第１ヘッダタイプ特定部１００６の判定結果がＫｅｙＥｘｃｈａｎｇｅで、ＴＬＳ／ＳＳＬ第２ヘッダタイプ特定部１００５の判定結果が無しの場合、パケットタイプ＝ＫｅｙＥｘｃｈａｎｇｅの判定結果を出力する。ＴＬＳ／ＳＳＬ第１ヘッダタイプ特定部１００６の判定結果がＫｅｙＥｘｃｈａｎｇｅで、ＴＬＳ／ＳＳＬ第２ヘッダタイプ特定部１００５の判定結果がＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃで、ＴＬＳ／ＳＳＬ第３ヘッダタイプ特定部１００５の判定結果が無しの場合、パケットタイプ＝ＫｅｙＥｘｃｈａｎｇｅ＋ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃの判定結果を出力する。ＴＬＳ／ＳＳＬ第１ヘッダタイプ特定部１００６の判定結果がＫｅｙＥｘｃｈａｎｇｅで、ＴＬＳ／ＳＳＬ第２ヘッダタイプ特定部１００５の判定結果がＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃで、ＴＬＳ／ＳＳＬ第３ヘッダタイプ特定部１００５の判定結果がＦｉｎｉｓｈｅｄの場合、パケットタイプ＝ＫｅｙＥｘｃｈａｎｇｅ＋ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ＋Ｆｉｎｉｓｈｅｄの判定結果を出力する。
メッセージ処理部１００９は、パケットタイプ判定部１００３の判定結果に基づいて、ＴＬＳ／ＳＳＬメッセージの処理を行い、クライアントの送信パケットに含まれるハンドシェークメッセージに応じて、新たなＴＬＳ／ＳＳＬ状態およびハンドシェークメッセージを含むパケットを作成する。
【００３８】
図２８には、メッセージ処理部１００９のブロック図を示す。メッセージ処理部１００９は、メッセージの判定結果に応じてパケットと状態情報を振り分ける振り分け部２８０１と、Ｃｌｉｅｎｔ Ｈｅｌｌｏメッセージを含むパケットと状態情報を用いてメッセージの処理を行うＣｌｉｅｎｔ Ｈｅｌｌｏ処理部２８０３と、ＫｅｙＥｘｃｈａｎｇｅメッセージを含むパケットと状態情報を用いてメッセージの処理を行うＫｅｙＥｘｃｈａｎｇｅ処理部２８０４と、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージのみを含むパケットと状態情報を用いてメッセージの処理を行うＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ処理部２８０５と、Ｆｉｎｉｓｈｅｄメッセージを含むパケットと状態情報を用いてメッセージの処理を行うＦｉｎｉｓｈｅｄ処理部２８０６と、Ａｌｅｒｔメッセージを含むパケットと状態情報を用いてメッセージの処理を行うＡｌｅｒｔ処理部２８０７と、暗号メッセージを含むパケットと状態情報を用いてメッセージの処理を行う暗号処理部２８０８と、平文メッセージを含むパケットと状態情報を用いてメッセージの処理を行う平文処理部２８０９と、各処理部から新たに出力されたパケットと状態情報を集約する集約部２８０２と、を備える。
Ｃｌｉｅｎｔ Ｈｅｌｌｏ処理部２８０３は、入力パケットがＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを含む場合、クライアントランダムと暗号スイートを抽出して、作成したサーバランダムと、使用する暗号スイートを指定するＳｅｒｖｅｒ Ｈｅｌｌｏメッセージと、公開鍵を含むＳｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅメッセージと、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを含むパケットを作成する。クライアントランダムとサーバランダムは、ＴＬＳ／ＳＳＬ状態のＣｌｉｅｎｔ Ｒａｎｄｏｍ１９０８とＳｅｒｖｅｒ Ｒａｎｄｏｍ１９０７に書き込まれる。更に、Ｃｌｉｅｎｔ ＨｅｌｌｏメッセージとＳｅｒｖｅｒ Ｈｅｌｌｏメッセージと、Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅメッセージと、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを用いて、ハッシュ値を途中まで計算し、途中結果と端数メッセージをＩｎｔｅｒｉｍ Ｈａｓｈ１９０９に記入する。さらに、状態情報のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９に、Ｃｌｉｅｎｔ Ｈｅｌｌｏメッセージまでを受信したことを表す状態値を格納し、作成済みパケットと、更新した状態情報を集約部２８０２へと出力する。
【００３９】
ＫｅｙＥｘｃｈａｎｇｅ処理部２８０４は、入力パケットがＫｅｙＥｘｃｈａｎｇｅメッセージを含む場合、ＫｅｙＥｘｃｈａｎｇｅメッセージ内の暗号化プリマスターシークレットを復号化し、マスターシークレットと、サーバ側の鍵状態と、クライアント側の鍵状態と、サーバ側のＭＡＣ書込みシークレットと、クライアント側のＭＡＣ書込みシークレットと、を作成する。それぞれ、ＴＬＳ／ＳＳＬ状態のＭａｓｔｅｒ Ｓｅｃｒｅｔ１９１１と、Ｓｅｒｖｅｒ Ｋｅｙ１９０１と、Ｃｌｉｅｎｔ Ｋｅｙ１９０２と、Ｓｅｒｖｅｒ ＭＡＣ Ｋｅｙ１９０３と、Ｃｌｉｅｎｔ ＭＡＣ Ｋｅｙ１９０４へと書き込まれる。更に、ＫｅｙＥｘｃｈａｎｇｅメッセージと、Ｉｎｔｅｒｉｍ Ｈａｓｈ１９０９に記入された途中結果と端数メッセージを用いて、ハッシュ値を途中まで計算し、途中結果と端数メッセージをＩｎｔｅｒｉｍ Ｈａｓｈ１９０９に記入する。また、状態情報のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９に、ＫｅｙＥｘｃｈａｎｇｅメッセージまでを受信したことを表す状態値を格納する。入力パケットが、ＫｅｙＥｘｃｈａｎｇｅメッセージと、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージを含む場合は、状態情報のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９に、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージまでを受信したことを表す状態値を格納する。更に、入力パケットがＫｅｙＥｘｃｈａｎｇｅメッセージとＦｉｎｉｓｈｅｄメッセージの両方を含む場合に、Ｆｉｎｉｓｈｅｄメッセージだけを抽出したパケットと、更新済みの状態情報を、Ｆｉｎｉｓｈｅｄ処理部２８０６へと送る。Ｆｉｎｉｓｈｅｄメッセージを含まない場合は、更新済みの状態情報を集約部２８０２へと出力する。
ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ処理部２８０５は、入力パケットがＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージを含む場合、状態情報のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９に、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージまでを受信したことを表す状態値を格納し、状態情報を集約部２８０２へと出力する。
Ｆｉｎｉｓｈｅｄ処理部２８０６は、入力パケットがＦｉｎｉｓｈｅｄメッセージを含む場合、ＴＬＳ／ＳＳＬ状態のＳｅｒｖｅｒ Ｋｅｙ１９０１を用いて復号化し、ベリファイ値と改竄チェック用のＭＡＣ値を抽出する。更に、Ｉｎｔｅｒｉｍ Ｈａｓｈ１９０９に記入された途中結果と端数メッセージを用いて、ベリファイ値を計算し、Ｆｉｎｉｓｈｅｄ記載のベリファイ値と一致するか否かを判定する。一致しない場合は、Ａｌｅｒｔメッセージを含むパケットを作成する。一致する場合はＦｉｎｉｓｈｅｄメッセージと、Ｉｎｔｅｒｉｍ Ｈａｓｈ１９０９に記入された途中結果と端数メッセージを用いて、ベリファイ値を計算し、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージとＦｉｎｉｓｈｅｄメッセージを含むパケットを作成する。Ｆｉｎｉｓｈｅｄメッセージは、改竄チェック用のＭＡＣ値を計算した上で、暗号化を行う。さらに、状態情報のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９に、Ｆｉｎｉｓｈｅｄメッセージまでを受信したことを表す状態値を格納し、作成済みパケットと、更新した状態情報を集約部２８０２へと出力する。
【００４０】
Ａｌｅｒｔ処理部２８０７は、入力パケットがＡｌｅｒｔメッセージを含む場合、警告メッセージの内容に応じて、ＴＣＰコネクションを終了するためのＦＩＮパケットを作成し、状態情報のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９に、Ａｌｅｒｔメッセージを受信したことを表す状態値を格納し、作成したパケットと、更新した状態情報を集約部２８０２へと出力する。
暗号処理部２８０８は、入力パケットが暗号化データを含むサーバ宛パケットだった場合は、ＴＬＳ／ＳＳＬ状態のＳｅｒｖｅｒ Ｋｅｙ１９０１を用いて復号化し、復号化済みの平文を用いて改竄チェック用のＭＡＣ値を計算する。復号化したパケットにＭＡＣ値が含まれる場合は、計算したＭＡＣ値と、パケットに含まれるＭＡＣ値が一致するか否かを判定し、判定結果を表す状態値を、状態情報のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９に格納する。さらに、復号化したパケットと、更新した状態情報を、集約部２８０２へと出力する。
平文処理部２８０９は、入力パケットが平文データを含むクライアント宛パケットだった場合は、平文を用いて改竄チェック用のＭＡＣ値を計算し、平文データに改竄チェック用のＭＡＣ値を追加した上で暗号化したクライアント宛パケットを、新たに作成する。また、入力パケットが改竄チェック用のＭＡＣ値を含まない平文データを暗号化したサーバ宛パケットだった場合は、暗号データを復号化したサーバ宛パケットと改竄チェック用のＭＡＣ値の途中結果を作成する。改竄チェック用のＭＡＣ値の途中結果は、ＴＬＳ／ＳＳＬ状態格納テーブル８１３に蓄積される。さらに、入力パケットが改竄チェック用のＭＡＣ値を含む平文データを暗号化したサーバ宛パケットだった場合は、ＴＬＳ／ＳＳＬ状態格納テーブル８１３に蓄積された改竄チェック用のＭＡＣ値の途中結果を読み出して、暗号データを復号化したサーバ宛パケットと改竄チェック用のＭＡＣ値を作成し、改竄チェック用のＭＡＣ値の整合性をチェックする。
以上のパケットタイプ判定部１００３とメッセージ処理部１００９とを備えることで、ＴＬＳ／ＳＳＬメッセージ処理部８１２は、メッセージ単位ではなくパケット単位で処理することが可能となる。
【００４１】
５．ＴＣＰ／ＩＰレイヤ処理部（２／２）
サーバ宛平文パケット処理部９２６は、ＴＬＳ／ＳＳＬメッセージ処理部８１２が出力するサーバ宛パケットの処理を行う。以下、図９等を参照して説明する。
サーバ宛平文パケット処理部９２６は、ＴＣＰペイロード長が０より大きく、改竄チェック用のＭＡＣ値を含まない復号化済みサーバ宛平文パケットを受け取ったときは、ＭＡＣ未ベリファイの情報と共に、サーバ宛送信バッファ８１１に蓄積する（９３４）。更に、ＴＣＰ状態に記載の、オフローダ１００がクライアント側に向けて送信済みのパケットのシーケンス番号を格納するＳｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６を送信シーケンス番号に、クライアントの送信済みパケットに対してオフローダ１００がＡＣＫを返信済みのシーケンス番号を格納するＡｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７を宛先シーケンス番号に用いて、クライアント向けのＡＣＫパケットを作成する。図７に示すように、クライアントからの暗号パケットＥｎｃｒｙｐｔｅｄ Ｄａｔａ７０１，７０４，７０６に対して、ＡＣＫパケット７０２、７０５、７０７が返信される。
ＴＣＰペイロード長が０より大きく、正しい改竄チェック用のＭＡＣ値を含む復号化済みサーバ宛平文パケットを受け取ったときは、これまで蓄積したＭＡＣ未ベリファイの復号化済みサーバ宛平文パケットを読み出して（９３３）、先に集約部９０４に出力してから、改竄チェック用のＭＡＣ値を含む復号化済みサーバ宛平文パケットを出力する（９４３）。蓄積してあったＭＡＣ未ベリファイ済みの復号化済みサーバ宛平文パケットは、ＭＡＣベリファイ済みに書き換える（９３５）。更に、ＴＣＰ状態に記載の、Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６を送信シーケンス番号に、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７を宛先シーケンス番号に用いて、クライアント向けのＡＣＫパケットを作成する。図７に示すように、平文パケット７１２〜７１５が連続してサーバ１０１に向けて送信され、ＡＣＫパケット７１１がクライアントに返信される。
ＴＣＰペイロード長が０より大きく、誤った改竄チェック用のＭＡＣ値を含む復号化済みサーバ宛平文パケットを受け取ったときは、これまで蓄積したＭＡＣ未ベリファイの復号化済みサーバ宛平文パケットを削除して（９３５）、Ａｌｅｒｔメッセージを含むクライアント宛パケットと、ＴＣＰコネクションの終了を開始するサーバ宛ＦＩＮパケットを作成し、集約部９０４へと出力する。図７に示すように、Ａｌｅｒｔパケット７０９がクライアント１０２に送信され、ＦＩＮパケット７１０がサーバ１０１へと送信される。
【００４２】
図１８には、サーバ送信ＡＣＫ処理部９２４の実施するフローチャートを示す。
サーバ送信ＡＣＫ処理部９２４は、サーバからのＡＣＫパケットを受信すると、受信パケットの宛先シーケンス番号ＤＳｅｑ１１０７が、ＴＣＰ状態記載のＡｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８よりも小さいか否かを判定する（ステップ１８０１）。小さい場合は、処理を終了して、パケットを廃棄する（ステップ１８０２）。大きい場合は、受信パケットの宛先シーケンス番号ＤＳｅｑ１１０７が、ＴＣＰ状態記載のＡｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８よりも大きいか否かを判定する（ステップ１８０３）。大きい場合は、受信パケットの宛先シーケンス番号ＤＳｅｑ１１０７よりも、送信元シーケンス番号が小さなパケットをサーバ宛送信バッファ８１１から削除し、ＴＣＰ状態記載のＡｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８に、受信パケット記載の宛先シーケンス番号ＤＳｅｑ１１０７を記入して、ＴＣＰコネクション状態格納テーブル８０８へ書き込む（９４７）（ステップ１８０４）。一致する場合は、ＴＣＰ状態記載のＳｅｒｖｅｒ Ｓｔａｔｅ１２１９をみて、２回目に一致する重複ＡＣＫの場合か否かを判定する（ステップ１８０５）。２回目に一致する重複ＡＣＫではない場合は、ＴＣＰ状態記載のＳｅｒｖｅｒ Ｓｔａｔｅ１２１９に、１回目に一致する重複ＡＣＫであることを記入する（ステップ１８０６）。２回目に一致する重複ＡＣＫである場合は、受信パケットの宛先シーケンス番号Ｄｓｅｑ１１０７と同一の送信元シーケンス番号を持つパケットをサーバ宛送信バッファ８１１から読み出す（ステップ１８０７）。読み出したパケットは、集約部９０４へと出力される（９５０）。なお、ここでは一例として２回としたが、適宜の回数に設定することができる。
以上のように、サーバ送信ＡＣＫ処理部９２４が図１８に示すフローチャートに従って処理することで、サーバ宛送信バッファからのパケット読出しを２回目の重複ＡＣＫを受信したときに限定し、読出し回数を抑制することが可能となる。
【００４３】
６．追記
本発明では、受信バッファ８０９の、サイズまたはメモリに占めるアドレス範囲を指定するレジスタを備え、外部の端末から、レジスタ値を変更するようにしてもよい。
また、本発明では、クライアント宛送信バッファ８１０の、サイズまたはメモリに占めるアドレス範囲を指定するレジスタを備え、外部の端末から、レジスタ値を変更するようにしてもよい。
また、本発明では、サーバ宛送信バッファ８１１の、サイズまたはメモリに占めるアドレス範囲を指定するレジスタを備え、外部の端末から、レジスタ値を変更するようにしてもよい。
【産業上の利用可能性】
【００４４】
本発明は、ＴＬＳ／ＳＳＬコネクション確立以外にも、各種の暗号化通信のためのコネクション確立に適用することができる。
【符号の説明】
【００４５】
８００…パケット処理装置、８０７…ＴＣＰ／ＩＰレイヤ処理部、９０５…ＴＣＰの状態遷移判定部、９１１…ＡＣＫ不一致パケット処理部、９２１…後続パケット再入力部、９２２…クライアント送信ＡＣＫ処理部、９２４…サーバ送信ＡＣＫ処理部、９２６…サーバ宛平文パケット処理部、９２７…クライアント宛パケット処理部。
【技術分野】
【０００１】
本発明は、通信装置及び通信システムに係り、特に、メッセージ処理を高速化する通信装置及び通信システムに関する。
本発明は、例えば、サーバとクライアントの間に設置され、サーバから受信した平文データを暗号化してクライアントに送信し、クライアントから受信した暗号データを復号化してサーバに送信する通信装置を用いて、サーバの暗号化通信のための演算処理を肩代わりすると共に、サーバとクライアントとの間の暗号化通信を高速化するための技術に関する。
【背景技術】
【０００２】
インターネットを通じた商取引拡大を背景に，ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）／ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）を利用した暗号化通信のニーズが高まっている。
暗号化通信は，サーバと多数のクライアントの間で実施される。サーバに接続するクライアントの数が多くなり，送受信するデータ量が増加すると，サーバへの演算負荷が高まり，処理速度が低下するという課題があった。
そこで、サーバに代わって暗号化通信を終端し，高速にデータを暗号・復号化する機能から成るＴＬＳ／ＳＳＬオフローダ機能を，サーバ前段に配置する通信装置に追加して，サーバの処理速度を向上させる必要がでてきた。
ＴＬＳオフローダ機能付き通信装置として、例えば、特許文献１のようなプロトコル処理装置が用いられる。
本プロトコル処理装置では、全パケットが受信バッファに蓄積される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−２１５０１３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
図１に、ＴＬＳ／ＳＳＬオフローダ機能付き通信装置の概要を示す。
ＴＬＳ／ＳＳＬオフローダ機能付き通信装置（以下、オフローダ）１００は、サーバ１０１とクライアント１０２の間に配置される。
サーバ１０１とオフローダ１００の間には、通常のＴＣＰコネクションが作成される。クライアント１０２とオフローダ１００の間には、ＳＳＬセッション１０４が作成され、その中に複数のＴＣＰコネクションおよびＴＬＳ／ＳＳＬコネクションが作成される。
オフローダ１００は、クライアント１０２とサーバ１０１との間で、ＴＣＰのハンドシェーク処理を仲介する。クライアントからのＳＹＮパケット（接続要求パケット）をサーバ１０１に送信してから、サーバからのＳＹＮ−ＡＣＫパケット（接続要求受取り確認応答パケット）をクライアント１０２に送信し、更に、クライアントからのＡＣＫパケットをサーバ１０１に送信する。
ＴＣＰコネクション確立のシーケンスが完了すると、クライアントとの間でＴＬＳ／ＳＳＬコネクション確立のシーケンス処理を、オフローダ１００がサーバに代わって実行する。
ＴＬＳ／ＳＳＬコネクション確立のシーケンス処理では、まず初めに、クライアント１０２からＣｌｉｅｎｔ Ｈｅｌｌｏメッセージ（利用可能な暗号方式の候補を複数指定）を含むパケットが、サーバに向けて送信される。
オフローダは、Ｃｌｉｅｎｔ Ｈｅｌｌｏパケットを受け取ると、Ｓｅｒｖｅｒ Ｈｅｌｌｏメッセージ（利用する暗号方式を１つ指定）と、公開鍵を含むＣｅｒｔｉｆｉｃａｔｅメッセージと、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを含むパケットをクライアント１０２に送信する。
【０００５】
クライアントは、上記パケットを受信すると、秘密鍵となるプリマスターシークレットを生成し、公開鍵を用いて暗号化する。更に、暗号化したマスターシークレットを含むＫｅｙＥｘｃｈａｎｇｅメッセージと、暗号化通信の開始を通知するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、これまでのメッセージをベリファイするためのＦｉｎｉｓｈｅｄメッセージを含むパケットをサーバ１０１に向けて送信する。なお、ＫｅｙＥｘｃｈａｎｇｅメッセージと、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、Ｆｉｎｉｓｈｅｄメッセージは、同一のパケットに含まれる場合と、別々のパケットに含まれる場合がある。
オフローダ１００は、上記パケットを受け取ると、暗号化通信の開始を通知するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、これまでのメッセージをベリファイするためのＦｉｎｉｓｈｅｄメッセージを含むパケットをクライアント１０２に向けて送信する。
以上記載したＴＬＳ／ＳＳＬコネクション確立のシーケンスが完了すると、ＴＬＳ／ＳＳＬによる暗号化通信が開始される。
なお、クライアントが、もう一つ別のＴＬＳ／ＳＳＬコネクションを作成する際には、ＴＣＰのハンドシェークを行った上で、すでに合意した暗号方式と、すでにやり取りしたマスターシークレットを再利用する旨（以降、セッションの再利用と呼ぶ）を指定したＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを、サーバ１０１に向けて送信する。
オフローダ１００は、セッションの再利用を指定するＣｌｉｅｎｔ Ｈｅｌｌｏメッセージ付パケットを受信すると、Ｓｅｒｖｅｒ Ｈｅｌｌｏメッセージ（利用する暗号方式を１つ指定）と、暗号化通信の開始を通知するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、これまでのメッセージをベリファイするためのＦｉｎｉｓｈｅｄメッセージを含むパケットをクライアントに向けて送信する。公開鍵を含むＣｅｒｔｉｆｉｃａｔｅメッセージは送信されない。
上記パケットを受け取ったクライアントは、暗号化通信の開始を通知するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、これまでのメッセージをベリファイするためのＦｉｎｉｓｈｅｄメッセージを含むパケットをサーバ１０１に向けて送信する。なお、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、Ｆｉｎｉｓｈｅｄメッセージは、同一のパケットに含まれる場合と、別々のパケットに含まれる場合がある。
【０００６】
オフローダ１００が上記Ｆｉｎｉｓｈｅｄメッセージを含むパケットを受け取ると、ＴＬＳ／ＳＳＬコネクションが確立し、暗号化通信が開始される。
ＴＬＳ／ＳＳＬによる暗号化通信では、クライアントからの暗号化パケットが、オフローダ１００によって復号化され、平文パケットがサーバ１０１に向けて送信される。また、サーバからの平文パケットが、オフローダによって復号化され、暗号化パケットがクライアント１０２に向けて送信される。
暗号化通信が完了すると、オフローダ１００は、ＴＣＰコネクションのクローズシーケンスを仲介する。クライアント１０２からのＦＩＮ−ＡＣＫパケット（接続切断要求）をサーバ１０１に送信してから、サーバ１０１からのＦＩＮ−ＡＣＫパケット（接続切断要求への応答）をクライアント１０２に送信し、更に、クライアント１０２からのＡＣＫパケットをサーバ１０１に送信する。
【０００７】
以下に、上記ＴＬＳ／ＳＳＬのシーケンスを、従来型の汎用ＣＰＵを用いた装置において処理する場合の課題について述べる。
上記装置では、汎用ＣＰＵ上で、ＴＣＰ／ＩＰレイヤの処理を行うＴＣＰ／ＩＰレイヤ処理プロセスと、ＴＬＳ／ＳＳＬレイヤの処理を行うＴＬＳ／ＳＳＬメッセージ処理プロセスが実行されている。
ＴＣＰ／ＩＰレイヤ処理プロセスは、ＴＣＰ／ＩＰコネクションが生成される毎に、対となるＴＬＳ／ＳＳＬメッセージ処理プロセスと送信バッファと受信バッファを生成し、受信パケットが含むメッセージをすべて、ＴＬＳ／ＳＳＬメッセージ処理プロセス毎に用意された受信バッファに蓄積する。
ＴＬＳ／ＳＳＬメッセージ処理プロセスは、受信バッファのメッセージを１つずつ読みだして、シーケンシャルに処理を行う。
また、ＴＬＳ／ＳＳＬメッセージ処理プロセスが生成した返信メッセージは全て、プロセス毎に確保された送信バッファに蓄積される。ＴＣＰ／ＩＰレイヤ処理プロセスは、送信バッファのメッセージをＴＣＰ／ＩＰヘッダでカプセル化して、パケットを送信する。
なお、汎用ＣＰＵ上のＴＬＳ／ＳＳＬメッセージ処理プロセスが行う処理の一部を、外部に接続した暗号アクセラレータが肩代わりするケースもある。この場合は、ＴＬＳ／ＳＳＬメッセージ中の一部の暗号化された鍵データや、暗号化データや、平文データや、改竄チェック用のＭＡＣ値が、暗号アクセラレータとの間でやりとりされる。
【０００８】
なお、改竄チェック用のＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｆｉｃａｔｉｏｎ Ｃｏｄｅ：メッセージ認証コード）値とは、例えば、暗号化前のメッセージによるハッシュ値を使って計算する値であり、メッセージを受け取った端末が、通信経路上でメッセージが改竄されていないかを判定するために用いられる。
以上述べてきた従来型の汎用ＣＰＵを用いた装置では、全てのメッセージデータが、受信バッファと送信バッファを必ず往復する。オフローダ１００の性能を向上させるために、送受信するパケット量を増加させると、必要なメモリ容量が増加し高コストとなるだけでなく、メモリ帯域の消費量が増加し、性能が劣化するという課題があった。
【０００９】
本発明は、以上の点に鑑み、到着順に誤りのある一部のパケットのみを受信バッファに読み書きすることで、端末が送信した順番にパケットのメッセージ処理を行うことを実現することを目的とする。
また、本発明は、メッセージ単位ではなくパケット単位での処理を実現することを他の目的とする。
また、本発明は、クライアント送信バッファ及び／又はサーバ送信バッファからのパケット読出し回数の抑制を実現することを他の目的とする。
【課題を解決するための手段】
【００１０】
本発明は、これらの課題を解決するため、例えば、
ＴＣＰコネクション毎に、どこまで受信したかを記録しておくＴＣＰ／ＩＰコネクションテーブルと、
ＴＣＰ／ＩＰコネクションテーブルから、受信パケットに対応するＴＣＰ状態を読出し、受信パケットが、受信済みデータの最後尾直後から後続しているか否かを判定するＴＣＰ状態遷移判定部と、を備える通信装置において、
端末が、パケットＡの後にパケットＢを送信し、
パケットＡの蓄積はせず、パケットＢの到着順がパケットＡよりも先になった場合のみ、パケットＢを蓄積する受信バッファと、
前記ＴＣＰ状態遷移判定部が、パケットＢがパケットＡよりも先に到着したことを検出した場合のみ、パケットＢを受信バッファに蓄積するＡＣＫ不一致パケット処理部と、
メッセージ処理するメッセージ処理部と、
前記メッセージ処理部におけるパケットＡの処理終了時に、パケットＢが受信バッファに蓄積されている場合に、パケットＢを読み出してメッセージ処理部に出力する後続パケット再入力部と、を備え、
到着順に誤りのある一部のパケットのみを受信バッファに読み書きすることで、端末が送信した順番にパケットがメッセージ処理部に到着することを実現する通信装置が提供される。
【００１１】
また、前記通信装置において、
メッセージ処理部がＴＬＳ／ＳＳＬメッセージを処理する場合に、
メッセージ処理部に、１つまたは複数または分割されたＴＬＳ／ＳＳＬメッセージを含むパケットが入力され、どのようなメッセージが含まれるかを判定するための、パケットタイプ判定部を備え、
パケットタイプ判定部の判定結果に基づいて、
入力パケットが、クライアントが送信するハンドシェークメッセージを１つまたは複数含む場合は、受信した１つまたは複数のハンドシェークメッセージに対応するハンドシェークメッセージを含むパケットを作成し、
入力パケットが、サーバが送信する平文データを含むパケットだった場合は、平文データを暗号化したクライアント宛パケットを作成し、
入力パケットが、クライアントが送信する暗号データを含み改竄チェック用のＭＡＣ値を含まないパケットだった場合は、暗号データを複号化したサーバ宛パケットと改竄チェック用のＭＡＣ値の途中結果を作成し、
入力パケットが、クライアントが送信する暗号データを含み改竄チェック用のＭＡＣ値を含むパケットだった場合は、暗号データを複号化したサーバ宛パケットと改竄チェック用のＭＡＣ値を作成し、改竄チェック用のＭＡＣ値の整合性をチェックすることで、
メッセージ単位ではなくパケット単位での処理を実現する。
【００１２】
更に、前記通信装置において、
メッセージ処理部が作成したクライアント宛パケットをＡＣＫ未受信の情報と共に蓄積するクライアント向け送信バッファと、
クライアントから応答ＡＣＫを受信したときに、前記クライアント向け送信バッファの対応するパケットのＡＣＫ未受信の情報をＡＣＫ応答済みの情報に変更し、
重複ＡＣＫを受信したときに、前記クライアント向け送信バッファの対応するパケットを読み出して再送するクライアント送信ＡＣＫ処理部を備えることで、
クライアント送信バッファからのパケット読出し回数の抑制を実現する。
【００１３】
更に、前記通信装置において、
サーバ宛パケットをＡＣＫ未受信およびベリファイ未完了の情報と共に蓄積するサーバ向け送信バッファと、
ＴＬＳ／ＳＳＬメッセージ処理部から、改竄チェック用のＭＡＣ値を含まない復号化済みパケットを受け取ったときに、ＡＣＫ未受信およびベリファイ未完了の情報と共に前記送信バッファに蓄積し、
ＴＬＳ／ＳＳＬメッセージ処理部から、正しい改竄チェック用のＭＡＣ値を含む復号化済みパケットを受け取ったときに、前記送信バッファに蓄積したベリファイ未完了のパケットをベリファイ完了とした上で読み出して送信してから、正しい改竄チェック用のＭＡＣ値を含む復号化済みパケットを送信し、
ＴＬＳ／ＳＳＬメッセージ処理部から、誤った改竄チェック用のＭＡＣ値を含む復号化済みパケットを受け取ったときに、前記送信バッファに蓄積したベリファイ未完了のパケットを消去するサーバ向け平文パケット作成部と、
サーバから、応答ＡＣＫを受信したときに、前記サーバ向け送信バッファの対応するパケットのＡＣＫ未受信の情報をＡＣＫ受信済みに変更し、
サーバから、重複ＡＣＫを受信したときに、前記サーバ向け送信バッファの対応するパケットを読み出して再送するサーバＡＣＫ処理部と、を備えることで、
サーバ送信バッファからのパケット読出し回数の抑制を実現する。
【００１４】
本発明の第１の解決手段によると、
クライアント端末とサーバ端末との間に設置され、前記サーバ端末から受信した平文データを暗号化して前記クライアント端末に送信し、前記クライアント端末から受信した暗号データを復号化して前記サーバ端末に送信するために、暗号化通信のコネクション確立シーケンスを前記サーバ端末に代わって実行するための通信装置において、
端末識別情報に対応して、端末が通信装置に送信してきたデータ量を表すための値である第１端末シーケンス情報と、端末が送信してきたデータのうち、実際に通信装置が受信して確認応答を端末に返信したデータ量を表す第１確認シーケンス情報と、通信装置が端末に送信したデータ量を表すための値である第２端末シーケンス情報と、通信装置が実際に端末からのＡＣＫを受信済みのデータ量である第２確認シーケンス情報と、を含むコネクション状態データを記憶し、コネクション毎にどこまで受信したかを記録するためのコネクション状態テーブルと、
パケットの到着順が逆転した場合に、後に到着すべきパケットを蓄積するための受信バッファと、
前記コネクション状態テーブルから、受信パケットに対応するコネクション状態を読出し、受信パケットが、受信済みデータの最後尾直後から後続しているか否かを判定し、パケットの到着順が逆転した場合に、後に到着すべきパケットを前記受信バッファに蓄積するためのパケット処理部と
を備え、
前記パケット処理部は、
端末から、送信元識別情報、送信シーケンス情報、宛先シーケンス情報、ペイロード長を含む、暗号化通信のコネクション確立のための第１の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第１の受信パケットの送信元識別情報が一致するコネクション状態データを求め、
該コネクション状態データについて、前記端末からの前記第１の受信パケットの送信シーケンス情報Ａと、第１確認シーケンス情報Ａが一致する場合、第１端末シーケンス情報Ａにペイロード長Ｌを加算して Ａ＋Ｌ に更新し、第１確認シーケンス情報Ａにペイロード長Ｌを加算して Ａ＋Ｌ に更新し、シーケンス情報 Ａ＋Ｌ を宛先シーケンス情報としたペイロード長０の第１の送信パケットを、前記端末に向けて送信し、
一方、前記端末から、送信シーケンス情報 Ａ＋Ｌ 及びペイロード長Ｌの第２の受信パケットが送られたが、該第２の受信パケットを受信する前に、続けて前記端末から送信された、送信シーケンス情報 Ａ＋２Ｌ 及びペイロード長Ｌの第３の受信パケットを受信したとき、
前記コネクション状態テーブルを参照し、前記第３の受信パケットに含まれる送信シーケンス情報 Ａ＋２Ｌ と、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ が異なる場合、該第３のパケットのペイロード長が０より大きければ該第３の受信パケットを前記受信バッファに蓄積し、該第３の受信パケットに含まれる送信シーケンス情報 Ａ＋２Ｌ を、第１端末シーケンス情報として前記コネクション状態テーブルを更新し、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ を宛先シーケンス情報としたペイロード長０の第２の送信パケットを作成し、該第２の送信パケットを前記端末に向けて送信し、
前記端末は、前記第２の送信パケットを受け取ると、宛先シーケンス情報 Ａ＋Ｌ により、前記第２の受信パケットが前記通信装置で受信されていないことを判定することにより、前記端末から、送信シーケンス情報を Ａ＋Ｌ 及びペイロード長Ｌの前記第２の受信パケット又は前記第２の受信パケットと同じ内容の第４の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第２又は第４の受信パケットの送信シーケンス情報 Ａ＋Ｌ と、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ が一致することを確認すると、第１確認シーケンス情報 Ａ＋Ｌ に、前記第４の受信パケットのペイロード長Ｌを加算して Ａ＋２Ｌ に更新し、シーケンス情報 Ａ＋２Ｌ を宛先シーケンス情報としたペイロード長０の第３の送信パケットを作成し、該第３の送信パケットを前記端末に向けて送信する
前記通信装置が提供される。
【００１５】
本発明の第２の解決手段によると、
クライアント端末とサーバ端末との間に設置され、前記サーバ端末から受信した平文データを暗号化して前記クライアント端末に送信し、前記クライアント端末から受信した暗号データを復号化して前記サーバ端末に送信するために、暗号化通信のコネクション確立シーケンスを前記サーバ端末に代わって実行するための通信装置において、
端末識別情報に対応して、端末が通信装置に送信してきたデータ量を表すための値である第１端末シーケンス情報と、端末が送信してきたデータのうち、実際に通信装置が受信して確認応答を端末に返信したデータ量を表す第１確認シーケンス情報と、通信装置が端末に送信したデータ量を表すための値である第２端末シーケンス情報と、通信装置が実際に端末からのＡＣＫを受信済みのデータ量である第２確認シーケンス情報と、を含むコネクション状態データを記憶し、コネクション毎にどこまで受信したかを記録するためのコネクション状態テーブルと、
パケットの到着順が逆転した場合に、後に到着すべきパケットを蓄積するための受信バッファと、
前記コネクション状態テーブルから、受信パケットに対応するコネクション状態を読出し、受信パケットが、受信済みデータの最後尾直後から後続しているか否かを判定し、パケットの到着順が逆転した場合に、後に到着すべきパケットを前記受信バッファに蓄積するためのパケット処理部と
を備え、
前記パケット処理部は、
端末へ、送信元識別情報、送信シーケンス情報、宛先シーケンス情報、ペイロード長を含む、暗号化通信のコネクション確立のための第１の送信パケットを送信し、
前記コネクション状態テーブルを参照し、前記第１のパケットの送信元識別情報が一致するコネクション状態データを求め、
該コネクション状態データについて、ペイロード長Ｌの前記第１の送信パケットの送信シーケンス情報Ｂと、第２端末シーケンス情報Ｂが一致する場合、第２端末シーケンス情報Ｂにペイロード長Ｌを加算して Ｂ＋Ｌ に更新し、
前記第１の送信パケットに応答して、前記端末から、宛先シーケンス情報を Ｂ＋Ｌ としたペイロード長０の第１の受信パケットを受け取ると、前記コネクション状態テーブルの第２確認シーケンス情報に、前記第１の受信パケットに含まれる宛先シーケンス情報 Ｂ＋Ｌ を記憶し、
一方、前記端末に向けて、前記コネクション状態テーブルを参照し、第２端末シーケンス情報と同じ送信シーケンス情報 Ｂ＋Ｌ 及びペイロード長Ｌの第２の送信パケットを送り、第２端末シーケンス情報 Ｂ＋Ｌ に、第２の送信パケットのペイロード長Ｌを加算して、Ｂ＋２Ｌ に更新し、
続けて、第２端末シーケンス情報と同じ送信シーケンス情報 Ｂ＋２Ｌ を持つペイロード長Ｌの第３の送信パケットを送り、第２端末シーケンス情報 Ｂ＋２Ｌ に、該第３の送信パケットのペイロード長Ｌを加算し、Ｂ＋３Ｌ に更新し、
前記端末は、前記第２の送信パケットを受け取る前に前記第３の送信パケットを受け取った場合、送信シーケンス情報 Ｂ＋２Ｌ より、その前の前記第２の送信パケットが受信できなかったことを判定することにより、前記端末から送信された、前記第２の送信パケットの再送を促すため、宛先シーケンス情報を Ｂ＋Ｌ としたペイロード長０の第２の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第２の受信パケット又は該第２の受信パケットと同じ内容のパケットを、所定回数連続して受信した場合、前記第２の送信パケットが途中で廃棄されてしまったことを判定し、送信シーケンス情報 Ｂ＋Ｌ 及びペイロード長Ｌの前記第２の送信パケットを再送又は前記第２の送信パケットと同じ内容の第４の送信パケットを送信し、
前記第２又は第４の送信パケットに応答して、前記端末から、宛先シーケンス情報を Ｂ＋３Ｌ としたペイロード長０の第３の受信パケットを受信する
前記通信装置が提供される。
【００１６】
本発明の第３の解決手段によると、
クライアント端末とサーバ端末との間に設置され、前記サーバ端末から受信した平文データを暗号化して前記クライアント端末に送信し、前記クライアント端末から受信した暗号データを復号化して前記サーバ端末に送信するために、暗号化通信のコネクション確立シーケンスを前記サーバ端末に代わって実行するための通信装置を備えた通信システムにおいて、
前記通信装置は、
端末識別情報に対応して、端末が通信装置に送信してきたデータ量を表すための値である第１端末シーケンス情報と、端末が送信してきたデータのうち、実際に通信装置が受信して確認応答を端末に返信したデータ量を表す第１確認シーケンス情報と、通信装置が端末に送信したデータ量を表すための値である第２端末シーケンス情報と、通信装置が実際に端末からのＡＣＫを受信済みのデータ量である第２確認シーケンス情報と、を含むコネクション状態データを記憶し、コネクション毎にどこまで受信したかを記録するためのコネクション状態テーブルと、
パケットの到着順が逆転した場合に、後に到着すべきパケットを蓄積するための受信バッファと、
前記コネクション状態テーブルから、受信パケットに対応するコネクション状態を読出し、受信パケットが、受信済みデータの最後尾直後から後続しているか否かを判定し、パケットの到着順が逆転した場合に、後に到着すべきパケットを前記受信バッファに蓄積するためのパケット処理部と
を備え、
前記パケット処理部は、
端末から、送信元識別情報、送信シーケンス情報、宛先シーケンス情報、ペイロード長を含む、暗号化通信のコネクション確立のための第１の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第１の受信パケットの送信元識別情報が一致するコネクション状態データを求め、
該コネクション状態データについて、前記端末からの前記第１の受信パケットの送信シーケンス情報Ａと、第１確認シーケンス情報Ａが一致する場合、第１端末シーケンス情報Ａにペイロード長Ｌを加算して Ａ＋Ｌ に更新し、第１確認シーケンス情報Ａにペイロード長Ｌを加算して Ａ＋Ｌ に更新し、シーケンス情報 Ａ＋Ｌ を宛先シーケンス情報としたペイロード長０の第１の送信パケットを、前記端末に向けて送信し、
一方、前記端末から、送信シーケンス情報 Ａ＋Ｌ 及びペイロード長Ｌの第２の受信パケットが送られたが、該第２の受信パケットを受信する前に、続けて前記端末から送信された、送信シーケンス情報 Ａ＋２Ｌ 及びペイロード長Ｌの第３の受信パケットを受信したとき、
前記コネクション状態テーブルを参照し、前記第３の受信パケットに含まれる送信シーケンス情報 Ａ＋２Ｌ と、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ が異なる場合、該第３のパケットのペイロード長が０より大きければ該第３の受信パケットを前記受信バッファに蓄積し、該第３の受信パケットに含まれる送信シーケンス情報 Ａ＋２Ｌ を、第１端末シーケンス情報として前記コネクション状態テーブルを更新し、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ を宛先シーケンス情報としたペイロード長０の第２の送信パケットを作成し、該第２の送信パケットを前記端末に向けて送信し、
前記端末は、前記第２の送信パケットを受け取ると、宛先シーケンス情報 Ａ＋Ｌ により、前記第２の受信パケットが前記通信装置で受信されていないことを判定することにより、前記端末から、送信シーケンス情報を Ａ＋Ｌ 及びペイロード長Ｌの前記第２の受信パケット又は前記第２の受信パケットと同じ内容の第４の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第２又は第４の受信パケットの送信シーケンス情報 Ａ＋Ｌ と、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ が一致することを確認すると、第１確認シーケンス情報 Ａ＋Ｌ に、前記第４の受信パケットのペイロード長Ｌを加算して Ａ＋２Ｌ に更新し、シーケンス情報 Ａ＋２Ｌ を宛先シーケンス情報としたペイロード長０の第３の送信パケットを作成し、該第３の送信パケットを前記端末に向けて送信する
前記通信システムが提供される。
【図面の簡単な説明】
【００１７】
【図１】ＴＬＳ／ＳＳＬオフローダの説明図。
【図２】本実施の形態の通信装置が、サーバおよびクライアントとやりとりするパケットのシーケンス図（ＳＳＬの基本シーケンス）（１）。
【図３】本実施の形態の通信装置が、サーバおよびクライアントとやりとりするパケットのシーケンス図（ＳＳＬの基本シーケンス）（２）。
【図４】本実施の形態の通信装置が、サーバおよびクライアントとやりとりするパケットのシーケンス図（ＳＳＬコネクション確立の変則シーケンス）（１）。
【図５】本実施の形態の通信装置が、サーバおよびクライアントとやりとりするパケットのシーケンス図（ＳＳＬコネクション確立の変則シーケンス）（２）。
【図６】本実施の形態の通信装置が、サーバおよびクライアントとやりとりするパケットのシーケンス図。
【図７】本実施の形態の通信装置が、サーバおよびクライアントとやりとりするパケットのシーケンス図。
【図８】本実施の形態の通信装置のアーキテクチャの一例のブロック図。
【図９】本実施の形態の通信装置の一部のブロック図。
【図１０】本実施の形態の通信装置の一部のブロック図。
【図１１】本実施の形態における通信装置とクライアントとサーバの間でやりとりされるパケットフォーマットの説明図。
【図１２】本実施の形態におけるＴＣＰコネクションの状態を格納するテーブルのフォーマットの一例の説明図。
【図１３】本実施の形態の通信装置の一部のブロックにおいて行われる処理のフローチャート図。
【図１４】本実施の形態の通信装置の一部のブロックにおいて行われる処理のフローチャート図。
【図１５】本実施の形態の通信装置の一部のブロックにおいて行われる処理のフローチャート図。
【図１６】本実施の形態の通信装置の一部のブロックにおいて行われる処理のフローチャート図。
【図１７】本実施の形態における通信装置とクライアントとサーバの間でやりとりされるパケットが含むペイロードフォーマットの説明図。
【図１８】本実施の形態の通信装置の一部のブロックにおいて行われる処理のフローチャート図。
【図１９】本実施の形態におけるＴＬＳ／ＳＳＬコネクションの状態を格納するテーブルのフォーマットの一例の説明図。
【図２０】クライアントがペイロード長Ｌのパケットを送信するときの説明図。
【図２１】オフローダがクライアントに向けてペイロード長Ｌのパケットを送信するときの説明図。
【図２２】サーバがペイロード長Ｌのパケットを送信するときの説明図。
【図２３】オフローダがサーバに向けてペイロード長Ｌのパケットを送信するときの説明図。
【図２４】Ｃｌｉｅｎｔ Ｓｅｑと、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑの関係を表す説明図。
【図２５】Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔと、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔの関係を表す説明図。
【図２６】Ｓｅｒｖｅｒ Ｓｅｑと、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑの関係を表す説明図。
【図２７】Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒと、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒの関係を表す説明図。
【図２８】メッセージ処理部のブロック図。
【発明を実施するための形態】
【００１８】
以下、本発明の実施の形態を、図面を用いて説明する。
１．ＴＬＳ／ＳＳＬコネクション確立シーケンス
まず初めに、図２及び図３に、ＴＬＳ／ＳＳＬコネクション確立までのシーケンス処理（ＳＳＬの基本シーケンス）を示す。また、図４及び図５に、ＴＬＳ／ＳＳＬコネクション確立の変則シーケンスを示す。
オフローダ１００は、クライアント１０２とサーバ１０１との間で、ＴＣＰのハンドシェーク処理を仲介する。クライアントからのＳＹＮパケット２００をサーバ１０１に送信してから（２０１）、サーバからのＳＹＮ−ＡＣＫパケット２０２をクライアント１０２に送信し（２０３）、更に、クライアントからのＡＣＫ２０４パケットをサーバ１０１に送信（２０５）する。
ＴＣＰコネクション確立のシーケンスが完了すると、クライアントとの間でＴＬＳ／ＳＳＬコネクション確立のシーケンス処理を、サーバに代わって実行する。
ＴＬＳ／ＳＳＬコネクション確立のシーケンス処理では、まず初めに、クライアント１０２からＣｌｉｅｎｔ Ｈｅｌｌｏメッセージ２０６（利用可能な暗号方式の候補を複数指定）を含むパケットが、サーバに向けて送信される。
オフローダは、Ｃｌｉｅｎｔ Ｈｅｌｌｏパケット２０６を受け取ると、Ｓｅｒｖｅｒ Ｈｅｌｌｏメッセージ（利用する暗号方式を１つ指定）と、公開鍵を含むＣｅｒｔｉｆｉｃａｔｅメッセージと、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを含むパケット２０７をクライアント１０２に送信する。
クライアントは、上記パケットを受信すると、秘密鍵となるマスターシークレットを生成し、公開鍵を用いて暗号化する。更に、暗号化したマスターシークレットを含むＫｅｙＥｘｃｈａｎｇｅメッセージと、暗号化通信の開始を通知するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、これまでのメッセージをベリファイするためのＦｉｎｉｓｈｅｄメッセージを含むパケット２０８をサーバ１０１に向けて送信する。なお、図４及び図５の３０３〜３０５、３０９、３１０、３１４、３１５に示すように、ＫｅｙＥｘｃｈａｎｇｅメッセージと、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、Ｆｉｎｉｓｈｅｄメッセージは、同一のパケットに含まれる場合と、別々のパケットに含まれる場合がある。
オフローダ１００は、上記パケット２０８を受け取ると、暗号化通信の開始を通知するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、これまでのメッセージをベリファイするためのＦｉｎｉｓｈｅｄメッセージを含むパケット２０９をクライアント１０２に向けて送信する。
以上記載したＴＬＳ／ＳＳＬコネクション確立のシーケンスが完了すると、ＴＬＳ／ＳＳＬによる暗号化通信が開始される。
【００１９】
ＴＬＳ／ＳＳＬによる暗号化通信では、クライアントからの暗号化パケット２１３が、オフローダ１００によって復号化され、平文パケット２１４がサーバ１０１に向けて送信される。また、サーバからの平文パケット２１６が、オフローダによって復号化され、暗号化パケット２１５がクライアント１０２に向けて送信される。
暗号化通信が完了すると、オフローダ１００は、ＴＣＰコネクションのクローズシーケンスを仲介する。クライアント１０２からのＦＩＮ−ＡＣＫパケット２１７をサーバ１０１に送信してから（２１８）、サーバ１０１からのＦＩＮ−ＡＣＫパケット２２０をクライアント１０２に送信し（２１９）、更に、クライアント１０２からのＡＣＫパケット２２１をサーバ１０１に送信（２２２）する。
【００２０】
なお、図３に示されるように、クライアントが、もう一つ別のＴＬＳ／ＳＳＬコネクションを作成する際には、ＴＣＰのハンドシェークを行った上で、すでに合意した暗号方式と、すでにやり取りしたマスターシークレットを再利用する旨（以降、セッションの再利用と呼ぶ）を指定したＣｌｉｅｎｔ Ｈｅｌｌｏメッセージ２１０を、サーバ１０１に向けて送信する。
オフローダ１００は、セッションの再利用を指定するＣｌｉｅｎｔ Ｈｅｌｌｏメッセージ付パケット２１０を受信すると、Ｓｅｒｖｅｒ Ｈｅｌｌｏメッセージ（利用する暗号方式を１つ指定）と、暗号化通信の開始を通知するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、これまでのメッセージをベリファイするためのＦｉｎｉｓｈｅｄメッセージを含むパケット２１１をクライアントに向けて送信する。公開鍵を含むＣｅｒｔｉｆｉｃａｔｅメッセージは送信されない。
上記パケットを受け取ったクライアントは、暗号化通信の開始を通知するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、これまでのメッセージをベリファイするためのＦｉｎｉｓｈｅｄメッセージを含むパケット２１２をサーバ１０１に向けて送信する。なお、図５の３１９、３２０等に示すように、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージと、Ｆｉｎｉｓｈｅｄメッセージは、同一のパケットに含まれる場合と、別々のパケットに含まれる場合がある。
オフローダ１００が上記パケット２１２を受け取ると、ＴＬＳ／ＳＳＬコネクションが確立し、暗号化通信が開始される。
【００２１】
２．オフローダの概要
図８には、本実施の形態のオフローダ８００のアーキテクチャを示す。
オフローダ８００は、クライアントやサーバ等の装置外部とパケットをやり取りするネットワークインターフェース８０２と、パケット処理部８０３と、メモリ８０５と、を備える。
パケット処理部８０３は、ＴＣＰ／ＩＰレイヤ処理部８０７と、ＴＬＳ／ＳＳＬメッセージ処理部８１２と、テーブルサイズ／アドレス範囲指定レジスタ８０６と、暗号アクセラレータ８１４とを備える。
メモリ８０５は、ＴＣＰの状態を管理するＴＣＰコネクションテーブル８０８と、ＡＣＫ不一致の受信パケットのみを蓄積する受信バッファ８０９と、ＡＣＫ未受信のクライアント宛パケットを蓄積するクライアント宛送信バッファ８１０と、ＭＡＣベリファイが未済みでＡＣＫ未受信のサーバ向けパケットを蓄積するサーバ宛送信バッファ８１１と、ＴＬＳ／ＳＳＬの状態を管理するＴＬＳ／ＳＳＬ状態テーブル８１３を、内部に備える。
ＴＣＰ／ＩＰレイヤ処理部８０７と、ＴＬＳ／ＳＳＬメッセージ処理部８１２は、テーブルサイズ／アドレス範囲指定レジスタ８０６記載の値に従って、メモリ８０５のアドレス空間に、ＴＣＰコネクションテーブル８０８と、受信バッファ８０９と、クライアント宛送信バッファ８１０と、サーバ宛送信バッファ８１１と、ＴＬＳ／ＳＳＬ状態テーブル８１３と、の領域を確保する。
図１１には、ネットワークインターフェース８０２が送受信するパケットデータのフォーマットの一例を示す。
パケットデータは、Ｌｅｎ１１００と、Ｐｒｏｔｏ１１０１と、ＳＩＰ１１０２と、ＤＩＰ１１０３と、Ｓｐｏｒｔ１１０４と、Ｄｐｏｒｔ１１０５と、ＳＳｅｑ１１０６と、ＤＳｅｑ１１０７と、Ｆｌａｇ１１０８と、Ｏｔｈｅｒｓ１１０９と、Ｐａｙｌｏａｄ１１１０と、ＤＭＡＣ１１１１と、ＳＭＡＣ１１１２と、Ｔｙｐｅ１１１３とを含む。
Ｌｅｎ１１００は、ＩＰ層のパケット長を格納する。Ｐｒｏｔｏ１１０１は、トランスポート層のプロトコルを識別するための識別番号を格納する。ＳＩＰ１１０２は、送信元アドレス、すなわち、送信側の端末のアドレスである送信元ＩＰアドレスを格納する。ＤＩＰ１１０３は、宛先アドレス、すなわち、受信側の端末のアドレスである宛先ＩＰアドレスを格納する。Ｓｐｏｒｔ１１０４は、ＴＣＰの送信元ポートを格納する。Ｄｐｏｒｔ１１０５は、ＴＣＰの宛先ポートを格納する。ＳＳｅｑ１１０６は、送信元シーケンス番号を格納する。ＤＳｅｑ１１０７は、宛先シーケンス番号を格納する。Ｆｌａｇ１１０８はＴＣＰフラグ番号を格納する。Ｏｔｈｅｒｓ１１０９は、その他のＩＰ／ＴＣＰヘッダデータを格納する。Ｐａｙｌｏａｄ１１１０は、パケットヘッダ以外のデータを格納する。ＤＭＡＣ１１１１は、物理層の宛先ＭＡＣアドレスを格納する。ＳＭＡＣ１１１２は、物理層の送信元ＭＡＣアドレスを格納する。Ｔｙｐｅ１１１３は、パケットデータのタイプを表す。なお、ＭＡＣとは、Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｆｒａｍｅのことをあらわし、物理層を流れるパケットのことをＭＡＣフレームと呼ぶ。ＳＳＬのＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｆｉｃａｔｉｏｎ Ｃｏｄｅ：メッセージ認証コード）とは異なるものである。
【００２２】
また、Ｐａｙｌｏａｄ１１１０が、最大で３つのＴＬＳ／ＳＳＬのメッセージを含むことがある。メッセージ長を格納するＳＳＬ Ｌｅｎ１１１４／１１１８／１１２２と、メッセージタイプを格納するＭｓｇ Ｔｙｐｅ１１１５／１１１９／１１２３と、その他のＳＳＬヘッダデータを格納するＳＳＬ Ｏｔｈｅｒｓ１１１６／１１２０／１１２４と、ＴＬＳ／ＳＳＬメッセージ本体を格納するＳＳＬ Ｍｅｓｓａｇｅ１１１７／１１２１／１１２５とを含む。これらをすべて含む場合もあれば、部分的に含む場合もある。
図１２には、オフローダ１００がクライアント１０２およびサーバ１０１との間で作成するＴＣＰコネクションの状態（以下、ＴＣＰ状態と呼ぶ）を記録するＴＣＰコネクション状態格納テーブル８０８の１エントリに記載されるＴＣＰ状態のフォーマットの一例を示す。
ＴＣＰ状態は、クライアントのＩＰアドレスを格納するＣｌｉｅｎｔ ＩＰ１２０１と、オフローダがクライアント側に対して公開しているＩＰアドレスを格納するＯｆｆｌｏａｄｅｒ ＩＰ ｆｏｒ Ｃｌｉｅｎｔ１２０２と、クライアント１０２のＴＣＰのポート番号を格納するＣｌｉｅｎｔ Ｐｏｒｔ１２０３と、オフローダ１００のクライアント側のＴＣＰのポート番号を格納するＰｏｒｔ ｆｏｒ Ｃｌｉｅｎｔ１２０４と、クライアントが送信してきたデータのシーケンス番号を格納するＣｌｉｅｎｔ Ｓｅｑ１２０５（第１端末シーケンス情報）と、オフローダ１００がクライアント側に向けて送信済みのデータのシーケンス番号を格納するＳｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６（第２端末シーケンス情報）と、クライアントの送信済みデータに対してオフローダ１００がＡＣＫを返信済みのシーケンス番号を格納するＡｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７（第１確認シーケンス情報）と、オフローダ１００がクライアント側に向けて送信済みのデータに対してクライアントがＡＣＫを返信済みのシーケンス番号を格納するＡｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８（第２確認シーケンス情報）と、クライアント１０２とのＴＣＰコネクションの状態を格納するＣｌｉｅｎｔ Ｓｔａｔｅ１２０９と、サーバのＩＰアドレスを格納するＳｅｒｅｒ ＩＰ１２１１と、オフローダがサーバ側に対して公開しているＩＰアドレスを格納するＯｆｆｌｏａｄｅｒ ＩＰ ｆｏｒ Ｓｅｒｅｒ１２１２と、サーバ１０１のＴＣＰのポート番号を格納するＳｅｒｅｒ Ｐｏｒｔ１２１３と、オフローダ１００のサーバ側のＴＣＰポート番号を格納するＰｏｒｔ ｆｏｒ Ｓｅｒｖｅｒ１２１４と、サーバの送信済みデータのシーケンス番号を格納するＳｅｒｖｅｒ Ｓｅｑ１２１５（第１端末シーケンス情報）と、オフローダ１００がサーバ側に向けて送信済みのデータのシーケンス番号を格納するＳｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６（第２端末シーケンス情報）と、サーバの送信済みデータに対してオフローダ１００がＡＣＫを返信済みのシーケンス番号を格納するＡｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７（第１確認シーケンス情報）と、オフローダ１００がサーバ側に向けて送信済みのデータに対してサーバがＡＣＫを返信済みのシーケンス番号を格納するＡｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８（第２確認シーケンス情報）と、サーバ１０１とのＴＣＰコネクションの状態を格納するＳｅｒｖｅｒ Ｓｔａｔｅ１２１９と、を含む。
【００２３】
図２４には、Ｃｌｉｅｎｔ Ｓｅｑ１２０５と、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７の関係を表す説明図を示す。
Ｃｌｉｅｎｔ Ｓｅｑ１２０５は、クライアントがオフローダに送るべきデータ量のうち、クライアントがオフローダに送信してきたデータ量を表すための値である。一方、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７は、クライアントが送信してきたデータのうち、実際にオフローダが受信してＡＣＫをクライアントに返信したデータ量を表す。Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７と、Ｃｌｉｅｎｔ Ｓｅｑ１２０５の差は、クライアントが送信したが、オフローダがまだ受信していないデータ量を表す。
図２５には、Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６と、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８の関係を表す説明図を示す。
Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６は、オフローダがクライアントに送るべきデータ量のうち、オフローダが送信したデータ量を表すための値である。一方、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８は、オフローダが実際にクライアントからのＡＣＫを受信済みのデータ量である。Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６と、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８の差は、オフローダが送信したが、クライアントの受信が確認されていないデータ量を表す。
図２６には、Ｓｅｒｖｅｒ Ｓｅｑ１２１５と、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７の関係を表す説明図を示す。
Ｓｅｒｖｅｒ Ｓｅｑ１２１５は、サーバがオフローダに送るべきデータ量のうち、サーバがオフローダに送信してきたデータ量を表すための値である。一方、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７は、サーバが送信してきたデータのうち、実際にオフローダが受信してＡＣＫをサーバに返信したデータ量を表す。Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７と、Ｓｅｒｖｅｒ Ｓｅｑ１２１５の差は、サーバが送信したが、オフローダがまだ受信していないデータ量を表す。
【００２４】
図２７には、Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６と、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８の関係を表す説明図を示す。
Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６は、オフローダがサーバに送るべきデータ量のうち、オフローダが送信したデータ量を表すための値である。一方、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８は、オフローダが実際にサーバからのＡＣＫを受信済みのデータ量である。Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６と、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｅｒ１２１８の差は、オフローダが送信したが、サーバの受信が確認されていないデータ量を表す。
図２０〜２３には、ＴＣＰ状態に記載されるシーケンス番号（Ｃｌｉｅｎｔ Ｓｅｑ１２０５、Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８、Ｓｅｒｖｅｒ Ｓｅｑ１２１５、Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８）と、パケットに記載されるシーケンス番号との関係を表す説明図を示す。
【００２５】
図２０には、クライアントがペイロード長Ｌのパケットを送信するときの説明図を示す。
オフローダは、クライアントからのパケット２００１の送信シーケンス番号（Ａ）と、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７（Ａ）が一致する場合、Ｃｌｉｅｎｔ Ｓｅｑ１２０５（Ａ）に、ペイロード長Ｌを加算する（２００８）。更に、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７（Ａ）に、ペイロード長Ｌを加算して（２００９）、シーケンス番号（Ａ＋Ｌ）を宛先シーケンス番号としたペイロード長０のパケット２００２を、クライアントに向けて送信する。
次に、クライアントからオフローダに、送信シーケンス番号をＡ＋Ｌとしたペイロード長Ｌのパケット２００３が送られ、途中で廃棄されてしまったとする。
クライアントは、パケット２００３が廃棄されたことが分からないため、続けて、送信シーケンス番号をＡ＋２Ｌとしたペイロード長Ｌのパケット２００４を、オフローダに向けて送信する。
オフローダは、パケット２００４記載の送信シーケンス番号（Ａ＋２Ｌ）と、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７記載のシーケンス番号（Ａ＋Ｌ）が異なる場合、オフローダは、ペイロード長が‘０’より大きければ、パケットを受信バッファ８０９に蓄積する。そしてオフローダは、パケット２００４記載の送信シーケンス番号（Ａ＋２Ｌ）を、Ｃｌｉｅｎｔ Ｓｅｑ１２０５に記載し（２０１０）、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７記載のシーケンス番号（Ａ＋Ｌ）を宛先シーケンス番号としたペイロード長０のパケット２００５を、クライアントに向けて送信する。
クライアントは、パケット２００５を受け取ると、宛先シーケンス番号の値（Ａ＋Ｌ）により、パケット２００３が廃棄されてしまったことを知り、送信シーケンス番号をＡ＋Ｌとしたペイロード長Ｌのパケット２００６（パケット２００３と同じパケット）を、オフローダに向けて再度送信する。
オフローダは、パケット２００６の送信シーケンス番号（Ａ＋Ｌ）と、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７記載のシーケンス番号（Ａ＋Ｌ）が一致することを確認すると、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７記載のシーケンス番号（Ａ＋Ｌ）に、パケット２００６のペイロード長Ｌを加算して（２０１１）、シーケンス番号（Ａ＋２Ｌ）を宛先シーケンス番号としたペイロード長０のパケット２００７を、クライアントに向けて送信する。
【００２６】
図２１には、オフローダがクライアントに向けてペイロード長Ｌのパケットを送信するときの説明図を示す。
オフローダがクライアントに送るペイロード長Ｌのパケット２１０１の送信シーケンス番号（Ｂ）と、Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６（Ｂ）が一致する場合、Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６（Ｂ）に、ペイロード長Ｌを加算する（２１０８）。
その後、オフローダが、クライアントから、宛先シーケンス番号をＢ＋Ｌとしたペイロード長０のパケット２１０２を受け取ると、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８に、パケット記載の宛先シーケンス番号（Ｂ＋Ｌ）を記載する（２１０９）。
次に、オフローダからクライアントに向けて、Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６と同じ送信シーケンス番号（Ｂ＋Ｌ）で送ったペイロード長Ｌのパケット２１０３が、途中で廃棄されてしまったとする。Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６（Ｂ＋Ｌ）には、パケット２１０３のペイロード長Ｌが加算される（２１１０）。
オフローダは、パケット２１０３が途中で廃棄されたことを知らないため、続けて、Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６と同じ送信シーケンス番号（Ｂ＋２Ｌ）を持つペイロード長Ｌのパケット２１０４を送る。Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６（Ｂ＋２Ｌ）には、パケット２１０４のペイロード長Ｌが加算される（２１１１）。
クライアントは、パケット２１０４を受け取ると、送信シーケンス番号の値（Ｂ＋２Ｌ）より、その前のパケット２１０３が途中で廃棄されてしまったことを知る。パケット２１０３の再送をオフローダに促すため、宛先シーケンス番号をＢ＋Ｌとしたペイロード長０のパケット２１０５とパケット２１０６を、オフローダに向けて送信する。
オフローダは、パケット２１０５記載の宛先シーケンス番号が、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８の値と同じパケット２１０５とパケット２１０６を、連続して受け取った場合、パケット２１０３が途中で廃棄されてしまったことを知り、送信シーケンス番号（Ｂ＋Ｌ）でペイロード長Ｌのパケット２１０７（パケット２１０３と同じパケット）を再度送信する。
クライアントは、パケット２１０７を受け取ると、宛先シーケンス番号をＢ＋３Ｌとしたペイロード長０のパケット２１０８を、オフローダに向けて送信する。
【００２７】
図２２には、サーバがペイロード長Ｌのパケットを送信するときの説明図を示す。
オフローダは、サーバからのパケット２２０１の送信シーケンス番号（Ａ）と、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７（Ａ）が一致する場合、Ｓｅｒｖｅｒ Ｓｅｑ１２１５（Ａ）に、ペイロード長Ｌを加算する（２２０８）。更に、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７（Ａ）に、ペイロード長Ｌを加算して（２２０９）、シーケンス番号（Ａ＋Ｌ）を宛先シーケンス番号としたペイロード長０のパケット２２０２を、サーバに向けて送信する。
次に、サーバからオフローダに、送信シーケンス番号をＡ＋Ｌとしたペイロード長Ｌのパケット２２０３が送られ、途中で廃棄されてしまったとする。
サーバは、パケット２２０３が廃棄されたことが分からないため、続けて、送信シーケンス番号をＡ＋２Ｌとしたペイロード長Ｌのパケット２２０４を、オフローダに向けて送信する。
オフローダは、パケット２２０４記載の送信シーケンス番号（Ａ＋２Ｌ）と、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７記載のシーケンス番号（Ａ＋Ｌ）が異なる場合、パケット２２０４記載の送信シーケンス番号（Ａ＋２Ｌ）を、Ｓｅｒｖｅｒ Ｓｅｑ１２１５に記載し（２２１０）、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７記載のシーケンス番号（Ａ＋Ｌ）を宛先シーケンス番号としたペイロード長０のパケット２２０５を、サーバに向けて送信する。
サーバは、パケット２２０５を受け取ると、宛先番号の値（Ａ＋Ｌ）により、パケット２２０３が廃棄されてしまったことを知り、送信シーケンス番号をＡ＋Ｌとしたペイロード長Ｌのパケット２２０６（パケット２２０３と同じパケット）を、オフローダに向けて再度送信する。
オフローダは、パケット２２０６の送信シーケンス番号（Ａ＋Ｌ）と、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７記載のシーケンス番号（Ａ＋Ｌ）が一致することを確認すると、Ａｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７記載のシーケンス番号（Ａ＋Ｌ）に、パケット２２０６のペイロード長Ｌを加算して（２２１１）、シーケンス番号（Ａ＋２Ｌ）を宛先シーケンス番号としたペイロード長０のパケット２２０７を、サーバに向けて送信する。
【００２８】
図２３には、オフローダがサーバに向けてペイロード長Ｌのパケットを送信するときの説明図を示す。
オフローダがサーバに送るペイロード長Ｌのパケット２３０１の送信シーケンス番号（Ｂ）と、Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６（Ｂ）が一致する場合、Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６（Ｂ）に、ペイロード長Ｌを加算する（２３０８）。
その後、オフローダが、サーバから、宛先シーケンス番号をＢ＋Ｌとしたペイロード長０のパケット２３０２を受け取ると、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８に、パケット記載の宛先シーケンス番号（Ｂ＋Ｌ）を記載する（２３０９）。
次に、オフローダからサーバに向けて、Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６と同じ送信シーケンス番号（Ｂ＋Ｌ）で送ったペイロード長Ｌのパケット２３０３が、途中で廃棄されてしまったとする。Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６（Ｂ＋Ｌ）には、パケット２３０３のペイロード長Ｌが加算される（２３１０）。
オフローダは、パケット２３０３が途中で廃棄されたことを知らないため、続けて、Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６と同じ送信シーケンス番号（Ｂ＋２Ｌ）を持つペイロード長Ｌのパケット２３０４を送る。Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６（Ｂ＋２Ｌ）には、パケット２３０４のペイロード長Ｌが加算される（２３１１）。
サーバは、パケット２３０４を受け取ると、送信シーケンス番号の値（Ｂ＋２Ｌ）より、その前のパケット２３０３が途中で廃棄されてしまったことを知る。パケット２３０３の再送をオフローダに促すため、宛先シーケンス番号をＢ＋Ｌとしたペイロード長０のパケット２３０５とパケット２３０６を、オフローダに向けて送信する。
オフローダは、パケット２３０５記載の宛先シーケンス番号が、Ａｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８の値と同じパケット２３０５とパケット２３０６を、連続して受け取った場合、パケット２３０３が途中で廃棄されてしまったことを知り、送信シーケンス番号（Ｂ＋Ｌ）でペイロード長Ｌのパケット２３０７（パケット２３０３と同じパケット）を再度送信する。
サーバは、パケット２３０７を受け取ると、宛先シーケンス番号をＢ＋３Ｌとしたペイロード長０のパケット２３０８を、オフローダに向けて送信する。
【００２９】
３．ＴＣＰ／ＩＰレイヤ処理部（１／２）
図９には、ＴＣＰ／ＩＰレイヤ処理部８０７の内部のブロック図を示す。
ＴＣＰ／ＩＰレイヤ処理部８０７は、ＴＣＰの状態遷移判定部９０５と、ＡＣＫ不一致パケット処理部９１１と、後続パケット再入力部９２１と、クライアント送信ＡＣＫ処理部９２２と、サーバ送信ＡＣＫ処理部９２４と、サーバ宛平文パケット処理部９２６と、クライアント宛暗号パケット処理部９２７と、を備える。
図１３には、ＴＣＰの状態遷移判定部９０５の実施するフローチャートを示す。
ＴＣＰの状態遷移判定部９０５は、パケット９０１を受信すると、パケット記載のＰｒｏｔｏ１１０１にＴＣＰを表す値が格納されているか否かを確認する（ステップ１３０１）。ＴＣＰを表す値でない場合は廃棄する（ステップ１３０２）。次に、パケット記載の１１０２〜１１０５（送信元アドレス、宛先アドレス、送信元ポート、宛先ポート）と、１２０１〜１２０４または１２１１〜１２１４が一致するエントリが、ＴＣＰコネクション状態格納テーブル８０８に存在するか否かを判定する（ステップ１３０３）。存在しない場合は、受信パケットのＦｌａｇ１１０８がＳＹＮか否かを判定する（ステップ１３１３）。ＳＹＮでない場合は、廃棄する（ステップ１３０４）。ＳＹＮの場合は、新たなエントリ（１２０１〜１２０５にパケットの１１０２〜１１０６を記載した上で、Ｃｌｉｅｎｔ Ｓｅｑ１２０５に‘１’を加算したエントリ）を作成して、ＴＣＰコネクション状態格納テーブル８０８へ書込み（９４８）、ＤＩＰ１１０３とＤｐｏｒｔ１１０５に、サーバのＩＰアドレスとポート番号を記載したサーバ宛ＳＹＮパケット（９４９）を作成する（ステップ１３１４）。ステップ１３０３にて、一致するエントリが存在する場合は、一致するエントリを読み出す（９０７）（ステップ１３０５）。更に、受信パケット記載の１１０２〜１１０５が、読み出したＴＣＰ状態記載の１２０１〜１２０４に一致する場合は、受信パケット記載の送信シーケンス番号１１０６がＴＣＰ状態記載のＡｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７よりも大きいか否かを判定し、一方、受信パケット記載の１１０２２〜１１０５がＴＣＰ状態記載の１２１１〜１２１４に一致する場合は、受信パケット記載の送信シーケンス番号１１０６がＴＣＰ状態記載のＡｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７よりも大きいか否かを判定する（ステップ１３０６）。大きい場合は、ＡＣＫ不一致パケット処理部９１１へとパケットおよび読み出したＴＣＰ状態を送信する（ステップ１３０９）。大きくない場合は、一致するか否かを判定する（ステップ１３０７）。一致しない場合は、廃棄する（ステップ１３０８）。一致する場合は、受信パケットにペイロードデータが存在するか否かを判定する（ステップ１３１０）。存在する場合は、ＴＬＳ／ＳＳＬメッセージ処理部８１２へと、パケットおよび読み出したＴＣＰ状態を送信する（ステップ１３１２）。存在しない場合は、クライアント／サーバ送信ＡＣＫ処理部９２２／９２４へと、パケットおよび読み出したＴＣＰ状態を送信する（ステップ１３１１）。
【００３０】
図１４には、ＡＣＫ不一致パケット処理部９１１の実施するフローチャートを示す。
ＡＣＫ不一致パケット処理部９１１は、ＴＣＰの状態遷移判定部９０５からパケットおよびＴＣＰ状態を受け取ると、パケットのＴＣＰペイロード長が‘０’よりも大きいか否かを判定する（ステップ１４０１）。大きい場合は、パケットを受信バッファ８０９に蓄積する（ステップ１４０２）。更に、パケットの送信シーケンス番号が、ＴＣＰ状態記載のＣｌｉｅｎｔ／Ｓｅｒｖｅｒ Ｓｅｑ１２０５／１２１５よりも大きいか否かを判定する（ステップ１４０３）。大きい場合は、ＴＣＰ状態記載のＣｌｉｅｎｔ／Ｓｅｒｖｅｒ Ｓｅｑ１２０５／１２１５を、パケットの送信シーケンス番号ＳＳｅｑ１１０６へと更新する（ステップ１４０４）。更に、ＴＣＰ状態記載のＡｃｋｅｄ Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ Ｓｅｑ１２０７／１２１７を宛先シーケンス番号とし、Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ１２０６／１２１６を送信元シーケンス番号としたＡＣＫパケットを作成する（ステップ１４０５）。新たに作成したＴＣＰ状態は、ＴＣＰコネクション状態格納テーブル８０８へと書き込む（９１０）。新たに作成したパケットは、集約部９０４へと出力する（９１２）。
以上、ＡＣＫ不一致パケット処理部９１１が、図１４のフローチャートに従って処理することで、到着順が逆転した一部のパケットのみを受信バッファ８０９に書き込むことが可能となる。
また、図１３のステップ１３１２において、パケットとＴＣＰ状態がＴＬＳ／ＳＳＬメッセージ処理部８１２へ転送され、ＴＬＳ／ＳＳＬメッセージ処理部８１２での処理が終了すると、Ａｃｋｅｄ Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ Ｓｅｑ１２０７／１２１７に、ＴＣＰペイロード長を加算して、新たなＴＣＰ状態８３１が作成される。
【００３１】
図１５には、後続パケット再入力部９２１の実施するフローチャートを示す。
後続パケット再入力部９２１は、ＴＣＰ状態８３１を受け取ると、ＴＣＰ状態記載のＡｃｋｅｄ Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ Ｓｅｑ１２０７／１２１７と一致する送信シーケンス番号を持つパケットが、受信バッファ８０９に蓄積されているか否かを判定する（ステップ１５０１）。蓄積されていない場合は終了する（ステップ１５０２）。蓄積されている場合は、受信バッファから前記パケットを読出し（９１７）、受信バッファ８０９から消去する（９１８）。更に、ＴＣＰ状態と読み出したパケットをＴＬＳ／ＳＳＬメッセージ処理部８１２へと出力する（ステップ１５０３）。
図７には、クライアント１０２が送信する暗号化パケットが、オフローダ１００によって復号化され、サーバ１０１に送られるシーケンス図を示す。
クライアント１０２が送信する暗号化パケット７０１は、オフローダのＴＬＳ／ＳＳＬメッセージ処理部８１２において復号化される。復号化された平文パケットは、改竄チェック用のＭＡＣ値を持たない場合、サーバ宛平文パケット処理部９２６において、サーバ宛送信バッファ８１１に蓄積される。更に、ＡＣＫパケット７０２をクライアント１０２に向けて送信する。
クライアント１０２が送信する暗号化パケット７０３が廃棄され、次に送信した暗号化パケット７０４がオフローダ１００に到着した場合、オフローダ１００は、パケット７０３が途中で廃棄されたものとみなし、重複ＡＣＫ７０５、７１７を連続してクライアント１０２へ送信する。クライアントは、重複ＡＣＫ７０５、７１７を２回受け取ると、パケット７０３が途中で廃棄されたことを知り、パケット７０３と同じパケット７０６を再送する。オフローダ１００は、再送パケット７０６を受け取ると、通常のＡＣＫパケット７０７をクライアント１０２へ返信する。
オフローダ１００が、改竄チェック用のＭＡＣ値を持つ暗号化パケット７０８を受け取った場合は、ＴＬＳ／ＳＳＬメッセージ処理部８１２において復号化し、サーバ宛平文パケット処理部９２６において、これまでに蓄積したサーバ宛平文パケットを読み出して送信した（７１２〜７１４）後で、復号化したパケットを送信する（７１５）。
以上、後続パケット再入力部９２１が、図１５のフローチャートに従って処理することで、受信バッファを経由するパケットを、到着順に誤りのある一部のパケットのみに限定しつつ、端末が送信した順番にパケットをＴＬＳ／ＳＳＬメッセージ処理部８１２に到着させることが可能となる。
【００３２】
クライアント宛パケット処理部９２７は、ＴＬＳ／ＳＳＬメッセージ処理部８１２が出力するクライアント宛パケットでＴＣＰペイロード長が０より大きいパケットを、クライアント宛送信バッファ８１０に蓄積した上で、クライアント宛パケットを集約部９０４に出力する（９４１）。更に、ＴＣＰ状態に記載の、オフローダ１００がサーバ側に向けて送信済みのパケットのシーケンス番号を格納するＳｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１６を送信シーケンス番号に、サーバの送信済みパケットに対してオフローダ１００がＡＣＫを返信済みのシーケンス番号を格納するＡｃｋｅｄ Ｓｅｒｖｅｒ Ｓｅｑ１２１７を宛先シーケンス番号に用いて、サーバ向けのＡＣＫパケットを作成し、集約部９０４に出力する（９４１）。
【００３３】
図１６には、クライアント送信ＡＣＫ処理部９２２の実施するフローチャートを示す。
クライアント送信ＡＣＫ処理部９２２は、クライアントからのＡＣＫパケットを受信すると、受信パケットの宛先シーケンス番号ＤＳｅｑ１１０７が、ＴＣＰ状態記載のＡｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８よりも小さいか否かを判定する（ステップ１６０１）。小さい場合は、処理を終了して、パケットを廃棄する（ステップ１６０２）。大きい場合は、受信パケットの宛先シーケンス番号ＤＳｅｑ１１０７が、ＴＣＰ状態記載のＡｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８よりも大きいか否かを判定する（ステップ１６０３）。大きい場合は、受信パケットの宛先シーケンス番号ＤＳｅｑ１１０７よりも、送信元シーケンス番号が小さなパケットをクライアント宛送信バッファ８１０から削除し、ＴＣＰ状態記載のＡｃｋｅｄ Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０８に、受信パケット記載の宛先シーケンス番号ＤＳｅｑ１１０７を記入して、ＴＣＰコネクション状態格納テーブル８０８へ書き込む（９４６）（ステップ１６０４）。一致する場合は、ＴＣＰ状態記載のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９をみて、２回目に一致する重複ＡＣＫの場合か否かを判定する（ステップ１６０５）。２回目に一致する重複ＡＣＫでない場合は、ＴＣＰ状態記載のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９に、１回目に一致する重複ＡＣＫであることを記入する（ステップ１６０６）。２回目に一致する重複ＡＣＫである場合は、受信パケットの宛先シーケンス番号Ｄｓｅｑ１１０７と同一の送信元シーケンス番号を持つパケットをクライアント宛送信バッファ８１０から読み出す（ステップ１６０７）。読み出したパケットは、集約部９０４へと出力される（９４５）。なお、ここでは一例として２回としたが、適宜の回数に設定することができる。
【００３４】
図６には、サーバ１０１が送信する平文パケットが、オフローダ１００によって暗号化され、クライアント１０２に送られるシーケンス図を示す。
サーバが送信する平文パケット６０１／６０４は、オフローダのＴＬＳ／ＳＳＬメッセージ処理部８１２において暗号化される。暗号化されたパケットは、クライアント宛パケット処理部９２７において、クライアント宛送信バッファ８１０に蓄積されると同時に、クライアント１０２に向けて送信される（６０２／６０５）。更に、ＡＣＫパケット６０３／６０６をサーバに向けて送信する。
クライアントは、クライアントに向けて送信された暗号化パケット６０２を受け取ると、ＡＣＫパケット６０７をオフローダに向けて送信する。
クライアントに向けて送信された暗号化パケット６０５が廃棄されると、図２０で説明したように、宛先シーケンス番号がＡＣＫパケット６０７と同じＡＣＫパケット（重複ＡＣＫと呼ぶ）６０８、６０９が送られる。
オフローダは、重複ＡＣＫを２回受け取ったことを判定すると、暗号化パケット６０５が途中で廃棄されたことを知る。クライアント送信ＡＣＫ処理部９２２が、クライアント宛送信バッファ８１０から暗号化パケット６０５を読み出し、暗号化パケット６０５と同じ暗号化パケット６１０を再送する。クライアント送信ＡＣＫ処理部９２２は、１回目の重複ＡＣＫ６０８を受信したとき何も再送せず、２回目の重複ＡＣＫ６０９を受信したときに、クライアント１０２へ暗号化パケット６１０を再送する。クライアント１０２は、暗号化パケット６１０が再送されると、ＡＣＫパケット６１１を返信する。
なお、オフローダ１００は、再送された暗号化パケット６１０に対するＡＣＫパケット６１１を受け取る前・後にかかわらず、サーバ１０１から平文パケット６０４の次の平文パケット６１３を受け取ると、ＴＬＳ／ＳＳＬメッセージ処理部８１２において暗号化したパケット６１３を、クライアント宛パケット処理部９２７において、クライアント宛送信バッファ８１０に蓄積すると同時に、クライアント１０２に向けて送信する。更に、ＡＣＫパケット６１４をサーバに向けて送信する。
以上のように、クライアント送信ＡＣＫ処理部９２２が図１６に示すフローチャートに従って処理することで、クライアント宛送信バッファからのパケット読出しを２回目の重複ＡＣＫを受信したときに限定し、読出し回数を抑制することが可能となる。
【００３５】
４．ＴＬＳ／ＳＳＬメッセージ処理部
図１７には、受信パケットのペイロード１１１０が、複数のＴＬＳ／ＳＳＬメッセージを含むケース（１７０１）、１つのＴＬＳ／ＳＳＬメッセージを含むケース（１７０２）、一部のＴＬＳ／ＳＳＬメッセージを含むケース（１７０３〜１７０５）を示す。
一部のＴＬＳ／ＳＳＬメッセージを含むケース（１７０３〜１７０５）では、ＴＬＳ／ＳＳＬヘッダを除く部分が暗号化されている場合がある。更に、後尾部分を含むケース（１７０５）では、最後尾に改竄チェック用のＭＡＣ値（メッセージが改竄されているか否かを判定するための値）が付加されている。改竄チェック用のＭＡＣ値を計算するためには、先頭部分から後尾部分までのメッセージ全体のハッシュ値が必要であるため、正しいメッセージを受け取ったかどうかを判定するためには、メッセージ最後尾のパケットの到着を待つ必要がある。
図１０には、ＴＬＳ／ＳＳＬメッセージ処理部８１２のブロック図を示す。
ＴＬＳ／ＳＳＬメッセージ処理部８１２は、ＴＬＳ／ＳＳＬ状態格納テーブルから対応するＴＬＳ／ＳＳＬ状態の読出しを行う状態読出し部１００２と、パケットタイプ判定部１００３と、パケットタイプの判定結果に基づいてメッセージの処理を行い返信パケットの作成と新たなＴＬＳ／ＳＳＬ状態の作成を行いＴＬＳ／ＳＳＬ状態格納テーブルへの書込みを行うメッセージ処理部１００９とを備える。
状態読出し部１００２は、ＴＣＰ状態に対応したＴＬＳ／ＳＳＬ状態を、ＴＬＳ／ＳＳＬ状態格納テーブル８１３から読み出す。
図１９には、ＴＬＳ／ＳＳＬ状態格納テーブル８１３の１エントリに記載されるＴＬＳ／ＳＳＬ状態のフォーマットの一例を示す。
ＴＬＳ／ＳＳＬ状態格納テーブル８１３は、ＴＬＳ／ＳＳＬコネクション状態を格納する領域８１３−１と、ＴＬＳ／ＳＳＬセッション状態を格納する領域８１３−２に分割される。
ＴＬＳ／ＳＳＬコネクション状態を格納する領域８１３−１の１エントリは、サーバ側の鍵状態を格納するＳｅｒｖｅｒ Ｋｅｙ１９０１と、クライアント側の鍵状態を格納するＣｌｉｅｎｔ Ｋｅｙ１９０２と、サーバ側のＭＡＣ書込みシークレットを格納するＳｅｒｖｅｒ ＭＡＣ Ｋｅｙ１９０３と、クライアント側のＭＡＣ書込みシークレットを格納するＣｌｉｅｎｔ ＭＡＣ Ｋｅｙ１９０４と、サーバ側のシーケンス番号を格納するＳｅｒｖｅｒ Ｓｅｑ１９０５と、クライアント側のシーケンス番号を格納するＣｌｉｅｎｔ Ｓｅｑ１９０６と、サーバランダムを格納するＳｅｒｖｅｒ Ｒａｎｄｏｍ１９０７と、クライアントランダムを格納するＣｌｉｅｎｔ Ｒａｎｄｏｍ１９０８と、ＶｅｒｉｆｙやＭＡＣなどの途中結果を格納するＩｎｔｅｒｉｍ Ｈａｓｈ１９０９と、セッション状態を格納するエントリへのポインタを格納するＳｅｓｓｉｏｎ Ｐｏｉｎｔｅｒ１９１０を含む。
ＴＬＳ／ＳＳＬセッション状態を格納する領域８１３−２の１エントリは、マスターシークレットを格納するＭａｓｔｅｒ Ｓｅｃｒｅｔ１９１１と、セッションＩＤを格納するＳｅｓｓｉｏｎ ＩＤ１９１２と、暗号方式を格納するＣｉｐｈｅｒ Ｓｕｉｔｅ１９１３とを含む。
【００３６】
パケットタイプ判定部１００３は、ＴＬＳ／ＳＳＬ第１〜３ヘッダタイプ特定部１００４〜１００６とタイプ判定部１００８と、パケットが２つ以上のＴＬＳ／ＳＳＬメッセージをから構成される場合に、２番目のメッセージの位置を判定する第２メッセージ位置判定部１０１０と、パケットが３つ以上のＴＬＳ／ＳＳＬメッセージをから構成される場合に、３番目のメッセージの位置を判定する第３メッセージ位置判定部１０１１とを備える。
第２メッセージ位置判定部１０１０は、ＴＣＰ／ＩＰヘッダ内のＬｅｎ１１００の値が、一番目のＴＬＳ／ＳＳＬヘッダ内のＳＳＬ Ｌｅｎ１１１４の値とＳＳＬヘッダ長とＴＣＰ／ＩＰヘッダ長の和と一致しない場合に、２番目のＴＬＳ／ＳＳＬメッセージの位置を判定して、ＴＬＳ／ＳＳＬ第２ヘッダタイプ特定部１００５に通知する。さらに、ＴＣＰ／ＩＰヘッダ内のＬｅｎ１１００の値と、一番目のＴＬＳ／ＳＳＬヘッダ内のＳＳＬ Ｌｅｎ１１１４の値とＳＳＬヘッダ長とＴＣＰ／ＩＰヘッダ長の和との差を、第３メッセージ位置判定部１０１１へ通知する。
第３メッセージ位置判定部１０１１は、第２メッセージ位置判定部１０１０から通知された差が、２番目のＴＬＳ／ＳＳＬヘッダ内のＳＳＬ Ｌｅｎ１１１８の値とＳＳＬヘッダ長の和と一致しない場合に、３番目のＴＬＳ／ＳＳＬメッセージの位置を判定して、ＴＬＳ／ＳＳＬ第３ヘッダタイプ特定部１００４に通知する。
【００３７】
ＴＬＳ／ＳＳＬ第１〜３ヘッダタイプ特定部１００４〜１００６は、図１７に示すように、ペイロードが最大３つのＴＬＳ／ＳＳＬメッセージを含む場合に、各メッセージのタイプの種類を判定する。ＴＬＳ／ＳＳＬ第１ヘッダタイプ特定部１００６の判定するメッセージタイプは、クライアントが送信するハンドシェークメッセージ（Ｃｌｉｅｎｔ Ｈｅｌｌｏ，ＫｅｙＥｘｃｈａｎｇｅ，ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ，Ｆｉｎｉｓｈｅｄ），サーバが送信する平文データ，クライアントからの暗号データ（先頭部分，中盤，最後尾）（図１７の１７０３〜１７０５のケース）、のいずれかとなる。ＴＬＳ／ＳＳＬ第２ヘッダタイプ特定部１００５の判定するメッセージタイプは、クライアントが送信するハンドシェークメッセージ（ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ，Ｆｉｎｉｓｈｅｄ）のいずれかとなる。ＴＬＳ／ＳＳＬ第３ヘッダタイプ特定部１００４の判定するメッセージタイプは、Ｆｉｎｉｓｈｅｄのみとなる。
タイプ判定部１００８は、ＴＬＳ／ＳＳＬ第２ヘッダタイプ特定部１００５と、ＴＬＳ／ＳＳＬ第３ヘッダタイプ特定部１００４の判定結果を、ＴＬＳ／ＳＳＬ第１ヘッダタイプ特定部１００６の判定結果に統合して、判定結果を出力する。たとえば、ＴＬＳ／ＳＳＬ第１ヘッダタイプ特定部１００６の判定結果がＫｅｙＥｘｃｈａｎｇｅで、ＴＬＳ／ＳＳＬ第２ヘッダタイプ特定部１００５の判定結果が無しの場合、パケットタイプ＝ＫｅｙＥｘｃｈａｎｇｅの判定結果を出力する。ＴＬＳ／ＳＳＬ第１ヘッダタイプ特定部１００６の判定結果がＫｅｙＥｘｃｈａｎｇｅで、ＴＬＳ／ＳＳＬ第２ヘッダタイプ特定部１００５の判定結果がＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃで、ＴＬＳ／ＳＳＬ第３ヘッダタイプ特定部１００５の判定結果が無しの場合、パケットタイプ＝ＫｅｙＥｘｃｈａｎｇｅ＋ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃの判定結果を出力する。ＴＬＳ／ＳＳＬ第１ヘッダタイプ特定部１００６の判定結果がＫｅｙＥｘｃｈａｎｇｅで、ＴＬＳ／ＳＳＬ第２ヘッダタイプ特定部１００５の判定結果がＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃで、ＴＬＳ／ＳＳＬ第３ヘッダタイプ特定部１００５の判定結果がＦｉｎｉｓｈｅｄの場合、パケットタイプ＝ＫｅｙＥｘｃｈａｎｇｅ＋ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ＋Ｆｉｎｉｓｈｅｄの判定結果を出力する。
メッセージ処理部１００９は、パケットタイプ判定部１００３の判定結果に基づいて、ＴＬＳ／ＳＳＬメッセージの処理を行い、クライアントの送信パケットに含まれるハンドシェークメッセージに応じて、新たなＴＬＳ／ＳＳＬ状態およびハンドシェークメッセージを含むパケットを作成する。
【００３８】
図２８には、メッセージ処理部１００９のブロック図を示す。メッセージ処理部１００９は、メッセージの判定結果に応じてパケットと状態情報を振り分ける振り分け部２８０１と、Ｃｌｉｅｎｔ Ｈｅｌｌｏメッセージを含むパケットと状態情報を用いてメッセージの処理を行うＣｌｉｅｎｔ Ｈｅｌｌｏ処理部２８０３と、ＫｅｙＥｘｃｈａｎｇｅメッセージを含むパケットと状態情報を用いてメッセージの処理を行うＫｅｙＥｘｃｈａｎｇｅ処理部２８０４と、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージのみを含むパケットと状態情報を用いてメッセージの処理を行うＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ処理部２８０５と、Ｆｉｎｉｓｈｅｄメッセージを含むパケットと状態情報を用いてメッセージの処理を行うＦｉｎｉｓｈｅｄ処理部２８０６と、Ａｌｅｒｔメッセージを含むパケットと状態情報を用いてメッセージの処理を行うＡｌｅｒｔ処理部２８０７と、暗号メッセージを含むパケットと状態情報を用いてメッセージの処理を行う暗号処理部２８０８と、平文メッセージを含むパケットと状態情報を用いてメッセージの処理を行う平文処理部２８０９と、各処理部から新たに出力されたパケットと状態情報を集約する集約部２８０２と、を備える。
Ｃｌｉｅｎｔ Ｈｅｌｌｏ処理部２８０３は、入力パケットがＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを含む場合、クライアントランダムと暗号スイートを抽出して、作成したサーバランダムと、使用する暗号スイートを指定するＳｅｒｖｅｒ Ｈｅｌｌｏメッセージと、公開鍵を含むＳｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅメッセージと、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを含むパケットを作成する。クライアントランダムとサーバランダムは、ＴＬＳ／ＳＳＬ状態のＣｌｉｅｎｔ Ｒａｎｄｏｍ１９０８とＳｅｒｖｅｒ Ｒａｎｄｏｍ１９０７に書き込まれる。更に、Ｃｌｉｅｎｔ ＨｅｌｌｏメッセージとＳｅｒｖｅｒ Ｈｅｌｌｏメッセージと、Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅメッセージと、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを用いて、ハッシュ値を途中まで計算し、途中結果と端数メッセージをＩｎｔｅｒｉｍ Ｈａｓｈ１９０９に記入する。さらに、状態情報のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９に、Ｃｌｉｅｎｔ Ｈｅｌｌｏメッセージまでを受信したことを表す状態値を格納し、作成済みパケットと、更新した状態情報を集約部２８０２へと出力する。
【００３９】
ＫｅｙＥｘｃｈａｎｇｅ処理部２８０４は、入力パケットがＫｅｙＥｘｃｈａｎｇｅメッセージを含む場合、ＫｅｙＥｘｃｈａｎｇｅメッセージ内の暗号化プリマスターシークレットを復号化し、マスターシークレットと、サーバ側の鍵状態と、クライアント側の鍵状態と、サーバ側のＭＡＣ書込みシークレットと、クライアント側のＭＡＣ書込みシークレットと、を作成する。それぞれ、ＴＬＳ／ＳＳＬ状態のＭａｓｔｅｒ Ｓｅｃｒｅｔ１９１１と、Ｓｅｒｖｅｒ Ｋｅｙ１９０１と、Ｃｌｉｅｎｔ Ｋｅｙ１９０２と、Ｓｅｒｖｅｒ ＭＡＣ Ｋｅｙ１９０３と、Ｃｌｉｅｎｔ ＭＡＣ Ｋｅｙ１９０４へと書き込まれる。更に、ＫｅｙＥｘｃｈａｎｇｅメッセージと、Ｉｎｔｅｒｉｍ Ｈａｓｈ１９０９に記入された途中結果と端数メッセージを用いて、ハッシュ値を途中まで計算し、途中結果と端数メッセージをＩｎｔｅｒｉｍ Ｈａｓｈ１９０９に記入する。また、状態情報のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９に、ＫｅｙＥｘｃｈａｎｇｅメッセージまでを受信したことを表す状態値を格納する。入力パケットが、ＫｅｙＥｘｃｈａｎｇｅメッセージと、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージを含む場合は、状態情報のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９に、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージまでを受信したことを表す状態値を格納する。更に、入力パケットがＫｅｙＥｘｃｈａｎｇｅメッセージとＦｉｎｉｓｈｅｄメッセージの両方を含む場合に、Ｆｉｎｉｓｈｅｄメッセージだけを抽出したパケットと、更新済みの状態情報を、Ｆｉｎｉｓｈｅｄ処理部２８０６へと送る。Ｆｉｎｉｓｈｅｄメッセージを含まない場合は、更新済みの状態情報を集約部２８０２へと出力する。
ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ処理部２８０５は、入力パケットがＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージを含む場合、状態情報のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９に、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージまでを受信したことを表す状態値を格納し、状態情報を集約部２８０２へと出力する。
Ｆｉｎｉｓｈｅｄ処理部２８０６は、入力パケットがＦｉｎｉｓｈｅｄメッセージを含む場合、ＴＬＳ／ＳＳＬ状態のＳｅｒｖｅｒ Ｋｅｙ１９０１を用いて復号化し、ベリファイ値と改竄チェック用のＭＡＣ値を抽出する。更に、Ｉｎｔｅｒｉｍ Ｈａｓｈ１９０９に記入された途中結果と端数メッセージを用いて、ベリファイ値を計算し、Ｆｉｎｉｓｈｅｄ記載のベリファイ値と一致するか否かを判定する。一致しない場合は、Ａｌｅｒｔメッセージを含むパケットを作成する。一致する場合はＦｉｎｉｓｈｅｄメッセージと、Ｉｎｔｅｒｉｍ Ｈａｓｈ１９０９に記入された途中結果と端数メッセージを用いて、ベリファイ値を計算し、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージとＦｉｎｉｓｈｅｄメッセージを含むパケットを作成する。Ｆｉｎｉｓｈｅｄメッセージは、改竄チェック用のＭＡＣ値を計算した上で、暗号化を行う。さらに、状態情報のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９に、Ｆｉｎｉｓｈｅｄメッセージまでを受信したことを表す状態値を格納し、作成済みパケットと、更新した状態情報を集約部２８０２へと出力する。
【００４０】
Ａｌｅｒｔ処理部２８０７は、入力パケットがＡｌｅｒｔメッセージを含む場合、警告メッセージの内容に応じて、ＴＣＰコネクションを終了するためのＦＩＮパケットを作成し、状態情報のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９に、Ａｌｅｒｔメッセージを受信したことを表す状態値を格納し、作成したパケットと、更新した状態情報を集約部２８０２へと出力する。
暗号処理部２８０８は、入力パケットが暗号化データを含むサーバ宛パケットだった場合は、ＴＬＳ／ＳＳＬ状態のＳｅｒｖｅｒ Ｋｅｙ１９０１を用いて復号化し、復号化済みの平文を用いて改竄チェック用のＭＡＣ値を計算する。復号化したパケットにＭＡＣ値が含まれる場合は、計算したＭＡＣ値と、パケットに含まれるＭＡＣ値が一致するか否かを判定し、判定結果を表す状態値を、状態情報のＣｌｉｅｎｔ Ｓｔａｔｅ１２０９に格納する。さらに、復号化したパケットと、更新した状態情報を、集約部２８０２へと出力する。
平文処理部２８０９は、入力パケットが平文データを含むクライアント宛パケットだった場合は、平文を用いて改竄チェック用のＭＡＣ値を計算し、平文データに改竄チェック用のＭＡＣ値を追加した上で暗号化したクライアント宛パケットを、新たに作成する。また、入力パケットが改竄チェック用のＭＡＣ値を含まない平文データを暗号化したサーバ宛パケットだった場合は、暗号データを復号化したサーバ宛パケットと改竄チェック用のＭＡＣ値の途中結果を作成する。改竄チェック用のＭＡＣ値の途中結果は、ＴＬＳ／ＳＳＬ状態格納テーブル８１３に蓄積される。さらに、入力パケットが改竄チェック用のＭＡＣ値を含む平文データを暗号化したサーバ宛パケットだった場合は、ＴＬＳ／ＳＳＬ状態格納テーブル８１３に蓄積された改竄チェック用のＭＡＣ値の途中結果を読み出して、暗号データを復号化したサーバ宛パケットと改竄チェック用のＭＡＣ値を作成し、改竄チェック用のＭＡＣ値の整合性をチェックする。
以上のパケットタイプ判定部１００３とメッセージ処理部１００９とを備えることで、ＴＬＳ／ＳＳＬメッセージ処理部８１２は、メッセージ単位ではなくパケット単位で処理することが可能となる。
【００４１】
５．ＴＣＰ／ＩＰレイヤ処理部（２／２）
サーバ宛平文パケット処理部９２６は、ＴＬＳ／ＳＳＬメッセージ処理部８１２が出力するサーバ宛パケットの処理を行う。以下、図９等を参照して説明する。
サーバ宛平文パケット処理部９２６は、ＴＣＰペイロード長が０より大きく、改竄チェック用のＭＡＣ値を含まない復号化済みサーバ宛平文パケットを受け取ったときは、ＭＡＣ未ベリファイの情報と共に、サーバ宛送信バッファ８１１に蓄積する（９３４）。更に、ＴＣＰ状態に記載の、オフローダ１００がクライアント側に向けて送信済みのパケットのシーケンス番号を格納するＳｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６を送信シーケンス番号に、クライアントの送信済みパケットに対してオフローダ１００がＡＣＫを返信済みのシーケンス番号を格納するＡｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７を宛先シーケンス番号に用いて、クライアント向けのＡＣＫパケットを作成する。図７に示すように、クライアントからの暗号パケットＥｎｃｒｙｐｔｅｄ Ｄａｔａ７０１，７０４，７０６に対して、ＡＣＫパケット７０２、７０５、７０７が返信される。
ＴＣＰペイロード長が０より大きく、正しい改竄チェック用のＭＡＣ値を含む復号化済みサーバ宛平文パケットを受け取ったときは、これまで蓄積したＭＡＣ未ベリファイの復号化済みサーバ宛平文パケットを読み出して（９３３）、先に集約部９０４に出力してから、改竄チェック用のＭＡＣ値を含む復号化済みサーバ宛平文パケットを出力する（９４３）。蓄積してあったＭＡＣ未ベリファイ済みの復号化済みサーバ宛平文パケットは、ＭＡＣベリファイ済みに書き換える（９３５）。更に、ＴＣＰ状態に記載の、Ｓｅｑ ｆｏｒ Ｃｌｉｅｎｔ１２０６を送信シーケンス番号に、Ａｃｋｅｄ Ｃｌｉｅｎｔ Ｓｅｑ１２０７を宛先シーケンス番号に用いて、クライアント向けのＡＣＫパケットを作成する。図７に示すように、平文パケット７１２〜７１５が連続してサーバ１０１に向けて送信され、ＡＣＫパケット７１１がクライアントに返信される。
ＴＣＰペイロード長が０より大きく、誤った改竄チェック用のＭＡＣ値を含む復号化済みサーバ宛平文パケットを受け取ったときは、これまで蓄積したＭＡＣ未ベリファイの復号化済みサーバ宛平文パケットを削除して（９３５）、Ａｌｅｒｔメッセージを含むクライアント宛パケットと、ＴＣＰコネクションの終了を開始するサーバ宛ＦＩＮパケットを作成し、集約部９０４へと出力する。図７に示すように、Ａｌｅｒｔパケット７０９がクライアント１０２に送信され、ＦＩＮパケット７１０がサーバ１０１へと送信される。
【００４２】
図１８には、サーバ送信ＡＣＫ処理部９２４の実施するフローチャートを示す。
サーバ送信ＡＣＫ処理部９２４は、サーバからのＡＣＫパケットを受信すると、受信パケットの宛先シーケンス番号ＤＳｅｑ１１０７が、ＴＣＰ状態記載のＡｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８よりも小さいか否かを判定する（ステップ１８０１）。小さい場合は、処理を終了して、パケットを廃棄する（ステップ１８０２）。大きい場合は、受信パケットの宛先シーケンス番号ＤＳｅｑ１１０７が、ＴＣＰ状態記載のＡｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８よりも大きいか否かを判定する（ステップ１８０３）。大きい場合は、受信パケットの宛先シーケンス番号ＤＳｅｑ１１０７よりも、送信元シーケンス番号が小さなパケットをサーバ宛送信バッファ８１１から削除し、ＴＣＰ状態記載のＡｃｋｅｄ Ｓｅｑ ｆｏｒ Ｓｅｒｖｅｒ１２１８に、受信パケット記載の宛先シーケンス番号ＤＳｅｑ１１０７を記入して、ＴＣＰコネクション状態格納テーブル８０８へ書き込む（９４７）（ステップ１８０４）。一致する場合は、ＴＣＰ状態記載のＳｅｒｖｅｒ Ｓｔａｔｅ１２１９をみて、２回目に一致する重複ＡＣＫの場合か否かを判定する（ステップ１８０５）。２回目に一致する重複ＡＣＫではない場合は、ＴＣＰ状態記載のＳｅｒｖｅｒ Ｓｔａｔｅ１２１９に、１回目に一致する重複ＡＣＫであることを記入する（ステップ１８０６）。２回目に一致する重複ＡＣＫである場合は、受信パケットの宛先シーケンス番号Ｄｓｅｑ１１０７と同一の送信元シーケンス番号を持つパケットをサーバ宛送信バッファ８１１から読み出す（ステップ１８０７）。読み出したパケットは、集約部９０４へと出力される（９５０）。なお、ここでは一例として２回としたが、適宜の回数に設定することができる。
以上のように、サーバ送信ＡＣＫ処理部９２４が図１８に示すフローチャートに従って処理することで、サーバ宛送信バッファからのパケット読出しを２回目の重複ＡＣＫを受信したときに限定し、読出し回数を抑制することが可能となる。
【００４３】
６．追記
本発明では、受信バッファ８０９の、サイズまたはメモリに占めるアドレス範囲を指定するレジスタを備え、外部の端末から、レジスタ値を変更するようにしてもよい。
また、本発明では、クライアント宛送信バッファ８１０の、サイズまたはメモリに占めるアドレス範囲を指定するレジスタを備え、外部の端末から、レジスタ値を変更するようにしてもよい。
また、本発明では、サーバ宛送信バッファ８１１の、サイズまたはメモリに占めるアドレス範囲を指定するレジスタを備え、外部の端末から、レジスタ値を変更するようにしてもよい。
【産業上の利用可能性】
【００４４】
本発明は、ＴＬＳ／ＳＳＬコネクション確立以外にも、各種の暗号化通信のためのコネクション確立に適用することができる。
【符号の説明】
【００４５】
８００…パケット処理装置、８０７…ＴＣＰ／ＩＰレイヤ処理部、９０５…ＴＣＰの状態遷移判定部、９１１…ＡＣＫ不一致パケット処理部、９２１…後続パケット再入力部、９２２…クライアント送信ＡＣＫ処理部、９２４…サーバ送信ＡＣＫ処理部、９２６…サーバ宛平文パケット処理部、９２７…クライアント宛パケット処理部。
【特許請求の範囲】
【請求項１】
クライアント端末とサーバ端末との間に設置され、前記サーバ端末から受信した平文データを暗号化して前記クライアント端末に送信し、前記クライアント端末から受信した暗号データを復号化して前記サーバ端末に送信するために、暗号化通信のコネクション確立シーケンスを前記サーバ端末に代わって実行するための通信装置において、
端末識別情報に対応して、端末が通信装置に送信してきたデータ量を表すための値である第１端末シーケンス情報と、端末が送信してきたデータのうち、実際に通信装置が受信して確認応答を端末に返信したデータ量を表す第１確認シーケンス情報と、通信装置が端末に送信したデータ量を表すための値である第２端末シーケンス情報と、通信装置が実際に端末からのＡＣＫを受信済みのデータ量である第２確認シーケンス情報と、を含むコネクション状態データを記憶し、コネクション毎にどこまで受信したかを記録するためのコネクション状態テーブルと、
パケットの到着順が逆転した場合に、後に到着すべきパケットを蓄積するための受信バッファと、
前記コネクション状態テーブルから、受信パケットに対応するコネクション状態を読出し、受信パケットが、受信済みデータの最後尾直後から後続しているか否かを判定し、パケットの到着順が逆転した場合に、後に到着すべきパケットを前記受信バッファに蓄積するためのパケット処理部と
を備え、
前記パケット処理部は、
端末から、送信元識別情報、送信シーケンス情報、宛先シーケンス情報、ペイロード長を含む、暗号化通信のコネクション確立のための第１の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第１の受信パケットの送信元識別情報が一致するコネクション状態データを求め、
該コネクション状態データについて、前記端末からの前記第１の受信パケットの送信シーケンス情報Ａと、第１確認シーケンス情報Ａが一致する場合、第１端末シーケンス情報Ａにペイロード長Ｌを加算して Ａ＋Ｌ に更新し、第１確認シーケンス情報Ａにペイロード長Ｌを加算して Ａ＋Ｌ に更新し、シーケンス情報 Ａ＋Ｌ を宛先シーケンス情報としたペイロード長０の第１の送信パケットを、前記端末に向けて送信し、
一方、前記端末から、送信シーケンス情報 Ａ＋Ｌ 及びペイロード長Ｌの第２の受信パケットが送られたが、該第２の受信パケットを受信する前に、続けて前記端末から送信された、送信シーケンス情報 Ａ＋２Ｌ 及びペイロード長Ｌの第３の受信パケットを受信したとき、
前記コネクション状態テーブルを参照し、前記第３の受信パケットに含まれる送信シーケンス情報 Ａ＋２Ｌ と、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ が異なる場合、該第３のパケットのペイロード長が０より大きければ該第３の受信パケットを前記受信バッファに蓄積し、該第３の受信パケットに含まれる送信シーケンス情報 Ａ＋２Ｌ を、第１端末シーケンス情報として前記コネクション状態テーブルを更新し、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ を宛先シーケンス情報としたペイロード長０の第２の送信パケットを作成し、該第２の送信パケットを前記端末に向けて送信し、
前記端末は、前記第２の送信パケットを受け取ると、宛先シーケンス情報 Ａ＋Ｌ により、前記第２の受信パケットが前記通信装置で受信されていないことを判定することにより、前記端末から、送信シーケンス情報を Ａ＋Ｌ 及びペイロード長Ｌの前記第２の受信パケット又は前記第２の受信パケットと同じ内容の第４の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第２又は第４の受信パケットの送信シーケンス情報 Ａ＋Ｌ と、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ が一致することを確認すると、第１確認シーケンス情報 Ａ＋Ｌ に、前記第４の受信パケットのペイロード長Ｌを加算して Ａ＋２Ｌ に更新し、シーケンス情報 Ａ＋２Ｌ を宛先シーケンス情報としたペイロード長０の第３の送信パケットを作成し、該第３の送信パケットを前記端末に向けて送信する
前記通信装置。
【請求項２】
請求項１に記載の通信装置において、
前記パケット処理部は、
パケットに含まれるメッセージを処理する暗号化通信メッセージ処理部と、
前記暗号化通信メッセージ処理部における送信シーケンス情報 Ａ＋Ｌ の前記第２又は第４の受信パケットの処理終了時に、送信シーケンス情報 Ａ＋２Ｌ の前記第３の受信パケットが受信バッファに蓄積されている場合に、該送信シーケンス情報 Ａ＋２Ｌ の前記第３の受信パケットを読み出して前記暗号化通信メッセージ処理部に出力する後続パケット再入力部と、
を備え、到着順に誤りのある一部のパケットのみが前記受信バッファを経由することで、端末が送信した順番にパケットが前記暗号化通信メッセージ処理部に到着することを特徴とする通信装置。
【請求項３】
請求項２に記載の通信装置において、
前記暗号化通信メッセージ処理部が作成したクライアント宛パケットを蓄積するクライアント宛送信バッファをさらに備え、
前記パケット処理部は、
前記暗号化通信メッセージ処理部が作成したクライアント宛パケットを前記クライアント宛送信バッファに蓄積するクライアント宛パケット処理部と、
クライアント端末から受信したことを通知する確認応答パケットを受信したときに、前記クライアント宛て送信バッファの対応するパケットを消去し、再送を要求する確認応答パケットを予め定められた回数以上受信したときに、前記クライアント宛て送信バッファの対応するパケットを読み出して再送するクライアント送信ＡＣＫ処理部と
を備えることで、前記クライアント宛送信バッファからのパケット読出し回数を抑制することを特徴とする通信装置。
【請求項４】
請求項２に記載の通信装置において、
前記暗号化通信メッセージ処理部は、
１つまたは複数または分割された暗号化通信のためのメッセージを含むパケットを入力し、入力された該メッセージに、どのようなメッセージタイプで暗号化通信のコネクション確立のためのメッセージが含まれるかを判定するための、パケットタイプ判定部を備え、
前記暗号化通信メッセージ処理部は、
暗号化通信のためのメッセージを処理する場合に、前記パケットタイプ判定部の判定結果に基づいて、
入力パケットが、サーバ端末が送信する平文データを含むパケットだった場合は、平文データを暗号化したクライアント宛パケットを作成し、
入力パケットが、クライアント端末が送信するハンドシェークメッセージを１つまたは複数含む場合は、受信した１つまたは複数のハンドシェークメッセージに対応するハンドシェークメッセージを含むパケットを作成し、
入力パケットが、クライアント端末が送信する暗号データを含み改竄チェック用のＭＡＣ値を含まないパケットだった場合は、暗号データを複号化したサーバ宛パケットとＭＡＣ値の途中結果を作成し、
入力パケットが、クライアント端末が送信する暗号データを含み改竄チェック用のＭＡＣ値を含むパケットだった場合は、暗号データを複号化したサーバ宛パケットと改竄チェック用のＭＡＣ値を作成し、改竄チェック用のＭＡＣ値の整合性をチェックすることで、
メッセージ単位ではなくパケット単位で処理することを特徴とする通信装置。
【請求項５】
請求項４に記載の通信装置において、
サーバ宛パケットをＭＡＣベリファイの情報と共に蓄積するサーバ宛送信バッファをさらに備え、
前記パケット処理部は、
前記暗号化通信メッセージ処理部から、改竄チェック用のＭＡＣ値を含まない復号化済みパケットを受信したときに、ＭＡＣ未ベリファイの情報と共に前記送信バッファに蓄積し、及び、前記暗号化通信メッセージ処理部から、正しい改竄チェック用のＭＡＣ値を含む復号化済みパケットを受け取ったときに、前記送信バッファに蓄積したＭＡＣ未ベリファイのパケットをＭＡＣベリファイ済とした上で読み出して送信してから、正しい改竄チェック用のＭＡＣ値を含む復号化済みパケットを送信し、及び、前記暗号化通信メッセージ処理部から、誤った改竄チェック用のＭＡＣ値を含む復号化済みパケットを受け取ったときに、前記送信バッファに蓄積したＭＡＣ未ベリファイのパケットを消去するサーバ宛平文パケット処理部と、
サーバ端末から、受信したことを通知する確認応答を受信したときに、前記サーバ宛送信バッファの対応するパケットを消去し、サーバ端末から、予め定められた回数以上再送を要求する確認応答を受信したときに、前記サーバ宛送信バッファの対応するパケットを読み出して再送するサーバ送信ＡＣＫ処理部と、
を備えることで、
前記サーバ宛送信バッファからのパケット読出し回数の抑制することを特徴とする通信装置。
【請求項６】
請求項１に記載の通信装置であって、
前記受信バッファの、サイズまたはメモリに占めるアドレス範囲を指定するレジスタを備え、
前記通信装置の外部の端末から、前記レジスタ値を変更することを特徴とする通信装置。
【請求項７】
請求項３に記載の通信装置であって、
前記クライアント宛送信バッファの、サイズまたはメモリに占めるアドレス範囲を指定するレジスタを備え、
前記通信装置の外部の端末から、前記レジスタ値を変更することを特徴とする通信装置。
【請求項８】
請求項５に記載の通信装置であって、
前記サーバ宛送信バッファの、サイズまたはメモリに占めるアドレス範囲を指定するレジスタを備え、
前記通信装置の外部の端末から、前記レジスタ値を変更することを特徴とする通信装置。
【請求項９】
請求項１に記載の通信装置において、
１つまたは複数または分割された暗号化通信のためのメッセージを含むパケットを入力し、入力された該メッセージに、どのようなメッセージタイプで暗号化通信のコネクション確立のためのメッセージが含まれるかを判定し、パケットに含まれるメッセージを処理するための暗号化通信メッセージ処理部をさらに備え、
クライアント端末からは、暗号化したマスターシークレットを含む第１コネクション確立メッセージと、暗号化通信の開始を通知する第２コネクション確立メッセージと、メッセージをベリファイするための第３コネクション確立メッセージを含む暗号化通信のコネクション確立のためのパケットを受信する際、
第１から第３のコネクション確立メッセージを別々の３つのパケットで到着するタイプ、第１コネクション確立メッセージと第２コネクション確立メッセージ・プラス・第３コネクション確立メッセージの２つのパケットで到着するタイプ、第１コネクション確立メッセージ・プラス・第２コネクション確立メッセージと第３コネクション確立メッセージの２つのパケットで到着するタイプ、第２コネクション確立メッセージと第３コネクション確立メッセージの２つのパケットで到着するタイプ、
のいずれかのタイプで受信し、
前記暗号化通信メッセージ処理部は、前記いずれかのタイプを判定することにより、メッセージをメッセージ単位ではなくパケット単位で処理することを特徴とする通信装置。
【請求項１０】
請求項１に記載の通信装置において、
受信したパケットが接続要求パケットであるとき、新たなエントリを前記コネクション状態テーブルに作成することを特徴とする通信装置。
【請求項１１】
請求項１に記載の通信装置において、
前記端末は、クライアント端末又はサーバ端末であることを特徴とする通信装置。
【請求項１２】
クライアント端末とサーバ端末との間に設置され、前記サーバ端末から受信した平文データを暗号化して前記クライアント端末に送信し、前記クライアント端末から受信した暗号データを復号化して前記サーバ端末に送信するために、暗号化通信のコネクション確立シーケンスを前記サーバ端末に代わって実行するための通信装置において、
端末識別情報に対応して、端末が通信装置に送信してきたデータ量を表すための値である第１端末シーケンス情報と、端末が送信してきたデータのうち、実際に通信装置が受信して確認応答を端末に返信したデータ量を表す第１確認シーケンス情報と、通信装置が端末に送信したデータ量を表すための値である第２端末シーケンス情報と、通信装置が実際に端末からのＡＣＫを受信済みのデータ量である第２確認シーケンス情報と、を含むコネクション状態データを記憶し、コネクション毎にどこまで受信したかを記録するためのコネクション状態テーブルと、
パケットの到着順が逆転した場合に、後に到着すべきパケットを蓄積するための受信バッファと、
前記コネクション状態テーブルから、受信パケットに対応するコネクション状態を読出し、受信パケットが、受信済みデータの最後尾直後から後続しているか否かを判定し、パケットの到着順が逆転した場合に、後に到着すべきパケットを前記受信バッファに蓄積するためのパケット処理部と
を備え、
前記パケット処理部は、
端末へ、送信元識別情報、送信シーケンス情報、宛先シーケンス情報、ペイロード長を含む、暗号化通信のコネクション確立のための第１の送信パケットを送信し、
前記コネクション状態テーブルを参照し、前記第１のパケットの送信元識別情報が一致するコネクション状態データを求め、
該コネクション状態データについて、ペイロード長Ｌの前記第１の送信パケットの送信シーケンス情報Ｂと、第２端末シーケンス情報Ｂが一致する場合、第２端末シーケンス情報Ｂにペイロード長Ｌを加算して Ｂ＋Ｌ に更新し、
前記第１の送信パケットに応答して、前記端末から、宛先シーケンス情報を Ｂ＋Ｌ としたペイロード長０の第１の受信パケットを受け取ると、前記コネクション状態テーブルの第２確認シーケンス情報に、前記第１の受信パケットに含まれる宛先シーケンス情報 Ｂ＋Ｌ を記憶し、
一方、前記端末に向けて、前記コネクション状態テーブルを参照し、第２端末シーケンス情報と同じ送信シーケンス情報 Ｂ＋Ｌ 及びペイロード長Ｌの第２の送信パケットを送り、第２端末シーケンス情報 Ｂ＋Ｌ に、第２の送信パケットのペイロード長Ｌを加算して、Ｂ＋２Ｌ に更新し、
続けて、第２端末シーケンス情報と同じ送信シーケンス情報 Ｂ＋２Ｌ を持つペイロード長Ｌの第３の送信パケットを送り、第２端末シーケンス情報 Ｂ＋２Ｌ に、該第３の送信パケットのペイロード長Ｌを加算し、Ｂ＋３Ｌ に更新し、
前記端末は、前記第２の送信パケットを受け取る前に前記第３の送信パケットを受け取った場合、送信シーケンス情報 Ｂ＋２Ｌ より、その前の前記第２の送信パケットが受信できなかったことを判定することにより、前記端末から送信された、前記第２の送信パケットの再送を促すため、宛先シーケンス情報を Ｂ＋Ｌ としたペイロード長０の第２の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第２の受信パケット又は該第２の受信パケットと同じ内容のパケットを、所定回数連続して受信した場合、前記第２の送信パケットが途中で廃棄されてしまったことを判定し、送信シーケンス情報 Ｂ＋Ｌ 及びペイロード長Ｌの前記第２の送信パケットを再送又は前記第２の送信パケットと同じ内容の第４の送信パケットを送信し、
前記第２又は第４の送信パケットに応答して、前記端末から、宛先シーケンス情報を Ｂ＋３Ｌ としたペイロード長０の第３の受信パケットを受信する
前記通信装置。
【請求項１３】
請求項１２に記載の通信装置において、
１つまたは複数または分割された暗号化通信のためのメッセージを含むパケットを入力し、入力された該メッセージに、どのようなメッセージタイプで暗号化通信のコネクション確立のためのメッセージが含まれるかを判定し、パケットに含まれるメッセージを処理するための暗号化通信メッセージ処理部をさらに備え、
クライアント端末からは、暗号化したマスターシークレットを含む第１コネクション確立メッセージと、暗号化通信の開始を通知する第２コネクション確立メッセージと、メッセージをベリファイするための第３コネクション確立メッセージを含む暗号化通信のコネクション確立のためのパケットを受信する際、
第１から第３のコネクション確立メッセージを別々の３つのパケットで到着するタイプ、第１コネクション確立メッセージと第２コネクション確立メッセージ・プラス・第３コネクション確立メッセージの２つのパケットで到着するタイプ、第１コネクション確立メッセージ・プラス・第２コネクション確立メッセージと第３コネクション確立メッセージの２つのパケットで到着するタイプ、第２コネクション確立メッセージと第３コネクション確立メッセージの２つのパケットで到着するタイプ、
のいずれかのタイプで受信し、
前記暗号化通信メッセージ処理部は、前記いずれかのタイプを判定することにより、メッセージをメッセージ単位ではなくパケット単位で処理することを特徴とする通信装置。
【請求項１４】
クライアント端末とサーバ端末との間に設置され、前記サーバ端末から受信した平文データを暗号化して前記クライアント端末に送信し、前記クライアント端末から受信した暗号データを復号化して前記サーバ端末に送信するために、暗号化通信のコネクション確立シーケンスを前記サーバ端末に代わって実行するための通信装置を備えた通信システムにおいて、
前記通信装置は、
端末識別情報に対応して、端末が通信装置に送信してきたデータ量を表すための値である第１端末シーケンス情報と、端末が送信してきたデータのうち、実際に通信装置が受信して確認応答を端末に返信したデータ量を表す第１確認シーケンス情報と、通信装置が端末に送信したデータ量を表すための値である第２端末シーケンス情報と、通信装置が実際に端末からのＡＣＫを受信済みのデータ量である第２確認シーケンス情報と、を含むコネクション状態データを記憶し、コネクション毎にどこまで受信したかを記録するためのコネクション状態テーブルと、
パケットの到着順が逆転した場合に、後に到着すべきパケットを蓄積するための受信バッファと、
前記コネクション状態テーブルから、受信パケットに対応するコネクション状態を読出し、受信パケットが、受信済みデータの最後尾直後から後続しているか否かを判定し、パケットの到着順が逆転した場合に、後に到着すべきパケットを前記受信バッファに蓄積するためのパケット処理部と
を備え、
前記パケット処理部は、
端末から、送信元識別情報、送信シーケンス情報、宛先シーケンス情報、ペイロード長を含む、暗号化通信のコネクション確立のための第１の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第１の受信パケットの送信元識別情報が一致するコネクション状態データを求め、
該コネクション状態データについて、前記端末からの前記第１の受信パケットの送信シーケンス情報Ａと、第１確認シーケンス情報Ａが一致する場合、第１端末シーケンス情報Ａにペイロード長Ｌを加算して Ａ＋Ｌ に更新し、第１確認シーケンス情報Ａにペイロード長Ｌを加算して Ａ＋Ｌ に更新し、シーケンス情報 Ａ＋Ｌ を宛先シーケンス情報としたペイロード長０の第１の送信パケットを、前記端末に向けて送信し、
一方、前記端末から、送信シーケンス情報 Ａ＋Ｌ 及びペイロード長Ｌの第２の受信パケットが送られたが、該第２の受信パケットを受信する前に、続けて前記端末から送信された、送信シーケンス情報 Ａ＋２Ｌ 及びペイロード長Ｌの第３の受信パケットを受信したとき、
前記コネクション状態テーブルを参照し、前記第３の受信パケットに含まれる送信シーケンス情報 Ａ＋２Ｌ と、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ が異なる場合、該第３のパケットのペイロード長が０より大きければ該第３の受信パケットを前記受信バッファに蓄積し、該第３の受信パケットに含まれる送信シーケンス情報 Ａ＋２Ｌ を、第１端末シーケンス情報として前記コネクション状態テーブルを更新し、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ を宛先シーケンス情報としたペイロード長０の第２の送信パケットを作成し、該第２の送信パケットを前記端末に向けて送信し、
前記端末は、前記第２の送信パケットを受け取ると、宛先シーケンス情報 Ａ＋Ｌ により、前記第２の受信パケットが前記通信装置で受信されていないことを判定することにより、前記端末から、送信シーケンス情報を Ａ＋Ｌ 及びペイロード長Ｌの前記第２の受信パケット又は前記第２の受信パケットと同じ内容の第４の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第２又は第４の受信パケットの送信シーケンス情報 Ａ＋Ｌ と、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ が一致することを確認すると、第１確認シーケンス情報 Ａ＋Ｌ に、前記第４の受信パケットのペイロード長Ｌを加算して Ａ＋２Ｌ に更新し、シーケンス情報 Ａ＋２Ｌ を宛先シーケンス情報としたペイロード長０の第３の送信パケットを作成し、該第３の送信パケットを前記端末に向けて送信する
前記通信システム。
【請求項１５】
請求項１４に記載の通信システムにおいて、
前記通信装置は、
１つまたは複数または分割された暗号化通信のためのメッセージを含むパケットを入力し、入力された該メッセージに、どのようなメッセージタイプで暗号化通信のコネクション確立のためのメッセージが含まれるかを判定し、パケットに含まれるメッセージを処理するための暗号化通信メッセージ処理部をさらに備え、
クライアント端末からは、暗号化したマスターシークレットを含む第１コネクション確立メッセージと、暗号化通信の開始を通知する第２コネクション確立メッセージと、メッセージをベリファイするための第３コネクション確立メッセージを含む暗号化通信のコネクション確立のためのパケットを受信する際、
第１から第３のコネクション確立メッセージを別々の３つのパケットで到着するタイプ、第１コネクション確立メッセージと第２コネクション確立メッセージ・プラス・第３コネクション確立メッセージの２つのパケットで到着するタイプ、第１コネクション確立メッセージ・プラス・第２コネクション確立メッセージと第３コネクション確立メッセージの２つのパケットで到着するタイプ、第２コネクション確立メッセージと第３コネクション確立メッセージの２つのパケットで到着するタイプ、
のいずれかのタイプで受信し、
前記暗号化通信メッセージ処理部は、前記いずれかのタイプを判定することにより、メッセージをメッセージ単位ではなくパケット単位で処理することを特徴とする通信システム。
【請求項１】
クライアント端末とサーバ端末との間に設置され、前記サーバ端末から受信した平文データを暗号化して前記クライアント端末に送信し、前記クライアント端末から受信した暗号データを復号化して前記サーバ端末に送信するために、暗号化通信のコネクション確立シーケンスを前記サーバ端末に代わって実行するための通信装置において、
端末識別情報に対応して、端末が通信装置に送信してきたデータ量を表すための値である第１端末シーケンス情報と、端末が送信してきたデータのうち、実際に通信装置が受信して確認応答を端末に返信したデータ量を表す第１確認シーケンス情報と、通信装置が端末に送信したデータ量を表すための値である第２端末シーケンス情報と、通信装置が実際に端末からのＡＣＫを受信済みのデータ量である第２確認シーケンス情報と、を含むコネクション状態データを記憶し、コネクション毎にどこまで受信したかを記録するためのコネクション状態テーブルと、
パケットの到着順が逆転した場合に、後に到着すべきパケットを蓄積するための受信バッファと、
前記コネクション状態テーブルから、受信パケットに対応するコネクション状態を読出し、受信パケットが、受信済みデータの最後尾直後から後続しているか否かを判定し、パケットの到着順が逆転した場合に、後に到着すべきパケットを前記受信バッファに蓄積するためのパケット処理部と
を備え、
前記パケット処理部は、
端末から、送信元識別情報、送信シーケンス情報、宛先シーケンス情報、ペイロード長を含む、暗号化通信のコネクション確立のための第１の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第１の受信パケットの送信元識別情報が一致するコネクション状態データを求め、
該コネクション状態データについて、前記端末からの前記第１の受信パケットの送信シーケンス情報Ａと、第１確認シーケンス情報Ａが一致する場合、第１端末シーケンス情報Ａにペイロード長Ｌを加算して Ａ＋Ｌ に更新し、第１確認シーケンス情報Ａにペイロード長Ｌを加算して Ａ＋Ｌ に更新し、シーケンス情報 Ａ＋Ｌ を宛先シーケンス情報としたペイロード長０の第１の送信パケットを、前記端末に向けて送信し、
一方、前記端末から、送信シーケンス情報 Ａ＋Ｌ 及びペイロード長Ｌの第２の受信パケットが送られたが、該第２の受信パケットを受信する前に、続けて前記端末から送信された、送信シーケンス情報 Ａ＋２Ｌ 及びペイロード長Ｌの第３の受信パケットを受信したとき、
前記コネクション状態テーブルを参照し、前記第３の受信パケットに含まれる送信シーケンス情報 Ａ＋２Ｌ と、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ が異なる場合、該第３のパケットのペイロード長が０より大きければ該第３の受信パケットを前記受信バッファに蓄積し、該第３の受信パケットに含まれる送信シーケンス情報 Ａ＋２Ｌ を、第１端末シーケンス情報として前記コネクション状態テーブルを更新し、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ を宛先シーケンス情報としたペイロード長０の第２の送信パケットを作成し、該第２の送信パケットを前記端末に向けて送信し、
前記端末は、前記第２の送信パケットを受け取ると、宛先シーケンス情報 Ａ＋Ｌ により、前記第２の受信パケットが前記通信装置で受信されていないことを判定することにより、前記端末から、送信シーケンス情報を Ａ＋Ｌ 及びペイロード長Ｌの前記第２の受信パケット又は前記第２の受信パケットと同じ内容の第４の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第２又は第４の受信パケットの送信シーケンス情報 Ａ＋Ｌ と、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ が一致することを確認すると、第１確認シーケンス情報 Ａ＋Ｌ に、前記第４の受信パケットのペイロード長Ｌを加算して Ａ＋２Ｌ に更新し、シーケンス情報 Ａ＋２Ｌ を宛先シーケンス情報としたペイロード長０の第３の送信パケットを作成し、該第３の送信パケットを前記端末に向けて送信する
前記通信装置。
【請求項２】
請求項１に記載の通信装置において、
前記パケット処理部は、
パケットに含まれるメッセージを処理する暗号化通信メッセージ処理部と、
前記暗号化通信メッセージ処理部における送信シーケンス情報 Ａ＋Ｌ の前記第２又は第４の受信パケットの処理終了時に、送信シーケンス情報 Ａ＋２Ｌ の前記第３の受信パケットが受信バッファに蓄積されている場合に、該送信シーケンス情報 Ａ＋２Ｌ の前記第３の受信パケットを読み出して前記暗号化通信メッセージ処理部に出力する後続パケット再入力部と、
を備え、到着順に誤りのある一部のパケットのみが前記受信バッファを経由することで、端末が送信した順番にパケットが前記暗号化通信メッセージ処理部に到着することを特徴とする通信装置。
【請求項３】
請求項２に記載の通信装置において、
前記暗号化通信メッセージ処理部が作成したクライアント宛パケットを蓄積するクライアント宛送信バッファをさらに備え、
前記パケット処理部は、
前記暗号化通信メッセージ処理部が作成したクライアント宛パケットを前記クライアント宛送信バッファに蓄積するクライアント宛パケット処理部と、
クライアント端末から受信したことを通知する確認応答パケットを受信したときに、前記クライアント宛て送信バッファの対応するパケットを消去し、再送を要求する確認応答パケットを予め定められた回数以上受信したときに、前記クライアント宛て送信バッファの対応するパケットを読み出して再送するクライアント送信ＡＣＫ処理部と
を備えることで、前記クライアント宛送信バッファからのパケット読出し回数を抑制することを特徴とする通信装置。
【請求項４】
請求項２に記載の通信装置において、
前記暗号化通信メッセージ処理部は、
１つまたは複数または分割された暗号化通信のためのメッセージを含むパケットを入力し、入力された該メッセージに、どのようなメッセージタイプで暗号化通信のコネクション確立のためのメッセージが含まれるかを判定するための、パケットタイプ判定部を備え、
前記暗号化通信メッセージ処理部は、
暗号化通信のためのメッセージを処理する場合に、前記パケットタイプ判定部の判定結果に基づいて、
入力パケットが、サーバ端末が送信する平文データを含むパケットだった場合は、平文データを暗号化したクライアント宛パケットを作成し、
入力パケットが、クライアント端末が送信するハンドシェークメッセージを１つまたは複数含む場合は、受信した１つまたは複数のハンドシェークメッセージに対応するハンドシェークメッセージを含むパケットを作成し、
入力パケットが、クライアント端末が送信する暗号データを含み改竄チェック用のＭＡＣ値を含まないパケットだった場合は、暗号データを複号化したサーバ宛パケットとＭＡＣ値の途中結果を作成し、
入力パケットが、クライアント端末が送信する暗号データを含み改竄チェック用のＭＡＣ値を含むパケットだった場合は、暗号データを複号化したサーバ宛パケットと改竄チェック用のＭＡＣ値を作成し、改竄チェック用のＭＡＣ値の整合性をチェックすることで、
メッセージ単位ではなくパケット単位で処理することを特徴とする通信装置。
【請求項５】
請求項４に記載の通信装置において、
サーバ宛パケットをＭＡＣベリファイの情報と共に蓄積するサーバ宛送信バッファをさらに備え、
前記パケット処理部は、
前記暗号化通信メッセージ処理部から、改竄チェック用のＭＡＣ値を含まない復号化済みパケットを受信したときに、ＭＡＣ未ベリファイの情報と共に前記送信バッファに蓄積し、及び、前記暗号化通信メッセージ処理部から、正しい改竄チェック用のＭＡＣ値を含む復号化済みパケットを受け取ったときに、前記送信バッファに蓄積したＭＡＣ未ベリファイのパケットをＭＡＣベリファイ済とした上で読み出して送信してから、正しい改竄チェック用のＭＡＣ値を含む復号化済みパケットを送信し、及び、前記暗号化通信メッセージ処理部から、誤った改竄チェック用のＭＡＣ値を含む復号化済みパケットを受け取ったときに、前記送信バッファに蓄積したＭＡＣ未ベリファイのパケットを消去するサーバ宛平文パケット処理部と、
サーバ端末から、受信したことを通知する確認応答を受信したときに、前記サーバ宛送信バッファの対応するパケットを消去し、サーバ端末から、予め定められた回数以上再送を要求する確認応答を受信したときに、前記サーバ宛送信バッファの対応するパケットを読み出して再送するサーバ送信ＡＣＫ処理部と、
を備えることで、
前記サーバ宛送信バッファからのパケット読出し回数の抑制することを特徴とする通信装置。
【請求項６】
請求項１に記載の通信装置であって、
前記受信バッファの、サイズまたはメモリに占めるアドレス範囲を指定するレジスタを備え、
前記通信装置の外部の端末から、前記レジスタ値を変更することを特徴とする通信装置。
【請求項７】
請求項３に記載の通信装置であって、
前記クライアント宛送信バッファの、サイズまたはメモリに占めるアドレス範囲を指定するレジスタを備え、
前記通信装置の外部の端末から、前記レジスタ値を変更することを特徴とする通信装置。
【請求項８】
請求項５に記載の通信装置であって、
前記サーバ宛送信バッファの、サイズまたはメモリに占めるアドレス範囲を指定するレジスタを備え、
前記通信装置の外部の端末から、前記レジスタ値を変更することを特徴とする通信装置。
【請求項９】
請求項１に記載の通信装置において、
１つまたは複数または分割された暗号化通信のためのメッセージを含むパケットを入力し、入力された該メッセージに、どのようなメッセージタイプで暗号化通信のコネクション確立のためのメッセージが含まれるかを判定し、パケットに含まれるメッセージを処理するための暗号化通信メッセージ処理部をさらに備え、
クライアント端末からは、暗号化したマスターシークレットを含む第１コネクション確立メッセージと、暗号化通信の開始を通知する第２コネクション確立メッセージと、メッセージをベリファイするための第３コネクション確立メッセージを含む暗号化通信のコネクション確立のためのパケットを受信する際、
第１から第３のコネクション確立メッセージを別々の３つのパケットで到着するタイプ、第１コネクション確立メッセージと第２コネクション確立メッセージ・プラス・第３コネクション確立メッセージの２つのパケットで到着するタイプ、第１コネクション確立メッセージ・プラス・第２コネクション確立メッセージと第３コネクション確立メッセージの２つのパケットで到着するタイプ、第２コネクション確立メッセージと第３コネクション確立メッセージの２つのパケットで到着するタイプ、
のいずれかのタイプで受信し、
前記暗号化通信メッセージ処理部は、前記いずれかのタイプを判定することにより、メッセージをメッセージ単位ではなくパケット単位で処理することを特徴とする通信装置。
【請求項１０】
請求項１に記載の通信装置において、
受信したパケットが接続要求パケットであるとき、新たなエントリを前記コネクション状態テーブルに作成することを特徴とする通信装置。
【請求項１１】
請求項１に記載の通信装置において、
前記端末は、クライアント端末又はサーバ端末であることを特徴とする通信装置。
【請求項１２】
クライアント端末とサーバ端末との間に設置され、前記サーバ端末から受信した平文データを暗号化して前記クライアント端末に送信し、前記クライアント端末から受信した暗号データを復号化して前記サーバ端末に送信するために、暗号化通信のコネクション確立シーケンスを前記サーバ端末に代わって実行するための通信装置において、
端末識別情報に対応して、端末が通信装置に送信してきたデータ量を表すための値である第１端末シーケンス情報と、端末が送信してきたデータのうち、実際に通信装置が受信して確認応答を端末に返信したデータ量を表す第１確認シーケンス情報と、通信装置が端末に送信したデータ量を表すための値である第２端末シーケンス情報と、通信装置が実際に端末からのＡＣＫを受信済みのデータ量である第２確認シーケンス情報と、を含むコネクション状態データを記憶し、コネクション毎にどこまで受信したかを記録するためのコネクション状態テーブルと、
パケットの到着順が逆転した場合に、後に到着すべきパケットを蓄積するための受信バッファと、
前記コネクション状態テーブルから、受信パケットに対応するコネクション状態を読出し、受信パケットが、受信済みデータの最後尾直後から後続しているか否かを判定し、パケットの到着順が逆転した場合に、後に到着すべきパケットを前記受信バッファに蓄積するためのパケット処理部と
を備え、
前記パケット処理部は、
端末へ、送信元識別情報、送信シーケンス情報、宛先シーケンス情報、ペイロード長を含む、暗号化通信のコネクション確立のための第１の送信パケットを送信し、
前記コネクション状態テーブルを参照し、前記第１のパケットの送信元識別情報が一致するコネクション状態データを求め、
該コネクション状態データについて、ペイロード長Ｌの前記第１の送信パケットの送信シーケンス情報Ｂと、第２端末シーケンス情報Ｂが一致する場合、第２端末シーケンス情報Ｂにペイロード長Ｌを加算して Ｂ＋Ｌ に更新し、
前記第１の送信パケットに応答して、前記端末から、宛先シーケンス情報を Ｂ＋Ｌ としたペイロード長０の第１の受信パケットを受け取ると、前記コネクション状態テーブルの第２確認シーケンス情報に、前記第１の受信パケットに含まれる宛先シーケンス情報 Ｂ＋Ｌ を記憶し、
一方、前記端末に向けて、前記コネクション状態テーブルを参照し、第２端末シーケンス情報と同じ送信シーケンス情報 Ｂ＋Ｌ 及びペイロード長Ｌの第２の送信パケットを送り、第２端末シーケンス情報 Ｂ＋Ｌ に、第２の送信パケットのペイロード長Ｌを加算して、Ｂ＋２Ｌ に更新し、
続けて、第２端末シーケンス情報と同じ送信シーケンス情報 Ｂ＋２Ｌ を持つペイロード長Ｌの第３の送信パケットを送り、第２端末シーケンス情報 Ｂ＋２Ｌ に、該第３の送信パケットのペイロード長Ｌを加算し、Ｂ＋３Ｌ に更新し、
前記端末は、前記第２の送信パケットを受け取る前に前記第３の送信パケットを受け取った場合、送信シーケンス情報 Ｂ＋２Ｌ より、その前の前記第２の送信パケットが受信できなかったことを判定することにより、前記端末から送信された、前記第２の送信パケットの再送を促すため、宛先シーケンス情報を Ｂ＋Ｌ としたペイロード長０の第２の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第２の受信パケット又は該第２の受信パケットと同じ内容のパケットを、所定回数連続して受信した場合、前記第２の送信パケットが途中で廃棄されてしまったことを判定し、送信シーケンス情報 Ｂ＋Ｌ 及びペイロード長Ｌの前記第２の送信パケットを再送又は前記第２の送信パケットと同じ内容の第４の送信パケットを送信し、
前記第２又は第４の送信パケットに応答して、前記端末から、宛先シーケンス情報を Ｂ＋３Ｌ としたペイロード長０の第３の受信パケットを受信する
前記通信装置。
【請求項１３】
請求項１２に記載の通信装置において、
１つまたは複数または分割された暗号化通信のためのメッセージを含むパケットを入力し、入力された該メッセージに、どのようなメッセージタイプで暗号化通信のコネクション確立のためのメッセージが含まれるかを判定し、パケットに含まれるメッセージを処理するための暗号化通信メッセージ処理部をさらに備え、
クライアント端末からは、暗号化したマスターシークレットを含む第１コネクション確立メッセージと、暗号化通信の開始を通知する第２コネクション確立メッセージと、メッセージをベリファイするための第３コネクション確立メッセージを含む暗号化通信のコネクション確立のためのパケットを受信する際、
第１から第３のコネクション確立メッセージを別々の３つのパケットで到着するタイプ、第１コネクション確立メッセージと第２コネクション確立メッセージ・プラス・第３コネクション確立メッセージの２つのパケットで到着するタイプ、第１コネクション確立メッセージ・プラス・第２コネクション確立メッセージと第３コネクション確立メッセージの２つのパケットで到着するタイプ、第２コネクション確立メッセージと第３コネクション確立メッセージの２つのパケットで到着するタイプ、
のいずれかのタイプで受信し、
前記暗号化通信メッセージ処理部は、前記いずれかのタイプを判定することにより、メッセージをメッセージ単位ではなくパケット単位で処理することを特徴とする通信装置。
【請求項１４】
クライアント端末とサーバ端末との間に設置され、前記サーバ端末から受信した平文データを暗号化して前記クライアント端末に送信し、前記クライアント端末から受信した暗号データを復号化して前記サーバ端末に送信するために、暗号化通信のコネクション確立シーケンスを前記サーバ端末に代わって実行するための通信装置を備えた通信システムにおいて、
前記通信装置は、
端末識別情報に対応して、端末が通信装置に送信してきたデータ量を表すための値である第１端末シーケンス情報と、端末が送信してきたデータのうち、実際に通信装置が受信して確認応答を端末に返信したデータ量を表す第１確認シーケンス情報と、通信装置が端末に送信したデータ量を表すための値である第２端末シーケンス情報と、通信装置が実際に端末からのＡＣＫを受信済みのデータ量である第２確認シーケンス情報と、を含むコネクション状態データを記憶し、コネクション毎にどこまで受信したかを記録するためのコネクション状態テーブルと、
パケットの到着順が逆転した場合に、後に到着すべきパケットを蓄積するための受信バッファと、
前記コネクション状態テーブルから、受信パケットに対応するコネクション状態を読出し、受信パケットが、受信済みデータの最後尾直後から後続しているか否かを判定し、パケットの到着順が逆転した場合に、後に到着すべきパケットを前記受信バッファに蓄積するためのパケット処理部と
を備え、
前記パケット処理部は、
端末から、送信元識別情報、送信シーケンス情報、宛先シーケンス情報、ペイロード長を含む、暗号化通信のコネクション確立のための第１の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第１の受信パケットの送信元識別情報が一致するコネクション状態データを求め、
該コネクション状態データについて、前記端末からの前記第１の受信パケットの送信シーケンス情報Ａと、第１確認シーケンス情報Ａが一致する場合、第１端末シーケンス情報Ａにペイロード長Ｌを加算して Ａ＋Ｌ に更新し、第１確認シーケンス情報Ａにペイロード長Ｌを加算して Ａ＋Ｌ に更新し、シーケンス情報 Ａ＋Ｌ を宛先シーケンス情報としたペイロード長０の第１の送信パケットを、前記端末に向けて送信し、
一方、前記端末から、送信シーケンス情報 Ａ＋Ｌ 及びペイロード長Ｌの第２の受信パケットが送られたが、該第２の受信パケットを受信する前に、続けて前記端末から送信された、送信シーケンス情報 Ａ＋２Ｌ 及びペイロード長Ｌの第３の受信パケットを受信したとき、
前記コネクション状態テーブルを参照し、前記第３の受信パケットに含まれる送信シーケンス情報 Ａ＋２Ｌ と、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ が異なる場合、該第３のパケットのペイロード長が０より大きければ該第３の受信パケットを前記受信バッファに蓄積し、該第３の受信パケットに含まれる送信シーケンス情報 Ａ＋２Ｌ を、第１端末シーケンス情報として前記コネクション状態テーブルを更新し、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ を宛先シーケンス情報としたペイロード長０の第２の送信パケットを作成し、該第２の送信パケットを前記端末に向けて送信し、
前記端末は、前記第２の送信パケットを受け取ると、宛先シーケンス情報 Ａ＋Ｌ により、前記第２の受信パケットが前記通信装置で受信されていないことを判定することにより、前記端末から、送信シーケンス情報を Ａ＋Ｌ 及びペイロード長Ｌの前記第２の受信パケット又は前記第２の受信パケットと同じ内容の第４の受信パケットを受信し、
前記コネクション状態テーブルを参照し、前記第２又は第４の受信パケットの送信シーケンス情報 Ａ＋Ｌ と、第１確認シーケンス情報のシーケンス情報 Ａ＋Ｌ が一致することを確認すると、第１確認シーケンス情報 Ａ＋Ｌ に、前記第４の受信パケットのペイロード長Ｌを加算して Ａ＋２Ｌ に更新し、シーケンス情報 Ａ＋２Ｌ を宛先シーケンス情報としたペイロード長０の第３の送信パケットを作成し、該第３の送信パケットを前記端末に向けて送信する
前記通信システム。
【請求項１５】
請求項１４に記載の通信システムにおいて、
前記通信装置は、
１つまたは複数または分割された暗号化通信のためのメッセージを含むパケットを入力し、入力された該メッセージに、どのようなメッセージタイプで暗号化通信のコネクション確立のためのメッセージが含まれるかを判定し、パケットに含まれるメッセージを処理するための暗号化通信メッセージ処理部をさらに備え、
クライアント端末からは、暗号化したマスターシークレットを含む第１コネクション確立メッセージと、暗号化通信の開始を通知する第２コネクション確立メッセージと、メッセージをベリファイするための第３コネクション確立メッセージを含む暗号化通信のコネクション確立のためのパケットを受信する際、
第１から第３のコネクション確立メッセージを別々の３つのパケットで到着するタイプ、第１コネクション確立メッセージと第２コネクション確立メッセージ・プラス・第３コネクション確立メッセージの２つのパケットで到着するタイプ、第１コネクション確立メッセージ・プラス・第２コネクション確立メッセージと第３コネクション確立メッセージの２つのパケットで到着するタイプ、第２コネクション確立メッセージと第３コネクション確立メッセージの２つのパケットで到着するタイプ、
のいずれかのタイプで受信し、
前記暗号化通信メッセージ処理部は、前記いずれかのタイプを判定することにより、メッセージをメッセージ単位ではなくパケット単位で処理することを特徴とする通信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【公開番号】特開２０１１−４１００８（Ｐ２０１１−４１００８Ａ）
【公開日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願番号】特願２００９−１８６７１０（Ｐ２００９−１８６７１０）
【出願日】平成２１年８月１１日（２００９．８．１１）
【出願人】（０００００５１２０）日立電線株式会社 (3,358)
【Ｆターム（参考）】
【公開日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願日】平成２１年８月１１日（２００９．８．１１）
【出願人】（０００００５１２０）日立電線株式会社 (3,358)
【Ｆターム（参考）】
[ Back to top ]