(57)【要約】【課題】ネットワーク装置及びパケット通信処理方法を提供する。【解決手段】クライアントとウェブサーバとの間に介在されるＨＴＴＰプロキシの役割を行うＴＣＰ基盤のネットワーク装置に関するものであって、ＨＴＴＰ専用ポートである８０ポートに対するｎｏｎ−ＨＴＴＰサービスを提供することができない問題点を解決するため、クライアントからＴＣＰ接続を生成させるために伝送されるＴＣＰハンドシェイキング（ＴＣＰ  ３−ｗａｙ  ｈａｎｄｓｈａｋｉｎｇ）パケットを、遅延バインディング機能処理を実行せずに宛先サーバにフォワーディングし、以後、伝送されるｎｏｎ−ＨＴＴＰパケットに対して単純にクライアントと宛先サーバの相互間に中継送信するネットワーク装置によって、ＨＴＴＰプロトコルではないサービスが提供されない問題点を解決して、サービス品質をより向上させることができる。【選択図】図３
2010183553.tif 000002
【特許請求の範囲】
【請求項１】
特定の通信プロトコルに対応する専用ポートを備え、クライアント側通信装置から送信されるパケットを前記専用ポートで受信し、前記受信したパケットを宛先側通信装置に再送信し、前記再送信した後、前記クライアント側通信装置又は前記宛先側通信装置から送信されるパケットを前記専用ポートで受信し、当該受信したパケットを前記クライアント側通信装置と前記宛先側通信装置の相互間に中継送信する通信設定オプションを有することを特徴とするネットワーク装置。
【請求項２】
ＨＴＴＰに対応する専用ポートである８０ポートを備え、クライアント側通信装置から送信されるｎｏｎ−ＨＴＴＰパケットを前記８０ポートで受信し、前記ｎｏｎ−ＨＴＴＰパケットを宛先側通信装置に再送信し、前記再送信した後、前記クライアント側通信装置又は前記宛先側通信装置から送信されるパケットを前記専用ポートで受信し、当該受信したパケットを前記クライアント側通信装置と前記宛先側通信装置の相互間に中継送信する通信設定オプションを有することを特徴とするネットワーク装置。
【請求項３】
前記クライアント側通信装置からＴＣＰ接続を実行するために伝送されるＴＣＰハンドシェイキングパケットを受信して、遅延バインディング機能処理を実行せずに前記宛先側通信装置に前記ＴＣＰハンドシェイキングパケットを中継送信することを特徴とする請求項２に記載のネットワーク装置。
【請求項４】
クライアント側通信装置から送信されるパケットを特定の通信プロトコルに対応する専用ポートで受信する段階と、
前記受信されたパケットを宛先側通信装置に再送信する段階と、
前記再送信した後、前記クライアント側通信装置又は前記宛先側通信装置から前記専用ポートに入力されるパケットを、前記クライアント側通信装置と前記宛先側通信装置の相互間に中継送信する段階と、を含むことを特徴とするパケット通信処理方法。
【請求項５】
クライアント側通信装置から送信されるｎｏｎ−ＨＴＴＰパケットをＨＴＴＰに対応する専用ポートで受信する段階と、
前記受信されたｎｏｎ−ＨＴＴＰパケットを宛先側通信装置に再送信する段階と、
前記再送信した後、前記クライアント側通信装置又は前記宛先側通信装置から前記８０ポートに入力されるパケットを、前記クライアント側通信装置と前記宛先側通信装置の相互間に中継送信する段階と、を含むことを特徴とするパケット通信処理方法。
【請求項６】
前記ｎｏｎ−ＨＴＴＰパケットを受信する前に、
前記クライアント側通信装置からＴＣＰ接続を実行するために伝送されるＴＣＰハンドシェイキングパケットが前記８０ポートで受信されれば、遅延バインディング機能処理を実行せずに、前記ＴＣＰハンドシェイキングパケットを前記宛先側通信装置に中継送信する段階と、
前記ＴＣＰハンドシェイキングパケットに対して前記宛先側通信装置から送信される応答パケットを、前記宛先側通信装置と前記クライアント側通信装置との相互間に中継送信する段階と、をさらに含むことを特徴とする請求項６に記載のパケット通信処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク装置に係り、特に、クライアントとウェブサーバとの間に介在されるＨＴＴＰプロキシの役割を行うＴＣＰ基盤のネットワーク装置に関する。
【背景技術】
【０００２】
ネットワーク上で網の統制あるいは制御のための装備が、クライアントとサーバとの間に介在される場合がある。しかし、このようなファイアウォール（Ｆｉｒｅ  Ｗａｌｌ）あるいは負荷分散スイッチのような装置の存在が、時にはクライアントとサーバとの間の通信に障害をもたらす場合がある。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
本発明は、このような背景から導出されたものであって、ネットワーク装置によってｎｏｎ−ＨＴＴＰトラフィックに対する特定サービスの提供中止現象を阻むネットワーク装置及びパケット通信処理方法を提供することを目的とする。
【課題を解決するための手段】
【０００４】
前記技術的課題は、ネットワーク装置が備えるＨＴＴＰ専用ポートである８０ポートに対してクライアントから送信されるｎｏｎ−ＨＴＴＰパケットを宛先サーバにフォワーディング（Ｆｏｒｗａｒｄｉｎｇ：再送信）し、以後、前記クライアント又は前記宛先サーバから入力されるパケットを単純に前記クライアントと前記宛先サーバの相互間に中継送信する通信設定オプションを有することを特徴とするネットワーク装置によって達成される。
【０００５】
この際、前記ネットワーク装置は、クライアントからＴＣＰ接続を生成させるために伝送されるＴＣＰハンドシェイキング（ＴＣＰ  ３−ｗａｙ  ｈａｎｄｓｈａｋｉｎｇ）パケットを、遅延バインディング（Ｄｅｌａｙｅｄ  Ｂｉｎｄｉｎｇ）機能処理を実行せずに単純に宛先サーバに中継送信することを特徴とする。
【０００６】
一方、前記技術的課題は、ネットワーク装置が備えるＨＴＴＰ専用ポートである８０ポートに対してクライアントから送信されるｎｏｎ−ＨＴＴＰパケットを受信する段階と、前記受信されたｎｏｎ−ＨＴＴＰパケットを宛先サーバにフォワーディング（Ｆｏｒｗａｒｄｉｎｇ：再送信）する段階と、前記フォワーディングした後、前記クライアント又は前記宛先サーバから前記８０ポートに入力されるパケットを単純に前記クライアントと前記宛先サーバの相互間に中継送信する段階と、を含むことを特徴とするネットワーク装置のパケット通信処理方法によっても達成される。
【０００７】
前記方法は、前記ｎｏｎ−ＨＴＴＰパケットを受信する段階以前に、前記クライアントからＴＣＰ接続を生成させるために伝送されるＴＣＰハンドシェイキングパケットが受信されれば、遅延バインディング機能処理を実行せずにＴＣＰハンドシェイキングパケットをサービスサーバに中継する段階と、前記ＴＣＰハンドシェイキングパケットに対する前記サービスサーバの応答パケットを、前記サービスサーバと前記クライアントとの間に中継送信する段階と、をさらに含む。
【発明の効果】
【０００８】
本発明によれば、負荷分散を目的として導入するネットワーク装置によって特定サービスが提供されないという問題点を解決して、サービス品質をより向上させることができる。
【図面の簡単な説明】
【０００９】
【図１】ネットワーク装置が含まれたネットワーク構成の一例を概略的に示した図である。
【図２】ネットワーク装置のパケット通信処理過程を説明するためのデータフローチャートである。
【図３】本発明の一実施形態に係るネットワーク装置でのパケット通信処理方法を示すデータフローチャートである。
【図４】本発明の一実施形態に係るネットワークシステムにおいてｎｏｎ−ＨＴＴＰパケットのクライアントプッシュ過程を説明するためのデータフローチャートである。
【図５】本発明の一実施形態に係るネットワークシステムにおいてｎｏｎ−ＨＴＴＰパケットのサーバプッシュ過程を説明するためのデータフローチャートである。
【発明を実施するための形態】
【００１０】
前述した、そして、追加的な本発明の態様は、添付した図面を参照して説明される望ましい実施形態を通じてさらに明確になる。以下では、本発明を、このような実施形態を通じて当業者が容易に理解して再現できるように詳しく説明する。
【００１１】
図１は、ネットワーク装置２０が含まれたネットワーク構成の一例を概略的に示した図である。クライアント（クライアント側通信装置）１０は、サービスサーバ３０あるいはキャッシュサーバ４０で処理されるデータを伝送する。ネットワーク装置２０は、クライアント１０から送信されるトラフィックの内容を基準にスイッチングを実行してサービスサーバ（宛先側通信装置）３０やキャッシュサーバ（宛先側通信装置）４０に伝達する。
【００１２】
クライアント１０とサービスサーバ３０との間の通信には、クライアント１０が先にデータをサービスサーバ３０に伝送する場合、すなわち、クライアントプッシュ（Ｃｌｉｅｎｔ−ｐｕｓｈ）の場合と、サービスサーバ３０が先にクライアント１０にデータを伝送するサーバプッシュ（Ｓｅｒｖｅｒ−ｐｕｓｈ）の場合とが存在する。例えば、クライアントプッシュの場合に使われるプロトコルは、ＨＴＴＰ、ＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ）、Ｓｋｙｐｅ（登録商標）などがあり、サーバプッシュの場合に使われるプロトコルは、ＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ＰＯＰ３（Ｐｏｓｔ  Ｏｆｆｉｃｅ  Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  ３）、ＩＭＡＰ（Ｉｎｔｅｒｎｅｔ  Ｍｅｓｓａｇｅ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）、Ｔｅｌｎｅｔなどがある。一般的に、クライアント１０あるいはサービスサーバ３０が、先にデータ伝送を要請する前に相手は期待するデータを受信するまで待機状態になる。
【００１３】
この際、ネットワーク装置２０は、クライアント１０から伝送されるハイパーテキスト伝送プロトコル（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ：以下、ＨＴＴＰと称する）要請を支援するために、ＨＴＴＰ専用ポート（８０ポート）を宛先とするセッションを通じてトラフィックを受信する。
【００１４】
図２は、ネットワーク装置２０のパケット通信処理過程を説明するためのフローチャートである。
【００１５】
クライアント１０は、まず、ネットワーク装置２０との間で通信するための準備を実行するために、ＴＣＰハンドシェイキング（ＴＣＰ  ３−ｗａｙ  ｈａｎｄｓｈａｋｉｎｇ）過程を経る。これは、ＴＣＰ基盤のプロトコルで通信を実行するために、このＴＣＰ基盤でネットワーク装置２０が通信可能であるかを確認し、ネットワーク装置２０との間でＴＣＰ接続を行うための過程である。具体的に、クライアント１０が、ネットワーク装置２０に接続準備ができているかを問うパケット、すなわち、ＳＹＮ（Ｓｙｎｃｈｒｏｎｉｚｅ：同期）パケットを伝送すると（Ｓ２００）、ネットワーク装置２０は、現在接続準備ができており、クライアント１０に送る準備ができているかを問うパケット、すなわち、ＳＹＮ／ＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅe：確認応答）パケットを伝送する（Ｓ２０２）。次いで、クライアント１０は、メッセージ送信準備ができたということを知らせるパケット、すなわち、ＡＣＫパケットをネットワーク装置２０に伝送する（Ｓ２０４）。
【００１６】
そして、以後にネットワーク装置２０は、クライアント１０からＨＴＴＰパケットを受信（Ｓ２１０）した以後に受信されるＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）の内容によって実際サービスを提供するサービスサーバ３０を決定し、当該サービスサーバ３０とＴＣＰハンドシェイキングを行う（Ｓ２２０、Ｓ２２２）。ここで、ＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットは、クライアント１０がウェブサービスを受けることを所望する実際の内容を設定した要請メッセージである。
【００１７】
ネットワーク装置２０において、クライアント１０のユーザが所望するウェブサービス要求の内容を理解するためには、このようなＴＣＰハンドシェイキングに基づく手順を通さなければならない。すなわち、ＳＹＮ、ＳＹＮ／ＡＣＫ、ＡＣＫパケットを送受信する段階を経てから実際にクライアント１０のユーザが所望するウェブサービス要請の内容が分かる。
【００１８】
そして、ネットワーク装置２０は、サービスを提供するサービスサーバ３０を決定するために、クライアント１０のユーザが要請するサービスの内容を分からなければならない。したがって、ネットワーク装置２０は、サービスサーバ３０を決定する前までは、接続のためにその如何なるウェブサーバ（サービスサーバ３０）ともＴＣＰハンドシェイキングを進行しない。これを遅延バインディング（Ｄｅｌａｙｅｄ  Ｂｉｎｄｉｎｇ）と言う。すなわち、ネットワーク装置２０は、実際にクライアント１０からウェブサービス要請の内容を受信すれば、その時初めて内容を分析して、サービスを提供するサービスサーバ３０を決定して、実際に接続手順を実行する。ネットワーク装置２０は、決定したサービスサーバ３０にＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットを伝達する（Ｓ２３０）。サービスサーバ３０は、ＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットに対するＨＴＴＰ応答（ＨＴＴＰ  ｒｅｓｐ．）パケットをクライアント１０に伝送する（Ｓ２３５）。
【００１９】
また、ネットワーク装置２０は、クライアント１０から受信するＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットの内容によって（Ｓ２４０）、キャッシュサーバ４０への伝達が必要な場合には、キャッシュサーバ４０との間でＴＣＰハンドシェイキングを行う（Ｓ２５０、Ｓ２５５）。そして、ネットワーク装置２０は、キャッシュサーバ４０にＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットを伝達する（Ｓ２６０）。キャッシュサーバ４０は、ＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットに対するＨＴＴＰ応答（ＨＴＴＰ  ｒｅｓｐ．）パケットをクライアント１０に伝送する（Ｓ２６５）。
【００２０】
クライアント１０とネットワーク装置２０との間にＴＣＰハンドシェイキングが完了した後に、ネットワーク装置２０は、クライアント１０からＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットを受信すれば（Ｓ２７０）、サービスサーバ３０とＴＣＰハンドシェイキングを実行せずに、直ちに、クライアント１０から受信したＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットをサービスサーバ３０に伝達する（Ｓ２７２）。そして、サービスサーバ３０は、ＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットに対するＨＴＴＰ応答（ＨＴＴＰ  ｒｅｓｐ．）パケットをクライアント１０に伝送する（Ｓ２７４）。
【００２１】
一方、クライアント１０とネットワーク装置２０との間でＴＣＰハンドシェイキングが完了した後に、ネットワーク装置２０の８０ポートに対してＨＴＴＰ以外のプロトコルデータが受信されれば、ネットワーク装置２０は、誤ったＨＴＴＰパケットを受信したと認識して、その誤ったＨＴＴＰパケットの中継を実行せず、クライアント１０に「４００Ｂａｄ  Ｒｅｑｕｓｔ」を伝送する。そして、ネットワーク装置２０は、サービスサーバ３０には誤ったＨＴＴＰパケットを伝達しない。すなわち、ネットワーク装置２０が備えるＨＴＴＰ専用ポートである８０ポートに対してｎｏｎ−ＨＴＴＰパケットが受信された場合は、クライアントプッシュは不可能である。
【００２２】
また、クライアント１０が要請するウェブサービスを提供するサービスサーバ３０が存在していないか、サービスサーバ３０に障害が発生して通信できない場合に、このような障害状況をクライアント１０が直ちに分かる方法はない。クライアント１０とネットワーク装置２０との間で既にＴＣＰハンドシェイキングが正常になされたために、ネットワーク装置２０とサービスサーバ３０との間でＴＣＰハンドシェイキングが正常になされなくても、クライアント１０は、ネットワーク装置２０にＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットを送ってその応答を待つ。この場合、ネットワーク装置２０は、クライアント１０に「５０３  Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ応答」を送って障害が発生したということを知らせるが、この過程で時間及びネットワーク資源が浪費される。
【００２３】
また、ネットワーク装置２０は、実際にクライアント１０からＨＴＴＰパケットを受信した後にサービスサーバ３０を選択し、このサービスサーバ３０との間でＴＣＰハンドシェイキングを実行して通信準備ができているかを確認することができる。このため、クライアント１０からＨＴＴＰパケットを受信した履歴のないサービスサーバ３０側では、当該クライアント１０の通信準備ができたか否かは判断することができない。したがって、この場合は、サーバプッシュも不可能である。結果的に、ネットワーク装置２０にｎｏｎ−ＨＴＴＰパケットが入力される場合は、該当する特定サービスに対してＴＣＰ基盤に基づくＨＴＴＰ通信を正常に実行することができないという問題がある。
【００２４】
本出願人は、ファイアウォール（Ｆｉｒｅ  Ｗａｌｌ）あるいは負荷分散スイッチが存在するネットワークにおいて理由が分からない通信障害、特に、ＦＴＰ、ｅ−ｍａｉｌサービスのようなｎｏｎ−ＨＴＴＰ通信における障害の発生原因を長時間分析した結果、クライアントからのｎｏｎ−ＨＴＴＰ通信のような非正常的な８０ポートを通じるｎｏｎ−ＨＴＴＰプロトコル処理過程において、Ｌ７（レイヤ７：アプリケーション層）が装備する上記のような特徴（ＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットに基づく通信手順）によって問題が招来されることを発見した。
【００２５】
実際に、クライアント１０とネットワーク装置２０との間には、有害なトラフィック伝送を防止するためにファイアウォール（Ｆｉｒｅ  Ｗａｌｌ）を設ける場合があるが、この際、クライアント１０のユーザが、ファイアウォール（Ｆｉｒｅ  Ｗａｌｌ）回避などを目的でＨＴＴＰ以外のプロトコルデータをＨＴＴＰ専用ポートである８０ポートに宛先ポートを設定する場合が発生しているという点を認識した。
【００２６】
本発明は、このような問題点を解決のためのものであって、このような技術的課題を解決のための本発明の態様を以下でより詳しく説明する。
【００２７】
図３は、本発明の一実施形態に係るネットワーク装置３００において実行されるパケット通信処理方法を示すデータフローチャートである。
【００２８】
本発明の一実施形態に係るネットワーク装置３００は、特定の通信プロトコルに対応する専用ポートを備え、この専用ポートに入力される他の通信プロトコルに対応する要請パケットを相手にフォワーディングし、以後入力されるパケットを相手に単純に中継する設定オプションを有する。
【００２９】
ここで、特定の通信プロトコルは、ＨＴＴＰであり、特定の通信プロトコルに対応する専用ポートは、８０ポートである。本実施形態に係るネットワーク装置３００は、クライアント１０から８０ポートに入力されるＳＳＬ、Ｓｋｙｐｅ（登録商標）のようなｎｏｎ−ＨＴＴＰパケットをサービスサーバ３０に伝達する通信を実現する。
【００３０】
そして、ネットワーク装置３００は、以後、クライアント１０から入力されるパケットに対してもやはり負荷分散、保安のような一例のＬ７（レイヤ７：アプリケーション層）に関わる処理を実行せずに単純にパケットを相手に中継する通信を実現する。
【００３１】
また、追加的な態様によって一実施形態に係るネットワーク装置３００は、クライアント１０から通信前処理のために特定プロトコルの専用ポートに入力されるＴＣＰハンドシェイキングのパケットを、遅延バインディング機能処理を実行せずに単純に相手に中継することを特徴とする。
【００３２】
ネットワーク装置３００は、クライアント１０から、接続準備ができているかを問うパケット、すなわち、ＳＹＮパケットを受信すると（Ｓ３００）、クライアント１０に現在接続準備ができており、クライアント１０に送る準備ができているかを問うパケット、すなわち、ＳＹＮ／ＡＣＫパケットをクライアント１０に伝送する前に、接続準備ができているかを問うパケット、すなわち、ＳＹＮパケットをサービスサーバ３０に伝達する（Ｓ３０２）。
【００３３】
そして、ネットワーク装置３００は、サービスサーバ３０から、接続準備ができており、送信メッセージが準備されているかを問うパケット、すなわち、ＳＹＮ／ＡＣＫパケットを受信し（Ｓ３０４）、そのＳＹＮ／ＡＣＫパケットをクライアント１０に伝達する（Ｓ３０６）。また、ネットワーク装置３００は、クライアント１０から、メッセージ送信準備ができたということを知らせるパケット、すなわち、ＡＣＫパケットを受信すると（Ｓ３０８）、そのＡＣＫパケットをサービスサーバ３０に伝達する（Ｓ３０９）。すなわち、従来、ネットワーク装置が実際のＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットをクライアント１０から受信するまでは、ネットワーク装置２０とサービスサーバ３０との間にＴＣＰハンドシェイキングが実行されていないものとは異なって、本発明の一実施形態によれば、ネットワーク装置３００では、クライアント１０との間のＴＣＰハンドシェイキングが実行されると同時に、サービスサーバ３０との間でもＴＣＰハンドシェイキングが実行される。
【００３４】
このＴＣＰハンドシェイキング動作により、ネットワーク装置３００は、クライアント１０からＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットを受信すると（Ｓ３１０）、これを直ちにサービスサーバ３０に伝達することができる（Ｓ３１２）。サービスサーバ３０は、そのＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットに対応するＨＴＴＰ応答（ＨＴＴＰ  ｒｅｓｐ．）パケットをクライアント１０に伝送する（Ｓ３１６）。
【００３５】
一方、ネットワーク装置３００は、クライアント１０から受信するＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットの内容を理解して（Ｓ３２０）、キャッシュサーバ４０への伝達が必要であると判断した場合には、キャッシュ４０との間でＴＣＰハンドシェイキングを行う（Ｓ３２２、Ｓ３２４）。そして、ネットワーク装置３００は、キャッシュサーバ４０にＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットを伝達する（Ｓ３２６）。キャッシュサーバ４０は、そのＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットに対するＨＴＴＰ応答（ＨＴＴＰ  ｒｅｓｐ．）パケットをクライアント１０に伝送する（Ｓ３２８）。
【００３６】
図４は、本発明の一実施形態に係るネットワークシステムにおいて実行されるｎｏｎ−ＨＴＴＰパケットのクライアントプッシュ過程を説明するためのデータフローチャートである。
【００３７】
まず、クライアント１０と、ネットワーク装置３００と、サービスサーバ３０との間で通信を実行するためのＴＣＰハンドシェイキングが実行される。
【００３８】
ネットワーク装置３００は、クライアント１０から、接続準備ができているかを問うパケット、すなわち、ＳＹＮパケットを受信すると（Ｓ３００）、クライアント１０に、現在接続準備ができており、クライアントに送る準備ができているかを問うパケット、すなわち、ＳＹＮ／ＡＣＫパケットを伝送する前に、接続準備ができているかを問うパケット、すなわち、ＳＹＮパケットをサービスサーバ３０に伝達する（Ｓ３０２）。
【００３９】
そして、ネットワーク装置３００は、サービスサーバ３０から、接続準備ができており、送信メッセージが準備されているかを問うパケット、すなわち、ＳＹＮ／ＡＣＫパケットを受信し（Ｓ３０４）、そのＳＹＮ／ＡＣＫパケットをクライアント１０に伝達する（Ｓ３０６）。また、ネットワーク装置３００は、クライアント１０から、メッセージ送信準備ができたということを知らせるパケット、すなわち、ＡＣＫパケットを受信し（Ｓ３０８）、そのＡＣＫパケットをサービスサーバ３０に伝達する（Ｓ３０９）。すなわち、従来、実際のＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットを受信するまでは、ネットワーク装置２０とサービスサーバ３０との間でＴＣＰハンドシェイキングが実行されていないものとは異なって、本発明の一実施形態によれば、ネットワーク装置３００は、クライアント１０との間でＴＣＰハンドシェイキングを実行すると同時に、サービスサーバ３０との間でもＴＣＰハンドシェイキングを実行する。
【００４０】
そして、ネットワーク装置３００は、クライアント１０からｎｏｎ−ＨＴＴＰパケットを受信する（Ｓ４００）。この際、ネットワーク装置３００は、ＨＴＴＰ専用ポート（８０ポート）にＨＴＴＰパケットではないｎｏｎ−ＨＴＴＰパケットを受信すると、負荷分散や、保安処理のような別途の処理を実行せずに、そのｎｏｎ−ＨＴＴＰパケットをサービスサーバ３０に伝達する（Ｓ４０５）。以後、ネットワーク装置３００は、クライアント１０とサービスサーバ３０との間で伝送されるパケットも別途の処理を実行せずに直ちに相手にフォワーディング（Ｆｏｒｗａｒｄｉｎｇ：再送信）する（Ｓ４１０）。
【００４１】
もし、クライアント１０が要請するウェブサービスを提供するサービスサーバ３０が存在していないか、サービスサーバ３０に障害が発生して正常に通信を行うことができない場合、サービスサーバ３０が、ネットワーク装置３００に現在接続準備ができているというパケット、すなわち、ＳＹＮ／ＡＣＫパケット（Ｓ３０４）を伝送することができない。この場合、クライアント１０とネットワーク装置３００との間、ネットワーク装置３００とサービスサーバ３０との間、いずれもＴＣＰハンドシェイキングが失敗する。そして、上述の図４に示した通信プロトコルを適用することにより、クライアント１０は、ＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットを伝送する前にサービスサーバ３０に障害が発生したということが分かる。したがって、クライアント１０が、サービスサーバ３０の障害発生を分からないままネットワーク装置３００にＨＴＴＰ要請（ＨＴＴＰ  ｒｅｑ．）パケットを伝送することによって発生しうる時間とネットワーク資源の浪費とを防止することができる。
【００４２】
図５は、本発明の一実施形態によるネットワークシステムにおいて実行されるｎｏｎ−ＨＴＴＰパケットのサーバプッシュ過程を説明するためのデータフローチャートである。
【００４３】
ネットワーク装置３００は、クライアント１０から、接続準備ができているかを問うパケット、すなわち、ＳＹＮパケットを受信すると（Ｓ３００）、クライアント１０に、現在接続準備ができており、クライアントに送る準備ができているかを問うパケット、すなわち、ＳＹＮ／ＡＣＫパケットを伝送する前に、接続準備ができているかを問うパケット、すなわち、ＳＹＮパケットをサービスサーバ３０に伝達する（Ｓ３０２）。
【００４４】
そして、ネットワーク装置３００は、サービスサーバ３０から、接続準備ができており、送信メッセージが準備されているかを問うパケット、すなわち、ＳＹＮ／ＡＣＫパケットを受信し（Ｓ３０４）、そのＳＹＮ／ＡＣＫパケットをクライアント１０に伝達する（Ｓ３０６）。また、ネットワーク装置３００は、クライアント１０からメッセージ送信準備ができたということを知らせるパケット、すなわち、ＡＣＫパケットを受信し（Ｓ３０８）、そのＡＣＫパケットをサービスサーバ３０に伝達する（Ｓ３０９）。本発明の一実施形態によれば、ネットワーク装置３００は、クライアント１０との間でＴＣＰハンドシェイキングを実行すると同時に、サービスサーバ３０との間でもＴＣＰハンドシェイキングを実行する。
【００４５】
そして、ネットワーク装置３００は、サービスサーバ３０からｎｏｎ−ＨＴＴＰパケットを受信することができる。従来は、ネットワーク装置３００が、クライアント１０からＨＴＴＰパケットを受信するまでは、ネットワーク装置３００とサービスサーバ３０との間でＴＣＰハンドシェイキングが実行されていないために、サービスサーバ３０が、クライアント１０の接続状態を認識することが不可能であった。しかし、本発明の一実施形態のネットワーク装置３００が、遅延バインディング（Ｄｅｌａｙｅｄ  Ｂｉｎｄｉｎｇ）機能処理を実行せずに、クライアント１０との間でＴＣＰハンドシェイキングを実行すると同時に、サービスサーバ３０との間でもＴＣＰハンドシェイキングを実行するため、サーバプッシュが可能である。
【００４６】
そして、ネットワーク装置３００は、サービスサーバ３０からｎｏｎ−ＨＴＴＰパケットを受信する（Ｓ５００）。この際、ネットワーク装置３００は、ＨＴＴＰ専用ポート（８０ポート）にＨＴＴＰパケットではないｎｏｎ−ＨＴＴＰパケットを受信すると、負荷分散や、保安処理のような別途の処理を実行せずにサービスサーバ３０にｎｏｎ−ＨＴＴＰパケットを伝達する（Ｓ５０５）。以後、ネットワーク装置３００は、クライアント１０とサービスサーバ３０との間で伝送されるｎｏｎ−ＨＴＴＰパケットに対して負荷分散や、保安のような処理を一切実行せずに単純にｎｏｎ−ＨＴＴＰパケットを相手にフォワーディング（Ｆｏｒｗａｒｄｉｎｇ：再送信）する（Ｓ５１０）。
【００４７】
なお、上述したパケット通信処理方法は、コンピュータプログラムとして作成可能である。また、このプログラムは、コンピュータで読み取り可能な情報記録媒体（ｃｏｍｐｕｔｅｒ  ｒｅａｄａｂｌｅ  ｍｅｄｉａ）に保存され、コンピュータによって読み取られて実行されることで実現可能である。この記録媒体は、磁気記録媒体、光記録媒体などを含む。
【００４８】
以上、本発明について望ましい実施形態を中心に説明した。当業者は、本発明が、本発明の本質的な特性から外れない範囲で変形された形態として具現可能であるということを理解できるであろう。したがって、開示された実施形態は限定的な観点ではなく、説明的な観点で考慮されなければならない。本発明の範囲は、特許請求の範囲に表われており、それと同等な範囲内にあるあらゆる差点は、本発明に含まれたものと解釈されなければならない。
【符号の説明】
【００４９】
１０…クライアント、３０…サービスサーバ、４０…キャッシュサーバ、３００…ネットワーク装置。
【図１】
2010183553.tif 000003
【図２】
2010183553.tif 000004
【図３】
2010183553.tif 000005
【図４】
2010183553.tif 000006
【図５】
2010183553.tif 000007