HTTP proxy サーバにおける 動的コネクション管理方式 大阪大学 大学院基礎工学研究科 岡本 卓也 tak-okmt@ics.es.osaka-u.ac.jp 2001年11月22日 TM 研究会

背景 proxy サーバにおけるデータ転送処理の 高速・高機能化の検討が必要 エンドホストにおけるデータ転送処理の高速化 SSBT 方式の提案 Webサーバにおけるサーバ資源の管理 データ転送処理速度の向上 応答時間の削減 proxy サーバを介した HTTP アクセス 全体の35％程度 proxy サーバの処理能力の不足によるスループットの低下 ネットワークの高速化のための研究として、TCPの輻輳制御や、WDMなどの転送技術にかんする 研究は広く行われているのに対し、エンドホストの高速化に関する研究はあまり行われていない。 しかし、ネットワークが高速になるにつれ、エンドホストがボトルネックとなる状況が発生しつつある。 これまで、我々の研究グループでは、Webサーバのおけるデータ転送の高速高機能化を実現する方法として、 SSBT方式を提案し、実際のWebサーバに実装することによって、その有効性を確認してきた。 しかし、現在のインターネットにおいては、Proxyサーバを介したHTTPリクエストも多く存在する。 また、ISPなどが設置したProxyサーバでは、多数のクライアントからのリクエストを 処理しなければならない。そのため、ネットワークに輻輳がなく、かつ、Webサーバの性能に余裕がある 状況においても、Proxyサーバの処理不足によって、スループットの低下が考えられる。 そこで、Proxyサーバのおけるデータ転送処理の高速高機能化の検討が必要であると考えられる。 proxy サーバにおけるデータ転送処理の 高速・高機能化の検討が必要 2001年11月22日 TM 研究会

エンドホストにおける問題点 特に多くの TCP コネクションを収容する proxy サーバでは これらのサーバ資源の効率的な割り当てが必要 ソケットバッファの割り当て 各 TCP コネクションの帯域，遅延等は異なる 固定サイズのソケットバッファの割り当て 各 TCP コネクションの帯域の考慮 コネクション管理 資源の割り当て mbuf ，ファイルディスクリプタ，メモリ空間 資源の不足 新規にTCP コネクションの確立の拒否 クライアントからのリクエスト要求を多くうけつけるProxyサーバでは， データ転送処理，クライアント間のコネクションの確立処理，さらにはWebサーバ間のコネクションの確立処理 を行わなければならない． そこで，まず，Proxyサーバでの様々な処理に使用されるサーバ資源についての説明を行う． まず，データ転送処理に使用される資源としては，ソケットバッファが挙げられる． これは，アプリケーションがTCPを使用してデータ転送を行う時に，転送データを一時的に格納する カーネル領域のメモリ空間である． 次に，コネクションの確立の際に各TCPコネクションに割り当てられる資源としては，以下のものが挙げられる． まず，mbuf, mbuf cluster．これらは，ソケットバッファにある転送データをネットワークカードに 書き込む際に使用されるメモリ空間である． 次に，ファイルディスクリプタがある．これは，それぞれのコネクションをカーネルおよびユーザアプリケーションが 識別できるようにするための識別子である． また，ネットワークの状態等をを保持しておくためのコントロールブロックを作成するメモリ空間に関しても サーバ資源となる． これら3つの資源のうち１つでも不足するとProxyサーバで新規コネクションを確立することができなくなる． これらの資源の効率的な割り当てを行うことによって，Proxyサーバにおけるデータ転送処理の高速化が行えると考えられる． 次のスライドからProxyサーバの高速高機能化を実現する提案方式についての説明を行う． 特に多くの TCP コネクションを収容する proxy サーバでは これらのサーバ資源の効率的な割り当てが必要 2001年11月22日 TM 研究会

提案方式 1． ソケットバッファ管理方式 （E2–ATBT 方式） E–ATBT 方式を改良したもの ・ 受信側ソケットバッファの考慮 ・ TCP コネクション間の依存関係の考慮 2． コネクション管理方式 ・ サーバ資源の管理 ・ persistent TCP コネクションの管理 提案方式は2つの手法から構成されます． まず，1つ目は先ほど説明したソケットバッファの管理手法です． 我々は，すでに提案しているWebサーバにおけるデータ転送処理の高速高機能化を実現するSSBT方式の中で Webサーバの動的なソケットバッファ管理方式を行うE-ATBT方式を提案しています． ProxyサーバはWebサーバと同様に，様々な環境からのコネクションを管理するのでソケットバッファを動的に変更して 割り当てることによって，データ転送処理を軽減できると考えられます． しかし，E-ATBT方式では，送信側のソケットバッファの動的な割り当てについての考察のみしか行っていません． 一方，Proxyサーバは，特性上，クライアントへのコネクションとWebさーばへのコネクションの間に依存関係が存在します． また，Webサーバからドキュメントをダウンロードするときには受信側となります． そのため，E-ATBT方式を適用するには，受信側のソケットバッファの管理，およびTCPコネクションの依存関係の考慮を しなければなりません． そこでこれらのことを考慮した手法である，E2-ATBT方式の提案を行います． 次にコネクション管理方式を提案します． Proxyサーバは，HTTP1.1をサポートしてきています． HTTP１．１を利用することによって，ネットワークおよびWebサーバの負荷を軽減させることができます． しかし，データ転送を行っていないpersistentコネクションに対しても，Proxyサーバはデータ転送を行っている コネクションと同等の資源を割り当てます． そのため， 2001年11月22日 TM 研究会

ソケットバッファ管理方式 E-ATBT (Equation-based Automatic TCP Buffer Tuning) 方式 決定した大きさのソケットバッファの割り当て proxy サーバの特性 TCP コネクション間の依存関係 受信側ソケットバッファの制御 まず，ソケットバッファ管理方式について説明します． これまでわれわれの研究グループでは，Webサーバの転送処理軽減手法として， E-ATBT方式を提案してきました． E-ATBT方式とは，各TCPコネクションの平均スループットを解析的手法によって導出し， そのスループットに基づく，動的なソケットバッファの割り当てを行ってきました． ProxyサーバもWebサーバと同様に，帯域や遅延時間の異なる多くのコネクションを収容するため， E-ATBT方式を適用することができると考えられます． しかし，Proxyサーバはその特性上，クライアントからのTCPコネクションとWebサーバのTCPコネクション の間には，依存関係が存在します． ここでの依存関係とは，たとえば，E-ATBT方式によって，クライアント間のTCPコネクションに 多くのソケットバッファの割り当てを行っても，Webサーバ関のTCPコネクションのスループットが 小さいために，クライアント間のTCPコネクションに割り当てたソケットバッファが無駄になってしまうといった ことです． また，ProxyサーバはWebサーバからドキュメントをダウンロードする時には，受信側ホストとして振る舞います． そのため，E-ATBT方式をProxyサーバに適用するためには，E-ATBT方式を改良する必要があります． 2001年11月22日 TM 研究会

E2-ATBT 方式 - コネクション間の依存関係 - 依存関係とは TCP コネクション間のスループットの違い client host proxy server web server 大きいサイズの ソケットバッファの割り当て そこで，E2-ATBT方式では，先ほどのべたTCPコネクション間の依存関係，および 受信側ソケットバッファの動的な割り当てを考慮します． まず依存関係の考慮について説明を行います． 依存関係を調べるためには，カーネルにおいてTCPコネクションのうち， クライアントとサーバの組み合わせを知る必要があります． しかし，カーネルでは各TCPコネクションを識別することは可能ですが， それらのコネクション間の依存関係を調べることはできません． そこでこの問題点に対して，以下の方法を用いることで，コネクションの識別を行った時と 同等の効果が得られると考えられます． まず，1つ目の方法としましては，各TCPコネクションに割り当てている送信側のソケットバッファの使用率 を監視し，その使用率が低い場合にはソケットバッファの有効な利用が行えていないと判断し， ソケットバッファの割り当てを強制的に減少させるという方法です． 2つ目の方法は，パケットヘッダへコネクション情報を付加する方法です． パケットヘッダに依存関係に関する情報を付加することによって，カーネルでソケットバッファの割り当て を変更させます． 無駄になる クライアント間のTCP コネクションに 割り当てるバッファサイズを減らす 2001年11月22日 TM 研究会

E2-ATBT 方式 - 受信側ソケットバッファ - proxy サーバの特徴 受信側ホストとして振る舞い 受信側ソケットバッファの割り当て 受信側ソケットバッファの不足によるスループットの低下 受信側ソケットバッファの動的な割り当てが必要 次に受信側ソケットバッファについての説明を行います． 送信側ホストが十分に高速で，かつネットワークに輻輳が生じていない環境において， 受信側ソケットバッファの不足によって，送信側ホストの送信レートが抑えられることによって， TCPコネクションのスループットが抑えられてしまうことがかんがえられます． 受信側ソケットバッファがスループット向上のボトルネックとならないためには 受信側ソケットバッファが送信側ウィンドウサイズ以上にすることによって可能となります． この問題点に対しては，コネクション間の依存関係と同様な方法によって可能であると考えられます． 提案方式のシミュレーションによる有効性の検証では， ソケットバッファに関する情報を正確に知ることができると仮定し，性能評価を行う． 実装に関する検討は，今後の課題とします． 受信側ソケットバッファサイズを 送信側ウィンドウサイズ以上にする 2001年11月22日 TM 研究会

コネクション管理方式 persistent TCP コネクション 転送終了後一定時間接続の保持 ウィンドウサイズなどのネットワーク情報の再利用 3-way handshake を行わない サーバ資源の割り当て 割り当てられたサーバ資源が無駄になる可能性がある サーバ資源の不足による新規 TCP コネクションの確立の拒否 proxy サーバは多くの TCP コネクションを収容する サーバ資源の無駄遣い persistent TCP コネクションの切断 次にコネクション管理についての説明を行います． Persistent コネクションは，ネットワーク情報を再利用してデータ転送を行うため ネットワークへの負荷を軽減することができます．また， スリーウェイハンドシェイクを避けることができるためWebサーバに対する負荷も軽減することができます． しかし，ProxyサーバはTCPコネクションがデータ転送にしようされている，いないにかかわらず ソケットバッファやファイルディスクリプタ等のサーバ資源を各TCPコネクションに割り当てるため， もしpersistent コネクションが利用されなければ割り当てられたサーバ資源が無駄になります． また，サーバ資源が不足し，新規TCPコネクションの確立が行えない状況になると， これらのサーバ資源が解放されるまで待機しなければならないため，Webドキュメント転送のスループットは 著しく低下してしまう． そこで，TCPコネクションを管理する必要があると考えられます． 2001年11月22日 TM 研究会

および persistent TCP コネクションの管理が必要 コネクション管理方式 proxy サーバの残存資源が十分ある時 可能な限り persistent TCP コネクションを収容する proxy サーバの残存資源が少ない時 使用されていない persistent TCP コネクションを切断し，新規 TCP コネクションの確立を行う この方式の実現には，残存資源の監視 および persistent TCP コネクションの管理が必要 そこでコネクション管理方式を，以下のよう行います． Proxyサーバの残存資源が十分にある時には， 可能な限りpersistent コネクションを収容します． これは，先ほど述べたように，persistent コネクションによりネットワークやWebサーバの負荷を軽減する ことができるためです． 一方，残存資源が少ない時には，使用されていないpersistent コネクションを切断し， サーバ資源を解放することによって新規TCPコネクションの確立を行えるようにし， TCPコネクションが確立できないことによる，スループットの低下を防ぎます． この方式を実現するためには，残存資源の管理およびpersistent コネクションの管理が必要となります． 2001年11月22日 TM 研究会

コネクション管理方式 - 残存資源の監視 - システムコールによる，各サーバ資源の使用可能量，および現在使用している量の取得 各サーバ資源の閾値の設定 その閾値を越えた場合，proxy サーバの資源が少なくなったと判断 まず，残存資源を管理するための方法についての説明をおこないます． プロキシサーバにおける資源の使用可能な量および，現在使用している量を取得することは， Sysctl 等のシステムコールを用いることで可能です． そこで，コネクション確立時に割り当てられる各サーバの資源に対して，閾値を設定し， それらの資源のうちどれかひとつでも閾値を超えた場合にはproxyサーバの資源 が少なくなったと判断することにします． このサーバ資源の監視の周期は，E2-ATBT方式で各TCPコネクションのスループットを計算する時に 同時に行うことにします． 2001年11月22日 TM 研究会

コネクション管理方式 - persistent TCP コネクションの管理 - hash function ( 192.168.10.200, 10010 ) ( 192. 168.17.10, 12049 ) ( 192.168.240.3, 10338 ) 246 36 120 16:20'40 16:20'42 16:20'48 time scheduling list time (IP address, port number) socket file descriptor NULL ・・・ ( 192.168.2.155, 10110 ) そして，persistent状態になったコネクションとして，time scheduling list の後ろの追加されます． このようにすることによって，persistent コネクションを切断しなければならない時には， Time scheduling list の先頭から切断することによってpersistent 状態の長いものから切断することが 可能となります． さらに，効果的な資源管理方式としては，persistent TCP コネクションに割り当てているソケットバッファの大きさを徐々に減らしていく方式が考えられる． シミュレーションでは，この方式も含めた性能評価を行う． ( 192.168.2.155, 10110 ) 159 16:20'53 2001年11月22日 TM 研究会

シミュレーションによる評価 シミュレーションモデル 伝搬遅延時間 : 10 – 200秒 ロス率 : 0.0001 – 0.01 今回の提案方式の有効性を検証するために，シミュレーションによる評価を行いました． シミュレーションモデルは図のとおりです． クライアントホストとプロキシサーバ間の伝播遅延時間を10-100秒まで，ロス率を0.0001-0.01までの値としました． また，Webサーバとプロキシサーバ間も同様に伝播遅延時間を10-200秒まで，ロス率を0.0001-0.01までの値としました． プロキシサーバのキャッシュヒット率を0.5，Webサーバの台数を50台としました． クライアント数を50,100,200,500と替え，HTTPリクエスト要求を 発生させた時の従来方式と提案方式によるシミュレーション結果を以下に示します． なお，このシミュレーションではプロキシサーバの性能の限界として， 200 TCPコネクションまでしか確立できないとし，シミュレーション時間は300secと設定しました． Proxy サーバ キャッシュヒット率 0.5 Web servers クライアントホスト 50，100，200，500 台 Web サーバ 50 台 伝搬遅延時間 : 10 – 100秒 ロス率 : 0.0001 – 0.01 2001年11月22日 TM 研究会

性能評価 性能評価を行った方式 scheme 1: 従来方式 scheme 2: ソケットバッファ管理方式 コネクション管理方式 scheme 4: scheme 3 にさらにソケットバッファを 徐々に減らす方式 2001年11月22日 TM 研究会

Total transfer size [Mbytes] proxy サーバでの性能評価 1200 scheme (1) scheme (2) scheme (3) 1000 scheme (4) 800 Total transfer size [Mbytes] 600 まず，Proxyサーバでの性能評価を行いました． この図は，プロキシサーバが扱ったデータの総量をあらわしています． ここでschemeとは， Scheme 1: 従来方式 Scheme 2: ソケットバッファ管理方式 Scheme 3: ソケットバッファ管理方式にさらにコネクション管理方式 Scheme 4: ソケットバッファ管理方式，コネクション管理方式とソケットバッファを徐々に減らす方式 をあらわします， この図より，従来方式はクライアント数が多くなると性能が低下していることがわかります． これは，TCPコネクションのうちドキュメント転送をおこなっていないpersistent TCPコネクションを収容 しているため，新規TCPコネクションの確立が行えないためです． ソケットバッファ管理方式では，コネクション数が小さいときは従来方式より性能が向上していることがわかります． これは，各TCPコネクションが要求しているソケットバッファサイズに基づいた割り当てを行うため， ソケットバッファの効率的な割り当てが行えたためであると考えられます． 一方，コネクション数が多くなると従来方式と同様に性能が悪くなります．これは， コネクション数が多いときに問題となるコネクションに関する管理を行っていないためであると考えられます． 次に，コネクション管理を行った方式について着目すると，コネクション数が増えている状態でも， たかい性能を示していることがわかります． これは，コネクション数が増加し，サーバ資源が少なくなってきた時にデータ転送を行っていないコネクションを 切断することにより新規TCPコネクションを確立しデータ転送を行うことができるため， Proxyサーバの扱ったデータ転送量が増加したと考えられます． また，persistent状態になったコネクションのソケットバッファを徐々に減少させていく方法では， コネクション数の少ないところで，ソケットバッファを徐々に減らさない方法よりも， 性能が向上していることがわかります． これは，データ転送をおこなっていないコネクションのソケットバッファを， データ転送をおこなっているコネクションに割り当てることによって，そのコネクションの スループットが向上し，全体としてプロキシサーバの扱ったデータ転送量が増加したと考えられます。 しかし，コネクション数が増加すると，persistent状態になったコネクションのソケットバッファを 減少させる前にコネクションが切断されてしまうため， ソケットバッファを徐々に減らす効果が見られないという結果となっています． 400 200 50 100 200 500 Number of client hosts 2001年11月22日 TM 研究会

クライアントの応答時間 - クライアント数 50 - 0.1 1 10 100 1000 10000 100000 1e+006 1e+007 1e+008 Response Time [sec] Document Size [Byte] scheme (1) scheme (2) scheme (3) scheme (4) 次にクライアントがドキュメントを要求してから，そのドキュメントを取得するまでにかかった 応答時間についてのシミュレーション結果を示します． まず，クライアント数が50の時の結果です． クライアント数が50の時は，サーバ資源が十分にあるため，従来方式においても コネクションの確立要求にすぐに答えることが可能であるため，それほど応答時間に違いはありませんが， しかし，ドキュメントサイズが大きくなるにつれ，提案方式の応答時間が短くなっていることがわかります． これは，E2-ATBT方式によって，各TCPコネクションの要求サイズの応じたソケットバッファの割り当てが行えるため， スループットが向上し，応答時間が短くなっていることがわかります． 2001年11月22日 TM 研究会

クライアントの応答時間 - クライアント数 200 - 0.1 1 10 100 1000 10000 100000 1e+006 1e+007 Response Time [sec] Document Size [Byte] scheme (1) scheme (2) scheme (3) scheme (4) クライアント数が200の時です． この図より，コネクション管理方式を行っていない方式と比較して， コネクション管理を行っている方式は応答時間が短くなっていることがわかります． これは，先ほど説明したように，プロキシサーバの資源が少なくなってきた時に， アイドル状態であるpersistent コネクションを切断することによって，新規TCPコネクションを すぐに確立できるため，応答時間が短くなっていると考えられます． 2001年11月22日 TM 研究会

まとめと今後の課題 proxy サーバにおけるサーバ資源管理方式の提案 シミュレーションによる有効性の確認 ソケットバッファ管理方式 コネクション管理方式 proxy サーバの性能改善 応答時間の改善 今後の課題 提案方式を実際の proxy サーバへの実装 その他のエンドホスト資源管理方式の検討 2001年11月22日 TM 研究会