JP5832335B2 - 通信装置および通信システム - Google Patents

通信装置および通信システム Download PDF

Info

Publication number
JP5832335B2
JP5832335B2 JP2012038156A JP2012038156A JP5832335B2 JP 5832335 B2 JP5832335 B2 JP 5832335B2 JP 2012038156 A JP2012038156 A JP 2012038156A JP 2012038156 A JP2012038156 A JP 2012038156A JP 5832335 B2 JP5832335 B2 JP 5832335B2
Authority
JP
Japan
Prior art keywords
communication
tcp
packet
transmission
bandwidth
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.)
Expired - Fee Related
Application number
JP2012038156A
Other languages
English (en)
Other versions
JP2013175850A (ja
JP2013175850A5 (ja
Inventor
武己 矢崎
武己 矢崎
隆史 磯部
隆史 磯部
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2012038156A priority Critical patent/JP5832335B2/ja
Priority to EP12869123.5A priority patent/EP2819359A1/en
Priority to PCT/JP2012/079309 priority patent/WO2013125109A1/ja
Priority to US14/378,669 priority patent/US20150029861A1/en
Publication of JP2013175850A publication Critical patent/JP2013175850A/ja
Publication of JP2013175850A5 publication Critical patent/JP2013175850A5/ja
Application granted granted Critical
Publication of JP5832335B2 publication Critical patent/JP5832335B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/215Flow control; Congestion control using token-bucket
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/19Flow control; Congestion control at layers above the network layer
    • H04L47/193Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/168Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]

Description

本発明は、通信装置および通信システムに係り、特に、計算機間の通信を中継する通信装置及び通信システムに関する。
グローバル拠点間の通信網として、IP―VPN(Internet Protocol−Virtual Private Network)技術等を用いたWAN(Wide Area Network)を用いることが、一般的になっている。
拠点に存在する端末が、別の海外の拠点に存在する端末と通信する場合は、自拠点LAN(Local Area Network)と国内WANを接続する回線と、国内WANと海外WANを接続する回線と、海外WANと別拠点LANを接続する回線と、を経由して通信が行われる。これらの回線は、契約帯域によって使用可能な帯域幅が制限されている。
端末間の通信では、TCP(Transport Communication Protocol)を用いるのが一般的である。TCP通信では、送信端末が送信したデータ(パケットと呼ぶ)に対して、受信端末が受信済みパケット量を送信端末にフィードバック通知する。送信端末は、フィードバック通知される受信済みパケット量が増加しなくなると、廃棄検出と判定する。
さらに、送信端末は、ウィンドウサイズ(受信したことを受信端末から通知されなくても送信可能なデータサイズ)と呼ばれるパラメータを管理しており、RTT(Round Trip Time)や廃棄検出の有無に応じて、ウィンドウサイズを変化させる。
送信端末は、RTT増加時や廃棄検出時にネットワークが混雑していると判定して、ウィンドウサイズを減少させることで、送信帯域を減少させて、ネットワークの混雑を回避する。また、RTT減少時や廃棄が無い時にネットワークが空いていると判定して、ウィンドウサイズを増加させることで、送信帯域を増加させて、ネットワークの回線帯域を有効利用する。以上のように、TCPを用いた通信では、送信帯域がRTTと廃棄率に大きく左右されるため、前述のWANのようなRTTが大きく、契約帯域が制限されておりパケット廃棄が発生する環境において、契約帯域を大幅に下回る送信帯域しか得られない場合がある。
これらの問題を解決する技術が特許文献1に記載されている。本文献では、受信側端末に接続した装置が送信側端末に接続した装置に対して廃棄箇所を全てフィードバック通知する手段と、送信側端末に接続した装置がフィードバック通知された廃棄箇所を再送する手段と、送信側端末に接続した装置が再送帯域・廃棄帯域に基づいて送信帯域を制御する手段を備えることにより、送信帯域が改善される、と記載されている。
WO2011033894A
IP―VPNによるWANの契約帯域は回線帯域より小さい場合があり、特許文献1記載の送信側端末が契約帯域を超過して送信したパケットについては、WANにて廃棄されてしまう場合がある。また、TCP以外の通信、例えば、他のプロトコルであるUDP通信などが存在するが、特許文献1記載の送信側端末が契約帯域をすべて消費してしまうと、UDP通信などの通信遅延時間やパケットの廃棄率といった通信品質が劣化するといった課題がある。
そこで、本願の目的の一つは、他のプロトコル等の通信の劣化を防ぎ、TCP通信に対する送信帯域制御をすることにある。
前述した課題を解決するために、本発明の一態様は、第一のTCP通信と第二のTCP通信の2つのTCP通信を中継する通信装置であって、第二のTCP通信の規定に基づいて判定した通信帯域と、第二のTCP通信の最大帯域とを遵守し、パケット送信する第二のTCP通信の上限帯域を制御する態様である。
また、別の態様として、第一のTCP通信と第二のTCP通信の2つのTCP通信を中継する中継装置であって、第二のTCP通信の規定に基づいて、第二のTCP通信における通信帯域を判定する送信帯域制御部と、第二のTCP通信の最大帯域を設定する最大送信帯域設定部と、第一のTCP通信により通信されたパケットを蓄積するバッファを備え、前記判定した通信帯域および前記最大帯域に基づき、前記バッファに対してパケットの送信を指示し、パケットを送信することを特徴とする。
上記以外の本願が解決しようとする課題、その解決手段は、本願の「発明を実施するための形態」の欄および図面で明らかにされる。
本発明の一態様によると、回線を共有する他のプロトコル通信の劣化を防ぎ、第二のTCP通信として通信帯域を向上させる新規TCPによる通信帯域をTCP通信に対して向上することができる。
通信装置#1/#2 910/920をWANとLANの境界に設置したシステム図。 パケットのフォーマットの一例を示す図。 通信装置1000のブロックの一例を示す図。 通信装置1000内部の標準TCP部(NIF0 TCP)1007の一例を示すブロック図。 通信装置1000内部の従来TCP部(NIF1 TCP)914/923の一例を示すブロック図。 通信装置910/920をWANとLANの境界に設置して、通信装置間で独自TCPを用いて通信するシステム図。 帯域制御方式の説明図。 再送制御方式の説明図。 通信装置#1、#2 100、101が1パケット分ずらしてACK返信するシーケンス図。 パケット送信制御部3207の動作を示すフローチャート。 輻輳制御方式の説明図。 通信装置1000内部の独自TCP部(NIF1 独自TCP)2501/2502の一例を示すブロック図。 パケット送信制御部3207の構成の一例を示す図。 セッション・シェーパテーブルの一例を示す図。 送信帯域制御部3206が制御帯域を更新する際のフローチャート。 シェーパ毎の送信・再送帯域テーブル3205の一例を示す図。 シェーパ毎の送信・再送帯域テーブル3205が保持する値の説明図。 制御帯域の更新のフローチャート。
以下、本願発明を、実施例を用いて説明する。
図1には、通信装置#1(910)と通信装置#2(920)がネットワーク#0(900)とネットワーク#1、2(901、902)の境界に設置されて、ネットワーク#1(901)に接続している端末(903、904)と、ネットワーク2(902)に接続している端末(905、906)の間で、3つのTCP通信を経由して通信が行われる様子を示す。通信装置#1(910)は、ネットワークインターフェースNIF0/1(915/916)と、演算部911を備える。演算部911は、TCP通信を行うTCPモジュール913/914と、TCPの変換(例えば、TCP1からTCP2の変換)を行うProxyモジュール912を備える。
図2には、本実施例でやりとりされるパケットのフォーマットを表す。パケットは、MACヘッダ2900、IPヘッダ2904、TCPヘッダ2909、TCPオプションヘッダ2916、ペイロード2927を含む。MACヘッダ2900は、宛先MACアドレスを表すDMAC2901と、送信元MACアドレスを表すSMAC2902と、MACフレームタイプを表すType2903を含む。IPヘッダ2904は、MACヘッダを除くパケット長を表すIP length2905と、プロトコル番号を表すprotocol 2906と、送信元IPアドレスを表すSIP2907と、宛先IPアドレスを表すDIP2908とを含む。TCPヘッダ2909は、送信元ポート番号を表すsrc.port2910と、宛先ポート番号を表すdst.port2911と、送信シーケンス番号を表すSEQ2912と、受信シーケンス番号を表すACK2913と、TCPフラグ番号を表すflag2914と、TCPのヘッダ長を表すtcp hlen2915とを含む。flag2914は、URG2914‐1、ACK2914‐2、PSH2914‐3、RST2914‐4、SYN2914‐5、FIN2914‐6の各ビットから構成される。TCPオプションヘッダ2916は、オプション種別を表すoption kind2917と、オプション長を表すoption length2918と、どこからどこまで部分的に受信できたかを記載するleft_edge_1〜4(2919、2921、2923、2925)、right_edge_1〜4(2920、2922、2924、2926)を含む。なお、端末間の通信を例に説明するが、TCP通信可能な計算機間の通信、クライアント計算機とサーバ計算機間の通信、分散ファイルサーバー間の通信にも本実施例の通信装置910、920等を適用してもよい。
通信装置#1,2の概要動作を、図1、5を用いて説明する。
端末903、904と通信装置#1 910間では、TCP1により、通信装置#1と#2間では、TCP2により、通信装置#2と端末905、906間ではTCP3により通信が行われ、端末903、904が送信したパケットが端末905、906まで通信されている。通信装置#1は、TCP1からTCP2への変換を、通信装置#2は、TCP2からTCP3へのプロトコル変換を実施している。
図5は通信装置#1のNIF1 TCP914を示している。送信帯域制御部3208はネットワーク#0に送信するパケットの通信帯域をTCP2の規定に基づきセッション毎に判定している。ここでセッションとはsrc.port2910と、宛先ポート番号を表すdst.port2911と、SIP2907と、DIP2908より決まるパケットの一連の流れのことを言う。この判定は、TCP2の通信装置#2から送信され、パケット解析部3108により抽出された情報、例えば、通信装置#1が送信したパケットに対するACKパケットに基づき判定する。ACKパケットとは、通信装置#1が送信したパケットを通信装置#2が受信したことを示すパケットであり、図2のACKが1となっているパケットである。つまり、送信帯域制御部3208は、ネットワーク#0に送信するパケットの通信帯域を、ネットワーク#0からのACKパケットに基づき判定する。あるいは、送信帯域制御部3208は、ネットワーク#0における通信状況に基づき、送信するパケットの通信帯域を算出する。
また、NIF1 TCP914は、最大送信帯域設定部3211を備え、外部端末よりプロセッサ200経由で全セッションの帯域の総和が設定されている。さらに、NIF1 TCP914はセッション毎のバッファ3111を備え、ネットワーク#1から入力したパケットをセッション毎に格納する。パケット送信制御部3207は、送信帯域制御部3208が判定したセッション毎の通信帯域と、最大送信帯域設定部3211に設定される全セッションの帯域の総和より、セッション毎のバッファ3111からパケットを送信するタイミングを判定する。
パケットがネットワーク#1より入力するとNIF0 TCP913がTCP1のパケットを受信し、Proxy912が、必要に応じてパケットの情報の書き換え、NIF1 TCP914に送信する、NIF1 TCP914は該パケットをセッション毎のバッファ311に格納する。前述の通り、送信帯域制御部3208は、ネットワーク#0からのパケットに基づき、バッファからの送信帯域をセッション毎に判定し、その結果をセッション毎通信帯域情報としてパケット送信制御部3207に通知する。パケット送信制御部3207は最大送信帯域設定部3211に設定された最大帯域に基づき、バッファ311よりパケットを送信した際に全てのセッションの送信帯域の総和を遵守できるか否かを判定する。さらに、セッション毎通信帯域情報に基づき、各バッファ311からのパケットの送信可否を判定する。送信帯域の総和を遵守「可」であり、かつセッション(バッファ)の送信可否が「可」のセッション(バッファ)のパケットを「送信」と判定し、バッファ311にセッション毎送信要求信号を送信する。バッファ311は、該情報に対応するセッション毎のバッファより、パケットを読み出してNIF1 916経由でパケットをネットワーク#0に向けて送信する。なお、最大送信帯域設定部3211には、外部端末より管理ネットワークを介して全セッションの帯域の総和が設定されてもよい。
以上に記載した実施例によれば、送信帯域制御部3208が、TCP2のプロトコルの規定により決まるセッション毎のパケットの通信帯域を判定し、パケット送信制御部3207がTCP2のセッション全体の総和の帯域と送信帯域制御部3208が判定した通信帯域に基づき、パケットの送信の可否を判定し、パケットをバッファ311より送信することにより、TCP2のプロトコルの規定を遵守しつつ、TCP2の上限帯域を制御可能となる。
次に変形例を説明する。
セッション数が1であり、図1のTCP2が従来TCPである場合の通信装置#1、2の詳細動作について説明する。図3には、ハードウェアで実装した、本実施例の通信装置#1(1000)(図1の通信装置910、920に相当)のブロック図を表す。通信装置#1(1000)は、外部ネットワークとのパケットの送受信を行うネットワークインターフェースNIF0/1(1011/1012)と、TCP以外のUDPパケット等を1007、1008、1013〜1016、1000を迂回させるためのフィルタ(1009/1010)と、TCP通信のための制御を行うNIF0/1向けTCPモジュール1007/1008と、NIF0向けTCPモジュール1007が管理する送信バッファ1013および受信バッファ1015と、NIF1向けTCPモジュール1008が管理する送信バッファ1016および受信バッファ1014と、送受信バッファ間でデータの乗せ換えを行うプロキシ1000と、セッション毎にエントリを備えた状態テーブル1001を有する(本実施例ではエントリ数は1)。ソフトウェアで実装する際は、状態テーブル1001と送受信バッファ(1013〜1016)を記憶部に持ち、フィルタ(1009/1010)とTCPモジュール1007/1008とプロキシ1000の部分をモジュールとして演算部(図1の演算部912に対応)に持たせる。
図4には、NIF0用のTCPモジュール1007のブロック図を表す。NIF1用のTCPモジュール1008のブロック図、動作は1007と同様である。本モジュールの動作を図1の端末903、904から端末905、906にパケットを送信する際の動作にて説明する。
図4の標準TCPを実現するTCPブロック1007は、受信処理を行うRX部(受信処理部)3102と、送信処理を行うTX部(送信処理部)3101を有する。RX部3102は、受信パケットをTCP制御パケットとデータパケットとACK/部分的確認応答用SACKパケットに分離するパケット解析部3108と、受信したTCP制御パケットに基づいて状態テーブル1001内のTCP状態を変更するTCP制御部3107と、src.port2910と、宛先ポート番号を表すdst.port2911と、SIP2907と、DIP2908より決まるパケットの属するセッション毎にエントリを備えた状態テーブル1001(本実施例ではエントリ数は1)と、TCP制御パケットに基づき、セッション毎のTCPの状態を管理するTCP制御部3107と、受信履歴更新部3106とを有する。
まず、通信の開始に先立ち、端末903、904よりSYN2914−5が1であるSYNパケットを受信すると、パケット解析部3108は該パケットをTCP制御部3107に送信する。TCP制御部3107は、状態テーブル1001の空きのエントリがあるとSYNパケットを受信したTCP状態であることを状態テーブル1001に書き込む。さらにTCP制御部3103は、このTCP状態を参照し、ACK2914−2およびSYN2914−5が1であるSYN−ACKパケットをバッファ3111に格納する。集約部3109が該パケットをNIF0 1011より端末903、904に送信する。
次に、端末903、904はACK2914−2のみを1としたACKパケットを通信装置#1に送信し、パケット解析部3108は該パケットを受信するとTCP制御部3107に送信する。TCP制御部3107がこのパケットを受信すると、セッションが確立されたことを表すTCP状態を、状態テーブルに書き込む。
次にTCP制御部はこのセッションの確立をNIF1用のTCPモジュール1008に通知すると、TCPモジュール1008のTCP制御部3103は前述の端末903、904と同様のSYNパケットをバッファ3111に格納し、集約部3109が該パケットをNIF1 1012より通信装置#2に送信する。TCP制御部3103は状態テーブル1001にSYNパケットを送信したTCP状態であることを書き込む。なお、集約部309が該パケットを送信するタイミングは後述する。通信装置#2は、通信装置#1にてSYNパケットを受信した際と同様の処理を実施し、通信装置#1にSYN−ACKパケットを送信する。通信装置#1がSYN−ACKパケットを受信すると、パケット解析部3108は該パケットをTCP制御部3107に送信し、TCP制御部3107は状態テーブル1001にセッションが確立したことを表すTCP状態を書き込む。TCP制御部3103は状態テーブル1001のTCP状態を参照し、前述の端末903、904と同様のACKパケットをバッファ3111に格納し、集約部3109が該パケットを通信装置#2に送信することで通信装置#1、2間のセッションが確立される。通信装置#2と端末905、906間のセッション確立についても同様である。
セッションが確立されると端末903、904はパケットの送信を開始する。通信装置#1のパケット解析部3108は、該パケットを受信すると、受信履歴更新部3106に送信する。受信履歴更新部3106は受信バッファ1013にパケットを書き込み、送信シーケンス番号SEQ2912に対応した値を受信シーケンス番号ACK2913に記載したACKパケットをバッファ3110に書き込む。該ACKパケットは集約部3109によりバッファ3110より読み出され、端末903、904に送信される。
受信バッファ1013にパケットが蓄積されると、Proxy1000はパケットを読み出し、送信バッファ1016に転送し、送信バッファ1016は該パケットを蓄積する。パケットが蓄積されると、NIF1 TCP1006の送信履歴更新部3105はパケットをバッファ3113に書き込み、集約部3109は該パケットを通信装置#2に送信する。集約部3109が該パケットを送信するタイミングについては後述する。また、送信履歴更新部3105は送信したパケットの履歴を状態テーブル1001に書き込む。
該パケットを受信した通信装置#2の通信装置#1へのACKパケットの送信動作およびパケットの端末905、906への送信動作は通信装置#1と同一である。通信装置#1が送信したパケットに対応するACKパケットを通信装置#1が受信すると、該パケットの送信履歴を状態テーブル1001より削除する。一方、対応するACKパケットを受信できない場合、TXパケット再送部3104が該パケットと同一のパケットをバッファ3112に再度書き込み、集約部3109経由で該パケットを通信装置#2に送信する。
通信装置#1の送信帯域制御部3214は、ACKパケットの受信状況から送信したパケットの到着状況および廃棄状況を監視し、図7の左図および図11の左図に記載されるように、通信装置#1から通信装置#2に送信すべき通信帯域を判定し、パケット送信制御部3215に通知する。また、最大送信帯域設定部3211には外部端末よりプロセッサ3216経由で、通信装置#1から通信装置#2に送信する最大帯域が設定されており、パケット送信制御部3215にこの最大帯域が通知されている。図7の左図および図11の左図の詳細については後述する。
パケット送信制御部3215は、送信帯域制御部3214が通知した通信帯域およびこの最大帯域の両方を遵守するタイミングで、集約部3109に送信要求信号を送信する。集約部3109はこの送信要求信号を受信するとバッファ3113あるいは3111よりパケットを読み出し送信する。
図9は、本実施例におけるプロキシ(100、101)のACK返信方法を記載したシーケンス図を表す。 通信装置#1(100)・通信装置#2(101)(図1の通信装置910、920に相当)は、先頭パケット(110、111)を受け取ってもACKを返信しない。通信装置#1(100)・通信装置#2(101)は、2つ目のパケット(113、114)を受け取ってから、1つ目のパケットに対するACKパケット(121、120)を返信する。更に、3つ目のパケット(116、117)を受け取ると、2つ目のパケットに対するACKパケット(122、124)を返信する。送信端末103は、3つ目のパケット(116)を送信しても、2つ目のパケットに対するACKパケット(122)しか受信しないので、送信が完了していないと判断したままである(128)。通信装置#2(101)から3つ目のパケット(118)が受信端末104に到達して初めて、3つ目のパケットに対する末尾のACKパケット(125)が受信端末104から返信され、受信端末130は受信が完了したと判断する(130)。通信装置#2(101)・通信装置#1(100)は、末尾のACKパケット(125、126)を受け取ると、3つ目のパケットに対する末尾のACKパケット(126、127)を送信側へ送信する。送信端末103は、末尾のACKパケット127を受け取り、送信が完了したと判断する(129)。受信端末130で受信が完了したと判断されない限り(130)、末尾のACKパケット(125、126、127)が送信端末103に返信されず、送信端末129が送信完了と判断しないため、受信端末104が編集データを受け取れないまま、送信端末のアプリケーションが終了してしまい、編集データが消滅してしまう、といった事態を防ぐことができる。なお、上述のように、ひとつ前に受信したデータパケットに対するACKを送信する以外にも、2つ前、3つ前など少なくともひとつ前のデータパケットに対するACKを送信してもよい。また、先頭パケット110に対しては、ACKを送信しない以外にも、先頭パケットの最後尾データに対応する受信シーケンス番号を含まないような(例えば、0〜1459)ACKを返送し、先頭パケットの最後尾データに対応する受信シーケンス番号を含むACKは返送しないようにしてもよい。
次に別の変形例を説明する。
セッション数が複数であり、図6のWANの通信が独自TCPである場合の通信装置#1、2の詳細動作について説明する。図6は、図1をベースにNIF1側のTCPモジュールを上記の独自TCPの処理を行うモジュール2501/2502に変更したシステム図である。本システムでは、WAN907内で独自TCPを用いて通信が行われる。
通信装置#1、2 910/920は、図3に示したブロック図と同様なブロック図で実装することができ、NIF TCP1008が図12に示す独自TCPモジュール2501/2502に変わる。
受信端末側の通信装置#2は、送信端末側の通信装置#1に対して廃棄箇所を全て逐一フィードバック通知すると共に、送信端末側の通信装置は、受信端末側の通信装置からフィードバック通知された廃棄箇所を再送し、尚且つ、基準時刻以降の再送帯域又は廃棄帯域(再送/廃棄帯域と記すこともある)と、基準時刻以前の送信帯域とに基づいて、特定の宛先に対する送信帯域と再送帯域の総和を制御することで、RTTや廃棄率に依存しない通信帯域を確保する。
図7、8、11には、独自TCPの3つの特徴を表した説明図を示す。図7には、左側に、標準的なTCPの例として従来型TCPの帯域制御方式を、右側に独自TCPの帯域制御方式を示す。従来型TCPは、送信端末2601において、RTT毎の送信量を定めたウィンドウサイズ2605を制御することで(2607)、送信帯域を制御する。送信帯域は、ウィンドウサイズ/RTTで表される。この方式による帯域制御は、RTTが増加すると回線が空いていても送信不可能な時間2610が増加して、回線帯域の利用率が減少する、という課題があった。一方、独自TCPでは、一定時間毎の送信量を定めたトークンサイズ2606を制御することで(2608)、送信帯域を制御する。送信帯域は、トークンサイズ/インターバル時間で表される。本方式を用いることで、回線が空いていても送信不能な時間を無くすことが出来るため、回線帯域の利用率が増加する(2609)。RTTに依存しない帯域制御を実現することができる。
図8には、左側に従来型TCPの再送制御方式を、右側に独自TCPの再送制御方式を示す。従来型TCPでは、ACKパケットのTCPオプションヘッダ2916内のleft_edge_1〜4(2919、2921、2923、2925)、right_edge_1〜4(2920、2922、2924、2926)には、どこからどこまで部分的に受信済であるかを最大4箇所記載して、部分的確認応答(Selective ACK(SACK))用に用いる。一方、独自TCPでは、TCPオプションヘッダ2916内のleft_edge_1〜4(2919、2921、2923、2925)、right_edge_1〜4(2920、2922、2924、2926)には、どこからどこまで部分的に再送してほしいかを最大4箇所記載して、部分的未確認応答(Negative ACK(NACK))用に用いる。
従来型TCPでは、送信端末2701から受信端末2702へ送った12個のデータパケットA〜L(2705)のうち、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〜L(2708)のうち、B、D、F、H、Jが途中で廃棄されたとしても、A〜Jまでの再送してほしい箇所をTCPオプションヘッダ2916内のleft_edge_1(2919とright_edge_1(2920)へ逐一書き込んでから、部分的未確認応答用(NACK)のACKパケットを返信する(2711)。各再送要求箇所は、1つのNACKパケットにだけ書き込まれる。送信端末2703は、部分的未確認応答用(NACK)のACKパケット(2711)を受信すると、TCPオプションヘッダ2916に記載された再送要求箇所B、D、F、H、Jを再送する(2710)。パケット廃棄が大量に発生した時でも、一度で再送が完了するため、通信時間が短縮し(2712)、帯域が向上する。つまり、送信端末と受信端末の間に2台の通信装置を設置し、受信端末側の通信装置が送信端末側の通信装置に対して廃棄箇所を全て逐一フィードバック通知する。
図11には、左側に従来型TCPの輻輳制御方式を、右側に独自TCPの輻輳制御方式を示す。従来型TCPは、パケット廃棄が1回起きただけでも、制御帯域を大幅に減少させる(2801)。通信回線では、回線利用率が100%に到達していなくても、バッファ等において待ち行列理論から導かれる一定の確率で廃棄が生じる(2806)。このため、従来型TCPは、回線利用率が100%に到達する前に、帯域が減少してしまい(2804)、回線帯域を100%使い切ることが出来ない場合があった。一方、独自TCPは、廃棄/再送率が一定に推移していれば、待ち行列理論から導かれる一定の確率で廃棄が生じているに過ぎないと判断して帯域を増加させていく。廃棄/再送率が増加し始めたら、例えば回線帯域の使いすぎが発生したと判断して、直近の廃棄/再送帯域と、それよりも1RTT前の制御帯域とに基づいて、1RTT前の制御帯域よりも小さくなるように制御帯域を減少させる。制御帯域が回線帯域付近で上下するように制御するため、回線帯域を100%近く使い切ることができる。
なお、ここで、送信帯域とは、シェーパ3209へパケットを振り分ける振分部3208において、シェーパ毎に観測している入力帯域を指す。また、制御帯域とは、独自のTCPの規定に基づき判定したシェーパ3209から送信すべきパケットの帯域を指す。
図12に、NIF1側のTCPモジュール2501/2502ブロックに実装する独自TCPを実現するためのブロック図を示す。NIF0側のTCPモジュール1007ブロックに実装する標準TCPを実現するためのブロック図は、図4と同様のものを用いることができる。
独自TCPを実現するTCPブロック2501/2502は、標準TCPを実現する図4のTCPブロック1007をベースに、図12に示すように、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〜C(3209)とを有する。
さらに、TX部3101は、現在時刻を出力するタイマ3203と、インターバル時間を定めたインターバル格納部3204と、図8と図11の右図に示した独自TCPの送信帯域を実現するための送信帯域制御部3206と、シェーパ毎に送信帯域や再送帯域の統計情報を記録するシェーパ毎の送信・再送帯域テーブル3205と、独自TCPによる送信帯域の最大値を設定する最大送信帯域設定部3211と、送信帯域制御部3206より決まる独自TCPによるセッション毎の通信帯域(以下、制御帯域と呼ぶ)と最大送信帯域設定部3211に設定される最大帯域を遵守する様に、パケットの送信タイミングを制御するパケット送信制御部3207と、から構成される。
図14には、TCPセッション毎に使用するシェーパを定めるためのセッション・シェーパテーブル3202のフォーマットを表す。セッション・シェーパテーブル3202には、送信元IP/サブネット、宛先IP/サブネット、送信元ポート番号、および、宛先ポート番号を含むセッション情報毎に、対応するシェーパの識別情報を記載する。シェーパ判定部3201は受け取ったパケットのIPヘッダ記載のIPアドレス2907/2908、TCPヘッダ記載のポート番号2910/2911と一致するセッション情報を持つセッション・シェーパテーブル3202のエントリを探し、そのエントリに記載されたシェーパにパケットが出力されるように振り分け部3208へ指示する。
図15は、送信帯域制御部3206が制御帯域を更新する際のフローチャートを表す。処理がスタートすると(ステップ4201)、送信帯域制御部3206が、パケット再送率(=再送帯域/制御帯域)の増加率が一定値を超過したか否かを判定する(ステップ4202)。超過した場合は、現在の再送帯域と、過去の制御帯域を用いて、制御帯域を更新する(ステップ4203)。超過しなかった場合は、制御帯域を増加させる(ステップ4204)。
図16は、シェーパ毎の送信・再送帯域テーブル3205のフォーマットを示す。シェーパ毎の送信・再送帯域テーブル3205は、シェーパ毎に、旧基準時刻前の送信帯域・制御帯域と、基準時刻前の送信帯域・再送帯域・制御帯域、基準時刻と、基準時刻後の送信ビット積算値・再送ビット積算値・制御帯域とを記録する。送信ビット積算値・再送ビット積算値は、例えば、シェーパにパケットを振り分ける振分部3208が送信ビット数、再送ビット数を送信帯域制御部3206に通知し、送信帯域制御部3206がシェーパ毎の送信・再送帯域テーブル3205に書き込むことができる。
図17は、シェーパ毎の送信・再送帯域テーブル3205が保持する値の意味を説明する図である。上から下に向かって時間の経過を表す。図17の4301に示すように、基準時刻後の制御帯域は、現在時刻における制御帯域を表す(本実施例では、tokenと表す)。基準時刻後の送信帯域は、現在時刻における送信帯域を表し(本実施例では、sndと表す)、基準時刻後の送信ビット積算値をインターバルで除算することで求められる。基準時刻後の再送帯域は、現在時刻における再送帯域を表し(本実施例では、rtsと表す)、基準時刻後の再送ビット積算値をインターバルで除算することで求められる。また、図17の4302に示すように、基準時刻前の制御帯域・送信帯域・再送帯域は、基準時刻の直前まで(現在の基準時刻からインターバル時間前まで)の制御帯域・送信帯域・再送帯域を表す(本実施例では、old_token、old_snd、old_rtsと表す)。また、図17の4303に示すように、現在使用している基準時刻の一つ前に使用していた基準時刻を旧基準時刻と呼び、旧基準時刻前の制御帯域・送信帯域・再送帯域は、旧基準時刻の直前まで(旧基準時刻からさらにインターバル時間前まで。現在の基準時刻からすると2インターバル時間前)の制御帯域・送信帯域・再送帯域を表す(本実施例では、old_old_token、old_old_snd、old_old_rtsと表す)。図17の4302に示すように、基準時刻前の再送率old_rts_ratioは、old_rts/old_old_sndで求められる。また、図17の4301に示すように、基準時刻後の現在の再送率rts_ratioは、現在の再送帯域rtsと、基準時刻前の送信帯域とに基づき、rts/old_sndで求められる。
図18は、送信帯域制御部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)。ステップ3505、3506が終了すると、送信帯域(基準時刻前)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の制御帯域を更新する方法により、図11に示す直近の廃棄/再送帯域と、それよりも1RTT前の制御帯域とに基づいて、1RTT前の制御帯域よりも小さくなるように制御帯域を減少させることが可能となる。制御帯域が回線帯域付近で上下するように更新されるため、回線帯域を100%近く使い切ることができる。
送信帯域制御部3206は、前述の通り、独自TCPの送信帯域を実現するため、シェーパ毎の送信・再送帯域テーブル3205記載の制御帯域が変更されると、新たな変更済み制御帯域をパケット送信制御部3207へ通知する。パケット送信制御部3207は、通知されたシェーパ毎の制御帯域と最大送信帯域設定部3211に設定される最大送信帯域を同時に遵守する様に、トークンバケツアルゴリズムを用いて、各シェーパ3209からパケットが送信可能か否かを判定し、シェーパ3209からパケットを送信するように集約部3109へ指示する。
トークンバケツアルゴリズムでは、蓄積されるトークンの最大値が規定されたトークンバケツに、時間に比例したトークンが蓄積されていき、送信するパケット長に到達するとパケットの送信が許可される。更に、パケット送信と同時に、送信パケット長に対応するトークンが、トークンバケツから減らされる。パケット送信制御部3207は、送信帯域制御部3206から通知された制御帯域と最大送信帯域設定部3207の設定値に基づいて、トークンバケツに加算するトークンの値を決定する。
パケット送信制御部3207の詳細を図13に示す。本制御部3207は、各シェーパX3209X(X=A、B、C)の送信帯域を制御するトークンバケツ更新部X 1101X(X=A、B、C)と、シェーパXの送信帯域の総和を制御する最大帯域制御部1102と、トークンバケツ更新部X 1101Xと最大帯域制御部1102から送信される送信可否情報を受信し、何れも「送信可」である際に、集約部3109に各シェーパXよりパケット送信を指示する送信要求信号Xを送信する送信判定部1103より構成される。
トークンバケツ更新部X 1101Xは、各シェーパX3209Xより、それぞれのシェーパX 3209から最初に送信すべき、即ち、シェーパXが蓄積しているパケットであって最も過去に受信したパケットのパケット長が通知されている。この値をそれぞれIP_LENX(X=A、B、C)と記載する。このパケット長としては例えば、図2のIP length2905や、IP length2905にTCPのヘッダ長などを加算した情報を使用する。
パケット送信制御部3207の動作を図10のフローチャートを用いて説明する。シェーパAからのパケットの送信を判定するケースについて記載されているが、シェーパB、シェーパCについても同様な動作を行っている。なお、通信装置#1、通信装置#2の装置起動時に、シェーパA、B、C全ての出力帯域の総和に対応するPTokenとシェーパAの出力帯域に対応するPTokenAの値が、PTokenおよびPTokenAの最大値であるPToken_MAX、PTokenA_MAXにそれぞれ初期化され。また、シェーパAから前パケットを送信した時刻であるTAおよびシェーパA、B、Cの何れから前パケットを送信した時刻であるTが、現在時刻に初期化される。
シェーパA 3209Aにパケットが存在してIP_LENAが通知され、かつ、シェーパB、Cのステップが1002ではある場合にステップ1003に進む。次に、シェーパAからの前パケットの送信時刻TAからの経過時間にTokenAを乗算した値にPTokenAを加算した値と、PTokenA_MAXを比較し、小さな値を新たなPTokenAとする。同様に、前パケットの送信時刻Tからの経過時間にTokenを乗算した値にPTokenを加算した値と、PToken_MAXを比較し、小さな値を新たなPTokenとする(ステップ1003)。なお、ここでTokenは、最大送信帯域設定部3211に設定された値に対応する値である。次に、PTokenAとIP_LENAを比較し、PTokenA≧IP_LENAであって十分トークンが存在する場合にトークンバケツ更新部A 1101AはシェーパAの送信可能信号を送信判定部1103に送信する。さらに、最大帯域制御部1102が、PTokenとIP_LENAを比較し、PToken≧IP_LENAであってシェーパA、B、Cの共通のトークンが存在するか否かを判定する。PToken≧IP_LENAである際には、送信可能信号を送信判定部1103に送信する。次に送信判定部1103は、トークンバケツ更新部Aおよび最大帯域制御部1102が送信した送信可能信号が何れも「送信可」か否かを判定する(ステップ1104)。何れも「送信可」の場合、ステップ1105に進み、それ以外の場合にはステップ1102に戻る。ステップ1105では、送信判定部1103は集約部3109にシェーパAのセッション毎送信要求信号を送付するとともに、トークンバケツ更新部Aおよび最大帯域制御部1102に対し、送信要求信号を送付したことを通知する。本信号を受信した集約部3109はシェーパAよりパケットを読み出し、パケットを送信する(ステップ1006)。最終的にこのパケットは、フィルタ1010、NIF1 1012経由でネットワークに送信される。さらに、トークンバケツ更新部Aおよび最大帯域制御部1102は、PTokenAとPTokenより送信したパケット長であるIP_LENAを減算し、新たなPTokenAとPTokenとする(ステップ1007)。
以上に説明した様に、パケット送信制御部3207が、各シェーパXのパケットの送信可否を判定するトークンバケツ更新部Xおよび最大送信帯域設定部3211に設定されたシェーパXの送信帯域の総和の上限値に基づいて、シェーパXからパケットの送信可否を判定する最大帯域制御部1102を備え、送信判定部1103が、トークンバケツ更新部Xと最大帯域制御部1102の何れも送信可と判断した際に送信要求信号Xを集約部3109に送信することで、シェーパXの送信帯域の総和を遵守しつつ、セッション・シェーパテーブルにて指定した各セッションについて独自TCPの帯域制御を行い、パケットを送信できる。
本発明は、例えば、端末間の通信を中継する通信装置および通信システムに利用可能である。
103、104、903、904、905、906 端末
100、101、910、920、1000 通信装置
900、901、902、907 ネットワーク

Claims (7)

  1. 第一のTCP通信と第二のTCP通信の2つのTCP通信を中継する通信装置において、
    第二のTCP通信の規定に基づいて、第二のTCP通信におけるセッション毎の通信帯域を判定する送信帯域制御部と、
    第一のTCP通信により入力されたパケットを蓄積するセッション毎のバッファと、
    トークンバケツアルゴリズムを用いて、前記セッション毎の通信帯域に基づくパケットの送信可否を判定する第1判定と所定の第二のTCP通信の最大帯域に基づくパケットの送信可否を判定する第2判定とを行い、前記第1の判定及び前記第2の判定が送信可のときに前記バッファに対してパケットの送信を指示し、前記バッファに蓄積されるパケットを送信する送信制御部と、
    を有することを特徴とする通信装置。
  2. 請求項1記載の通信装置であって、
    前記送信帯域制御部がパケットの再送率の変化に基づき、前記通信帯域を判定する、
    ことを特徴とする通信装置。
  3. 請求項2記載の通信装置であって、
    外部からの入力により所定の第二のTCP通信の最大帯域の情報を保持する最大送信帯域設定部と、前記送信帯域制御部は、前記最大送信帯域設定部に保持される最大帯域の情報を参照する、
    ことを特徴とする通信装置。
  4. 請求項1乃至3のいずれか一項記載の通信装置であって、
    前記送信帯域制御部は、前記第2のTCP通信により受信するパケットに基づいて前記通信帯域を判定する、
    ことを特徴とする通信装置。
  5. 通信システムであって、計算機間の複数のTCP通信それぞれを3つのTCP通信に分割して、中継する第一の通信装置と第二の通信装置とを備え、
    前記第一の通信装置がデータ送信計算機との第一のTCP通信を実施し、前記第二の通信装置がデータ受信計算機との第二のTCP通信を実施し、前記第一の通信装置と前記第二の通信装置の間で第三のTCP通信を実施し、
    前記第一の通信装置が、トークンバケツアルゴリズムを用いて、前記第三のTCP通信の規定によるセッション毎の通信帯域に基づくパケットの送信可否を判定する第1判定と、通信開始前に予め設定された第三のTCP通信の最大帯域に基づくパケットの送信可否を判定する第2判定とを行い、前記第1の判定及び前記第2の判定が送信可のときにパケットを送信することを特徴とする通信システム。
  6. 請求項5記載の通信システムであって、
    前記第三のTCP通信の規定による通信帯域は、前記第3のTCP通信により前記第一の通信装置が受信するACKパケットに基づいて判定される通信帯域であり、
    前記第一の通信装置は、計算間の前記TCP通信毎に、通信開始前に予め設定された第三のTCP通信の最大帯域とを遵守する、
    ことを特徴とする通信システム。
  7. 計算機間の複数のTCP通信それぞれを3つのTCP通信に分割して、データ転送を中継する通信方法であって、
    第一の通信装置がデータ送信する計算機との第一のTCP通信を実施し、第二の通信装置がデータ受信する計算機との第二のTCP通信を実施し、前記第一の通信装置と前記第二の通信装置の間で第三のTCP通信を実施し、
    前記第一の通信装置が、トークンバケツアルゴリズムを用いて、前記第三のTCP通信の規定によるセッション毎の通信帯域に基づくパケットの送信可否を判定する第1判定と、通信開始前に予め設定された第三のTCP通信の最大帯域に基づくパケットの送信可否を判定する第2判定とを行い、前記第1の判定及び前記第2の判定が送信可のときにパケットを送信することを特徴とする通信方法。
JP2012038156A 2012-02-24 2012-02-24 通信装置および通信システム Expired - Fee Related JP5832335B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2012038156A JP5832335B2 (ja) 2012-02-24 2012-02-24 通信装置および通信システム
EP12869123.5A EP2819359A1 (en) 2012-02-24 2012-11-12 Communication device and communication system
PCT/JP2012/079309 WO2013125109A1 (ja) 2012-02-24 2012-11-12 通信装置および通信システム
US14/378,669 US20150029861A1 (en) 2012-02-24 2012-11-12 Communication device and communication system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012038156A JP5832335B2 (ja) 2012-02-24 2012-02-24 通信装置および通信システム

Publications (3)

Publication Number Publication Date
JP2013175850A JP2013175850A (ja) 2013-09-05
JP2013175850A5 JP2013175850A5 (ja) 2014-07-31
JP5832335B2 true JP5832335B2 (ja) 2015-12-16

Family

ID=49005309

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012038156A Expired - Fee Related JP5832335B2 (ja) 2012-02-24 2012-02-24 通信装置および通信システム

Country Status (4)

Country Link
US (1) US20150029861A1 (ja)
EP (1) EP2819359A1 (ja)
JP (1) JP5832335B2 (ja)
WO (1) WO2013125109A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5998923B2 (ja) * 2012-12-28 2016-09-28 富士通株式会社 プログラム、情報処理装置、及び通信方法
JP6495583B2 (ja) * 2014-06-19 2019-04-03 エヌ・ティ・ティ・コミュニケーションズ株式会社 音声通信端末及びコンピュータプログラム
WO2016156014A1 (en) * 2015-03-30 2016-10-06 British Telecommunications Public Limited Company Processing data items in a communications network
KR102343331B1 (ko) * 2015-07-07 2021-12-24 삼성전자주식회사 통신 시스템에서 비디오 서비스를 제공하는 방법 및 장치
CN108011834A (zh) * 2016-10-28 2018-05-08 华为技术有限公司 Tcp拥塞窗口的确定方法和装置
JP7043808B2 (ja) * 2017-11-30 2022-03-30 富士通株式会社 通信装置、通信システム、および通信速度制御方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120063493A1 (en) * 2009-03-06 2012-03-15 Yohei Hasegawa Transmission rate control method, transmission unit, and communication system
US8605745B2 (en) 2009-09-16 2013-12-10 Hitachi, Ltd. Communication apparatus and communication system for enhancing speed of communications between terminals
JP5580706B2 (ja) * 2010-09-29 2014-08-27 Kddi株式会社 再送制御プロトコルを用いるデータ転送装置、プログラム及び方法
US9118594B2 (en) * 2011-12-06 2015-08-25 Brocade Communications Systems, Inc. Lossless connection failover for single devices

Also Published As

Publication number Publication date
WO2013125109A1 (ja) 2013-08-29
US20150029861A1 (en) 2015-01-29
EP2819359A1 (en) 2014-12-31
JP2013175850A (ja) 2013-09-05

Similar Documents

Publication Publication Date Title
JP5816718B2 (ja) 通信装置、通信システム、およびデータ通信の中継方法
JP5258938B2 (ja) 通信装置
JP5651805B2 (ja) 通信装置
US8843654B2 (en) Data packet transfer over wide area network in fast and reliable manner
JP5020076B2 (ja) 低頻度ackのシステムに適した高性能tcp
JP5832335B2 (ja) 通信装置および通信システム
US8085669B2 (en) Session relay device and session relay method
US20150237173A1 (en) TCP Proxy Server
CN105376173B (zh) 一种发送窗口流量控制方法和终端
US20130250767A1 (en) Method and Device for Data Transmission
JPWO2008023656A1 (ja) 通信装置
WO2013101942A1 (en) Tcp congestion control for large latency networks
US20100226384A1 (en) Method for reliable transport in data networks
US8681617B2 (en) Communication device
CN104683259A (zh) Tcp拥塞控制方法及装置
JP4506430B2 (ja) アプリケーションモニタ装置
WO2015107806A1 (ja) 通信装置
WO2015022809A1 (ja) 通信装置及び送信帯域制御方法
KR101231793B1 (ko) Tcp 세션 최적화 방법 및 네트워크 노드
JP2006279867A (ja) Adsl通信装置、プログラム及び方法
JP6268027B2 (ja) 通信システム、送信装置、及び通信方法
KR101396785B1 (ko) 네트워크 장치에서 tcp 기능을 수행하는 방법

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140613

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140613

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20140613

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20140707

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150714

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150909

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20150929

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20151027

R150 Certificate of patent or registration of utility model

Ref document number: 5832335

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees