JP2002084289A - Ｔｃｐ通信方法 - Google Patents

Abstract

(57)【要約】 【課題】 ネットワークで広く用いられている例えば１
５００バイト程度の小さなパケットサイズを変更するこ
となく、端末において大きなパケットサイズによる効率
的なＴＣＰ通信を可能にする。 【解決手段】 通信ボード１上のＣＰＵを利用してＴＣ
Ｐレベルでパケットの分割及び組立を行うことによりＴ
ＣＰ通信を高速化する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はＴＣＰ通信を高速化
する技術に関する。

【０００２】

【従来の技術】通常のイーサネット（登録商標）では、
ＩＰの最大パケット長(Maximum Transfer Unit size:以
下、ＭＴＵサイズと呼ぶ）は１５００バイトであり、Ｔ
ＣＰの最大ユーザデータ長(Maximum Segment Siz: 以
下、ＭＳＳと呼ぶ）はＭＴＵサイズからＩＰ及びＴＣＰ
のヘッダ領域を除いた１４６０バイトである。

【０００３】このように通常のイーサネットでは、ＴＣ
Ｐの最大ユーザデータ長ＭＳＳが小さいために、パケッ
ト単位で行われるＴＣＰやＩＰのプロトコル処理、並び
に、ホスト端末と通信ボード間のデータ転送処理がホス
ト端末に対して大きなオーバヘッドとなり、この処理オ
ーバヘッドがＴＣＰ通信の高速化を妨げている。

【０００４】これらの処理オーバヘッドを減らすために
は、より大きなＭＳＳを用いることが望まれる。

【０００５】一方、近年、ギガビットイーサネット（Ｇ
ｉｇａ ｂｉｔｓ Ｅｔｈｅｒｎｅｔ（登録商標）：以
下、ＧｂＥと呼ぶ）の普及に伴い、ホスト端末において
もギガビットクラスの広い帯域を利用可能になってい
る。しかし、ＧｂＥで標準的に用いられているＭＴＵサ
イズは通常のイーサネットと同じ１５００バイトである
ため、現状のホスト端末ではやはり、パケット単位で行
われるプロトコル処理、並びに、ホスト端末と通信ボー
ド間のデータ転送処理が大きなオーバヘッドとなる。

【０００６】その解決策として、フレーム長を独自に長
く拡張したイーサネットフレーム（以下、ジャンボフレ
ームと呼ぶ）を用いてＭＴＵサイズを拡大する方法が提
案されている（例えば、ＭＴＵサイズ：８８００バイ
ト、ＭＳＳ：８７６０バイト）。しかし、この方法には
下記に示す問題点がある。 (1) 原則として、サブネットを構成するホスト端末、並
びに、スイッチやルータ等のネットワーク機器全てが、
ジャンボフレームをサポートする必要がある。このた
め、ジャンボフレームをサポートしない既存のホスト端
末とは同一のサブネットを構成できない。 (2) 通信経路上の、広域網を含む全てのリンクにおける
ＭＴＵサイズ（以下、パスＭＴＵサイズと呼ぶ）が例え
ば８８００バイト以上と大きい必要がある。そうでない
場合は、ルータでのＩＰパケットの分割（ＩＰフラグメ
ンテーション) や、ホスト端末でのパスＭＴＵサイズに
応じたパケットサイズの調整（最大セグメントサイズの
交換、パスＭＴＵディスカバリー(path MTU discover
y)）が起きるため、大きなサイズのパケットで通信する
ことは不可能である。

【０００７】

【発明が解決しようとする課題】本発明の課題は、パス
ＭＴＵサイズよりも大きなＭＴＵサイズをホスト端末に
提供することができるＴＣＰ通信方法を提供することで
ある。

【０００８】

【課題を解決するための手段】請求項１に係る発明は上
記課題を解決するＴＣＰ通信方法であり、端末本体に搭
載される通信ボード上のＣＰＵ（オンボードＣＰＵ）を
利用してＴＣＰレベルでパケットの分割及び組立を行う
ことを特徴とする。請求項２に係る発明は、請求項１に
おいて、前記端末本体のＴＣＰモジュールから送信され
た１つのデータセグメントを前記通信ボード上で適切な
ＴＣＰ／ＩＰヘッダを持つ複数のデータセグメントに分
割してネットワークへ出力し、前記ネットワークから入
力された複数のデータセグメントを前記通信ボード上で
１つのデータセグメントに組み立てた後、前記ＴＣＰモ
ジュールに通知することを特徴とするＴＣＰ通信方法で
ある。

【０００９】請求項３に係る発明は、請求項２におい
て、分割前のデータセグメントに対するＡＣＫパケット
の増加、並びに、組立前のデータセグメントに対するＡ
ＣＫパケットの減少を前記通信ボード上で調整し、これ
らＡＣＫパケットの増減がＴＣＰの輻輳制御や再送処理
等の制御手順へ及ぼす影響を防ぐことを特徴とするＴＣ
Ｐ通信方法である。請求項４に係る発明は、請求項３に
おいて、送受信シーケンス番号及びＡＣＫ番号をＴＣＰ
コネクション毎に保持するコネクションテーブルを前記
通信ボード上に用意し、前記コネクションテーブルを参
照して前記ＡＣＫパケットの増減を調整することを特徴
とするＴＣＰ通信方法である。

【００１０】請求項５に係る発明は、請求項２におい
て、通信経路上のネットワークを含む全てのリンクにお
けるＭＴＵサイズ（以下、パスＭＴＵと呼ぶ）と、ネッ
トワークに対するＭＴＵサイズ（以下、ネットＭＴＵと
呼ぶ）を比較し、パスＭＴＵ≧ネットＭＴＵである場合
はネットＭＴＵに基づいて前記データセグメントの分割
を行い、パスＭＴＵ＜ネットＭＴＵである場合はパスＭ
ＴＵに基づいて前記データセグメントの分割を行うこと
を特徴とするＴＣＰ通信方法である。請求項６に係る発
明は、請求項５において、宛先ＩＰアドレス毎にパスＭ
ＴＵ情報を参照して、前記パスＭＴＵに基づくデータセ
グメントの分割を行うことを特徴とするＴＣＰ通信方法
である。

【００１１】請求項７に係る発明は、請求項１におい
て、ＵＤＰのようにメッセージ境界を保つ必要があるプ
ロトコルのパケットに対してはＩＰレベルでパケットの
分割及び組立を行うことを特徴とするＴＣＰ通信方法で
ある。

【００１２】請求項８に係る発明は上記課題を解決する
他のＴＣＰ通信方法であり、ＴＣＰを処理するＴＣＰモ
ジュール及びＩＰを処理するＩＰモジュールを有する端
末本体と、ＣＰＵ及びメモリを有し、ネットワーク及び
前記ホストに接続される通信ボードと、該通信ボードの
ＣＰＵ（オンボードＣＰＵ）上で動作するファームウェ
アと、前記端末本体が有するＣＰＵ（ホストＣＰＵ）で
動作する、前記通信ボード用のデバイスドライバとによ
りＴＣＰ通信を行うこと、前記ファームウェアは、ＴＣ
Ｐコネクションの確立を監視し、該ＴＣＰコネクション
の確立手順を利用することより、前記端末本体が前記ネ
ットワーク上のパケットサイズよりも大きなパケットサ
イズを利用することを可能にする第１機能と、前記通信
ボードへ前記端末本体から分割されてＤＭＡ転送された
ＴＣＰセグメントに適切なＴＣＰヘッダを付加し、前記
通信ボードから前記ネットワークへ転送する第２機能
と、前記ネットワークから前記通信ボードが受信したパ
ケットをＴＣＰコネクション毎にまとめて１つのパケッ
トとして前記端末本体へ通知する第３機能を提供するこ
と、前記デバイスドライバは、前記端末本体から前記通
信ボードへ渡されるべきパケットを、メモリコピーを行
うことなく、前記通信ボードでのＴＣＰヘッダの付加を
考慮して分割し、通信ボードの前記メモリにＤＭＡ転送
する機能を提供することを特徴とする。請求項８に係る
発明は、請求項８において、前記ファームウェアは、前
記第１、第２及び第３機能により生じる前記端末本体か
ら前記通信ボードへのＡＣＫパケットの減少、並びに、
前記ネットワークから前記通信ボードへのＡＣＫパケッ
トの増加を防ぐ第４機能を提供することを特徴とするＴ
ＣＰ通信方法である。

【００１３】

【発明の実施の形態】図面を参照して、本発明の実施形
態例に係るＴＣＰ通信方法を説明する。

【００１４】［発明の基本］本方法では、通信ボード上
のＣＰＵ（オンボードＣＰＵ）を利用してパケットの分
割及び組立を行うことにより、ネットワークに対しては
標準のイーサネットと同じＭＴＵサイズを使用しつつ、
端末本体のＴＣＰやＩＰ等のプロトコルモジュールにお
いて大きなパケットの利用を可能とする。このため、通
信ボード用のデバイスドライバでは、端末本体のＩＰモ
ジュールに対して、ネットワークに対するＭＴＵサイズ
（以下、ネットＭＴＵと呼ぶ）とは独立した、大きなＭ
ＴＵサイズ（以下、ホストＭＴＵと呼ぶ）を提供する。

【００１５】ＴＣＰでは、コネクション確立時に交換す
るＭＳＳを越えるセグメントを送信してはならない。一
方、ＭＳＳの値はＭＴＵサイズに依存するため、大きな
ＭＴＵサイズを持たない既存の端末では、大きなセグメ
ントを使用することが不可能である。そこで、既存端末
とのＴＣＰ通信においても、本方法を適用できるよう
に、パケット分割・組立をＩＰではなくＴＣＰレベルで
行う。即ち、端末本体のＴＣＰモジュールから送信され
た１つのＤＴ（データセグメント）を、通信ボード上
で、それぞれ適切なＴＣＰ／ＩＰヘッダを持つ複数のＤ
Ｔに分割してネットワークへ出力する。また、ネットワ
ークから入力された複数のＤＴを、通信ボード上で１つ
のＤＴに組み立てた上で、端末本体のＴＣＰモジュール
へ通知する。一方、ＵＤＰ（ユーザデータグラムプロト
コル）のようなメッセージ境界を保つ必要があるプロト
コルに対しては、通信ボード上でＩＰレベルのパケット
分割・組立（ＩＰフラグメンテーションとリアセンブ
リ）を行う高速化を図る。

【００１６】上記の処理により、ＴＣＰ通信において
は、端末本体のＴＣＰモジュールで処理される１つのＤ
Ｔは、ネットワーク上で転送される複数のＤＴに対応す
ることになる。このため、既存の端末との通信を想定し
た場合、分割前のＤＴに対するＡＣＫ（確認応答）の数
はは多くなり、逆に、組立前のＤＴに対するＡＣＫの数
は少なくなることが予想される。一方、ＴＣＰのslow s
tart（スロータート）手順やcongestion avoidance（コ
ンジェスチョンアボイダンス）手順、あるいは、fast r
ecovery （ファーストリカバリ）手順において参照され
る輻輳ウインドウ(cwnd)はＡＣＫ受信により更新され
る。また、fast retransmit（ファーストリトランスミ
ット）手順では受信したＡＣＫを調べてパケット紛失を
検出する。これらのため、通信ボード上でＡＣＫの数並
びにその内容を調整し、これらの制御手順への影響を抑
える。

【００１７】ＡＣＫ調整を行うために、通信ボード上で
個々のＴＣＰコネクション毎に、送受信シーケンス番号
やＡＣＫ番号を登録し参照する。そこで、これらの情報
（ＴＣＰコネクション毎の送受信シーケンス番号やＡＣ
Ｋ番号）を保持するためのコネクションテーブルを通信
ボード上に用意する。また、パスＭＴＵ＜ネットＭＴＵ
である場合は、パケット分割は、ネットＭＴＵではなく
パスＭＴＵに基づいて行う。このため、パスＭＴＵ＜ネ
ットＭＴＵである場合は、宛先ＩＰアドレス毎にパスＭ
ＴＵ情報を参照できるようにする。

【００１８】端末の収容先としては、基本的には１５０
０バイトのＭＴＵサイズを持つ標準のイーサネットセグ
メントを想定しているが、これより大きなＭＴＵサイズ
を持つイーサネットセグメントへ収容した場合も動作可
能である。

【００１９】［全体構成］図１に本例に係るＴＣＰ通信
方法の全体構成を示す。図１において、１は通信ボー
ド、２はデバイスドライバ、３はＴＣＰ／ＩＰモジュー
ルである。通信ボード１はオンボードＣＰＵを有する市
販のＰＣＩバス用ＧｂＥボード（例えば、Alteon Websy
stems ACEnic（アルテオン・ウェブシステムズ社のエー
スニック）)には用い、本発明実現のため、ＧｂＥボー
ドのオンボードＣＰＵ（図示省略）上で動作する高速デ
ータ通信ソフトウェア（ファームウェア）を改修してあ
る。また、ＧｂＥボードに搭載されたＰＣＩ／ＧｂＥコ
ントロール用ＡＳＩＣ中には、2 つのＲＩＳＣ−ＣＰＵ
(MIPS R4000 相当）が組み込まれており、端末本体（図
示省略）からダウンロードされたファームウェアによっ
て、送信パケットと受信パケットに対して付加的な処理
を行うことができるようにしてある。デバイスドライバ
２は端末本体と通信ボード１との間のデータ転送を制御
するための通信ボード１用デバイスドライバであり、端
末本体が有するＣＰＵ（ホストＣＰＵ：図示省略）で動
作する。デバイスドライバ２には、本発明実現のため、
ＧｂＥボード用デバイスドライバを改修して用いてい
る。ＴＣＰ／ＩＰモジュール３はＴＣＰを処理するＴＣ
Ｐモジュール及びＩＰを処理するＩＰモジュールであ
り、端末本体に備えられている。その他、端末本体はメ
モリ等を備え、ジャンボフレームをサポートしている。
端末本体にはＵＮＩＸ（登録商標）コンピュータを用い
ている。

【００２０】ファームウェアはデバイスドライバ２と協
調してＴＣＰレベルのパケット分割・組立機能を提供
し、ＴＣＰを用いた通信に対して効率的なホストバスイ
ンターフェースを提供する。デバイスドライバ２は端末
本体のＯＳ（例えばＵＮＩＸ）のカーネルの一部として
実装され、カーネル内に予め用意されているＩＰ等のプ
ロトコルモジュールと協調して動作する。また、端末本
体は、ファームウェア並びにデバイスドライバ２に実装
した機能に対する各種パラメータの設定並びに統計情報
の取得を行うための制御用ソフトウェアを有する。これ
はユーザプロセスである。

【００２１】［ファームウェアとデバイスドライバ］上
記の機能を実現するため、通信ボードのファームウェア
並びに端末本体のデバイスドライバ２では、以下の処理
(1) 〜(5) を行う。

【００２２】(1) デバイスドライバ２からＩＰモジュー
ルに対し、１５００バイト以上のＭＴＵサイズを通知す
る。通知するＭＴＵサイズは制御プログラムにより可能
とし、例えば最大で３６０００バイトとする。デフォル
ト値は８８００バイトとする。このＭＴＵサイズはホス
トＭＴＵである。

【００２３】(2) ファームウェアでは、ＴＣＰコネクシ
ョンの確立を監視して、必要に応じて、対応するＴＣＰ
コネクションテーブルを作成する。このテーブルの最大
数はデフォルトで１６とするが、コンパイルオプション
により変更可能としている。ＴＣＰレベルのパケット分
割・組立機能は、このＴＣＰコネクションテーブルが作
成されているコネクションに対してのみ適用する。

【００２４】(3) ＴＣＰではコネクション確立時に交換
するＳＹＮパケット並びにＳＹＮ＋ＡＣＫパケットを用
いてＭＳＳを互いに交換するため、ファームウェアで必
要に応じてこれを書き換え、ＴＣＰモジュールに大きな
ＭＳＳを通知する。

【００２５】(4) 上位プロトコルモジュールから渡され
たパケットを、送信側ファームウェアにより、制御用ソ
フトウェアにより指定されたＭＴＵサイズでネットワー
クに出力できるようにする。このＭＴＵサイズはボード
ＭＴＵである。このために、付加するヘッダを含む送信
パケットを連続したオンボードメモリ（通信ボード１）
上に置く。そこで、デバイスドライバ２において以下の
手順（ａ）、（ｂ）を用いることにより、デバイスドラ
イバ２自身並びに通信ボード１上において不要なデータ
コピーを行うことなく、分割した各パケットに対して通
信ボード１上で容易にヘッダを付加できるようにする。 （ａ）デバイスドライバ２では、分割する各パケット毎
にＤＭＡ(Direct MemoryAccess)転送要求を設定する。
この際、先頭パケット以外は、ＤＭＡ転送を開始するア
ドレスをヘッダ領域分、前にずらす( 図１の（ａ）参
照) 。パケット本体のコピーは行わない。 （ｂ）ファームウェアでは、先頭パケットのヘッダ情報
を基に各パケットのヘッダを作成し、各パケットの先頭
部分を上書きして送信する（図１の（ｂ）参照）。

【００２６】(5) 受信側のファームウェアでは、ネット
ワークから受信したパケットをできる限り大きなパケッ
トサイズでデバイスドライバに通知するために、以下に
示す方針（ａ）〜（ｅ）に従って組み立てる。 （ａ）受信したフレームがＴＣＰセグメントであり、且
つ、対応するコネクションテーブルが存在する場合は、
原則として、端末本体に対して受信通知のための割り込
みをかけず、端末本体へのＤＭＡ転送のみ行い、次のフ
レームの受信を待つ。 （ｂ）次の受信フレームが、受信済み（但し、端末本体
には未通知）のＴＣＰセグメントに連続するＴＣＰセグ
メントである場合は、受信フレームからＴＣＰ／ＩＰヘ
ッダ等を取り除いて、１つのＴＣＰセグメントに結合さ
れるようにＤＭＡ転送する。結合されたＴＣＰセグメン
トに対するＴＣＰ／ＩＰヘッダの書き換えも同時に行
う。 （ｃ）セグメント紛失等により連続するＴＣＰセグメン
トを受信しなかった場合や、上記の結合処理によってホ
ストＭＴＵを超えたＴＣＰセグメントとなる場合等、パ
ケット組立が不可能である場合は、これ以前に受信した
未通知のフレームのみを端末本体へ通知する。以降は、
セグメント紛失から回復するまで、該当するコネクショ
ンに属するセグメントの組立は行わない。 （ｄ）セグメント紛失を検出した場合（ｒｘ＿ｎｅｘｔ
！＝ｒｅｘ＿ｍａｘ）は、シーケンス番号（ＳＥＱ番
号）を持つセグメントのグループｒｘ＿ｇｌｅとｒｘ＿
ｍａｘ）を保持する。このグループが受信ホストから送
達確認（ＡＣＫ．ｎｏ≧ｒｘ＿ｍａｘ−ｒｅｘ）される
か、このグループまでのセグメントを再度、紛失なく連
続して受信した場合に、セグメント紛失が回復したと見
なす。 （ｅ）一定の待ち時間（ｄｅｌｉｖｅｒ＿ｔｉｍｅｏｕ
ｔ）経過後は、受信したフレームを端末本体へ通知す
る。

【００２７】［ＴＣＰ−ＡＣＫ補償機能］ＴＣＰレベル
のパケット分割を行うことにより、ＴＣＰモジュールか
ら渡された１つのＴＣＰセグメントに対して、複数のＡ
ＣＫパケットが返ることが予想される。このため、下記
の問題(1) 〜(2) が予想される。 (1) ＡＣＫ処理負荷が削減されない。 (2) スロースタート(slow start)時の輻輳ウインドウの
急増など、ＴＣＰ輻輳制御との不整合が発生する。

【００２８】一方、パケット組立を行う端末のＴＣＰモ
ジュールでは、大きなパケットサイズでプロトコル処理
を行うため、十分にＡＣＫパケットを送信できない可能
性があり、これによりＴＣＰの輻輳制御や再送制御に悪
影響を与える恐れがあると言う問題がある。

【００２９】これらの問題を解決するために、以下の要
領（ａ）〜（ｂ）により端末本体に通知するＴＣＰ−Ａ
ＣＫ（ユーザデータを含まない) を削減し、また、ネッ
トワーク側へ送出するＴＣＰ−ＡＣＫを増加させること
とする。

【００３０】（ａ）ＴＣＰ−ＡＣＫの削減（送信側) (i) ＴＣＰコネクションテーブルにＡＣＫ番号、並び
に、送信ＴＣＰセグメントのＳＥＱ番号を記録する。記
録するＳＥＱ番号は必要に応じて上書きする。 (ii)保持しているＴＣＰセグメントのＳＥＱ番号を送達
確認する場合、または、２×ホスト側ＭＳＳ−ボード側
ＭＳＳ（２＊ｈ＿ｍｓｓ−ｎ＿ｍｓｓ）を超えるＴＣＰ
パケットを新規に送達確認する場合、または、最もＳＥ
Ｑ番号の大きい送信済みパケットをＡＣＫする場合（Ａ
ＣＫ．ｎｏ＝＝ｓｎｄ＿ｍａｘ）に、ＡＣＫを端末本体
に通知する。 (iii) ＤＵＰＡＣＫ（重複ＡＣＫ：ＡＣＫ．ｎｏとＡＣ
Ｋ．ｗｉｎ（ウインドウサイズ）が前回と同じＡＣＫ）
では、ホスト側ＭＳＳ／ボード側ＭＳＳで与えられる個
数のＤＵＰＡＣＫ受信毎に端末本体へ通知する。

【００３１】（ｂ）ＴＣＰ−ＡＣＫの増加（受信側） (i) ＴＣＰセグメントが連続して２セグメント受信した
場合は、通信ボード１でＡＣＫを作成し送信する。但
し、原則として、３セグメント目を受信後に２セグメン
ト分のＡＣＫをする。 (ii)３セグメント目が受信されない場合は、ｄｅｌｉｖ
ｅｒ＿ｔｉｍｅｒ発火後、端末本体への通知と同時にａ
ｃｋ＿ｔｉｍｅｒを起動させる。ａｃｋ＿ｔｉｍｅｒ発
火までに端末本体からのＡＣＫ受信もしくはネットワー
クからのＤＴ受信がなければ、ＡＣＫを作成し送信る。 (iii) パケット紛失時は、前述のようにＤＴ受信毎にそ
のままホストに通知させ、適切にＤＵＰＡＣＫを発生さ
せる。

【００３２】従って、ＴＣＰ通信に対する動作手順は以
下のように定まる。

【００３３】［動作手順その１：コネクション確立とパ
スＭＴＵ設定］図２にＴＣＰコネクション確立に伴う処
理フローを示す。ＴＣＰでは、コネクション確立時に相
手から通知されたＭＳＳと自分のＭＳＳとを比較し、い
ずれあ小さい方のＭＳＳを使用する。このため、通信ボ
ード１とそのデバイスドライバ２では、コネクション確
立時に以下の処理(1) 〜(2) を行い、端末本体のＴＣＰ
モジュールで使用するＭＳＳを大きく保つと同時に、相
手端末に対しては、ネットＭＴＵ(netＭＴＵ）またはパ
スＭＴＵ（pathＭＴＵ）に基づくＭＳＳを通知する。更
に、必要であればパケット分割に用いるパスＭＴＵの設
定も行う。

【００３４】(1) 図２において、ＴＣＰモジュールから
のＳＹＮ（＋ＡＣＫ）を受信した場合（ステップＳ
１）、それに含まれるＭＳＳ（図２のＳＹＮ（＋ＡＣ
Ｋ）．ＭＳＳ）を、同じＩＰアドレス宛のパスＭＴＵが
あればこれに基づくＭＳＳに、無い場合はネットＭＴＵ
に基づくＭＳＳに更新し、相手端末に送信する（ステッ
プＳ２、Ｓ５）。受信がＳＹＮであれば、同時にコネク
ションテーブルも作成する（ステップＳ３、Ｓ４）。

【００３５】(2) ネットワークからのＳＹＮ（＋ＡＣ
Ｋ）を受信した場合（ステップＳ６）、それに含まれる
ＭＳＳ（図２のＳＹＮ（＋ＡＣＫ）．ＭＳＳ）と、同じ
ＩＰアドレス宛のパスＭＴＵがあればこれに基づくＭＳ
Ｓ（図２のnmss）と、無い場合はネットＭＴＵに基づく
ＭＳＳ（図２のnmss）と比較する（ステップＳ７、Ｓ
８）。前者が小さい場合は、nmssの更新、並びに、パス
ＭＴＵの登録あるいは更新を行う（ステップＳ９）。次
に、ホストＭＴＵに基づくＭＳＳを超えないようにnmss
を整数倍した値を、ＳＹＮ（＋ＡＣＫ）のＭＳＳとして
ＴＣＰジュールに通知する（ステップＳ１０、Ｓ１
３）。また、受信がＳＹＮであれば、コネクションテー
ブルを作成する（ステップＳ１１、Ｓ１２）。

【００３６】図３にコネクション確立時の通信シーケン
ス例を示す。ここでは、双方の端末で、ホストＭＴＵを
９０００バイト程度として、ネットＭＴＵに１５００ま
たは９０００バイトを使用した４種類の組み合わせａ〜
ｄに対するシーケンスを示している。

【００３７】図３より、いずれの組み合わせの場合も、
ネットワーク側のＭＳＳは小さい方のネットＭＴＵに基
づく適切な値（ａ〜ｃでは１４６０バイト、ｄでは８９
６０バイト）が設定され、端末側のＭＳＳもネットワー
ク側のＭＳＳの整数倍（ａ〜ｃでは８７６０バイト、ｄ
では８９６０バイト）となるように調整されていること
が判る。なお、ｄでは、双方の端末のネットＭＴＵが９
０００バイトであるため、端末間に９０００バイトより
小さいＭＴＵサイズを持つ経路が存在しなければ、パケ
ット分割は行われない。

【００３８】一方、ａ〜ｄの全ての場合で、より小さい
パスＭＴＵが通信経路中に存在する可能性もある。これ
は、データ転送中にＩＣＭＰunreachable が返送される
ことで検出できる。通信ボード１ではＩＣＭＰunreacha
ble に含まれる新しいパスＭＴＵの登録。更新を行い、
分割に用いるパケットサイズを調整する。

【００３９】［動作手順その２：データ転送時の手順］
図４に、本方法をサポートする端末間におけるデータ転
送開始直後の通信シーケンスを示す。以下、図４に沿っ
てデータ転送時の動作手順(1) 〜(5) を説明する。

【００４０】(1) 送信側のＴＣＰ並びにＩＰモジュール
は、動作手順その１んいより提供される大きなＭＳＳ
（８７６０バイト：以降、ホストＭＳＳと呼ぶ）並びに
ＭＴＵサイズを利用してプロトコル処理を行い、ＤＴ送
信を通信ボード１に要求する（図４中、（ａ）参照）。

【００４１】(2) 送信側の通信ボード１では、ＤＴを動
作手順その１により決定したＭＳＳ（１４６０バイト：
以降、ネットＭＳＳと呼ぶ）に適合するように分割し、
各々に適切なＴＣＰ／ＩＰヘッダを付加した上で送信す
る（図４中、（ｂ）参照）。

【００４２】(3) 受信側の通信ボード１では、ＤＴが正
しく連続受信されている間は、原則としてネットワーク
から受信したＤＴを即座にＴＣＰモジュールへは通知せ
ず、可能な限り大きなＤＴに組み立てる。ＤＴ通知は以
下のどちらかの条件（ａ）（ｂ）を満たした時点で行
う。 （ａ）ＤＴの長さ＞ホストＭＴＵ−ネットＭＴＵ（図４
中、（ｃ）参照）。 （ｂ）先頭ＤＴの受信後一定時間が経過（図４中、
（ｄ）参照）。

【００４３】(4) 一般的なＴＣＰの実装では、２つのＤ
Ｔを正しく受信する毎に、対応するＡＣＫ番号を持つＡ
ＣＫを１つ返す。ＤＴ送信側が本方法をサポートしてい
ない場合も同様の間隔でＡＣＫが返るように、以下の要
領（ａ）（ｂ）に従い受信側の通信ボード１でＡＣＫを
補填する。この際、ＴＣＰモジュールからのＡＣＫと重
複することを避けるようにしている。 （ａ）新たに２つのＤＴを送達確認可能である場合、次
のＤＴ受信時にＡＣＫを送信する（図４中、（ｅ）参
照）。但し、２つのＤＴ毎にＡＣＫを返すために、最後
に受信したＤＴはＡＣＫの対象に含めない。 （ｂ）上記(3) によるＤＴ通知時点で、新たに２つのＤ
ＴをＡＣＫできる場合はＡＣＫタイマを設定する（図４
中、（ｆ）〜（ｈ）参照）。このタイマは次のＤＴの受
信（図４中、（ｆ）参照）、もしくは、ＴＣＰモジュー
ルからのＡＣＫ応答（図４中、（ｇ）参照）によりキャ
ンセルされる。タイマが満了した場合は、通信ボード１
からＡＣＫを送信する（図４中、（ｈ）参照）。

【００４４】また、ＴＣＰモジュールからのＡＣＫにつ
いては、最後に送信したＡＣＫよりも新しい情報（ＡＣ
Ｋ番号、winsize)を含んでいれば送信側に転送する。こ
の際、通信ボード１でより進んだＡＣＫ番号を既に送信
側に通知している場合は、これに合わせてＡＣＫ番号と
ウインサイズ(winsize) を決定する（図４中、（ｉ）参
照）。

【００４５】(5) 一方、ＤＴ送信側の通信ボード１には
上記(4) により２つのＤＴ送信毎に１つのＡＣＫが戻
る。ＴＣＰモジュールにおいても、cwndを適切に更新す
るために、分割前の２つのＤＴに対して１つのＡＣＫが
通知されることが望ましい。また、silly window syndr
ome （シリーウインドウシンドローム）を避けるために
は、ホストＭＳＳ以上の受信ウインドウを通知すべきで
ある。逆に、Nagle algorithm(ナグルアルゴリズム) 、
keep alive（キープアライブ）、window probe（ウイン
ドウプローブ）等の手順では、受信したＡＣＫを必ず通
知すべきである。そこで通信ボード１では、下記（ａ）
（ｂ）（ｃ）いずれかの処理は見込まれる場合のみ、Ａ
ＣＫを通知する。 （ａ）ホストＭＴＵの２倍−ネットＭＴＵ以上のＤＴを
送信確認する（図４中、（ｊ）参照）。 （ｂ）干す炉ＭＴＵ以上の受信ウインドウが付与される
（図４中、（ｋ）参照）。 （ｃ）送達確認待ちのＤＴがなくなるか、既にない（図
４中、（ｌ）参照）。 なお、ＡＣｋ番号またはwinsize のいずれかに、ＴＣＰ
モジュールにまだ通知すべきでない小さな更新がある場
合は、これらを調整した上で通知する（図４中、（ｋ）
参照）。

【００４６】［動作手順その３：誤り回復時の手順］図
５に、ＤＴ紛失に伴う再送手順を含む通信シーケンス例
を示す。紛失ＤＴに回復手順は、双方の端末のＴＣＰに
よりエンド・エンドで提供される。以下、図５に従っ
て、ＴＣＰの誤り回復手順を考慮した方法の動作手順
(1) 〜(6) を説明する。

【００４７】(1) ＤＴ(29201:30661) の紛失を検出する
と、通信ボード１は既に受信組立済みのＤＴ(26281:292
01) を即座にＴＣＰモジュールへ通知する（図５中、
（ａ）参照）。以降、通信ボード１では、ＴＣＰモジュ
ールの誤り回復手順の完了を確認するまで、受信したＤ
Ｔの組立は行わない（図５中、（ｂ）参照）。

【００４８】(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 retrans
mit の開始前後で以下（ａ）（ｂ）のように処理を変え
る。 （ａ）fast retransmit を素早く開始させるために、Ｔ
ＣＰモジュールに同一のＡＣＫを既に通知済みか同化検
査し、通知済みであれば１つのＡＣＫを、そうでなけれ
ば２つのＡＣＫをＴＣＰモジュールに通知する。更に、
２つのduplicateＡＣＫいついては、受信次第ＴＣＰモ
ジュールに通知する（図５中、（ｅ）参照）。 （ｂ）その後は、fast recovery 手順でのcwndの急激な
増加を避けるために、ホストＭＴＵ／ネットＭＴＵ（比
の値）個に１つの割合で、duplicate ＡＣＫが通知され
るようにする。但し、fast retransmit 開始のために先
に通知した４つのＡＣＫを考慮して、次の（５番目）の
ＡＣＫ通知だけは、前のＡＣＫから数えてホストＭＴＵ
の４倍／ネットＭＴＵ（比の値）−３なる個数のduplic
ate ＡＣＫを受信した時点で行う。

【００５２】(5) ＴＣＰモジュールは、duplicate ＡＣ
Ｋを受信すると、ＤＴ(29201:37961) を再送する。通信
ボード１れは、これをネットＭＳＳに基づき分割し、先
頭のＤＴ(29201:30661) だけを送信する（図５中、
（ｆ）参照）。

【００５３】(6) 受信側の通信ボード１では、再送ＤＴ
(29201:30661) の受信により、紛失部分がなくなり受信
済みＤＴグループ[30661,43801] まで連続して受信した
状態となる。そこで通信ボード１では、rx＿max ＝4380
1 をrx＿max＿rec に記録し、再送ＤＴをＴＣＰモジュ
ールに通知する。そして、ＴＣＰモジュールから返送さ
れるＡＣＫ(a43801,w35040) により、誤り回復の完了を
確認する。これにより、以降の受信ＤＴ(45261:46721−
51101:52561 は組立可能となる（図５中、（ｇ）参
照）。一方、ＡＣＫが戻る前に受信したＤＴ(43801:452
61) は、誤り回復完了を検出する前であるため、受信後
すぐにＴＣＰモジュールへ通知されている（図５中、
（ｈ）参照）。本ＤＴはrx＿max＿rec に連続するた
め、ＡＣＫ(a43801,w35050) が戻った時点で、ＴＣＰモ
ジュールにより正常に連続受信されることが保証され
る。

【００５４】［動作手順その４：コネクション終了時の
手順］図６に、コネクション終了時の通信シーケンス例
を示す。本方法では、コネクション終了に伴う状態遷移
を簡素化するために、ＴＣＰモジュールからのコネクシ
ョン終了要求（ＦＩＮ）並びにその送達確認のみを監視
する。ＴＣＰモジュールからのＦＩＮが送達確認された
時点で、そのコネクションに対しては、通信ボード１に
新たなパケット送信要求か来ないことが保証されるた
め、該当するコネクションテーブルを削除することがで
きる。以下、図６を例に、コネクション終了時の手順
(1) 〜(3) を説明する。

【００５５】(1) 通信ボード１では、ＴＣＰモジュール
からＦＩＮフラグを有効にしたＤＴを渡されると、これ
がネットＭＳＳ以上のユーザデータを含むＤＴである場
合あ、これを通信ボード１で分割する。その際、ＦＩＮ
フラグは分割後の最後のＤＴのみ有効にする（図６中、
（ａ）参照）。

【００５６】(2) 一方、ネットワークから受信したＦＩ
Ｎセグメントについては、通信ボード１上で、通常のＤ
Ｔと同様、可能であれば前のＤＴに連結する。そして、
直ぐに、ＴＣＰモジュールへ通知する（図６中、（ｂ）
参照）。

【００５７】(3) ネットワークからＦＩＮに対するＡＣ
Ｋを受信すると、通信ボード１はこれをＴＣＰモジュー
ルへ通知し、コネクションテーブルを削除する（図６
中、（ｃ）参照）。以降は、通信ボード１はＴＣＰ通信
に介在せず、受信データをそのままＴＣＰモジュールへ
通知する（図６中、（ｄ）参照）。

【００５８】上述のように、通信ボード１のオンボード
ＣＰＵを利用して、ＴＣＰまで考慮したパケット分割と
組立を行うことにより、端末に大きなＭＴＵサイズを提
供するから、例えば標準のイーサネットと同じＭＴＵサ
イズ（１５００バイト）をネットワーク上で用いること
ができる。つまり、ネットワークでは広く使用されてい
る小さなパケットサイズを用いつつ、ホスト内では大き
なパケットサイズで効率良くＴＣＰのプロトコル処理を
行うことができる。このため、本方法をサポートする端
末のプロトコルモジュールでは、大きなＭＴＵサイズを
サポートしない既存の端末やネットワーク機器と接続し
た場合でも、大きなパケットで処理を行うことが可能と
なる。

【００５９】また、パケットの分割・組立により、端末
本体のＴＣＰモジュールにおける１つのデータセグメン
ト（ＤＴ）が、ネットワーク上における複数のデータセ
グメント（ＤＴ）に対応するので、本方法をサポートす
る端末が既存端末と通信した場合は、双方の端末が送受
信するＡＣＫ（確認応答）の数が変動するので、ＴＣＰ
の輻輳制御や再送処理に影響が現れる可能性があるが、
ＡＣＫ数の増減を調整することによりこの影響を抑制す
ることができる。

【００６０】つまり、ＴＣＰレベルのパケット分解・組
立を行うと、通信ボード１が端末本体ホストから受信す
るＡＣＫパケットが、通信ボード１が通信相手へ送信す
べきＡＣＫパケットよりも減少し、反対に、通信ボード
１が端末本体へ通知すべきＡＣＫパケットよりも、通信
ボード１が通信相手から受信するＡＣＫパケットが増加
する。このようなＡＣＫパケット数の不一致はＴＣＰ輻
輳制御機能等に副作用を与えるが、ＡＣＫパケット増減
を補償することにより、ＴＣＰ輻輳制御機能等に与える
副作用を防ぐことができる。

【００６１】更に、ＴＣＰ以外のパケット、例えばＵＤ
Ｐパケットについては、通信ボード１上でＩＰフラグメ
ンテーション（ＩＰ分割）並びにそのデフラグメンテー
ション（ＩＰ組立）を行うことにより、送信端末トや受
信端末トにおけるプロトコル処理の負荷が削減可能であ
る。

【００６２】また、端末本体と通信ボード１間でのＴＣ
Ｐレベルのパケット分解・組立には、メモリコピーを行
わず、ＤＭＡ転送を行うことにより処理時間を短縮する
ことができる。

【００６３】互いに通信する端末間の一方が上述の機能
をサポートすることにより、他方の端末及びネットワー
ク機器がジャンボフレームをサポートしない場合でも、
相互接続性を保証することができる。

【００６４】また、上述の機能を双方の端末がともにサ
ポートしていれば、ネットワーク機器がジャンボフレー
ムをサポートしない場合でも、全てジャンボフレームを
適用した場合と同様に、各端末上でＴＣＰ、ＩＰ、デバ
イスドライバ等の処理オーバヘッドを削減することが可
能である。

【００６５】

【発明の効果】本発明によれば、ネットワークで広く用
いられている例えば１５００バイト程度の小さなパケッ
トサイズを変更することなく、端末において大きなパケ
ットサイズによる効率的なＴＣＰ通信が可能となる。ま
た、パケットの分解・組立に伴うＡＣＫパケットの増大
・不足を補償することで、ＴＣＰ輻輳制御等との不整合
を防止することができ、ネットワークに対して従来と同
様の輻輳制御等を提供することが可能となる。このよう
な効果を持つ本発明は、ＦＰＧＡ等の（プログラマブ
ル）ロジックによる実装を通じた通信装置への適用等が
可能である。

【図面の簡単な説明】

【図１】本発明の実施形態例に係るＴＣＰ通信方法の全
体構成を示す図。

【図２】コネクション確立時の処理フローを示す図。

【図３】コネクション確立時の通信シーケンス例を示す
図。

【図４】データ転送時の通信シーケンス例を示す図。

【図５】再送時の通信シーケンス例を示す図。

【図６】コネクション終了時の通信シーケンス例を示す
図。

【符号の説明】

１ 通信ボード ２ デバイスドライバ ３ ＴＣＰ／ＩＰモジュール

───────────────────────────────────────────────────── フロントページの続き (72)発明者 加藤 聰彦 埼玉県上福岡市大原二丁目１番15号 株式 会社ケイディディ研究所内 Ｆターム(参考） 5K030 GA01 HA08 HB28 JA05 KA12 LA02 5K033 AA01 AA03 CB04 CB06 CC02 5K034 AA01 AA07 BB06 LL01 MM25

Claims (9)

【特許請求の範囲】
1. 【請求項１】 端末本体に搭載される通信ボード上のＣ
   ＰＵ（以下、オンボードＣＰＵと呼ぶ）を利用してＴＣ
   Ｐレベルでパケットの分割及び組立を行うことによりＴ
   ＣＰ通信を高速化することを特徴とするＴＣＰ通信方
   法。
2. 【請求項２】 請求項１において、前記端末本体のＴＣ
   Ｐモジュールから送信された１つのデータセグメントを
   前記通信ボード上で適切なＴＣＰ／ＩＰヘッダを持つ複
   数のデータセグメントに分割してネットワークへ出力
   し、前記ネットワークから入力された複数のデータセグ
   メントを前記通信ボード上で１つのデータセグメントに
   組み立てた後、前記ＴＣＰモジュールに通知することを
   特徴とするＴＣＰ通信方法。
3. 【請求項３】 請求項２において、分割前のデータセグ
   メントに対するＡＣＫパケットの増加、並びに、組立前
   のデータセグメントに対するＡＣＫパケットの減少を前
   記通信ボード上で調整し、これらＡＣＫパケットの増減
   がＴＣＰの輻輳制御や再送処理等の制御手順へ及ぼす影
   響を防ぐことを特徴とするＴＣＰ通信方法。
4. 【請求項４】 請求項３において、送受信シーケンス番
   号及びＡＣＫ番号をＴＣＰコネクション毎に保持するコ
   ネクションテーブルを前記通信ボード上に用意し、前記
   コネクションテーブルを参照して前記ＡＣＫパケットの
   増減を調整することを特徴とするＴＣＰ通信方法。
5. 【請求項５】 請求項２において、通信経路上のネット
   ワークを含む全てのリンクにおけるＭＴＵサイズ（以
   下、パスＭＴＵと呼ぶ）と、ネットワークに対するＭＴ
   Ｕサイズ（以下、ネットＭＴＵと呼ぶ）を比較し、パス
   ＭＴＵ≧ネットＭＴＵである場合はネットＭＴＵに基づ
   いて前記データセグメントの分割を行い、パスＭＴＵ＜
   ネットＭＴＵである場合はパスＭＴＵに基づいて前記デ
   ータセグメントの分割を行うことを特徴とするＴＣＰ通
   信方法。
6. 【請求項６】 請求項５において、宛先ＩＰアドレス毎
   にパスＭＴＵ情報を参照して、前記パスＭＴＵに基づく
   データセグメントの分割を行うことを特徴とするＴＣＰ
   通信方法。
7. 【請求項７】 請求項１において、ＵＤＰのようにメッ
   セージ境界を保つ必要があるプロトコルのパケットに対
   してはＩＰレベルでパケットの分割及び組立を行うこと
   を特徴とするＴＣＰ通信方法。
8. 【請求項８】 ＴＣＰを処理するＴＣＰモジュール及び
   ＩＰを処理するＩＰモジュールを有する端末本体と、Ｃ
   ＰＵ及びメモリを有し、ネットワーク及び前記ホストに
   接続される通信ボードと、該通信ボードの前記ＣＰＵ
   （オンボードＣＰＵ）上で動作するファームウェアと、
   前記端末本体が有するＣＰＵ（以下、ホストＣＰＵと呼
   ぶ）で動作する、前記通信ボード用のデバイスドライバ
   とによりＴＣＰ通信を行うこと、前記ファームウェア
   は、ＴＣＰコネクションの確立を監視し、該ＴＣＰコネ
   クションの確立手順を利用することより、前記端末本体
   が前記ネットワーク上のパケットサイズよりも大きなパ
   ケットサイズを利用することを可能にする第１機能と、
   前記通信ボードへ前記端末本体から分割されてＤＭＡ転
   送されたＴＣＰセグメントに適切なＴＣＰヘッダを付加
   し、前記通信ボードから前記ネットワークへ転送する第
   ２機能と、前記ネットワークから前記通信ボードが受信
   したパケットをＴＣＰコネクション毎にまとめて１つの
   パケットとして前記端末本体へ通知する第３機能を提供
   すること、前記デバイスドライバは、前記端末本体から
   前記通信ボードへ渡されるべきパケットを、メモリコピ
   ーを行うことなく、前記通信ボードでのＴＣＰヘッダの
   付加を考慮して分割し、通信ボードの前記メモリにＤＭ
   Ａ転送する機能を提供することを特徴とするＴＣＰ通信
   方法。
9. 【請求項９】 請求項８において、前記ファームウェア
   は、前記第１、第２及び第３機能により生じる前記端末
   本体から前記通信ボードへのＡＣＫパケットの減少、並
   びに、前記ネットワークから前記通信ボードへのＡＣＫ
   パケットの増加を防ぐ第４機能を提供することを特徴と
   するＴＣＰ通信方法。