JP2003152783A - サーバ負荷分散装置 - Google Patents

Abstract

(57)【要約】 【課題】同一クライアントによる同一セッションの要求
を同一サーバに転送するサーバ負荷分散装置に関し、サ
ービス提供者の希望に応じたクライアントに対する優先
制御を可能にする。 【解決手段】優先度情報記憶手段が、クライアントから
の新規セッションの接続要求に応答して振分先サーバが
該新規セッション毎に割り当てるセッション識別子に対
し、優先度情報を対応付けて記憶すると共に各優先度情
報に対応した通信品質を記憶し、転送手段が、該クライ
アント又は該サーバからパケットを受信したとき、該パ
ケットを該優先度情報に基づく通信品質で転送する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、サーバ負荷分散装
置に関し、特に同一クライアントによる同一セッション
の要求を同一サーバに転送するサーバ負荷分散装置に関
する。インターネット上の電子商取引として、例えば、
電子バンクや電子モールなどのサービスを提供者するサ
ービス提供者は、一般にサービス提供のための複数のサ
ーバから成るサーバ群（サーバファーム）を有してお
り、このようなサーバ群を収容するデータセンタ内やネ
ットワーク上の入り口には、サーバ負荷分散機能を有す
る装置を配置している。

【０００２】サーバ負荷分散機能とは、複数のサーバに
処理を分散させることにより、サービス応答時間を短縮
し、安定的なサービスの提供を実現する機能であり、以
下の説明においては、このようなサーバ負荷分散機能を
有する装置をサーバ負荷分散装置（サーバロードバラン
サ及びルータなどのネットワーク機器を含む。）と称す
る。

【０００３】サーバ負荷分散装置は、クライアントによ
るサーバサービスへのアクセス毎に、L4（レイヤ４;TC
P,UDP等）レベルのポート番号や、さらに高位レイヤのU
RL情報等に基づき、予め定められたルール、あるいは、
個々のサーバの負荷状態に応じて、サーバ群内のサーバ
にトラヒックを振り分ける。

【０００４】これにより、各サーバへの過度のアクセス
を回避するだけでなく、障害が発生したサーバの切り離
しやサーバの新規追加などを容易にすることが可能とな
る。従って、トラフィックの集中に備えるだけでなく、
耐障害性と拡張性を保持した柔軟なシステム構築を可能
とするサーバ負荷分散処理技術が求められている。

【０００５】

【従来の技術】図17は、一般的なサーバ負荷分散装置に
よるサーバ負荷分散処理例を示したものである。図示の
如く、サービス提供者A及びBは、それぞれ複数のサーバ
A1〜Anから成るサーバ群SG_A、及びサーバB1〜Bnから成
るサーバ群SG_Bを用いてサービスを提供している。ま
た、各サーバA1〜An及びサーバB1〜Bnは、サーバ負荷分
散装置LBを介してインターネットNWに接続されており、
ユーザ端末であるクライアントCもインターネットNWに
接続されている。

【０００６】図示の例では、サービス提供者Bのサービ
スを利用するユーザは、ユーザ端末であるクライアント
Cからサーバ負荷分散装置LBを介してサーバB1に接続さ
れている。この場合に、クライアントCとサーバB1との
間で送受信されるパケットについてサーバ負荷分散装置
LBが行うアドレス変換処理の例を図18に示す。

【０００７】図18は、図17におけるサーバ群SG_Bに割り
当てられた仮想的なIPアドレス（代表IPアドレスまたは
仮想IPアドレスと呼ばれる。）をAvとし、仮想ポート番
号をPvとした場合の例を示している。このような仮想IP
アドレスをサーバ群に割り当てることで、複数のサーバ
を仮想的に1つのサーバとしてユーザに見せることがで
きる。

【０００８】図示の如く、例えばクライアントCは複数
のサーバB1〜Bnの存在を意識することなく、仮想IPアド
レスAv宛のパケットPK1を送信する。サーバ負荷分散装
置LBは、受信したパケットPK1の仮想IPアドレスAvか
ら、該パケットがサーバ群SG_B宛のパケットであると判
断し、予め定められたルールに基づいてサーバ群SG_Bの
中から、例えばサーバB1を振分先サーバとして選択す
る。

【０００９】サーバB1のIPアドレスはAsであるので、サ
ーバ負荷分散装置LBは、パケットPK1の宛先アドレスをA
vからAsに書き換えてパケットPK2としてサーバB1宛に送
信する。次に、サーバB1が、受信したパケットPK2に対
する応答として、送信元に対するパケットPK3を送る場
合、パケットPK3の送信元アドレスはサーバB1のIPアド
レスであるのでAsになっている。このパケットPK3を受
信したサーバ負荷分散装置LBは、送信元アドレスAsをサ
ーバB1が属しているサーバ群SG_Bの仮想IPアドレスAvに
変換し、パケットPK4としてクライアントC宛に送信す
る。

【００１０】これにより、クライアントCは、サーバ群S
G_B内のいずれのサーバに実際に接続されているかを意
識することなく、サービス提供者Bのサービスを受ける
ことが出来る。なお、上記の説明では、IPアドレスのみ
に注目したが、図示の如くポート番号についてもサーバ
負荷分散装置LBは、IPアドレスと同様な変換を行ってい
る。

【００１１】また、図示の例ではIPアドレスを使用した
が、MACアドレスを使用する場合もある。なお、サーバ
負荷分散装置による振分先サーバの選択方法としては、
単純なラウンドロビン、サーバの処理性能に応じサーバ
毎に重付けをしたラウンドロビン、サーバに接続してい
るコネクションを観測して接続コネクション数が最も少
ないサーバに転送するなど、様々な方法が用いられる。

【００１２】また、オンラインショッピングの様なサー
ビスを提供する場合には、サーバ負荷分散装置は同一ユ
ーザによる同一セッションの要求は同じサーバに転送し
なくてはならないという一貫性保持の制約がある。この
場合、送信元IPアドレスに基づくハッシュによる方法
や、SSL(Secure Socket Layer)のセッションIDやHTTPの
cookieに基づいてセッションを区別する必要がある。

【００１３】従来のサーバ負荷分散装置には、インター
ネット上の電子商取引でユーザの情報を保護するための
プロトコルとして近年広く用いられているSSLプロトコ
ルに対応したものがある。このような、SSLプロトコル
に対応したサーバ負荷分散装置LBの基本概念図を図19に
示す。

【００１４】図示の如く、サーバ負荷分散装置LBは、受
信インタフェース(I/F)部10、パケット情報抽出部20、
コネクション管理部31、パケット処理判定部32、負荷分
散サーバ選択部33、パケット情報書換部40、ルーティン
グ処理部50、パケット送出・優先制御部60、送信インタ
フェース(I/F)部70、及びSSLセッション処理部80によっ
て構成される。

【００１５】図示の二重線矢印は、外部またはサーバ負
荷分散装置LB内から受信I/F部10に与えられたパケット
が、パケット情報抽出部20、及びルーティング処理部50
を介して、パケット送出・優先制御部60に送られる様子
を示している。さらに、パケット送出・優先制御部60が
受信したパケットは、パケットの種類に応じて、送信I/
F部70又はSSLセッション処理部80に送出される。

【００１６】また、パケット情報抽出部20、コネクショ
ン管理部31、パケット処理判定部32、負荷分散サーバ選
択部33、パケット情報書換部40、ルーティング処理部5
0、パケット送出・優先制御部60、及びSSLセッション処
理部80間では、内部制御用情報が図示の点線矢印の如く
送受信される。

【００１７】また、図20〜22は、それぞれ図19に示した
サーバ負荷分散装置LBのコネクション管理部31のコネク
ション管理テーブルT31、パケット処理判定部32のルー
ルテーブルT32、及びルーティング処理部50の転送テー
ブルT50の例を示している。さらに、図23は、負荷分散
サーバ選択部33のサーバ選択リストテーブルT33_1、サ
ーバファームメンバリストテーブルT33_2、及びサーバ
情報テーブルT33_3の例を示しており、図24は、SSLセッ
ション処理部80のSSL・IDテーブルT80_1及びセッション
管理テーブルT80_2の例を示している。なお、各テーブ
ルを用いた処理については後述する。

【００１８】図19に示したサーバ負荷分散装置LBを介す
ることにより、例えば、図17におけるクライアントCと
サーバB1との間のSSLセッションが確立される。このよ
うなサーバ負荷分散装置LBを介するSSLセッションにつ
いて説明する前に、まず、基本的なSSLセッションの例
として、クライアントCとサーバS(図17におけるサーバB
1に相当するサーバ)が直接SSLセッションを確立する場
合について、図25を用いて説明する。

【００１９】まず、クライアントCとサーバSとの間で、
SYNメッセージが送受信され、TCPコネクションが開始さ
れる（ステップS1及びS2）。次に、SSLハンドシェーク
（新規セッション開始）のため、クライアントCはClien
t HelloメッセージをサーバSに送信する（同S3）。この
場合、新規のセッションであることを示すため、Client
HelloメッセージにSession ID=Oを含める。これに対
し、サーバSはSession ID=Aを割り当て、Server Hello
メッセージをクライアントCに送信する(同S4)。

【００２０】この後、図示の如くHTTPデータ転送が行わ
れ(同S5及びS6)、TCPコネクションの終了時には、クラ
イアントCとサーバSとの間でFINメッセージが互いに送
受信される（同S7及びS8）。クライアントCが、再びTCP
コネクションを開始する場合は、再度クライアントCと
サーバSとの間でSYNメッセージが送受信される（ステッ
プS9及びS10）。次に、SSLハンドシェーク（既存セッシ
ョン再開）のため、クライアントCはClient Helloメッ
セージをサーバSに送信する（同S11）。

【００２１】今回は、既存セッションの再開であること
を示すため、Client Helloメッセージ内にSession ID=A
を含める。これに対し、サーバSはSession ID=Aを含むS
erver HelloメッセージをクライアントCに送信する(同S
12)。この後、再度HTTPデータ転送が行われ(同S13及びS
14)、TCPコネクションの終了時には、クライアントCと
サーバSとの間でFINメッセージが互いに送受信される
（同S15及びS16）。

【００２２】上記の一連の処理を行う際、図19に示した
ようなサーバ負荷分散装置LBがクライアントCとサーバS
との間に設けられている場合のパケットの流れを図26及
び27を参照して、以下に説明する。図26及び27は、それ
ぞれ、新規にSSLセッションの接続要求があった場合と
既存のSSLセッションに関する接続要求があった場合に
おける、クライアントC、サーバ負荷分散装置LB及びサ
ーバS間で交換されるパケットの流れを示したものであ
る。

【００２３】すなわち、図26及び27はそれぞれ、図25に
おけるステップS1〜S6及びS9〜S14に相当する処理に関
するパケットの流れを示している。図25及び26では共
に、クライアントCとサーバ負荷分散装置LBとの間で、
まずTCP Synメッセージ及びTCP Syn Ackメッセージが送
受信され(ステップ(1)及び(2))、クライアントCからのS
SL Client Helloメッセージを受信した後(ステップ
(3))、サーバ負荷分散装置LBとサーバSとの間でTCP Syn
メッセージ及びTCP Syn Ackメッセージが送受信される
(ステップ(4)及び(5))。

【００２４】次に、サーバ負荷分散装置LBは、SSL Clie
nt HelloメッセージをサーバSに送信し(ステップ(6))、
これに応答してサーバSが送信するSSL Server Helloメ
ッセージを受信した後(ステップ(7))、これをクライア
ントCに転送する(ステップ(8))。

【００２５】上記のステップ(1)〜(8)までのパケット転
送は、サーバ負荷分散装置LB内のSSLセッション処理部8
0を介して行われた後は、クライアントCとサーバSとの
間のアプリケーションデータパケットの転送がサーバ負
荷分散装置LB内のコネクション管理部31を介して行われ
る(ステップ(9))。

【００２６】このように、図25及び26におけるパケット
の流れ自体は同じであるが、SSL Client Helloメッセー
ジ及びSSL Server Helloメッセージ受信時のサーバ負荷
分散装置LBの処理が異なる。SSLセッションが新規か否
かは、SSL Client HelloメッセージのSSLセッションID
で判断される。新規の場合、SSLセッションID=0であ
る。SSLセッションIDがゼロでない場合は、既にサーバS
との間に、セッションが確立されているため、クライア
ントCは、以前サーバSから払い出されたSSLセッションI
Dを用いて接続を要求して来る。

【００２７】従って、図26に示す如く、新規SSLセッシ
ョンの場合、サーバ負荷分散装置LBは接続先サーバを予
め定められたルールに従って選択する。また、図27に示
す如く、既存SSLセッションの場合、サーバ負荷分散装
置LBはSSL Client HelloメッセージのSSLセッションID
に対応付けられたサーバを検索する。

【００２８】上述のように、サーバ負荷分散装置LBは、
クライアントCからSSL Client Helloメッセージを受信
するまで、振分先サーバを判断することができない。従
って、上記のように、SSLセッション処理部80にてTCPの
コネクションを終端する必要がある。

【００２９】次に、TCPコネクション管理の流れを図28
を参照して説明する。同図(1)は、SSL Client Helloメ
ッセージを受信するまでのTCPコネクションを示す。図
示の如く、SSL Client Helloメッセージ受信前までは、
クライアントCとSSLセッション処理部80間のみにTCPコ
ネクションが確立されている。

【００３０】ここで、図26及び27のステップ(1)として
示したTCP Synパケットの受信時に、図28(1)のコネクシ
ョン-1及び-2で示したコネクションの内容がコネク
ション管理部31のコネクション管理テーブルT31(図20参
照)に登録され、図26及び27のステップ(2)として示した
TCP Syn Ackパケットは、図28（1）のコネクション-2
を用いて転送される。

【００３１】SSL Client Helloメッセージ受信によっ
て、振り分け先サーバを決定次第、図28(2)に示す如
く、SSLセッション処理部80とサーバS間にTCPコネクシ
ョン-1及び-2が確立される。従って、図26及び27の
ステップ(4)及び(6)として示したサーバ負荷分散装置LB
からサーバSに送信されるTCP Synパケット及びSSL Clie
nt Helloメッセージは、図28(2)のコネクション-2で
転送される。

【００３２】同様に、図26及び27のステップ(5)及び(7)
として示したサーバSからサーバ負荷分散装置LBに送信
されるTCP Syn Ackパケット及びSSL Server Helloメッ
セージは、図28(2)のコネクション-1で転送される。
新規SSLセッション処理時において、サーバSからのSSL
Server Helloメッセージを受信することにより、サーバ
SとSSLセッションID(以降、SSL・IDと称する場合があ
る。)の対応関係が明らかになるので、SSLセッション処
理部80は、この対応関係をSSL・IDテーブルT80_1(図24
(1)参照)に登録する。

【００３３】また、その後に受信するパケットについ
て、SSLセッション処理部80を介さずに、SSLよりも低レ
ベルのレイヤのみによって高速に転送するために、コネ
クション管理部31のコネクション管理テーブルT31(図20
参照)の設定を変更し、図28(2)のコネクション-1及び
-1をそれぞれ、同図(3)のコネクション-1’及び-
1’に変更する。

【００３４】これにより、SSL Server Helloメッセージ
の転送後は、クライアントCとサーバSとの間で送受信さ
れるパケットが、SSLセッション処理部80を経由せず、
コネクション管理部31においてアドレス変換を施すこと
によって転送されるようになる。

【００３５】このように、コネクション管理部31のコネ
クション管理テーブルT31を用いることにより、SSLセッ
ションに対する処理段階に応じて、パケットの転送ルー
トを切り替えることになる。次に、図29〜34を参照し
て、図19に示したサーバ負荷分散装置LBがパケットを受
信したときの処理フローを受信パケットの種類に応じて
説明する。

【００３６】すなわち、(1)TCP Syn パケット受信時(図
26及び27のステップ(1)参照)、(2)SSL Client Hello パ
ケット受信時(同ステップ(3)参照)、(3)TCP Syn Ack パ
ケット受信時(同ステップ(5)参照)、(4)SSL Server Hel
lo パケット受信時(同ステップ(7)参照)、(5)SSL Serve
r Hello パケットをクライアントCに転送後、TCP FINパ
ケット受信前まで(同ステップ(9)参照)、及び(6)TCP FI
Nパケット受信時(図26及び27には図示せず)に分けて説
明する。

【００３７】(1) TCP Syn パケット受信時：図29及び30
参照 クライアントCからのTCP Synパケットを受信した場合、
まず、受信IF部10が物理的な通信信号を終端し、パケッ
トを認識する(図29のステップ13100)。続いて、パケッ
ト情報抽出部20がパケットに対する処理の決定に必要な
ヘッダ情報を抽出し(同ステップ13110)、コネクション
管理部31及びパケット処理判定部32に渡す。

【００３８】このような、図29のステップ13100及び131
10の処理は、以下の説明において受信I/F部10が受け付
ける全てのパケットに共通して行われる処理である。コ
ネクション管理部31は、クライアントCとサーバSとの間
で既に確立されているコネクションの情報、すなわち、
クライアントCのIPアドレス/TCP(/UDP)ポート番号とサ
ーバSのIPアドレスの対応関係をコネクション管理テー
ブルT31(図20参照)に保持し、管理している。また、コ
ネクション管理テーブルT31には、図20に示す如く、転
送方路及びアドレス変換内容が保持される。

【００３９】そこで、コネクション管理部31は、抽出情
報に対応するエントリの有無をコネクション管理テーブ
ルT31を検索することによって判定する(図29のステップ
13120)。TCP Synパケット受信時においては、まだ、ク
ライアントCとの間にコネクションが設定されておら
ず、パケットの中継がないので、コネクション管理テー
ブルT31のエントリは無い(図29のステップ13120でNo判
定)。

【００４０】一方、パケット処理判定部32は、SSL IDに
基づく処理対象なのか否か等を判断するルールを処理ル
ールテーブルT32(図21参照)に保持している。そこで、
パケット処理判定部32は、処理ルールテーブルT32を参
照し、受信したパケット(TCPSynパケット)がSSLセッシ
ョン IDに基づく処理対象のパケットであると判断する
(図29のステップ13200でYes判定)。

【００４１】従って、SSLメッセージ処理部80がクライ
アントCと通信できるようするために、コネクション管
理テーブルT31に2つの新しいエントリが登録される(図2
9のステップ13210)。すなわち、コネクション管理テー
ブルT31に、クライアントCからのパケットがSSLメッセ
ージ処理部80に転送され、SSLメッセージ処理部80から
のパケットがクライアントCに転送されるように、転送
方路を設定したエントリが登録される。

【００４２】次に、SSLメッセージ処理部80が、クライ
アントCとの間で、まず、TCPコネクションを確立する。
すなわち、図30に示す如く、SSLメッセージ処理部80で
は、受信パケットがクライアントCからのTCP Synパケッ
トであると判定し(図30のステップ14100でYes判定)、ク
ライアントC宛のTCP Syn Ackパケットを生成して受信I/
F部10に送出する(同ステップ14110)。

【００４３】この場合、SSLメッセージ処理部80にて生
成されたTCP Syn Ackパケットは、受信IF部10を経由し
てパケット情報抽出部20でヘッダ情報を抽出され(図29
のステップ13110)、抽出情報は、コネクション管理部31
及びパケット処理判定部32に渡される。

【００４４】この場合、コネクション管理テーブルT31
には、クライアントCへの転送に関するエントリがある
ので(図29のステップ13120でYes判定)、コネクション管
理テーブルT31の内容に基づき、パケット情報書換部40
がTCP Syn Ackパケットのアドレスやポート番号の書換
を行う(図29のステップ13140)。

【００４５】さらに、コネクション管理テーブルT31の
内容に従い(図29のステップ13150でNo判定(クライアン
トCへの転送のため))、TCP Syn Ackパケットがルーティ
ング処理部50に転送される。ルーティング処理部50は、
転送テーブルT50に基づき、TCP Syn Ackパケットの転送
先IFを決定し(図29のステップ13170)、その情報を基に
パケット送出・優先制御部60が振り分け処理を行い、送
信IF部70がTCP Syn Ackパケットをネットワークに送出
する(図29のステップ13180)。

【００４６】(2)SSL Client Hello パケット受信時：図
29〜31参照 クライアントCからのSSL Client Helloパケット受信時
においても、上記クライアントCからのTCP Synパケット
受信時の場合と同様に、図29のステップ13100及び13110
の処理が実行される。

【００４７】この場合、コネクション管理テーブルT31
には、クライアントCからSSLセッション処理部80へ転送
に関するエントリが登録されている(図29のステップ131
20でYes判定)。また、SSL Client HelloパケットはTCP
FINパケットではないので(同ステップ13130でNo判定)、
コネクション管理テーブルT31の内容に基づき、パケッ
ト情報書換部40がSSL Client Helloパケットのアドレス
やポート番号を書換を行う(図29のステップ13140)。

【００４８】この場合、SSL Client Helloパケットの転
送先がSSLセッション処理部80であるため(図29のステッ
プ13150でYes判定)、図30に示す如く、SSLセッション処
理部80は、SSL Client Helloメッセージであることを認
識する(図30のステップ14120でYes判定)。

【００４９】図31は、図30のステップS14120においてSS
L Client Helloメッセージであると判定された場合のSS
Lセッション処理部80による処理フローを示したもので
ある。この場合、新規セッションである場合と既存セッ
ションである場合で以下のように処理が異なる。

【００５０】a) 新規セッションの場合は、SSL Client
HelloメッセージにおいてSSL セッションID=0である(図
31のステップ14130でYes判定)。従って、負荷分散サー
バ選択部33が所定のルール/アルゴリズムに従って転送
先のサーバSを選択し(図31のステップ14140)、SSLメッ
セージ処理部80と選択したサーバSとの間で通信できる
ように、コネクション管理テーブルT31の該当するエン
トリに設定する(図30のステップ14150)。

【００５１】b)既存セッションの場合は、SSL Client H
elloメッセージ中のSSL セッションIDが零でない(図31
のステップ14130でNo判定)。すなわち、既に或るサーバ
(例えばサーバS)との間にSSLセッションが確立されてい
る。従って、SSL Client Helloメッセージ中のSSL セッ
ションIDをキーに、SSL・IDテーブルT80_1を検索し、接
続先サーバSの情報を取得する(図31のステップ14200)。

【００５２】この取得情報を基に、SSLメッセージ処理
部80と選択したサーバSとの間で通信できるように、コ
ネクション管理テーブルT31の該当するエントリに設定
する(図30のステップ14220)。図31のステップ14150又は
14220の処理後は、新規セッション及び既存セッション
のいずれの場合にも、受信したSSL Client Helloメッセ
ージを保存し、保存したSSL Client Helloメッセージの
保存場所ポインタを接続先サーバSのIPアドレスに対応
付けてセッション管理テーブルT80_2(図24(2)参照)に登
録する(図31のステップ14160及び14170)。

【００５３】さらに、SSLメッセージ処理部80は、選択
したサーバSに対するTCP Synパケットを作成し、受信I/
F部10に送出する(図30のステップ14180)。なお、サーバ
S宛のTCP Synパケットの処理は、上記(1)におけるクラ
イアントC宛のTCP Syn Ackパケットと同様に処理され
る。すなわち、図29のステップ13100→13110→13120→1
3130→13140→13150→13170→13180→13190の順に処理
される。

【００５４】(3)TCP Syn Ack パケット受信時:図29及び
30参照 サーバSからのTCP Syn Ackパケット受信時においても、
上記クライアントCからのTCP Synパケット受信時の場合
と同様に、図29のステップ13100及び13110の処理が実行
される。

【００５５】この場合、上記(2)のSSL Client Helloパ
ケット受信時の処理におけるステップ14150又は14220に
おいて、既にコネクション管理テーブルT31には、サー
バSからSSLセッション処理部80への転送に関するエント
リが登録されている(図29のステップ13120でYes判定)。

【００５６】また、TCP Syn AckパケットはTCP FINパケ
ットではないので(同ステップ13130でNo判定)、コネク
ション管理テーブルT31の内容に基づき、パケット情報
書換部40がSSL Client Helloパケットのアドレスやポー
ト番号の書換を行う(図29のステップ13140)。

【００５７】この場合、TCP Syn Ackパケットの転送先
がSSLセッション処理部80であるため(図29のステップ13
150でYes判定)、図30に示す如く、SSLセッション処理部
80は、TCP Syn Ackパケットであることを認識する(図30
のステップ14250でYes判定)。

【００５８】この後、SSLセッション処理部80は、受信
したTCP Syn Ackパケットの送信元IPアドレス、すなわ
ち、接続サーバのIPアドレスをキーにセッション管理テ
ーブルT80_2を参照してSSL Client Helloメッセージの
保存場所を獲得し、送信できるように準備する(図30の
ステップ15100)。

【００５９】さらに、SSL Client Helloメッセージの宛
先を接続先サーバのIPアドレスに書き換えて受信I/F部1
0に送出する(図15のステップ15110)。この後、SSL Clie
nt Helloメッセージの転送に関連したセッション管理テ
ーブルのエントリは削除される(図15のステップ1512
0)。

【００６０】なお、サーバS宛のSSL Client Helloは、
上記(1)におけるクライアントC宛のTCP Syn Ackパケッ
トと同様に処理される。すなわち、図29のステップ1310
0→13110→13120→13130→13140→13150→13170→13180
→13190の順に処理される。 (4)SSL Server Hello パケット受信時：図29,30,及び32
参照 サーバSからのSSL Server Helloパケット受信時におい
ても、上記クライアントCからのTCP Synパケット受信時
の場合と同様に、図29のステップ13100及び13110の処理
が実行される。

【００６１】この場合、上記(3)のTCP Syn Ackパケット
受信時の場合と同様な処理を実行した後、図30に示した
SSLセッション処理部80の処理において、SSLセッション
処理部80がSSL Server Helloパケットであることを認識
する(図30のステップ14260でYes判定)。

【００６２】その後、SSLセッション処理部80は、図32
に示す如く、SSL Server Hello メッセージ中のSSLセッ
ションIDをキーにSSL・IDテーブルT80_1を検索する。こ
こで、エントリーが無かった場合(図32のステップ16100
でNo判定)、すなわち、新規セッションに関するセッシ
ョンIDの払い出し時は、SSL Server Helloメッセージ中
のSSLセッションIDと接続先サーバのIPアドレス及び有
効時間であるライフタイムとを対応付けてSSL・IDテーブ
ルT80_1に登録する(図32のステップ16150)。

【００６３】このライフタイムは、接続先サーバとの間
で予め取り決めておき、サーバID毎にサーバ情報テーブ
ルT33_3(図23(3)参照)に登録されているものである。図
32において、ステップ16100でYes判定又はステップ1615
0の処理後は、コネクション管理テーブルT31内のクライ
アントC→SSLメッセージ処理部80及びサーバS→SSLメッ
セージ処理部80のエントリの設定を、各々、クライアン
トC→サーバS及びサーバS→クライアントCとなるように
変更し、クライアントCとサーバSとの間のパケット転送
がSSLメッセージ処理部80を経由しないようにする(図32
のステップ16120)。

【００６４】この設定の変更後、SSLメッセージ処理部8
0は、クライアントC宛のSSL ServerHelloメッセージを
受信I/F部10に送出する(図32のステップ16140)。なお、
クライアントC宛のSSL Server Helloメッセージは、上
記(1)におけるクライアントC宛のTCP Syn Ackパケット
と同様に処理される。すなわち、図29のステップ13100
→13110→13120→13130→13140→13150→13170→13180
→13190の順に処理される。

【００６５】以後、TCPコネクションが切断されるま
で、コネクション管理テーブルT31の内容に基づき、ク
ライアントCとサーバSとの間の通信路が保持される。 (5)SSL Server Hello パケットのクライアントCに転送
後からTCP FINパケット受信前まで：図29参照 SSL Server Hello パケットのクライアントCに転送後か
らTCP FINパケット受信前までの間にサーバ負荷分散装
置LBが受信するパケットは、上記(1)におけるクライア
ントC宛のTCP Syn Ackパケットと同様に処理される。す
なわち、図29のステップ13100→13110→13120→13130→
13140→13150→13170→13180→13190の順に処理され
る。

【００６６】(6)TCP FINパケット 受信時：図29及び33
参照 図25に示したように、TCPコネクション終了時には、TCP
FINパケットがクライアントCとサーバSとの間でハンド
シェイクされる。クライアントCとサーバSとの間にサー
バ負荷分散装置LBが存在する場合、サーバ負荷分散装置
LBは以下のような処理を行う。

【００６７】図29のステップ13100及び13110の処理の
後、ステップ13120でYes判定を受けたTCP FINパケット
は、ステップ13130でYes判定となる。従って、図33に示
すTCP FINパケットの処理フローが実行される。この場
合、コネクション管理テーブルT31には、クライアントC
→サーバS及びサーバS→クライアントCのコネクション
の組が設定されている。

【００６８】コネクション管理テーブルT31において、
受信したTCP FINパケットと逆方向コネクションに対応
するエントリを読み出し、すなわち、受信パケットの宛
先IPアドレスと送信元IPアドレスを、それぞれ、送信元
IPアドレスと宛先IPアドレスと見なして、コネクション
管理テーブルT31からエントリを検索し、そのエントリ
のセッション状態が、FIN受信状態で無ければ(図33のス
テップ17100でNo判定)、それはクライアントCとサーバS
との間で最初に送信されたFINパケットである。

【００６９】この場合、コネクション管理テーブルT31
における順方向コネクションのエントリのセッション状
態をFIN受信状態に設定する(図33のステップ17160)。設
定後は、ステップ13140→13150→13170→13180→13190
の順に処理される。一方、コネクション管理テーブルT3
1において、受信したTCP FINパケットと逆方向コネクシ
ョンに対応するエントリのセッション状態が、FIN受信
状態であった場合は(図33のステップ17100でYes判定)、
受信パケットをコネクション管理テーブルT31における
順方向コネクションのエントリ内容に基づき、パケット
情報書換部40でアドレスやポート番号を書き換える(図3
3のステップ17110)。

【００７０】この後、コネクション管理テーブルT31の
該セッションにおける順方向と逆方向コネクション及
び、SSLセッション処理部80とサーバS及びクライアント
Cとのコネクションに関するエントリを削除し(同ステッ
プ17120)、受信したTCP FINパケットをルーティング処
理部50に転送する。

【００７１】ルーティング処理部50へ転送されたパケッ
トは、ルーティング処理部50にて転送先IFを決定し(図3
3のステップ17130)、その情報を基にパケット送出・優
先制御部60にて振り分け処理を行い(図33のステップ171
40)、送信IF部70を介して、ネットワークへ送出され
る。

【００７２】上記(1)〜(6)のパケット受信を契機とした
処理の他に、SSLセッションIDについてのライフタイム
処理、すなわち、SSL・IDテーブルエントリの周期的な有
効性チェックならびに失効エントリの削除処理がある。
図34は、このようなライフタイム処理の流れを示したも
のである。

【００７３】同図において、周期トリガータイマーによ
って、ライフタイム処理が起動されると、まず、SSL・ID
テーブルT80_1の先頭エントリがアクセスされ(ステップ
18110)、ライフタイムから所定の値を引いた値がゼロよ
り大きい場合は(同18120でYes判定)、ライフタイムの更
新を行う(同18130)。逆に、ライフタイムから所定の値
を引いた値がゼロ以下である場合は(同18120でNo判
定)、このエントリを削除する(同18150)。

【００７４】このような処理を、最終エントリまでSSL・
IDテーブルT80_1の全てのエントリに対して行う。

【００７５】

【発明が解決しようとする課題】上記のようなサーバ負
荷分散装置LBを使用してサービスを提供するサービス提
供者の間では、サービス利用履歴や支払能力など各ユー
ザの顧客情報に基づき、異なる通信品質を提供する要望
が高まりつつある。例えば、電子モールでのショッピン
グなどの場合、同一サービスを頻繁に利用するユーザに
対しては通信品質を上げることによりサーバへの接続性
を良くすることなどが望まれる。

【００７６】この場合、例えば、図26及び27に示すよう
に、サーバSから優先度情報をサーバ負荷分散装置LBに
指定する必要があるが、従来のサーバ負荷分散装置では
このような優先度情報を扱う機能を有してはいない。ま
た、現状では、インターネットにおける通信品質差別化
は、L4（トランスポートレイヤ）までの情報をもとに半
固定的に行なう方式が一般的である。

【００７７】上記のサービス提供者の要望を満たすため
に、ユーザから受信したIPパケットの送信元IPアドレス
とサーバ自身のIPアドレスのセットでユーザを識別し、
差別化する方式が考えられる。しかし、ユーザが企業網
や私設網内に居る場合、セキュリティのために設けられ
たIPアドレス変換装置が介在している場合があり、ユー
ザを送信元IPアドレスで特定することはできない。すな
わち、別ユーザが同じ送信元IPアドレスを持っている場
合があり、上記の要望を満たせなかった。

【００７８】従って本発明は、同一クライアントによる
同一セッションの要求を同一サーバに転送するサーバ負
荷分散装置において、サービス提供者の希望に応じたク
ライアントに対する優先制御を可能にすることを目的と
する。

【００７９】

【課題を解決するための手段】上記の目的を達成するた
め、本発明に係るサーバ負荷分散装置は、複数のサーバ
からなるサーバ群に接続され、クライアントと該サーバ
との間のトラヒックを所定の方法で選択した振分先サー
バに振り分けるサーバ負荷分散装置において、該クライ
アントからの新規セッションの接続要求に応答して該振
分先サーバが該新規セッション毎に割り当てるセッショ
ン識別子に対し、優先度情報を対応付けて記憶すると共
に各優先度情報に対応した通信品質を記憶する優先度情
報記憶手段と、該クライアント又は該サーバからパケッ
トを受信したとき、該パケットを該優先度情報に基づく
通信品質で転送する転送手段と、を備えたことを特徴と
している(請求項1及び付記1)。

【００８０】すなわち、本発明に係るサーバ負荷分散装
置は、クライアントからの新規セッションの接続要求に
応答して、振分先サーバが従来と同様に新規セッション
毎に割り当てるセッション識別子に対して、優先度情報
記憶手段が、優先度情報を対応付けて記憶する。一方、
この優先度情報には、通信品質が対応して記憶されてい
る。

【００８１】クライアントとサーバとの間で送受信され
るパケットは、転送手段によって、上記優先度情報に基
づく転送品質で転送される。セッション識別子にはサー
ビス提供者が希望する優先度情報を対応付けることがで
き、セッション識別子はサーバがクライアントに対して
割り当てるものであることから、サービス提供者の希望
に応じた優先度による通信品質のパケット転送サービス
が可能となる。

【００８２】上記のサーバ負荷分散装置は、該クライア
ントから該セッション識別子を用いた既存セッションの
再接続要求があったとき、該セッション識別子に対応付
けられた該優先度情報及び該振分先サーバの負荷状態に
応じて、該既存セッションの再接続の可否を判断する処
理判定手段をさらに備えてもよい(請求項2及び付記2)。

【００８３】すなわち、クライアントから該セッション
識別子を用いた既存セッションの接続要求があったと
き、従来のように無条件に該セッション識別子によって
特定されるセッションで接続するのではなく、該セッシ
ョン識別子に対応付けられた該優先度情報及び該選択し
たサーバの負荷状態に応じて、処理判定手段が該既存セ
ッションの接続の可否を判断する。

【００８４】例えば、或るセッション識別子に対応付け
られた優先度情報が、このセッション識別子によって特
定されるセッションが低優先であることを示している場
合、接続先のサーバの負荷状態によっては、処理判定手
段で既存セッションの接続が不可であると判定されるた
め、この接続要求は無視される。

【００８５】これにより、既存セッションの接続要求が
特定のサーバに集中することにより、サーバの負荷が大
きくなり、高優先で既に接続しているセッションのサー
ビス品質が低下してしまうのを防ぐことが出来る。ま
た、サーバの負荷状態に応じて低優先のセッションの接
続要求を無視することにより、高優先のセッション用の
リソースを確保することができる。

【００８６】また、上記のサーバ負荷分散装置は、該セ
ッション識別子に対応する優先度情報へ重み付けした値
の総和を、該サーバ群に含まれる各サーバ毎に求めるセ
ッション収容状態算定手段と、新規のセッションの接続
要求を該クライアントから受信したとき、該総和に基づ
いて該振分先サーバを選択する負荷分散サーバ選択手段
と、をさらに備えてもよい(請求項3及び付記3)。

【００８７】すなわち、セッション収容状態算定手段
は、セッション識別子に対応する優先度情報へ重み付け
した値の総和を各サーバ毎に求める。また、負荷分散サ
ーバ選択手段は、新規のセッションの接続要求をクライ
アントから受信したとき、該総和を加味して振分先サー
バを選択する。

【００８８】また、上記のサーバ負荷分散装置は、該振
分先サーバが指定する同一クライアントによる該振分先
サーバへのアクセス頻度及びアクセス間隔に応じた指標
を、クライアントに対応付けておき、該クライアントか
らのコネクション切断要求後も、該指標に従って該振分
先サーバとの間のコネクションを保留してもよい(請求
項4及び付記4)。

【００８９】すなわち、同一クライアントによる該振分
先サーバへのアクセス頻度及びアクセス間隔に応じた指
標の指定を該振分先サーバから受けておき、この指標を
クライアントに対応付けておくことにより、クライアン
トからのコネクション切断要求後も、該指標に従って該
振分先サーバとの間のコネクションを保留する。

【００９０】これにより、短い間に頻繁にコネクション
の接続及び切断を繰り返すクライアントについては、上
記の指標を用いることにより、クライアントからのコネ
クション切断要求後も振分先サーバとの間のコネクショ
ンを保留し、再度コネクションの接続要求があった場合
に接続処理を容易に行える。

【００９１】また、上記のサーバ負荷分散装置は、該セ
ッション識別子と該優先度情報との対応関係が予め定め
られていてもよい(付記5)。すなわち、セッション識別
子と優先度情報との間には、例えば、セッション識別情
報の上位又は下位の固定ビットと優先度情報とを対応付
けることにより、予め対応関係を与えることが出来る。

【００９２】これにより、サーバが割り当てるセッショ
ン識別子自体から対応する優先度情報を抽出することが
出来る。また、上記のサーバ負荷分散装置は、該振分先
サーバが該セッション識別子を通知するための制御パケ
ットに、該優先度情報が含まれていてもよい(付記6)。

【００９３】すなわち、振分先サーバが、該セッション
識別子を通知する制御パケットに該優先度情報を含めて
通知する。また、上記のサーバ負荷分散装置は、該振分
先サーバが該セッション識別子を新規に割り当てる度
に、該セッション識別子に対応する該優先度情報を、予
め該振分先サーバとの間で確立した制御用コネクション
を用いて該振分先サーバに問い合わせてもよい(付記
7)。

【００９４】すなわち、セッション識別子と優先度情報
との間に予め対応関係が定められていない場合は、振分
先サーバとの間で予め制御用コネクションを確立してお
き、この制御用コネクションを用いて、セッション識別
子が新規に割り当てられる度に対応する優先度情報を該
振分先サーバに問い合わせる。

【００９５】上記のセッション識別子は、SSLプロトコ
ルに基づくSSLセッションIDであってもよく(請求項5及
び付記8)、又はhttpプロトコルに基づくcookieであって
もよい(付記9)。

【００９６】

【発明の実施の形態】図1は本発明に係るサーバ負荷分
散装置の実施例を示したものであり、この実施例では、
図19に示した従来のサーバ負荷分散装置LBと同様に、受
信インタフェース(I/F)部10、パケット情報抽出部20、
コネクション管理部31、パケット処理判定部32、負荷分
散サーバ選択部33、パケット情報書換部40、ルーティン
グ処理部50、パケット送出・優先制御部60、送信インタ
フェース(I/F)部70、及びSSLセッション処理部80を含む
と共に、新たに優先度情報記憶部90が付加されている。

【００９７】なお、図1において、符号110の点線で囲ま
れたコネクション管理部31、パケット処理判定部32、負
荷分散サーバ選択部33、SSLセッション処理部80、及び
優先度情報記憶部90は、従来のサーバ負荷分散装置LBと
は異なる処理を行なうものである。

【００９８】また、本実施例においても、サーバ負荷分
散装置LBは、図20〜24に示した従来例と同様に、コネク
ション管理テーブルT31、処理ルールテーブルT32、転送
テーブルT50、サーバ選択リストテーブルT33_1、サーバ
ファームメンバリストテーブルT33_2、サーバ情報テー
ブルT33_3、SSL・IDテーブルT80_1、及びセッション管理
テーブルT80_2を使用する。

【００９９】この内、本実施例で使用するコネクション
管理テーブルT31、サーバ情報テーブルT33_3、及びSSL・
IDテーブルT80は、図2〜4に示す如く従来例とは異な
る。さらに、本実施例では、図5に示す優先度情報記憶
部90が管理する優先度対応テーブルT90が追加されてい
る。

【０１００】すなわち、図2に示したコネクション管理
テーブルT31は、図20に示した従来のコネクション管理
テーブルT31の項目に、保留タイマの有効/無効を示す項
目及び保留タイマ値の項目を追加したものである。ま
た、本実施例においては、図2に示したコネクション管
理テーブルT31の変換内容には、従来例と同様なアドレ
スの変換内容だけでなく、振分先サーバによって指定さ
れる優先度に対応した通信品質を表わすIP・ToSフィール
ド値が含まれる。

【０１０１】また、図3に示したサーバ情報テーブルT33
_3は、図23(3)に示した従来のサーバ情報テーブルT33_3
の項目に、SSLセッション収容状態指標値の項目及びリ
ミット値の項目を追加したものである。さらに、図4に
示したSSL・IDテーブルT80は、図24(1)に示した従来のSS
L・IDテーブルT80の項目に、サーバIDの項目及び優先度
コードの項目を追加したものである。

【０１０２】この優先度コードは、優先度情報を表すコ
ードであり、例えば、優先度の高い順に1〜4の優先度コ
ードを使用することができる。この優先度コードは、図
5に示す優先度対応テーブルにおいてIP・TOSフィールド
値が対応付けられている。

【０１０３】上記のようなコネクション管理テーブルT3
1、サーバ情報テーブルT33_3、SSL・IDテーブルT80、及
び優先度対応テーブルT90を用いていることを除き、本
実施例においても、上述の従来例について図29〜34を用
いて説明したパケット受信時の処理と同様な処理が行な
われる。

【０１０４】以下、本実施例において、従来と異なるパ
ケット処理が行なわれる場合のみについて図6〜16を参
照して説明する。なお、図29〜34に示した従来例と同様
なフローを示した図の場合、二重線で囲まれたステップ
は本発明特有のステップを示すものである。

【０１０５】(1)優先度情報に基づくパケット転送 (1-1)SSL・IDと優先度コードの対応付けの処理フロー
(1)：図6参照 優先度情報に基づくパケット転送を行うためには、サー
バから新規のSSLセッションIDが割り振られたときに、S
SL・IDテーブルT80において、SSLセッションIDに優先度
コードを対応付ける必要がある。

【０１０６】図6は、このためのSSLセッションIDと優先
度コードの対応付けの処理フロー(1)を示したものであ
り、図32に示した従来例におけるSSL Server Helloメッ
セージの処理フローに、ステップ16110、16115、及び16
130が追加されたものである。

【０１０７】すなわち、受信したSSL Server Helloメッ
セージ内のSSLセッションIDのエントリがSSL・IDテーブ
ルT80にない場合(ステップ16100でNo判定)、従来と同様
に、SSL Server Hello メッセージ中のSSLセッションID
と接続先サーバのIPアドレス及びライフタイムとを対応
付けてSSL・IDテーブルT80_1に登録する(ステップ1615
0)。

【０１０８】この後、受信したSSL Server Hello メッ
セージからSSLセッションIDに対する優先度情報を抽出
し(ステップ16110)、SSLセッションIDと優先度情報との
対応関係をSSL・IDテーブルT80(図4参照)に保持する(ス
テップ16115)。ステップ16110において、SSL Server He
llo メッセージからSSLセッションIDに対する優先度情
報を抽出する方法としては、予めSSLセッションIDの割
当ルールを定めておき、SSLセッションIDの値そのもの
が優先度情報を示すものである場合は、SSLセッションI
Dから優先度を求めればよい。

【０１０９】また、SSLのプロトコルを拡張することに
よりSSL Server Hello メッセージに優先度情報のフィ
ールドを設け、このフィールドから優先度情報を抽出す
るようにしてもよい。同図のステップ16100でYes判定又
はステップ16115の処理後は、従来と同様に、コネクシ
ョン管理テーブルT31内のクライアント→SSLメッセージ
処理部及びサーバ→SSLメッセージ処理部のエントリの
設定を、各々、クライアント→サーバ及びサーバ→クラ
イアントとなるように変更し、クライアントとサーバと
の間のパケット転送がSSLメッセージ処理部80を経由し
ないようにする(ステップ16120)。

【０１１０】その後、本実施例では、SSL・IDテーブルT8
0から該当するエントリの優先度を取得し、優先度対応
テーブル90(図5参照)に基づくIP・TOSフィールド値の書
き換えをコネクション管理テーブルT31の該当するエン
トリの変換内容に追加し(ステップ16130)、従来と同様
に、クライアント宛のSSL Server Helloメッセージを受
信I/F部10に送出する(ステップ16140)。

【０１１１】(1-2)優先度情報に基づくパケット転送：
図7参照 次に、図7を参照して、クライアントとサーバとの間で
送受信されるパケットについて優先度情報に基づく通信
品質で転送される様子を説明する。この場合、上記(1-
1)の処理によって、SSL・IDテーブルT80の該当するSSLセ
ッションIDに優先度コードが対応付けられ、この優先度
コードに対し、優先度対応テーブルT90において対応付
けられたIP・TOSフィールド値が、コネクション管理テー
ブルT31の該当するエントリの変換内容に設定済みであ
る。

【０１１２】図7は、ステップ13150でYes判定を受けた
ときの処理として、ステップ13160に示す優先度情報取
得処理が行なわれる場合を除いて、図29に示した処理フ
ローと同様である。従って、クライアント又はサーバか
らサーバ負荷分散装置LBが受信するパケットは、図29の
場合と同様に、ステップ13100→13110→13120→13130→
13140→13150→13170→13180→13190の順に処理され
る。

【０１１３】但し、ステップ13140のパケットの書換に
おいては、コネクション管理テーブルT31の該当するエ
ントリの変換内容に基づき、従来と同様なアドレスやポ
ートの書換だけでなく、IP・TOSフィールド値の書換も行
う。従って、ステップ13180でパケット転送が行なわれ
る際に、IP・TOSフィールド値によって特定される通信品
質が保証されることになる。

【０１１４】上記(1-1)及び(1-2)で説明したように、サ
ーバ、すなわち、サービス提供者がクライアントに割り
振るSSLセッションIDに対応した優先度情報を設け、こ
れを利用することにより、サービス提供者の意図に基づ
いたパケット転送サービスの差別化が実現できる。

【０１１５】なお、SSLセッションIDと優先度コードの
対応付けの処理フローについては、上記(1-1)の代わり
に、以下に説明する(1-3)の処理フローを用いてもよ
い。 (1-3)SSL・IDと優先度コードの対応付けの処理フロー
(2)：図7〜9参照 上記(1-1)では、SSLセッションIDと優先度コードを対応
付けるために、受信したSSL Server Helloメッセージか
ら優先度情報を抽出したが、SSL Server Helloメッセー
ジに優先度情報を含めずに、別途優先度を問い合わせる
パケットを使用することも可能である。

【０１１６】この場合、図6ではなく図8に示すSSLセッ
ションIDと優先度コードの対応付けの処理フロー(2)が
実行される。図8は、図6のステップ16110及び16115の代
わりにステップ16105を設けたものである。ステップ161
05では、受信したSSL Server HelloメッセージのSSLセ
ッションIDに対する優先度を問い合わせるためのメッセ
ージを生成し、予めサーバとSSLセッション処理部80と
の間で固定的に確立したコネクションを用いてこの問い
合わせメッセージを送出する。

【０１１７】この場合、サーバから問い合わせメッセー
ジに対する応答として優先度情報を通知するメッセージ
(以降、応答メッセージと称する。)が送信されることに
なる。従って、応答メッセージを受信した場合に対応す
るため、図7においてステップ13160が実行される。

【０１１８】ステップ13160の詳細は、図9に示す通りで
あり、応答メッセージを受信した場合には、ステップ22
100及び22110でYes判定となるため、受信した応答メッ
セージ中のSSLセッションIDと優先度の対応関係をSSL・I
DテーブルT80に保持した後、パケットを廃棄して処理を
終了する(ステップ22120〜22140)。

【０１１９】従来のサーバ負荷分散装置の中には、サー
バのCPU負荷率などのサーバ状態情報を取得するため、
予めサーバ間に制御用コネクションを設けているものが
ある。上記(1-3)で説明した処理は、このような制御用
コネクションをセッション優先度の獲得にも利用するも
のである。

【０１２０】(2)コネクション制限処理：図10及び11参
照 本実施例では、既存セッションの再接続についてセッシ
ョンの優先度に応じてコネクションを制限することが可
能である。この場合、図10に示す如く、SSL Client Hel
loメッセージの処理が、図31に示した従来例の場合と異
なる。既存セッションの場合は、図10のステップ14130
においてNo判定となる。この場合の処理について、図10
は図31にステップ14205及び14210を追加したものであ
る。

【０１２１】なお、ステップ14210の具体的な内容は、
図11に示されている。同図のステップ19100では、サー
バ情報テーブルT33_3から該当するサーバのサーバ情報
を取得する。この場合のサーバ情報は、従来のサーバ負
荷分散装置LBにおいてもサーバを選択する際に参照して
いる情報であり、例えば、サーバのコネクション収容
数、転送データ量、反応時間、CPU負荷率等の情報であ
る。

【０１２２】ステップ19100で取得したサーバ情報値
は、ステップ19110で所定値と比較され、サーバ情報値
＞所定値である場合は、サーバの負荷が大きくなってい
ることを意味する。そこで、コネクションを拒否すべき
か否かを判断するため、ステップ19115では、図10にお
けるステップ14205で取得した該セッションIDに関する
優先度と所定の優先度とを比較する。

【０１２３】該セッションIDに関する優先度が所定の優
先度よりも低い場合(ステップ19115でYes判定)、受信し
たClient Helloメッセージは廃棄され、処理が終了する
(ステップ19120及び19130)。該セッションIDに関する優
先度が所定の優先度よりも高い場合(ステップ19115でNo
判定)は、高優先のセッションであるため、受信したCli
ent Helloメッセージを破棄することなく、図10のステ
ップ14220に処理を進める。

【０１２４】SSLでは、SSLセッションIDを用いて最初に
サービスしたサーバに必ず接続することにより、サービ
スの一貫性保持を実現している。従って、本実施例で
は、既存セッションを用いたコネクションが、或るサー
バに一過的に集中し、サーバ輻輳状態になった場合は、
サービス提供者が優先度を低く設定したセッションのコ
ネクションは接続しない。

【０１２５】これにより、高優先度セッションのコネク
ション接続用のリソースを確保できる。また、サービス
を受けているセッションのサービス品質を保証すること
ができる。 (3)新規セッション確立時における転送先サーバ選択フ
ロー：図10,12,13参照 本実施例においては、図10のステップ14130でYes判定に
なった場合、すなわち、新規セッションの場合の転送先
サーバ選択処理(ステップ14140)を、図12に示すフロー
で処理する。

【０１２６】図12においては、まず、サーバ選択リスト
テーブルT33_1(図23(1)参照)からパケットの宛先アドレ
スと一致する代表IPアドレスに対応付けられた筆頭候補
サーバを取得する(ステップ20100)。次に、サーバ情報
テーブルT33_3の該当するエントリから、サーバIDに対
応付けられたSSLセッション割当状態指標値及びリミッ
ト値を取得し(ステップ20110)、両者を比較する(ステッ
プ20120)。

【０１２７】状態指標値＞リミット値であると判定され
る間は(ステップ20120でYes判定)は、サーバファームメ
ンバリストテーブルT33_2から、次候補サーバのサーバI
Dを取得し(ステップ20130)、ステップ20110に戻る。状
態指標値＞リミット値でないと判定された場合(ステッ
プ20120でNo判定)、サーバ情報テーブルT33_3の該当す
るエントリについて、サーバIDに対応した状態指標値を
該セッションの優先度に対応した指標値を加算した値に
更新し(ステップ20140)、このサーバIDが示すサーバを
転送先サーバとして選択する(ステップ20150)。

【０１２８】なお、サーバ情報テーブルT33_3のSSLセッ
ション収容状態指標値は、SSL・IDテーブルT80に登録さ
れているエントリの状態を反映したものにする必要があ
るため、図13に示す如く、本実施例におけるSSLセッシ
ョンIDのライフタイム管理は、図34に示した従来の場合
の処理フローにステップ18140及び18145を追加したもの
となる。

【０１２９】すなわち、SSL・IDテーブルT80のエントリ
が削除される場合、削除されるエントリに登録されたサ
ーバIDをキーとしてサーバ情報テーブルT33_3にアクセ
スし(ステップ18140)、該当するエントリのSSLセッショ
ン収容状態指標値から、SSL・IDテーブルT80を参照して
算出される該当セッションの優先度に対応した指標値を
減算する(ステップ18145)。

【０１３０】サーバへの接続コネクション数に基づき、
振り分け先サーバを選択するアルゴリズムは従来からあ
るが、コネクション数で制限した場合、収容コネクショ
ンが全て低いセッション優先度のコネクションから成る
場合、過剰サービスである。従って、サーバの処理能力
が無駄になり、その分、同じサーバファームに属する他
のサーバに高優先度セッションが集中することになり、
望ましくない。

【０１３１】これに対し、本実施例では、コネクション
にセッション優先度に応じた重み付けを行なうことによ
り、サーバ処理リソースを有効活用することができる。
また、本実施例によれば、高性能、信頼性の高いサーバ
に高優先度セッションを固めて収容することもできるた
め、クライアントへのサービス保証ならび、サービス提
供者側のサーバ保守（サーバの保守にも優先度が付けら
れ、効率的である。）の観点からも効力を持つ。

【０１３２】(4)TCP FINパケットの処理フロー：図14及
び15参照 本実施例では、TCP FINパケットを受信してもコネクシ
ョン管理部31において保留タイマが有効であり且つ保留
タイマ値がゼロより大きい場合には、サーバとSSLセッ
ション処理部80との間のコネクションを残すことができ
る。

【０１３３】図14は、このような処理を反映したもので
ある。同図のステップ24100、24110、24150〜24170、及
び24180は、それぞれ、図33に示した従来の処理におけ
るステップ17100、17110、17130〜17150、及び17160に
相当している。従って、図14におけるステップ24120〜2
4140が本実施例特有の処理であり、従来の図33における
ステップ17120とは異なっている。

【０１３４】図14においては、コネクション管理部31の
該当するエントリの保留タイマが有効且つ保留タイマ＞
0であると判定された場合（ステップ24120でYes判定）
には、コネクション管理部31の該当するエントリの内、
SSLセッション処理部→クライアント及びクライアント
→サーバのエントリを削除し、サーバ→クライアントの
エントリについては、サーバ→SSLセッション処理部と
なるようにエントリを変更する。

【０１３５】ステップ24120でNo判定の場合には、従来
の図33におけるステップ17120と同様に、図14のステッ
プ24140において、コネクション管理部31において該当
するセッションに関連した4つのエントリが全て削除さ
れる。なお、図14でTCP FINパケットを受信したにもか
かわらず、サーバとSSLセッション処理部とのコネクシ
ョンを保留した場合、図15に示すようなコネクション管
理部のエントリ管理フローを実施する必要がある。

【０１３６】すなわち、周期トリガータイマーによって
処理を起動し(ステップ25100)、コネクション管理部31
の先頭エントリにアクセスし、保留タイマが有効且つ保
留タイマ−所定値がゼロ以上であるかを判定する(ステ
ップ25120)。ステップ25120の判定がYesの場合は、保留
タイマ値を更新し(ステップ25130)、ステップ25120の判
定がNoの場合は該当するエントリを削除する(ステップ2
5140)。

【０１３７】上記の処理を、ステップ25150で最終エン
トリであると判断されるまで、コネクション管理部31の
全てのエントリについて実行する。図16は、本実施例に
おけるコネクション管理部登録内容の変化の流れを示し
たものである。同図(1)〜(3)は、それぞれ図28(1)〜(3)
に示した従来例と同様である。図16(4)には、本実施例
においてTCP FINパケットの受信後、保留タイマがタイ
ムアウトするまでのコネクションが示されている。

【０１３８】すなわち、図14に示した処理によって、図
16(3)のコネクション-2及び-1'が削除され、サーバ
→クライアントのコネクション-1'が、図16(4)に示す
如く、サーバ→SSLセッション処理部のコネクション-
1''に変更されている。このように、サーバとSSLセッシ
ョン処理部との間のコネクションを保留し、再利用する
ため、既存セッションによるコネクション要求があった
とき、サーバとのコネクション接続処理を省略すること
ができ、クライアントに対して素早い接続性を提供する
ことができる。

【０１３９】上記の図6〜16を参照した本実施例の説明
においては、SSLプロトコルを用いる場合について説明
したが、SSLセッションIDと同様、サーバが払い出し、
コネクションが張り代わってもサービスの連続性を保証
するhttpプロトコルのcookieを用い、図1におけるSSLセ
ッション処理部80に相当するcookie処理部を設ければ、
SSLプロトコルの場合と同じ流れで処理することが可能
である。 （付記１）複数のサーバからなるサーバ群に接続され、
クライアントと該サーバとの間のトラヒックを所定の方
法で選択した振分先サーバに振り分けるサーバ負荷分散
装置において、該クライアントからの新規セッションの
接続要求に応答して該振分先サーバが該新規セッション
毎に割り当てるセッション識別子に対し、優先度情報を
対応付けて記憶すると共に各優先度情報に対応した通信
品質を記憶する優先度情報記憶手段と、該クライアント
又は該サーバからパケットを受信したとき、該パケット
を該優先度情報に基づく通信品質で転送する転送手段
と、を備えたことを特徴とするサーバ負荷分散装置。 （付記２）付記１において、該クライアントから該セッ
ション識別子を用いた既存セッションの再接続要求があ
ったとき、該セッション識別子に対応付けられた該優先
度情報及び該振分先サーバの負荷状態に応じて、該既存
セッションの再接続の可否を判断する処理判定手段をさ
らに備えたことを特徴とするサーバ負荷分散装置。 （付記３）付記１において、該セッション識別子に対応
する優先度情報へ重み付けした値の総和を、該サーバ群
に含まれる各サーバ毎に求めるセッション収容状態算定
手段と、新規のセッションの接続要求を該クライアント
から受信したとき、該総和に基づいて振分先サーバを選
択する負荷分散サーバ選択手段と、をさらに備えたこと
を特徴とするサーバ負荷分散装置。 （付記４）付記１において、該振分先サーバが指定する
同一クライアントによる該振分先サーバへのアクセス頻
度及びアクセス間隔に応じた指標を、該クライアントに
対応付けておき、該クライアントからのコネクション切
断要求後も、該指標に従って該振分先サーバとの間のコ
ネクションを保留することを特徴としたサーバ負荷分散
装置。 （付記５）付記１において、該セッション識別子と該優
先度情報との対応関係が予め定められていることを特徴
とするサーバ負荷分散装置。 （付記６）付記１において、該振分先サーバが該セッシ
ョン識別子を通知するための制御パケットに、該優先度
情報が含まれていることを特徴としたサーバ負荷分散装
置。 （付記７）付記１において、該振分先サーバが該セッシ
ョン識別子を新規に割り当てる度に、該セッション識別
子に対応する該優先度情報を、予め該振分先サーバとの
間で確立した制御用コネクションを用いて該振分先サー
バに問い合わせることを特徴とするサーバ負荷分散装
置。 （付記８）付記１において、該セッション識別子が、SS
Lプロトコルに基づくSSLセッションIDであることを特徴
としたサーバ負荷分散装置。 （付記９）付記１において、該セッション識別子が、ht
tpプロトコルに基づくcookieであることを特徴としたサ
ーバ負荷分散装置。

【０１４０】

【発明の効果】以上説明したように、本発明に係るサー
バ負荷分散装置は、優先度情報記憶手段が、クライアン
トからの新規セッションの接続要求に応答して振分先サ
ーバが該新規セッション毎に割り当てるセッション識別
子に対し、優先度情報を対応付けて記憶すると共に各優
先度情報に対応した通信品質を記憶し、転送手段が、ク
ライアント又は該サーバからパケットを受信したとき、
該パケットを該優先度情報に基づく通信品質で転送する
ように構成したので、サービス提供者の希望に応じてク
ライアントに対する優先制御を行うことが可能となる。

【図面の簡単な説明】

【図１】本発明に係るサーバ負荷分散装置の実施例を示
したブロック図である。

【図２】本発明におけるコネクション管理部31のコネク
ション管理テーブルの構成例を示した図である。

【図３】本発明における負荷分散サーバ選択部33のサー
バ情報テーブルの構成例を示した図である。

【図４】本発明におけるSSLセッション処理部80のSSL・I
Dテーブルの構成例を示した図である。

【図５】本発明における優先度保持情報記憶部90の優先
度対応テーブルの構成例を示した図である。

【図６】本発明におけるSSL Server Helloメッセージの
処理フロー(1)を説明するためのフローチャート図であ
る。

【図７】本発明におけるパケット処理フローを説明する
ためのフローチャート図である。

【図8】本発明におけるSSL Server Helloメッセージの
処理フロー(2)を説明するためのフローチャート図であ
る。

【図9】図7における優先度情報取得処理の詳細を示した
フローチャート図である。

【図10】本発明におけるSSL Client Helloメッセージの
処理フローを説明するためのフローチャート図である。

【図11】図10におけるコネクション制限処理の内容を説
明するためのフローチャート図である。

【図12】図10におけるステップ14140の処理フローの詳
細を示したフローチャート図である。

【図13】本発明におけるSSLセッションIDのライフタイ
ム管理を説明するためのフローチャート図である。

【図14】本発明におけるTCP FINパケットの処理フロー
を説明するためのフローチャート図である。

【図15】本発明におけるコネクション管理テーブルのエ
ントリ管理フローを説明するためのフローチャート図で
ある。

【図16】本発明におけるコネクション管理テーブル登録
内容変化の流れを説明するためのブロック図である。

【図17】一般的なサーバ負荷分散処理を説明するための
ブロック図である。

【図18】一般的なサーバ負荷分散装置によるアドレス変
換を説明するためのブロック図である。

【図19】従来のサーバ負荷分散装置の基本概念を示した
ブロック図である。

【図20】従来のコネクション管理部31のコネクション管
理テーブルの構成例を示した図である。

【図21】従来のパケット処理判定部32の処理ルールテー
ブル構成例を示した図である。

【図22】従来のルーティング処理部50の転送テーブル構
成例を示した図である。

【図23】従来の負荷分散サーバ選択部33のテーブル構成
例を示した図である。

【図24】従来のSSLセッション処理部80のテーブル構成
例を示した図である。

【図25】基本的なSSLセッションの概要を説明するため
のシーケンス図である。

【図26】一般的なサーバ負荷分散装置が介在する場合の
SSL新規セッション時におけるパケットの流れを説明す
るためのシーケンス図である。

【図27】一般的なサーバ負荷分散装置が介在する場合の
SSL既存セッション時におけるパケットの流れを説明す
るためのシーケンス図である。

【図28】従来のコネクション管理テーブル登録内容変化
の流れを説明するためのブロック図である。

【図29】従来のサーバ負荷分散装置におけるパケット処
理フローを示したフローチャート図である。

【図30】従来のSSLセッション処理部80による処理フロ
ーを示したフローチャート図である。

【図31】従来のSSL Client Helloメッセージの処理フロ
ーを示したフローチャート図である。

【図32】従来のSSL Server Helloメッセージの処理フロ
ーを示したフローチャート図である。

【図33】従来のTCP FINパケット処理フローを示したフ
ローチャート図である。

【図34】従来のSSLセッションIDのライフタイム管理を
示したフローチャート図である。

【符号の説明】

A1〜An, B1〜Bn, S サーバ C クライアント LB サーバ負荷分散装置 NW インターネット SG_A, SG_B サーバ群 10 受信インタフェース(I/F)部 20 パケット情報抽出部 31 コネクション管理部 32 パケット処理判定部 33 負荷分散サーバ選択部 40 パケット情報書換部 50 ルーティング処理部 60 パケット送出・優先制御部 70 送信インタフェース(I/F)部 80 SSLセッション処理部 90 優先度保持情報記憶部 図中、同一符号は同一又は相当部分を示す。

Claims (5)

【特許請求の範囲】
1. 【請求項1】複数のサーバからなるサーバ群に接続さ
   れ、クライアントと該サーバとの間のトラヒックを所定
   の方法で選択した振分先サーバに振り分けるサーバ負荷
   分散装置において、 該クライアントからの新規セッションの接続要求に応答
   して該振分先サーバが該新規セッション毎に割り当てる
   セッション識別子に対し、優先度情報を対応付けて記憶
   すると共に各優先度情報に対応した通信品質を記憶する
   優先度情報記憶手段と、 該クライアント又は該サーバからパケットを受信したと
   き、該パケットを該優先度情報に基づく通信品質で転送
   する転送手段と、 を備えたことを特徴とするサーバ負荷分散装置。
2. 【請求項2】請求項1において、 該クライアントから該セッション識別子を用いた既存セ
   ッションの再接続要求があったとき、該セッション識別
   子に対応付けられた該優先度情報及び該振分先サーバの
   負荷状態に応じて、該既存セッションの再接続の可否を
   判断する処理判定手段をさらに備えたことを特徴とする
   サーバ負荷分散装置。
3. 【請求項3】請求項1において、 該セッション識別子に対応する優先度情報へ重み付けし
   た値の総和を、該サーバ群に含まれる各サーバ毎に求め
   るセッション収容状態算定手段と、新規のセッションの
   接続要求を該クライアントから受信したとき、該総和に
   基づいて該振分先サーバを選択する負荷分散サーバ選択
   手段と、をさらに備えたことを特徴とするサーバ負荷分
   散装置。
4. 【請求項4】請求項1において、 該振分先サーバが指定する同一クライアントによる該振
   分先サーバへのアクセス頻度及びアクセス間隔に応じた
   指標を、該クライアントに対応付けておき、該クライア
   ントからのコネクション切断要求後も、該指標に従って
   該振分先サーバとの間のコネクションを保留することを
   特徴としたサーバ負荷分散装置。
5. 【請求項5】請求項1において、 該セッション識別子が、SSLプロトコルに基づくSSLセッ
   ションIDであることを特徴としたサーバ負荷分散装置。