JP2010130610A - データ伝送システム - Google Patents
データ伝送システム Download PDFInfo
- Publication number
- JP2010130610A JP2010130610A JP2008306015A JP2008306015A JP2010130610A JP 2010130610 A JP2010130610 A JP 2010130610A JP 2008306015 A JP2008306015 A JP 2008306015A JP 2008306015 A JP2008306015 A JP 2008306015A JP 2010130610 A JP2010130610 A JP 2010130610A
- Authority
- JP
- Japan
- Prior art keywords
- data
- communication node
- proxy server
- communication
- segment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】データ伝送速度が異なる伝送路を介してTCPによりデータ通信を行う際に、ゼロウィンドウプローブセグメントの発生を防ぎ、伝送効率の低下を防ぐ。
【解決手段】送信したデータセグメントに損失が生じたときに、輻輳ウィンドウのサイズを初期化して小さくするTCPの機能を利用して、プロキシサーバ16で、ウィンドウサイズの残り容量が、あらかじめ決められた値より少なくなったときに、クライアント装置14またはサーバ装置20から送られてきたデータセグメントに対するACKセグメントを送らないように制御する。この制御により、クライアント装置14またはサーバ装置20に、擬似的に、有線ネットワークシステム10に輻輳が生じたと判断させることができ、これらからプロキシサーバ16への実行伝送レートを下げさせる。
【選択図】図1
【解決手段】送信したデータセグメントに損失が生じたときに、輻輳ウィンドウのサイズを初期化して小さくするTCPの機能を利用して、プロキシサーバ16で、ウィンドウサイズの残り容量が、あらかじめ決められた値より少なくなったときに、クライアント装置14またはサーバ装置20から送られてきたデータセグメントに対するACKセグメントを送らないように制御する。この制御により、クライアント装置14またはサーバ装置20に、擬似的に、有線ネットワークシステム10に輻輳が生じたと判断させることができ、これらからプロキシサーバ16への実行伝送レートを下げさせる。
【選択図】図1
Description
本発明は、所定のプロトコル、例えば、TCP(Transmission Control Protocol)によりデータの通信を行うデータ通信システムに関する。
例えば、特許文献1は、2つの有線通信ネットワーク間で、無線通信路を介してたデータ通信を行うシステムが開示されている。
しかしながら、一般に、有線通信ネットワークにおけるデータの伝送速度は、これらの間を接続する無線通信路の伝送速度よりも大きく、無線通信路が、このようなシステムにおけるボトルネックとなってしまうことがある。
特会2005−348230号公報
しかしながら、一般に、有線通信ネットワークにおけるデータの伝送速度は、これらの間を接続する無線通信路の伝送速度よりも大きく、無線通信路が、このようなシステムにおけるボトルネックとなってしまうことがある。
本願発明は、上述のような背景からなされたものであって、ネットワーク間を、これらのネットワークにおけるよりもデータ伝送速度が低い通信回線で接続して、TCPによりデータ伝送を行うときに、TCPに起因する伝送効率の低下を防ぐように改良された通信システムを低供することを目的とする。
上記目的を達成するために、本願にかかる第1のデータ通信システムは、予め決められた第1のデータ伝送速度の伝送路と、前記伝送路を介して接続され、前記第1のデータ伝送速度よりも速い第2のデータ伝送速度の複数のネットワークと、前記ネットワークそれぞれに1つ以上、接続された複数の通信ノードと、前記ネットワークの1つ以上に接続され、同じネットワークを介して接続された前記通信ノードからデータを受信して受信バッファに記憶し、この通信ノードと、他のネットワークの通信ノードとの間で、予め決められたプロトコルを代理してデータ伝送を実行するプロキシサーバとを有するデータ伝送システムであって、前記プロトコルにおいて、前記プロキシサーバは、同じネットワークに接続された通信ノードからデータを受信したときに、この通信ノードに対して、このデータを受信したことと、前記受信バッファの残り容量を示す第1の信号を通信相手の通信ノードに返し、前記通信ノードは、予め決められた第1の時間が経過する前に、前記第1の信号を受けると、次のデータを前記プロキシサーバに送信し、前記通信ノードは、同じネットワークに接続された前記プロキシサーバから返された前記第1の信号が、その受信バッファの残り容量が0であることを示したときに、定期的に、前記プロキシサーバに、その受信バッファの残り容量があるか否かを問い合わせる第2の信号を送信し、前記通信ノードは、前記データを送信してから、前記第1の時間が経過する前に、前記通信ノードに返されたとき以外に、前記通信ノードがデータを再送する機能を有し、前記プロキシサーバは、同じネットワークに接続された前記通信ノードからデータを受信したときに、前記第1の信号の送信を、前記第1の時間より短い第2の時間だけ遅らせて、この通信ノードに返す。
また、本願にかかる第2のデータ伝送システムは、予め決められた第1のデータ伝送速度の伝送路と、前記伝送路を介して接続され、前記第1のデータ伝送速度よりも速い第2のデータ伝送速度の複数のネットワークと、前記ネットワークそれぞれに1つ以上、接続された複数の通信ノードと、前記ネットワークの1つ以上に接続され、同じネットワークを介して接続された前記通信ノードから、伝送されるデータを構成するデータセグメントを受信して受信バッファに記憶し、この通信ノードと、他のネットワークの通信ノードとの間で、予め決められたプロトコルを代理してデータ伝送を実行するプロキシサーバとを有するデータ伝送システムであって、前記プロトコルにおいて、前記プロキシサーバは、同じネットワークに接続された通信ノードから前記データセグメントを受信したときに、この通信ノードに対して、このデータセグメントを受信したことを示す第1の信号を通信相手の通信ノードに返し、前記通信ノードは、送信した全ての前記データセグメントに対応する全ての前記第1の信号を受けたときに、一度に送信する前記データのデータ量を増やし、これ以外のときには、前記データのデータ量を減らす機能を有し、前記プロキシサーバは、前記受信バッファの残り容量が、予め決められた値よりも多いときにのみ、前記データセグメントを送信した通信ノードに対して、前記第1の信号を返す。
また、本願にかかる第3のデータ伝送システムは、予め決められた第1のデータ伝送速度の伝送路と、前記伝送路を介して接続され、前記第1のデータ伝送速度よりも速い第2のデータ伝送速度の複数のネットワークと、前記ネットワークそれぞれに1つ以上、接続された複数の通信ノードと、前記ネットワークの1つ以上に接続され、同じネットワークを介して接続された前記通信ノードから伝送されるデータを構成するデータセグメントを受信して受信バッファに記憶し、この通信ノードと、他のネットワークの通信ノードとの間で、予め決められたプロトコルを代理してデータ伝送を実行するプロキシサーバとを有するデータ伝送システムであって、前記プロトコルにおいて、前記プロキシサーバは、同じネットワークに接続された通信ノードからデータセグメントを受信したときに、この通信ノードに対して、このデータセグメントを受信したことと、前記受信バッファの残り容量を示す第1の信号を通信相手の通信ノードに返し、前記通信ノードは、予め決められた第1の時間が経過する前に、前記第1の信号を受けると、次のデータセグメントを前記プロキシサーバに送信し、前記通信ノードは、同じネットワークに接続された前記プロキシサーバから返された前記第1の信号が、その受信バッファの残り容量が0であることを示したときに、定期的に、前記プロキシサーバに、その受信バッファの残り容量があるか否かを問い合わせる第2の信号を送信し、前記通信ノードは、前記データセグメントを送信してから、前記第1の時間が経過する前に、前記通信ノードに返されたとき以外に、前記通信ノードがデータセグメントを再送し、前記通信ノードは、送信した全ての前記データセグメントに対応する全ての前記第1の信号を受けたときに、一度に送信する前記データのデータ量を増やし、これ以外のときには、前記データのデータ量を減らす機能を有し、前記プロキシサーバは、同じネットワークに接続された前記通信ノードからデータセグメントを受信したときに、前記第1の信号の送信を、前記第1の時間より短い第2の時間だけ遅らせて、この通信ノードに返す第1の処理、および、前記プロキシサーバは、前記受信バッファの残り容量が、予め決められた値よりも多いときにのみ、前記データセグメントを送信した通信ノードに対して、前記第1の信号を返す第2の処理、またはこれらのいずれかを行う。
本願発明によれば、ネットワーク間を、これらのネットワークにおけるよりもデータ伝送速度が低い通信回線で接続して、TCPによりデータ伝送を行うときに、TCPに起因する伝送効率の低下を防ぐことができる。
[本願発明がなされるに至った経緯]
本願発明の説明に先立ち、その理解を助けるために、まず、本願発明がなされるに至った経緯を説明する。
図1は、本願発明が適用されるデータ通信システム1の構成を例示する図である。
図1に示すように、データ通信システム1は、それぞれの内部で、例えば100Mbpsでデータ通信が可能な第1の有線ネットワークシステム10−1と、第2の有線ネットワークシステム10−2とが、無線通信装置18−1,18−2、および、例えば、9.6kbpsでデータ伝送が可能な無線通信路を介して、通信可能に接続されて構成される。
第1の有線ネットワークシステム10−1には、クライアント装置14−1〜14−3、TCP透過型のProxy(プロキシ)サーバ16−1が、ネットワーク12−1を介して接続されて構成される。
有線ネットワークシステム10−2には、クライアント装置14−4,14−5、プロキシサーバ16−2、および、クライアント装置14−1〜14−5からの要求に応じて処理を行い、処理結果を返すサーバ装置20が、ネットワーク12−2を介して接続されて構成される。
本願発明の説明に先立ち、その理解を助けるために、まず、本願発明がなされるに至った経緯を説明する。
図1は、本願発明が適用されるデータ通信システム1の構成を例示する図である。
図1に示すように、データ通信システム1は、それぞれの内部で、例えば100Mbpsでデータ通信が可能な第1の有線ネットワークシステム10−1と、第2の有線ネットワークシステム10−2とが、無線通信装置18−1,18−2、および、例えば、9.6kbpsでデータ伝送が可能な無線通信路を介して、通信可能に接続されて構成される。
第1の有線ネットワークシステム10−1には、クライアント装置14−1〜14−3、TCP透過型のProxy(プロキシ)サーバ16−1が、ネットワーク12−1を介して接続されて構成される。
有線ネットワークシステム10−2には、クライアント装置14−4,14−5、プロキシサーバ16−2、および、クライアント装置14−1〜14−5からの要求に応じて処理を行い、処理結果を返すサーバ装置20が、ネットワーク12−2を介して接続されて構成される。
なお、以下、クライアント装置14−1〜14−5など、複数あり得る構成部分のいずれかを特定せずに示すときには、単にクライアント装置14とも記す。
また、CPU、メモリ、入出力装置および通信装置などから構成され、プログラム(図示せず)をこれらのハードウェアを具体体に利用して実行し、情報処理を行い、他の装置と、有線通信回線(ネットワーク12)または無線通信路を介して通信を行いうるクライアント装置14、無線通信装置18およびサーバ装置20を、通信ノードと総称することがある。
データ通信システム1は、これらの構成部分により、2つの有線ネットワークシステム10それぞれの中に閉じたデータ通信、または、2つの有線ネットワークシステム10の間でノード間のデータ通信を実現する。
また、CPU、メモリ、入出力装置および通信装置などから構成され、プログラム(図示せず)をこれらのハードウェアを具体体に利用して実行し、情報処理を行い、他の装置と、有線通信回線(ネットワーク12)または無線通信路を介して通信を行いうるクライアント装置14、無線通信装置18およびサーバ装置20を、通信ノードと総称することがある。
データ通信システム1は、これらの構成部分により、2つの有線ネットワークシステム10それぞれの中に閉じたデータ通信、または、2つの有線ネットワークシステム10の間でノード間のデータ通信を実現する。
図2は、図1に示したプロキシサーバ16の第1の動作例を示す図である。
図2に示した場合においては、例えば、有線ネットワークシステム10−1において、プロキシサーバ16−1は、クライアント装置14から、サーバ装置20へのデータセグメントを受けるたびに、クライアント装置14へACK(Acknowledge)セグメントを応答する。
なお、上記データセグメントは、クライアント装置14およびサーバ装置20の輻輳バッファ(図示せず)に、プロキシサーバ16への送信のために格納されたデータが分割されたものであって、全てのデータセグメントの集合が、1つのデータを構成する。
同様に、図2に示した場合においては、例えば、有線ネットワークシステム10−2において、プロキシサーバ16−2は、サーバ装置20から、有線ネットワークシステム10−1内のクライアント装置14へのデータセグメントを受けるたびに、サーバ装置20へACKセグメントを応答する。
図2に示した場合においては、例えば、有線ネットワークシステム10−1において、プロキシサーバ16−1は、クライアント装置14から、サーバ装置20へのデータセグメントを受けるたびに、クライアント装置14へACK(Acknowledge)セグメントを応答する。
なお、上記データセグメントは、クライアント装置14およびサーバ装置20の輻輳バッファ(図示せず)に、プロキシサーバ16への送信のために格納されたデータが分割されたものであって、全てのデータセグメントの集合が、1つのデータを構成する。
同様に、図2に示した場合においては、例えば、有線ネットワークシステム10−2において、プロキシサーバ16−2は、サーバ装置20から、有線ネットワークシステム10−1内のクライアント装置14へのデータセグメントを受けるたびに、サーバ装置20へACKセグメントを応答する。
しかしながら、上述のように、ネットワーク12内部のデータ伝送速度は100Mbpsであるのに対して、無線通信路のデータ伝送速度は9.6kpsしかないので、無線通信路は、データ通信システム1におけるデータ伝送のボトルネックとなる。
一方、ACKセグメントを受けるたびに、クライアント装置14およびサーバ装置20は、100Mbpsでプロキシサーバ16に対してデータセグメントを送信する可能性があるが、プロキシサーバ16が受けたデータセグメントは、9.6kbpsの非常に低速でしか、無線通信路を介して通信相手に伝送されない。
一方、ACKセグメントを受けるたびに、クライアント装置14およびサーバ装置20は、100Mbpsでプロキシサーバ16に対してデータセグメントを送信する可能性があるが、プロキシサーバ16が受けたデータセグメントは、9.6kbpsの非常に低速でしか、無線通信路を介して通信相手に伝送されない。
従って、プロキシサーバ16の受信バッファ(図示せず)はに、次第にデータセグメントが溜まってゆくことになる。
なお、図2に点線の矢印で示したセグメントは、有線ネットワークシステム10−2のプロキシサーバ16−1が、サーバ装置20の代理で送信するACKセグメントであり、プロキシサーバ16−2のサーバ装置20に対して送信されないデータセグメントは、プロキシサーバ16−1で破棄される。
なお、図2に点線の矢印で示したセグメントは、有線ネットワークシステム10−2のプロキシサーバ16−1が、サーバ装置20の代理で送信するACKセグメントであり、プロキシサーバ16−2のサーバ装置20に対して送信されないデータセグメントは、プロキシサーバ16−1で破棄される。
図3は、図1に示したプロキシサーバ16が、図2に例示した動作を行うときに、クライアント装置14またはサーバ装置20からプロキシサーバ16に送信されるゼロウィンドウプローブセグメントを例示する図である。
TCPにおいては、プロキシサーバ16のウィンドウウサイズ(受信バッファ)により通信フロー制御が行なわれ、プロキシサーバ16は、ウィンドウウサイズ一杯にデータセグメントが溜まると、図3に「*」を付して示す期間、クライアント装置14またはサーバ装置20に、ウィンドウウサイズ=0を示すACKセグメントを送信することになる。
TCPにおいては、プロキシサーバ16のウィンドウウサイズ(受信バッファ)により通信フロー制御が行なわれ、プロキシサーバ16は、ウィンドウウサイズ一杯にデータセグメントが溜まると、図3に「*」を付して示す期間、クライアント装置14またはサーバ装置20に、ウィンドウウサイズ=0を示すACKセグメントを送信することになる。
TCPにおいては、上述のウィンドウウサイズ=0のACKセグメントを受けたクライアント装置14またはサーバ装置20は、プロキシサーバ16に、定期的に、ウィンドウウサイズに空きが生じた(回復した)か否かを問い合わせるゼロウィンドウプローブセグメントを送信する。
このゼロウィンドウプローブセグメントには、有効なデータ(実データ)は1バイトしか含まれず、他には、IP(Internet Protocol)ヘッダと、TCPヘッダとが合計40バイト含まれる。
つまり、ゼロウィンドウプローブセグメントの伝送は、1バイトの実データを送るために40バイトのヘッダデータを用いるので、データ通信システム1の伝送効率を大幅に低めることになる。
このゼロウィンドウプローブセグメントには、有効なデータ(実データ)は1バイトしか含まれず、他には、IP(Internet Protocol)ヘッダと、TCPヘッダとが合計40バイト含まれる。
つまり、ゼロウィンドウプローブセグメントの伝送は、1バイトの実データを送るために40バイトのヘッダデータを用いるので、データ通信システム1の伝送効率を大幅に低めることになる。
有線ネットワークシステム10に単にプロキシサーバ16を設けると、TCPセッションの安定性を確保できる。
一方、上述のように、単にプロキシサーバ16を設けただけで、何も工夫しないと、データ通信システム1のようなシステムにおいては、無線通信路がボトルネックとなって、プロキシサーバ16の受信バッファ(ウィンドウサイズ)が空になり、ゼロウィンドウプローブセグメントの伝送が生じる可能性がある。
低速な無線通信路に起因するボトルネックに加えて、このゼロウィンドウプローブセグメントの伝送が生じると、さらに、データ通信システム1全体の伝送効率が低下してしまう
一方、上述のように、単にプロキシサーバ16を設けただけで、何も工夫しないと、データ通信システム1のようなシステムにおいては、無線通信路がボトルネックとなって、プロキシサーバ16の受信バッファ(ウィンドウサイズ)が空になり、ゼロウィンドウプローブセグメントの伝送が生じる可能性がある。
低速な無線通信路に起因するボトルネックに加えて、このゼロウィンドウプローブセグメントの伝送が生じると、さらに、データ通信システム1全体の伝送効率が低下してしまう
[本願発明にかかる第1の通信方式]
以下、図1に示したデータ通信システム1に、本発明にかかる改良された第1の通信方式を適用する場合を説明する。
データ通信システム1において、プロキシサーバ16のウィンドウサイズが0にならなければ、クライアント装置14およびサーバ装置20からのゼロウィンドウプローブセグメントは発生しない。
プロキシサーバ16のウィンドウサイズが0にならないようにするには、クライアント装置14およびサーバ装置20からのデータセグメントの送信頻度を、ウィンドウサイズが0にならないようにする程度に少なくするように制御すればよい。
本願発明にかかる通信方式は、TCPに従って、プロキシサーバ16からクライアント装置14およびサーバ装置20へのACKセグメントの応答時間を制御することにより、クライアント装置14およびサーバ装置20からのデータセグメントの送信頻度を制御し、プロキシサーバ16のウィンドウサイズが0にならないように工夫されている。
以下、図1に示したデータ通信システム1に、本発明にかかる改良された第1の通信方式を適用する場合を説明する。
データ通信システム1において、プロキシサーバ16のウィンドウサイズが0にならなければ、クライアント装置14およびサーバ装置20からのゼロウィンドウプローブセグメントは発生しない。
プロキシサーバ16のウィンドウサイズが0にならないようにするには、クライアント装置14およびサーバ装置20からのデータセグメントの送信頻度を、ウィンドウサイズが0にならないようにする程度に少なくするように制御すればよい。
本願発明にかかる通信方式は、TCPに従って、プロキシサーバ16からクライアント装置14およびサーバ装置20へのACKセグメントの応答時間を制御することにより、クライアント装置14およびサーバ装置20からのデータセグメントの送信頻度を制御し、プロキシサーバ16のウィンドウサイズが0にならないように工夫されている。
TCPにおいては、受信側(プロキシサーバ16)からのACKセグメントを待たずに1度に送信できるデータセグメントのバイト数は、受信側からのACKセグメントにより示されるウィンドウサイズ、および、送信側(クライアント装置14・サーバ装置20)の輻輳ウィンドウサイズ(受信側からのACKセグメント受信ごとに、送信側が、1度に送信するセグメント数を増やしてゆく動作;図5参照して後述)のいずれか少ない一方と決められる。
送信側は、上述のように決められるバイト数のデータセグメントを送信すると、受信側から返されるACKセグメントを待つ。
従って、受信側から送信側にACKセグメントを返す応答時間を長くすることにより、送信側が受信側にデータセグメントを送信する頻度を減らすことができ、その結果、送信側に、データセグメントをゆっくりと受信側に送信させることができる。
送信側は、上述のように決められるバイト数のデータセグメントを送信すると、受信側から返されるACKセグメントを待つ。
従って、受信側から送信側にACKセグメントを返す応答時間を長くすることにより、送信側が受信側にデータセグメントを送信する頻度を減らすことができ、その結果、送信側に、データセグメントをゆっくりと受信側に送信させることができる。
図4は、図1に示したプロキシサーバ16からクライアント装置14へのACKセグメントの送信制御を例示する図であって、(A)は、ACKセグメントの応答時間を制御しない場合を示し、(B)は、ACKセグメントの応答時間が長くなるように制御した場合を示す。
図4を参照すると分かるように、(A)に示したACKセグメントの応答時間を制御しない場合に比べて、(B)は、ACKセグメントの応答時間が長くなるように制御した場合の方が、プロキシサーバ16に溜まるデータセグメントの量が少ない。
図4を参照すると分かるように、(A)に示したACKセグメントの応答時間を制御しない場合に比べて、(B)は、ACKセグメントの応答時間が長くなるように制御した場合の方が、プロキシサーバ16に溜まるデータセグメントの量が少ない。
しかしながら、TCPにおいては、受信側から送信側へのACKセグメントの応答時間を遅らせすぎると、タイムアウトが生じて、送信側から受信側へのデータセグメントの再送制御が行われる。
つまり、ACKセグメントの応答時間を遅らせすぎると、不要なデータセグメントの再送が行われるので、受信側におけるACKセグメントの応答時間の遅延は、このようなデータセグメントの再送が生じない範囲とされなければならない。
このタイムアウトが生じる時間は、TCPにおいて規定されているので、ACKセグメントの応答時間は、TCPに規定されたタイムアウトが生じる時間より短く設定されている必要がある。
ACKセグメントの応答時間は、有線ネットワークシステム10内部のデータ伝送速度、および、ボトルネックとなる無線通信路のデータ伝送速度を考慮した最適な時間に調整可能とすることが望ましい。
データ通信システム1(図1)に対して、以上説明した本発明にかかる第1の通信方式を適用することにより、ゼロウィンドウプローブセグメントの発生が防止される。
なお、ACKセグメントの応答時間は、プロキシサーバ16の受信バッファの残り容量に応じて変更することができる(例えば、残り容量が、予め決められた値を下回ったときに、ACKセグメントの応答時間を長く変更する)。
つまり、ACKセグメントの応答時間を遅らせすぎると、不要なデータセグメントの再送が行われるので、受信側におけるACKセグメントの応答時間の遅延は、このようなデータセグメントの再送が生じない範囲とされなければならない。
このタイムアウトが生じる時間は、TCPにおいて規定されているので、ACKセグメントの応答時間は、TCPに規定されたタイムアウトが生じる時間より短く設定されている必要がある。
ACKセグメントの応答時間は、有線ネットワークシステム10内部のデータ伝送速度、および、ボトルネックとなる無線通信路のデータ伝送速度を考慮した最適な時間に調整可能とすることが望ましい。
データ通信システム1(図1)に対して、以上説明した本発明にかかる第1の通信方式を適用することにより、ゼロウィンドウプローブセグメントの発生が防止される。
なお、ACKセグメントの応答時間は、プロキシサーバ16の受信バッファの残り容量に応じて変更することができる(例えば、残り容量が、予め決められた値を下回ったときに、ACKセグメントの応答時間を長く変更する)。
[本発明にかかる第2の通信方式]
TCPにおいては、一度に伝送可能な全てのセグメントの受信側への送信に成功すると、その次の送信側の輻輳ウィンドウのサイズは、2倍に増やされる。
つまり、例えば、ある時点での送信側の輻輳ウィンドウのサイズが2kバイトであるときには、送信側は、2kバイトのデータを、複数のデータセグメントに分けて、一度に受信側に送信する。
受信側から、送信側が送信した全てのデータセグメントに対するACKセグメントが返されると、次の送信における送信側の輻輳ウィンドウのサイズは、4kバイトに増やされる。
TCPは、以上説明したように、送信側から受信側への実行伝送レートを、次第に増加させる仕組みを持っている。
TCPにおいては、一度に伝送可能な全てのセグメントの受信側への送信に成功すると、その次の送信側の輻輳ウィンドウのサイズは、2倍に増やされる。
つまり、例えば、ある時点での送信側の輻輳ウィンドウのサイズが2kバイトであるときには、送信側は、2kバイトのデータを、複数のデータセグメントに分けて、一度に受信側に送信する。
受信側から、送信側が送信した全てのデータセグメントに対するACKセグメントが返されると、次の送信における送信側の輻輳ウィンドウのサイズは、4kバイトに増やされる。
TCPは、以上説明したように、送信側から受信側への実行伝送レートを、次第に増加させる仕組みを持っている。
しかしながら、一度、輻輳(送信したデータセグメントに損失(ロス)が生じたと判断されたとき)が生じると、受信側の輻輳ウィンドウのサイズは、初期状態の一番少ないデータ量とされる。
つまり、TCPは、ネットワークが混んでいて、輻輳が生じたときには、送信側から受信側への実行伝送レートを下げる仕組みを有している。
つまり、TCPは、ネットワークが混んでいて、輻輳が生じたときには、送信側から受信側への実行伝送レートを下げる仕組みを有している。
図5は、TCPにおいて、図1に示したネットワーク12に輻輳が生じたときに、送信側から受信側への実行伝送レートを下げる制御を例示する図である。
図5に示すように、送信側が送信したデータセグメントが失われることなく、全て受信側に受信され、全てのデータセグメントに対するACKセグメントが返されている間は、輻輳ウィンドウのサイズは、順次、2倍ずつ大きくされる。
一方、図5に「**」を付したように、送信側が送信したデータセグメントに損失(ロス)が生じ、全てのデータセグメントに対するACKセグメントが返されなかった時には、送信側の輻輳ウィンドウのサイズは、初期状態に戻される。
図5に示すように、送信側が送信したデータセグメントが失われることなく、全て受信側に受信され、全てのデータセグメントに対するACKセグメントが返されている間は、輻輳ウィンドウのサイズは、順次、2倍ずつ大きくされる。
一方、図5に「**」を付したように、送信側が送信したデータセグメントに損失(ロス)が生じ、全てのデータセグメントに対するACKセグメントが返されなかった時には、送信側の輻輳ウィンドウのサイズは、初期状態に戻される。
以上のようなTCPの機能を利用して、プロキシサーバ16(受信側)で、ウィンドウサイズの残り容量が、あらかじめ決められた値より少なくなったときに、クライアント装置14またはサーバ装置20(送信側)から送られてきたデータセグメントに対するACKセグメントを送らないように制御する。
この制御により、プロキシサーバ16は、クライアント装置14またはサーバ装置20に、擬似的に、有線ネットワークシステム10に輻輳が生じたと判断させることができ、これらからプロキシサーバ16への実行伝送レートを下げることができる。
この制御により、プロキシサーバ16は、クライアント装置14またはサーバ装置20に、擬似的に、有線ネットワークシステム10に輻輳が生じたと判断させることができ、これらからプロキシサーバ16への実行伝送レートを下げることができる。
なお、第1の通信方式においてと同様に、プロキシサーバ16がクライアント装置14またはサーバ装置20に、擬似的に、有線ネットワークシステム10において輻輳が生じていると判断させるためにACKセグメントの送信を停止する際の閾値もまた、有線ネットワークシステム10内部のデータ伝送速度、および、ボトルネックとなる無線通信路のデータ伝送速度を考慮した最適な時間に調整可能とすることが望ましい。
また、第1の通信方式と、第2の通信方式は、適宜、組み合わせてデータ通信システム1に適応することができる。
データ通信システム1(図1)に対して、以上説明した本発明にかかる第2の通信方式を適用することにより、ゼロウィンドウプローブセグメントの発生が防止される。
また、第1の通信方式と、第2の通信方式は、適宜、組み合わせてデータ通信システム1に適応することができる。
データ通信システム1(図1)に対して、以上説明した本発明にかかる第2の通信方式を適用することにより、ゼロウィンドウプローブセグメントの発生が防止される。
本発明は、データの伝送のために利用することができる。
1・・・データ通信システム,10・・・有線ネットワークシステム,12・・・ネットワーク,14・・・クライアント装置,16・・・プロキシサーバ,18・・・無線通信装置,20・・・サーバ装置,
Claims (2)
- 予め決められた第1のデータ伝送速度の伝送路と、
前記伝送路を介して接続され、前記第1のデータ伝送速度よりも速い第2のデータ伝送速度の複数のネットワークと、
前記ネットワークそれぞれに1つ以上、接続された複数の通信ノードと、
前記ネットワークの1つ以上に接続され、同じネットワークを介して接続された前記通信ノードからデータを受信して受信バッファに記憶し、この通信ノードと、他のネットワークの通信ノードとの間で、予め決められたプロトコルを代理してデータ伝送を実行するプロキシサーバと
を有するデータ伝送システムであって、
前記プロトコルにおいて、
前記プロキシサーバは、同じネットワークに接続された通信ノードからデータを受信したときに、この通信ノードに対して、このデータを受信したことと、前記受信バッファの残り容量を示す第1の信号を通信相手の通信ノードに返し、
前記通信ノードは、予め決められた第1の時間が経過する前に、前記第1の信号を受けると、次のデータを前記プロキシサーバに送信し、
前記通信ノードは、同じネットワークに接続された前記プロキシサーバから返された前記第1の信号が、その受信バッファの残り容量が0であることを示したときに、定期的に、前記プロキシサーバに、その受信バッファの残り容量があるか否かを問い合わせる第2の信号を送信し、
前記通信ノードは、前記データを送信してから、前記第1の時間が経過する前に、前記第1の信号が前記通信ノードに返されたとき以外に、前記通信ノードがデータを再送する
機能を有し、
前記プロキシサーバは、同じネットワークに接続された前記通信ノードからデータを受信したときに、前記第1の信号の送信を、前記第1の時間より短い第2の時間だけ遅らせて、この通信ノードに返す
データ伝送システム。 - 予め決められた第1のデータ伝送速度の伝送路と、
前記伝送路を介して接続され、前記第1のデータ伝送速度よりも速い第2のデータ伝送速度の複数のネットワークと、
前記ネットワークそれぞれに1つ以上、接続された複数の通信ノードと、
前記ネットワークの1つ以上に接続され、同じネットワークを介して接続された前記通信ノードから、伝送されるデータを構成するデータセグメントを受信して受信バッファに記憶し、この通信ノードと、他のネットワークの通信ノードとの間で、予め決められたプロトコルを代理してデータ伝送を実行するプロキシサーバと
を有するデータ伝送システムであって、
前記プロトコルにおいて、
前記プロキシサーバは、同じネットワークに接続された通信ノードから前記データセグメントを受信したときに、この通信ノードに対して、このデータセグメントを受信したことを示す第1の信号を通信相手の通信ノードに返し、
前記通信ノードは、送信した全ての前記データセグメントに対応する全ての前記第1の信号を受けたときに、一度に送信する前記データのデータ量を増やし、これ以外のときには、前記データのデータ量を減らす
機能を有し、
前記プロキシサーバは、前記受信バッファの残り容量が、予め決められた値よりも多いときにのみ、前記データセグメントを送信した通信ノードに対して、前記第1の信号を返す
データ伝送システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008306015A JP2010130610A (ja) | 2008-12-01 | 2008-12-01 | データ伝送システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008306015A JP2010130610A (ja) | 2008-12-01 | 2008-12-01 | データ伝送システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2010130610A true JP2010130610A (ja) | 2010-06-10 |
Family
ID=42330607
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008306015A Pending JP2010130610A (ja) | 2008-12-01 | 2008-12-01 | データ伝送システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2010130610A (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2016529744A (ja) * | 2014-06-26 | 2016-09-23 | ジラット サテライト ネットワークス リミテッド | トンネル化されたトラフィックの最適化のための複数の方法及び装置 |
WO2017022034A1 (ja) * | 2015-07-31 | 2017-02-09 | 富士通株式会社 | 情報処理装置、情報処理方法、及び、情報処理プログラム |
US9961587B2 (en) | 2014-06-26 | 2018-05-01 | Gilat Satellite Networks Ltd. | Methods and apparatus for optimizing tunneled traffic |
-
2008
- 2008-12-01 JP JP2008306015A patent/JP2010130610A/ja active Pending
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2016529744A (ja) * | 2014-06-26 | 2016-09-23 | ジラット サテライト ネットワークス リミテッド | トンネル化されたトラフィックの最適化のための複数の方法及び装置 |
US9961587B2 (en) | 2014-06-26 | 2018-05-01 | Gilat Satellite Networks Ltd. | Methods and apparatus for optimizing tunneled traffic |
US10021594B2 (en) | 2014-06-26 | 2018-07-10 | Gilat Satellite Networks Ltd. | Methods and apparatus for optimizing tunneled traffic |
US10785680B2 (en) | 2014-06-26 | 2020-09-22 | Gilat Satellite Networks Ltd. | Methods and apparatus for optimizing tunneled traffic |
US11671868B2 (en) | 2014-06-26 | 2023-06-06 | Gilat Satellite Networks Ltd. | Methods and apparatus for optimizing tunneled traffic |
WO2017022034A1 (ja) * | 2015-07-31 | 2017-02-09 | 富士通株式会社 | 情報処理装置、情報処理方法、及び、情報処理プログラム |
JPWO2017022034A1 (ja) * | 2015-07-31 | 2018-04-26 | 富士通株式会社 | 情報処理装置、情報処理方法、及び、情報処理プログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9160670B2 (en) | Transmission control protocol (TCP) congestion control using transmission delay components | |
JP4589406B2 (ja) | バルク・データ転送 | |
JP5020076B2 (ja) | 低頻度ackのシステムに適した高性能tcp | |
US8493859B2 (en) | Method and apparatus for adaptive bandwidth control with a bandwidth guarantee | |
US20090268747A1 (en) | Communication apparatus | |
Fisk et al. | Dynamic right-sizing in TCP | |
US7656800B2 (en) | Transmission control protocol (TCP) | |
US10075382B2 (en) | Communication device, relay device, and communication method for a plurality of packets | |
US8259728B2 (en) | Method and system for a fast drop recovery for a TCP connection | |
KR20090014334A (ko) | 전송 프로토콜의 성능을 향상시키는 시스템 및 방법 | |
WO2016033948A1 (zh) | 一种发送窗口流量控制方法和终端 | |
WO2012149762A1 (zh) | 拥塞控制方法及设备 | |
JP2022537187A (ja) | 輻輳制御方法および装置、通信ネットワーク、ならびにコンピュータ記憶媒体 | |
US20180176136A1 (en) | TCP Bufferbloat Resolution | |
JP2007200055A (ja) | iSCSI通信制御方法とそれを用いた記憶システム | |
US20180026899A1 (en) | Method and apparatus for controlling send buffer of transmission control protocol in communication system | |
JP2010130610A (ja) | データ伝送システム | |
JP2007013449A (ja) | シェーパー制御方法、データ通信システム、ネットワークインタフェース装置及びネットワーク中継装置 | |
US9467386B2 (en) | Communication terminal and communication method | |
CN107683598B (zh) | 一种传输数据的方法及设备 | |
KR100859908B1 (ko) | 지속적인 혼잡감지를 이용한 tcp 혼잡제어방법 | |
CN113438180B (zh) | Udp数据包的传输控制方法、装置、设备及可读存储介质 | |
JP2009049742A (ja) | 通信システム、通信方法、送信機、受信機、レート計算方法およびプログラム | |
JP6010502B2 (ja) | パケット処理方法及びパケット処理装置 | |
Le et al. | SFC: Near-source congestion signaling and flow control |