JP6194292B2 - 通信システム、方法及びプログラム - Google Patents

通信システム、方法及びプログラム Download PDF

Info

Publication number
JP6194292B2
JP6194292B2 JP2014163893A JP2014163893A JP6194292B2 JP 6194292 B2 JP6194292 B2 JP 6194292B2 JP 2014163893 A JP2014163893 A JP 2014163893A JP 2014163893 A JP2014163893 A JP 2014163893A JP 6194292 B2 JP6194292 B2 JP 6194292B2
Authority
JP
Japan
Prior art keywords
communication
stream
usep
protocol
entity device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014163893A
Other languages
English (en)
Other versions
JP2016038881A (ja
Inventor
徹也 日紫喜
徹也 日紫喜
巧 大羽
巧 大羽
新 小池
新 小池
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2014163893A priority Critical patent/JP6194292B2/ja
Publication of JP2016038881A publication Critical patent/JP2016038881A/ja
Application granted granted Critical
Publication of JP6194292B2 publication Critical patent/JP6194292B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Description

この発明は、通信システム、方法及びプログラムに関する。
インターネットを主とした従来の通信システムでは、クライアントからのリクエストに対してサーバがレスポンスする構造を持つ、ＨＴＴＰ(HyperText Transfer Protocol)が広く利用されている（例えば、非特許文献１参照。）。
しかしながら、ＨＴＴＰは、ヘッダのサイズが大きい、多重化ができない等、ネットワークリソース削減の観点から非効率な点が知られている。したがって、用途に応じて改良された様々なプロトコルが提案されている。
例えば、ＳＰＤＹプロトコルは、ＴＣＰ(Transmission Control Protocol)上で動作し、同一ホストに対する通信において、単一のＴＣＰコネクション上で複数のストリームを多重化して利用できるようデザインされたプロトコルである（例えば、非特許文献３参照。）。また、ＳＰＤＹは、ユーザのセキュリティ及びプライバシ保護の観点からＴＣＰ上で動作する暗号化のためのプロトコルであるＴＬＳ(Transport Layer Security)上での利用が事実上必須となっており、ＴＬＳの利用可能性を交渉する際に、クライアント及びサーバが互いにＳＰＤＹの利用可能性を確認する設計になっている（例えば、非特許文献２参照。）。
また、ＳＰＤＹをベースとして策定されたプロトコルとしてＨＴＴＰ／２(HyperText Transfer Protocol version 2)が知られている（例えば、非特許文献４参照。）。ＨＴＴＰ／２の主な特徴は、ＳＰＤＹと同等であり、ＴＬＳ上での利用が典型例となっている。
"Hypertext Transfer Protocol -- HTTP/1.1", IETF RFC 2616, 1999. "The Transport Layer Security (TLS) Protocol Version 1.2", IETF RFC 5246, 2008. "SPDY Protocol", IETF Internet Draft, draft-mbelshe-httpbis-spdy-00, 2012. "Hypertext Transfer Protocol Version 2", IETF Internet Draft, draft-ietf-httpbis-http2-13, 2014.
しかしながら、以上のような通信システムは、暗号化通信が典型例である従来のプロトコルをそのまま利用すると、今後、増大が予想される非力なデバイスに対し、処理負荷を軽減するために暗号化通信を最小限に抑える、といった要件を満たすことができない。
一方、通信キャリアやＩＳＰ(Internet Service Provider)等は、通信システムの平文通信のパケット監視に基づくマルウェア検出、有害サイトのブロック、キャッシュの配置による高速化及び特定トラフィックの圧縮による高速配信等のサービスを提供している。このような平文通信に対するサービスは、暗号化通信が典型例である従来のプロトコルをそのまま利用すると、提供することができなくなる。
しかしながら、上述した暗号化通信に関する課題の解決のために単純に平文通信を推奨することは、通信システムのセキュリティの観点から好ましくない。
すなわち、従来の通信システムでは、セキュリティを適切に保護しつつ、処理負荷を軽減することができない。
この発明は上記事情に着目してなされたもので、その目的とするところは、セキュリティを適切に保護しつつ、処理負荷を軽減することができるようにした通信システム、方法及びプログラムを提供することにある。
上記目的を達成するためにこの発明の第１の観点は、以下のような構成要素を備えている。すなわち、通信システムは、第１エンティティ装置及び第２エンティティ装置を備えている。上記通信システムは、上記第１エンティティ装置からの要求に対して上記第２エンティティ装置が応答する、ネットワークを介した通信をする際に、上記各エンティティ装置間で暗号化するか否かを選択しつつ多重化通信をするための通信プロトコルを備えている。上記通信プロトコル上の通信パケットは、上記通信パケットを暗号化するか否かを示す暗号化フラグ、上記通信パケットの通信に使用する上位レイヤの情報を示す上位レイヤ情報、及び上記通信プロトコル上で行われる通信を識別するストリームＩＤをヘッダ情報に含む。上記第１エンティティ装置は、使用中のストリームＩＤ及び上記第２エンティティ装置のホスト名を関連付けて記憶する。上記記憶したストリームＩＤに基づき、上記ホスト名に対応する使用中のストリームＩＤと重複しないＩＤ番号を通信開始時に上記ヘッダ情報内のストリームＩＤとして設定する。上記通信パケットを暗号化するか否かを選択する。上記選択結果に基づき、上記ヘッダ情報内の暗号化フラグを設定する。上記ヘッダ情報内の上位レイヤ情報を設定する。上記各エンティティ装置は、異なるストリームＩＤが設定された複数の上記通信パケットを、コネクション型の下位レイヤの場合は当該下位レイヤにおける単一のコネクション上で送受信し、コネクションレス型の下位レイヤの場合は当該下位レイヤ上で送受信するようにしたものである。
また、この発明の第１の観点は以下のような態様を備えることを特徴とする。
第１の態様は、上記通信プロトコル上の通信パケットは、上記通信パケットの到達保証を実施するか否かを示す到達保証実施フラグ及び上記通信パケットの到達確認がされたか否かを示す到達確認フラグを上記ヘッダ情報に更に含む。上記第１エンティティ装置は、上記ヘッダ情報内の到達保証実施フラグを設定する。上記到達確認フラグが設定されていない通信パケットのストリームＩＤを記憶する。上記第２エンティティ装置は、上記ヘッダ情報内の到達確認フラグを設定する。上記到達保証を実施する値に到達保証実施フラグが設定され、上記到達確認がされた値に到達確認フラグが設定されていない通信パケットを受信すると、上記到達確認がされた値に到達確認フラグが設定された到着確認メッセージを送信するようにしたものである。
第２の態様は、上記各エンティティ装置間に第３エンティティ装置を更に備え、上記第３エンティティ装置は、上記第１エンティティ装置及び上記第２エンティティ装置間の通信を上記下位レイヤでトンネルするようにしたものである。
第３の態様は、上記暗号化選択手段が、予め定められたルールに基づいて暗号化するか否かを静的に選択するようにしたものである。
第４の態様は、上記暗号化選択手段が、暗号化するか否かをユーザに動的に選択させるようにしたものである。
この発明の第１の観点によれば、各エンティティ装置は暗号化するか否かを選択しつつ多重化通信をするための通信プロトコルを備えており、通信プロトコル上の通信パケットは、暗号化するか否かが選択され、暗号化するか否かを示す暗号化フラグが設定されると共に、動作させる上位レイヤを示す上位レイヤ情報が設定される。そして、単一の下位レイヤのコネクション上で送受信される複数の通信パケットは、ストリームＩＤによって識別される。このため、暗号化するか否かを選択しつつ多重化通信をすることができるようになる。したがって、セキュリティを適切に保護しつつ、処理負荷を軽減することが可能となる。
第１の態様によれば、通信プロトコル上の通信パケットは、到達保証を実施するか否かを示す到達保証実施フラグが設定され、受信時に到達確認がされたか否かを示す到達確認フラグが設定される。このため、信頼性を高める制御機能を備えていないプロトコル上で通信を実施する際にも、上記通信プロトコルのレイヤ上で再送制御を実施することができるようになり、信頼性を高めることが可能となる。したがって、よりセキュリティを適切に保護しつつ、処理負荷を軽減することが可能になる。
第２の態様によれば、第１及び第２エンティティ装置間に更に備えられた第３エンティティ装置が通信をトンネリングする。このため、第３エンティティ装置が暗号化するか否かを選択しつつ多重化通信をするための通信プロトコルを備えていなくても、第１及び第２エンティティ装置間で暗号化するか否かを選択しつつ多重化通信することができるようになる。したがって、よりセキュリティを適切に保護しつつ、処理負荷を軽減することが可能となる。
第３の態様によれば、暗号化するか否かを予め定められたルールに従って静的に選択する。このため、通信の際に予め定められたセキュリティレベルを遵守したルールを設定することができるようになり、よりセキュリティを適切に保護することが可能となる。
第４の態様によれば、暗号化するか否かをユーザに動的に選択させる。このため、通信の際に状況に応じた柔軟なセキュリティレベルを設定することができるようになり、よりセキュリティを適切に保護することが可能となる。
すなわち、この発明によれば、セキュリティを適切に保護しつつ、処理負荷を軽減するようにした通信システム、方法及びプログラムを提供することができる。
この発明の一実施形態に係る通信システムの機能構成の一例を示すブロック図である。 同実施形態におけるプロトコルスタックの一例を示す模式図である。 同実施形態におけるパケットフォーマットの一例を示す模式図である。 同実施形態におけるクライアント装置ＵＳＥＰ処理部及びサーバ装置ＵＳＥＰ処理部の機能構成の一例を示す模式図である。 同実施形態におけるプロトコルリストの一例を示す模式図である。 同実施形態におけるストリームＩＤ管理リストの一例を示す模式図である。 同実施形態におけるＵＳＥＰセッション確立の動作を説明するためのシーケンス図である。 同実施形態におけるＵＳＥＰ通信の動作を説明するためのシーケンス図である。 同実施形態における取得リソースの一例を示す模式図である。 この発明の一実施形態の変形例を説明するためのシーケンス図である。 この発明の一実施形態の変形例を説明するためのシーケンス図である。 この発明の一実施形態の変形例を説明するためのシーケンス図である。 この発明の他の実施形態に係るプロトコルスタックの一例を示す模式図である。 同実施形態におけるパケットフォーマットの一例を示す模式図である。 同実施形態におけるクライアント装置ＵＳＥＰ処理部及びサーバ装置ＵＳＥＰ処理部の機能構成の一例を示す模式図である。 同実施形態における到達未確認ストリームＩＤリストの一例を示す模式図である。 同実施形態におけるＵＳＥＰセッション確立の動作を説明するためのシーケンス図である。 この発明の他の実施形態に係るＵＳＥＰ通信の動作を説明するためのシーケンス図である。 この発明の他の実施形態の変形例を説明するためのシーケンス図である。 この発明の他の実施形態の変形例を説明するためのシーケンス図である。 この発明の他の実施形態の変形例を説明するためのシーケンス図である。
以下、図面を参照してこの発明に関わる実施形態を説明する。なお、以下の通信システムは、暗号化するか否かを選択しつつ多重化通信できる通信システムとしてコンピュータを機能させるためのプログラムを用いて実施してもよい。すなわち、通信システムは、メモリ又はＣＰＵ(Central Processing Unit)等のハードウェア資源に協働する機能ブロックの機能をプログラムにより実現してもよい。
［一実施形態］
図１は、この発明の一実施形態に係る通信システムの機能構成を示すブロック図であり、図２及び図３は、それぞれプロトコルスタック及びパケットフォーマットの一例を示す模式図である。通信システム１は、クライアント装置１０およびサーバ装置２０を備えている。また、通信システム１は、クライアント装置１０からの要求に対してサーバ装置２０が応答する、ネットワークを介した通信をする際に、各エンティティ装置間で暗号化するか否かを選択しつつ多重化通信をするためのプロトコル（以下、ＵＳＥＰ(User Selectable Encryption Protocol)という。）を備えている。なお、以下の説明では、「クライアント装置」及び「サーバ装置」を、それぞれ「第１エンティティ装置」及び「第２エンティティ装置」と読み替えてもよい。また、「プロトコル」を、「通信規約」又は「通信手順」等と読み替えてもよい。
クライアント装置１０及びサーバ装置２０は、ネットワークを介して接続されている。なお、クライアント装置１０及びサーバ装置２０は、１台に限らず、２台以上の任意の台数がネットワークを介して接続可能となっている。クライアント装置１０及びサーバ装置２０は、ＵＳＥＰをサポートしている。一例として、クライアント装置１０及びサーバ装置２０は、図２に示す如きプロトコルスタック１００ａを実装している。
クライアント装置１０及びサーバ装置２０は、ＴＣＰを動作させることで通信を実施してもよい。また、クライアント装置１０及びサーバ装置２０は、ＴＣＰ上でＷｅｂＳｏｃｋｅｔプロトコルを動作させてもよい。
クライアント装置１０及びサーバ装置２０は、ＷｅｂＳｏｃｋｅｔプロトコル上でＵＳＥＰを動作させてもよく、ＷｅｂＳｏｃｋｅｔプロトコルのＨＴＴＰの「Ｕｐｇｒａｄｅ」ヘッダの機能を拡張することでＵＳＥＰプロトコルの利用可能性を交渉してもよい。
クライアント装置１０及びサーバ装置２０は、ＵＳＥＰ上で任意のアプリケーションプロトコルを動作させてもよい。具体的には、平文通信する際にはＨＴＴＰやＨＴＴＰ／２を動作させてもよく、暗号化通信する際にはＴＬＳ上でのＨＴＴＰであるＨＴＴＰＳ（HTTP secure）、ＨＴＴＰ／２及びＳＰＤＹを動作させてもよい。
なお、以下の説明では、プロトコルスタック１００ａにおけるＵＳＥＰレイヤより上位及び下位のレイヤを「上位レイヤ」及び「下位レイヤ」と読み替えてもよい。また、ＴＣＰやＷｅｂＳｏｃｋｅｔプロトコルに例示される、ＵＳＥＰを動作させるプロトコルを、「下位レイヤのプロトコル」又は「下位プロトコル」と読み替えてもよい。また、ＨＴＴＰ、ＨＴＴＰ／２及びＳＰＤＹに例示される、ＵＳＥＰ上で動作するプロトコルを、「上位レイヤのプロトコル」又は「上位プロトコル」と読み替えてもよい。
ＵＳＥＰのパケットフォーマット１００ｂは、図３に示すように、ヘッダ情報とデータ情報を含む。ヘッダ情報は、暗号化フラグ、上位レイヤ情報及びストリームＩＤを含む。なお、パケットフォーマット１００ｂは、あくまで一例であり、フォーマットやビット長、識別に利用される情報の組み合わせはこの限りではない。
暗号化フラグは、通信パケットを暗号化するか否かを示す変数である。暗号化フラグは、１ビットで実現されてもよい。暗号化フラグは、１ビットで実現される場合、データ情報が暗号化されていないことを示す場合に“０”が設定され、データ情報が暗号化されていることを示す場合に“１”が設定されてもよい。
上位レイヤ情報は、通信パケットの通信に使用する上位レイヤの情報を示す。すなわち、上位レイヤ情報は、上位レイヤで利用されるプロトコルを一意に識別するための値を含む情報である。上位レイヤ情報は、後述する利用可能プロトコルＤＢ１０５に記憶されているプロトコルリスト１００ｃの値と対応していてもよい。
ストリームＩＤは、通信プロトコル上で行われる通信を識別する。すなわち、ストリームＩＤは、ＵＳＥＰレイヤにおけるＵＳＥＰ上の通信を識別するための識別番号であり、下位レイヤであるＴＣＰ等の単一のコネクション上において動作する、複数のＵＳＥＰ上の通信ストリームを識別するための識別番号である。ストリームＩＤは、典型的には２４ビットの値として設定されるが、２４ビット以外のビット長として設定されてもよい。
データ情報は、ＵＳＥＰデータグラムにおける任意長のペイロードである。
クライアント装置１０は、上位プロトコル処理部１１、クライアント装置ＵＳＥＰ処理部１２、下位プロトコル処理部１３及び送受信部１４を備えている。また、サーバ装置２０は、上位プロトコル処理部２１、サーバ装置ＵＳＥＰ処理部２２、下位プロトコル処理部２３及び送受信部２４を備えている。
なお、互いに同一名称の機能ブロックである上位プロトコル処理部１１，２１と、下位プロトコル処理部１３，２３と、送受信部１４，２４とは、それぞれ互いに同等の機能を有している。このため、サーバ装置２０における上記重複部の機能構成については説明を省略する。
上位プロトコル処理部１１は、サーバ装置２０へ送信するメッセージの上位プロトコルに関する処理を実施する。上位プロトコル処理部１１は、送信メッセージを作成し、クライアント装置ＵＳＥＰ処理部１２に送信する。上位プロトコル処理部１１は、サーバ装置２０から受信したメッセージをクライアント装置ＵＳＥＰ処理部１２から受信し、上位プロトコルに関する処理を実施する。また、上位プロトコル処理部１１は、セッション確立時に、上位プロトコルの利用可能性を交渉する。なお、以下の説明では、「送信メッセージ」及び「受信メッセージ」を、「送信パケット」及び「受信パケット」と読み替えてもよい。また、「送信」又は「受信」を「通信」と読み替えてもよい。
クライアント装置ＵＳＥＰ処理部１２は、図４に示すように、上位プロトコル連携部１００、ＵＳＥＰヘッダ処理部１０１、下位プロトコル連携部１０２、利用可能プロトコルＤＢ１０３、ストリームＩＤ管理部１０４及びストリームＩＤ管理ＤＢ１０５を備えている。サーバ装置ＵＳＥＰ処理部２２は、上位プロトコル連携部２００、ＵＳＥＰヘッダ処理部２０１、下位プロトコル連携部及び利用可能プロトコルＤＢ２０３を備えている。また、クライアント装置ＵＳＥＰ処理部１２及びサーバ装置ＵＳＥＰ処理部２２は、利用可能プロトコルＤＢ１０３を備えている場合、セッション確立時に、上位プロトコルの利用可能性を交渉してもよい。
なお、互いに同一名称の機能ブロックである上位プロトコル連携部１００，２００と、ＵＳＥＰヘッダ処理部１０１，２０１と、下位プロトコル連携部１０２，２０２と、利用可能プロトコルＤＢ１０３，２０３とは、それぞれ互いに同等の機能を有している。このため、サーバ装置ＵＳＥＰ処理部２２の機能構成については説明を省略する。
上位プロトコル連携部１００は、上位プロトコル処理部１１から送信メッセージを受信すると、受信した送信メッセージ内の情報に基づいて、利用可能な上位プロトコルの値を利用可能プロトコルＤＢ１０３から読込む。上位プロトコル連携部１００は、送信メッセージ及び読込んだ上位プロトコルの値をＵＳＥＰヘッダ処理部１０１に送信する。また、上位プロトコル連携部１００は、ＵＳＥＰヘッダ処理部１０１から受信メッセージを受信し、ヘッダ情報内の上位レイヤ情報に基づき、当該受信メッセージを適切な上位プロトコルを処理する上位プロトコル処理部１１へ送信する。
また、上位プロトコル連携部１００は、セッション確立時に、利用可能プロトコルＤＢ１０３から利用可能なプロトコルの値を読出し、下位プロトコル連携部１０２を通じて下位プロトコル処理部１３に送信してもよい。
ＵＳＥＰヘッダ処理部１０１は、上位プロトコル連携部１００から送信メッセージ及び利用可能な上位プロトコルの値を受信し、ＵＳＥＰのヘッダ情報を設定する。また、下位プロトコル連携部１０２から受信メッセージを受信し、上位プロトコル連携部１００に送信する。
ＵＳＥＰのヘッダ情報を設定するための具体的な機能構成を以下に説明する。ＵＳＥＰヘッダ処理部１０１は、送信メッセージを暗号化するか否かを選択する。また、ＵＳＥＰヘッダ処理部１０１は、選択結果に基づき、ヘッダ情報内の暗号化フラグを設定する。また、ＵＳＥＰヘッダ処理部１０１は、利用可能な上位プロトコルの値を受信し、ヘッダ情報内の上位レイヤ情報を設定する。また、ＵＳＥＰヘッダ処理部１０１は、ストリームＩＤ管理部１０４から利用可能なストリームＩＤを取得し、取得したストリームＩＤをヘッダ情報内のストリームＩＤとして設定する。
なお、ＵＳＥＰヘッダ処理部１０１は、暗号化するか否かを選択する際に、予め定められたルールに基づき、暗号化するか否かを静的に選択してもよい。ＵＳＥＰヘッダ処理部１０１は、ＵＳＥＰ上で動作する上位レイヤのアプリケーションやソフトウェアから予め定められたルールが記述された設定ファイルを読込むことで、暗号化するか否かを選択してもよい。当該ルールが記述された設定ファイルは、アプリケーションやソフトウェアの設定ファイル内に含められていてもよく、”usep.cfg”等の外部ファイルに記述されたルールを読込むことでＵＳＥＰヘッダ処理部１０１に認識されてもよい。また、ルールを記述したファイルを設定する際は、ネットワーク毎のルールに従ってネットワークから配信してもよい。
暗号化するか否かを定めたルールとしては、例えば、以下のような判断基準が個別に使用可能であり、これらの判断基準を複合的に組み合わせてルールを設定してもよい。なお、以下の判断基準又はルールは、一例であり、これに限定されない。
・http://スキームとhttps://スキームで使い分ける場合：
取得するリソースがhttp://スキームを使用する場合は、暗号化フラグを“１”に設定せずに平文通信を実施し、https://スキームを利用する場合は、暗号化フラグを“１”に設定して暗号化通信を実現する。
・取得リソースのタイプによって使い分ける場合：
取得するリソースのタイプ(css, javascript（登録商標）, html, text, image等)によって暗号化又は平文通信を切り替える。例えば、共通的な情報しか含まれないcssファイルやjavascript等のタイプのリソースを取得するときには、平文通信を実施する。また例えば、動的に生成される可能性のあるtextやhtml等のタイプのリソースを取得するときには、暗号化通信を利用する。
・サーバが用意したプロファイル情報から選択する場合：
サーバが、「すべて暗号化通信を利用する」というルールから「すべて平文通信を利用する」というルールまで、いくつかのプロファイル情報を用意しておき、各プロファイル情報の中からどのプロファイル情報を優先的に選択するかを記述しておく。
なお、これらのルールは、以下に例示するように制御式を用いて特定のドメイン毎に使い分けることもできるものとする。
if(ドメインが○○○.com) then サーバプロファイルのうち最もプライバシが高いものを選択する。
else if(ドメインが△△△.com) then http://スキームには平文通信を適用する。
else cssとjavascriptの取得は、平文通信を適用する。
また、ＵＳＥＰヘッダ処理部１０１は、暗号化するか否かを選択する際に、暗号化するか否かをユーザに動的に選択させてもよい。すなわち、ＵＳＥＰヘッダ処理部１０１は、ＵＳＥＰ上で動作するアプリケーションやソフトウェアがプロンプト等を用いてユーザに選択を求めることで暗号化するか否かを選択してもよい。なお、ＵＳＥＰヘッダ処理部１０１は、複数のリソースを取得する場合、個別のリソース毎に暗号化するか否かをユーザに動的に選択させてもよく、リソースのページ及び／又はドメイン毎にユーザに選択を求めてもよい。このとき、ＵＳＥＰヘッダ処理部１０１は、動的に選択した結果を設定ファイルに設定してもよい。また、これらの設定は、一度選択した結果をドメイン毎に保存できてもよく、前述したルールと同様に、制御式を用いて特定のドメイン毎に使い分けてもよい。
下位プロトコル連携部１０２は、ＵＳＥＰヘッダ処理部１０１から送信メッセージを受信し、下位プロトコル処理部１３に送信する。下位プロトコル連携部１０２は、下位プロトコル処理部１３から受信メッセージを受信し、ＵＳＥＰヘッダ処理部１０１に送信する。また、下位プロトコル連携部１０２は、セッション確立時に、上位プロトコル連携部１００から利用可能なプロトコルの値を受信し、下位プロトコル処理部１３に送信してもよい。
利用可能プロトコルＤＢ１０３は、上位プロトコル連携部１００から書込／読出可能なメモリであり、プロトコルリスト１００ｃを記憶する。
プロトコルリスト１００ｃは、図５に示すように、上位プロトコルとして利用可能なプロトコルのプロトコル名と、それらと一意に対応するプロトコルの値とが関連付けられて記憶されている。プロトコル名は、例えばＨＴＴＰやＨＴＴＰ／２、ＳＰＤＹ等に対応するプロトコルの値として、http/1.1, h2, spdy/3.1等の値が関連付けられて記憶されてもよい。
なお、利用可能プロトコルＤＢ１０３は、省略してもよい。利用可能プロトコルＤＢ１０３が無い場合、上位プロトコル連携部１００は、利用可能な上位プロトコルの値を上位プロトコル処理部１１から受信してもよい。
ストリームＩＤ管理部１０４は、ＵＳＥＰレイヤにおけるＵＳＥＰ上の通信を識別するためのストリームＩＤを管理する。具体的には、通信開始の際にＵＳＥＰヘッダ処理部１０１からの問い合わせに応じ、現在通信に使用中であり、かつ当該開始する通信に利用可能なストリームＩＤをストリームＩＤ管理ＤＢ１０５から読出し、ＵＳＥＰヘッダ処理部１０１に送信する。ストリームＩＤ管理部１０４は、現在通信に使用中であり、かつ当該開始する通信に利用可能なストリームＩＤがストリームＩＤ管理ＤＢ１０５に記憶されていない場合、ストリームＩＤ管理ＤＢ１０５から未使用のストリームＩＤを読出し、ＵＳＥＰヘッダ処理部１０１に送信する。すなわち、ストリームＩＤ管理部１０４は、ストリームＩＤ管理ＤＢ１０５に記憶されたストリームＩＤに基づき、通信先のホスト名に対応する使用中のストリームＩＤと重複しないＩＤ番号を、ヘッダ情報内に設定可能なストリームＩＤとして通信開始時にＵＳＥＰヘッダ処理部１０１に送信する。また、ストリームＩＤ管理部１０４は、通信終了の際にストリームＩＤ管理ＤＢ１０５に終了を通知し、当該終了する通信のストリームＩＤをストリームＩＤ記憶部１０５から削除する。
なお、ストリームＩＤ管理部１０４は、未使用のストリームＩＤ群から一つのＩＤ番号を選択する際には、ランダムに選択してもよく、最小又は最大のものを選択してもよい。
ストリームＩＤ管理ＤＢ１０５は、ストリームＩＤ管理部１０４から書込／読出可能なメモリであり、ストリームＩＤ管理リスト１００ｄを記憶する。
ストリームＩＤ管理リスト１００ｄは、図６に示すように、使用中のストリームＩＤと、通信先のサーバ装置のホスト名とを関連付けたストリームＩＤ管理リスト１００ｄを記憶するデータベースである。ストリームＩＤ管理リスト１００ｄは、現在使用中のストリームＩＤ以外に、使用可能であって、現在未使用のストリームＩＤを記憶してもよい。このとき、現在未使用のストリームＩＤに対応する通信先のサーバ装置のホスト名は、“−”（ハイフン）等によって未使用であることを示してもよい。
なお、ストリームＩＤ管理部１０４及びストリームＩＤ管理ＤＢ１０５は、ＵＳＥＰに基づく通信をクライアント装置１０から開始するため、サーバ装置２０には存在しない。
下位プロトコル処理部１３は、サーバ装置２０へ送信するメッセージをＵＳＥＰ処理部１２から受信し、下位プロトコルに関する処理を実施し、送受信部１４に送信する。具体的には、下位プロトコル処理部１３は、ＵＳＥＰレイヤにおける複数の通信パケットを単一のＴＣＰコネクション上で処理し、送信メッセージとして送受信部１４に送信する。下位プロトコル処理部１３は、サーバ装置２０から受信したメッセージを送受信部１４から受信し、下位プロトコルに関する処理を実施し、クライアント装置ＵＳＥＰ処理部１２へ送信する。また、下位プロトコル処理部１３は、セッション確立時に、下位プロトコルの利用可能性を交渉する。下位プロトコル処理部１３は、セッション確立時に、下位プロトコルの利用可能性を交渉する際に、同時にＵＳＥＰレイヤの利用可能性も交渉してもよい。また、下位プロトコル処理部１３は、下位プロトコル連携部１０２から利用可能な上位プロトコルの値を受信し、ＵＳＥＰレイヤの利用可能性の交渉時に上位プロトコルの利用可能性についても交渉してもよい。ＵＳＥＰレイヤの利用可能性の交渉時に上位プロトコルの利用可能性を同時に交渉することで、上位レイヤ利用可能性の交渉時に必要なラウンドトリップを削減することができる。
送受信部１４は、下位プロトコル連携部１０２から送信メッセージを受信し、サーバ装置２０に送信する。送受信部１４は、サーバ装置２０から受信メッセージを受信し、下位プロトコル連携部１０２に送信する。
次に、以上のように構成された通信システムの動作について図７及び図８に示すシーケンス図及び図９に示す取得リソースを示す模式図を用いて説明する。なお、以下の説明は、クライアント装置１０及びサーバ装置２０が、ＵＳＥＰをサポートしており、図１に示したように、ネットワークを介して物理的に接続されている場合について述べる。
まず、セッション確立時の動作について、図７のシーケンス図を用いて説明する。
いま、クライアント装置１０は、サーバ装置２０との間にＴＣＰハンドシェークによりＴＣＰコネクションを確立する（ＳＴ１００〜ＳＴ１０２）。具体的には、以下に示すように、下位プロトコル処理部１３，２３がステップＳＴ１００〜ＳＴ１０２を実行する。なお、クライアント装置１０とサーバ装置２０間にＴＣＰコネクションが既に存在する場合は、当該既存のＴＣＰコネクションを再利用してもよい。
下位プロトコル処理部１３は、サーバ装置２０にＳＹＮ(Synchronize)フラグを設定したＴＣＰセグメントを送信する（ＳＴ１００）。下位プロトコル処理部２３は、クライアント装置１０にＳＹＮフラグとＡＣＫ(Acknowledgement)フラグを設定したＴＣＰセグメントを送信する（ＳＴ１０１）。下位プロトコル処理部１３は、サーバ装置２０にＡＣＫフラグを設定したＴＣＰセグメントを送信する（ＳＴ１０２）。
次に、クライアント装置１０は、サーバ装置２０との間にＷｅｂＳｏｃｋｅｔの接続を行う。クライアント装置１０は、ＷｅｂＳｏｃｋｅｔの利用可能性を交渉する際に、ＵＳＥＰセッションの利用可能性についても交渉する（ＳＴ１０３〜ＳＴ１０４）。具体的には、以下に示すように、クライアント装置ＵＳＥＰ処理部１２、サーバ装置ＵＳＥＰ処理部２２及び下位プロトコル処理部１３，２３がステップＳＴ１０３〜ＳＴ１０４を実行する。
クライアント装置ＵＳＥＰ処理部１２及び下位プロトコル処理部１３は、ハンドシェーク要求をサーバ装置２０に送信する。クライアント装置ＵＳＥＰ処理部１２及び下位プロトコル処理部１３は、ハンドシェーク要求の際に、ＷｅｂＳｏｃｋｅｔの接続先を指定する「Ｈｏｓｔ」ヘッダ及びハンドシェーク応答を得るための「Ｓｅｃ−ＷｅｂＳｏｃｋｅｔ−Ｋｅｙ」ヘッダを指定する。クライアント装置ＵＳＥＰ処理部１２及び下位プロトコル処理部１３は、ＨＴＴＰ Ｕｐｇｒａｄｅを利用し、「Ｓｅｃ−ＷｅｂＳｏｃｋｅｔ−Ｐｒｏｔｏｃｏｌ」ヘッダに“ｕｓｅｐ”値を設定することでＵＳＥＰセッションの利用可能性を交渉する（ＳＴ１０３）。なお、上位プロトコルの利用可能性についても同時に交渉する場合、下位プロトコル処理部１３は、クライアント装置ＵＳＥＰ処理部１２から利用可能な上位プロトコルの値を受信してもよい。下位プロトコル処理部１３は、受信した上位プロトコルの値を用いて、「Ｓｅｃ−ＷｅｂＳｏｃｋｅｔ−Ｐｒｏｔｏｃｏｌ」ヘッダに“ｕｓｅｐ−ｈ２”及び“ｕｓｅｐ-ｓｐｄｙ／３．１”等のＩＡＮＡ(Internet Assigned Numbers Authority)に重複して登録されていない値を設定し、上位プロトコルの利用可能性を同時に交渉してもよい。
サーバ装置ＵＳＥＰ処理部２２及び下位プロトコル処理部２３は、ハンドシェーク応答をクライアント装置１０に送信する。ハンドシェーク応答の際に、サーバ装置ＵＳＥＰ処理部２２及び下位プロトコル処理部２３は、ＵＳＥＰセッションが利用可能な場合、クライアントとのコネクションを維持するための「Ｓｅｃ−ＷｅｂＳｏｃｋｅｔ−Ａｃｃｅｐｔ」及びＷｅｂＳｏｃｋｅｔのバージョンを指定する「Ｓｅｃ−ＷｅｂＳｏｃｋｅｔ−Ｖｅｒｓｉｏｎ」と共に、「１０１ Ｓｗｉｔｃｈｉｎｇ Ｐｒｏｔｏｃｏｌ」レスポンスをクライアント装置１０に送信し、ＵＳＥＰの利用可能性を通知する（ＳＴ１０４）。以上より、クライアント装置１０及びサーバ装置２０は、ＵＳＥＰによる通信を開始する。
次に、サーバ装置２０内のリソースを取得する際の動作について、図８のシーケンス図を用いて説明する。なお、サーバ装置２０から取得されるリソースは、図９に示すように上位プロトコルとしてＨＴＴＰ又はＨＴＴＰＳを利用したページ上の３種類のファイル（テキストＡ，イメージＢ，テキストＣ）であるとする。また、暗号化するか否かの選択の結果、テキストＡ及びイメージＢは暗号化し、テキストＣは暗号化しないものとする。また、イメージＢは、テキストＡ及びテキストＣと比較して容量が大きいため、サーバ装置２０における応答処理に時間を要するものとする。
まず、クライアント装置１０は、使用中のストリームＩＤ及び通信先のサーバ装置のホスト名を関連付けて記憶する。なお、この例では、サーバ装置２０に対する使用中のストリームＩＤはないものとする。
クライアント装置１０は、テキストＡに関する要求メッセージを作成する（ＳＴ２００）。具体的には、クライアント装置１０は、メッセージ作成に際し、使用中のストリームＩＤと重複しないＩＤ番号を、通信開始時にＵＳＥＰのヘッダ情報内のストリームＩＤとして設定する。ここでは、ＵＳＥＰのヘッダ情報内のストリームＩＤに“１”を設定する。クライアント装置１０は、暗号化するか否かを選択する。なお、暗号化するか否かの選択に際しては、予め定められたルールに基づき静的に選択してもよく、ユーザに動的に選択させてもよい。クライアント装置１０は、選択結果に基づき、ＵＳＥＰヘッダ情報内の暗号化フラグを設定する。ここでは、暗号化フラグに暗号化を示す“１”を設定する。また、クライアント装置１０は、ＵＳＥＰヘッダ情報内の上位レイヤ情報を設定する。ここでは、上位レイヤとしてＨＴＴＰＳを使用するため、ＨＴＴＰＳを示す値（例えばhttps）を上位レイヤ情報に設定する。
クライアント装置１０は、ＨＴＴＰの「ＧＥＴ」メソッドを用い、テキストＡの取得を要求するメッセージをサーバ装置２０に送信する（ＳＴ２０１）。
クライアント装置１０は、ステップＳＴ２００と同様に、イメージＢに関する要求メッセージを作成する。クライアント装置１０は、メッセージ作成に際し、ＵＳＥＰのヘッダ情報内のストリームＩＤに“２”を設定し、暗号化フラグに暗号化を示す“１”を設定し、上位レイヤ情報に“https”を設定する（ＳＴ２０２）。クライアント装置１０は、ＨＴＴＰの「ＧＥＴ」メソッドを用い、イメージＢの取得を要求するメッセージをサーバ装置２０に送信する（ＳＴ２０３）。
クライアント装置１０は、ステップＳＴ２００，２０２と同様に、テキストＣに関する要求メッセージを作成する。クライアント装置１０は、メッセージ作成に際し、ＵＳＥＰのヘッダ情報内のストリームＩＤに“３”を設定し、暗号化フラグに平文を示す“０”を設定し、上位レイヤ情報に“http/1.1”を設定する（ＳＴ２０４）。クライアント装置１０は、ＨＴＴＰの「ＧＥＴ」メソッドを用い、テキストＣの取得を要求する送信メッセージをサーバ装置２０に送信する（ＳＴ２０５）。
すなわち、クライアント装置１０は、ステップＳＴ２０１，２０３，２０５において、異なるストリームＩＤが設定された複数のメッセージを、単一のＴＣＰコネクション上で送信する。
サーバ装置２０は、ステップＳＴ２０１で送信されたテキストＡの要求メッセージを受信し、これに対する応答メッセージを作成する。サーバ装置２０は、応答メッセージ作成に際し、受信したメッセージのＵＳＥＰヘッダ情報内のストリームＩＤ及び暗号化フラグと同じ値を設定する。また、サーバ装置２０は、応答メッセージのデータ情報内に、暗号化したテキストＡを設定する（ＳＴ２０６）。サーバ装置２０は、「ＯＫ」ステータスと共に、暗号化したテキストＡを応答メッセージとしてクライアント装置１０に送信する（ＳＴ２０７）。
サーバ装置２０は、ステップＳＴ２０５で送信されたテキストＣの要求メッセージを受信し、これに対する応答メッセージを作成する。サーバ装置２０は、応答メッセージ作成に際し、受信したメッセージのＵＳＥＰヘッダ情報内のストリームＩＤ及び暗号化フラグと同じ値を設定する。また、サーバ装置２０は、応答メッセージのデータ情報内に、平文のテキストＣを設定する（ＳＴ２０８）。サーバ装置２０は、「ＯＫ」ステータスと共に、平文のテキストＣを応答メッセージとしてクライアント装置１０に送信する（ＳＴ２０９）。なお、クライアント装置１０から受信する要求メッセージは、イメージＢを要求するメッセージの方が先に到着しているが、応答処理に要する時間はテキストＣの方が短いため、テキストＣに関する応答メッセージ送信がイメージＢに関する応答メッセージ送信よりも早くなっている。
サーバ装置２０は、ステップＳＴ２０３で送信されたイメージＢの要求メッセージを受信し、これに対する応答メッセージを作成する。サーバ装置２０は、応答メッセージ作成に際し、受信したメッセージのＵＳＥＰヘッダ情報内のストリームＩＤ及び暗号化フラグと同じ値を設定する。また、サーバ装置２０は、応答メッセージのデータ情報内に、暗号化したイメージＢを設定する（ＳＴ２１０）。サーバ装置２０は、「ＯＫ」ステータスと共に、暗号化したイメージＢを応答メッセージとしてクライアント装置１０に送信する（ＳＴ２１１）。
クライアント装置１０は、全ての要求データを受信した後、ＵＳＥＰ通信を終了する。クライアント装置１０は、ＵＳＥＰ終了時に使用したストリームＩＤを削除する（ＳＴ２１２）。
以上詳述したように、一実施形態では、通信システムは、第１エンティティ装置及び第２エンティティ装置を備えている。上記通信システムは、上記第１エンティティ装置からの要求に対して上記第２エンティティ装置が応答する、ネットワークを介した通信をする際に、上記各エンティティ装置間で暗号化するか否かを選択しつつ多重化通信をするための通信プロトコルを備える。上記通信プロトコル上の通信パケットは、上記通信パケットを暗号化するか否かを示す暗号化フラグ、上記通信パケットの通信に使用する上位レイヤの情報を示す上位レイヤ情報、及び上記通信プロトコル上で行われる通信を識別するストリームＩＤをヘッダ情報に含む。上記第１エンティティ装置は、使用中のストリームＩＤ及び上記第２エンティティ装置のホスト名を関連付けて記憶する。上記記憶したストリームＩＤに基づき、上記ホスト名に対応する使用中のストリームＩＤと重複しないＩＤ番号を通信開始時に上記ヘッダ情報内のストリームＩＤとして設定する。上記各エンティティ装置は、上記通信パケットを暗号化するか否かを選択する。上記選択結果に基づき、上記ヘッダ情報内の暗号化フラグを設定する。上記ヘッダ情報内の上位レイヤ情報を設定する。異なるストリームＩＤが設定された複数の上記通信パケットを、単一の下位レイヤのコネクション上で送受信するようにしている。
したがって、通信プロトコル上の通信パケットは、暗号化するか否かが選択され、暗号化フラグが設定されると共に、動作させる上位レイヤが設定される。そして、単一の下位レイヤのコネクション上で送受信される複数の通信パケットは、ストリームＩＤによって識別される。
これにより、クライアント装置及びサーバ装置間において暗号化するか否かを選択しつつ多重化通信をすることができるようになり、セキュリティを適切に保護しつつ、処理負荷を軽減することが可能となる。
補足すると、本実施形態では、暗号化通信と平文通信とを切り替え可能で且つ上位レイヤを多重化するためのＵＳＥＰというプロトコルを導入している。なお、従来の通信システムは、あるホストに対して暗号通信と平文通信を混在させることはできない。
本実施形態では、ＵＳＥＰによってユーザが選択的に暗号化通信と平文通信とを制御できるため、例えば、ユーザの個人情報等が含まれないデータに関しては暗号化通信を行わずに平文通信を行うといった制御が可能となる。また、ユーザは、多重化の恩恵によりセッション数を増やすことなく通信が可能となる。さらに、ユーザは、暗号化通信と平文通信とを切り替えることで、プライバシを含む通信のセキュリティを適切に守りつつ、端末の処理負荷やネットワークリソースの利用を必要最低限に抑えることができる。また、通信キャリアやＩＳＰなどの事業者は、通信パケットの監視に基づくサービスを引き続きユーザに提供することができる。
また、本実施形態では、通信機能の中間レイヤのプロトコルをＵＳＥＰとして定義することで暗号化通信と平文通信（非暗号化通信）との混在化及び多重化を実現したことに加え、静的な及び動的な選択方法をそれぞれ定義している。補足すると、本実施形態では、リソースに応じた暗号化通信と平文通信との選択権をユーザがもっている。すなわち、本実施形態では、ユーザによる静的な又は動的な選択方法のいずれによっても、暗号化通信と平文通信とを切り替えることができる。
例えば、通信パケットを選択するか否かを選択する際、予め定められたルールに基づいて暗号化するか否かを静的に選択するようにしている。
これにより、ＵＳＥＰ通信の際に予め定められたセキュリティレベルを遵守したルールを設定することが出来るようになり、よりセキュリティを適切に保護することが可能となる。
また、通信パケットを選択するか否かを選択する際、ユーザに動的に選択させるようにすることもできる。
これにより、ＵＳＥＰ通信の際に状況に応じた柔軟なセキュリティレベルを設定することが出来るようになり、よりセキュリティを保護することが可能となる。
その他、クライアント装置及びサーバ装置の構成や機能、通信手順、処理手順と処理内容等についても、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。
例えば、通信システム１は、クライアント装置１０及びサーバ装置２０間にプロキシ装置３０を更に備えていてもよい。すなわち、クライアント装置１０及びサーバ装置２０は、プロキシ装置３０を介して接続されていてもよい。プロキシ装置３０は、ＵＳＥＰをサポートしていてもよく、ＵＳＥＰをサポートしていなくてもよい。なお、以下の説明では、「プロキシ装置」を、「第３エンティティ装置」と読み替えてもよい。
クライアント装置１０及びサーバ装置２０は、プロキシ装置３０がＵＳＥＰをサポートしていない場合、クライアント装置１０及びサーバ装置２０間の通信をプロキシ装置３０がＵＳＥＰの下位レイヤでトンネルすることで、ＵＳＥＰによる通信の接続を確立してもよい。
このときのセッション確立時の動作を図１０に示すシーケンス図を用いて説明する。
クライアント装置１０は、プロキシ装置３０との間にＴＣＰハンドシェークによりＴＣＰコネクションを確立する（ＳＴ３００〜ＳＴ３０２）。
クライアント装置１０は、ＨＴＴＰの「ＣＯＮＮＥＣＴ」メソッドを使用して、プロキシ装置３０にサーバ装置２０への接続要求を行う（ＳＴ３０３）。
プロキシ装置３０は、サーバ装置２０との間にＴＣＰハンドシェークによりＴＣＰコネクションを確立する（ＳＴ３０４〜ＳＴ３０６）。
プロキシ装置３０は、プロキシ装置３０とサーバ装置２０との間でＴＣＰコネクションが確立できた場合、クライアント装置１０に「２００ Ｃｏｎｎｅｔｉｏｎ Ｅｓｔａｂｌｉｓｈｅｄ」レスポンスを送信し、ＴＣＰコネクションが確立されたことを通知する（ＳＴ３０７）。
クライアント装置１０は、サーバ装置２０との間にＷｅｂＳｏｃｋｅｔの接続を行う。この時、ＷｅｂＳｏｃｋｅｔ交渉を使って、ＵＳＥＰセッションの利用可能性についても交渉する（ＳＴ３０８〜ＳＴ３０９）。以上より、クライアント装置１０及びサーバ装置２０は、プロキシ装置３０がトンネリングを行うことでＵＳＥＰによる通信を開始する。
このように、この変形例では、クライアント装置１０及びサーバ装置２０間に備えられたプロキシ装置３０が、クライアント装置１０及びサーバ装置２０間のＵＳＥＰ通信を下位レイヤでトンネリングするようにしている。
これにより、プロキシ装置３０がＵＳＥＰをサポートしていなくても、クライアント装置１０及びサーバ装置２０間で暗号化するか否かを選択しつつ多重化通信を実施することができ、よりセキュリティを適切に保護しつつ処理負荷を軽減することが可能となる。
また、クライアント装置１０及びサーバ装置２０は、プロキシ装置３０がＵＳＥＰをサポートしている場合、プロキシ装置３０がＵＳＥＰによる通信を終端することで、ＵＳＥＰによる通信の接続を確立してもよい。
このときのセッション確立時の動作を図１１に示すシーケンス図を用いて説明する。
クライアント装置１０は、プロキシ装置３０との間にＴＣＰハンドシェークによりＴＣＰコネクションを確立する（ＳＴ４００〜ＳＴ４０２）。
クライアント装置１０は、プロキシ装置３０との間にＷｅｂＳｏｃｋｅｔの接続を行う。この時、ＷｅｂＳｏｃｋｅｔ交渉を使って、ＵＳＥＰセッションの利用可能性についても交渉する（ＳＴ４０３〜ＳＴ４０４）。以上より、クライアント装置１０とプロキシ装置３０間でＵＳＥＰによる通信の接続を確立する。
次に、プロキシ装置３０は、サーバ装置２０との間にＴＣＰハンドシェークによりＴＣＰコネクションを確立する（ＳＴ４０５〜ＳＴ４０７）。
プロキシ装置３０は、サーバ装置２０との間にＷｅｂＳｏｃｋｅｔの接続を行う。この時、ＷｅｂＳｏｃｋｅｔ交渉を使って、ＵＳＥＰセッションの利用可能性についても交渉する（ＳＴ４０８〜ＳＴ４０９）。以上より、プロキシ装置３０とサーバ装置２０間でＵＳＥＰによる通信の接続を確立する。したがって、クライアント装置１０とサーバ装置２０は、プロキシ装置３０がＵＳＥＰ通信を終端することで、ＵＳＥＰ通信の接続を確立する。
このように、この変形例では、クライアント装置１０及びサーバ装置２０間に備えられたプロキシ装置３０が、ＵＳＥＰ通信を終端するようにしている。
これにより、プロキシ装置３０がＵＳＥＰをサポートしている場合、プロキシ装置３０がＵＳＥＰ通信を終端することでクライアント装置１０及びサーバ装置２０間で暗号化するか否かを選択しつつ多重化通信を実施することができ、よりセキュリティを適切に保護しつつ処理負荷を軽減することが可能となる。
また、クライアント装置１０及びプロキシ装置３０は、プロキシ装置３０がＵＳＥＰをサポートしている場合、クライアント装置１０及びプロキシ装置３０間でＵＳＥＰ通信を実施してもよく、プロキシ装置３０及びサーバ装置２０間でＵＳＥＰ通信を実施しなくてもよい。なお、プロキシ装置３０及びサーバ装置２０間でＵＳＥＰ通信を実施しない場合、サーバ装置２０は、ＵＳＥＰをサポートしていなくてもよい。
このときのセッション確立時の動作を図１２に示すシーケンス図を用いて説明する。
クライアント装置１０は、プロキシ装置３０との間にＴＣＰハンドシェークによりＴＣＰコネクションを確立する（ＳＴ５００〜ＳＴ５０２）。
クライアント装置１０は、プロキシ装置３０との間にＷｅｂＳｏｃｋｅｔの接続を行う。この時、ＷｅｂＳｏｃｋｅｔ交渉を使って、ＵＳＥＰセッションの利用可能性についても交渉する（ＳＴ５０３〜ＳＴ５０４）。以上より、クライアント装置１０とプロキシ装置３０間でＵＳＥＰによる通信の接続を確立する。
次に、プロキシ装置３０は、サーバ装置２０との間にＴＣＰハンドシェークによりＴＣＰコネクションを確立する（ＳＴ５０５〜ＳＴ５０７）。
プロキシ装置３０は、サーバ装置２０との間にＷｅｂＳｏｃｋｅｔの接続を行う。この時、ＷｅｂＳｏｃｋｅｔ交渉を使って、ＵＳＥＰセッションの利用可能性についても交渉する（ＳＴ５０８）。
サーバ装置２０は、「４００ Ｂａｄ Ｒｅｑｕｅｓｔ」レスポンス等をプロキシ装置３０に送信し、ＵＳＥＰが利用不可能であることを通知する（ＳＴ５０９）。プロキシ装置３０及びサーバ装置２０は、ＵＳＥＰ以外のプロトコルについての利用可能性を交渉し、利用可能なプロトコルに切替える。以上より、クライアント装置１０とプロキシ装置３０間でＵＳＥＰ通信を実施し、プロキシ装置３０とサーバ装置２０間でＵＳＥＰ以外の通信を実施する。
このように、この変形例では、クライアント装置１０及びサーバ装置２０間に備えられたプロキシ装置３０がＵＳＥＰ通信を終端し、プロキシ装置３０及びサーバ装置２０間の通信は、ＵＳＥＰ通信を実施しないようにしている。
これにより、プロキシ装置３０がＵＳＥＰをサポートしている場合、サーバ装置２０側においてＵＳＥＰ通信が実施できない状況においてもクライアント装置１０及びプロキシ装置３０間で暗号化するか否かを選択しつつ多重化通信を実施することができ、よりセキュリティを適切に保護しつつ処理負荷を軽減することが可能となる。
［他の実施形態］
本発明の他の実施形態は、ＵＳＥＰを動作させる下位レイヤとしてＴＣＰのように信頼性を高めるための制御機能を備えたプロトコルを用いない場合を想定する。すなわち、本発明の他の実施形態における通信システム１は、ＵＳＥＰをＵＤＰ(User Datagram Protocol)上で動作させてもよい。以下の説明は、ＵＳＥＰをＵＤＰ上で動作させる場合を例に挙げて述べる。
クライアント装置１０及びサーバ装置２０は、ＵＳＥＰをＵＤＰ上で動作させてＵＳＥＰ通信を実施する場合、図１３に示す如きプロトコルスタック１００ｆを実装している。
クライアント装置１０及びサーバ装置２０は、ＵＤＰを動作させることで通信を実施してもよい。また、クライアント装置１０及びサーバ装置２０は、ＵＤＰ上でＵＳＥＰを動作させてもよい。
クライアント装置１０及びサーバ装置２０は、ＵＳＥＰ上で任意のアプリケーションプロトコルを動作させてもよい。具体的には、平文通信にはＨＴＴＰ、ＨＴＴＰ／２、ＣｏＡＰ(Constrained Application Protocol)及びＭＱＴＴ(Message Queuing Telemetry Transport)プロトコルを動作させてもよく、暗号化通信にはＱＵＩＣ(Quick UDP Internet Connections)又はＤＴＬＳ(Datagram Transport Layer Security)上でＨＴＴＰ／２及びＳＰＤＹを動作させてもよい。
本実施形態におけるＵＳＥＰのパケットフォーマット１００ｇは、図１４に示すように、ヘッダ情報とデータ情報を含む。ヘッダ情報は、暗号化フラグ、上位レイヤ情報、ストリームＩＤに加えて、通信パケットの到達保証を実施するか否かを示す到達保証実施フラグ及び通信パケットの到達確認がされたか否かを示す到達確認フラグを更に含む。なお、パケットフォーマット１００ｇは、あくまで一例であり、フォーマットやビット長、識別に利用される情報の組み合わせはこの限りではない。また、パケットフォーマット１００ｇは、ヘッダ情報を拡張することで、ＴＣＰ等で実現されている輻輳制御の機能や、ＤＳＣＰ(Differentiated Services Code Point)等で実現されている優先制御の機能を導入してもよい。
到達保証実施フラグは、ＵＳＥＰレイヤで到達保証を実施するか否かを示す変数である。到達保証実施フラグは、１ビットで実現されてもよい。到達保証実施フラグは、１ビットで実現される場合、ＵＳＥＰが到達保証を実施しないことを示す場合に“０”が設定され、ＵＳＥＰが到達保証を実施することを示す場合に“１”が設定されてもよい。
到達確認フラグは、到達保証をＵＳＥＰレイヤで実施する際に、到達確認が行われたか否かを示す変数である。到達確認フラグは、１ビットで実現されてもよい。この場合、通信パケットを受信した際に値を“１”にした到達確認フラグを含む到達確認メッセージを送信することで、当該通信パケットの送信元に対して、当該通信パケットの到達確認が行われたことを示す。すなわち、到達確認フラグの値が“１”に設定された通信パケットが返送されない場合、当該通信パケットの到達が保証されないことを示す。
クライアント装置ＵＳＥＰ処理部１２及びサーバ装置ＵＳＥＰ処理部２２は、図１５に示すように、一実施形態の機能構成に加え、再送制御部１０６を更に備える。
ＵＳＥＰヘッダ処理部１０１は、一実施形態の機能に加え、以下の機能を備える。ＵＳＥＰヘッダ処理部１０１は、上位プロトコル連携部１００から送信メッセージを受信すると、当該送信メッセージのヘッダ情報内の到達保証実施フラグを“１”に設定する。ＵＳＥＰヘッダ処理部１０１は、到達保証を実施する送信メッセージを、再送制御部１０６に送信する。また、ＵＳＥＰヘッダ処理部１０１は、下位プロトコル連携部１０２から受信メッセージを受信すると、当該受信メッセージを再送制御部１０６に送信する。また、ＵＳＥＰヘッダ処理部１０１は、下位プロトコル連携部１０２から受信メッセージを受信すると、ヘッダ情報内の到達確認フラグを“１”に設定した通信パケットを、到達確認メッセージとして送信元へ返送する。なお、送信元へ返送される通信パケットのヘッダ情報内のストリームＩＤは、受信した通信パケットのストリームＩＤと同一とする。また、到達確認フラグが“１”に設定された通信パケットは、要求メッセージに対する応答メッセージ内に含まれていてもよい。
再送制御部１０６は、ＵＳＥＰヘッダ処理部１０１から到達保証を実施するメッセージを受信する。再送制御部１０６は、到達保証実施フラグが“１”に設定されたメッセージを受信すると、当該メッセージのヘッダ情報内の到達確認フラグを確認する。再送制御部１０６は、到達確認フラグを確認した結果、到達確認フラグが“１”に設定されていないメッセージについて、当該メッセージのヘッダ情報内のストリームＩＤを図１６に示すように到達未確認ストリームＩＤリスト１００ｈに記憶する。再送制御部１０６は、到達確認フラグを確認した結果、到達が確認されたメッセージについて、当該メッセージのヘッダ情報内のストリームＩＤを到達未確認ストリームＩＤリスト１００ｈから削除する。また、再送制御部１０６は、到達未確認ストリームＩＤリスト１００ｈに基づき、再送制御を実施する。なお、再送制御部１０６は、再送制御に際し、これまでに送信した通信パケットの到達確認メッセージが返送されるまでの時間を計測し、計測時間が予め定めた時間又は直近の計測結果に基づいて算出される時間より大きい場合にメッセージの再送要求を行ってもよい。ただし、再送制御部１０６の再送制御方法は、この限りではない。
次に、以上のように構成された通信システムの動作について図１７、図１８及び図１９に示すシーケンス図を用いて説明する。なお、以下の説明は、クライアント装置１０及びサーバ装置２０が、ＵＳＥＰをサポートしており、図１に示したように、ネットワークを介して物理的に接続されている場合について述べる。
まず、セッション確立時の動作について、図１７のシーケンス図を用いて説明する。
クライアント装置１０は、サーバ装置２０との間にＴＣＰハンドシェークによりＴＣＰコネクションを確立する（ＳＴ６００〜ＳＴ６０２）。
クライアント装置１０は、ＨＴＴＰ等による通信を開始する（ＳＴ６０３）。
サーバ装置２０は、「Ａｌｔｅｒｎａｔｅ−Ｐｒｏｔｏｃｏｌ」ヘッダに“ｕｓｅｐ”値を設定することでＵＳＥＰセッションの利用可能性をクライアント装置１０と交渉する（ＳＴ６０４）。
クライアント装置１０は、ＵＳＥＰセッションが利用可能な場合、ＴＣＰコネクションを切断し（ＳＴ６０５〜ＳＴ６０７）、ＵＤＰ上でのＵＳＥＰ通信に切り替える。具体的には、クライアント装置１０及びサーバ装置２０はがステップＳＴ６０５〜ＳＴ６０７を実行する。
クライアント装置１０は、サーバ装置２０にＦＩＮ(Finish)フラグを設定したＴＣＰセグメントを送信する（ＳＴ６０５）。サーバ装置２０は、クライアント装置１０にＦＩＮフラグとＡＣＫフラグを設定したＴＣＰセグメントを送信する（ＳＴ６０６）。クライアント装置１０は、サーバ装置２０にＡＣＫフラグを設定したＴＣＰセグメントを送信する（ＳＴ６０７）。以降は、クライアント装置１０は、サーバ装置２０に対してＵＤＰ上でのＵＳＥＰ通信を実行する。
次に、サーバ装置２０内のリソースを取得する際の動作について、図１８のシーケンス図を用いて説明する。なお、サーバ装置２０から取得されるリソースは、図９に示すように上位プロトコルとしてＨＴＴＰを利用したページ上のうち、１種類のファイル（テキストＡ）であるとする。また、暗号化するか否かの選択結果は、テキストＡを暗号化することを示すものとする。
クライアント装置１０は、テキストＡに関する要求メッセージを作成する。クライアント装置１０は、当該メッセージの通信パケット作成に際し、ヘッダ情報内のストリームＩＤに“１”を設定し、暗号化フラグに暗号化を示す“１”を設定する。
クライアント装置１０は、ＵＳＥＰヘッダ内の到達保証実施フラグを設定する。ここでは、到達保証実施フラグに“１”を設定する。また、クライアント装置１０は、ＵＳＥＰヘッダ内の到達確認フラグを設定する。ここでは、到達確認フラグに“０”を設定する（ＳＴ７００）。
クライアント装置１０は、まだ到達確認フラグが“１”に設定されていない当該通信パケットについて、ストリームＩＤのＩＤ番号である“１”を、到達未確認ストリームＩＤリスト１００ｈに記憶する（ＳＴ７０１）。クライアント装置１０は、ＨＴＴＰの「ＧＥＴ」メソッドを用い、テキストＡの取得を要求するメッセージをサーバ装置２０に送信する（ＳＴ７０２）。
サーバ装置２０は、テキストＡの要求メッセージを受信し、これに対する応答メッセージとして、到着確認メッセージを作成する（ＳＴ７０３）。具体的には、サーバ装置２０は、到達保証実施フラグが“１”に設定されており、到達確認フラグが“１”に設定されていないメッセージを受信すると、到達確認フラグが“１”に設定された到着確認メッセージを作成する。なお、到着確認メッセージのストリームＩＤは、受信した要求メッセージのストリームＩＤと同一のＩＤ番号を設定する。ここでは、サーバ装置２０は、応答メッセージ作成に際し、ＵＳＥＰヘッダ情報内のストリームＩＤに“１”を設定し、暗号化フラグに“１”を設定し、到達保証実施フラグ及び到達確認フラグに“１”を設定する。また、サーバ装置２０は、応答メッセージのデータ情報内に、暗号化したテキストＡを設定する。
サーバ装置２０は、「ＯＫ」ステータスと共に、暗号化したテキストＡを応答メッセージとしてクライアント装置１０に送信する（ＳＴ７０４）。
クライアント装置１０は、応答メッセージとして、到着確認メッセージを受信する。クライアント装置１０は、受信した到着確認メッセージのヘッダ情報内の到達保証実施フラグが“１”であることを確認し、当該メッセージを再送制御部１０６に送信する。再送制御部１０６は、到達未確認ストリームＩＤリスト１００ｈ内を検索し、ストリームＩＤ“１”をリストから削除する（ＳＴ７０５）。
クライアント装置１０は、全ての要求データを受信した後、ＵＳＥＰ通信を終了する。クライアント装置１０は、ＵＳＥＰ終了時に使用したストリームＩＤを削除する（ＳＴ７０６）。
なお、セッション確立時の動作は、図１７に示した「Ａｌｔｅｒｎａｔｅ−Ｐｒｏｔｏｃｏｌ」ヘッダを用いてＵＳＥＰセッションの利用可能性を交渉するシーケンスに限らず、ダイレクトにＵＳＥＰによる接続を試みてもよい。以下に、ダイレクトにＵＳＥＰによる接続を試みる際のセッション確立時の動作について、図１９のシーケンス図を用いて説明する。
クライアント装置１０は、送信する通信パケットについてヘッダ情報内の到達保証実施フラグを設定する。クライアント装置１０は、到達保証を実施する値に到達保証実施フラグが設定された通信パケットをサーバ装置２０に送信する。サーバ装置２０は、到達保証実施フラグが設定された通信パケットを受信する（ＳＴ８００）。
サーバ装置２０は、到達保証実施フラグが設定された通信パケットを受信すると、到達確認メッセージを作成する。すなわち、サーバ装置２０は、到達確認がされた値に到達確認フラグが設定された通信パケットをクライアント装置１０に送信する。クライアント装置１０は、到達確認フラグが設定されたＵＳＥＰパケットを受信する（ＳＴ８０１）。以上より、クライアント装置１０及びサーバ装置２０の双方でＵＳＥＰをサポートしていることが確認できるため、クライアント装置１０は、ＵＳＥＰによる通信に切り替える。
以上詳述したように、他の実施形態では、通信規約１００ｇ上の通信パケットは、通信パケットの到達保証を実施するか否かを示す到達保証実施フラグ及び通信パケットの到達確認がされたか否かを示す到達確認フラグを更に含む。各エンティティ装置１０，２０は、上記ヘッダ情報内の到達保証実施フラグを設定する。各エンティティ装置１０，２０は、上記ヘッダ情報内の到達確認フラグを設定する。上記到達確認フラグが設定されていない通信パケットのストリームＩＤを記憶する。到達保証を実施する値に到達保証実施フラグが設定され、到達確認がされた値に到達確認フラグが設定されていない通信パケットを受信すると、到達確認がされた値に到達確認フラグが設定された到着確認メッセージを送信するようにしている。
したがって、信頼性を高める制御機能を備えていないプロトコル上でＵＳＥＰ通信を実施する際にも、ＵＳＥＰレイヤ上で再送制御を実施することができるようになり、より信頼性を高めることが可能となる。
その他、クライアント装置及びサーバ装置の構成や機能、通信手順、処理手順と処理内容等についても、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。
例えば、通信システム１は、プロキシ装置３０を備えていてもよい。クライアント装置１０及びサーバ装置２０は、プロキシ装置３０を介して接続されていてもよい。プロキシ装置３０は、ＵＳＥＰをサポートしていてもよく、ＵＳＥＰをサポートしていなくてもよい。
クライアント装置１０及びサーバ装置２０は、プロキシ装置３０がＵＳＥＰをサポートしていない場合、ＵＳＥＰの下位レイヤでトンネルすることで、ＵＳＥＰによる通信の接続を確立してもよい。
このときのセッション確立時の動作を図２０に示すシーケンス図を用いて説明する。
クライアント装置１０及びサーバ装置２０は、プロキシ装置３０がトンネリングすることで、ＴＣＰコネクションを確立する（ＳＴ９００〜ＳＴ９０７）。具体的には、ステップＳＴ９００〜ＳＴ９０７は、ステップＳＴ３００〜ＳＴ３０７と同等であるため、説明を省略する。
クライアント装置１０は、ＨＴＴＰ等による通信を開始する（ＳＴ９０８）。
サーバ装置２０は、「Ａｌｔｅｒｎａｔｅ−Ｐｒｏｔｏｃｏｌ」ヘッダに“ｕｓｅｐ”値を設定することでＵＳＥＰセッションの利用可能性をクライアント装置１０と交渉する（ＳＴ９０９）。
クライアント装置１０は、ＵＳＥＰセッションが利用可能な場合、ＴＣＰコネクションを切断し（ＳＴ９１０〜ＳＴ９１２）、ＵＤＰ上でのＵＳＥＰ通信に切り替える。以上より、クライアント装置１０及びサーバ装置２０は、プロキシ装置３０がトンネリングすることで、ＵＳＥＰによる通信の接続を確立する。
このように、この変形例では、クライアント装置１０及びサーバ装置２０間に備えられたプロキシ装置３０が、クライアント装置１０及びサーバ装置２０間のＵＳＥＰ通信を下位レイヤでトンネルするようにしている。
これにより、プロキシ装置３０がＵＳＥＰをサポートしていない状況で、信頼性の高い制御機能を備えていない下位プロトコル上でＵＳＥＰを動作させる場合でも、クライアント装置１０及びサーバ装置２０間で暗号化するか否かを選択しつつ多重化通信を実施することができる。したがって、よりセキュリティを適切に保護しつつ処理負荷を軽減することが可能となる。
また、クライアント装置１０及びサーバ装置２０は、プロキシ装置３０がＵＳＥＰをサポートしている場合、プロキシ装置３０がＵＳＥＰによる通信を終端することで、ＵＳＥＰによる通信の接続を確立してもよい。
このときのセッション確立時の動作を図２１に示すシーケンス図を用いて説明する。
クライアント装置１０及びプロキシ装置３０は、ＨＴＴＰの「Ａｌｔｅｒｎａｔｅ−Ｐｒｏｔｏｃｏｌ」ヘッダを用いてＵＳＥＰセッションの利用可能性を交渉し、ＵＳＥＰによる通信の接続を確立する（ＳＴ１０００〜ＳＴ１００７）。具体的には、ステップＳＴ１０００〜ＳＴ１００７は、ステップＳＴ６００〜ＳＴ６０７と同等であるため、説明を省略する。
プロキシ装置３０及びサーバ装置２０は、ＨＴＴＰの「Ａｌｔｅｒｎａｔｅ−Ｐｒｏｔｏｃｏｌ」ヘッダを用いてＵＳＥＰセッションの利用可能性を交渉し、ＵＳＥＰによる通信の接続を確立する（ＳＴ１００８〜ＳＴ１０１５）。具体的には、ステップＳＴ１００８〜ＳＴ１０１５は、ステップＳＴ６００〜ＳＴ６０７と同等であるため、説明を省略する。以上より、クライアント装置１０及びサーバ装置２０は、プロキシ装置３０が終端することにより、ＵＳＥＰによる通信の接続を確立する。
なお、プロキシ装置３０を介するＵＳＥＰセッションの確立方法は、ダイレクトにＵＳＥＰによる接続を試みる方法に適用してもよい。
このように、この変形例では、クライアント装置１０及びサーバ装置２０間に備えられたプロキシ装置３０が、ＵＳＥＰ通信を終端するようにしている。
これにより、プロキシ装置３０がＵＳＥＰをサポートしている場合、信頼性の高い制御機能を備えていない下位プロトコル上でＵＳＥＰを動作させる場合でも、プロキシ装置３０がＵＳＥＰ通信を終端することで暗号化するか否かを選択しつつ多重化通信を実施することができる。したがって、よりセキュリティを適切に保護しつつ処理負荷を軽減することが可能となる。
要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
１…通信システム、１０…クライアント装置、１１，２１…上位プロトコル処理部、１２…クライアント装置ＵＳＥＰ処理部、１３，２３…下位プロトコル処理部、１４，２４…送受信部、２０…サーバ装置、２２…サーバ装置ＵＳＥＰ処理部、３０…プロキシ装置、１００，２００…上位プロトコル連携部、１０１，２０１…ＵＳＥＰヘッダ処理部、１０２，２０２…下位プロトコル連携部、１０３，２０３…利用可能プロトコルＤＢ、１０４…ストリームＩＤ管理部、１０５…ストリームＩＤ管理ＤＢ、１０６，２０４…再送制御部、１００ａ，１００ｆ…プロトコルスタック、１００ｂ，１００ｇ…パケットフォーマット、１００ｃ…プロトコルリスト、１００ｄ…ストリームＩＤ管理リスト、１００ｅ…取得リソース、１００ｈ…到達未確認ストリームＩＤリスト。

Claims (7)

  1. 第１エンティティ装置及び第２エンティティ装置を備え、前記第１エンティティ装置からの要求に対して前記第２エンティティ装置が応答する、ネットワークを介した通信をする際に、前記各エンティティ装置間で暗号化するか否かを選択しつつ多重化通信をするための通信プロトコルを備えた通信システムであって、
    前記通信プロトコル上の通信パケットは、前記通信パケットを暗号化するか否かを示す暗号化フラグ、前記通信パケットの通信に使用する上位レイヤの情報を示す上位レイヤ情報、及び前記通信プロトコル上で行われる通信を識別するストリームＩＤをヘッダ情報に含み、
    前記第１エンティティ装置は、
    使用中のストリームＩＤ及び前記第２エンティティ装置のホスト名を関連付けて記憶する記憶手段と、
    前記記憶したストリームＩＤに基づき、前記ホスト名に対応する前記使用中のストリームＩＤと重複しないＩＤ番号を、通信開始時に前記ヘッダ情報内のストリームＩＤとして設定するストリームＩＤ設定手段と、
    前記通信パケットを暗号化するか否かを選択する暗号化選択手段と、
    前記選択結果に基づき、前記ヘッダ情報内の暗号化フラグを設定する暗号化フラグ設定手段と、
    前記ヘッダ情報内の上位レイヤ情報を設定する上位レイヤ情報設定手段と、
    を備え、
    前記各エンティティ装置は、
    異なるストリームＩＤが設定された複数の前記通信パケットを、コネクション型の下位レイヤの場合は当該下位レイヤにおける単一のコネクション上で送受信し、コネクションレス型の下位レイヤの場合は当該下位レイヤ上で送受信する送受信手段、
    を備えたことを特徴とする通信システム。
  2. 前記通信プロトコル上の通信パケットは、前記通信パケットの到達保証を実施するか否かを示す到達保証実施フラグ及び前記通信パケットの到達確認がされたか否かを示す到達確認フラグを前記ヘッダ情報に更に含み、
    前記第１エンティティ装置は、
    前記ヘッダ情報内の到達保証実施フラグを設定する到達保証実施フラグ設定手段と、
    前記到達確認がされた値に到達確認フラグが設定されていない通信パケットのストリームＩＤを記憶する到達未確認ストリームＩＤ記憶手段と、
    を更に備え、
    前記第２エンティティ装置は、
    前記ヘッダ情報内の到達確認フラグを設定する到達確認フラグ設定手段と、
    前記到達保証を実施する値に到達保証実施フラグが設定され、前記到達確認がされた値に到達確認フラグが設定されていない通信パケットを受信すると、前記到達確認がされた値に到達確認フラグが設定された到着確認メッセージを送信する到達確認メッセージ送信手段と、
    を更に備えたことを特徴とする請求項１に記載の通信システム。
  3. 前記各エンティティ装置間に第３エンティティ装置を更に備え、
    前記第３エンティティ装置は、
    前記第１エンティティ装置及び前記第２エンティティ装置間の通信を前記下位レイヤでトンネルする、
    ことを特徴とする請求項１又は請求項２記載の通信システム。
  4. 前記暗号化選択手段は、予め定められたルールに基づいて暗号化するか否かを静的に選択する、
    ことを特徴とする請求項１乃至請求項３のいずれか１項に記載の通信システム。
  5. 前記暗号化選択手段は、暗号化するか否かをユーザに動的に選択させる、
    ことを特徴とする請求項１乃至請求項３のいずれか１項に記載の通信システム。
  6. 第１エンティティ装置及び第２エンティティ装置を備え、前記第１エンティティ装置からの要求に対して前記第２エンティティ装置が応答する、ネットワークを介した通信をする際に、前記各エンティティ装置間で暗号化するか否かを選択しつつ多重化通信をするための通信プロトコルを備えた通信システムにおける通信方法であって、
    前記通信プロトコル上の通信パケットは、前記通信パケットを暗号化するか否かを示す暗号化フラグ、前記通信パケットの通信に使用する上位レイヤの情報を示す上位レイヤ情報、及び前記通信プロトコル上で行われる通信を識別するストリームＩＤをヘッダ情報に含み、
    前記第１エンティティ装置は、
    使用中のストリームＩＤ及び前記第２エンティティ装置のホスト名を関連付けて記憶する記憶工程と、
    前記記憶したストリームＩＤに基づき、前記ホスト名に対応する前記使用中のストリームＩＤと重複しないＩＤ番号を、通信開始時に前記ヘッダ情報内のストリームＩＤとして設定するストリームＩＤ設定工程と、
    前記通信パケットを暗号化するか否かを選択する暗号化選択工程と、
    前記選択結果に基づき、前記ヘッダ情報内の暗号化フラグを設定する暗号化フラグ設定工程と、
    前記ヘッダ情報内の上位レイヤ情報を設定する上位レイヤ情報設定工程と、
    を備え、
    前記各エンティティ装置は、
    異なるストリームＩＤが設定された複数の前記通信パケットを、コネクション型の下位レイヤの場合は当該下位レイヤにおける単一のコネクション上で送受信し、コネクションレス型の下位レイヤの場合は当該下位レイヤ上で送受信する送受信工程、
    を備えたことを特徴とする通信方法。
  7. 第１エンティティ装置及び第２エンティティ装置を備え、前記第１エンティティ装置からの要求に対して前記第２エンティティ装置が応答する、ネットワークを介した通信をする際に、前記各エンティティ装置間で暗号化するか否かを選択しつつ多重化通信をするための通信プロトコルを備えた通信システムに関し、前記各エンティティ装置に用いられるプログラムであって、
    前記通信プロトコル上の通信パケットは、前記通信パケットを暗号化するか否かを示す暗号化フラグ、前記通信パケットの通信に使用する上位レイヤの情報を示す上位レイヤ情報、及び前記通信プロトコル上で行われる通信を識別するストリームＩＤをヘッダ情報に含み、
    前記第１エンティティ装置のコンピュータを、
    使用中のストリームＩＤ及び前記第２エンティティ装置のホスト名を関連付けてメモリに記憶する記憶手段、
    前記記憶したストリームＩＤに基づき、前記ホスト名に対応する前記使用中のストリームＩＤと重複しないＩＤ番号を、通信開始時に前記ヘッダ情報内のストリームＩＤとして設定するストリームＩＤ設定手段、
    前記通信パケットを暗号化するか否かを選択する暗号化選択手段、
    前記選択結果に基づき、前記ヘッダ情報内の暗号化フラグを設定する暗号化フラグ設定手段、
    前記ヘッダ情報内の上位レイヤ情報を設定する上位レイヤ情報設定手段、として機能させ、
    前記各エンティティ装置のコンピュータを、
    異なるストリームＩＤが設定された複数の前記通信パケットを、コネクション型の下位レイヤの場合は当該下位レイヤにおける単一のコネクション上で送受信し、コネクションレス型の下位レイヤの場合は当該下位レイヤ上で送受信する送受信手段、
    として機能させるためのプログラム。
JP2014163893A 2014-08-11 2014-08-11 通信システム、方法及びプログラム Active JP6194292B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014163893A JP6194292B2 (ja) 2014-08-11 2014-08-11 通信システム、方法及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014163893A JP6194292B2 (ja) 2014-08-11 2014-08-11 通信システム、方法及びプログラム

Publications (2)

Publication Number Publication Date
JP2016038881A JP2016038881A (ja) 2016-03-22
JP6194292B2 true JP6194292B2 (ja) 2017-09-06

Family

ID=55529857

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014163893A Active JP6194292B2 (ja) 2014-08-11 2014-08-11 通信システム、方法及びプログラム

Country Status (1)

Country Link
JP (1) JP6194292B2 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6681282B2 (ja) * 2016-06-16 2020-04-15 人吉アサノ電機株式会社 電力デマンド遠隔管理システム、デマンドコントローラ、デマンドコントローラの親機、および電力デマンドの遠隔管理方法
US9998299B2 (en) * 2016-07-20 2018-06-12 Oracle International Corporation Efficient transport of encapsulated media traffic over restrictive networks
JP6716424B2 (ja) * 2016-10-31 2020-07-01 株式会社東芝 データ収集システム、末端装置、データ収集装置、データ収集方法及びプログラム
JP7004982B2 (ja) * 2017-08-03 2022-01-21 株式会社 アプトポッド クライアント装置、データ収集システム、データ送信方法、及びプログラム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0746331B2 (ja) * 1988-03-08 1995-05-17 松下電器産業株式会社 異機種通信システム間のデータ通信方法
JP2005295468A (ja) * 2004-04-06 2005-10-20 Hitachi Hybrid Network Co Ltd 通信装置及び通信システム

Also Published As

Publication number Publication date
JP2016038881A (ja) 2016-03-22

Similar Documents

Publication Publication Date Title
KR102487923B1 (ko) 서비스들 - 사용자-평면 접근법에 대한 네트워크 토큰들을 이용한 효율적인 정책 집행
US8811397B2 (en) System and method for data communication between a user terminal and a gateway via a network node
JP5969689B2 (ja) リアルタイム通信のための冗長性
US20100138649A1 (en) Transmission of packet data over a network with security protocol
US20140205096A1 (en) Un-ciphered network operation solution
JP6194292B2 (ja) 通信システム、方法及びプログラム
JP2015525018A (ja) コール確立時間を短縮させるシステムおよび方法
CN110191052B (zh) 一种跨协议网络传输方法及系统
CN110800271B (zh) 激活应用于数据会话的进程的方法
JP4892404B2 (ja) 暗号化パケット転送方法、中継装置、そのプログラムおよび通信システム
TWI549553B (zh) Communication methods and communication systems
JPWO2009011120A1 (ja) アドレス生成方法、アドレス生成システム、通信装置、通信方法、通信システム及び相手先通信装置
JP5326815B2 (ja) パケット送受信装置およびパケット送受信方法
JP2011160286A (ja) 呼制御サーバ、中継サーバ、ｖｐｎ装置、ｖｐｎ通信システム、ｖｐｎネットワーキング方法、プログラム、及び記憶媒体
JP3979390B2 (ja) モバイルルータ装置およびホームエージェント装置
JP5840575B2 (ja) マルチホーム通信方法およびシステム
KR101730404B1 (ko) 네트워크 경로를 관리하는 방법 및 이를 수행하는 네트워크 엔티티
JP2011077887A (ja) パケット転送システム、パケット転送方法、通信装置及びパケット転送プログラム
JP4571006B2 (ja) ネットワーク制御装置、ネットワークシステム、及びプログラム
US20160308836A1 (en) Virtual private network security apparatus and operation method thereof
JP5854148B2 (ja) シームレスプッシュシステム及びその方法
Matama et al. Extension mechanism of overlay network protocol to support digital authenticates
KR101594897B1 (ko) 사물 인터넷에서 경량 사물간 보안 통신 세션 개설 방법 및 보안 통신 시스템
JP2022161704A (ja) 通信システムおよび通信方法
JP5832396B2 (ja) ＩＰｓｅｃ装置およびＩＰｓｅｃ通信方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160715

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170524

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170613

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170718

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170808

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170814

R150 Certificate of patent or registration of utility model

Ref document number: 6194292

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150