View - 村田研究室

社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS
信学技報
TECHNICAL REPORT OF IEICE.
Web プロキシサーバにおける TCP 受信バッファの動的割り当て方式
岡本
卓也†
長谷川 剛††
村田
正幸††
† 大阪大学 大学院基礎工学研究科 〒 560-8531 大阪府豊中市待兼山町 1-3
†† 大阪大学 サイバーメディアセンター 〒 560-0043 大阪府豊中市待兼山町 1-32
E-mail: [email protected], ††{hasegawa,[email protected]
あらまし 現在のインターネットにおいては、Web プロキシサーバを経由した Web サーバへのアクセスが数多く存在
する。Web プロキシサーバはその性質上、Web クライアントホストからの TCP コネクションおよび Web サーバへの
TCP コネクションを収容しなければならないため、Web プロキシサーバにおいて効率的な資源管理が必要になる。そ
こで本稿では、Web プロキシサーバの高速・高機能化を実現するための資源管理方式を提案する。提案方式は、Web
プロキシサーバの特性を考慮し、Web プロキシサーバが Web サーバからドキュメントをダウンロードする際に、各
TCP コネクションのネットワーク状況に応じた大きさの TCP 受信バッファを動的に割り当てる。したがって、ネッ
トワーク帯域が大きい TCP コネクションにはより多くの受信ソケットバッファを割り当て、またネットワーク帯域が
小さい TCP コネクションにはより少ない受信ソケットバッファを割り当てることが可能となるため、Web プロキシ
サーバの資源を効率的に利用することができる。本稿では、提案方式の有効性をシミュレーションを用いて検証した。
その結果提案方式を用いることによって、Web プロキシサーバの特性を考慮した効率的な資源管理を行うことができ、
資源管理をしない従来方式と比較して最大 2 倍のスループットが得られ、応答時間も約 1/4 に短縮できることを示す。
キーワード Web プロキシサーバ、TCP、受信ソケットバッファ
Dynamic Receive Socket Buffer Allocation at Web Proxy Servers
Takukya OKAMOTO† , Go HASEGAWA†† , and Masayuki MURATA††
† Graduate School of Engineering Science, Osaka University
1-3 Machikaneyama, Toyonaka, Osaka 560-8531, Japan
†† Cybermedia Center, Osaka University
1-32 Machikaneyama, Toyonaka, Osaka 560-0043, Japan
E-mail: [email protected], ††{hasegawa,[email protected]
Abstract In the current Internet, many HTTP sessions are established between Web clients and servers via Web
proxy servers. Since the Web proxy server accommodates lots of TCP connections from Web client hosts, and
those to Web servers, it cannot show sufficient performance if the resources of the proxy server should be utilized
effectively. In this paper, we propose a new resource management scheme for Web proxy servers to improve their
performance and to reduce Web document transfer time via it. Our proposed scheme assigns the proper size of
receive socket buffer to each TCP connection, which downloads the original Web document from the Web server
via the Web proxy server. That is, a larger size of the receive socket buffer is assigned for a TCP connection with
larger link bandwidth, and vice versa. We validate an effectiveness of our proposed scheme through simulation
experiments. The simulation results show that our proposed scheme can manage resouces at the Web proxy server
and an about twice throughput of the Web Proxy server and up to one-quater response time of document transfer
is obtained our proposed scheme as compared with the conventional method.
Key words Web proxy server, TCP, receive socket buffer
1. は じ め に
インターネットの急速な発展により、WWW (World Wide
Web) を利用して非常に多くの情報を取得することが可能になっ
ている。WWW の普及によりインターネットの利用者は爆発
的に増加し、それに伴なうネットワークトラヒックの増大のた
めにネットワークにおける輻輳が引き起こされている。この問
題に対してこれまで行なわれてきた研究の多くは、ネットワー
ク帯域の増強や、輻輳の抑制に関するものであった。これは、
これまでネットワークの処理速度と比較してエンドホストにお
けるデータ転送処理速度は高速であり、エンドホストがボトル
ネックとなるような状況は想定されていなかったためである。
しかし、これまでの研究成果や技術革新により、ネットワーク
帯域が飛躍的に増加したため、Web サーバのようなエンドホス
トがデータ転送のボトルネックとなる状況が生まれつつある。
この問題に対し我々の研究グループでは、エンドホストに
おけるデータ転送処理の高速・高機能化のための手法とし
て SSBT (Scalable Socket Buffer Tuning) 方式を提案してい
る [1]。SSBT 方式は、TCP によるデータ転送効率と複数コネク
ション間の公平性の向上を目的とした、動的な送信ソケットバッ
ファ割り当て手法である E-ATBT (Equation-based Automatic
TCP Buffer Tuning) 方式、および高速なデータ転送時の通信
処理軽減手法である SMR (Simple Memory-copy Reduction)
方式からなる。[1] では、シミュレーションおよび実験ネットワー
—1—
クにおいて、実ネットワーク上での Web アクセス分布を考慮し
たワークロードを用いたデータ転送実験を行ない、SSBT 方式
の有効性を確かめた。しかし現在のインターネットでは、Web
プロキシサーバを経由した HTTP アクセスも多い [2]。Web プ
ロキシサーバは、ISP (Internet Service Provider) 等が顧客へ
のサービスために提供している場合が多いため、多くのユーザ
からのドキュメント転送要求を同時に受け付け処理する必要が
ある。そのため、ネットワークに輻輳が発生しておらず、また
Web サーバの稼働能力が十分であるにもかかわらず、Web プ
ロキシサーバの処理能力が十分でないために、Web プロキシ
サーバがドキュメント転送のボトルネックとなることが考えら
れる。すなわち、Web プロキシサーバにおいても、高速・高機
能化のための手法を考慮する必要がある。
Web サーバと同様に SSBT 方式を適用することによって、
Web プロキシサーバの高速・高機能化を実現できると考えられ
る。しかし上述したように、Web プロキシサーバは多くの TCP
コネクションを同時に受け付けなければならず、また Web サー
バと異なり、ドキュメントをダウンロードする際には受信ホス
トとしてふるまう。そのため、SSBT 方式を単純に適用するだ
けでは不十分であり、Web プロキシサーバの特性を考慮した資
源管理方式を適用する必要がある。そこで我々は [3] において、
Web プロキシサーバの特性を考慮した資源管理手法として、送
受信ソケットバッファの動的割り当て手法、およびドキュメン
ト転送終了後の persistent な TCP コネクションを管理するコ
ネクション管理手法を提案した。送受信ソケットバッファの動
的割り当て手法は、[1] で提案した E-ATBT 方式を Web プロキ
シサーバへ適用したものであり、各 TCP コネクションのネッ
トワーク状況に応じて受信ソケットバッファを与える手法であ
る。さらに Web プロキシサーバの特徴である、クライアント
ホストへの TCP コネクションと Web サーバへの TCP コネク
ションの依存関係、すなわち両コネクション間のスループット
の違いを考慮したソケットバッファ管理手法をあわせて提案し
た。しかし受信ソケットバッファの割り当て手法に関しては、
その必要性および設計指針を述べるにとどまっており、詳細な
アルゴリズムを示していない。そこで本稿では、受信ソケット
バッファの動的な割り当て手法について詳細なアルゴリズムを
示す。提案アルゴリズムは、受信ホストにおいて受信ソケット
バッファの利用率を監視し、受信ソケットバッファが不足すれ
ばより多くのバッファを割り当て、逆に受信ソケットバッファ
を余剰に割り当てている場合には、バッファの割り当てサイズ
を減少させる手法である。また本稿では、提案アルゴリズムの
有効性をシミュレーションを用いた性能評価結果を通じて確認
する。
以下、2 章では Web プロキシサーバの概略と TCP の送受信
ソケットバッファについて述べる。3 章では TCP 受信バッファ
の動的割り当て手法を説明し、詳細なアルゴリズムを示す。4
章では提案方式の有効性をシミュレーションを用いて検証する。
最後に、5 章で結論と今後の課題について述べる。
2. 背
景
2. 1 Web プロキシサーバ
Web プロキシサーバとは、Web クライアントホストからオ
リジナル Web サーバへのドキュメント転送要求を代理で行なう
サーバである (図 1)。Web プロキシサーバはクライアントホス
トからドキュメント転送要求を受信すると、要求されたドキュ
メントをクライアントに代わってオリジナル Web サーバから
ダウンロードする。その際、要求されたドキュメントをキャッ
シュに保存しておき、別のクライアントホストから同じドキュ
メントの転送要求が発生した際には、キャッシュしたドキュメ
ントを直接クライアントホストに転送する。これにより、クラ
イアントの感じるドキュメント転送時間を短かくすることが可
能となる。[4] では、Web プロキシサーバを利用することによっ
Web servers
get the document from
the original Web server
Internet
Upward
TCP connection
Request the document
to the original Web server
No Hit
Hit
Web proxy server
Downward
TCP connection
Internet
deliver the document
Request a document
Client hosts
図 1 Web プロキシサーバの概略
て、ドキュメント転送時間を約 30%削減することが可能となる
と報告されている。また、キャッシュしたドキュメントをクラ
イアントホストへ直接転送することにより、オリジナル Web
サーバへの TCP コネクションの確立を行なう必要がないため、
ネットワーク内のトラヒック量を抑え、さらにオリジナル Web
サーバの負荷を軽減することができる。
Web プロキシサーバは、多数の TCP コネクションを同時に
処理しなければならず、またその性質上送信ホストにも受信ホ
ストにもなる。そのため、Web プロキシサーバにおいて十分
な資源管理がなされていなければ、Web プロキシサーバの資
源を浪費してしまうため、ネットワーク帯域およびオリジナル
Web サーバの処理能力に余裕があるにもかかわらず、Web プ
ロキシサーバがドキュメント転送のボトルネックとなり、満足
するサービスを提供できなくなる。したがって、Web プロキシ
サーバの性能を向上させるためには、Web プロキシサーバにお
いて効率的な資源管理が必要である。
Web プロキシサーバが持つ資源には、mbuf やファイルディ
スクリプタ、TCP コネクション情報を格納するメモリ領域、ソ
ケットバッファ等が挙げられる [3]。本稿ではこれらの資源のう
ち、TCP によるデータ送受信の際に各 TCP コネクションに割
り当てられる資源であるソケットバッファに着目する。
2. 2 ソケットバッファ
TCP を用いたデータ転送では、各 TCP コネクション毎に転
送データを格納するための領域である、ソケットバッファが送
受信ホストにおいて割り当てられる。ユーザアプリケーション
が TCP を用いてデータ転送を行なう時には、送信データは一
旦送信ソケットバッファにコピーされ、続いてカーネルのメモ
リ空間にある mbuf にコピーされネットワークに送出される。
受信ホストにおいては、受信したデータパケットは受信ソケッ
トバッファに蓄積された後、ユーザアプリケーションに渡され
る。TCP によるデータ転送においては、各 TCP コネクション
毎に割り当てられるソケットバッファサイズがその性能に大き
な影響を与える。例えば、64 [Kbps] のリンクで接続している
クライアント A と、100 [Mbps] のリンクで接続しているクラ
イアント B が存在する場合に、OS が同じ大きさの送信ソケッ
トバッファを両コネクションに割り当てると、クライアント A
にとってはバッファサイズが大きい、あるいはクライアント B
にとってバッファサイズが小さいという状況が発生し得る。こ
のように、エンドホスト資源の一つであるソケットバッファを
有効に利用するためには、それぞれの TCP コネクションの持
つリンク容量 (帯域遅延積) に応じたソケットバッファの割り当
てを行なう必要がある。
我々の研究グループでは、Web サーバにおいて RTT (Round
Trip Time)、RTO (Retransmission Timeout)、パケットロス
率などから各 TCP コネクションのスループットを解析的に推
測し、そのスループットに応じて動的に送信ソケットバッファ
を割り当てる、E-ATBT 方式を提案している [1]。E-ATBT 方
式では、送信ホストが上述のパラメータを利用し、[5] に示され
ている解析手法により平均ウィンドウサイズを導出する。その
—2—
ウィンドウサイズから、さらに TCP の再送タイムアウトを考
慮した上で、各 TCP コネクションの平均スループットを導出
する。このようにして求めた平均スループットを基に、各 TCP
コネクションが必要としている送信ソケットバッファの大きさ
を導出する。我々はこの E-ATBT 方式を Web サーバへ適用
し、その有効性を確かめた。
Web プロキシサーバは、Web サーバと同様に様々な環境か
ら非常に多くの TCP コネクションを収容している。そのため、
E-ATBT 方式を適用することによって Web プロキシサーバ
の高速化を実現することが可能であると考えられる。しかし、
Web プロキシサーバは Web サーバと異なり、ドキュメントダ
ウンロード時のオリジナル Web サーバへの TCP コネクショ
ンにおいては受信ホストとしてふるまうため、E-ATBT 方式
で考慮していなかった受信ソケットバッファの制御が必要とな
る。そこで次章において、TCP 受信バッファの動的割り当て
アルゴリズムを提案する。
3. TCP 受信バッファの動的割り当て
これまで述べたように、Web プロキシサーバの高速・高機能
化のためには、Web プロキシサーバのふるまいを考慮した動
的なソケットバッファの割り当てを行なう必要がある。一方、
TCP の輻輳制御方式、およびスループットに関するこれまで
の研究のほとんどにおいては、エンドホストではなくネット
ワークにボトルネックがあり、TCP コネクションの受信ソケッ
トバッファの大きさは十分に大きいと仮定されてきた。そのた
め、従来の OS によって割り当てられる受信ソケットバッファ
の大きさは、例えば FreeBSD では 16KB と、TCP コネクショ
ンの状態に関係なく固定的に割り当てられる [6]。しかし、近年
のインターネットの発展によってリンク帯域が飛躍的に増加し
ている状況においては、従来の割り当て方法による受信ソケッ
トバッファの大きさは十分ではなく、データ転送のボトルネッ
クになることがある [7]。この問題を避けるためには、受信ホス
トにある受信ソケットバッファの大きさを、送信ホストの輻輳
ウィンドウサイズ以上にする必要がある。したがって、受信ホ
ストにおいて送信ホストの輻輳ウィンドウサイズを知る必要が
ある。
受信ホストにおいて送信ホストの輻輳ウィンドウサイズを知
る方法として、我々の研究グループでは [3] において、受信ソ
ケットバッファの利用率を監視する方法、および送受信するパ
ケットのヘッダにコネクション情報を埋めこむ方法の 2 種類の
指針を示した。後者の方法は、前者の方法に比べてより正確に
送信ホストの輻輳ウィンドウサイズを知ることが可能である
が、送受信ホストの TCP を改造する必要があるという大きな
問題点がある。そこで本章では、前者の指針に基づいて、受信
ソケットバッファの利用率の変化の特性を利用した受信ソケッ
トバッファの割り当てアルゴリズムを示す。
3. 1 割り当てアルゴリズム
TCP を用いたデータ転送においては、受信ホストが受信し
たデータパケットは、ビットエラーのチェック等を行なった後、
受信ソケットバッファに格納される。パケットが廃棄されるこ
となく順調に受信されている場合は、受信ソケットバッファに
格納されたパケットは通常直ちにユーザアプリケーションに渡
される。そのため、受信ソケットバッファの利用率 (パケット
が格納されている割合) は低い。しかし、ネットワーク内でパ
ケットが廃棄されると、それ以降に受信されたパケットは、そ
の廃棄されたパケットが再送によって受信ホストに届くまで受
信ソケットバッファに蓄積される。したがって、受信ソケット
バッファの利用率は高くなる。本提案方式は、この受信ソケッ
トバッファの利用率の変化の特性を利用し、受信ソケットバッ
ファの割り当てを行う。以降、パケット廃棄が発生する場合と
しない場合について、提案アルゴリズムに関する説明を行なう。
Sender
Receiver
1
2
3
4
5
store at
receive socket buffer
n
n+1
duplicate ACK
re-transmit
2
Data Packet
図2
ACK Packet
受信ソケットバッファの動作
3. 1. 1 パケット廃棄がある場合
ネットワーク内でパケット廃棄等が発生すると、それ以降に
受信したパケットは、廃棄されたパケットが再送され受信ホス
トに到着するまで受信ソケットバッファに蓄積される。そのた
め、受信ソケットバッファの利用率は一時的に高くなる。ネッ
トワーク内で廃棄されたパケットが再送され受信ホストに到着
すると、それまで蓄積されていたパケットはまとめてユーザア
プリケーションに渡され、受信ソケットバッファの利用率は低
くなる。このとき、廃棄されたパケットが Fast Retransmit ア
ルゴリズム [8] によって再送されるとすると、廃棄されたパケッ
トの再送は約 1 RTT (Round Trip Time) 後に行なわれる。そ
のため、受信ソケットバッファに蓄積されるパケット数は送信
ホストが 1 RTT に送信することができるパケット数、すなわ
ち送信ホストの輻輳ウィンドウサイズにほぼ等しくなる (図 2)。
そこで、受信ホストで観測して得られた受信ソケットバッファ
の利用率を用いて、受信ソケットバッファの割り当てを以下の
ように行なう。なお、受信ホストにおけるネットワーク内での
パケット廃棄の検出に関しては、受信したパケットの TCP ヘッ
ダに記されているシーケンス番号の検査を行ない、シーケンス
番号が連続していなければパケットが廃棄されたと判断する。
• パケット廃棄があり、受信ソケットバッファの利用率が
高い場合
送信ホストから 1 RTT で送出されたパケットによって
受信ソケットバッファがほとんど使い切られてしまって
いるため、受信ソケットバッファの大きさがデータ転送
のボトルネックとなっている可能性がある。そこで、受
信ソケットバッファを、観測された送信ホストのウィン
ドウサイズを考慮した大きさに変更する。
• パケット廃棄はあるが、受信ソケットバッファの利用率
が低い場合
現在のネットワーク状況では、受信ソケットバッファが
必要以上に多く割り当てられていると考えられるので、
割り当てサイズを小さくする。
3. 1. 2 パケット廃棄がない場合
ネットワークにおいてパケット廃棄が発生せず、ユーザアプ
リケーションの処理速度 (受信ソケットバッファにあるデータ
パケットを処理する速度) が十分に速いときは、受信ソケット
バッファの利用率は低い。この場合、以下の 2 つの状況が考え
られる。
(a) 受信ソケットバッファは十分に大きく、送信側のウィン
ドウサイズがデータ転送のボトルネックになっている
(b) 受信ソケットバッファが小さすぎて、データ転送のボト
ルネックとなっている
これらの違いは、受信ソケットバッファの割り当てサイズが
TCP コネクションの利用可能な帯域遅延積より大きいかどうか
によって決まる。しかし受信ホストではデータパケットを送信
しないため、ネットワーク状況を知ることができな。そこで本
方式では、受信ソケットバッファの大きさを変化させ、スルー
プット (受信ホストにおけるデータパケット受信レート) の変化
—3—
を観測することによって以下のように判断する。
• 受信ソケットバッファを増加させた時に、スループット
が向上しない場合
既に受信ソケットバッファが十分に割り当たっていると
考えられるため、(a) の場合に相当する。したがって、受
信ソケットバッファを減少させる。
• 受信ソケットバッファを増加させた時に、スループット
が向上する場合
受信ソケットバッファの増加によりスループットが向上
したと考えられるため、(b) の場合に相当する。したがっ
て、さらに受信ソケットバッファを増加させる。
また、パケット廃棄が発生しない場合においても、ユーザア
プリケーションの処理速度が低いために、受信ソケットバッファ
の利用率が高くなることがある。これは、ユーザアプリケー
ションの処理速度が遅いために、受信ソケットバッファに蓄積
されたパケットがなかなか処理されないためである。この場合
は、ユーザアプリケーションの処理速度がデータ転送のボト
ルネックであるため、受信ソケットバッファを増加させてもス
ループットは向上しない。したがって、受信ソケットバッファ
を増減させず、そのままの大きさを維持する。
3. 1. 3 アルゴリズム
前節までの考察に基づいた、具体的な受信ソケットバッファ
の動的割り当てアルゴリズムを以下に示す。ある TCP コネク
ションの i 番目の観測期間における受信ソケットバッファの最
大利用率を Ui 、観測期間中に割り当てられている受信ソケッ
トバッファサイズを Bi 、観測期間中のスループット (データパ
ケットの受信速度) を ρi とすると、新たな割り当てサイズ Bi+1
は以下のようになる。
• 観測期間 i にパケット廃棄が発生した場合

 Bi+1
Bi+1
 B
i+1
=
=
=
α × Ui × Bi
β × Bi
Bi
when
Ui < Tu
when
Ui < Tl
otherwise
• 観測期間 i においてパケット廃棄が発生しなかった場合

 Bi+1
Bi+1

Bi+1
=
=
=
α × Bi
β × Bi
Bi
when Ui < Tl and ρi >
= ρi−1
when Ui < Tl and ρi < ρi−1
otherwise
ここで、α、β 、は受信ソケットバッファの割り当てサイズの
増減割合を決定するパラメータであり、Tu 、Tl は受信ソケット
バッファの利用率が高いか低いかを判断するための閾値である。
4. シミュレーション
本章では、前章において提案した受信ソケットバッファの動
的割り当て方式について、ns-2 [9] を用いたシミュレーション
によってその有効性を確かめる。なお以下のシミュレーション
では、3. 1. 3 節で示した変数 α、β 、Tu 、Tl は、それぞれ、2、
0.1、0.9、0.4 としている。
4. 1 ファイル転送実験による性能評価
まず、提案した TCP 受信バッファ割り当てアルゴリズムの基
本的性質を確認するために、無限長ファイルの FTP 転送による
性能評価を行なう。シミュレーションを行なったネットワークト
ポロジを図 3 に示す。図 3 において、受信ホストとルータの間の
リンク帯域を 100 Mbps、伝播遅延時間を 0.001 sec とする。ま
た、送信ホスト数を 45 とし、帯域と伝搬遅延時間が (100 Mbps,
1 sec)、(100 Mbps, 0.1 sec)、(100 Mbps, 0.01 sec)、(1.5 Mbps,
1 sec)、(1.5 Mbps, 0.1 sec)、(1.5 Mbps, 0.01 sec)、(128 Kbps,
1 sec)、(128 Kbps, 0.1 sec)、(128 Kbps, 0.01 sec) であるよう
な 9 種類のリンクをそれぞれ 5 本ずつ用意し、45 台の送信ホ
ストとルータの間のリンクとする。ボトルネックルータのバッ
ファサイズは 50 とする。このネットワークにおいて、各送信
BW: 100Mbps
RTT: 0.001sec
Receiver
BW: 100Mbps/1.5Mbps/128Kbps
RTT: 1sec/0.1sec/0.01sec
Sender
図 3 シミュレーショントポロジ (1)
ホストは受信ホストに向かって無限長のファイル転送を FTP
によって行なう。すわなち、受信ホストは 45 本の TCP コネ
クションをシミュレーション中保持し、データを受信する。シ
ミュレーション時間は 1000 秒とした。
図 4 に、受信ホストにおける TCP コネクション 1 本あた
りの受信ソケットバッファの大きさとして、16 KB、64 KB、
128 KB、256 KB、512 KB の固定値、および提案方式を用い
た場合のシミュレーション結果を示す。図 4(a) は、リンク帯域
と伝播遅延時間がそれぞれ異なる 9 種類のコネクションの平均
スループットを示し、図 4(b) は、受信ホストが 9 種類の TCP
コネクションに割り当てている受信ソケットバッファの平均サ
イズを示している。また、各グラフの上部には各条件下におい
てすべての TCP コネクションを収容するために必要であった
受信ソケットバッファの総量を示している。
この結果から、固定的に 16 KB や 64 KB の受信ソケットバッ
ファが割り当てられる場合においては、リンク帯域が 100 Mbps
や 1.5 Mbps のリンク上の TCP コネクションに対して受信ソ
ケットバッファが小さすぎるため、スループットが低下してい
ることが分かる。また逆に、各 TCP コネクションに 512 KB
の受信ソケットバッファを割り当てた場合は、十分なスループッ
トが得られているが、その値は 128 KB や 256 KB の場合とほ
とんど変わらず、過剰な受信ソケットバッファが割り当てられ
ている。
一方、提案方式を用いた場合には、各コネクションは十分大
きなソケットバッファを割り当てた場合 (512 KB) とほぼ同一
のスループットを獲得しながら、使用している受信ソケットバッ
ファの総量を小さく抑えることができている。また、図 4(b)
より、リンク帯域が 128 Kbps のリンク上の TCP コネクショ
ンには、その帯域での十分な大きさである 15∼20 KB の受信
ソケットバッファを割り当て、リンク帯域が大きい 100 Mbps
のコネクションにはより大きな 300∼400 KB の受信ソケット
バッファを割り当てていることが分かる。すなわち提案方式は、
各 TCP コネクションが必要とするバッファサイズに応じた受
信ソケットバッファの割り当てを行ない、少ない受信ソケット
バッファの割り当てサイズで多くの TCP コネクションを収容
し、その結果高いスループットを得ることができていることを
示している。このことは、受信ソケットバッファの総量を固定
した次節での Web プロキシサーバにおける性能評価で明らか
にする。
また、このシミュレーション結果における提案方式の性能お
よび受信ソケットバッファの割り当て総量は、128 KB の固定
サイズを割り当てた場合とほぼ同じ結果になっている。しかし、
実際の Web プロキシサーバの性能は収容するコネクション数
や受信ソケットバッファの総量などに依存しており、最適な受
信ソケットバッファの割り当てサイズは変化する。提案方式で
は、この変化に対応し動的な割り当てが可能であるため、どの
ような環境においても高いスループットを獲得することができ
る。このことも、次節であわせて明らかにする。
—4—
1.5Mbps, 1sec
1.5Mbps, 0.1sec
1.5Mbps, 0.01sec
10
9
8
7
6
5
4
3
2
1
0
128Kbps, 1sec
128Kbps, 0.1sec
128Kbps, 0.01sec
10M/1.5M/128Kbps
1/0.1/0.01sec
Web Servers
Client Hosts
図 5 シミュレーショントポロジ (2)
ix
BF
64K
KB
128
Fix
KB
256
Fix
KB
512
Fix
osed
Prop
(a) スループット
1.5Mbps, 1sec
1.5Mbps, 0.1sec
1.5Mbps, 0.01sec
100Mbps, 1sec
100Mbps, 0.1sec
100Mbps, 0.01sec
600
128Kbps, 1sec
128Kbps, 0.1sec
128Kbps, 0.01sec
202.5 MB
500
50.61 MB
400
Total Transferred Size [MB]
ix
BF
16K
Assigned Buffer Size [KB]
Proxy Server
16K
ix
ix
ix
ix
B F 6 4 KB F 2 8 KB F 5 6 KB F
o se d
2
1
Prop
2.5
2
1.5
1
0.5
0
3.2
101.25 MB
300
6.4
Total Buffer Size [MB]
12.8
50.63 MB
200
100 6.33 MB
0
ix
BF
16K
25.31 MB
ix
BF
64K
(a) 転送バイト数
KB
128
Fix
KB
256
Fix
KB
512
Fix
osed
Prop
(b) 受信ソケットバッファサイズの使用量
図 4 シミュレーション結果 (FTP 転送: スループットと受信ソケット
バッファの割り当てサイズ)
4. 2 Web プロキシサーバの性能評価
次に、提案方式を Web プロキシサーバに適用した際の性能評
価を行なう。シミュレーションに用いたネットワークトポロジを
図 5 に示す。図 5 において、Web プロキシサーバと Web サー
バ間のリンク帯域を 100 Mbps/10 Mbps/1.5 Mbps、伝播遅延
時間を 1 sec/0.1 sec/0.01 sec とするような Web サーバ数を 99
(各 11 台× 9 種類)、また Web プロキシサーバと Web クライア
ントホスト間のリンク帯域を 10 Mbps/1.5 Mbps/128 Kbps、
伝播遅延時間を 1 sec/0.1 sec/0.01 sec とするような Web クラ
イアントホスト数を 450 (各 50 台× 9 種類) とする。各クライ
アントホストは、99 台の Web サーバからランダムに 1 台選択
し、ドキュメント転送要求を Web プロキシサーバに送信する。
Web プロキシサーバはキャッシュヒット率 (このシミュレーショ
ンでは 0.5 に固定) に基づいて、キャッシュヒットかキャッシュ
ミスかを判断し、キャッシュヒットであればそのままクライア
ントホストにドキュメントを転送し、キャッシュミスであれば
Web サーバからダウンロードした後、クライアントホストへド
キュメント転送を行なう。各クライアントホストは、[10] に示
されている、実際の Web クライアントの動作解析によって得
られたドキュメント転送要求間隔分布、要求ドキュメントサイ
ズ分布にしたがってドキュメント転送要求を発生するものとす
る。シミュレーション時間は 1000 秒とする。
図 6 は、Web プロキシサーバの受信ソケットバッファの総量
を 3.2 MB/6.4 MB/12.8 MB と変化させ、Web プロキシサーバ
の受信ソケットバッファの大きさを 16 KB、64 KB、128 KB、
256 KB の固定値、および提案方式を用いたときの、Web プロ
16K
Response Time [sec]
Throughput [Mbps]
100Mbps, 1sec
100Mbps, 0.1sec
100Mbps, 0.01sec
BW: 100/10/1.5 Mbps
RTT: 1/0.1/0.01sec
9
8
7
6
5
4
3
2
1
0
ix
ix
ix
Fix
ed
B F 6 4 KB F 8 KB F
KB Propos
12
256
3.2
6.4
Total Buffer Size [MB]
12.8
(b) 応答時間
図 6 シミュレーション結果
キシサーバがクライアントホストに向けて転送したドキュメン
トの総バイト数 (図 6(a))、およびクライアントホストがドキュ
メント転送要求を送信してからドキュメントのダウンロードが
完了するまでにかかった応答時間を示している (図 6(b))。図
6(a) から、Web プロキシサーバの受信ソケットバッファの総
量が十分にある (12.8 MB) 場合、4. 1 節でのシミュレーション
結果と同様に、受信ソケットバッファの割り当てサイズが小さ
い場合には TCP コネクションのスループットが低く、Web プ
ロキシサーバの性能が低下していることがわかる。一方、受信
ソケットバッファの割り当てサイズが大きい場合はより高いス
ループットが得らている。また、図 6(b) から、受信ソケット
バッファの割り当てサイズが小さい場合、応答時間が長いこと
が分かる。これは、TCP コネクションのリンク帯域と比較し
て受信ソケットバッファの割り当てサイズが小さすぎるため、
TCP コネクションのスループットが低く、ドキュメント転送時
間が大きくなっているためである。
—5—
5. まとめと今後の課題
Blocking Ratio
逆に、Web プロキシサーバの受信ソケットバッファの総量
が少ない (3.2 MB) 場合は、受信ソケットバッファの割り当
てサイズが大きい時には、応答時間が非常に長く (図 6(b))、
Web プロキシサーバの転送量も少なくなっていることが分か
る (図 6(a))。これは 256 KB と大きなサイズの受信ソケット
バッファを各 TCP コネクションに割り当てると、受信ソケッ
トバッファが不足し、Web プロキシサーバに到着するすべて
の TCP コネクションを収容することができなくなるためであ
る。その結果、収容されない TCP コネクションは他の TCP
コネクションが転送を終了し、受信ソケットバッファを開放す
るまで待たされるため、ドキュメント転送に必要な時間が増大
する。また、256 KB の受信ソケットバッファサイズはほとん
どの TCP コネクションとっては大きすぎるため、受信ソケッ
トバッファの使用効率が低下し、Web プロキシサーバの転送量
が低下している。
一方、提案方式を適用した場合、受信ソケットバッファの総
量が十分ある時は、従来方式において十分大きな受信ソケット
バッファを割り当てた場合とほぼ同等のスループットが得られ、
また応答時間も短いことが分かる。さらに、受信ソケットバッ
ファの総量が少ない場合においても、高いスループットを維持
し、かつ応答時間も短いことが分かる。これは、リンク帯域の
小さい TCP コネクション (今の場合、128 Kbps) の使用して
いない受信ソケットバッファを、リンク帯域の大きい TCP コ
ネクション (10 Mbps) に再割り当てを行なうことによって、リ
ンク帯域の大きい TCP コネクションの受信ソケットバッファ
の不足を解消することができるためである。またその結果、各
TCP コネクションに割り当てられた受信ソケットバッファの
使用効率が向上するため、Web プロキシサーバの転送量が大
きくなり、応答時間を短くすることができる。図 7 は、ドキュ
メント転送のために TCP コネクションを張ろうとした時に、
受信ソケットバッファの不足のためにコネクション確立要求が
拒否された確率 (ブロッキング率) を示したグラフである。こ
の図から、受信ソケットバッファを固定的に割り当てる従来方
式では、特に受信ソケットバッファの総量が小さい時に、TCP
コネクション 1 本あたりの割り当てサイズが大きくなると、ブ
ロッキング率が非常に高くなっていることがわかる。これは、
Web プロキシサーバにおいて受信ソケットバッファが不足する
ため、新規の TCP コネクションを確立できないためである。
さらに、確立されている TCP コネクションに割り当てられて
いる受信ソケットバッファの実際の使用効率は低い。このため、
図 6 に示したように、Web プロキシサーバの性能が劣化し、ド
キュメント転送にかかる時間が増大している。一方、提案方式
では、コネクション確立要求が拒否されることはなく、新規の
TCP コネクションが到着すると、ネットワーク状況に応じて必
要とする受信ソケットバッファを割り当てるため、受信ソケッ
トバッファの使用効率が向上する。これにより、受信ソケット
バッファの総量に依存せず、高い Web プロキシサーバの性能
および短い応答時間を実現している。
また、図 6 より、受信ソケットバッファの総量が 3.2 MB の
時は 64 KB、6.4 MB の時は 128 KB、および 12.8 MB のとき
は 256 KB の固定サイズを割り当てると、Web プロキシサー
バのスループットが一番高く、かつ応答時間が短い。このよう
に、従来の固定的な割り当て方式においては、受信ソケット
バッファの総量などによって最適な割り当てサイズが異なる。
一方、提案方式を用いることで、どのような状況下においても
Web プロキシサーバのスループットはほぼ最大の値を得られ、
また応答時間も非常に短い。すなわち提案方式はネットワーク
状況に応じた効率的な受信ソケットバッファの割り当てが可能
であるといえる。
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
16K
B
3.2
64K
B
128
KB
256
KB
o
Prop
6.4
Total Buffer Size [MB]
se d
12.8
図 7 ブロッキング率
信ホストにおける受信ソケットバッファの動的管理割り当て方
式を提案した。提案方式では、Web プロキシサーバの特性で
ある TCP 受信ホストとしてのふるまいを考慮し、受信ソケッ
トバッファの利用率に応じてその割り当てサイズを変更する、
動的な受信ソケットバッファの割り当てを行なう。提案方式の
有効性はシミュレーションによって評価した。その結果、提案
方式を用いることによって、効率的な資源割り当てが可能とな
り、受信ソケットバッファの総量が小さい場合においても、高
い性能および短い転送時間を達成することができることが明ら
かとなった。今後の課題としては、本方式を実プロキシサーバ
へ実装し、実ネットワーク上での性能評価を行うことが挙げら
れる。
文
献
[1] G. Hasegawa, T. Terai, T. Okamoto, and M. Murata,
“Scalable socket buffer tuning for high-performance Web
servers,” in Proceedings of IEEE ICNP 2001, Nov. 2001.
[2] Proxy Survey, available at http: // www. delegate. org/
survey/ proxy. cgi .
[3] T. Okamoto, T. Terai, G. Hasegawa, and M. Murata, “A
resouorce/connection management scheme for HTTP proxy
servers,” in Proceedings of Second International IFIP-TC6
Networking Conference, pp. 252–263, May 2002.
[4] A. Feldmann, R. Caceres, F. Douglis, G. Glass, and M. Rabinovich, “Performance of Web proxy caching in heterogeneous bandwidth environments,” in Proceedings of IEEE
INFOCOM ’99, pp. 107–116, 1999.
[5] G. Hasegawa, T. Matsuo, M. Murata, and H. Miyahara,
“Comparisons of packet scheduling algorithms for fair service among connections on the internet,” in Proceedings of
IEEE INFOCOM 2000, Mar. 2000.
[6] M. K. McKusick, K. Bostic, M. J. Karels, and J. S. Quarterman, The Design and Implementation of the 4.4 BSD Operating System. Reading, Massachusetts: Addison-Wesley,
1999.
[7] M. Allman, “A Web server’s view of the transport layer,”
ACM Computer Communication Review, vol. 30, pp. 10–20,
Oct. 2000.
[8] W. Stevens, “TCP slow start, congestion avoidance, fastretransmit, and fast recovery algorithms,” Request for Comments (RFC) 2001, Jan. 1997.
[9] The VINT Project, “UCB/LBNL/VINT network simulator
- ns (version 2).” available at http://www.isi.edu/nsnam/
ns/.
[10] P. Barford and M. Crovella, “Generating representative
Web workloads for network and server performance evaluation,” in Proceedings of the 1998 ACM SIGMETRICS
International Conference on Measurement and Modeling of
Computer Systems, pp. 151–160, July 1998.
本稿では、Web プロキシサーバの特性を考慮した、TCP 受
—6—