"2つの端末間に位置し、端末間のTCP通信を中継する第一の通信装置と第二の通信装置を備え、前記第二の通信装置が、通信中に受信できなかったデータの箇所を検出すると、未受信箇所の識別情報を確認応答パケットに含めて、前記第一の通信装置に対してフィードバック通知し、前記第一の通信装置は、フィードバック通知された確認応答パケットに含まれる未受信箇所のデータを含む再送パケットを前記第二の通信装置に送信し、前記第二の通信装置は、前記未受信箇所のデータを含む再送パケットを受信するまで、前記未受信箇所の識別情報を含む確認応答パケットを、前記第一の通信装置に対して、定期的にフィードバック通知する通信システム。前記第一の通信装置が予め定められたインターバル時間と、該インターバル時間毎に更新される基準時刻とを管理しており、現在時刻と基準時刻の差がインターバル時間を超過した場合に、基準時刻にインターバル時間を加算して該基準時刻を更新し、前記第一の通信装置が、再送/廃棄帯域と、送信帯域と、再送/廃棄帯域と送信帯域の総和を制限するための制御帯域とを、基準時刻以降現在時刻までの第一時間と、基準時刻から該基準時刻よりもインターバル時間前の旧基準時刻までの第二時間と、該旧基準時刻からさらにインターバル時間前までの第三時間とに分けてそれぞれ記録するテーブルを備え、基準時刻以降の前記第一時間の再送/廃棄帯域と、基準時刻以前の前記第二時間の制御帯域又は送信帯域とに基づいて、基準時刻以降の制御帯域を変化させることを特徴とする請求項1に記載の通信システム。基準時刻から旧基準時刻の間の前記第二時間の送信帯域又は制御帯域と、基準時刻以降現在時刻までの前記第一時間の再送/廃棄帯域との比で求められる第一再送率が、該旧基準時刻からさらにインターバル時間前までの前記第三時間の送信帯域又は制御帯域と、基準時刻から旧基準時刻の間の前記第二時間の再送/廃棄帯域との比で求められる第二再送率よりも大きいときに、基準時刻以降の制御帯域を、基準時刻以降の再送/廃棄帯域に基づいて、基準時刻から旧基準時刻の間の前記第二時間の制御帯域よりも小さくなるように減少させることを特徴とする請求項2に記載の通信システム。基準時刻から旧基準時刻の間の前記第二時間の送信帯域又は制御帯域と、基準時刻以降現在時刻までの前記第一時間の再送/廃棄帯域との比で求められる第一再送率が、該旧基準時刻からさらにインターバル時間前までの前記第三時間の送信帯域又は制御帯域と、基準時刻から旧基準時刻の間の前記第二時間の再送/廃棄帯域との比で求められる第二再送率よりも小さいとき、制御帯域を減少させた時点より所定の期間経過しているか判定し、前記判定結果、所定の期間経過している場合は、基準時刻以降の制御帯域を第一の量大きくなるよう制御し、前記判定結果、所定の期間経過していない場合は、第一の量より小さい第二の量だけ大きくなるよう制御する、ことを特徴とする請求項3に記載の通信システム。前記第一の通信装置が、一定時間毎の送信量を定めたトークンサイズを制御することで制御帯域を制御する請求項1に記載の通信システム。前記第一の通信装置及び前記第二の通信装置は、プロキシ装置である請求項1に記載の通信システム。前記通信システムは、前記第一の通信装置がデータ送信端末との第一のTCP通信を実施し、前記第二の通信装置がデータ受信端末との第二のTCP通信を実施し、前記第一の通信装置と前記第二の通信装置の間で第三のTCP通信を実施し、各TCP通信が送信データの再送と受信データの整列を独立して実施し、前記第一の通信装置は、第一のTCP通信においてデータ付パケットを受信した場合は、少なくともひとつ前に受信したデータ付パケットに対する確認応答、又は、最後尾データより手前のデータに対する確認応答を返信し、第三のTCP通信において確認応答待ちの送信中データが有り、かつ、第一のTCP通信において整列待ちの受信中データが無い状態で第三のTCP通信において確認応答を受信して確認応答待ちの送信中データが無くなったタイミングで、第一のTCP通信において受信した最後尾データに対する確認応答を返信することを特徴とする請求項1に記載の通信システム。第三のTCP通信において確認応答待ちの送信中データが有り、又は、第一のTCP通信において整列待ちの受信中データが有る状態で第一のTCP通信においてデータ付パケットを受信した場合に、前記少なくともひとつ前に受信したデータ付パケットに対する確認応答、又は、前記最後尾データより手前のデータに対する確認応答を返信する請求項7に記載の通信システム。第三のTCP通信において確認応答待ちの送信中データが無く、かつ、第一のTCP通信において整列待ちの受信中データも無い状態で、第一のTCP通信においてデータ付パケットを受信した場合は確認応答の返信を行わない請求項8に記載の通信システム。前記第一の通信装置は、第三のTCP通信に対する送信バッファと、第一のTCP通信に対する受信バッファとを備え、第三のTCP通信の前記送信バッファ内に確認応答待ちの送信中データが記憶され、第一のTCP通信の前記受信バッファ内に整列待ちの受信中データが記憶され、前記送信バッファを参照して、第三のTCP通信において確認応答待ちの送信中データが有るか否か判定し、前記受信バッファを参照して第一のTCP通信において整列待ちの受信中データが有るか否かを判定する請求項7に記載の通信システム。第一のデータ通信と第二のデータ通信の2つのデータ通信を中継する通信装置において、第二のデータ通信においてデータ付パケットを受信した場合は、少なくともひとつ前に受信したデータ付パケットに対する確認応答、又は、最後尾データより手前のデータに対する確認応答を返信し、第一のデータ通信において確認応答待ちの送信中データが有り、かつ、第二のデータ通信において整列待ちの受信中データが無い状態で第一のデータ通信において確認応答を受信して確認応答待ちの送信中データが無くなったタイミングで、第二のデータ通信において受信した最後尾データに対する確認応答を返信する通信装置。第一のデータ通信において確認応答待ちの送信中データが有り、又は、第二のデータ通信において整列待ちの受信中データが有る状態で第二のデータ通信においてデータ付パケットを受信した場合に、前記少なくともひとつ前に受信したデータ付パケットに対する確認応答、又は、前記最後尾データより手前のデータに対する確認応答を返信する請求項11に記載の通信装置。第一のデータ通信において確認応答待ちの送信中データが無く、かつ、第二のデータ通信において整列待ちの受信中データも無い状態で、第二のデータ通信においてデータ付パケットを受信した場合は確認応答の返信を行わない請求項12に記載の通信装置。第一のデータ通信に対する送信バッファと、第二のデータ通信に対する受信バッファとを備え、第一のデータ通信の前記送信バッファ内に確認応答待ちの送信中データが記憶され、第二のデータ通信の前記受信バッファ内に整列待ちの受信中データが記憶され、前記送信バッファを参照して、第一のデータ通信において確認応答待ちの送信中データが有るか否か判定し、前記受信バッファを参照して第二のデータ通信において整列待ちの受信中データが有るか否かを判定する請求項11に記載の通信装置。第一のデータ通信において確認応答待ちの送信中データが有り、又は、第二のデータ通信において整列待ちの受信中データが有る状態で、第二のデータ通信において、前回受信したデータ付パケットと同じデータ付パケットを受信した場合は、前回確認応答を返信したデータよりも後ろで、かつ、最後尾データより手前のデータに対する確認応答を返信することを特徴とする請求項12に記載の通信装置。第一のデータ通信で予測コマンドを送信し、第一のデータ通信で受信したデータ又は該データに対して加工を施したデータを、第二のデータ通信にて送信した後で、第二のデータ通信において予測コマンドに対するデータ付パケットを受信した場合は、該データ付パケットの最後尾データに対する確認応答を第二のデータ通信で返信することを特徴とする請求項11に記載の通信装置。第二のデータ通信において、PSHフラグ付のデータパケットを受信した後、第一のデータ通信において、確認応答を受信して確認応答待ちの送信中データが無くなった状態になったタイミングで、第二のデータ通信において受信したデータパケットのうち、最後尾に位置するデータパケットに対する確認応答を返信することを特徴とする請求項11に記載の通信装置。TCPを用いた通信では、RTTや廃棄検出の有無に応じて、送信帯域を制御するため、送信帯域がRTTと廃棄率に大きく影響を受ける。このため、WANのようなRTTが大きく、ホップ数が大きく廃棄発生箇所が多い環境では、契約帯域を大幅に下回る送信帯域しか得られない場合があるという課題がある。また、非特許文献1や特許文献1に記載の技術では、受信側からフィードバック通知された受信帯域や輻輳有無の情報を用いて送信帯域を制御する。輻輳有無は通知されるが、輻輳の大きさが分からないため、どの程度、送信帯域を増減させればよいか分からない、という課題がある。また、特許文献2に記載の技術では、データ本体の送信帯域、誤り符号データの送信帯域、廃棄したデータの再送帯域の総和が一定値となるように制御を行う。制御帯域の総和が一定であるため、1つの回線を複数の通信が共有するケースなど、他の通信と競合して使用可能な帯域が減ったときに、再送帯域が制御帯域を超過して、データが全く送信できなくなってしまう、という課題がある。また、特許文献3に記載の技術は、装置の入力帯域と出力帯域の差分であるパケット廃棄帯域が一定値を超過したときに、帯域制限値を変化させることができるが、装置から受信端末までの通信経路上の輻輳状態廃棄帯域を考慮した帯域制限をすることができない、という課題がある。しかし、通信装置が、TCPプロトコルに基づいて、送信端末から末尾のデータを受信して確認応答のACKパケットを返信し、その直後に故障した場合、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースが発生し得る。このケースでは、受信端末側のデータが更新されないまま、送信端末側のアプリケーションが終了してしまい、受信端末に書き込むはずだったデータが書き込まれないまま消えてしまう、という課題が発生する。本発明は、以上の点に鑑み、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースの発生を防ぐことを目的とする。また、本発明は、通信装置が、送信端末から末尾のデータを受信し、その直後に故障した場合でも、送信端末との通信の状態と、受信端末との通信の状態を一致するようにすることを目的の一つとする。上記課題を解決するために、本願発明の一態様では、受信端末側からの第一のデータパケットに対するACKパケット待ち状況に応じて、第一のデータパケットより後に送信端末から送信された第二のデータパケットに対するACKパケットを、送信端末に送信する、送信端末と受信端末とのパケット送受信を仲介する通信装置である。特に、通信装置内にACK待ちの送信中データも整列待ちの受信中データも無い状態でデータパケットを受信した場合はACK返信を行わず、通信装置内にACK待ちの送信中データ、或いは整列待ちの受信中データが有る状態でデータパケットを受信した場合は1つ前に受信したデータパケットに対するACKを返信し、受信端末側からACKを受信してACK待ちの送信中データも整列待ちの受信中データも無い状態になったタイミングで通常のACKを返信するための手段を備える。本発明の別の態様によると、2つの端末間に位置し、端末間のTCP通信を中継する第一の通信装置と第二の通信装置を備え、前記第二の通信装置が、通信中に受信できなかったデータの箇所を検出すると、未受信箇所の識別情報を確認応答パケットに含めて、前記第一の通信装置に対してフィードバック通知し、前記第一の通信装置は、フィードバック通知された確認応答パケットに含まれる未受信箇所のデータを含む再送パケットを前記第二の通信装置に送信し、前記第二の通信装置は、前記未受信箇所のデータを含む再送パケットを受信するまで、前記未受信箇所の識別情報を含む確認応答パケットを、前記第一の通信装置に対して、定期的にフィードバック通知する通信システムが提供される。また、本発明の別の態様によると、第一のデータ通信と第二のデータ通信の2つのデータ通信を中継する通信装置において、第二のデータ通信においてデータ付パケットを受信した場合は、少なくともひとつ前に受信したデータ付パケットに対する確認応答、又は、最後尾データより手前のデータに対する確認応答を返信し、第一のデータ通信において確認応答待ちの送信中データが有り、かつ、第二のデータ通信において整列待ちの受信中データが無い状態で第一のデータ通信において確認応答を受信して確認応答待ちの送信中データが無くなったタイミングで、第二のデータ通信において受信した最後尾データに対する確認応答を返信する通信装置が提供される。本発明の第1の解決手段によると、第一のTCP通信と第二のTCP通信の2つのTCP通信を中継する通信装置において、第二のTCP通信においてデータ付パケットを受信した場合は、少なくともひとつ前に受信したデータ付パケットに対する確認応答、又は、最後尾データより手前のデータに対する確認応答を返信し、第一のTCP通信において確認応答待ちの送信中データが有り、かつ、第二のTCP通信において整列待ちの受信中データが無い状態で第一のTCP通信において確認応答を受信して確認応答待ちの送信中データが無くなったタイミングで、第二のTCP通信において受信した最後尾データに対する確認応答を返信する通信装置が提供される。この通信装置によると、通信装置が故障しても、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースの発生を防ぐ効果がある。本発明の第2の解決手段によると、2つの端末間に位置し、端末間のTCP通信を3つのTCP通信に分割して中継する第一の通信装置と第二の通信装置を備え、前記第一の通信装置がデータ送信端末との第一のTCP通信を実施し、前記第二の通信装置がデータ受信端末との第二のTCP通信を実施し、前記第一の通信装置と前記第二の通信装置の間で第三のTCP通信を実施し、各TCP通信が送信データの再送と受信データの整列を独立して実施する通信システムであって、前記第二の通信装置が、通信中に受信できなかったデータの箇所を検出すると、未受信箇所の識別情報を確認応答パケットに含めて、前記第一の通信装置に対してフィードバック通知し、前記第一の通信装置は、フィードバック通知された確認応答パケットに含まれる未受信箇所のデータを含む再送パケットを前記第二の通信装置に送信し、前記第二の通信装置は、前記未受信箇所のデータを含む再送パケットを受信するまで、前記未受信箇所の識別情報を含む確認応答パケットを、前記第一の通信装置に対して、定期的にフィードバック通知する前記通信システムが提供される。この通信システムによると、RTT毎の送信量を定めたウィンドウサイズ2605を制御することにより、帯域制御を行うTCP通信しかできない端末間でも、RTTや廃棄率に依存しない通信を実現することができる。本発明によると、通信装置が、送信端末から末尾のデータを受信し、その直後に故障した場合でも、送信端末との通信の状態と、受信端末との通信の状態が一致するため、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースが発生しなくなる。本発明を実施するための代表的な形態は、以下のとおりである。まず、第一のTCP通信と第二のTCP通信の2つのTCP通信を中継する通信装置が、各TCP通信に対して送信バッファと受信バッファを持ち、1第一のTCP通信の送信バッファ内にACK待ちの送信中データが無く、尚且つ、第二のTCP通信の受信バッファ内に整列待ちの受信中データも無い状態で、第二のTCP通信においてデータパケットを受信した場合はACK返信を行わず、2第一のTCP通信の送信バッファ内にACK待ちの送信中データが有り、或いは、第二のTCP通信の受信バッファ内に整列待ちの受信中データが有る状態で、第二のTCP通信においてデータパケットを受信した場合は少なくとも1つ前に受信したデータパケットに対するACKを返信し、3第一のTCP通信の送信バッファ内にACK待ちの送信中データが有り、尚且つ、第二のTCP通信の受信バッファ内に整列待ちの受信中データが無い状態で、第一のTCP通信においてACKを受信してACK待ちの送信中データが無くなった状態になったタイミングで、第二のTCP通信において受信したデータパケットのうち、最後尾に位置するデータパケットに対するACKを返信するための手段を備える態様とした。この態様により、受信端末が、送信端末から送信した末尾データを受信するまで、送信端末は末尾データに対するACKを受け取ることができないため、通信装置が故障しても、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースの発生を防ぐ効果がある。本態様の詳細は、実施例1を中心に後述する。別の様態として、TCPフラグとしてPSHフラグを持つデータパケットを受信したときのみ、実施例1に記載のACK返信方法を実施する態様とした。この態様により、送信端末が末尾データ送信時にPSHフラグを付加するケースでは、実施例1と同等の効果が得られる。本態様の詳細は、実施例2を中心に後述する。更に、別の態様として、通信装置を端末間に2台設置し、端末間のTCP通信を3つのTCP通信に分割して、通信装置が中継する2つのTCP通信のうち、端末と通信装置間のTCP通信では、標準TCPを、通信装置間のTCP通信では特許出願1に記載の技術を用いる態様とした。この態様により、標準的なTCP通信しかできない端末間でも、RTTや廃棄率に依存しない通信を実現することができる。本態様の詳細は、実施例3を中心に後述する。更に、別の態様として、通信装置を端末間に2台設置し、端末間のTCP通信を3つのTCP通信に分割して、通信装置が中継する2つのTCP通信のうち、端末と通信装置間のTCP通信では、RTT毎の送信量を制御することによる標準的なTCP図27参照を、通信装置間のTCP通信では、特許出願1特願2009-214015号、PCT/JP2010/063973に記載の技術を用いつつ、さらに、実施例1に記載のACK返信方法を用いる態様とした。この態様により、TCP通信しかできない端末間でも、RTTや廃棄率に依存しない通信を実現することが出来、尚且つ、通信装置のいずれか一方が故障しても、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースの発生を防ぐ効果がある。本態様の詳細は、実施例4を中心に後述する。他の本発明の態様は、以下に述べる種々の実施例で説明される。以下、本発明の態様を詳細に説明するべく、通信の中継を行う通信装置の構成や処理シーケンスや、当該装置がネットワークを介して接続されることにより構成されるシステム等の詳細について実施例を用いて述べる。図1~図22を用いて、2つのTCP通信を中継中に故障した場合でも、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースを発生させない通信装置の実施例を示す。図1には、通信装置1910と通信装置2920をネットワーク0900とネットワーク1、2901、902の境界に設置して、ネットワーク1901に接続している端末903904と、ネットワーク2902に接続している端末905906の間で、3つのTCP通信を経由して通信が行われる様子を示す。通信装置1910は、ネットワークインターフェースNIF0/1915/916と、演算部911を備える。演算部911は、TCP通信を行うTCPモジュール913/914と、データの乗せ換えを行うProxyモジュール912を実行する。なお、本実施例では、通信装置910、920はひとつでもよい。また、通信装置910、920は、例えば、プロキシ装置でもよい。図2には、本実施例でやりとりされるパケットのフォーマット図を表す。パケットは、MACヘッダ2900、IPヘッダ2904、TCPヘッダ2909、TCPオプションヘッダ2916、ペイロード2927を含む。MACヘッダ2900は、宛先MACアドレスを表すDMAC2901と、送信元MACアドレスを表すSMAC2902と、MACフレームタイプを表すType2903を含む。IPヘッダ2904は、MACヘッダを除くパケット長を表すIPlength2905と、プロトコル番号を表すprotocol2906と、送信元IPアドレスを表すSIP2907と、宛先IPアドレスを表すDIP2908とを含む。TCPヘッダ2909は、送信元ポート番号を表すsrc.port2910と、宛先ポート番号を表すdst.port2911と、送信シーケンス番号を表すSEQ2912と、受信シーケンス番号を表すACK2913と、TCPフラグ番号を表すflag2914と、TCPのヘッダ長を表すtcphlen2915とを含む。TCPオプションヘッダ2916は、オプション種別を表すoptionkind2917と、オプション長を表すoptionlength2918と、どこからどこまで部分的に受信できたかを記載するleft_edge_1~42919、2921、2923、2925、right_edge_1~42920、2922、2924、2926を含む。図41には、従来のプロキシ装置の課題を説明するためのシーケンス図を表す。送信端末103から受信端末104に向けて、従来のプロキシ1200と従来のプロキシ2201とを経由して、4380バイトから構成されるファイルデータを1460バイトのデータを含むパケット3個110、113、116に分割して送信する場合105にやりとりされるパケットを示している。図41の送信端末103のパケット3個110、113、116には、送信シーケンス番号として0、1460、2920の値が記載される。プロキシ1200は、パケット110、113、116を受け取ると、受信パケット記載の送信シーケンス番号にペイロード長1460を加算して、その値を受信シーケンス番号ACKにした確認応答用のACKパケット121、122、127を送信端末103に返信する。送信端末103は、末尾データに対するACKパケット127を受信すると、送信が完了したと判断する230。その後で、プロキシ1200に障害が発生したとする232。この場合、パケット110、113に記載されていたデータについては、プロキシ2に向けてパケット111、114として送信され、プロキシ2経由でパケット112、115として受信端末104に送り届けられる。それぞれのパケットに対するACKパケット120、124、119、123も返信される。一方、パケット116に記載されていたデータは、障害発生232と共に消滅してしまい、プロキシ1200からは送信されなくなる。このため、受信端末104は、受信が未完了のままである231。すると、送信端末103では、送信が完了したと判断しているのにもかかわらず230、受信端末104では、受信が完了していないと判断している状態の不一致が発生することとなる。これは、プロキシ2201の障害発生でも起こりうる。上記の状態の不一致が発生した状態で、例えば、送信端末103でアプリケーションを使って編集したデータを受信端末104に送信完了してから、アプリケーションを終了するケースでは、受信端末104が編集データを受け取れないまま、送信端末のアプリケーションが終了してしまい、編集データが消滅してしまう、といった事態が起こる。以下、上述の状態の不一致を防ぐための構成処理を詳細に説明する。装置構成図3には、ハードウェアで実装した、本実施例の通信装置910のブロック図を表す。通信装置920も同様の構成である。通信装置910は、外部ネットワークとのパケットの送受信を行うネットワークインターフェースNIF0/11011/1012と、TCP以外のUDPパケット等を素通しさせるためのフィルタ1009/1010と、TCP通信のための制御を行うNIF0/1向けTCPモジュール1007/1008と、NIF0向けTCPモジュール1007の管理するN個Nは1以上の整数の送信バッファ1013およびN個の受信バッファ1015と、NIF1向けTCPモジュール1008の管理するN個の送信バッファ1016およびN個の受信バッファ1014と、送受信バッファ間でデータの乗せ換えを行うプロキシモジュール1000と、N個のエントリを備えた状態テーブル1001を有する。ソフトウェアで実装する際は、状態テーブル1001と送受信バッファ1013~1016を記憶部に持ち、フィルタ1009/1010とTCPモジュール1007/1008とプロキシモジュール1000の部分をモジュールとして演算部図1の演算部912に対応に持たせる。状態テーブル1001は、N個のエントリを持ち、各エントリは、IPアドレス、TCPのポート番号等を含むコネクション特定のための情報1002と、NIF0側のTCPのOPEN/CLOSE等の状態情報1003と、NIF1側のTCPのOPEN/CLOSE等の状態情報1004と、NIF0側の送受信バッファ管理用のポインタ情報1005と、NIF1側の送受信バッファ管理用のポインタ情報1006とを登録する。図4には、TCPモジュール1007/1008のブロック図を表す。標準TCPを実現するTCPブロック1007は、受信処理を行うRX部受信処理部3102と、送信処理を行うTX部送信処理部3101を有する。RX部3102は、受信パケットをTCP制御パケットとデータ付パケットとACK/部分的確認応答用SACKパケットに分離するパケット解析部3108と、受信したTCP制御パケットに基づいて状態テーブル1001内のTCP状態1003を変更するTCP制御部3107と、受信したデータパケットの送信シーケンス番号SEQ2912と受信シーケンス番号ACK2913とに基づいて、状態テーブル1001内のバッファ管理ポインタ1005を変更してACKパケットや部分的確認応答SACK付ACKパケットを返信する受信履歴更新部3106、とを有する。受信履歴更新部3106のバッファ管理ポインタ1005の変更については、後述する。TX部3101は、状態テーブル1001内のTCP状態1004を用いてTCP制御パケットを送信するTCP制御部3103と、受信したACKパケットに基づいて状態テーブル1001内のバッファ管理ポインタ1005を変更し、受信した部分的確認応答SACK付ACKパケットを用いて送信バッファ1015からデータを読み出してパケットを再送するTXパケット再送部3104と、送信バッファ1015からデータを読み出してパケットを送信して、状態テーブル1001内のバッファ管理ポインタ1005を変更する送信履歴更新部3105と、ACK/SACKパケット、TCP制御パケット、再送パケット、データパケットをFIFOで集約して出力するマルチプレクサ集約部3109およびバッファ3110~3113とを有する。なお、実施例1、2において、TCP1007/1008は同様の構成としてもよい。ポインタの説明図5には、送受信バッファ管理用のポインタの説明図を表す。本図では、データを左から右に書き込んでいき、左から右に読み出していくものとする。受信バッファ1013/1014は、受信したデータの先頭受信右端、データを書き込む先頭位置を示すポインタright_recv1103と、整列済みデータと未整列データの境界を示すポインタleft_recv1102と、プロキシモジュール1000による読出し済データと未読出しデータの境界を示すleft_rbuf1101と、受信できずに歯抜けになっているデータ箇所ロスセグメントの左端と右端を表すポインタleft/right_loss1107-1~SEG_SIZE最大SEG_SIZE個を管理する。受信したデータの先頭を示すポインタright_recv1103は、ロスの発生が無く、前から順番にデータを受信すると、受信したデータサイズ分増えて、右へ移動する。受信できずに歯抜けになっているデータ箇所ロスセグメントが存在する状態で、再送パケットを受信して、ロスセグメントが消滅すると、整列済みデータと未整列データの境界を示すポインタleft_recv1102は、最も小さなロスセグメントの左端まで移動する。プロキシモジュールは、読出し済データと未読出しデータの境界を示すleft_rbuf1101から順番にデータを読み出し、読み出したデータサイズ分、left_rbuf1101を右へ移動させる。読み出せるデータサイズの最大値は、left_recv1102とleft_rbuf1101の差である。送信バッファ1015/1016は、プロキシモジュール1000が書き込み済みで送信可能状態となっているデータの先頭送信右端を表すポインタright_sbuf1106と、送信済みデータの先頭を示すポインタright_send1105と、受信側から確認応答を受信済みのデータの先頭を示すポインタleft_send1104と、再送中のデータ箇所の左端と右端を表すポインタleft/right_rts1108-1~SEG_SIZE最大SEG_SIZE個を管理する。プロキシモジュールが書き込み済みで送信可能状態となっているデータの先頭を表すポインタright_sbuf1106は、プロキシモジュールがデータを書き込む毎に、書き込んだデータサイズ分増加し、右へ移動する。送信したデータの先頭を示すポインタright_send1105を始点として、新たなデータが送信され、right_send1105は、送信されたデータサイズ分増加し、右へ移動する。受信側から、left_send1104よりも大きな受信シーケンス番号を持つ確認応答パケットを受信すると、left_send1104は、確認応答パケットに記載された受信シーケンス番号へと増加し、右へ移動する。同一の受信シーケンス番号を持つ確認応答パケットを重複して受信するなど、再送が発生するケースでは、再送すべき箇所がleft/right_rts1108に記載され、実際に再送されるとleft/right_rts1108に0が代入され、再送済みとなる。図6には、NIF0向けTCPモジュール1007の送信バッファ1015と、NIF1向けTCPモジュール1008の受信バッファ1014を共有するケース、或いは、NIF1向けTCPの送信バッファ1016と、NIF0向けTCPの受信バッファ1013を共有するケースを示す。送信バッファ1016と受信バッファ1013間で、データを共有するために、プロキシモジュール1000は、受信したデータを受信バッファ領域から送信バッファ領域に移動する場合である。送信バッファと受信バッファの2つのバッファを、1つの送受信共用バッファとし、送信バッファ用のポインタright_sbuf1106と、受信バッファ用のポインタleft_rbuf1101が同一の値となる。この同一の値により、送信バッファ領域か、受信バッファ領域かが区別される。図7には、状態の不一致を防ぐための後述する図8に記載の通信装置100、101のACK返信方法を実現するために追加で必要となるバッファ管理用ポインタの説明図を示す。図5に示したポインタに加えて、直近のleft_recv1102の値を記録するためのポインタprev_left_recv1900をさらに有する。なお、図6のようにバッファを構成した場合も同様である。基本シーケンス図8には、本実施例における通信装置100、101のACK返信方法を記載したシーケンス図を表す。図41と同様に、送信端末103から受信端末104に向けて4380バイトから構成されるファイルデータを1460バイトのデータを含むパケット3個110、113、116に分割して送信する例を示している。送信端末103からの1つ目のパケット110-112には、送信シーケンス番号として0、パケット長として1460が記載される0番目のバイトから1459番目のバイトが送信される。2つ目のパケット113-115には、送信シーケンス番号として先頭データを表す1460、パケット長として1460が記載される1460番目のバイトから2919番目のバイトが送信される。同様に、3つ目のパケット116-118には、送信シーケンス番号として先頭データを表す2920、パケット長として1460が記載される2920番目のバイトから4379番目のバイトが送信される。通信装置1100通信装置2101図1の通信装置910、920に相当は、先頭パケット110111を受け取ってもACKを返信しない。通信装置1100通信装置2101は、2つ目のパケット113114を受け取ってから、1つ目のパケットに対するACKパケット121、120を返信する。更に、3つ目のパケット116117を受け取ると、2つ目のパケットに対するACKパケット122、124を返信する。送信端末103は、3つ目のパケット116を送信しても、2つ目のパケットに対するACKパケット122しか受信しないので、送信が完了していないと判断したままである128。通信装置2101から3つ目のパケット118が受信端末104に到達して初めて、3つ目のパケットに対する末尾のACKパケット125が受信端末104から返信され、受信端末130は受信が完了したと判断する130。通信装置2101通信装置1100は、末尾のACKパケット125126を受け取ると、3つ目のパケットに対する末尾のACKパケット126127を送信側へ送信する。送信端末103は、末尾のACKパケット127を受け取り、送信が完了したと判断する129。受信端末130で受信が完了したと判断されない限り130、末尾のACKパケット125、126、127が送信端末103に返信されず、送信端末129が送信完了と判断しないため、受信端末104が編集データを受け取れないまま、送信端末のアプリケーションが終了してしまい、編集データが消滅してしまう、といった事態を防ぐことができる。なお、上述のように、ひとつ前に受信したデータパケットに対するACKを送信する以外にも、2つ前、3つ前など少なくともひとつ前のデータパケットに対するACKを送信してもよい。また、先頭パケット110に対しては、ACKを送信しない以外にも、先頭パケットの最後尾データに対応する受信シーケンス番号を含まないような例えば、0~1459ACKを返送し、先頭パケットの最後尾データに対応する受信シーケンス番号を含むACKは返送しないようにしてもよい。再送への対処図9には、通信装置間の回線帯域が狭いなど、受信端末104からの末尾のACKパケット125の返信が遅れた場合のシーケンス図を示す。この場合、送信端末103は、3つ目のパケット116が途中で廃棄したと判断して、パケットの再送を行う500。通信装置1100は、再送パケット501を受信すると、2つ目のパケット113に対するACKパケット502を重複して返信する。すると、送信端末103は、再びパケット廃棄が生じたと判断して、再度送信を行う503。通信装置1100は、再送パケット504を受信すると、2つ目のパケットに対するACKパケット505を重複して返信する。すると、送信端末103は、再三パケット廃棄が生じたと判断して、再度送信を行う506。通信装置1100は、再送パケット507を受信すると、2つ目のパケットに対するACKパケット508を重複して返信する。このように、何度も再送をした後に、3つ目のパケット116に対するACKパケット127を受け取ると、送信端末103がTCPフラグ番号をRSTresetにセットしたパケット509を送信して、受信側では、強制的にTCPコネクションを切断しなければならなくなる。図10には、上記のRSTパケット送信を防ぐための通信装置100、101のACK返信方法を記載したシーケンス図を表す。受信端末104からの末尾のACKパケット125の返信が遅れた場合、送信端末103は、3つ目のパケット116が途中で廃棄したと判断して、上述のようにパケットの再送を行う300。通信装置1100は、再送パケット301を受信すると、受信シーケンス番号を、2つ目のパケットに対するACKパケット122よりも大きく、3つ目のパケットに対するACKパケット127よりも小さく設定した、ACKパケット302を返信する。送信端末は、戻ってくるACKパケットの受信シーケンス番号がインクリメントしている間は、送信したパケット301の一部のデータが受信端末に届いており、送信端末103は通信回線がまだ繋がっていると判断するため、RSTを送信しなくなる。通信装置は、強制的にTCPコネクション切断する制御をする必要がなくなる。図11のように、送信端末103が、3つ目のパケット116が途中で廃棄したと判断してパケットを再送するケース400、403、406が多い場合、受信シーケンス番号を1ずつ増加させてACKパケットを返信してもよい402、405、408。この場合、再送パケット401、402、403の送信シーケンス番号は1ずつ増加し、ペイロード長は1ずつ減少する。予測コマンドへの対処図12には、通信装置1100と同一のACK返信を行う通信装置1600が、アプリケーション内部でウィンドウサイズを持っているCIFSCommonInternetFileSystem等のアプリケーションを高速化させるために、次に来るコマンドを予測して送信する機能を持っている場合に、本実施例の処理により不具合が発生することを説明するためのシーケンス図を示す。クライアントクライアント装置603が、サーバ604に向けて、ファイルの0バイト目から0xf00061440バイト読み出すreadコマンドを記載したパケット610を送信したとする。通信装置1600は、パケット610を中継してパケット611としてサーバ604に向けて送信すると共に、次にやって来るパケットには、ファイルの0xf000バイト目から0xf00061440バイト読み出すreadコマンドが記載されていると予測して、予め予測したreadコマンドを記載したパケット613をサーバに向けて送信する。クライアントの発行したコマンドを記載したパケット611と、予測したコマンドを記載したパケット613は、通信装置2601経由で、パケット612、614としてサーバ604に届けられる。サーバ604は、コマンド記載パケットに対するACKパケット615を返信すると共に、コマンド記載の、ファイルの0バイト目から0xf00061440バイトのデータ618と、ファイルの0xf000バイト目から0xf00061440バイトのデータ621をクライアント603に向けて送信する。これらのデータ618、621は、通信装置2701経由で通信装置1700へデータ619、622として送られる。通信装置1700は、クライアントの要求してきたデータ619を受信端末603へ送信する620一方で、後続データ622については、受信端末603への送信と末尾データに対するACKの受信が完了していないため、受け取ったデータサイズ0x1e000よりも少ないサイズを受信シーケンス番号に記載したACKパケット624をサーバ側に返信する。クライアント603は、コマンドで要求したデータ623を受け取ると、受信が完了したと判断して629、再びコマンドを発行できるようになる。ここで、クライアント603が、通信装置1600が予測したコマンド613とは異なるコマンド例えば、trans、createを記載したパケット626を送信したとする。この場合、サーバ604は、送信したデータサイズよりも小さな受信シーケンス番号を持つACKパケット625が来て、送信が未完了だと判断している状態で630、次のコマンドを記載したパケット628を受信することになり、前のコマンドに対する処理が終わっていないため、次のコマンドに対する処理が行われず、アプリケーションが停止してしまう。図13には、前記のアプリケーションの停止を防ぐためのシーケンス図を示す。通信装置1700が、予測コマンドを発行している状態では、受け取ったデータサイズ0x1e000と同一のサイズを受信シーケンス番号に記載したACKパケット724をサーバ側に返信する。自身が予測コマンドを発行している状態で、通常通りのACK返信を行うことで、サーバ604は、送信したデータサイズと同一の受信シーケンス番号を持つACKパケット725を受け取ることによって、送信が完了したと判断することができ730、次のコマンド628がやって来たときに、次のコマンドに対する処理を続けて実行することが可能となる。アプリケーションが、次のコマンドに対する処理を行わずに、停止することが無くなる。予測コマンドを発行している状態か否かは、装置内に予測コマンドを発行することが予め設定されてもよいし、予測コマンドを発行した際にフラグを立ててそれを参照するなど、適宜の手法で判断できる。図8、図10、図11、図13に示す通信装置の動作シーケンスは、図1に示すシステム、図3、図4のブロックを持つ装置によって実現される。図14には、状態の不一致を防ぐために1パケット/1バイトずらしでACK返信を行う通信装置2000が、先頭データ2005を受信したときに、どのようにポインタが移動するかを示したシーケンス図を示す。ここで、通信装置2000は、通信装置910、920である。通信装置2000が送信端末2001との間のTCP通信に用いる受信バッファ2003のポインタ移動と、通信装置2000が受信端末2002との間のTCP通信に用いる送信バッファ2004のポインタ移動を示す。通信装置2000が、送信端末2001から送信シーケンス番号がright_recv1103と等しい先頭データ付パケット2005を受信すると、left_recv1102とright_recv1103を、受信したデータサイズ分、右側へ移動させる2006。prev_left_recv1900は不変である。受信シーケンス番号をleft_recv1102にした確認応答用のACKパケット1309を送信端末1301へ送る。left_recv1102がleft_rbuf1101よりも大きくなると、left_rbuf1101からleft_recv1102まで書かれているデータを、right_sbuf1106を先頭に送信バッファ2007へ移動させて2013、left_rbuf1101とright_sbuf1106を、移動させたデータサイズ分、右側へ移動させる2008、2009。right_sbuf1106がright_send1105よりも大きくなると、right_send1105からright_sbuf1106までのデータを受信端末2002へ送信して2011、right_send1105を、送信したデータサイズ分、右側へ移動させる2012。上記のシーケンスにより、通信装置内にACK待ちの送信中データも整列待ちの受信中データも無い状態でデータパケットを受信した場合はACK返信を行わない手段が実現される。図15には、この状態から、更に、通信装置2000が、送信端末2001から送信シーケンス番号がright_recv1103と等しい先頭データ付パケット2101を受信した場合のシーケンス図を示す。通信装置2000が、パケット2101を受信すると、prev_left_recv1900にleft_recv1102の値を代入してから、left_recv1102とright_recv1103を、受信したデータサイズ分、右側へ移動させて2103、受信シーケンス番号ACK2913をprev_left_recv1900にした確認応答用のACKパケット2104を送信端末2001へ送る。なお、受信したパケットに対してACKを返信する場合は、受信シーケンス番号をleft_recv1102にした確認応答用のACKパケット1318を送信端末1301へ送ることになるが、本実施例では、1つ前のパケットに対するACKが送信される。left_recv1102がleft_rbuf1101よりも大きくなると、left_rbuf1101からleft_recv1102まで書かれているデータを、right_sbuf1106を先頭に送信バッファ2102へ移動させて2110、left_rbuf1101とright_sbuf1106を、移動させたデータサイズ分、右側へ移動させる2106、2105。right_sbuf1106がright_send1105よりも大きくなると、right_send1105からright_sbuf1106までのデータを受信端末2002へ送信して2107、right_send1105を、送信したデータサイズ分、右側へ移動させる2109。なお、left_send1104は、確認応答用のACKパケットを受信端末から受信していないので移動しない。上記のシーケンスにより、通信装置内にACK待ちの送信中データ、或いは整列待ちの受信中データが有る状態でデータパケットを受信した場合は1つ前に受信したデータパケットに対するACKを返信する手段が実現される。図16には、状態の不一致を防ぐために1パケット/1バイトずらしでACK返信を行う通信装置2000が、末尾データ2013を受信したときに、どのようにポインタが移動するかを示したシーケンス図を示す。通信装置2000が送信端末2001との間のTCP通信に用いる受信バッファ2010のポインタ移動と、通信装置2000が受信端末2002との間のTCP通信に用いる送信バッファ2012のポインタ移動を示す。通信装置2000が末尾データを受信端末2002に送信した後、送信バッファ2012では、right_send1105とright_sbuf1106が同じ値となり、right_send1105はleft_send1104よりも末尾データサイズ分大きい値となっている。受信バッファ2010では、left_recv1102とright_recv1103が同じ値となっており、未整列の受信中データが存在せず、prev_left_recv1900がleft_recv1102よりも小さい値となっている。この状態で、受信シーケンス番号がright_send1105と同じ値である末尾データに対するACKパケット2013を受信すると、left_send1104がright_send1105と同じ値となり2014、受信バッファ2010に未整列の受信中データが無い状態で、送信バッファ2012に確認応答待ちのデータが無くなる。このタイミングで、通信装置2000は、受信シーケンス番号をleft_recv1102としたACKパケット2016を受信端末2001に対して返信する。上記のシーケンスにより、受信バッファに整列待ちの受信中データが無い状態で、受信端末側からACKを受信して、送信バッファに確認応答待ちの送信中データが無くなったタイミングで通常のACKを返信する手段が実現される。図17には、図8のシーケンス図に、送信側TCP通信で用いる受信バッファにおける受信中データの有無と、受信側TCP通信で用いる送信バッファにおける送信中データの有無の情報を加えたシーケンス図を示す。通信装置100/101は、データ付パケット110/111を、受信中データも送信中データも無い状態1606/1609で受け取るので、先頭データと判断してACKを返信しない。また、通信装置100/101は、受信シーケンス番号4380のACKパケット125/126を受け取ると、受信中データも送信中データも無い状態1630/1631に変化するため、末尾データに対するACKパケット126/127を返信する。データパケット113、114、116、117を受信したときは、受信中データか送信中データがある状態なので、一つ前のデータパケットに対するACKパケットを返信する。また、受信中データや送信中データがある状態で、ACKパケット119、120、123、124を受信すると、受信済みデータに対するACKパケットを送信側へ返信しない。図18には、NIF0TCPモジュール1007の受信履歴更新部3106の処理フローチャートを表す。処理がスタートするとステップ3801、受信履歴更新部3106は、ペイロード長が0より大きなパケットを受信するまで待機するステップ3802。パケットを受信すると、受信履歴更新部3106は、NIF0の受信バッファの管理ポインタ1005を変更しステップ3803、NIF0の受信バッファ1013へパケットデータを記録するステップ3804。更に、受信履歴更新部3106は、NIF1の送信バッファ1016に送信中データが残っている、またはNIF0の受信バッファに残っている受信中データのサイズが受信パケットのペイロードサイズよりも大きいか否かを判定するステップ3805。受信履歴更新部3106は、否と判定された場合は、ステップ3802に戻る。受信履歴更新部3106は、真と判定された場合は、受信済みデータの1パケット前、または1バイト前に対するACKを返信するステップ3806。ステップ3805により、図14に示した、最初に到着したデータに対してACKを返信しないシーケンス処理が実現される。また、ステップ3805に続くステップ3806により、図15に示した、受信済みデータの1パケット前、または1バイト前に対するACK返信のシーケンス処理が実現される。図19には、NIF0TCPモジュール1007のTXパケット再送部3104の処理フローチャートを表す。処理がスタートするとステップ3901、TXパケット再送部3104は、ペイロード長が0のACKパケットを受信するまで待機するステップ3902。ACKパケットを受信すると、TXパケット再送部3104は、NIF0の送信バッファと、NIF1の受信バッファにデータが有るか否かを判定するステップ3903。無い場合は、ステップ3902へ戻る。有る場合は、TXパケット再送部3104は、受信したACKパケット記載の受信シーケンス番号ACK2913やleft_edge_1~42919、2921、2923、2925やright_edge_1~42920、2922、2924、2926に基づいて、NIF0の送信バッファの管理ポインタを変更するステップ3905。ステップ3905では、受信したACKパケットに記載されている受信シーケンス番号ACK2913が、left_send1104よりも大きい場合、left_send1104は、受信シーケンス番号ACK2913の値に変更される。例えば、末尾ACKであれば、送信バッファ中にACK待ちのデータがなくなる。更に、ステップ3903と同様に、TXパケット再送部3104は、もう一度、NIF0の送信バッファと、NIF1の受信バッファにデータが有るか否かを判定するステップ3906。ステップ3906で、NIF1の受信バッファにデータが有る場合は、TXパケット再送部3104は、再送中のデータ箇所の左端と右端を表すポインタleft/right_rts1108-1~SEG_SIZEの値を確認し、再送パケットがあるか否かを判定するステップ3908。再送パケットが無い場合は、ステップ3902へ戻る。再送パケットが有る場合は、パケットを再送してステップ3909、ステップ3902へ戻る。ステップ3906において、NIF1の受信バッファにデータが無いと判定された場合は、ACKパケットを受信したNIF0とは反対側のNIF1で、受信済みデータに対するACKを送信するステップ3907。NIF0の送信バッファの管理ポインタ変更処理ステップ3905の前後で、NIF0の送信バッファとNIF1の受信バッファに送受信中のデータが有る状態から無い状態に変化したときに、受信済みデータに対するACKを返信することで、図16に示した受信側から末尾ACKを受信するまで、末尾ACKを返信しないシーケンス処理が実現される。図20には、図18の受信バッファの管理ポインタprev_left_recv1900と、left_recv1102と、right_recv1103変更処理ステップ3803を詳細化し、ステップ3805を受信バッファ管理ポインタを用いて表したフローチャート図をあらわす。このフローチャートの各ステップは、例えば、通信装置のTCPモジュール1007、1008が実行する。処理がスタートするとステップ1701、データ付パケットを受信するまで待機するステップ1702。データ付パケットを受信すると、len=ペイロード2927の長さ、left_pkt=受信パケットの送信シーケンス番号、right_pkt=left_pktlen、とするステップ1703。その後、right_pktがright_recv1103よりも大きいか否かを判定するステップ1704。大きい場合は、更に、right_recv1103がleft_pkt以上か否かを判定するステップ1705。ステップ1705の判定結果が真の場合は、right_recv1103にright_pktを代入するステップ1706。更に、ロスセグメントの有無を判定し1707、無い場合はprev_left_recv1900にleft_recv1102を代入しステップ2309、left_recv1102にright_pktを代入するステップ1708。有る場合は何もしない。ステップ1705の判定結果が偽の場合は、新規ロスセグメントleft_losskとright_losskを作成して、left_losskにright_recv1103の値を、right_losskにleft_pktの値を代入して1709、その後でprev_left_recv1900にleft_recv1102を代入しステップ2311、right_recv1103にright_pktの値を代入する1710。ステップ1704の判定結果が偽の場合は、パケットのセグメントleft_pkt~right_pktと1バイト以上一致するロスセグメントleft_lossk~right_losskがあるか否かを判定しステップ1711、無い場合は何もしない。有る場合は、ロスセグメントを更新した上でステップ1712、ロスセグメントの有無を判定するステップ1713。ロスセグメントが無い場合は、left_recv1102にright_recv1103の値を代入するステップ1714。その後に、prev_left_recv1900にleft_recv1102-1の値を代入するステップ2319。ロスセグメントが有る場合は、left_recv1102に最小のロスセグメントの左端の値を代入するステップ1715。また、prev_left_recv1900にleft_recv1102を代入するステップ2320。left_recv1102とright_recv1103の変更が完了すると、left_recv1102を受信シーケンスACK2913に記載してACKパケットを返信するステップ1716。更に、ステップ1708の後と、ステップ1707で偽と判定された後に、受信バッファへパケットデータを記録しステップ3810、right_sbuf1106がleft_send1104よりも大きい、または、right_recv1103とleft_rbuf1101の差がlenよりも大きいか否かを判定するステップ2313。ステップ2313は、受信バッファか送信バッファのいずれかに送受信中のデータが残っているか否かを判定するための処理である。ステップ2313で否と判定されたときは、ACK返信をしないまま、ステップ1702へ戻る。本ステップを挿入することで、先頭データを受信したときにACK返信しない手段が実現される。更に、ステップ1711で否と判定された後に、prev_left_recv1900とleft_pktが等しく、尚且つ、left_recv1102がright_recv1103と等しく、尚且つ、right_recv1103がright_pktと等しいか否かを判定するステップ2321。ステップ2321で、真等しいと判定された時は、prev_left_recv1900を1インクリメントするステップ2322。更に、prev_left_recv1900がright_recv1103と等しいか否かの判定を行いステップ2323、真等しいと判定された場合は、prev_left_recv1900にleft_recv1102-1の値を代入するステップ2324。ステップ2321~2324を挿入することで、送信端末からのパケット再送が繰り返されるときに、送信端末がRSTパケットを送信してコネクションを強制切断する可能性が低くなる。ステップ2313で否と判定されるケース以外、ACK返信を行ってからステップ2325、ステップ1702へ戻る。図21には、ステップ2325の詳細なフローチャートを示す。ステップ2325の処理がスタートするとステップ2401、right_sbuf1106とleft_send1104が等しく、尚且つ、right_recv1103とleft_rbuf1101が等しいか否かを判定するステップ2402。ステップ2402は、送信バッファにも受信バッファにも送受信中のデータが残っていないことを確認するための処理である。否と判定され、すなわち、送受信中のデータが残っていると判定された場合は、図12や図13のシーケンス図に示したようなサーバ側に予測コマンドを送信中か否かを判定するステップ2403。否と判定された場合は、prev_left_recv1900を受信シーケンス番号としてACKを返信するステップ2404。ステップ2402で真と判定され、送信バッファにも受信バッファにも送受信中のデータが残っていないと判定された場合や、ステップ2403で真と判定され、サーバ側に予測コマンドを送信中だと判定された場合は、left_recv1102を受信シーケンス番号としてACKを返信するステップ2405。通信装置は、ステップ2402の分岐を用いることで、受信端末からの末尾データに対するACKを受信するまで、送信側に末尾データに対するACKを返信しなくなるため、通信装置に障害が発生しても、図41を用いて説明したような送信側のTCP通信と受信側のTCP通信の状態の不一致が起こらなくなる。また、ステップ2403の分岐を用いることで、サーバ側に予測コマンドを送信した後で予測が外れても、サーバに対して末尾データに対するACKが返信されるため、図12を用いて説明したようなサーバ側の処理が止まることが無くなる。図22には、ロスセグメント更新ステップ1712のフローチャートを示す。処理スタート後ステップ1801、left_pktがleft_lossk以下であり、尚且つleft_losskがright_pktよりも小さいか否かを判定するステップ1802。ステップ1802において、否と判定された場合は、left_pktがright_losskよりも小さく、尚且つright_losskがright_pkt以下であるか否かを判定するステップ1803。ここで、否と判定された場合は、left_losskがleft_pktよりも小さく、right_pktがright_losskよりも小さいか否かを判定するステップ1804。ステップ1804において真と判定された場合、right_losskにleft_pktを代入した上でステップ1805、新規ロスセグメントleft_lossjとright_lossjを作成して、left_losskにright_pktの値を、right_losskにright_losskの値を代入する1806。ステップ1802にて真と判定された場合、left_losskにright_pktの値を代入するステップ1808。ステップ1803にて真と判定された場合、right_losskにleft_pktの値を代入するステップ1807。ステップ1807/1808が完了すると、left_losskがright_lossk以上であるか否かを判定するステップ1809。ステップ1809にて真と判定された場合、ロスセグメントleft_losskとright_losskを初期化して、消去するステップ1810。例えば、端末と通信装置の間では標準TCPを使って通信を行い受信データの整列や送信データの再送を行い、各通信装置間ではRTTや廃棄率に依存しない独自のプロトコル独自TCPを使って通信を行い受信データの整列や送信データの再送を行う通信装置を用いるときに、送信端末から末尾のデータを受信して確認応答のACKパケットを返信し、その直後に故障した場合、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースの発生を防ぐことができる。ポインタの移動の補足説明以下、ポインタの移動について補足して説明する。受信したデータサイズに応じて受信シーケンス番号を記載してACKパケットを返信する通信装置が、パケットを前から順番に受信することが出来ずに、ロスセグメントが発生したときに、どのようにポインタが移動するかを以下に示す。通信装置が送信端末との間のTCP通信に用いる受信バッファのポインタ移動と、通信装置が受信端末との間のTCP通信に用いる送信バッファのポインタ移動を示す。通信装置が、送信端末から送信シーケンス番号がright_recv1103よりも大きなデータ付パケットを受信すると、right_recv1103を、受信パケットの送信シーケンス番号とデータ長の和に変更して、left_loss0をleft_recv1102に、right_loss0を受信パケットの送信シーケンス番号にしたロスセグメント記録ポインタを新たに作成する。更に、受信シーケンス番号をleft_recv1102にして、TCPオプションヘッダ2916内のleft_edge_12919とright_edge_12920に、right_loss0とright_recv1103の値を記載した部分的確認応答SelectiveACKSACK用のACKパケットを送信端末へ送る。その後、更に、通信装置が、送信端末から送信シーケンス番号がright_recv1103よりも大きなデータ付パケットを受信すると、left_loss1をright_recv1103に、right_loss1を受信パケットの送信シーケンス番号にしたロスセグメント記録ポインタを新たに作成して、right_recv1103を、受信パケットの送信シーケンス番号とデータ長の和に変更する。更に、受信シーケンス番号をleft_recv1102にして、TCPオプションヘッダ2916内のleft_edge_12919とright_edge_12920に、right_loss0とleft_loss1の値を記載し、TCPオプションヘッダ2916内のleft_edge_22921とright_edge_22922に、right_loss1とright_recv1103の値を記載した部分的確認応答SACK付のACKパケットを送信端末へ送る。その後、通信装置が、送信シーケンス番号がleft_recv1102と等しく、送信シーケンス番号とデータ長の和がright_loss0と等しいデータ付再送パケットを、送信端末から受信すると、left_recv1102をleft_loss1の所まで移動させて、ロスセグメント記録用ポインタleft_loss0とright_loss0を初期化して無くして、受信シーケンス番号をleft_recv1102にした確認応答用のACKパケットを送信端末へ送る。left_recv1102がleft_rbuf1101よりも大きくなると、left_rbuf1101からleft_recv1102まで書かれているデータを、right_sbuf1106を先頭に送信バッファへ移動させて、left_rbuf1101とright_sbuf1106を、移動させたデータサイズ分、右側へ移動させる。次に、受信したデータサイズに応じて受信シーケンス番号を記載してACKパケットを返信する通信装置が、受信端末からACKを受信したときに、どのようにポインタが移動するかを示す。通信装置が送信端末との間のTCP通信に用いる受信バッファのポインタ移動と、通信装置が受信端末との間のTCP通信に用いる送信バッファのポインタ移動を示す。通信装置が、すでにある程度の量のデータを受信端末へ送っており、right_sbuf1106とright_send1105が等しく、right_send1105がleft_send1104よりも大きいときを初期状態とする。通信装置が、受信端末から、受信シーケンス番号がleft_send1104よりも大きくright_send1105よりも小さな確認応答用のACKパケットを受信すると、left_send1104の値がACKパケット記載の受信シーケンス番号に変更される。更に、受信シーケンス番号がleft_send1104の値と等しく、尚且つ、受信シーケンス番号がACKパケットのそれと等しく、TCPオプションヘッダ2916内のleft_edge_12919にleft_send1104よりも大きくright_send1105よりも小さな値を記載し、TCPオプションヘッダ2916内のright_edge_12920にright_send1105の値を記載した部分的確認応答SelectiveACKSACK用の重複ACKパケットを受信すると、left_rts0をleft_send1104に、right_rts0をleft_edge_12919にした再送セグメント記録ポインタを新たに作成する。通信装置は、再送セグメントが作成されると、left_rts0からright_rts0までのデータを再送して、再送セグメント記録ポインタを初期化して消去する。図23、図24、図25を用い、上述の実施例の図面を適宜参照して、パケットのTCPフラグにPSHフラグがセットされているか否かで末尾データか否かを判断して、末尾データに対するACKパケットが受信端末側から到着するまで、受信済みデータの1パケット前、または1バイト前に対するACKを返信する通信装置800の実施例を示す。本実施例では、実施例1で示した図3、図4のブロック構成を持つ装置と同様の構成を用いる。図18や図19で示した受信履歴更新部3106やTXパケット再送部3104で行う処理に、幾つかの処理を追加することで、本実施例の通信装置800を実現する。図23には、受信履歴更新部3106がペイロード付きデータを受信した時の処理手順を示したフローチャート図を示す。図18と同様の処理については、同じ符号を付し、説明を省略する。新たに、PSHデータ受信中か否かを判定するための状態変数PSH_recvを定義して、図18に示したステップ3801の後に、PSH_recvに0を代入する処理ステップ4001を挿入する。更に、ステップ3804の後に、受信パケットのTCPフラグにPSHフラグがセットされているか否かを判定する処理ステップ4002を挿入する。ステップ4002において、真と判定された場合は、PSH_recvに1を代入してステップ4003、ステップ3805に移る。ステップ4002において、否と判定された場合は、NIF0において、従来どおり、受信済みデータに対するACKを返信してからステップ4004、ステップ3802へと戻る。本処理方式により、PSHパケットを受信したときだけ、実施例1に示したACK返信の機能が有効になる。図24には、TXパケット再送部3104がACKパケットを受信した時の処理手順を示したフローチャート図を示す。図19と同様の処理については、同じ符号を付し、説明を省略する。図19に示したステップ3905の後に、PSH_recvが1であるか否かを判定する処理ステップ4101を追加する。ステップ4101で真PSH_recvが1であると判定した場合は、ステップ3906へ戻る。ステップ4101で偽と判定した場合は、ステップ3906を飛ばして、ステップ3908へと進む。更に、ステップ3907の後に、PSH_recvに0を代入する処理ステップ4102を追加する。本処理方式により、PSHパケットを受信したときだけ、実施例1に示した、末尾データに対するACKパケットが受信端末側から到着するまで、末尾ACKを返信しない機能が有効になる。図25には、装置800が、図23、図24の処理方式を用いて、末尾データか否かを、パケット記載のTCPフラグflag2914にPSHフラグがセットされているか否かで判定を行い、PSHデータ受信中のときだけ、末尾データに対するACKパケットが受信端末側から到着するまで、末尾ACKを返信しない処理を行った場合のシーケンス図を示す。通信装置1800が、送信端末803からPSHフラグ付パケット810を受け取ると、末尾のデータと判断してACKを返信せずに、そのまま通信装置2へ送信する811。通信装置2801は、同様に、末尾のデータと判断してACKを返信せずに、そのまま受信端末804へと送信する812。通信装置1800は、再送パケット813を受け取っても、受信シーケンス番号に受信済みデータサイズよりも1~1459小さな値をセットしたACKを返信する。通信装置2801通信装置1800は、受信シーケンス番号に受信済みデータサイズをセットした末尾のデータに対するACKパケット816、815を受信端末側から受け取ると、送信端末側に向けて末尾のデータに対するACKパケット815、814を送信する。上記の方式により、送信端末では、送信が完了したと判断しているのにもかかわらず、受信端末では、受信が完了していないと判断している状態の不一致を防ぐことができる。図26~図36を用い、上述の実施例の図面を適宜参照して、送信端末と受信端末の間に2つの通信装置を設置し、通信装置間では上記特許出願1に記載の、又はそれをさらに改良した独自TCPによる通信を行うための実施例を示す。図26には、図1をベースにNIF1側のTCPモジュールを上記の独自TCPの処理を行うモジュール2501/2502に変更したシステム図を示す。本システムでは、WAN907内で独自TCPを用いて通信が行われる。通信装置910/920例えば、通信装置は、図3に示したブロック図と同様なブロック図で実装することができ、NIFTCP1008が独自TCPモジュール2501/2502に変わる。受信端末側の通信装置は、送信端末側の通信装置に対して廃棄箇所を全て逐一フィードバック通知すると共に、送信端末側の通信装置は、受信端末側の通信装置からフィードバック通知された廃棄箇所を再送し、尚且つ、基準時刻以降の再送帯域又は廃棄帯域再送/廃棄帯域と記すこともあると、基準時刻以前の送信帯域とに基づいて、特定の宛先に対するデータ送信帯域とデータ再送帯域の総和を制御することで、RTTや廃棄率に依存しない通信帯域を確保する。図27~図30には、独自TCPの3つの特徴を表した説明図を示す。なお、独自TCPは、以降、RadicRTTAndDiscardIndependentCongestionControl-TCPと記載することもある。図27には、左側に、標準的なTCPの例として従来型TCPの帯域制御方式を、特許出願1記載の右側に独自TCPの帯域制御方式を示す。従来型TCPは、送信端末2601において、RTT毎の送信量を定めたウィンドウサイズ2605を制御することで2607、送信帯域を制御する。送信帯域は、ウィンドウサイズ/RTTで表される。この方式による帯域制御は、RTTが増加すると回線が空いていても送信不可能な時間2610が増加して、回線帯域の利用率が減少する、という課題があった。一方、独自TCPでは、一定時間毎の送信量を定めたトークンサイズ2606を制御することで2608、送信帯域を制御する。送信帯域は、トークンサイズ/インターバル時間で表される。独自TCPを用いることで、回線が空いていても送信不可能な時間を無くすことが出来るため、回線帯域の利用率が増加する2609。RTTに依存しない帯域制御を実現することができる。図28には、左側に従来型TCPの再送制御方式を、右側に独自TCPの再送制御方式を示す。従来型TCPでは、ACKパケットのTCPオプションヘッダ2916内のleft_edge_1~42919、2921、2923、2925、right_edge_1~42920、2922、2924、2926には、どこからどこまで部分的に受信済であるかを最大4箇所記載して、部分的確認応答SelectiveACKSACK用に用いる。一方、独自TCPでは、TCPオプションヘッダ2916内のleft_edge_1~42919、2921、2923、2925、right_edge_1~42920、2922、2924、2926には、どこからどこまで部分的に再送してほしいかを最大4箇所記載して、部分的未確認応答NegativeACKNACK用に用いる。従来型TCPでは、送信端末2701から受信端末2702へ送った12個のデータパケットA~L2705のうち、B、D、F、H、Jが途中で廃棄されたとすると、TCPオプションヘッダ2916に書き込める受信済み箇所が最大4箇所までである制約から、I以降に送ったパケットに対する確認応答をこの時点では送信端末2701に送ることができない2709。送信端末は、A~Iまでの部分的確認応答を記載した確認応答パケット2709を用いて、パケットA~Iのうち廃棄されたパケットB、D、F、Hを再送する2706。受信端末2702は、再送パケット2706を受信してから、パケットI以降の部分的確認応答を記載した確認応答を返信する2712。送信端末2701は、パケットI以降の部分的確認応答を記載した確認応答2712を受信してから、パケットI以降に廃棄されたパケットJを再送することができる2707。一方、独自TCPでは、送信端末2703から受信端末2704へ送った12個のデータパケットA~L2708のうち、B、D、F、H、Jが途中で廃棄されたとしても、A~Jまでの再送してほしい箇所をTCPオプションヘッダ2916内のleft_edge_12919とright_edge_12920へ逐一書き込んでから、部分的未確認応答用NACKのACKパケットを返信する2711。各再送要求箇所は、1つのNACKパケットにだけ書き込まれる。送信端末2703は、部分的未確認応答用NACKのACKパケット2711を受信すると、TCPオプションヘッダ2916に記載された再送要求箇所B、D、F、H、Jを再送する2710。ロスが大量に発生したときでも、一度で再送が完了するため、通信時間が短縮し2712、帯域が向上する。つまり、送信端末と受信端末の間に2台の通信中継装置通信装置を設置し、受信端末側の通信装置が送信端末側の通信装置に対して廃棄箇所を全て逐一フィードバック通知する。例えば、送信端末側の通信装置は、受信端末側の通信装置からフィードバック通知された廃棄箇所を再送すると共に、基準時刻以降の再送帯域や廃棄帯域と、基準時刻以前の送信帯域とに基づいて、特定の宛先に対するデータ送信帯域とデータ再送帯域の総和を増減させる。それにより、廃棄率に依存しない通信を実現することができる。なお、図29に示すように、部分的未確認応答用NACKのACKパケットによって再送されたパケットが廃棄されるケースもある。送信端末3000からパケットA~Dが送信され3002、パケットBが廃棄され、パケットBをTCPオプションヘッダ2916内のleft_edge_12919とright_edge_12920に記載した部分的未確認応答用NACKのACKパケット3003によって再送されたパケットB3004が再び廃棄されたとする。この場合、受信端末3001は、例えば2RTT待っても再送パケットB3004が到達しなければ、再び、パケットBの再送を要求する部分的未確認応答用NACKのACKパケット3005を送信する3006。本再送方式は、受信バッファ管理ポインタのleft/right_loss1107と関連付けて、図7に示すACK返信時刻acked_time1901を記録することで実現する。ACK返信時刻acked_time1901と現在時刻との差分が2RTTを超過したときに、超過した廃棄箇所left/right_loss1107の再送を要求する部分的未確認応答用NACKのACKパケットを再送する。図30には、左側に従来型TCPの輻輳制御方式を、右側に独自TCPの輻輳制御方式を示す。従来型TCPは、パケット廃棄が1回起きただけでも、制御帯域を大幅に減少させる2801。通信回線では、回線利用率が100に到達していなくても、バッファ等において待ち行列理論から導かれる一定の確率で廃棄が生じる2806。このため、従来型TCPは、回線利用率が100に到達する前に、帯域が減少してしまい2804、回線帯域を100使い切ることが出来ない場合があった。一方、独自TCPは、廃棄/再送率が一定に推移していれば、待ち行列理論から導かれる一定の確率で廃棄が生じているに過ぎないと判断して帯域を増加させていく。廃棄/再送率が増加し始めたら、例えば回線帯域の使いすぎが発生したと判断して、直近の廃棄/再送帯域と、それよりも1RTT前の制御帯域とに基づいて、1RTT前の制御帯域よりも小さくなるように制御帯域を減少させる。制御帯域が回線帯域付近で上下するように制御するため、回線帯域を100近く使い切ることができる。なお、ここで、送信帯域とは、シェーパ3209へパケットを振り分ける振分部3208において、シェーパ毎に観測している入力帯域を指す。また、制御帯域とは、シェーパ3209からの実際の出力帯域を指す。図31には、NIF1側のTCPモジュール2501/2502ブロックに実装する独自TCPを実現するためのブロック図を示す。NIF0側のTCPモジュール1007ブロックに実装する標準TCPを実現するためのブロック図は、図4と同様のものを用いることができる。まず、標準TCPを実現するTCPブロック1007913/924について説明すると、図4に示すように受信処理を行うRX部3102と、送信処理を行うTX部3101を有する。RX部3102は、受信パケットをTCP制御パケットとデータ付パケットとACK/部分的確認応答用SACKパケットに分離するパケット解析部3108と、受信したTCP制御パケットに基づいて状態テーブル1001内のTCP状態1003を変更するTCP制御部3107と、受信したデータパケットの送信シーケンス番号SEQ2912と受信シーケンス番号ACK2913とに基づいて、状態テーブル1001内のバッファ管理ポインタ1005を変更してACKパケットや部分的確認応答SACK付ACKパケットを返信する受信履歴更新部3106、とを有する。受信履歴更新部3106のバッファ管理ポインタ1005の変更では、実施例1に記載の方法を用いる。TX部3101は、状態テーブル1001内のTCP状態1004を用いてTCP制御パケットを送信するTCP制御部3103と、受信したACKパケットに基づいて状態テーブル1001内のバッファ管理ポインタ1005を変更し、受信した部分的確認応答SACK付ACKパケットを用いて送信バッファ1015からデータを読み出してパケットを再送するTXパケット再送部3104と、送信バッファ1015からデータを読み出してパケットを送信して、状態テーブル1001内のバッファ管理ポインタ1005を変更する送信履歴更新部3105と、ACK/SACKパケット、TCP制御パケット、再送パケット、データパケットをFIFOで集約して出力するマルチプレクサ3109およびバッファ3110~3113とを有する。独自TCPを実現するTCPブロック2501/2502は、標準TCPを実現するTCPブロック1007をベースに、図31に示すように、RX部3102内の一部のブロックからの出力を変更し、TX部3101内に幾つかのブロックを追加することで実現される。まず、パケット解析部3108は、ACK/部分的確認応答用SACKパケットを、ACK部分的未確認応答用NACKのACKパケット3210に変更し、TXパケット再送部3104に出力する。同様に、受信履歴更新部3106のACK/部分的確認応答用SACKパケットを、ACK部分的未確認応答用NACKのACKパケット3210に変更し、バッファ3110に出力する。ACK/SACKパケットをACK/NACKパケットに変更し、変更されたパケットを送ることで、TX部3101では、廃棄箇所の即時再送を行うことができる。TX部3101は、図4と異なり、送信パケットと再送パケットのヘッダ情報を用いてどのシェーパに割り振るかを判定するシェーパ判定部3201と、コネクション情報毎に宛先シェーパを定めたコネクションシェーパテーブル3202と、シェーパ判定部3201の判定結果に基づいてパケットを割り振る振り分け部3208と、シェーパA~C3209とを有する。この構成により、RTT非依存なトークンに基づく帯域制御が可能となる。さらに、TX部3101は、現在時刻を出力するタイマ3203と、インターバル時間を定めたインターバル格納部3204と、シェーパ毎の送信帯域を制御する送信帯域制御部3206と、シェーパ毎に送信帯域や再送帯域の統計情報を記録するシェーパ毎の送信再送帯域テーブル3205と、インターバル時間あたりの送信可能量を制御するトークン更新部3207とを追加する構成である。送信帯域制御部3206は、シェーパ毎の送信再送帯域テーブル3205記載の制御帯域が変更されると、新たな変更済み制御帯域をトークン更新部3207へ通知する。トークン更新部3207は、トークンバケツアルゴリズムを用いて、各シェーパ3209からパケットが送信可能か否かを判定し、送信可能と判定したシェーパ3209からパケットを送信するように集約部3109へ指示する。この構成により、再送率に基づく輻輳制御が可能となる。トークンバケツアルゴリズムでは、トークンバケツに単位時間毎に予め定められたトークンが蓄積されていき、送信パケット長に到達するとパケットの送信が許可される。更に、パケット送信と同時に、送信パケット長と同じ分のトークンが、トークンバケツから減らされる。トークン更新部3207は、送信帯域制御部3206から通知された制御帯域に基づいて、トークンバケツに加算するトークンの値を決定する。以上の、送信帯域制御部3206の制御により、図27のトークンサイズに基づく帯域制御を実現可能となる。図32には、TCPコネクション毎に使用するシェーパを定めるためのコネクションシェーパテーブル3202のフォーマットを表す。コネクションシェーパテーブル3202には、送信元IP/サブネット、宛先IP/サブネット、送信元ポート番号、及び、宛先ポート番号を含むコネクション情報毎に、対応するシェーパの識別情報を記載する。シェーパ判定部3201は受け取ったパケットのIPヘッダ記載のIPアドレス2907/2908、TCPヘッダ記載のポート番号2910/2911と一致するコネクション情報を持つコネクションシェーパテーブル3202のエントリを探し、そのエントリに記載されたシェーパにパケットが出力されるように振り分け部3208へ指示する。図33には、送信帯域制御部3206が制御帯域を更新する際の概念的なフローチャートを表す。処理がスタートするとステップ4201、送信帯域制御部3206が以下同じ、パケット再送率=再送帯域/制御帯域の増加率が一定値を超過したか否かを判定するステップ4202。超過した場合は、現在の再送帯域と、昔の制御帯域を用いて、制御帯域を更新するステップ4203。超過しなかった場合は、制御帯域を増加させるステップ4204。図34には、シェーパ毎の送信再送帯域テーブル3205のフォーマットを表す。シェーパ毎の送信再送帯域テーブル3205は、シェーパ毎に、旧基準時刻前の送信帯域制御帯域と、基準時刻前の送信帯域再送帯域制御帯域、基準時刻と、基準時刻後の送信ビット積算値再送ビット積算値制御帯域とを記録する。送信ビット積算値再送ビット積算値は、例えば、シェーパにパケットを振り分ける振分部3208が送信ビット数、再送ビット数を送信帯域制御部3206に通知し、送信帯域制御部3206がシェーパ毎の送信再送帯域テーブル3205に書き込むことができる。図35には、シェーパ毎の送信再送帯域テーブル3205が保持する値の意味を説明するための概念図である。上から下に向かって時間の経過を表す。図35の4301に示すように、基準時刻後の制御帯域は、現在時刻における制御帯域を表す本実施例では、tokenと表す。基準時刻後の送信帯域は、現在時刻における送信帯域を表し本実施例では、sndと表す、基準時刻後の送信ビット積算値をインターバルで除算することで求められる。基準時刻後の再送帯域は、現在時刻における再送帯域を表し本実施例では、rtsと表す、基準時刻後の再送ビット積算値をインターバルで除算することで求められる。また、図35の4302に示すように、基準時刻前の制御帯域送信帯域再送帯域は、基準時刻の直前まで現在の基準時刻からインターバル時間前までの制御帯域送信帯域再送帯域を表す本実施例では、old_token、old_snd、old_rtsと表す。また、図35の4303に示すように、現在使用している基準時刻の一つ前に使用していた基準時刻を旧基準時刻と呼び、旧基準時刻前の制御帯域送信帯域再送帯域は、旧基準時刻の直前まで旧基準時刻からさらにインターバル時間前まで。現在の基準時刻からすると2インターバル時間前の制御帯域送信帯域再送帯域を表す本実施例では、old_old_token、old_old_snd、old_old_rtsと表す。図35の4302に示すように、基準時刻前の再送率old_rts_ratioは、old_rts/old_old_sndで求められる。また、図35の4301に示すように、基準時刻後の現在の再送率rts_ratioは、現在の再送帯域rtsと、基準時刻前の送信帯域とに基づき、rts/old_sndで求められる。図36には、送信帯域制御部3206がシェーパ毎の送信再送帯域テーブル3205記載の値を用いて、制御帯域を変更するフローチャート図を表す。処理がスタートするとステップ3501、送信帯域制御部3206が以下同じ、初めにタイマ3203の出力する現在時刻と、送信再送帯域テーブル3205記載の基準時刻との差が、インターバル3204以上であるか否かを判定するステップ3502。インターバルとして、計測したRTT等を使用してもよい。ステップ3502において真と判断された場合、制御帯域基準時刻後tokenの値をtmpに退避させておくステップ3503。更に、再送ビット積算値基準時刻後/インターバル/送信帯域基準時刻前で求められる再送率基準時刻後rts_ratioが、再送帯域基準時刻前/送信帯域旧基準時刻前で求められる旧再送率基準時刻前old_rts_ratioのK倍K:予め定められた1以上の定数よりも大きいか否かを判定するステップ3504。大きい場合は、再送率が増加していると判断して、制御帯域基準時刻後tokenの値を、制御帯域基準時刻前old_tokenの値よりも小さくなるように、再送帯域rtsを用いて減少させる。例えば、制御帯域基準時刻後token=制御帯域基準時刻前old_token-再送帯域基準時刻後rtsとするステップ3505。ステップ3504で偽と判定された場合は、制御帯域基準時刻後tokenを増加させるステップ3506。ステップ35053506が終了すると、送信帯域基準時刻前old_snd=送信帯域基準時刻後snd、再送帯域基準時刻前old_rts=再送帯域基準時刻後rts、基準時刻=基準時刻インターバル、送信ビット積算値基準時刻後=0、再送ビット積算値基準時刻後=0、制御帯域旧基準時刻前old_old_token=制御帯域基準時刻前old_token、送信帯域旧基準時刻前old_old_snd=送信帯域基準時刻前old_snd、制御帯域基準時刻前old_token=tmp、とし、各値を送信再送帯域テーブル3205に記憶するステップ3507。ステップ3502で、偽と判定された場合は、ステップ3504と同様に、再送ビット積算値基準時刻後/インターバル/送信帯域基準時刻前で求められる再送率基準時刻後rts_ratioが、再送帯域基準時刻前/送信帯域旧基準時刻前で求められる旧再送率基準時刻前old_rts_ratioのK倍K:予め定められた1以上の定数よりも大きいか否かを判定するステップ3508。大きい場合は、例えば再送率が増加していると判断して、ステップ3505と同様に、制御帯域基準時刻後tokenの値を、制御帯域基準時刻前old_tokenの値よりも小さくなるように、再送帯域rtsを用いて減少させる。例えば、制御帯域基準時刻後token=制御帯域基準時刻前old_token-再送帯域基準時刻後rtsとするステップ3509。以上の送信帯域制御部3206の制御帯域を更新する方法により、図30に示す直近の廃棄/再送帯域と、それよりも1RTT前の制御帯域とに基づいて、1RTT前の制御帯域よりも小さくなるように制御帯域を減少させることが可能となる。制御帯域が回線帯域付近で上下するように更新されるため、回線帯域を100近く使い切ることができる。以上記載した手段を用いることで、標準的なTCP通信しかできない端末間でも、RTTや廃棄率に依存しない通信を実現することができる。図37~図40を中心に、上述の実施例の図面を適宜参照して、通信装置を端末間に2台設置し、端末間のTCP通信を、端末と通信装置間のTCP通信、通信装置間のTCP通信、通信装置と端末間のTCP通信、という3つのTCP通信に分割して、各通信装置が中継する2つのTCP通信のうち、端末と通信装置間のTCP通信では標準TCPを、通信装置間のTCP通信では上記特許出願1に記載の又はそれをさらに改良した独自TCPを用いつつ、実施例1に記載のACK返信方法を用いる実施例を説明する。各通信装置が中継する2つのTCP通信では、送信データの再送と受信データの整列が独立して実行される。本実施例では、図26に記載のシステム、図3に記載のブロックを備えた通信装置例えば通信装置を用い、通信装置のTCPモジュールは、端末側は図4に記載のブロックを備えた標準TCPモジュールを用い、対向する通信装置側は図31に記載のブロックを備えた独自TCPモジュールを用いる図26参照。更に、受信履歴更新部3106において、実施例1において図22、図14~図21、図18、図19を用いて説明した手法を用いてバッファ管理ポインタ更新と、ACKパケット返信を行う。また、図37に示すように、図18のフローチャート図が示す処理に対して、ACKを返信する処理ステップ3806の前に、TCPオプションフィールドのright/left_edge_1~42919~2926に、管理ポインタright/left_loss1107が指示する廃棄箇所を記載する処理ステップ4401を追加することで、廃棄箇所を記載した部分的未確認応答NegativeACKNACK用のACKパケットの返信が実現される。他の各ステップは、図18と同様であり、同じ符号を付して説明を省略する。更に、図38に示すように、図19のフローチャート図が示す処理に対して、送信バッファの管理ポインタを変更する処理ステップ3905の後で、TCPオプションフィールドのright/left_edge_1~42919~2926に記載されている値を、再送箇所管理ポインタright/left_rts1108に記載する処理ステップ4501を追加することで、廃棄箇所を記載した部分的未確認応答NegativeACKNACK用のACKパケットを受信したときに、廃棄箇所の即時再送が実現される。受信履歴更新部3106は、図37に示すように、図18のフローチャート図が示す処理に対して、ACKを返信する処理ステップ3805の前に、TCPオプションフィールドのright/left_edge_1~42919~2926に、管理ポインタright/left_loss1107が指示する廃棄箇所を記載する処理ステップ4401を追加することで、廃棄箇所を記載した部分的未確認応答NegativeACKNACK用のACKパケット返信を実現する。更に、受信履歴更新部3106は、廃棄箇所の管理ポインタright/left_loss1107毎に、TCPオプションフィールドに記載してACKパケットを返信した時刻を記録しておき、現在時刻とACKパケットの返信時刻との差が一定時間以上に達するまで、管理ポインタright/left_loss1107をTCPオプションフィールドに記載したACKパケットを返信しないことで、図29に示した、一定時間経過しても再送パケットが到着しない場合に、再度、廃棄箇所を記載したACKパケットを返信することが可能となる。更に、TXパケット再送部3104は、図38に示すように、図19のフローチャート図が示す処理に対して、送信バッファの管理ポインタを変更する処理ステップ3905の後で、TCPオプションフィールドのright/left_edge_1~42919~2926に記載されている値を、再送箇所管理ポインタright/left_rts1108に記載する処理ステップ4501を追加し、再送箇所管理ポインタright/left_rts1108に記載された範囲のデータを再送することで、廃棄箇所を記載した部分的未確認応答NegativeACKNACK用のACKパケットを受信したときに、廃棄箇所を即時再送することが可能となる。以上の受信履歴更新部3106と、TXパケット再送部3104の制御により、図28の全廃棄箇所の即時再送が実現可能となる。図39には、本実施例を用いた場合に、通信装置間の独自TCPを用いた通信において、ロスセグメントが発生したときに、どのようにポインタが移動し、どのようなACKパケットが返信されるかの一例を示したシーケンス図を示す。通信装置23602上述の通信装置920に相当が通信装置13601上述の通信装置910に相当との間の独自TCP通信に用いる受信バッファ3603のポインタ移動と、通信装置3602が受信端末3603との間の標準TCP通信に用いる送信バッフ3604のポインタ移動を示す。通信装置23602が、通信装置13601から送信シーケンス番号がright_recv1103よりも大きなデータ付パケット3605を受信すると、right_recv1103を、受信パケットの送信シーケンス番号とデータ長の和に変更して、left_loss0をleft_recv1102に、right_loss0を受信パケットの送信シーケンス番号にしたロスセグメント記録ポインタを新たに作成する3606。更に、受信シーケンス番号をprev_left_recv1102にして、TCPオプションヘッダ2916内のleft_edge_12919とright_edge_12920に、left_loss0とright_loss[0]の値を記載した3604部分的未確認応答NegativeACKNACK用のACKパケット3608を通信装置13601へ送る。その後、更に、通信装置23602が、通信装置13601から送信シーケンス番号がright_recv1103よりも大きなデータ付パケット3609を受信すると、left_loss1をright_recv1103に、right_loss1を受信パケットの送信シーケンス番号にしたロスセグメント記録ポインタを新たに作成して、right_recv1103を、受信パケットの送信シーケンス番号とデータ長の和に変更する3610。更に、受信シーケンス番号をprev_left_recv1102にして、TCPオプションヘッダ2916内のleft_edge_12919とright_edge_12920に、left_loss1とright_loss1の値を記載した3605部分的未確認応答NACK用のACKパケット3612を通信装置13601へ送る。その後、通信装置23602が、送信シーケンス番号がleft_recv1102と等しく、送信シーケンス番号とデータ長の和がright_loss0と等しいデータ付再送パケット3613を、通信装置13601から受信すると、left_recv1102をleft_loss1の所まで移動させて、ロスセグメント記録用ポインタleft_loss0とright_loss0を初期化して無くして3614、受信シーケンス番号をprev_left_recv1102にした確認応答用のACKパケット3618を通信装置13601へ送る。left_recv1102がleft_rbuf1101よりも大きくなると、left_rbuf1101からleft_recv1102まで書かれているデータを、right_sbuf1106を先頭に送信バッファ3615へ移動させて3616、left_rbuf1101とright_sbuf1106を、移動させたデータサイズ分、右側へ移動させる3617、3619。図40には、本実施例を用いた場合に、通信装置13600が通信装置23602からNACKを受信したときに、どのようにポインタが移動するかを示したシーケンス図を示す。通信装置13600が送信端末3601との間のTCP通信に用いる受信バッファ3603のポインタ移動と、通信装置13600が通信装置23602との間の独自TCP通信に用いる送信バッファ3604のポインタ移動を示す。通信装置13600が、すでにある程度の量のデータを通信装置23602へ送っており、right_sbuf1106とright_send1105が等しく、right_send1105がleft_send1104よりも大きいときを初期状態とする3604。通信装置13600が、通信装置23602から、受信シーケンス番号がleft_send1104よりも大きくright_send1105よりも小さな確認応答用のACKパケット3605を受信すると、left_send1104の値がACKパケット3605記載の受信シーケンス番号ACKに変更される3606。更に、受信シーケンス番号がleft_send1104の値と等しく、尚且つ、受信シーケンス番号がACKパケット3605と等しく、TCPオプションヘッダ2916内のleft_edge_12919にleft_send1104の値を記載し、TCPオプションヘッダ2916内のright_edge_12920にleft_send1104よりも大きくright_send1105よりも小さな値を記載した3611部分的未確認応答NACK用の重複ACKパケット3607を受信すると、left_rts0をleft_edge_12919に、right_rts0をright_edge_12920にした再送セグメント記録ポインタを新たに作成する3608。通信装置13600は、再送セグメントが作成されると、left_rts0からright_rts0までのデータを再送して3609、再送セグメント記録ポインタを初期化して消去する3610。上記に記載の手段を用いることで、標準的なTCP通信しかできない端末間でも、RTTや廃棄率に依存しない通信を実現することが出来、尚且つ、通信装置のいずれか一方が故障しても、送信端末では送信が完了している一方で、受信端末では受信が完了していない、というケースを発生させなくすることが可能となる。[変形例]以下、図42ないし図48を用いて図30ないし図36に関連する通信装置の送信制御部における帯域制御に関する他の変形例を説明する。以下、送信帯域制御部3206が、所定の期間内における現時点における再送状況と、過去の所定の期間内における送信状況、特に再送状況とに基づいて、シェーパー毎のバッファ3209や再送用のバッファ3110に保持されるパケットをネットワークに送出する量である制御帯域を増減する量を制御する例である。図42は、シェーパ毎の送信再送帯域テーブル3205が保持する値の意味を説明するための図35の変形例である。上から下に向かって時間の経過を表す。図42の4201と4202に示すように、基準時刻後の制御帯域は、現在時刻における制御帯域に対応し本実施例では、tokenと表す。基準時刻後の送信帯域は、現在時刻における送信帯域本実施例では、sndと表すに対応する。送信帯域制御部3206は、基準時刻後の送信ビット積算値を現在時刻と基準時刻の差で除算することで求める場合と4202、基準時刻後の送信ビット積算値をインターバルで除算した値に、基準時刻後の送信帯域old_sndに1-現在時刻-基準時刻/インターバルを乗算した値を加算することで求める場合がある4201。基準時刻後の再送帯域は、現在時刻における再送帯域に対応する本実施例では、rtsと表す。この場合は、送信帯域制御部3206は、基準時刻後の再送ビット積算値を現在時刻と基準時刻の差で除算することで求める場合と4202、基準時刻後の再送ビット積算値をインターバルで除算した値に、基準時刻後の再送帯域old_rtsに1-現在時刻-基準時刻/インターバルを乗算した値を加算することで求める場合がある4201。また、図42の4203に示すように、基準時刻前の制御帯域送信帯域再送帯域は、基準時刻の直前まで現在の基準時刻からインターバル時間前までの制御帯域送信帯域再送帯域に対応する本実施例では、old_token、old_snd、old_rtsと表す。また、図42の4204に示すように、現在使用している基準時刻の一つ前に使用していた基準時刻を旧基準時刻と呼び、旧基準時刻前の制御帯域送信帯域再送帯域は、旧基準時刻の直前まで旧基準時刻からさらにインターバル時間前まで。現在の基準時刻からすると2インターバル時間前の制御帯域送信帯域再送帯域に対応する本実施例では、old_old_token、old_old_snd、old_old_rtsと表す。図42の4203に示すように、基準時刻前の再送率old_rts_ratioは、old_rts/old_old_sndで求められる。また、図42の4201または4202に示すように、基準時刻後の現在の再送率rts_ratioは、現在の再送帯域rtsと、基準時刻前の送信帯域とに基づき、rts/old_sndで求められる。現在時刻から基準時刻までを1区間前、基準時刻から旧基準時刻までを2区間前、旧基準時刻以前を3区画前、と区別する。インターバルには、計測したRTTを使用してもよいし、固定値を用いてもよい。図43、44等を用いて、図33の変形例として、送信帯域制御部3206が、1区間前の再送帯域と、2区間前以上前の帯域の使用状況と、に基づいて、制御帯域を増減する制御をする例を示す。図43には、送信帯域制御部3206がシェーパ毎の送信再送帯域テーブル3205記載の値を用いて、制御帯域を更新する例を示す。処理がスタートするとステップ4301、送信帯域制御部3206が以下同じ、1区間前のパケット再送帯域rtsが閾値を超過したか否かを判定するステップ4302。超過した場合は、送信帯域制御部3206は、1区間前の再送帯域と、2区間以上前の送信制御帯域を用いて、制御帯域を減少させるステップ4303。ステップ4303の結果、通信装置から、一のシェーパーに対応するWAN側へのTX部3101からのデータ流出量は、減少する。一方、超過しなかった場合は、ステップ4304に進み、送信帯域制御部3206は、制御帯域を増加させる制御を行う。はじめに、一定期間、再送帯域の閾値超過が無いか否かを判定するステップ4304。例えば、一定期間とは、過去における2区間以上前の所定の一又は複数の区間に対応する。過去における所定の区間毎の再送帯域は、図34に示す送信再送帯域テーブル3205に、旧基準時刻前の再送帯域の欄を、区間ごとに設け、送信帯域制御部3206は、再送状況を管理する。ステップ4304では、送信帯域制御部3206は、旧基準時刻前の再送帯域の欄の所定の一以上の区間の再送帯域の情報を参照し、一定期間、再送帯域の閾値超過が無いか否かを判定する。この場合は、ステップ4302における閾値と、ステップ4306における閾値は異なってもよい。または、ステップ4303において最後に帯域減少させた時刻として保持しておき、送信帯域制御部は、最後に帯域減少させた時刻と、現時刻とを比較して、所定の期間経過したかを判定してもよい。帯域減少させる処理ステップ4303は、図43の処理時点で、再送帯域が閾値を超えていた場合に行われるため、帯域減少させた時刻を送信再送帯域テーブルに保持しておくことで、ステップ4302の閾値と同じ情報を用いて、ステップ4304の判定をすることができる。ステップ4304の結果、YESの場合、送信帯域制御部3206は、制御帯域を指数的に増加させるステップ4305。ステップ4305の結果、通信装置から、一のシェーパーに対応するWAN側へのTX部3101からのデータ流出量は、増加する。一方、NOの場合は、送信帯域制御部3206は、制御帯域を線形的に増加させる4306。ステップ4605,あるいは4606により増加された新たな制御帯域に基づいて、各シェーパー毎のバッファ3209に保持されるパケットを、ネットワークへ送出する。ステップ4306による帯域の増加は、ステップ4305における帯域の増加よりも、緩やかな増加の制御となり、通信装置から一のシェーパーに対応するWAN側へのTX部3101からのデータ流出量は、ステップ4305より比べ緩やかに増加する。ステップ4304~4306により、再送帯域が閾値を下回ってから一定時間経つまでは、他通信との競合が発生する可能性があると判断し、線形的にゆっくりと帯域を増加させる。一方、再送帯域が閾値を下回っている状態が一定時間続くと、他通信との競合が発生していないと判断し、指数的に急激に帯域を増加させる。このように、2区間前以上の一定期間の再送の発生状況により、制御帯域の増加する割合を制御することにより、他の通信帯域を圧迫しないような帯域制御が可能となる。なお、ステップ4305とステップ4306の帯域の増加のさせ方は、指数的な増加、線形的な増加に限定されない。例えば、ステップ4302の結果、一定期間における再送帯域が閾値以下の場合に増加させる制御帯域量が、一定期間における再送帯域が閾値を超過した場合に増加させる制御帯域量の2倍や3倍としてもよい。つまり、ステップ4305と4306では、送信帯域制御部3206は、制御帯域を増加させる場合、2区間以上前の再送帯域に基づいて、制御帯域の増加量を制御し、過去の再送帯域が一定期間、閾値を下回っている場合に比べ、閾値に達した場合の制御帯域の増加量を抑える。また、送信帯域制御部3206は、一定期間における再送帯域が閾値を上回った回数によって、帯域の増加を緩やかにするか急にするかを制御してもよい。また、送信帯域制御部は、一定期間、帯域を減少させた回数によって、帯域の増加を緩やかにするか急にするかを制御してもよい。図43に示す処理により、2区間以上に亘る送信/制御/再送帯域に基づく帯域制御と、他の通信帯域を圧迫しないような帯域制御の共存が可能となる。図44には、図43をより詳細に説明した、送信帯域制御部3206がシェーパ毎の送信再送帯域テーブル3205記載の値を用いて、制御帯域を設定する際のフローチャート図を表す。処理がスタートするとステップ4401、送信帯域制御部3206が以下同じ、基準時刻後の再送帯域rtsが、予め定めた閾値thr_Rよりも大きいか否かを判定するステップ4402。大きい場合、送信帯域制御部3206は、基準時刻前の制御帯域old_tokenよりも小さくなるように、基準時刻後の再送帯域rtsを用いて、新たな制御帯域基準時刻後tokenを決定するステップ4408。例えば、old_token-rtsを新たな制御帯域基準時刻後tokenとするステップ4408。ステップ4402にて否と判定した場合、送信帯域制御部3206は、現在時刻と基準時刻との差がインターバル以上か否かを判定するステップ4403。否の場合は、ステップ4402に戻る。ステップ4403にて真と判定した場合、送信帯域制御部3206は、制御帯域基準時刻後tokenの値をtmpに退避させておくステップ4404。その後、送信帯域制御部3206は、制御帯域基準時刻後tokenを増加させる。一定期間、送信帯域制御部3206は、再送帯域の閾値超過が無いか否かを判定するステップ4405。YESの場合は、送信帯域制御部3206は、制御帯域を指数的に増加させるステップ4410。NOの場合は、送信帯域制御部3206は、制御帯域を線形的に増加させるステップ4409。その後、送信帯域制御部3206は、制御帯域旧基準時刻前old_old_token=制御帯域基準時刻前old_token、制御帯域基準時刻前old_token=tmp、とし、各値を送信再送帯域テーブル3205に記憶するステップ4406。ステップ4406またはステップ4408を実施した後、送信帯域制御部3206は、送信帯域旧基準時刻前old_old_snd=送信帯域基準時刻前old_snd、送信帯域基準時刻前old_snd=送信帯域基準時刻後snd、再送帯域基準時刻前old_rts=再送帯域基準時刻後rts、基準時刻=基準時刻インターバル、送信ビット積算値基準時刻後=0、再送ビット積算値基準時刻後=0、基準時刻=現在時刻として、各値を送信再送帯域テーブル3205に記憶するステップ4407。ステップ4407の後、ステップ4402に戻る。ステップ4405と4409と4410により、再送帯域が閾値を下回ってから一定時間経つまでは、他通信との競合が発生する可能性があると判断し、線形的にゆっくりと帯域を増加させる。一方、再送帯域が閾値を下回っている状態が一定時間続くと、他通信との競合が発生していないと判断し、指数的に急激に帯域を増加させる。これにより、他の通信帯域を圧迫しないような帯域制御が可能となる。更に、図44に示す処理により、2区間以上に亘る送信/制御/再送帯域に基づく帯域制御と、他の通信帯域を圧迫しないような帯域制御の共存が可能となる。図45、46、47を用いて、送信帯域制御部3206が、複数の区間における再送率の変化率に基づいて、制御帯域を制御する例を説明する。図45には、図33の変形例として、送信帯域制御部3206がシェーパ毎の送信再送帯域テーブル3205記載の値を用いて、制御帯域を更新する処理を表す。処理がスタートするとステップ4501、送信帯域制御部3206が以下同じ、パケット再送率の変化率rts_ratio/old_rts_ratioが閾値を超過したか否かを判定するステップ4502。超過した場合は、1区間前の再送帯域と、2区間以上前の送信制御帯域を用いて、制御帯域を減少させるステップ4503。超過しなかった場合は、制御帯域を増加させるステップ4504。これにより、2区間以上に亘る送信/制御/再送帯域、および再送率の変化率に基づく、帯域制御が可能となる。図46には、図45の変形例として、送信帯域制御部3206がシェーパ毎の送信再送帯域テーブル3205記載の値を用いて、制御帯域を更新する際、特に帯域を増加させる場合を中心に、フローチャート図を用いて説明する。処理がスタートするとステップ4601、ステップ4602、4603は、図45のステップ4502及び4503に対応する。ステップ4602の結果、パケットの再送率の変化率rtsratio/old_rts_ratioが閾値を超過しなかった場合は、送信帯域制御部3206は、過去の一定期間、再送率の変化率の閾値超過が無いか否かを判定するステップ4604。これは、ステップ4603で、送信帯域制御部3206は、最後に帯域減少させた時刻として保持しておき、送信帯域制御部3206は、最後に帯域減少させた時刻と、現時刻とを比較して、所定の期間経過したかを判定してもよい。帯域減少させる処理ステップ4603は、図46の処理時点で、再送帯域が閾値を超えていた場合に行われるため、帯域減少させた時刻を管理しておくことで、ステップ4602の閾値と同じ情報を用いて、ステップ4604の判定をすることができる。あるいは、一定期間とは、過去における2区間以上前の所定の一又は複数の区間に対応する。過去における所定の区間毎の再送帯域は、図34に示す送信再送帯域テーブル3205に、パケット再送率の欄を過去の区間ごとに設け、送信帯域制御部3206は、パケット再送の変化率を管理してもよい。ステップ4604では、送信帯域制御部3206は、送信再送帯域管理テーブル3205を参照し、一定期間における再送の変化率が閾値を超過していないか判定する。この場合、ステップ4604の閾値とステップ4602の閾値は異なる値でもよい。一定期間、再送率の変化率の閾値超過が無い場合は、送信帯域制御部3206は、制御帯域を指数的に増加させるステップ4606。ステップ4604にて否と判定した場合は、送信帯域制御部3206は、制御帯域を線形増加させるステップ4605。ステップ4605,及び4606により増加させた場合、新たな制御帯域を、テーブル3205に格納し、新たな制御帯域に基づいて、各シェーパー毎のバッファ3209に保持されるパケットを、ネットワークに送出する。図43のステップ4305や4306と同様に、ステップ4606による帯域の増加は、ステップ4605における帯域の増加よりも、緩やかな増加の制御となり、ステップ4606の結果、通信装置から、一のシェーパーに対応するWAN側へのTX部3101からのデータ流出量は、ステップ4605より比べ緩やかに増加する。これにより、2区間以上に亘る送信/制御/再送帯域、および再送率の変化率に基づく帯域制御と、他の通信帯域を圧迫しないような帯域制御を共存させることが可能となる。つまり、廃棄率の増加率が閾値を下回ってから一定時間経つまでは、他通信との競合が発生する可能性があると判断し、線形的にゆっくりと帯域を増加させる。一方、廃棄率の増加率が閾値を下回っている状態が一定時間続くと、他通信との競合が発生していないと判断し、指数的に急激に帯域を増加させる。これにより、他の通信帯域を圧迫しないような帯域制御が可能となる。図43と同様に図46も、2区間前以上の一定期間の再送の発生状況により、制御帯域の増加する割合を制御することにより、他の通信帯域を圧迫しないような帯域制御が可能となる。なお、ステップ4605とステップ4606の帯域の増加のさせ方は、指数的な増加、線形的な増加に限定されない。例えば、ステップ4602の結果、一定期間における再送の変化率が閾値以下の場合に増加させる制御帯域量が、一定期間における再送の変化率が閾値を超過した場合に増加させる制御帯域量の2倍や3倍としてもよい。つまり、ステップ4305と4306では、送信帯域制御部3206は、制御帯域を増加させる場合、2区間以上前の再送率の変化率に基づいて、制御帯域の増加量を制御し、過去の再送率の変化率が一定期間、閾値を下回っている場合に比べ、閾値に達した場合の制御帯域の増加量を抑えるようにしてもよい。送信帯域制御部3206は、ステップ4604の代わりに一定期間における再送率の変化率が閾値を上回った回数によって、帯域の増加を緩やかにするか急にするかを判定してもよい。図47には、図46の具体的な例として、送信帯域制御部3206が制御帯域を更新する処理を示す。処理がスタートするとステップ4701、送信帯域制御部3206が以下同じ、初めにタイマ3203の出力する現在時刻と、送信再送帯域テーブル3205記載の基準時刻との差が、インターバル3204以上であるか否かを判定するステップ4702。インターバルには、計測したRTTを用いてもよいし、予め定めた値を用いても良い。ステップ4702において真と判断された場合、送信帯域制御部3206は、制御帯域基準時刻後tokenの値をtmpに退避させておくステップ4703。更に、再送率基準時刻後rts_ratioが、旧再送率基準時刻前old_rts_ratioのK倍K:予め定められた1以上の定数よりも大きいか否かを判定するステップ4704。大きい場合は、送信帯域制御部3206は、再送率が増加していると判断して、制御帯域基準時刻後tokenの値を、制御帯域基準時刻前old_tokenの値よりも小さくなるように、再送帯域rtsを用いて減少させる。例えば、制御帯域基準時刻後token=制御帯域基準時刻前old_token-再送帯域基準時刻後rtsとするステップ4705。更に、最後に帯域減少させた時刻としてdec_timeに現在時刻を代入しておくステップ4706。ステップ4704で偽と判定された場合は、送信帯域制御部3206は、制御帯域基準時刻後tokenを線形的にまたは指数的に増加させる。現在時刻と、最後に帯域減少させた時刻dec_timeの差が、予め定めた閾値Tよりも大きいか否かを判定するステップ4708。Tは、RTTとtokenに比例する動的変数値としてもよい。ステップ4708にて真と判定した場合は、tokenを指数的に増加させるステップ4709。たとえば、予め定めた値Eを用いて、token=Etokenとしてもよいステップ4709。Eは、tokenによって定まる値としてもよい。ステップ4708にて偽と判定した場合は、tokenを線形的に増加させるステップ4710。たとえば、予め定めた値Lを用いて、token=tokenLMSS/RTTとしてもよいステップ4710。MSSはMaximumSegmentSizeである。ステップ4706、4709、4710が終了したら、送信帯域旧基準時刻前old_old_snd=送信帯域基準時刻前old_snd、送信帯域基準時刻前old_snd=送信帯域基準時刻後snd、再送帯域基準時刻前old_rts=再送帯域基準時刻後rts、基準時刻=基準時刻インターバル、送信ビット積算値基準時刻後=0、再送ビット積算値基準時刻後=0、制御帯域旧基準時刻前old_old_token=制御帯域基準時刻前old_token、制御帯域基準時刻前old_token=tmp、とし、各値を送信再送帯域テーブル3205に記憶するステップ4707。ステップ4702で、偽と判定された場合は、ステップ4704と同様に、送信帯域制御部3206は、再送率基準時刻後rts_ratioが、旧再送率基準時刻前old_rts_ratioのK倍K:予め定められた1以上の定数よりも大きいか否かを判定するステップ4711。大きい場合は、例えば再送率が増加していると判断して、ステップ3505と同様に、制御帯域基準時刻後tokenの値を、制御帯域基準時刻前old_tokenの値よりも小さくなるように、再送帯域rtsを用いて減少させる。例えば、制御帯域基準時刻後token=制御帯域基準時刻前old_token-再送帯域基準時刻後rtsとするステップ4712。ステップ4712が終了したら、ステップ4702に戻る。以上により、2区間以上に亘る送信/制御/再送帯域、および再送率の変化率に基づく帯域制御と、他の通信帯域を圧迫しないような帯域制御を共存させることが可能となる。図46及び47によると、送信帯域制御部3206は、第一の期間内における現時点で設定されている制御帯域に基づいて、TX部3101から送出されるパケットに占める再送パケットの再送率の変化率を監視する。その監視結果、所定の閾値に達した場合、送出されるパケットの量を減少させるために、制御帯域を小さくし、その制御帯域に従ってバッファ3209からパケットを読み出す。また、監視結果、再送率の変化率が、所定の時間経過後、閾値に達しなかった場合、送信帯域制御部3206は、送出されるパケットの量を増加させるために制御帯域を大きくし、その制御帯域に従って、その制御帯域に従ってバッファ3209からパケットを読み出す。また、制御帯域を大きくする場合、送信帯域制御部3206は、過去の第一の期間ごとの制御帯域の遷移に基づいて、どの程度大きくするかを制御する。例えば、制御帯域が減少された時点と現在の時刻との期間が、第一の期間よりも大きく、あらかじめ設けられた期間を経過している場合は、していない場合に比べて、増加させる量を制御する。図43ないし図47によると、送信帯域制御部3206は、RTT等に対応するインターバル毎にTX部3101から送出されるパケットの量を制限するための制御帯域を更新する。送信帯域制御部は、再送パケットの送出に応じて、インターバルである第一の期間ごとに再送状況を監視し、再送状況に基づいて、制御帯域を増減すべきかを判断する。監視対象となる再送状況は、例えば、第一の期間で発生した再送パケットの量に対応する再送帯域や、第一の期間で発生した再送パケットの量が、監視した時点を含む第一の期間よりも前の期間で発生した再送パケットの量との比較したものが対象となる。制御帯域を減少させる場合、送信帯域制御部3206は、監視した時点を含む第一の期間よりも、過去の送信状況、再送状況や設定されていた制御帯域に基づいて、減少させる帯域量を決定し、制御帯域を減少させる。一方、制御帯域を増加させる場合、送信帯域制御部3206は、制御帯域を減少させた時点と現時点との間隔をみて、間隔が長い場合のときは、短い場合に比べて増加させる制御帯域の量大きくする、制御を行う。以上の構成や処理により、通信装置は、第一の期間における再送状況と、過去の送信状況によって、きめ細やかな帯域制御を行うことができる。また、帯域の増減をきめ細やかに行うことで、他の通信帯域への圧迫を防ぐことができる。また、以上の送信帯域制御部3206の制御帯域を更新する方法により、現時点の第一の期間における再送帯域と、それより以前の第一の期間、例えば、1RTT前の制御帯域野菜層帯域とに基づいて、1RTT前の制御帯域よりも小さくなるように制御帯域を減少させ、あるいは、増加させることが可能となる。制御帯域が回線帯域付近で上下するように更新されるため、回線帯域を有効に使うことができる。以下、図48ないし53を用いて、図9に関係するデータ通信を行う通信装置間を中心にシーケンス図を説明する。図48は、図9に示すデータ通信を行う前に、TCPコネクションを確立するためのシーケンス図を示す。はじめに、送信端末103と通信装置1100との間で、SYN4801、SYN-ACK4802、ACK4803のやり取りを行いコネクションを確立する。次に、通信装置1100と通信装置2101との間で、SYN4804、SYN-ACK4805、ACK4806のやり取りを行いコネクションを確立する。最後に、通信装置2101と受信端末104との間で、SYN4807、SYN-ACK4808、ACK4809のやり取りを行いコネクションを確立する。送信端末103は、送信端末103と通信装置1100との間で、コネクションが確立した後に、図9と同様にデータ送信を開始する。図49は、図9に示すデータ通信を行う前に、TCPコネクションを確立するための別のシーケンス図を示す。送信端末103から、通信装置1100と通信装置2101を経由して、受信端末104に向けて、SYN4901、4904、4907が送られる。次に、受信端末104から、通信装置2101と通信装置1100を経由して、送信端末103に向けて、SYN-ACK4908、4905、4902が送られる。最後に、送信端末103から、通信装置1100と通信装置2101を経由して、受信端末104に向けて、ACK4903、4906、4909が送られる。この後、送信端末103は、図9と同様にデータ送信を開始する。図50は、図9に示すデータ通信を行う前に、TCPコネクションを確立するための別のシーケンス図を示す。送信端末103から、通信装置1100と通信装置2101を経由して、受信端末104に向けて、SYN5001、5004、5007が送られる。次に、受信端末104から、通信装置2101と通信装置1100を経由して、送信端末103に向けて、SYN-ACK5008、5005、5002が送られる。通信装置2101は、SYN-ACK5008を受け取ると、ACK5009を返信する。通信装置1100は、SYN-ACK5005を受け取ると、ACK5006を返信する。送信端末103は、SYN-ACK5002を受け取ると、ACK5003を返信する。その後、送信端末103は、図9と同様にデータ送信を開始する。図51は、図9に示すデータ通信を行った後に、TCPコネクションを切断するためのシーケンス図を示す。はじめに、送信端末103と通信装置1100との間で、FIN5101、FIN-ACK5102、ACK5103のやり取りを行い、コネクションを切断する。次に、通信装置1100と通信装置2101との間で、FIN5104、FIN-ACK5105、ACK5106のやり取りを行い、コネクションを確立する。最後に、通信装置2101と受信端末104との間で、FIN5107、FIN-ACK5108、ACK5109のやり取りを行いコネクションを切断する。図52は、図9に示すデータ通信を行った後に、TCPコネクションを切断するための別のシーケンス図を示す。送信端末103から、通信装置1100と通信装置2101を経由して、受信端末104に向けて、FIN5201、5204、5207が送られる。次に、受信端末104から、通信装置2101と通信装置1100を経由して、送信端末103に向けて、FIN-ACK5208、5205、5202が送られる。最後に、送信端末103から、通信装置1100と通信装置2101を経由して、受信端末104に向けて、ACK5203、5206、5209が送られる。図53は、図9に示すデータ通信を行った後に、TCPコネクションを切断するための別のシーケンス図を示す。送信端末103から、通信装置1100と通信装置2101を経由して、受信端末104に向けて、FIN5301、5304、5307が送られる。次に、受信端末104から、通信装置2101と通信装置1100を経由して、送信端末103に向けて、FIN-ACK5308、5305、5302が送られる。通信装置2101は、FIN-ACK5308を受け取ると、ACK5309を返信する。通信装置1100は、FIN-ACK5305を受け取ると、ACK5306を返信する。送信端末103は、FIN-ACK5302を受け取ると、ACK5303を返信する。以上、図9並びに図48ないし図53により、端末間でTCPコネクションを確立後、通信装置が、送信側と受信側とのデータ通信を中継し、送信側の端末にACKを返すタイミングを制御する。データ通信に関するACKを送信側が受信するのに応じて、送信側からTCPコネクションを切断する処理が行われる、例を説明した。"