JP2001298485A - トランスポート層におけるデータ転送方法 - Google Patents

Abstract

(57)【要約】 【課題】 信頼性の保証されたデータリンク層を利用し
た通信においてスループットを向上させることができる
トランスポート層におけるデータ転送方法を提供するこ
と。 【解決手段】 ウインドウ・サイズ（確認応答を受けた
際に確認応答を待たずに送信できるデータの大きさ）
が、その最大値である既定サイズより小さいとき、図１
（ａ）に示すようにウインドウ・サイズを既定サイズま
で一度に拡大する。あるいは、ウィンドウ・サイズをそ
の最大値にしたままでデータを送信する。これにより、
スロースタート制御や輻輳回避制御が行われず、効率の
良いデータ転送を行うことができる。また、タイムアウ
ト発生時、ウィンドウ番号を図１（ｂ）に示すように設
定し、次送信データ番号を保持しておき、タイムアウト
を発生させたデータだけを再送する。これにより、重複
するデータを送ることを最小限に抑えることができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データ通信中のデ
ータ損失がほとんどないような信頼性が保証されたデー
タリンク層を利用したトランスポート層におけるデータ
通信方法に関し、さらに詳細には、ウインドウサイズの
制御やタイムアウトによるデータ再送などを含めたトラ
ンスポート層におけるデータ転送方法に関するものであ
る。

【０００２】

【従来の技術】データ通信中のデータ損失がほとんどな
いような信頼性が保証されたデータリンク層として携帯
電話やＰＨＳなどの無線リンク層やＰＰＰ（Ｐｏｉｎｔ
−ｔｏ−Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）などが考えら
れ、また、トランスポート層としてはＴＣＰ（Ｔｒａｎ
ｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏ
ｌ）が考えられる。例えばトランスポート層にＴＣＰを
考えたとする。従来のＴＣＰのデータ転送方法において
は、データリンク層としてＥｔｈｅｒｎｅｔ（登録商
標）のような複数ユーザが共有してデータリンク層を利
用するような形態を考慮しており、データ損失はルータ
などにおいて輻輳が起きてしまいデータが複数個連続し
て損失してしまうことを想定している。そのため、デー
タ転送開始時にはスロースタート制御、タイムアウト発
生時にはスロースタート制御や輻輳回避制御、タイムア
ウトを発生させたデータ以降を全て再送するなどの制御
を行っている。

【０００３】図１５（ａ）は上記従来のＴＣＰにおける
確認応答受信時の処理を示すフローチャートである。図
１５（ａ）において、確認応答を受信すると、その時の
ウインドウ・サイズ（確認応答を受信したとき、確認応
答を待たずに送信できるデータの大きさ）が既定サイズ
（確認応答を待たずに送信できるデータの最大値）より
小さいかを調べ、既定サイズの場合には処理を終了す
る。また、既定サイズより小さい場合には、ウィンドウ
・サイズが閾値ｓｓ＿ｔｈｒｅｓｈより大きいかを調べ
る。上記閾値ｓｓ＿ｔｈｒｅｓｈはスロースタートと輻
輳回避を分ける閾値であり、その初期値は例えば６５５
３５バイトに設定され、輻輳回避制御時には上記閾値ｓ
ｓ＿ｔｈｒｅｓｈはウィンドウ・サイズと既定サイズの
小さい方の半分となる。スロースタート時には、上記閾
値は十分大きいので、ウインドウ・サイズを１パケット
分増加して処理を終了する。また、輻輳回避制御時に
は、ウィンドウ・サイズと等しいパケット数の確認応答
（Ａｃｋ）を受信毎にウィンドウ・サイズを１パケット
分増加する。

【０００４】図１５（ｂ）は従来のＴＣＰにおけるタイ
ムアウト発生時の処理を示すフローチャートである。タ
イムアウトが発生すると、図１５（ｂ）に示すようにウ
ィンドウ・サイズを１パケット分に設定し、Ａｃｋ受信
済データ番号とウィンドウ・サイズの和を、ウィンドウ
番号と次送信データ番号に設定する。図１５（ｃ）は従
来のＴＣＰにおけるデータ送信処理を示すフローチャー
トである。データ送信に際して、図１５（ｃ）に示すよ
うに、次送信データ番号とウィンドウ番号を比較し、次
送信データ番号がウィンドウ番号より大きい場合には処
理を終了する。また、次送信データ番号がウィンドウ番
号より大きくない場合には、データを送信し、送信した
データ番号に１加えたものを次送信データ番号に設定す
る。図１５（ｄ）は従来のＴＣＰにおける確認応答受信
時のポインタ設定フローチャートである。確認応答（Ａ
ｃｋ）を受信するとＡｃｋ受信済データ番号にＡｃｋ内
データ番号を設定し、ウィンドウ番号にＡｃｋ受信済デ
ータ番号と図１５（ａ）で求めたウィンドウ・サイズの
和を設定する。

【０００５】図１６は従来のＴＣＰにおけるデータ送信
開始時のデータ送信シーケンスを示す図である。データ
送信開始時、従来のＴＣＰにおいては、図１５（ａ）の
フローチャートに示したように、ウィンドウ・サイズを
既定値に達するまで１パケットずつ増加させる（スロー
スタート時）。したがって、送信するパケット数は図１
６に示すように増加する。なお、以下の説明では送信側
から受信側へ送るべきデータが説明に必要な分は十分あ
るとし、確認応答を待たずに送信できるデータの最大値
である既定サイズは８パケット分（例えば：１４６０バ
イト×８＝１１．６８ｋバイト）であるとして説明す
る。

【０００６】送信を開始したとき、ウィンドウ・サイズ
は１であり、図１６に示すように、まず、送信側から受
信側にデータＤ１を送信する。受信側から確認応答Ａｃ
ｋ１が送られてくると、ウィンドウ・サイズは２とな
り、送信側から受信側にデータＤ２，Ｄ３を送信する。
次いで、確認応答Ａｃｋ２を受信すると、ウィンドウ・
サイズは３となり、データＤ４，Ｄ５を送信する（ウィ
ンドウ・サイズが３であり、確認応答Ａｃｋ２を受信し
ているので、データＤ３〜Ｄ５を送信することができる
がデータＤ３は送信済）。次に、確認応答Ａｃｋ３を受
信すると、ウィンドウ・サイズは４となり、データＤ
６，Ｄ７を送信する（ウィンドウ・サイズが４であり、
確認応答Ａｃｋ３を受信しているのでデータＤ４〜Ｄ７
を送信することができる）。以下同様にして確認応答を
受信する毎にウインドウ・サイズを１ずつ増加させなが
らデータを送信する。図１７は上記従来のＴＣＰにおけ
る送信開始時の出力パケット数の変化を示す図であり、
出力パケット数は同図に示すように指数関数的に上昇す
る。

【０００７】図１８は、タイムアウト発生時におけるデ
ータ送信シーケンスを示す図である。タイムアウト発生
時、従来のＴＣＰにおいては、図１５（ｂ）のフローチ
ャートに示したように、ウィンドウ・サイズを１パケッ
トに設定し、Ａｃｋ受信済データ番号とウィンドウ・サ
イズの和を、ウィンドウ番号と次送信データ番号に設定
する。したがって、図１８に示すような送信シーケンス
となる。例えば、データＤ１２を送信したのち、データ
Ｄ１２の確認応答が送信側で所定時間内に受信できず、
タイムアウトが発生すると、ウィンドウ・サイズを１に
設定し、Ａｃｋ受信済データ番号Ａｃｋ１１とウィンド
ウ・サイズ１の和を、ウィンドウ番号と次送信データ番
号に設定する。したがって、ウィンドウ番号に１２が設
定され、次送信データ番号に１２が設定され、確認応答
を受信していないデータＤ１２が再送される。

【０００８】一方、確認応答Ａｃｋ１２が受信すると、
図１５のフローチャートに示したように、ウィンドウ・
サイズは２となり、データＤ１３，Ｄ１４を送信する。
次にＡｃｋ１３を受信すると、ウィンドウ・サイズは３
となり、データＤ１５，Ｄ１６を送信する。次にＡｃｋ
１４を受信すると、ウィンドウ・サイズは４となり、デ
ータＤ１７，Ｄ１８を送信する。Ａｃｋ１５を受信する
と、ウィンドウ・サイズは５となり、前記図１５（ａ）
に示したｓｓ＿ｔｈｒｅｓｈ（既定値８の半分である
４）よりウィンドウ・サイズが大きくなるので、前記し
たようにウインドウ・サイズと等しいパケット数の確認
応答（Ａｃｋ）を受信毎にウィンドウ・サイズを１パケ
ット分増加する。したがって、確認応答Ａｃｋ１６を受
信してもウィンドウ・サイズは５のままであり（データ
Ｄ１７〜Ｄ２１を送信できる）、データＤ２１を送信す
る。以下同様に、Ａｃｋ１７〜Ａｃｋ１９を受信しても
ウィンドウ・サイズは５のままであり、確認応答を受信
する毎にデータＤ２２〜Ｄ２４を送信する。確認応答Ａ
ｃｋ２０を受信すると、ウインドウ・サイズと等しいパ
ケット数の確認応答（Ａｃｋ）が受信されたので、ウィ
ンドウ・サイズを６として、データＤ２５、Ｄ２６を送
信する。以下、同様に出力パケット数を増加しながらデ
ータを送信する。

【０００９】図１９は上記従来のＴＣＰにおけるタイム
アウト発生時の出力パケット数の変化を示す図である。
ウィンドウ・サイズがｓｓ＿ｔｈｒｅｓｈを越えるまで
は、ウィンドウ・サイズを１パケットずつ増加させるス
ロースタートが行われ、出力パケット数は同図に示すよ
うに増加する。ウィンドウ・サイズがｓｓ＿ｔｈｒｅｓ
ｈを越えると、輻輳回避制御が行われ、出力パケット数
は同図に示すように増加する。そして、ウィンドウ・サ
イズが既定値に達すると、安定転送状態となる。

【００１０】

【発明が解決しようとする課題】以上のように、従来に
おいては、データ転送開始時にはスロースタート制御、
タイムアウト発生時にはスロースタート制御や輻輳回避
制御、タイムアウトを発生させたデータ以降を全て再送
するなどの制御を行っていた。しかし、信頼性の保証さ
れたデータリンク層（データ通信中のデータ損失はほと
んどなくあったとしても単発的に起こるデータリンク
層）においては、データリンク層におけるデータ再送の
ために発生するトランスポート層のタイムアウトに際
し、上記のように、それを発生させたデータ以降をトラ
ンスポート層で再送すると、既に受信側で得た同じデー
タを重複して送ってしまうこととなる。例えば前記図１
８のようにデータＤ１２でタイムアウトが発生した場合
には、データＤ１３〜Ｄ１９を重複して送ってしまうこ
ととなる。また、従来の方法では、スロースタート制御
・輻輳回避制御によって転送データ量を抑えてしまうた
め、スループットが落ちるという欠点がある。本発明は
上記した事情を考慮してなされたものであって、信頼性
の保証されたデータリンク層を利用した通信において、
スループットを向上させるためのトランスポート層にお
けるデータ転送方法を提供することを目的とする。

【００１１】

【課題を解決するための手段】図１（ａ）は本発明を用
いた確認応答受信時のフローチャートであり、図１
（ｂ）は本発明を用いたタイムアウト発生時のフローチ
ャートである。図１（ａ）（ｂ）において、ウインドウ
サイズは受信側からの確認応答（Ａｃｋ）を待たずに送
信側が送信できるデータの大きさ（量）であり、既定サ
イズは受信側からの確認応答（Ａｃｋ）を待たずに送信
側が送信できるデータの最大値（最大量）である。Ａｃ
ｋ受信済みデータ番号は、受信側から送られる受信側で
受信を完了したデータ番号情報が入った確認応答（Ａｃ
ｋ）を送信側で受けとり、その受信側で受信を完了した
データ番号を送信側で記憶する番号である。ウインドウ
番号はその時点での確認応答を待たずに送信できる最も
大きいデータ番号である（Ａｃｋ受信ずみデータ番号と
ウインドウサイズを加えたものがこれになる）。

【００１２】本発明においては、以下のようにして前記
課題を解決する。 （１）本発明の請求項１，４の発明においては、確認応
答を受けた際に確認応答を待たずに送信できるデータの
大きさであるウインドウサイズが、確認応答を受けた際
に確認応答を待たずに送信できるデータの最大値である
既定サイズより小さいとき、図１（ａ）に示すようにウ
インドウサイズを上記既定サイズまで一度に拡大した
り、また、ウィンドウサイズを確認応答を待たずに送信
できるデータの最大値にしたままでデータを送信する。
このため、従来のスロースタート制御や輻輳回避制御が
行われず、送信開始時に直ちにデータリンク層にあった
効率の良いデータ量でデータ転送を行うことができる。 （２）本発明の請求項２，４の発明においては、タイム
アウトが発生した場合、ウィンドウ番号を図１（ｂ）に
示すように設定する。そして、次送信データ番号を保持
しておき、タイムアウトを発生させたデータだけを再送
する。すなわち、、データ送信に際して、上記次送信デ
ータ番号と上記ウィンドウ番号を比較し、次送信データ
番号がウィンドウ番号より大きい場合にはデータを送信
せず、次送信データ番号がウィンドウ番号より大きくな
い場合には、上記保持しておいた次送信番号のデータを
送信し、送信したデータ番号に１加えたものを次送信デ
ータ番号に設定する。上記のように次送信データ番号を
保持しているので、データリンク層の再送によりタイム
アウトが発生してしまっても、タイムアウトを発生させ
たデータのみの再送しか行なわず、受信側で重複するデ
ータを送ることを最小限に抑えることができる。 （３）本発明の請求項３，６の発明においては、請求項
１，４の発明において、請求項２，５の発明のように、
タイムアウトが発生した場合、その時点までに送信した
データ番号を保持しておき、タイムアウトを発生させた
データだけを再送する。このため、送信開始時に直ちに
データリンク層にあった効率の良いデータ量でデータ転
送を行うことができるとともに、タイムアウトを発生さ
せたデータのみの再送しか行なわず、受信側で重複する
データを送ることを最小限に抑えることができる。

【００１３】

【発明の実施の形態】以下、本発明の実施の形態につい
て説明する。なお、本発明は、例えば、パソコン等の情
報処理装置、携帯電話、通信機器等のＣＰＵ、メモリ、
通信インタフェース、外部記憶装置、入力出力装置等か
ら構成されるシステムで実現することができ、以下の説
明ではこれらのシステムにおける処理についてフローチ
ャートにより説明する。また、以下では、前記したよう
に送信側から受信側へ送るべきデータが説明に必要な分
は十分あるとし、確認応答を待たずに送信できるデータ
の最大値である既定サイズは、例えば８パケット分（例
えば：１４６０バイト×８＝１１．６８ｋバイト）であ
るとして説明する。

【００１４】（１）実施例１ 図２は本発明の第１の実施例の処理を示すフローチャー
トである。図２（ａ）に確認応答受信時のウインドウサ
イズ増加のフローチャート、図２（ｂ）にタイムアウト
発生時のフローチャート、図２（ｃ）にデータ送信フロ
ーチャート、図２（ｄ）に確認応答（Ａｃｋ）受信時の
ポインタ設定フローチャートを示す。本実施例において
は、図２（ａ）に示すように確認応答受信時、ウィンド
ウ・サイズと既定サイズを比較し、ウィンドウ・サイズ
が既定サイズより小さい場合には、ウィンドウ・サイズ
を既定サイズまで増加させる。また、確認応答（Ａｃ
ｋ）を受信すると、図２（ｄ）に示すように、Ａｃｋ受
信済データ番号にＡｃｋ内データ番号を設定し、Ａｃｋ
受信済データ番号とウィンドウ・サイズの和をウィンド
ウ番号に設定する。タイムアウト発生時のフローチャー
ト、データ送信のフローチャートは前記図１５（ｂ）
（ｃ）と同じである。すなわち、前記したように、タイ
ムアウト発生時にはウィンドウ・サイズを１パケット分
に設定し、Ａｃｋ受信済データ番号とウィンドウ・サイ
ズの和を、ウィンドウ番号と次送信データ番号に設定す
る。また、データ送信に際して、次送信データ番号とウ
ィンドウ番号を比較し、次送信データ番号がウィンドウ
番号より大きい場合には処理を終了する。また、次送信
データ番号がウィンドウ番号より大きくない場合には、
データを送信し、送信したデータ番号に１加えたものを
次送信データ番号に設定する。

【００１５】図３にデータ送信開始時の出力パケット数
の変化を、図４にデータ送信開始時のシーケンス図を示
す。図４において、データ送信開始時、ウインドウサイ
ズは１パケット分であり一番始めのデータを１パケット
分（Ｄ１）を送る。それに対するＡｃｋ１を受信した
ら、ウインドウサイズと既定サイズを比べウインドウサ
イズの方が小さいのでウインドウサイズを８パケット分
まで一度に拡大する（ウインドウサイズに既定サイズを
代入する）。これにより、次にはデータＤ２〜Ｄ９まで
を確認応答なしに一度に送信できるようになる。したが
って、出力パケット数の変化は図３に示すようになる。
これに対し、従来の方法では、前記図１５（ａ）のフロ
ーチャートに示したようにＡｃｋを一つ受信するとウイ
ンドウサイズを既定サイズまで一つずつ増加させるた
め、出力パケット数は前記図１７に示したように指数的
に増加するが、上記第１の実施例に比べるとデータリン
ク層を有効に利用できていない。

【００１６】また、タイムアウトが発生した場合、本実
施例では、従来例と同様ウインドウサイズを１パケット
分に縮小しタイムアウトを発生させたデータを再送する
が〔図２（ｂ）（ｃ）〕、再送パケットに対するＡｃｋ
を受信すると、一度にウインドウサイズを既定サイズま
で拡大する。図５にタイムアウト発生時の本実施例のシ
ーケンス図を示す。同図に示すように、データＤ１２が
タイムアウトを発生させたとすると、図２（ｂ）のフロ
ーチャートに示すように、ウインドウサイズを１パケッ
ト分に設定し、ウインドウ番号、次送信データ番号を、
ＡｃＫ受信済みデータ番号「１１」にウインドウサイズ
１を足した「１２」に設定し、ウインドウ番号「１２」
のデータＤ１２を再送する。確認応答Ａｃｋ１２を受信
すると、図２（ａ）のフローチャートに示すように一度
にウインドウサイズを８パケットまで拡大し、データＤ
１３〜Ｄ２０を一度に送信する。ついで、確認応答Ａｃ
ｋ１３を受信するとデータＤ２１を送信する。以下同様
に確認応答を受信する毎にデータを送信する。タイムア
ウトが発生した場合における本実施例のパケット出力数
の変化を図６に示す。同図に示すように本実施例ではタ
イムアウト発生後、１パケットを送信後、安定転送状態
となる。

【００１７】これに対し、従来方法においては、タイム
アウトが発生すると、ウインドウサイズを１パケット分
に縮小しタイムアウトを発生させたデータを再送し、再
送パケットに対するＡｃｋを受信すると、前記図１８、
図１９に示したように、スロースタート／輻輳回避処理
によってウインドウサイズを徐々に増加（回復）する。

【００１８】（２）実施例２ 図７〜図８に本発明の第２の実施例のフローチャートを
示す。本実施例は、データ送信開始時の動作は前記従来
方法と同じだが、タイムアウト発生時、タイムアウトを
発生させたデータのみの再送しか行なわないようにし、
重複するデータを送ることを最小限に抑えたものであ
る。図７（ａ）は確認応答受信時のフローチャートであ
り従来例の図１５（ａ）と同じである。図７（ｂ）は本
実施例のタイムアウト発生時のポインタ設定フローチャ
ート、図８（ａ）はデータ送信フローチヤート、図８
（ｂ）は、確認応答受信時のポインタ設定のフローチャ
ートである。確認応答を受信すると、図７（ａ）に示す
ように、その時のウインドウ・サイズが既定サイズより
小さいかを調べ既定サイズの場合には処理を終了する。
また、既定サイズより小さい場合には、ウィンドウ・サ
イズが閾値ｓｓ＿ｔｈｒｅｓｈより大きいかを調べる。
スロースタート時には、ウインドウ・サイズを１パケッ
ト分増加して処理を終了する。輻輳回避制御時には、ウ
ィンドウ・サイズと等しいパケット数の確認応答（Ａｃ
ｋ）を受信毎にウィンドウ・サイズを１パケット分増加
する。

【００１９】タイムアウトが発生すると、図７（ｂ）に
示すように、ウィンドウ・サイズを１パケット分に設定
し、Ａｃｋ受信済データ番号とウィンドウ・サイズの和
を、ウィンドウ番号に設定し、ウィンドウ番号のデータ
を送信する。また、データ送信に際しては、前記従来例
と違い次送信データ番号を保持しておき、図８（ａ）に
示すように、次送信データ番号とウィンドウ番号を比較
し、次送信データ番号がウィンドウ番号より大きい場合
には処理を終了する。また、次送信データ番号がウィン
ドウ番号より大きくない場合には、上記保持しておいた
次送信番号のデータを送信し、送信したデータ番号に１
加えたものを次送信データ番号に設定する。また、確認
応答（Ａｃｋ）を受信すると、図８（ｂ）に示すよう
に、Ａｃｋ受信済データ番号にＡｃｋ内データ番号を設
定し、Ａｃｋ受信済データ番号とウィンドウ・サイズの
和をウィンドウ番号に設定する。

【００２０】図９に本実施例におけるタイムアウト発生
時のデータ送信のシーケンス図を示す。図９において、
データＤ１２がタイムアウトを発生させたとすると、そ
の時点でのＡｃｋ受信済みデータ番号は「１１」、次送
信データ番号は「２０」、ウインドウ番号は「１９」と
なる。次に、図７（ｂ）のフローチャートに示すよう
に、ウインドウサイズを１パケット分に設定し、ウイン
ドウ番号をＡｃＫ受信済みデータ番号「１１」にウイン
ドウサイズ１を足した「１２」に設定する。そして、ウ
インドウ番号「１２」のデータＤ１２を再送する。次に
図８（ａ）に示すデータ送信フローチャートの通り次送
信データ番号「２０」とウインドウ番号「１２」を比較
し、比較式が成り立つのでデータを送信せずに終了す
る。次に、Ａｃｋを受信したら図７（ａ）、図８
（ｂ）、図８（ａ）のフローチャートの順に従い処理を
行う。すなわち、Ａｃｋ１２を受信した場合、ウインド
ウサイズは１増えて「２」〔図７（ａ）〕、ＡｃＫ受信
済みデータ番号は「１２」、ウインドウ番号は「１４」
となり〔図８（ｂ）〕、次送信データ番号は「２０」な
のでデータは送信されない。

【００２１】次にＡｃＫ１３を受信した場合は、ウイン
ドウサイズは「３」、ＡｃＫ受信済みデータ番号は「１
３」、ウインドウ番号は「１６」となり、次送信データ
番号は「２０」なのでまだデータは送信されない。同様
にＡｃｋ１４を受信してもまだデータは送信されない。
Ａｃｋ１５を受信したときに、ウインドウサイズは
「５」、ＡｃＫ受信済みデータ番号は「１５」、ウイン
ドウ番号は「２０」となり、次送信データ番号は「２
０」なのでデータＤ２０が送信される。データＤ２０を
送信したら次送信データ番号を「２１」に設定する。以
上のように本実施例によれば、次送信データ番号を保持
しておき、送信に際し、次送信データ番号とウィンドウ
番号を比較し、次送信データ番号がウィンドウ番号より
大きい場合にはデータを送信しないようにしているの
で、データＤ１３〜Ｄ１９が重複して送信されることが
ない。

【００２２】（３）実施例３ 図１０〜図１１に本発明の第３の実施例のフローチャー
トを示す。本実施例は、データ送信開始時、前記第１の
実施例のようにウィンドウ・サイズを１パケットから既
定サイズまで一度に拡大し、タイムアウト発生時、前記
第２の実施例に示したようにタイムアウトを発生させた
データのみの再送しか行なわないようにしたものであ
る。図１０（ａ）は確認応答受信時のウィンドウ・サイ
ズ増加のフローチャートであり、前記図２（ａ）に示し
たフローチャートと同じである。図１０（ｂ）はタイム
アウト発生時のポインタ設定フローチャート、図１１
（ａ）はデータ送信フローチヤートであり、前記図７
（ｂ）、図８（ａ）と同じである。また、図１１（ｂ）
は確認応答受信時のポインタ設定のフローチャートであ
り、前記図８（ｂ）と同じである。

【００２３】本実施例においては、図１０（ａ）に示す
ように確認応答受信時、ウィンドウ・サイズと既定サイ
ズを比較し、ウィンドウ・サイズが既定サイズより小さ
いか場合には、ウィンドウ・サイズを既定サイズまで増
加させる。したがって、第１の実施例のようにデータ送
信開始時、Ａｃｋ１を受信したら、ウインドウサイズを
１パケット分から８パケット分まで一度に拡大する。こ
れにより、前記図４に示したようにデータＤ２〜Ｄ９ま
でを確認応答なしに一度に送信できるようになる。した
がって、出力パケット数の変化は図３に示すようにな
る。

【００２４】また、タイムアウト発生時には、前記第２
の実施例に示したように重複したデータを送信しないよ
うに動作する。本実施例のタイムアウトを発生時のシー
ケンス図を図１２に示す。図１２のシーケンス図に示す
ように、データＤ１２がタイムアウトを発生させたとす
ると、その時点でのＡｃｋ受信済みデータ番号は「１
１」、次送信データ番号は「２０」、ウインドウ番号は
「１９」となる。次に図１０（ｂ）のフローチャートに
示す通りウインドウサイズを１パケット分に設定し、ウ
インドウ番号をＡｃｋ受信済みデータ番号「１１」にウ
インドウサイズ１を足した「１２」に設定する。そし
て、ウインドウ番号「１２」のデータＤ１２を再送す
る。次いで図１１（ａ）のデータ送信フローチャートの
通り次送信データ番号「２０」とウインドウ番号「１
２」を比較し、比較式が成り立つのでデータを送信せず
に終了する。

【００２５】次に、確認応答（Ａｃｋ）を受信したら図
１０（ａ）、図１１（ｂ）、図１１（ａ）のフローチャ
ートにより処理を行う。すなわち、Ａｃｋ１２を受信し
たのでウインドウサイズを一度に「８」まで拡張し〔図
１０（ａ）〕、Ａｃｋ受信済みデータ番号は「１２」、
ウインドウ番号は「２０」となり〔図１１（ｂ）〕、次
送信データ番号は「２０」なのでデータＤ２０が送信さ
れる〔図１１（ａ）〕。データＤ２０を送信したら次送
信データ番号を「２１」に設定する。次にＡｃｋ１３を
受信すると、ウインドウサイズは「８」、Ａｃｋ受信済
みデータ番号は「１３」、ウインドウ番号は「２１」と
なり、次送信データ番号は「２１」なのでデータＤ２１
が送信される。データＤ２１を送信したら次送信データ
番号を「２２」に設定する。以下同様に順次データが送
信される。以上のように本実施例においては、データ送
信開始時、ウインドウサイズを１パケットから一度に８
パケットまで拡大しているので、第１の実施例のように
効率のよいデータ転送を行うことができる。また、タイ
ムアウト発生時には、本実施例においては、第２の実施
例と同様、データが重複して送信されることがない。

【００２６】（４）実施例４ 本実施例は、データ送信開始時からウィンドウ・サイズ
を既定値（例えば８パケット分）にしておくようにした
ものである。本実施例のデータ送信開始時の出力パケッ
ト数の変化を図１３に示し、また、データ送信開始時の
シーケンス図を図１４に示す。図１４に示すように、デ
ータ送信開始時、データＤ１〜Ｄ８の８パケット分のデ
ータを送出し、Ａｃｋ１が受信されたらデータＤ９を送
信し、Ａｃｋ２が受信されたらデータＤ１０、Ａｃｋ３
が受信されたデータＤ１１を送信する。以下、同様にＡ
ｃｋが受信される毎にデータを順次送信する。以上のよ
うに本実施例においては、データ送信開始時からウイン
ドウサイズを既定サイズの８パケット分にしておくの
で、データＤ１〜Ｄ８を最初から送信が可能となる。

【００２７】

【発明の効果】以上説明したように、本発明において
は、以下の効果を得ることができる。 （１）ウインドウサイズを既定サイズまで一度に拡大し
たり、また、ウィンドウサイズを確認応答を待たずに送
信できるデータの最大値にしたままでデータを送信する
ようにしているので、従来のスロースタート制御や輻輳
回避制御が行われず、送信開始時に直ちにデータリンク
層にあった効率の良いデータ量でデータ転送を行うこと
ができる。このため、データ転送のスループットの向上
に寄与することができる。 （２）タイムアウトが発生したとき、タイムアウトを発
生させたデータのみの再送しか行なわないので、受信側
で重複するデータを送ることを最小限に抑えることがで
き、タイムアウト発生時に直ぐにデータリンク層を有効
に利用する状態とすることが可能となる。このため、デ
ータ転送のスループットの向上に寄与することができ
る。

【図面の簡単な説明】

【図１】本発明の原理を示すフローチャートである。

【図２】本発明の第１の実施例の処理を示すフローチャ
ートである。

【図３】第１の実施例のデータ送信開始時の出力パケッ
ト数の変化を示す図である。

【図４】第１の実施例のデータ送信開始時のシーケンス
図である。

【図５】第１の実施例のタイムアウト発生時のシーケン
ス図である。

【図６】第１の実施例においてタイムアウトが発生した
場合のパケット出力数の変化を示す図である。

【図７】本発明の第２の実施例のフローチャート（１）
である。

【図８】本発明の第２の実施例のフローチャート（２）
である。

【図９】第２の実施例のタイムアウト発生時のシーケン
ス図である。

【図１０】本発明の第３の実施例のフローチャート
（１）である。

【図１１】本発明の第３の実施例のフローチャート
（２）である。

【図１２】第３の実施例のタイムアウト発生時のシーケ
ンス図である。

【図１３】第４の実施例のデータ送信開始時の出力パケ
ット数の変化を示す図である。

【図１４】第４の実施例のデータ送信開始時のシーケン
ス図である。

【図１５】従来のＴＣＰにおける処理を示すフローチャ
ートである。

【図１６】従来のＴＣＰにおけるデータ送信開始時のデ
ータ送信シーケンスを示す図である。

【図１７】従来のＴＣＰにおける送信開始時の出力パケ
ット数の変化を示す図である。

【図１８】従来のＴＣＰにおけるタイムアウト発生時に
おけるデータ送信シーケンスを示す図である。

【図１９】従来のＴＣＰにおけるタイムアウト発生時の
出力パケット数の変化を示す図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 栗田 敏彦 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 竹間 智 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 徳世 雅永 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 谷口 徹哉 東京都千代田区永田町二丁目11番１号 エ ヌ・ティ・ティ移動通信網株式会社内 (72)発明者 久永 隆則 東京都千代田区永田町二丁目11番１号 エ ヌ・ティ・ティ移動通信網株式会社内 (72)発明者 近田 倫康 東京都千代田区永田町二丁目11番１号 エ ヌ・ティ・ティ移動通信網株式会社内 (72)発明者 桑田 大介 東京都千代田区永田町二丁目11番１号 エ ヌ・ティ・ティ移動通信網株式会社内 Ｆターム(参考） 5B089 GB01 HB02 KA05 KA08 MC06 ME08 5K030 GA03 HA08 HC09 HC13 HD06 JL01 JL04 JT03 JT09 LA08 LB02 LB18 LC03 LC05 MB02 5K033 AA01 CB06 CC01 DA01 DA06 DA19 DB16 9A001 CC03

Claims (6)

【特許請求の範囲】
1. 【請求項１】 信頼性が保証されたデータリンク層を利
   用したトランスポート層におけるデータ通信方法であっ
   て、 確認応答を受けた際に確認応答を待たずに送信できるデ
   ータの大きさであるウインドウサイズが、確認応答を受
   けた際に確認応答を待たずに送信できるデータの最大値
   である既定サイズより小さいとき、ウインドウサイズを
   上記既定サイズまで一度に拡大することを特徴とするト
   ランスポート層におけるデータ転送方法。
2. 【請求項２】 信頼性が保証されたデータリンク層を利
   用したトランスポート層におけるデータ通信方法であっ
   て、 タイムアウトが発生した場合、その時点までに送信した
   データ番号を保持しておき、タイムアウトを発生させた
   データだけを再送することを特徴とするトランスポート
   層におけるデータ転送方法。
3. 【請求項３】 タイムアウトが発生した場合、その時点
   までに送信したデータ番号を保持しておき、タイムアウ
   トを発生させたデータだけを再送することを特徴とする
   請求項１のトランスポート層におけるデータ転送方法。
4. 【請求項４】 信頼性が保証されたデータリンク層を利
   用したトランスポート層におけるデータ通信プログラム
   を記録した記録媒体であって、 上記プログラムは、確認応答を受けた際に確認応答を待
   たずに送信できるデータの大きさであるウインドウサイ
   ズが、確認応答を受けた際に確認応答を待たずに送信で
   きるデータの最大値である既定サイズより小さいとき、
   ウインドウサイズを上記既定サイズまで一度に拡大する
   ことを特徴とするトランスポート層におけるデータ転送
   プログラムを記録した記録媒体。
5. 【請求項５】 信頼性が保証されたデータリンク層を利
   用したトランスポート層におけるデータ通信方法プログ
   ラムを記録した記録媒体であって、 タイムアウトが発生した場合、その時点までに送信した
   データ番号を保持しておき、タイムアウトを発生させた
   データだけを再送することを特徴とするトランスポート
   層におけるデータ転送プログラムを記録した記録媒体。
6. 【請求項６】 タイムアウトが発生した場合、その時点
   までに送信したデータ番号を保持しておき、タイムアウ
   トを発生させたデータだけを再送することを特徴とする
   請求項３のトランスポート層におけるデータ転送プログ
   ラムを記録した記録媒体。