JP4041646B2 - Ｔｃｐ通信方法 - Google Patents
Ｔｃｐ通信方法 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
- Small-Scale Networks (AREA)
- Communication Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はＴＣＰ通信を高速化する技術に関する。
【０００２】
【従来の技術】
通常のイーサネットでは、ＩＰの最大パケット長(Maximum Transfer Unit size:以下、ＭＴＵサイズと呼ぶ）は１５００バイトであり、ＴＣＰの最大ユーザデータ長(Maximum Segment Siz: 以下、ＭＳＳと呼ぶ）はＭＴＵサイズからＩＰ及びＴＣＰのヘッダ領域を除いた１４６０バイトである。
【０００３】
このように通常のイーサネットでは、ＴＣＰの最大ユーザデータ長ＭＳＳが小さいために、パケット単位で行われるＴＣＰやＩＰのプロトコル処理、並びに、ホスト端末と通信ボード間のデータ転送処理がホスト端末に対して大きなオーバヘッドとなり、この処理オーバヘッドがＴＣＰ通信の高速化を妨げている。
【０００４】
これらの処理オーバヘッドを減らすためには、より大きなＭＳＳを用いることが望まれる。
【０００５】
一方、近年、ギガビットイーサネット（Giga bits Ethernet：以下、ＧｂＥと呼ぶ）の普及に伴い、ホスト端末においてもギガビットクラスの広い帯域を利用可能になっている。しかし、ＧｂＥで標準的に用いられているＭＴＵサイズは通常のイーサネットと同じ１５００バイトであるため、現状のホスト端末ではやはり、パケット単位で行われるプロトコル処理、並びに、ホスト端末と通信ボード間のデータ転送処理が大きなオーバヘッドとなる。
【０００６】
その解決策として、フレーム長を独自に長く拡張したイーサネットフレーム（以下、ジャンボフレームと呼ぶ）を用いてＭＴＵサイズを拡大する方法が提案されている（例えば、ＭＴＵサイズ：８８００バイト、ＭＳＳ：８７６０バイト）。しかし、この方法には下記に示す問題点がある。
(1) 原則として、サブネットを構成するホスト端末、並びに、スイッチやルータ等のネットワーク機器全てが、ジャンボフレームをサポートする必要がある。このため、ジャンボフレームをサポートしない既存のホスト端末とは同一のサブネットを構成できない。
(2) 通信経路上の、広域網を含む全てのリンクにおけるＭＴＵサイズ（以下、パスＭＴＵサイズと呼ぶ）が例えば８８００バイト以上と大きい必要がある。そうでない場合は、ルータでのＩＰパケットの分割（ＩＰフラグメンテーション) や、ホスト端末でのパスＭＴＵサイズに応じたパケットサイズの調整（最大セグメントサイズの交換、パスＭＴＵディスカバリー(path MTU discovery)）が起きるため、大きなサイズのパケットで通信することは不可能である。
【０００７】
【発明が解決しようとする課題】
本発明の課題は、パスＭＴＵサイズよりも大きなＭＴＵサイズをホスト端末に提供することができるＴＣＰ通信方法を提供することである。
【０００９】
【課題を解決するための手段】
請求項１に係る発明は上記課題を解決するＴＣＰ通信方法であり、端末本体に搭載される通信ボード上のＣＰＵ（オンボードＣＰＵ）を利用してＴＣＰレベルでパケットの分割及び組立を行う際、前記端末本体のＴＣＰモジュールから送信された１つのデータセグメントを前記通信ボード上で適切なＴＣＰ／ＩＰヘッダを持つ複数のデータセグメントに分割してネットワークへ出力し、前記ネットワークから入力された複数のデータセグメントを前記通信ボード上で１つのデータセグメントに組み立てた後、前記ＴＣＰモジュールに通知すると共に、分割前のデータセグメントに対するＡＣＫパケットの増加、並びに、組立前のデータセグメントに対するＡＣＫパケットの減少を前記通信ボード上で調整し、これらＡＣＫパケットの増減がＴＣＰの輻輳制御や再送処理等の制御手順へ及ぼす影響を防ぐことを特徴とするＴＣＰ通信方法である。請求項２に係る発明は、請求項１において、送受信シーケンス番号及びＡＣＫ番号をＴＣＰコネクション毎に保持するコネクションテーブルを前記通信ボード上に用意し、前記コネクションテーブルを参照して前記ＡＣＫパケットの増減を調整することを特徴とするＴＣＰ通信方法である。
【００１０】
請求項３に係る発明は、請求項１において、通信経路上のネットワークを含む全てのリンクにおけるＭＴＵサイズ（以下、パスＭＴＵと呼ぶ）と、ネットワークに対するＭＴＵサイズ（以下、ネットＭＴＵと呼ぶ）を比較し、パスＭＴＵ≧ネットＭＴＵである場合はネットＭＴＵに基づいて前記データセグメントの分割を行い、パスＭＴＵ＜ネットＭＴＵである場合はパスＭＴＵに基づいて前記データセグメントの分割を行うことを特徴とするＴＣＰ通信方法である。請求項４に係る発明は、請求項３において、宛先ＩＰアドレス毎にパスＭＴＵ情報を参照して、前記パスＭＴＵに基づくデータセグメントの分割を行うことを特徴とするＴＣＰ通信方法である。
【００１１】
請求項５に係る発明は、請求項１において、ＵＤＰのようにメッセージ境界を保つ必要があるプロトコルのパケットに対してはＩＰレベルでパケットの分割及び組立を行うことを特徴とするＴＣＰ通信方法である。
【００１２】
請求項６に係る発明は上記課題を解決する他のＴＣＰ通信方法であり、ＴＣＰを処理するＴＣＰモジュール及びＩＰを処理するＩＰモジュールを有する端末本体と、ＣＰＵ及びメモリを有し、ネットワーク及び前記ホストに接続される通信ボードと、該通信ボードのＣＰＵ（オンボードＣＰＵ）上で動作するファームウェアと、前記端末本体が有するＣＰＵ（ホストＣＰＵ）で動作する、前記通信ボード用のデバイスドライバとによりＴＣＰ通信を行うこと、前記ファームウェアは、ＴＣＰコネクションの確立を監視し、該ＴＣＰコネクションの確立手順を利用することより、前記端末本体が前記ネットワーク上のパケットサイズよりも大きなパケットサイズを利用することを可能にする第１機能と、前記通信ボードへ前記端末本体から分割されてＤＭＡ転送されたＴＣＰセグメントに適切なＴＣＰヘッダを付加し、前記通信ボードから前記ネットワークへ転送する第２機能と、前記ネットワークから前記通信ボードが受信したパケットをＴＣＰコネクション毎にまとめて１つのパケットとして前記端末本体へ通知する第３機能を提供すること、前記デバイスドライバは、前記端末本体から前記通信ボードへ渡されるべきパケットを、メモリコピーを行うことなく、前記通信ボードでのＴＣＰヘッダの付加を考慮して分割し、通信ボードの前記メモリにＤＭＡ転送する機能を提供することを特徴とする。請求項７に係る発明は、請求項６において、前記ファームウェアは、前記第１、第２及び第３機能により生じる前記端末本体から前記通信ボードへのＡＣＫパケットの減少、並びに、前記ネットワークから前記通信ボードへのＡＣＫパケットの増加を防ぐ第４機能を提供することを特徴とするＴＣＰ通信方法である。
【００１３】
【発明の実施の形態】
図面を参照して、本発明の実施形態例に係るＴＣＰ通信方法を説明する。
【００１４】
［発明の基本］
本方法では、通信ボード上のＣＰＵ（オンボードＣＰＵ）を利用してパケットの分割及び組立を行うことにより、ネットワークに対しては標準のイーサネットと同じＭＴＵサイズを使用しつつ、端末本体のＴＣＰやＩＰ等のプロトコルモジュールにおいて大きなパケットの利用を可能とする。このため、通信ボード用のデバイスドライバでは、端末本体のＩＰモジュールに対して、ネットワークに対するＭＴＵサイズ（以下、ネットＭＴＵと呼ぶ）とは独立した、大きなＭＴＵサイズ（以下、ホストＭＴＵと呼ぶ）を提供する。
【００１５】
ＴＣＰでは、コネクション確立時に交換するＭＳＳを越えるセグメントを送信してはならない。一方、ＭＳＳの値はＭＴＵサイズに依存するため、大きなＭＴＵサイズを持たない既存の端末では、大きなセグメントを使用することが不可能である。そこで、既存端末とのＴＣＰ通信においても、本方法を適用できるように、パケット分割・組立をＩＰではなくＴＣＰレベルで行う。即ち、端末本体のＴＣＰモジュールから送信された１つのＤＴ（データセグメント）を、通信ボード上で、それぞれ適切なＴＣＰ／ＩＰヘッダを持つ複数のＤＴに分割してネットワークへ出力する。また、ネットワークから入力された複数のＤＴを、通信ボード上で１つのＤＴに組み立てた上で、端末本体のＴＣＰモジュールへ通知する。一方、ＵＤＰ（ユーザデータグラムプロトコル）のようなメッセージ境界を保つ必要があるプロトコルに対しては、通信ボード上でＩＰレベルのパケット分割・組立（ＩＰフラグメンテーションとリアセンブリ）を行う高速化を図る。
【００１６】
上記の処理により、ＴＣＰ通信においては、端末本体のＴＣＰモジュールで処理される１つのＤＴは、ネットワーク上で転送される複数のＤＴに対応することになる。このため、既存の端末との通信を想定した場合、分割前のＤＴに対するＡＣＫ（確認応答）の数はは多くなり、逆に、組立前のＤＴに対するＡＣＫの数は少なくなることが予想される。一方、ＴＣＰのslow start（スロータート）手順やcongestion avoidance（コンジェスチョンアボイダンス）手順、あるいは、fast recovery （ファーストリカバリ）手順において参照される輻輳ウインドウ(cwnd)はＡＣＫ受信により更新される。また、fast retransmit（ファーストリトランスミット）手順では受信したＡＣＫを調べてパケット紛失を検出する。これらのため、通信ボード上でＡＣＫの数並びにその内容を調整し、これらの制御手順への影響を抑える。
【００１７】
ＡＣＫ調整を行うために、通信ボード上で個々のＴＣＰコネクション毎に、送受信シーケンス番号やＡＣＫ番号を登録し参照する。そこで、これらの情報（ＴＣＰコネクション毎の送受信シーケンス番号やＡＣＫ番号）を保持するためのコネクションテーブルを通信ボード上に用意する。また、パスＭＴＵ＜ネットＭＴＵである場合は、パケット分割は、ネットＭＴＵではなくパスＭＴＵに基づいて行う。このため、パスＭＴＵ＜ネットＭＴＵである場合は、宛先ＩＰアドレス毎にパスＭＴＵ情報を参照できるようにする。
【００１８】
端末の収容先としては、基本的には１５００バイトのＭＴＵサイズを持つ標準のイーサネットセグメントを想定しているが、これより大きなＭＴＵサイズを持つイーサネットセグメントへ収容した場合も動作可能である。
【００１９】
［全体構成］
図１に本例に係るＴＣＰ通信方法の全体構成を示す。図１において、１は通信ボード、２はデバイスドライバ、３はＴＣＰ／ＩＰモジュールである。通信ボード１はオンボードＣＰＵを有する市販のＰＣＩバス用ＧｂＥボード（例えば、Alteon Websystems ACEnic（アルテオン・ウェブシステムズ社のエースニック）) には用い、本発明実現のため、ＧｂＥボードのオンボードＣＰＵ（図示省略）上で動作する高速データ通信ソフトウェア（ファームウェア）を改修してある。また、ＧｂＥボードに搭載されたＰＣＩ／ＧｂＥコントロール用ＡＳＩＣ中には、2 つのＲＩＳＣ−ＣＰＵ(MIPS R4000 相当）が組み込まれており、端末本体（図示省略）からダウンロードされたファームウェアによって、送信パケットと受信パケットに対して付加的な処理を行うことができるようにしてある。デバイスドライバ２は端末本体と通信ボード１との間のデータ転送を制御するための通信ボード１用デバイスドライバであり、端末本体が有するＣＰＵ（ホストＣＰＵ：図示省略）で動作する。デバイスドライバ２には、本発明実現のため、ＧｂＥボード用デバイスドライバを改修して用いている。ＴＣＰ／ＩＰモジュール３はＴＣＰを処理するＴＣＰモジュール及びＩＰを処理するＩＰモジュールであり、端末本体に備えられている。その他、端末本体はメモリ等を備え、ジャンボフレームをサポートしている。端末本体にはＵＮＩＸコンピュータを用いている。
【００２０】
ファームウェアはデバイスドライバ２と協調してＴＣＰレベルのパケット分割・組立機能を提供し、ＴＣＰを用いた通信に対して効率的なホストバスインターフェースを提供する。デバイスドライバ２は端末本体のＯＳ（例えばＵＮＩＸ）のカーネルの一部として実装され、カーネル内に予め用意されているＩＰ等のプロトコルモジュールと協調して動作する。また、端末本体は、ファームウェア並びにデバイスドライバ２に実装した機能に対する各種パラメータの設定並びに統計情報の取得を行うための制御用ソフトウェアを有する。これはユーザプロセスである。
【００２１】
［ファームウェアとデバイスドライバ］
上記の機能を実現するため、通信ボードのファームウェア並びに端末本体のデバイスドライバ２では、以下の処理(1) 〜(5) を行う。
【００２２】
(1) デバイスドライバ２からＩＰモジュールに対し、１５００バイト以上のＭＴＵサイズを通知する。通知するＭＴＵサイズは制御プログラムにより可能とし、例えば最大で３６０００バイトとする。デフォルト値は８８００バイトとする。このＭＴＵサイズはホストＭＴＵである。
【００２３】
(2) ファームウェアでは、ＴＣＰコネクションの確立を監視して、必要に応じて、対応するＴＣＰコネクションテーブルを作成する。このテーブルの最大数はデフォルトで１６とするが、コンパイルオプションにより変更可能としている。ＴＣＰレベルのパケット分割・組立機能は、このＴＣＰコネクションテーブルが作成されているコネクションに対してのみ適用する。
【００２４】
(3) ＴＣＰではコネクション確立時に交換するＳＹＮパケット並びにＳＹＮ＋ＡＣＫパケットを用いてＭＳＳを互いに交換するため、ファームウェアで必要に応じてこれを書き換え、ＴＣＰモジュールに大きなＭＳＳを通知する。
【００２５】
(4) 上位プロトコルモジュールから渡されたパケットを、送信側ファームウェアにより、制御用ソフトウェアにより指定されたＭＴＵサイズでネットワークに出力できるようにする。このＭＴＵサイズはボードＭＴＵである。このために、付加するヘッダを含む送信パケットを連続したオンボードメモリ（通信ボード１）上に置く。そこで、デバイスドライバ２において以下の手順（ａ）、（ｂ）を用いることにより、デバイスドライバ２自身並びに通信ボード１上において不要なデータコピーを行うことなく、分割した各パケットに対して通信ボード１上で容易にヘッダを付加できるようにする。
（ａ）デバイスドライバ２では、分割する各パケット毎にＤＭＡ(Direct Memory Access)転送要求を設定する。この際、先頭パケット以外は、ＤＭＡ転送を開始するアドレスをヘッダ領域分、前にずらす( 図１の（ａ）参照) 。パケット本体のコピーは行わない。
（ｂ）ファームウェアでは、先頭パケットのヘッダ情報を基に各パケットのヘッダを作成し、各パケットの先頭部分を上書きして送信する（図１の（ｂ）参照）。
【００２６】
(5) 受信側のファームウェアでは、ネットワークから受信したパケットをできる限り大きなパケットサイズでデバイスドライバに通知するために、以下に示す方針（ａ）〜（ｅ）に従って組み立てる。
（ａ）受信したフレームがＴＣＰセグメントであり、且つ、対応するコネクションテーブルが存在する場合は、原則として、端末本体に対して受信通知のための割り込みをかけず、端末本体へのＤＭＡ転送のみ行い、次のフレームの受信を待つ。
（ｂ）次の受信フレームが、受信済み（但し、端末本体には未通知）のＴＣＰセグメントに連続するＴＣＰセグメントである場合は、受信フレームからＴＣＰ／ＩＰヘッダ等を取り除いて、１つのＴＣＰセグメントに結合されるようにＤＭＡ転送する。結合されたＴＣＰセグメントに対するＴＣＰ／ＩＰヘッダの書き換えも同時に行う。
（ｃ）セグメント紛失等により連続するＴＣＰセグメントを受信しなかった場合や、上記の結合処理によってホストＭＴＵを超えたＴＣＰセグメントとなる場合等、パケット組立が不可能である場合は、これ以前に受信した未通知のフレームのみを端末本体へ通知する。以降は、セグメント紛失から回復するまで、該当するコネクションに属するセグメントの組立は行わない。
（ｄ）セグメント紛失を検出した場合（ｒｘ＿ｎｅｘｔ！＝ｒｅｘ＿ｍａｘ）は、シーケンス番号（ＳＥＱ番号）を持つセグメントのグループｒｘ＿ｇｌｅとｒｘ＿ｍａｘ）を保持する。このグループが受信ホストから送達確認（ＡＣＫ．ｎｏ≧ｒｘ＿ｍａｘ−ｒｅｘ）されるか、このグループまでのセグメントを再度、紛失なく連続して受信した場合に、セグメント紛失が回復したと見なす。
（ｅ）一定の待ち時間（ｄｅｌｉｖｅｒ＿ｔｉｍｅｏｕｔ）経過後は、受信したフレームを端末本体へ通知する。
【００２７】
［ＴＣＰ−ＡＣＫ補償機能］
ＴＣＰレベルのパケット分割を行うことにより、ＴＣＰモジュールから渡された１つのＴＣＰセグメントに対して、複数のＡＣＫパケットが返ることが予想される。このため、下記の問題(1) 〜(2) が予想される。
(1) ＡＣＫ処理負荷が削減されない。
(2) スロースタート(slow start)時の輻輳ウインドウの急増など、ＴＣＰ輻輳制御との不整合が発生する。
【００２８】
一方、パケット組立を行う端末のＴＣＰモジュールでは、大きなパケットサイズでプロトコル処理を行うため、十分にＡＣＫパケットを送信できない可能性があり、これによりＴＣＰの輻輳制御や再送制御に悪影響を与える恐れがあると言う問題がある。
【００２９】
これらの問題を解決するために、以下の要領（ａ）〜（ｂ）により端末本体に通知するＴＣＰ−ＡＣＫ（ユーザデータを含まない) を削減し、また、ネットワーク側へ送出するＴＣＰ−ＡＣＫを増加させることとする。
【００３０】
（ａ）ＴＣＰ−ＡＣＫの削減（送信側)
(i) ＴＣＰコネクションテーブルにＡＣＫ番号、並びに、送信ＴＣＰセグメントのＳＥＱ番号を記録する。記録するＳＥＱ番号は必要に応じて上書きする。
(ii)保持しているＴＣＰセグメントのＳＥＱ番号を送達確認する場合、または、２×ホスト側ＭＳＳ−ボード側ＭＳＳ（２＊ｈ＿ｍｓｓ−ｎ＿ｍｓｓ）を超えるＴＣＰパケットを新規に送達確認する場合、または、最もＳＥＱ番号の大きい送信済みパケットをＡＣＫする場合（ＡＣＫ．ｎｏ＝＝ｓｎｄ＿ｍａｘ）に、ＡＣＫを端末本体に通知する。
(iii) ＤＵＰＡＣＫ（重複ＡＣＫ：ＡＣＫ．ｎｏとＡＣＫ．ｗｉｎ（ウインドウサイズ）が前回と同じＡＣＫ）では、ホスト側ＭＳＳ／ボード側ＭＳＳで与えられる個数のＤＵＰＡＣＫ受信毎に端末本体へ通知する。
【００３１】
（ｂ）ＴＣＰ−ＡＣＫの増加（受信側）
(i) ＴＣＰセグメントが連続して２セグメント受信した場合は、通信ボード１でＡＣＫを作成し送信する。但し、原則として、３セグメント目を受信後に２セグメント分のＡＣＫをする。
(ii)３セグメント目が受信されない場合は、ｄｅｌｉｖｅｒ＿ｔｉｍｅｒ発火後、端末本体への通知と同時にａｃｋ＿ｔｉｍｅｒを起動させる。ａｃｋ＿ｔｉｍｅｒ発火までに端末本体からのＡＣＫ受信もしくはネットワークからのＤＴ受信がなければ、ＡＣＫを作成し送信る。
(iii) パケット紛失時は、前述のようにＤＴ受信毎にそのままホストに通知させ、適切にＤＵＰＡＣＫを発生させる。
【００３２】
従って、ＴＣＰ通信に対する動作手順は以下のように定まる。
【００３３】
［動作手順その１：コネクション確立とパスＭＴＵ設定］
図２にＴＣＰコネクション確立に伴う処理フローを示す。ＴＣＰでは、コネクション確立時に相手から通知されたＭＳＳと自分のＭＳＳとを比較し、いずれあ小さい方のＭＳＳを使用する。このため、通信ボード１とそのデバイスドライバ２では、コネクション確立時に以下の処理(1) 〜(2) を行い、端末本体のＴＣＰモジュールで使用するＭＳＳを大きく保つと同時に、相手端末に対しては、ネットＭＴＵ(netＭＴＵ）またはパスＭＴＵ（pathＭＴＵ）に基づくＭＳＳを通知する。更に、必要であればパケット分割に用いるパスＭＴＵの設定も行う。
【００３４】
(1) 図２において、ＴＣＰモジュールからのＳＹＮ（＋ＡＣＫ）を受信した場合（ステップＳ１）、それに含まれるＭＳＳ（図２のＳＹＮ（＋ＡＣＫ）．ＭＳＳ）を、同じＩＰアドレス宛のパスＭＴＵがあればこれに基づくＭＳＳに、無い場合はネットＭＴＵに基づくＭＳＳに更新し、相手端末に送信する（ステップＳ２、Ｓ５）。受信がＳＹＮであれば、同時にコネクションテーブルも作成する（ステップＳ３、Ｓ４）。
【００３５】
(2) ネットワークからのＳＹＮ（＋ＡＣＫ）を受信した場合（ステップＳ６）、それに含まれるＭＳＳ（図２のＳＹＮ（＋ＡＣＫ）．ＭＳＳ）と、同じＩＰアドレス宛のパスＭＴＵがあればこれに基づくＭＳＳ（図２のnmss）と、無い場合はネットＭＴＵに基づくＭＳＳ（図２のnmss）と比較する（ステップＳ７、Ｓ８）。前者が小さい場合は、nmssの更新、並びに、パスＭＴＵの登録あるいは更新を行う（ステップＳ９）。次に、ホストＭＴＵに基づくＭＳＳを超えないようにnmssを整数倍した値を、ＳＹＮ（＋ＡＣＫ）のＭＳＳとしてＴＣＰジュールに通知する（ステップＳ１０、Ｓ１３）。また、受信がＳＹＮであれば、コネクションテーブルを作成する（ステップＳ１１、Ｓ１２）。
【００３６】
図３にコネクション確立時の通信シーケンス例を示す。ここでは、双方の端末で、ホストＭＴＵを９０００バイト程度として、ネットＭＴＵに１５００または９０００バイトを使用した４種類の組み合わせａ〜ｄに対するシーケンスを示している。
【００３７】
図３より、いずれの組み合わせの場合も、ネットワーク側のＭＳＳは小さい方のネットＭＴＵに基づく適切な値（ａ〜ｃでは１４６０バイト、ｄでは８９６０バイト）が設定され、端末側のＭＳＳもネットワーク側のＭＳＳの整数倍（ａ〜ｃでは８７６０バイト、ｄでは８９６０バイト）となるように調整されていることが判る。なお、ｄでは、双方の端末のネットＭＴＵが９０００バイトであるため、端末間に９０００バイトより小さいＭＴＵサイズを持つ経路が存在しなければ、パケット分割は行われない。
【００３８】
一方、ａ〜ｄの全ての場合で、より小さいパスＭＴＵが通信経路中に存在する可能性もある。これは、データ転送中にＩＣＭＰunreachable が返送されることで検出できる。通信ボード１ではＩＣＭＰunreachable に含まれる新しいパスＭＴＵの登録。更新を行い、分割に用いるパケットサイズを調整する。
【００３９】
［動作手順その２：データ転送時の手順］
図４に、本方法をサポートする端末間におけるデータ転送開始直後の通信シーケンスを示す。以下、図４に沿ってデータ転送時の動作手順(1) 〜(5) を説明する。
【００４０】
(1) 送信側のＴＣＰ並びにＩＰモジュールは、動作手順その１んいより提供される大きなＭＳＳ（８７６０バイト：以降、ホストＭＳＳと呼ぶ）並びにＭＴＵサイズを利用してプロトコル処理を行い、ＤＴ送信を通信ボード１に要求する（図４中、（ａ）参照）。
【００４１】
(2) 送信側の通信ボード１では、ＤＴを動作手順その１により決定したＭＳＳ（１４６０バイト：以降、ネットＭＳＳと呼ぶ）に適合するように分割し、各々に適切なＴＣＰ／ＩＰヘッダを付加した上で送信する（図４中、（ｂ）参照）。
【００４２】
(3) 受信側の通信ボード１では、ＤＴが正しく連続受信されている間は、原則としてネットワークから受信したＤＴを即座にＴＣＰモジュールへは通知せず、可能な限り大きなＤＴに組み立てる。ＤＴ通知は以下のどちらかの条件（ａ）（ｂ）を満たした時点で行う。
（ａ）ＤＴの長さ＞ホストＭＴＵ−ネットＭＴＵ（図４中、（ｃ）参照）。
（ｂ）先頭ＤＴの受信後一定時間が経過（図４中、（ｄ）参照）。
【００４３】
(4) 一般的なＴＣＰの実装では、２つのＤＴを正しく受信する毎に、対応するＡＣＫ番号を持つＡＣＫを１つ返す。ＤＴ送信側が本方法をサポートしていない場合も同様の間隔でＡＣＫが返るように、以下の要領（ａ）（ｂ）に従い受信側の通信ボード１でＡＣＫを補填する。この際、ＴＣＰモジュールからのＡＣＫと重複することを避けるようにしている。
（ａ）新たに２つのＤＴを送達確認可能である場合、次のＤＴ受信時にＡＣＫを送信する（図４中、（ｅ）参照）。但し、２つのＤＴ毎にＡＣＫを返すために、最後に受信したＤＴはＡＣＫの対象に含めない。
（ｂ）上記(3) によるＤＴ通知時点で、新たに２つのＤＴをＡＣＫできる場合はＡＣＫタイマを設定する（図４中、（ｆ）〜（ｈ）参照）。このタイマは次のＤＴの受信（図４中、（ｆ）参照）、もしくは、ＴＣＰモジュールからのＡＣＫ応答（図４中、（ｇ）参照）によりキャンセルされる。タイマが満了した場合は、通信ボード１からＡＣＫを送信する（図４中、（ｈ）参照）。
【００４４】
また、ＴＣＰモジュールからのＡＣＫについては、最後に送信したＡＣＫよりも新しい情報（ＡＣＫ番号、winsize)を含んでいれば送信側に転送する。この際、通信ボード１でより進んだＡＣＫ番号を既に送信側に通知している場合は、これに合わせてＡＣＫ番号とウインサイズ(winsize) を決定する（図４中、（ｉ）参照）。
【００４５】
(5) 一方、ＤＴ送信側の通信ボード１には上記(4) により２つのＤＴ送信毎に１つのＡＣＫが戻る。ＴＣＰモジュールにおいても、cwndを適切に更新するために、分割前の２つのＤＴに対して１つのＡＣＫが通知されることが望ましい。また、silly window syndrome （シリーウインドウシンドローム）を避けるためには、ホストＭＳＳ以上の受信ウインドウを通知すべきである。逆に、Nagle algorithm(ナグルアルゴリズム) 、keep alive（キープアライブ）、window probe（ウインドウプローブ）等の手順では、受信したＡＣＫを必ず通知すべきである。そこで通信ボード１では、下記（ａ）（ｂ）（ｃ）いずれかの処理は見込まれる場合のみ、ＡＣＫを通知する。
（ａ）ホストＭＴＵの２倍−ネットＭＴＵ以上のＤＴを送信確認する（図４中、（ｊ）参照）。
（ｂ）干す炉ＭＴＵ以上の受信ウインドウが付与される（図４中、（ｋ）参照）。
（ｃ）送達確認待ちのＤＴがなくなるか、既にない（図４中、（ｌ）参照）。
なお、ＡＣｋ番号またはwinsize のいずれかに、ＴＣＰモジュールにまだ通知すべきでない小さな更新がある場合は、これらを調整した上で通知する（図４中、（ｋ）参照）。
【００４６】
［動作手順その３：誤り回復時の手順］
図５に、ＤＴ紛失に伴う再送手順を含む通信シーケンス例を示す。紛失ＤＴに回復手順は、双方の端末のＴＣＰによりエンド・エンドで提供される。以下、図５に従って、ＴＣＰの誤り回復手順を考慮した方法の動作手順(1) 〜(6) を説明する。
【００４７】
(1) ＤＴ(29201:30661) の紛失を検出すると、通信ボード１は既に受信組立済みのＤＴ(26281:29201) を即座にＴＣＰモジュールへ通知する（図５中、（ａ）参照）。以降、通信ボード１では、ＴＣＰモジュールの誤り回復手順の完了を確認するまで、受信したＤＴの組立は行わない（図５中、（ｂ）参照）。
【００４８】
(2) 受信側通信ボード１では、ＴＣＰモジュールにおける誤り回復手順の完了を検出するために、ＤＴ紛失の検出後、最大のシーケンス番号を持つ連続した受信済みＤＴのグループをリスト [rx＿gle,rx＿max]形式で保存する。
【００４９】
図５の例では、ＤＴ紛失を検出した直後の受信済みＤＴグループは[30661,32121] であり、再送ＤＴの受信直前は[30661,43801] となる。通信ボード１はrx＿gle までの紛失ＤＴを受信することで、紛失部分がなくなり、rx＿max まで連続して受信した状態となる。ＴＣＰモジュールから、rx＿max まで送達確認するＡＣＫが返されれば、ＴＣＰモジュールの誤り回復手順が完了したと見なす。また、rx＿max までの全てのＤＴが再度連続して受信された場合も同様である。
【００５０】
(3) ＴＣＰモジュールから、紛失ＤＴの送信を要求するＡＣＫ(a29201,w37961) が渡されると、通信ボード１はこれを送信側に転送する。以降も、ＤＴ通知毎に返送されるduplicate ＡＣＫについては、そのまま送信側に転送する。（図５中、（ｃ）参照）。
【００５１】
(4) 送信側の通信ボード１において検出したduplicate ＡＣＫ(a29291,w62615) は、fast retransmit の開始前後で以下（ａ）（ｂ）のように処理を変える。
（ａ）fast retransmit を素早く開始させるために、ＴＣＰモジュールに同一のＡＣＫを既に通知済みか同化検査し、通知済みであれば１つのＡＣＫを、そうでなければ２つのＡＣＫをＴＣＰモジュールに通知する。更に、２つのduplicate ＡＣＫいついては、受信次第ＴＣＰモジュールに通知する（図５中、（ｅ）参照）。
（ｂ）その後は、fast recovery 手順でのcwndの急激な増加を避けるために、ホストＭＴＵ／ネットＭＴＵ（比の値）個に１つの割合で、duplicate ＡＣＫが通知されるようにする。但し、fast retransmit 開始のために先に通知した４つのＡＣＫを考慮して、次の（５番目）のＡＣＫ通知だけは、前のＡＣＫから数えてホストＭＴＵの４倍／ネットＭＴＵ（比の値）−３なる個数のduplicate ＡＣＫを受信した時点で行う。
【００５２】
(5) ＴＣＰモジュールは、duplicate ＡＣＫを受信すると、ＤＴ(29201:37961) を再送する。通信ボード１れは、これをネットＭＳＳに基づき分割し、先頭のＤＴ(29201:30661) だけを送信する（図５中、（ｆ）参照）。
【００５３】
(6) 受信側の通信ボード１では、再送ＤＴ(29201:30661) の受信により、紛失部分がなくなり受信済みＤＴグループ[30661,43801] まで連続して受信した状態となる。そこで通信ボード１では、rx＿max ＝43801 をrx＿max＿rec に記録し、再送ＤＴをＴＣＰモジュールに通知する。そして、ＴＣＰモジュールから返送されるＡＣＫ(a43801,w35040) により、誤り回復の完了を確認する。これにより、以降の受信ＤＴ(45261:46721−51101:52561 は組立可能となる（図５中、（ｇ）参照）。一方、ＡＣＫが戻る前に受信したＤＴ(43801:45261) は、誤り回復完了を検出する前であるため、受信後すぐにＴＣＰモジュールへ通知されている（図５中、（ｈ）参照）。本ＤＴはrx＿max＿rec に連続するため、ＡＣＫ(a43801,w35050) が戻った時点で、ＴＣＰモジュールにより正常に連続受信されることが保証される。
【００５４】
［動作手順その４：コネクション終了時の手順］
図６に、コネクション終了時の通信シーケンス例を示す。本方法では、コネクション終了に伴う状態遷移を簡素化するために、ＴＣＰモジュールからのコネクション終了要求（ＦＩＮ）並びにその送達確認のみを監視する。ＴＣＰモジュールからのＦＩＮが送達確認された時点で、そのコネクションに対しては、通信ボード１に新たなパケット送信要求か来ないことが保証されるため、該当するコネクションテーブルを削除することができる。以下、図６を例に、コネクション終了時の手順(1) 〜(3) を説明する。
【００５５】
(1) 通信ボード１では、ＴＣＰモジュールからＦＩＮフラグを有効にしたＤＴを渡されると、これがネットＭＳＳ以上のユーザデータを含むＤＴである場合あ、これを通信ボード１で分割する。その際、ＦＩＮフラグは分割後の最後のＤＴのみ有効にする（図６中、（ａ）参照）。
【００５６】
(2) 一方、ネットワークから受信したＦＩＮセグメントについては、通信ボード１上で、通常のＤＴと同様、可能であれば前のＤＴに連結する。そして、直ぐに、ＴＣＰモジュールへ通知する（図６中、（ｂ）参照）。
【００５７】
(3) ネットワークからＦＩＮに対するＡＣＫを受信すると、通信ボード１はこれをＴＣＰモジュールへ通知し、コネクションテーブルを削除する（図６中、（ｃ）参照）。以降は、通信ボード１はＴＣＰ通信に介在せず、受信データをそのままＴＣＰモジュールへ通知する（図６中、（ｄ）参照）。
【００５８】
上述のように、通信ボード１のオンボードＣＰＵを利用して、ＴＣＰまで考慮したパケット分割と組立を行うことにより、端末に大きなＭＴＵサイズを提供するから、例えば標準のイーサネットと同じＭＴＵサイズ（１５００バイト）をネットワーク上で用いることができる。つまり、ネットワークでは広く使用されている小さなパケットサイズを用いつつ、ホスト内では大きなパケットサイズで効率良くＴＣＰのプロトコル処理を行うことができる。このため、本方法をサポートする端末のプロトコルモジュールでは、大きなＭＴＵサイズをサポートしない既存の端末やネットワーク機器と接続した場合でも、大きなパケットで処理を行うことが可能となる。
【００５９】
また、パケットの分割・組立により、端末本体のＴＣＰモジュールにおける１つのデータセグメント（ＤＴ）が、ネットワーク上における複数のデータセグメント（ＤＴ）に対応するので、本方法をサポートする端末が既存端末と通信した場合は、双方の端末が送受信するＡＣＫ（確認応答）の数が変動するので、ＴＣＰの輻輳制御や再送処理に影響が現れる可能性があるが、ＡＣＫ数の増減を調整することによりこの影響を抑制することができる。
【００６０】
つまり、ＴＣＰレベルのパケット分解・組立を行うと、通信ボード１が端末本体ホストから受信するＡＣＫパケットが、通信ボード１が通信相手へ送信すべきＡＣＫパケットよりも減少し、反対に、通信ボード１が端末本体へ通知すべきＡＣＫパケットよりも、通信ボード１が通信相手から受信するＡＣＫパケットが増加する。このようなＡＣＫパケット数の不一致はＴＣＰ輻輳制御機能等に副作用を与えるが、ＡＣＫパケット増減を補償することにより、ＴＣＰ輻輳制御機能等に与える副作用を防ぐことができる。
【００６１】
更に、ＴＣＰ以外のパケット、例えばＵＤＰパケットについては、通信ボード１上でＩＰフラグメンテーション（ＩＰ分割）並びにそのデフラグメンテーション（ＩＰ組立）を行うことにより、送信端末トや受信端末トにおけるプロトコル処理の負荷が削減可能である。
【００６２】
また、端末本体と通信ボード１間でのＴＣＰレベルのパケット分解・組立には、メモリコピーを行わず、ＤＭＡ転送を行うことにより処理時間を短縮することができる。
【００６３】
互いに通信する端末間の一方が上述の機能をサポートすることにより、他方の端末及びネットワーク機器がジャンボフレームをサポートしない場合でも、相互接続性を保証することができる。
【００６４】
また、上述の機能を双方の端末がともにサポートしていれば、ネットワーク機器がジャンボフレームをサポートしない場合でも、全てジャンボフレームを適用した場合と同様に、各端末上でＴＣＰ、ＩＰ、デバイスドライバ等の処理オーバヘッドを削減することが可能である。
【００６５】
【発明の効果】
本発明によれば、ネットワークで広く用いられている例えば１５００バイト程度の小さなパケットサイズを変更することなく、端末において大きなパケットサイズによる効率的なＴＣＰ通信が可能となる。また、パケットの分解・組立に伴うＡＣＫパケットの増大・不足を補償することで、ＴＣＰ輻輳制御等との不整合を防止することができ、ネットワークに対して従来と同様の輻輳制御等を提供することが可能となる。このような効果を持つ本発明は、ＦＰＧＡ等の（プログラマブル）ロジックによる実装を通じた通信装置への適用等が可能である。
【図面の簡単な説明】
【図１】本発明の実施形態例に係るＴＣＰ通信方法の全体構成を示す図。
【図２】コネクション確立時の処理フローを示す図。
【図３】コネクション確立時の通信シーケンス例を示す図。
【図４】データ転送時の通信シーケンス例を示す図。
【図５】再送時の通信シーケンス例を示す図。
【図６】コネクション終了時の通信シーケンス例を示す図。
【符号の説明】
１ 通信ボード
２ デバイスドライバ
３ ＴＣＰ／ＩＰモジュール
【発明の属する技術分野】
本発明はＴＣＰ通信を高速化する技術に関する。
【０００２】
【従来の技術】
通常のイーサネットでは、ＩＰの最大パケット長(Maximum Transfer Unit size:以下、ＭＴＵサイズと呼ぶ）は１５００バイトであり、ＴＣＰの最大ユーザデータ長(Maximum Segment Siz: 以下、ＭＳＳと呼ぶ）はＭＴＵサイズからＩＰ及びＴＣＰのヘッダ領域を除いた１４６０バイトである。
【０００３】
このように通常のイーサネットでは、ＴＣＰの最大ユーザデータ長ＭＳＳが小さいために、パケット単位で行われるＴＣＰやＩＰのプロトコル処理、並びに、ホスト端末と通信ボード間のデータ転送処理がホスト端末に対して大きなオーバヘッドとなり、この処理オーバヘッドがＴＣＰ通信の高速化を妨げている。
【０００４】
これらの処理オーバヘッドを減らすためには、より大きなＭＳＳを用いることが望まれる。
【０００５】
一方、近年、ギガビットイーサネット（Giga bits Ethernet：以下、ＧｂＥと呼ぶ）の普及に伴い、ホスト端末においてもギガビットクラスの広い帯域を利用可能になっている。しかし、ＧｂＥで標準的に用いられているＭＴＵサイズは通常のイーサネットと同じ１５００バイトであるため、現状のホスト端末ではやはり、パケット単位で行われるプロトコル処理、並びに、ホスト端末と通信ボード間のデータ転送処理が大きなオーバヘッドとなる。
【０００６】
その解決策として、フレーム長を独自に長く拡張したイーサネットフレーム（以下、ジャンボフレームと呼ぶ）を用いてＭＴＵサイズを拡大する方法が提案されている（例えば、ＭＴＵサイズ：８８００バイト、ＭＳＳ：８７６０バイト）。しかし、この方法には下記に示す問題点がある。
(1) 原則として、サブネットを構成するホスト端末、並びに、スイッチやルータ等のネットワーク機器全てが、ジャンボフレームをサポートする必要がある。このため、ジャンボフレームをサポートしない既存のホスト端末とは同一のサブネットを構成できない。
(2) 通信経路上の、広域網を含む全てのリンクにおけるＭＴＵサイズ（以下、パスＭＴＵサイズと呼ぶ）が例えば８８００バイト以上と大きい必要がある。そうでない場合は、ルータでのＩＰパケットの分割（ＩＰフラグメンテーション) や、ホスト端末でのパスＭＴＵサイズに応じたパケットサイズの調整（最大セグメントサイズの交換、パスＭＴＵディスカバリー(path MTU discovery)）が起きるため、大きなサイズのパケットで通信することは不可能である。
【０００７】
【発明が解決しようとする課題】
本発明の課題は、パスＭＴＵサイズよりも大きなＭＴＵサイズをホスト端末に提供することができるＴＣＰ通信方法を提供することである。
【０００９】
【課題を解決するための手段】
請求項１に係る発明は上記課題を解決するＴＣＰ通信方法であり、端末本体に搭載される通信ボード上のＣＰＵ（オンボードＣＰＵ）を利用してＴＣＰレベルでパケットの分割及び組立を行う際、前記端末本体のＴＣＰモジュールから送信された１つのデータセグメントを前記通信ボード上で適切なＴＣＰ／ＩＰヘッダを持つ複数のデータセグメントに分割してネットワークへ出力し、前記ネットワークから入力された複数のデータセグメントを前記通信ボード上で１つのデータセグメントに組み立てた後、前記ＴＣＰモジュールに通知すると共に、分割前のデータセグメントに対するＡＣＫパケットの増加、並びに、組立前のデータセグメントに対するＡＣＫパケットの減少を前記通信ボード上で調整し、これらＡＣＫパケットの増減がＴＣＰの輻輳制御や再送処理等の制御手順へ及ぼす影響を防ぐことを特徴とするＴＣＰ通信方法である。請求項２に係る発明は、請求項１において、送受信シーケンス番号及びＡＣＫ番号をＴＣＰコネクション毎に保持するコネクションテーブルを前記通信ボード上に用意し、前記コネクションテーブルを参照して前記ＡＣＫパケットの増減を調整することを特徴とするＴＣＰ通信方法である。
【００１０】
請求項３に係る発明は、請求項１において、通信経路上のネットワークを含む全てのリンクにおけるＭＴＵサイズ（以下、パスＭＴＵと呼ぶ）と、ネットワークに対するＭＴＵサイズ（以下、ネットＭＴＵと呼ぶ）を比較し、パスＭＴＵ≧ネットＭＴＵである場合はネットＭＴＵに基づいて前記データセグメントの分割を行い、パスＭＴＵ＜ネットＭＴＵである場合はパスＭＴＵに基づいて前記データセグメントの分割を行うことを特徴とするＴＣＰ通信方法である。請求項４に係る発明は、請求項３において、宛先ＩＰアドレス毎にパスＭＴＵ情報を参照して、前記パスＭＴＵに基づくデータセグメントの分割を行うことを特徴とするＴＣＰ通信方法である。
【００１１】
請求項５に係る発明は、請求項１において、ＵＤＰのようにメッセージ境界を保つ必要があるプロトコルのパケットに対してはＩＰレベルでパケットの分割及び組立を行うことを特徴とするＴＣＰ通信方法である。
【００１２】
請求項６に係る発明は上記課題を解決する他のＴＣＰ通信方法であり、ＴＣＰを処理するＴＣＰモジュール及びＩＰを処理するＩＰモジュールを有する端末本体と、ＣＰＵ及びメモリを有し、ネットワーク及び前記ホストに接続される通信ボードと、該通信ボードのＣＰＵ（オンボードＣＰＵ）上で動作するファームウェアと、前記端末本体が有するＣＰＵ（ホストＣＰＵ）で動作する、前記通信ボード用のデバイスドライバとによりＴＣＰ通信を行うこと、前記ファームウェアは、ＴＣＰコネクションの確立を監視し、該ＴＣＰコネクションの確立手順を利用することより、前記端末本体が前記ネットワーク上のパケットサイズよりも大きなパケットサイズを利用することを可能にする第１機能と、前記通信ボードへ前記端末本体から分割されてＤＭＡ転送されたＴＣＰセグメントに適切なＴＣＰヘッダを付加し、前記通信ボードから前記ネットワークへ転送する第２機能と、前記ネットワークから前記通信ボードが受信したパケットをＴＣＰコネクション毎にまとめて１つのパケットとして前記端末本体へ通知する第３機能を提供すること、前記デバイスドライバは、前記端末本体から前記通信ボードへ渡されるべきパケットを、メモリコピーを行うことなく、前記通信ボードでのＴＣＰヘッダの付加を考慮して分割し、通信ボードの前記メモリにＤＭＡ転送する機能を提供することを特徴とする。請求項７に係る発明は、請求項６において、前記ファームウェアは、前記第１、第２及び第３機能により生じる前記端末本体から前記通信ボードへのＡＣＫパケットの減少、並びに、前記ネットワークから前記通信ボードへのＡＣＫパケットの増加を防ぐ第４機能を提供することを特徴とするＴＣＰ通信方法である。
【００１３】
【発明の実施の形態】
図面を参照して、本発明の実施形態例に係るＴＣＰ通信方法を説明する。
【００１４】
［発明の基本］
本方法では、通信ボード上のＣＰＵ（オンボードＣＰＵ）を利用してパケットの分割及び組立を行うことにより、ネットワークに対しては標準のイーサネットと同じＭＴＵサイズを使用しつつ、端末本体のＴＣＰやＩＰ等のプロトコルモジュールにおいて大きなパケットの利用を可能とする。このため、通信ボード用のデバイスドライバでは、端末本体のＩＰモジュールに対して、ネットワークに対するＭＴＵサイズ（以下、ネットＭＴＵと呼ぶ）とは独立した、大きなＭＴＵサイズ（以下、ホストＭＴＵと呼ぶ）を提供する。
【００１５】
ＴＣＰでは、コネクション確立時に交換するＭＳＳを越えるセグメントを送信してはならない。一方、ＭＳＳの値はＭＴＵサイズに依存するため、大きなＭＴＵサイズを持たない既存の端末では、大きなセグメントを使用することが不可能である。そこで、既存端末とのＴＣＰ通信においても、本方法を適用できるように、パケット分割・組立をＩＰではなくＴＣＰレベルで行う。即ち、端末本体のＴＣＰモジュールから送信された１つのＤＴ（データセグメント）を、通信ボード上で、それぞれ適切なＴＣＰ／ＩＰヘッダを持つ複数のＤＴに分割してネットワークへ出力する。また、ネットワークから入力された複数のＤＴを、通信ボード上で１つのＤＴに組み立てた上で、端末本体のＴＣＰモジュールへ通知する。一方、ＵＤＰ（ユーザデータグラムプロトコル）のようなメッセージ境界を保つ必要があるプロトコルに対しては、通信ボード上でＩＰレベルのパケット分割・組立（ＩＰフラグメンテーションとリアセンブリ）を行う高速化を図る。
【００１６】
上記の処理により、ＴＣＰ通信においては、端末本体のＴＣＰモジュールで処理される１つのＤＴは、ネットワーク上で転送される複数のＤＴに対応することになる。このため、既存の端末との通信を想定した場合、分割前のＤＴに対するＡＣＫ（確認応答）の数はは多くなり、逆に、組立前のＤＴに対するＡＣＫの数は少なくなることが予想される。一方、ＴＣＰのslow start（スロータート）手順やcongestion avoidance（コンジェスチョンアボイダンス）手順、あるいは、fast recovery （ファーストリカバリ）手順において参照される輻輳ウインドウ(cwnd)はＡＣＫ受信により更新される。また、fast retransmit（ファーストリトランスミット）手順では受信したＡＣＫを調べてパケット紛失を検出する。これらのため、通信ボード上でＡＣＫの数並びにその内容を調整し、これらの制御手順への影響を抑える。
【００１７】
ＡＣＫ調整を行うために、通信ボード上で個々のＴＣＰコネクション毎に、送受信シーケンス番号やＡＣＫ番号を登録し参照する。そこで、これらの情報（ＴＣＰコネクション毎の送受信シーケンス番号やＡＣＫ番号）を保持するためのコネクションテーブルを通信ボード上に用意する。また、パスＭＴＵ＜ネットＭＴＵである場合は、パケット分割は、ネットＭＴＵではなくパスＭＴＵに基づいて行う。このため、パスＭＴＵ＜ネットＭＴＵである場合は、宛先ＩＰアドレス毎にパスＭＴＵ情報を参照できるようにする。
【００１８】
端末の収容先としては、基本的には１５００バイトのＭＴＵサイズを持つ標準のイーサネットセグメントを想定しているが、これより大きなＭＴＵサイズを持つイーサネットセグメントへ収容した場合も動作可能である。
【００１９】
［全体構成］
図１に本例に係るＴＣＰ通信方法の全体構成を示す。図１において、１は通信ボード、２はデバイスドライバ、３はＴＣＰ／ＩＰモジュールである。通信ボード１はオンボードＣＰＵを有する市販のＰＣＩバス用ＧｂＥボード（例えば、Alteon Websystems ACEnic（アルテオン・ウェブシステムズ社のエースニック）) には用い、本発明実現のため、ＧｂＥボードのオンボードＣＰＵ（図示省略）上で動作する高速データ通信ソフトウェア（ファームウェア）を改修してある。また、ＧｂＥボードに搭載されたＰＣＩ／ＧｂＥコントロール用ＡＳＩＣ中には、2 つのＲＩＳＣ−ＣＰＵ(MIPS R4000 相当）が組み込まれており、端末本体（図示省略）からダウンロードされたファームウェアによって、送信パケットと受信パケットに対して付加的な処理を行うことができるようにしてある。デバイスドライバ２は端末本体と通信ボード１との間のデータ転送を制御するための通信ボード１用デバイスドライバであり、端末本体が有するＣＰＵ（ホストＣＰＵ：図示省略）で動作する。デバイスドライバ２には、本発明実現のため、ＧｂＥボード用デバイスドライバを改修して用いている。ＴＣＰ／ＩＰモジュール３はＴＣＰを処理するＴＣＰモジュール及びＩＰを処理するＩＰモジュールであり、端末本体に備えられている。その他、端末本体はメモリ等を備え、ジャンボフレームをサポートしている。端末本体にはＵＮＩＸコンピュータを用いている。
【００２０】
ファームウェアはデバイスドライバ２と協調してＴＣＰレベルのパケット分割・組立機能を提供し、ＴＣＰを用いた通信に対して効率的なホストバスインターフェースを提供する。デバイスドライバ２は端末本体のＯＳ（例えばＵＮＩＸ）のカーネルの一部として実装され、カーネル内に予め用意されているＩＰ等のプロトコルモジュールと協調して動作する。また、端末本体は、ファームウェア並びにデバイスドライバ２に実装した機能に対する各種パラメータの設定並びに統計情報の取得を行うための制御用ソフトウェアを有する。これはユーザプロセスである。
【００２１】
［ファームウェアとデバイスドライバ］
上記の機能を実現するため、通信ボードのファームウェア並びに端末本体のデバイスドライバ２では、以下の処理(1) 〜(5) を行う。
【００２２】
(1) デバイスドライバ２からＩＰモジュールに対し、１５００バイト以上のＭＴＵサイズを通知する。通知するＭＴＵサイズは制御プログラムにより可能とし、例えば最大で３６０００バイトとする。デフォルト値は８８００バイトとする。このＭＴＵサイズはホストＭＴＵである。
【００２３】
(2) ファームウェアでは、ＴＣＰコネクションの確立を監視して、必要に応じて、対応するＴＣＰコネクションテーブルを作成する。このテーブルの最大数はデフォルトで１６とするが、コンパイルオプションにより変更可能としている。ＴＣＰレベルのパケット分割・組立機能は、このＴＣＰコネクションテーブルが作成されているコネクションに対してのみ適用する。
【００２４】
(3) ＴＣＰではコネクション確立時に交換するＳＹＮパケット並びにＳＹＮ＋ＡＣＫパケットを用いてＭＳＳを互いに交換するため、ファームウェアで必要に応じてこれを書き換え、ＴＣＰモジュールに大きなＭＳＳを通知する。
【００２５】
(4) 上位プロトコルモジュールから渡されたパケットを、送信側ファームウェアにより、制御用ソフトウェアにより指定されたＭＴＵサイズでネットワークに出力できるようにする。このＭＴＵサイズはボードＭＴＵである。このために、付加するヘッダを含む送信パケットを連続したオンボードメモリ（通信ボード１）上に置く。そこで、デバイスドライバ２において以下の手順（ａ）、（ｂ）を用いることにより、デバイスドライバ２自身並びに通信ボード１上において不要なデータコピーを行うことなく、分割した各パケットに対して通信ボード１上で容易にヘッダを付加できるようにする。
（ａ）デバイスドライバ２では、分割する各パケット毎にＤＭＡ(Direct Memory Access)転送要求を設定する。この際、先頭パケット以外は、ＤＭＡ転送を開始するアドレスをヘッダ領域分、前にずらす( 図１の（ａ）参照) 。パケット本体のコピーは行わない。
（ｂ）ファームウェアでは、先頭パケットのヘッダ情報を基に各パケットのヘッダを作成し、各パケットの先頭部分を上書きして送信する（図１の（ｂ）参照）。
【００２６】
(5) 受信側のファームウェアでは、ネットワークから受信したパケットをできる限り大きなパケットサイズでデバイスドライバに通知するために、以下に示す方針（ａ）〜（ｅ）に従って組み立てる。
（ａ）受信したフレームがＴＣＰセグメントであり、且つ、対応するコネクションテーブルが存在する場合は、原則として、端末本体に対して受信通知のための割り込みをかけず、端末本体へのＤＭＡ転送のみ行い、次のフレームの受信を待つ。
（ｂ）次の受信フレームが、受信済み（但し、端末本体には未通知）のＴＣＰセグメントに連続するＴＣＰセグメントである場合は、受信フレームからＴＣＰ／ＩＰヘッダ等を取り除いて、１つのＴＣＰセグメントに結合されるようにＤＭＡ転送する。結合されたＴＣＰセグメントに対するＴＣＰ／ＩＰヘッダの書き換えも同時に行う。
（ｃ）セグメント紛失等により連続するＴＣＰセグメントを受信しなかった場合や、上記の結合処理によってホストＭＴＵを超えたＴＣＰセグメントとなる場合等、パケット組立が不可能である場合は、これ以前に受信した未通知のフレームのみを端末本体へ通知する。以降は、セグメント紛失から回復するまで、該当するコネクションに属するセグメントの組立は行わない。
（ｄ）セグメント紛失を検出した場合（ｒｘ＿ｎｅｘｔ！＝ｒｅｘ＿ｍａｘ）は、シーケンス番号（ＳＥＱ番号）を持つセグメントのグループｒｘ＿ｇｌｅとｒｘ＿ｍａｘ）を保持する。このグループが受信ホストから送達確認（ＡＣＫ．ｎｏ≧ｒｘ＿ｍａｘ−ｒｅｘ）されるか、このグループまでのセグメントを再度、紛失なく連続して受信した場合に、セグメント紛失が回復したと見なす。
（ｅ）一定の待ち時間（ｄｅｌｉｖｅｒ＿ｔｉｍｅｏｕｔ）経過後は、受信したフレームを端末本体へ通知する。
【００２７】
［ＴＣＰ−ＡＣＫ補償機能］
ＴＣＰレベルのパケット分割を行うことにより、ＴＣＰモジュールから渡された１つのＴＣＰセグメントに対して、複数のＡＣＫパケットが返ることが予想される。このため、下記の問題(1) 〜(2) が予想される。
(1) ＡＣＫ処理負荷が削減されない。
(2) スロースタート(slow start)時の輻輳ウインドウの急増など、ＴＣＰ輻輳制御との不整合が発生する。
【００２８】
一方、パケット組立を行う端末のＴＣＰモジュールでは、大きなパケットサイズでプロトコル処理を行うため、十分にＡＣＫパケットを送信できない可能性があり、これによりＴＣＰの輻輳制御や再送制御に悪影響を与える恐れがあると言う問題がある。
【００２９】
これらの問題を解決するために、以下の要領（ａ）〜（ｂ）により端末本体に通知するＴＣＰ−ＡＣＫ（ユーザデータを含まない) を削減し、また、ネットワーク側へ送出するＴＣＰ−ＡＣＫを増加させることとする。
【００３０】
（ａ）ＴＣＰ−ＡＣＫの削減（送信側)
(i) ＴＣＰコネクションテーブルにＡＣＫ番号、並びに、送信ＴＣＰセグメントのＳＥＱ番号を記録する。記録するＳＥＱ番号は必要に応じて上書きする。
(ii)保持しているＴＣＰセグメントのＳＥＱ番号を送達確認する場合、または、２×ホスト側ＭＳＳ−ボード側ＭＳＳ（２＊ｈ＿ｍｓｓ−ｎ＿ｍｓｓ）を超えるＴＣＰパケットを新規に送達確認する場合、または、最もＳＥＱ番号の大きい送信済みパケットをＡＣＫする場合（ＡＣＫ．ｎｏ＝＝ｓｎｄ＿ｍａｘ）に、ＡＣＫを端末本体に通知する。
(iii) ＤＵＰＡＣＫ（重複ＡＣＫ：ＡＣＫ．ｎｏとＡＣＫ．ｗｉｎ（ウインドウサイズ）が前回と同じＡＣＫ）では、ホスト側ＭＳＳ／ボード側ＭＳＳで与えられる個数のＤＵＰＡＣＫ受信毎に端末本体へ通知する。
【００３１】
（ｂ）ＴＣＰ−ＡＣＫの増加（受信側）
(i) ＴＣＰセグメントが連続して２セグメント受信した場合は、通信ボード１でＡＣＫを作成し送信する。但し、原則として、３セグメント目を受信後に２セグメント分のＡＣＫをする。
(ii)３セグメント目が受信されない場合は、ｄｅｌｉｖｅｒ＿ｔｉｍｅｒ発火後、端末本体への通知と同時にａｃｋ＿ｔｉｍｅｒを起動させる。ａｃｋ＿ｔｉｍｅｒ発火までに端末本体からのＡＣＫ受信もしくはネットワークからのＤＴ受信がなければ、ＡＣＫを作成し送信る。
(iii) パケット紛失時は、前述のようにＤＴ受信毎にそのままホストに通知させ、適切にＤＵＰＡＣＫを発生させる。
【００３２】
従って、ＴＣＰ通信に対する動作手順は以下のように定まる。
【００３３】
［動作手順その１：コネクション確立とパスＭＴＵ設定］
図２にＴＣＰコネクション確立に伴う処理フローを示す。ＴＣＰでは、コネクション確立時に相手から通知されたＭＳＳと自分のＭＳＳとを比較し、いずれあ小さい方のＭＳＳを使用する。このため、通信ボード１とそのデバイスドライバ２では、コネクション確立時に以下の処理(1) 〜(2) を行い、端末本体のＴＣＰモジュールで使用するＭＳＳを大きく保つと同時に、相手端末に対しては、ネットＭＴＵ(netＭＴＵ）またはパスＭＴＵ（pathＭＴＵ）に基づくＭＳＳを通知する。更に、必要であればパケット分割に用いるパスＭＴＵの設定も行う。
【００３４】
(1) 図２において、ＴＣＰモジュールからのＳＹＮ（＋ＡＣＫ）を受信した場合（ステップＳ１）、それに含まれるＭＳＳ（図２のＳＹＮ（＋ＡＣＫ）．ＭＳＳ）を、同じＩＰアドレス宛のパスＭＴＵがあればこれに基づくＭＳＳに、無い場合はネットＭＴＵに基づくＭＳＳに更新し、相手端末に送信する（ステップＳ２、Ｓ５）。受信がＳＹＮであれば、同時にコネクションテーブルも作成する（ステップＳ３、Ｓ４）。
【００３５】
(2) ネットワークからのＳＹＮ（＋ＡＣＫ）を受信した場合（ステップＳ６）、それに含まれるＭＳＳ（図２のＳＹＮ（＋ＡＣＫ）．ＭＳＳ）と、同じＩＰアドレス宛のパスＭＴＵがあればこれに基づくＭＳＳ（図２のnmss）と、無い場合はネットＭＴＵに基づくＭＳＳ（図２のnmss）と比較する（ステップＳ７、Ｓ８）。前者が小さい場合は、nmssの更新、並びに、パスＭＴＵの登録あるいは更新を行う（ステップＳ９）。次に、ホストＭＴＵに基づくＭＳＳを超えないようにnmssを整数倍した値を、ＳＹＮ（＋ＡＣＫ）のＭＳＳとしてＴＣＰジュールに通知する（ステップＳ１０、Ｓ１３）。また、受信がＳＹＮであれば、コネクションテーブルを作成する（ステップＳ１１、Ｓ１２）。
【００３６】
図３にコネクション確立時の通信シーケンス例を示す。ここでは、双方の端末で、ホストＭＴＵを９０００バイト程度として、ネットＭＴＵに１５００または９０００バイトを使用した４種類の組み合わせａ〜ｄに対するシーケンスを示している。
【００３７】
図３より、いずれの組み合わせの場合も、ネットワーク側のＭＳＳは小さい方のネットＭＴＵに基づく適切な値（ａ〜ｃでは１４６０バイト、ｄでは８９６０バイト）が設定され、端末側のＭＳＳもネットワーク側のＭＳＳの整数倍（ａ〜ｃでは８７６０バイト、ｄでは８９６０バイト）となるように調整されていることが判る。なお、ｄでは、双方の端末のネットＭＴＵが９０００バイトであるため、端末間に９０００バイトより小さいＭＴＵサイズを持つ経路が存在しなければ、パケット分割は行われない。
【００３８】
一方、ａ〜ｄの全ての場合で、より小さいパスＭＴＵが通信経路中に存在する可能性もある。これは、データ転送中にＩＣＭＰunreachable が返送されることで検出できる。通信ボード１ではＩＣＭＰunreachable に含まれる新しいパスＭＴＵの登録。更新を行い、分割に用いるパケットサイズを調整する。
【００３９】
［動作手順その２：データ転送時の手順］
図４に、本方法をサポートする端末間におけるデータ転送開始直後の通信シーケンスを示す。以下、図４に沿ってデータ転送時の動作手順(1) 〜(5) を説明する。
【００４０】
(1) 送信側のＴＣＰ並びにＩＰモジュールは、動作手順その１んいより提供される大きなＭＳＳ（８７６０バイト：以降、ホストＭＳＳと呼ぶ）並びにＭＴＵサイズを利用してプロトコル処理を行い、ＤＴ送信を通信ボード１に要求する（図４中、（ａ）参照）。
【００４１】
(2) 送信側の通信ボード１では、ＤＴを動作手順その１により決定したＭＳＳ（１４６０バイト：以降、ネットＭＳＳと呼ぶ）に適合するように分割し、各々に適切なＴＣＰ／ＩＰヘッダを付加した上で送信する（図４中、（ｂ）参照）。
【００４２】
(3) 受信側の通信ボード１では、ＤＴが正しく連続受信されている間は、原則としてネットワークから受信したＤＴを即座にＴＣＰモジュールへは通知せず、可能な限り大きなＤＴに組み立てる。ＤＴ通知は以下のどちらかの条件（ａ）（ｂ）を満たした時点で行う。
（ａ）ＤＴの長さ＞ホストＭＴＵ−ネットＭＴＵ（図４中、（ｃ）参照）。
（ｂ）先頭ＤＴの受信後一定時間が経過（図４中、（ｄ）参照）。
【００４３】
(4) 一般的なＴＣＰの実装では、２つのＤＴを正しく受信する毎に、対応するＡＣＫ番号を持つＡＣＫを１つ返す。ＤＴ送信側が本方法をサポートしていない場合も同様の間隔でＡＣＫが返るように、以下の要領（ａ）（ｂ）に従い受信側の通信ボード１でＡＣＫを補填する。この際、ＴＣＰモジュールからのＡＣＫと重複することを避けるようにしている。
（ａ）新たに２つのＤＴを送達確認可能である場合、次のＤＴ受信時にＡＣＫを送信する（図４中、（ｅ）参照）。但し、２つのＤＴ毎にＡＣＫを返すために、最後に受信したＤＴはＡＣＫの対象に含めない。
（ｂ）上記(3) によるＤＴ通知時点で、新たに２つのＤＴをＡＣＫできる場合はＡＣＫタイマを設定する（図４中、（ｆ）〜（ｈ）参照）。このタイマは次のＤＴの受信（図４中、（ｆ）参照）、もしくは、ＴＣＰモジュールからのＡＣＫ応答（図４中、（ｇ）参照）によりキャンセルされる。タイマが満了した場合は、通信ボード１からＡＣＫを送信する（図４中、（ｈ）参照）。
【００４４】
また、ＴＣＰモジュールからのＡＣＫについては、最後に送信したＡＣＫよりも新しい情報（ＡＣＫ番号、winsize)を含んでいれば送信側に転送する。この際、通信ボード１でより進んだＡＣＫ番号を既に送信側に通知している場合は、これに合わせてＡＣＫ番号とウインサイズ(winsize) を決定する（図４中、（ｉ）参照）。
【００４５】
(5) 一方、ＤＴ送信側の通信ボード１には上記(4) により２つのＤＴ送信毎に１つのＡＣＫが戻る。ＴＣＰモジュールにおいても、cwndを適切に更新するために、分割前の２つのＤＴに対して１つのＡＣＫが通知されることが望ましい。また、silly window syndrome （シリーウインドウシンドローム）を避けるためには、ホストＭＳＳ以上の受信ウインドウを通知すべきである。逆に、Nagle algorithm(ナグルアルゴリズム) 、keep alive（キープアライブ）、window probe（ウインドウプローブ）等の手順では、受信したＡＣＫを必ず通知すべきである。そこで通信ボード１では、下記（ａ）（ｂ）（ｃ）いずれかの処理は見込まれる場合のみ、ＡＣＫを通知する。
（ａ）ホストＭＴＵの２倍−ネットＭＴＵ以上のＤＴを送信確認する（図４中、（ｊ）参照）。
（ｂ）干す炉ＭＴＵ以上の受信ウインドウが付与される（図４中、（ｋ）参照）。
（ｃ）送達確認待ちのＤＴがなくなるか、既にない（図４中、（ｌ）参照）。
なお、ＡＣｋ番号またはwinsize のいずれかに、ＴＣＰモジュールにまだ通知すべきでない小さな更新がある場合は、これらを調整した上で通知する（図４中、（ｋ）参照）。
【００４６】
［動作手順その３：誤り回復時の手順］
図５に、ＤＴ紛失に伴う再送手順を含む通信シーケンス例を示す。紛失ＤＴに回復手順は、双方の端末のＴＣＰによりエンド・エンドで提供される。以下、図５に従って、ＴＣＰの誤り回復手順を考慮した方法の動作手順(1) 〜(6) を説明する。
【００４７】
(1) ＤＴ(29201:30661) の紛失を検出すると、通信ボード１は既に受信組立済みのＤＴ(26281:29201) を即座にＴＣＰモジュールへ通知する（図５中、（ａ）参照）。以降、通信ボード１では、ＴＣＰモジュールの誤り回復手順の完了を確認するまで、受信したＤＴの組立は行わない（図５中、（ｂ）参照）。
【００４８】
(2) 受信側通信ボード１では、ＴＣＰモジュールにおける誤り回復手順の完了を検出するために、ＤＴ紛失の検出後、最大のシーケンス番号を持つ連続した受信済みＤＴのグループをリスト [rx＿gle,rx＿max]形式で保存する。
【００４９】
図５の例では、ＤＴ紛失を検出した直後の受信済みＤＴグループは[30661,32121] であり、再送ＤＴの受信直前は[30661,43801] となる。通信ボード１はrx＿gle までの紛失ＤＴを受信することで、紛失部分がなくなり、rx＿max まで連続して受信した状態となる。ＴＣＰモジュールから、rx＿max まで送達確認するＡＣＫが返されれば、ＴＣＰモジュールの誤り回復手順が完了したと見なす。また、rx＿max までの全てのＤＴが再度連続して受信された場合も同様である。
【００５０】
(3) ＴＣＰモジュールから、紛失ＤＴの送信を要求するＡＣＫ(a29201,w37961) が渡されると、通信ボード１はこれを送信側に転送する。以降も、ＤＴ通知毎に返送されるduplicate ＡＣＫについては、そのまま送信側に転送する。（図５中、（ｃ）参照）。
【００５１】
(4) 送信側の通信ボード１において検出したduplicate ＡＣＫ(a29291,w62615) は、fast retransmit の開始前後で以下（ａ）（ｂ）のように処理を変える。
（ａ）fast retransmit を素早く開始させるために、ＴＣＰモジュールに同一のＡＣＫを既に通知済みか同化検査し、通知済みであれば１つのＡＣＫを、そうでなければ２つのＡＣＫをＴＣＰモジュールに通知する。更に、２つのduplicate ＡＣＫいついては、受信次第ＴＣＰモジュールに通知する（図５中、（ｅ）参照）。
（ｂ）その後は、fast recovery 手順でのcwndの急激な増加を避けるために、ホストＭＴＵ／ネットＭＴＵ（比の値）個に１つの割合で、duplicate ＡＣＫが通知されるようにする。但し、fast retransmit 開始のために先に通知した４つのＡＣＫを考慮して、次の（５番目）のＡＣＫ通知だけは、前のＡＣＫから数えてホストＭＴＵの４倍／ネットＭＴＵ（比の値）−３なる個数のduplicate ＡＣＫを受信した時点で行う。
【００５２】
(5) ＴＣＰモジュールは、duplicate ＡＣＫを受信すると、ＤＴ(29201:37961) を再送する。通信ボード１れは、これをネットＭＳＳに基づき分割し、先頭のＤＴ(29201:30661) だけを送信する（図５中、（ｆ）参照）。
【００５３】
(6) 受信側の通信ボード１では、再送ＤＴ(29201:30661) の受信により、紛失部分がなくなり受信済みＤＴグループ[30661,43801] まで連続して受信した状態となる。そこで通信ボード１では、rx＿max ＝43801 をrx＿max＿rec に記録し、再送ＤＴをＴＣＰモジュールに通知する。そして、ＴＣＰモジュールから返送されるＡＣＫ(a43801,w35040) により、誤り回復の完了を確認する。これにより、以降の受信ＤＴ(45261:46721−51101:52561 は組立可能となる（図５中、（ｇ）参照）。一方、ＡＣＫが戻る前に受信したＤＴ(43801:45261) は、誤り回復完了を検出する前であるため、受信後すぐにＴＣＰモジュールへ通知されている（図５中、（ｈ）参照）。本ＤＴはrx＿max＿rec に連続するため、ＡＣＫ(a43801,w35050) が戻った時点で、ＴＣＰモジュールにより正常に連続受信されることが保証される。
【００５４】
［動作手順その４：コネクション終了時の手順］
図６に、コネクション終了時の通信シーケンス例を示す。本方法では、コネクション終了に伴う状態遷移を簡素化するために、ＴＣＰモジュールからのコネクション終了要求（ＦＩＮ）並びにその送達確認のみを監視する。ＴＣＰモジュールからのＦＩＮが送達確認された時点で、そのコネクションに対しては、通信ボード１に新たなパケット送信要求か来ないことが保証されるため、該当するコネクションテーブルを削除することができる。以下、図６を例に、コネクション終了時の手順(1) 〜(3) を説明する。
【００５５】
(1) 通信ボード１では、ＴＣＰモジュールからＦＩＮフラグを有効にしたＤＴを渡されると、これがネットＭＳＳ以上のユーザデータを含むＤＴである場合あ、これを通信ボード１で分割する。その際、ＦＩＮフラグは分割後の最後のＤＴのみ有効にする（図６中、（ａ）参照）。
【００５６】
(2) 一方、ネットワークから受信したＦＩＮセグメントについては、通信ボード１上で、通常のＤＴと同様、可能であれば前のＤＴに連結する。そして、直ぐに、ＴＣＰモジュールへ通知する（図６中、（ｂ）参照）。
【００５７】
(3) ネットワークからＦＩＮに対するＡＣＫを受信すると、通信ボード１はこれをＴＣＰモジュールへ通知し、コネクションテーブルを削除する（図６中、（ｃ）参照）。以降は、通信ボード１はＴＣＰ通信に介在せず、受信データをそのままＴＣＰモジュールへ通知する（図６中、（ｄ）参照）。
【００５８】
上述のように、通信ボード１のオンボードＣＰＵを利用して、ＴＣＰまで考慮したパケット分割と組立を行うことにより、端末に大きなＭＴＵサイズを提供するから、例えば標準のイーサネットと同じＭＴＵサイズ（１５００バイト）をネットワーク上で用いることができる。つまり、ネットワークでは広く使用されている小さなパケットサイズを用いつつ、ホスト内では大きなパケットサイズで効率良くＴＣＰのプロトコル処理を行うことができる。このため、本方法をサポートする端末のプロトコルモジュールでは、大きなＭＴＵサイズをサポートしない既存の端末やネットワーク機器と接続した場合でも、大きなパケットで処理を行うことが可能となる。
【００５９】
また、パケットの分割・組立により、端末本体のＴＣＰモジュールにおける１つのデータセグメント（ＤＴ）が、ネットワーク上における複数のデータセグメント（ＤＴ）に対応するので、本方法をサポートする端末が既存端末と通信した場合は、双方の端末が送受信するＡＣＫ（確認応答）の数が変動するので、ＴＣＰの輻輳制御や再送処理に影響が現れる可能性があるが、ＡＣＫ数の増減を調整することによりこの影響を抑制することができる。
【００６０】
つまり、ＴＣＰレベルのパケット分解・組立を行うと、通信ボード１が端末本体ホストから受信するＡＣＫパケットが、通信ボード１が通信相手へ送信すべきＡＣＫパケットよりも減少し、反対に、通信ボード１が端末本体へ通知すべきＡＣＫパケットよりも、通信ボード１が通信相手から受信するＡＣＫパケットが増加する。このようなＡＣＫパケット数の不一致はＴＣＰ輻輳制御機能等に副作用を与えるが、ＡＣＫパケット増減を補償することにより、ＴＣＰ輻輳制御機能等に与える副作用を防ぐことができる。
【００６１】
更に、ＴＣＰ以外のパケット、例えばＵＤＰパケットについては、通信ボード１上でＩＰフラグメンテーション（ＩＰ分割）並びにそのデフラグメンテーション（ＩＰ組立）を行うことにより、送信端末トや受信端末トにおけるプロトコル処理の負荷が削減可能である。
【００６２】
また、端末本体と通信ボード１間でのＴＣＰレベルのパケット分解・組立には、メモリコピーを行わず、ＤＭＡ転送を行うことにより処理時間を短縮することができる。
【００６３】
互いに通信する端末間の一方が上述の機能をサポートすることにより、他方の端末及びネットワーク機器がジャンボフレームをサポートしない場合でも、相互接続性を保証することができる。
【００６４】
また、上述の機能を双方の端末がともにサポートしていれば、ネットワーク機器がジャンボフレームをサポートしない場合でも、全てジャンボフレームを適用した場合と同様に、各端末上でＴＣＰ、ＩＰ、デバイスドライバ等の処理オーバヘッドを削減することが可能である。
【００６５】
【発明の効果】
本発明によれば、ネットワークで広く用いられている例えば１５００バイト程度の小さなパケットサイズを変更することなく、端末において大きなパケットサイズによる効率的なＴＣＰ通信が可能となる。また、パケットの分解・組立に伴うＡＣＫパケットの増大・不足を補償することで、ＴＣＰ輻輳制御等との不整合を防止することができ、ネットワークに対して従来と同様の輻輳制御等を提供することが可能となる。このような効果を持つ本発明は、ＦＰＧＡ等の（プログラマブル）ロジックによる実装を通じた通信装置への適用等が可能である。
【図面の簡単な説明】
【図１】本発明の実施形態例に係るＴＣＰ通信方法の全体構成を示す図。
【図２】コネクション確立時の処理フローを示す図。
【図３】コネクション確立時の通信シーケンス例を示す図。
【図４】データ転送時の通信シーケンス例を示す図。
【図５】再送時の通信シーケンス例を示す図。
【図６】コネクション終了時の通信シーケンス例を示す図。
【符号の説明】
１ 通信ボード
２ デバイスドライバ
３ ＴＣＰ／ＩＰモジュール
Claims (7)
- 端末本体に搭載される通信ボード上のＣＰＵ（以下、オンボードＣＰＵと呼ぶ）を利用してＴＣＰレベルでパケットの分割及び組立を行うことによりＴＣＰ通信を高速化するＴＣＰ通信方法において、
前記端末本体のＴＣＰモジュールから送信された１つのデータセグメントを前記通信ボード上で適切なＴＣＰ／ＩＰヘッダを持つ複数のデータセグメントに分割してネットワークへ出力し、前記ネットワークから入力された複数のデータセグメントを前記通信ボード上で１つのデータセグメントに組み立てた後、前記ＴＣＰモジュールに通知すると共に、
分割前のデータセグメントに対するＡＣＫパケットの増加、並びに、組立前のデータセグメントに対するＡＣＫパケットの減少を前記通信ボード上で調整し、これらＡＣＫパケットの増減がＴＣＰの輻輳制御や再送処理等の制御手順へ及ぼす影響を防ぐことを特徴とするＴＣＰ通信方法。 - 請求項１において、
送受信シーケンス番号及びＡＣＫ番号をＴＣＰコネクション毎に保持するコネクションテーブルを前記通信ボード上に用意し、前記コネクションテーブルを参照して前記ＡＣＫパケットの増減を調整することを特徴とするＴＣＰ通信方法。 - 請求項１において、
通信経路上のネットワークを含む全てのリンクにおけるＭＴＵサイズ（以下、パスＭＴＵと呼ぶ）と、ネットワークに対するＭＴＵサイズ（以下、ネットＭＴＵと呼ぶ）を比較し、パスＭＴＵ≧ネットＭＴＵである場合はネットＭＴＵに基づいて前記データセグメントの分割を行い、パスＭＴＵ＜ネットＭＴＵである場合はパスＭＴＵに基づいて前記データセグメントの分割を行うことを特徴とするＴＣＰ通信方法。 - 請求項３において、
宛先ＩＰアドレス毎にパスＭＴＵ情報を参照して、前記パスＭＴＵに基づくデータセグメントの分割を行うことを特徴とするＴＣＰ通信方法。 - 請求項１において、
ＵＤＰのようにメッセージ境界を保つ必要があるプロトコルのパケットに対してはＩＰレベルでパケットの分割及び組立を行うことを特徴とするＴＣＰ通信方法。 - ＴＣＰを処理するＴＣＰモジュール及びＩＰを処理するＩＰモジュールを有する端末本体と、ＣＰＵ及びメモリを有し、ネットワーク及び前記ホストに接続される通信ボードと、該通信ボードの前記ＣＰＵ（オンボードＣＰＵ）上で動作するファームウェアと、前記端末本体が有するＣＰＵ（以下、ホストＣＰＵと呼ぶ）で動作する、前記通信ボード用のデバイスドライバとによりＴＣＰ通信を行うこと、前記ファームウェアは、ＴＣＰコネクションの確立を監視し、該ＴＣＰコネクションの確立手順を利用することより、前記端末本体が前記ネットワーク上のパケットサイズよりも大きなパケットサイズを利用することを可能にする第１機能と、前記通信ボードへ前記端末本体から分割されてＤＭＡ転送されたＴＣＰセグメントに適切なＴＣＰヘッダを付加し、前記通信ボードから前記ネットワークへ転送する第２機能と、前記ネットワークから前記通信ボードが受信したパケットをＴＣＰコネクション毎にまとめて１つのパケットとして前記端末本体へ通知する第３機能を提供すること、前記デバイスドライバは、前記端末本体から前記通信ボードへ渡されるべきパケットを、メモリコピーを行うことなく、前記通信ボードでのＴＣＰヘッダの付加を考慮して分割し、通信ボードの前記メモリにＤＭＡ転送する機能を提供することを特徴とするＴＣＰ通信方法。
- 請求項６において、
前記ファームウェアは、前記第１、第２及び第３機能により生じる前記端末本体から前記通信ボードへのＡＣＫパケットの減少、並びに、前記ネットワークから前記通信ボードへのＡＣＫパケットの増加を防ぐ第４機能を提供することを特徴とするＴＣＰ通信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000271666A JP4041646B2 (ja) | 2000-09-07 | 2000-09-07 | Ｔｃｐ通信方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000271666A JP4041646B2 (ja) | 2000-09-07 | 2000-09-07 | Ｔｃｐ通信方法 |
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 | Ｔｃｐ通信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4041646B2 (ja) |
Families Citing this family (22)
| 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 |
| CN100445977C (zh) | 2004-05-18 | 2008-12-24 | 皇家飞利浦电子股份有限公司 | 数据处理系统以及用于处理数据的方法 |
| US7757074B2 (en) | 2004-06-30 | 2010-07-13 | Citrix Application Networking, Llc | System and method for establishing a virtual private 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 |
| US8739274B2 (en) | 2004-06-30 | 2014-05-27 | Citrix Systems, Inc. | Method and device for performing integrated caching in a data communication network |
| US7808906B2 (en) | 2004-07-23 | 2010-10-05 | Citrix Systems, Inc. | Systems and methods for communicating a lossy protocol via a lossless protocol using false acknowledgements |
| JP2008507929A (ja) | 2004-07-23 | 2008-03-13 | サイトリックス システムズ， インコーポレイテッド | プライベートネットワークへの遠隔アクセスを安全にする方法およびシステム |
| 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 |
| 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 |
| US8706877B2 (en) | 2004-12-30 | 2014-04-22 | Citrix Systems, Inc. | Systems and methods for providing client-side dynamic redirection to bypass an intermediary |
| 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 |
| 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 |
| 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 | データ送信装置、データ送信方法及びデータ送信プログラム |
| 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 |
| 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 |
| JP2008028767A (ja) * | 2006-07-21 | 2008-02-07 | Sumitomo Electric Networks Inc | ネットワークカードおよび情報処理装置 |
| JP5106359B2 (ja) * | 2008-11-21 | 2012-12-26 | 株式会社富士通アドバンストエンジニアリング | コンピュータプログラム、データ捕捉装置、データ捕捉方法及びデータ管理システム |
| US9042244B2 (en) | 2008-12-25 | 2015-05-26 | Panasonic Intellectual Property Corporation Of America | TCP transmission control device and method of control of TCP transmission |
| JP2011249922A (ja) * | 2010-05-24 | 2011-12-08 | Nec Access Technica Ltd | ネットワーク装置、ｔｃｐパケット受信装置及び方法 |
-
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) | Ｔｃｐ通信方法 | |
| 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) | マルチｔｃｐ確認応答を用いたｔｃｐ輻輳制御システム及びその方法 | |
| JP4921569B2 (ja) | オフロードユニットを使用したｔｃｐ接続のためのデータ処理 | |
| JP3604615B2 (ja) | 通信装置、中継装置および通信制御方法 | |
| US11477130B2 (en) | Transmission control method and apparatus | |
| EP1359724B1 (en) | Method to offload a network stack | |
| KR100988339B1 (ko) | 무선 인터페이스를 통해 ｔｃｐ 성능을 개선시키기 위한 이중 프록시 접근 방식 | |
| 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 | |
| WO2004054207A2 (en) | Apparatus for implementing a lightweight, reliable, packet-based transport protocol | |
| 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 |