JP2009152953A - ゲートウェイ装置およびパケット転送方法 - Google Patents

ゲートウェイ装置およびパケット転送方法 Download PDF

Info

Publication number
JP2009152953A
JP2009152953A JP2007329803A JP2007329803A JP2009152953A JP 2009152953 A JP2009152953 A JP 2009152953A JP 2007329803 A JP2007329803 A JP 2007329803A JP 2007329803 A JP2007329803 A JP 2007329803A JP 2009152953 A JP2009152953 A JP 2009152953A
Authority
JP
Japan
Prior art keywords
packet
ack
sequence number
header
entry
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.)
Withdrawn
Application number
JP2007329803A
Other languages
English (en)
Inventor
Yuichi Ishikawa
雄一 石川
Ichiro Yamaguchi
一郎 山口
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.)
NEC Corp
Original Assignee
NEC Corp
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 NEC Corp filed Critical NEC Corp
Priority to JP2007329803A priority Critical patent/JP2009152953A/ja
Priority to US12/337,983 priority patent/US7969976B2/en
Publication of JP2009152953A publication Critical patent/JP2009152953A/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】クライアント−サーバ間のＴＣＰコネクションを終端せずに転送パケットのＡＰヘッダを書換える。
【解決手段】ゲートウェイモジュール１１０の変換部１１６は、パケットの転送時に、次に転送するパケットのＴＣＰヘッダに含まれることが予想されるシーケンス番号（Ｓｅｑ＃）とＡＰヘッダの書換えによるパケットサイズの変更を考慮して求めた変換後のＳｅｑ＃との組を、予想Ｓｅｑ＃及び変換Ｓｅｑ＃の組、並びに、前記転送したパケットの転送方向と逆の転送方向におけるパケットのＴＣＰヘッダに含まれる予想Ａｃｋ＃及び変換Ａｃｋ＃の組として変換テーブル１１７に登録する。そして、変換部１１６は、次のパケットの転送時に、変換テーブル１１７を参照して、転送するパケットのＴＣＰヘッダに含まれるＳｅｑ＃およびＡｃｋ＃を、それらに一致する予想Ｓｅｑ＃および予想Ａｃｋ＃に対応する変換Ｓｅｑ＃および変換Ａｃｋ＃に書換える。
【選択図】図１

Description

本発明は、端末間のＴＣＰコネクション上を流れるパケットのデータを書換えて転送するゲートウェイ装置に関する。
クライアント−サーバ間で送受信されるメッセージの転送を行うゲートウェイにおいて、アプリケーションヘッダ（以下ＡＰヘッダ）の書換えを行う仕組みが広く利用されている。
たとえば、ＳＩＰにおいては、プライベートネットワークに接続したクライアントがグローバルネットワークに設置されたサーバへメッセージを送信する際に、ゲートウェイにおいてＡＰヘッダの書換えが行われる。ＳＩＰでは、クライアントが送信するメッセージのＡＰヘッダにクライアントのＩＰアドレスが含まれており、サーバはこのＩＰアドレスを宛先アドレスとしてクライアントへメッセージを送信する。若し、クライアントがサーバへ送信したメッセージに含まれるＩＰアドレスがプライベートアドレスのままであると、メッセージの送信が失敗するため、前述のようにゲートウェイにおいてクライアント送信メッセージのＡＰヘッダに含まれるＩＰアドレスをグローバルアドレスに変換している。
また、サーバのマルチテナント利用（複数のクライアントグループ（テナント）で単一のサーバをあたかもテナント専用のサーバであるかのように安全に共用する利用形態）を実現するために、ゲートウェイにおいてメッセージのＡＰヘッダ書換えを行う場合もある。
たとえば、特許文献１には、ＷＥＢキャッシュサーバをマルチテナントで利用するために、ゲートウェイがメッセージ転送の際にＡＰヘッダの書換えを行う方法が記載されている。ゲートウェイは、クライアントがＷＥＢキャッシュサーバへ送信するＨＴＴＰメッセージのＡＰヘッダに含まれる宛先ＵＲＬに、クライアントが所属するテナントの識別子を強制的に挿入する。こうすることで、ＷＥＢキャッシュサーバにはテナント識別子付きのＵＲＬでキャッシュが蓄積されるとともに、キャッシュアクセスもテナント識別子付きのＵＲＬで行われるため、キャッシュは同一テナントのクライアント間でしか閲覧できず、複数テナントで単一のＷｅｂキャッシュサーバを安全に共用できるようになる。
また、特許文献２には、ＳＩＰサーバをマルチテナントで利用するために、ゲートウェイがメッセージ転送の際にＡＰヘッダの書換えを行う方法が記載されている。ゲートウェイは、クライアントがＳＩＰサーバへ送信するＳＩＰメッセージのＡＰヘッダに含まれる送信元ＵＲＩならびに宛先ＵＲＩへ、クライアントが所属するテナントの識別子を強制的に挿入する。こうすることで、ＳＩＰサーバにはテナント識別子付きのＵＲＩでクライアント情報が蓄積されるとともに、クライアント情報へのアクセスもテナント識別子付きのＵＲＩで行われるため、クライアント情報が同一テナントに属するクライアント間でしか利用できず、複数テナントで単一のＳＩＰサーバを安全に共用できるようになる。
上述のように、ゲートウェイがクライアント−サーバ間で送受信されるメッセージのＡＰヘッダを書換えて転送する場合、ＡＰヘッダの書換えに伴ってパケットサイズが変わると、クライアントまたはサーバが送信した際のパケットサイズとサーバまたはクライアントが受信した際のパケットサイズが異なる場合がある。このため、トランスポート層のプロトコルにＴＣＰを使用する場合、ゲートウェイがクライアントまたはサーバから受信したパケットのシーケンス番号（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ。以下、Ｓｅｑ＃と記す）と確認応答番号（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ Ｎｕｍｂｅｒ。以下、Ａｃｋ＃と記す）を書換えずにそのままサーバまたはクライアントに転送すると、サーバおよびクライアントはＳｅｑ＃およびＡｃｋ＃からパケットロスを正しく把握できなくなる。このため、ＡＰヘッダの書換えに伴ってパケットサイズが変わる場合には、ゲートウェイにおいてＴＣＰコネクションの終端処理を行っている。
他方、ゲートウェイにおいてＡＰヘッダを書換えないか、或いは書換えてもパケットサイズが変わらない場合には、ＴＣＰコネクションの終端処理を行わないことで、ゲートウェイの処理負荷を軽減することができる。そのような技術の一例が特許文献３に記載されている。特許文献３に記載される技術では、クライアントとサーバとの間に中継装置としての交換機が介在しており、クライアントと交換機との間に確立したＴＣＰコネクションと、交換機とサーバとの間に確立したＴＣＰコネクションとを１つに接続することにより、クライアントとサーバとのそれぞれにＴＣＰによるパケットの再送およびフロー制御を行わせ、交換機が当該ＴＣＰコネクションに関する再送制御やフロー制御を行う必要がないようにしている。具体的には、クライアントと交換機との間にＴＣＰコネクションが張られた際のクライアントの初期Ｓｅｑ＃をＳＣ、交換機の初期Ｓｅｑ＃をＳＵ、サーバと交換機との間にＴＣＰコネクションが張られた際のサーバの初期Ｓｅｑ＃をＳＳ、交換機の初期Ｓｅｑ＃をＳＶとする場合、Ｓｅｑ／Ａｃｋ＃を以下のように書換える。まず、サーバからクライアントへ送られるパケットのＳｅｑ＃は「パケット中のＳｅｑ＃＋ＳＵ−ＳＳ」に書換え、Ａｃｋ＃は「パケット中のＡｃｋ＃＋ＳＣ−ＳＶ」に書換える。また、クライアントからサーバへ送られるパケットのＳｅｑ＃は「パケット中のＳｅｑ＃＋ＳＶ−ＳＣ」に書換え、Ａｃｋ＃は「パケット中のＡｃｋ＃＋ＳＳ−ＳＵ」に書換える。
特開２００４−３０３０９号公報 特開２００７−１５７０８５号公報 特許第３６４２３０５号公報
上述したように従来においては、ＡＰヘッダの書換えに伴ってパケットサイズが変わる場合、ゲートウェイにおいてＴＣＰコネクションの終端処理を行っている。このため、ゲートウェイにＴＣＰコネクションの終端処理に伴う負荷がかかっていた。具体的には、ゲートウェイには主に以下の処理に伴う負荷がかかっていた。
（A）再送制御
（1）クライアント（またはサーバ）から通知されるＡｃｋ＃をチェックして転送パケットがクライアント（またはサーバ）に届いていることを確認し、パケットロスの発生時にパケットの再送を行うための処理負荷。
（2）パケットロス発生に備えクライアント（またはサーバ）からＡｃｋ＃を受信するまで、サーバ（またはクライアント）から受信したパケットをバッファリングしておくための処理負荷。
（B）フロー制御
（1）ネットワークにおいて輻輳が発生した際に輻輳を悪化させないように、ネットワークの輻輳状態（パケットロス）に応じてクライアントまたはサーバからＡｃｋを受け取らずに一度に転送可能なパケットの数を調整するための処理負荷。
（2）自身のパケットバッファ空き容量に応じて受信可能なパケット数を計算し、クライアントまたはサーバへ通知するための処理負荷。
（C）ユーザランドとカーネルランド間のパケットコピー
上記Ａ、Ｂの処理はカーネルランドで動作するＴＣＰスタックにおいて実施されるのに対して、ＡＰヘッダの書換えはユーザランドで動作するプログラムがＴＣＰスタックからＴＣＰソケットを利用しパケットに含まれるデータをストリーム形式で受け取って処理するため、ユーザランドとカーネルランド間でデータのコピーを頻繁に行うことによる処理負荷。
本発明の目的は、クライアント−サーバ間など端末間のＴＣＰコネクションを終端せずに転送パケットのＡＰヘッダを書換えることが可能なゲートウェイを提供することで、上述したＡ〜Ｃの処理に伴う負荷を無くし、端末間のメッセージ転送性能を改善することにある。
本発明の第１のゲートウェイ装置は、端末間のＴＣＰコネクションを流れるパケットのＴＣＰヘッダ以降のデータであるＡＰヘッダを書換えて転送するゲートウェイ装置であって、パケットの転送時に、次に転送するパケットのＴＣＰヘッダに含まれることが予想されるシーケンス番号とＡＰヘッダの書換えによるパケットサイズの変更を考慮して求めた変換後のシーケンス番号との組を、予想シーケンス番号および変換シーケンス番号の組、ならびに、前記転送したパケットの転送方向と逆の転送方向におけるパケットのＴＣＰヘッダに含まれる予想Ａｃｋ番号および変換Ａｃｋ番号の組として登録するエントリを有する番号変換テーブルと、パケットの転送時に、前記番号変換テーブルを参照して、転送するパケットのＴＣＰヘッダに含まれるシーケンス番号およびＡｃｋ番号を、それらに一致する予想シーケンス番号および予想Ａｃｋ番号に対応する変換シーケンス番号および変換Ａｃｋ番号に書換える番号書換処理を行う変換手段とを備える。
本発明の第１のパケット転送方法は、ゲートウェイ装置において端末間のＴＣＰコネクションを流れるパケットのＴＣＰヘッダ以降のデータであるＡＰヘッダを書換えて転送する方法であって、前記ゲートウェイ装置が、パケットの転送時に、次に転送するパケットのＴＣＰヘッダに含まれることが予想されるシーケンス番号とＡＰヘッダの書換えによるパケットサイズの変更を考慮して求めた変換後のシーケンス番号との組を、予想シーケンス番号および変換シーケンス番号の組、ならびに、前記転送したパケットの転送方向と逆の転送方向におけるパケットのＴＣＰヘッダに含まれる予想Ａｃｋ番号および変換Ａｃｋ番号の組として番号変換テーブルに登録するステップと、前記ゲートウェイ装置が、パケットの転送時に、前記番号変換テーブルを参照して、転送するパケットのＴＣＰヘッダに含まれるシーケンス番号およびＡｃｋ番号を、それらに一致する予想シーケンス番号および予想Ａｃｋ番号に対応する変換シーケンス番号および変換Ａｃｋ番号に書換える番号書換処理を行うステップとを含む。
本発明によれば、パケットの転送時に、次に転送するパケットのＴＣＰヘッダに含まれるシーケンス番号とＡＰヘッダの書換えによるパケットサイズの変更を考慮して求めた変換後のシーケンス番号との組を、予想シーケンス番号および変換シーケンス番号の組、ならびに、前記転送したパケットの転送方向と逆の転送方向におけるパケットのＴＣＰヘッダに含まれる予想Ａｃｋ番号および変換Ａｃｋ番号の組として、番号変換テーブルのエントリに登録し、パケットの転送時に、前記番号変換テーブルを参照して、転送するパケットのＴＣＰヘッダに含まれるシーケンス番号およびＡｃｋ番号を、それらに一致する予想シーケンス番号および予想Ａｃｋ番号に対応する変換シーケンス番号および変換Ａｃｋ番号に書換えるため、転送されるパケットのサイズがＡＰヘッダの書換えによって変化しても、パケットの送信側および受信側がパケット中のシーケンス番号およびＡｃｋ番号からパケットロスを正しく把握することが可能となる。これにより、パケットの再送制御やフロー制御などのＴＣＰで行われる制御がパケットの送受信側で行われ、パケットを中継するゲートウェイ装置においてＴＣＰコネクションを終端する必要がなくなり、ゲートウェイ装置の負荷軽減が可能になる。
『第１の実施の形態』
次に、本発明の第１の実施の形態について図面を参照して詳細に説明する。
［構成の説明］
図１を参照すると、本発明の第１の実施の形態に係るゲートウェイモジュール１１０は、クライアント端末装置（以下クライアント）２００とサーバ端末装置（以下サーバ）３００との間のＴＣＰコネクションを終端することなく両端末間で送受信されるパケットをインターセプトし、アプリケーションヘッダ（以下ＡＰヘッダ）を書換えてから転送を行う。
本明細書では、ＡＰヘッダとは、クライアント２００およびサーバ３００上で稼働するアプリケーションプログラムがネットワークに送出するデータ全てを指す。アプリケーションプログラムの例としては、Ｗｅｂブラウザ／サーバなどに代表されるＨＴＴＰクライアント／サーバ、ＦＴＰクライアント／サーバやＳＩＰクライアント／サーバなどがあげられる。こうしたアプリケーションプログラムが送出するデータ（すなわちＡＰヘッダ）は、パケットのＴＣＰヘッダ以降に含まれ、ネットワーク上を流れる。
図２および図３にゲートウェイモジュール１１０の配置形態の例を示す。図２では、ゲートウェイモジュール１１０をゲートウェイノード１００を構成するコンピュータのユーザランドで動作するモジュールとして実装し、図３では、カーネルランドで動作するモジュールとして実装している。何れの構成においても、クライアント２００からサーバ３００へ送信されたパケットおよびその逆にサーバ３００からクライアント２００へ送信されたパケットが、ゲートウェイノード１００のＮＩＣ（ネットワークインタフェースカード）を通じてパケットフック部１３０で捕獲され、ゲートウェイモジュール１１０に伝達される。ゲートウェイモジュール１１０では、パケットに対してＡＰヘッダの書換えおよびＴＣＰヘッダのＳｅｑ／Ａｃｋ＃の書換えを行い、書換え後のパケットをＮＩＣを通じてサーバ３００またはクライアント２００へ転送する。
なお、ゲートウェイモジュール１１０は、図２および図３に示したようにクライアント２００やサーバ３００とは独立したゲートウェイノード１００上に配置されていても良いし、クライアント２００またはサーバ３００と同一のノードに配置されていても良い。また、ゲートウェイモジュール１１０には、図２および図３に示すように、ＴＣＰスタック１４０、このＴＣＰスタック１４０のＴＣＰソケット１４１−１〜１４１−ｎを利用してストリーム形式でデータの送受信を行うアプリケーションプログラム１５１〜１５ｎが実装されていても良い。
再び図１を参照すると、ゲートウェイモジュール１１０は、ＴＣＰコネクションハンドリング部１１１、コネクション管理テーブル１１２、ＡＰヘッダパース部１１３、書換位置管理テーブル１１４、ＡＰヘッダ書換部１１５、Ｓｅｑ／Ａｃｋ＃変換部（請求項の変換手段に相当）１１６およびＳｅｑ／Ａｃｋ＃変換テーブル（請求項の番号変換テーブルに相当）１１７を備えている。コネクション管理テーブル１１２、書換位置管理テーブル１１４およびＳｅｑ／Ａｃｋ＃変換テーブル１１７は、ゲートウェイモジュール１１０を構成するコンピュータの主記憶や補助記憶で実現される。ＴＣＰコネクションハンドリング部１１１、ＡＰヘッダパース部１１３、ＡＰヘッダ書換部１１５、Ｓｅｑ／Ａｃｋ＃変換部１１６といった機能手段は、ゲートウェイモジュール１１０を構成するコンピュータとプログラムとで実現することができる。プログラムは、磁気ディスクや半導体メモリ等のコンピュータ可読記録媒体に記録されて提供され、コンピュータの立ち上げ時などにコンピュータに読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータを各機能手段として機能させる。
(コネクション管理テーブル１１２)
コネクション管理テーブル１１２は、クライアント２００とサーバ３００間で構築されるＴＣＰコネクションに関する情報を保持する記憶手段である。１つのエントリで１つのＴＣＰコネクションの情報を管理する。各エントリには、図４に示すように、コネクションＩＤおよびＴＣＰコネクションに関する情報が登録される。ＴＣＰコネクションに関する情報としては、例えばクライアント２００およびサーバ３００のＩＰアドレスおよびポート番号などが含まれる。
(ＴＣＰコネクションハンドリング部１１１)
ＴＣＰコネクションハンドリング部１１１は、クライアント２００およびサーバ３００が送信したパケットを図２および図３に示したパケットフック部１３０から受け取って、Ｓｅｑ／Ａｃｋ＃変換部１１６に渡す機能を有する。また、Ｓｅｑ／Ａｃｋ＃変換部１１６から渡されたパケットを、その転送方向に応じてサーバ３００またはクライアント２００へ転送する機能を有する。
ＴＣＰコネクションハンドリング部１１１は、クライアント２００とサーバ３００間で送受信されるパケットによって新たにクライアント−サーバ間でＴＣＰコネクションが構築される場合、コネクション管理テーブル１１２にその構築されたＴＣＰコネクションに関する情報を登録した新たなエントリを作成し、ＴＣＰコネクションが削除される場合、コネクション管理テーブル１１２から対応するエントリを削除する。
（Ｓｅｑ／Ａｃｋ＃変換テーブル１１７）
Ｓｅｑ／Ａｃｋ＃変換テーブル１１７は、クライアント２００またはサーバ３００が送信するパケットのＳｅｑ＃及びＡｃｋ＃と、当該Ｓｅｑ＃またはＡｃｋ＃を持つパケットをサーバ３００またはクライアント２００に対して転送する際に変換すべきＳｅｑ＃およびＡｃｋ＃との対応関係が登録されている。Ｓｅｑ／Ａｃｋ＃変換テーブル１１７の例を図５および図６に示す。
この例では、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７は、パケットの転送方向がクライアント→サーバであるパケットに含まれるＳｅｑ／Ａｃｋ＃を変換するために使用するクライアント→サーバＳｅｑ／Ａｃｋ＃変換テーブル１１７−１（図５）と、パケットの転送方向がサーバ→クライアントであるパケットに含まれるＳｅｑ／Ａｃｋ＃を変換するために使用するサーバ→クライアントＳｅｑ／Ａｃｋ＃変換テーブル１１７−２（図６）とで構成される。
また、クライアント→サーバＳｅｑ／Ａｃｋ＃変換テーブル１１７−１は、Ｓｅｑ＃の変換に使用するクライアント→サーバＳｅｑ＃変換テーブル１１７−１１と、Ａｃｋ＃の変換に使用するクライアント→サーバＡｃｋ＃変換テーブル１１７−１２との２種類のテーブルで構成される。クライアント→サーバＳｅｑ＃変換テーブル１１７−１１には、コネクションＩＤと、そのコネクションを通じてクライアント２００から受信したパケットに含まれるＳｅｑ＃（予想Ｓｅｑ＃）と、当該Ｓｅｑ＃を持つパケットをサーバ３００に対して転送する際に格納すべきＳｅｑ＃（変換Ｓｅｑ＃）との組が１つのエントリとして登録される。また、クライアント→サーバＡｃｋ＃変換テーブル１１７−１２には、コネクションＩＤと、そのコネクションを通じてクライアント２００から受信したパケットに含まれるＡｃｋ＃（予想Ａｃｋ＃）と、当該Ａｃｋ＃を持つパケットをサーバ３００に対して転送する際に格納すべきＡｃｋ＃（変換Ａｃｋ＃）との組が１つのエントリとして登録される。
同様に、サーバ→クライアントＳｅｑ／Ａｃｋ＃変換テーブル１１７−２は、Ｓｅｑ＃の変換に使用するサーバ→クライアントＳｅｑ＃変換テーブル１１７−２１と、Ａｃｋ＃の変換に使用するサーバ→クライアントＡｃｋ＃変換テーブル１１７−２２との２種類のテーブルで構成される。サーバ→クライアントＳｅｑ＃変換テーブル１１７−２１には、コネクションＩＤと、そのコネクションを通じてサーバ３００から受信したパケットに含まれるＳｅｑ＃（予想Ｓｅｑ＃）と、当該Ｓｅｑ＃を持つパケットをクライアント２００に対して転送する際に格納すべきＳｅｑ＃（変換Ｓｅｑ＃）との組が１つのエントリとして登録される。また、サーバ→クライアントＡｃｋ＃変換テーブル１１７−２２には、コネクションＩＤと、そのコネクションを通じてサーバ３００から受信したパケットに含まれるＡｃｋ＃（予想Ａｃｋ＃）と、当該Ａｃｋ＃を持つパケットをクライアント２００に対して転送する際に格納すべきＡｃｋ＃（変換Ａｃｋ＃）との組が１つのエントリとして登録される。
(Ｓｅｑ／Ａｃｋ＃変換部１１６)
ゲートウェイモジュール１１０においてＴＣＰコネクションの終端処理を回避するためには、少なくともＴＣＰのフロー制御や再送制御がクライアント２００とサーバ３００で行われる必要があるため、クライアント２００とサーバ３００が受信パケットのＳｅｑ＃及びＡｃｋ＃からパケットロスを検出できるようにしなければならない。しかし、ゲートウェイモジュール１１０においてパケット転送時にＡＰヘッダを書換える場合、クライアント２００またはサーバ３００が送信した際のパケットサイズとサーバ３００またはクライアント２００が受信した際のパケットサイズが異なることになるため、ゲートウェイモジュール１１０がクライアント２００やサーバ３００から受信したパケットのＳｅｑ＃、Ａｃｋ＃を書換えずにそのままサーバ３００やクライアント２００に転送すると、サーバ３００、クライアント２００はＳｅｑ＃及びＡｃｋ＃からパケットロスを正しく把握できなくなる。このため、Ｓｅｑ／Ａｃｋ＃変換部１１６は、パケット転送時にＡＰヘッダ書換えによるパケットサイズ変更に応じて受信パケットのＳｅｑ＃及びＡｃｋ＃を書換え、クライアント２００やサーバ３００がＳｅｑ＃及びＡｃｋ＃からパケットロスを正しく把握できるようにする。
具体的にはＳｅｑ／Ａｃｋ＃変換部１１６は、（1）管理しているＳｅｑ／Ａｃｋ＃変換テーブル１１７を参照して、ＴＣＰコネクションハンドリング部１１１から渡されたパケットのＴＣＰヘッダのＳｅｑ＃およびＡｃｋ＃を書換える処理と、（2）Ｓｅｑ／Ａｃｋ＃変換テーブル１１７の管理とを行う。以下、それぞれの処理について説明する。
（1）ＴＣＰコネクションハンドリング部１１１から渡されたパケットのＴＣＰヘッダのＳｅｑ＃およびＡｃｋ＃の書換え処理
Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＴＣＰコネクションハンドリング部１１１から渡されたパケットのＴＣＰヘッダのＳｅｑ＃及びＡｃｋ＃を、以下のようにして、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７を参照して書換える。
まずＳｅｑ／Ａｃｋ＃変換部１１６は、ＴＣＰコネクションハンドリング部１１１からパケットを渡されると、転送方向に対応するＳｅｑ／Ａｃｋ＃変換テーブル１１７を参照して、渡されたパケットの属するＴＣＰコネクションに該当するコネクションＩＤを持ち、かつ予想Ｓｅｑ＃の値がパケットのＴＣＰヘッダのＳｅｑ＃と同じエントリを探す。次にＳｅｑ／Ａｃｋ＃変換部１１６は、パケットのＴＣＰヘッダのＳｅｑ＃を前記探索したエントリの変換Ｓｅｑ＃に書換える。例えば、コネクションＩＤ１に該当するＴＣＰコネクション上でクライアント２００からＳｅｑ＃がｘｘｘのパケットを受信した場合、図５のクライアント→サーバＳｅｑ＃変換テーブル１１７−１１におけるクライアント→サーバ予想Ｓｅｑ＃がｘｘｘとなっているエントリを参照し、当該パケットのＳｅｑ＃を同一エントリのクライアント→サーバ変換Ｓｅｑ＃に記載されたｙｙｙに書換える。
Ａｃｋ＃についても同様に、Ｓｅｑ／Ａｃｋ＃変換部１１６は、パケットの属するＴＣＰコネクションに該当するコネクションＩＤを持ち、かつ予想Ａｃｋ＃がパケットのＴＣＰヘッダのＡｃｋ＃と同じエントリを探し、パケットのＴＣＰヘッダのＡｃｋ＃を当該エントリの変換Ａｃｋ＃に書換える。例えば、コネクションＩＤ１に該当するＴＣＰコネクション上で、クライアント２００からＡｃｋ＃がｗｗｗのパケットを受信した場合、図５のクライアント→サーバＡｃｋ＃変換テーブル１１７−１２におけるクライアント→サーバ予想Ａｃｋ＃がｗｗｗとなっているエントリを参照し、当該パケットのＡｃｋ＃を同一エントリのクライアント→サーバ変換Ａｃｋ＃に記載されたｚｚｚに書換える。
以上は、クライアント２００からサーバ３００へ転送するパケットのＳｅｑ／Ａｃｋ＃の書換え処理であるが、サーバ３００からクライアント２００へ転送するパケットのＳｅｑ／Ａｃｋ＃は、図６に示すサーバ→クライアントＳｅｑ／Ａｃｋ＃変換テーブル１１７−２を参照して行われる。
Ｓｅｑ／Ａｃｋ＃変換部１１６は、Ｓｅｑ／Ａｃｋ＃の書換えを行った後、パケットをＡＰヘッダパース部１１３に渡す。また、その後にＡＰヘッダ書換部１１５からパケットを受け取ると、ＴＣＰコネクションハンドリング部１１１へ伝達する。
（2）Ｓｅｑ／Ａｃｋ＃変換テーブル１１７の管理
（2-1）新規エントリの作成
Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＴＣＰコネクションハンドリング部１１１からパケットを渡されると、当該パケットと同一のＴＣＰコネクション上で同一ノードから次に受け取るべきパケット（次受信パケット）のＳｅｑ＃を計算して、予想Ｓｅｑ＃としてＳｅｑ／Ａｃｋ＃変換テーブル１１７に登録する。具体的にはＳｅｑ／Ａｃｋ＃変換部１１６は、ＴＣＰコネクションハンドリング部１１１から渡されたパケットのＳｅｑ＃とパケットのデータサイズ（ＴＣＰヘッダ以降のデータのサイズ）の和を予想Ｓｅｑ＃としてＳｅｑ／Ａｃｋ＃変換テーブル１１７に登録する。また、登録した予想Ｓｅｑ＃は次受信パケットに対するＡｃｋ＃ともなるので、次受信パケットと反対の転送方向の変換Ａｃｋ＃としてＳｅｑ／Ａｃｋ＃変換テーブル１１７に登録する。
例えば、コネクションＩＤ＝１に属し、Ｓｅｑ＃がｘｘｘ−ｘで、データサイズがｘのパケットをクライアント２００から受信した場合、図５のクライアント→サーバＳｅｑ＃変換テーブル１１７−１１に、コネクションＩＤ＝１、クライアント→サーバ予想Ｓｅｑ＃＝ｘｘｘ、クライアント→サーバ変換Ｓｅｑ＃＝ＮＵＬＬのエントリを新たに登録し、図６のサーバ→クライアントＡｃｋ＃変換テーブル１１７−２２に、コネクションＩＤ１、サーバ→クライアント変換Ａｃｋ＃＝ｘｘｘ、サーバ→クライアント予想Ａｃｋ＃＝ＮＵＬＬのエントリを新たに登録する。
また、Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＡＰヘッダ書換部１１５からＡＰヘッダ書換後のパケットを渡されると、当該パケットと同一のＴＣＰコネクション上で同一ノードへ次に転送すべきパケット（次転送パケット）のＳｅｑ＃を変換Ｓｅｑ＃としてＳｅｑ／Ａｃｋ＃変換テーブル１１７に登録する。具体的にはＳｅｑ／Ａｃｋ＃変換部１１６は、ＡＰヘッダ書換部１１５から渡されたパケットのＳｅｑ＃とパケットのデータサイズの和を変換Ｓｅｑ＃としてＳｅｑ／Ａｃｋ＃変換テーブル１１７に登録する。また、登録した変換Ｓｅｑ＃は、次転送パケットに対するＡｃｋ＃ともなるので、次転送パケットと反対の転送方向の予想Ａｃｋ＃としてＳｅｑ／Ａｃｋ＃変換テーブル１１７に登録する。
例えば、前述の例のパケット（すなわちコネクションＩＤ１に属するＳｅｑ＃がｘｘｘ−ｘ、データサイズｘのクライアントから送信されたパケット）をＴＣＰコネクションハンドリング部１１１から受け取り、ＡＰヘッダパース部１１３に渡した結果、ＡＰヘッダ書換部１１５からＳｅｑ＃がｙｙｙ−ｙ、データサイズがｙのパケットを渡された場合、Ｓｅｑ／Ａｃｋ＃変換部１１６は、図５のクライアント→サーバＳｅｑ＃変換テーブル１１７−１１のコネクションＩＤ＝１、クライアント→サーバ予想Ｓｅｑ＃＝ｘｘｘを持つエントリのクライアント→サーバ変換Ｓｅｑ＃にｙｙｙを登録し、図６のサーバ→クライアントＡｃｋ＃変換テーブル１１７−２２のコネクションＩＤ＝１、サーバ→クライアント変換Ａｃｋ＃＝ｘｘｘを持つエントリのサーバ→クライアント予想Ａｃｋ＃にｙｙｙを登録する。なお、この場合、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７には予想Ｓｅｑ＃がｘｘｘ−ｘ、変換Ｓｅｑ＃がｙｙｙ−ｙのエントリが登録されている。
Ｓｅｑ／Ａｃｋ＃変換部１１６の機能について、簡単な例を挙げて再度説明する。
今、図７に示すように、ゲートウェイモジュール１１０において、クライアント２００から受信したパケットＰ１（Ｓｅｑ＃が１、データサイズが１０）のＡＰヘッダを書換えて、サーバ３００にパケットＰ１’（Ｓｅｑ＃が１、データサイズが１１）として転送したとする。
パケットＰ１を送信したクライアント２００は、パケットＰ１のＳｅｑ＃が１で且つデータサイズが１０なので、次に送信するパケットＰ１のＳｅｑ＃には１１（１＋１０）を設定する。そこで、Ｓｅｑ／Ａｃｋ＃変換部１１６は、パケットＰ１を転送する際に、パケットＰ１のＳｅｑ＃の１とデータサイズの１０とを加算した１１をパケットＰ１の次のパケットの予想Ｓｅｑ＃として、クライアント→サーバＳｅｑ＃変換テーブル１１７−１１に登録しておく。
また、パケットＰ１’のＳｅｑ＃が１で且つデータサイズが１１なので、サーバ３００がパケットＰ１’の次に受信するパケットには、Ｓｅｑ＃として１２（１＋１１）が設定されていなければならない。そこで、Ｓｅｑ／Ａｃｋ＃変換部１１６は、パケットＰ１’を転送する際に、パケットＰ１’のＳｅｑ＃の１とデータサイズの１１とを加算した１２を、予想Ｓｅｑ＃＝１１に対応する変換Ｓｅｑ＃として、クライアント→サーバＳｅｑ＃変換テーブル１１７−１１に登録しておく。
他方、パケットＰ１’を受信したサーバ３００がそのＡＣＫをクライアント２００に返す場合、パケットＰ１’のＳｅｑ＃は１、データサイズは１１なので、Ａｃｋ＃＝１２を設定したＡｃｋパケットを送信する。そして、このようなＡｃｋパケットがサーバ３００から送信された場合、ゲートウェイモジュール１１０は、クライアント２００に対しては、パケットＰ１に対するＡｃｋパケットとして転送する必要があり、パケットＰ１のＳｅｑ＃は１、データサイズは１０なので、パケットＰ１に対するＡｃｋパケットのＡｃｋ＃には、１１（１＋１０）を設定する必要がある。そこで、Ｓｅｑ／Ａｃｋ＃変換部１１６は、パケットＰ１をパケットＰ１’として転送する際に、サーバ→クライアントＡｃｋ＃変換テーブル１１７−２２に、予想Ａｃｋ＃＝１２、変換Ａｃｋ＃＝１１のエントリを登録しておく。
はたして、図７に示すようにクライアント２００がＳｅｑ＃＝１１のパケットＰ２を送信すると、Ｓｅｑ／Ａｃｋ＃変換部１１６は、予想Ｓｅｑ＃＝１１に対応する変換Ｓｅｑ＃＝１２をクライアント→サーバＳｅｑ＃変換テーブル１１７−１１から読み出し、パケットＰ２’のＳｅｑ＃に設定してサーバ３００に送信する。
また、サーバ３００がＡｃｋ＃＝１２のＡｃｋパケットを送信すると、Ｓｅｑ／Ａｃｋ＃変換部１１６は、予想Ａｃｋ＃＝１２に対応する変換Ａｃｋ＃＝１１をサーバ→クライアントＡｃｋ＃変換テーブル１１７−２２から読み出し、そのＡｃｋパケットのＡｃｋ＃を１２から１１に書換えてクライアント２００に送信する。
（2-2）既存エントリの削除
Ｓｅｑ／Ａｃｋ＃変換部１１６は、以下の場合にＳｅｑ／Ａｃｋ＃変換テーブル１１７からエントリを削除する。なお、エントリの削除処理は省略してもよい。
Ａ）クライアント−サーバ間のＴＣＰコネクションが切断された場合
切断されたＴＣＰコネクションに対応するコネクションＩＤを持つ全てのエントリを削除する。具体的には以下のように処理する。
（ア）クライアント２００またはサーバ３００が送信したＲＳＴパケットをＴＣＰコネクションハンドリング部１１１から渡された場合
Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＲＳＴパケットを渡されたら即座に当該ＲＳＴパケットの属するＴＣＰコネクションに対応するコネクションＩＤを持つ全てのエントリを削除する。
（イ）クライアント２００またはサーバ３００が送信したＦＩＮパケットをＴＣＰコネクションハンドリング部１１１から渡された場合
Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＦＩＮパケットを渡されたらＦＩＮを送信した側（アクティブクローズ側）がＴＩＭＥ＿ＷＡＩＴ状態となってからＣＬＯＳＥＤ状態に移行するまでの時間（２ＭＳＬ時間）待ってから、当該ＦＩＮパケットの属するＴＣＰコネクションに対応するコネクションＩＤを持つ全てのエントリを削除する。具体的には、Ｓｅｑ／Ａｃｋ＃変換部１１６は、アクティブクローズ側が送信したＡｃｋをＴＣＰコネクションハンドリング部１１１から渡された時点で、アクティブクローズ側がＴＩＭＥ＿ＷＡＩＴ状態になったと判断し、その後２ＭＳＬ時間待ってからエントリ削除を行う。
Ｂ）ＴＣＰコネクションがタイムアウトした場合
Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＴＣＰコネクション上でパケットが最後に送信されてから一定時間送信されない場合、ケーブル断やマシン異常終了にてＴＣＰコネクションがタイムアウトしたと判断し、当該ＴＣＰコネクションに対応するコネクションＩＤを持つ全てのエントリを削除する。
Ｃ）パケットに対するＡｃｋを当該パケットの送信元が受信した場合
パケットに対するＡｃｋを当該パケットの送信元が受信するまでは当該パケットの再送が行われる可能性がある。こうした再送に備えるため、Ｓｅｑ／Ａｃｋ＃変換部１１６はＳｅｑ／Ａｃｋ＃変換テーブル１１７のエントリを、当該エントリの予想Ｓｅｑ＃を持つパケットに対するＡｃｋを当該パケットの送信元が受信してから削除する。
ＴＣＰでは、Ａｃｋを受信せずに送信できる最大データ量として受信Ｗｉｎｄｏｗ Ｓｉｚｅというパラメタを導入しており、Ｓｅｑ／Ａｃｋ＃変換部１１６は、受信Ｗｉｎｄｏｗ Ｓｉｚｅを利用してパケット送信元が送信パケットに対するＡｃｋを受信したか否かを確認し、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７のエントリ削除を行う。具体的には以下の削除処理を行う。
Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＴＣＰコネクションハンドリング部１１１からパケットを渡された際、渡されたパケットのＳｅｑ＃から受信Ｗｉｎｄｏｗ Ｓｉｚｅを差し引いた値よりも小さい値の予想Ｓｅｑ＃または変換Ａｃｋ＃（予想Ｓｅｑ＃または変換Ａｃｋ＃＜受信パケットのＳｅｑ＃−受信Ｗｉｎｄｏｗ Ｓｉｚｅ）を持ち、かつ前記パケットの受信に利用したコネクションに対応するコネクションＩＤを持つエントリを検索し、当該エントリを削除する。たとえば図５および図６に示すＳｅｑ／Ａｃｋ＃変換テーブル１１７を持つ場合、ＴＣＰコネクションハンドリング部１１１からクライアントの送信したＳｅｑ＃＝ｘｘｘ＋受信Ｗｉｎｄｏｗ Ｓｉｚｅ＋α（α＞０）のパケットを受け取った場合、Ｓｅｑ／Ａｃｋ＃変換部１１６はクライアント→サーバ予想Ｓｅｑ＃（サーバ→クライアント変換Ａｃｋ＃）がｘｘｘのエントリをテーブルから削除する。
なお、上記で用いる受信Ｗｉｎｄｏｗ Ｓｉｚｅの値としては、《1》ＴＣＰコネクション構築時に決定されるＷｉｎｄｏｗ Ｓｃａｌｅオプション値から計算されるＴＣＰコネクション上で利用可能な最大受信Ｗｉｎｄｏｗ Ｓｉｚｅ、《2》ＴＣＰコネクション構築後にＴＣＰコネクションの対向エンドから逐次通知される受信Ｗｉｎｄｏｗ Ｓｉｚｅ（パケットのＴＣＰヘッダのＷｉｎｄｏｗ Ｓｉｚｅによって通知される）、の２種類がある。
《1》を用いる場合、Ｓｅｑ／Ａｃｋ＃変換部１１６は、クライアント−サーバ間でＴＣＰコネクションを構築する際に決定されるＷｉｎｄｏｗ Ｓｃａｌｅオプション値から最大受信Ｗｉｎｄｏｗ Ｓｉｚｅを計算し、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７のエントリ削除に利用する。なお、Ｗｉｎｄｏｗ Ｓｃａｌｅオプション値は、クライアント→サーバとサーバ→クライアントで異なる値になる場合もあるため、それぞれについて最大受信Ｗｉｎｄｏｗ Ｓｉｚｅを計算しておく。たとえば、ＴＣＰコネクション構築時にサーバ３００からクライアント２００に対してＷｉｎｄｏｗ Ｓｃａｌｅオプション値が４と通知された場合は、デフォルトの最大受信Ｗｉｎｄｏｗ Ｓｉｚｅ値６５５３５バイトに１６（２4）をかけた値（１０４８５６０バイト）をサーバ→クライアントの最大受信Ｗｉｎｄｏｗ Ｓｉｚｅとして利用し、クライアント→サーバＳｅｑ／Ａｃｋ＃変換テーブル１１７−１のエントリ削除に利用する。また、クライアント→サーバの最大受信Ｗｉｎｄｏｗ Ｓｉｚｅをサーバ→クライアントＳｅｑ／Ａｃｋ＃変換テーブル１１７−２のエントリ削除に利用する。
《2》を用いる場合、Ｓｅｑ／Ａｃｋ＃変換部１１６は、パケットのＴＣＰヘッダのＷｉｎｄｏｗ Ｓｉｚｅを監視して同一ＴＣＰコネクション上で通知される最大の受信Ｗｉｎｄｏｗ Ｓｉｚｅをクライアント→サーバ、サーバ→クライアントの方向毎に記憶し、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７のエントリ削除に利用する。たとえばクライアント２００が送信したパケットの処理を行う場合は、その時点までで同一ＴＣＰコネクション上でサーバ３００からクライアント２００に通知された受信Ｗｉｎｄｏｗ Ｓｉｚｅのうち、最大の受信Ｗｉｎｄｏｗ Ｓｉｚｅを利用してクライアント→サーバＳｅｑ／Ａｃｋ＃変換テーブル１１７−１のエントリ削除を行う。サーバ３００から受信したパケットの処理を行う場合は、クライアント２００からサーバ３００に通知された受信ｗｉｎｄｏｗ Ｓｉｚｅを利用してサーバ→クライアントＳｅｑ／Ａｃｋ＃変換テーブル１１７−２のエントリ削除を行う。《2》は転送する全パケットについてＷｉｎｄｏｗ Ｓｉｚｅを監視する必要があるものの、《1》に比べてエントリ削除に用いるＷｉｎｄｏｗ Ｓｉｚｅが小さくなり、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７のサイズを《1》よりも小さく保つことができる。
［再送パケットへの対応］
なお、クライアント２００またはサーバ３００が再送したパケットについては、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７の管理処理が既に完了し、かつ以下の説明で述べるように書換位置の検出結果が既に書換位置管理テーブル１１４に記録されているため、Ｓｅｑ／Ａｃｋ＃変換部１１６は、上記（2）の処理は実施せず、（1）の処理を行った後、ＡＰヘッダパース部１１３にはパケットを渡さず、ＡＰヘッダ書換部１１５にパケットを直接に渡す処理を行ってもよい。Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＴＣＰコネクションハンドリング部１１１から渡されたパケットに対して予想Ｓｅｑ＃を計算した結果、当該予想Ｓｅｑ＃を持つエントリが既にＳｅｑ／Ａｃｋ＃変換テーブル１１７に登録されている場合、当該パケットが再送パケットだと判断する。
（書換位置管理テーブル１１４）
書換位置管理テーブル１１４は、ＴＣＰコネクション上のパケットのＳｅｑ＃とＡＰヘッダの書換え位置との対応関係をパケットの転送方向毎に保持する記憶手段である。書換位置管理テーブル１１４の例を図８−１に示す。図８−１に示す例では、書換位置管理テーブル１１４は、パケットの転送方向（クライアント→サーバ、サーバ→クライアント）毎に１種類のテーブルを持ち、テーブル中の各エントリに、コネクションＩＤとＳｅｑ＃と書換位置との組を保持する。例えば、図８−１のクライアント→サーバ書換位置管理テーブルの１行目のエントリは、コネクションＩＤが１、Ｓｅｑ＃がａであるパケットの書換位置はα、β、γの３箇所であることを示す。また、サーバ→クライアント書換位置管理テーブルの１行目のエントリは、コネクションＩＤが１、Ｓｅｑ＃がｂであるパケットの書換位置はδ、ε、ζの３箇所であることを示す。
（ＡＰヘッダパース部１１３）
ＡＰヘッダパース部１１３は、Ｓｅｑ／Ａｃｋ＃変換部１１６から渡されたパケットのＡＰヘッダ、すなわちＴＣＰヘッダ以降をパースし、ＡＰヘッダの書換位置を検索する機能を有する。書換位置を検出した場合は、パケットの属するＴＣＰコネクションのコネクションＩＤ、パケットのＳｅｑ＃および書換位置を一つのエントリとして書換位置管理テーブル１１４に新たに登録する。
さらに、ＡＰヘッダパース部１１３は、（Ａ）クライアント−サーバ間のＴＣＰコネクションが切断された場合、（Ｂ）ＴＣＰコネクションがタイムアウトした場合、（Ｃ）パケットに対するＡｃｋを当該パケットの送信元が受信した場合、において、Ｓｅｑ／Ａｃｋ＃変換部１１６のＳｅｑ／Ａｃｋ＃変換テーブル１１７のエントリ削除動作と同様の方法で、書換位置管理テーブル１１４のエントリを削除する。
上記処理を行った後、ＡＰヘッダパース部１１３は、パケットをＡＰヘッダ書換部１１５に渡す。
（ＡＰヘッダ書換部１１５）
ＡＰヘッダ書換部１１５は、書換位置管理テーブル１１４を参照し、ＡＰヘッダパース部１１３から渡されたパケットのＡＰヘッダを書換える。ＡＰヘッダの書換え例については背景技術の項で既に説明した。例えば、ＡＰヘッダに含まれるＳＩＰ ＵＲＩは、ＡＳＣＩＩ等で符号化されているため、別のＳＩＰ ＵＲＩに書換えると、文字数が変化し、パケットサイズが変化する。
［動作の説明］
次に、図９〜図１２のシーケンス図および図１３のフローチャートを参照して図１のゲートウェイモジュール１１０の動作をＳｅｑ／Ａｃｋ＃変換部１１６の動作を中心に説明する。
（ＴＣＰコネクション開設時）
図９にクライアント−サーバ間でＴＣＰコネクションを開設する際のゲートウェイモジュール１１０の動作例を示す。
［ＳＹＮ転送時］
ゲートウェイモジュール１１０がクライアント２００の送信したＳＹＮパケットをインターセプトすると（図９のＳ１）、ＴＣＰコネクションハンドリング部１１１は、コネクションＩＤを新規に割り当て（図９では１が割り当てられている）、当該コネクションＩＤおよびＳＹＮパケットの送信元ＩＰアドレス、送信元ポート番号を持つエントリをコネクション管理テーブル１１２に登録し、ＳＹＮパケットをＳｅｑ／Ａｃｋ＃変換部１１６に渡す。
Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＴＣＰコネクションハンドリング部１１１からＳＹＮパケットを渡されると、次受信パケットのＳｅｑ＃をＳＹＮパケットのＳｅｑ＃から計算する（図１３のＴ１、Ｔ２でＹＥＳ、Ｔ７）。図９の例では、ＳＹＮパケットのＳｅｑ＃はa-1であり、ＳＹＮパケットはＴＣＰのプロトコル規約上Ｓｅｑ＃を１消費するため、次受信パケットのＳｅｑ＃はa-1+1=aとなる。Ｓｅｑ／Ａｃｋ＃変換部１１６は、計算した次受信パケットのＳｅｑ＃をクライアント→サーバ予想Ｓｅｑ＃として持つエントリをクライアント→サーバＳｅｑ＃変換テーブル１１７−１１に登録し（図９のＳ２−１）、ＳＹＮパケットをＡＰヘッダパース部１１３に渡す（図１３のＴ８、Ｔ９）。
ＡＰヘッダパース部１１３は、ＳＹＮパケットにはＴＣＰヘッダ以降にデータが含まれないため、書換位置管理テーブル１１４への新規エントリの登録は行わず、ＳＹＮパケットをＡＰヘッダ書換部１１５に渡す。ＡＰヘッダ書換部１１５は、ＳＹＮパケットの書換位置情報が書換位置管理テーブル１１４に登録されていないので、ＡＰヘッダの書換えは行わず、ＳＹＮパケットをそのままＳｅｑ／Ａｃｋ＃変換部１１６に渡す。
Ｓｅｑ／Ａｃｋ＃変換部１１６は、渡されたＳＹＮパケットから次転送パケットのＳｅｑ＃を計算する（図１３のＴ１、Ｔ１０）。図９の例では、ＡＰヘッダ書換部１１５から渡されたＳＹＮパケットのＳｅｑ＃はa-1であるため、次転送パケットのＳｅｑ＃はa-1+1=aとなる。ＴＣＰコネクションハンドリング部１１１からパケットを渡された際に作成したクライアント→サーバＳｅｑ＃変換テーブル１１７−１１のエントリに、計算した次転送パケットのＳｅｑ＃をクライアント→サーバ変換Ｓｅｑ＃として登録する（図９のＳ２−１、図１３のＴ１１）。
また、Ｓｅｑ／Ａｃｋ＃変換部１１６は、クライアント→サーバ予想Ｓｅｑ＃をサーバ→クライアント変換Ａｃｋ＃として、クライアント→サーバ変換Ｓｅｑ＃をサーバ→クライアント予想Ａｃｋ＃としてそれぞれ持つエントリを、サーバ→クライアントＡｃｋ＃変換テーブル１１７−２２に登録する（図９のＳ２−２、図１３のＴ１２）。その後、Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＳＹＮパケットをＴＣＰコネクションハンドリング部１１１に渡す（図１３のＴ１３）。
ＴＣＰコネクションハンドリング部１１１は、Ｓｅｑ／Ａｃｋ＃変換部１１６から渡されたパケットをサーバ３００へ転送する（図９のＳ３）。
［ＳＹＮ ＡＣＫ転送時］
次に、ゲートウェイモジュール１１０がサーバ３００の送信したＳＹＮ ＡＣＫパケットをインターセプトすると（図９のＳ４）、ＴＣＰコネクションハンドリング部１１１は、ＳＹＮ ＡＣＫパケットをＳｅｑ／Ａｃｋ＃変換部１１６に渡す。なお、受信したＳＹＮ ＡＣＫパケットに対応するエントリが既に図９のＳ２において登録されているため、コネクション管理テーブル１１２への新規エントリ作成は行わない。
Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＴＣＰコネクションハンドリング部１１１からＳＹＮ ＡＣＫパケットを渡されると、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７を参照し、Ｓｅｑ＃／Ａｃｋ＃の書換えを行う（図１３のＴ１〜Ｔ５）。渡されたＳＹＮ ＡＣＫパケットはサーバ→クライアントへ転送されるパケットであるため、サーバ→クライアント予想Ｓｅｑ／Ａｃｋ＃テーブル１１７−２を参照する。具体的には、渡されたパケットのＳｅｑ＃およびＡｃｋ＃と同じサーバ→クライアント予想Ｓｅｑ＃およびサーバ→クライアント予想Ａｃｋ＃を持つエントリを検索し（図１３のＴ３）、当該エントリに記載されたサーバ→クライアント変換Ｓｅｑ＃およびサーバ→クライアント変換Ａｃｋ＃へ、渡されたパケットのＳｅｑ＃／Ａｃｋ＃を書換える（図９のＳ５−１、図１３のＴ５）。なお、図９のＳ５は、ＴＣＰコネクション上で初めてサーバ３００からパケットを受信したタイミングであり、サーバ→クライアント予想Ｓｅｑ＃及びサーバ→クライアント変換Ｓｅｑ＃を持つエントリが存在しないため、Ｓｅｑ＃の書換えは行わない。Ａｃｋ＃については該当エントリが存在するため、書換えを行う。ただし、この場合、エントリ中の予想Ａｃｋ＃と変換Ａｃｋ＃は同じ値であるため、同じ値に書換えられる。
ここで、Ｓｅｑ／Ａｃｋ＃変換部１１６は、渡されたパケットのＳｅｑ＃およびＡｃｋ＃と同じサーバ→クライアント予想Ｓｅｑ＃およびサーバ→クライアント予想Ａｃｋ＃を持つエントリがＳｅｑ／Ａｃｋ＃変換テーブル１１７に登録されていない場合には、パケットを廃棄する（図１３のＴ６）。その理由は、今回のパケットの予想Ｓｅｑ＃および予想Ａｃｋ＃を計算する元となった１つ前のパケットがパケットロスしているためである。このようにパケットを廃棄しても送信元がパケットを再送するので問題は生じない。
続いてＳｅｑ／Ａｃｋ＃変換部１１６は、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７への新規エントリの登録を行う（図１３のＴ８）。まず、次受信パケットのＳｅｑ＃をＳＹＮ ＡＣＫパケットのＳｅｑ＃から計算する。図９の例では、ＳＹＮ ＡＣＫパケットのＳｅｑ＃はb-1であるため、次受信パケットのＳｅｑ＃はb-1+1=ｂとなる。計算した次受信パケットのＳｅｑ＃をサーバ→クライアント予想Ｓｅｑ＃として持つエントリをサーバ→クライアントＳｅｑ＃変換テーブル１１７−２１に登録し、ＳＹＮ ＡＣＫパケットをＡＰヘッダパース部１１３に渡す（図１３のＴ９）。
ＡＰヘッダパース部１１３は、ＳＹＮ ＡＣＫパケットにはＴＣＰヘッダ以降にデータを含まないため、書換位置管理テーブル１１４への新規エントリの登録は行わず、ＳＹＮ ＡＣＫパケットをＡＰヘッダ書換部１１５に渡す。ＡＰヘッダ書換部１１５は、ＳＹＮ ＡＣＫパケットの書換位置情報が書換位置管理テーブル１１４に登録されていないので、ＡＰヘッダの書換えは行わず、ＳＹＮ ＡＣＫパケットをそのままＳｅｑ／Ａｃｋ＃変換部１１６に渡す。
Ｓｅｑ／Ａｃｋ＃変換部１１６は、渡されたＳＹＮ ＡＣＫパケットから次転送パケットのＳｅｑ＃を計算する（図１３のＴ１、Ｔ１０）。図９の例では、ＡＰヘッダ書換部１１５から渡されたＳＹＮ ＡｃｋパケットのＳｅｑ＃はb-1であるため、次転送パケットのＳｅｑ＃はb-1+1=ｂとなる。ＴＣＰコネクションハンドリング部１１１からパケットを渡された際に作成したサーバ→クライアントＳｅｑ＃変換テーブル１１７−２１のエントリに、計算した次転送パケットのＳｅｑ＃をサーバ→クライアント変換Ｓｅｑ＃として登録する（図９のＳ５−２、図１３のＴ１１）。
また、図９のＳ５−２において登録したサーバ→クライアント予想Ｓｅｑ＃をクライアント→サーバ変換Ａｃｋ＃として、サーバ→クライアント変換Ｓｅｑ＃をクライアント→サーバ予想Ａｃｋ＃としてそれぞれ持つエントリを、クライアント→サーバＡｃｋ＃変換テーブル１１７−１２に登録する（図９のＳ５−３、図１３のＴ１２））。その後、ＳＹＮ ＡＣＫパケットをＴＣＰコネクションハンドリング部１１１に渡す（図１３のＴ１３）。
ＴＣＰコネクションハンドリング部１１１は、Ｓｅｑ／Ａｃｋ＃変換部１１６から渡されたパケットをクライアント２００へ転送する（図９のＳ６）。
［ＡＣＫ転送時］
次に、ゲートウェイモジュール１１０がクライアント２００の送信したＡＣＫパケットをインターセプトすると（図９のＳ７）、ＴＣＰコネクションハンドリング部１１１は、ＡｃｋパケットをＳｅｑ／Ａｃｋ＃変換部１１６に渡す。なお、コネクション管理テーブル１１２への新規エントリ作成は、受信したＳＹＮ ＡＣＫパケットに対応するエントリが既に図９のＳ２において登録されているため行わない。
Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＴＣＰコネクションハンドリング部１１１からＡＣＫパケットを渡されると、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７を参照し、Ｓｅｑ＃／Ａｃｋ＃の書換えを行う（図１３のＴ１〜Ｔ５）。渡されたＡＣＫパケットはクライアント→サーバへ転送されるパケットであるため、クライアント→サーバＳｅｑ／Ａｃｋ＃変換テーブル１１７−１を参照する。具体的には、渡されたパケットのＳｅｑ＃およびＡｃｋ＃と同じクライアント→サーバ予想Ｓｅｑ＃およびクライアント→サーバ予想Ａｃｋ＃を持つエントリを検索し（図１３のＴ３）、当該エントリに記載されたクライアント→サーバ変換Ｓｅｑ＃およびクライアント→サーバ変換Ａｃｋ＃へ、渡されたパケットのＳｅｑ＃／Ａｃｋ＃を書換える（図９のＳ８−１及びＳ８−３、図１３のＴ５））。ただし、この場合エントリ中の予想Ｓｅｑ＃／Ａｃｋ＃と変換Ｓｅｑ＃／Ａｃｋ＃は同じ値であるため、ＡＣＫパケットのＳｅｑ＃及びＡｃｋ＃はＴＣＰコネクションハンドリング部１１１から渡された時の値と同じ値に書換えられる。
また、Ｓｅｑ／Ａｃｋ＃変換部１１６は、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７への新規エントリの登録を行う（図１３のＴ８）。まず、次受信パケットのＳｅｑ＃をＡＣＫパケットのＳｅｑ＃から計算する。図９の例ではＡＣＫパケットのＳｅｑ＃はaであり、ＡＣＫパケットはＴＣＰヘッダ以降にデータを含まないため、次受信パケットのＳｅｑ＃はa+0=aとなる。計算した次受信パケットのＳｅｑ＃をクライアント→サーバ予想Ｓｅｑ＃として持つエントリをクライアント→サーバＳｅｑ＃変換テーブル１１７−１１に登録し（図９のＳ８−２）、ＡＣＫパケットをＡＰヘッダパース部１１３に渡す（図１３のＴ９）。
ＡＣＫパケットはＴＣＰヘッダ以降にデータを含まないため、ＡＰヘッダの書換えは行われず、ＡＣＫパケットはＡＰヘッダ書換部１１５からそのままＳｅｑ／Ａｃｋ＃変換部１１６に渡される。
Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＡＰヘッダ書換部１１５から渡されたＡＣＫパケットから次転送パケットのＳｅｑ＃を計算する（図１３のＴ１、Ｔ１０）。図９の例では、ＡＰヘッダ書換部１１５から渡されたＡＣＫパケットのＳｅｑ＃はaであるため、次転送パケットのＳｅｑ＃はa+0=aとなる。ＴＣＰコネクションハンドリング部１１１からパケットを渡された際に作成したクライアント→サーバＳｅｑ＃変換テーブル１１７−１１のエントリに、計算した次転送パケットのＳｅｑ＃をクライアント→サーバ変換Ｓｅｑ＃として登録する（図９のＳ８−２、図１３のＴ１１）。
また、図９のＳ８−２において登録したクライアント→サーバ予想Ｓｅｑ＃をサーバ→クライアント変換Ａｃｋ＃として、クライアント→サーバ変換Ｓｅｑ＃をサーバ→クライアント予想Ａｃｋ＃としてそれぞれ持つエントリを、サーバ→クライアントＡｃｋ＃変換テーブル１１７−２２に登録する（図９のＳ８−４、図１３のＴ１２）。その後、ＡＣＫパケットをＴＣＰコネクションハンドリング部１１１に渡す（図１３のＴ１３）。
ＴＣＰコネクションハンドリング部１１１は、Ｓｅｑ／Ａｃｋ＃変換部１１６から渡されたパケットをサーバ３００へ転送する（図９のＳ９）。
［ＴＣＰコネクション開設時のその他の動作形態（動作簡略化）］
以上、ＴＣＰコネクション開設時のゲートウェイモジュール１１０の動作をＳｅｑ／Ａｃｋ＃変換部１１６の動作を中心として説明した。上述の説明では、Ｓｅｑ／Ａｃｋ＃変換部１１６がＴＣＰコネクション開設時においてもＴＣＰコネクション開設後のパケット転送時と同様の動作をする形態について述べたが、ＴＣＰコネクション開設時はＴＣＰヘッダ以降にデータを含むパケットの転送が行われず、またＡＰヘッダの書換えが行われないため、Ｓｅｑ／Ａｃｋ＃変換部１１６の動作はＴＣＰコネクション開設後のパケット転送動作よりも簡略化することができる。
具体的にはＴＣＰコネクション開設時には以下の動作（a）〜（d）を省略することができる。
（a)ＡＰヘッダパース部１１３及びＡＰヘッダ書換部１１５とのパケット授受
ＴＣＰコネクション開設時に転送するパケットについてはＡＰヘッダが含まれないため、ＴＣＰコネクションハンドリング部１１１から渡されたパケットをＡＰヘッダパース部１１３に渡す必要がない。
（b）変換Ｓｅｑ＃／Ａｃｋ＃の計算
ＴＣＰコネクション開設時に転送するパケットについてはＡＰヘッダの書換えが行われず、転送時にパケットサイズが変わらないため、変換Ｓｅｑ＃／Ａｃｋ＃の値は対応する予想Ｓｅｑ＃／Ａｃｋ＃と同じになる。
（c）パケット転送時のＳｅｑ＃およびＡｃｋ＃の書換え
ＴＣＰコネクション開設時に転送するパケットについてはＡＰヘッダの書換えが行われず、転送時にパケットサイズが変わらないため、Ｓｅｑ＃／Ａｃｋ＃の書換えが不要となる。
（d）ＡＣＫパケット転送時のＳｅｑ／Ａｃｋ＃変換テーブル１１７へのエントリ作成
ＳＹＮパケット転送時に作成したＳｅｑ／Ａｃｋ＃変換テーブル１１７のエントリと同一の内容を含むエントリを作成することになるため、不要となる。
（ＴＣＰコネクション開設後、パケット転送時）
［クライアント→サーバ］
図１０にＴＣＰコネクション開設後に、クライアント２００からサーバ３００へ送信されるパケットを転送する際のゲートウェイモジュール１１０の動作例を示す。
ゲートウェイモジュール１１０がクライアント２００の送信したパケットをインターセプトすると（図１０のＳ１０）、ＴＣＰコネクションハンドリング部１１１は、パケットをＳｅｑ／Ａｃｋ＃変換部１１６に渡す。
Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＴＣＰコネクションハンドリング部１１１からパケットを渡されると、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７のクライアント→サーバＳｅｑ／Ａｃｋ＃変換テーブル１１７−１を参照し、Ｓｅｑ＃／Ａｃｋ＃の書換えを行う（図１３のＴ１〜Ｔ５）。具体的には、渡されたパケットのＳｅｑ＃およびＡｃｋ＃と同じクライアント→サーバ予想Ｓｅｑ＃およびクライアント→サーバ予想Ａｃｋ＃を持つエントリを検索し、当該エントリに記載されたクライアント→サーバ変換Ｓｅｑ＃およびクライアント→サーバ変換Ａｃｋ＃へ、渡されたパケットのＳｅｑ＃／Ａｃｋ＃を書換える（図１０のＳ１１−１及びＳ１１−４）。図１０のＳ１１では、Ｓｅｑ＃がaからaに書換えられると共に、Ａｃｋ＃がbからbに書換えられる。
また、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７への新規エントリの登録を行う（図１３のＴ７、Ｔ８）。まず、次受信パケットのＳｅｑ＃をパケットのＳｅｑ＃から計算する。図１０のＳ１１の例では、パケットのＳｅｑ＃はaであり、パケットはＴＣＰヘッダ以降にC1バイトのデータを含むため、次受信パケットのＳｅｑ＃はa+C1となる。計算した次受信パケットのＳｅｑ＃をクライアント→サーバ予想Ｓｅｑ＃として持つエントリをクライアント→サーバＳｅｑ＃変換テーブル１１７−１１に登録し（図１０のＳ１１−２）、パケットをＡＰヘッダパース部１１３に渡す（図１３のＴ９）。
ＡＰヘッダパース部１１３は、渡されたパケットのＡＰヘッダをパースし、書換位置を特定して書換位置管理テーブル１１４に登録した後、ＡＰヘッダ書換部１１５にパケットを渡す。ＡＰヘッダ書換部１１５は、書換位置管理テーブル１１４を参照してパケットのＡＰヘッダの書換えを行った後、パケットをＳｅｑ／Ａｃｋ＃変換部１１６に渡す。ＡＰヘッダの書換え前後のパケットの例を図８−２、図８−３に示す。この例は、「ＳＩＰ ＵＲＩの＠マークの手前に「＿ｃｕｇＡ」という文字列を挿入するという書換ルールによる書換え例である。図８−２を参照すると、書換え前のパケットのＡＰヘッダにはＳＩＰ ＵＲＩの＠マークが３箇所あるため、ＡＰヘッダパース部１１３はそれぞれの＠マークの手前の位置を書換位置として検出し、書換位置管理テーブル１１４に登録する。例えばＡＰヘッダの先頭を０バイト目とした場合に、１番目の＠マークの手前がαバイト目、２番目の＠マークの手前がβバイト目、３番目の＠マークの手前がγバイト目とすると、ＡＰヘッダパース部１１３は、例えば図８−１の１行目のエントリに示すように、コネクションＩＤが１、Ｓｅｑ＃がａであるパケットの書換位置として、α、β、γの３箇所を書換位置管理テーブル１１４に登録する。ＡＰヘッダ書換部１１５は、図８−１の１行目のエントリを参照して、図８−２に示すパケットのＡＰヘッダにおけるαバイト目、βバイト目、γバイト目にそれぞれ「＿ｃｕｇＡ」という文字列を挿入する。これにより、当該パケットのＡＰヘッダは図８−３に示すように書換えられる。なお、この例では、書換えによりパケットのデータサイズがX1増加する。
Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＡＰヘッダ書換部１１５から渡されたパケットから、次転送パケットのＳｅｑ＃を計算する（図１３のＴ１、Ｔ１０）。図１０のＳ１１の例では、ＡＰヘッダ書換部１１５から渡されたパケットのＳｅｑ＃はaであり、パケットはＴＣＰヘッダ以降にC1+X1バイトのデータを含むため、次転送パケットのＳｅｑ＃はa+C1+X1となる。ＴＣＰコネクションハンドリング部１１１からパケットを渡された際に作成したクライアント→サーバＳｅｑ＃変換テーブル１１７−１１のエントリに、計算した次転送パケットのＳｅｑ＃をクライアント→サーバ変換Ｓｅｑ＃として登録する（図１０のＳ１１−２、図１３のＴ１１）。
また、図１０のＳ１１−２において登録したクライアント→サーバ予想Ｓｅｑ＃をサーバ→クライアント変換Ａｃｋ＃として、クライアント→サーバ変換Ｓｅｑ＃をサーバ→クライアント予想Ａｃｋ＃としてそれぞれ持つエントリを、サーバ→クライアントＡｃｋ＃変換テーブル１１７−２２に登録する（図１０のＳ１１−３、図１３のＴ１２）。その後、パケットをＴＣＰコネクションハンドリング部１１１に渡す（図１３のＴ１３）。
ＴＣＰコネクションハンドリング部１１１は、Ｓｅｑ／Ａｃｋ＃変換部１１６から渡されたパケットをサーバ３００へ転送する（図１０のＳ１２）。
以降、クライアント２００の送信したパケットをゲートウェイモジュール１１０がインターセプトすると、上記と同様の処理が繰り返される（図１０のＳ１３〜Ｓ１５）。
［サーバ→クライアント］
図１１にＴＣＰコネクション開設後にサーバ３００からクライアント２００へ送信されるパケットを転送する際のゲートウェイモジュール１１０の動作例を示す。
ゲートウェイモジュール１１０がサーバ３００の送信したパケットをインターセプトすると（図１１のＳ１６）、ＴＣＰコネクションハンドリング部１１１は、パケットをＳｅｑ／Ａｃｋ＃変換部１１６に渡す。
Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＴＣＰコネクションハンドリング部１１１からパケットを渡されると、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７のサーバ→クライアントＳｅｑ／Ａｃｋ＃変換テーブル１１７−２を参照し、Ｓｅｑ＃／Ａｃｋ＃の書換えを行う（図１３のＴ１〜Ｔ５）。具体的には、渡されたパケットのＳｅｑ＃およびＡｃｋ＃と同じサーバ→クライアント予想Ｓｅｑ＃およびサーバ→クライアント予想Ａｃｋ＃を持つエントリを検索し、当該エントリに記載されたサーバ→クライアント変換Ｓｅｑ＃およびサーバ→クライアント変換Ａｃｋ＃へ、渡されたパケットのＳｅｑ＃／Ａｃｋ＃を書換える（図１１のＳ１７−１及び１７−２）。図１１のＳ１７では、Ｓｅｑ＃がbからbに書換えられると共に、Ａｃｋ＃がa+C1+X1からa+C1に書換えられる。
また、Ｓｅｑ／Ａｃｋ＃変換部１１６は、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７への新規エントリの登録を行う（図１３のＴ７、Ｔ８）。まず、次受信パケットのＳｅｑ＃をパケットのＳｅｑ＃から計算する。図１１のＳ１７の例ではパケットのＳｅｑ＃はｂであり、パケットはＴＣＰヘッダ以降にS1バイトのデータを含むため、次受信パケットのＳｅｑ＃はb+S1となる。計算した次受信パケットのＳｅｑ＃をサーバ→クライアント予想Ｓｅｑ＃として持つエントリをサーバ→クライアントＳｅｑ＃変換テーブル１１７−２１に登録し（図１１のＳ１７−３）、パケットをＡＰヘッダパース部１１３に渡す（図１３のＴ９）。
ＡＰヘッダパース部１１３は、渡されたパケットのＡＰヘッダをパースし、書換位置を特定して書換位置管理テーブル１１４に新規エントリを登録した後、ＡＰヘッダ書換部１１５にパケットを渡す。ＡＰヘッダ書換部１１５は、書換位置管理テーブル１１４を参照してパケットの書換えを行った後、パケットをＳｅｑ／Ａｃｋ＃変換部１１６に渡す。なお、図１１のＳ１７の例では、書換えによりパケットのデータサイズがY1増加する。
Ｓｅｑ／Ａｃｋ＃変換部１１６は、ＡＰヘッダ書換部１１５から渡されたパケットから次転送パケットのＳｅｑ＃を計算する（図１３のＴ１、Ｔ１０）。図１１のＳ１７の例では、ＡＰヘッダ書換部１１５から渡されたパケットのＳｅｑ＃はbであり、パケットはＴＣＰヘッダ以降にS1+Y1バイトのデータを含むため、次転送パケットのＳｅｑ＃はb+S1+Y1 となる。ＴＣＰコネクションハンドリング部１１１からパケットを渡された際に作成したサーバ→クライアントＳｅｑ＃変換テーブル１１７−２１のエントリに、計算した次転送パケットのＳｅｑ＃をサーバ→クライアント変換Ｓｅｑ＃として登録する（図１１のＳ１７−３、図１３のＴ１１）。
また、図１１のＳ１７−３において登録したサーバ→クライアント予想Ｓｅｑ＃をクライアント→サーバ変換Ａｃｋ＃として、サーバ→クライアント変換Ｓｅｑ＃をクライアント→サーバ予想Ａｃｋ＃としてそれぞれ持つエントリを、クライアント→サーバＡｃｋ＃変換テーブル１１７−１２に登録する（図１１のＳ１７−４、図１３のＴ１２））。その後、パケットをＴＣＰコネクションハンドリング部１１１に渡す（図１３のＴ１２）。
ＴＣＰコネクションハンドリング部１１１は、Ｓｅｑ／Ａｃｋ＃変換部１１６から渡されたパケットをクライアント２００へ転送する（図１１のＳ１８）。
以降、サーバ３００の送信したパケットをゲートウェイモジュール１１０がインターセプトすると、上記と同様の処理が繰り返される（図１１のＳ１９〜Ｓ２１）。
（エントリ削除時）
図１２にＳｅｑ／Ａｃｋ＃変換テーブル１１７のエントリ削除時のゲートウェイモジュール１１０の動作例を示す。
ゲートウェイモジュール１１０がクライアント２００の送信したパケットをインターセプトすると（図１２のＳｎ）、Ｓｅｑ／Ａｃｋ＃変換部１１６は、クライアント→サーバＳｅｑ＃変換テーブル１１７−１１およびサーバ→クライアントＡｃｋ＃変換テーブル１１７−２２を参照し、クライアント→サーバ予想Ｓｅｑ＃及びサーバ→クライアント変換Ａｃｋ＃の値がクライアント２００の送信したパケットのＳｅｑ＃からＷｉｎｄｏｗ Ｓｉｚｅ値を差し引いた値よりも小さい値となっているエントリを削除する。図１２のＳｎの例では、Ｓｅｑ＃がa+C1+C2+window_size+α(α＞０)のパケットを受け取っているため、クライアント→サーバ予想Ｓｅｑ＃及びサーバ→クライアント変換Ａｃｋ＃の値が、a+C1+C2以下のエントリが削除される（図１２のＳｎ＋１、Ｓｎ＋１−１、Ｓｎ＋１−２）。
ゲートウェイモジュール１１０がサーバ３００の送信したパケットをインターセプトした場合についても、Ｓｅｑ／Ａｃｋ＃変換部１１７は、上記と同様にサーバ→クライアントＳｅｑ＃変換テーブル１１７−２１およびクライアント→サーバＡｃｋ＃変換テーブル１１７−１２の該当するエントリを削除する。
なお、前述したようにクライアント２００またはサーバ３００が再送したパケットについて、Ｓｅｑ／Ａｃｋ＃変換テーブル１１７および書換位置管理テーブル１１４への登録処理を省略し、ＡＰヘッダ書換部１１５にパケットを直接に渡す処理を行う場合、Ｓｅｑ／Ａｃｋ＃変換部１１６は、図１３の処理に代えて図１４に示す処理を行う。ここで、ステップＴ２１においては、ＴＣＰコネクションハンドリング部１１１から渡されたパケットに対して予想Ｓｅｑ＃を計算した結果、当該予想Ｓｅｑ＃を持つエントリが既にＳｅｑ／Ａｃｋ＃変換テーブル１１７に登録されている場合に、当該パケットが再送パケットだと判断する。また、ステップＴ２２では、Ｓｅｑ／Ａｃｋ＃変換部１１６からＡＰヘッダ書換部１１５に直接にパケットが渡される。さらに、ステップＴ２３では、ＡＰヘッダ書換部１１５から受け取ったパケットが、ステップＴ２１において再送パケットであると判定されていたパケットかどうかによって、ステップＴ１１、Ｔ１２をスキップするか否かを判断している。
次に本実施の形態の効果を説明する。
第１の効果は、パケットのＡＰヘッダを書換えて転送するゲートウェイ装置において、ＴＣＰコネクションを終端する必要がなくなり、ゲートウェイ装置の負荷軽減が可能になることである。
その理由は、ゲートウェイモジュール１１０におけるＳｅｑ／Ａｃｋ＃変換部１１６が、ＡＰヘッダ書換えに伴うパケットサイズ変更に応じてパケットのＳｅｑ＃及びＡｃｋ＃を書換えた後、クライアント２００やサーバ３００にパケットを転送することで、クライアント２００やサーバ３００がＳｅｑ＃及びＡｃｋ＃からパケットロスを正しく把握することが可能となり、これによりパケットの再送制御やフロー制御はクライアント２００やサーバ３００で行われるためである。
第２の効果は、ゲートウェイモジュール１１０が保持する各種テーブル１１７、１１４のサイズが小さく保たれることである。
その理由は、ゲートウェイモジュール１１０が転送するパケットのうち、送信元へ受信側から対応するＡｃｋが届いたことが保証されたパケットについて、当該パケットに対応するＳｅｑ／Ａｃｋ＃変換テーブル１１７および書換位置管理テーブル１１４のエントリを、Ｓｅｑ／Ａｃｋ＃変換部１１６及びＡＰヘッダパース部１１３がそれぞれ消去するためである。
第３の効果は、ゲートウェイモジュール１１０におけるＡＰヘッダのパース処理の回数が少なくなることである。
その理由は、ゲートウェイモジュール部１１０が転送するパケットのうち、転送パケットのＳｅｑ＃と同じ予想Ｓｅｑ＃を持つエントリがＳｅｑ／Ａｃｋ＃変換テーブル１１７にすでに登録されているパケットは再送パケットと判断し、再送パケットについてはＡＰヘッダパース部１１３によるＡＰヘッダのパース処理を行わないためである。
『第２の実施の形態』
次に本発明の第２の実施の形態について図面を参照して詳細に説明する。
クライアントとサーバがＴＣＰコネクションを利用して通信を行う場合、クライアント−サーバ間で送受信するメッセージが複数のパケットに分割して（メッセージがフラグメントされて）送信される場合がある。たとえばＳＩＰの場合は、通常トランスポートプロトコルとしてＵＤＰが用いられるが、ネットワークの許容するパケットの最大長（ＭＴＵ）よりも大きいＳＩＰメッセージを送受信する場合、トランスポートプロトコルとしてＴＣＰを用いることが規定されている。
このようなケースでは、パケットのバッファリングを行ってメッセージを再構築してからＡＰヘッダのパースを行った方が、ＡＰヘッダの書換位置を把握するのに都合が良い。
例えば書換位置を特定のテキストパターンによって検出する場合、当該テキストパターンが複数のパケットにまたがって存在している可能性があるため（たとえばテキストパターンが"ip addr"であるとして"i"が一つ目のパケットの終端部分に、"p addr"が二つ目のパケットの先頭部分にあるような場合）、メッセージを再構築すること無しに、こうしたケースに対応しようとすると、テキストパターンに応じてパケットの終端部分を記憶しておくなどの処理（たとえば前述の例ではパケットの終端部分５バイト以上を常に記憶するなど）を行う必要がある。
メッセージの再構築を行わない場合、上述したメッセージのフラグメントに対応するための処理は、ＡＰヘッダ書換位置の検出ルールが複雑化するのに伴ってより複雑となり、かつそうした処理は特定の書換位置検出ルールにしか対応できないため汎用性に乏しい。
これに対して、メッセージの再構築はパケットをバッファリングしなければならないものの、パケット中からメッセージの終端位置（先頭位置）を検出することで実現でき、メッセージの終端位置（先頭位置）の検出処理は、ＡＰヘッダ書換位置の検出処理に比べて多くの場合単純であることが想定され、かつ特定の書換位置検出ルールによらずアプリケーションレベルのプロトコルによって検出ルールが一意に決まるため汎用的である。
このような観点から第２の実施の形態におけるゲートウェイモジュール１１０’は、メッセージがフラグメントされている場合、パケットバッファリングし、メッセージを再構築する機能を持つ。また、バッファリングするパケットの数を最小限に抑えることで、必要なバッファ記憶容量を削減する。
図１５を参照すると、第２の実施の形態におけるゲートウェイモジュール１１０’は、メッセージの再構築を行うためのパケットバッファ部１１８を有する点で第１の実施の形態におけるゲートウェイモジュール１１０と相違する。また、パケットバッファ部１１８を有することから、Ｓｅｑ／Ａｃｋ＃変換部１１６’、ＡＰヘッダ書換部１１５’およびＡＰヘッダパース部１１３’の機能も、第１の実施の形態におけるゲートウェイモジュール１１０のＳｅｑ／Ａｃｋ＃変換部１１６、ＡＰヘッダ書換部１１５およびＡＰヘッダパース部１１３と一部相違する。
以下、本実施の形態のゲートウェイモジュール１１０’の構成要素のうち、第１の実施の形態と動作が異なる構成要素について説明する。（説明しない構成要素は第一の実施の形態と動作が一緒）。
（Ｓｅｑ／Ａｃｋ＃変換部１１６’）
Ｓｅｑ／Ａｃｋ＃変換部１１６’は、ＴＣＰコネクションハンドリング部１１１からパケットを受け取り、第１の実施の形態におけるＳｅｑ／Ａｃｋ＃変換部１１６の説明で述べた（1）、（2）の処理を行った後、パケットをパケットバッファ部１１８に渡す。ＡＰヘッダ書換部１１５’からパケットを渡された際のＳｅｑ／Ａｃｋ＃変換部１１６’の動作は第１の実施の形態と同じである。
［再送パケットへの対応］
なお、クライアント２００またはサーバ３００が再送したパケットについては、以下の説明で述べるようにメッセージの終端位置や書換位置の検出結果が既に書換位置管理テーブルに記録されているため、パケットバッファ部１１８には渡さず直接にＡＰヘッダ書換部１１５’に渡してもよい（すなわちパケットのバッファリングやＡＰヘッダのパースは行わなくてもよい）。さらに第１の実施の形態におけるＳｅｑ／Ａｃｋ＃変換部１１６と同様に（2）の処理（Ｓｅｑ／Ａｃｋ＃変換テーブルの管理）も省略してもよい。ＴＣＰコネクションハンドリング部１１１から渡されたパケットが再送パケットか否かについては、第１の実施の形態におけるＳｅｑ／Ａｃｋ＃変換部１１６と同様の処理で判断する。
（パケットバッファ部１１８）
パケットバッファ部１１８は、Ｓｅｑ／Ａｃｋ＃変換部１１６’からパケットを受け取ると、パケットをバッファに記憶し、フラグメントされたメッセージの再構築処理を行う機能を有する。
具体的には、パケットバッファ部１１８は、Ｓｅｑ／Ａｃｋ＃変換部１１６’からパケットを受け取ると、受け取ったパケットをバッファリングし、バッファリングされている全てのパケットに対して前回検出したメッセージ終端位置からメッセージの終端位置検索を開始する。なお、ＴＣＰコネクション構築後、クライアント２００またはサーバ３００が一番最初に送信したパケットについては、当該パケットのＴＣＰヘッダの直後からメッセージの終端位置検索を開始する。
パケットバッファ部１１８は、バッファリングされているパケットの最後（すなわちＳｅｑ／Ａｃｋ＃変換部１１６’から受け取ったパケットの最後）まで終端位置検索を行った後、メッセージの終端位置を検出した場合には、終端位置が検出された全てのメッセージについて先頭位置（多くのアプリケーションプロトコルでは前回検出したメッセージ終端位置の直後となる）と終端位置をＡＰヘッダパース部１１３’に通知するとともに、ＡＰヘッダパース部１１３’における書換位置検出完了後、最後にバッファリングしたパケットを除く全てのパケットを、ＡＰヘッダ書換部１１５’に渡すとともにバッファから消去する。なお、メッセージの終端位置が最後にバッファリングしたパケットの最後尾と一致する場合は、最後にバッファリングしたパケットも含めてすべてのパケットをＡＰヘッダ書換部１１５’に渡すとともにバッファから消去する。なお、全ての場合においてバッファからパケットを消去する処理については省略してもよい。
パケットバッファ部１１８は、メッセージの終端位置を検索した結果、メッセージの終端位置が検出されなかった場合は何も行わない。
図１６にパケットバッファ部１１８の動作例を示す。図１６に示す例では、メッセージＡ、Ｂ、Ｃがパケット《1》、《2》、《3》により送信され、メッセージＡがパケット《1》に、メッセージＢがパケット《1》、《2》に、メッセージＣが《2》、《3》にそれぞれ含まれている。以下順を追って動作を説明する。
図１６のＵ１、Ｕ２：
パケットバッファ部１１８は、パケット《1》を受け取ると、パケット《1》をバッファリングし、メッセージの終端位置を検索する。ここではメッセージＡの終端位置が特定される。パケットの最後までメッセージの終端位置検索を行った後、ＡＰヘッダパース部１１３’にメッセージＡの先頭位置、終端位置を通知する。パケット《1》にはメッセージＢの一部が含まれるためバッファに残す。
図１６のＵ３：
パケットバッファ部１１８は、パケット《2》を受け取ると、パケット《2》をバッファリングし、メッセージの終端位置の検索を行う。ここではメッセージＢの終端位置が特定される。パケットの最後までメッセージの終端位置検索を行った後、ＡＰヘッダパース部１１３’にメッセージＢの先頭位置、終端位置を通知する。
図１６のＵ４：
パケットバッファ部１１８は、パケット《1》に含まれるメッセージについては先頭位置、終端位置の検出が完了したため、書換位置の検出完了後、パケット《1》をバッファから廃棄し、パケット《1》をＡＰヘッダ書換部１１５’に渡す。パケット《2》についてはメッセージＣの一部が含まれるため、バッファに残す。
図１６のＵ５、６：
パケットバッファ部１１８は、パケット《3》を受け取ると、パケット《3》をバッファリングし、メッセージの終端位置の検索を行う。ここではメッセージＣの終端位置が特定される。パケットの最後までメッセージの終端位置検索を行った後、ＡＰヘッダパース部１１３’にメッセージＢの先頭位置、終端位置を通知する。
図１６のＵ７：
パケットバッファ部１１８は、パケット《2》及び《3》に含まれるメッセージについて先頭位置、終端位置の検出が完了したため、書換位置検出完了後、パケット《2》、《3》をバッファから廃棄し、パケット《2》、《3》をＡＰヘッダ書換部１１５’に渡す。
（ＡＰヘッダパース部１１３’）
ＡＰヘッダパース部１１３’は、パケットバッファ部１１８からメッセージの先頭位置、終端位置の通知を受けると、パケットバッファ部１１８にバッファリングされているパケットに対して通知された先頭位置から終端位置までの範囲内で書換位置の検索を行い、検出した書換位置を記述したエントリを書換位置管理テーブル１１４に登録する。なお、書換位置管理テーブル１１４に登録するエントリやエントリの削除処理は第１の実施の形態におけるＡＰヘッダパース部１１３と同様である。
（ＡＰヘッダ書換部１１５’）
ＡＰヘッダ書換部１１５’は、パケットバッファ部１１８からパケットを受け取ると、書換位置管理テーブル１１４を参照して当該パケットの書換位置を把握し、ＡＰヘッダを書換える。ＡＰヘッダ書換え後、パケットをＳｅｑ/Ａｃｋ＃変換部１１６’に渡す。
本実施の形態によれば、第１の実施の形態と同様な第１乃至第３の効果が得られると同時に、以下の効果が得られる。
第４の効果は、ゲートウェイモジュール１１０’にバッファリングされるパケットの量が少なく保たれることである。
その理由は、パケットバッファ部１１８は、メッセージ先頭終端位置検索処理において最後に記憶したパケットにアプリケーションプロトコルのメッセージの終端位置を検出した場合は、メッセージに対するＡＰヘッダパース部１１０’による解析が終了した時点で、最後に記憶したパケットを除き記憶している全てのパケットをバッファから消去するためである。
第５の効果は、アプリケーションプロトコルメッセージの終端位置検索処理の回数が小さく保たれることである。
その理由は、ゲートウェイモジュール１１０’が転送するパケットのうち、そのパケットのＳｅｑ＃と同じ予想Ｓｅｑ＃を持つエントリがＳｅｑ／Ａｃｋ＃変換テーブル１１７に既に登録されているパケットは再送パケットと判断し、再送パケットについては、パケットバッファ部１１８でバッファリングを行わず、アプリケーションプロトコルメッセージの終端位置検索を行わないためである。
以上、本発明の実施の形態について説明したが、本発明は以上の実施の形態にのみ限定されず、その他各種の付加変更が可能である。例えば、特定のパケットについては転送しないで廃棄する実施の形態も可能である。具体的には、ＡＰヘッダの書換ルール次第では、パケットに含まれるＡＰヘッダ全体が削除されるようなケースがある。このようなケースにおいても、書換え前にｘ（＞０）バイトだったパケットサイズが書換えによって０バイトに変更したと考えて、通常の書換え時（すなわちＡＰヘッダ書換え後もパケットサイズが０にならない場合）と同様に処理してよい。しかし、パケットサイズが０バイトのパケットはＩＰヘッダやＴＣＰヘッダのみからなる空のパケットであるため、パケットの転送が無意味でネットワーク帯域の浪費になるケースもある（書換え前からパケットサイズが０バイトのパケットについてはこの限りではない）。このため、書換え後にＡＰヘッダ全体が削除されるようなパケットについては廃棄し、転送しないという処理を行っても良い。
本発明の第１の実施の形態におけるゲートウェイモジュールのブロック図である。 ゲートウェイモジュールの配置例を示すブロック図である。 ゲートウェイモジュールの配置例を示すブロック図である。 コネクション管理テーブルの構成例を示す図である。 Ｓｅｑ／Ａｃｋ＃変換テーブルの構成例を示す図である。 Ｓｅｑ／Ａｃｋ＃変換テーブルの構成例を示す図である。 Ｓｅｑ／Ａｃｋ＃変換部の変換処理の説明図である。 書換位置管理テーブルの構成例を示す図である。 ＡＰヘッダ書換え前のパケットの例を示す図である。 ＡＰヘッダ書換え後のパケットの例を示す図である。 ＴＣＰコネクション開設時のＳｅｑ／Ａｃｋ＃変換部の動作例を示す図である。 ＴＣＰコネクション開設後のＳｅｑ／Ａｃｋ＃変換部の動作例を示す図である。 ＴＣＰコネクション開設後のＳｅｑ／Ａｃｋ＃変換部の動作例を示す図である。 ＴＣＰコネクション開設後のＳｅｑ／Ａｃｋ＃変換部の動作例を示す図である。 Ｓｅｑ／Ａｃｋ＃変換部の処理例を示すフローチャートである。 Ｓｅｑ／Ａｃｋ＃変換部の別の処理例を示すフローチャートである。 本発明の第２の実施の形態におけるゲートウェイモジュールのブロック図である。 パケットバッファ部の動作説明図である。
符号の説明
１１０…ゲートウェイモジュール
１１１…ＴＣＰコネクションハンドリング部
１１２…コネクション管理テーブル
１１３…ＡＰヘッダパース部
１１４…書換位置管理テーブル
１１５…ＡＰヘッダ書換部
１１６…Ｓｅｑ／Ａｃｋ＃変換部
１１７…Ｓｅｑ／Ａｃｋ＃変換テーブル
２００…クライアント
３００…サーバ

Claims (33)

  1. 端末間のＴＣＰコネクションを流れるパケットのＴＣＰヘッダ以降のデータであるＡＰヘッダを書換えて転送するゲートウェイ装置であって、
    パケットの転送時に、次に転送するパケットのＴＣＰヘッダに含まれることが予想されるシーケンス番号とＡＰヘッダの書換えによるパケットサイズの変更を考慮して求めた変換後のシーケンス番号との組を、予想シーケンス番号および変換シーケンス番号の組、ならびに、前記転送したパケットの転送方向と逆の転送方向におけるパケットのＴＣＰヘッダに含まれる予想Ａｃｋ番号および変換Ａｃｋ番号の組として登録するエントリを有する番号変換テーブルと、
    パケットの転送時に、前記番号変換テーブルを参照して、転送するパケットのＴＣＰヘッダに含まれるシーケンス番号およびＡｃｋ番号を、それらに一致する予想シーケンス番号および予想Ａｃｋ番号に対応する変換シーケンス番号および変換Ａｃｋ番号に書換える番号書換処理を行う変換手段とを備えることを特徴とするゲートウェイ装置。
  2. 前記番号変換テーブルは、予想シーケンス番号と変換シーケンス番号の組からなるエントリと、予想Ａｃｋ番号と変換Ａｃｋ番号の組からなるエントリとが、前記パケットの転送方向毎に登録されるものであり、
    前記変換手段が行う番号書換処理においては、転送パケットと転送方向が同じでかつ転送パケットのＴＣＰヘッダのシーケンス番号及びＡｃｋ番号と一致する予想シーケンス番号及び予想Ａｃｋ番号を持つエントリを前記番号変換テーブルから検索し、転送パケットのＴＣＰヘッダのシーケンス番号及びＡｃｋ番号を前記検索したエントリに記載された変換シーケンス番号および変換Ａｃｋ番号に書換えることを特徴とする請求項１に記載のゲートウェイ装置。
  3. 前記変換手段は、前記番号書換処理に加えて番号変換テーブル管理処理を行うものであり、前記番号変換テーブル管理処理は、転送パケットと転送方向が同じエントリを登録する同一転送方向エントリ登録処理と転送方向が逆のエントリを登録する逆転送方向エントリ登録処理とを含み、前記同一転送方向エントリ登録処理においては、転送パケットに対してシーケンス番号およびＡｃｋ番号の書換処理およびＡＰヘッダの書換処理を行う前の転送パケットのＴＣＰヘッダのシーケンス番号とＡＰヘッダのサイズの和を予想シーケンス番号に持ち、シーケンス番号およびＡｃｋ番号の書換処理および前記ＡＰヘッダの書換処理を行った後の転送パケットのＴＣＰヘッダのシーケンス番号とＡＰヘッダのサイズの和を変換シーケンス番号に持つエントリを前記番号変換テーブルに登録し、前記逆転送方向エントリ登録処理においては、前記同一転送方向エントリ登録処理において登録したエントリの予想シーケンス番号と同じ値を変換Ａｃｋ番号に持ち、前記同一転送方向エントリ登録処理において登録したエントリの変換シーケンス番号と同じ値を予想Ａｃｋ番号に持つエントリを前記番号変換テーブルに登録することを特徴とする請求項２に記載のゲートウェイ装置。
  4. 前記パケットのシーケンス番号とＡＰヘッダの書換位置の組を記載したエントリが前記パケットの転送方向毎に登録された書換位置管理テーブルと、
    転送パケットのＡＰヘッダを解析して書換位置を検索する書換位置検索処理と、該書換位置検索処理で検索された書換位置を含むエントリを前記書換位置管理テーブルに登録する書換位置管理テーブル管理処理とを行うＡＰヘッダパース手段と、
    前記書換位置管理テーブルを参照して転送パケットのＡＰヘッダを書換えるＡＰヘッダ書換処理を行うＡＰヘッダ書換手段とを備えることを特徴とする請求項１乃至３の何れか１項に記載のゲートウェイ装置。
  5. 転送パケットのうち、シーケンス番号と同じ予想シーケンス番号を持つエントリが前記番号変換テーブルにすでに登録されているパケットについては、前記ＡＰヘッダ書換位置検索処理を行わないことを特徴とする請求項４に記載のゲートウェイ装置。
  6. 前記変換手段は、前記番号変換テーブル管理処理において、さらに、パケットの送信側へ受信側から対応するＡｃｋが届いたことが保証されたＡｃｋ到達パケットを把握するＡｃｋ到達パケット検出処理と、前記Ａｃｋ到達パケットと同一の転送方向でかつ前記Ａｃｋ到達パケットのシーケンス番号よりも小さい予想シーケンス番号を持つエントリと、前記Ａｃｋ到達パケットと逆の転送方向でかつ前記Ａｃｋ到達パケットのシーケンス番号よりも小さい変換Ａｃｋ番号を持つエントリを、前記番号変換テーブルから削除する番号変換テーブルエントリ削除処理を行うことを特徴とする請求項１乃至５の何れか１項に記載のゲートウェイ装置。
  7. 前記ＡＰヘッダパース手段は、前記書換位置管理テーブル管理処理において、さらに、パケットのうち送信側へ受信側から対応するＡｃｋが届いたことが保証されたＡｃｋ到達パケットを把握するＡｃｋ到達パケット検出処理と、前記Ａｃｋ到達パケットと同一の転送方向でかつ前記Ａｃｋ到達パケットのシーケンス番号よりも小さいシーケンス番号を持つエントリを、前記書換位置管理テーブルから削除する書換位置管理テーブルエントリ削除処理を行うことを特徴とする請求項４または５に記載のゲートウェイ装置。
  8. 前記Ａｃｋ到達パケット検出処理においては、前記ＴＣＰコネクション上で最後にインターセプトしたパケットのシーケンス番号から、前記ＴＣＰコネクション構築時に決定されたＷｉｎｄｏｗ Ｓｃａｌｅオプション値により計算される前記ＴＣＰコネクション上で利用可能な最大受信Ｗｉｎｄｏｗ Ｓｉｚｅを引いた値よりも小さいシーケンス番号を持つパケットを前記Ａｃｋ到達パケットとして把握することを特徴とする請求項６または７に記載のゲートウェイ装置。
  9. 前記Ａｃｋ到達パケット検出処理においては、前記ＴＣＰコネクション上で最後にインターセプトしたパケットのシーケンス番号から、前記ＴＣＰコネクション構築後に前記ＴＣＰコネクションにおいてパケット受信側から通知された最大のＷｉｎｄｏｗ Ｓｉｚｅを引いた値よりも小さいシーケンス番号を持つパケットを前記Ａｃｋ到達パケットとして把握することを特徴とする請求項６または７に記載のゲートウェイ装置。
  10. 転送パケットを記憶するバッファを有し、アプリケーションプロトコルのメッセージの先頭と終端位置を検索して前記ＡＰヘッダパース手段に通知するメッセージ先頭終端位置検索処理を行うパケットバッファ手段を備え、
    前記パケットバッファ手段は、前記メッセージ先頭終端位置検索処理において最後に記憶したパケットにアプリケーションプロトコルのメッセージの終端位置を検出した場合は、前記メッセージに対する前記ＡＰヘッダパース手段による解析が終了した時点で、最後に記憶したパケットを除き記憶している全てのパケットをバッファから消去することを特徴とする請求項４または５に記載のゲートウェイ装置。
  11. 転送パケットのうち、シーケンス番号と同じ予想シーケンス番号を持つエントリが前記番号変換テーブルにすでに登録されているパケットについては、前記パケットバッファ手段によるバッファへの記憶は行わないことを特徴とする請求項１０に記載のゲートウェイ装置。
  12. ゲートウェイ装置において端末間のＴＣＰコネクションを流れるパケットのＴＣＰヘッダ以降のデータであるＡＰヘッダを書換えて転送する方法であって、
    前記ゲートウェイ装置が、パケットの転送時に、次に転送するパケットのＴＣＰヘッダに含まれることが予想されるシーケンス番号とＡＰヘッダの書換えによるパケットサイズの変更を考慮して求めた変換後のシーケンス番号との組を、予想シーケンス番号および変換シーケンス番号の組、ならびに、前記転送したパケットの転送方向と逆の転送方向におけるパケットのＴＣＰヘッダに含まれる予想Ａｃｋ番号および変換Ａｃｋ番号の組として番号変換テーブルに登録するステップと、
    前記ゲートウェイ装置が、パケットの転送時に、前記番号変換テーブルを参照して、転送するパケットのＴＣＰヘッダに含まれるシーケンス番号およびＡｃｋ番号を、それらに一致する予想シーケンス番号および予想Ａｃｋ番号に対応する変換シーケンス番号および変換Ａｃｋ番号に書換える番号書換処理を行うステップとを含むことを特徴とするパケット転送方法。
  13. 前記番号変換テーブルは、予想シーケンス番号と変換シーケンス番号の組からなるエントリと、予想Ａｃｋ番号と変換Ａｃｋ番号の組からなるエントリとが、前記パケットの転送方向毎に登録されるものであり、
    前記番号書換処理においては、転送パケットと転送方向が同じでかつ転送パケットのＴＣＰヘッダのシーケンス番号及びＡｃｋ番号と一致する予想シーケンス番号及び予想Ａｃｋ番号を持つエントリを前記番号変換テーブルから検索し、転送パケットのＴＣＰヘッダのシーケンス番号及びＡｃｋ番号を前記検索したエントリに記載された変換シーケンス番号および変換Ａｃｋ番号に書換えることを特徴とする請求項１２に記載のパケット転送方法。
  14. 前記ゲートウェイ装置が、番号変換テーブル管理処理を行うステップを含み、
    前記番号変換テーブル管理処理は、転送パケットと転送方向が同じエントリを登録する同一転送方向エントリ登録処理と転送方向が逆のエントリを登録する逆転送方向エントリ登録処理とを含み、前記同一転送方向エントリ登録処理においては、転送パケットに対してシーケンス番号およびＡｃｋ番号の書換処理およびＡＰヘッダの書換処理を行う前の転送パケットのＴＣＰヘッダのシーケンス番号とＡＰヘッダのサイズの和を予想シーケンス番号に持ち、シーケンス番号およびＡｃｋ番号の書換処理および前記ＡＰヘッダの書換処理を行った後の転送パケットのＴＣＰヘッダのシーケンス番号とＡＰヘッダのサイズの和を変換シーケンス番号に持つエントリを前記番号変換テーブルに登録し、前記逆転送方向エントリ登録処理においては、前記同一転送方向エントリ登録処理において登録したエントリの予想シーケンス番号と同じ値を変換Ａｃｋ番号に持ち、前記同一転送方向エントリ登録処理において登録したエントリの変換シーケンス番号と同じ値を予想Ａｃｋ番号に持つエントリを前記番号変換テーブルに登録することを特徴とする請求項１３に記載のパケット転送方法。
  15. 前記ゲートウェイ装置は、前記パケットのシーケンス番号とＡＰヘッダの書換位置の組を記載したエントリが前記パケットの転送方向毎に登録された書換位置管理テーブルを備え、
    前記ゲートウェイ装置が、転送パケットのＡＰヘッダを解析して書換位置を検索する書換位置検索処理と、該書換位置検索処理で検索された書換位置を含むエントリを前記書換位置管理テーブルに登録する書換位置管理テーブル管理処理とを行うステップと、
    前記ゲートウェイ装置が、前記書換位置管理テーブルを参照して転送パケットのＡＰヘッダを書換えるＡＰヘッダ書換処理を行うステップとを含むことを特徴とする請求項１２乃至１４の何れか１項に記載のパケット転送方法。
  16. 前記ゲートウェイ装置は、転送パケットのうち、シーケンス番号と同じ予想シーケンス番号を持つエントリが前記番号変換テーブルにすでに登録されているパケットについては、前記ＡＰヘッダの書換位置検索処理を行わないことを特徴とする請求項１５に記載のパケット転送方法。
  17. 前記ゲートウェイ装置が、パケットの送信側へ受信側から対応するＡｃｋが届いたことが保証されたＡｃｋ到達パケットを把握するＡｃｋ到達パケット検出処理と、前記Ａｃｋ到達パケットと同一の転送方向でかつ前記Ａｃｋ到達パケットのシーケンス番号よりも小さい予想シーケンス番号を持つエントリと、前記Ａｃｋ到達パケットと逆の転送方向でかつ前記Ａｃｋ到達パケットのシーケンス番号よりも小さい変換Ａｃｋ番号を持つエントリを、前記番号変換テーブルから削除する番号変換テーブルエントリ削除処理を行うステップを含むことを特徴とする請求項１２乃至１６の何れか１項に記載のパケット転送方法。
  18. 前記ゲートウェイ装置が、パケットのうち送信側へ受信側から対応するＡｃｋが届いたことが保証されたＡｃｋ到達パケットを把握するＡｃｋ到達パケット検出処理と、前記Ａｃｋ到達パケットと同一の転送方向でかつ前記Ａｃｋ到達パケットのシーケンス番号よりも小さいシーケンス番号を持つエントリを、前記書換位置管理テーブルから削除する書換位置管理テーブルエントリ削除処理を行うステップを含むことを特徴とする請求項１５または１６に記載のパケット転送方法。
  19. 前記Ａｃｋ到達パケット検出処理においては、前記ＴＣＰコネクション上で最後にインターセプトしたパケットのシーケンス番号から、前記ＴＣＰコネクション構築時に決定されたＷｉｎｄｏｗ Ｓｃａｌｅオプション値により計算される前記ＴＣＰコネクション上で利用可能な最大受信Ｗｉｎｄｏｗ Ｓｉｚｅを引いた値よりも小さいシーケンス番号を持つパケットを前記Ａｃｋ到達パケットとして把握することを特徴とする請求項１７または１８に記載のパケット転送方法。
  20. 前記Ａｃｋ到達パケット検出処理においては、前記ＴＣＰコネクション上で最後にインターセプトしたパケットのシーケンス番号から、前記ＴＣＰコネクション構築後に前記ＴＣＰコネクションにおいてパケット受信側から通知された最大のＷｉｎｄｏｗ Ｓｉｚｅを引いた値よりも小さいシーケンス番号を持つパケットを前記Ａｃｋ到達パケットとして把握することを特徴とする請求項１７または１８に記載のパケット転送方法。
  21. 前記ゲートウェイ装置は転送パケットを記憶するバッファを有し、
    前記ゲートウェイ装置が、アプリケーションプロトコルのメッセージの先頭と終端位置を検索して前記ＡＰヘッダパース手段に通知するメッセージ先頭終端位置検索処理を行うステップと、
    前記ゲートウェイ装置が、前記メッセージ先頭終端位置検索処理において最後に記憶したパケットにアプリケーションプロトコルのメッセージの終端位置を検出した場合は、前記メッセージに対する前記ＡＰヘッダパース手段による解析が終了した時点で、最後に記憶したパケットを除き記憶している全てのパケットをバッファから消去するステップとを含むことを特徴とする請求項１５または１６に記載のパケット転送方法。
  22. 前記ゲートウェイ装置が、転送パケットのうち、シーケンス番号と同じ予想シーケンス番号を持つエントリが前記番号変換テーブルにすでに登録されているパケットについては、バッファへの記憶は行わないことを特徴とする請求項２１に記載のパケット転送方法。
  23. 端末間のＴＣＰコネクションを流れるパケットのＴＣＰヘッダ以降のデータであるＡＰヘッダを書換えて転送するゲートウェイ装置であって、パケットの転送時に、次に転送するパケットのＴＣＰヘッダに含まれることが予想されるシーケンス番号とＡＰヘッダの書換えによるパケットサイズの変更を考慮して求めた変換後のシーケンス番号との組を、予想シーケンス番号および変換シーケンス番号の組、ならびに、前記転送したパケットの転送方向と逆の転送方向におけるパケットのＴＣＰヘッダに含まれる予想Ａｃｋ番号および変換Ａｃｋ番号の組として登録するエントリを有する番号変換テーブルを有するゲートウェイ装置を構成するコンピュータを、
    パケットの転送時に、前記番号変換テーブルを参照して、転送するパケットのＴＣＰヘッダに含まれるシーケンス番号およびＡｃｋ番号を、それらに一致する予想シーケンス番号および予想Ａｃｋ番号に対応する変換シーケンス番号および変換Ａｃｋ番号に書換える番号書換処理を行う変換手段として機能させるためのプログラム。
  24. 前記番号変換テーブルは、予想シーケンス番号と変換シーケンス番号の組からなるエントリと、予想Ａｃｋ番号と変換Ａｃｋ番号の組からなるエントリとが、前記パケットの転送方向毎に登録されるものであり、
    前記変換手段が行う番号書換処理においては、転送パケットと転送方向が同じでかつ転送パケットのＴＣＰヘッダのシーケンス番号及びＡｃｋ番号と一致する予想シーケンス番号及び予想Ａｃｋ番号を持つエントリを前記番号変換テーブルから検索し、転送パケットのＴＣＰヘッダのシーケンス番号及びＡｃｋ番号を前記検索したエントリに記載された変換シーケンス番号および変換Ａｃｋ番号に書換えることを特徴とする請求項２３に記載のプログラム。
  25. 前記変換手段は、前記番号書換処理に加えて番号変換テーブル管理処理を行うものであり、前記番号変換テーブル管理処理は、転送パケットと転送方向が同じエントリを登録する同一転送方向エントリ登録処理と転送方向が逆のエントリを登録する逆転送方向エントリ登録処理とを含み、前記同一転送方向エントリ登録処理においては、転送パケットに対してシーケンス番号およびＡｃｋ番号の書換処理およびＡＰヘッダの書換処理を行う前の転送パケットのＴＣＰヘッダのシーケンス番号とＡＰヘッダのサイズの和を予想シーケンス番号に持ち、シーケンス番号およびＡｃｋ番号の書換処理および前記ＡＰヘッダの書換処理を行った後の転送パケットのＴＣＰヘッダのシーケンス番号とＡＰヘッダのサイズの和を変換シーケンス番号に持つエントリを前記番号変換テーブルに登録し、前記逆転送方向エントリ登録処理においては、前記同一転送方向エントリ登録処理において登録したエントリの予想シーケンス番号と同じ値を変換Ａｃｋ番号に持ち、前記同一転送方向エントリ登録処理において登録したエントリの変換シーケンス番号と同じ値を予想Ａｃｋ番号に持つエントリを前記番号変換テーブルに登録することを特徴とする請求項２４に記載のプログラム。
  26. 前記コンピュータをさらに、
    転送パケットのＡＰヘッダを解析して書換位置を検索する書換位置検索処理と、該書換位置検索処理で検索された書換位置を含むエントリを、パケットのシーケンス番号とＡＰヘッダの書換位置の組を記載したエントリが前記パケットの転送方向毎に登録される書換位置管理テーブルに登録する書換位置管理テーブル管理処理とを行うＡＰヘッダパース手段、
    前記書換位置管理テーブルを参照して転送パケットのＡＰヘッダを書換えるＡＰヘッダ書換処理を行うＡＰヘッダ書換手段として機能させることを特徴とする請求項２３乃至２５の何れか１項に記載のプログラム。
  27. 転送パケットのうち、シーケンス番号と同じ予想シーケンス番号を持つエントリが前記番号変換テーブルにすでに登録されているパケットについては、前記ＡＰヘッダ書換位置検索処理を行わないことを特徴とする請求項２６に記載のプログラム。
  28. 前記変換手段は、前記番号変換テーブル管理処理において、さらに、パケットの送信側へ受信側から対応するＡｃｋが届いたことが保証されたＡｃｋ到達パケットを把握するＡｃｋ到達パケット検出処理と、前記Ａｃｋ到達パケットと同一の転送方向でかつ前記Ａｃｋ到達パケットのシーケンス番号よりも小さい予想シーケンス番号を持つエントリと、前記Ａｃｋ到達パケットと逆の転送方向でかつ前記Ａｃｋ到達パケットのシーケンス番号よりも小さい変換Ａｃｋ番号を持つエントリを、前記番号変換テーブルから削除する番号変換テーブルエントリ削除処理を行うことを特徴とする請求項２３乃至２７の何れか１項に記載のプログラム。
  29. 前記ＡＰヘッダパース手段は、前記書換位置管理テーブル管理処理において、さらに、パケットのうち送信側へ受信側から対応するＡｃｋが届いたことが保証されたＡｃｋ到達パケットを把握するＡｃｋ到達パケット検出処理と、前記Ａｃｋ到達パケットと同一の転送方向でかつ前記Ａｃｋ到達パケットのシーケンス番号よりも小さいシーケンス番号を持つエントリを、前記書換位置管理テーブルから削除する書換位置管理テーブルエントリ削除処理を行うことを特徴とする請求項２６または２７に記載のプログラム。
  30. 前記Ａｃｋ到達パケット検出処理においては、前記ＴＣＰコネクション上で最後にインターセプトしたパケットのシーケンス番号から、前記ＴＣＰコネクション構築時に決定されたＷｉｎｄｏｗ Ｓｃａｌｅオプション値により計算される前記ＴＣＰコネクション上で利用可能な最大受信Ｗｉｎｄｏｗ Ｓｉｚｅを引いた値よりも小さいシーケンス番号を持つパケットを前記Ａｃｋ到達パケットとして把握することを特徴とする請求項２８または２９に記載のプログラム。
  31. 前記Ａｃｋ到達パケット検出処理においては、前記ＴＣＰコネクション上で最後にインターセプトしたパケットのシーケンス番号から、前記ＴＣＰコネクション構築後に前記ＴＣＰコネクションにおいてパケット受信側から通知された最大のＷｉｎｄｏｗ Ｓｉｚｅを引いた値よりも小さいシーケンス番号を持つパケットを前記Ａｃｋ到達パケットとして把握することを特徴とする請求項２８または２９に記載のプログラム。
  32. 前記コンピュータをさらに、
    転送パケットをバッファに記憶し、アプリケーションプロトコルのメッセージの先頭と終端位置を検索して前記ＡＰヘッダパース手段に通知するメッセージ先頭終端位置検索処理を行うパケットバッファ手段であって、前記メッセージ先頭終端位置検索処理において最後に記憶したパケットにアプリケーションプロトコルのメッセージの終端位置を検出した場合は、前記メッセージに対する前記ＡＰヘッダパース手段による解析が終了した時点で、最後に記憶したパケットを除き記憶している全てのパケットをバッファから消去するパケットバッファ手段として機能させるための請求項２６または２７に記載のプログラム。
  33. 転送パケットのうち、シーケンス番号と同じ予想シーケンス番号を持つエントリが前記番号変換テーブルにすでに登録されているパケットについては、前記パケットバッファ手段によるバッファへの記憶は行わないことを特徴とする請求項３２に記載のプログラム。
JP2007329803A 2007-12-21 2007-12-21 ゲートウェイ装置およびパケット転送方法 Withdrawn JP2009152953A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2007329803A JP2009152953A (ja) 2007-12-21 2007-12-21 ゲートウェイ装置およびパケット転送方法
US12/337,983 US7969976B2 (en) 2007-12-21 2008-12-18 Gateway apparatus, packet forwarding method, and program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007329803A JP2009152953A (ja) 2007-12-21 2007-12-21 ゲートウェイ装置およびパケット転送方法

Publications (1)

Publication Number Publication Date
JP2009152953A true JP2009152953A (ja) 2009-07-09

Family

ID=40788554

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007329803A Withdrawn JP2009152953A (ja) 2007-12-21 2007-12-21 ゲートウェイ装置およびパケット転送方法

Country Status (2)

Country Link
US (1) US7969976B2 (ja)
JP (1) JP2009152953A (ja)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010283615A (ja) * 2009-06-04 2010-12-16 Canon Inc 通信装置、通信装置の制御方法、及びコンピュータプログラム
JP2011172201A (ja) * 2010-01-19 2011-09-01 Alaxala Networks Corp アドレス変換装置およびアドレス変換テーブルの管理方法
JP2012028888A (ja) * 2010-07-21 2012-02-09 Nippon Telegr & Teleph Corp <Ntt> Ｓｉｐ通信システム、ｓｉｐクライアント、ｓｉｐサーバ、ｓｉｐ通信方法、ｓｉｐ通信プログラム
WO2013172391A1 (ja) 2012-05-15 2013-11-21 日本電気株式会社 マルチテナントシステム、スイッチ、コントローラ、及びパケット転送方法
JP2014511073A (ja) * 2011-03-25 2014-05-01 コスモス Ｉｐネットワーク上を移動するデータストリームからデータを抽出する方法および装置
JP2016086232A (ja) * 2014-10-23 2016-05-19 西日本電信電話株式会社 クラウド交換機システム及びゲートウェイ装置とゲートウェイプログラム
JP2017538335A (ja) * 2014-10-30 2017-12-21 中国科学院声学研究所Ｉｎｓｔｉｔｕｔｅ Ｏｆ Ａｃｏｕｓｔｉｃｓ， Ｃｈｉｎｅｓｅ Ａｃａｄｅｍｙ Ｏｆ Ｓｃｉｅｎｃｅｓ プロトコルスタックがないモードにおけるｔｃｐの中間者処理方法
JP2020523950A (ja) * 2017-06-08 2020-08-06 ハイアニス・ポート・リサーチ・インコーポレーテッドＨｙａｎｎｉｓ Ｐｏｒｔ Ｒｅｓｅａｒｃｈ，Ｉｎｃ 変更通知ありのｔｃｐストリーム動的処理

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2202935B1 (en) * 2008-12-23 2012-06-20 Nokia Siemens Networks OY Method and device for processing data in a network
JP5239966B2 (ja) * 2009-03-17 2013-07-17 富士通株式会社 中継装置、テナント管理プログラム
US9009293B2 (en) * 2009-11-18 2015-04-14 Cisco Technology, Inc. System and method for reporting packet characteristics in a network environment
US9015318B1 (en) 2009-11-18 2015-04-21 Cisco Technology, Inc. System and method for inspecting domain name system flows in a network environment
US9148380B2 (en) * 2009-11-23 2015-09-29 Cisco Technology, Inc. System and method for providing a sequence numbering mechanism in a network environment
US8792495B1 (en) 2009-12-19 2014-07-29 Cisco Technology, Inc. System and method for managing out of order packets in a network environment
US8935427B2 (en) * 2010-09-23 2015-01-13 Microsoft Corporation Providing virtual networks using multi-tenant relays
US8787303B2 (en) 2010-10-05 2014-07-22 Cisco Technology, Inc. Methods and apparatus for data traffic offloading at a router
US9003057B2 (en) 2011-01-04 2015-04-07 Cisco Technology, Inc. System and method for exchanging information in a mobile wireless network environment
CN102143078B (zh) * 2011-03-29 2013-10-02 华为技术有限公司 一种报文处理方法、转发设备及系统
US8948013B1 (en) 2011-06-14 2015-02-03 Cisco Technology, Inc. Selective packet sequence acceleration in a network environment
US8737221B1 (en) 2011-06-14 2014-05-27 Cisco Technology, Inc. Accelerated processing of aggregate data flows in a network environment
US8743690B1 (en) 2011-06-14 2014-06-03 Cisco Technology, Inc. Selective packet sequence acceleration in a network environment
US8792353B1 (en) 2011-06-14 2014-07-29 Cisco Technology, Inc. Preserving sequencing during selective packet acceleration in a network environment
EP2571223A1 (en) * 2011-09-14 2013-03-20 Telefonaktiebolaget LM Ericsson (publ) A gateway and a method therein for enabling sip communication over a non-standard sip transport protocol
US9025475B1 (en) * 2012-01-16 2015-05-05 Amazon Technologies, Inc. Proactively retransmitting data packets in a low latency packet data network
US9027129B1 (en) * 2012-04-30 2015-05-05 Brocade Communications Systems, Inc. Techniques for protecting against denial of service attacks
FR3023663B1 (fr) * 2014-07-11 2016-08-05 Sagemcom Broadband Sas Passerelle residentielle relais entre un dispositif terminal et un serveur
US10382591B2 (en) 2014-10-13 2019-08-13 International Business Machines Corporation Transparent inline content inspection and modification in a TCP session
US9774631B2 (en) 2014-10-29 2017-09-26 International Business Machines Corporation TLS connection abandoning
CN105763474B (zh) * 2014-12-19 2019-10-25 华为技术有限公司 数据传输方法和装置
GB2539003B (en) * 2015-06-03 2018-05-09 Openwave Mobility Inc A method and apparatus for managing connections in a communication network
US9990400B2 (en) 2015-10-26 2018-06-05 Salesforce.Com, Inc. Builder program code for in-memory cache
US9984002B2 (en) 2015-10-26 2018-05-29 Salesforce.Com, Inc. Visibility parameters for an in-memory cache
US10013501B2 (en) * 2015-10-26 2018-07-03 Salesforce.Com, Inc. In-memory cache for web application data
US10798159B2 (en) * 2017-07-26 2020-10-06 Netapp, Inc. Methods for managing workload throughput in a storage system and devices thereof
CN108111509B (zh) * 2017-12-19 2020-11-06 北京百度网讯科技有限公司 数据传输方法
US10642745B2 (en) 2018-01-04 2020-05-05 Salesforce.Com, Inc. Key invalidation in cache systems
CN111741127B (zh) * 2020-07-23 2020-11-13 杭州海康威视数字技术股份有限公司 通信连接阻断方法、装置、电子设备及存储介质
CN113347119B (zh) * 2021-04-30 2023-01-06 北京华为数字技术有限公司 一种发送数据包的方法、装置、设备和存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3642305B2 (ja) 2000-12-28 2005-04-27 日本電気株式会社 通信システムとそのパケット交換方法、及び交換プログラムを記録した記録媒体
JP4221646B2 (ja) 2002-06-26 2009-02-12 日本電気株式会社 共有キャッシュサーバ
US7277963B2 (en) * 2002-06-26 2007-10-02 Sandvine Incorporated TCP proxy providing application layer modifications
US7391768B1 (en) * 2003-05-13 2008-06-24 Cisco Technology, Inc. IPv4-IPv6 FTP application level gateway
US7392323B2 (en) * 2004-11-16 2008-06-24 Seiko Epson Corporation Method and apparatus for tunneling data using a single simulated stateful TCP connection
JP4154615B2 (ja) 2005-12-08 2008-09-24 日本電気株式会社 Ｓｉｐサーバ共有モジュール装置、ｓｉｐメッセージ中継方法、及びプログラム
JP4634320B2 (ja) * 2006-02-28 2011-02-16 株式会社日立製作所 対異常通信防御を行うための装置とネットワークシステム

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010283615A (ja) * 2009-06-04 2010-12-16 Canon Inc 通信装置、通信装置の制御方法、及びコンピュータプログラム
JP2011172201A (ja) * 2010-01-19 2011-09-01 Alaxala Networks Corp アドレス変換装置およびアドレス変換テーブルの管理方法
JP2012028888A (ja) * 2010-07-21 2012-02-09 Nippon Telegr & Teleph Corp <Ntt> Ｓｉｐ通信システム、ｓｉｐクライアント、ｓｉｐサーバ、ｓｉｐ通信方法、ｓｉｐ通信プログラム
JP2014511073A (ja) * 2011-03-25 2014-05-01 コスモス Ｉｐネットワーク上を移動するデータストリームからデータを抽出する方法および装置
WO2013172391A1 (ja) 2012-05-15 2013-11-21 日本電気株式会社 マルチテナントシステム、スイッチ、コントローラ、及びパケット転送方法
US9654394B2 (en) 2012-05-15 2017-05-16 Nec Corporation Multi-tenant system, switch, controller and packet transferring method
JP2016086232A (ja) * 2014-10-23 2016-05-19 西日本電信電話株式会社 クラウド交換機システム及びゲートウェイ装置とゲートウェイプログラム
JP2017538335A (ja) * 2014-10-30 2017-12-21 中国科学院声学研究所Ｉｎｓｔｉｔｕｔｅ Ｏｆ Ａｃｏｕｓｔｉｃｓ， Ｃｈｉｎｅｓｅ Ａｃａｄｅｍｙ Ｏｆ Ｓｃｉｅｎｃｅｓ プロトコルスタックがないモードにおけるｔｃｐの中間者処理方法
JP2020523950A (ja) * 2017-06-08 2020-08-06 ハイアニス・ポート・リサーチ・インコーポレーテッドＨｙａｎｎｉｓ Ｐｏｒｔ Ｒｅｓｅａｒｃｈ，Ｉｎｃ 変更通知ありのｔｃｐストリーム動的処理
JP7184881B2 (ja) 2017-06-08 2022-12-06 ハイアニス・ポート・リサーチ・インコーポレーテッド 変更通知ありのｔｃｐストリーム動的処理

Also Published As

Publication number Publication date
US7969976B2 (en) 2011-06-28
US20090161680A1 (en) 2009-06-25

Similar Documents

Publication Publication Date Title
JP2009152953A (ja) ゲートウェイ装置およびパケット転送方法
US10158570B2 (en) Carrying TCP over an ICN network
US9008100B2 (en) Wavefront detection and disambiguation of acknowledgments
WO2020063298A1 (zh) 处理tcp报文的方法、toe组件以及网络设备
US7656799B2 (en) Flow control system architecture
US8462630B2 (en) Early generation of acknowledgements for flow control
US8233392B2 (en) Transaction boundary detection for reduction in timeout penalties
US7698453B2 (en) Early generation of acknowledgements for flow control
US8411560B2 (en) TCP selection acknowledgements for communicating delivered and missing data packets
EP3035638A1 (en) Interest acknowledgements for information centric networking
EP2892189A1 (en) System and method for diverting established communication sessions
US20060221825A1 (en) Congestion control network relay device and method
US20040006643A1 (en) TCP proxy providing application layer modifications
US10361921B2 (en) Method and apparatus for managing connections in a communication network
CN105939297B (zh) 一种tcp报文重组方法和装置
JP2008536369A (ja) 接続転送
US10516615B2 (en) Network traffic congestion control
US20150373135A1 (en) Wide area network optimization
US20070291782A1 (en) Acknowledgement filtering
JP4658546B2 (ja) フェイルオーバーイベントをサポートするネットワーク状態オブジェクトの多重オフロード
JP2005520374A (ja) Ｔｃｐ／ｉｐに対する変更
WO2019243890A2 (en) Multi-port data transmission via udp
JP2016019066A (ja) パケット中継システム、パケット中継装置、およびパケット中継方法
JP2000232480A (ja) パケットヘッダ変換装置および通信ノード装置
EP3525419A1 (en) Connectionless protocol with bandwidth and congestion control

Legal Events

Date Code Title Description
RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20091008

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20091008

A300 Application deemed to be withdrawn because no request for examination was validly filed

Free format text: JAPANESE INTERMEDIATE CODE: A300

Effective date: 20110301