(57)【要約】【課題】セキュリティを適切に保護しつつ処理負荷を軽減することができるようにする。【解決手段】通信プロトコル上の通信パケットは、上記通信パケットを暗号化するか否かを示す暗号化フラグ、上記通信パケットの通信に使用する上位レイヤの情報を示す上位レイヤ情報、及び上記通信プロトコル上で行われる通信を識別するストリームＩＤをヘッダ情報に含む。クライアント装置１０は、サーバ装置２０のホスト名と関連付けたストリームＩＤに基づき、上記ホスト名に対応する使用中のストリームＩＤと重複しないＩＤ番号を、通信開始時にストリームＩＤとして設定する。上記各装置１０，２０は、上記通信パケットを暗号化するか否かを選択し、上記選択結果に基づき上記暗号化フラグを設定し、上位レイヤ情報を設定する。上記各装置１０，２０は、異なるストリームＩＤが設定された複数の上記通信パケットを、単一の下位レイヤのコネクション上で送受信する。【選択図】図４
2016038881.tif 000002
【特許請求の範囲】
【請求項１】
第１エンティティ装置及び第２エンティティ装置を備え、前記第１エンティティ装置からの要求に対して前記第２エンティティ装置が応答する、ネットワークを介した通信をする際に、前記各エンティティ装置間で暗号化するか否かを選択しつつ多重化通信をするための通信プロトコルを備えた通信システムであって、
前記通信プロトコル上の通信パケットは、前記通信パケットを暗号化するか否かを示す暗号化フラグ、前記通信パケットの通信に使用する上位レイヤの情報を示す上位レイヤ情報、及び前記通信プロトコル上で行われる通信を識別するストリームＩＤをヘッダ情報に含み、
前記第１エンティティ装置は、
使用中のストリームＩＤ及び前記第２エンティティ装置のホスト名を関連付けて記憶する記憶手段と、
前記記憶したストリームＩＤに基づき、前記ホスト名に対応する前記使用中のストリームＩＤと重複しないＩＤ番号を、通信開始時に前記ヘッダ情報内のストリームＩＤとして設定するストリームＩＤ設定手段とを備え、
前記各エンティティ装置は、
前記通信パケットを暗号化するか否かを選択する暗号化選択手段と、
前記選択結果に基づき、前記ヘッダ情報内の暗号化フラグを設定する暗号化フラグ設定手段と、
前記ヘッダ情報内の上位レイヤ情報を設定する上位レイヤ情報設定手段と、
異なるストリームＩＤが設定された複数の前記通信パケットを、単一の下位レイヤのコネクション上で送受信する送受信手段と、
を備えたことを特徴とする通信システム。
【請求項２】
前記通信プロトコル上の通信パケットは、前記通信パケットの到達保証を実施するか否かを示す到達保証実施フラグ及び前記通信パケットの到達確認がされたか否かを示す到達確認フラグを前記ヘッダ情報に更に含み、
前記各エンティティ装置は、
前記ヘッダ情報内の到達保証実施フラグを設定する到達保証実施フラグ設定手段と、
前記ヘッダ情報内の到達確認フラグを設定する到達確認フラグ設定手段と、
前記到達確認がされた値に到達確認フラグが設定されていない通信パケットのストリームＩＤを記憶する到達未確認ストリームＩＤ記憶手段と、
前記到達保証を実施する値に到達保証実施フラグが設定され、前記到達確認がされた値に到達確認フラグが設定されていない通信パケットを受信すると、前記到達確認がされた値に到達確認フラグが設定された到着確認メッセージを送信する到達確認メッセージ送信手段と、
を更に備えたことを特徴とする請求項１に記載の通信システム。
【請求項３】
前記各エンティティ装置間に第３エンティティ装置を更に備え、
前記第３エンティティ装置は、
前記第１エンティティ装置及び前記第２エンティティ装置間の通信を前記下位レイヤでトンネルする、
ことを特徴とする請求項１又は請求項２記載の通信システム。
【請求項４】
前記暗号化選択手段は、予め定められたルールに基づいて暗号化するか否かを静的に選択する、
ことを特徴とする請求項１乃至請求項３のいずれか１項に記載の通信システム。
【請求項５】
前記暗号化選択手段は、暗号化するか否かをユーザに動的に選択させる、
ことを特徴とする請求項１乃至請求項３のいずれか１項に記載の通信システム。
【請求項６】
第１エンティティ装置及び第２エンティティ装置を備え、前記第１エンティティ装置からの要求に対して前記第２エンティティ装置が応答する、ネットワークを介した通信をする際に、前記各エンティティ装置間で暗号化するか否かを選択しつつ多重化通信をするための通信プロトコルを備えた通信システムにおける通信方法であって、
前記通信プロトコル上の通信パケットは、前記通信パケットを暗号化するか否かを示す暗号化フラグ、前記通信パケットの通信に使用する上位レイヤの情報を示す上位レイヤ情報、及び前記通信プロトコル上で行われる通信を識別するストリームＩＤをヘッダ情報に含み、
前記第１エンティティ装置は、
使用中のストリームＩＤ及び前記第２エンティティ装置のホスト名を関連付けて記憶する記憶工程と、
前記記憶したストリームＩＤに基づき、前記ホスト名に対応する前記使用中のストリームＩＤと重複しないＩＤ番号を、通信開始時に前記ヘッダ情報内のストリームＩＤとして設定するストリームＩＤ設定工程とを備え、
前記各エンティティ装置は、
前記通信パケットを暗号化するか否かを選択する暗号化選択工程と、
前記選択結果に基づき、前記ヘッダ情報内の暗号化フラグを設定する暗号化フラグ設定工程と、
前記ヘッダ情報内の上位レイヤ情報を設定する上位レイヤ情報設定工程と、
異なるストリームＩＤが設定された複数の前記通信パケットを、単一の下位レイヤのコネクション上で送受信する送受信工程と、
を備えたことを特徴とする通信方法。
【請求項７】
第１エンティティ装置及び第２エンティティ装置を備え、前記第１エンティティ装置からの要求に対して前記第２エンティティ装置が応答する、ネットワークを介した通信をする際に、前記各エンティティ装置間で暗号化するか否かを選択しつつ多重化通信をするための通信プロトコルを備えた通信システムに関し、前記各エンティティ装置に用いられるプログラムであって、
前記通信プロトコル上の通信パケットは、前記通信パケットを暗号化するか否かを示す暗号化フラグ、前記通信パケットの通信に使用する上位レイヤの情報を示す上位レイヤ情報、及び前記通信プロトコル上で行われる通信を識別するストリームＩＤをヘッダ情報に含み、
前記第１エンティティ装置のコンピュータを、
使用中のストリームＩＤ及び前記第２エンティティ装置のホスト名を関連付けてメモリに記憶する記憶手段、
前記記憶したストリームＩＤに基づき、前記ホスト名に対応する前記使用中のストリームＩＤと重複しないＩＤ番号を、通信開始時に前記ヘッダ情報内のストリームＩＤとして設定するストリームＩＤ設定手段、として機能させ、
前記各エンティティ装置のコンピュータを、
前記通信パケットを暗号化するか否かを選択する暗号化選択手段、
前記選択結果に基づき、前記ヘッダ情報内の暗号化フラグを設定する暗号化フラグ設定手段、
前記ヘッダ情報内の上位レイヤ情報を設定する上位レイヤ情報設定手段、
異なるストリームＩＤが設定された複数の前記通信パケットを、単一の下位レイヤのコネクション上で送受信する送受信手段、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、通信システム、方法及びプログラムに関する。
【背景技術】
【０００２】
インターネットを主とした従来の通信システムでは、クライアントからのリクエストに対してサーバがレスポンスする構造を持つ、ＨＴＴＰ(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)フラグを設定したＴＣＰセグメントを送信する（ＳＴ６０５）。サーバ装置２０は、クライアント装置１０にＦＩＮフラグとＡＣＫフラグを設定したＴＣＰセグメントを送信する（ＳＴ６０６）。クライアント装置１０は、サーバ装置２０にＡＣＫフラグを設定したＴＣＰセグメントを送信する（ＳＴ６０７）。以降は、クライアント装置１０は、サーバ装置２０に対してＵＤＰ上でのＵＳＥＰ通信を実行する。
【０１３５】
次に、サーバ装置２０内のリソースを取得する際の動作について、図１８のシーケンス図を用いて説明する。なお、サーバ装置２０から取得されるリソースは、図９に示すように上位プロトコルとしてＨＴＴＰを利用したページ上のうち、１種類のファイル（テキストＡ）であるとする。また、暗号化するか否かの選択結果は、テキストＡを暗号化することを示すものとする。
【０１３６】
クライアント装置１０は、テキストＡに関する要求メッセージを作成する。クライアント装置１０は、当該メッセージの通信パケット作成に際し、ヘッダ情報内のストリームＩＤに“１”を設定し、暗号化フラグに暗号化を示す“１”を設定する。
【０１３７】
クライアント装置１０は、ＵＳＥＰヘッダ内の到達保証実施フラグを設定する。ここでは、到達保証実施フラグに“１”を設定する。また、クライアント装置１０は、ＵＳＥＰヘッダ内の到達確認フラグを設定する。ここでは、到達確認フラグに“０”を設定する（ＳＴ７００）。
【０１３８】
クライアント装置１０は、まだ到達確認フラグが“１”に設定されていない当該通信パケットについて、ストリームＩＤのＩＤ番号である“１”を、到達未確認ストリームＩＤリスト１００ｈに記憶する（ＳＴ７０１）。クライアント装置１０は、ＨＴＴＰの「ＧＥＴ」メソッドを用い、テキストＡの取得を要求するメッセージをサーバ装置２０に送信する（ＳＴ７０２）。
【０１３９】
サーバ装置２０は、テキストＡの要求メッセージを受信し、これに対する応答メッセージとして、到着確認メッセージを作成する（ＳＴ７０３）。具体的には、サーバ装置２０は、到達保証実施フラグが“１”に設定されており、到達確認フラグが“１”に設定されていないメッセージを受信すると、到達確認フラグが“１”に設定された到着確認メッセージを作成する。なお、到着確認メッセージのストリームＩＤは、受信した要求メッセージのストリームＩＤと同一のＩＤ番号を設定する。ここでは、サーバ装置２０は、応答メッセージ作成に際し、ＵＳＥＰヘッダ情報内のストリームＩＤに“１”を設定し、暗号化フラグに“１”を設定し、到達保証実施フラグ及び到達確認フラグに“１”を設定する。また、サーバ装置２０は、応答メッセージのデータ情報内に、暗号化したテキストＡを設定する。
【０１４０】
サーバ装置２０は、「ＯＫ」ステータスと共に、暗号化したテキストＡを応答メッセージとしてクライアント装置１０に送信する（ＳＴ７０４）。
【０１４１】
クライアント装置１０は、応答メッセージとして、到着確認メッセージを受信する。クライアント装置１０は、受信した到着確認メッセージのヘッダ情報内の到達保証実施フラグが“１”であることを確認し、当該メッセージを再送制御部１０６に送信する。再送制御部１０６は、到達未確認ストリームＩＤリスト１００ｈ内を検索し、ストリームＩＤ“１”をリストから削除する（ＳＴ７０５）。
【０１４２】
クライアント装置１０は、全ての要求データを受信した後、ＵＳＥＰ通信を終了する。クライアント装置１０は、ＵＳＥＰ終了時に使用したストリームＩＤを削除する（ＳＴ７０６）。
【０１４３】
なお、セッション確立時の動作は、図１７に示した「Ａｌｔｅｒｎａｔｅ−Ｐｒｏｔｏｃｏｌ」ヘッダを用いてＵＳＥＰセッションの利用可能性を交渉するシーケンスに限らず、ダイレクトにＵＳＥＰによる接続を試みてもよい。以下に、ダイレクトにＵＳＥＰによる接続を試みる際のセッション確立時の動作について、図１９のシーケンス図を用いて説明する。
【０１４４】
クライアント装置１０は、送信する通信パケットについてヘッダ情報内の到達保証実施フラグを設定する。クライアント装置１０は、到達保証を実施する値に到達保証実施フラグが設定された通信パケットをサーバ装置２０に送信する。サーバ装置２０は、到達保証実施フラグが設定された通信パケットを受信する（ＳＴ８００）。
【０１４５】
サーバ装置２０は、到達保証実施フラグが設定された通信パケットを受信すると、到達確認メッセージを作成する。すなわち、サーバ装置２０は、到達確認がされた値に到達確認フラグが設定された通信パケットをクライアント装置１０に送信する。クライアント装置１０は、到達確認フラグが設定されたＵＳＥＰパケットを受信する（ＳＴ８０１）。以上より、クライアント装置１０及びサーバ装置２０の双方でＵＳＥＰをサポートしていることが確認できるため、クライアント装置１０は、ＵＳＥＰによる通信に切り替える。
【０１４６】
以上詳述したように、他の実施形態では、通信規約１００ｇ上の通信パケットは、通信パケットの到達保証を実施するか否かを示す到達保証実施フラグ及び通信パケットの到達確認がされたか否かを示す到達確認フラグを更に含む。各エンティティ装置１０，２０は、上記ヘッダ情報内の到達保証実施フラグを設定する。各エンティティ装置１０，２０は、上記ヘッダ情報内の到達確認フラグを設定する。上記到達確認フラグが設定されていない通信パケットのストリームＩＤを記憶する。到達保証を実施する値に到達保証実施フラグが設定され、到達確認がされた値に到達確認フラグが設定されていない通信パケットを受信すると、到達確認がされた値に到達確認フラグが設定された到着確認メッセージを送信するようにしている。
【０１４７】
したがって、信頼性を高める制御機能を備えていないプロトコル上でＵＳＥＰ通信を実施する際にも、ＵＳＥＰレイヤ上で再送制御を実施することができるようになり、より信頼性を高めることが可能となる。
【０１４８】
その他、クライアント装置及びサーバ装置の構成や機能、通信手順、処理手順と処理内容等についても、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。
【０１４９】
例えば、通信システム１は、プロキシ装置３０を備えていてもよい。クライアント装置１０及びサーバ装置２０は、プロキシ装置３０を介して接続されていてもよい。プロキシ装置３０は、ＵＳＥＰをサポートしていてもよく、ＵＳＥＰをサポートしていなくてもよい。
【０１５０】
クライアント装置１０及びサーバ装置２０は、プロキシ装置３０がＵＳＥＰをサポートしていない場合、ＵＳＥＰの下位レイヤでトンネルすることで、ＵＳＥＰによる通信の接続を確立してもよい。
【０１５１】
このときのセッション確立時の動作を図２０に示すシーケンス図を用いて説明する。
【０１５２】
クライアント装置１０及びサーバ装置２０は、プロキシ装置３０がトンネリングすることで、ＴＣＰコネクションを確立する（ＳＴ９００〜ＳＴ９０７）。具体的には、ステップＳＴ９００〜ＳＴ９０７は、ステップＳＴ３００〜ＳＴ３０７と同等であるため、説明を省略する。
【０１５３】
クライアント装置１０は、ＨＴＴＰ等による通信を開始する（ＳＴ９０８）。
【０１５４】
サーバ装置２０は、「Ａｌｔｅｒｎａｔｅ−Ｐｒｏｔｏｃｏｌ」ヘッダに“ｕｓｅｐ”値を設定することでＵＳＥＰセッションの利用可能性をクライアント装置１０と交渉する（ＳＴ９０９）。
【０１５５】
クライアント装置１０は、ＵＳＥＰセッションが利用可能な場合、ＴＣＰコネクションを切断し（ＳＴ９１０〜ＳＴ９１２）、ＵＤＰ上でのＵＳＥＰ通信に切り替える。以上より、クライアント装置１０及びサーバ装置２０は、プロキシ装置３０がトンネリングすることで、ＵＳＥＰによる通信の接続を確立する。
【０１５６】
このように、この変形例では、クライアント装置１０及びサーバ装置２０間に備えられたプロキシ装置３０が、クライアント装置１０及びサーバ装置２０間のＵＳＥＰ通信を下位レイヤでトンネルするようにしている。
【０１５７】
これにより、プロキシ装置３０がＵＳＥＰをサポートしていない状況で、信頼性の高い制御機能を備えていない下位プロトコル上でＵＳＥＰを動作させる場合でも、クライアント装置１０及びサーバ装置２０間で暗号化するか否かを選択しつつ多重化通信を実施することができる。したがって、よりセキュリティを適切に保護しつつ処理負荷を軽減することが可能となる。
【０１５８】
また、クライアント装置１０及びサーバ装置２０は、プロキシ装置３０がＵＳＥＰをサポートしている場合、プロキシ装置３０がＵＳＥＰによる通信を終端することで、ＵＳＥＰによる通信の接続を確立してもよい。
【０１５９】
このときのセッション確立時の動作を図２１に示すシーケンス図を用いて説明する。
【０１６０】
クライアント装置１０及びプロキシ装置３０は、ＨＴＴＰの「Ａｌｔｅｒｎａｔｅ−Ｐｒｏｔｏｃｏｌ」ヘッダを用いてＵＳＥＰセッションの利用可能性を交渉し、ＵＳＥＰによる通信の接続を確立する（ＳＴ１０００〜ＳＴ１００７）。具体的には、ステップＳＴ１０００〜ＳＴ１００７は、ステップＳＴ６００〜ＳＴ６０７と同等であるため、説明を省略する。
【０１６１】
プロキシ装置３０及びサーバ装置２０は、ＨＴＴＰの「Ａｌｔｅｒｎａｔｅ−Ｐｒｏｔｏｃｏｌ」ヘッダを用いてＵＳＥＰセッションの利用可能性を交渉し、ＵＳＥＰによる通信の接続を確立する（ＳＴ１００８〜ＳＴ１０１５）。具体的には、ステップＳＴ１００８〜ＳＴ１０１５は、ステップＳＴ６００〜ＳＴ６０７と同等であるため、説明を省略する。以上より、クライアント装置１０及びサーバ装置２０は、プロキシ装置３０が終端することにより、ＵＳＥＰによる通信の接続を確立する。
【０１６２】
なお、プロキシ装置３０を介するＵＳＥＰセッションの確立方法は、ダイレクトにＵＳＥＰによる接続を試みる方法に適用してもよい。
【０１６３】
このように、この変形例では、クライアント装置１０及びサーバ装置２０間に備えられたプロキシ装置３０が、ＵＳＥＰ通信を終端するようにしている。
【０１６４】
これにより、プロキシ装置３０がＵＳＥＰをサポートしている場合、信頼性の高い制御機能を備えていない下位プロトコル上でＵＳＥＰを動作させる場合でも、プロキシ装置３０がＵＳＥＰ通信を終端することで暗号化するか否かを選択しつつ多重化通信を実施することができる。したがって、よりセキュリティを適切に保護しつつ処理負荷を軽減することが可能となる。
【０１６５】
要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【０１６６】
１…通信システム、１０…クライアント装置、１１，２１…上位プロトコル処理部、１２…クライアント装置ＵＳＥＰ処理部、１３，２３…下位プロトコル処理部、１４，２４…送受信部、２０…サーバ装置、２２…サーバ装置ＵＳＥＰ処理部、３０…プロキシ装置、１００，２００…上位プロトコル連携部、１０１，２０１…ＵＳＥＰヘッダ処理部、１０２，２０２…下位プロトコル連携部、１０３，２０３…利用可能プロトコルＤＢ、１０４…ストリームＩＤ管理部、１０５…ストリームＩＤ管理ＤＢ、１０６，２０４…再送制御部、１００ａ，１００ｆ…プロトコルスタック、１００ｂ，１００ｇ…パケットフォーマット、１００ｃ…プロトコルリスト、１００ｄ…ストリームＩＤ管理リスト、１００ｅ…取得リソース、１００ｈ…到達未確認ストリームＩＤリスト。
【図１】
2016038881.tif 000003
【図２】
2016038881.tif 000004
【図３】
2016038881.tif 000005
【図４】
2016038881.tif 000006
【図５】
2016038881.tif 000007
【図６】
2016038881.tif 000008
【図７】
2016038881.tif 000009
【図８】
2016038881.tif 000010
【図９】
2016038881.tif 000011
【図１０】
2016038881.tif 000012
【図１１】
2016038881.tif 000013
【図１２】
2016038881.tif 000014
【図１３】
2016038881.tif 000015
【図１４】
2016038881.tif 000016
【図１５】
2016038881.tif 000017
【図１６】
2016038881.tif 000018
【図１７】
2016038881.tif 000019
【図１８】
2016038881.tif 000020
【図１９】
2016038881.tif 000021
【図２０】
2016038881.tif 000022
【図２１】
2016038881.tif 000023