(57)【要約】【課題】ゼロウインドウ状態でゼロウインドウプローブの送信を繰り返すことによるスループット低下を回避する。【解決手段】送信装置は、受信装置からウインドウサイズの当該単位容量を示すデータを受信し、データパケットを送信するごとに、当該データパケットに応答して前記受信装置から送信される、前記ウインドウサイズを含む確認応答を受信し、前記ウインドウサイズがゼロのとき、前記単位容量未満のデータサイズの検査用データパケットを送信し、当該検査用データパケットに応答して前記受信装置が送信する前記ウインドウサイズがゼロであっても、当該ウインドウサイズを含む前記確認応答が前記検査用データパケットが前記メモリに格納されたことを示すときには、前記検査用データパケットのデータサイズ以上であって前記単位容量未満の第１のデータサイズの前記データパケットを送信する。【選択図】    図８
2013038594.tif 000002
【特許請求の範囲】
【請求項１】
データパケットを受信して格納するためのメモリを有する受信装置に、前記データパケットを順次送信する送信部と、
前記受信装置から、所定のプロトコルに従って前記メモリの空き容量を単位容量の数を示すウインドウサイズで示すときの当該単位容量を示すデータを受信し、前記送信部が前記データパケットを送信するごとに、当該データパケットに応答して前記受信装置から送信される、前記ウインドウサイズを含む確認応答を受信する受信部と、
前記ウインドウサイズがゼロのとき、前記送信部に前記単位容量未満のデータサイズの検査用データパケットを送信させ、当該検査用データパケットに応答して前記受信装置が送信する前記ウインドウサイズがゼロであっても、当該ウインドウサイズを含む前記確認応答が前記検査用データパケットが前記メモリに格納されたことを示すときには、前記送信部に、前記検査用データパケットのデータサイズ以上であって前記単位容量未満の第１のデータサイズの前記データパケットを送信させる制御部と、
を有する送信装置。
【請求項２】
請求項１において、
前記制御部は、前記送信部が送信する前記データパケットのデータサイズを記憶し、前記ウインドウサイズが１以上からゼロになったときに、当該ウインドウサイズがゼロになる直前に送信された前記データパケットのデータサイズを前記単位容量から減算した最小予測空き容量に基づいて前記第１のデータサイズを推測する、送信装置。
【請求項３】
請求項２において、
前記制御部は、前記第１のデータサイズのデータパケットに応答して前記受信装置が送信する前記確認応答が、当該データパケットが前記メモリに格納されたことを示すときは前記送信部に前記第１のデータサイズのデータパケットを送信させ、前記メモリに格納されたことを示さないときは前記送信部に前記検査用データパケットを送信させる、送信装置。
【請求項４】
請求項１乃至３のいずれかにおいて、
前記空き容量は、前記受信装置にて前記メモリに格納された前記データパケットが処理されると増加する、送信装置。
【請求項５】
請求項１乃至４のいずれかに記載の送信装置と受信装置とを有する通信システム。
【請求項６】
データパケットを受信して格納するためのメモリを有する受信装置から、所定のプロトコルに従って前記メモリの空き容量を単位容量の数を示すウインドウサイズで示すときの当該単位容量を示すデータを受信し、
前記受信装置に前記データパケットを順次送信し、
前記受信装置から、前記送信部が前記データパケットを送信するごとに、当該データパケットに応答して前記受信装置から送信される、前記ウインドウサイズを含む確認応答を受信し、
前記ウインドウサイズがゼロのとき、前記送信部に前記単位容量未満のデータサイズの検査用データパケットを送信させ、当該検査用データパケットに応答して前記受信装置が送信する前記ウインドウサイズがゼロであっても、当該ウインドウサイズを含む前記確認応答が前記検査用データパケットが前記メモリに格納されたことを示すときには、前記検査用データパケットのデータサイズ以上であって前記単位容量未満の第１のデータサイズの前記データパケットを送信する、
データ送信方法。
【請求項７】
請求項６において、
前記送信される前記データパケットのデータサイズを記憶し、
前記ウインドウサイズが１以上からゼロになったときに、当該ウインドウサイズがゼロになる直前に送信された前記データパケットのデータサイズを前記単位容量から減算した最小予測空き容量に基づいて前記第１のデータサイズを推測する、
データ送信方法。
【請求項８】
請求項６において、
前記第１のデータサイズのデータパケットに応答して前記受信装置が送信する前記確認応答が、当該データパケットが前記メモリに格納されたことを示すときは前記第１のデータサイズのデータパケットを送信し、前記メモリに格納されたことを示さないときは前記検査用データパケットを送信する、
データ送信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信装置、通信システム、及び送信方法に関する。
【背景技術】
【０００２】
インターネットで標準的に利用されるＴＣＰ（Transmission Control Protocol）は、ＩＰ（Internet Protocol）の機能を拡張するプロトコルである。ＴＣＰ／ＩＰに関する具体的な仕様は、インターネット技術の標準を定める団体ＩＥＴＦ（Internet Engineering Task Force）により策定されている。
【０００３】
かかるＴＣＰ規格を用いる通信システム（たとえば、特許文献１、２）では、送信側装置と受信側装置とがコネクションを確立すると、送信側装置は、たとえば複数バイトのデータパケットを、たとえば数十ミリ秒の所定の送信周期で受信側装置に送信する。受信側装置は、データパケットを受信してバッファメモリに格納し、確認応答を返信する。このとき、確認応答には、バッファメモリの空き容量を１バイト以上の容量単位の数で示すウインドウサイズが含まれる。
【０００４】
上記のような通信システムでは、送信側装置は、ウインドウサイズが「０」になると（以下、かかる状態をゼロウインドウ状態という）、複数バイトのデータパケットの代わりに、最小の送信単位である１バイトの検査用データパケット（ゼロウインドウプローブ）を受信側装置に送信する。すると、受信側装置は、ゼロウインドウプローブに応答して、ウインドウサイズを返信する。このとき、依然としてバッファメモリの容量が不十分だと、ウインドウサイズ「０」が返信される。一方、たとえば受信側装置にてバッファメモリ内のデータが処理されて空き容量が増加すると、「１」以上のウインドウサイズが返信される。よって、ゼロウインドウプローブの送信は、ウインドウサイズが「１」以上に回復するまで、繰り返される。そして、ウインドウサイズが回復すると、送信側装置は、複数バイトのデータパケットの送信を再開する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平９−９７２２３号公報
【特許文献２】特開２００７−１１０６８０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ＴＣＰ規格によれば、ゼロウインドウ状態のとき、ゼロウインドウプローブは１秒以上の送信周期で送信される。よって、ゼロウインドウプローブの送受信が繰り返されるとき、応答待ちによる時間的なロスが発生する。また、ウインドウプローブを繰り返し送信することは、通信トラフィックの無用な増加につながる。こうしたことは、スループットを低下させる要因となる。
【０００７】
そこで、本発明の目的は、ゼロウインドウ状態でゼロウインドウプローブの送信を繰り返すことによるスループット低下を回避する送信装置、通信システム、及び送信方法を提供することにある。
【課題を解決するための手段】
【０００８】
上記の目的を達成するための一実施形態における送信装置は、たとえば、送信部と、受信部と、制御部とを有する。送信部は、データパケットを受信して格納するためのメモリを有する受信装置に、前記データパケットを順次送信する。また、受信部は、前記受信装置から、ＴＣＰに従って前記メモリの空き容量を単位容量の数を示すウインドウサイズで示すときの当該単位容量を示すデータを受信し、前記送信部が前記データパケットを送信するごとに、当該データパケットに応答して前記受信装置から送信される、前記ウインドウサイズを含む確認応答を受信する。そして、制御部は、前記ウインドウサイズがゼロのとき、前記送信部に前記単位容量未満のデータサイズの検査用データパケットを送信させ、当該検査用データパケットに応答して前記受信装置が送信する前記ウインドウサイズがゼロであっても、当該ウインドウサイズを含む前記確認応答が前記検査用データパケットが前記メモリに格納されたことを示すときには、前記送信部に、前記検査用データパケットのデータサイズ以上であって前記単位容量未満の第１のデータサイズの前記データパケットを送信させる。
【発明の効果】
【０００９】
以下に説明する実施形態によれば、ゼロウインドウ状態でゼロウインドウプローブの送信を繰り返すことによるスループット低下を回避することができる。
【図面の簡単な説明】
【００１０】
【図１】本実施形態における通信システムの構成を示す図である。
【図２】送信側装置１０２のＴＣＰ部１１６の詳細な構成例を説明するための図である。
【図３】受信側装置１０３のＴＣＰ部１１６の詳細な構成例を説明するための図である。
【図４】送信側装置１０２と受信側装置１０３の概略的な通信シーケンスを示す図である。
【図５】ウインドウサイズの変遷の例を示す図である。
【図６】スケール値ごとの容量単位を示す図である。
【図７】ウインドウサイズの変遷の例を示す図である。
【図８】本実施形態における、ウインドウサイズの遷移を示す図である。
【図９】本実施形態における送信側装置の動作手順を説明するフローチャート図である。
【図１０】変形例における送信側装置の動作手順を説明するフローチャート図である。
【図１１】図１０の手順Ｓ９１８ｂの後に実行される手順を示すフローチャート図である。
【図１２】実施例を説明するシーケンス図である。
【発明を実施するための形態】
【００１１】
以下、図面にしたがって本発明の実施の形態について説明する。但し、本発明の技術的範囲はこれらの実施の形態に限定されず、特許請求の範囲に記載された事項とその均等物まで及ぶものである。
【００１２】
図１は、本実施形態における通信システムの構成を示す図である。この通信システムは、たとえばインターネットなどの通信回線網１００を介して通信可能に接続される、送信側装置１０２と受信側装置１０３とを有する。送信側装置１０２と受信側装置１０３は、ＴＣＰ／ＩＰのＴＣＰ規格に従って、データパケットの送受信を行う。送信側装置１０２、及び受信側装置１０３は、たとえば、パーソナルコンピュータや、各種電子機器に設けられるプロセッサである。一例として、送信側装置１０２はセンサ類に設けられる制御用のマイクロコンピュータであり、受信側装置１０３はサーバとしてのパーソナルコンピュータである。かかる例では、送信側装置１０２は、センサによる検知データをインターネット経由で受信側装置１０３に送信する。
【００１３】
図１では、送信側装置１０２の構成が図示され、受信側装置１０３の構成は図示が省略される。ただし、受信側装置１０３は、送信側装置１０２と同様の構成を有し、送信側装置１０２についての次の説明は、受信側装置１０３にも適用される。
【００１４】
送信側装置１０２では、通信部１０４、ＣＰＵ（Central Processing Unit）１０６、ＲＯＭ（Read Only Memory）１０７、ＲＡＭ（Random Access Memory）１０８が、バス１１０を介して接続される。
【００１５】
通信部１０４は、たとえば、ＯＳＩ（Open System Intercommunication）参照モデルの物理層に対応する通信回路１１１と、データリンク層に対応するＭＡＣ（Media Access Control）部１１２とを有する。ＭＡＣ部１１２は、たとえば４８ビットのＭＡＣアドレスに基づいて、通信回路１１１によるデータの送受信を制御する。通信部１０４は、たとえば、ＮＩＣ（Network Interface Card）などである。
【００１６】
ＣＰＵ１０６は、ＩＰ部１１４、ＴＣＰ部１１６、ＡＰＩ（アプリケーションインターフェース）部１１８、及びアプリケーション部１２０を有する。ＩＰ部１１４、ＴＣＰ部１１６、ＡＰＩ部１１８、及びアプリケーション部１２０は、ＣＰＵ１０６がＲＯＭ１０７に格納されるＯＳ（オペレーションシステム）、通信ドライバプログラム、及びアプリケーションプログラムを実行することで構成される。ＩＰ部１１４は、ＯＳＩ参照モデルのネットワーク層に対応し、３２ビットの論理的なＩＰアドレスに基づいて、通信部１０４によるデータの送受信を制御する。ＴＣＰ部１１６は、トランスポート層に対応し、ＴＣＰ規格に基づいて、通信部１０４によるデータの送受信を制御する。そして、アプリケーション部１２０は、アプリケーション層に対応し、ＡＰＩ部１１８を介してＴＣＰ部１１６と、データの受け渡しを行う。
【００１７】
ＲＡＭ１０８には、受信側装置１０３に送信するためのデータパケットが一時的に格納される。ＲＡＭ１０８は、たとえば、ＤＲＡＭ（Dynamic Random Access Memory）である。また、受信側装置１０３では、ＲＡＭ１０８の一部は、送信側装置１０２から受信したデータパケットを格納するバッファメモリ１０９として使用される。受信側装置１０３では、ＴＣＰ部１１６が送信側装置１０２から送信されたデータパケットをバッファメモリ１０９に一時的に格納する。そして、アプリケーション部１２０は、ＡＰＩ部１１８を介してバッファメモリ１０９に格納されたデータパケットを読み出して処理する。
【００１８】
ここで、送信側装置１０２及び受信側装置１０３のＴＣＰ部１１６について、それぞれ図２、３を参照して説明する。
【００１９】
図２は、送信側装置１０２のＴＣＰ部１１６の詳細な構成例を説明するための図である。送信側装置１０２のＴＣＰ部１１６では、ＴＣＰ受信部２０４が、受信側装置１０３からの確認応答を受信する（２０２）。確認応答は、送信側装置１０２のデータパケットの送信に応答して受信側装置１０３から送信される。確認応答には、期待データ番号やウインドウサイズが含まれる。期待データ番号（以下、ＡＣＫ番号という）は、受信側装置１０３が次に送信側装置１０２から受信すべきデータのシーケンス番号に対応する。また、ウインドウサイズは、バッファメモリ１０９の空き容量を１バイト以上の単位容量で示す。
【００２０】
ＴＣＰ受信部２０４は、ウインドウサイズ判断部２０８に、確認応答を渡す（２０６）。すると、ウインドウサイズ判断部２０８は、確認応答からウインドウサイズを取得して確認応答とともにＡＣＫ番号取得部２１２に渡す（２１０）。そして、ＡＣＫ番号取得部２１２は、確認応答からＡＣＫ番号を取得し、送信制御部２１６に、ＡＣＫ番号とウインドウサイズとを渡す（２１４）。
【００２１】
送信制御部２１６は、タイマ部２２０に、タイマ起動を指示する（２１８）。すると、タイマ部２２０はタイマカウントを開始し、送信制御部２１６に、所定の送信周期（たとえば数十ミリ秒）ごとにタイムアウトを通知する（２２２）。ここで、送信周期は、ＴＣＰ規格に基づいて任意に設定される。
【００２２】
送信制御部２１６は、ウインドウサイズが「０」でなければ、すなわち、ゼロウインドウ状態でなければ、データ送信部２２９にデータパケット送信を指示し（２２６）、ウインドウサイズが「０」のときには、すなわち、ゼロウインドウ状態のときには、ウインドウプローブ送信部２２８ゼロウインドウプローブ送信を指示する（２２４）。ゼロウインドウプローブは、１バイトの検査用データパケットである。ただし、ゼロウインドウプローブは、検査のために用いられるが、本来送信すべきデータパケットである。データパケット送信が指示されたデータ送信部２２９、またはゼロウインドウプローブ送信が指示されたウインドウプローブ送信部２２８は、送信データ取得部２３４に、送信データの取得を指示する（２３０）。
【００２３】
送信データ取得部２３４は、たとえばＲＡＭ１０８から送信用のデータパケット（ゼロウインドウプローブを含む）を読み出し、データ送信部２２０にデータ取得を通知する（２３２）。そして、データ送信部２２０は、ＴＣＰ送信部２４０にデータ送信を指示する（２３８）。または、ウインドウプローブ送信部２２８は、ＴＣＰ送信部２４０にゼロウインドウプローブ送信を指示する（２３６）。
【００２４】
ＴＣＰ送信部２４０は、受信側装置１０３へ送信するためのデータパケットまたはゼロウインドウプローブを出力する（２４２）。このとき、データパケットまたはゼロウインドウプローブには、シーケンス番号が付される。そして、データパケットまたはゼロウインドウプローブは、ＩＰ部１１４を介して通信部１０４に送られ、さらに受信側装置１０３へ向けて通信回線網１００に送出される。
【００２５】
上記のようなＴＣＰ部１１６を備える送信側装置１０２において、ＴＣＰ送信部２４０が、受信側装置１０３にデータパケットを送信する「送信部」の例である。また、ＴＣＰ受信部２０４が、受信側装置１０３からウインドウサイズを含む受信応答を受信する「受信部」の例である。
【００２６】
図３は、受信側装置１０３のＴＣＰ部１１６の詳細な構成例を説明するための図である。受信側装置１０３のＴＣＰ部１１６では、ＴＣＰ受信部３０４が、送信側装置１０２からのデータパケットや確認応答を受信する（３０２）。そして、ＴＣＰ受信部３０４は、ウインドウサイズ判断部３０８に、受信通知を渡す（３０６）。
【００２７】
ウインドウサイズ判断部３０８は、データパケットを格納した後のバッファメモリ１０９の空き容量を示すウインドウサイズを求める。ウインドウサイズ判断部３０８は、たとえば、予め使用可能なバッファメモリ１０９の領域をＣＰＵ１０６のレジスタ等に記憶し、受信したデータパケットのデータサイズに基づき、空き容量を算出する。あるいは、ウインドウサイズ判断部３０８は、データパケットを格納するごとに、バッファメモリ１０９の空き容量をそのメモリコントローラから取得してもよい。そして、ウインドウサイズ判断部３０８は、求めた空き容量と、後述するスケール値とに基づき、ウインドウサイズを算出する。算出されたウインドウサイズは、応答判断部３１２に渡される（３１０）。
【００２８】
応答判断部３１２は、次に送信側装置１０２から受信すべきデータのシーケンス番号に対応する、ＡＣＫ番号を求める。たとえば、応答判断部３１２は、受信したデータのシーケンス番号をＲＡＭ１０８に格納しておき、これに基づいてＡＣＫ番号を求める。求められたＡＣＫ番号は、ウインドウサイズとともに、送信制御部３１６に渡される（３１４）。送信制御部３１６は、データ送信部３２０に、データ送信を指示する（３１８）。そして、データ送信部３２０は、送信データ生成部３２４に、送信用データパケットの生成を指示する（３２２）。送信用のデータパケットは、送信側装置１０２に返信される、ＡＣＫ番号とウインドウサイズとを含む確認応答である。
【００２９】
送信データ生成部３２４は、送信用のデータパケットを生成し、データ送信部３２０に通知する（３２６）。そして、データ送信部３２０は、ＴＣＰ送信部３３０にデータ送信を指示する（３２８）。そして、ＴＣＰ送信部３３０は、送信側装置１０２へ送信するためのデータパケットを出力する（３３２）。そして、出力されたデータパケットは、ＩＰ部１１４を介して送受信回路１０４に送られ、さらに送信側装置１０２へ向けて通信回線網１００に送出される。
【００３０】
図４は、送信側装置１０２と受信側装置１０３の概略的な通信シーケンスを示す。送信側装置１０２は、コネクション確立時に、受信側装置１０３に、データパケットｓＳＹＮと、スケール値ｓＳｃａｌｅとを送信する（Ｓ４０２）。データパケットｓＳＹＮは、コネクション確立を要求するＳＹＮフラグを有する。また、スケール値ｓＳｃａｌｅは、送信側装置１０２が受信側装置として動作する場合に、送信側装置１０２のウインドウサイズの単位容量を示す。
【００３１】
これに応答して受信側装置１０３は、送信側装置１０２に、データパケットｒＳＹＮと、確認応答ＡＣＫとを送信する（Ｓ４０４）。データパケットｒＳＹＮは、コネクション確立に応答するＳＹＮフラグを有する。また、確認応答ＡＣＫは、ＡＣＫ番号ｎＡＣＫと、スケール値ｒＳｃａｌｅとを有する。スケール値ｒＳｃａｌｅは、バッファメモリ１０９のウインドウサイズの単位を示す。そして、送信側装置１０２が、受信側装置１０３に、確認応答ＡＣＫを送信する（Ｓ４０６）。ここにおいて、コネクションが確立し、データパケットの送受信に必要な情報のやり取りが完了する。
【００３２】
次いで、送信側装置１０２は、受信側装置１０３に、たとえば複数バイトのデータパケットＤＰｃｋｔを、シーケンス番号ＳＥＱとともに送信する（Ｓ４０８）。シーケンス番号ＳＥＱは、たとえばデータパケットＤＰｃｋｔの先頭のデータのシーケンス番号に対応する。すると、受信側装置１０３は、データパケットＤＰｃｋｔを受信してバッファメモリ１０９に格納し、ＡＣＫ番号ｎＡＣＫとウインドウサイズＷＳとを含む確認応答ＡＣＫを返信する（Ｓ４１０）。ＡＣＫ番号ｎＡＣＫは、次に受信すべきデータのシーケンス番号に対応する。このようにして、１回分のデータパケットの送受信が完了する。
【００３３】
上記のようなデータパケットの送受信が、送信側装置１０２からの送信用データの送信が完了するか、または、送信用データの送信が完了する前にウインドウサイズＷＳが「０」になるまで繰り返される。
【００３４】
ウインドウサイズＷＳが「０」になると、送信側装置１０２は、受信側装置１０３に、ゼロウインドウプローブＺＷを送信する（Ｓ４１２）。ゼロウインドウプローブＺＷは、たとえば１バイトのデータパケットである。また、ゼロウインドウプローブＺＷには、シーケンス番号ＳＥＱが付加される。すると、受信側装置１０３は、これを受信し、ＡＣＫ番号ｎＡＣＫとウインドウサイズＷＳとを含む確認応答ＡＣＫを返信する（Ｓ４１４）。このとき、ウインドウサイズＷＳ＝「０」だと、送信側装置１０２からのゼロウインドウプローブＺＷの送信が繰り返される。
【００３５】
このようなゼロウインドウプローブの送受信は、バッファメモリ１０９のデータが処理されて空き容量が増加し、ウインドウサイズＷＳが「１」以上に回復するまで繰り返される。ウインドウサイズＷＳが回復すると、たとえば複数バイトのデータパケットＤＰｃｋｔの送信が再開される。たとえば、送信側装置１０２は、シーケンス番号ＳＥＱが付加されたデータパケットＤＰｃｋｔを送信し（Ｓ４１６）、これに応答して受信側装置１０３は、ＡＣＫ番号ｎＡＣＫとウインドウサイズＷＳとを含む確認応答ＡＣＫを送信する（Ｓ４１８）。
【００３６】
次いで、データパケットの送受信にともなうウインドウサイズの変遷について、詳細に説明する。
【００３７】
図５は、ＴＣＰ規格に基づく一般的な通信シーケンスを例として、ウインドウサイズの変遷を示す。図５では、送信側装置１０２から受信側装置１０３に、それぞれ１バイトのデータＤ１〜Ｄ７が送信されるステップＳ５０２〜Ｓ５２２が縦軸方向に示される。ここでは、受信側装置１０３のバッファメモリ１０９は、６バイトの容量を有する（各マス目が１バイトを示す）。
【００３８】
図５に示すシーケンス図は、図４においてステップＳ４０２〜Ｓ４０６が完了してコネクションが確立した後のステップに対応する。ここでは、送信側装置１０２から受信側装置１０３に、単位容量１バイトのデータのデータパケットずつ送信される。また、受信側装置１０３から送信側装置１０２に、バッファメモリ１０９の空き容量が、１バイトごとのウインドウサイズにより通知される。すなわち、コネクション確立時に、受信側装置１０３から送信側装置１０２へ、単位容量１バイトを示すスケール値ｒＳｃａｌｅが通知されたものとする。
【００３９】
初期状態Ｓ５０２に示されるように、受信側装置１０３は、６バイトのウインドウサイズＷＳ＝「６」を有する。
【００４０】
ステップＳ５０４で、送信側装置１０２は、受信側装置１０３に、シーケンス番号ＳＥＱが付加されたデータＤ１を送信する。すると、受信側装置１０３は、データＤ１をバッファメモリ１０９に格納する。ここで、次に受信すべきデータはＤ２である。また、バッファメモリ１０９の空き容量は５バイトになる。よって、ウインドウサイズＷＳ＝「５」になる。よって、受信側装置１０３は、データＤ２に対応するＡＣＫ番号ｎＡＣＫと、ウインドウサイズＷＳ＝「５」とを含む確認応答ＡＣＫを、返信する。
【００４１】
次いで、ステップＳ５０６〜Ｓ５１２に示すように、送信側装置１０２は、ステップごとに、１バイトのデータＤ２〜Ｄ５をシーケンス番号ＳＥＱともに受信側装置１０３に送信する。一方、受信側装置１０３は、データＤ２〜Ｄ５をそれぞれ受信する毎に、バッファメモリ１０９に格納する。すると、バッファメモリ１０９の空き容量が４バイト、３バイト、２バイト、そして１バイトというように減少する。そのたびに、受信側装置１０３は、ＡＣＫ番号ｎＡＣＫと空き容量に対応するウインドウサイズＷＳとを含む確認応答ＡＣＫを返信する。よって、ステップごとのウインドウサイズＷＳは、「４」、「３」、「２」、そして「１」というように減少する。
【００４２】
ステップＳ５１４で、送信側装置１０２は、受信側装置１０３に、データＤ６をシーケンス番号ＳＥＱとともに送信する。すると、受信側装置１０３は、データＤ６をバッファメモリ１０９に格納する。すると、空き容量は「０」バイトになる。よって、受信側装置１０３は、データＤ７に対応するＡＣＫ番号ｎＡＣＫとウインドウサイズＷＳ＝「０」とを含む確認応答ＡＣＫを返信する。
【００４３】
ステップＳ５１６で、ウインドウサイズＷＳ＝「０」なので、送信側装置１０２は受信側装置１０３に、データＤ７をゼロウインドウプローブＺＷとして送信する。このとき、受信側装置１０３では、バッファメモリ１０９の空き容量が「０」バイトなので、データパケットＤ７を格納することができない。よって、受信側装置１０３は、送信側装置１０２に、データＤ７を示すＡＣＫ番号ｎＡＣＫとウインドウサイズＷＳ＝「０」とを含む確認応答ＡＣＫを送信する。
【００４４】
これに応答して送信側装置１０２は、ステップＳ５１８で、受信側装置１０３に、再びデータＤ７をゼロウインドウプローブＺＷとして送信する。このとき、受信側装置１０３では、バッファメモリ１０９が一杯なのでデータＤ７を格納することができない。よって、受信側装置１０３は、再びデータＤ７を示すＡＣＫ番号ｎＡＣＫとウインドウサイズ＝「０」とを含む確認応答ＡＣＫを返信する。
【００４５】
同様の動作が、たとえば、ステップＳ５２０まで繰り返される。ここで、ステップＳ５２０の後、バッファメモリ１０９のデータが処理されて、空き容量が再び「６」バイトになる。すると、続くステップＳ５２２で、送信側装置１０２が受信側装置１０３に、データＤ７をゼロウインドウプローブＺＷとして送信したとき、受信側装置１０３では、バッファメモリ１０９にデータＤ７が格納される。これにより、空き容量が「５」バイトになる。よって、受信側装置１０３は、送信側装置１０２に、次のデータパケットを示すＡＣＫ番号ｎＡＣＫと、ウインドウサイズＷＳ＝「５」とを含む確認応答ＡＣＫを送信する。
【００４６】
このように、ステップＳ５１４でウインドウサイズＷＳ＝「０」になると、ステップＳ５１６〜Ｓ５２０で、送信側装置１０２はゼロウインドウプローブＺＷを受信側装置１０３に送信する。そして、ステップＳ５２０の後、ウインドウサイズＷＳが１以上に回復すると、データパケットＤ７が受信されて格納され、データパケットＤ１〜Ｄ７の送受信が完了する。
【００４７】
ところで、ＴＣＰ規格では、確認応答ＡＣＫに含まれるウインドウサイズＷＳは、１６ビット長のデータである。よって、表現できる空き容量は、０〜６５，５３５バイトの６５，５３６（＝２＾１６）個の値である。しかし、かかる規格の策定時から、半導体メモリの低価格化などを受け、バッファメモリが大容量化している。よって、より大きい空き容量を通知可能なウインドウスケールオプション（ＲＦＣ１１２２）がＩＥＴＦにより追加された。
【００４８】
ウインドウスケールオプションでは、ウインドウサイズＷＳの１単位に対応する空き容量、すなわち単位容量ＵＣが、スケール値ｒＳｃａｌｅにより次のように示される。
ＵＣ＝２＾ｒＳｃａｌｅ  (バイト)
よって、バッファメモリ１０９の空き容量ＢＦは次の式により示される。
ＢＦ＝ＷＳ×２＾ｒＳｃａｌｅ  (バイト)
ウインドウスケールオプションによれば、「０」〜「１４」のスケール値が用意されている。スケール値ｒＳｃａｌｅごとのウインドウサイズＷＳの１単位が示す単位容量（バイト数）は、図６に示すようになる。なお、ウインドウスケールオプションによって通知可能な空き容量の最大値は、６５５３５×２＾１４＝１,０７３,７２５,４４０バイトである。ここで、２をスケール値でべき乗する計算は、ビットシフトで行うことができる。
【００４９】
図７は、ウインドウスケールオプションを用いた場合の通信シーケンスを例として、ウインドウサイズの変遷を示す。図７では、送信側装置１０２から受信側装置１０３に、それぞれ１バイトのデータＤ１〜Ｄ１３が送信されるステップＳ７０２〜Ｓ７２２が示される。ここでは、受信側装置１０３のバッファメモリ１０９は、１２バイトの容量を有する（各マス目が１バイトを示す）。
【００５０】
図７に示すシーケンス図は、図４においてステップＳ４０２〜Ｓ４０６が完了してコネクションが確立した後のステップに対応する。ここでは、送信側装置１０２から受信側装置１０３に、３バイトのデータパケットずつ送信される。また、受信側装置１０３から送信側装置１０２に、４バイトの空き容量につき１単位のウインドウサイズが通知される。すなわち、コネクション確立時に、受信側装置１０３から送信側装置１０２へ、４バイトの単位容量を示すスケール値ｒＳｃａｌｅが通知されたものとする。
【００５１】
まず、初期状態Ｓ７０２において、バッファメモリ１０９は「１２」バイトの空き容量を有する。よって、４バイト単位のウインドウサイズＷＳ＝「３」である。
【００５２】
ステップＳ７０４で、送信側装置１０２は、受信側装置１０３に、シーケンス番号ＳＥＱとともに３バイトのデータＤ１〜Ｄ３を送信する。すると、受信側装置１０３は、データＤ１〜Ｄ３をバッファメモリ１０９に格納する。すると、空き容量は９バイトになる。すると、４バイト単位のウインドウサイズＷＳは「２」になる。ここで、ウインドウサイズＷＳは、バッファめもり１０９の空き容量をスケール値ｒＳｃａｌｅで除算したときの商の整数部分に対応する。よって、受信側装置１０３は、ＡＣＫ番号ｎＡＣＫとウインドウサイズＷＳ＝「２」とを含む確認応答ＡＣＫを返信する。
【００５３】
次いで、ステップＳ７０６で、送信側装置１０２は、受信側装置１０３に、シーケンス番号ＳＥＱとともに３バイトのデータＤ４〜Ｄ６を送信する。すると、受信側装置１０３は、データＤ４〜Ｄ６をバッファメモリ１０９に格納する。すると、空き容量は６バイトになる。すると、４バイト単位のウインドウサイズＷＳは「１」になる。よって、受信側装置１０３は、ＡＣＫ番号ｎＡＣＫとウインドウサイズＷＳ＝「１」とを含む確認応答ＡＣＫを返信する。
【００５４】
次いで、ステップＳ７０８で、送信側装置１０２は、受信側装置１０３に、シーケンス番号ＳＥＱとともに３バイトのデータＤ７〜Ｄ９を送信する。すると、受信側装置１０３は、データＤ７〜Ｄ９をバッファメモリ１０９に格納する。すると、空き容量は３バイトになる。すると、４バイト単位のウインドウサイズＷＳ＝「０」になる。よって、受信側装置１０３は、ＡＣＫ番号ｎＡＣＫとウインドウサイズＷＳ＝「０」とを含む確認応答ＡＣＫを返信する。
【００５５】
次に、ステップＳ７１０で、送信側装置１０２は、ウインドウサイズＷＳ＝「０」なので、受信側装置１０３に、データＤ１０をゼロウインドウプローブＺＷとして、シーケンス番号ＳＥＱとともに送信する。すなわち、３バイトずつデータパケットを送信することを中止し、その代わりに、１バイトのデータＤ１０をゼロウインドウプローブＺＷとして送信する。このとき、受信側装置１０３では、バッファメモリ１０９の空き容量は３バイトであるので、データＤ１０をバッファメモリ１０９に格納する。その結果、空き容量は２バイトになる。このとき、４バイト単位のウインドウサイズＷＳは「０」である。よって、受信側装置１０３は、ＡＣＫ番号ｎＡＣＫとウインドウサイズＷＳ＝「０」とを含む確認応答ＡＣＫを返信する。
【００５６】
次に、ステップＳ７１２で、ウインドウサイズＷＳ＝「０」なので、送信側装置１０２は、受信側装置１０３に、データＤ１１をゼロウインドウプローブＺＷとしてシーケンス番号ＳＥＱとともに送信する。このとき、受信側装置１０３では、バッファメモリ１０９の空き容量は２バイトであるので、データＤ１１をバッファメモリ１０９に格納する。その結果、空き容量は１バイトになる。すると、４バイト単位のウインドウサイズＷＳは「０」である。よって、受信側装置１０３は、ＡＣＫ番号ｎＡＣＫとウインドウサイズＷＳ＝「０」とを含む確認応答ＡＣＫを返信する。
【００５７】
次に、ステップＳ７１４で、ウインドウサイズＷＳ＝「０」なので、送信側装置１０２は、受信側装置１０３に、データＤ１２をゼロウインドウプローブＺＷとしてシーケンス番号ＳＥＱとともに送信する。このとき、受信側装置１０３では、バッファメモリ１０９の空き容量は１バイトであるので、データＤ１２をバッファメモリ１０９に格納する。その結果、空き容量は０バイトになる。すると、４バイト単位のウインドウサイズＷＳは「０」である。よって、受信側装置１０３は、ＡＣＫ番号ｎＡＣＫとウインドウサイズＷＳ＝「０」とを含む確認応答ＡＣＫを返信する。
【００５８】
次に、ステップＳ７１６で、ウインドウサイズＷＳ＝「０」なので、送信側装置１０２は、受信側装置１０３に、データＤ１３をゼロウインドウプローブとしてシーケンス番号ＳＥＱとともに送信する。このとき、受信側装置１０３では、バッファメモリ１０９の空き容量は０バイトであるので、データＤ１３がバッファメモリ１０９に格納されずに破棄される。よって、受信側装置１０３は、ＡＣＫ番号ｎＡＣＫとウインドウサイズＷＳ＝「０」とを含む確認応答ＡＣＫを返信する。
【００５９】
同様の動作が、たとえば、ステップＳ７２０まで繰り返される。ここで、ステップＳ７２０の後、バッファメモリ１０９のデータが処理されて、空き容量が再び「１２」バイトになる。よって、ウインドウサイズＷＳが「３」に回復する。すると、続くステップＳ７２２で、送信側装置１０２が受信側装置１０３に、データＤ１３をゼロウインドウプローブＺＷとして送信したとき、受信側装置１０３では、バッファメモリ１０９にデータＤ１３が格納される。こうして、データＤ１〜Ｄ１３の送受信が完了する。
【００６０】
図７において、ステップＳ７０８〜Ｓ７１２で、実際にはバッファメモリ１０９の空き容量があるにもかかわらず、ウインドウサイズＷＳ＝「０」が通知される。以下、かかる状況を、便宜上、みなしゼロウインドウという。このことにより、ステップＳ７１０〜Ｓ７１４では、ゼロウインドウインドウプローブＺＷとして１バイトのデータパケットＤ１０〜Ｄ１２が順次送信される。本実施形態では、ウインドウサイズＷＳ＝「０」が通知された場合であっても実際に空き容量がある場合、すなわちみなしゼロウインドウの場合に、ゼロウインドウプローブより大きいサイズのデータパケットを送信することで、スループットを向上させる。
【００６１】
図８は、本実施形態の通信シーケンスにおける、ウインドウサイズの遷移を示す。図８では、図７と同じ条件で、送信側装置１０２から受信側装置１０３にデータＤ１〜Ｄ１３が送信されるステップＳ７０２〜Ｓ７１０、Ｓ７１２´、Ｓ７１６〜Ｓ７２２が示される。
【００６２】
図８において、ステップＳ７０２〜Ｓ７１０は図７と同じであるので、説明を省略する。ここで、ステップＳ７１０において受信側装置１０３から送信側装置１０２に送信される確認応答ＡＣＫには、送信したデータＤ１０の次のデータパケットＤ１１を示すＡＣＫ番号が含まれている。このことは、ゼロウインドウプローブＺＷとして送信したデータパケットＤ１０が、破棄されずにバッファメモリ１０９に格納されたことを示す。すなわち、このことは、ウインドウサイズが「０」であるにもかかわらず、実際の空き容量がまだある蓋然性を示す。つまり、みなしゼロウインドウであることが示される。
【００６３】
そこで、ステップＳ７１２´で、送信側装置１０２は、ウインドウサイズＷＳ＝「０」であるにもかかわらず、受信側装置１０３に、１バイトのゼロウインドウプローブではなく、たとえば３バイトのデータパケットＤ１１−Ｄ１３を送信する。このとき、受信側装置１０３では、バッファメモリ１０９の空き容量は２バイトであるので、データパケットＤ１１、Ｄ１２がバッファメモリ１０９に格納され、データパケットＤ１３が破棄される。この結果、空き容量が「０」バイトになる。すると、４バイト単位のウインドウサイズＷＳは「０」である。よって、受信側装置１０３は、ＡＣＫ番号ｎＡＣＫとウインドウサイズＷＳ＝「０」とを含む確認応答ＡＣＫを返信する。このとき、ＡＣＫ番号ｎＡＣＫは、次に受信すべきデータパケットＤ１３を示す。
【００６４】
送信側装置１０２は、ＡＣＫ番号ｎＡＣＫから、送信したデータパケットＤ１１〜Ｄ１３のうち、データパケットＤ１３が格納されなかったと判断する。このことは、同時に、バッファメモリ１０９の実際の空き容量がなくなったことを示す。よって、ステップＳ７１６で、図７と同じウインドウサイズＷＳ＝「０」の場合の動作が実行される。たとえば、送信側装置１０２は、受信側装置１０３に、データパケットＤ１３をゼロウインドウプローブＺＷとして送信する。こうして、図７と同じステップＳ７１６〜ステップＳ７２２が実行される。すなわち、ゼロウインドウプローブとしてデータパケットＤ１３が繰り返し送信される。そして、ステップＳ７２２で、パケットデータＤ１〜Ｄ１３の送受信が完了する。
【００６５】
図８では、図７のステップＳ７１２、Ｓ７１４に対応する処理が、ステップＳ７１２´により行われる。すなわち、ＴＣＰ部１１６の送信制御部２１６は、ゼロウインドウプローブＺＷに応答して返信されるウインドウサイズＷＳが「０」であっても、これとともに返信される確認応答ＡＣＫがゼロウインドウプローブＺＷがバッファメモリ１０９に格納されたことを示すとき、すなわち、進んだＡＣＫ番号が受信されると、１バイトより大きいデータサイズのデータパケットを送信するようにＴＣＰ送信部２４０を制御する。そうすることで、みなしゼロウインドウのときにゼロウインドウプローブを繰り返し送信することを回避でき、ステップ数を減少させることができる。よって、このような送信側装置１０２の動作によって、通信システムのスループットが向上する。
【００６６】
図９は、本実施形態における送信側装置１０２の動作手順を説明するフローチャート図である。図９のフローチャート図は、ウインドウサイズが「０」になりゼロウインドウプローブを送信したとき、たとえば図８のステップＳ７１０で送信側装置１０２が確認応答ＡＣＫを受信したときに、送信側装置１０２のＴＣＰ部１１６の各部により実行される。
【００６７】
まず、ＴＣＰ受信部２０４が、受信側装置１０３からのデータパケット受信処理を行う（Ｓ９０２）。次いで、ウインドウサイズ判断部３０８が、受信側装置１０３のウインドウサイズＷＳを取得する（Ｓ９０４）。
【００６８】
次いで、送信制御部２１６が、ウインドウサイズＷＳが「０」でない場合であって（Ｓ９０６のＮＯ）、送信すべきデータがある場合（Ｓ９１０のＹＥＳ）を判定すると、データ送信部２３０がデータパケットの送信処理を行う（Ｓ９１８）。また、送信データがない場合（Ｓ９１０のＮＯ）、たとえば、図８におけるステップＳ７２２の後などは、あらたな送信／受信処理を待ち受ける待ち状態に移行する（Ｓ９２０）。
【００６９】
ウインドウサイズＷＳが「０」の場合であり（Ｓ９０６のＹＥＳ）、かつ、ＡＣＫ番号判断部２１２が判断したＡＣＫ番号が進んでいる場合であって（Ｓ９０８のＹＥＳ）、送信すべきデータがある場合（Ｓ９１２のＹＥＳ）を送信制御部２１６が判定すると、送信制御部２１６が送信データサイズを算出する（Ｓ９１６）。たとえば、図８のステップＳ７１２´において、１バイトのゼロウインドウプローブの代わりに、当初の送信データサイズどおりの、３バイトのデータパケットの送信が決定される。このとき決定される送信データサイズは、スケール値に対応する単位容量のバイト数以下である。さらに、すでに１バイト分のゼロウインドウプローブが格納されているので、スケール値に対応するバイト数−１バイトを送信データサイズとしてもよい。そうすることで、不要なトラフィックの増加を回避できる。
【００７０】
そして、データ送信部２３０がデータパケットの送信処理を行う（Ｓ９１８）。また、送信データがない場合（Ｓ９１２のＮＯ）、送信／受信処理待ち状態に移行する（Ｓ９２０）。また、ＡＣＫ番号が進んでいない場合（Ｓ９０８のＮＯ）、ウインドウプローブ送信部２２８が、ゼロウインドウプローブの送信処理を行う（Ｓ９１４）。この処理は、図８のステップＳ７１６〜Ｓ７２２に対応する。
【００７１】
データパケットの送信処理（Ｓ９１８）またはゼロウインドウプローブの送信処理（Ｓ９１４）の後、ＴＣＰ受信部２０４は、受信待ちに移行する（Ｓ９２４、Ｓ９２６のＮＯ）。そして、データパケットを受信すると（Ｓ９２６のＹＥＳ）、手順Ｓ９０２に移行し、上記の手順が繰り返される。
【００７２】
次に、本実施形態の変形例について説明する。変形例では、送信制御部２１６は、「０」のウインドウサイズが受信される直前に送信されたデータパケットのデータサイズと、スケール値とに基づき、送信データサイズを推測する。たとえば、スケール値に対応する単位容量から直前に送信されたデータパケットのデータサイズを減算した最小の予測容量から、送信データサイズが推測される。さらに、ウインドウサイズＷＳが「０」になったとき、直前のウインドウサイズをＷＳ´（＝「１」）、直前に送信したデータサイズをＤＳとすると、送信すべき送信データサイズＴＤが、スケール値ｒＳｃａｌｅから次の式Ｆ１により求められる。
Ｆ１：  ＴＤ＝ＷＳ´×２＾ｒＳｃａｌｅ−ＤＳ−１
すなわち、送信データサイズＴＤは、ウインドウサイズ実際の空き容量の最小値（ＷＳ´×２＾ｒＳｃａｌｅ）から、直前に送信したデータサイズＤＳとウインドウプローブのデータサイズ「１」とを減算した値である。そうすることで、空き容量に格納されうる最大サイズのデータパケットを送信することができる。よって、ステップ数を省略するとともに、無駄な通信トラフィックを削減でき、スループットを向上することができる。
【００７３】
図１０は、変形例における送信側装置１０２の動作手順を説明するフローチャート図である。図１０のフローチャート図は、図９のフローチャート図に対し、それぞれ点線で囲まれる、手順Ｓ９０５、Ｓ９１７、Ｓ９１５が追加されたものである。また、手順Ｓ９１８が手順Ｓ９１８ａ、Ｓ９１８ｂとして分割して示されるが、手順Ｓ９１８ａ、Ｓ９１８ｂの処理内容は手順Ｓ９１８と同じである。
【００７４】
図１０の手順では、手順Ｓ９０５で、ウインドウサイズ判断部３０８は、受信側装置１０３のウインドウサイズの保存処理を行う。また、手順Ｓ９１７で、データ送信部３３０は、送信したデータパケットのデータサイズを保存する処理を行う。そして、ウインドウサイズが「０」であるにもかかわらず実際の空き容量がある場合、すなわち、みなしゼロウインドウのとき、手順Ｓ９１５で、送信制御部３１６は、送信データサイズを計算する。たとえば、上述した式Ｆ１により、送信データサイズが推測される。そして、算出された送信データサイズのデータパケットの送信処理が行われる（Ｓ９１８ｂ）。
【００７５】
このようにして、実際の空き容量に最適な送信データサイズを求めてデータパケットを送信することができる。よって、ステップ数を省略でき、無駄なトラフィックの増加を回避できる。よって、スループットを向上させることができる。
【００７６】
図１１は、図１０の手順Ｓ９１８ｂの後に実行される手順を示すフローチャート図である。図１０の手順と同じ手順には、図１０と同じ符号を付し、重複する説明は適宜省略する。図１１では、点線で囲んだ手順Ｓ９０９が追加されている。
【００７７】
まず、図１０で示した手順Ｓ９０２〜Ｓ９０６が実行される。そして、送信制御部２１６が、ウインドウサイズＷＳが「０」でない場合（Ｓ９０６のＮＯ）を判定すると、データ送信部２３０がデータパケットの送信処理を行う（Ｓ９１８ａ）。一方、ウインドウサイズＷＳが「０」の場合において（Ｓ９０６のＹＥＳ）、ＡＣＫ番号判断部２１２が判断したＡＣＫ番号が進んでいて（Ｓ９０８のＹＥＳ）、直前に送信したデータパケット、すなわち、図１０の手順Ｓ９１５で送信データサイズを求めＳ９１８ｂで送信したデータパケットがすべてバッファメモリ１０９に格納された場合（Ｓ９０９のＹＥＳ）、手順Ｓ９１２に進む。手順Ｓ９０９では、受信側装置１０３から返信されたＡＣＫ番号ｎＡＣＫが、送信済みデータパケットのうちいずれかを示す場合には、そのデータパケットが格納されず破棄されたと判断でき、送信したデータパケットの次のデータパケットを示す場合には、すべてのデータパケットが格納されたと判断することができる。
【００７８】
送信すべきデータがある場合（Ｓ９１２のＹＥＳ）を送信制御部２１６が判定すると、送信制御部２１６が送信データサイズを推測する（Ｓ９１５）。そして、データ送信部２３０がデータパケットの送信処理を行う（Ｓ９１８ｂ）。また、送信データがない場合（Ｓ９１２のＮＯ）、受信処理待ち状態に移行する（Ｓ９２０）。また、ＡＣＫ番号が進んでいない場合（Ｓ９０８のＮＯ）、あるいは、ＡＣＫ番号が進んでいても（Ｓ９０８のＹＥＳ）直前の送信データがすべて格納された場合（Ｓ９０９のＮＯ）には、ウインドウプローブ送信部２２８がゼロウインドウプローブの送信処理を行う（Ｓ９１４）。
【００７９】
手順Ｓ９１４、Ｓ９２４、Ｓ９２６は、図１０と同じである。
【００８０】
図１１で示す手順によれば、バッファメモリ１０９の実際の空き容量がゼロになってデータが格納できなくなるまで、推測した送信データサイズのデータの送信が繰り返される。よって、送信側装置１０２は、推測したデータサイズのデータパケットを送信した後、さらにみなしゼロウインドウ状態が続く場合であっても、最小のステップ数で、残りの送信すべきデータを送信することができる。よって、スループットが向上する。
【００８１】
図１２は、図１０、１１で示した手順における実施例を説明するシーケンス図である。送信側装置１０２と受信側装置１０３は、ステップＳ１２０２とＳ１２０４で、互いにスケール値ｓＳｃａｌｅ＝「１０」と、スケール値ｒＳｃａｌｅ＝「１０」を通知する。この例では、ウインドウサイズ１単位当たりの単位容量は、１０２４バイト（＝２＾ｒＳｌａｌｅ）である。
【００８２】
送信側装置１０２は、シーケンス番号ＳＥＱ＝「１」と、１０００バイトのデータパケットＤＰｃｋｔを送信する（Ｓ１２０６）。すると、受信側装置１０３は、これをバッファメモリ１０９に格納し、ステップＳ１２０８でＡＣＫ番号ｎＡＣＫ＝「１００１」ウインドウサイズＷＳ＝「１」を含む確認応答を返信する（Ｓ１２０８）。
【００８３】
次いで、送信側装置１０２は、ウインドウサイズＷＳ＝「１」を記録する（Ｓ１２１０）。そして、送信側装置１０２は、５００バイトの送信データサイズを記録し（Ｓ１２１２）、５００バイトのデータパケットＤＰｃｋｔと、シーケンス番号ＳＱ＝「１００１」を送信する（Ｓ１２１４）。すると、受信側装置１０３は、５００バイトのデータパケットＤＰｃｋｔを受信してバッファメモリ１０９に格納し、ＡＣＫ番号ｎＡＣＫ＝「１５０１」と、ウインドウサイズＷＳ＝「０」を含む確認応答を返信する（Ｓ１２１６）。
【００８４】
次いで、送信側装置１０２は、ウインドウサイズＷＳ＝「０」なので、１バイトのゼロウインドウプローブＺＷをシーケンス番号ＳＥＱ＝「１５０１」とともに送信する（Ｓ１２１８）。すると、受信側装置１０３は、ゼロウインドウプローブＺＷを格納し、ＡＣＫ番号ｎＡＣＫ＝「１５０２」と、ウインドウサイズＷＳ＝「０」を含む確認応答を返信する（Ｓ１２２０）。
【００８５】
次いで、送信側装置１０２は、ＡＣＫ番号ｎＡＣＫが「１５０１」から「１５０２」に進んだことにより、みなしゼロウインドウ状態であるので、ゼロウインドウプローブの代わりに送信するデータの送信データサイズを推測する（Ｓ１２２２）。この場合、直前のウインドウサイズＷＳ＝「１」、直前の送信データサイズ＝「５００」、スケール値ｒＳｃａｌｅ＝「１０」なので、送信データサイズＤＳが次の式から算出される。
【００８６】
ＤＳ＝１×２＾１０−５００−１
＝５２３（バイト）
そして、送信側装置１０２は、シーケンス番号ＳＥＱ＝「２０２５」と、５２３バイトのデータパケットＤＰｃｋｔを受信側装置１０３に送信する（Ｓ１２２４）。  すると、受信側装置１０３は、ＡＣＫ番号ｎＡＣＫ＝２０２５（＝１５０１＋５２３）と、ウインドウサイズＷＳ＝「０」を含む確認応答を返信する（Ｓ１２２６）。
【００８７】
次いで、送信側装置１０２は、ＡＣＫ番号ｎＡＣＫが「１５０２」から「２０２５」に「５２３」進んだことにより、送信したデータがすべて格納されたと判断し（Ｓ１２２８）、再度５２３バイトのデータサイズのデータパケットをシーケンス番号ＳＥＱ＝「２０２５」とともに送信する（Ｓ１２３２）。すると、受信側装置１０３は、ＡＣＫ番号ｎＡＣＫ＝２１００（＝２０２５＋７５）と、ウインドウサイズＷＳ＝「０」を含む確認応答を送信する（Ｓ１２３４）。
【００８８】
次いで、送信側装置１０２は、ＡＣＫ番号ｎＡＣＫが「２０２５」から「２１００」に「７５」しか進んでいないことにより、送信した５００バイトのデータがすべて格納されなかったと判断し（Ｓ１２３５）、ウインドウサイズＷＳ＝「０」なので、１バイトのゼロウインドウプローブＺＷを送信する（Ｓ１２３６）。
【００８９】
上述したように、本実施形態によれば、ウインドウサイズが「０」になった場合、ゼロウインドウプローブの送信を繰り返すことで生じる時間的ロスや無用なトラフィックの増大を回避でき、スループットを向上させることができる。
【符号の説明】
【００９０】
１０２：送信側装置、  １０３：受信側装置、  １０９：バッファメモリ、２０４：ＴＣＰ受信部、２１６：送信制御部、２４０：ＴＣＰ送信部
【図１】
2013038594.tif 000003
【図２】
2013038594.tif 000004
【図３】
2013038594.tif 000005
【図４】
2013038594.tif 000006
【図５】
2013038594.tif 000007
【図６】
2013038594.tif 000008
【図７】
2013038594.tif 000009
【図８】
2013038594.tif 000010
【図９】
2013038594.tif 000011
【図１０】
2013038594.tif 000012
【図１１】
2013038594.tif 000013
【図１２】
2013038594.tif 000014