シンクライアントトラヒックの性能向上のための 遅延解析と - 村田研究室

社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS
信学技報
TECHNICAL REPORT OF IEICE.
シンクライアントトラヒックの性能向上のための
遅延解析と TCP 層最適化
小川祐紀雄†
長谷川
剛††
村田 正幸†††
† 日立製作所 システム開発研究所 〒 215–0013 神奈川県川崎市麻生区王禅寺 1099
†† 大阪大学 サイバーメディアセンター 〒 560–0043 大阪府豊中市待兼山町 1–32
††† 大阪大学 大学院情報科学研究科 〒 565–0871 大阪府吹田市山田丘 1–5
E-mail: [email protected], [email protected], [email protected]
あらまし シンクライアントシステムとは,本稿では,クライアントからキーボード・マウスイベントを送信し,サー
バから画面情報を受信するシステムを指す.本稿においては,シンクライアントシステムで発生するトラヒックを,文
字情報に相当するインタラクティブデータフローと,ウィンドウなどの画面情報に相当するバルクデータフローから
なる二状態系で把握し,利用者の操作性能を向上させるために,通信全体の性能を維持しつつ前者の遅延を最小化す
ることを目的とする.実システムから抽出したトラヒックを用いてシミュレーションを行い,インタラクティブデー
タフローの遅延の要因は,ボトルネックリンクに接続するルータでのキューイング遅延と,サーバの TCP 送信バッ
ファにおける送信遅延であることを示す.さらに,インタラクティブデータフローの優先制御を行い,かつ,バルク
データフローの再送タイムアウトの発生を抑制する手法を提案し,各データフローが TCP コネクションを共有する
場合と個別に持つ場合それぞれにおいて,遅延が改善されることを示す.
キーワード シンクライアント,インタラクティブ,バルク,二状態系,優先制御,再送タイムアウト
Delay Analysis and Transport-Layer Optimization
for Improving Performance of Thin-Client Traffic
Yukio OGAWA† , Go HASEGAWA†† , and Masayuki MURATA†††
† Systems Development Laboratory, Hitachi, Ltd.
Ohzenji 1099, Asao-ku, Kawasaki-shi, Kanagawa 215–0013 Japan
†† Cyber Media Center, Osaka University Machikaneyama 1–32, Toyonaka-shi, Osaka 560–0043 Japan
††† Graduate School of Information Science and Technology, Osaka University
Yamadaoka 1–5, Suita-shi, Osaka 565–0871 Japan
E-mail: [email protected], [email protected], [email protected]
Abstract Thin-client system is a system in which a client transmits a user event such as a mouse or keyboard
input to a server and the server returns screen updates of a desktop application to the client. Network traffic in a
thin-client system, that is, thin client traffic, is recognized by using two state system, that is consist of interactive
data flows and bulk data flows. The interactive data flows mainly transfer character information, and the bulk data
flows transfer screen update information. Our purpose is to minimize the latency time of the interactive data flows
as well as to keep the performance of whole data flows in order to improve user’s operation performance. We run
the traffic simulation using the real field data, and show that the latency time of an interactive data flow is almost
the sum of queuing delay at the router connecting to the bottleneck link and TCP’s transmit delay at the server.
We propose techniques of priority queuing of the interactive data flows as well as restraining the retransmission time
out of the bulk data flows, and we show the effectiveness of the techniques when the two data flows exist together
in a TCP connection as well as when each data flow has its own TCP connection.
Key words thin client, interactive data, bulk data, two state system, priority queuing, retransmission time out
1. は じ め に
data center
web (proxy) / mail server
シンクライアントシステムとは,クライアント・サーバ型のシ
remote desktop
service
ステムであり,本稿では,サーバのリモートデスクトップサー
server
external
server
(blade PC)
ビスを利用して,データやアプリケーションを持たないクライ
screen
updates
アントからキーボードやマウスのイベント情報をサーバに送信
し,サーバから処理結果を表す画面情報を受信する画面転送型
intranet
のシステムを指す(図 1).データセンタに PC を集約し,オ
Internet
fire wall
/ VPN gateway
フィスや自宅などからネットワーク経由で PC に接続しデスク
トップ環境を利用する形態で企業などに導入されている.デー
タや計算資源と利用者を分離することにより,コンピュータ資
keyboard
/ mouse
events
thin client
home
源の集中管理,PC の盗難や紛失による情報漏洩リスクの低減,
柔軟なサテライトオフィス勤務や在宅勤務などの就業形態を実
現する企業情報システムとして注目されている [1].
office
mobile
VPN: Virtual Private Network
図 1 シンクライアントシステムの構成
シンクライアントシステムを実現するアプリケーションプロ
トコルには,X11 [2],Citrix R Independent Computing Ar-
chitecture(ICA)[3],Microsoft R Remote Desktop Protocol
(RDP) [4] などがある.シンクライアント通信は,持続的接続
(persistent connection)を用いる対話型の TCP(Transmis-
sion Control Protocol)通信であり,クライアントからの要求
に対して,文字情報やウィンドウ画面情報などの様々な大きさ
のデータを即時に返す.従来,シンクライアントシステムで発
生するトラヒック(シンクライアントトラヒック)に関して,
代表的なアプリケーションソフトの操作時における性能評価結
果が報告されており,広域ネットワーク環境での利用時などに,
ネットワーク遅延が問題になることが指摘されている [5], [6].
また,即時に処理結果を返す必要のあるアプリケーションプ
ロトコルにおいて,TCP の Nagle アルゴリズムと遅延 ACK
(delayed acknowledgement)に起因するデータのバッファリン
グが性能に影響を与えることが報告されている [7], [8].例えば,
X11 では,利用者の操作性能を向上させるために小さなデータ
を遅延なく転送することが必要であり,これらの設定をオフに
する必要がある [9].
また,持続的接続を用いる TCP に HTTP(Hypertext Trans-
fer Protocol)/ 1.1 がある [10], [11].この HTTP において,
TCP のスロースタート再スタート(slow-start restart)によ
り,アイドル時間後に輻輳ウィンドウサイズが初期化されるた
め,転送性能が向上しないことが示されている [12], [13].
また,転送データサイズの異なる複数の TCP フローが競合
し不公平が発生することも報告されている.インターネット
通信の大半はウェブサイト閲覧などのための小さなサイズの
データフローであるが,それらは,少数の大きなサイズのバル
クデータフローのためにキューイング遅延やパケットロスを起
ロー)と,マウス入力に対するウィンドウ画面情報出力などに
相当するよりバルク転送的な特性のデータフロー(バルクデー
タフロー)が一コネクション中に混在したトラヒックと捉えら
れる.我々のこれまでの研究において,それぞれのデータフ
ローに対してパケットロスに対する耐性向上を課題に検討を行
い,前者のフローに対してはパケットの複製を送信することに
より,後者のフローに対してデータセグメントの再構成を行う
ことにより,課題を解決できることを示した [17], [18].
本報告では,さらに,これらのデータフローの競合状態を対
象に検討を行う.利用者はキーボード入力に対する文字情報出
力の遅延に対してより敏感であるため,利用者の操作性能の向
上のために,トラヒック全体としての性能を維持しつつインタ
ラクティブデータフローの遅延を最小化することを目的とする.
実トラヒックから抽出した評価用データを用いてシミュレー
ションを実施し,インタラクティブデータフローの遅延は,ボ
トルネックリンクに接続するルータでのキューイング遅延と,
サーバの TCP 送信バッファにおける送信遅延に起因すること
を示す.さらに,それらの改善のために,従来手法のルータで
の優先制御に加え,TCP の再送タイムアウト発生を抑制する
手法を提案する.また,TCP 送信バッファでの遅延の根本的
な原因は,両データフローが一コネクション中に共存すること
であるため,各データフローが TCP コネクションを共有する
場合と個別に持つ場合に分けて評価を行う.
以下,2 章ではシンクライアントトラヒックのモデル化手法
ついて説明する.3 章でインタラクティブデータフローの性能
劣化の要因をシミュレーションによって明らかにし,4 章にお
いて性能向上手法を提案しその評価結果を示す.最後に 5 章で
本稿のまとめと今後の課題を述べる.
こすことがあり,DiffServ(Differentiated Services)や RED
(Random Early Detection)などの適用によりこれらの問題を
解決する手法が示されている [14]∼[16].
以上の関連研究を踏まえ,シンクライアントトラヒックの性
能向上手法を検討する.シンクライアントトラヒックは,キー
ボード入力に対する文字情報出力などに相当するよりインタ
ラクティブな特性のデータフロー(インタラクティブデータフ
2. シンクライアントトラヒックのモデル化
2. 1 二状態系によるモデル化
シンクライアントトラヒックを,図 2 に示すように,文字情
報などに相当するインタラクティブデータフローと,ウィンド
ウ画面情報などに相当するバルクデータフローからなる二状態
100 connections
1-α
α
interactive
data flow
α
bulk
data flow
data center
β
server
(sender host)
100 Mbps, 1 msec
buffer size
= 10000 packets
R
1-β
β
intranet
(WAN)
R
図 2 シンクライアントトラヒックのモデル化
remote office
interactive data flow
bulk data flow
(character information)
(screen update information)
client
server
client
server
R router
図 4 シミュレーションモデル
•~102 packets
•short interval
response
response
large
interval
size of data segment
m ( n MSS + a )
MSS
図3
100 Mbps, 1 msec
client
(receiver host)
request
request
time
10 Mbps, 20 msec
bottleneck link
time
time
エンドでほぼ 100 Mbps である.一評価用トラヒックの条件を,
時間区間が 300 sec,前節で求めた状態遷移確率との差が 0.01
以内,含まれるフロー数が 100 以上とし,これらの条件を満た
time
time
MSS: Maximum Segment Size
インタラクティブ/バルクデータフローの特徴
す約 100 個のトラヒックを抽出した(表 1).
3. インタラクティブデータフローの遅延解析
3. 1 対象システム構成とシミュレーションモデル
表 1 評価用トラヒックの特徴
(一評価用トラヒック(300 秒)あたりの平均値)
サーバに対して同時に多数の通信が行われる場合のシステム
構成として,データセンタからイントラネットを経て多数のシ
interactive data flow
bulk data flow
flows
934
198
ンクライアントが設置された遠隔オフィスに接続する構成を対
packets
934
1,466 (7.4/flow)
象とする.イントラネットには,東京∼大阪間といった数 10
bytes
128,188 (137.2/packet) 1,373,366 (936.8/packet)
msec の遅延のある広域ネットワークを考える.図 1 に示すシ
ンクライアントシステムの構成の特徴により,サーバからメー
系によりモデル化する.図 3 に示すように,インタラクティブ
データフローは,一つの要求パケットと一つの応答パケットの
組からなる.一方,バルクデータフローは,一つの要求パケッ
トと最大 102 個程度の応答パケットとの組からなる.これらの
データフローの識別は,応答パケットの到着間隔を基に行う.
アプリケーションプロトコルに Microsoft
R
RDP を使用した
約 200 台のサーバとクライアントの組からなる試行システムに
対する約一ケ月間のトラヒック観察結果に基づき,応答パケッ
トの到着間隔に関する閾値を 10
−2.2
sec(約 6.3 msec)と設定
する [18].二状態系における状態遷移確率は,上述の観察結果
より,イントラネットからの接続では α = 0.91,β = 0.58,イ
ンターネットからの接続では α = 0.94,β = 0.59 であった.
これらの値の違いは,各状況で利用するアプリケーションソフ
トの違いなどによると考えられる.
2. 2 評価用トラヒックの抽出
次章以降で実施するシミュレーションのための評価用トラ
ヒックとして,個々の評価用トラヒックがシンクライアントト
ラヒックの平均的な特徴を備えるよう,各トラヒック中のイン
タラクティブ/バルクデータフローの状態遷移確率が前節で求
めた値に近いトラヒックを選ぶ.また,実トラヒックから抽出
する際には,遅延と帯域の影響の少ない,イントラネット経由
で接続したトラヒックを用いる.このとき,大半は同一拠点内
からの接続であり,遅延は 1 msec 以下,帯域はエンド・ツー・
ル・ウェブサーバなどの業務サーバへの通信は,基本的にデー
タセンタ内で閉じており,広域ネットワークを転送されるトラ
ヒックはほぼシンクライアントトラヒックのみである.以上の
構成を図 4 に示すモデルで表す.サーバ(送信ホスト)とクラ
イアント(受信ホスト)を 100 組とし,これらの 100 コネク
ションが同時に通信する.各ホストから広域ネットワーク(ボ
トルネックリンク)に接続するルータまでの回線の帯域を 100
Mbps,伝播遅延時間を 1 msec,広域ネットワークでは,帯域
を 10 Mbps,伝播遅延時間を 20 msec に設定する.ルータの
バッファサイズは,パケットドロップが発生しない十分大きな
値とする.サーバおよびクライアントの設定は,即時に応答を
返信するために Nagle アルゴリズムと遅延 ACK の設定はオフ
に設定し,スループット向上のためにスロースタート再スター
トもオフに設定する [18].
3. 2 インタラクティブデータフローの遅延発生箇所の解析
サーバのアプリケーションが送信してからクライアントのア
プリケーションが受信するまでのエンド・ツー・エンドの遅延
において,回線の伝送遅延以外の遅延要因を以下に挙げる.な
お,各ノードでのパケット処理遅延は除いている.
•
サーバでの遅延 − TCP 送信バッファにおけるバッファ
リング遅延,送信遅延
•
ルータでの遅延 − キューイング遅延,送信遅延
•
クライアントでの遅延 − TCP 受信バッファにおける
バッファリング遅延
all flows
0
router
interactive data flows
0
end-to-end
bulk data flows
0
end-to-end
-1
router
router
-1
-1
end-to-end
server
-2
-3
-4
-2
server
-3
-4
-5
-4
-3
-2
-1
delay time (log10 sec)
(a) トラヒック全体
-2
-3
-4
RTO: 5.40 / connection
Dup. ACK: 0.14 / connection
-5
-6
P [X>x] (log10)
P [X>x] (log10)
P [X>x] (log10)
server
RTO: 4.85 / connection
Dup. ACK: 0.06 / connection
0
1
-5
-6
-5
-4
RTO: 0.55 / connection
Dup. ACK: 0.08 / connection
-3
-2
-1
delay time (log10 sec)
0
-5
-6
1
-5
(b) インタラクティブデータフローのみ
-4
-3
-2
-1
delay time (log10 sec)
0
1
(c) バルクデータフローのみ
トドロップなどによってパケットの順序が入れ替わって受信さ
れない限りは発生しないため,本報告では改善対象としない.
図 5 に,ns-2 [19] によりシミュレーションを行った結果を示
す.トラヒック全体,インタラクティブデータフローのみ,バ
server (app) send
server (TCP) send
congestion
widow size
server (TCP) receive
ルクデータフローのみに分けて,エンド・ツー・エンド,サー
time (sec)
について,パケット毎の遅延時間の累積補分布(CCDF: Com-
plementary. Cumulative Distribution Function)を示してい
る.グラフにコネクション当たりの再送タイムアウト(RTO:
Retransmission Time Out)と重複 ACK(duplicate ACK)の
RTO, srtt, rttvar (sec)
バ,ボトルネックリンク接続ルータ,クライアントでの各遅延
router queue length
RTO
rtt
srtt
rttvar
発生回数(輻輳ウィンドウサイズ(congestion window size)
time (sec)
の縮小回数)を追記している.図 5(b) に示されるように,イ
ンタラクティブデータフローのエンド・ツー・エンドでの遅延
router queue length (packets)
頭ブロッキング(head-of-line blocking)と呼ばれる.パケッ
sequence number (bytes)
これらのうち,クライアントでのバッファリング遅延は,行
congestion window size (segments)
図5 遅延分布
図 6 再送タイムアウト発生によるサーバでの遅延の例
の要因は,ボトルネックリンク接続ルータおよびサーバでの遅
延である.インタラクティブデータフローで発生するエンド・
ツー・エンドの遅延に関して約 0.3 sec より小さな遅延が 99.9
%を占め,その部分はルータでの遅延が支配的である.一方,
それ以上の大きな遅延も 0.1 %程度と割合は小さいが存在して
おり,その部分はサーバでの遅延が支配的である.
ズの縮小も発生しているが,これは,複数のパケットが再送タ
イムアウト発生により連続して再送信されると,クライアント
ではオリジナルのパケットの受信後,複数の再送パケットを受
信し,そのつど最大受信シーケンス番号に基づく ACK を返信
するという動作による.
ボトルネックリンク接続ルータでの遅延は,ルータのバッファ
においてパケットの出力速度より入力速度の方が大きく待ち行
列が発生することによる.サーバでの遅延は,TCP 送信バッ
ファからの出力速度よりアプリケーションからの入力速度の方
が大きい場合に発生する.バルクデータフローの TCP 送信バッ
ファへの入力速度は特に大きいためその送信遅延が後続のイン
タラクティブデータフローに及ぶこともある.また,図 6 に例
示するように,ルータのキュー長の時間変化に対して,サーバ
の送信間隔が大きく往復遅延時間(RTT: Round Trip Time)
の測定回数が少ないため,ルータでの遅延時間に対してサーバ
での再送タイムアウト値の再計算が追随せず,ルータでパケッ
ト廃棄が発生していないにも関わらずサーバで再送タイムアウ
トが発生している.このような再送タイムアウトの発生により,
サーバでの輻輳ウィンドウサイズが初期化され送信遅延がさら
に増加する.なお,重複 ACK 受信による輻輳ウィンドウサイ
4. インタラクティブデータフローの性能向上
4. 1 性能向上手法の検討
前章の評価結果より,インタラクティブデータフローの遅延
の最大要因は,ボトルネックリンクに接続するルータでのキュー
イング遅延であることがわかったので,本稿では,ルータでの
優先制御によりインタラクティブデータフローの遅延を減少さ
せる.ルータに各データフロー用のバッファを設け,インタラ
クティブデータフローをバルクデータフロー対して優先して送
信する.各データフローの識別のためのラベル付けは,サーバ
のアプリケーション層で実施する.
上記の優先送信により,インタラクティブデータフローの再
送タイムアウトは発生せず,同フロー自身に起因するサーバで
の遅延は起こりにくいと考えられる.したがって,サーバでの
all flows
bulk data flows
0
end-to-end
-1
server
-2
client
-3
router
router
-1
P [X>x] (log10)
P [X>x] (log10)
interactive data flows
0
end-to-end
router
end-to-end
-1
server
client
P [X>x] (log10)
0
-2
-3
server
-2
-3
client
-4
-4
-4
RTO: 1.00 / connection
Dup. ACK: 1.58 / connection
-5
-6
-5
-4
-3
-2
-1
delay time (log10 sec)
RTO: 0.00 / connection
Dup. ACK: 0.52 / connection
0
-5
-6
1
(a) トラヒック全体
-5
-4
-3
-2
-1
delay time (log10 sec)
RTO: 1.00 / connection
Dup. ACK: 1.06 / connection
0
-5
-6
1
-5
(b) インタラクティブデータフローのみ
-4
-3
-2
-1
delay time (log10 sec)
0
1
0
1
(c) バルクデータフローのみ
図 7 インタラクティブ/バルクデータフローが同一コネクションに共存するときの評価結果
all flows
router
router
router
-1
P [X>x] (log10)
-3
-4
-2
-3
server
-4
-4
-3
-2
-1
delay time (log10 sec)
-2
-3
-4
RTO: 0.30 / connection
Dup. ACK: 0.01 / connection
-5
end-to-end
-1
server
server
-2
-5
-6
bulk data flows
0
end-to-end
-1
P [X>x] (log10)
interactive data flows
0
end-to-end
P [X>x] (log10)
0
RTO: 0.00 / connection
Dup. ACK: 0.00 / connection
0
1
(a) トラヒック全体
-5
-6
-5
-4
-3
-2
-1
delay time (log10 sec)
RTO: 0.30 / connection
Dup. ACK: 0.01 / connection
0
1
-5
-6
-5
(b) インタラクティブデータフローのみ
-4
-3
-2
-1
delay time (log10 sec)
(c) バルクデータフローのみ
図 8 インタラクティブ/バルクデータフローに個別にコネクションを割り当てたときの評価結果
遅延を減少させるためには,バルクデータフローの送信遅延
スタート再スタート発生のタイミングで srtt および rttvar を
が後続のインタラクティブデータフローに影響しないようにす
初期化する.ただし,このとき輻輳ウィンドウサイズは初期化
る必要がある.これは,一つの TCP コネクション中に二つの
しない.さらに,ルータのキュー長の変化に追随するよう,よ
データフローが共存することに根本的な原因があるため,以下
り最近の往復遅延時間を再送タイムアウト値に反映させる.そ
の二つのアプローチに分けて検討を行う.
のため g = 7/8 に設定する.
( 1 ) インタラクティブ/バルクデータフローが一 TCP コ
アプローチ (2) のコネクションを分離し個別に割り当てる場
ネクションに共存(現アプリケーションプロトコル仕様を前提)
合においては,サーバでの送信時にバルクデータフローがイ
( 2 ) インタラクティブ/バルクデータフローの TCP コネ
ンタラクティブデータフローに影響することは無いが,バルク
クションを分離(アプリケーションプロトコルの改変を前提)
データフロー自身の性能を向上させるために,同様に再送タイ
アプローチ (1) においては,バルクデータフローの送信遅延
ムアウト発生の抑制を行う.
を抑えるために輻輳ウィンドウサイズの大きさを保つことが必
4. 2 バルクデータフローと共存する場合の評価
要である.そのため,再送タイムアウト発生の抑制手法を検討
アプローチ (1) の二つのデータフローが一コネクションに共
する.再送タイムアウト値 RT O は次式で計算される [6].
srtt ← (1 − g)srtt + g · rtt
rttvar ← (1 − h)rttvar + h|rtt − srtt|
RT O ← srttt + 4rttvar
(1)
存する場合の制御結果を図 7 に示す.比較のために,図 5 の制
御なしでの分布を点線で示している.
図 7(b) に示すように,インタラクティブデータフローにお
(2)
いて,エンド・ツー・エンドの遅延の大半を占める約 0.3 sec 以
(3)
下の遅延は,ルータでの優先制御に伴い改善される.ただし,
rtt は往復遅延時間,srtt は加重平均した往復時間,rttvar
は加重平均した平均偏差,g ,h は加重平均のパラメータで
g = 1/8,h = 1/4 である.提案方式においては,アイドル時
間後のルータのキュー長の変化に対応するために,アイドル時
間後に再送タイムアウト時間をリセットする.つまり,スロー
代わりにクライアントでの遅延が発生している.これは,ルー
タでの優先制御により先に送信されたバルクデータフローのパ
ケットを追い越すことがあり,行頭ブロッキングが発生するか
らである.サーバでの遅延も若干改善されているが,これは,
バルクデータフローの再送タイムアウト発生を抑制しているか
らであり(優先制御のみの適用時は,フロー全体での再送タイ
ト値のアイドル時間後の初期化や計算パラメータ変更により再
ムアウト発生回数は 2.87 回/コネクション),再送タイムアウ
送タイムアウト発生を抑制することで実現できることを示した.
ト発生抑制手法を適用しないとサーバでの遅延は悪化する.
一方,インタラクティブデータフローの遅延からバルクデータ
バルクデータフローの遅延は,図 7(c) に示すように,制御の
フローの影響を完全に除くためには,アプリケーションプロト
適用後も維持されている.ルータでの遅延は,非優先であって
コルを改変しコネクションを分離することが必要であることも
もインタラクティブデータフローのデータサイズが小さいため
示した.今後の課題としては,ルータのバッファサイズが十分
大きな遅延の増加とはならない.サーバでの遅延も,再送タイ
に大きくない場合の評価と制御方式の検討などが挙げられる.
ムアウト発生の抑制により改善されている.なお,行頭ブロッ
キング(クライアントでの遅延)が発生しているのは,TCP 送
信バッファからの送信時にバルクデータフローのセグメントが
先行するインタラクティブデータフローのセグメントと再構成
されて一つのセグメントとなり,ルータで優先送信され追い越
しが発生したためである.
4. 3 バルクデータフローと分離した場合の評価
アプローチ (2) の二つのデータフローに対してそれぞれ個別
にコネクションを割り当てた場合の制御結果を図 8 に示す.こ
のとき,クライアント側アプリケーションは,もともとの一コ
ネクション時の各データフロー間のパケットの順序を維持しな
くてもよいとする.
インタラクティブデータフローの遅延は,図 8(b) に示すよ
うに,ほぼ回線の伝送遅延のみである.バルクデータフローと
コネクションを分離したことにより,ルータでのパケットの追
い越しは発生せず,したがって,クライアントでの遅延は発生
しない.サーバにおいてバルクデータフローの送信遅延の影響
を受けることもない.
バルクデータフローの遅延は,図 8(c) に示すように,制御
前の値を維持している.ルータでの遅延が増加するのは,イン
タラクティブデータフローに対して非優先で転送されることに
加えて,再送タイムアウト回数が減少し輻輳ウィンドウサイズ
が縮小せず,バースト性が増加することによる.サーバでの遅
延は,再送タイムアウト発生の抑制により改善されている.
5. お わ り に
本稿では,シンクライアントトラヒック全体の通信性能を維
持しつつインタラクティブデータフローの遅延を最小化する
TCP 層の制御方式について検討した.実トラヒックを用いて
シミュレーションを行い,インタラクティブデータフローの遅
延の大半はボトルネックリンク(広域ネットワーク)に接続す
るルータでのキューイング遅延であるが,その他にサーバでの
TCP 送信バッファにおける遅延も存在することを示した.この
サーバでの遅延には再送タイムアウト発生が影響している.実
際に広域ネットワークを利用する場合は,アプリケーションプ
ロトコルの設定を変更しデータサイズを減らすことが考えられ
るので,バースト性が緩和され再送タイムアウト発生回数は少
なくなると考えられるものの,本稿のシステム構成に近い条件
下では再送タイムアウトが発生する可能性が高いと予想される.
現在のプロトコルの仕様のようにインタラクティブデータ
フローがバルクデータフローとコネクションを共有する場合,
サーバでの遅延をより小さくするためには輻輳ウィンドウサイ
ズを大きく保つことが必要である.本稿では,再送タイムアウ
文
献
[1] 新井, 溝口, “モバイルセキュリティを強化したシンクライアン
トソリューション”, 情報処理, vol. 47, no. 10, pp. 1127–1136,
October 2006.
[2] R. W. Scheifler and J. Gettys: X Window System: Core
and Extension Protocols : X Version 11, Releases 6 and
6.1, Butterworth-Heinemann, 1997.
[3] Citrix Systems, http://www.citrix.com/
[4] MSDN library, “Understanding the Remote Desktop Protocol (RDP) ”, http://support.microsoft.com/kb/186607
[5] A. Lai and J. Nieh: “On the Performance of Wide-Area
Thin-Client Computing”, ACM Transactions on Computer
Systems, vol. 24, no. 2, pp. 175-209, May 2006.
[6] N. Tolia, D. G. Andersen and M. Satyanarayanan: “Quantifying Interactive User Experience on Thin Clients”, IEEE
Computer Society Press Computer, vol. 39, no 3, pp. 46-52,
March 2006.
[7] G. Minshall, Y. Saito, J. Mogul, and B. Verghese: “Application performance pitfalls and TCP’s Nagle algorithm”, in
Proc. of 2nd Workshop on Internet Server Performance,
pp. 36-44, May 1999.
[8] J. C. Mogul and G. Minshall: “Rethinking the TCP Nagle
algorithm”, ACM SIGCOMM Computer Communication
Review, vol.31, no. 1, pp. 6-20, January 2001.
[9] W. R. Stevens: TCP/IP Illustrated, Volume 1: The Protocols, Addison-Wesley, 1994.
[10] J. C. Mogul: “The case for persistent-connection HTTP”,
ACM SIGCOMM Computer Communication Review, vol.
25, no. 4, pp. 299-313, October 1995.
[11] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,
P. Leach and T. Berners-Lee: “Hypertext Transfer Protocol
– HTTP/1.1”, RFC 2616, June 1999.
[12] J. Heidemann: “Performance Interactions Between PHTTP and TCP Implementations”, ACM SIGCOMM
Computer Communication Review, vol. 27, no. 2, pp. 6573, April 1997.
[13] J. Heidemann, K. Obraczka and J. Touch: “Modeling the
Performance of HTTP Over Several Transport Protocols”,
ACM/IEEE Transactions on Networking, vol. 5, no. 5, pp.
616-630, October 1997.
[14] X. Chen and J. Heidemann: “Preferential Treatment for
Short Flows to Reduce Web Latency”, Computer Networks,
vol. 41, no. 6, pp. 779-794, April 2003.
[15] L. Guo and I. Matta: “The War Between Mice and Elephants”, Technical Report BU-CS-2001-005, May 2001.
[16] K. Tokuda, G. Hasegawa and M. Murata: “Analysis and Improvement of the Fairness between Long-/Short-lived TCP
Connections”, in Proc. of IFIP/IEEE PfHSN 2002, April
2002.
[17] 小川, 長谷川, 村田, “シンクライアントトラヒックの性能向上手
法の検討”, 電子情報通信学会情報ネットワーク研究会 (口頭発
表), March 2007.
[18] Y. Ogawa, G. Hasegawa and M. Murata: “Transport-layer
optimization for thin-client systems”, in Proc. of CQR 2007
Workshop, May 2007.
[19] The VINT Project, “The Network Simulator - ns-2”,
available from http://www.isi.edu/nsnam/ns/.