JP2013027007A - 通信装置 - Google Patents

Abstract

【課題】ＬＡＮ側とＷＡＮ側の２つのＴＣＰ通信を中継する中継装置において、ＷＡＮ側の回線帯域がＬＡＮ側の回線帯域よりも小さい場合でも中継装置のＬＡＮ側受信バッファとＷＡＮ側送信バッファでのバッファ溢れ防ぎ、さらに、コネクションが強制切断されることを防ぐ。
【解決手段】ＷＡＮ側のＴＣＰ通信にて計測した送信スループット・廃棄率・ＲＴＴと、ＬＡＮ側の受信バッファの未整列データサイズと整列済みデータサイズとＷＡＮ側の送信バッファの未送信データサイズとＡＣＫ待ちデータサイズとの合計値に基づいて、ＬＡＮ側の送信端末へ返信するＡＣＫパケットに記載する受信ウィンドウサイズ（ｒｗｎｄ）の値を制御する。更に、ｒｗｎｄが減少して予め定めた閾値を下回り、再び超過したときに、受信ウィンドウサイズ（ｒｗｎｄ）の値を記載したＡＣＫパケットをＬＡＮ側の送信端末へ即座に送信する。
【選択図】図１

Description

本発明は、通信装置に関し、特に、端末間の通信を中継する通信装置に関する。

クラウド等に用いられる拠点間の通信網として、ＩＰ―ＶＰＮ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ− Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）技術等を用いたＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）を用いることが、一般的になっている。
或る拠点に存在する端末が、別の拠点に存在する端末と通信する場合は、自拠点ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）とＷＡＮを接続する回線と、ＷＡＮと別拠点ＬＡＮを接続する回線とを経由して通信が行われる。これらの回線は、契約帯域によって、使用可能な帯域幅が制限されている。

端末間の通信では、ＴＣＰ（Ｔｒａｎｓｐｏｒｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を用いるのが一般的である。ＴＣＰ通信では、送信端末の送信バッファと、受信端末の受信バッファを介して、データ転送が行われる。送信端末で動作するアプリケーションは、送信するデータを送信バッファに書き込む。送信端末は、送信バッファに書き込まれたデータをパケットに載せて、受信端末に向けて送信する。受信端末は、送信端末からパケットを受け取ると、受信データを受信バッファに蓄積する。更に、整列済み受信データの最後尾を示すシーケンス番号と、受信バッファの残存量を記載したＡＣＫパケットを送信端末に返信する。送信端末は、ＡＣＫパケットを受け取ると、記載されているシーケンス番号から受信済みデータを判断して、送信バッファから消去する。受信端末で動作するアプリケーションは、受信バッファに蓄積された整列済み受信データを定期的に読み出し、読出されたデータは受信バッファから消去される。各端末は、1つのＴＣＰ通信に対して、１組の送信バッファと受信バッファを持っており、送信する場合は送信バッファにデータを書き込み、受信する場合は受信バッファからデータを読み出す。
特許文献１では、輻輳ウィンドウサイズの値に基づいて、送信バッファに蓄積するデータサイズや新たに蓄積可能なデータサイズを制御する方法が記載されている。
特許文献２では、帯域幅と通信遅延の乗算値に基づいて、バッファのデータサイズを制御する方法が記載されている。

特開２００５−３４８１０７号公報 特表２００４−５２０７２５号公報

ＬＡＮ側とＷＡＮ側の２つのＴＣＰ通信を中継する中継装置において、ＬＡＮ側の回線帯域がＷＡＮ側の回線帯域よりも大きいと、ＬＡＮ側の送信端末から中継装置への入力スループットが、中継装置からＷＡＮへの出力スループットよりも大きくなる場合があり、中継装置のバッファに大量のデータが蓄積され溢れることがある。バッファ溢れがおきると、バッファ残存量０であることがＬＡＮ側の送信端末に通知され、ＬＡＮ側の送信端末から中継装置への送信が停止する。

中継装置からＷＡＮへの出力スループットが、ＬＡＮ側の送信端末から中継装置への入力スループットよりも相対的に小さいときは、中継装置のバッファに溜まったデータが減り、バッファに空きが生じるまでに時間がかかる。中継装置のバッファに再び空きが生じて通信が再開されるまでに長時間かかることにより、尚且つ、ＴＣＰではバッファが空いたことが即座にＬＡＮ側の送信端末に通知されないことにより、通信停止時間が長期化する課題がある。また、通信停止時間に長期化により通信が切断されたと送信端末に誤認され、コネクションが強制切断されてしまう課題があった。

本発明は、以上の点に鑑み、第一網側と第二網側を介して行われるＴＣＰ通信を中継する通信装置において、第一網側の回線帯域より第二網側の回線帯域が小さい場合、通信装置の送受信バッファのあふれを防ぎ、さらに端末間のコネクションが強制切断されることを防ぐ通信装置を提供することを目的とする。

上記課題の少なくとも一を解決するために、本発明の第１の解決手段によると、
第１網と第２網とを介するＴＣＰ通信を中継する通信装置において、
第１網から受信し、第２網へ中継する中継データを一時的に蓄積するバッファと、
前記バッファに蓄積した中継データのサイズを計算する受信部と、
第２網への実際の送信スループットを計測する送信帯域制御部と
を備え、
前記受信部は、
中継データのサイズと、送信スループットとに基づいて、第１網側のＴＣＰ通信で送信するＡＣＫパケットに記載する受信ウィンドウサイズの値を計算する前記通信装置が提供される。

例えば、第一の解決手段の具体的な一態様としては、ＬＡＮ側ＴＣＰ通信向け受信バッファに蓄積されている未整列データサイズと整列済みデータサイズと、ＷＡＮ側ＴＣＰ通信向け送信バッファに蓄積されている未送信データサイズと確認応答待ちデータサイズと、から装置に蓄積されたデータサイズの合計値を計算する手段と、ＷＡＮ側ＴＣＰ通信の送信スループットと再送スループットを計測する手段と、蓄積データサイズの合計値と、ＷＡＮ側ＴＣＰ通信の送信スループットと再送スループットとラウンドトリップタイム（ＲＴＴ）に基づいて、ＬＡＮ側の送信端末へ返信するＡＣＫパケットに記載する受信ウィンドウサイズ（ｒｗｎｄ）の値を計算するための手段を備える。更に、ｒｗｎｄが減少して予め定めた閾値を下回った後、再びその閾値を超過したときに、ｒｗｎｄの値を記載したＡＣＫパケットをＬＡＮ側の送信端末へ即座に送信する手段を備える。
本態様により、バッファに余裕ができたときに、通信が即座に再開され、通信停止時間を短縮することができる。

本発明によると、第一網側と第二網側を介して行われるＴＣＰ通信を中継する通信装置において、第一網側の回線帯域より第二網側の回線帯域が小さい場合、通信装置の中継のための送受信バッファのあふれを防ぐ。また、本発明によると、端末間のコネクションが強制切断されるころを防ぐ通信装置を提供できる。

本実施の形態における装置を有するシステム構成図。 装置２００のブロック図。 バッファのポインタの説明図。 パケットのフォーマット図。 状態テーブル２１２のフォーマット図。 プロキシ部２０６のブロック図。 ＷＡＮ側ＴＣＰ部２０９のブロック図。 ＬＡＮ側のＴＣＰモジュール２０３のブロック図。 帯域テーブル２１３のフォーマット図。 プロキシ部２０６がＬＡＮ側受信バッファのデータをＷＡＮ側送信バッファへ移動する処理のフローチャート図。 プロキシ部２０６がＷＡＮ側受信バッファのデータをＬＡＮ側送信バッファへ移動する処理のフローチャート図。 装置がＬＡＮ側の送信端末へ返信するＡＣＫパケット記載のｒｗｎｄを決定する処理のフローチャート図（１）。 装置がＬＡＮ側の送信端末へ返信するＡＣＫパケット記載のｒｗｎｄを決定する処理のフローチャート図（２）。 装置がＬＡＮ側の送信端末へ返信するＡＣＫパケット記載のｒｗｎｄを決定する処理のフローチャート図（３）。 ｒｗｎｄ５２７のより詳細な一例を示したフローチャート図。 受信履歴更新部７２６のＡＣＫ返信処理のフローチャート図。 ＬＡＮ側ＴＣＰの受信履歴更新部７２６のＡＣＫ返信の詳細な一例を示したフローチャート図。 従来の中継装置の課題を説明するためのシーケンス図。 従来の中継装置の課題を説明するためのスループット図。 本願の効果を説明するためのシーケンス図。 本願の効果を説明するためのスループット図。 ＬＡＮ側からデータ付きパケットを受信した際のパケットの流れの説明図。 旧基準時刻、基準時刻、現在時刻の説明図。

本発明を実施するための代表的な形態は、下記の通りである。
まず、図１３と図１４を用いて、従来の中継装置１３１０、１３２０の課題を説明する。
図１３には、端末１１１と端末１２１との間の通信を、従来の装置１３１０、１３２０が中継する際のシーケンス図を示す。図１４には、端末１１１と装置１３１０との間のＬＡＮ帯域１４０１と、装置１３１０と装置１３２０との間のＷＡＮ帯域１４０２の推移を示す。

装置１３１０は、この例ではＬＡＮ側に２パケット蓄積可能な受信バッファｒｂｕｆと、ＷＡＮ側に３パケット蓄積可能な送信バッファｓｂｕｆを備える（１３０１）。
装置１３１０は、端末１１１から１つ目のデータパケット１３１３を受信すると、装置１３１０のＬＡＮ側の受信バッファｒｂｕｆにパケット記載のデータを１つ蓄積する（１３０２）。装置１３１０は、１つ目のデータパケット受信後、１つ目のデータを受け取ったことを表すＡＣＫ＝１と受信バッファの残りサイズが１であることを表すｗｉｎ＿ｓｉｚｅ＝１を記載したＡＣＫパケット（１３２９）を端末１１１に向けて返信する。ＬＡＮ側の受信バッファに蓄積された１つ目のデータは、ＷＡＮ側の送信バッファに移される（１３０３）。１つ目のデータは、ＷＡＮ側の送信バッファに移された後、ＷＡＮ側の装置１３２０に向けて送られるが、ここでは廃棄されてしまうものとする（１３２８）。

次に、装置１３１０が、ＬＡＮ側の端末１１１から２つ目のデータパケット１３１４を受信すると、装置１３１０のＬＡＮ側の受信バッファｒｂｕｆにパケット記載のデータを１つ蓄積する（１３０４）。装置１３１０は、２つ目のデータパケット受信後、２つ目のデータを受け取ったことを表すＡＣＫ＝２と受信バッファの残りサイズが１であることを表すｗｉｎ＿ｓｉｚｅ＝１を記載したＡＣＫパケット（１３３０）を端末１１１に向けて返信する。ＬＡＮ側の受信バッファに蓄積された２つ目のデータは、ＷＡＮ側の送信バッファに移される（１３０５）。１つ目のデータが廃棄されて、ＷＡＮ側へ送信する際の制御帯域が小さいままなので、２つ目のデータは、ＷＡＮ側の送信バッファに移された後、しばらくはＷＡＮ側に向けて送信されずに、蓄積される。

次に、装置１３１０が、ＬＡＮ側の端末１１１から３つ目のデータパケット１３２４を受信すると、装置１３１０のＬＡＮ側の受信バッファｒｂｕｆにパケット記載のデータを１つ蓄積する（１３０６）。装置１３１０は、３つ目のデータパケット受信後、３つ目のデータを受け取ったことを表すＡＣＫ＝３と受信バッファの残りサイズが１であることを表すｗｉｎ＿ｓｉｚｅ＝１を記載したＡＣＫパケットを端末１１１に向けて返信する。ＬＡＮ側の受信バッファに蓄積された３つ目のデータは、ＷＡＮ側の送信バッファに移される（１３０７）。１つ目のデータが廃棄されて、ＷＡＮ側の制御帯域が小さいままなので、３つ目のデータは、ＷＡＮ側の送信バッファに移された後、しばらくはＷＡＮ側に向けて送信されずに、蓄積される。前回、蓄積されたままだった２つ目のデータが例えばここでＷＡＮ側に向けて送信される（１３３１）。

次に、装置１３１０が、ＬＡＮ側の端末１１１から４つ目のデータパケット１３２５を受信すると、装置１３１０のＬＡＮ側の受信バッファｒｂｕｆにパケット記載のデータが１つ蓄積される（１３０８）。装置１３１０は、４つ目のデータパケット受信後、４つ目のデータを受け取ったことを表すＡＣＫ＝４と受信バッファの残存量が１であることを表すｗｉｎ＿ｓｉｚｅ＝１を記載したＡＣＫパケットを端末１１１に向けて返信する。ＬＡＮ側の受信バッファに蓄積された４つ目のデータは、ＷＡＮ側の送信バッファが一杯なため、移されない（１３３２）。ＷＡＮ側の装置１３２０から、データ２に対するＡＣＫが戻ってきても（１３３３）、データ１が送信できていないため、ＷＡＮ側の送信バッファに蓄積されたデータ１〜３は消去されずにそのまま残る（１３３２）。

次に、ＬＡＮ側の端末１１１から５つ目のデータパケット１３２６が送信されると、ＬＡＮ側の受信バッファにパケットが２つ蓄積される（１３０９）。５つ目のデータパケット受信後、装置１３１０は、５つ目のデータを受け取ったことを表すＡＣＫ＝５と受信バッファの残りサイズが０であることを表すｗｉｎ＿ｓｉｚｅ＝０を記載したＡＣＫパケットを端末１１１に向けて返信する。
以上、述べてきたように、装置１３１０は、データパケットを受信する毎に、受信バッファ残存量を記載したＡＣＫパケットを、ＬＡＮ側の送信端末１１１に向けて送信する（１３１５）。

ＬＡＮ側の受信バッファ残存量が無いことを示すｗｉｎ＿ｓｉｚｅ＝０のＡＣＫパケットを受け取った端末１１１は、装置１３１０においてＬＡＮ側の受信バッファが一杯と判断して、データ送信を停止する。
その後、装置１３１０から３つ目のデータがＷＡＮ側へ送信され（１３３４）、３つ目のデータに対するＡＣＫが戻ってきても（１３３５）、データ１が到達できていないため、ＷＡＮ側の送信バッファに蓄積されたデータ１〜３は消去されずにそのまま残る（１３１６）。

装置１３１０は、ＬＡＮ側の送信端末１１１からデータパケットを受信しないときは、ＡＣＫパケット（１３１７）を定期的に装置１１１へ送る（１３１８）。ＡＣＫパケットには、ＬＡＮ側の受信バッファの残りサイズが０であることを表すｗｉｎ＿ｓｉｚｅ＝０が記載される。このように、パケット受信時（１３１５）、または定期的に（１３１８）、ＡＣＫパケットがＬＡＮ側の装置１１１へと送信される。

このように、ＷＡＮ側の回線帯域がＬＡＮ側の回線帯域よりも小さい場合、ＬＡＮ側の送信端末１１１から装置１３１０への入力スループットが、装置１３１０からＷＡＮ側の装置１３２０への出力スループットよりも大きく差が大きいため、装置１３１０のＷＡＮ側の送信バッファｓｂｕｆとＬＡＮ側の受信バッファｒｂｕｆに大量のデータがたまり、すぐに満杯となってしまう。更に、バッファに空きが生じるまでに時間がかかり、その後のデータ送信の停止時間が長時間におよぶため、端末１１１がコネクションに何らかの問題が生じたと判断して、ＲＳＴパケット送信（１３１９）によりコネクションを強制切断してしまう場合がある（１４０１）。

装置１３１０は、データ１に対するＡＣＫパケットが戻ってこないと、しばらくしてからデータ１を再送する（１３２１）。その後、装置１３２０からデータ１〜３を受け取ったことを表すＡＣＫ＝３を受信する（１３２２）。これにより、ＷＡＮ側の送信バッファに蓄積されたデータ１〜３が消去される（１３１１）。その後、ＬＡＮ側の受信バッファに蓄積された４つ目と５つ目のデータが、ＷＡＮ側の送信バッファへ移される（１３１２）。これにより、ＬＡＮ側の受信バッファｒｂｕｆが空となる。

受信パケットがないときはＡＣＫパケットは定期的に送信されるため、ＬＡＮ側の受信バッファが空になっても、ただちにｗｉｎ＿ｓｉｚｅを記載したＡＣＫパケットが端末１１１に送信されない（１３２３）。従って、端末１１１はデータ送信を再開できず、データ送信の停止時間が長期化してしまう。場合によっては、定期的なＡＣＫパケット送信の前に（１３２７）、端末１１１がコネクションに何らかの問題が生じたと判断して、ＲＳＴパケット送信（１３１９）によりコネクションを強制切断してしまう。

図１４を参照してさらに説明する。
以上、記載したように、ＬＡＮ側の回線帯域に対してＷＡＮ側の回線帯域が小さい場合は、ＬＡＮ側の送信端末１１１から中継装置１３１０への入力スループット（１４０１）が、中継装置１３１０からＷＡＮ側の中継装置１３２０への出力スループット（１４０２）よりも大きいため、装置１３１０のＷＡＮ側の送信バッファｓｂｕｆとＬＡＮ側の受信バッファｒｂｕｆに大量のデータがたまり、すぐに満杯となってしまう（１４０３）。更に、バッファに空きが生じるまでに時間がかかり、その後のデータ送信の停止時間が長時間におよぶため、端末１１１がコネクションに何らかの問題が生じたと判断して、ＲＳＴパケット送信（１３１９）によりコネクションを強制切断してしまう（１４０４）、という課題があった。加えて、ＬＡＮ側の受信バッファが空になっても、ただちにｗｉｎ＿ｓｉｚｅを記載したＡＣＫパケットが端末１１１に送信されないため（１３２３）、端末１１１はデータ送信を再開できず、データ送信の停止時間が長期化してしまう。場合によっては、端末１１１がコネクションに何らかの問題が生じたと判断して、ＲＳＴパケット送信（１３１９）によりコネクションを強制切断してしまう、という課題もあった。

更に、特許文献１に記載されているように、ＴＣＰ通信を制御するための変数である輻輳ウィンドウサイズに基づいて、バッファへの蓄積サイズや新たに蓄積可能なデータサイズを制御する方式では、ＷＡＮ側のＲＴＴが増大したときに、バッファの使用可能量が減少してしまう。例えば、送信スループットやＲＴＴや廃棄率の増大に応じて必要バッファ量が増大する独自ＴＣＰを用いて通信するケースでは、十分なスループットを達成できなくなり課題となる。また、特許文献２に記載のように、中継装置と中継装置の間の通信速度が、中継装置とクライアントの間の通信速度よりも高い時に、クライアント端末に対する受信ウィンドウサイズを抑える方式では、スループットの小さい方の通信の受信ウィンドウサイズを抑えて、通信速度差を余計に拡大させることとなり、本願の課題を解決することはできない。更に、特許文献２に記載のように、帯域遅延積を用いてバッファへのデータ蓄積量を制限する方式では、制限を越えるパケットを受信したときにバッファ溢れを生じ、パケット廃棄を生じさせることで、パケット再送が頻発し、データ送信の再開がかえって遅くなってしまう、という課題があった。
本実施の形態は、これらの従来の方式では解決できなかった課題を解決する。

図１には、本実施の形態の通信装置を適用したネットワークシステムの構成図を示す。
通信装置（中継装置ともいう。以下、単に装置と記す）１０１、１０２、１０３は、複数の拠点内ＬＡＮ（第１網）１１０、１２０、１３０とＷＡＮ（第２網）１４０を接続する通信回線上に設置される。各拠点内ＬＡＮ１１０、１２０、１３０には、複数の端末１１１〜１１３、１２１〜１２３、１３１〜１３３が接続している。装置１０１、１０２、１０３は、第１網と第２網の２つのＴＣＰ通信を中継する。なお、装置１０１、１０２、１０３は、２つのＷＡＮのＴＣＰ通信を中継してもよい。また、端末、装置及びネットワークの数は図示以外にも適宜の数を備えても良い。

図２には、本実施の形態の装置２００のブロック図を示す。
装置２００は、例えば、外部のＷＡＮ／ＬＡＮネットワークとのパケットの送受信を行うＷＡＮ側及びＬＡＮ側のネットワークインターフェース（２０１／２１１）と、ＴＣＰ以外のＵＤＰパケットやＡＲＰパケット等を素通しさせるためのフィルタ（２０２／２１０）と、ＴＣＰ通信のための制御を行うＷＡＮ側及びＬＡＮ側のＴＣＰモジュール２０３／２０９と、ＷＡＮ側のＴＣＰモジュール２０９の管理するＮ個の送信バッファ２０７およびＮ個の受信バッファ２０８と、ＬＡＮ側のＴＣＰモジュール２０３の管理するＮ個の送信バッファ２０５およびＮ個の受信バッファ２０４と、送受信バッファ間でデータの乗せ換えを行うプロキシ（データ転送部）２０６と、Ｎ個のエントリを備えた状態テーブル２１２と、Ｎ個のエントリを備えた帯域テーブル２１３とを備える。なお、上述のＮ個は、それぞれ異なる数でもよい。

ＴＣＰモジュール２０３／２０９、プロキシ２０６、状態テーブル２１２及び帯域テーブル２１３については、後に他の図面を参照して詳述し、ここでは概略を述べる。
ＷＡＮ側のＴＣＰモジュール２０９は、送信帯域制御部７１５と、送信履歴更新部７０５と、を備える。送信帯域制御部７１５は、送信スループット（５３１、５３２）の情報を状態テーブル２１２に蓄積する。送信履歴更新部７０５は、ＷＡＮ側送信バッファ２０７から読み出した送信データサイズに応じて、状態テーブル２１２のバッファ管理ポインタ（５０８〜５１０、５１５〜５１７、５２１〜５２６）の情報を更新する。

プロキシ２０６は、データ読出し部６０１と、データ加工部６０２と、データ書き込み部６０３を備える。データ加工部６０２は、加工中のデータサイズ（５２９、５３０）の情報を、状態テーブル２１２に蓄積する。データ読出し部６０１は、ＬＡＮ側受信バッファ２０４から読み出したデータサイズに応じて、状態テーブル２１２のバッファ管理ポインタ（５０８〜５１０、５１５〜５１７、５２１〜５２６）の情報を更新する。データ書き込み部６０３は、ＷＡＮ側送信バッファ２０７に書き込んだデータサイズに応じて、状態テーブル２１２のバッファ管理ポインタ（５０８〜５１０、５１５〜５１７、５２１〜５２６）の情報を更新する。

ＬＡＮ側のＴＣＰモジュール２０３は、受信履歴更新部７２６と、集約部７３２とを備える。受信履歴更新部７２６は、受信したパケットデータを、ＬＡＮ側受信バッファに蓄積する。更に、受信履歴更新部７２６は、蓄積したデータサイズに応じて、状態テーブル２１２のバッファ管理ポインタ（５０８〜５１０、５１５〜５１７、５２１〜５２６）の情報を更新する。更に、受信履歴更新部７２６は、状態テーブル２１２のバッファ管理ポインタ（５０８〜５１０、５１５〜５１７、５２１〜５２６）と加工中データサイズ（５２９、５３０）から読み出した情報から、ＬＡＮ側受信バッファに蓄積されたデータサイズと、ＷＡＮ側送信バッファに蓄積されたデータサイズと、加工中データサイズの合計値を計算する。更に、受信履歴更新部７２６は、計算したデータサイズと、状態テーブル２１２の送信スループット（５３１、５３２）の情報とに基づいて、受信ウィンドウサイズ（ｒｗｎｄ）を計算し、計算した受信ウィンドウサイズ（ｒｗｎｄ）の値を記載したＡＣＫパケットを生成し、生成したＡＣＫパケットを集約部７３２経由でＬＡＮ側に送信する。

図４には、装置がやりとりするパケットのフォーマット図を表す。
パケットは、ＭＡＣヘッダ４００、ＩＰヘッダ４１０、ＴＣＰヘッダ４２０、ＴＣＰオプションヘッダ４３０及びペイロード４５０を有する。ＭＡＣヘッダ４００は、宛先ＭＡＣアドレスを表すＤＭＡＣ４０１と、送信元ＭＡＣアドレスを表すＳＭＡＣ４０２と、ＭＡＣフレームタイプを表すＴｙｐｅ４０３を含む。ＩＰヘッダ４１０は、ＭＡＣヘッダを除くパケット長を表すＩＰ ｌｅｎｇｔｈ４１１と、プロトコル番号を表すｐｒｏｔｏｃｏｌ４１２と、送信元ＩＰアドレスを表すＳＩＰ４１３と、宛先ＩＰアドレスを現すＤＩＰ４１４とを含む。ＴＣＰヘッダ４２０は、送信元ポート番号を表すｓｒｃ．ｐｏｒｔ４２１と、宛先ポート番号を表すｄｓｔ．ｐｏｒｔ４２２と、送信シーケンス番号を表すＳＥＱ４２３と、受信シーケンス番号を表すＡＣＫ４２４と、ＴＣＰフラグ番号を表すｆｌａｇ４２５と、ＴＣＰのヘッダ長を表すｔｃｐ ｈｌｅｎ４２６と、受信バッファの残りサイズを表すｗｉｎ−ｓｉｚｅ４２７とを含む。ＴＣＰオプションヘッダ４３０は、オプション種別を表すｏｐｔｉｏｎ ｋｉｎｄ４３１と、オプション長を表すｏｐｔｉｏｎ ｌｅｎｇｔｈ４３２と、どこからどこまで部分的に受信できたかを記載するｌｅｆｔ＿ｅｄｇｅ＿１〜４（４３３、４３５、４３７、４３９）、ｒｉｇｈｔ＿ｅｄｇｅ＿１〜４（４３４、４３６、４３８、４４０）を含む。

図３には、送受信バッファ管理用のポインタの説明図を表す。本図では、データを左から右に書き込んでいき、左から右に読み出していくものとする。
受信バッファ（２０４、２０８）は、受信したデータの先頭（新しいデータ）を示すポインタｒｉｇｈｔ＿ｒｅｃｖ３０３と、整列済みデータと未整列データの境界を示すポインタｌｅｆｔ＿ｒｅｃｖ３０２と、プロキシ２０６による読出し済データと未読出しデータの境界を示すｌｅｆｔ＿ｒｂｕｆ３０１と、を管理する。

受信したデータの先頭を示すポインタｒｉｇｈｔ＿ｒｅｃｖ３０３は、ロスの発生が無く、前から順番にデータを受信すると、受信したデータサイズ分増えて、右へ移動する。受信できずに歯抜けになっているデータ箇所（ロスセグメント）が存在する状態で、再送パケットを受信して、ロスセグメントが消滅すると、整列済みデータと未整列データの境界を示すポインタｌｅｆｔ＿ｒｅｃｖ３０２は、最も小さなロスセグメントの左端まで移動する。プロキシ２０６は、読出し済データと未読出しデータの境界を示すｌｅｆｔ＿ｒｂｕｆ３０１から順番にデータを読み出し、読み出したデータサイズ分、ｌｅｆｔ＿ｒｂｕｆ３０１を右へ移動させる。読み出せるデータサイズの最大値は、ｌｅｆｔ＿ｒｅｃｖ３０２とｌｅｆｔ＿ｒｂｕｆ３０１の差に応じた値である。

送信バッファ（２０５、２０７）は、プロキシ２０６により書き込み済みで送信可能状態となっているデータの先頭を表すポインタｒｉｇｈｔ＿ｓｂｕｆ３０６と、送信済みデータの先頭を示す（送信済みデータと未送信データの境界でもある）ポインタｒｉｇｈｔ＿ｓｅｎｄ３０５と、受信側から確認応答を受信済みのデータの先頭を示すポインタｌｅｆｔ＿ｓｅｎｄ３０４と、を管理する。

プロキシ２０６が書き込み済みで送信可能状態となっているデータの先頭を表すポインタｒｉｇｈｔ＿ｓｂｕｆ３０６は、プロキシ２０６がデータを書き込む毎に、書き込んだデータサイズ分増加し、右へ移動する。送信したデータ、の先頭を示すポインタｒｉｇｈｔ＿ｓｅｎｄ３０５を始点として、新たなデータが送信され、ｒｉｇｈｔ＿ｓｅｎｄ３０５は、送信されたデータサイズ分増加し、右へ移動する。受信側から、ｌｅｆｔ＿ｓｅｎｄ３０４よりも大きな受信シーケンス番号を持つ確認応答パケットを受信すると、ｌｅｆｔ＿ｓｅｎｄ３０４は、確認応答パケットに記載された受信シーケンス番号へと増加し、右へ移動する。

図５には、状態テーブル２１２のフォーマット図を示す。
状態テーブル２１２は、ｎ個のエントリ５２０−１〜ｎを有する。
各エントリ５２０は、エントリが使用中であるか否かを記載するＶＬＤ５０１と、ＬＡＮまたはＷＡＮ側のコネクションが確立中であるか否かを記載するｃｏｎｎｅｃｔ＿ｓｔａｔｅ５０２と、ＬＡＮ側の端末のＩＰアドレスを表すＬＩＰ５０３と、ＷＡＮ側の端末のＩＰアドレスを表すＷＩＰ５０４と、ＬＡＮ側の端末のＴＣＰポート番号を表すＬｐｏｒｔ５０５と、ＷＡＮ側の端末のＴＣＰポート番号を表すＷｐｏｒｔ５０６と、ＬＡＮ側のＴＣＰ通信の状態を表すｌａｎ＿ｓｔａｔｅ５０７と、ＬＡＮ側の受信バッファ管理用のポインタを表すｌａｎ＿ｌｅｆｔ＿ｒｂｕｆ５０８、ｌａｎ＿ｌｅｆｔ＿ｒｅｃｖ５０９、ｌａｎ＿ｒｉｇｈｔ＿ｒｅｃｖ５１０と、ＬＡＮ側のウィンドウスケールオプションの値を表すｌａｎ＿ｗｓ５１１と、ＬＡＮ側の平均ＲＴＴを表すｌａｎ＿ｒｔｔ５１２と、ＬＡＮ側の輻輳ウィンドウサイズを表すｃｗｎｄ５１３と、ＬＡＮ側の送信バッファ管理用のポインタを表すｌａｎ＿ｌｅｆｔ＿ｓｅｎｄ５２１、ｌａｎ＿ｒｉｇｈｔ＿ｓｅｎｄ５２２、ｌａｎ＿ｒｉｇｈｔ＿ｓｂｕｆ５２３と、ＬＡＮ側の送信端末に通知する受信ウィンドウサイズを表すｒｗｎｄ５２７と、ＬＡＮ側の受信バッファから読み出され加工中のデータサイズを表すｌａｎ＿ｗａｎ５２９と、ＷＡＮ側のＴＣＰ通信の状態を表すｗａｎ＿ｓｔａｔｅ５１４と、ＷＡＮ側の受信バッファ管理用のポインタを表すｗａｎ＿ｌｅｆｔ＿ｒｂｕｆ５１５、ｗａｎ＿ｌｅｆｔ＿ｒｅｃｖ５１６、ｗａｎ＿ｒｉｇｈｔ＿ｒｅｃｖ５１７と、ＷＡＮ側のウィンドウスケールオプションの値を表すｗａｎ＿ｗｓ５１８と、ＷＡＮ側の平均ＲＴＴを表すｗａｎ＿ｒｔｔ５１９と、ＷＡＮ側の再送率を表すｒｔｓ＿ｒａｔｉｏ５２８と、ＷＡＮ側の基準時刻後の送信帯域を表すｓｎｄ５３１と、ＷＡＮ側の基準時刻前の送信帯域を表すｏｌｄ＿ｓｎｄ５３２と、ＷＡＮ側の送信バッファ管理用のポインタを表すｗａｎ＿ｌｅｆｔ＿ｓｅｎｄ５２４、ｗａｎ＿ｒｉｇｈｔ＿ｓｅｎｄ５２５、ｗａｎ＿ｒｉｇｈｔ＿ｓｂｕｆ５２６と、ＷＡＮ側の受信バッファから読み出され加工中のデータサイズを表すｗａｎ＿ｌａｎ５３０とを有する。

図６には、プロキシ２０６のブロック図を示す。
プロキシ２０６は、例えばＬＡＮ側の受信バッファｒｂｕｆ２０４からデータを読出すデータ読出し部６０１と、読み出したデータに対して圧縮・解凍・暗号化・復号・削除・複製・追記などの加工を行うデータ加工部６０２と、加工済みデータをＷＡＮ側の送信バッファｓｂｕｆ２０７へ書き込むデータ書き込み部６０３と、ＷＡＮ側の受信バッファｒｂｕｆ２０８からデータを読み出すデータ読出し部６０６と、読み出したデータに対して圧縮・解凍・暗号化・復号・削除・複製・追記などの加工を行うデータ加工部６０５と、加工済みデータをＬＡＮ側の送信バッファｓｂｕｆ２０５へ書き込むデータ書き込み部６０４とを有する。データ加工部６０２とデータ加工部６０５との間で、データのやり取りをする場合もある。データ加工部６０２、６０５の処理は、上述の例以外にも、データに対する適宜の処理でもよい。

データ読出し部６０１は、ｌａｎ＿ｌｅｆｔ＿ｒｂｕｆ５０８からｌａｎ＿ｌｅｆｔ＿ｒｅｃｖ５０９までの間に蓄積されている整列済みデータから読み出した先頭データから、読み出すべきデータサイズと、データ加工後のデータサイズを推定する。先頭データとしては、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）／ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）ヘッダ、ＳＭＢ（Ｓｅｒｖｅｒ Ｍｅｓｓａｇｅ Ｂｌｏｃｋ）ヘッダ、等などを使用してもよい。ＴＬＳ／ＳＳＬヘッダに記載された値からは、復号後のチェックサムやヘッダを除いた平文データサイズを推定することができる。ＳＭＢヘッダからは、プリフェッチ等を行った後のコマンドデータサイズを推定することができる。推定した加工後のデータサイズと、ｗａｎ＿ｒｉｇｈｔ＿ｓｂｕｆ５２６とｗａｎ＿ｌｅｆｔ＿ｓｅｎｄ５２４の差、すなわち未送信データとＡＣＫ確認待ちデータの合計との和が、ＷＡＮ側の送信バッファサイズｗａｎ＿ｓｂｕｆ＿ｓｉｚｅを超えない場合は、データを受信バッファ２０４から読み出して、データ加工部６０２へ転送する。更に、推定した読み出すべきデータサイズと、データ加工後のデータサイズのうち、大きい方を状態テーブル２１２のｌａｎ＿ｗａｎ５２９へ記載する。詳細は、図９に示すフローチャート図を参照して後述する。

データ読出し部６０６は、ｗａｎ＿ｌｅｆｔ＿ｒｂｕｆ５１５からｗａｎ＿ｌｅｆｔ＿ｒｅｃｖ５１６までの間に蓄積されている整列済みデータから読み出した先頭データから、読み出すべきデータサイズと、データ加工後のデータサイズを推定する。先頭データとしては、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）／ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）ヘッダ、ＳＭＢ（Ｓｅｒｖｅｒ Ｍｅｓｓａｇｅ Ｂｌｏｃｋ）ヘッダ、等などを使用してもよい。推定した加工後のデータサイズと、ｌａｎ＿ｒｉｇｈｔ＿ｓｂｕｆ５２３とｌａｎ＿ｌｅｆｔ＿ｓｅｎｄ５２１の差、すなわち未送信データとＡＣＫ確認待ちデータの合計との和が、ＬＡＮ側の送信バッファサイズｌａｎ＿ｓｂｕｆ＿ｓｉｚｅを超えない場合は、データを受信バッファ２０８から読み出して、データ加工部６０５へ転送する。更に、推定した読み出すべきデータサイズと、データ加工後のデータサイズのうち、大きい方を状態テーブル２１２のｗａｎ＿ｌａｎ５３０へ記載する。詳細は、図１０に示すフローチャート図を参照して後述する。

図９と図１０には、データ読出し部６０１とデータ読出し部６０６のデータ読出し処理のフローチャート図をそれぞれ示す。
図９の各処理は、データ読み出し部６０１が実行する。
データ読出し部６０１は、処理を開始すると（ステップ９００）、はじめにｌａｎ＿ｌｅｆｔ＿ｒｅｃｖ５０９がｌａｎ＿ｌｅｆｔ＿ｒｂｕｆ５０８よりも大きいか比較し、ＬＡＮ側の受信バッファに整列済みデータが存在するか否かを判定する（ステップ９０１）。ステップ９００で大きくないと判断した場合、すなわち整列済みデータが存在しない場合は、ステップ９０１を繰り返す。一方、ステップ９００で大きいと判断した場合、すなわち整列済みデータが存在する場合は、次に、ｌａｎ＿ｌｅｆｔ＿ｒｅｃｖ５０９からｌａｎ＿ｌｅｆｔ＿ｒｂｕｆ５０８の間にある整列済みデータの先頭データから、読み出すべきデータサイズと、データ加工後のデータサイズを推定する（ステップ９０６）。先頭データとしては、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）／ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）ヘッダ、ＳＭＢ（Ｓｅｒｖｅｒ Ｍｅｓｓａｇｅ Ｂｌｏｃｋ）ヘッダ、等などを使用してもよい。推定の手法は適宜の手法を用いてよい。

次に、ｗａｎ＿ｒｉｇｈｔ＿ｓｂｕｆ５２６とｗａｎ＿ｌｅｆｔ＿ｓｅｎｄ５２４の差分（未送信データとＡＣＫ確認待ちデータの合計値）と、ＷＡＮ側の送信バッファサイズｗａｎ＿ｓｂｕｆ＿ｓｉｚｅとの差分（バッファ空きサイズ）が、ステップ９０６で推定した加工後のデータサイズよりも大きいか否か比較を行う（ステップ９０２）。ステップ９０２にて大きいと判定した場合、ステップ９０６にて推定した読み出すべきデータサイズのデータを、ＬＡＮ側の受信バッファから読み出す（ステップ９０３）。ステップ９０２にて否と判定した場合は、データ加工しない場合のみ、ｗａｎ＿ｒｉｇｈｔ＿ｓｂｕｆ５２６とｗａｎ＿ｌｅｆｔ＿ｓｅｎｄ５２４の差分（未送信データとＡＣＫ確認待ちデータの合計値）と、ＷＡＮ側の送信バッファサイズｗａｎ＿ｓｂｕｆ＿ｓｉｚｅとの差分（バッファ空きサイズ）に相当するサイズのデータを、ＬＡＮ側の受信バッファから読み出す（ステップ９０４）。データを加工するか否かは、予め定められても良いし、パケットの種類毎に定められても良い。データ読み出し後、ｌａｎ＿ｌｅｆｔ＿ｒｂｕｆ５０８に読み出したデータサイズを加算する（ステップ９０５）。ステップ９０５の後、ステップ９０１へ戻る。なお、ｗａｎ＿ｒｉｇｈｔ＿ｓｂｕｆ５２６は、データ書き込み部６０３がデータを書き込んだ際に、書き込んだデータサイズ分だけ増加する。

図１０の各処理は、データ読み出し部６０６が実行する。
データ読出し部６０６は、処理を開始すると（ステップ１０００）、はじめにｗａｎ＿ｌｅｆｔ＿ｒｅｃｖ５１６がｗａｎ＿ｌｅｆｔ＿ｒｂｕｆ５１５よりも大きいか比較し、ＷＡＮ側の受信バッファに整列済みデータが存在するか否かを判定する（ステップ１００１）。ステップ１００１で大きくないと判断した場合、すなわち整列済みデータが存在しない場合は、ステップ１００１を繰り返す。一方、ステップ１００１で大きいと判断した場合、すなわち整列済みデータが存在する場合は、次に、ｗａｎ＿ｌｅｆｔ＿ｒｅｃｖ５１６からｗａｎ＿ｌｅｆｔ＿ｒｂｕｆ５１５の間にある整列済みデータの先頭データから、読み出すべきデータサイズと、データ加工後のデータサイズを推定する（ステップ１００６）。先頭データとしては、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）／ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）ヘッダ、ＳＭＢ（Ｓｅｒｖｅｒ Ｍｅｓｓａｇｅ Ｂｌｏｃｋ）ヘッダ、等などを使用してもよい。

次に、ｌａｎ＿ｒｉｇｈｔ＿ｓｂｕｆ５２３とｌａｎ＿ｌｅｆｔ＿ｓｅｎｄ５２１の差分（未送信データとＡＣＫ確認待ちデータの合計値）と、ＬＡＮ側の送信バッファサイズｌａｎ＿ｓｂｕｆ＿ｓｉｚｅとの差分（バッファ空きサイズ）が、ステップ１００６で推定した加工後のデータサイズよりも大きいか否か比較を行う（ステップ１００２）。ステップ１００２にて大きいと判定した場合、ステップ１００６にて推定した読み出すべきデータサイズのデータを、ＷＡＮ側の受信バッファから読み出す（ステップ１００３）。ステップ１００２にて否と判定した場合は、データ加工しない場合のみ、ｌａｎ＿ｒｉｇｈｔ＿ｓｂｕｆ５２３とｌａｎ＿ｌｅｆｔ＿ｓｅｎｄ５２１の差分（未送信データとＡＣＫ確認待ちデータの合計値）と、ＬＡＮ側の送信バッファサイズｌａｎ＿ｓｂｕｆ＿ｓｉｚｅとの差分（バッファ空きサイズ）に相当するサイズのデータを、ＷＡＮ側の受信バッファから読み出す（ステップ１００４）。データ読出し後、ｗａｎ＿ｌｅｆｔ＿ｒｂｕｆ５１５に読出したデータサイズを加算する（ステップ１００５）。ステップ１００５の後、ステップ１００１へ戻る。なお、ｌａｎ＿ｒｉｇｈｔ＿ｓｂｕｆ５２３は、データ書き込み部６０４がデータを書き込んだ際に、書き込んだデータサイズ分だけ増加する。

図７Ａには、ＷＡＮ側のＴＣＰモジュール２０９のブロック図を示す。
ＴＣＰ通信を実現するＴＣＰモジュール２０９は、受信処理を行うＲＸ部（受信部）７０２と、送信処理を行うＴＸ部（送信部）７０１を有する。ＲＸ部７０２は、受信パケットをＴＣＰ制御パケットとデータ付パケットとＡＣＫパケットに分離するパケット解析部７０８と、受信したＴＣＰ制御パケットに基づいて状態テーブル２１２内のＴＣＰ状態ｌａｎ＿ｓｔａｔｅ５０７、ｗａｎ＿ｓｔａｔｅ５１４を変更するＴＣＰ制御部７０７と、受信したデータパケットの送信シーケンス番号ＳＥＱ４２３と受信シーケンス番号ＡＣＫ４２４とに基づいて、状態テーブル２１２内のバッファ管理ポインタを変更してＡＣＫパケットを返信する受信履歴更新部７０６とを有する。

ＴＸ部７０１は、状態テーブル２１２内のＴＣＰ状態ｌａｎ＿ｓｔａｔｅ５０７、ｗａｎ＿ｓｔａｔｅ５１４を用いてＴＣＰ制御パケットを送信するＴＣＰ制御部７０３と、受信したＡＣＫパケットに基づいて状態テーブル２１２内のバッファ管理ポインタを変更し、受信したＡＣＫパケット記載の部分的確認応答ｌｅｆｔ＿ｅｄｇｅ＿１〜４（４３３、４３５、４３６、４３９）、ｒｉｇｈｔ＿ｅｄｇｅ＿１〜４（４３４、４３６、４３８、４４０）を用いて送信バッファｓｂｕｆ２０７からデータを読み出してパケットを再送するパケット再送部７０４と、送信バッファｓｂｕｆ２０７から読み出したデータを載せたパケットを送信して、状態テーブル２１２内のバッファ管理ポインタを変更する送信履歴更新部７０５とを有する。さらに、ＴＸ部７０１は、再送パケットとデータパケットを受け取り、バッファ１〜ｎ（７０９−１〜ｎ）に振り分けると共に、各ＴＣＰコネクションの送信／再送ビット長を送信帯域制御部７１５に通知する振分部７０８と、現在時刻を生成して送信帯域制御部７１５に通知するタイマ７１３と、インターバル時間を保存して送信帯域制御部７１５に通知するインターバル格納部７１４と、帯域テーブル２１３を制御して、各ＴＣＰコネクションのトークンサイズをトークン更新部７１７に通知する送信帯域制御部７１５と、ＴＣＰコネクション毎にトークンバケツを管理して、送信可能なコネクションをマルチプレクサ７１２に通知するトークン更新部７１７と、ＡＣＫパケット、ＴＣＰ制御パケット、再送パケット、データパケットをＦＩＦＯで集約して、出力するマルチプレクサ７１２およびバッファ７０９〜７１１とを有する。

図７Ｂには、ＬＡＮ側のＴＣＰモジュール２０３のブロック図を示す。
ＴＣＰ通信を実現するＴＣＰモジュール２０３は、受信処理を行うＲＸ部７２２と、送信処理を行うＴＸ部７２１を有する。ＲＸ部７２２は、受信パケットをＴＣＰ制御パケットとデータ付パケットとＡＣＫパケットに分離するパケット解析部７２８と、受信したＴＣＰ制御パケットに基づいて状態テーブル２１２内のＴＣＰ状態ｌａｎ＿ｓｔａｔｅ５０７、ｗａｎ＿ｓｔａｔｅ５１４を変更するＴＣＰ制御部７２７と、受信したデータパケットの送信シーケンス番号ＳＥＱ４２３と受信シーケンス番号ＡＣＫ４２４とに基づいて、状態テーブル２１２内のバッファ管理ポインタを変更してＡＣＫパケットを返信する受信履歴更新部７２６とを有する。

ＴＸ部７２１は、状態テーブル２１２内のＴＣＰ状態ｌａｎ＿ｓｔａｔｅ５０７、ｗａｎ＿ｓｔａｔｅ５１４を用いてＴＣＰ制御パケットを送信するＴＣＰ制御部７２３と、受信したＡＣＫパケットに基づいて状態テーブル２１２内のバッファ管理ポインタを変更し、受信したＡＣＫパケット記載の部分的確認応答ｌｅｆｔ＿ｅｄｇｅ＿１〜４（４３３、４３５、４３６、４３９）、ｒｉｇｈｔ＿ｅｄｇｅ＿１〜４（４３４、４３６、４３８、４４０）を用いて送信バッファｓｂｕｆ２０５からデータを読み出してパケットを再送するパケット再送部７２４と、送信バッファｓｂｕｆ２０５から読み出したデータを載せたパケットを送信して、状態テーブル２１２内のバッファ管理ポインタを変更する送信履歴更新部７２５と、ＡＣＫパケット、ＴＣＰ制御パケット、再送パケット、データパケットをＦＩＦＯで集約して、出力するマルチプレクサ７３２およびバッファ７２９〜７３１とを有する。

図８には、帯域テーブル２１３のフォーマットを表す。
帯域テーブル２１３は、コネクション毎に、旧基準時刻前の送信帯域・制御帯域、基準時刻前の送信帯域・再送帯域・制御帯域、基準時刻、及び、基準時刻後の送信ビット積算値・再送ビット積算値・制御帯域を記録する。基準時刻後の制御帯域は、現在時刻における制御帯域を表す（本実施例では、ｔｏｋｅｎと表す）。基準時刻後の送信帯域は、現在時刻における送信帯域を表し（本実施例では、ｓｎｄと表す）、基準時刻後の送信ビット積算値をインターバル時間で除算することで求められる。基準時刻後の再送帯域は、現在時刻における再送帯域を表し（本実施例では、ｒｔｓと表す）、基準時刻後の再送ビット積算値をインターバル時間で除算することで求められる。基準時刻前の制御帯域・送信帯域・再送帯域は、基準時刻の直前までの制御帯域・送信帯域・再送帯域を表す（本実施例では、ｏｌｄ＿ｔｏｋｅｎ、ｏｌｄ＿ｓｎｄ、ｏｌｄ＿ｒｔｓと表す）。また、現在使用している基準時刻の一つ前に使用していた基準時刻を旧基準時刻と呼び、旧基準時刻前の制御帯域・送信帯域・再送帯域は、旧基準時刻の直前までの制御帯域・送信帯域・再送帯域を表す（本実施例では、ｏｌｄ＿ｏｌｄ＿ｔｏｋｅｎ、ｏｌｄ＿ｏｌｄ＿ｓｎｄ、ｏｌｄ＿ｏｌｄ＿ｒｔｓと表す）。例えば、基準時刻前の再送率ｏｌｄ＿ｒｔｓ＿ｒａｔｉｏは、ｏｌｄ＿ｒｔｓ／ｏｌｄ＿ｏｌｄ＿ｓｎｄで求められる。また、基準時刻後の現在の再送率ｒｔｓ＿ｒａｔｉｏは、ｒｔｓ／ｏｌｄ＿ｓｎｄで求められる。なお、インターバル格納部７１４のインターバル時間の代わりに、状態テーブル２１２記載のｗａｎ＿ｒｔｔ５１９を用いる場合もある。

帯域テーブル２１３の各情報は、例えば、送信帯域制御部７１５により更新される。また、送信帯域制御部７１５は、送信ビット積算値、再送ビット積算値などから、送信帯域（送信スループット）ｓｎｄ５３１、再送帯域（再送スループット）ｒｔｓ、再送率ｒｔｓ＿ｒａｔｉｏ５２８をそれぞれ求め、状態テーブル２１２に記憶する。

図１８には、旧基準時刻、基準時刻、現在時刻の関係を表す。旧基準時刻と、基準時刻の差は、インターバル時間である。旧基準時刻前のインーターバル時間の制御帯域・送信帯域・再送帯域は、ｏｌｄ＿ｏｌｄ＿ｔｏｋｅｎ、ｏｌｄ＿ｏｌｄ＿ｓｎｄ、ｏｌｄ＿ｏｌｄ＿ｒｔｓと表す（１８０３）。旧基準時刻から基準時刻までの制御帯域・送信帯域・再送帯域は、ｏｌｄ＿ｔｏｋｅｎ、ｏｌｄ＿ｓｎｄ、ｏｌｄ＿ｒｔｓと表す（１８０２）。基準時刻から現在時刻までの制御帯域・送信帯域・再送帯域は、ｔｏｋｅｎ、ｓｎｄ、ｒｔｓと表す（１８０１）。インターバル時間は、例えばＲＴＴ等の変動する値でもよいし、固定の値を用いても良い。
送信帯域制御部７１５は、帯域テーブル２１３に記載された値を用いて制御帯域（ｔｏｋｅｎ）を決定し、トークン更新部７１７へ伝える。更に、状態テーブル２１２のｒｔｓ＿ｒａｔｉｏ５２８を更新する。

図１７には、ＬＡＮ側からデータ付きパケットを受信した際のパケットの流れを表す。
ＬＡＮ側から到着したデータ付きパケットは受信履歴更新部７２６に到着する。受信履歴更新部７２６は、ＡＣＫパケットを集約部７３２経由でＬＡＮ側に返信し、パケットに記載されたデータをＬＡＮ側受信バッファｒｂｕｆ２０４へと蓄積する。更に、蓄積データサイズに基づいて状態テーブル２１２のポインタを更新する。データ読出し部６０１は、ＬＡＮ側受信バッファｒｂｕｆ２０４に蓄積された整列済みデータを読出し、データ加工部６０２へ転送する。更に、読み出したデータサイズに基づいて状態テーブル２１２のポインタを更新する。データ加工部６０２は、データを加工して、データ書き込み部６０３へ転送する。更に、加工中のデータサイズに基づいて状態テーブル２１２の加工中データサイズを更新する。データ書き込み部６０３は、加工済みデータをＷＡＮ側送信バッファｓｂｕｆ２０７へと書き込む。更に、書き込んだデータサイズに基づいて状態テーブル２１２のポインタを更新する。ＷＡＮ側送信バッファｓｂｕｆ２０７に書き込まれたデータは、送信履歴更新部７０５から読み出されて、ＷＡＮ側へデータ付きパケットとして送信される。

受信履歴更新部７２６は、ＬＡＮ側の受信バッファ２０４の最大値から、ｌａｎ＿ｒｉｇｈｔ＿ｒｅｃｖ５１０とｌａｎ＿ｌｅｆｔ＿ｒｂｕｆ５０８との差分を引くことで、受信バッファの残存量を計算する。受信データのペイロード４５０のサイズが、受信バッファ２０４の残存量以下のときは、ペイロード４５０に記載されたデータ全てを受信バッファ２０４に格納する。ペイロード４５０のサイズが、受信バッファ２０４の残存量よりも大きい場合は、ペイロード４５０の先頭から受信バッファの残存量に相当するサイズのデータだけを受信バッファ２０４に格納する。格納データサイズが０よりも大きいときは、データ付きパケットのＴＣＰヘッダ４２０に記載されたＳＥＱ４２３の値と、格納データサイズに基づいて、受信バッファ管理用ポインタの更新を行う。例えば、ＳＥＱ４２３に格納データサイズを加算した値が、ｌａｎ＿ｒｉｇｈｔ＿ｒｅｃｖ５１０よりも大きい場合は、ｌａｎ＿ｒｉｇｈｔ＿ｒｅｃｖ５１０を、ＳＥＱ４２３に格納データサイズを加算した値に変更する。更に、格納データは、ｌａｎ＿ｒｉｇｈｔ＿ｒｅｃｖ５１０で最後尾となるように、ＬＡＮ側の受信バッファ２０４に記憶される。その後、ｒｗｎｄ５２７をＴＣＰヘッダ４２０のｗｉｎ＿ｓｉｚｅ４２７に記載し、受信バッファ管理ポインタの１つｌａｎ＿ｌｅｆｔ＿ｒｅｃｖ５０９をＴＣＰヘッダ４２０のＡＣＫ４２４に記載したＡＣＫパケットを、ＬＡＮ側へ返信する。

なお、受信履歴更新部７２６において、データを格納するか否かの判断に、ｒｗｎｄ５２７の値は使用されない。そのため、ｒｗｎｄ５２７が０であっても、受信バッファの残存量が０よりも大きければ、ＡＣＫパケットを送信した後に受信したパケットのペイロード４５０に記載されたデータは受信バッファに格納され、受信シーケンス番号がインクリメントされたＡＣＫ４２４を持ち、受信ウィンドウサイズを０にしたＡＣＫパケットが、ＬＡＮ側へ返信される。

送信履歴更新部７０５は、ｗａｎ＿ｒｉｇｈｔ＿ｓｅｎｄ５２５から右方向に、最大ｗａｎ＿ｒｉｇｈｔ＿ｓｂｕｆ５２６までのデータを、ＷＡＮ側送信バッファｓｂｕｆ２０７から読み出す。ｗａｎ＿ｒｉｇｈｔ＿ｓｅｎｄ５２５は、読み出したデータサイズ分、増加して、右に移動する。更に、読み出したデータをペイロード４５０に記載し、ｗａｎ＿ｒｉｇｈｔ＿ｓｅｎｄ５２５をＳＥＱ４２３に記載したＴＣＰヘッダ４２０を追加したデータ付きパケットを、ＷＡＮ側へ送信する。

図１２Ａには、ＬＡＮ側ＴＣＰの受信履歴更新部７２６のＡＣＫ返信の一例を示したフローチャート図を示す。
受信履歴更新部７２６は、処理が始まると（ステップ１２１１）、データパケットの受信があるか否かをポーリングして確認する（ステップ１２１２）。受信パケットがある場合は、新たなｒｗｎｄ５２７を求めてＴＣＰヘッダ４２０のｗｉｎ＿ｓｉｚｅ４２７に記載したＡＣＫパケットをＬＡＮ側へ返信する（ステップ１２１４）。ステップ１２１２において、受信パケットが無い場合でも、ｒｗｎｄ５２７が予め定めた閾値未満から閾値以上に増加したことを確認した場合は（ステップ１２１３）、新たなｒｗｎｄ５２７を求めてＴＣＰヘッダ４２０のｗｉｎ＿ｓｉｚｅ４２７に記載したＡＣＫパケットをＬＡＮ側へ返信する（ステップ１２１４）。ステップ１２１３にて、変化が確認されなかった場合は、ステップ１２１２へと戻る。

図１２Ａに示すように、ＬＡＮ側ＴＣＰの受信履歴更新部７２６が、ステップ１２１３の処理を行うことで、データパケットの受信が無いときでも、ＬＡＮ側の送信端末に通知すべきｒｗｎｄが予め定めた閾値を超過したら即座に、ｒｗｎｄを記載したＡＣＫパケットをＬＡＮ側の送信端末に返信できるようになる。これにより、ＬＡＮ側の送信端末は、ＬＡＮ側の受信バッファに空きが生じたことを直ちに知り、送信を再開することが可能となる。

図１２Ｂには、ＬＡＮ側ＴＣＰの受信履歴更新部７２６のＡＣＫ返信の、より詳細な一例を示したフローチャート図を示す。
受信履歴更新部７２６は、処理が始まると（ステップ１２００）、はじめに、内部変数ｌａｎ＿ｒｂｕｆ＿ｆｕｌｌを０に初期化する（ステップ１２０１）。次に、ｒｗｎｄ５２７を計算する（ステップ１２１０）。ｒｗｎｄ５２７の計算方法は、図１１Ａ〜Ｄを参照して後述する。次に、内部変数ｌａｎ＿ｒｂｕｆ＿ｆｕｌｌが０であり、かつ、ｒｗｎｄ５２７が最大セグメントサイズ（１パケットに載せられる最大データサイズ）ｍｓｓ（上述の閾値に相当）よりも小さいか否かを判定する（ステップ１２０２）。ステップ１２０２において真であれば、内部変数ｌａｎ＿ｒｂｕｆ＿ｆｕｌｌを１に変更して（ステップ１２０３）、ステップ１２０４へと進む。ステップ１２０２において偽であれば、ステップ１２０４へと進む。ステップ１２０４では、新たなデータパケットの受信があるか否かを判定する。受信パケットがある場合は、受信バッファ管理用ポインタ更新を行う（ステップ１２０５）。例えば、ＳＥＱ４２３にペイロード４５０のサイズを加算した値が、ｌａｎ＿ｒｉｇｈｔ＿ｒｅｃｖ５１０よりも大きい場合は、ｌａｎ＿ｒｉｇｈｔ＿ｒｅｃｖ５１０をＳＥＱ４２３にイロード４５０のサイズを加算した値に変更する。さらに、ｒｗｎｄ５２７を計算する（ステップ１２０８）。ｒｗｎｄ５２７の計算方法は、図１１Ａ〜Ｄを参照して後述する。一方、ステップ１２０４にて受信パケットが無い場合は、内部変数ｌａｎ＿ｒｂｕｆ＿ｆｕｌｌが１であり、かつ、ｒｗｎｄ５２７が最大セグメントサイズ（１パケットに載せられる最大データサイズ）ｍｓｓ以上であるか否かを判定する（ステップ１２０６）。否の場合は、ステップ１２１０へと戻る。真である場合は、内部変数ｌａｎ＿ｒｂｕｆ＿ｆｕｌｌを０にして（ステップ１２０７）、ステップ１２０８へと進む。ステップ１２０８では、ｒｗｎｄ５２７を計算する。その後、ｒｗｎｄ５２７をＴＣＰヘッダ４２０のｗｉｎ＿ｓｉｚｅ４２７に、受信バッファ管理ポインタの１つｌａｎ＿ｌｅｆｔ＿ｒｅｃｖ５０９をＴＣＰヘッダ４２０のＡＣＫ４２４に、それぞれ記載したＡＣＫパケットを返信する（ステップ１２０９）。

図１２Ｂに示すように、ＬＡＮ側ＴＣＰの受信履歴更新部７２６が、ステップ１２０６とステップ１２０７の処理（及びステップ１２０２、１２０３の処理）を行うことで、データパケットの受信が無いときでも、ＬＡＮ側の送信端末に通知すべきｒｗｎｄがＭＳＳを超過したら即座に、ｒｗｎｄを記載したＡＣＫパケットをＬＡＮ側の送信端末に返信できるようになる。これにより、ＬＡＮ側の送信端末は、ＬＡＮ側の受信バッファに空きが生じたことを直ちに知り、送信を再開することができる。

次に、ｒｗｎｄ５２７の計算について説明する。例えば、図１２Ａのステップ１２１４、図１２Ｂのステップ１２１０、１２０８の処理に相当する。
図１１Ａには、ＬＡＮ側ＴＣＰの受信履歴更新部７２６の行うｒｗｎｄ５２７計算の一例を示したフローチャート図を示す。
ｒｗｎｄ５２７計算がはじまると（ステップ１１１０）、ＷＡＮ送信バッファｓｂｕｆ２０７とＬＡＮ受信バッファｒｂｕｆ２０４に蓄積されたデータサイズ（蓄積データサイズ）と、プロキシ２０６で加工中のデータサイズを加算した値を、装置に蓄積された中継データサイズの合計値とする（ステップ１１１１）。各データサイズは、状態テーブル２１２から読み出してもよいし、又は状態テーブル２１２から読み出されたデータから求めてもよい。更に、装置に蓄積された中継データサイズの合計値を、計測したＷＡＮ側の送信スループット（ｓｎｄ又はｏｌｄ＿ｓｎｄ）で除算して、装置内のデータが空になる時間を推定する（ステップ１１１２）。更に、推定した時間が、予め定められた閾値ｔｈｒよりも大きいか否かを判定する（ステップ１１１３）。閾値は、ＴＣＰのタイムアウト時間より定めることができる。例えば、タイムアウト時間をそのまま閾値としても良いし、係数をかけてもよい。ステップ１１１３において、大きいと判定した場合は、ｒｗｎｄ５２７を０にして（ステップ１１１７）、処理を終了する（ステップ１１１６）。ステップ１１１３において、否と判定した場合は、計測した送信スループットと閾値を乗算した値と、装置に蓄積された中継データサイズの合計値と、の差をｒｗｎｄ５２７に設定する（ステップ１１１４）。更に、ｒｗｎｄ５２７を右にｗａｎ＿ｗｓ５１８シフトした値と、６５５３５のどちらか小さい方を、新たなｒｗｎｄ５２７の値として（ステップ１１１５）、終了する（ステップ１１１６）。ステップ１１１５により、例えばＡＣＫに書き込める最大値６５５３５を超える場合は、ｒｗｎｄ５２７が最大値６５５３５となる。なお、ＡＣＫに書き込める最大値は他の値が定められていてもよい。

図１１Ａに示したＬＡＮ側ＴＣＰモジュール２０３の受信履歴更新部７２６の行う処理により、装置に蓄積された中継データの合計値と、計測したＷＡＮ側の送信スループットとに基づいて、ＬＡＮ側に返信するＡＣＫパケットに記載する受信ウィンドウサイズを定める手段が実現される。更に、蓄積された中継データの合計値を、計測した送信スループットで除算した値が、ある閾値以上になったときに、ＬＡＮ側に送信するＡＣＫパケットに記載する受信ウィンドウサイズの値を０にする手段が実現される。

なお、特許文献２には、例えば受信履歴更新部７２６における、図１１Ａに示したような、送信帯域制御部７１５が計測したＷＡＮ側の送信スループットと、装置に蓄積された中継データサイズに基づいてｒｗｎｄ５２７を計算する手段や、図１２に示したような、ｒｗｎｄ５２７の変化をトリガとしてＡＣＫパケットを返信する手段について記載がない。上に記載した効果は、図１１Ａに示すｒｗｎｄ５２７の計算方法と、図１２に示すＡＣＫ返信方法とを用いて、初めて可能となる。

図１１Ｂには、ＬＡＮ側ＴＣＰモジュール２０３の受信履歴更新部７２６の行うｒｗｎｄ５２７計算の別の一例を示したフローチャート図を示す。
全体的な処理の流れは、図１１Ａと同じであるが、ステップ１１１１がステップ１１１８へ変更されており、装置に蓄積された中継データの合計値を求める手法が異なる。ＷＡＮ送信バッファｓｂｕｆとＬＡＮ受信バッファｒｂｕｆに蓄積されたデータサイズと、加工中のデータサイズの合計値から、計測した送信スループットとラウンドトリップタイムの積を減算した値を、装置に蓄積された中継データの合計値とする（ステップ１１１８）。これにより、ラウンドトリップタイムＲＴＴが大きいほど、中継データの合計値が少なく見積もられ、ｒｗｎｄが大きめに設定されて、ＴＣＰ通信が多くのバッファ量を使うことができるようｒｗｎｄ５２７を制御することができ、ＲＴＴを考慮した受信ウィンドウサイズｒｗｎｄ５２７の計算が可能となる。

図１１Ｂに示したＬＡＮ側ＴＣＰモジュール２０３の受信履歴更新部７２６の行う処理により、装置に蓄積された中継データの合計値と、計測したＷＡＮ側の送信スループットと、ラウンドトリップタイムとに基づいて、ＬＡＮ側に送信するＡＣＫパケットに記載する受信ウィンドウサイズの値を計算する手段が実現される。更に、装置に蓄積された及び加工中の中継データの合計値を、計測したＷＡＮ側の送信スループットとラウンドトリップタイムの乗算値で減算した値を、計測したＷＡＮ側の送信スループットで除算した値が、ある閾値以上になったときに、ＬＡＮ側に送信するＡＣＫパケットに記載する受信ウィンドウサイズの値を０にする手段が実現される。

図１１Ｃには、ＬＡＮ側ＴＣＰモジュール２０３の受信履歴更新部７２６の行うｒｗｎｄ５２７計算のさらに別の一例を示したフローチャート図を示す。
全体的な処理の流れは、図１１Ｂと同じであるが、ステップ１１１８がステップ１１１９とステップ１１１２０へ変更されおり、装置に蓄積された中継データの合計値を求める手法が異なる。まず、ステップ１１１９において、計測した送信スループットと再送率と、ラウンドとリップタイムに基づいて、係数ｋを計算する。例えば、送信スループット、ラウンドトリップタイム、再送率が大きくなると、係数ｋも大きくなるように係数ｋを求める。より詳細な求め方を図１１Ｄで例示する。更に、ステップ１１２０において、ＷＡＮ送信バッファｓｂｕｆとＬＡＮ受信バッファｒｂｕｆに蓄積されたデータサイズと、加工中のデータサイズを加算した値から、計測した送信スループットとラウンドトリップタイムと係数ｋの積を減算した値を、装置に蓄積された中継データの合計値とする。これにより、例えば再送率が大きいほど、ＴＣＰ通信が多くのバッファ量を使うことができるよう、ｒｗｎｄ５２７を制御することができ、ＲＴＴを考慮した受信ウィンドウサイズｒｗｎｄ５２７計算が可能となる。例えば、再送率が大きいほどステップ１１１４で設定されるｒｗｎｄ５２７が他の例に比べて大きくなり、端末からのデータを受信してバッファにたまりやすくなる。再送率が大きい場合は再送のためのデータも含めてバッファにためておく必要があり、本例では他の例に比べてバッファに蓄積される量を多めにすることができる。

図１１Ｃに示したＬＡＮ側ＴＣＰモジュール２０３の受信履歴更新部７２６の行う処理により、中継装置に蓄積されたデータのサイズと、ＷＡＮ側の送信スループットと、ラウンドトリップタイムと、ＷＡＮ側の再送率とに基づいて、ＬＡＮ側に送信するＡＣＫパケットに記載する受信ウィンドウサイズの値を決定する手段が実現される。更に、ＷＡＮ側の送信スループットとラウンドトリップタイムとＷＡＮ側の再送率から係数を計算し、中継装置に蓄積されたデータのサイズを、ＷＡＮ側の送信スループットとラウンドトリップタイムと前記係数との乗算値で減算した値を、ＷＡＮ側の送信スループットで除算した値が、ある閾値以上になったときに、ＬＡＮ側に送信するＡＣＫパケットに記載する受信ウィンドウサイズの値を０にする手段が実現される。

図１１Ｄには、ＬＡＮ側ＴＣＰモジュール２０３の受信履歴更新部７２６の行うｒｗｎｄ５２７計算の別のより詳細な一例を示したフローチャート図を示す。
ｒｗｎｄ５２７計算がはじまると（ステップ１１００）、基準時刻前の送信帯域ｏｌｄ＿ｓｎｄ５３２とＲＴＴ平均値ｗａｎ＿ｒｔｔ５１９を乗算することで内部変数ｃを計算し、更に、内部変数ｋに１を代入する（ステップ１１０１）。その後、最大セグメントサイズ（１パケットに載せられる最大データサイズ）ｍｓｓを内部変数ｃで除算した値が、ｒｔｓ＿ｒａｔｉｏ５２８のｋ乗よりも大きいか否かを判定する（ステップ１１０２）。小さい場合はｋに２を加算して（ステップ１１０３）、ステップ１１０２を繰り返す。ステップ１１０２が真の場合は、内部変数ｃをｃ＝ｃ＊ｋ＋ｏｌｄ＿ｓｎｄ＊ｔｈｒに更新する（ステップ１１０４）。更に、内部変数ｃが、ＷＡＮ側送信バッファの蓄積データサイズとＬＡＮ側受信バッファの蓄積データサイズと加工中のデータサイズの和ｗａｎ＿ｒｉｇｈｔ＿ｓｂｕｆ５２６−ｗａｎ＿ｌｅｆｔ＿ｓｅｎｄ５２４＋ｌａｎ＿ｒｉｇｈｔ＿ｒｅｃｖ５１０−ｌａｎ＿ｌｅｆｔ＿ｒｂｕｆ５０８＋ｌａｎ＿ｗａｎ５２９よりも大きいか否かを判定する（ステップ１１０５）。小さい場合は、ｒｗｎｄを０にして（ステップ１１０８）、終了する（ステップ１１０９）。ステップ１１０５が真の場合は、内部変数ｃと、ＷＡＮ側送信バッファの蓄積データサイズとＬＡＮ側受信バッファの蓄積データサイズと加工中のデータサイズの和ｗａｎ＿ｒｉｇｈｔ＿ｓｂｕｆ５２６−ｗａｎ＿ｌｅｆｔ＿ｓｅｎｄ５２４＋ｌａｎ＿ｒｉｇｈｔ＿ｒｅｃｖ５１０−ｌａｎ＿ｌｅｆｔ＿ｒｂｕｆ５０８＋ｌａｎ＿ｗａｎ５２９と、の差を、ｒｗｎｄ５２７の値とする（ステップ１１０６）。更に、ｒｗｎｄ５２７を右にｗａｎ＿ｗｓ５１８シフトした値と、６５５３５のどちらか小さい方を、新たなｒｗｎｄ５２７の値として（ステップ１１０７）、終了する（ステップ１１０９）。

これにより、ＲＴＴや再送率が大きいほど、ＴＣＰ通信が多くのバッファ量を使うことができるよう、ｒｗｎｄ５２７を制御することができ、ＲＴＴを考慮した受信ウィンドウサイズｒｗｎｄ５２７計算が可能となる。
図１１Ｄに示した、ｒｗｎｄ値の計算方式により、ＷＡＮ側のＴＣＰ通信の送信スループットｏｌｄ＿ｓｎｄと、再送率ｒｔｓ＿ｒａｔｉｏと、ＲＴＴと、ＬＡＮ側の未整列データサイズと整列済みデータサイズと、ＷＡＮ側の送信バッファの未送信データサイズとＡＣＫ待ちデータサイズと、加工中のデータサイズに基づいて、ＬＡＮ側の送信端末へ返信するＡＣＫパケットに記載する受信ウィンドウサイズ（ｒｗｎｄ）の値を制御することができる。

図１１Ａ〜Ｄに示したｒｗｎｄ値の計算方式により、ＷＡＮ側の回線帯域がＬＡＮ側の回線帯域よりも小さいときに、ＬＡＮ側の送信端末のデータの送信しすぎを防止することができる。これにより、ＷＡＮ側の送信バッファとＬＡＮ側の受信バッファが満杯になることによる通信停止時間の長期化およびそれに伴うタイムアウトとコネクション強制切断を防ぐことができる。

更に、図１２Ｂのステップ１２０６およびステップ１２０７を備えることで、データパケットの受信が無いときでも、ＬＡＮ側の送信端末に通知すべきｒｗｎｄがＭＳＳを超過したら即座に、ｒｗｎｄを記載したＡＣＫパケットをＬＡＮ側の送信端末に返信できるようになる。これにより、ＬＡＮ側の送信端末は、ＬＡＮ側の受信バッファに空きが生じたことを直ちに知り、送信を再開することができる。

図１５と図１６を用いて、装置１０１、１０２の効果を説明する。
図１５には、端末１１１と端末１２１との間の通信を、装置１０１、１０２が中継する際のシーケンス図を示す。図１６には、端末１１１と装置１０１との間のＬＡＮ帯域１６０１と、装置１０１と装置１０２との間のＷＡＮ帯域１６０２の推移を示す。
装置１０１は、この例ではＬＡＮ側に２パケット蓄積可能な受信バッファｒｂｕｆと、ＷＡＮ側に３パケット蓄積可能な送信バッファｓｂｕｆを備える（１５０１）。端末１１１から１つ目のデータパケットが送信されると、ＬＡＮ側の受信バッファにパケットが１つ蓄積される（１５０２）。１つ目のデータパケット受信後、装置１０１は、１つ目のデータを受け取ったことを表すＡＣＫ＝１と、ＷＡＮ側の制御帯域・ＲＴＴ・再送率とバッファの使用状況から計算したｗｉｎ＿ｓｉｚｅ＝３を記載したＡＣＫパケットを端末１１１に向けて返信する。ｗｉｎ−ｓｉｚｅが上述のｒｗｎｄに相当する。ＬＡＮ側の受信バッファに蓄積された１つ目のデータは、ＷＡＮ側の送信バッファに移される（１５０３）。１つ目のデータは、ＷＡＮ側の送信バッファに移された後、ＷＡＮ側に向けて送られるが、ここでは廃棄されてしまうものとする。データ廃棄が起きると、ＷＡＮ側の制御帯域は減少する。

次に、ＬＡＮ側の端末１１１から２つ目のデータパケットが送信されると、ＬＡＮ側の受信バッファにパケットが１つ蓄積される（１５０４）。２つ目のデータパケット受信後、装置１０１は、ＷＡＮ側の制御帯域・ＲＴＴ・再送率とバッファの使用状況からｗｉｎ＿ｓｉｚｅを計算する。ＷＡＮ側の制御帯域が減少し、バッファ使用量が増加したので、ｗｉｎ＿ｓｉｚｅは減少する。装置１０１は、２つ目のデータを受け取ったことを表すＡＣＫ＝２と、減少したｗｉｎ＿ｓｉｚｅ＝２を記載したＡＣＫパケットを端末１１１に向けて返信する。ＬＡＮ側の受信バッファに蓄積された２つ目のデータは、ＷＡＮ側の送信バッファに移される（１５０５）。１つ目のデータが廃棄されて、ＷＡＮ側の制御帯域が小さいままなので、２つ目のデータは、ＷＡＮ側の送信バッファに移された後、しばらくはＷＡＮ側に向けて送信されずに、蓄積される。

次に、ＬＡＮ側の端末１１１から３つ目のデータパケットが送信されると、ＬＡＮ側の受信バッファにパケットが１つ蓄積される（１５０６）。３つ目のデータパケット受信後、装置１０１は、ＷＡＮ側の制御帯域・ＲＴＴ・再送率とバッファの使用状況からｗｉｎ＿ｓｉｚｅを計算する。ＷＡＮ側の制御帯域が減少したままで、バッファ使用量が増加したので、ｗｉｎ＿ｓｉｚｅは減少する。装置１０１は、３つ目のデータを受け取ったことを表すＡＣＫ＝３と、減少したｗｉｎ＿ｓｉｚｅ＝１を記載したＡＣＫパケットを端末１１１に向けて返信する。ＬＡＮ側の受信バッファに蓄積された３つ目のデータは、ＷＡＮ側の送信バッファに移される（１５０７）。１つ目のデータが廃棄されて、ＷＡＮ側の制御帯域が小さいままなので、３つ目のデータは、ＷＡＮ側の送信バッファに移された後、しばらくはＷＡＮ側に向けて送信されずに、蓄積される。前回、蓄積されたままだった２つ目のデータが、例えばここでＷＡＮ側に向けて送信される。

次に、ＬＡＮ側の端末１１１から４つ目のデータパケット１５１３が送信されると、ＬＡＮ側の受信バッファにパケットが１つ蓄積される（１５０８）。４つ目のデータパケット１５１３受信後、装置１０１は、ＷＡＮ側の制御帯域・ＲＴＴ・再送率とバッファの使用状況からｗｉｎ＿ｓｉｚｅを計算する。ＷＡＮ側の制御帯域が減少したままで、バッファ使用量が増加したので、ｗｉｎ＿ｓｉｚｅは減少する。装置１０１は、４つ目のデータを受け取ったことを表すＡＣＫ＝４と、減少したｗｉｎ＿ｓｉｚｅ＝０を記載したＡＣＫパケット（１５１４）を端末１１１に向けて返信する。

このように、装置１０１からＷＡＮ側の装置１０２への出力スループットが、ＬＡＮ側の端末１１１から装置１０１への入力スループットよりも相対的に小さい時は、ＬＡＮ側の受信バッファに空きがあっても、図１３に示した従来方式よりも早めにバッファ残存量０であることを示すｗｉｎ＿ｓｉｚｅ＝０を記載したＡＣＫパケットを端末１１１に送信する（１５１６）。ｗｉｎ＿ｓｉｚｅ＝０のＡＣＫパケットを受け取った端末１１１は、ＬＡＮ側の受信バッファが一杯と判断して、データ送信を停止する。これにより、ＬＡＮ側の端末１１１から装置１０１への入力スループットを小さくすることができ、データ送信停止時のバッファへのデータ蓄積量を少なくすることができる。

ＬＡＮ側の受信バッファに蓄積された４つ目のデータは、ＷＡＮ側の送信バッファが一杯なため、移されない（１５１５）。ＷＡＮ側の装置１０２から、データ２に対するＡＣＫが戻ってきても、データ１が送信できていないため、ＷＡＮ側の送信バッファに蓄積されたデータ１〜３は消去されずにそのまま残る（１５１５）。同様に、その後、装置１０１から３つ目のデータパケット（１５１７）が送信されて、データ３に対するＡＣＫが戻ってきても、データ１が送信できていないため、ＷＡＮ側の送信バッファに蓄積されたデータ１〜３は消去されずにそのまま残る（１５１８）。

データ１を送信してからしばらくたってから、装置１０１は、データ１を再送する（１５１９）。その後、装置１０２からデータ１〜３を受け取ったことを表すＡＣＫ＝３のＡＣＫパケット（１５２０）を受信して初めて、ＷＡＮ側の送信バッファに蓄積されたデータ１〜３が消去される（１５０９）。３つ目のデータまで送信できたので、ＷＡＮ側の制御帯域は回復する。

送受信バッファに蓄積していたデータ１〜３が消去され、データ４だけが残ると、ＷＡＮ側の制御帯域・ＲＴＴ・再送率とバッファの使用状況からｗｉｎ＿ｓｉｚｅが再計算される。ＷＡＮ側の制御帯域が大きく回復し、バッファへの蓄積量が減少したので、ｗｉｎ＿ｓｉｚｅは増加する。ｗｉｎ＿ｓｉｚｅが０より大きくなると、即座に、３に増加したｗｉｎ＿ｓｉｚｅ＝３を記載したＡＣＫパケット（１５２２）が、端末１１１に向けて返信される。このように、バッファ残存量に余裕ができて、ｗｉｎ＿ｓｉｚｅの値が回復すると、即座にＡＣＫパケットが送信され、ｗｉｎ＿ｓｉｚｅの値が通知される（１５２１）。
その後、ＬＡＮ側の受信バッファに蓄積された４つ目のデータが、ＷＡＮ側の送信バッファへ移される（１５１０）。

次に、ＬＡＮ側の端末１１１から５つ目のデータパケットが送信されると、ＬＡＮ側の受信バッファにパケットが１つ蓄積される（１５１１）。５つ目のデータパケット受信後、装置１０１は、ＷＡＮ側の制御帯域・ＲＴＴ・再送率とバッファの使用状況からｗｉｎ＿ｓｉｚｅを計算する。バッファ使用量が増加したのでｗｉｎ＿ｓｉｚｅは減少する。５つ目のデータを受け取ったことを表すＡＣＫ＝５と、減少したｗｉｎ＿ｓｉｚｅ＝２を記載したＡＣＫパケットを端末１１１に向けて返信する。更に、４つ目のデータをＷＡＮ側へ送信すると共に、ＬＡＮ側の受信バッファに蓄積された５つ目のデータが、ＷＡＮ側の送信バッファへ移される（１５１２）。

以上のように、ＷＡＮ側の回線帯域がＬＡＮ側の回線帯域よりも小さく、装置１０１からＷＡＮ側の装置１０２への出力スループット（１６０２）が、ＬＡＮ側の端末１１１から装置１０１への入力スループット（１６０１）よりも小さい時に、装置１０１は、ＬＡＮ側の受信バッファとＷＡＮ側の送信バッファの残存量が少なくなってくると、早めにｗｉｎ＿ｓｉｚｅ＝０を記載したＡＣＫパケットを装置１１１へ送ることで、送信端末１１１の送信を停止させる。これにより、ＬＡＮ側の端末１１１から装置１０１への入力スループットを少なくすることができ（１６０１）、データ送信停止時のバッファへのデータ蓄積量を少なくすることができる（１６０３）。データ蓄積量が少ないため、ＷＡＮ側の装置１０２へのデータ送信が進展し、バッファ残存量に余裕ができるまでの時間も短期化し、送信再開までの時間を短くすることができる（１６０４）。更に、バッファ残存量が回復したときに、直ちに０よりも大きなｗｉｎ＿ｓｉｚｅを送信端末１１１に通知することで、データ送信を即座に再開させることができる。これらにより、ＬＡＮ側の送信端末１１１から装置１０１への送信停止時間が小さくなり、コネクションが切断されたとＬＡＮ側の送信端末１１１に誤認されることによるコネクション強制切断が起きにくくなる（１６０４）。加えて、装置１０１におけるＬＡＮ側の受信バッファとＷＡＮ側の送信バッファへのデータ蓄積量のゆらぎが小さくなり、底をつきにくくなるため、ＷＡＮ側の送信帯域を一定に保ちやすくなる（１６０２）。

上述の本実施の形態の態様により、ＬＡＮ側とＷＡＮ側の２つのＴＣＰ通信を中継する中継装置において、ＷＡＮ側の回線帯域がＬＡＮ側の回線帯域よりも小さく、中継装置からＷＡＮ側への出力スループットが、ＬＡＮ側の送信端末から中継装置への入力スループットよりも相対的に小さいときに、ＬＡＮ側ＴＣＰ通信向け受信バッファに空きがあっても、早めに、バッファ残存量０であることをＬＡＮ側の送信端末へ通知して送信を停止させることができる。これにより、ＬＡＮ側の送信端末から中継装置への入力スループットが小さくなるので、ＬＡＮ側のＴＣＰ通信の受信バッファとＷＡＮ側のＴＣＰ通信の送信バッファに、短時間で大量のデータが蓄積され溢れることを防ぐ。加えて、バッファへの蓄積量を少なくすることにより、中継装置のバッファに再び余裕が生じて、通信が再開されるまでの通信停止時間を短縮する。更に、バッファに余裕が生じたときに、そのことを直ちに送信端末に通知することで、通信を即座に再開させ、通信停止時間を短縮する。これらの効果により、ＬＡＮ側の送信端末と中継装置との間の通信停止時間が短縮され、通信が切断されたとＬＡＮ側の送信端末に誤認され、タイムアウトにより、コネクションが強制切断されてしまうことを防ぐ。

本発明は、例えば端末間の通信を中継する通信装置に利用可能である。

１０１ 装置
１０２ 装置
１０３ 装置
１１０ ネットワーク
１２１ 端末
２００ 通信装置
２０３、２０９ ＴＣＰモジュール
２０４、２０８ 受信バッファ
２０５、２０７ 送信バッファ
２０６ プロキシ
２１２ 状態テーブル
２１３ 帯域テーブル
３０１ ポインタ
４００ ヘッダデータ
５２０ エントリ
６０１ 機能ブロック
７０４ パケット再送部
７０５ 送信履歴更新部
７１５ 送信帯域制御部
７２６ 受信履歴更新部

Claims (14)

1. 第１網と第２網のＴＣＰ通信を中継する通信装置において、
   第１網から受信し、第２網へ中継する中継データを一時的に蓄積するバッファと、
   前記バッファに蓄積した中継データのサイズを計算する受信部と、
   第２網への実際の送信スループットを計測する送信帯域制御部と
   を備え、
   前記受信部は、
   中継データのサイズと、送信スループットとに基づいて、第１網側のＴＣＰ通信で送信するＡＣＫパケットに記載する受信ウィンドウサイズの値を計算する前記通信装置。
2. 請求項１に記載の通信装置において、
   前記バッファが空いていても残存量が所定量以下であれば残存量をゼロとして、前記ＡＣＫパケットに記載する受信ウィンドウサイズの値を定める通信装置。
3. 請求項１に記載の通信装置において、
   前記受信部は、
   中継データのサイズを、送信スループットで除算し、
   中継データのサイズを送信スループットで除算した値が、予め定められた閾値以上の場合に、
   第１網側のＴＣＰ通信で送信するＡＣＫパケットに記載する前記受信ウィンドウサイズの値を０にすることを特徴とする通信装置。
4. 請求項１に記載の通信装置において、
   第２網でのラウンドトリップタイムを記録する第１記憶領域
   をさらに備え、
   前記受信部は、
   前記中継データのサイズと、前記送信スループットと、前記ラウンドトリップタイムとに基づいて、第１網側のＴＣＰ通信で送信するＡＣＫパケットに記載する前記受信ウィンドウサイズの値を計算することを特徴とする通信装置。
5. 請求項４に記載の通信装置において、
   前記受信部は、
   前記中継データのサイズから、前記送信スループットと前記ラウンドトリップタイムの乗算値を減算した値を、送信スループットで除算した値が、予め定められた閾値以上の場合に、
   第１網側のＴＣＰ通信で送信するＡＣＫパケットに記載する前記受信ウィンドウサイズの値を０にすることを特徴とする通信装置。
6. 請求項４に記載の通信装置において、
   第２網側のＴＣＰ通信においてパケット廃棄を検出したときに、廃棄パケットを再送するパケット再送部
   をさらに備え、
   前記送信帯域制御部は、
   第２網側のＴＣＰ通信での再送スループットを計測し、計測した再送スループットを送信スループットで除算することで再送率を計算し、
   前記受信部は、
   前記中継データのサイズと、前記送信スループットと、前記ラウンドトリップタイムと、再送率とに基づいて、第１網側のＴＣＰ通信で送信するＡＣＫパケットに記載する前記受信ウィンドウサイズの値を決定することを特徴とする通信装置。
7. 請求項６に記載の通信装置において、
   前記受信部は、
   前記送信スループットと前記ラウンドトリップタイムと前記再送率の増加に伴い大きくなる係数を計算し、
   前記中継データのサイズから、前記送信スループットとラウンドトリップタイムと前記係数との乗算値を減算した値を、送信スループットで除算した値が、予め定められた閾値以上の場合に、
   第１網側のＴＣＰ通信で送信するＡＣＫパケットに記載する前記受信ウィンドウサイズの値を０にすることを特徴とする通信装置。
8. 請求項６に記載の通信装置において、
   インターバル時間を保持する第２記憶領域と、
   現在時刻との基準時刻との差がインターバル時間よりも大きいときに、該インターバル時間が加算される該基準時刻を記録する第３記憶領域と、
   基準時刻後の再送スループットと、基準時刻前の送信スループットを記録する第４記憶領域と
   をさらに備え、
   前記受信部は、
   基準時刻後の再送スループットを、基準時刻前の送信スループットで除算することで再送率を求めることを特徴とする通信装置。
9. 請求項１に記載の通信装置において、
   前記バッファは、
   第１網からの受信データを整列されるまで蓄積しておき、整列後も読み出されるまで蓄積しておく第１網側受信バッファと、
   第２網への送信データを蓄積しておき、データ送信後も第２網側からＡＣＫを受信するまで蓄積しておく第２網側送信バッファと
   を有し、
   前記受信部は、
   前記第１網側受信バッファに蓄積された整列済みデータと未整列データのサイズと、前記第２網側送信バッファに蓄積された未送信データとＡＣＫ待ちデータのサイズとを加算することで、蓄積された中継データのサイズを計算することを特徴とする通信装置。
10. 請求項９に記載の通信装置において、
    前記第１網側受信バッファの整列済みデータを読出し、前記第２側送信バッファへ未送信データとして書き込むデータ転送部
    をさらに備え、
    前記受信部は、
    前記データ転送部が処理中のデータのサイズをさらに加算することで、中継データのサイズを計算することを特徴とする通信装置。
11. 請求項１０に記載の通信装置において、
    前記データ転送部が、データ転送中にデータの加工を行うことを特徴とする通信装置。
12. 請求項１に記載の通信装置において、
    前記受信部は、
    第１網側のＴＣＰ通信で通知すべき受信ウィンドウサイズの値が予め定められた閾値未満に減少した後、再び該閾値以上に増加したときに、第１網側のＴＣＰ通信において受信パケットが無いときでも、第１網側のＴＣＰ通信での新たな受信ウィンドウサイズの値を求めて、該受信ウィンドウサイズの値を記載したＡＣＫパケットを送信することを特徴とする通信装置。
13. 請求項３に記載の通信装置において、
    前記受信部は、
    第１網側のＴＣＰ通信にて受信ウィンドウサイズの値を０にしたＡＣＫパケットを送信した後に、未受信データを含むパケットを受信したときに、
    第１網側のＴＣＰ通信での受信シーケンス番号をインクリメントして、受信ウィンドウサイズを０にしたＡＣＫパケットを送信することを特徴とする通信装置。
14. 請求項９に記載の通信装置において、
    前記受信部は、
    第１網側のＴＣＰ通信にて受信ウィンドウサイズの値を０にしたＡＣＫパケットを送信した後に、未受信データを含むパケットを受信したときに、
    前記第１網側の受信バッファに空きがあれば、受信したパケットを該第１網側受信バッファに蓄積して、
    第１網側のＴＣＰ通信での受信シーケンス番号をインクリメントして、受信ウィンドウサイズを０にしたＡＣＫパケットを送信することを特徴とする通信装置。

Images