JP4041646B2 - Tcp通信方法 - Google Patents
Tcp通信方法 Download PDFInfo
- Publication number
- JP4041646B2 JP4041646B2 JP2000271666A JP2000271666A JP4041646B2 JP 4041646 B2 JP4041646 B2 JP 4041646B2 JP 2000271666 A JP2000271666 A JP 2000271666A JP 2000271666 A JP2000271666 A JP 2000271666A JP 4041646 B2 JP4041646 B2 JP 4041646B2
- Authority
- JP
- Japan
- Prior art keywords
- tcp
- mtu
- communication
- communication board
- ack
- 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
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Communication Control (AREA)
Description
【発明の属する技術分野】
本発明はTCP通信を高速化する技術に関する。
【0002】
【従来の技術】
通常のイーサネットでは、IPの最大パケット長(Maximum Transfer Unit size:以下、MTUサイズと呼ぶ)は1500バイトであり、TCPの最大ユーザデータ長(Maximum Segment Siz: 以下、MSSと呼ぶ)はMTUサイズからIP及びTCPのヘッダ領域を除いた1460バイトである。
【0003】
このように通常のイーサネットでは、TCPの最大ユーザデータ長MSSが小さいために、パケット単位で行われるTCPやIPのプロトコル処理、並びに、ホスト端末と通信ボード間のデータ転送処理がホスト端末に対して大きなオーバヘッドとなり、この処理オーバヘッドがTCP通信の高速化を妨げている。
【0004】
これらの処理オーバヘッドを減らすためには、より大きなMSSを用いることが望まれる。
【0005】
一方、近年、ギガビットイーサネット(Giga bits Ethernet:以下、GbEと呼ぶ)の普及に伴い、ホスト端末においてもギガビットクラスの広い帯域を利用可能になっている。しかし、GbEで標準的に用いられているMTUサイズは通常のイーサネットと同じ1500バイトであるため、現状のホスト端末ではやはり、パケット単位で行われるプロトコル処理、並びに、ホスト端末と通信ボード間のデータ転送処理が大きなオーバヘッドとなる。
【0006】
その解決策として、フレーム長を独自に長く拡張したイーサネットフレーム(以下、ジャンボフレームと呼ぶ)を用いてMTUサイズを拡大する方法が提案されている(例えば、MTUサイズ:8800バイト、MSS:8760バイト)。しかし、この方法には下記に示す問題点がある。
(1) 原則として、サブネットを構成するホスト端末、並びに、スイッチやルータ等のネットワーク機器全てが、ジャンボフレームをサポートする必要がある。このため、ジャンボフレームをサポートしない既存のホスト端末とは同一のサブネットを構成できない。
(2) 通信経路上の、広域網を含む全てのリンクにおけるMTUサイズ(以下、パスMTUサイズと呼ぶ)が例えば8800バイト以上と大きい必要がある。そうでない場合は、ルータでのIPパケットの分割(IPフラグメンテーション) や、ホスト端末でのパスMTUサイズに応じたパケットサイズの調整(最大セグメントサイズの交換、パスMTUディスカバリー(path MTU discovery))が起きるため、大きなサイズのパケットで通信することは不可能である。
【0007】
【発明が解決しようとする課題】
本発明の課題は、パスMTUサイズよりも大きなMTUサイズをホスト端末に提供することができるTCP通信方法を提供することである。
【0009】
【課題を解決するための手段】
請求項1に係る発明は上記課題を解決するTCP通信方法であり、端末本体に搭載される通信ボード上のCPU(オンボードCPU)を利用してTCPレベルでパケットの分割及び組立を行う際、前記端末本体のTCPモジュールから送信された1つのデータセグメントを前記通信ボード上で適切なTCP/IPヘッダを持つ複数のデータセグメントに分割してネットワークへ出力し、前記ネットワークから入力された複数のデータセグメントを前記通信ボード上で1つのデータセグメントに組み立てた後、前記TCPモジュールに通知すると共に、分割前のデータセグメントに対するACKパケットの増加、並びに、組立前のデータセグメントに対するACKパケットの減少を前記通信ボード上で調整し、これらACKパケットの増減がTCPの輻輳制御や再送処理等の制御手順へ及ぼす影響を防ぐことを特徴とするTCP通信方法である。請求項2に係る発明は、請求項1において、送受信シーケンス番号及びACK番号をTCPコネクション毎に保持するコネクションテーブルを前記通信ボード上に用意し、前記コネクションテーブルを参照して前記ACKパケットの増減を調整することを特徴とするTCP通信方法である。
【0010】
請求項3に係る発明は、請求項1において、通信経路上のネットワークを含む全てのリンクにおけるMTUサイズ(以下、パスMTUと呼ぶ)と、ネットワークに対するMTUサイズ(以下、ネットMTUと呼ぶ)を比較し、パスMTU≧ネットMTUである場合はネットMTUに基づいて前記データセグメントの分割を行い、パスMTU<ネットMTUである場合はパスMTUに基づいて前記データセグメントの分割を行うことを特徴とするTCP通信方法である。請求項4に係る発明は、請求項3において、宛先IPアドレス毎にパスMTU情報を参照して、前記パスMTUに基づくデータセグメントの分割を行うことを特徴とするTCP通信方法である。
【0011】
請求項5に係る発明は、請求項1において、UDPのようにメッセージ境界を保つ必要があるプロトコルのパケットに対してはIPレベルでパケットの分割及び組立を行うことを特徴とするTCP通信方法である。
【0012】
請求項6に係る発明は上記課題を解決する他のTCP通信方法であり、TCPを処理するTCPモジュール及びIPを処理するIPモジュールを有する端末本体と、CPU及びメモリを有し、ネットワーク及び前記ホストに接続される通信ボードと、該通信ボードのCPU(オンボードCPU)上で動作するファームウェアと、前記端末本体が有するCPU(ホストCPU)で動作する、前記通信ボード用のデバイスドライバとによりTCP通信を行うこと、前記ファームウェアは、TCPコネクションの確立を監視し、該TCPコネクションの確立手順を利用することより、前記端末本体が前記ネットワーク上のパケットサイズよりも大きなパケットサイズを利用することを可能にする第1機能と、前記通信ボードへ前記端末本体から分割されてDMA転送されたTCPセグメントに適切なTCPヘッダを付加し、前記通信ボードから前記ネットワークへ転送する第2機能と、前記ネットワークから前記通信ボードが受信したパケットをTCPコネクション毎にまとめて1つのパケットとして前記端末本体へ通知する第3機能を提供すること、前記デバイスドライバは、前記端末本体から前記通信ボードへ渡されるべきパケットを、メモリコピーを行うことなく、前記通信ボードでのTCPヘッダの付加を考慮して分割し、通信ボードの前記メモリにDMA転送する機能を提供することを特徴とする。請求項7に係る発明は、請求項6において、前記ファームウェアは、前記第1、第2及び第3機能により生じる前記端末本体から前記通信ボードへのACKパケットの減少、並びに、前記ネットワークから前記通信ボードへのACKパケットの増加を防ぐ第4機能を提供することを特徴とするTCP通信方法である。
【0013】
【発明の実施の形態】
図面を参照して、本発明の実施形態例に係るTCP通信方法を説明する。
【0014】
[発明の基本]
本方法では、通信ボード上のCPU(オンボードCPU)を利用してパケットの分割及び組立を行うことにより、ネットワークに対しては標準のイーサネットと同じMTUサイズを使用しつつ、端末本体のTCPやIP等のプロトコルモジュールにおいて大きなパケットの利用を可能とする。このため、通信ボード用のデバイスドライバでは、端末本体のIPモジュールに対して、ネットワークに対するMTUサイズ(以下、ネットMTUと呼ぶ)とは独立した、大きなMTUサイズ(以下、ホストMTUと呼ぶ)を提供する。
【0015】
TCPでは、コネクション確立時に交換するMSSを越えるセグメントを送信してはならない。一方、MSSの値はMTUサイズに依存するため、大きなMTUサイズを持たない既存の端末では、大きなセグメントを使用することが不可能である。そこで、既存端末とのTCP通信においても、本方法を適用できるように、パケット分割・組立をIPではなくTCPレベルで行う。即ち、端末本体のTCPモジュールから送信された1つのDT(データセグメント)を、通信ボード上で、それぞれ適切なTCP/IPヘッダを持つ複数のDTに分割してネットワークへ出力する。また、ネットワークから入力された複数のDTを、通信ボード上で1つのDTに組み立てた上で、端末本体のTCPモジュールへ通知する。一方、UDP(ユーザデータグラムプロトコル)のようなメッセージ境界を保つ必要があるプロトコルに対しては、通信ボード上でIPレベルのパケット分割・組立(IPフラグメンテーションとリアセンブリ)を行う高速化を図る。
【0016】
上記の処理により、TCP通信においては、端末本体のTCPモジュールで処理される1つのDTは、ネットワーク上で転送される複数のDTに対応することになる。このため、既存の端末との通信を想定した場合、分割前のDTに対するACK(確認応答)の数はは多くなり、逆に、組立前のDTに対するACKの数は少なくなることが予想される。一方、TCPのslow start(スロータート)手順やcongestion avoidance(コンジェスチョンアボイダンス)手順、あるいは、fast recovery (ファーストリカバリ)手順において参照される輻輳ウインドウ(cwnd)はACK受信により更新される。また、fast retransmit(ファーストリトランスミット)手順では受信したACKを調べてパケット紛失を検出する。これらのため、通信ボード上でACKの数並びにその内容を調整し、これらの制御手順への影響を抑える。
【0017】
ACK調整を行うために、通信ボード上で個々のTCPコネクション毎に、送受信シーケンス番号やACK番号を登録し参照する。そこで、これらの情報(TCPコネクション毎の送受信シーケンス番号やACK番号)を保持するためのコネクションテーブルを通信ボード上に用意する。また、パスMTU<ネットMTUである場合は、パケット分割は、ネットMTUではなくパスMTUに基づいて行う。このため、パスMTU<ネットMTUである場合は、宛先IPアドレス毎にパスMTU情報を参照できるようにする。
【0018】
端末の収容先としては、基本的には1500バイトのMTUサイズを持つ標準のイーサネットセグメントを想定しているが、これより大きなMTUサイズを持つイーサネットセグメントへ収容した場合も動作可能である。
【0019】
[全体構成]
図1に本例に係るTCP通信方法の全体構成を示す。図1において、1は通信ボード、2はデバイスドライバ、3はTCP/IPモジュールである。通信ボード1はオンボードCPUを有する市販のPCIバス用GbEボード(例えば、Alteon Websystems ACEnic(アルテオン・ウェブシステムズ社のエースニック)) には用い、本発明実現のため、GbEボードのオンボードCPU(図示省略)上で動作する高速データ通信ソフトウェア(ファームウェア)を改修してある。また、GbEボードに搭載されたPCI/GbEコントロール用ASIC中には、2 つのRISC−CPU(MIPS R4000 相当)が組み込まれており、端末本体(図示省略)からダウンロードされたファームウェアによって、送信パケットと受信パケットに対して付加的な処理を行うことができるようにしてある。デバイスドライバ2は端末本体と通信ボード1との間のデータ転送を制御するための通信ボード1用デバイスドライバであり、端末本体が有するCPU(ホストCPU:図示省略)で動作する。デバイスドライバ2には、本発明実現のため、GbEボード用デバイスドライバを改修して用いている。TCP/IPモジュール3はTCPを処理するTCPモジュール及びIPを処理するIPモジュールであり、端末本体に備えられている。その他、端末本体はメモリ等を備え、ジャンボフレームをサポートしている。端末本体にはUNIXコンピュータを用いている。
【0020】
ファームウェアはデバイスドライバ2と協調してTCPレベルのパケット分割・組立機能を提供し、TCPを用いた通信に対して効率的なホストバスインターフェースを提供する。デバイスドライバ2は端末本体のOS(例えばUNIX)のカーネルの一部として実装され、カーネル内に予め用意されているIP等のプロトコルモジュールと協調して動作する。また、端末本体は、ファームウェア並びにデバイスドライバ2に実装した機能に対する各種パラメータの設定並びに統計情報の取得を行うための制御用ソフトウェアを有する。これはユーザプロセスである。
【0021】
[ファームウェアとデバイスドライバ]
上記の機能を実現するため、通信ボードのファームウェア並びに端末本体のデバイスドライバ2では、以下の処理(1) 〜(5) を行う。
【0022】
(1) デバイスドライバ2からIPモジュールに対し、1500バイト以上のMTUサイズを通知する。通知するMTUサイズは制御プログラムにより可能とし、例えば最大で36000バイトとする。デフォルト値は8800バイトとする。このMTUサイズはホストMTUである。
【0023】
(2) ファームウェアでは、TCPコネクションの確立を監視して、必要に応じて、対応するTCPコネクションテーブルを作成する。このテーブルの最大数はデフォルトで16とするが、コンパイルオプションにより変更可能としている。TCPレベルのパケット分割・組立機能は、このTCPコネクションテーブルが作成されているコネクションに対してのみ適用する。
【0024】
(3) TCPではコネクション確立時に交換するSYNパケット並びにSYN+ACKパケットを用いてMSSを互いに交換するため、ファームウェアで必要に応じてこれを書き換え、TCPモジュールに大きなMSSを通知する。
【0025】
(4) 上位プロトコルモジュールから渡されたパケットを、送信側ファームウェアにより、制御用ソフトウェアにより指定されたMTUサイズでネットワークに出力できるようにする。このMTUサイズはボードMTUである。このために、付加するヘッダを含む送信パケットを連続したオンボードメモリ(通信ボード1)上に置く。そこで、デバイスドライバ2において以下の手順(a)、(b)を用いることにより、デバイスドライバ2自身並びに通信ボード1上において不要なデータコピーを行うことなく、分割した各パケットに対して通信ボード1上で容易にヘッダを付加できるようにする。
(a)デバイスドライバ2では、分割する各パケット毎にDMA(Direct Memory Access)転送要求を設定する。この際、先頭パケット以外は、DMA転送を開始するアドレスをヘッダ領域分、前にずらす( 図1の(a)参照) 。パケット本体のコピーは行わない。
(b)ファームウェアでは、先頭パケットのヘッダ情報を基に各パケットのヘッダを作成し、各パケットの先頭部分を上書きして送信する(図1の(b)参照)。
【0026】
(5) 受信側のファームウェアでは、ネットワークから受信したパケットをできる限り大きなパケットサイズでデバイスドライバに通知するために、以下に示す方針(a)〜(e)に従って組み立てる。
(a)受信したフレームがTCPセグメントであり、且つ、対応するコネクションテーブルが存在する場合は、原則として、端末本体に対して受信通知のための割り込みをかけず、端末本体へのDMA転送のみ行い、次のフレームの受信を待つ。
(b)次の受信フレームが、受信済み(但し、端末本体には未通知)のTCPセグメントに連続するTCPセグメントである場合は、受信フレームからTCP/IPヘッダ等を取り除いて、1つのTCPセグメントに結合されるようにDMA転送する。結合されたTCPセグメントに対するTCP/IPヘッダの書き換えも同時に行う。
(c)セグメント紛失等により連続するTCPセグメントを受信しなかった場合や、上記の結合処理によってホストMTUを超えたTCPセグメントとなる場合等、パケット組立が不可能である場合は、これ以前に受信した未通知のフレームのみを端末本体へ通知する。以降は、セグメント紛失から回復するまで、該当するコネクションに属するセグメントの組立は行わない。
(d)セグメント紛失を検出した場合(rx_next!=rex_max)は、シーケンス番号(SEQ番号)を持つセグメントのグループrx_gleとrx_max)を保持する。このグループが受信ホストから送達確認(ACK.no≧rx_max−rex)されるか、このグループまでのセグメントを再度、紛失なく連続して受信した場合に、セグメント紛失が回復したと見なす。
(e)一定の待ち時間(deliver_timeout)経過後は、受信したフレームを端末本体へ通知する。
【0027】
[TCP−ACK補償機能]
TCPレベルのパケット分割を行うことにより、TCPモジュールから渡された1つのTCPセグメントに対して、複数のACKパケットが返ることが予想される。このため、下記の問題(1) 〜(2) が予想される。
(1) ACK処理負荷が削減されない。
(2) スロースタート(slow start)時の輻輳ウインドウの急増など、TCP輻輳制御との不整合が発生する。
【0028】
一方、パケット組立を行う端末のTCPモジュールでは、大きなパケットサイズでプロトコル処理を行うため、十分にACKパケットを送信できない可能性があり、これによりTCPの輻輳制御や再送制御に悪影響を与える恐れがあると言う問題がある。
【0029】
これらの問題を解決するために、以下の要領(a)〜(b)により端末本体に通知するTCP−ACK(ユーザデータを含まない) を削減し、また、ネットワーク側へ送出するTCP−ACKを増加させることとする。
【0030】
(a)TCP−ACKの削減(送信側)
(i) TCPコネクションテーブルにACK番号、並びに、送信TCPセグメントのSEQ番号を記録する。記録するSEQ番号は必要に応じて上書きする。
(ii)保持しているTCPセグメントのSEQ番号を送達確認する場合、または、2×ホスト側MSS−ボード側MSS(2*h_mss−n_mss)を超えるTCPパケットを新規に送達確認する場合、または、最もSEQ番号の大きい送信済みパケットをACKする場合(ACK.no==snd_max)に、ACKを端末本体に通知する。
(iii) DUPACK(重複ACK:ACK.noとACK.win(ウインドウサイズ)が前回と同じACK)では、ホスト側MSS/ボード側MSSで与えられる個数のDUPACK受信毎に端末本体へ通知する。
【0031】
(b)TCP−ACKの増加(受信側)
(i) TCPセグメントが連続して2セグメント受信した場合は、通信ボード1でACKを作成し送信する。但し、原則として、3セグメント目を受信後に2セグメント分のACKをする。
(ii)3セグメント目が受信されない場合は、deliver_timer発火後、端末本体への通知と同時にack_timerを起動させる。ack_timer発火までに端末本体からのACK受信もしくはネットワークからのDT受信がなければ、ACKを作成し送信る。
(iii) パケット紛失時は、前述のようにDT受信毎にそのままホストに通知させ、適切にDUPACKを発生させる。
【0032】
従って、TCP通信に対する動作手順は以下のように定まる。
【0033】
[動作手順その1:コネクション確立とパスMTU設定]
図2にTCPコネクション確立に伴う処理フローを示す。TCPでは、コネクション確立時に相手から通知されたMSSと自分のMSSとを比較し、いずれあ小さい方のMSSを使用する。このため、通信ボード1とそのデバイスドライバ2では、コネクション確立時に以下の処理(1) 〜(2) を行い、端末本体のTCPモジュールで使用するMSSを大きく保つと同時に、相手端末に対しては、ネットMTU(netMTU)またはパスMTU(pathMTU)に基づくMSSを通知する。更に、必要であればパケット分割に用いるパスMTUの設定も行う。
【0034】
(1) 図2において、TCPモジュールからのSYN(+ACK)を受信した場合(ステップS1)、それに含まれるMSS(図2のSYN(+ACK).MSS)を、同じIPアドレス宛のパスMTUがあればこれに基づくMSSに、無い場合はネットMTUに基づくMSSに更新し、相手端末に送信する(ステップS2、S5)。受信がSYNであれば、同時にコネクションテーブルも作成する(ステップS3、S4)。
【0035】
(2) ネットワークからのSYN(+ACK)を受信した場合(ステップS6)、それに含まれるMSS(図2のSYN(+ACK).MSS)と、同じIPアドレス宛のパスMTUがあればこれに基づくMSS(図2のnmss)と、無い場合はネットMTUに基づくMSS(図2のnmss)と比較する(ステップS7、S8)。前者が小さい場合は、nmssの更新、並びに、パスMTUの登録あるいは更新を行う(ステップS9)。次に、ホストMTUに基づくMSSを超えないようにnmssを整数倍した値を、SYN(+ACK)のMSSとしてTCPジュールに通知する(ステップS10、S13)。また、受信がSYNであれば、コネクションテーブルを作成する(ステップS11、S12)。
【0036】
図3にコネクション確立時の通信シーケンス例を示す。ここでは、双方の端末で、ホストMTUを9000バイト程度として、ネットMTUに1500または9000バイトを使用した4種類の組み合わせa〜dに対するシーケンスを示している。
【0037】
図3より、いずれの組み合わせの場合も、ネットワーク側のMSSは小さい方のネットMTUに基づく適切な値(a〜cでは1460バイト、dでは8960バイト)が設定され、端末側のMSSもネットワーク側のMSSの整数倍(a〜cでは8760バイト、dでは8960バイト)となるように調整されていることが判る。なお、dでは、双方の端末のネットMTUが9000バイトであるため、端末間に9000バイトより小さいMTUサイズを持つ経路が存在しなければ、パケット分割は行われない。
【0038】
一方、a〜dの全ての場合で、より小さいパスMTUが通信経路中に存在する可能性もある。これは、データ転送中にICMPunreachable が返送されることで検出できる。通信ボード1ではICMPunreachable に含まれる新しいパスMTUの登録。更新を行い、分割に用いるパケットサイズを調整する。
【0039】
[動作手順その2:データ転送時の手順]
図4に、本方法をサポートする端末間におけるデータ転送開始直後の通信シーケンスを示す。以下、図4に沿ってデータ転送時の動作手順(1) 〜(5) を説明する。
【0040】
(1) 送信側のTCP並びにIPモジュールは、動作手順その1んいより提供される大きなMSS(8760バイト:以降、ホストMSSと呼ぶ)並びにMTUサイズを利用してプロトコル処理を行い、DT送信を通信ボード1に要求する(図4中、(a)参照)。
【0041】
(2) 送信側の通信ボード1では、DTを動作手順その1により決定したMSS(1460バイト:以降、ネットMSSと呼ぶ)に適合するように分割し、各々に適切なTCP/IPヘッダを付加した上で送信する(図4中、(b)参照)。
【0042】
(3) 受信側の通信ボード1では、DTが正しく連続受信されている間は、原則としてネットワークから受信したDTを即座にTCPモジュールへは通知せず、可能な限り大きなDTに組み立てる。DT通知は以下のどちらかの条件(a)(b)を満たした時点で行う。
(a)DTの長さ>ホストMTU−ネットMTU(図4中、(c)参照)。
(b)先頭DTの受信後一定時間が経過(図4中、(d)参照)。
【0043】
(4) 一般的なTCPの実装では、2つのDTを正しく受信する毎に、対応するACK番号を持つACKを1つ返す。DT送信側が本方法をサポートしていない場合も同様の間隔でACKが返るように、以下の要領(a)(b)に従い受信側の通信ボード1でACKを補填する。この際、TCPモジュールからのACKと重複することを避けるようにしている。
(a)新たに2つのDTを送達確認可能である場合、次のDT受信時にACKを送信する(図4中、(e)参照)。但し、2つのDT毎にACKを返すために、最後に受信したDTはACKの対象に含めない。
(b)上記(3) によるDT通知時点で、新たに2つのDTをACKできる場合はACKタイマを設定する(図4中、(f)〜(h)参照)。このタイマは次のDTの受信(図4中、(f)参照)、もしくは、TCPモジュールからのACK応答(図4中、(g)参照)によりキャンセルされる。タイマが満了した場合は、通信ボード1からACKを送信する(図4中、(h)参照)。
【0044】
また、TCPモジュールからのACKについては、最後に送信したACKよりも新しい情報(ACK番号、winsize)を含んでいれば送信側に転送する。この際、通信ボード1でより進んだACK番号を既に送信側に通知している場合は、これに合わせてACK番号とウインサイズ(winsize) を決定する(図4中、(i)参照)。
【0045】
(5) 一方、DT送信側の通信ボード1には上記(4) により2つのDT送信毎に1つのACKが戻る。TCPモジュールにおいても、cwndを適切に更新するために、分割前の2つのDTに対して1つのACKが通知されることが望ましい。また、silly window syndrome (シリーウインドウシンドローム)を避けるためには、ホストMSS以上の受信ウインドウを通知すべきである。逆に、Nagle algorithm(ナグルアルゴリズム) 、keep alive(キープアライブ)、window probe(ウインドウプローブ)等の手順では、受信したACKを必ず通知すべきである。そこで通信ボード1では、下記(a)(b)(c)いずれかの処理は見込まれる場合のみ、ACKを通知する。
(a)ホストMTUの2倍−ネットMTU以上のDTを送信確認する(図4中、(j)参照)。
(b)干す炉MTU以上の受信ウインドウが付与される(図4中、(k)参照)。
(c)送達確認待ちのDTがなくなるか、既にない(図4中、(l)参照)。
なお、ACk番号またはwinsize のいずれかに、TCPモジュールにまだ通知すべきでない小さな更新がある場合は、これらを調整した上で通知する(図4中、(k)参照)。
【0046】
[動作手順その3:誤り回復時の手順]
図5に、DT紛失に伴う再送手順を含む通信シーケンス例を示す。紛失DTに回復手順は、双方の端末のTCPによりエンド・エンドで提供される。以下、図5に従って、TCPの誤り回復手順を考慮した方法の動作手順(1) 〜(6) を説明する。
【0047】
(1) DT(29201:30661) の紛失を検出すると、通信ボード1は既に受信組立済みのDT(26281:29201) を即座にTCPモジュールへ通知する(図5中、(a)参照)。以降、通信ボード1では、TCPモジュールの誤り回復手順の完了を確認するまで、受信したDTの組立は行わない(図5中、(b)参照)。
【0048】
(2) 受信側通信ボード1では、TCPモジュールにおける誤り回復手順の完了を検出するために、DT紛失の検出後、最大のシーケンス番号を持つ連続した受信済みDTのグループをリスト [rx_gle,rx_max]形式で保存する。
【0049】
図5の例では、DT紛失を検出した直後の受信済みDTグループは[30661,32121] であり、再送DTの受信直前は[30661,43801] となる。通信ボード1はrx_gle までの紛失DTを受信することで、紛失部分がなくなり、rx_max まで連続して受信した状態となる。TCPモジュールから、rx_max まで送達確認するACKが返されれば、TCPモジュールの誤り回復手順が完了したと見なす。また、rx_max までの全てのDTが再度連続して受信された場合も同様である。
【0050】
(3) TCPモジュールから、紛失DTの送信を要求するACK(a29201,w37961) が渡されると、通信ボード1はこれを送信側に転送する。以降も、DT通知毎に返送されるduplicate ACKについては、そのまま送信側に転送する。(図5中、(c)参照)。
【0051】
(4) 送信側の通信ボード1において検出したduplicate ACK(a29291,w62615) は、fast retransmit の開始前後で以下(a)(b)のように処理を変える。
(a)fast retransmit を素早く開始させるために、TCPモジュールに同一のACKを既に通知済みか同化検査し、通知済みであれば1つのACKを、そうでなければ2つのACKをTCPモジュールに通知する。更に、2つのduplicate ACKいついては、受信次第TCPモジュールに通知する(図5中、(e)参照)。
(b)その後は、fast recovery 手順でのcwndの急激な増加を避けるために、ホストMTU/ネットMTU(比の値)個に1つの割合で、duplicate ACKが通知されるようにする。但し、fast retransmit 開始のために先に通知した4つのACKを考慮して、次の(5番目)のACK通知だけは、前のACKから数えてホストMTUの4倍/ネットMTU(比の値)−3なる個数のduplicate ACKを受信した時点で行う。
【0052】
(5) TCPモジュールは、duplicate ACKを受信すると、DT(29201:37961) を再送する。通信ボード1れは、これをネットMSSに基づき分割し、先頭のDT(29201:30661) だけを送信する(図5中、(f)参照)。
【0053】
(6) 受信側の通信ボード1では、再送DT(29201:30661) の受信により、紛失部分がなくなり受信済みDTグループ[30661,43801] まで連続して受信した状態となる。そこで通信ボード1では、rx_max =43801 をrx_max_rec に記録し、再送DTをTCPモジュールに通知する。そして、TCPモジュールから返送されるACK(a43801,w35040) により、誤り回復の完了を確認する。これにより、以降の受信DT(45261:46721−51101:52561 は組立可能となる(図5中、(g)参照)。一方、ACKが戻る前に受信したDT(43801:45261) は、誤り回復完了を検出する前であるため、受信後すぐにTCPモジュールへ通知されている(図5中、(h)参照)。本DTはrx_max_rec に連続するため、ACK(a43801,w35050) が戻った時点で、TCPモジュールにより正常に連続受信されることが保証される。
【0054】
[動作手順その4:コネクション終了時の手順]
図6に、コネクション終了時の通信シーケンス例を示す。本方法では、コネクション終了に伴う状態遷移を簡素化するために、TCPモジュールからのコネクション終了要求(FIN)並びにその送達確認のみを監視する。TCPモジュールからのFINが送達確認された時点で、そのコネクションに対しては、通信ボード1に新たなパケット送信要求か来ないことが保証されるため、該当するコネクションテーブルを削除することができる。以下、図6を例に、コネクション終了時の手順(1) 〜(3) を説明する。
【0055】
(1) 通信ボード1では、TCPモジュールからFINフラグを有効にしたDTを渡されると、これがネットMSS以上のユーザデータを含むDTである場合あ、これを通信ボード1で分割する。その際、FINフラグは分割後の最後のDTのみ有効にする(図6中、(a)参照)。
【0056】
(2) 一方、ネットワークから受信したFINセグメントについては、通信ボード1上で、通常のDTと同様、可能であれば前のDTに連結する。そして、直ぐに、TCPモジュールへ通知する(図6中、(b)参照)。
【0057】
(3) ネットワークからFINに対するACKを受信すると、通信ボード1はこれをTCPモジュールへ通知し、コネクションテーブルを削除する(図6中、(c)参照)。以降は、通信ボード1はTCP通信に介在せず、受信データをそのままTCPモジュールへ通知する(図6中、(d)参照)。
【0058】
上述のように、通信ボード1のオンボードCPUを利用して、TCPまで考慮したパケット分割と組立を行うことにより、端末に大きなMTUサイズを提供するから、例えば標準のイーサネットと同じMTUサイズ(1500バイト)をネットワーク上で用いることができる。つまり、ネットワークでは広く使用されている小さなパケットサイズを用いつつ、ホスト内では大きなパケットサイズで効率良くTCPのプロトコル処理を行うことができる。このため、本方法をサポートする端末のプロトコルモジュールでは、大きなMTUサイズをサポートしない既存の端末やネットワーク機器と接続した場合でも、大きなパケットで処理を行うことが可能となる。
【0059】
また、パケットの分割・組立により、端末本体のTCPモジュールにおける1つのデータセグメント(DT)が、ネットワーク上における複数のデータセグメント(DT)に対応するので、本方法をサポートする端末が既存端末と通信した場合は、双方の端末が送受信するACK(確認応答)の数が変動するので、TCPの輻輳制御や再送処理に影響が現れる可能性があるが、ACK数の増減を調整することによりこの影響を抑制することができる。
【0060】
つまり、TCPレベルのパケット分解・組立を行うと、通信ボード1が端末本体ホストから受信するACKパケットが、通信ボード1が通信相手へ送信すべきACKパケットよりも減少し、反対に、通信ボード1が端末本体へ通知すべきACKパケットよりも、通信ボード1が通信相手から受信するACKパケットが増加する。このようなACKパケット数の不一致はTCP輻輳制御機能等に副作用を与えるが、ACKパケット増減を補償することにより、TCP輻輳制御機能等に与える副作用を防ぐことができる。
【0061】
更に、TCP以外のパケット、例えばUDPパケットについては、通信ボード1上でIPフラグメンテーション(IP分割)並びにそのデフラグメンテーション(IP組立)を行うことにより、送信端末トや受信端末トにおけるプロトコル処理の負荷が削減可能である。
【0062】
また、端末本体と通信ボード1間でのTCPレベルのパケット分解・組立には、メモリコピーを行わず、DMA転送を行うことにより処理時間を短縮することができる。
【0063】
互いに通信する端末間の一方が上述の機能をサポートすることにより、他方の端末及びネットワーク機器がジャンボフレームをサポートしない場合でも、相互接続性を保証することができる。
【0064】
また、上述の機能を双方の端末がともにサポートしていれば、ネットワーク機器がジャンボフレームをサポートしない場合でも、全てジャンボフレームを適用した場合と同様に、各端末上でTCP、IP、デバイスドライバ等の処理オーバヘッドを削減することが可能である。
【0065】
【発明の効果】
本発明によれば、ネットワークで広く用いられている例えば1500バイト程度の小さなパケットサイズを変更することなく、端末において大きなパケットサイズによる効率的なTCP通信が可能となる。また、パケットの分解・組立に伴うACKパケットの増大・不足を補償することで、TCP輻輳制御等との不整合を防止することができ、ネットワークに対して従来と同様の輻輳制御等を提供することが可能となる。このような効果を持つ本発明は、FPGA等の(プログラマブル)ロジックによる実装を通じた通信装置への適用等が可能である。
【図面の簡単な説明】
【図1】本発明の実施形態例に係るTCP通信方法の全体構成を示す図。
【図2】コネクション確立時の処理フローを示す図。
【図3】コネクション確立時の通信シーケンス例を示す図。
【図4】データ転送時の通信シーケンス例を示す図。
【図5】再送時の通信シーケンス例を示す図。
【図6】コネクション終了時の通信シーケンス例を示す図。
【符号の説明】
1 通信ボード
2 デバイスドライバ
3 TCP/IPモジュール
Claims (7)
- 端末本体に搭載される通信ボード上のCPU(以下、オンボードCPUと呼ぶ)を利用してTCPレベルでパケットの分割及び組立を行うことによりTCP通信を高速化するTCP通信方法において、
前記端末本体のTCPモジュールから送信された1つのデータセグメントを前記通信ボード上で適切なTCP/IPヘッダを持つ複数のデータセグメントに分割してネットワークへ出力し、前記ネットワークから入力された複数のデータセグメントを前記通信ボード上で1つのデータセグメントに組み立てた後、前記TCPモジュールに通知すると共に、
分割前のデータセグメントに対するACKパケットの増加、並びに、組立前のデータセグメントに対するACKパケットの減少を前記通信ボード上で調整し、これらACKパケットの増減がTCPの輻輳制御や再送処理等の制御手順へ及ぼす影響を防ぐことを特徴とするTCP通信方法。 - 請求項1において、
送受信シーケンス番号及びACK番号をTCPコネクション毎に保持するコネクションテーブルを前記通信ボード上に用意し、前記コネクションテーブルを参照して前記ACKパケットの増減を調整することを特徴とするTCP通信方法。 - 請求項1において、
通信経路上のネットワークを含む全てのリンクにおけるMTUサイズ(以下、パスMTUと呼ぶ)と、ネットワークに対するMTUサイズ(以下、ネットMTUと呼ぶ)を比較し、パスMTU≧ネットMTUである場合はネットMTUに基づいて前記データセグメントの分割を行い、パスMTU<ネットMTUである場合はパスMTUに基づいて前記データセグメントの分割を行うことを特徴とするTCP通信方法。 - 請求項3において、
宛先IPアドレス毎にパスMTU情報を参照して、前記パスMTUに基づくデータセグメントの分割を行うことを特徴とするTCP通信方法。 - 請求項1において、
UDPのようにメッセージ境界を保つ必要があるプロトコルのパケットに対してはIPレベルでパケットの分割及び組立を行うことを特徴とするTCP通信方法。 - TCPを処理するTCPモジュール及びIPを処理するIPモジュールを有する端末本体と、CPU及びメモリを有し、ネットワーク及び前記ホストに接続される通信ボードと、該通信ボードの前記CPU(オンボードCPU)上で動作するファームウェアと、前記端末本体が有するCPU(以下、ホストCPUと呼ぶ)で動作する、前記通信ボード用のデバイスドライバとによりTCP通信を行うこと、前記ファームウェアは、TCPコネクションの確立を監視し、該TCPコネクションの確立手順を利用することより、前記端末本体が前記ネットワーク上のパケットサイズよりも大きなパケットサイズを利用することを可能にする第1機能と、前記通信ボードへ前記端末本体から分割されてDMA転送されたTCPセグメントに適切なTCPヘッダを付加し、前記通信ボードから前記ネットワークへ転送する第2機能と、前記ネットワークから前記通信ボードが受信したパケットをTCPコネクション毎にまとめて1つのパケットとして前記端末本体へ通知する第3機能を提供すること、前記デバイスドライバは、前記端末本体から前記通信ボードへ渡されるべきパケットを、メモリコピーを行うことなく、前記通信ボードでのTCPヘッダの付加を考慮して分割し、通信ボードの前記メモリにDMA転送する機能を提供することを特徴とするTCP通信方法。
- 請求項6において、
前記ファームウェアは、前記第1、第2及び第3機能により生じる前記端末本体から前記通信ボードへのACKパケットの減少、並びに、前記ネットワークから前記通信ボードへのACKパケットの増加を防ぐ第4機能を提供することを特徴とするTCP通信方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000271666A JP4041646B2 (ja) | 2000-09-07 | 2000-09-07 | Tcp通信方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000271666A JP4041646B2 (ja) | 2000-09-07 | 2000-09-07 | Tcp通信方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2002084289A JP2002084289A (ja) | 2002-03-22 |
JP4041646B2 true JP4041646B2 (ja) | 2008-01-30 |
Family
ID=18757917
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000271666A Expired - Fee Related JP4041646B2 (ja) | 2000-09-07 | 2000-09-07 | Tcp通信方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4041646B2 (ja) |
Families Citing this family (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2004068803A1 (ja) * | 2003-01-27 | 2004-08-12 | Fujitsu Limited | パス設定方法及びそれを用いた伝送装置及び監視制御装置及びそのプログラムを記録した記録媒体 |
US7978716B2 (en) | 2003-11-24 | 2011-07-12 | Citrix Systems, Inc. | Systems and methods for providing a VPN solution |
DE602005007014D1 (de) | 2004-05-18 | 2008-07-03 | Koninkl Philips Electronics Nv | Integrierte schaltung und verfahren zur pufferung zur optimierung der burst-länge in netzwerken auf chips |
US7757074B2 (en) | 2004-06-30 | 2010-07-13 | Citrix Application Networking, Llc | System and method for establishing a virtual private network |
US8739274B2 (en) | 2004-06-30 | 2014-05-27 | Citrix Systems, Inc. | Method and device for performing integrated caching in a data communication network |
US8495305B2 (en) | 2004-06-30 | 2013-07-23 | Citrix Systems, Inc. | Method and device for performing caching of dynamically generated objects in a data communication network |
AU2005266943C1 (en) | 2004-07-23 | 2011-01-06 | Citrix Systems, Inc. | Systems and methods for optimizing communications between network nodes |
AU2005266945A1 (en) | 2004-07-23 | 2006-02-02 | Citrix Systems, Inc. | A method and systems for securing remote access to private networks |
US8954595B2 (en) | 2004-12-30 | 2015-02-10 | Citrix Systems, Inc. | Systems and methods for providing client-side accelerated access to remote applications via TCP buffering |
US8549149B2 (en) | 2004-12-30 | 2013-10-01 | Citrix Systems, Inc. | Systems and methods for providing client-side accelerated access to remote applications via TCP multiplexing |
US8706877B2 (en) | 2004-12-30 | 2014-04-22 | Citrix Systems, Inc. | Systems and methods for providing client-side dynamic redirection to bypass an intermediary |
US8700695B2 (en) | 2004-12-30 | 2014-04-15 | Citrix Systems, Inc. | Systems and methods for providing client-side accelerated access to remote applications via TCP pooling |
US7810089B2 (en) | 2004-12-30 | 2010-10-05 | Citrix Systems, Inc. | Systems and methods for automatic installation and execution of a client-side acceleration program |
US8255456B2 (en) | 2005-12-30 | 2012-08-28 | Citrix Systems, Inc. | System and method for performing flash caching of dynamically generated objects in a data communication network |
US7561573B2 (en) | 2005-03-23 | 2009-07-14 | Fujitsu Limited | Network adaptor, communication system and communication method |
JP2006295819A (ja) * | 2005-04-14 | 2006-10-26 | Sony Corp | データ送信装置、データ送信方法及びデータ送信プログラム |
US8301839B2 (en) | 2005-12-30 | 2012-10-30 | Citrix Systems, Inc. | System and method for performing granular invalidation of cached dynamically generated objects in a data communication network |
US7921184B2 (en) | 2005-12-30 | 2011-04-05 | Citrix Systems, Inc. | System and method for performing flash crowd caching of dynamically generated objects in a data communication network |
JP2008028767A (ja) * | 2006-07-21 | 2008-02-07 | Sumitomo Electric Networks Inc | ネットワークカードおよび情報処理装置 |
JP5106359B2 (ja) * | 2008-11-21 | 2012-12-26 | 株式会社富士通アドバンストエンジニアリング | コンピュータプログラム、データ捕捉装置、データ捕捉方法及びデータ管理システム |
JP5517951B2 (ja) * | 2008-12-25 | 2014-06-11 | パナソニック株式会社 | Tcp送信制御装置及びtcp送信制御方法 |
JP2011249922A (ja) * | 2010-05-24 | 2011-12-08 | Nec Access Technica Ltd | ネットワーク装置、tcpパケット受信装置及び方法 |
CN115622944B (zh) * | 2022-10-09 | 2024-07-23 | 上海华讯网络***有限公司 | 基于多并行度下数据流的tcp拼包方法和*** |
-
2000
- 2000-09-07 JP JP2000271666A patent/JP4041646B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2002084289A (ja) | 2002-03-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4041646B2 (ja) | Tcp通信方法 | |
US7042907B2 (en) | Packet transfer apparatus and method | |
US8064461B2 (en) | Method and apparatus for TCIP/IP data transfer over a wireless network | |
US7483376B2 (en) | Method and apparatus for discovering path maximum transmission unit (PMTU) | |
JP4248550B2 (ja) | マルチtcp確認応答を用いたtcp輻輳制御システム及びその方法 | |
JP4921569B2 (ja) | オフロードユニットを使用したtcp接続のためのデータ処理 | |
JP3604615B2 (ja) | 通信装置、中継装置および通信制御方法 | |
US11477130B2 (en) | Transmission control method and apparatus | |
EP1359724B1 (en) | Method to offload a network stack | |
KR100988339B1 (ko) | 무선 인터페이스를 통해 tcp 성능을 개선시키기 위한 이중 프록시 접근 방식 | |
US7443845B2 (en) | Apparatus and method for a lightweight, reliable, packet-based transport protocol | |
US20030131079A1 (en) | Performance enhancing proxy techniques for internet protocol traffic | |
US20100322249A1 (en) | Discovering path maximum transmission unit size | |
US8085669B2 (en) | Session relay device and session relay method | |
US20100226384A1 (en) | Method for reliable transport in data networks | |
EP1295428A2 (en) | Performance enhancement of transmission control protocol (tcp) for wireless network applications | |
US20070291782A1 (en) | Acknowledgement filtering | |
JP5832335B2 (ja) | 通信装置および通信システム | |
JP4244159B2 (ja) | 受信装置、通信システムおよびプログラム | |
US7623546B1 (en) | Latency improvement for file transfers over network connections | |
JP2002344559A (ja) | プロトコル変換装置とそのプロトコル変換方法、及びプロトコル変換プログラム | |
JP4434019B2 (ja) | データ配信管理装置およびデータ配信管理方法 | |
WO2018137218A1 (zh) | 一种数据传输方法、数据接收设备及数据发送设备 | |
WO2019196853A1 (zh) | Tcp加速方法及装置 | |
US9628397B2 (en) | Communication device and related packet processing method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050830 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070803 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070814 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071015 |
|
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: 20071106 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071112 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101116 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111116 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121116 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131116 Year of fee payment: 6 |
|
LAPS | Cancellation because of no payment of annual fees |