JP6391532B2 - 通信装置、通信方法、及びプログラム - Google Patents

Description

本発明は、論理的な接続を使用して通信を行うための通信方法に関する。

インターネット標準技術として広く利用されている、ＯＳＩ参照モデルにおけるアプリケーション層のプロトコル（通信規約）の一つに、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）がある。ＨＴＴＰの新しいバージョンとして、インターネット標準化団体（ＩＥＴＦ：Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）においてＨＴＴＰ／２の標準策定が行われた。ＨＴＴＰ／２規格では、ＨＴＴＰメッセージを用いたフロー制御の仕組みが規定されている。フロー制御は、通信装置が受信バッファの容量を超えるデータを受信してデータを取りこぼすことを防ぐために用いられる。従来は、トランスポート層のプロトコルの一つであるＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）の機能によりフロー制御が行われていた（特許文献１参照）。一方、ＨＴＴＰ／２におけるフロー制御では、制御フレームの一つであるＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを用いてデータの送受信が管理される。受信側の通信装置は、受信バッファに格納可能なデータ量を表すウインドウサイズを管理し、受信バッファ内のデータを処理したことによるウインドウサイズの増加量を、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信により送信側の通信装置に通知する。送信側の通信装置は、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームにより通知された量のデータを、受信側の通信装置に新たに送信することが許可されることとなる。ＨＴＴＰ／２通信では通常、通信装置がＤＡＴＡフレームの受信処理を行ってウインドウサイズが変化する度に、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信を行う。

特開２００９−７１７６６号公報

しかしながら、受信側の通信装置が送信側の通信装置に送信を許可するデータ量の通知を頻繁に行うと、受信側の通信装置における処理負荷が大きくなってしまうという課題がある。

本発明は上記課題に鑑み、通信装置が送信を許可するデータ量を通知する処理に係る、通信装置の処理負荷の増大を抑制するための技術を提供することを目的とする。

上記の課題を解決するため、本発明に係る通信装置は、例えば以下の構成を備える。すなわち、送信装置との間の論理的な接続を使用して、前記送信装置からコンテンツを構成するデータを受信する通信装置であって、前記送信装置から前記通信装置への前記論理的な接続を使用したデータの送信を許可するデータ量に関する情報を、前記送信装置に通知する通知手段と、前記通知手段による前記通知に応じて前記送信装置から送信された、前記コンテンツを構成するデータを受信する受信手段と、前記コンテンツを構成するデータのうち前記受信手段が受信していないデータの量が所定値より小さい場合に、前記論理的な接続が切断されるまで前記通知手段による前記通知を行わないよう制御する制御手段とを有する。

本発明によれば、通信装置が送信を許可するデータ量を通知する処理に係る、通信装置の処理負荷の増大を抑制することができる。

実施形態に係る通信システムの構成例を示す図である。 実施形態に係る第２の通信装置２０のハードウェア構成例を示すブロック図である。 実施形態に係る第２の通信装置２０の機能モジュール構成例を示すブロック図である。 第１実施形態に係る、第２の通信装置２０がストリームにおける最後のデータ受信に対してストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しない場合のシステムの動作を説明するためのシーケンス図である。 実施形態に係る、第２の通信装置２０と第１の通信装置１０とのＨＴＴＰ通信接続に関する動作を説明するためのシーケンス図である。 第１実施形態に係る、第２の通信装置２０がコネクションにおける最後のデータ受信に対してコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しない場合のシステムの動作を説明するためのシーケンス図である。 第１実施形態に係る、第２の通信装置２０によるＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信判断に関する動作を説明するためのフローチャートである。 第２実施形態に係る、第２の通信装置２０がＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈ及びＷｉｎｄｏｗＳｉｚｅに基づいてＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信判断を行う場合のシステムの動作を説明するためのシーケンス図である。 第２実施形態に係る、第２の通信装置２０によるＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信判断に関する動作を説明するためのフローチャートである。 第３実施形態に係る、第１の通信装置１０がＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームにより通知するデータ量をＣｏｎｔｅｎｔ−Ｌｅｇｔｈに基づいて判断する場合のシステムの動作を説明するためのシーケンス図である。

以下、本発明の実施形態について、図面を参照して説明する。なお、以下の実施形態は特許請求の範囲に係る本発明を限定するものではなく、また、以下の実施形態で説明する特徴の組み合わせの全てが本発明に必須のものとは限らない。

＜第１実施形態＞
［システム構成］
図１は、通信システムの構成例を示す図である。通信システムは第１の通信装置１０（以下、通信装置１０）と第２の通信装置２０（以下、通信装置２０）とを備え、これらがＩＥＥＥ８０２．１１に則った無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）により接続されている。

通信装置１０は、クライアントとしての通信装置であり、通信装置２０との間の論理的な接続（後述するコネクションやストリーム等）を使用して、コンテンツ（例えばテキストや画像、動画等）を構成するデータを送信又は受信する。通信装置２０は、サーバとしての通信装置であり、通信装置１０との間の論理的な接続を使用して、コンテンツを構成するデータを送信又は受信する。通信装置１０及び通信装置２０の具体例としては、デジタルカメラ、デジタルビデオカメラ、ネットワークカメラ、プリンタ、デジタル複合機、デジタルテレビ、プロジェクタ、携帯電話、スマートフォン、ＰＣ、及びサーバ装置などがある。通信の内容に応じて、通信装置１０と通信装置２０の何れか一方がデータ送信装置となり、他方がデータ受信装置となる。

例えば、通信装置１０がプリンタであり通信装置２０がサーバ装置である場合、ユーザはプリンタの操作パネルを操作することで、サーバ装置に記憶されている画像の中から印刷したい画像を選択する。画像が選択されると、プリンタはその画像のデータを送信するようサーバ装置に要求し、論理的な接続を使用してその画像データを受信し印刷する。この場合、サーバ装置である通信装置２０がデータ送信装置となり、プリンタである通信装置１０がデータ受信装置となる。また例えば、通信装置１０がデジタルカメラであり通信装置２０がサーバ装置である場合、ユーザはカメラに記憶された画像の中からサーバ装置にアップロードしたい画像を選択する。画像が選択されると、デジタルカメラは論理的な接続を使用してその画像データをサーバ装置に送信する。この場合、デジタルカメラである通信装置１０がデータ送信装置となり、サーバ装置である通信装置２０がデータ受信装置となる。

なお、本実施形態では通信装置１０と通信装置２０とが直接無線ＬＡＮ接続を行う例を示すが、これに限らず、外部の無線アクセスポイントを経由して接続しても良い。また、無線ＬＡＮ通信機能に限らず、例えばＢｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）、及びＲＦＩＤなどの他の無線通信機能を利用しても良い。また、例えばＥｔｈｅｒｎｅｔ（登録商標）などの有線ＬＡＮ通信機能、または無線ＬＡＮ通信機能と有線ＬＡＮ通信機能の組合せを利用しても良い。有線ＬＡＮ接続の場合は、例えばネットワークスイッチやルータなどの中継装置を経由して接続してもよい。さらに、本実施形態では通信装置１０と通信装置２０は同一ＬＡＮ上で接続しているが、これに限らず、例えばＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネット、及び携帯電話用の公衆無線回線などを経由して接続してもよい。

次に、通信装置の構成要素を詳細に説明する。図２は、通信装置２０のハードウェア構成例を示すブロック図である。なお、通信装置１０も通信装置２０と同じ構成である。本実施形態では通信装置１０がＰＯＳＴメソッドを使用して通信装置２０にデータをアップロードする場合について説明するため、ここではフロー制御を行う通信装置２０を中心に説明する。通信装置２０は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、補助記憶装置２０４、表示部２０５、操作部２０６、無線通信部２０７、及びアンテナ２０８を備える。

ＣＰＵ２０１は、通信装置２０の全体を制御する。ＲＯＭ２０２は、変更を必要としないプログラムやパラメータを格納する。ＲＡＭ２０３は、補助記憶装置２０４などから供給されるプログラムやデータを一時記憶する。補助記憶装置２０４は、画像コンテンツや映像コンテンツなどのデータを記憶する。表示部２０５は、ユーザが通信装置２０を操作するためのＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を表示する。操作部２０６は、ユーザが通信装置２０を操作するための入力インタフェースである。無線通信部２０７は、アンテナ２０８を制御し、通信装置１０との無線ＬＡＮ通信を行う。通信装置１０と通信装置２０とが外部の無線アクセスポイントを経由して接続する場合は、無線通信部２０７はアンテナ２０８を制御して無線アクセスポイント（不図示）との無線ＬＡＮ通信を行う。なお、本実施形態では表示部２０５と操作部２０６は通信装置２０の内部に存在するが、表示部２０５及び操作部２０６の少なくとも一方が通信装置２０の外部に別の装置として存在していてもよい。

［機能モジュール構成］
図３は、通信装置２０の機能モジュール構成例を示すブロック図である。なお、通信装置１０も通信装置２０と同じ構成である。通信装置２０は、制御部３０１、無線ＬＡＮ通信制御部３０２（以下、無線制御部３０２）、表示制御部３０３、操作制御部３０４、記憶制御部３０５、及びＴＣＰ／ＩＰ通信制御部３０６（以下、ＴＣＰ制御部３０６）を備える。通信装置２０はまた、ＨＴＴＰ通信制御部３０７（以下、ＨＴＴＰ制御部３０７）、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥ送信判断部３０８（以下、ＵＰＤＡＴＥ判断部３０８）、及びＧＯＡＷＡＹ判断部３０９を備える。通信装置２０はさらに、最終ＤＡＴＡフレーム判断部３１０（以下、最終判断部３１０）、ＷｉｎｄｏｗＳｉｚｅ判断部３１１（以下、Ｓｉｚｅ判断部３１１）及びＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈ取得部３１２（以下、Ｌｅｎｇｔｈ取得部３１２）を備える。各モジュールは、ＣＰＵ２０１がＲＯＭ２０２に格納されたプログラムをＲＡＭ２０３に展開して後述する各フローチャートに従った処理を実行することで実現されている。また例えば、ＣＰＵ２０１を用いたソフトウェア処理の代替としてハードウェアによる処理を行う場合には、ここで説明する各モジュールの処理に対応させた演算部や回路を構成すればよい。なお、通信装置２０が上記のモジュール全てを備えることは必須でない。

制御部３０１は、通信装置２０が備える個々の機能モジュールを制御する。無線制御部３０２は無線通信部２０７を制御し、通信装置１０との無線ＬＡＮ通信の制御を行う。通信装置１０と通信装置２０とが外部の無線アクセスポイントを経由して接続する場合は、無線制御部３０２は無線通信部２０７を制御して無線アクセスポイント（不図示）との無線ＬＡＮ通信の制御を行う。表示制御部３０３は表示部２０５を制御し、通信装置２０におけるＧＵＩの表示制御を行う。操作制御部３０４は操作部２０６を制御し、通信装置２０に対するユーザからの操作入力の制御を行う。記憶制御部３０５はＲＡＭ２０３及び補助記憶装置２０４を制御し、処理データや画像コンテンツ、映像コンテンツなどのデータを記憶または削除する。

ＴＣＰ制御部３０６は、無線制御部３０２を利用して、通信装置１０との間でＴＣＰ／ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）方式の通信制御を行う。なお、本実施形態ではＴＣＰ／ＩＰ通信を利用する例を示すが、これに限らず、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）など他のプロトコルに基づく通信をしても良い。ＨＴＴＰ制御部３０７は、ＴＣＰ制御部３０６を利用して、通信装置１０との間でＨＴＴＰ／２方式の通信制御を行う。また、ＨＴＴＰ制御部３０７は、通信装置１０との間でＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）を利用したＨＴＴＰＳ（ＨＴＴＰ Ｓｅｃｕｒｉｔｙ）方式の通信制御も行う。ただし、ＨＴＴＰ制御部３０７はこれら以外の方式（例えばＳＰＤＹ等）に基づく通信制御を行ってもよい。

ＨＴＴＰ／２方式の通信を行う通信装置は、ＯＳＩ参照モデルのトランスポート層におけるコネクション（論理的な第１接続）を通信装置間で確立する。通信装置はさらに、コネクションに基づいて複数のストリーム（論理的な第２接続）を確立することができ、それぞれのストリームにおいて独立したシーケンスで通信を行う。ストリームの確立は、確立するストリームのＩＤを指定したＨＥＡＤＥＲＳフレームを、そのストリームの基礎となるコネクションを使用して通信装置が相手側の通信装置に送信することにより行われる。コネクションを使用して送信されるメッセージにはストリームＩＤが設定されており、そのメッセージがコネクション上のどのストリームを使用して送信されるメッセージであるかが特定される。また、ＨＴＴＰ／２において通信装置間でやり取りされるメッセージは、フレームという形式をとる。フレームの具体例としては、制御情報を含むＨＥＡＤＥＲＳフレームやＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレーム、コンテンツを構成するデータ（ペイロードデータ）の一部又は全部を含むＤＡＴＡフレームなどがある。なお、通信装置２０は、例えばＨＴＴＰ／２以外のプロトコルに従って通信を行う場合などには、コネクションやストリーム以外の論理的な接続を使用してもよい。

ＵＰＤＡＴＥ判断部３０８は、コネクション用のＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレーム及びストリーム用のＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否かを判断する。この判断には、ＧＯＡＷＡＹ判断部３０９、最終判断部３１０、Ｓｉｚｅ判断部３１１、及びＬｅｎｇｔｈ取得部３１２の少なくとも何れかが利用される。

ＵＰＤＡＴＥ判断部３０８は、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する判断を下した場合、ＨＴＴＰ制御部３０７を使用して通信装置１０にＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する。通信装置２０は、通信装置１０から通信装置２０へのストリームを使用したデータの送信を許可するデータ量に関する情報（第１情報）を、ストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームにより通信装置１０に通知する。また、通信装置１０から通信装置２０へのコネクションに基づく１以上のストリームを使用したデータの送信を許可するデータ量に関する情報（第２情報）は、コネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームにより通知される。通知を受けた通信装置１０は、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームに記述されたデータ量に関するパラメータに基づいた値を上限とする量のペイロードデータを、通信装置２０に送信する。なお、通信装置２０は、例えばＨＴＴＰ／２以外のプロトコルに従って通信を行う場合などには、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレーム以外のメッセージによって上記のデータ量に関する情報を通知してもよい。

通信装置２０は、上述のように制御フレームの一つであるＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを用いて、コネクション及びストリームのそれぞれに対する通信装置１０からのデータ送信を管理してフロー制御を行う。具体的には、通信装置２０は、コネクションおよびストリームのそれぞれに対応する受信バッファの空き容量として定められたＷｉｎｄｏｗＳｉｚｅ（ウインドウサイズ）を管理する。ストリームを使用したデータの受信により受信バッファの空き容量が減少した場合、通信装置２０は、そのストリームに対応するＷｉｎｄｏｗＳｉｚｅとそのストリームの基礎となるコネクションに対応するＷｉｎｄｏｗＳｉｚｅとを減少させる。そして通信装置２０は、データの受信処理による受信バッファの空き容量の増加分を、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信により通信装置１０に通知し、ＷｉｎｄｏｗＳｉｚｅを増加させる。ここで、本実施形態における受信処理とは、通信装置２０が通信装置１０から受信してＲＡＭ２０３内の受信バッファに格納したデータを、ＣＰＵ２０１により処理した後受信バッファから取り除くことを言う。

つまり、ストリームＩＤが１であるストリームに関するＷｉｎｄｏｗＳｉｚｅは、通信装置２０が通信装置１０に、ＩＤが１であるストリームを使用したデータの送信を許可済みのデータ量である。また、コネクション用ＷｉｎｄｏｗＳｉｚｅは、通信装置２０がコネクションに基づく１以上のストリームを使用したデータの送信を許可済みのデータ量である。通信装置１０は、ストリーム用ＷｉｎｄｏｗＳｉｚｅ及びコネクション用ＷｉｎｄｏｗＳｉｚｅを超えない量のペイロードデータを、ストリームを使用して通信装置２０に送信する。ただし、例えば通信装置２０のリソース状況や通信経路の状況などによっては、通信装置１０から通信装置２０への論理的な接続を使用したデータの送信を許可済みのデータ量と受信バッファの空き容量とが異なっていてもよい。

ＧＯＡＷＡＹ判断部３０９は、ＨＴＴＰ制御部３０７が通信装置１０からＧＯＡＷＡＹフレームを受信したか否か、及び通信装置１０にＧＯＡＷＡＹフレームを送信したか否かを判断する。ＨＴＴＰ／２において規定されるＧＯＡＷＡＹフレームは、通信装置がそのＧＯＡＷＡＹフレームの送信に使用したコネクションに基づく新たなストリームを確立しないことを示す情報である。なお、通信装置１０及び通信装置２０は、例えばＨＴＴＰ／２以外のプロトコルに従って通信を行う場合などには、ＧＯＡＷＡＹフレーム以外のメッセージによって新たなストリームを確立しないことを通知してもよい。

最終判断部３１０は、ＨＴＴＰ制御部３０７がストリームを使用して通信装置１０から受信したＤＡＴＡフレームが、そのストリームにおける最終ＤＡＴＡフレームであるか否かを判断する。ここで、最終判断部３１０は、ＤＡＴＡフレームのフレームヘッダ中のＥＮＤ＿ＳＴＲＥＡＭフラグが有効（値が１）である場合、そのＤＡＴＡフレームがストリームにおける最終ＤＡＴＡフレームであると判断する。本実施形態において、ストリームにおける最終ＤＡＴＡフレームとは、通信装置１０から通信装置２０へそのストリームを使用して送信される最後のＤＡＴＡフレームである。なお、通信装置２０は、例えばＨＥＡＤＥＲＳフレーム中に記述された情報など、ＥＮＤ＿ＳＴＲＥＡＭフラグ以外の情報に基づいて、どのフレームが最終ＤＡＴＡフレームかを判断してもよい。

Ｓｉｚｅ判断部３１１は、コネクション用及びストリーム用のＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームに記述する、コネクション用及びストリーム用のＷｉｎｄｏｗＳｉｚｅの増加量を決定する。増加量の決定方法については後述する。

Ｌｅｎｇｔｈ取得部３１２は、ＨＴＴＰ制御部３０７がＨＥＡＤＥＲＳフレームを受信すると、ＨＥＡＤＥＲＳフレームのヘッダーブロックフラグメント中にＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈフィールドが設定されているか否かを判断する。Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈフィールドが設定されている場合、Ｌｅｎｇｔｈ取得部３１２はそのＨＥＡＤＥＲＳフレームからＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値を取得する。Ｃｏｎｔｅｔｎｔ−Ｌｅｎｇｔｈは、それが設定されたＨＥＡＤＥＲＳフレームに続いて送信されるコンテンツのデータ量（ペイロードデータのサイズ）を表す。なお、通信装置２０は、例えば通信装置１０に要求するデータのサイズを予め知っている場合など、コンテンツのデータ量をＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈ以外の情報に基づいて判断してもよい。

［通信シーケンス（１）］
以下、本実施形態における通信装置１０と通信装置２０との間における通信シーケンスについて、詳細に説明する。図４は、本実施形態に係る、通信装置２０がストリームにおける最後のデータ受信に対してストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しない場合のシステムの動作を説明するためのシーケンス図である。図４の処理は、例えば通信装置２０と通信を行うためのユーザ操作が通信装置１０に入力されたタイミングで開始される。ただし、図４の処理の開始タイミングは上記タイミングに限定されない。

Ｍ４０１において、通信装置１０が、通信装置２０との間でコネクションを確立してＨＴＴＰ通信接続を行う。この通信接続の詳細なシーケンスについては、図５を用いて後述する。本実施形態において、通信装置２０のコネクションに関するＩｎｉｔｉａｌＷｉｎｄｏｗＳｉｚｅはデフォルト値である６４ＫＢとし、以後確立される各ストリームに関するＩｎｉｔｉａｌＷｉｎｄｏｗＳｉｚｅも同様にデフォルト値である６４ＫＢとする。ここで、図４における「ＩＤ＿０」はコネクションに関する情報であることを示している。

Ｍ４０２において、通信装置１０が通信装置２０に対して、ＨＴＴＰリクエストヘッダ情報が記述されたＨＥＡＤＥＲＳフレームを送信する。本シーケンスにおいて、当該ＨＴＴＰリクエストはＰＯＳＴメソッドを使用し、通信装置１０は通信装置２０に９６ＫＢのペイロードデータを送信するものとする。このＨＥＡＤＥＲＳフレームの送信によって、通信装置１０はストリームＩＤを１とする新規ストリームを確立する。このとき、通信装置２０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは６４ＫＢであり、ストリーム１（ＩＤ＿１）に関するＷｉｎｄｏｗＳｉｚｅは６４ＫＢである。これは、通信装置１０が６４ＫＢまでのＤＡＴＡフレームを送信することが許可されていることを示す。なお、本実施形態では、通信装置１０から通信装置２０へのリクエストとして、上述のようにＰＯＳＴメソッドを指定したＨＥＡＤＥＲＳフレームを用いる。しかしこれに限らず、例えばＧＥＴメソッドやＰＵＴメソッドなどの他のＨＴＴＰリクエストメソッドや、ＣＯＮＴＩＮＵＡＴＩＯＮなどの他のフレームを利用してもよい。

Ｍ４０３において、通信装置１０が通信装置２０に対して、全９６ＫＢのペイロードデータのうち６４ＫＢ分を含むＤＡＴＡフレームを、ストリーム１（ＩＤ＿１）を使用して送信する。このＤＡＴＡフレームはストリーム１における最終ＤＡＴＡフレームではないため、ＥＮＤ＿ＳＴＲＥＡＭフラグは無効（値が０）である。このＤＡＴＡフレームを通信装置２０が受信すると、通信装置２０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは０ＫＢとなり、ストリーム１（ＩＤ＿１）に関するＷｉｎｄｏｗＳｉｚｅは０ＫＢとなる。これは、通信装置２０が、通信装置１０から６４ＫＢのＤＡＴＡフレームを受信して、その分の受信バッファを消費しているためである。

Ｍ４０４において、通信装置２０がＭ４０３で受信したＤＡＴＡフレームの受信処理を実施する。Ｍ４０５において、通信装置２０が通信装置１０に対して、コネクション（ＩＤ＿０）に関する６４ＫＢ分のＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する。このＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームが送信されると、通信装置２０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは６４ＫＢとなるが、ストリーム１（ＩＤ＿１）に関するＷｉｎｄｏｗＳｉｚｅは０ＫＢのままである。Ｍ４０６において、通信装置２０が通信装置１０に対して、ストリーム１（ＩＤ＿１）に関する６４ＫＢ分のＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する。このＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームが送信されると、ストリーム１（ＩＤ＿１）に関するＷｉｎｄｏｗＳｉｚｅも６４ＫＢとなる。

Ｍ４０７において、通信装置１０が、Ｍ４０５及びＭ４０６で通信装置２０から送信されたＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームによる送信許可データ量の通知に応じて、データ送信を行う。そして、通信装置２０のＨＴＴＰ制御部３０７がこれを受信する。具体的には、通信装置１０が通信装置２０に対して、全９６ＫＢのペイロードデータのうち残りの３２ＫＢ分を含むＤＡＴＡフレームを、ストリーム１（ＩＤ＿１）を使用して送信する。これはストリーム１における最終ＤＡＴＡフレームであるため、ＥＮＤ＿ＳＴＲＥＡＭフラグは有効（値が１）である。このＤＡＴＡフレームを通信装置２０が受信すると、通信装置２０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは３２ＫＢとなり、ストリーム１（ＩＤ＿１）に関するＷｉｎｄｏｗＳｉｚｅは３２ＫＢとなる。

Ｍ４０８において、通信装置２０がＭ４０７で受信したＤＡＴＡフレームの受信処理を実施する。Ｍ４０９において、通信装置２０がＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否か判断する。通信装置２０は、受信したコンテンツを構成するデータに、論理的な接続を使用して送信される最後のコンテンツを構成するデータであることを示す情報が設定されている場合に、その論理的な接続が切断されるまで通知を行わないよう制御する。本実施形態において、通信装置２０がＭ４０７で受信したＤＡＴＡフレームは、ＥＮＤ＿ＳＴＲＥＡＭフラグが有効である。このことから、通信装置２０は、このＤＡＴＡフレームが最終ＤＡＴＡフレームであり、これ以降ストリーム１を使用してＤＡＴＡフレームを受信することがないと判断する。そのため、通信装置２０は、通信装置１０にストリーム１を使用したデータの送信を許可する必要がないと判断し、ストリーム１が切断されるまでストリーム１に関するＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。

Ｍ４１０において、通信装置２０が通信装置１０に対して、コネクション（ＩＤ＿０）に関する３２ＫＢ分のＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する。このＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームが送信されると、通信装置２０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは６４ＫＢとなる。

Ｍ４１１において、通信装置２０が、Ｍ４０２で受信したＨＴＴＰリクエスト及びＭ４０３とＭ４０７で受信したデータへの応答として、通信装置１０に対して、ＨＴＴＰレスポンスであるＨＥＡＤＥＲＳフレームを送信する。本実施形態において、当該ＨＴＴＰレスポンスのステータスコードは「２００ ＯＫ」とする。通信装置２０は、ストリーム１を使用してこのＨＥＡＤＥＲＳフレームを送信する。本実施形態では、上述したように「２００ ＯＫ」が記述されたＨＥＡＤＥＲＳフレームを用いたが、これに限らず、他のステータスコードや、ＰＵＳＨ＿ＰＲＯＭＩＳＥなどの他のフレームを利用してもよい。Ｍ４１２において、通信装置１０が通信装置２０に対して、コネクションの終了に際してこれ以降新たなストリームを確立しないことを示す情報であるＧＯＡＷＡＹフレームを送信する。Ｍ４１３において、通信装置１０と通信装置２０とがＨＴＴＰ通信接続を終了する。具体的には、ＴＣＰコネクションを切断する。

［ＨＴＴＰ通信接続シーケンス］
図５は、通信装置２０と通信装置１０とのＨＴＴＰ通信接続に関する動作を説明するためのシーケンス図であり、図４のＭ４０１の詳細を示すものである。

Ｍ５０１において、通信装置１０が通信装置２０との間でＴＣＰコネクションを確立する。ＨＴＴＰＳ通信を行う場合、Ｍ５０２において、通信装置１０が通信装置２０とＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）通信接続を行う。ＴＬＳ通信接続の際に、ＡＬＰＮ（Ａｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ Ｐｒｏｔｏｃｏｌ Ｎｅｇｏｔｉａｔｉｏｎ）によるＨＴＴＰ／２通信開始のためのネゴシエーションも行われる。一方、ＨＴＴＰＳ通信を行わない場合、Ｍ５０３において、通信装置１０が通信装置２０に対してＨＴＴＰ／２アップグレード要求を送信する。Ｍ５０４において、通信装置２０が通信装置１０に対してＨＴＴＰ／２アップグレード応答を送信する。Ｍ５０２又はＭ５０４以降、通信装置１０と通信装置２０との間でＨＴＴＰ／２通信が行われる。

Ｍ５０５において、通信装置１０が通信装置２０に対して、クライアントコネクションプリフェイスのうちＰＲＩメソッドを指定する部分を送信する。Ｍ５０６において、通信装置１０が通信装置２０に対して、クライアントコネクションプリフェイスのうちＳＥＴＴＩＮＧＳフレームにあたる部分を送信する。Ｍ５０７において、通信装置２０が通信装置１０に対してサーバコネクションプリフェイスを送信する。これは空の可能性があるＳＥＴＴＩＮＧＳフレームだけで構成される。

［通信シーケンス（２）］
図６は、本実施形態に係る、通信装置２０がコネクションにおける最後のデータ受信に対してコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しない場合のシステムの動作を説明するためのシーケンス図である。図６の処理は、例えば通信装置２０と通信を行うためのユーザ操作が通信装置１０に入力されたタイミングで開始される。ただし、図６の処理の開始タイミングは上記タイミングに限定されない。図６において、図４と同じ内容の部分に関しては説明を省略する。

Ｍ６０１〜Ｍ６０６はＭ４０１〜Ｍ４０６と同じである。Ｍ６０７において、通信装置１０が通信装置２０に対して、これ以降新たなストリームを確立しないことを示す情報であるＧＯＡＷＡＹフレームを送信する。Ｍ６０８、Ｍ６０９はＭ４０７、Ｍ４０８と同じである。

Ｍ６１０において、通信装置２０がＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否か判断する。具体的には、通信装置２０は、Ｍ６０８で受信したＤＡＴＡフレームが最終ＤＡＴＡフレームであり、これ以降ストリーム１を使用してＤＡＴＡフレームを受信することがないと判断する。また、通信装置２０は、Ｍ６０７でＧＯＡＷＡＹフレームを受信したことから、Ｍ６０８で受信したＤＡＴＡフレームはコネクションにおける最終ＤＡＴＡフレームでもあると判断する。つまりこのＤＡＴＡフレームは、通信装置１０から通信装置２０へコネクションを使用して送信される最後のＤＡＴＡフレームでもある。そのため、通信装置２０は、それ以降通信装置１０にストリーム１を使用したデータの送信を許可する必要がないと判断し、ストリーム１が切断されるまでストリーム１に関するＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。また、通信装置２０は、通信装置１０にコネクションを使用したデータの送信を許可する必要がないと判断し、そのコネクションが切断されるまでコネクションに関するＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。Ｍ６１１、Ｍ６１２はＭ４１１、Ｍ４１３と同じである。

［ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信判断フロー］
図７は、本実施形態に係る、通信装置２０によるＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信判断に関する動作を説明するためのフローチャートである。図７の処理は、例えば通信装置２０が通信装置１０から何らかのフレームを受信したタイミングで開始される。ただし、図７の処理の開始タイミングは上記タイミングに限定されない。

Ｓ７０１において、ＨＴＴＰ制御部３０７が、通信装置１０との間のストリームを使用して通信装置１０からコンテンツを構成するデータであるＤＡＴＡフレームを受信したか否かを判断する。ＤＡＴＡフレームを受信した場合（Ｓ７０１；Ｙｅｓ）はＳ７０２に進むが、ＤＡＴＡフレームを受信していない場合（Ｓ７０１；Ｎｏ）は処理を終了する。Ｓ７０２において、ＨＴＴＰ制御部３０７がＤＡＴＡフレームの受信処理を行う。Ｓ７０３において、ＨＴＴＰ制御部３０７が、ＤＡＴＡフレームの受信処理が完了したか否かを判断する。ＤＡＴＡフレームの受信処理が完了した場合（Ｓ７０３；Ｙｅｓ）はＳ７０４に進むが、ＤＡＴＡフレームの受信処理が完了していない場合（Ｓ７０３；Ｎｏ）はＳ７０２に戻る。

Ｓ７０４において、ＵＰＤＡＴＥ判断部３０８が、ストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否かを判断する。ＵＰＤＡＴＥ判断部３０８は、受信したコンテンツを構成するデータに、論理的な接続を使用して送信される最後のコンテンツを構成するデータであることを示す情報が設定されている場合に、その論理的な接続が切断されるまで通知を行わないよう制御する。本実施形態においては、ＵＰＤＡＴＥ判断部３０８が、最終判断部３１０を利用して、受信したＤＡＴＡフレームのフレームヘッダ中にあるＥＮＤ＿ＳＴＲＥＡＭフラグが有効（値が１）か否かを判断する。ＥＮＤ＿ＳＴＲＥＡＭフラグが有効である場合（Ｓ７０４；Ｙｅｓ）、ＵＰＤＡＴＥ判断部３０８はストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しない判断を下しＳ７０６に進む。一方ＥＮＤ＿ＳＴＲＥＡＭフラグが有効でない場合（Ｓ７０４；Ｎｏ）はＳ７０５に進む。

Ｓ７０５において、ＵＰＤＡＴＥ判断部３０８が、ＤＡＴＡフレームの受信に使用したストリームに関するＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを通信装置１０に対して送信する判断を下す。そしてＵＰＤＡＴＥ判断部３０８が、ＨＴＴＰ制御部３０７を利用してストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する。これにより、通信装置１０から通信装置２０へのストリームを使用したデータの送信を許可するデータ量に関する情報が、通信装置１０に通知される。

Ｓ７０６において、ＵＰＤＡＴＥ判断部３０８が、ＨＴＴＰ制御部３０７が通信装置１０からＧＯＡＷＡＹフレームを受信したか否か、及び通信装置１０にＧＯＡＷＡＹフレームを送信したか否かを判断する。この判断にはＧＯＡＷＡＹ判断部３０９が利用される。ＨＴＴＰ制御部３０７がＧＯＡＷＡＹフレームを受信も送信もしていない場合（Ｓ７０６；Ｎｏ）はＳ７０８に進むが、受信または送信をした場合（Ｓ７０６；Ｙｅｓ）はＳ７０７に進む。

Ｓ７０７において、ＵＰＤＡＴＥ判断部３０８が、ＨＴＴＰ制御部３０７を利用して、実行中のストリームが存在するか否かを判断する。ここで実行中のストリームとは、通信装置１０と通信装置２０との間に確立されているストリームであり、通信装置２０がＤＡＴＡフレームの受信に使用中または使用予定のストリームである。実行中のストリームが存在しない場合（Ｓ７０７；Ｎｏ）、ＵＰＤＡＴＥ判断部３０８はコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しない判断を下し、処理を終了する。一方、実行中のストリームが存在する場合（Ｓ７０７；Ｙｅｓ）はＳ７０８に進む。

つまり、通信装置２０は、ＧＯＡＷＡＹフレームが通信装置２０によって送信又は受信され、コネクションに基づくストリームが１つであり、且つ、当該ストリームにおける最後のＤＡＴＡフレームを受信した場合、以下の制御を実行する。すなわち、通信装置２０は、コネクションを使用したデータの送信を許可するデータ量に関する第２情報の通知と、ストリームを使用したデータの送信を許可するデータ量に関する第１情報の通知とを行わないよう制御する。なお、本実施形態においてＧＯＡＷＡＹフレームは、コネクション（第１接続）に基づく新たなストリーム（第２接続）を確立しないことを示す情報である。また、第２情報の通知はコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信により実現され、第１情報の通知はストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信により実現される。

Ｓ７０８において、ＵＰＤＡＴＥ判断部３０８が、ＤＡＴＡフレームの受信に使用したストリームの基礎となるコネクションに関するＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを通信装置１０に対して送信する判断を下す。そしてＵＰＤＡＴＥ判断部３０８が、ＨＴＴＰ制御部３０７を利用してコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信し、処理を終了する。これにより、通信装置１０から通信装置２０へのコネクションを使用したデータの送信を許可するデータ量に関する情報が、通信装置１０に通知される。

以上説明したように、本実施形態における通信装置２０は、ストリームにおける最終ＤＡＴＡフレームを受信した場合に、そのストリームが切断されるまでそのストリームに関するＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。通常、通信装置２０は、１つのＤＡＴＡフレームの受信に対してコネクション用及びストリーム用の２つのＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する。しかし、ストリームにおける最終ＤＡＴＡフレームの受信後には、そのストリームに関するフロー制御が不要となるため、ストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する必要がない。本実施形態を用いれば、通信装置２０は、ＤＡＴＡフレームを受信するたびに２つのＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する場合に比べ、不要なＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信を削減することができ、処理負荷を軽減できる。処理負荷の軽減によって、例えば通信装置２０がバッテリーにより稼働している場合には、バッテリーの消費が低減される。

さらに、本実施形態における通信装置２０は、ストリームにおける最終ＤＡＴＡフレームを受信した場合に、ＧＯＡＷＡＹフレームが受信または送信されているか否か及びコネクションに基づく他の実行中ストリームがあるか否かを判断する。ＧＯＡＷＡＹフレームが通信装置２０により受信又は送信され、且つコネクションに基づいて確立されている実行中のストリームが他にない場合を考える。この場合には、通信装置２０は、ストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないことに加え、コネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームも送信しない。ＧＯＡＷＡＹフレームは、その送信に使用されたコネクションに基づく新たなストリームを確立しないことを示す情報である。よって、ＧＯＡＷＡＹフレームの送受信があり実行中ストリームが一つである場合に受信したストリームにおける最終ＤＡＴＡフレームは、コネクションにおける最終ＤＡＴＡフレームでもある。そのため、通信装置２０は、それ以降コネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する必要がない。本実施形態を用いれば、通信装置２０は、不要なＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信をさらに削減することができ、処理負荷をさらに軽減することができる。

一方、ＧＯＡＷＡＹフレームが通信装置２０によって送信も受信もされず、通信装置２０が通信装置１０からストリームにおける最終ＤＡＴＡフレームを受信した場合を考える。この場合、本実施形態における通信装置２０は、ストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥは送信せず、コネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥは送信するよう制御する。また、本実施形態における通信装置２０は、ストリームにおける最終ＤＡＴＡフレームを受信した場合にＧＯＡＷＡＹフレームが送受信されていても、他の実行中ストリームが存在すればコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する。このように、本実施形態における通信装置２０は、ストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥの送信とコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥの送信をそれぞれ異なる基準で制御する。これにより、通信装置２０は、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信の削減により実行中ストリームのフロー制御に不都合が生じてしまうのを回避することができる。

＜第２実施形態＞
以下、本発明に係る第２実施形態について説明する。第２実施形態における通信装置２０は、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値及びＷｉｎｄｏｗＳｉｚｅに基づいて、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否か判断する。第２実施形態における通信システム構成、機能モジュール構成、シーケンス、及びフローチャートについて、上述した第１実施形態と同じ部分については説明を省略する。

本実施形態では、ＨＴＴＰ制御部３０７がＤＡＴＡフレームを受信した場合、ＵＰＤＡＴＥ判断部３０８は最終判断部３１０とＳｉｚｅ判断部３１１を使用して、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否か判断する。最終判断部３１０が、受信されたＤＡＴＡフレームのＥＮＤ＿ＳＴＲＥＡＭフラグが有効であると判断した場合、ＵＰＤＡＴＥ判断部３０８は、ストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しない判断を下す。また、Ｓｉｚｅ判断部３１１は、ＨＴＴＰ制御部３０７が管理するコネクション用ＷｉｎｄｏｗＳｉｚｅ及びストリーム用ＷｉｎｄｏｗＳｉｚｅが閾値以上であるか否かを判断する。ＷｉｎｄｏｗＳｉｚｅが閾値以上だと判定された場合、ＵＰＤＡＴＥ判断部３０８は、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しない判断を下す。本実施形態において、閾値は１バイトとする。つまり、Ｓｉｚｅ判断部３１１は、ＷｉｎｄｏｗＳｉｚｅが全て消費されたか否かを判断する。なお、閾値は１バイトに限らず、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームで送信可能なＷｉｎｄｏｗＳｉｚｅの最大値（２＾３１−１）以下であればよい。例えば、閾値はＩｎｉｔｉａｌＷｉｎｄｏｗＳｉｚｅ（初期ウインドウサイズ）に設定されてもよい。この場合Ｓｉｚｅ判断部３１１は、ＷｉｎｄｏｗＳｉｚｅが初期状態から消費されたか否かを判断する。また例えば、閾値は通信装置２０がデータ受信用に確保できるメモリサイズに設定されてもよい。この場合Ｓｉｚｅ判断部３１１は、ＷｉｎｄｏｗＳｉｚｅが通信装置２０のリソースに関する上限に達しているか否かを判断する。以下では、閾値が１バイトである場合の例を中心に説明する。

また、本実施形態では、ＨＴＴＰ制御部３０７がＨＥＡＤＥＲＳフレームを受信した場合、ＵＰＤＡＴＥ判断部３０８はＬｅｎｇｔｈ取得部３１２とＳｉｚｅ判断部３１１を使用して、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否か判断する。Ｌｅｎｇｔｈ取得部３１２は、受信されたＨＥＡＤＥＲＳフレームに設定されたＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値を取得する。Ｓｉｚｅ判断部３１１は、ＨＴＴＰ制御部３０７が管理するコネクション用ＷｉｎｄｏｗＳｉｚｅ及びストリーム用ＷｉｎｄｏｗＳｉｚｅがＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値以上か否かを判断する。ＷｉｎｄｏｗＳｉｚｅがＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値以上だと判断された場合、ＵＰＤＡＴＥ判断部３０８は、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しない判断を下す。

［通信シーケンス］
以下、本実施形態における通信装置１０と通信装置２０との間における通信シーケンスについて、詳細に説明する。図８は、本実施形態に係る、通信装置２０がＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈ及びＷｉｎｄｏｗＳｉｚｅに基づいてＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信判断を行う場合のシステムの動作を説明するためのシーケンス図である。図８の処理は、例えば通信装置２０と通信を行うためのユーザ操作が通信装置１０に入力されたタイミングで開始される。ただし、図８の処理の開始タイミングは上記タイミングに限定されない。図８において、図４と同じ内容の部分に関しては説明を省略する。

Ｍ８０１は、Ｍ４０１と同じである。Ｍ８０２において、通信装置１０が通信装置２０に対して、ストリーム１（ＩＤ＿１）においてＰＯＳＴメソッドを使用して３２ＫＢのペイロードデータを送信するという情報が記述されたＨＥＡＤＥＲＳフレームを送信する。本実施形態において、ＨＥＡＤＥＲＳフレーム中にはＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈフィールドが含まれる。Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値は、当該ＨＥＡＤＥＲＳフレームに続いて送信されるペイロードデータのサイズを表し、ここでは３２ＫＢとなっているものとする。このとき、通信装置２０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは６４ＫＢであり、ストリーム１（ＩＤ＿１）に関するＷｉｎｄｏｗＳｉｚｅは６４ＫＢである。

Ｍ８０３において、通信装置１０が通信装置２０に対して、３２ＫＢのＤＡＴＡフレームを、ストリーム１（ＩＤ＿１）を使用して送信する。このＤＡＴＡフレームはストリーム１における最終ＤＡＴＡフレームになるため、ＥＮＤ＿ＳＴＲＥＡＭフラグは有効（値が１）である。このＤＡＴＡフレームを通信装置２０が受信すると、通信装置２０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは３２ＫＢとなり、ストリーム１（ＩＤ＿１）に関するＷｉｎｄｏｗＳｉｚｅは３２ＫＢとなる。Ｍ８０４において、通信装置２０がＭ８０３で受信したＤＡＴＡフレームの受信処理を実施する。

Ｍ８０５において、通信装置２０がＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否か判断する。通信装置２０は、Ｍ８０３で受信したＤＡＴＡフレームのＥＮＤ＿ＳＴＲＥＡＭフラグが有効であることから、このＤＡＴＡフレームが最終ＤＡＴＡフレームであり、これ以降ストリーム１を使用してＤＡＴＡフレームを受信することがないと判断する。そのため、通信装置２０は、ストリーム１（ＩＤ＿１）に関するＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。さらに、通信装置２０は、コネクション用ＷｉｎｄｏｗＳｉｚｅが所定の閾値以上であるため、コネクション用ＷｉｎｄｏｗＳｉｚｅを増加させるためのコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。本実施形態において、閾値は１バイトとする。Ｍ８０６において、通信装置２０が通信装置１０に対して、ＨＴＴＰレスポンスヘッダ情報として「２００ ＯＫ」が記述されたＨＥＡＤＥＲＳフレームを、ストリーム１（ＩＤ＿１）を使用して送信する。

Ｍ８０７において、通信装置１０が通信装置２０に対して、ストリーム３（ＩＤ＿３）においてＰＯＳＴメソッドを使用して１６ＫＢのペイロードデータを送信するという情報が記述されたＨＥＡＤＥＲＳフレームを送信する。このとき、通信装置２０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは３２ＫＢであり、ストリーム３（ＩＤ＿３）に関するＷｉｎｄｏｗＳｉｚｅは６４ＫＢである。Ｍ８０８において、通信装置１０が通信装置２０に対して、１６ＫＢのＤＡＴＡフレームを、ストリーム３（ＩＤ＿３）を使用して送信する。このＤＡＴＡフレームはストリーム３における最終ＤＡＴＡフレームになるため、ＥＮＤ＿ＳＴＲＥＡＭフラグは有効（値が１）である。このＤＡＴＡフレームを通信装置２０が受信すると、通信装置２０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは１６ＫＢとなり、ストリーム３（ＩＤ＿３）に関するＷｉｎｄｏｗＳｉｚｅは４８ＫＢとなる。

Ｍ８０９において、通信装置２０がＭ８０８で受信したＤＡＴＡフレームの受信処理を実施する。Ｍ８１０において、通信装置２０がＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否か判断する。通信装置２０は、Ｍ８０８で受信したＤＡＴＡフレームのＥＮＤ＿ＳＴＲＥＡＭフラグが有効であることから、このＤＡＴＡフレームが最終ＤＡＴＡフレームであり、これ以降ストリーム３を使用してＤＡＴＡフレームを受信することがないと判断する。そのため、通信装置２０は、ストリーム３（ＩＤ＿３）に関するＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。さらに、通信装置２０は、コネクション用ＷｉｎｄｏｗＳｉｚｅが閾値（１バイト）以上であるため、コネクション用ＷｉｎｄｏｗＳｉｚｅを増加させるためのコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。

Ｍ８１１において、通信装置２０が通信装置１０に対して、ＨＴＴＰレスポンスヘッダ情報として「２００ ＯＫ」が記述されたＨＥＡＤＥＲＳフレームを、ストリーム３（ＩＤ＿３）を使用して送信する。Ｍ８１２において、通信装置１０が通信装置２０に対して、ストリーム５（ＩＤ＿５）においてＰＯＳＴメソッドを使用して３２ＫＢのペイロードデータを送信するという情報が記述されたＨＥＡＤＥＲＳフレームを送信する。このとき、通信装置２０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは１６ＫＢであり、ストリーム５（ＩＤ＿５）に関するＷｉｎｄｏｗＳｉｚｅは６４ＫＢである。

Ｍ８１３において、通信装置２０がＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否か判断する。通信装置２０は、通信相手によって送信されるコンテンツのデータ量が、論理的な接続を使用したデータの送信を許可済みのデータ量より小さい場合に、通知を行わないよう制御する。本実施形態において、Ｍ８１２で通信装置２０が受信したＨＥＡＤＥＲＳフレーム中のＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値は３２ＫＢであり、コネクション（ＩＤ＿０）のＷｉｎｄｏｗＳｉｚｅである１６ＫＢよりも大きい。そのため通信装置２０は、ペイロードデータ全体を受信するためにはコネクション用ＷｉｎｄｏｗＳｉｚｅを増加させる必要があると判断する。そして通信装置２０は、コネクション（ＩＤ＿０）に関するＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを直ちに送信するよう制御する。一方、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値である３２ＫＢはストリーム５（ＩＤ＿５）のＷｉｎｄｏｗＳｉｚｅである６４ＫＢよりも小さいため、通信装置２０はストリーム用ＷｉｎｄｏｗＳｉｚｅが十分であると判断する。そのため、通信装置２０は、ストリーム５（ＩＤ＿５）に関するＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。

Ｍ８１４において、通信装置２０が通信装置１０に対して、コネクション（ＩＤ＿０）に関する４８ＫＢ分のＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する。これにより、通信装置２０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは６４ＫＢとなり、通信装置１０が１回のＤＡＴＡフレーム送信で全３２ＫＢのペイロードデータを送信できるようになる。Ｍ８１５において、通信装置１０が通信装置２０に対して、３２ＫＢのＤＡＴＡフレームを、ストリーム５（ＩＤ＿５）を使用して送信する。このＤＡＴＡフレームはストリーム５における最終ＤＡＴＡフレームになるため、ＥＮＤ＿ＳＴＲＥＡＭフラグは有効（値が１）である。このＤＡＴＡフレームを通信装置２０が受信すると、通信装置２０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは３２ＫＢとなり、ストリーム５（ＩＤ＿５）に関するＷｉｎｄｏｗＳｉｚｅは３２ＫＢとなる。Ｍ８１６において、通信装置２０がＭ８１５で受信したＤＡＴＡフレームの受信処理を実施する。

Ｍ８１７において、通信装置２０がＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否か判断する。通信装置２０は、Ｍ８１５で受信したＤＡＴＡフレームのＥＮＤ＿ＳＴＲＥＡＭフラグが有効であることから、このＤＡＴＡフレームが最終ＤＡＴＡフレームであり、これ以降ストリーム５を使用してＤＡＴＡフレームを受信することがないと判断する。そのため、通信装置２０は、ストリーム５（ＩＤ＿５）に関するＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。さらに、通信装置２０は、コネクション用ＷｉｎｄｏｗＳｉｚｅが閾値（１バイト）以上であるため、コネクション用ＷｉｎｄｏｗＳｉｚｅを増加させるためのコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。Ｍ８１８において、通信装置２０が通信装置１０に対して、ＨＴＴＰレスポンスヘッダ情報として「２００ ＯＫ」が記述されたＨＥＡＤＥＲＳフレームを、ストリーム５（ＩＤ＿５）を使用して送信する。Ｍ８１９、Ｍ８２０はＭ４１２、Ｍ４１３と同じである。

［ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信判断フロー］
図９は、本実施形態に係る、通信装置２０によるＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信判断に関する動作を説明するためのフローチャートである。図９の処理は、例えば通信装置２０が通信装置１０から何らかのフレームを受信したタイミングで開始される。ただし、図９の処理の開始タイミングは上記タイミングに限定されない。図９において、図７と同じ内容の部分に関しては説明を省略する。

Ｓ９０１において、ＨＴＴＰ制御部３０７が、通信装置１０からＨＴＴＰ通信におけるストリームを使用してＤＡＴＡフレームを受信したか否かを判断する。ＤＡＴＡフレームを受信した場合（Ｓ９０１；Ｙｅｓ）はＳ９０２に進むが、ＤＡＴＡフレームを受信していない場合（Ｓ９０１；Ｎｏ）はＳ９１１に進む。Ｓ９０２〜Ｓ９０４はＳ７０２〜Ｓ７０４と同じである。Ｓ９０４において、ＥＮＤ＿ＳＴＲＥＡＭフラグが有効である場合（Ｓ９０４；Ｙｅｓ）はＳ９０７に進むが、ＥＮＤ＿ＳＴＲＥＡＭフラグが有効でない場合（Ｓ９０４；Ｎｏ）はＳ９０５に進む。

Ｓ９０５において、ＵＰＤＡＴＥ判断部３０８が、Ｓｉｚｅ判断部３１１を利用して、ＤＡＴＡフレームの受信に使用されたストリームに関するＷｉｎｄｏｗＳｉｚｅが所定の閾値以上か否かを判断する。本実施形態において閾値は１バイトとする。つまりＳｉｚｅ判断部３１１は、ストリーム用ＷｉｎｄｏｗＳｉｚｅが０バイトよりも大きいか否かを判定する。ストリーム用ＷｉｎｄｏｗＳｉｚｅが閾値以上の場合（Ｓ９０５；Ｙｅｓ）、ＵＰＤＡＴＥ判断部３０８はストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しない判断を下し、Ｓ９０７に進む。一方、ストリーム用ＷｉｎｄｏｗＳｉｚｅが閾値未満の場合（Ｓ９０５；Ｎｏ）はＳ９０６に進む。

Ｓ９０６〜Ｓ９０８はＳ７０５〜Ｓ７０７と同じである。Ｓ９０７において、ＨＴＴＰ制御部３０７がＧＯＡＷＡＹフレームを受信も送信もしていない場合（Ｓ９０７；Ｎｏ）はＳ９０９に進むが、受信または送信をした場合（Ｓ９０７；Ｙｅｓ）はＳ９０８に進む。Ｓ９０８において、実行中のストリームが存在する場合（Ｓ９０８；Ｙｅｓ）はＳ９０９に進むが、実行中のストリームが存在しない場合（Ｓ９０８；Ｎｏ）は処理を終了する。

Ｓ９０９においてＳ９０５と同様に、ＵＰＤＡＴＥ判断部３０８が、Ｓｉｚｅ判断部３１１を利用して、コネクション用ＷｉｎｄｏｗＳｉｚｅが閾値（１バイト）以上か（つまり０バイトよりも大きいか）否かを判断する。コネクション用ＷｉｎｄｏｗＳｉｚｅが閾値以上である場合（Ｓ９０９；Ｙｅｓ）、ＵＰＤＡＴＥ判断部３０８はコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しない判断を下し、処理を終了する。一方、コネクション用ＷｉｎｄｏｗＳｉｚｅが閾値未満の場合（Ｓ９０９；Ｎｏ）はＳ９１０に進む。Ｓ９１０はＳ７０８と同じである。

Ｓ９１１において、ＨＴＴＰ制御部３０７が、通信装置１０からＨＴＴＰ通信におけるストリームを使用してＨＥＡＤＥＲＳフレームを受信したか否かを判断する。ＨＥＡＤＥＲＳフレームを受信した場合（Ｓ９１１；Ｙｅｓ）はＳ９１２に進むが、ＨＥＡＤＥＲＳフレームを受信していない場合（Ｓ９１１；Ｎｏ）は処理を終了する。Ｓ９１２において、Ｌｅｎｇｔｈ取得部３１２が、ＨＴＴＰ制御部３０７が受信したＨＥＡＤＥＲＳフレームのヘッダーブロックフラグメント中にＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈフィールドが含まれるか否かを判断する。Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈフィールドが含まれる場合（Ｓ９１２；Ｙｅｓ）はＳ９１３に進むが、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈフィールドが含まれない場合（Ｓ９１２；Ｎｏ）は処理を終了する。Ｓ９１３において、Ｌｅｎｇｔｈ取得部３１２が、ＨＴＴＰ制御部３０７が受信したＨＥＡＤＥＲＳフレームのヘッダーブロックフラグメント中からＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値を取得する。

Ｓ９１４において、ＵＰＤＡＴＥ判断部３０８が、Ｓ９１３で取得されたＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値がコネクション用ＷｉｎｄｏｗＳｉｚｅよりも大きいか否かを判断する。この判断にはＳｉｚｅ判断部３１１及びＬｅｎｇｔｈ取得部３１２が利用される。Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値がコネクション用ＷｉｎｄｏｗＳｉｚｅよりも大きい場合（Ｓ９１４；Ｙｅｓ）、ＵＰＤＡＴＥ判断部３０８はコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する判断を下し、Ｓ９１５に進む。一方、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値がコネクション用ＷｉｎｄｏｗＳｉｚｅ以下の場合（Ｓ９１４；Ｎｏ）、ＵＰＤＡＴＥ判断部３０８はコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しない判断を下し、Ｓ９１７に進む。

Ｓ９１５において、ＵＰＤＡＴＥ判断部３０８がＳｉｚｅ判断部３１１を利用して、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームに設定するコネクション用ＷｉｎｄｏｗＳｉｚｅの増加量を決定する。本実施形態においてＵＰＤＡＴＥ判断部３０８は、ＩｎｉｔｉａｌＷｉｎｄｏｗＳｉｚｅから受信バッファに格納されているＤＡＴＡフレームの合計サイズを差引いた値とＷｉｎｄｏｗＳｉｚｅとが一致するように増加量を決定する。ただし、ＵＰＤＡＴＥ判断部３０８は、ＷｉｎｄｏｗＳｉｚｅがＩｎｉｔｉａｌＷｉｎｄｏｗＳｉｚｅより大きくなるように設定してもよい。Ｓ９１６において、ＵＰＤＡＴＥ判断部３０８が、ＨＴＴＰ制御部３０７を利用して、通信装置１０に対してコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する。

Ｓ９１７において、ＵＰＤＡＴＥ判断部３０８が、ストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否かを判断する。ＵＰＤＡＴＥ判断部３０８は、通信相手によって送信されるコンテンツのデータ量が、論理的な接続を使用したデータの送信を許可済みのデータ量より小さい場合に、通知を行わないよう制御する。本実施形態においてＵＰＤＡＴＥ判断部３０８は、Ｓ９１３で取得されたＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値が、ＨＥＡＤＥＲＳフレームの受信に使用されたストリームに関するＷｉｎｄｏｗＳｉｚｅよりも大きいか否かを判断する。この判断にはＳｉｚｅ判断部３１１及びＬｅｎｇｔｈ取得部３１２が利用される。Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値がストリーム用ＷｉｎｄｏｗＳｉｚｅよりも大きい場合（Ｓ９１７；Ｙｅｓ）、ＵＰＤＡＴＥ判断部３０８はストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する判断を下し、Ｓ９１８に進む。一方、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値がコネクション用ＷｉｎｄｏｗＳｉｚｅ以下の場合（Ｓ９１７；Ｎｏ）、ＵＰＤＡＴＥ判断部３０８はコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しない判断を下し、処理を終了する。

Ｓ９１８において、ＵＰＤＡＴＥ判断部３０８がＳｉｚｅ判断部３１１を利用して、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームに設定するストリーム用ＷｉｎｄｏｗＳｉｚｅの増加量を決定する。増加量の決定方法については、Ｓ９１５におけるコネクション用ＷｉｎｄｏｗＳｉｚｅの場合と同様である。Ｓ９１９において、ＵＰＤＡＴＥ判断部３０８が、ＨＴＴＰ制御部３０７を利用して、通信装置１０に対してストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信し、処理を終了する。

以上説明したように、本実施形態における通信装置２０は、コネクション用ＷｉｎｄｏｗＳｉｚｅが閾値以上である場合にコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しない。また通信装置２０は、ストリーム用ＷｉｎｄｏｗＳｉｚｅが閾値以上であればストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しない。これにより通信装置２０は、ＤＡＴＡフレームを受信するたびにＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する場合と比べてＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信を削減することができ、処理負荷を軽減することができる。

一方、通信装置２０は、コネクション用ＷｉｎｄｏｗＳｉｚｅがＨＥＡＤＥＲＳフレームに記述されたＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値よりも小さければ、コネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する。また通信装置２０は、ＨＥＡＤＥＲＳフレームの受信に使用したストリームに関するＷｉｎｄｏｗＳｉｚｅがＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値よりも小さければ、そのストリームに関するＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する。

仮にこれを実施しない場合、具体的には図８のＭ８１４でＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しない場合を考える。この場合、通信装置２０におけるコネクション用ＷｉｎｄｏｗＳｉｚｅが１６ＫＢのため、通信装置１０はまず全３２ＫＢのペイロードデータのうち１６ＫＢ分のみを含むＤＡＴＡフレームを送信する。このＤＡＴＡフレームを受信した通信装置２０は、コネクション用ＷｉｎｄｏｗＳｉｚｅが０ＫＢとなり閾値を下回るため、通信装置１０に対してコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する。それに応じて、通信装置１０が残りの１６ＫＢ分を含むＤＡＴＡフレームを送信することとなる。

これに対して本実施形態では、上述した通り、通信装置２０が、ＨＥＡＤＥＲＳフレームの受信後かつＤＡＴＡフレームの受信前に、Ｍ８１４において通信装置１０にコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する。これによって、通信装置１０はＭ８１５において１つのＤＡＴＡフレームで全３２ＫＢのペイロードデータを送信でき、１６ＫＢのＤＡＴＡフレームを２回送信する場合よりも伝送にかかる遅延を低減することができる。そのため、通信装置１０から通信装置２０へのＤＡＴＡフレームの送信スループットが向上する。

また、通信装置２０は、コネクション用ＷｉｎｄｏｗＳｉｚｅがＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値より小さくても、ＩｎｉｔｉａｌＷｉｎｄｏｗＳｉｚｅ以上である場合には、コネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しなくてもよい。本実施形態におけるＷｉｎｄｏｗＳｉｚｅの最大値はＩｎｉｔｉａｌＷｉｎｄｏｗＳｉｚｅであるため、例えばコネクションのＷｉｎｄｏｗＳｉｚｅを消費していない場合が上記に該当し、コネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信の必要がない。これにより、通信装置２０は、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの不要な送信をさらに削減することができ、処理負荷をさらに軽減することができる。

なお、本実施形態では、通信装置２０がＨＥＡＤＥＲＳフレームまたはＤＡＴＡフレームを受信するたびにストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否かを判断する例を中心に説明したが、これに限らない。通信装置２０は、通信相手によって送信されるコンテンツのデータ量が、論理的な接続を使用したデータの送信を許可済みのデータ量より小さい場合に、その論理的な接続が切断されるまで許可するデータ量に関する通知を行わないよう制御してもよい。具体的には、例えば通信装置２０は、受信したＨＥＡＤＥＲＳフレームに記述されたＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値が、その受信に使用したストリームに関するＷｉｎｄｏｗＳｉｚｅより小さいか否かを判断する。Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値がストリーム用ＷｉｎｄｏｗＳｉｚｅ以下の場合、通信装置２０はストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信せずに、そのＨＥＡＤＥＲＳフレームに続いて送信されるペイロードデータ全てを受信できる。そのため、ＵＰＤＡＴＥ判断部３０８は、そのストリームが切断されるまでストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御してもよい。これにより、通信装置２０は、ＤＡＴＡフレームを受信するたびに行うＷＩＮＤＯＷ＿ＵＰＤＡＴＥの送信判断を省略でき、さらに処理負荷を軽減することができる。

また、通信装置２０は、未受信データ量に基づいてＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否か判断してもよい。通信装置２０は、論理的な接続を使用して通信装置１０から受信するコンテンツを構成するデータのうち、まだ受信していないデータの量が所定値より小さい場合に、論理的な接続が切断されるまで通知を行わないよう制御する。具体的には、ＨＴＴＰ制御部３０７が、通信装置１０からストリームを使用して送信されるペイロードデータのうちまだ受信していないデータの量を管理する。これは、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値から受信したＤＡＴＡフレームのサイズを差し引いたものである。そして、この未受信データ量が所定値より小さい場合に、ＵＰＤＡＴＥ判断部３０８が、そのストリームが切断されるまでストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。上記の所定値は、例えばストリーム用ＷｉｎｄｏｗＳｉｚｅとしてもよいし、１バイトとしてもよい。これにより、通信装置２０は、通信装置１０と通信を行う中でＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信が不要となったことを検知し、それ以降のＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信を削減して処理負荷を軽減できる。

例えば、上記の所定値をストリーム用ＷｉｎｄｏｗＳｉｚｅとした場合を考える。通信装置２０は、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレーム及びＤＡＴＡフレームを送受信する中で未受信データ量がストリーム用ＷｉｎｄｏｗＳｉｚｅより小さくなると、それ以降ストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。この場合、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値がストリーム用ＷｉｎｄｏｗＳｉｚｅより小さければ、通信装置２０は、ＨＥＡＤＥＲＳフレームを受信した時点でそれ以降のストリーム用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。また、例えば所定値を１バイトとした場合、通信装置２０は、最終データフレームを受信した時点でそれ以降のＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。

＜第３実施形態＞
以下、本発明に係る第３実施形態について説明する。第３実施形態においては、クライアント装置である通信装置１０が図９で説明した処理を行い、サーバ装置である通信装置２０にＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信してフロー制御を行う。第３実施形態における通信システム構成、機能モジュール構成、シーケンス、及びフローチャートについて、上述した第１実施形態または第２実施形態と同じ部分については説明を省略する。

［通信シーケンス］
以下、本実施形態における通信装置１０と通信装置２０との間における通信シーケンスについて、詳細に説明する。図１０は、本実施形態に係る、通信装置１０がＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームにより通知するデータ量をＣｏｎｔｅｎｔ−Ｌｅｇｔｈに基づいて判断する場合のシステムの動作を説明するためのシーケンス図である。図１０の処理は、例えば通信装置２０と通信を行うためのユーザ操作が通信装置１０に入力されたタイミングで開始される。ただし、図１０の処理の開始タイミングは上記タイミングに限定されない。図１０において、図４または図８と同じ内容の部分に関しては説明を省略する。

Ｍ１００１はＭ４０１と同じである。Ｍ１００２において、通信装置１０が通信装置２０に対して、ストリーム１（ＩＤ＿１）においてＧＥＴメソッドを使用してＵＲＬ＿１で指定されるデータを要求するという情報が記述されたＨＥＡＤＥＲＳフレームを送信する。Ｍ１００３において、通信装置２０が通信装置１０に対して、ストリーム１（ＩＤ＿１）においてＵＲＬ＿１で指定される１００ＫＢのペイロードデータを要求に応じて送信するという情報が記述されたＨＥＡＤＥＲＳフレームを送信する。本実施形態において、このＨＥＡＤＥＲＳフレーム中にはステータスコードとして「２００ ＯＫ」が記述されている。さらに、このＨＥＡＤＥＲＳフレーム中にはＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈフィールドが含まれ、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値としてペイロードデータサイズである１００ＫＢが記述されているものとする。このとき、通信装置１０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは６４ＫＢであり、ストリーム１（ＩＤ＿１）に関するＷｉｎｄｏｗＳｉｚｅは６４ＫＢである。

Ｍ１００４において、通信装置１０がＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否か判断する。Ｍ１００３で通信装置１０が受信したＨＥＡＤＥＲＳフレーム中のＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値は１００ＫＢであり、コネクション（ＩＤ＿０）のＷｉｎｄｏｗＳｉｚｅである６４ＫＢよりも大きい。そのため、通信装置１０は、ペイロードデータ全体を受信するためにはＷｉｎｄｏｗＳｉｚｅを増加させる必要があると判断する。そのため、通信装置１０は、コネクション用ＷｉｎｄｏｗＳｉｚｅがデフォルト値（６４ＫＢ）を超えてＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈと同じ値（１００ＫＢ）になるように、コネクション用ＷｉｎｄｏｗＳｉｚｅの増加分を３６ＫＢに決定する。そして、通信装置１０は、コネクション用ＷｉｎｄｏｗＳｉｚｅの増加分（３６ＫＢ）を指定して、コネクション（ＩＤ＿０）に関するＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを直ちに送信するよう制御する。同様に、通信装置１０は、ストリーム用ＷｉｎｄｏｗＳｉｚｅの増加分（３６ＫＢ）を指定して、ストリーム１（ＩＤ＿１）に関するＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを直ちに送信するよう制御する。

Ｍ１００５において、通信装置１０が通信装置２０に対して、コネクション（ＩＤ＿０）に関する３６ＫＢ分のＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する。このＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームが送信されると、通信装置１０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは１００ＫＢとなるが、ストリーム１（ＩＤ＿１）に関するＷｉｎｄｏｗＳｉｚｅは６４ＫＢのままである。Ｍ１００６において、通信装置１０が通信装置２０に対して、ストリーム１（ＩＤ＿１）に関する３６ＫＢ分のＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する。このＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームが送信されると、ストリーム１（ＩＤ＿１）に関するＷｉｎｄｏｗＳｉｚｅも１００ＫＢとなる。

Ｍ１００７において、通信装置２０が通信装置１０に対して、１００ＫＢのＤＡＴＡフレームを、ストリーム１（ＩＤ＿１）を使用して送信する。このＤＡＴＡフレームはストリーム１における最終ＤＡＴＡフレームになるため、ＥＮＤ＿ＳＴＲＥＡＭフラグは有効（値が１）である。このＤＡＴＡフレームを通信装置１０が受信すると、通信装置１０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは０ＫＢとなり、ストリーム１（ＩＤ＿１）に関するＷｉｎｄｏｗＳｉｚｅは０ＫＢとなる。Ｍ１００８において、通信装置１０がＭ１００７で受信したＤＡＴＡフレームの受信処理を実施する。

Ｍ１００９において、通信装置１０がＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否か判断する。通信装置１０は、Ｍ１００７で受信したＤＡＴＡフレームのＥＮＤ＿ＳＴＲＥＡＭフラグが有効であることから、このＤＡＴＡフレームが最終ＤＡＴＡフレームであり、これ以降ストリーム１を使用してＤＡＴＡフレームを受信することがないと判断する。そのため、通信装置１０は、ストリーム１（ＩＤ＿１）に関するＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。一方、通信装置１０は、コネクション用ＷｉｎｄｏｗＳｉｚｅが閾値よりも小さいため、コネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するよう制御する。このとき、通信装置１０は、コネクション用ＷｉｎｄｏｗＳｉｚｅがデフォルト値（６４ＫＢ）に戻るように、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームに設定するコネクション用ＷｉｎｄｏｗＳｉｚｅの増加分を６４ＫＢに設定する。ただし、ＷｉｎｄｏｗＳｉｚｅの増加分の設定方法はこれに限らず、例えばＭ１００４と同様に、ＷｉｎｄｏｗＳｉｚｅがデフォルト値より大きくなってもよい。

Ｍ１０１０において、通信装置１０が通信装置２０に対して、コネクション（ＩＤ＿０）に関する６４ＫＢ分のＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信する。このＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームが送信されると、通信装置１０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは６４ＫＢとなる。

Ｍ１０１１において、通信装置１０が通信装置２０に対して、ストリーム３（ＩＤ＿３）においてＧＥＴメソッドを使用してＵＲＬ＿３で指定されるデータを要求するという情報が記述されたＨＥＡＤＥＲＳフレームを送信する。Ｍ１０１２において、通信装置２０が通信装置１０に対して、ストリーム３（ＩＤ＿３）においてＵＲＬ＿３で指定される３２ＫＢのペイロードデータを要求に応じて送信するという情報が記述されたＨＥＡＤＥＲＳフレームを送信する。このとき、通信装置１０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは６４ＫＢであり、ストリーム３（ＩＤ＿３）に関するＷｉｎｄｏｗＳｉｚｅは６４ＫＢである。

Ｍ１０１３において、通信装置２０が通信装置１０に対して、３２ＫＢのＤＡＴＡフレームを、ストリーム３（ＩＤ＿３）を使用して送信する。このＤＡＴＡフレームはストリーム３における最終ＤＡＴＡフレームになるため、ＥＮＤ＿ＳＴＲＥＡＭフラグは有効（値が１）である。このＤＡＴＡフレームを通信装置１０が受信すると、通信装置１０のコネクション（ＩＤ＿０）に関するＷｉｎｄｏｗＳｉｚｅは３２ＫＢとなり、ストリーム３（ＩＤ＿３）に関するＷｉｎｄｏｗＳｉｚｅは３２ＫＢとなる。

Ｍ１０１４において、通信装置１０がＭ１０１３で受信したＤＡＴＡフレームの受信処理を実施する。Ｍ１０１５において、通信装置１０がＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否か判断する。通信装置１０は、Ｍ１０１３で受信したＤＡＴＡフレームが最終ＤＡＴＡフレームであり、これ以降ストリーム３を使用してＤＡＴＡフレームを受信することがないと判断する。そのため、通信装置１０は、ストリーム３（ＩＤ＿３）に関するＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。さらに、通信装置１０は、コネクション用ＷｉｎｄｏｗＳｉｚｅが閾値以上であるため、コネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しないよう制御する。Ｍ１０１６、Ｍ１０１７はＭ４１２、Ｍ４１３と同じである。なお、Ｍ１０１３で通信装置１０がＤＡＴＡフレームを正常に受信したことは、ＴＣＰ制御部３０６がトランスポート層における確認応答を通信装置２０に送信することで通知される。

以上説明したように、本実施形態における通信装置１０は、ＨＴＴＰクライアントとしてＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否か判断する。これに対して、第１実施形態及び第２実施形態では、通信装置２０がＨＴＴＰサーバとしてＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信するか否か判断する場合について説明した。このように、通信装置はクライアント装置として動作する場合もサーバ装置として動作する場合も、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信回数を低く抑え、処理負荷の増大を抑制することができる。

また、本実施形態における通信装置１０は、コネクション用ＷｉｎｄｏｗＳｉｚｅがコネクションのＩｎｉｔｉａｌＷｉｎｄｏｗＳｉｚｅよりも大きな値になるように、コネクション用ＷｉｎｄｏｗＳｉｚｅの増加量を設定した。これは、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値がコネクションのＩｎｉｔｉａｌＷｉｎｄｏｗＳｉｚｅのデフォルト値である６４ＫＢよりも大きい場合に行われる。この場合に、通信装置１０は、コネクション用ＷｉｎｄｏｗＳｉｚｅとＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値とが一致するようにコネクション用ＷｉｎｄｏｗＳｉｚｅの増加量を決定した。これによって、通信装置２０は、コネクション用ＷｉｎｄｏｗＳｉｚｅのデフォルト値を超える大きさのペイロードデータを、１つのＤＡＴＡフレームで送信できるようになる。そのため、通信装置２０がＩｎｉｔｉａｌＷｉｎｄｏｗＳｉｚｅより小さい複数のＤＡＴＡフレームを送信する場合よりも伝送にかかる遅延が低減され、通信装置２０から通信装置１０へのＤＡＴＡフレームの送信スループットが向上する。

また、例えばＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値がＩｎｉｔｉａｌＷｉｎｄｏｗＳｉｚｅの２倍以上である場合を考える。このとき、ＷｉｎｄｏｗＳｉｚｅの最大値をＩｎｉｔｉａｌＷｉｎｄｏｗＳｉｚｅとしていた場合は、通信装置１０はペイロードデータ全体を受信するまでにコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを複数回送信することになる。一方本実施形態によれば、通信装置１０は、ＷｉｎｄｏｗＳｉｚｅをＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値に一致させるようなコネクション用ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを一回送信すれば、ペイロードデータ全体を受信することができる。これにより、通信装置１０は、ＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームの送信を削減し処理負荷を軽減することができる。

なお、本実施形態では、通信装置１０はコネクション用ＷｉｎｄｏｗＳｉｚｅとＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈが表すコンテンツのデータ量とが一致するように制御したが、これに限らない。例えば、通信装置１０は、コネクション用ＷｉｎｄｏｗＳｉｚｅがコンテンツのデータ量以上となるように制御してもよい。通信装置１０は、コネクション用ＷｉｎｄｏｗＳｉｚｅをコンテンツのデータ量よりも大きくしておくことで、次にＨＥＡＤＥＲＳフレームを受信した際にＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを送信しなくてもよい可能性が増加する。

なお、通信装置１０は、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値分のメモリ領域を受信バッファとして確保できない場合には、コネクション用ＷｉｎｄｏｗＳｉｚｅがＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの値よりも小さくなるように制御してもよい。これによって、通信装置１０は、機器のリソース制約を考慮したうえでＷｉｎｄｏｗＳｉｚｅを適切に制御することができ、省リソース化と処理負荷軽減とを両立することができる。なお、ストリーム用ＷｉｎｄｏｗＳｉｚｅの増加量の決定方法についても、コネクション用ＷｉｎｄｏｗＳｉｚｅの場合と同様である。

＜その他の実施形態＞
上述した各実施形態は、その複数を組み合わせて実施することもできる。

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ等）によっても実現可能である。また、そのプログラムをコンピュータにより読み取り可能な記録媒体に記録して提供してもよい。

１０ 第１の通信装置
２０ 第２の通信装置
３０７ ＨＴＴＰ通信制御部
３０８ ＷＩＮＤＯＷ＿ＵＰＤＡＴＥ送信判断部

Claims (23)

1. 送信装置との間の論理的な接続を使用して、前記送信装置からコンテンツを構成するデータを受信する通信装置であって、
   前記送信装置から前記通信装置への前記論理的な接続を使用したデータの送信を許可するデータ量に関する情報を、前記送信装置に通知する通知手段と、
   前記通知手段による前記通知に応じて前記送信装置から送信された、前記コンテンツを構成するデータを受信する受信手段と、
   前記コンテンツを構成するデータのうち前記受信手段が受信していないデータの量が所定値より小さい場合に、前記論理的な接続が切断されるまで前記通知手段による前記通知を行わないよう制御する制御手段とを有することを特徴とする通信装置。
2. 前記制御手段は、前記受信手段が受信した前記コンテンツを構成するデータに、前記送信装置から前記通信装置へ前記論理的な接続を使用して送信される最後の前記コンテンツを構成するデータであることを示す情報が設定されている場合に、前記論理的な接続が切断されるまで前記通知手段による前記通知を行わないよう制御することを特徴とする請求項１に記載の通信装置。
3. 前記コンテンツのデータ量を取得する取得手段を有し、
   前記制御手段は、前記取得手段が取得した前記コンテンツのデータ量が、前記論理的な接続を使用したデータの送信を許可済みのデータ量より小さい場合に、前記論理的な接続が切断されるまで前記通知手段による前記通知を行わないよう制御することを特徴とする請求項１又は２に記載の通信装置。
4. 前記制御手段は、前記取得手段が取得した前記コンテンツのデータ量が、前記論理的な接続を使用したデータの送信を許可済みのデータ量より大きい場合に、前記論理的な接続を使用したデータの送信を許可済みのデータ量が前記コンテンツのデータ量以上となるように、前記通知手段による前記通知を行うよう制御することを特徴とする請求項３に記載の通信装置。
5. 前記コンテンツを構成するデータは、前記送信装置と前記通信装置との間の論理的な第１接続に基づいて確立される論理的な第２接続を使用して、前記送信装置から送信され、
   前記通知手段は、前記送信装置から前記通信装置への前記第２接続を使用したデータの送信を許可するデータ量に関する第１情報と、前記送信装置から前記通信装置への前記第１接続に基づく１以上の第２接続を使用したデータの送信を許可するデータ量に関する第２情報とを、前記送信装置に通知し、
   前記受信手段は、前記通知手段による前記第１情報及び前記第２情報の通知に応じて前記送信装置から送信された、前記コンテンツを構成するデータを受信し、
   前記制御手段は、前記第１接続に基づく新たな第２接続を確立しないことを示す情報が前記通信装置によって送信も受信もされず、前記受信手段が受信した前記コンテンツを構成するデータに、前記送信装置から前記通信装置へ第２接続を使用して送信される最後の前記コンテンツを構成するデータであることを示す情報が設定されている場合に、前記通知手段による前記第１情報の通知を行わず、前記通知手段による前記第２情報の通知を行うよう制御することを特徴とする請求項１乃至４のうち何れか１項に記載の通信装置。
6. 前記制御手段は、前記第１接続に基づく新たな第２接続を確立しないことを示す情報が前記通信装置によって送信又は受信され、前記第１接続に基づいて確立されている第２接続が一つであり、且つ前記受信手段が受信した前記コンテンツを構成するデータに、前記送信装置から前記通信装置へ第２接続を使用して送信される最後の前記コンテンツを構成するデータであることを示す情報が設定されている場合に、前記通知手段による前記第１情報及び前記第２情報の通知を行わないよう制御することを特徴とする請求項５に記載の通信装置。
7. 送信装置との間の論理的な接続を使用して、前記送信装置からコンテンツを構成するデータを受信する通信装置であって、
   前記送信装置から前記通信装置への前記論理的な接続を使用したデータの送信を許可するデータ量に関する情報を、前記送信装置に通知する通知手段と、
   前記通知手段による前記通知に応じて前記送信装置から送信された、前記コンテンツを構成するデータを受信する受信手段と、
   前記論理的な接続を使用したデータの送信を許可済みのデータ量が所定の閾値以上か否かを判定する判定手段と、
   前記論理的な接続を使用したデータの送信を許可済みのデータ量が前記所定の閾値以上だと前記判定手段が判定した場合に、前記通知手段による前記通知を行わないよう制御する制御手段とを有することを特徴とする通信装置。
8. 前記論理的な接続を使用したデータの送信を許可済みのデータ量は、前記論理的な接続に対応する前記通信装置の受信バッファの空き容量として定められたウインドウサイズであることを特徴とする請求項１乃至７のうち何れか１項に記載の通信装置。
9. 前記通知手段は、ＨＴＴＰ／２において規定されるＷＩＮＤＯＷ＿ＵＰＤＡＴＥフレームを前記送信装置に送信することで、前記送信装置から前記通信装置への前記論理的な接続を使用したデータの送信を許可するデータ量に関する情報を、前記送信装置に通知することを特徴とする請求項１乃至８のうち何れか１項に記載の通信装置。
10. 前記論理的な接続は、ＨＴＴＰ／２において規定されるストリームを含むことを特徴とする請求項１乃至９のうち何れか１項に記載の通信装置。
11. 前記論理的な第１接続は、ＨＴＴＰ／２において規定されるコネクションであり、前記論理的な第２接続は、ＨＴＴＰ／２において規定されるストリームであることを特徴とする請求項５又は６に記載の通信装置。
12. 前記送信装置から前記通信装置へ前記論理的な接続を使用して送信される最後の前記コンテンツを構成するデータであることを示す情報は、ＨＴＴＰ／２において規定されるＥＮＤ＿ＳＴＲＥＡＭフラグであることを特徴とする請求項２に記載の通信装置。
13. 前記取得手段は、前記通信装置が前記送信装置から受信した、ＨＴＴＰ／２において規定されるＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈフィールドの設定されたフレームから、前記コンテンツのデータ量を取得することを特徴とする請求項３又は４に記載の通信装置。
14. 前記第１接続に基づく新たな第２接続を確立しないことを示す情報は、ＨＴＴＰ／２において規定されるＧＯＡＷＡＹフレームであることを特徴とする請求項５又は６に記載の通信装置。
15. 前記所定値は、前記論理的な接続に対応する前記通信装置の受信バッファの空き容量として定められたウインドウサイズ又は１バイトであることを特徴とする請求項１乃至６のうち何れか１項に記載の通信装置。
16. 前記所定の閾値は、ＨＴＴＰ／２において規定される初期ウインドウサイズ又は１バイトであることを特徴とする請求項７に記載の通信装置。
17. 送信装置と、前記送信装置との間の論理的な接続を使用して前記送信装置からコンテンツを構成するデータを受信する通信装置とを有し、
    前記通信装置は、データ量に関するパラメータを前記送信装置に通知する通知手段と、
    前記通知手段による前記パラメータの通知に応じて前記送信装置から送信された、前記コンテンツを構成するデータを受信する受信手段と、
    前記コンテンツを構成するデータのうち前記受信手段が受信していないデータの量が所定値より小さい場合に、前記論理的な接続が切断されるまで前記通知手段による前記通知を行わないよう制御する制御手段とを有し、
    前記送信装置は、前記通知手段により通知された前記パラメータに基づいた量の前記コンテンツを構成するデータを、前記論理的な接続を使用して前記通信装置に送信する送信手段を有することを特徴とする通信システム。
18. 前記制御手段は、前記受信手段が受信した前記コンテンツを構成するデータに、前記送信装置から前記通信装置へ前記論理的な接続を使用して送信される最後の前記コンテンツを構成するデータであることを示す情報が設定されている場合に、前記論理的な接続が切断されるまで前記通知手段による前記通知を行わないよう制御することを特徴とする請求項１７に記載の通信システム。
19. 前記通信装置は、前記コンテンツのデータ量を取得する取得手段を有し、
    前記制御手段は、前記取得手段が取得した前記コンテンツのデータ量が、前記論理的な接続に対応する前記通信装置の受信バッファの空き容量として定められたウインドウサイズより小さい場合に、前記論理的な接続が切断されるまで前記通知手段による前記通知を行わないよう制御することを特徴とする請求項１７又は１８に記載の通信システム。
20. データ量に関するパラメータを送信装置に通知する通知工程と、
    前記送信装置が、前記通知工程において通知された前記パラメータに基づいた量のコンテンツを構成するデータを、通信装置との間の論理的な接続を使用して前記通信装置に送信する送信工程と、
    前記通信装置が、前記送信工程において前記送信装置から送信された前記コンテンツを構成するデータを受信する受信工程と、
    前記コンテンツを構成するデータのうち前記受信工程において受信されていないデータの量が所定値より小さい場合に、前記論理的な接続が切断されるまで前記通知工程における前記通知を行わないよう制御する制御工程とを有することを特徴とする通信方法。
21. 前記制御工程は、前記受信工程において受信された前記コンテンツを構成するデータに、前記送信装置から前記通信装置へ前記論理的な接続を使用して送信される最後の前記コンテンツを構成するデータであることを示す情報が設定されている場合に、前記論理的な接続が切断されるまで前記通知工程における前記通知を行わないよう制御することを特徴とする請求項２０に記載の通信方法。
22. 前記コンテンツのデータ量を取得する取得工程を有し、
    前記制御工程は、前記取得工程において取得された前記コンテンツのデータ量が、前記論理的な接続に対応する前記通信装置の受信バッファの空き容量として定められたウインドウサイズより小さい場合に、前記論理的な接続が切断されるまで前記通知工程における前記通知を行わないよう制御することを特徴とする請求項２０又は２１に記載の通信方法。
23. コンピュータを、請求項１乃至１６のうち何れか１項に記載の通信装置として動作させるためのプログラム。

Images