JP2017538335A - プロトコルスタックがないモードにおけるtcpの中間者処理方法 - Google Patents
プロトコルスタックがないモードにおけるtcpの中間者処理方法 Download PDFInfo
- Publication number
- JP2017538335A JP2017538335A JP2017523335A JP2017523335A JP2017538335A JP 2017538335 A JP2017538335 A JP 2017538335A JP 2017523335 A JP2017523335 A JP 2017523335A JP 2017523335 A JP2017523335 A JP 2017523335A JP 2017538335 A JP2017538335 A JP 2017538335A
- Authority
- JP
- Japan
- Prior art keywords
- tcp
- data packet
- tcp data
- packet
- process proceeds
- 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.)
- Pending
Links
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/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
-
- 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
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
本発明は、プロトコルスタックがないモードにおけるTCPの中間者処理方法に関し、送信側が受信側に送信したTCPデータパケットをインターセプトして、該TCPデータパケットをTCP/IP再編成し、次に、該TCPデータパケットのペイロード長を修正し、シリアル番号、及び確認番号を少なくとも含むTCPデータパケットのTCPヘッダー情報を修正して、最終的にTCPデータパケットをキャッシュするとともに受信側に転送するステップを含む。【選択図】図3
Description
本発明はネットワーク通信分野に関し、特にプロトコルスタックがないモードにおけるTCPの中間者(man-in-the-middle)処理方法に関する。
インターネットの発展に伴って、ネットワーク伝送媒体は日々に多様化し、ネットワークのセキュリティー問題も次第に重視されつつある。ネットワーク攻撃の1種として、中間者攻撃は強い隠蔽性を有し、脅威が深刻である。攻撃者は、情報送信者と受信者の間に位置し、両者が交換する情報を処理する。しかし、ある特定の場合には、中間者技術は利点もある。例えば、中間者技術はある程度でネットワーク犯罪を監視することができ、ネットワークにおける不法な、暴力的な、或いは、ポルノ的な情報を遮蔽できる。
従来のTCP中間者処理方法は、いずれも通常のTCP/IPプロトコルスタックモードにおいて作動し、中間者は、送信側と受信側にそれぞれに接続を確立する方法を採用して、送信側と受信側の交換パケットを監視する。このような方法の利点は実現が容易であることである。この方法は通常のTCP/IPプロトコルスタックモードにおいて作動するため、データパケットを受信する際に、データパケットを順次ネットワーク層(IPプロトコルスタック)、トランスポート層(TCPプロトコルスタック)、アプリケーション層に渡して処理し、その後、再びアプリケーション層、トランスポート層(TCP)、ネットワーク層(IP)によってパッケージし、最終的にデータパケットを転送する。従って、従来のTCP中間者処理方法は、リアルタイム性が悪く、ネットワークスループットに影響を与える。また、この方法は、送信側と受信側の正常な通信に影響を与える。
本発明は、従来技術におけるTCP中間者処理方法がリアルタイム性が悪く、クライアントとサーバーとの正常な通信に影響を与えるという欠陥を克服して、リアルタイム性が高く、送信側及び受信側に透明であるTCP中間者処理方法を提供することを目的とする。
上記の目的を実現するために、本発明はプロトコルスタックがないモードにおけるTCPの中間者処理方法を提供し、この方法は、
送信側が受信側に送信したTCPデータパケットをインターセプトし、TCPデータパケットをTCP/IP再編成し、次に、前記TCPデータパケットのペイロード長を修正し、シリアル番号、確認番号を少なくとも含むTCPデータパケットのTCPヘッダー情報を修正して、最終的にTCPデータパケットをキャッシュするとともに、受信側に転送するステップを含む。
送信側が受信側に送信したTCPデータパケットをインターセプトし、TCPデータパケットをTCP/IP再編成し、次に、前記TCPデータパケットのペイロード長を修正し、シリアル番号、確認番号を少なくとも含むTCPデータパケットのTCPヘッダー情報を修正して、最終的にTCPデータパケットをキャッシュするとともに、受信側に転送するステップを含む。
上記の技術的解決手段において、前記中間者処理方法は、ステップS101〜S111を更に含む。
ステップS101:1つのTCPデータパケットを受信する。
ステップS102:前記TCPデータパケットをTCP/IP再編成する。
ステップS103:TCP再編成した情報によって該TCPデータパケットが再送パケットであるか否かを判断し、再送パケットである(YES)場合、再送パケット処理フローであるステップS108に進み、再送パケットでない(NO)場合、正常パケット処理フローであるステップS104に進む。
ステップS104:必要に応じて前記データパケットのペイロード長を修正し、ペイロード長の変更値をオフセットとして、ステップS105に進む。
ステップS105:前記TCPデータパケットが確認番号を含むか否かを検査し、含む(YES)場合、ステップS106に進み、含まない(NO)場合、ステップS107に進む。
ステップS106:前記TCPデータパケットのクィンテットを抽出して、逆引きハッシュ検索を行い、逆引きのTCP流を確認して、逆引きキャッシュキューにおいて確認されたTCPデータパケットを削除して、且つTCPヘッダーの確認番号を修正し、ステップS107に進む。
ステップS107:TCPデータパケットのクィンテットでフォワードハッシュ検索を行い、TCPヘッダーのシリアル番号を修正し、該パケットをフォワードキャッシュ末尾に挿入して、前方に転送し、ステップS111に進む。
ステップS108:前記TCPデータパケットが再送パケットであると判定(determine)し、該再送パケットがTCP中間者処理モジュールによって確認(acknowledge)されたか否かを判断し、確認された(YES)場合、ステップS109に進み、確認されない(NO)場合、ステップS110に進む。
ステップS109:前記TCPデータパケットのクィンテットで逆引きハッシュ検索を行い、逆引きキャッシュキューにおける対応するTCPデータパケットを検出し、キャッシュキューにおける対応するTCPデータパケットを後方に転送して、元のTCPデータパケットを廃棄し、ステップS111に進む。
ステップS110:前記TCPデータパケットのクィンテットでフォワードハッシュ検索を行い、フォワードキャッシュキューにおける対応するTCPデータパケットを検出し、キャッシュキューにおける対応したTCPデータパケットを前方に転送して、元のTCPデータパケットを廃棄し、ステップS111に進む。
ステップS111:前記TCPデータパケット処理を終了する。
ステップS101:1つのTCPデータパケットを受信する。
ステップS102:前記TCPデータパケットをTCP/IP再編成する。
ステップS103:TCP再編成した情報によって該TCPデータパケットが再送パケットであるか否かを判断し、再送パケットである(YES)場合、再送パケット処理フローであるステップS108に進み、再送パケットでない(NO)場合、正常パケット処理フローであるステップS104に進む。
ステップS104:必要に応じて前記データパケットのペイロード長を修正し、ペイロード長の変更値をオフセットとして、ステップS105に進む。
ステップS105:前記TCPデータパケットが確認番号を含むか否かを検査し、含む(YES)場合、ステップS106に進み、含まない(NO)場合、ステップS107に進む。
ステップS106:前記TCPデータパケットのクィンテットを抽出して、逆引きハッシュ検索を行い、逆引きのTCP流を確認して、逆引きキャッシュキューにおいて確認されたTCPデータパケットを削除して、且つTCPヘッダーの確認番号を修正し、ステップS107に進む。
ステップS107:TCPデータパケットのクィンテットでフォワードハッシュ検索を行い、TCPヘッダーのシリアル番号を修正し、該パケットをフォワードキャッシュ末尾に挿入して、前方に転送し、ステップS111に進む。
ステップS108:前記TCPデータパケットが再送パケットであると判定(determine)し、該再送パケットがTCP中間者処理モジュールによって確認(acknowledge)されたか否かを判断し、確認された(YES)場合、ステップS109に進み、確認されない(NO)場合、ステップS110に進む。
ステップS109:前記TCPデータパケットのクィンテットで逆引きハッシュ検索を行い、逆引きキャッシュキューにおける対応するTCPデータパケットを検出し、キャッシュキューにおける対応するTCPデータパケットを後方に転送して、元のTCPデータパケットを廃棄し、ステップS111に進む。
ステップS110:前記TCPデータパケットのクィンテットでフォワードハッシュ検索を行い、フォワードキャッシュキューにおける対応するTCPデータパケットを検出し、キャッシュキューにおける対応したTCPデータパケットを前方に転送して、元のTCPデータパケットを廃棄し、ステップS111に進む。
ステップS111:前記TCPデータパケット処理を終了する。
上記の技術的解決手段において、前記逆引きハッシュ検索は、TCPデータパケットの宛先アドレス、宛先ポート、送信元アドレス、送信元ポート及びプロトコルタイプを値(value)としてハッシュマッチして、前記フォワードハッシュ検索は、TCPデータパケットの送信元アドレス、送信元ポート、宛先アドレス、宛先ポート及びプロトコルタイプを値(value)としてハッシュマッチする。
上記の技術的解決手段において、ステップS107では、前記TCPヘッダーのシリアル番号を修正することは、下記の計算式によって行い、修正後のシリアル番号=修正前のシリアル番号+累積的なオフセット、ここで、累積的なオフセット=末尾TCPパケットの累積的なオフセット+該TCPデータパケットのオフセットである。
上記の技術的解決手段において、ステップS106では、TCPヘッダーの確認番号を修正することは、以下の計算式によって行い、修正後の確認番号=所望の確認番号-累積的なオフセット、ここで、前記所望の確認番号=修正後のシリアル番号+修正後のTCPペイロード長である。
上記の技術的解決手段において、ステップS108では、以下のような方法を採用してTCPデータパケットが再送パケットであるか否かを判断する。即ち該TCPデータパケットのシリアル番号がTCP/IP再編成過程に出力した最大のシリアル番号値より大きい場合、該TCPパケットが再送パケットではないと判断し、そうでない場合、該TCPパケットは再送パケットであると判断する。
上記の技術的解決手段において、前記フォワード転送は、転送する方向がソースTCPデータパケットを送信する方向と同じである転送であり、前記後方転送は、転送する方向がソースTCPデータパケットを送信する方向と逆である転送である。
本発明の利点は以下の通りであり、
1、本発明のプロトコルスタックがないモードにおけるTCPの中間者処理方法は、プロトコルスタックがないモードにおいて作動し、TCPデータパケットの修正は送信側及び受信側に対して透明であり、且つ送信側と受信側との正常な通信に影響を与えることがなく、
2、本発明のプロトコルスタックがないモードにおけるTCPの中間者処理方法は、キャッシュメカニズムによって、再送パケットの処理の一定の高速化を実現し、
3、本発明のプロトコルスタックがないモードにおけるTCPの中間者処理方法は、その他のTCPプロトコルに基づく中間者手段に下層技術サポートを提供することができる。
1、本発明のプロトコルスタックがないモードにおけるTCPの中間者処理方法は、プロトコルスタックがないモードにおいて作動し、TCPデータパケットの修正は送信側及び受信側に対して透明であり、且つ送信側と受信側との正常な通信に影響を与えることがなく、
2、本発明のプロトコルスタックがないモードにおけるTCPの中間者処理方法は、キャッシュメカニズムによって、再送パケットの処理の一定の高速化を実現し、
3、本発明のプロトコルスタックがないモードにおけるTCPの中間者処理方法は、その他のTCPプロトコルに基づく中間者手段に下層技術サポートを提供することができる。
以下、図面を参照して本発明を更に説明する。
本発明の中間者処理方法はTCP/IPプロトコルスタックを採用せず、直接ネットワーク層においてトランスポート層(TCP)とアプリケーション層(様々なプロトコル)のデータメッセージを処理する。本発明において、通信ネットワークにある2つのネットワークノードの間に位置する、本発明の方法を採用したTCP中間者をTCP中間者モジュールと呼ぶ。2つのネットワークノード間で通信する際に、前記TCP中間者モジュールは、流れているTCPデータパケットを受信し、再編成し、修正及び転送処理をするとともに、正常なTCP接続を保持する。この過程において、TCPデータパケット処理前後の長さの変更値に応じて、TCPヘッダーのシリアル番号及び確認番号の値を修正する必要がある、且つ送信側及び受信側の正常な通信に影響を与えない。
図1に示すように、本発明の方法は、以下のステップS1〜S6を含む。
ステップS1では、TCP中間者処理モジュールは初期化を行い、
ステップS2では、送信側が受信側にTCPデータパケットを送信し、
ステップS3では、TCP中間者処理モジュールがTCPデータパケットをインターセプトして、TCPデータパケットをTCP/IP(処理プログラムで)再編成し、受信したTCPパケットの秩序性を確保し、
ステップS4では、TCP中間者処理モジュールがTCPデータパケットのペイロード長を修正し、
ステップS5では、TCP中間者処理モジュールが、データパケットのシリアル番号、確認番号、チェックサム等のフィールドを含むTCPヘッダー情報を修正し、
ステップS6では、TCP中間者処理モジュールが、TCPデータパケットをキャッシュして、且つ受信側に転送する。
ステップS1では、TCP中間者処理モジュールは初期化を行い、
ステップS2では、送信側が受信側にTCPデータパケットを送信し、
ステップS3では、TCP中間者処理モジュールがTCPデータパケットをインターセプトして、TCPデータパケットをTCP/IP(処理プログラムで)再編成し、受信したTCPパケットの秩序性を確保し、
ステップS4では、TCP中間者処理モジュールがTCPデータパケットのペイロード長を修正し、
ステップS5では、TCP中間者処理モジュールが、データパケットのシリアル番号、確認番号、チェックサム等のフィールドを含むTCPヘッダー情報を修正し、
ステップS6では、TCP中間者処理モジュールが、TCPデータパケットをキャッシュして、且つ受信側に転送する。
図3に示すように、本発明の方法は、以下のステップS101〜S111に更に細分することができる。
ステップS101では、TCP中間者処理モジュールが、1つのTCPデータパケットを受信し、
ステップS102では、TCP中間者処理モジュールが、該TCPデータパケットをTCP/IP再編成する。
ステップS102では、TCP中間者処理モジュールが、該TCPデータパケットをTCP/IP再編成する。
正常プロトコルスタックは、TCP/IP再編成の機能を提供するが、本発明の方法は、プロトコルスタックを採用しないため、本ステップではTCPデータパケットをTCP/IP(処理プログラムで)再編成する必要がある。
ステップS103では、TCP再編成した情報によって該TCPデータパケットが再送パケットであるか否かを判断し、再送パケットである(YES)場合、再送パケット処理フローであるステップS108に進み、再送パケットでない(NO)場合、正常パケット処理フローであるステップS104に進み、
ステップS104では、TCP中間者処理モジュールは、必要に応じて前記データパケットのペイロード長を修正し、ペイロード長の変更値をオフセットとし、ステップS105に進む。
ステップS104では、TCP中間者処理モジュールは、必要に応じて前記データパケットのペイロード長を修正し、ペイロード長の変更値をオフセットとし、ステップS105に進む。
本発明の方法は、主に以下の状況、例えばネットワーク層データパケットを受信した後に、具体的な必要性(例えば問題のある言葉を削除する)に応じてTCPペイロードから対応するデータを検出して修正する必要がある場合に適用する。このため、本ステップでは必要に応じてデータパケットのペイロード長を修正する。
ステップS105では、前記TCPデータパケットに確認番号 (ACK) を含むか否かを検査し、含む(YES)場合、ステップS106に進み、含まない(NO)場合、ステップS107に進む。
1つのTCPデータパケットは2つの方向のデータフローに属する可能性があり、1つは送信側->受信側方向であり、もう1つは受信側->送信側方向である。それぞれの方向におけるTCPデータパケットの確認番号は、逆方向のTCPデータパケットの確認であり、即ち、送信側->受信側方向においてTCPデータパケットに確認番号を有すると、該確認番号は受信側->送信側方向におけるその前のあるTCPデータパケットの確認であり、逆も同様である。
ステップS106では、前記TCPデータパケットのクィンテットを抽出して、逆引きハッシュ検索を行い、逆引きのTCPフローを確認して、逆引きキャッシュキューにおいて確認されたTCPデータパケットを削除して、TCPヘッダーの確認番号を修正し、ステップS107に進む。
TCPデータパケットのクィンテットは、送信元アドレス、送信元ポート、宛先アドレス、宛先ポート及びプロトコルタイプを含む。前記逆引きハッシュ検索とは、TCPデータパケットの宛先アドレス、宛先ポート、送信元アドレス、送信元ポート及びプロトコルタイプを値(value)としてハッシュマッチする。本ステップにおいて言及した逆引きキャッシュキューとは、逆引きハッシュ検索によって検索されたキューを指す。図2における先頭ポインタ及び末尾ポインタが指したTCPデータパケットは、1つのキューのヘッド及びテールである。
前のステップS104で言及したように、TCP中間者処理モジュールは、TCPデータパケットのペイロード長を修正することがあるので、TCPデータパケットのシリアル番号及び確認番号の整合性を維持するために、TCPデータパケットのシリアル番号及び確認番号を修正する必要がある。後のステップS107ではTCPデータパケットシリアル番号の修正を完了して、シリアル番号が修正されたTCPデータパケットを受信側に送信し、受信側は確認番号が含まれるTCPデータパケットを返送し、更に本ステップではTCPヘッダーの確認番号の修正を行う。
TCPデータパケットの確認は、該TCPパケットの確認番号と逆引きキャッシュキューにおける各データパケットの「所望の確認番号」とを比較することによって実施することができ、該TCPパケットの確認番号が、逆引きキャッシュキューにおけるあるデータパケットP1の「所望の確認番号」と同じであると、該TCPデータパケットが該データパケットP1の確認であることを表す。データパケットを確認した後に、TCPパケットの確認番号を修正し、その計算式は、修正後の確認番号=修正前の所望の確認番号-累積的なオフセット、である。
ステップS107では、TCPデータパケットのクィンテットでフォワードハッシュ検索を行い、TCPヘッダーのシリアル番号を修正し、該パケットをフォワードキャッシュキューの末尾に挿入して、前方に転送し、ステップS111に進む。
前記フォワードハッシュ検索とは、TCPデータパケットの送信元アドレス、送信元ポート、宛先アドレス、宛先ポート、及びプロトコルタイプを値(value)としてハッシュマッチすることを指す。本ステップで言及したフォワードキャッシュキューとは、フォワードハッシュ検索によって検索されたキューを指す。
本出願で言及したフォワード転送は、転送の方向がソースTCPデータパケットを送信していく方向と同じである転送である。
本ステップでは、TCPヘッダーのシリアル番号を修正するのは、以下の計算式に従って計算される。即ち、修正後のシリアル番号=修正前のシリアル番号+累積的なオフセット、累積的なオフセット=末尾TCPパケットの累積的なオフセット+該TCPデータパケットのオフセットである。TCPヘッダーのシリアル番号を修正した後に、修正後のシリアル番号についての「所望の確認番号」を計算する必要もあり、所望の確認番号=修正後のシリアル番号+修正後のTCPペイロード長となる。修正後のTCPパケット、累積的なオフセット、及び所望の確認番号は、いずれもキャッシュキューに記憶される。
ステップS108では、前記TCPデータパケットが再送パケットであると判定(determine)し、該再送パケットがTCP中間者処理モジュールによって確認(acknowledge)されたか否かを判断し、確認された(YES)場合、ステップS109に進み、確認されない(NO)場合、ステップS110に進む。
本ステップでは、以下のような方法を採用してTCPデータパケットが再送パケットであるか否かを判断する。すなわち、該TCPデータパケットのシリアル番号がTCP/IP再編成過程に出力した最大のシリアル番号値より大きい場合、該TCPパケットが再送パケットではないと判断し、そうでない場合、該TCPパケットは再送パケットであると判断する。
ステップS109では、前記TCPデータパケットのクィンテットで逆引きハッシュ検索を行い、逆引きキャッシュキューにおける対応するTCPデータパケットを検出し、キャッシュキューにおける対応するTCPデータパケットを後方に転送して、元のTCPデータパケットを廃棄し、ステップS111に進む。
本出願における後方転送は、転送の方向がソースTCPデータパケットを送信していく方向と逆である転送である。
ステップS110では、前記TCPデータパケットのクィンテットでフォワードハッシュ検索を行い、フォワードキャッシュキューにおける対応するTCPデータパケットを検出し、キャッシュキューにおける対応したTCPデータパケットを前方に転送して、元のTCPデータパケットを廃棄し、ステップS111に進む。
ステップS111では、TCPデータパケット処理を終了する。
理解しやすくするために、以下、図4を参照して、本発明の方法を更に説明する。
図4に示すように、クライアントは、まずTCPデータパケットを送信する。このTCPデータパケットのシリアル番号Seqはc1であり、データパケットの長さlenがl1であり、TCP中間者モジュールは該TCPデータパケットを受信した後に、このTCPデータパケットをTCP/IP再編成し、且つデータパケット長さを修正する。仮にデータパケット長さがΔ1増加すると、修正後のデータパケット長さがl1+Δ1であり、TCPデータパケットシリアル番号の整合性を維持するために、TCP中間者モジュールは、該TCPデータパケットを転送する前に、該TCPデータパケットのシリアル番号にΔ1を加算する必要があり、修正後のデータパケットシリアル番号はc1+Δ1である。TCP中間者モジュールは、このTCPデータパケットを修正した後に、サーバーに送信する。
サーバーは、前記のTCPデータパケットを受信した後に、確認番号付きのTCPデータパケットを返し、該確認番号はc1+Δ1+l1で示される。TCPデータパケット確認番号の整合性を維持するために、確認番号値からΔ1を差引く必要があり、新しい確認番号はc1+l1である。TCP中間者モジュールは、この確認番号のTCPデータパケットをクライアントに返す。
TCP中間者モジュールは、クライアントからその後に送信されるTCPデータパケットに対して同様な処理を行う。即ち、クライアントから送信されたTCPデータパケットを受信した後に、該データパケットの長さにΔiを加算し、次に、TCPデータパケットシリアル番号の整合性を維持するために、転送する前に、TCPデータパケットシリアル番号に
を加算する。受信側から返った確認番号パケットを受信する際には、TCPデータパケット確認番号値から
を差引き、再び確認番号付きのパケットを送信側に送信する。
を加算する。受信側から返った確認番号パケットを受信する際には、TCPデータパケット確認番号値から
を差引き、再び確認番号付きのパケットを送信側に送信する。
図5は送信側と受信側の間でのTCPデータパケットのやりとりを示す完全なフローであり、この図を参照して、その前に説明した本発明の方法におけるステップS108〜ステップS110を捕捉説明する。
図5において、パケット1は、送信側が受信側に送信したパケットPacket1を示し、パケット2は、Packet1がTCP中間者モジュールにより処理された後のパケットPacket2を示し、パケット3は、受信側がPacket2を受信した後に、送信側に返送された確認パケットPacket3を示し、パケット4は、Packet3が中間者により処理された後のパケットPacket4を示す。
Packet3が紛失した場合、送信側は再送パケットPacket1を送信するが、中間者がPacket3を受信していないため、再送パケットPacket1がTCP中間者処理モジュールによって確認されないことになり、この時、ステップS110の説明のように、フォワードキャッシュキューからPacket1に対応するPacket2を検出し、Packet2をフォワード転送する。
中間者がPacket3を受信した後Packet4が紛失した場合、送信側は1つの再送パケットPacket1を送信するが、中間者はPacket3を受信したため、再送パケットPacket1がTCP中間者処理モジュールによって確認されることになり、この時、ステップS109の説明のように、逆引きキャッシュキューからPacket1の確認パケットPacket4を検出し、Packet4を後方転送する。
最後に、以上の実施例は本発明の技術的解決手段を説明するためのものだけであり、制限するためのものではない。実施例を参照して本発明を詳細的に説明したが、当業者は、本発明の技術的解決手段に対する修正や均等な置換えは、本発明の技術的解決手段の精神及び範囲を逸脱するものではなく、本発明の請求項の範囲に含まれることを理解すべきである。
Claims (7)
- プロトコルスタックがないモードにおけるTCPの中間者処理方法であって、
送信側が受信側に送信したTCPデータパケットをインターセプトし、前記TCPデータパケットをTCP/IP再編成し、次に、前記TCPデータパケットのペイロード長を修正し、シリアル番号と確認番号とを少なくとも含む前記TCPデータパケットのTCPヘッダー情報を修正して、最終的に前記TCPデータパケットをキャッシュするとともに受信側に転送するステップを含む、プロトコルスタックがないモードにおけるTCPの中間者処理方法。 - 以下のステップS101〜S111を更に含むことを特徴とする請求項1に記載のプロトコルスタックがないモードにおけるTCPの中間者処理方法。
ステップS101:1つのTCPデータパケットを受信する。
ステップS102:前記TCPデータパケットをTCP/IP再編成する。
ステップS103:TCP再編成した情報によって前記TCPデータパケットが再送パケットであるか否かを判断し、再送パケットである場合、再送パケット処理フローであるステップS108に進み、再送パケットではない場合、正常パケット処理フローであるステップS104に進む。
ステップS104:必要に応じて前記データパケットのペイロード長を修正して、ペイロード長の変更値をオフセットとし、ステップS105に進む。
ステップS105:前記TCPデータパケットが確認番号を含むか含む場合、ステップS106へ進み、含まない場合、ステップS107に進む。
ステップS106:前記TCPデータパケットのクィンテットを抽出して、逆引きハッシュ検索を行い、逆引きのTCPフローを確認して、逆引きキャッシュキューにおいて確認されたTCPデータパケットを削除して、TCPヘッダーの確認番号を修正し、ステップS107に進む。
ステップS107:TCPデータパケットのクィンテットでフォワードハッシュ検索を行い、TCPヘッダーのシリアル番号を修正し、該パケットをフォワードキャッシュキューの末尾に挿入して、前方に転送し、ステップS111に進む。
ステップS108:前記TCPデータパケットが再送パケットであると判定し、該再送パケットがTCP中間者処理モジュールによって確認されたか否かを判断し、確認された場合、ステップS109に進み、確認されない場合、ステップS110に進む。
ステップS109:前記TCPデータパケットのクィンテットで逆引きハッシュ検索を行い、逆引きキャッシュキューにおける対応するTCPデータパケットを検出し、キャッシュキューにおける対応するTCPデータパケットを後方に転送して、元のTCPデータパケットを廃棄し、ステップS111に進む。
ステップS110:前記TCPデータパケットのクィンテットでフォワードハッシュ検索を行い、フォワードキャッシュキューにおける対応するTCPデータパケットを検出し、キャッシュキューにおける対応したTCPデータパケットを前方に転送して、元のTCPデータパケットを廃棄し、ステップS111に進む。
ステップS111:TCPデータパケット処理を終了する。 - 前記逆引きハッシュ検索は、TCPデータパケットの宛先アドレス、宛先ポート、送信元アドレス、送信元ポート、及びプロトコルタイプを値としてハッシュマッチし、前記フォワードハッシュ検索は、TCPデータパケットの送信元アドレス、送信元ポート、宛先アドレス、宛先ポート、及びプロトコルタイプを値としてハッシュマッチする、ことを特徴とする請求項2に記載のプロトコルスタックがないモードにおけるTCPの中間者処理方法。
- 前記ステップS107において、前記TCPヘッダーのシリアル番号を修正することは、下記の計算式によって行い、
修正後のシリアル番号=修正前のシリアル番号+累積的なオフセット、
ここで、前記累積的なオフセット=末尾TCPパケットの累積的なオフセット+該TCPデータパケットのオフセット、である
ことを特徴とする請求項2に記載のプロトコルスタックがないモードにおけるTCPの中間者処理方法。 - 前記ステップS106において、TCPヘッダーの確認番号を修正することは、以下の計算式によって行い、
修正後の確認番号=所望の確認番号-累積的なオフセット、
ここで、前記所望の確認番号=修正後のシリアル番号+修正後のTCPペイロード長、である
ことを特徴とする請求項4に記載のプロトコルスタックがないモードにおけるTCPの中間者処理方法。 - 前記ステップS108において、TCPデータパケットのシリアル番号が、TCP/IP再編成過程に出力した最大のシリアル番号値より大きい場合、該TCPパケットが再送パケットではないと判断し、そうでない場合、該TCPパケットは再送パケットであると判断する、ことを特徴とする請求項2に記載のプロトコルスタックがないモードにおけるTCPの中間者処理方法。
- 前記フォワード転送は、転送する方向がソースTCPデータパケットを送信する方向と同じである転送であり、前記後方転送は、転送する方向がソースTCPデータパケットを送信する方向と逆である転送である、ことを特徴とする請求項2に記載のプロトコルスタックがないモードにおけるTCPの中間者処理方法。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410601880.8 | 2014-10-30 | ||
CN201410601880.8A CN105635058B (zh) | 2014-10-30 | 2014-10-30 | 一种无协议栈模式下针对tcp的中间人处理方法 |
PCT/CN2015/074080 WO2016065786A1 (zh) | 2014-10-30 | 2015-03-12 | 一种无协议栈模式下针对tcp的中间人处理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2017538335A true JP2017538335A (ja) | 2017-12-21 |
Family
ID=55856493
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017523335A Pending JP2017538335A (ja) | 2014-10-30 | 2015-03-12 | プロトコルスタックがないモードにおけるtcpの中間者処理方法 |
Country Status (4)
Country | Link |
---|---|
EP (1) | EP3203699A4 (ja) |
JP (1) | JP2017538335A (ja) |
CN (1) | CN105635058B (ja) |
WO (1) | WO2016065786A1 (ja) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107294877B (zh) * | 2016-03-31 | 2020-05-08 | 阿里巴巴集团控股有限公司 | 一种tcp流重组方法和装置 |
CN107332753A (zh) * | 2017-07-24 | 2017-11-07 | 佛山易识科技有限公司 | 一种网络数据包乱序传输方法 |
CN112688876B (zh) * | 2020-12-18 | 2022-10-14 | 北京华环电子股份有限公司 | 一种tcp拥塞快速恢复的方法 |
CN113141409A (zh) * | 2021-04-28 | 2021-07-20 | 深圳希施玛数据科技有限公司 | 一种数据传输方法、装置、终端设备及可读存储介质 |
CN115085890B (zh) * | 2022-06-23 | 2024-06-25 | 云合智网(上海)技术有限公司 | 数据中心网络芯片优化tcp rto重传等待时间的方法 |
CN115190090A (zh) * | 2022-07-12 | 2022-10-14 | 国泰君安证券股份有限公司 | 基于哈希表和队列结构的tcp流重组行情监控处理方法、系统、装置、处理器及存储介质 |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006339726A (ja) * | 2005-05-31 | 2006-12-14 | Nippon Telegr & Teleph Corp <Ntt> | 中継装置およびデータ中継方法 |
CN1297119C (zh) * | 2004-03-30 | 2007-01-24 | 中国科学院计算技术研究所 | 应用层协议转换网关的包序号控制方法 |
US20070025374A1 (en) * | 2005-07-28 | 2007-02-01 | Third Brigade, Inc. | TCP normalization engine |
JP2009089197A (ja) * | 2007-10-01 | 2009-04-23 | Fujitsu Ltd | 中継装置 |
JP2009152953A (ja) * | 2007-12-21 | 2009-07-09 | Nec Corp | ゲートウェイ装置およびパケット転送方法 |
JP2012191622A (ja) * | 2011-03-09 | 2012-10-04 | Ixia | Tcp接続を検査するためのメタデータキャプチャ |
JP2013179486A (ja) * | 2012-02-28 | 2013-09-09 | Nippon Telegr & Teleph Corp <Ntt> | パケット監視装置、パケット監視方法およびパケット監視システム |
JP2014045499A (ja) * | 2008-07-17 | 2014-03-13 | Huawei Technologies Co Ltd | データ伝送方法および装置 |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101035135A (zh) * | 2007-04-27 | 2007-09-12 | 清华大学 | 适用于无/弱本地存储客户端系统的数字证书系统 |
CN101188498B (zh) * | 2007-12-19 | 2010-12-08 | 华为技术有限公司 | 一种通信终端及通信方法 |
CN101572700B (zh) * | 2009-02-10 | 2012-05-23 | 中科正阳信息安全技术有限公司 | 一种HTTP Flood分布式拒绝服务攻击防御方法 |
CN101938741A (zh) * | 2009-06-30 | 2011-01-05 | 大唐移动通信设备有限公司 | 双向认证的方法、系统及装置 |
EP2595423B1 (en) * | 2011-11-21 | 2018-01-03 | Swisscom AG | Application security evaluation system and method |
CN102970306B (zh) * | 2012-12-18 | 2015-07-15 | 中国科学院计算机网络信息中心 | 一种IPv6网络环境下的入侵检测系统 |
CN103428199B (zh) * | 2013-05-23 | 2017-02-08 | 中国科学院信息工程研究所 | 一种适用于IPv6的信息防泄漏方法及系统 |
-
2014
- 2014-10-30 CN CN201410601880.8A patent/CN105635058B/zh active Active
-
2015
- 2015-03-12 EP EP15853757.1A patent/EP3203699A4/en not_active Withdrawn
- 2015-03-12 WO PCT/CN2015/074080 patent/WO2016065786A1/zh active Application Filing
- 2015-03-12 JP JP2017523335A patent/JP2017538335A/ja active Pending
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1297119C (zh) * | 2004-03-30 | 2007-01-24 | 中国科学院计算技术研究所 | 应用层协议转换网关的包序号控制方法 |
JP2006339726A (ja) * | 2005-05-31 | 2006-12-14 | Nippon Telegr & Teleph Corp <Ntt> | 中継装置およびデータ中継方法 |
US20070025374A1 (en) * | 2005-07-28 | 2007-02-01 | Third Brigade, Inc. | TCP normalization engine |
JP2009089197A (ja) * | 2007-10-01 | 2009-04-23 | Fujitsu Ltd | 中継装置 |
JP2009152953A (ja) * | 2007-12-21 | 2009-07-09 | Nec Corp | ゲートウェイ装置およびパケット転送方法 |
JP2014045499A (ja) * | 2008-07-17 | 2014-03-13 | Huawei Technologies Co Ltd | データ伝送方法および装置 |
JP2012191622A (ja) * | 2011-03-09 | 2012-10-04 | Ixia | Tcp接続を検査するためのメタデータキャプチャ |
JP2013179486A (ja) * | 2012-02-28 | 2013-09-09 | Nippon Telegr & Teleph Corp <Ntt> | パケット監視装置、パケット監視方法およびパケット監視システム |
Also Published As
Publication number | Publication date |
---|---|
WO2016065786A1 (zh) | 2016-05-06 |
CN105635058B (zh) | 2019-05-17 |
CN105635058A (zh) | 2016-06-01 |
EP3203699A4 (en) | 2017-10-11 |
EP3203699A1 (en) | 2017-08-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2017538335A (ja) | プロトコルスタックがないモードにおけるtcpの中間者処理方法 | |
US20070025374A1 (en) | TCP normalization engine | |
US7277963B2 (en) | TCP proxy providing application layer modifications | |
US7471681B2 (en) | Determining network path transmission unit | |
CN104025525B (zh) | 用于发送分组的方法和设备以及交换机装置 | |
EP2273738B1 (en) | Discovering path maximum transmission unit size | |
US10873613B2 (en) | TCP processing for devices | |
US7502860B1 (en) | Method and apparatus for client-side flow control in a transport protocol | |
US9867068B2 (en) | Wirespeed TCP session optimization for networks having radio segments | |
US10834126B2 (en) | Method and system for processing forged TCP packet | |
EP2866395B1 (en) | Maximum transmission unit negotiation method and data terminal | |
JP2009525708A (ja) | プロトコルリンクレイヤ | |
Thornburgh | Adobe's Secure Real-Time Media Flow Protocol | |
US10063444B2 (en) | Network traffic capture analysis | |
KR101430032B1 (ko) | 물리적 전송 매체의 인터럽션 경우에 있어서 tcp 데이터 전송 프로세스를 향상시키는 방법 | |
US20150373135A1 (en) | Wide area network optimization | |
US9848067B2 (en) | Managing sequence values with added headers in computing devices | |
US20200280580A1 (en) | Method and apparatus for processing data | |
CN109756475B (zh) | 一种单向网络中数据传输方法及装置 | |
US7623546B1 (en) | Latency improvement for file transfers over network connections | |
US7286546B2 (en) | Method and system for providing reliable and fast communications with mobile entities | |
JP4506430B2 (ja) | アプリケーションモニタ装置 | |
CN111314447B (zh) | 代理服务器及其处理访问请求的方法 | |
WO2015048999A1 (en) | Method and proxy node for source to destination packet transfer | |
JP6478816B2 (ja) | 通信装置、制御方法、及びプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20180618 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20180626 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20190212 |