JP2016019156A - 通信装置およびその制御方法 - Google Patents

Abstract

【課題】ＴＣＰ通信のスループットを改善する適切な通信制御を行う。
【解決手段】通信装置は、外部通信装置との間でＴＣＰコネクションを確立して通信する通信手段と、ＴＣＰコネクションを確立する際に、外部通信装置から当該外部通信装置の機器情報を受信する受信手段と、受信した外部通信装置の機器情報に基づいて、ＴＣＰコネクションの再送タイムアウト（ＲＴＯ）タイマー値を変更するよう制御する制御手段と、を有する。
【選択図】図４

Description

本発明は、ＴＣＰ通信のスループットを改善する技術に関するものである。

インターネット通信において輻輳制御を行うプロトコルとしてＴＣＰ（Transmission Control Protocol）が広く知られている。ＴＣＰはＲＦＣ７９３、ＲＦＣ１１２２、ＲＦＣ２５８１、ＲＦＣ２５８２等の文書に記載されており、その改良のための研究が続けられている。ところで、ＴＣＰは誤り制御にＡＲＱ（自動再送要求）方式を採用している。ＡＲＱ方式では送信側から受信側へデータパケットが送信され、これを受信した受信側から送信側へＡＣＫ（肯定応答）パケットが返送される。ＡＣＫパケットが返送されないデータパケットがあった場合には、送信側からデータパケットが再送される。また、送信側はスループットを大きくするため、一定サイズ以内の複数のパケットをまとめて送信しようとする。このような制御は、スライディングウィンドウ方式のフロー制御と呼ばれている。さらに、この制御は、ネットワーク上の輻輳を回避するため、徐々にスループットを上げるように設計されている。

また、近年、移動体通信端末は高速な通信方式を持つものが多くなってきている。一方で省電力化も進んでおり、高速な通信を行える機能がありながら、省電力化の影響により通信遅延のゆらぎや、突発的な遅延が発生しやすくなっている。突発的な遅延が発生すると、ＡＣＫパケットを受信する時間が遅れるために、送信側はデータパケットを再送してしまう。また、送信側はデータパケットの再送を行った段階で、ネットワーク上で輻輳が発生していると判断し、スループットを落とす方向に制御を行ためスループットは低下してしまう。このような無線環境下における突発的な遅延の発生の対策として、例えば、特許文献１には、ネットワーク特性情報に基づき時間的な変動の有無を判定し輻輳制御変数の値を制御する技術が開示されている。

特開２００６−５８３３号公報

しかしながら、特許文献１に示されるようなネットワーク特性情報に基づく時間的な変動の有無の判定だけでは適切な通信制御を行うことができない。例えば、上述のような、通信端末の省電力特性情報や通信端末のＯＳ（オペレーティングシステム）に関する制御情報は利用することができない。

本発明は上述の問題点に鑑みなされたものであり、ＴＣＰ通信のスループットを改善する適切な通信制御を行うことのできる技術を提供することを目的としている。

上述の問題点を解決するため、本発明に係る通信装置は以下の構成を備える。すなわち、通信装置は、外部通信装置との間でＴＣＰコネクションを確立して通信する通信手段と、前記ＴＣＰコネクションを確立する際に、前記外部通信装置から該外部通信装置の機器情報を受信する受信手段と、前記受信した前記外部通信装置の機器情報に基づいて、前記ＴＣＰコネクションの再送タイムアウト（ＲＴＯ）タイマー値を変更するよう制御する制御手段と、を有する。

本発明によれば、ＴＣＰ通信のスループットを改善する適切な通信制御を行うことのできる技術を提供することができる。

第１実施形態に係る通信装置であるサーバ装置を含む通信システムの構成を説明する図である。 サーバ装置及びクライアント装置のハードウェア構成を示す図である。 サーバ装置のソフトウェア構成を示す図である。 ＨＴＴＰリクエスト解析処理のフローチャートである。 ＲＴＯタイマー算出処理のフローチャートである。 Ｓｙｎパケット解析処理のフローチャートである。 ＨＴＴＰセッション数を考慮したＨＴＴＰリクエスト解析処理のフローチャートである。 ＨＴＴＰセッション数を考慮したＲＴＯタイマー算出処理のフローチャートである。 ＲＴＯ加算係数テーブルの一例を示す図である。 ＨＴＴＰセッション数による減衰係数テーブルの一例を示す図である。

以下に、図面を参照して、この発明の好適な実施の形態を詳しく説明する。なお、以下の実施の形態はあくまで例示であり、本発明の範囲を限定する趣旨のものではない。

（第１実施形態）
本発明に係る通信装置の第１実施形態として、Ｗｅｂサービスを提供するサーバ装置１０１を例に挙げて以下に説明する。

＜用語＞
まず、以下の実施形態の説明で用いる用語について説明する。
ＴＣＰ（Transmission Control Protocol）：ファイルの送受信のような信頼性を要求する通信に一般的に利用されるプロトコル
ＨＴＴＰ（Hypertext Transfer Protocol）：Ｗｅｂクライアント装置とＷｅｂサーバ装置の間で各種コンテンツの送受信に用いられるプロトコル（ＲＦＣ１９４５、ＲＦＣ２０６８、ＲＦＣ２６１６）
ソケット：ＴＣＰレイヤ上の通信路を識別、分類するための表記（ＩＰアドレスとＴＣＰポート番号の組のことを指す。）
ＴＣＰコネクション：ＴＣＰレイヤにおけるひとつの通信路（受信側ソケットと送信側ソケットの組のことを指す。）
受信ウィンドウサイズ：ＴＣＰプロトコルにおける、受信用のバッファ領域のサイズ（ＴＣＰは残り受信ウィンドウサイズを送信側に通知することにより、バッファ溢れを防ぐことが出来る。）
輻輳ウィンドウサイズ：ＴＣＰプロトコルにおける、送信用のバッファ領域のサイズ（ＴＣＰは輻輳ウィンドウサイズを徐々に大きくすることにより、通信速度の向上を試みる。一方で輻輳ウィンドウサイズを単に大きくすると、通信路の輻輳に繋がるため、これらウィンドウサイズの制御を行う輻輳回避アルゴリズムが必要である。ＴＣＰに実装される輻輳回避アルゴリズムには、Ｔａｈｏｅ、Ｒｅｎｏ等がある。）
ＲＴＯ（再送タイムアウト）：ＴＣＰにおいて受信側からＡＣＫパケットが返信されなかった場合、ネットワーク上で送信パケットが損失したとみなし、再送を行うこと
ＲＴＯタイマー：送信パケットが損失したと判定するまでの時間を測るタイマー（ＴＣＰでは一般的に「Ａ＋４Ｄ」で計算されている。ここで、「Ａ」はＲＴＴ（Round Trip Time）の指数移動平均、「Ｄ」はＲＴＴの平均偏差の指数移動平均を指す。この「４Ｄ」の項により、急な遅延の変化に対応出来る、とされている。）
ＩＥＥＥ８０２．１１：ＩＥＥＥ（The Insitute of Electrical and Electronics Engineers）で策定されている無線ＬＡＮに関する標準規格

＜装置構成＞
図１は、第１実施形態に係る通信装置であるサーバ装置１０１を含む通信システムの構成を説明する図である。

サーバ装置１０１は、Ｗｅｂサービスを提供する通信装置である。Ｗｅｂサービスでは一般的に、このＨＴＴＰを使用して通信を行う。サーバ装置１０１は、図１においては１台のサーバ装置１０１として示されているが複数台のサーバ装置で構成されていても構わない。また、仮想ＰＣとして構成されていても構わない。また、外部通信装置であるクライアント装置１０３は、無線ルータ１０２を介してサーバ装置１０１にアクセスしＷｅｂサービスを利用する通信装置である。

インターネット１００は、ファイアウォールを越えて上述の各装置間で情報をやり取りするための通信回線ネットワークである。インターネット１００は、ＴＣＰ／ＩＰプロトコルをサポートしている。無線ルータ１０２はインターネット１００と接続されており、また、クライアント装置１０３と無線通信が可能に構成されている。

図２は、クライアント装置１０３やサーバ装置１０１を構成するコンピュータ２００のハードウェア構成を示す図である。

コンピュータ２００は、ＲＯＭ２０２あるいは外部記憶装置２０５に記憶されたオペレーションシステムあるいは各種のアプリケーションプログラムを実行するＣＰＵ２０１を備える。ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。

ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。通信制御部２０６は、ネットワークＩ／Ｆ３０６を介したＬＡＮ２０７とのデータの送受信を制御する。

図３は、サーバ装置１０１のソフトウェア構成を示す図である。なお、ＴＣＰレイヤまでの管理機構はＲＦＣ７９３を満たし、利用可能なＡＰＩが提供されていればどのような実装でも構わない。すなわち、以下で説明するＴＣＰ管理処理部３０４および下位レイヤ管理処理部３０５が適切なＡＰＩを提供していれば、その実装は問わない。ＴＣＰ管理処理部３０４および下位レイヤ管理処理部３０５は、多くの場合、オペレーティングシステムが提供することが一般的であるが、後述する管理機構を別個に実装していても構わない。

ダウンロード管理処理部３０２は、ＨＴＴＰ通信を用いた送受信処理を管理し、上位レイヤアプリケーション３０１へのインターフェースを提供する。また下位レイヤに対してのデータ送受信も管理する。ダウンロード管理処理部３０２は、ここでは１つのソフトウェアライブラリの形で記述するものとして説明する。しかし、オペレーティングシステムそのものに本機能を実装したり、ネットワークＩ／Ｆ３０６のハードウェアに実装しても構わない。すなわち、同等の機能及びインターフェースが上位レイヤアプリケーション３０１に提供できればよい。

ＴＣＰ管理処理部３０４は、ＴＣＰコネクションを管理する。具体的にはＴＣＰコネクションの接続、受付、送受信等を管理し、その結果を上位レイヤアプリケーション３０１に通知する。また、直接結果を上位レイヤアプリケーション３０１に通知するだけでなく、ＳＳＬ／ＴＬＳ管理処理部３０３のような中間レイヤに通知してもよい。なお、ＳＳＬ／ＴＬＳとは認証、暗号化、改ざん検出を行う、Ｗｅｂサービスで一般的に使用される技術である。

ネットワークＩ／Ｆ３０６は、外部ネットワークと通信するインタフェースである。ネットワークＩ／Ｆ３０６は、無線通信インタフェースであっても構わない。すなわち、無線アンテナやその制御のための装置を備えていても良い。

＜装置の動作＞
以下では、モバイル端末であるクライアント装置１０３がサーバ装置１０１を介して不図示の画像処理装置へ印刷を依頼する状況を考える。つまり、サーバ装置１０１は、モバイル端末であるクライアント装置１０３から受け取った画像を画像処理装置が理解できる画像データへと変換するＷｅｂサービスを提供している。以下の説明では、使用する通信プロトコルとしてＨＴＴＰを用いる。もちろん、同様の機能を持つ他のプロトコルや独自のものを用いても良い。

本発明の特徴を示すため、サーバ装置１０１の動作について詳細に説明する。なお、サーバ装置１０１は一般的なＨＴＴＰサーバ装置の機能を満たし、ＧＥＴコマンドとＨＥＡＤコマンドが使用可能に構成されているものとする。なお、以下の説明では、本発明と本質的に関係の少ない、ＨＴＴＰによるサーバ装置、クライアント装置間の基本的な処理については説明は省略する。

図４は、ＲＴＯ調整用ＨＴＴＰリクエスト解析処理のフローチャートである。ＲＴＯ調整用ＨＴＴＰリクエスト解析処理は、サーバ装置１０１がクライアント装置１０３からＨＴＴＰリクエストを受け取った際の処理である。なお、以下の説明はサーバ装置で実行される動作を示している。

Ｓ４０１では、ダウンロード管理処理部３０２は、クライアント装置１０３からＨＴＴＰリクエストを受信する。Ｓ４０２では、ダウンロード管理処理部３０２は、ＨＴＴＰリクエストに含まれるＨＴＴＰヘッダ内に、クライアント装置１０３のハードウェア情報、およびＯＳ情報が含まれるかどうかを確認する。

具体的には、クライアント装置１０３は、サーバ装置１０１に対してＴＣＰコネクションの接続を確立する。このとき、クライアント装置１０３は、ＨＴＴＰリクエストのヘッダ内にクライアント装置１０３の機器情報として「ハードウェア情報」や「ＯＳ情報」を含ませる。「ハードウェア情報」や「ＯＳ情報」と記述可能なヘッダとしてはいくつか考えられるが、ここでは一般的に使われているＵｓｅｒＡｇｅｎｔヘッダ内に記述するものとする。もちろんＨＴＴＰリクエスト内であればどのヘッダを用いても構わない。また、記述する情報をハードウェア情報やＯＳ情報だけに制限するものではない。すなわち、有線か無線の区別や、接続方式の種類、リンク速度の情報などのネットワーク特性情報を含めても構わない。

ここで、「ハードウェア情報」とは、クライアント装置１０３のベンダー名や商品名などの、ハードウェア構成の特定が可能な情報である。また、「ＯＳ情報」とは、クライアント装置１０３が利用しているＯＳの名前およびバージョン情報などソフトウェア構成を特定可能な情報である。なお、「ハードウェア情報」と「ＯＳ情報」に分けているのは、同一のハードウェア情報を有する機種であっても異なるＯＳが使用された場合、ＴＣＰ通信の挙動が異なるためである。

ダウンロード管理処理部３０２は、Ｓ４０２において、受信したＨＴＴＰリクエスト内にハードウェア情報およびＯＳ情報が含まれないと判定した場合、ＲＴＯ調整用ＨＴＴＰリクエスト解析処理を終了する。その場合、ダウンロード管理処理部３０２は、その後、一般的なＨＴＴＰのリクエスト処理を行う。通常はＨＴＴＰのリクエスト処理内にて上位レイヤアプリケーション３０１に、ＨＴＴＰリクエスト受信の通知が行われることになる。上位レイヤアプリケーション３０１による、レスポンス内容に関する処理はアプリケーションごとに異なるため説明は省略する。

一方、ダウンロード管理処理部３０２は、Ｓ４０２において、受信したＨＴＴＰリクエスト内にハードウェア情報およびＯＳ情報が含まれると判定した場合、ＲＴＯ加算係数算出処理（Ｓ４０３）に遷移する。

Ｓ４０３では、ダウンロード管理処理部３０２は、ＨＴＴＰリクエスト内に含まれるハードウェア情報やＯＳ情報から、無線環境下での突発的な遅延量を想定し、ＲＴＯ加算値を決定する。例えば、予め記憶されたＲＴＯ加算係数テーブルにて決定される加算係数に基づきＲＴＯ加算値を決定する。なお、以下の説明ではハードウェア情報とＯＳ情報の組み合わせのみで判定を行うが、他の情報を併せて用いてもよい。

図９は、ＲＴＯ加算係数テーブルの一例を示す図である。ここでは、ハードウェア情報とＯＳ情報の異なる組み合わせそれぞれに対して加算係数αが設定されている。ＲＴＯ加算係数テーブルを参照することによりＲＴＯ加算係数は導出される。しかし、最終的に各々のクライアント装置１０３にとって適切なＲＴＯ加算値を得られるのであれば、他の算出方法を使用しても良い。例えば、機種、ＯＳごとのスループットを測り、その統計を基にＲＴＯ加算値を算出する、といった動的な方法であっても良い。なお、ハードウェア情報とＯＳ情報の一方のみに対して加算係数αを関連付けたＲＴＯ加算係数テーブルを用いてもよい。

ここでは、ダウンロード管理処理部３０２は、図９のＲＴＯ加算係数テーブルからクライアント装置１０３との通信に対するＲＴＯ加算係数を算出する。図９に示されるように、ＲＴＯ加算係数テーブルは、ハードウェア情報とＯＳ情報の組み合わせに対してＲＴＯ加算係数を一意に指定するハッシュテーブルである。このＲＴＯ加算係数テーブルは、静的に設定されていても良いし、あとからサーバ装置管理者が動的に設定可能に構成しても良い。また、「ハードウェア情報」及び「ＯＳ情報」両方を用いる代わりに、一方のみでＲＴＯ加算係数を算出するよう構成しても良い。

Ｓ４０４では、ダウンロード管理処理部３０２は、算出したＲＴＯ加算係数を、ＨＴＴＰセッションに結び付けられたＴＣＰコネクションのパラメータとしてセットする。

図５は、ＲＴＯタイマー算出処理のフローチャートである。ＲＴＯタイマー算出処理は、ＴＣＰ管理処理部３０４が実行するＲＴＯタイマー値の設定処理（変更処理）である。なお、以下の説明はサーバ装置で実行される動作を示している。

Ｓ５０１では、ＴＣＰ管理処理部３０４は、ＴＣＰコネクションに対してＲＴＯ加算係数がセットされているか確認する。ＲＴＯ加算係数がセットされていなければＳ５０２に進み、セットされていればＳ５０３に進む。

Ｓ５０２では、ＴＣＰ管理処理部３０４は、ＲＴＯタイマーに通常のタイムアウト値をセットする。すなわち、一般的なＴＣＰのＲＴＯタイマーのタイムアウト値を算出する。実際の算出値はＯＳによって異なる場合があるが、一般的にはＡ＋４Ｄがセットされる。

Ｓ５０３では、ＴＣＰ管理処理部３０４は、ダウンロード管理処理部３０２が設定したＲＴＯ加算係数を考慮したタイムアウト値を算出する。具体的には、タイムアウト値は実際のアプリケーションとネットワーク網等に依存した値になる。例として、ＲＴＯタイマー値の一般的な算出方法はＡ＋４Ｄであることをふまえ、Ａ＋４Ｄ（１＋α）と算出することができる。ここでαは算出したＲＴＯ加算係数である。このような算出を行うことで、クライアント装置１０３のハードウェア情報およびＯＳ情報に依存して、ＲＴＯタイマーを延長することができる。

もちろん、具体的な算出方法はこれに限定されず、例えばクライアント装置１０３の接続方式を基に、遅延が発生しやすいかどうかを判定に加えても良い。例えば、クライアント装置１０３が有線で接続されていると検出出来る場合には、突発的な遅延が発生しないと見なし、ＲＴＯタイマーの加算を行わないといった処理を加えても良い。

その後、ＴＣＰ管理処理部３０４はＲＴＯタイマー算出処理を終了する。上述の処理により、ＴＣＰ管理処理部３０４は、ＲＴＯタイマー算出処理でセットされたタイムアウト値を用いて再送制御を行うことになる。すなわち、通信相手であるクライアント装置１０３のハードウェア情報とＯＳ情報を考慮した再送制御を行うことになる。なお、ＲＴＯタイマー以外の具体的な再送制御については一般的なＴＣＰにおける再送制御と同等であるため説明は省略する。

なお、上述の説明ではＲＴＯタイマーのみを修正する形態について説明したが、同様の効果のある別のパラメータの修正を行っても構わない。例えば、輻輳回避アルゴリズム内で、輻輳回避の制御を修正しても良い。具体的には、輻輳回避アルゴリズムにおいて、ハードウェア情報とＯＳ情報に基づいて突発的な遅延が発生すると推定される場合、推定遅延時間を延長するといった修正を行っても良い。

以上説明したとおり第１実施形態によれば、通信相手のハードウェア情報とＯＳ情報を考慮して、ＲＴＯタイマー値を制御する。これにより、通信相手のハードウェア情報とＯＳ情報を考慮した再送制御を行うことが可能となり、ＴＣＰ通信のスループットを改善することが可能となる。

（第２実施形態）
第２実施形態では、ＴＣＰオプションを使用してハードウェア情報およびＯＳ情報を送信する形態について説明する。すなわち、ＨＴＴＰヘッダの代わりにＴＣＰオプションを使用する点が第１実施形態と異なる。なお、通信システムの構成やハードウェア構成は第１実施形態と同様であるため説明は省略する。

＜装置の動作＞
図６は、Ｓｙｎパケット解析処理のフローチャートである。具体的には、サーバ装置１０１がクライアント装置１０３からＴＣＰのＳｙｎパケットを受信した際の処理である。なお、以下の説明はサーバ装置で実行される動作を示している。なお、ＳｙｎパケットとはＴＣＰコネクションを確立する際に送信するパケットであり、ＴＣＰヘッダの制御フラグ内のＳｙｎフィールドがセットされたパケットのことを指す。

まず、クライアント装置１０３は、ＴＣＰヘッダのオプション領域にハードウェア情報およびＯＳ情報を含める（埋め込む）こととなる。この際、オプション番号を０から２５５の値で決定する必要があるが、ＩＡＮＡ（Internet Assigned Numbers Authority）により付番されていない番号を選択する。

Ｓ６０１では、ＴＣＰ管理処理部３０４は、クライアント装置１０３からＳｙｎパケットを受信する。なお、この時点でＩＰレイヤに関する情報、例えば送信元、送信先ＩＰアドレス等はすでに解析されているものとする。

Ｓ６０２では、ＴＣＰ管理処理部３０４は、Ｓｙｎパケット内にハードウェア情報およびＯＳ情報を含まれているかどうか判定する。含まれていない場合、ＲＴＯ調整用Ｓｙｎパケット解析処理を終了する。一方で、ハードウェア情報およびＯＳ情報が含まれている場合はＳ６０３に進む。

Ｓ６０３では、ＴＣＰ管理処理部３０４は、ＲＴＯタイマーの加算係数を算出する。この処理はＳ４０３と同等である。つまり、ＨＴＴＰレイヤ（ダウンロード管理処理部３０２）ではなくＴＣＰレイヤ（ＴＣＰ管理処理部３０４）で実行する点が第１実施形態と異なる。

Ｓ６０４では、ＴＣＰ管理処理部３０４は、算出したＲＴＯ加算係数を、ＴＣＰコネクションのパラメータとしてセットする。なお、実際のＲＴＯタイマー算出処理については第１実施形態（図５）と同様であるため説明は省略する。

以上説明したとおり第２実施形態によれば、第１実施形態と同様に通信相手のハードウェア情報とＯＳ情報を考慮してＲＴＯタイマー値を制御する。また、ハードウェア情報とＯＳ情報をＴＣＰのオプション領域内に含めることで、ＴＣＰレイヤのみでＲＴＯタイマーの設定を行うことができる。

（第３実施形態）
第３実施形態では、複数のＨＴＴＰセッションを複数利用するマルチＨＴＴＰセッション通信を利用する形態について説明する。すなわち、単一のＨＴＴＰセッションのかわりにマルチＨＴＴＰセッションを使用する点が第１実施形態と異なる。なお、通信システムの構成やハードウェア構成は第１実施形態と同様であるため説明は省略する。

マルチＨＴＴＰセッション通信とは、ひとつのコンテンツに対し、同時に複数のＨＴＴＰセッションを使用して、ダウンロードを行う通信方法である。この方法はＯＳによるＴＣＰの実装方法に関係なく、スループットの向上を期待できることから、一般的に広く使用されている。具体的には、クライアント装置１０３がＨＴＴＰリクエストにＲａｎｇｅヘッダを使用することでダウンロード対象のコンテンツを分割してダウンロードを行う。ＨＴＴＰセッション数に応じてＲａｎｇｅヘッダの範囲を決定し、それぞれのＨＴＴＰセッションがダウンロード量を分担することで実現する。

ＩＥＥＥ８０２．１１に基づいて無線通信を行う際、クライアント装置１０３は、必ずしも無線ルータ１０２の発信に応答する必要はない。これは省電力モードと呼ばれており、クライアント装置１０３の無線送受信デバイスに常に通電しなくても良いようにする工夫である。クライアント装置１０３と無線ルータ１０２の間で突発的な遅延が発生するのは、この省電力モードが大きく関わっていると考えられる。クライアント装置１０３は数百ミリ秒の間、無線ルータ１０２から受信を行わない場合、省電力モードに入ってしまい、復帰するまでにはさらに数百ミリ秒必要となる。

マルチＨＴＴＰセッション通信を行えば、ＴＣＰのフロー制御に大きく依存することなく、サーバ装置１０１と頻繁なパケットの送受信を行うことができる。頻繁な送受信によって、クライアント装置１０３は省電力モードに入りにくくなる。そのため、マルチＨＴＴＰセッション通信は、省電力化が行われている移動体端末においてもスループット向上の効果が期待できる。

一方で、ＲＴＯタイマー値を大きくすると、真のパケット損失の検出が遅延することになる。そのため、特に理由がなければ、出来るだけ小さくすべき値である。

＜装置の動作＞
図７は、ＨＴＴＰセッション数を考慮したＨＴＴＰリクエスト解析処理のフローチャートである。ＨＴＴＰリクエスト解析処理は、サーバ装置１０１がクライアント装置１０３からＨＴＴＰリクエストを受け取った際の処理である。なお、以下の説明はサーバ装置で実行される動作を示している。

Ｓ７０１では、ダウンロード管理処理部３０２は、クライアント装置１０３からＨＴＴＰリクエストを受信する。Ｓ７０２では、ダウンロード管理処理部３０２は、ＨＴＴＰリクエストに含まれるＨＴＴＰヘッダ内に、クライアント装置１０３のハードウェア情報、およびＯＳ情報が含まれるかどうかを確認する。

ダウンロード管理処理部３０２は、Ｓ７０２において、受信したＨＴＴＰリクエスト内にハードウェア情報およびＯＳ情報が含まれないと判定した場合、ＲＴＯ調整用ＨＴＴＰリクエスト解析処理を終了する。その場合、ダウンロード管理処理部３０２は、その後、一般的なＨＴＴＰのリクエスト処理を行う。

一方、ダウンロード管理処理部３０２は、Ｓ７０２において、受信したＨＴＴＰリクエスト内にハードウェア情報およびＯＳ情報が含まれると判定した場合、ＲＴＯ加算係数算出処理（Ｓ７０３）に遷移する。

Ｓ７０３では、ダウンロード管理処理部３０２は、ＨＴＴＰリクエスト内に含まれるハードウェア情報やＯＳ情報から、無線環境下での突発的な遅延量を想定し、ＲＴＯ加算値を決定する。Ｓ７０４では、ダウンロード管理処理部３０２は、算出したＲＴＯ加算係数を、ＨＴＴＰセッションに結び付けられたＴＣＰコネクションのパラメータとしてセットする。なお、Ｓ７０３、Ｓ７０４は、第１実施形態（Ｓ４０３，Ｓ４０４）と同様の処理であるため詳細な説明は省略する。

Ｓ７０５では、ダウンロード管理処理部３０２は、ＨＴＴＰリクエストがＨＴＴＰセッション数を含むかどうかを確認する。ここで、ＨＴＴＰセッション数はマルチＨＴＴＰセッション通信で使用されるＨＴＴＰセッションの数を示す。このＨＴＴＰセッション数はＨＴＴＰリクエスト内のどこかに記述されているものとする。ここではＨＴＴＰリクエストのＵｓｅｒＡｇｅｎｔヘッダに、ＨＴＴＰセッション数の情報を付与するものとする。もちろん、ＵｓｅｒＡｇｅｎｔヘッダ以外にも独自ヘッダ内に記述したり、ＨＴＴＰボディ部に記述しても良い。なお便宜上、マルチＨＴＴＰセッション通信を行わない場合、ＨＴＴＰセッション数として”１”が設定されるものとする。

ここで、ダウンロード管理処理部３０２は、ＨＴＴＰリクエスト内にＨＴＴＰセッション数の情報が含まれていない場合、ＲＴＯ調整用ＨＴＴＰリクエスト解析処理を終了する。一方で、ダウンロード管理処理部３０２は、ＨＴＴＰリクエスト内にＨＴＴＰセッション数の情報が含まれている場合はＳ７０６に進む。

Ｓ７０６では、ダウンロード管理処理部３０２は、取得したＨＴＴＰセッション数を、ＲＴＯ算出用ＨＴＴＰセッション数として該当するＴＣＰコネクションに設定する。設定後、ダウンロード管理処理部３０２は、ＲＴＯ調整用ＨＴＴＰリクエスト解析処理を終了する。

図８は、ＨＴＴＰセッション数を考慮したＲＴＯタイマー算出処理のフローチャートである。ＲＴＯタイマー算出処理は、ＴＣＰ管理処理部３０４が実行するＲＴＯタイマーの設定処理である。なお、以下の説明はサーバ装置で実行される動作を示している。

Ｓ８０１では、ＴＣＰ管理処理部３０４は、ＴＣＰコネクションにＲＴＯ加算係数が設定されているか確認する。ＲＴＯ加算係数がセットされていなければＳ８０２に進み、セットされていればＳ８０３に進む。

Ｓ８０２では、ＴＣＰ管理処理部３０４は、ＲＴＯタイマーに通常のタイムアウト値をセットする。その後、ＲＴＯタイマー算出処理を終了する。なお、通常のタイムアウト値の算出方法については第１実施形態（Ｓ５０２）と同様であるため説明は省略する。

Ｓ８０３では、ＴＣＰ管理処理部３０４は、ＲＴＯ算出用ＨＴＴＰセッションの数が２以上であるか否かを判定する。すなわちマルチＨＴＴＰセッション通信であるか否かを判定する。マルチＨＴＴＰセッション通信で無い場合はＳ８０４に進み、マルチＨＴＴＰセッション通信である場合はＳ８０５に進む。

Ｓ８０４では、ＴＣＰ管理処理部３０４は、ダウンロード管理処理部３０２が設定したＲＴＯ加算係数を考慮したタイムアウト値を算出する。なお、具体的な算出方法については第１実施形態（Ｓ５０３）と同様であるため説明は省略する。

Ｓ８０５では、ＴＣＰ管理処理部３０４は、ＲＴＯ加算係数と、ＲＴＯ算出用ＨＴＴＰセッション数考慮したタイムアウト値を算出する。上述の第１実施形態では、Ａ＋４Ｄ（１＋α）といった算出方法を示した。ここでは、更に、マルチＨＴＴＰセッション数に応じてタイムアウト値を制御する。すなわち、セッション数が多くなるほど、クライアント装置１０３が省電力機能を実現するための省電力モードに入らず、ＲＴＯタイマーのタイムアウト値の加算が必要ないと予想できるからである。

図１０は、ＨＴＴＰセッション数による減衰係数テーブルの一例を示す図である。ここでは、図１０のテーブルを用いることによって、ＲＴＯ算出用ＨＴＴＰセッション数から減衰係数βを求める。そして、ＴＣＰ管理処理部３０４はＡ＋４Ｄ（１＋αβ）といったタイムアウト値をＳ８０５でセットする。その結果、セッション数が増加するにつれて、ＲＴＯタイマーのタイムアウト値の加算を徐々に減らすことが出来る。ここでは、テーブルによる減衰係数βを求めたが、マルチＨＴＴＰセッション数が多くなるほど、最終的なＲＴＯタイマのタイムアウト値が通常の状態に近づくような構成であれば、どのような算出法でも構わない。

以上説明したとおり第３実施形態によれば、第１実施形態と同様に通信相手のハードウェア情報とＯＳ情報を考慮してＲＴＯタイマー値を制御する。また、マルチＨＴＴＰセッション数を併せて考慮することで、不要なＲＴＯタイマーの延長を防ぐことが出来る。

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

３０２ ダウンロード管理処理部； ３０３ ＳＳＬ／ＴＬＳ管理処理部； ３０４ ＴＣＰ管理処理部

Claims (10)

1. 外部通信装置との間でＴＣＰコネクションを確立して通信する通信手段と、
   前記ＴＣＰコネクションを確立する際に、前記外部通信装置から該外部通信装置の機器情報を受信する受信手段と、
   前記受信した前記外部通信装置の機器情報に基づいて、前記ＴＣＰコネクションの再送タイムアウト（ＲＴＯ）タイマー値を変更するよう制御する制御手段と、
   を有することを特徴とする通信装置。
2. 前記機器情報は、前記ＴＣＰコネクションを介して送信されたＨＴＴＰリクエスト内に含められている
   ことを特徴とする請求項１に記載の通信装置。
3. 前記ＨＴＴＰリクエスト内にはＨＴＴＰセッション数の情報が更に含められており、
   前記制御手段は、前記受信したＨＴＴＰセッション数の情報に基づいて、前記ＴＣＰコネクションのＲＴＯタイマー値を更に変更するよう制御する
   ことを特徴とする請求項２に記載の通信装置。
4. 前記機器情報は、前記ＴＣＰコネクションを介して送信されたＳｙｎパケット内に含められている
   ことを特徴とする請求項１に記載の通信装置。
5. 前記機器情報は、前記外部通信装置のハードウェア構成を特定する第１の情報及び前記外部通信装置のソフトウェア構成を特定する第２の情報の少なくとも一方を含む
   ことを特徴とする請求項１乃至４の何れか１項に記載の通信装置。
6. ハードウェア構成及びソフトウェア構成の少なくとも一方と関連付けられた加算係数テーブルを記憶する記憶手段を更に含み、
   前記制御手段は、前記第１の情報及び前記第２の情報の少なくとも一方と、前記加算係数テーブルと、に基づいて、前記ＴＣＰコネクションのＲＴＯタイマー値を変更する
   ことを特徴とする請求項５に記載の通信装置。
7. 外部通信装置との間でＴＣＰコネクションを確立して通信する通信装置の制御方法であって、
   前記ＴＣＰコネクションを確立する際に、前記外部通信装置から該外部通信装置の機器情報を受信する受信工程と、
   前記受信した前記外部通信装置の機器情報に基づいて、前記ＴＣＰコネクションの再送タイムアウト（ＲＴＯ）タイマー値を変更するよう制御する制御工程と、
   前記変更されたＲＴＯタイマー値に基づいて、前記ＴＣＰコネクションを介した通信を実行する通信工程と、
   を含むことを特徴とする通信装置の制御方法。
8. 第１の通信装置と第２の通信装置とを含む通信システムであって、
   前記第１の通信装置は、
   前記第２の通信装置との間でＴＣＰコネクションを確立して通信する第１の通信手段と、
   前記ＴＣＰコネクションを確立する際に、前記第１の通信装置の機器情報を前記第２の通信装置に送信する送信手段と、
   を有し、
   前記第２の通信装置は、
   前記第１の通信装置との間でＴＣＰコネクションを確立して通信する第２の通信手段と、
   前記ＴＣＰコネクションを確立する際に、前記第１の通信装置から該第１の通信装置の機器情報を受信する受信手段と、
   前記受信した前記第１の通信装置の機器情報に基づいて、前記ＴＣＰコネクションの再送タイムアウト（ＲＴＯ）タイマー値を変更するよう制御する制御手段と、
   を有する
   ことを特徴とする通信システム。
9. 前記第１の通信手段は省電力機能を備えている
   ことを特徴とする請求項８に記載の通信システム。
10. コンピュータを、請求項１乃至６の何れか一項に記載の通信装置の各手段として機能させるためのプログラム。

Images