(57)【要約】【課題】サーバ側でのパイプライン処理を支援する。【解決手段】パイプライン処理支援装置２であって、各クライアント１から送信されたリクエストを受信して、バッファ記憶手段２３に記憶する受信手段２１と、バッファ記憶手段２３に記憶されたリクエストの送信元アドレスを用いて、リクエストの送信元のクライアント１を特定し、バッファ記憶手段２３のリクエストをクライアント１毎に並べ替えるアドレス分析手段２１と、クライアント１毎に並べ替えられたリクエストを、クライアント１がパイプライン処理で送信したように並べ替え、クライアント１毎にサーバ３へ送信するパイプライン分析手段２２と、を備える。【選択図】図１
2015035152.tif 000002
【特許請求の範囲】
【請求項１】
パイプライン処理支援装置であって、
各クライアントから送信されたリクエストを受信して、バッファ記憶手段に記憶する受信手段と、
前記バッファ記憶手段に記憶されたリクエストの送信元アドレスを用いて、リクエストの送信元のクライアントを特定し、前記バッファ記憶手段のリクエストをクライアント毎に並べ替えるアドレス分析手段と、
クライアント毎に並べ替えられたリクエストを、クライアントがパイプライン処理で送信したように並べ替え、クライアント毎にサーバへ送信するパイプライン分析手段と、を備えること
を特徴とするパイプライン処理支援装置。
【請求項２】
請求項１記載のパイプライン処理支援装置であって、
前記アドレス分析手段は、前記バッファ記憶手段に記憶されたリクエストの数が所定の値を越えたタイミング、または、前記バッファ記憶手段に最初のリクエストを記憶してから所定の時間が経過したタイミングで、前記バッファ記憶手段のリクエストを読み出して送信元のクライアントを特定し、クライアント毎に並べ替えること
を特徴とするパイプライン処理支援装置。
【請求項３】
請求項１または２記載のパイプライン処理支援装置であって、
前記アドレス分析手段は、前記バッファ記憶手段に記憶されたリクエストの送信先アドレスを用いて、リクエストの送信先のサーバを特定し、特定したサーバ単位で、前記バッファ記憶手段のリクエストをクライアント毎に並べ替え、
前記パイプライン分析手段は、サーバ単位で、クライアント毎に並べ替えられたリクエストを、クライアントがパイプライン処理で送信したように並べ替え、各サーバへクライアント毎に送信すること
を特徴とするパイプライン処理支援装置。
【請求項４】
請求項１から３のいずれか一項に記載のパイプライン処理支援装置であって、
前記パイプライン分析手段は、リクエストに含まれる所定のパラメータを用いて同じパイプライン処理で送信されたリクエストを特定し、特定したリクエストが連続するように並べ替えること
を特徴とするパイプライン処理支援装置。
【請求項５】
パイプライン処理支援装置が行うパイプライン処理支援方法であって、
各クライアントから送信されたリクエストを受信して、バッファ記憶部に記憶する受信ステップと、
前記バッファ記憶部に記憶されたリクエストの送信元アドレスを用いて、リクエストの送信元のクライアントを特定し、前記バッファ記憶部のリクエストをクライアント毎に並べ替えるアドレス分析ステップと、
クライアント毎に並べ替えられたリクエストを、クライアントがパイプライン処理で送信したように並べ替え、クライアント毎にサーバへ送信するパイプライン分析ステップと、を行うこと
を特徴とするパイプライン処理支援方法。
【請求項６】
請求項５記載のパイプライン処理支援方法であって、
前記アドレス分析ステップは、前記バッファ記憶部に記憶されたリクエストの数が所定の値を越えたタイミング、または、前記バッファ記憶部に最初のリクエストを記憶してから所定の時間が経過したタイミングで、前記バッファ記憶部のリクエストを読み出して送信元のクライアントを特定し、クライアント毎に並べ替えること
を特徴とするパイプライン処理支援方法。
【請求項７】
請求項５または６記載のパイプライン処理支援方法であって、
前記アドレス分析ステップは、前記バッファ記憶部に記憶されたリクエストの送信先アドレスを用いて、リクエストの送信先のサーバを特定し、特定したサーバ単位で、前記バッファ記憶部のリクエストをクライアント毎に並べ替え、
前記パイプライン分析ステップは、サーバ単位で、クライアント毎に並べ替えられたリクエストを、クライアントがパイプライン処理で送信したように並べ替え、各サーバへクライアント毎に送信すること
を特徴とするパイプライン処理支援方法。
【請求項８】
請求項５から７のいずれか一項に記載のパイプライン処理支援方法であって、
前記パイプライン分析ステップは、リクエストに含まれる所定のパラメータを用いて同じパイプライン処理で送信されたリクエストを特定し、特定したリクエストが連続するように並べ替えること
を特徴とするパイプライン処理支援方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント−サーバモデルのリクエスト−レスポンス型の通信において、パイプライン処理を支援するパイプライン処理支援装置、およびパイプライン処理支援方法に関する。
【背景技術】
【０００２】
近年では、電子メール、ウェブショッピング等の様々なサービスがインターネットを介したIPネットワークにて実現されている。その多くはクライアント−サーバモデルによる分散処理によって構成され、サービス利用者はクライアントからサーバに対してリクエスト信号を送信し、その後、サーバからそのリクエスト信号に応じたレスポンス信号をクライアントが受信することで実現している。
【０００３】
クライアント−サーバモデルのリクエスト−レスポンス型の通信では、１つのリクエスト信号に対し、１つのレスポンス信号を返却するため、クライアントは送信済みのリクエスト信号に対するレスポンス信号が返却されるまで次のリクエスト信号を送信できない。これに対し、処理効率化のために通信をパイプライン化してレスポンス信号を待たずに複数のリクエスト信号をサーバへ送信する手法がある（非特許文献１）。また、特許文献１には、移動体端末装置でコンテンツを取得するための時間を短縮するための移動通信ネットワークシステムが記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開2008-152629号公報
【非特許文献】
【０００５】
【非特許文献１】RFC2616 “Hypertext Transfer Protocol -- HTTP/1.1” section 8.1.2.2  (The Internet Society)
【発明の概要】
【発明が解決しようとする課題】
【０００６】
非特許文献１では、クライアントがサーバからのレスポンス信号を待つ間に、他のリクエスト信号が送信できないことによる効率の悪さから、複数のリクエスト信号を一度に送信できるパイプライン化が提案されている。しかしながら、複数のクライアントと同時に通信するサーバでは、各クライアントがパイプラインでリクエスト信号を送信しても、他のクライアントからのリクエスト信号が混在してしまうため、サーバ側ではクライアント側のようにパイプライン処理が実装できないという問題がある。また、特許文献１でも、サーバ側のパイプライン処理については考慮されていない。
【０００７】
本発明は、上記の事情に鑑みなされたもので、本発明の目的は、サーバ側でのパイプライン処理を支援するパイプライン処理支援装置およびパイプライン処理支援方法を提供することにある。
【課題を解決するための手段】
【０００８】
上記の課題を解決するため、請求項１記載の本発明は、パイプライン処理支援装置であって、各クライアントから送信されたリクエストを受信して、バッファ記憶手段に記憶する受信手段と、前記バッファ記憶手段に記憶されたリクエストの送信元アドレスを用いて、リクエストの送信元のクライアントを特定し、前記バッファ記憶手段のリクエストをクライアント毎に並べ替えるアドレス分析手段と、クライアント毎に並べ替えられたリクエストを、クライアントがパイプライン処理で送信したように並べ替え、クライアント毎にサーバへ送信するパイプライン分析手段と、を備える。
【０００９】
請求項２記載の本発明は、前記パイプライン処理支援装置において、前記アドレス分析手段は、前記バッファ記憶手段に記憶されたリクエストの数が所定の値を越えたタイミング、または、前記バッファ記憶手段に最初のリクエストを記憶してから所定の時間が経過したタイミングで、前記バッファ記憶手段のリクエストを読み出して送信元のクライアントを特定し、クライアント毎に並べ替える。
【００１０】
請求項３記載の本発明は、前記パイプライン処理支援装置において、前記アドレス分析手段は、前記バッファ記憶手段に記憶されたリクエストの送信先アドレスを用いて、リクエストの送信先のサーバを特定し、特定したサーバ単位で、前記バッファ記憶手段のリクエストをクライアント毎に並べ替え、前記パイプライン分析手段は、サーバ単位で、クライアント毎に並べ替えられたリクエストを、クライアントがパイプライン処理で送信したように並べ替え、各サーバへクライアント毎に送信する。
【００１１】
請求項４記載の本発明は、前記パイプライン処理支援装置において、前記パイプライン分析手段は、リクエストに含まれる所定のパラメータを用いて同じパイプライン処理で送信されたリクエストを特定し、特定したリクエストが連続するように並べ替える。
【００１２】
請求項５記載の本発明は、パイプライン処理支援装置が行うパイプライン処理支援方法であって、各クライアントから送信されたリクエストを受信して、バッファ記憶部に記憶する受信ステップと、前記バッファ記憶部に記憶されたリクエストの送信元アドレスを用いて、リクエストの送信元のクライアントを特定し、前記バッファ記憶部のリクエストをクライアント毎に並べ替えるアドレス分析ステップと、クライアント毎に並べ替えられたリクエストを、クライアントがパイプライン処理で送信したように並べ替え、クライアント毎にサーバへ送信するパイプライン分析ステップと、を行う。
【００１３】
請求項６記載の本発明は、前記パイプライン処理支援方法において、前記アドレス分析ステップは、前記バッファ記憶部に記憶されたリクエストの数が所定の値を越えたタイミング、または、前記バッファ記憶部に最初のリクエストを記憶してから所定の時間が経過したタイミングで、前記バッファ記憶部のリクエストを読み出して送信元のクライアントを特定し、クライアント毎に並べ替える。
【００１４】
請求項７記載の本発明は、前記パイプライン処理支援方法において、前記アドレス分析ステップは、前記バッファ記憶部に記憶されたリクエストの送信先アドレスを用いて、リクエストの送信先のサーバを特定し、特定したサーバ単位で、前記バッファ記憶部のリクエストをクライアント毎に並べ替え、前記パイプライン分析ステップは、サーバ単位で、クライアント毎に並べ替えられたリクエストを、クライアントがパイプライン処理で送信したように並べ替え、各サーバへクライアント毎に送信する。
【００１５】
請求項８記載の本発明は、前記パイプライン処理支援方法において、前記パイプライン分析ステップは、リクエストに含まれる所定のパラメータを用いて同じパイプライン処理で送信されたリクエストを特定し、特定したリクエストが連続するように並べ替える。
【発明の効果】
【００１６】
本発明によれば、サーバ側でのパイプライン処理を支援するパイプライン処理支援装置およびパイプライン処理支援方法を提供することができる。
【図面の簡単な説明】
【００１７】
【図１】本実施形態における通信システムの全体構成図である。
【図２】パイプライン処理支援装置の構成を示すブロック図である。
【図３】クライアント−サーバモデルのリクエスト−レスポンス型の通信の一例である。
【図４】複数のクライアントと、サーバとが対向する場合のリクエスト−レスポンス型の通信の一例である。
【図５】本実施形態のパイプライン処理支援装置の処理を示すシーケンス図である。
【図６】サーバの処理を示すフローチャートである。
【発明を実施するための形態】
【００１８】
以下、本発明の実施の形態を、図面を用いて説明する。
【００１９】
図１は、本発明の実施形態における通信システムの構成例を示す図である。本実施形態の通信システムは、クライアント−サーバモデルのリクエスト−レスポンス型の通信において、ネットワーク内で各クライアントが送信したようにリクエストを並べ替え、サーバ側でのパイプライン処理を支援するものである。なお、リクエスト−レスポンス型の通信は、ＩＰネットワークにおいて、例えば、ｗｅｂやメールなどで広く利用されている。
【００２０】
図示する通信システムは、複数のクライアント１と、ネットワーク内に配置されたパイプライン処理支援装置２と、少なくとも１つのサーバ３とを備える。サーバ３は、図１に示すように複数であっても、１つであってもよい。ネットワークには、例えばインターネットなどのＩＰネットワークを用いることができる。
【００２１】
本実施形態のクライアント１は、処理効率を向上させるために、リクエスト毎に逐一レスポンスを待たず、複数のリクエストをまとめて送信するパイプライン処理が実装された装置である。パイプライン処理は、同一のサーバに複数のレスポンスをまとめて送信する処理である。パイプライン処理については、非特許文献１に記載されている。クライアント１には、例えば、スマートフォン、ＰＣ、タブレット端末などを用いることができる。
【００２２】
パイプライン処理支援装置２は、各クライアント１から各サーバ３に送信されたリクエストを、サーバ３側でのパイプライン処理が可能になるように、ネットワーク内で並べ替えてパイプライン化し、各サーバ３に送信する。パイプライン処理支援装置２は、サーバ３でのパイプライン処理を支援する装置である。
【００２３】
図２は、本実施形態のパイプライン処理支援装置２の機能を示す機能ブロック図である。図示するパイプライン処理支援装置２は、アドレス分析部２１と、パイプライン分析部２２と、バッファ記憶部２３とを備える。
【００２４】
アドレス分析部２１（受信手段、アドレス分析手段）は、各クライアント１から送信されたリクエストを受信して、バッファ記憶部２３に記憶する。そして、アドレス分析部２１は、バッファ記憶部２３に記憶されたリクエストの送信元アドレスを用いて、リクエストの送信元のクライアント１を特定し、バッファ記憶部２３のリクエストをクライアント１毎に並べ替える。すなわち、リクエストをクライアント１毎にグルーピングする。また、アドレス分析部２１は、バッファ記憶部２３に記憶されたリクエストの数が所定の値を越えたタイミング、または、バッファ記憶部２３に最初のリクエストを記憶してから所定の時間が経過したタイミングで、バッファ記憶部２３のリクエストを読み出し、クライアント毎に並べ替える。
【００２５】
パイプライン分析部２２（パイプライン分析手段）は、アドレス分析部２１により並べ替えられたクライアント１毎のリクエストを、当該クライアント１がパイプライン処理で送信したように並べ替え、並べ替えたリクエストをクライアント１毎にサーバ３へ送信する。本実施形態では、クライアント１がパイプライン処理で送信したリクエストについては連続するように並べ替えるものとする。
【００２６】
バッファ記憶部２３（バッファ記憶手段）には、各クライアント１から送信されたリクエストが記憶される。
【００２７】
なお、上記説明したパイプライン処理支援装置２は、例えば、ＣＰＵと、メモリと、ＨＤＤ等の外部記憶装置などを備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵがメモリ上にロードされたパイプライン処理支援装置２のプログラムを実行することにより、パイプライン処理支援装置２の各機能が実現される。また、パイプライン処理支援装置２用のプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ−ＲＯＭなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。
【００２８】
また、パイプライン処理支援装置２に、サーバを用いることとしてもよく、また、パケット信号の分析機能（DPI：Deep Packet Inspection）が実装されたルータやスイッチなどのネットワーク機器を用いることとしてもよい。また、パイプライン処理支援装置２は、複数の装置から構成されるものであってよい。
【００２９】
本実施形態の処理を説明する前に、ここでは、一般的なリクエスト−レスポンス型の通信について説明する。
【００３０】
図３は、クライアント−サーバモデルのリクエスト−レスポンス型の通信の一例である。図３（ａ）は、通常の通信のシーケンス図である、図３（ｂ）は、パイプライン処理を行う場合の通信のシーケンス図である。クライアントとサーバとは、ネットワークを介してリクエスト（リクエスト信号）およびレスポンス（レスポンス信号）を送受信する。
【００３１】
図３（ａ）では、クライアントは、サーバに対してリクエスト１を送信し、その後、サーバからのレスポンスを待つ（Ｓ１１）。サーバは、リクエスト１を受信すると、当該リクエスト１に対するレスポンス１をクライアントに送信する（Ｓ１２）。クライアントは、リクエスト１に対するレスポンス１を受信後、次のリクエスト２をサーバ３に送信する（Ｓ１３）。サーバは、リクエスト２を受信すると、当該リクエスト２に対するレスポンス２をクライアントに送信する（Ｓ１４）。
【００３２】
このように、図３（ａ）の通信では、１つのリクエストに対して１つのレスポンスを返却するため、クライアントでは、送信済みのリクエストに対するレスポンスが返ってくるまで次のリクエストを送信できず、処理効率が良くない。
【００３３】
これに対し、図３（ｂ）では、クライアントは、パイプライン処理により、複数のリクエスト１、２をまとめてサーバに送信する（Ｓ２１、Ｓ２２）。そして、サーバは、受信したリクエスト１、２に対するレスポンス１、２をクライアントに送信する（Ｓ２３、２４）。このように、図３（ｂ）の通信では、クライアントは、パイプライン処理を行うとで、サーバからのレスポンスを待たずに、複数のリクエストをサーバに送信する。これより、クライアント側でのレスポンスの待ち時間が減って処理効率を向上させることができる。
【００３４】
図４は、複数のクライアントと、サーバとが対向する場合のリクエスト−レスポンス型の通信のシーケンス図である。
【００３５】
クライアントＡは、リクエストＡ１、Ａ２、Ａ３については、パイプライン処理によりパイプライン化してまとめて送信し（Ｓ３１、Ｓ３３、Ｓ３５）、その後、非パイプラインでリクエストＡ４を送信する（Ｓ３８）。  
クライアントＢは、リクエストＢ１、Ｂ２をパイプライン処理によりパイプライン化してまとめて送信し（Ｓ３２、Ｓ３４）、その後、リクエストＢ３、Ｂ４も別のパイプライン処理によりパイプライン化してまとめて送信する（Ｓ３６、Ｓ３７）。
【００３６】
各クライアントＡ、Ｂが送信したリクエストは、ネットワークに到着した順に処理され、サーバに送信される。したがって、複数のクライアントＡ、Ｂが送信したリクエストを受信し、処理するサーバでは、クライアント側ではパイプライン処理により複数のリクエストをまとめて送信しても、他のクライアントからのリクエストと混じって受信される。すなわち、複数のクライアントのリクエストが混在してサーバに到着するため、サーバ側では、処理効率向上のためのパイプライン処理を行うことができない。
【００３７】
次に、本実施形態の処理について説明する。
【００３８】
図５は、本実施形態のパイプライン処理支援装置２の処理を示すシーケンス図である。図５では、複数のクライアントＡ、Ｂは、図４と同様のリクエスト（リクエスト信号）をネットワークを介してサーバに送信する（Ｓ４１）。
【００３９】
ネットワーク上に配置されたパイプライン処理支援装置２のアドレス分析部２１は、各クライアントＡ、Ｂから送信されたリクエストを受信し、一旦、バッファ記憶部２３に記憶する（Ｓ４２）。アドレス分析部２１に到着するリクエストは、図５に示すように、複数のクライアントＡ、Ｂからのリクエストが混在しており、各クライアントが送信したようなパイプライン化されたリクエストの順序とは異なるものである。
【００４０】
そして、アドレス分析部２１は、リクエストの受信状況およびバッファ記憶部２３の状態を監視し、バッファ記憶部２３に記憶されたリクエストの数が所定の値を越えたタイミング、または、バッファ記憶部２３に最初のリクエストを記憶してから所定の時間が経過したタイミングで、バッファ記憶部２３に記憶された全てのリクエストを読み出して、以下の処理を開始する（Ｓ４３）。
【００４１】
なお、上記所定の値または上記所定の時間の閾値は、パイプライン処理支援装置２の図示しない記憶部に記憶されているものとする。また、これらの閾値は、サーバの処理内容またはサービス内容に応じて設定される。また、アドレス分析部２１は、バッファ記憶部２３のリクエストを読み出すと、バッファ記憶部２３を初期化する。
【００４２】
アドレス分析部２１は、上記タイミングで読み出した各リクエストについて、当該リクエス（ＩＰパケット）のＩＰヘッダに設定されたアドレスを分析する（Ｓ４３）。具体的には、アドレス分析部２１は、ＩＰヘッダの送信元アドレスを用いて、リクエストの送信元のクライアントを特定するとともに、ＩＰヘッダの送信先アドレスを用いて、リクエストの送信先のサーバを特定する。
【００４３】
そして、アドレス分析部２１は、送信先のサーバが処理対象のサーバか否かを判別する。処理対象のサーバか否かの判断は、例えば、パイプライン処理支援装置２の図示しない記憶部に、処理対象のサーバの識別情報（または、処理対象外のサーバの識別情報）が記憶されているものとする。
【００４４】
処理対象外のサーバを送信先とするリクエストについては、アドレス分析部２１は、以下の処理を行うことなく、当該アドレス分析部２１に到着した順に、送信先のサーバに送信する。
【００４５】
処理対象のサーバを送信先とするリクエストについては、アドレス分析部２１は、処理対象の各サーバ宛のリクエストを、クライアント毎に並べ替え（ソートし）、パイプライン分析部２２に送出する（Ｓ４４）。これにより、図５に示すように、図示するサーバ宛のリクエストは、送信元のクライアント毎にグルーピングされて、パイプライン分析部２２に送出される。なお、クライアント毎のリクエストの並び順は、基本的には、アドレス分析部２１にリクエストが到着した順番となる。
【００４６】
パイプライン分析部２２は、サーバ単位で、クライアント毎にソートされたリクエストを、各クライアントがパイプライン処理で送信したように並べ替え、並べ替えたリクエストを各サーバへクライアント毎に送信する（Ｓ４５）。すなわち、パイプライン分析部２２は、通信プロトコルまたは提供サービスに応じてリクエストのデータ内容（ヘッダ情報、メッセージ内容）を分析し、サーバ側でもパイプライン処理ができるように、各クライアントがパイプライン処理で送信したリクエストについては連続するように並べ替えて、リクエストのパイプライン化を再構築してサーバに送信する。
【００４７】
本実施形態では、パイプライン分析部２２は、リクエストに含まれる所定のパラメータを用いて、同じパイプライン処理で送信されたリクエストを特定し、特定した同じパイプライン処理で送信されたリクエストが連続するように並べ替え、クライアント毎のリクエストの並び順を正規化する。
【００４８】
例えば、ＨＴＴＰプロトコルを用いた通信の場合、パイプライン分析部２２は、リクエストのＴＣＰヘッダ部の送信元ポート番号を用いて同じパイプライン処理で送信されたリクエストを特定する。すなわち、同じ送信元ポート番号が設定されたリクエストは、同じパイプライン処理で送信されたリクエストであると判別する。そして、パイプライン分析部２２は、同じパイプライン処理で送信されたリクエストが連続して並んでいない場合は、送信元ポート番号でソートするなどして、同じパイプライン処理で送信されたリクエストが連続するようにリクエストの順番を並び替える。
【００４９】
同一時刻に同一クライアントから別のポート番号を用いて同一サーバへのリクエストが複数送信された場合（例えば、複数のブラウザから同時にリクエストが送信された場合など）、同じパイプライン処理でまとめて送信されたはずのリクエストが連続してアドレス分析部２１に到着しないことがあるが、本実施形態では、パイプライン分析部２２が、同じパイプライン処理で送信されたリクエストを特定し、同じパイプライン処理で送信されたリクエストが連続するように、クライアント毎のリクエストの並び順を変えることで、同じパイプライン処理に属するリクエストが連続した並び順になり、各クライアントがパイプライン処理で送信したようにリクエストをパイプライン化することができる。
【００５０】
また、クライアントで、例えばＷｅｂページを閲覧する際に、同一画面で本文と画像とをパイプライン処理でリクエストを送信するのと、動画だけを単体で閲覧するためにリクエストを送信するのとは、本来関連ないが、アドレス分析部２１が行うクライアント毎のリクエストの並べ替えだけでは、全て同一パイプラインで送信されたものとサーバが認識してしま恐れがあり、また、Ｗｅｂページを閲覧する際のパイプライン処理の複数のリクエストの間に動画を閲覧するためのリクエストがまぎれてしまう場合がある。このため、本実施形態では、パイプライン分析部２２が、クライアントがパイプライン処理で送信したようにリクエストを並べ替え、パイプライン構成を再現する。
【００５１】
なお、ＨＴＴＰプロトコルを用いた通信では、以下の３つのパターンがある。
【００５２】
（１）１回のリクエスト−レスポンス毎に通信を切断し、その度にクライアントのポート（ポート番号）が変わるパターン
（２）Ｋｅｅｐ−Ａｌｉｖｅ機能を用いるパターンであって、１回のリクエスト−レスポンス毎に通信を切断せず、次のリクエスト−レスポンスにも同じクライアントのポート（ポート番号）が使用されるパターン。
【００５３】
（３）Ｋｅｅｐ−Ａｌｉｖｅ機能を用い、さらにパイプライン処理でリクエストを送信するパターンであって、複数のリクエストおよび複数のレスポンスは、同じクライアントのポートが使用されるパターン。
【００５４】
（１）のパターンについては、同じポート番号のリクエストは１つしかないため、パイプライン分析部２２は、パイプライン処理のリクエストではないと判別する。（２）のパターンについては、同じポート番号で複数のリクエストが送信されるが、（２）では１つのリクエストを送信した後、レスポンスが返ってくるまで次のリクエストが送信されないため、パイプライン分析部２２は、常に１つのリクエストしか受信しない。したがって、パイプライン分析部２２は、（２）のパターンについても、（１）と同様に、パイプライン処理で送信されたリクエストではないと判別する。
【００５５】
なお、ＨＴＴＰプロトコル以外の通信においても、対応する通信プロトコルのリクエストに含まれる所定のパラメータ（例えば、パイプライン対応有無、コネクションクローズの有無など）を用いて、パイプライン分析部２２は、同じパイプライン処理で送信されたリクエストを特定し、特定したリクエストが連続するように並べ替える。
【００５６】
このようなパイプライン分析部２２の処理により、図５に示すように、図示するサーバ宛のリクエストは、送信元のクライアント毎に、当該クライアントがパイプライン処理で送信したように並べ替えられて送信される。
【００５７】
以上説明した本実施形態では、パイプライン処理支援装置２が、クライアント毎に、また、クライアントでのパイプライン処理を意識してリクエストを並べ替え、各サーバに送信する。サーバは、パイプライン処理支援装置２が並べ替えた順序でリクエストを受信できるため、本実施形態では、サーバ側でも、クライアントと同様に、レスポンス送信時にパイプライン処理が可能となり、処理効率を向上させることができる。すなわち、複数のクライアントからのリクエストを処理するサーバであっても、レスポンス処理をパイプライン化し、サーバの内部処理の効率化を図り、処理効率を向上させることができる。これにより、クライアント側にとっても総待ち時間の短縮が可能になる。
【００５８】
図６は、本実施形態におけるサーバの処理の一例を示すフローチャートである。サーバは、パイプライン処理支援装置２から送信されたリクエストが格納されるキュー（ＳＯＣＫＥＴのＦＩＦＯキュー）から、リクエストを１つ取り出し（Ｓ５１）、リクエストの内容を分析する（Ｓ５２）。そして、サーバは、キューから次のリクエストを１つ取り出し（Ｓ５３）、取り出したリクエストがＳ５１のリクエストと同じパイプライン処理のリクエストか否かを判別する（Ｓ５４）。Ｓ５１と同じパイプライン処理のリクエストの場合（Ｓ５４：ＹＥＳ）、サーバは、Ｓ５２に戻り、Ｓ５３で取り出したリクエストの内容を分析し、Ｓ５１のパイプライン処理のリクエストと異なるリクエストを取り出すまで（Ｓ５４：ＮＯ）、Ｓ５２〜Ｓ５４の処理を繰り返す。そして、サーバは、Ｓ５４：ＮＯの場合、Ｓ５１と同じパイプライン処理の各リクエストについてのレスポンスデータを生成し（Ｓ５５）、レスポンスをクライアントに送信する。図６に示す処理では、サーバは、Ｓ５５およびＳ５６の処理をパイプライン処理により、効率的に処理することができる。
【００５９】
また、本実施形態では、ネットワーク上にパイプライン処理支援装置２を設けることで、各サーバが提供するサービスに依存することなく、サーバ側での処理を効率化することができる。
【００６０】
なお、本発明は上記実施形態に限定されるものではなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【００６１】
１  ：クライアント
２  ：パイプライン処理支援装置
２１：アドレス分析部
２２：パイプライン分析部
２３：バッファ記憶部
３  ：サーバ
【図１】
2015035152.tif 000003
【図２】
2015035152.tif 000004
【図３】
2015035152.tif 000005
【図４】
2015035152.tif 000006
【図５】
2015035152.tif 000007
【図６】
2015035152.tif 000008