以下、図面を参照してこの発明に関わる実施形態を説明する。なお、以下の通信システムは、暗号化するか否かを選択しつつ多重化通信できる通信システムとしてコンピュータを機能させるためのプログラムを用いて実施してもよい。すなわち、通信システムは、メモリ又はCPU(Central Processing Unit)等のハードウェア資源に協働する機能ブロックの機能をプログラムにより実現してもよい。
[一実施形態]
図1は、この発明の一実施形態に係る通信システムの機能構成を示すブロック図であり、図2及び図3は、それぞれプロトコルスタック及びパケットフォーマットの一例を示す模式図である。通信システム1は、クライアント装置10およびサーバ装置20を備えている。また、通信システム1は、クライアント装置10からの要求に対してサーバ装置20が応答する、ネットワークを介した通信をする際に、各エンティティ装置間で暗号化するか否かを選択しつつ多重化通信をするためのプロトコル(以下、USEP(User Selectable Encryption Protocol)という。)を備えている。なお、以下の説明では、「クライアント装置」及び「サーバ装置」を、それぞれ「第1エンティティ装置」及び「第2エンティティ装置」と読み替えてもよい。また、「プロトコル」を、「通信規約」又は「通信手順」等と読み替えてもよい。
クライアント装置10及びサーバ装置20は、ネットワークを介して接続されている。なお、クライアント装置10及びサーバ装置20は、1台に限らず、2台以上の任意の台数がネットワークを介して接続可能となっている。クライアント装置10及びサーバ装置20は、USEPをサポートしている。一例として、クライアント装置10及びサーバ装置20は、図2に示す如きプロトコルスタック100aを実装している。
クライアント装置10及びサーバ装置20は、TCPを動作させることで通信を実施してもよい。また、クライアント装置10及びサーバ装置20は、TCP上でWebSocketプロトコルを動作させてもよい。
クライアント装置10及びサーバ装置20は、WebSocketプロトコル上でUSEPを動作させてもよく、WebSocketプロトコルのHTTPの「Upgrade」ヘッダの機能を拡張することでUSEPプロトコルの利用可能性を交渉してもよい。
クライアント装置10及びサーバ装置20は、USEP上で任意のアプリケーションプロトコルを動作させてもよい。具体的には、平文通信する際にはHTTPやHTTP/2を動作させてもよく、暗号化通信する際にはTLS上でのHTTPであるHTTPS(HTTP secure)、HTTP/2及びSPDYを動作させてもよい。
なお、以下の説明では、プロトコルスタック100aにおけるUSEPレイヤより上位及び下位のレイヤを「上位レイヤ」及び「下位レイヤ」と読み替えてもよい。また、TCPやWebSocketプロトコルに例示される、USEPを動作させるプロトコルを、「下位レイヤのプロトコル」又は「下位プロトコル」と読み替えてもよい。また、HTTP、HTTP/2及びSPDYに例示される、USEP上で動作するプロトコルを、「上位レイヤのプロトコル」又は「上位プロトコル」と読み替えてもよい。
USEPのパケットフォーマット100bは、図3に示すように、ヘッダ情報とデータ情報を含む。ヘッダ情報は、暗号化フラグ、上位レイヤ情報及びストリームIDを含む。なお、パケットフォーマット100bは、あくまで一例であり、フォーマットやビット長、識別に利用される情報の組み合わせはこの限りではない。
暗号化フラグは、通信パケットを暗号化するか否かを示す変数である。暗号化フラグは、1ビットで実現されてもよい。暗号化フラグは、1ビットで実現される場合、データ情報が暗号化されていないことを示す場合に“0”が設定され、データ情報が暗号化されていることを示す場合に“1”が設定されてもよい。
上位レイヤ情報は、通信パケットの通信に使用する上位レイヤの情報を示す。すなわち、上位レイヤ情報は、上位レイヤで利用されるプロトコルを一意に識別するための値を含む情報である。上位レイヤ情報は、後述する利用可能プロトコルDB105に記憶されているプロトコルリスト100cの値と対応していてもよい。
ストリームIDは、通信プロトコル上で行われる通信を識別する。すなわち、ストリームIDは、USEPレイヤにおけるUSEP上の通信を識別するための識別番号であり、下位レイヤであるTCP等の単一のコネクション上において動作する、複数のUSEP上の通信ストリームを識別するための識別番号である。ストリームIDは、典型的には24ビットの値として設定されるが、24ビット以外のビット長として設定されてもよい。
データ情報は、USEPデータグラムにおける任意長のペイロードである。
クライアント装置10は、上位プロトコル処理部11、クライアント装置USEP処理部12、下位プロトコル処理部13及び送受信部14を備えている。また、サーバ装置20は、上位プロトコル処理部21、サーバ装置USEP処理部22、下位プロトコル処理部23及び送受信部24を備えている。
なお、互いに同一名称の機能ブロックである上位プロトコル処理部11,21と、下位プロトコル処理部13,23と、送受信部14,24とは、それぞれ互いに同等の機能を有している。このため、サーバ装置20における上記重複部の機能構成については説明を省略する。
上位プロトコル処理部11は、サーバ装置20へ送信するメッセージの上位プロトコルに関する処理を実施する。上位プロトコル処理部11は、送信メッセージを作成し、クライアント装置USEP処理部12に送信する。上位プロトコル処理部11は、サーバ装置20から受信したメッセージをクライアント装置USEP処理部12から受信し、上位プロトコルに関する処理を実施する。また、上位プロトコル処理部11は、セッション確立時に、上位プロトコルの利用可能性を交渉する。なお、以下の説明では、「送信メッセージ」及び「受信メッセージ」を、「送信パケット」及び「受信パケット」と読み替えてもよい。また、「送信」又は「受信」を「通信」と読み替えてもよい。
クライアント装置USEP処理部12は、図4に示すように、上位プロトコル連携部100、USEPヘッダ処理部101、下位プロトコル連携部102、利用可能プロトコルDB103、ストリームID管理部104及びストリームID管理DB105を備えている。サーバ装置USEP処理部22は、上位プロトコル連携部200、USEPヘッダ処理部201、下位プロトコル連携部及び利用可能プロトコルDB203を備えている。また、クライアント装置USEP処理部12及びサーバ装置USEP処理部22は、利用可能プロトコルDB103を備えている場合、セッション確立時に、上位プロトコルの利用可能性を交渉してもよい。
なお、互いに同一名称の機能ブロックである上位プロトコル連携部100,200と、USEPヘッダ処理部101,201と、下位プロトコル連携部102,202と、利用可能プロトコルDB103,203とは、それぞれ互いに同等の機能を有している。このため、サーバ装置USEP処理部22の機能構成については説明を省略する。
上位プロトコル連携部100は、上位プロトコル処理部11から送信メッセージを受信すると、受信した送信メッセージ内の情報に基づいて、利用可能な上位プロトコルの値を利用可能プロトコルDB103から読込む。上位プロトコル連携部100は、送信メッセージ及び読込んだ上位プロトコルの値をUSEPヘッダ処理部101に送信する。また、上位プロトコル連携部100は、USEPヘッダ処理部101から受信メッセージを受信し、ヘッダ情報内の上位レイヤ情報に基づき、当該受信メッセージを適切な上位プロトコルを処理する上位プロトコル処理部11へ送信する。
また、上位プロトコル連携部100は、セッション確立時に、利用可能プロトコルDB103から利用可能なプロトコルの値を読出し、下位プロトコル連携部102を通じて下位プロトコル処理部13に送信してもよい。
USEPヘッダ処理部101は、上位プロトコル連携部100から送信メッセージ及び利用可能な上位プロトコルの値を受信し、USEPのヘッダ情報を設定する。また、下位プロトコル連携部102から受信メッセージを受信し、上位プロトコル連携部100に送信する。
USEPのヘッダ情報を設定するための具体的な機能構成を以下に説明する。USEPヘッダ処理部101は、送信メッセージを暗号化するか否かを選択する。また、USEPヘッダ処理部101は、選択結果に基づき、ヘッダ情報内の暗号化フラグを設定する。また、USEPヘッダ処理部101は、利用可能な上位プロトコルの値を受信し、ヘッダ情報内の上位レイヤ情報を設定する。また、USEPヘッダ処理部101は、ストリームID管理部104から利用可能なストリームIDを取得し、取得したストリームIDをヘッダ情報内のストリームIDとして設定する。
なお、USEPヘッダ処理部101は、暗号化するか否かを選択する際に、予め定められたルールに基づき、暗号化するか否かを静的に選択してもよい。USEPヘッダ処理部101は、USEP上で動作する上位レイヤのアプリケーションやソフトウェアから予め定められたルールが記述された設定ファイルを読込むことで、暗号化するか否かを選択してもよい。当該ルールが記述された設定ファイルは、アプリケーションやソフトウェアの設定ファイル内に含められていてもよく、”usep.cfg”等の外部ファイルに記述されたルールを読込むことでUSEPヘッダ処理部101に認識されてもよい。また、ルールを記述したファイルを設定する際は、ネットワーク毎のルールに従ってネットワークから配信してもよい。
暗号化するか否かを定めたルールとしては、例えば、以下のような判断基準が個別に使用可能であり、これらの判断基準を複合的に組み合わせてルールを設定してもよい。なお、以下の判断基準又はルールは、一例であり、これに限定されない。
・http://スキームとhttps://スキームで使い分ける場合:
取得するリソースがhttp://スキームを使用する場合は、暗号化フラグを“1”に設定せずに平文通信を実施し、https://スキームを利用する場合は、暗号化フラグを“1”に設定して暗号化通信を実現する。
・取得リソースのタイプによって使い分ける場合:
取得するリソースのタイプ(css, javascript(登録商標), html, text, image等)によって暗号化又は平文通信を切り替える。例えば、共通的な情報しか含まれないcssファイルやjavascript等のタイプのリソースを取得するときには、平文通信を実施する。また例えば、動的に生成される可能性のあるtextやhtml等のタイプのリソースを取得するときには、暗号化通信を利用する。
・サーバが用意したプロファイル情報から選択する場合:
サーバが、「すべて暗号化通信を利用する」というルールから「すべて平文通信を利用する」というルールまで、いくつかのプロファイル情報を用意しておき、各プロファイル情報の中からどのプロファイル情報を優先的に選択するかを記述しておく。
なお、これらのルールは、以下に例示するように制御式を用いて特定のドメイン毎に使い分けることもできるものとする。
if(ドメインが○○○.com) then サーバプロファイルのうち最もプライバシが高いものを選択する。
else if(ドメインが△△△.com) then http://スキームには平文通信を適用する。
else cssとjavascriptの取得は、平文通信を適用する。
また、USEPヘッダ処理部101は、暗号化するか否かを選択する際に、暗号化するか否かをユーザに動的に選択させてもよい。すなわち、USEPヘッダ処理部101は、USEP上で動作するアプリケーションやソフトウェアがプロンプト等を用いてユーザに選択を求めることで暗号化するか否かを選択してもよい。なお、USEPヘッダ処理部101は、複数のリソースを取得する場合、個別のリソース毎に暗号化するか否かをユーザに動的に選択させてもよく、リソースのページ及び/又はドメイン毎にユーザに選択を求めてもよい。このとき、USEPヘッダ処理部101は、動的に選択した結果を設定ファイルに設定してもよい。また、これらの設定は、一度選択した結果をドメイン毎に保存できてもよく、前述したルールと同様に、制御式を用いて特定のドメイン毎に使い分けてもよい。
下位プロトコル連携部102は、USEPヘッダ処理部101から送信メッセージを受信し、下位プロトコル処理部13に送信する。下位プロトコル連携部102は、下位プロトコル処理部13から受信メッセージを受信し、USEPヘッダ処理部101に送信する。また、下位プロトコル連携部102は、セッション確立時に、上位プロトコル連携部100から利用可能なプロトコルの値を受信し、下位プロトコル処理部13に送信してもよい。
利用可能プロトコルDB103は、上位プロトコル連携部100から書込/読出可能なメモリであり、プロトコルリスト100cを記憶する。
プロトコルリスト100cは、図5に示すように、上位プロトコルとして利用可能なプロトコルのプロトコル名と、それらと一意に対応するプロトコルの値とが関連付けられて記憶されている。プロトコル名は、例えばHTTPやHTTP/2、SPDY等に対応するプロトコルの値として、http/1.1, h2, spdy/3.1等の値が関連付けられて記憶されてもよい。
なお、利用可能プロトコルDB103は、省略してもよい。利用可能プロトコルDB103が無い場合、上位プロトコル連携部100は、利用可能な上位プロトコルの値を上位プロトコル処理部11から受信してもよい。
ストリームID管理部104は、USEPレイヤにおけるUSEP上の通信を識別するためのストリームIDを管理する。具体的には、通信開始の際にUSEPヘッダ処理部101からの問い合わせに応じ、現在通信に使用中であり、かつ当該開始する通信に利用可能なストリームIDをストリームID管理DB105から読出し、USEPヘッダ処理部101に送信する。ストリームID管理部104は、現在通信に使用中であり、かつ当該開始する通信に利用可能なストリームIDがストリームID管理DB105に記憶されていない場合、ストリームID管理DB105から未使用のストリームIDを読出し、USEPヘッダ処理部101に送信する。すなわち、ストリームID管理部104は、ストリームID管理DB105に記憶されたストリームIDに基づき、通信先のホスト名に対応する使用中のストリームIDと重複しないID番号を、ヘッダ情報内に設定可能なストリームIDとして通信開始時にUSEPヘッダ処理部101に送信する。また、ストリームID管理部104は、通信終了の際にストリームID管理DB105に終了を通知し、当該終了する通信のストリームIDをストリームID記憶部105から削除する。
なお、ストリームID管理部104は、未使用のストリームID群から一つのID番号を選択する際には、ランダムに選択してもよく、最小又は最大のものを選択してもよい。
ストリームID管理DB105は、ストリームID管理部104から書込/読出可能なメモリであり、ストリームID管理リスト100dを記憶する。
ストリームID管理リスト100dは、図6に示すように、使用中のストリームIDと、通信先のサーバ装置のホスト名とを関連付けたストリームID管理リスト100dを記憶するデータベースである。ストリームID管理リスト100dは、現在使用中のストリームID以外に、使用可能であって、現在未使用のストリームIDを記憶してもよい。このとき、現在未使用のストリームIDに対応する通信先のサーバ装置のホスト名は、“−”(ハイフン)等によって未使用であることを示してもよい。
なお、ストリームID管理部104及びストリームID管理DB105は、USEPに基づく通信をクライアント装置10から開始するため、サーバ装置20には存在しない。
下位プロトコル処理部13は、サーバ装置20へ送信するメッセージをUSEP処理部12から受信し、下位プロトコルに関する処理を実施し、送受信部14に送信する。具体的には、下位プロトコル処理部13は、USEPレイヤにおける複数の通信パケットを単一のTCPコネクション上で処理し、送信メッセージとして送受信部14に送信する。下位プロトコル処理部13は、サーバ装置20から受信したメッセージを送受信部14から受信し、下位プロトコルに関する処理を実施し、クライアント装置USEP処理部12へ送信する。また、下位プロトコル処理部13は、セッション確立時に、下位プロトコルの利用可能性を交渉する。下位プロトコル処理部13は、セッション確立時に、下位プロトコルの利用可能性を交渉する際に、同時にUSEPレイヤの利用可能性も交渉してもよい。また、下位プロトコル処理部13は、下位プロトコル連携部102から利用可能な上位プロトコルの値を受信し、USEPレイヤの利用可能性の交渉時に上位プロトコルの利用可能性についても交渉してもよい。USEPレイヤの利用可能性の交渉時に上位プロトコルの利用可能性を同時に交渉することで、上位レイヤ利用可能性の交渉時に必要なラウンドトリップを削減することができる。
送受信部14は、下位プロトコル連携部102から送信メッセージを受信し、サーバ装置20に送信する。送受信部14は、サーバ装置20から受信メッセージを受信し、下位プロトコル連携部102に送信する。
次に、以上のように構成された通信システムの動作について図7及び図8に示すシーケンス図及び図9に示す取得リソースを示す模式図を用いて説明する。なお、以下の説明は、クライアント装置10及びサーバ装置20が、USEPをサポートしており、図1に示したように、ネットワークを介して物理的に接続されている場合について述べる。
まず、セッション確立時の動作について、図7のシーケンス図を用いて説明する。
いま、クライアント装置10は、サーバ装置20との間にTCPハンドシェークによりTCPコネクションを確立する(ST100〜ST102)。具体的には、以下に示すように、下位プロトコル処理部13,23がステップST100〜ST102を実行する。なお、クライアント装置10とサーバ装置20間にTCPコネクションが既に存在する場合は、当該既存のTCPコネクションを再利用してもよい。
下位プロトコル処理部13は、サーバ装置20にSYN(Synchronize)フラグを設定したTCPセグメントを送信する(ST100)。下位プロトコル処理部23は、クライアント装置10にSYNフラグとACK(Acknowledgement)フラグを設定したTCPセグメントを送信する(ST101)。下位プロトコル処理部13は、サーバ装置20にACKフラグを設定したTCPセグメントを送信する(ST102)。
次に、クライアント装置10は、サーバ装置20との間にWebSocketの接続を行う。クライアント装置10は、WebSocketの利用可能性を交渉する際に、USEPセッションの利用可能性についても交渉する(ST103〜ST104)。具体的には、以下に示すように、クライアント装置USEP処理部12、サーバ装置USEP処理部22及び下位プロトコル処理部13,23がステップST103〜ST104を実行する。
クライアント装置USEP処理部12及び下位プロトコル処理部13は、ハンドシェーク要求をサーバ装置20に送信する。クライアント装置USEP処理部12及び下位プロトコル処理部13は、ハンドシェーク要求の際に、WebSocketの接続先を指定する「Host」ヘッダ及びハンドシェーク応答を得るための「Sec−WebSocket−Key」ヘッダを指定する。クライアント装置USEP処理部12及び下位プロトコル処理部13は、HTTP Upgradeを利用し、「Sec−WebSocket−Protocol」ヘッダに“usep”値を設定することでUSEPセッションの利用可能性を交渉する(ST103)。なお、上位プロトコルの利用可能性についても同時に交渉する場合、下位プロトコル処理部13は、クライアント装置USEP処理部12から利用可能な上位プロトコルの値を受信してもよい。下位プロトコル処理部13は、受信した上位プロトコルの値を用いて、「Sec−WebSocket−Protocol」ヘッダに“usep−h2”及び“usep-spdy/3.1”等のIANA(Internet Assigned Numbers Authority)に重複して登録されていない値を設定し、上位プロトコルの利用可能性を同時に交渉してもよい。
サーバ装置USEP処理部22及び下位プロトコル処理部23は、ハンドシェーク応答をクライアント装置10に送信する。ハンドシェーク応答の際に、サーバ装置USEP処理部22及び下位プロトコル処理部23は、USEPセッションが利用可能な場合、クライアントとのコネクションを維持するための「Sec−WebSocket−Accept」及びWebSocketのバージョンを指定する「Sec−WebSocket−Version」と共に、「101 Switching Protocol」レスポンスをクライアント装置10に送信し、USEPの利用可能性を通知する(ST104)。以上より、クライアント装置10及びサーバ装置20は、USEPによる通信を開始する。
次に、サーバ装置20内のリソースを取得する際の動作について、図8のシーケンス図を用いて説明する。なお、サーバ装置20から取得されるリソースは、図9に示すように上位プロトコルとしてHTTP又はHTTPSを利用したページ上の3種類のファイル(テキストA,イメージB,テキストC)であるとする。また、暗号化するか否かの選択の結果、テキストA及びイメージBは暗号化し、テキストCは暗号化しないものとする。また、イメージBは、テキストA及びテキストCと比較して容量が大きいため、サーバ装置20における応答処理に時間を要するものとする。
まず、クライアント装置10は、使用中のストリームID及び通信先のサーバ装置のホスト名を関連付けて記憶する。なお、この例では、サーバ装置20に対する使用中のストリームIDはないものとする。
クライアント装置10は、テキストAに関する要求メッセージを作成する(ST200)。具体的には、クライアント装置10は、メッセージ作成に際し、使用中のストリームIDと重複しないID番号を、通信開始時にUSEPのヘッダ情報内のストリームIDとして設定する。ここでは、USEPのヘッダ情報内のストリームIDに“1”を設定する。クライアント装置10は、暗号化するか否かを選択する。なお、暗号化するか否かの選択に際しては、予め定められたルールに基づき静的に選択してもよく、ユーザに動的に選択させてもよい。クライアント装置10は、選択結果に基づき、USEPヘッダ情報内の暗号化フラグを設定する。ここでは、暗号化フラグに暗号化を示す“1”を設定する。また、クライアント装置10は、USEPヘッダ情報内の上位レイヤ情報を設定する。ここでは、上位レイヤとしてHTTPSを使用するため、HTTPSを示す値(例えばhttps)を上位レイヤ情報に設定する。
クライアント装置10は、HTTPの「GET」メソッドを用い、テキストAの取得を要求するメッセージをサーバ装置20に送信する(ST201)。
クライアント装置10は、ステップST200と同様に、イメージBに関する要求メッセージを作成する。クライアント装置10は、メッセージ作成に際し、USEPのヘッダ情報内のストリームIDに“2”を設定し、暗号化フラグに暗号化を示す“1”を設定し、上位レイヤ情報に“https”を設定する(ST202)。クライアント装置10は、HTTPの「GET」メソッドを用い、イメージBの取得を要求するメッセージをサーバ装置20に送信する(ST203)。
クライアント装置10は、ステップST200,202と同様に、テキストCに関する要求メッセージを作成する。クライアント装置10は、メッセージ作成に際し、USEPのヘッダ情報内のストリームIDに“3”を設定し、暗号化フラグに平文を示す“0”を設定し、上位レイヤ情報に“http/1.1”を設定する(ST204)。クライアント装置10は、HTTPの「GET」メソッドを用い、テキストCの取得を要求する送信メッセージをサーバ装置20に送信する(ST205)。
すなわち、クライアント装置10は、ステップST201,203,205において、異なるストリームIDが設定された複数のメッセージを、単一のTCPコネクション上で送信する。
サーバ装置20は、ステップST201で送信されたテキストAの要求メッセージを受信し、これに対する応答メッセージを作成する。サーバ装置20は、応答メッセージ作成に際し、受信したメッセージのUSEPヘッダ情報内のストリームID及び暗号化フラグと同じ値を設定する。また、サーバ装置20は、応答メッセージのデータ情報内に、暗号化したテキストAを設定する(ST206)。サーバ装置20は、「OK」ステータスと共に、暗号化したテキストAを応答メッセージとしてクライアント装置10に送信する(ST207)。
サーバ装置20は、ステップST205で送信されたテキストCの要求メッセージを受信し、これに対する応答メッセージを作成する。サーバ装置20は、応答メッセージ作成に際し、受信したメッセージのUSEPヘッダ情報内のストリームID及び暗号化フラグと同じ値を設定する。また、サーバ装置20は、応答メッセージのデータ情報内に、平文のテキストCを設定する(ST208)。サーバ装置20は、「OK」ステータスと共に、平文のテキストCを応答メッセージとしてクライアント装置10に送信する(ST209)。なお、クライアント装置10から受信する要求メッセージは、イメージBを要求するメッセージの方が先に到着しているが、応答処理に要する時間はテキストCの方が短いため、テキストCに関する応答メッセージ送信がイメージBに関する応答メッセージ送信よりも早くなっている。
サーバ装置20は、ステップST203で送信されたイメージBの要求メッセージを受信し、これに対する応答メッセージを作成する。サーバ装置20は、応答メッセージ作成に際し、受信したメッセージのUSEPヘッダ情報内のストリームID及び暗号化フラグと同じ値を設定する。また、サーバ装置20は、応答メッセージのデータ情報内に、暗号化したイメージBを設定する(ST210)。サーバ装置20は、「OK」ステータスと共に、暗号化したイメージBを応答メッセージとしてクライアント装置10に送信する(ST211)。
クライアント装置10は、全ての要求データを受信した後、USEP通信を終了する。クライアント装置10は、USEP終了時に使用したストリームIDを削除する(ST212)。
以上詳述したように、一実施形態では、通信システムは、第1エンティティ装置及び第2エンティティ装置を備えている。上記通信システムは、上記第1エンティティ装置からの要求に対して上記第2エンティティ装置が応答する、ネットワークを介した通信をする際に、上記各エンティティ装置間で暗号化するか否かを選択しつつ多重化通信をするための通信プロトコルを備える。上記通信プロトコル上の通信パケットは、上記通信パケットを暗号化するか否かを示す暗号化フラグ、上記通信パケットの通信に使用する上位レイヤの情報を示す上位レイヤ情報、及び上記通信プロトコル上で行われる通信を識別するストリームIDをヘッダ情報に含む。上記第1エンティティ装置は、使用中のストリームID及び上記第2エンティティ装置のホスト名を関連付けて記憶する。上記記憶したストリームIDに基づき、上記ホスト名に対応する使用中のストリームIDと重複しないID番号を通信開始時に上記ヘッダ情報内のストリームIDとして設定する。上記各エンティティ装置は、上記通信パケットを暗号化するか否かを選択する。上記選択結果に基づき、上記ヘッダ情報内の暗号化フラグを設定する。上記ヘッダ情報内の上位レイヤ情報を設定する。異なるストリームIDが設定された複数の上記通信パケットを、単一の下位レイヤのコネクション上で送受信するようにしている。
したがって、通信プロトコル上の通信パケットは、暗号化するか否かが選択され、暗号化フラグが設定されると共に、動作させる上位レイヤが設定される。そして、単一の下位レイヤのコネクション上で送受信される複数の通信パケットは、ストリームIDによって識別される。
これにより、クライアント装置及びサーバ装置間において暗号化するか否かを選択しつつ多重化通信をすることができるようになり、セキュリティを適切に保護しつつ、処理負荷を軽減することが可能となる。
補足すると、本実施形態では、暗号化通信と平文通信とを切り替え可能で且つ上位レイヤを多重化するためのUSEPというプロトコルを導入している。なお、従来の通信システムは、あるホストに対して暗号通信と平文通信を混在させることはできない。
本実施形態では、USEPによってユーザが選択的に暗号化通信と平文通信とを制御できるため、例えば、ユーザの個人情報等が含まれないデータに関しては暗号化通信を行わずに平文通信を行うといった制御が可能となる。また、ユーザは、多重化の恩恵によりセッション数を増やすことなく通信が可能となる。さらに、ユーザは、暗号化通信と平文通信とを切り替えることで、プライバシを含む通信のセキュリティを適切に守りつつ、端末の処理負荷やネットワークリソースの利用を必要最低限に抑えることができる。また、通信キャリアやISPなどの事業者は、通信パケットの監視に基づくサービスを引き続きユーザに提供することができる。
また、本実施形態では、通信機能の中間レイヤのプロトコルをUSEPとして定義することで暗号化通信と平文通信(非暗号化通信)との混在化及び多重化を実現したことに加え、静的な及び動的な選択方法をそれぞれ定義している。補足すると、本実施形態では、リソースに応じた暗号化通信と平文通信との選択権をユーザがもっている。すなわち、本実施形態では、ユーザによる静的な又は動的な選択方法のいずれによっても、暗号化通信と平文通信とを切り替えることができる。
例えば、通信パケットを選択するか否かを選択する際、予め定められたルールに基づいて暗号化するか否かを静的に選択するようにしている。
これにより、USEP通信の際に予め定められたセキュリティレベルを遵守したルールを設定することが出来るようになり、よりセキュリティを適切に保護することが可能となる。
また、通信パケットを選択するか否かを選択する際、ユーザに動的に選択させるようにすることもできる。
これにより、USEP通信の際に状況に応じた柔軟なセキュリティレベルを設定することが出来るようになり、よりセキュリティを保護することが可能となる。
その他、クライアント装置及びサーバ装置の構成や機能、通信手順、処理手順と処理内容等についても、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。
例えば、通信システム1は、クライアント装置10及びサーバ装置20間にプロキシ装置30を更に備えていてもよい。すなわち、クライアント装置10及びサーバ装置20は、プロキシ装置30を介して接続されていてもよい。プロキシ装置30は、USEPをサポートしていてもよく、USEPをサポートしていなくてもよい。なお、以下の説明では、「プロキシ装置」を、「第3エンティティ装置」と読み替えてもよい。
クライアント装置10及びサーバ装置20は、プロキシ装置30がUSEPをサポートしていない場合、クライアント装置10及びサーバ装置20間の通信をプロキシ装置30がUSEPの下位レイヤでトンネルすることで、USEPによる通信の接続を確立してもよい。
このときのセッション確立時の動作を図10に示すシーケンス図を用いて説明する。
クライアント装置10は、プロキシ装置30との間にTCPハンドシェークによりTCPコネクションを確立する(ST300〜ST302)。
クライアント装置10は、HTTPの「CONNECT」メソッドを使用して、プロキシ装置30にサーバ装置20への接続要求を行う(ST303)。
プロキシ装置30は、サーバ装置20との間にTCPハンドシェークによりTCPコネクションを確立する(ST304〜ST306)。
プロキシ装置30は、プロキシ装置30とサーバ装置20との間でTCPコネクションが確立できた場合、クライアント装置10に「200 Connetion Established」レスポンスを送信し、TCPコネクションが確立されたことを通知する(ST307)。
クライアント装置10は、サーバ装置20との間にWebSocketの接続を行う。この時、WebSocket交渉を使って、USEPセッションの利用可能性についても交渉する(ST308〜ST309)。以上より、クライアント装置10及びサーバ装置20は、プロキシ装置30がトンネリングを行うことでUSEPによる通信を開始する。
このように、この変形例では、クライアント装置10及びサーバ装置20間に備えられたプロキシ装置30が、クライアント装置10及びサーバ装置20間のUSEP通信を下位レイヤでトンネリングするようにしている。
これにより、プロキシ装置30がUSEPをサポートしていなくても、クライアント装置10及びサーバ装置20間で暗号化するか否かを選択しつつ多重化通信を実施することができ、よりセキュリティを適切に保護しつつ処理負荷を軽減することが可能となる。
また、クライアント装置10及びサーバ装置20は、プロキシ装置30がUSEPをサポートしている場合、プロキシ装置30がUSEPによる通信を終端することで、USEPによる通信の接続を確立してもよい。
このときのセッション確立時の動作を図11に示すシーケンス図を用いて説明する。
クライアント装置10は、プロキシ装置30との間にTCPハンドシェークによりTCPコネクションを確立する(ST400〜ST402)。
クライアント装置10は、プロキシ装置30との間にWebSocketの接続を行う。この時、WebSocket交渉を使って、USEPセッションの利用可能性についても交渉する(ST403〜ST404)。以上より、クライアント装置10とプロキシ装置30間でUSEPによる通信の接続を確立する。
次に、プロキシ装置30は、サーバ装置20との間にTCPハンドシェークによりTCPコネクションを確立する(ST405〜ST407)。
プロキシ装置30は、サーバ装置20との間にWebSocketの接続を行う。この時、WebSocket交渉を使って、USEPセッションの利用可能性についても交渉する(ST408〜ST409)。以上より、プロキシ装置30とサーバ装置20間でUSEPによる通信の接続を確立する。したがって、クライアント装置10とサーバ装置20は、プロキシ装置30がUSEP通信を終端することで、USEP通信の接続を確立する。
このように、この変形例では、クライアント装置10及びサーバ装置20間に備えられたプロキシ装置30が、USEP通信を終端するようにしている。
これにより、プロキシ装置30がUSEPをサポートしている場合、プロキシ装置30がUSEP通信を終端することでクライアント装置10及びサーバ装置20間で暗号化するか否かを選択しつつ多重化通信を実施することができ、よりセキュリティを適切に保護しつつ処理負荷を軽減することが可能となる。
また、クライアント装置10及びプロキシ装置30は、プロキシ装置30がUSEPをサポートしている場合、クライアント装置10及びプロキシ装置30間でUSEP通信を実施してもよく、プロキシ装置30及びサーバ装置20間でUSEP通信を実施しなくてもよい。なお、プロキシ装置30及びサーバ装置20間でUSEP通信を実施しない場合、サーバ装置20は、USEPをサポートしていなくてもよい。
このときのセッション確立時の動作を図12に示すシーケンス図を用いて説明する。
クライアント装置10は、プロキシ装置30との間にTCPハンドシェークによりTCPコネクションを確立する(ST500〜ST502)。
クライアント装置10は、プロキシ装置30との間にWebSocketの接続を行う。この時、WebSocket交渉を使って、USEPセッションの利用可能性についても交渉する(ST503〜ST504)。以上より、クライアント装置10とプロキシ装置30間でUSEPによる通信の接続を確立する。
次に、プロキシ装置30は、サーバ装置20との間にTCPハンドシェークによりTCPコネクションを確立する(ST505〜ST507)。
プロキシ装置30は、サーバ装置20との間にWebSocketの接続を行う。この時、WebSocket交渉を使って、USEPセッションの利用可能性についても交渉する(ST508)。
サーバ装置20は、「400 Bad Request」レスポンス等をプロキシ装置30に送信し、USEPが利用不可能であることを通知する(ST509)。プロキシ装置30及びサーバ装置20は、USEP以外のプロトコルについての利用可能性を交渉し、利用可能なプロトコルに切替える。以上より、クライアント装置10とプロキシ装置30間でUSEP通信を実施し、プロキシ装置30とサーバ装置20間でUSEP以外の通信を実施する。
このように、この変形例では、クライアント装置10及びサーバ装置20間に備えられたプロキシ装置30がUSEP通信を終端し、プロキシ装置30及びサーバ装置20間の通信は、USEP通信を実施しないようにしている。
これにより、プロキシ装置30がUSEPをサポートしている場合、サーバ装置20側においてUSEP通信が実施できない状況においてもクライアント装置10及びプロキシ装置30間で暗号化するか否かを選択しつつ多重化通信を実施することができ、よりセキュリティを適切に保護しつつ処理負荷を軽減することが可能となる。
[他の実施形態]
本発明の他の実施形態は、USEPを動作させる下位レイヤとしてTCPのように信頼性を高めるための制御機能を備えたプロトコルを用いない場合を想定する。すなわち、本発明の他の実施形態における通信システム1は、USEPをUDP(User Datagram Protocol)上で動作させてもよい。以下の説明は、USEPをUDP上で動作させる場合を例に挙げて述べる。
クライアント装置10及びサーバ装置20は、USEPをUDP上で動作させてUSEP通信を実施する場合、図13に示す如きプロトコルスタック100fを実装している。
クライアント装置10及びサーバ装置20は、UDPを動作させることで通信を実施してもよい。また、クライアント装置10及びサーバ装置20は、UDP上でUSEPを動作させてもよい。
クライアント装置10及びサーバ装置20は、USEP上で任意のアプリケーションプロトコルを動作させてもよい。具体的には、平文通信にはHTTP、HTTP/2、CoAP(Constrained Application Protocol)及びMQTT(Message Queuing Telemetry Transport)プロトコルを動作させてもよく、暗号化通信にはQUIC(Quick UDP Internet Connections)又はDTLS(Datagram Transport Layer Security)上でHTTP/2及びSPDYを動作させてもよい。
本実施形態におけるUSEPのパケットフォーマット100gは、図14に示すように、ヘッダ情報とデータ情報を含む。ヘッダ情報は、暗号化フラグ、上位レイヤ情報、ストリームIDに加えて、通信パケットの到達保証を実施するか否かを示す到達保証実施フラグ及び通信パケットの到達確認がされたか否かを示す到達確認フラグを更に含む。なお、パケットフォーマット100gは、あくまで一例であり、フォーマットやビット長、識別に利用される情報の組み合わせはこの限りではない。また、パケットフォーマット100gは、ヘッダ情報を拡張することで、TCP等で実現されている輻輳制御の機能や、DSCP(Differentiated Services Code Point)等で実現されている優先制御の機能を導入してもよい。
到達保証実施フラグは、USEPレイヤで到達保証を実施するか否かを示す変数である。到達保証実施フラグは、1ビットで実現されてもよい。到達保証実施フラグは、1ビットで実現される場合、USEPが到達保証を実施しないことを示す場合に“0”が設定され、USEPが到達保証を実施することを示す場合に“1”が設定されてもよい。
到達確認フラグは、到達保証をUSEPレイヤで実施する際に、到達確認が行われたか否かを示す変数である。到達確認フラグは、1ビットで実現されてもよい。この場合、通信パケットを受信した際に値を“1”にした到達確認フラグを含む到達確認メッセージを送信することで、当該通信パケットの送信元に対して、当該通信パケットの到達確認が行われたことを示す。すなわち、到達確認フラグの値が“1”に設定された通信パケットが返送されない場合、当該通信パケットの到達が保証されないことを示す。
クライアント装置USEP処理部12及びサーバ装置USEP処理部22は、図15に示すように、一実施形態の機能構成に加え、再送制御部106を更に備える。
USEPヘッダ処理部101は、一実施形態の機能に加え、以下の機能を備える。USEPヘッダ処理部101は、上位プロトコル連携部100から送信メッセージを受信すると、当該送信メッセージのヘッダ情報内の到達保証実施フラグを“1”に設定する。USEPヘッダ処理部101は、到達保証を実施する送信メッセージを、再送制御部106に送信する。また、USEPヘッダ処理部101は、下位プロトコル連携部102から受信メッセージを受信すると、当該受信メッセージを再送制御部106に送信する。また、USEPヘッダ処理部101は、下位プロトコル連携部102から受信メッセージを受信すると、ヘッダ情報内の到達確認フラグを“1”に設定した通信パケットを、到達確認メッセージとして送信元へ返送する。なお、送信元へ返送される通信パケットのヘッダ情報内のストリームIDは、受信した通信パケットのストリームIDと同一とする。また、到達確認フラグが“1”に設定された通信パケットは、要求メッセージに対する応答メッセージ内に含まれていてもよい。
再送制御部106は、USEPヘッダ処理部101から到達保証を実施するメッセージを受信する。再送制御部106は、到達保証実施フラグが“1”に設定されたメッセージを受信すると、当該メッセージのヘッダ情報内の到達確認フラグを確認する。再送制御部106は、到達確認フラグを確認した結果、到達確認フラグが“1”に設定されていないメッセージについて、当該メッセージのヘッダ情報内のストリームIDを図16に示すように到達未確認ストリームIDリスト100hに記憶する。再送制御部106は、到達確認フラグを確認した結果、到達が確認されたメッセージについて、当該メッセージのヘッダ情報内のストリームIDを到達未確認ストリームIDリスト100hから削除する。また、再送制御部106は、到達未確認ストリームIDリスト100hに基づき、再送制御を実施する。なお、再送制御部106は、再送制御に際し、これまでに送信した通信パケットの到達確認メッセージが返送されるまでの時間を計測し、計測時間が予め定めた時間又は直近の計測結果に基づいて算出される時間より大きい場合にメッセージの再送要求を行ってもよい。ただし、再送制御部106の再送制御方法は、この限りではない。
次に、以上のように構成された通信システムの動作について図17、図18及び図19に示すシーケンス図を用いて説明する。なお、以下の説明は、クライアント装置10及びサーバ装置20が、USEPをサポートしており、図1に示したように、ネットワークを介して物理的に接続されている場合について述べる。
まず、セッション確立時の動作について、図17のシーケンス図を用いて説明する。
クライアント装置10は、サーバ装置20との間にTCPハンドシェークによりTCPコネクションを確立する(ST600〜ST602)。
クライアント装置10は、HTTP等による通信を開始する(ST603)。
サーバ装置20は、「Alternate−Protocol」ヘッダに“usep”値を設定することでUSEPセッションの利用可能性をクライアント装置10と交渉する(ST604)。
クライアント装置10は、USEPセッションが利用可能な場合、TCPコネクションを切断し(ST605〜ST607)、UDP上でのUSEP通信に切り替える。具体的には、クライアント装置10及びサーバ装置20はがステップST605〜ST607を実行する。
クライアント装置10は、サーバ装置20にFIN(Finish)フラグを設定したTCPセグメントを送信する(ST605)。サーバ装置20は、クライアント装置10にFINフラグとACKフラグを設定したTCPセグメントを送信する(ST606)。クライアント装置10は、サーバ装置20にACKフラグを設定したTCPセグメントを送信する(ST607)。以降は、クライアント装置10は、サーバ装置20に対してUDP上でのUSEP通信を実行する。
次に、サーバ装置20内のリソースを取得する際の動作について、図18のシーケンス図を用いて説明する。なお、サーバ装置20から取得されるリソースは、図9に示すように上位プロトコルとしてHTTPを利用したページ上のうち、1種類のファイル(テキストA)であるとする。また、暗号化するか否かの選択結果は、テキストAを暗号化することを示すものとする。
クライアント装置10は、テキストAに関する要求メッセージを作成する。クライアント装置10は、当該メッセージの通信パケット作成に際し、ヘッダ情報内のストリームIDに“1”を設定し、暗号化フラグに暗号化を示す“1”を設定する。
クライアント装置10は、USEPヘッダ内の到達保証実施フラグを設定する。ここでは、到達保証実施フラグに“1”を設定する。また、クライアント装置10は、USEPヘッダ内の到達確認フラグを設定する。ここでは、到達確認フラグに“0”を設定する(ST700)。
クライアント装置10は、まだ到達確認フラグが“1”に設定されていない当該通信パケットについて、ストリームIDのID番号である“1”を、到達未確認ストリームIDリスト100hに記憶する(ST701)。クライアント装置10は、HTTPの「GET」メソッドを用い、テキストAの取得を要求するメッセージをサーバ装置20に送信する(ST702)。
サーバ装置20は、テキストAの要求メッセージを受信し、これに対する応答メッセージとして、到着確認メッセージを作成する(ST703)。具体的には、サーバ装置20は、到達保証実施フラグが“1”に設定されており、到達確認フラグが“1”に設定されていないメッセージを受信すると、到達確認フラグが“1”に設定された到着確認メッセージを作成する。なお、到着確認メッセージのストリームIDは、受信した要求メッセージのストリームIDと同一のID番号を設定する。ここでは、サーバ装置20は、応答メッセージ作成に際し、USEPヘッダ情報内のストリームIDに“1”を設定し、暗号化フラグに“1”を設定し、到達保証実施フラグ及び到達確認フラグに“1”を設定する。また、サーバ装置20は、応答メッセージのデータ情報内に、暗号化したテキストAを設定する。
サーバ装置20は、「OK」ステータスと共に、暗号化したテキストAを応答メッセージとしてクライアント装置10に送信する(ST704)。
クライアント装置10は、応答メッセージとして、到着確認メッセージを受信する。クライアント装置10は、受信した到着確認メッセージのヘッダ情報内の到達保証実施フラグが“1”であることを確認し、当該メッセージを再送制御部106に送信する。再送制御部106は、到達未確認ストリームIDリスト100h内を検索し、ストリームID“1”をリストから削除する(ST705)。
クライアント装置10は、全ての要求データを受信した後、USEP通信を終了する。クライアント装置10は、USEP終了時に使用したストリームIDを削除する(ST706)。
なお、セッション確立時の動作は、図17に示した「Alternate−Protocol」ヘッダを用いてUSEPセッションの利用可能性を交渉するシーケンスに限らず、ダイレクトにUSEPによる接続を試みてもよい。以下に、ダイレクトにUSEPによる接続を試みる際のセッション確立時の動作について、図19のシーケンス図を用いて説明する。
クライアント装置10は、送信する通信パケットについてヘッダ情報内の到達保証実施フラグを設定する。クライアント装置10は、到達保証を実施する値に到達保証実施フラグが設定された通信パケットをサーバ装置20に送信する。サーバ装置20は、到達保証実施フラグが設定された通信パケットを受信する(ST800)。
サーバ装置20は、到達保証実施フラグが設定された通信パケットを受信すると、到達確認メッセージを作成する。すなわち、サーバ装置20は、到達確認がされた値に到達確認フラグが設定された通信パケットをクライアント装置10に送信する。クライアント装置10は、到達確認フラグが設定されたUSEPパケットを受信する(ST801)。以上より、クライアント装置10及びサーバ装置20の双方でUSEPをサポートしていることが確認できるため、クライアント装置10は、USEPによる通信に切り替える。
以上詳述したように、他の実施形態では、通信規約100g上の通信パケットは、通信パケットの到達保証を実施するか否かを示す到達保証実施フラグ及び通信パケットの到達確認がされたか否かを示す到達確認フラグを更に含む。各エンティティ装置10,20は、上記ヘッダ情報内の到達保証実施フラグを設定する。各エンティティ装置10,20は、上記ヘッダ情報内の到達確認フラグを設定する。上記到達確認フラグが設定されていない通信パケットのストリームIDを記憶する。到達保証を実施する値に到達保証実施フラグが設定され、到達確認がされた値に到達確認フラグが設定されていない通信パケットを受信すると、到達確認がされた値に到達確認フラグが設定された到着確認メッセージを送信するようにしている。
したがって、信頼性を高める制御機能を備えていないプロトコル上でUSEP通信を実施する際にも、USEPレイヤ上で再送制御を実施することができるようになり、より信頼性を高めることが可能となる。
その他、クライアント装置及びサーバ装置の構成や機能、通信手順、処理手順と処理内容等についても、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。
例えば、通信システム1は、プロキシ装置30を備えていてもよい。クライアント装置10及びサーバ装置20は、プロキシ装置30を介して接続されていてもよい。プロキシ装置30は、USEPをサポートしていてもよく、USEPをサポートしていなくてもよい。
クライアント装置10及びサーバ装置20は、プロキシ装置30がUSEPをサポートしていない場合、USEPの下位レイヤでトンネルすることで、USEPによる通信の接続を確立してもよい。
このときのセッション確立時の動作を図20に示すシーケンス図を用いて説明する。
クライアント装置10及びサーバ装置20は、プロキシ装置30がトンネリングすることで、TCPコネクションを確立する(ST900〜ST907)。具体的には、ステップST900〜ST907は、ステップST300〜ST307と同等であるため、説明を省略する。
クライアント装置10は、HTTP等による通信を開始する(ST908)。
サーバ装置20は、「Alternate−Protocol」ヘッダに“usep”値を設定することでUSEPセッションの利用可能性をクライアント装置10と交渉する(ST909)。
クライアント装置10は、USEPセッションが利用可能な場合、TCPコネクションを切断し(ST910〜ST912)、UDP上でのUSEP通信に切り替える。以上より、クライアント装置10及びサーバ装置20は、プロキシ装置30がトンネリングすることで、USEPによる通信の接続を確立する。
このように、この変形例では、クライアント装置10及びサーバ装置20間に備えられたプロキシ装置30が、クライアント装置10及びサーバ装置20間のUSEP通信を下位レイヤでトンネルするようにしている。
これにより、プロキシ装置30がUSEPをサポートしていない状況で、信頼性の高い制御機能を備えていない下位プロトコル上でUSEPを動作させる場合でも、クライアント装置10及びサーバ装置20間で暗号化するか否かを選択しつつ多重化通信を実施することができる。したがって、よりセキュリティを適切に保護しつつ処理負荷を軽減することが可能となる。
また、クライアント装置10及びサーバ装置20は、プロキシ装置30がUSEPをサポートしている場合、プロキシ装置30がUSEPによる通信を終端することで、USEPによる通信の接続を確立してもよい。
このときのセッション確立時の動作を図21に示すシーケンス図を用いて説明する。
クライアント装置10及びプロキシ装置30は、HTTPの「Alternate−Protocol」ヘッダを用いてUSEPセッションの利用可能性を交渉し、USEPによる通信の接続を確立する(ST1000〜ST1007)。具体的には、ステップST1000〜ST1007は、ステップST600〜ST607と同等であるため、説明を省略する。
プロキシ装置30及びサーバ装置20は、HTTPの「Alternate−Protocol」ヘッダを用いてUSEPセッションの利用可能性を交渉し、USEPによる通信の接続を確立する(ST1008〜ST1015)。具体的には、ステップST1008〜ST1015は、ステップST600〜ST607と同等であるため、説明を省略する。以上より、クライアント装置10及びサーバ装置20は、プロキシ装置30が終端することにより、USEPによる通信の接続を確立する。
なお、プロキシ装置30を介するUSEPセッションの確立方法は、ダイレクトにUSEPによる接続を試みる方法に適用してもよい。
このように、この変形例では、クライアント装置10及びサーバ装置20間に備えられたプロキシ装置30が、USEP通信を終端するようにしている。
これにより、プロキシ装置30がUSEPをサポートしている場合、信頼性の高い制御機能を備えていない下位プロトコル上でUSEPを動作させる場合でも、プロキシ装置30がUSEP通信を終端することで暗号化するか否かを選択しつつ多重化通信を実施することができる。したがって、よりセキュリティを適切に保護しつつ処理負荷を軽減することが可能となる。
要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。