JP6516539B2 - 通信装置、通信方法、およびプログラム - Google Patents

Description

本発明は、通信装置、通信方法、およびプログラムに関し、特に、外部装置との通信を行うために用いて好適なものである。

インターネット標準技術として利用されている通信プロトコル（通信規約）の一つに、ＨＴＴＰ／１．１（Hyper Text Transfer Protocol）がある（非特許文献１参照）。現在、インターネット標準化団体（ＩＥＴＦ：Internet Engineering Task Force）において、ＨＴＴＰの新しいバージョン（ＨＴＴＰ／２）の標準化の策定が進められている（非特許文献２参照）。

ＨＴＴＰ／１．１では、サーバとクライアントとをＴＣＰコネクションで接続し、その接続内においてクライアントからサーバにリクエストを送信する。クライアントは、一つのリクエストに対するレスポンスがサーバから返ってくるまで、次のリクエストを送信する事ができない。しかし、クライアントは、複数のＴＣＰコネクションを使用する事で、接続したＴＣＰコネクションの数分のリクエストを並列に送信する事ができる。

一方、ＨＴＴＰ／２では、サーバとクライアントとをＴＣＰコネクションで接続し、その接続内において、ストリームと呼ばれる論理的なセッションを複数構築（多重化）する。クライアントは、それぞれのストリーム上で、サーバに並列にリクエストを送信する事ができる。ＨＴＴＰ／２では、ＴＣＰコネクションの数による制限を受けずに、リクエストを並列に送信する事ができる。

Hypertext Transfer Ｐｒｏｔｏｃｏｌ ―― ＨＴＴＰ／１．１ ［平成２６年１１月２５日検索］インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／Ｐｒｏｔｏｃｏｌｓ／ ｒｆｃ２６１６／ｒｆｃ２６１６．ｈｔｍｌ＞ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ２ ｄｒａｆｔ―ｉｅｔｆ―ｈｔｔｐｂｉｓ―ｈｔｔｐ２―１７ ［平成２６年１１月２５日検索］インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ―ｉｅｔｆ―ｈｔｔｐｂｉｓ―ｈｔｔｐ２―１７＞

しかしながら、ＨＴＴＰ／１．１とＨＴＴＰ／２との何れか一方の通信プロトコルを使用する事で、常に早く通信を完了させることができるというわけではない。
例えば、ＨＴＴＰ／１．１では、ＴＣＰコネクション数以上のリクエストを送信する場合、そのリクエストに対するレスポンスが戻ってくるまで送信できないリクエストが発生する。その結果、リクエストに対するレスポンスの応答時間が長くなる。

一方、ＨＴＴＰ／２では、ストリームの数がＴＣＰコネクション数により制限されないため、リクエストに対するレスポンスを待たずに、全てのリクエストを並列に送信する事ができる。その結果、リクエストに対するレスポンスの応答時間がＨＴＴＰ／１．１よりも短くなる。
しかしながら、ＨＴＴＰ／２を使用する事で、通信完了がＨＴＴＰ／１．１よりも遅くなる場合もある。例えば、一つのＨＴＴＰリクエストを送信する場合が考えられる。ＨＴＴＰ／２では、通信開始時にプロトコルアップグレードを行う必要がある。通信プロトコルのアップグレードにProtocol Upgradeメカニズムを使用する場合、サーバとクライアントとの間で追加のやり取りが必要となる。したがって、ＨＴＴＰ／１．１を用いて通信するよりもＨＴＴＰ／２を用いて通信する場合のほうが、通信完了が遅くなる場合がある。
以上の課題は、ＨＴＴＰ／１．１とＨＴＴＰ／２に限られない。例えば、ＨＴＴＰ／１．１とＳＰＤＹや、ＨＴＴＰ／１．１とＱＵＩＣ（Quick UDP Internet Connections）等においても同様である。

本発明は、このような問題点に鑑みてなされたものであり、複数の通信プロトコルを実行可能な通信装置による通信完了までの時間を短縮させることを目的とする。

本発明の通信装置は、通信装置であって、他の通信装置との通信のために、前記他の通信装置に対して連続的に送信されるＨＴＴＰリクエストの数を特定する特定手段と、前記特定手段により特定された前記ＨＴＴＰリクエストの数に基づいて、１つのコネクションにおいて連続的に複数のＨＴＴＰリクエストを送信することが許容されない第１通信プロトコルと、１つのコネクションにおいて連続的に複数のＨＴＴＰリクエストを送信することが許容される第２通信プロトコルとを含む複数の通信プロトコルから、前記他の通信装置との通信に使用する通信プロトコルを選択する選択手段と、を有することを特徴とする。

本発明によれば、複数の通信プロトコルを実行可能な通信装置による通信完了までの時間を短縮させることができる。

通信システムの構成を示す図である。 通信装置およびサーバのハードウェアの構成を示す図である。 通信装置のモジュール構成を示す図である。 通信装置の処理を説明するフローチャートである。 通信装置とサーバとの接続履歴を示す図である。 通信プロトコルの選択方法の第１の例を説明するフローチャートである。 通信プロトコルの選択方法の第２の例を説明するフローチャートである。 通信システムにおけるシーケンスの第１の例を示す図である。 通信システムにおけるシーケンスの第２の例を示す図である。 通信システムにおけるシーケンスの第３の例を示す図である。

以下、図面を参照して一実施形態を説明する。
図１は、通信システムの構成の一例を示す図である。
ネットワーク１００には、通信装置１０１とサーバ１０２とが接続される。本実施形態では、ネットワーク１００の形態は限定されない。例えば、ネットワーク１００は、インターネット、ＷＡＮ（Wide Area Network）、およびＬＡＮ（Local Area Network）の少なくとも１つを用いて構築される。尚、通信装置１０１とサーバ１０２は、ネットワーク１００を介さずに、直接接続されても良い。例えば、無線アドホックネットワークを用いて、通信装置１０１とサーバ１０２とが通信するようにしても良い。

通信装置１０１は、ネットワーク１００を通じてサーバ１０２と通信を行う。サーバ１０２との通信を行う際には、通信装置１０１は、クライアントとなる。本実施形態では、サーバ１０２との通信に際し、通信装置１０１が、ＨＴＴＰ（Hyper Text Transfer Protocol）／１．１およびＨＴＴＰ／２のうち何れか１つの通信プロトコルを選択する場合を例に挙げて説明する。
サーバ１０２は、通信装置１０１から送信されたリクエストに対するレスポンスを通信装置１０１に返信する。

図２は、通信装置１０１およびサーバ１０２の適用例である情報処理装置のハードウェアの構成の一例を示す図である。尚、通信装置１０１は、撮像装置、プリンタ、およびプロジェクタ等に適用する事ができる。したがって、図２に示す構成に対し、通信装置１０１を適用する装置に応じたハードウェアが追加されることになる。また、本実施形態では、サーバ１０２は１台の情報処理装置（ＰＣ）で実現される場合を例に挙げて示す。しかしながら、サーバ１０２は、プロキシサーバを含めても良いし、クラウド上で分散して配置されていても良い。

図２において、情報処理装置２００は、ＣＰＵ（Central Processing Unit）２０１と、ＲＯＭ（Read Only Memory）２０２と、ＲＡＭ（Random Access Memory）２０３と、を有する。情報処理装置２００は、さらに、入力装置２０４と、ＨＤ（Hard Disk）２０５と、表示装置２０６と、入出力Ｉ／Ｆ（Interface）２０７と、通信Ｉ／Ｆ（Interface）２０８と、システムバス２０９と、を有する。

ＣＰＵ２０１は、情報処理装置２００における動作を統括的に制御するものであり、システムバス２０９を介して、情報処理装置２００の各構成部（２０２〜２０８）を制御する。
ＲＯＭ２０２は、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Basic Input/Output System）およびオペレーティングシステムプログラム（ＯＳ）を記憶する。また、ＲＯＭ２０２は、ＣＰＵ２０１が後述する処理を実行するために必要なプログラム等を記憶する。

ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して、ＲＯＭ２０２からの必要なプログラム等の読み出しや、ＨＤ２０５からの必要な情報等の読み出しを行って、ＲＡＭ２０３にロードする。そして、ＣＰＵ２０１は、当該プログラムや情報等の処理を実行する事で各種の動作を実現する。
入力装置２０４は、例えば、ユーザが必要に応じて、情報処理装置２００に対して操作入力を行うためのものである。入力装置２０４は、例えば、マウス、キーボード、タッチパネル、ボタン、およびスイッチの少なくとも何れか１つを用いて構成される。

ＨＤ２０５は、各種のデータおよびファイル等を記憶する記憶手段を構成する。
表示装置２０６は、液晶ディスプレイ等のコンピュータディスプレイを有し、ＣＰＵ２０１の制御に基づいて、各種の情報や画像を表示する。また、表示装置２０６は、コンピュータディスプレイとは別に、ＬＥＤ（Light Emitting Diode）等の発光部を備える。
入出力Ｉ／Ｆ２０７は、ＣＰＵ２０１の制御に基づいて、可搬型記憶媒体等との間で、データの入出力を行う。

通信Ｉ／Ｆ２０８は、ＣＰＵ２０１の制御に基づいて、外部装置とネットワークを介して各種の情報等の通信を行う。
システムバス２０９は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、入力装置２０４、ＨＤ２０５、表示装置２０６、入出力Ｉ／Ｆ２０７および通信Ｉ／Ｆ２０８を相互に通信可能に接続するためのバスである。

図３は、通信装置１０１のモジュール構成の一例を示す図である。
バス３００は、以下の各モジュール（通信部３０１〜プロトコルアップグレード部３１７）を相互に通信可能に接続するためのものである。
通信部３０１は、ＴＣＰ／ＩＰ処理およびＴＬＳ（Transport Layer Security）処理を行う。
表示制御部３０２は、通信に使用している通信プロトコルを表示装置２０６（液晶ディスプレイやＬＥＤ）に表示させるための処理を行う。本実施形態では、通信に使用している通信プロトコルを表示する場合を例に挙げて説明する。しかしながら、これに限らず、通信装置１０１は、通信に使用している通信プロトコルを、表示に加えまたは表示に代えて、音や振動を用いてユーザに通知しても良い。

データ保持部３０３は、サーバ１０２の識別子に関連付けられた履歴情報を保持、管理する。サーバ１０２の識別子に関連付けられた履歴情報については、図５を参照しながら後述する。本実施形態では、サーバ１０２の識別子に関連付けられた履歴情報のデータベースを、通信装置１０１の内部に保持する場合を例に挙げて説明する。しかしながら、これに限らず、サーバ１０２の識別子に関連付けられた履歴情報は、ネットワーク１００を介した別の装置のデータベースに保存されていても良い。

比較部３０４は、通信装置１０１とサーバ１０２との通信に使用可能なＴＣＰコネクション数と、ＨＴＴＰリクエスト数とを比較する。さらに比較部３０４は、サーバ１０２に接続できたＴＣＰコネクション数とＨＴＴＰリクエスト数とを比較する。
判断部３０５は、ＨＴＴＰリクエストに対するサーバ１０２からのＨＴＴＰレスポンスを受信した後に、ＨＴＴＰリクエストの送信を継続するか否かを判断する。さらに、判断部３０５は、通信装置１０１に入力された、サーバ１０２の識別子から、当該サーバ１０２と過去に通信を行ったことがあるか否かを判断する。さらに、判断部３０５は、サーバ１０２との通信の際にプロトコルアップグレードを省略する事が可能であるか否かを判断する。

リクエスト数取得部３０６は、第１の取得処理として、ＨＴＴＰリクエスト数を取得する。
第１リクエスト送信部３０７は、ＨＴＴＰ／１．１を使用してＨＴＴＰリクエストをサーバ１０２に送信する。
第２リクエスト送信部３０８は、ＨＴＴＰ／２を使用してＨＴＴＰリクエストをサーバ１０２に送信する。

第１レスポンス受信部３０９は、第１リクエスト送信部３０７が送信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスをサーバ１０２から受信する。
第２レスポンス受信部３１０は、第２リクエスト送信部３０８が送信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスをサーバ１０２から受信する。

コネクション数取得部３１１は、第２の取得処理として、通信装置１０１が使用できるＴＣＰコネクション数を取得する。
選択部３１２は、ＨＴＴＰ／１．１とＨＴＴＰ／２から、サーバ１０２との通信に使用する通信プロトコルを選択する。
入力部３１３は、サーバ１０２の識別子を入力する。サーバ１０２の識別子には、例えば、ＵＲＩ、ＩＰアドレスとポート番号、およびＳｅｓｓｉｏｎ−ＩＤ等が含まれる。ユーザは、入力部３１３に対して、ＵＩ（User Interface）を用いてサーバ１０２の識別子を入力する事ができる。また、ユーザは、ＮＦＣ（Near field communication）やＢｌｕｅｔｏｏｔｈ（登録商標）等を用いてサーバ１０２の識別子を入力する事もできる。また、アプリケーションが記憶しているサーバ１０２の識別子を入力部３１３の入力情報として使用しても良い。

第１接続部３１４は、通信装置１０１とサーバ１０２との間に、ＨＴＴＰ／１．１で通信するためのコネクションを確立する。
第２接続部３１５は、通信装置１０１とサーバ１０２との間に、ＨＴＴＰ／２で通信するためのコネクションを確立する。

切断部３１６は、ＨＴＴＰ／１．１およびＨＴＴＰ／２で通信するためのサーバ１０２とのコネクションを切断する。
プロトコルアップグレード部３１７は、プロトコルアップグレードを行う。さらに、プロトコルアップグレード部３１７はプロトコルアップグレードに成功したか否かを判断する。

本実施形態では、通信装置１０１が、サーバ１０２との通信に使用する通信プロトコルとして、ＨＴＴＰ／１．１とＨＴＴＰ／２との何れかを選択して通信する場合を例に挙げて説明する。しかしながら、通信装置１０１とサーバ１０２とが通信するための通信プロトコル（第１のプロトコル、第２のプロトコル）は、これらに限定されない。例えば、複数のコネクションを確立し、それぞれのコネクションを使って複数のメッセージを並列に送信する通信プロトコルとして、ＨＴＴＰ／１．１以外の通信プロトコルを用いても良い。また、１つのコネクション上に構築された論理的な複数のストリームを用いることにより複数のメッセージを並列に送信する通信プロトコルとしてＨＴＴＰ／２以外のプロトコルを用いても良い。例えば、ＨＴＴＰ／２に代えて、ＳＰＤＹまたはＱＵＩＣ（Quick UDP Internet Connections）を採用しても良い。また、その他の異種の通信プロトコル間の選択であっても良い。さらに、３つ以上の複数の通信プロトコルからの選択であっても良い。

図４は、サーバ１０２と通信を行う際の通信装置１０１の処理の一例を説明するフローチャートである。
入力部３１３は、サーバ１０２の識別子を入力する（ステップＳ４０１）。入力部３１３は、サーバ１０２の識別子を、ユーザによる操作の結果に基づいて取得しても良いし、アプリケーションから取得しても良い。本実施形態では、サーバ１０２の識別子が、例えば、ＵＲＩ、ＩＰアドレス、ポート番号、およびＳｅｓｓｉｏｎ−ＩＤを含む場合を例に挙げて説明する。しかしながら、サーバ１０２の識別子は、これらに限られず、その他、通信相手であるサーバ１０２を識別するための情報であれば、どのような情報であってもよい。

次に、コネクション数取得部３１１は、通信装置１０１とサーバ１０２との通信に使用可能なＴＣＰコネクション数を取得する（ステップＳ４０２）。
コネクション数取得部３１１は、例えば、通信装置１０１全体で使用可能であるＴＣＰコネクション数を取得しても良いし、アプリケーションが既定しているＴＣＰコネクション数を取得しても良い。

また、コネクション数取得部３１１は、通信装置１０１上の他のアプリケーションと公平性を考慮して、通信装置１０１とサーバ１０２との通信に使用可能なＴＣＰコネクション数を取得する事ができる。例えば、コネクション数取得部３１１は、通信装置１０１全体で使用可能であるＴＣＰコネクション数を、通信装置１０１に実装されているアプリケーションの数で割った値を取得する。また、これに限らず、コネクション数取得部３１１は、別な方法、例えば、スループットを考慮して、他のアプリケーションとの公平性を保てるように、通信装置１０１とサーバ１０２との通信に使用可能なＴＣＰコネクション数を取得しても良い。

また、コネクション数取得部３１１は、サーバ１０２が受け付ける事ができるＴＣＰコネクションの数を、通信装置１０１とサーバ１０２との通信に使用可能なＴＣＰコネクション数として取得する事ができる。コネクション数取得部３１１は、サーバ１０２が受け付ける事ができるコネクション数を、ＮＦＣやＢｌｕｅｔｏｏｔｈ（登録商標）等を用いてサーバ１０２から直接取得しても良いし、他の通信装置から取得しても良い。また、コネクション数取得部３１１は、サーバ１０２に対して複数のコネクションで接続を行い、サーバが実際に受け付けるコネクション数を取得しても良い。

また、コネクション数取得部３１１は、通信装置１０１全体で使用可能であるＴＣＰコネクション数と、サーバ１０２が受け付ける事ができるＴＣＰコネクション数との片方だけでなく両方を考慮してもよい。すなわち、コネクション数取得部３１１は、これらの両方に基づいて、通信装置１０１とサーバ１０２との通信に使用可能なＴＣＰコネクション数を取得する事ができる。例えば、コネクション数取得部３１１は、通信装置１０１全体で使用可能であるＴＣＰコネクション数と、サーバ１０２が受け付ける事ができるＴＣＰコネクション数とのうち小さい方を採用しても良い。また、このとき、通信装置１０１全体で使用可能であるＴＣＰコネクション数に代えて、例えば、アプリケーションが既定しているＴＣＰコネクション数を採用してもよい。

コネクション数取得部３１１は、通信装置１０１とサーバ１０２との接続履歴がある場合、過去の接続履歴から、サーバ１０２の識別子に対応するコネクション数を取得する事ができる。
図５は、通信装置１０１とサーバ１０２との接続履歴の一例を示す図である。
図５に示すテーブル５００は、サーバ１０２の識別子と、通信装置１０１とサーバ１０２との接続履歴を示す履歴情報とを相互に関連付けて記憶する。このテーブル５００は、例えば、データ保存部３０３により記憶される。

図５では、Ｓｅｓｓｉｏｎ―ＩＤと、ＩＰアドレスおよびポート番号と、ＵＲＩとを含む情報が、サーバ１０２の識別子である場合を例に挙げて示す。しかしながら、サーバ１０２の識別子は、これに限るものではなく、通信相手のサーバ１０２を一意に特定できる情報であればどのような情報であっても良い。例えば、ＳＩＰ―ＵＲＩ等の他の識別子を用いても良い。

また、図５では、最大コネクション数、リクエスト数、およびＨＴＴＰ／２通信の可否を含む情報が、履歴情報である場合を例に挙げて示す。しかしながら、履歴情報は、これに限らず、例えば、他のレイヤの設定情報等を利用して履歴情報を構成しても良い。例えば、ＭＴＵサイズ、ＴＣＰのＷｉｎｄｏｗサイズ、アプリケーションのプロトコル情報、およびアプリケーションの設定情報等を利用して履歴情報を構成しても良い。尚、最大コネクション数とは、ＨＴＴＰ／１．１の通信に使用できるＴＣＰコネクション数の最大値のことである。リクエスト数は、通信装置１０１からサーバ１０２に対して送信されるＨＴＴＰリクエストの数である。ＨＴＴＰ／２通信の可否は、サーバ１０２がＨＴＴＰ／２を使用した通信を行えるか否かを示すものである。

判断部３０５は、図５に示すテーブル５００に、ステップＳ２０１で入力されたサーバ１０２の識別子が含まれているか否かを判断する。この判断の結果、サーバ１０２の識別子がテーブルに含まれている場合、コネクション数取得部３１１は、当該サーバ１０２の識別子に対応する最大コネクション数をテーブル５００から取得する事ができる。

また、コネクション数取得部３１１は、既に確立されているＴＣＰコネクションの数を、通信装置１０１とサーバ１０２との通信に使用可能なＴＣＰコネクション数として取得する事ができる。また、後述するステップＳ４１５からステップＳ４０２に進んだ場合（ステップＳ４０２の処理が繰り返された場合）、コネクション数取得部３１１は、過去にステップＳ４０２で取得したＴＣＰコネクション数を使用しても良い。

コネクション数取得部３１１は、以上のようにして通信装置１０１とサーバ１０２との通信に使用可能なＴＣＰコネクション数を取得できなかった場合、デフォルト値を使用する事ができる。また、この場合、通信装置１０１は、エラーとしてサーバ１０２との通信を終了しても良い。このとき、表示制御部３０２は、エラーであることを表示装置２０６に表示させる事ができる。

次に、リクエスト数取得部３０６は、ＨＴＴＰリクエスト数を取得する（ステップＳ４０３）。
ＨＴＴＰリクエスト数を取得する方法の例を以下に説明する。
リクエスト数取得部３０６は、ＨＴＴＰリクエスト数として、例えば、通信装置１０１がサーバ１０２へアップロードするファイル数や、通信装置１０１がサーバ１０２からダウンロードするファイル数を、ＨＴＴＰリクエスト数として取得する事ができる。

また、例えば、ポーリング（polling）のために通信装置１０１がサーバ１０２に定期的にリクエストを送信する場合がある。このような場合であって、定期的に送信されるリクエストの数が固定である場合、リクエスト数取得部３０６は、その値をＨＴＴＰリクエスト数として取得する事ができる。
また、通信装置１０１は、全てのリクエストに対するレスポンスを受信する前に、追加のリクエストをサーバ１０２に送信する事が必要になる場合がある。具体的には、Ｗｅｂページのダウンロードを行う場合や、ＳＯＡＰ等の通信プロトコルを使用する場合に、全てのリクエストに対するレスポンスを受信する前に、追加のリクエストをサーバ１０２に送信する事が必要になる。このような場合、リクエスト数取得部３０６は、追加のリクエストを想定して、ＨＴＴＰリクエスト数を設定する事ができる。

また、リクエスト数取得部３０６は、接続相手のサーバ１０２のアドレス、ポート番号、およびＵＲＬ等の情報をもとに、サーバ１０２によるサービスを特定し、特定したサービスに応じたリクエスト数をＨＴＴＰリクエスト数として取得する事ができる。
また、通信装置１０１とサーバ１０２との接続履歴がある場合、リクエスト数取得部３０６は、過去の接続履歴から、サーバ１０２の識別子に対応するリクエスト数を取得する事ができる（図５を参照）。

また、リクエスト数取得部３０６は、リクエスト数取得部３０６が過去に取得した値をＨＴＴＰリクエスト数として取得する事ができる。
また、リクエスト数取得部３０６は、以上のようにしてＨＴＴＰリクエスト数を取得できなかった場合、デフォルト値を使用する事ができる。また、この場合、通信装置１０１は、エラーとしてサーバ１０２との通信を終了しても良い。このとき、表示制御部３０２は、エラーであることを表示装置２０６に表示させる事ができる。

本実施形態では、コネクション数取得部３１１がＴＣＰコネクション数を取得した後に、リクエスト数取得部３０６がＨＴＴＰリクエスト数を取得する場合を例に挙げて説明する。しかしながら、ＴＣＰコネクション数とＨＴＴＰリクエスト数の取得の順番は、この順番に限定されない。

比較部３０４は、リクエスト数取得部３０６で取得されたＨＴＴＰリクエスト数が、コネクション数取得部３１１で取得されたＴＣＰコネクション数を上回るか否かを判定する（ステップＳ４０４）。この判定の結果、ＨＴＴＰリクエスト数がＴＣＰコネクション数以下の場合、ＨＴＴＰ／２よりもＨＴＴＰ／１．１を選択した方が、リクエストに対する通信の完了までの時間が短くなりやすいので、ステップＳ４０５に進む。すなわち、ＨＴＴＰリクエスト数がＴＣＰコネクション数以下の場合、すべてのＨＴＴＰリクエストを略同時に送信することができる一方、ＨＴＴＰ／１．１からＨＴＴＰ／２へのプロトコルのアップグレード処理が不要となる。従って、比較部３０４は、ＨＴＴＰリクエスト数がＴＣＰコネクション数以下の場合、ＨＴＴＰ／１．１を用いたほうが、ＨＴＴＰ／２を用いるよりも、リクエストに対する通信の完了までの時間が短くなりやすいと判定する。

一方、ＨＴＴＰリクエスト数がＴＣＰコネクション数を上回る場合、ＨＴＴＰ／１．１よりもＨＴＴＰ／２を選択した方が、リクエストに対する通信の完了までの時間が短くなりやすいので、ステップＳ４１０に進む。すなわち、ＨＴＴＰリクエスト数がＴＣＰコネクション数以下の場合、すべてのＨＴＴＰリクエストを略同時に送信することはできない。従って、比較部３０４は、ＨＴＴＰ／１．１からＨＴＴＰ／２へのプロトコルアップグレード処理を行う時間を考慮しても、ＨＴＴＰ／２を用いたほうが、ＨＴＴＰ／１．１を用いるよりも、リクエストに対する通信の完了までの時間が短くなりやすいと判定する。
前述したように、ＨＴＴＰリクエスト数とＴＣＰコネクション数の片方または両方を取得できなかった場合、比較部３０４は、デフォルト値を利用して比較を行う事ができる。また、通信装置１０１は、エラーとして通信を終了しても良い。

また、サーバ１０２がＨＴＴＰ／２に対応していない事が事前に分かる場合、ステップＳ４０４の判定を省略して、ステップＳ４０５に進んでも良い。比較部３０４は、サーバ１０２がＨＴＴＰ／２に対応してない事を、サーバ１０２の識別子を使用して接続履歴を参照することにより確認することができる（図５を参照）。また、比較部３０４は、サーバ１０２がＨＴＴＰ／２に対応してない事を示す情報を他の通信装置から取得することもできる。

また、サーバ１０２がＨＴＴＰ／１．１に対応していない事が事前に分かる場合、ステップＳ４０４の判定を省略して、ステップＳ４１０に進んでも良い。比較部３０４は、サーバ１０２がＨＴＴＰ／１．１に対応していない事を、サーバ１０２の識別子を使用して接続履歴を参照することにより確認する事ができる（図５を参照）。また、比較部３０４は、サーバ１０２がＨＴＴＰ／１．１に対応してない事を示す情報を他の通信装置から取得することもできる。

また、サーバ１０２がＨＴＴＰ／１．１とＨＴＴＰ／２の両方に対応していないことが事前に分かる場合、通信装置１０１は、サーバ１０２で使用できるその他の通信プロトコルを使用してサーバ１０２と通信しても良い。また、このような場合、通信装置１０１は、通信エラーとして通信を終了しても良い。

また、前述したように通信装置１０１がサーバ１０２に定期的にリクエストを送信する場合に、毎回のＨＴＴＰリクエスト数が固定であり、そのＨＴＴＰリクエスト数が、ＴＣＰコネクション数以下であることが予め分かるような場合がある。例えば、毎回のＨＴＴＰリクエスト数が「１」であるような場合がこのような場合に該当する。このような場合には、ステップＳ４０２およびステップＳ４０４の処理を省略して、ステップＳ４０５に進んでも良い。

ステップＳ４０４の判定の結果、ＨＴＴＰリクエスト数がＴＣＰコネクション数以下である場合、選択部３１２は、サーバ１０２との通信に使用する通信プロトコルとしてＨＴＴＰ／１．１を選択する（ステップＳ４０５）。
次に、第１接続部３１４は、サーバ１０２に対して、ＴＣＰコネクションの確立（ＴＣＰ接続）を行う（ステップＳ４０６）。このとき、第１接続部３１４は、ＨＴＴＰリクエスト数以上のＴＣＰコネクションを確立する。また、既にＨＴＴＰ／１．１のＴＣＰコネクションが確立されている場合、第１接続部３１４は、新たにＴＣＰコネクションを確立せずに、既に確立されているＨＴＴＰ／１．１のＴＣＰコネクションの一部または全部を利用しても良い。

ＴＣＰコネクションが確立した後、表示制御部３０２は、通信にＨＴＴＰ／１．１が使用されていることを示す情報を表示装置２０６（液晶ディスプレイやＬＥＤ）に表示させる。
次に、第１リクエスト送信部３０７は、第１接続部３１４により確立されたＴＣＰコネクションを使用し、ＨＴＴＰ／１．１のリクエストをサーバ１０２に送信する（ステップＳ４０７）。
次に、第１レスポンス受信部３０９は、第１リクエスト送信部３０７がサーバ１０２に対して送信したリクエストに対するレスポンスを受信する（ステップＳ４０８）。

次に、切断部３１６は、ＴＣＰコネクションを切断する（ステップＳ３２０）。切断部３１６は、レスポンスを受信し終えたＴＣＰコネクションから切断しても良いし、サーバ１０２から全てのレスポンスを受信してから全てのＴＣＰコネクションを切断しても良い。

サーバ１０２がPersistent Connectionに対応しているのであれば、切断部３１６は、ＴＣＰコネクションを再利用するために、ある一定時間（例えば１０分間）待ってから、ＴＣＰコネクションを切断しても良い。
以上のようにしてＴＣＰコネクションが切断されると、後述するステップＳ４１６に進む。

また、サーバ１０２がPersistent Connectionに対応していない場合であって、ＨＴＴＰ／１．１が選択された場合には、ＨＴＴＰリクエストを送信するたびにＴＣＰコネクションを切断する必要がある。このような状況で、ＨＴＴＰリクエストの送信を継続する場合には、ＨＴＴＰ／１．１を選択するよりもＨＴＴＰ／２を選択した方が通信完了までの時間を短縮できることがある。したがって、サーバ１０２がPersistent Connectionに対応していない場合には、ステップＳ４０４の判定を省略して、ステップＳ４１０に進んでも良い。かかる処理は、例えば、図５に示す接続履歴（履歴情報）に、サーバ１０２がPersistent Connectionに対応しているか否かを示す情報を含めることにより実現する事ができる。また、比較部３０４は、サーバ１０２がPersistent Connectionに対応しているか否かを示す情報を他の通信装置から取得する事もできる。

ステップＳ４０４の判定の結果、ＨＴＴＰリクエスト数がＴＣＰコネクション数を上回る場合、選択部３１２は、サーバ１０２との通信に使用する通信プロトコルとしてＨＴＴＰ／２を選択する（ステップＳ４１０）。
次に、第２接続部３１５は、サーバ１０２に対して、ＴＣＰコネクションの確立（ＴＣＰ接続）を行う（ステップＳ４１１）。

ここで、第２接続部３１５は、１本以上であれば、何本のＴＣＰコネクションを接続しても良い。
また、既にＨＴＴＰ／２のＴＣＰコネクションが確立されている場合、第２接続部３１５は、新たにＴＣＰコネクションを確立せずに、既に確立されているＨＴＴＰ／２のＴＣＰコネクションの一部または全部を利用しても良い。
ＴＣＰコネクションが確立した後、表示制御部３０２は、通信にＨＴＴＰ／２が使用されていることを示す情報を表示装置２０６（液晶ディスプレイやＬＥＤ）に表示させる。

次に、判断部３０５は、サーバ１０２とＨＴＴＰ／２で通信を行う場合に、プロトコルアップグレードを省略することが可能であるか否かを判断する（ステップＳ４１２）。ＨＴＴＰ／２で通信を行う場合であって、通信相手のサーバ１０２がＨＴＴＰ／２に対応している事が事前に明らかな場合には、プロトコルアップグレードを省略する事ができる。

判断部３０５は、サーバ１０２がＨＴＴＰ／２に対応しているか否かを、サーバ１０２の識別子を使用して、接続履歴を参照することにより確認する事ができる。また、判断部３０５は、ＮＦＣやＢｌｕｅｔｏｏｔｈ（登録商標）等を用いて、サーバ１０２がＨＴＴＰ／２に対応しているか否かを示す情報をサーバ１０２から直接取得する事もできる。また、判断部３０５は、サーバ１０２がＨＴＴＰ／２に対応しているか否かを示す情報を他の通信装置から取得する事もできる。サーバ１０２がＨＴＴＰ／２に対応しているかを判断する手段はこれらに限らない。

また、ステップＳ４１２において、判断部３０５は、既に確立されているＨＴＴＰ／２のＴＣＰコネクションがある場合、そのＴＣＰコネクションを使用して通信できるため、プロトコルアップグレードを省略することが可能であると判断する事ができる。

以上の判断の結果、プロトコルアップグレードを省略することが可能ではない場合、プロトコルアップグレード部３１７は、プロトコルアップグレードを行う（ステップＳ４１３）。プロトコルアップグレード部３１７は、通信プロトコルのアップグレードに、HTTP Upgradeメカニズムを使用することができる。また、プロトコルアップグレード部３１７は、通信プロトコルのアップグレードに、TLS ALPN（Application Layer Protocol Negotiation Extension）を使用する事もできる。

プロトコルアップグレードに成功した後、あるいはプロトコルアップグレードを省略した後に、第２リクエスト送信部３０８はＨＴＴＰ／２のリクエストをサーバ１０２に送信する（ステップＳ４１４）。
次に、第２レスポンス受信部３１０は、第２リクエスト送信部３０８がサーバ１０２に対して送信したリクエストに対するレスポンスを受信する（ステップＳ４１５）。そして、ステップＳ４１６に進む。

ステップＳ４１６に進むと、判断部３０５は、ＨＴＴＰリクエストの送信を継続するか否かを判断する。ＨＴＴＰリクエストの送信を継続する場合として、定期的にＨＴＴＰリクエストを送信する場合や、ＨＴＴＰレスポンスを受信した結果に対して新たなＨＴＴＰリクエストを送信する場合や、ユーザの操作により新たなＨＴＴＰリクエストを送信する場合等がある。
判断部３０５は、リクエストの送信を継続するか否かを、第１レスポンス受信部３０９または第２レスポンス受信部３１０が、全てのレスポンスを受信する前に判断しても良いし、全てのレスポンスを受信してから判断しても良い。

ＨＴＴＰリクエストの送信を継続する場合には、ステップＳ４０２に戻り、ＨＴＴＰリクエストの送信を終了するまで、ステップＳ４０２〜Ｓ４１６の処理が繰り返し実行される。
そして、判断部３０５によりＨＴＴＰリクエストの送信を継続しないと判断されると、切断部３１６は、ＴＣＰコネクションを切断する（ステップＳ４１７）。切断部３１６は、レスポンスを受信し終えたＴＣＰコネクションから切断しても良いし、サーバ１０２から全てのレスポンスを受信してから全てのＴＣＰコネクションを切断しても良い。また、ＴＣＰコネクションを再利用するために、切断部３１６は、ある一定時間（例えば１０分間）待ってから、ＴＣＰコネクションを切断しても良い。

ＨＴＴＰリクエストの送信を継続する場合には、既にＨＴＴＰ／２のＴＣＰコネクションが確立されている場合が考えられる。例えば、ステップＳ４１５からステップＳ４０２に進んだ場合が該当する。このような場合には、既に確立されているＴＣＰコネクションを使用して通信できるため、プロトコルアップグレードを省略することが可能である。このような状況では、ＨＴＴＰ／１．１を選択するよりもＨＴＴＰ／２を選択した方が、通信完了までの時間を短縮できることがある。したがって、既にＨＴＴＰ／２のＴＣＰコネクションが確立されている場合には、ステップＳ４０４の判定を省略して、ステップＳ４１０に進んでも良い。

図４のフローチャートでは、第１接続部３１４が、ステップＳ４０３で取得されたＨＴＴＰリクエスト数以上の数のＴＣＰコネクションの確立に成功する事を前提とする場合を例に挙げて示す。しかしながら、ＨＴＴＰリクエスト数以上の数のＴＣＰコネクションをサーバ１０２との間で確立することに失敗する場合も考えられる。このような場合として、例えば、サーバ１０２が他の通信装置ともＴＣＰコネクションで接続しているため、通信装置１０１からの接続を受け入れられない場合がある。この他、通信装置１０１が使用できるＴＣＰコネクション数が、他のアプリケーションの影響により変化する場合等においても、ＨＴＴＰリクエスト数以上の数のＴＣＰコネクションをサーバ１０２との間で確立することに失敗する場合がある。

図６は、ステップＳ４０３で取得されたＨＴＴＰリクエスト数以上のＴＣＰコネクションを確立することができないことを想定した場合の通信プロトコルの選択の方法の一例を説明するフローチャートである。図６のフローチャートは、例えば、図４のステップＳ４０６とステップＳ４０７との間で行われる。

比較部３０４は、第１接続部３１４により確立されたＴＣＰコネクション数（すなわち、サーバ１０２との接続に成功したＴＣＰコネクション数）が、ステップＳ４０３で取得されたＨＴＴＰリクエスト数以上であるか否かを判定する（ステップＳ６０１）。
この判定の結果、第１接続部３１４により確立されたＴＣＰコネクション数が、ＨＴＴＰリクエスト数以上である場合、第１リクエスト送信部３０７は、ＨＴＴＰ／１．１のリクエストをサーバ１０２に送信する。この場合、図６のフローチャートの終了後に、図４のステップＳ４０７に進む。

一方、第１接続部３１４により確立されたＴＣＰコネクション数が、ＨＴＴＰリクエスト数を下回る場合、選択部３１２は、サーバ１０２との通信に使用する通信プロトコルとしてＨＴＴＰ／２を選択する（ステップＳ６０２）。この場合、図６のフローチャート終了後に、図４のステップＳ４１１に進む。

また、図４のフローチャートでは、サーバ１０２がＨＴＴＰ／２に対応し、プロトコルアップグレードに成功する事を前提とする場合を例に挙げて示す。しかしながら、サーバ１０２がＨＴＴＰ／２に対応していない場合も考えられる。プロトコルアップグレードを行った結果、サーバ１０２がＨＴＴＰ／２に対応していない事が分かった場合、ＨＴＴＰ／１．１を選択する必要がある。

図７は、サーバ１０２がＨＴＴＰ／２に対応していないことを想定した場合の通信プロトコルの選択の方法の一例を説明するフローチャートである。図７のフローチャートは、例えば、図４のステップＳ４１３の処理の代わりに行われる。
プロトコルアップグレード部３１７は、プロトコルアップグレードを行う（ステップＳ７０１）。ステップＳ７０１の処理は、図４のステップＳ４１３の処理と同じである。
次に、プロトコルアップグレード部３１７は、プロトコルアップグレードに成功したか否かを判定する（ステップＳ７０２）。

この判定の結果、プロトコルアップグレードに成功した場合、ＨＴＴＰ／２で通信を行うことができる。この場合、図７のフローチャートの終了後に、図４のステップＳ４１４に進む。
一方、プロトコルアップグレードに失敗した場合、ＨＴＴＰ／２で通信を行う事ができないので、選択部３１２は、サーバ１０２との通信に使用する通信プロトコルとしてＨＴＴＰ／１．１を選択する。この場合、図７のフローチャートの終了後に、図４のステップＳ４０６に進む。

図８は、ＨＴＴＰ／１．１を用いて通信を行う場合の通信システムにおけるシーケンスの一例を示す図である。
ここでは、コネクション数取得部３１１が取得するＴＣＰコネクション数は「２」であり、リクエスト数取得部３０６が取得するＨＴＴＰリクエスト数は「２」であるものとする。この場合、図４のステップＳ４０４において、ＨＴＴＰリクエスト数がＴＣＰコネクション数以下である（Ｎｏ）と判定され、選択部３１２は、ＨＴＴＰ／１．１を選択する（ステップＳ４０５）。また、ここでは、ステップＳ４１６において、リクエストの送信を継続しない（Ｎｏ）と判定されるものとする。

ステップＳ８０１において、コネクション数取得部３１１は、ＴＣＰコネクション数を取得する。ここでは、ＴＣＰコネクション数として「２」が取得される。
次に、ステップＳ８０２において、リクエスト数取得部３０６は、ＨＴＴＰリクエスト数を取得する。ここでは、ＨＴＴＰリクエスト数として「２」が取得される。
次に、ステップＳ８０３において、選択部３１２は、サーバ１０２との通信に使用する通信プロトコルとしてＨＴＴＰ／１．１を選択する。

次に、ステップＳ８０４において、第１接続部３１４は、通信装置１０１とサーバ１０２との間に１本目のＴＣＰコネクションを確立する。
次に、ステップＳ８０５において、第１接続部３１４は、通信装置１０１とサーバ１０２との間に２本目のＴＣＰコネクションを確立する。

次に、ステップＳ８０６において、第１リクエスト送信部３０７は、１つ目のＴＣＰコネクションを利用して、１つ目のＨＴＴＰリクエストを送信する。
次に、ステップＳ８０７において、第１リクエスト送信部３０７は、２つ目のコネクションを利用して、２つ目のＨＴＴＰリクエストを送信する。

次に、ステップＳ８０８において、第１レスポンス受信部３０９は、１つ目のＨＴＴＰリクエストに対するＨＴＴＰレスポンスを受信する。
次に、ステップＳ８０９において、第１レスポンス受信部３０９は、２つ目のＨＴＴＰリクエストに対するＨＴＴＰレスポンスを受信する。

次に、ステップＳ８１０において、切断部３１６は、１本目のＴＣＰコネクションを切断する。
最後に、ステップＳ８１１において、切断部３１６は、２本目のＴＣＰコネクションを切断する。

図９は、ＨＴＴＰ／２を用いて通信を行う場合の通信システムにおけるシーケンスの一例を示す図である。
ここでは、コネクション数取得部３１１が取得するコネクション数は「２」であり、リクエスト数取得部３０６が取得するリクエスト数は「３」であるものとする。この場合、図４のステップＳ４０４において、ＨＴＴＰリクエスト数がＴＣＰコネクション数を上回る（Ｙｅｓ）と判定され、選択部３１２は、ＨＴＴＰ／２を選択する（ステップＳ４１０）。また、ここでは、ステップＳ４１６において、リクエストの送信を継続しない（Ｎｏ）と判定されるものとする。

ステップＳ９０１、Ｓ９０２は、それぞれ、図８のステップＳ８０１、Ｓ８０２と同じである。
ステップＳ９０３において、選択部３１２は、サーバ１０２との通信に使用する通信プロトコルとしてＨＴＴＰ／２を選択する。

次に、ステップＳ９０４において、第２接続部３１５は、通信装置１０１とサーバ１０２との間に１本のＴＣＰコネクションを確立する。
次に、ステップＳ９０５において、通信装置１０１は、プロトコルアップグレードを行う。
次に、ステップＳ９０６において、第２リクエスト送信部３０８は、ＨＴＴＰ／２のリクエストを送信する。
次に、ステップＳ９０７において、第２レスポンス受信部３１０は、ＨＴＴＰ／２のレスポンスを受信する。
最後に、ステップＳ９０８において、切断部３１６は、ＴＣＰのコネクションを切断する。

図１０は、ＨＴＴＰリクエストの送信を継続する場合の通信システムにおけるシーケンスの一例を示す図である。
ここでは、コネクション数取得部３１１が１回目に取得するコネクション数は「２」であり、リクエスト数取得部３０６が１回目に取得するＨＴＴＰリクエスト数は「２」であるものとする。この場合、図４のステップＳ４０４において、ＨＴＴＰリクエスト数がＴＣＰコネクション数以下である（Ｎｏ）と判定され、選択部３１２は、ＨＴＴＰ／１．１を選択する（ステップＳ４０５）。また、ここでは、ステップＳ４１６において、リクエストの送信を継続する（Ｙｅｓ）と判定されるものとする。

その後、コネクション数取得部３１１が２回目に取得するコネクション数は「２」であり、リクエスト数取得部３０６が２回目に取得するＨＴＴＰリクエスト数は「３」であるものとする。この場合、図４のステップＳ４０４において、ＨＴＴＰリクエスト数がＴＣＰコネクション数を上回る（Ｙｅｓ）と判定され、選択部３１２は、ＨＴＴＰ／２を選択する（ステップＳ４１０）。また、ここでは、ステップＳ４１６において、リクエストの送信を継続しない（Ｎｏ）と判定されるものとする。

ステップＳ１００１〜Ｓ１００９は、それぞれ図８のステップＳ８０１〜Ｓ８０９と同じである。
また、ステップＳ１０１０〜Ｓ１０１６は、それぞれ図９のステップＳ９０１〜Ｓ９１７と同じである。

ステップＳ１０１７において、切断部３１６は、通信装置１０１とサーバ１０２のＴＣＰコネクション１を切断する。
次に、ステップＳ１０１８において、切断部３１６は、通信装置１０１とサーバ１０２のＴＣＰコネクション２を切断する。
最後に、ステップＳ１０１９において、切断部３１６は、通信装置１０１とサーバ１０２のＴＣＰコネクション３を切断する。

以上のように本実施形態では、サーバ１０２に対するＨＴＴＰリクエスト数が、通信装置１０１とサーバ１０２との通信に使用可能なＴＣＰコネクション数を上回る場合に、ＨＴＴＰ／１．１を使用し、そうでない場合にＨＴＴＰ／２を使用する。これにより、通信完了までの時間が短くなる可能性の高い通信プロトコルを容易に且つ短時間に選択できる。これにより、ユーザの待ち時間を短縮する事が可能となり、通信システムにおけるユーザビリティを向上させることができる。

尚、前述した実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱する事なく、様々な形で実施する事ができる。

（その他の実施例）
本発明は、以下の処理を実行する事によっても実現される。即ち、まず、以上の実施形態の機能を実現するソフトウェア（コンピュータプログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給する。そして、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）が当該コンピュータプログラムを読み出して実行する。

１００：ネットワーク、１０１：通信装置、１０２：サーバ

Claims (13)

1. 通信装置であって、
   他の通信装置との通信のために、前記他の通信装置に対して連続的に送信されるＨＴＴＰリクエストの数を特定する特定手段と、
   前記特定手段により特定された前記ＨＴＴＰリクエストの数に基づいて、１つのコネクションにおいて連続的に複数のＨＴＴＰリクエストを送信することが許容されない第１通信プロトコルと、１つのコネクションにおいて連続的に複数のＨＴＴＰリクエストを送信することが許容される第２通信プロトコルとを含む複数の通信プロトコルから、前記他の通信装置との通信に使用する通信プロトコルを選択する選択手段と、を有することを特徴とする通信装置。
2. 前記他の通信装置との通信に使用可能なコネクションの数に関する情報を取得する取得手段を有し、
   前記選択手段は、前記特定手段により特定された前記ＨＴＴＰリクエストの数と、前記取得手段により取得された情報に基づく前記コネクションの数との比較の結果に基づいて、前記複数の通信プロトコルから前記他の通信装置との通信に使用する通信プロトコルを選択することを特徴とする請求項１に記載の通信装置。
3. 前記選択手段は、前記特定手段により特定された前記ＨＴＴＰリクエストの数が所定の閾値未満である場合、前記第１通信プロトコルを選択し、前記特定手段により特定された前記ＨＴＴＰリクエストの数が前記所定の閾値以上である場合、前記第２通信プロトコルを選択することを特徴とする請求項１に記載の通信装置。
4. 前記第１通信プロトコルは、ＨＴＴＰ（Hyper Text Transfer Protocol）／１．１であることを特徴とする請求項１〜３の何れか１項に記載の通信装置。
5. 前記他の通信装置との過去の通信の結果に基づいて、当該他の通信装置との通信に使用可能なコネクションの数を記憶する第１記憶手段を有し、
   前記取得手段は、前記第１記憶手段により記憶されている、前記他の通信装置との通信に使用可能なコネクションの数に関する情報を取得することを特徴とする請求項２に記載の通信装置。
6. 前記第２通信プロトコルは、１つのコネクションに基づいて複数のストリームを構築することにより前記他の通信装置に対して連続的に複数のＨＴＴＰリクエストを送信することが可能な通信プロトコルであることを特徴とする請求項１〜５の何れか１項に記載の通信装置。
7. 前記第２通信プロトコルは、ＨＴＴＰ（Hyper Text Transfer Protocol）／２、ＳＰＤＹ、またはＱＵＩＣ（Quick UDP Internet Connections）であることを特徴とする請求項１〜６の何れか１項に記載の通信装置。
8. 他の通信装置との通信の結果に基づいて、当該他の通信装置が前記第２通信プロトコルを使用できるか否かを示す情報を記憶する第２記憶手段と、
   他の通信装置で使用される通信プロトコルを前記第２通信プロトコルにアップグレードするために前記ＨＴＴＰリクエストの送信の前に当該他の通信装置との通信を行うプロトコルアップグレード手段と、を有し、
   前記第２通信プロトコルを使用できることを示す情報が前記第２記憶手段により記憶されている他の通信装置に対しては、前記プロトコルアップグレード手段による前記通信の少なくとも一部を省略することを特徴とする請求項１〜７の何れか１項に記載の通信装置。
9. 前記選択手段により選択された通信プロトコルを示す情報を出力する出力手段を有することを特徴とする請求項１〜８の何れか１項に記載の通信装置。
10. 前記選択手段により選択された通信プロトコルを用いて前記他の通信装置と通信を行う通信手段を有することを特徴とする請求項１〜９の何れか１項に記載の通信装置。
11. 前記特定手段は、前記他の通信装置からのＨＴＴＰレスポンスを待たずに前記他の通信装置へ送信可能なＨＴＴＰリクエストの数を、前記連続的に送信されるＨＴＴＰリクエストの数として特定することを特徴とする請求項１〜１０の何れか１項に記載の通信装置。
12. 通信装置が行う通信方法であって、
    他の通信装置との通信のために、前記他の通信装置に対して連続的に送信されるＨＴＴＰリクエストの数を特定する特定工程と、
    前記特定工程により特定された前記ＨＴＴＰリクエストの数に基づいて、１つのコネクションにおいて連続的に複数のＨＴＴＰリクエストを送信することが許容されない第１通信プロトコルと、１つのコネクションにおいて連続的に複数のＨＴＴＰリクエストを送信することが許容される第２通信プロトコルとを含む複数の通信プロトコルから、前記他の通信装置との通信に使用する通信プロトコルを選択する選択工程と、を有することを特徴とする通信方法。
13. 請求項１〜１１の何れか１項に記載の通信装置の各手段としてコンピュータを機能させることを特徴とするプログラム。

Images