瘦客戶計算體系結構研究

摘要：介紹了瘦客戶計算體系結構及目前廣泛使用的四種具體實現(xiàn)，并對影響瘦客戶計算平臺性能的主要因素進行了分析。在此基礎上給出了瘦客戶計算平臺的設計和研究方向。

關鍵詞：瘦客戶計算;遠程顯示協(xié)議;體系結構

中圖分類號：TP391文獻標志碼：A

文章編號：1001－3695(2007)05－0071－03

以大型機為主的計算中心時代，通過終端設備使用計算中心的各種應用和計算資源是當時的典型應用模式。因PC機成本的降低及用戶對使用中心計算模式所受各種限制的反感，致使大多數(shù)用戶采用PC機來完成計算任務。但網(wǎng)絡技術的飛速發(fā)展和應用軟件種類的增多及復雜程度不斷提高，讓用戶維護自己的計算環(huán)境成為具有挑戰(zhàn)性的工作，特別是針對安全性要求較高的企業(yè)應用環(huán)境。而以網(wǎng)絡通信技術為基礎，以服務器計算為中心，采用瘦客戶/服務器計算模式的瘦客戶計算，恰好能夠解決這一問題。

瘦客戶計算這一網(wǎng)絡計算模式的特點是：應用程序和數(shù)據(jù)都運行并存儲在服務器端，客戶端只剩下顯示和輸入設備，不進行復雜計算，因而對瘦客戶機的硬件要求很低。它可以是簡單的計算設備，如PDA(個人數(shù)字助手)，也可以是低端計算機或一些特殊設計的終端。

1瘦客戶計算體系結構

如圖1所示，瘦客戶計算體系結構模型由三部分構成：①瘦客戶機，客戶端的計算設備，主要負責顯示用戶界面和客戶端輸入；②遠程顯示協(xié)議（瘦客戶協(xié)議），用于在瘦客戶機與應用服務器之間傳送應用程序輸入/輸出信息的應用層協(xié)議，③應用服務器，高性能的計算機，應用程序的安裝、運行、維護、升級都在其上進行，用戶的個人配置文件也保存在應用服務器上。瘦客戶計算體系結構中的關鍵技術是遠程顯示協(xié)議，它是瘦客戶機和服務器上的應用系統(tǒng)之間進行交互的機制，它使得通過網(wǎng)絡為客戶設備提供圖形顯示等服務成為可能。

1．1瘦客戶計算的具體實現(xiàn)

1．1．1虛擬網(wǎng)絡計算 

虛擬網(wǎng)絡計算（Virtual Network Computing，VNC）的計算體系結構由三部分組成，即VNC服務器、RFB協(xié)議和VNC 瀏覽器。在用戶使用VNC客戶端連接到運行VNC服務器上時，通過鍵盤和鼠標動作來執(zhí)行存放在服務器上的應用程序。服務器桌面的快照被壓縮且通過RFB協(xié)議發(fā)送到客戶端?？蛻舳伺c服務器之間的通信是通過架構在TCP/IP上的RFB協(xié)議來實現(xiàn)的。

遠程幀緩沖協(xié)議（Remote Frame Buffers，RFB）是一個遠程存取圖形用戶界面的簡單協(xié)議。它工作在幀緩存級，能被用于所有的有關窗口操作的系統(tǒng)和應用程序中，具有優(yōu)秀的平臺獨立性。協(xié)議的顯示部分基于一個單獨的繪圖源語：存放矩形像素塊數(shù)據(jù)在已給坐標位置上。一系列的塊操作組成一次相應的幀更新。雖然這種像素塊的貼操作效率較低，但可以通過多種像素編碼壓縮方式來實現(xiàn)網(wǎng)絡帶寬、客戶端顯示速度及服務器處理速度之間的效率折中，以實現(xiàn)高效率的圖形顯示。

1．1．2微軟終端服務

微軟Windows終端計算體系結構由三部分組成，即服務器多用戶操作系統(tǒng)內核、遠程桌面協(xié)議（Remote Desktop Protocol，RDP）和基于窗口的痩客戶端軟件。服務器多用戶操作系統(tǒng)內核提供了在服務器上同時運行多個客戶會話的能力，且所有基于窗口的管理機制和技術都可用來管理終端桌面，它完全獨立于終端服務協(xié)議，使它既能運行于RDP協(xié)議上，也可以運行在第三方協(xié)議，如Citrix的ICA協(xié)議上。

RDP是微軟根據(jù)ITU (國際電信聯(lián)盟)的T.120協(xié)議族制定的終端服務器與客戶端之間的數(shù)據(jù)通信協(xié)議。作為一個多虛擬通道協(xié)議，RDP可以在不同的虛擬通道中傳輸Windows應用系統(tǒng)界面輸出數(shù)據(jù)、鍵盤和鼠標操作輸入數(shù)據(jù)等。RDP支持多點數(shù)據(jù)傳輸。數(shù)據(jù)從一個應用程序實時地傳輸?shù)蕉鄠€目的地，而無須為每個會話單獨地發(fā)送同樣的數(shù)據(jù)。

1．1．3Citrix的MetaFrame

Citrix的MetaFrame主要運行在Windows平臺上。它的計算體系結構有三個基本組成部分：應用服務器軟件（MetaFrame）、ICA網(wǎng)絡協(xié)議、ICA客戶端軟件。MetaFrame 中使用的MultiWin 技術允許多個用戶在不同的客戶端平臺上，同時訪問和運行服務器上的某個應用軟件?？蛻舳嗽O備上的ICA軟件用于接收顯示圖像，同時向服務器發(fā)送鼠標移動和鍵盤擊鍵動作的信息。

獨立計算體系結構（Independent Computing Architecture，ICA）是Citrix公司的窗口顯示協(xié)議。它能在服務器上模擬本地應用程序處理的多用戶層。多用戶層上的ICA顯示服務可將應用程序的執(zhí)行和顯示邏輯分離開來，使得應用程序可以100%地在服務器上執(zhí)行，并通過標準的網(wǎng)絡傳輸協(xié)議TCP/IP和IPX等把用戶界面?zhèn)魉偷娇蛻舳?。?/p>

1．1．4Tarantella Enterprise

Tarantella通過三層體系結構將傳統(tǒng)的非Web化的應用轉變?yōu)閃eb應用。第二層Tarantella服務器，是整個系統(tǒng)的核心。通過Tarantella服務器，各種不同平臺類型的應用服務器能夠同時為瘦客戶端提供服務，以實現(xiàn)企業(yè)應用的集中式管理。

適應性因特網(wǎng)協(xié)議 (Adaptive Internet Protocol，AIP) 運行于Tarantella服務器上的協(xié)議引擎和客戶端設備上的顯示引擎之間，是Tarantella客戶端與服務器之間的通信協(xié)議。AIP采用智能啟發(fā)式機制不斷地監(jiān)控、測量和適應應用程序與客戶端設備、數(shù)據(jù)傳輸?shù)木€路情況，以優(yōu)化網(wǎng)絡響應。Tarantella的監(jiān)視器經(jīng)常發(fā)送關于客戶端設備性能、網(wǎng)絡響應時間和帶寬等的反饋信息。該反饋信息將限定協(xié)議引擎運行和客戶端設備執(zhí)行操作的數(shù)量。協(xié)議引擎將各種需求按級別進行分類并自動進行優(yōu)化調整。例如AIP可以區(qū)別交互式和流式的應用，以對它們采用不同的優(yōu)化機制。AIP、協(xié)議引擎與顯示引擎、智能緩存等特性為遠程用戶提供良好的性能。

1．2瘦客戶計算平臺性能

在瘦客戶平臺的基本框架內，瘦客戶計算的具體實現(xiàn)有很多種設計選擇，不同的選擇會使平臺的性能具有明顯差異。評價瘦客戶平臺性能的主要指標是客戶端請求的平均等待時間和客戶端顯示圖像的質量等。要分析影響瘦客戶平臺性能的主要因素，需要測試不同設置下平臺在不同網(wǎng)絡環(huán)境下的網(wǎng)絡和視頻性能。在網(wǎng)絡性能方面，主要測試網(wǎng)頁從服務器端到客戶端的平均等待時間和數(shù)據(jù)傳輸量；在視頻性能方面，它主要測試視頻質量（即客戶端顯示質量）和傳送的數(shù)據(jù)量。為定量的描述視頻質量，采用慢速播放技術并使用式（1）來計算。 

2影響平臺性能的主要因素

測試結果表明，影響瘦客戶平臺性能的主要因素是顯示編碼源語、屏幕更新機制和緩存與壓縮。以下就不同平臺所使用不同設計選擇分析對平臺性能的影響。

2．1顯示編碼源語

顯示編碼源語分為基于像素和基于圖形的繪圖源語。使用基于像素的顯示編碼的瘦客戶平臺，顯示更新在服務器端處理，送到客戶端的僅是需要顯示的像素數(shù)據(jù)。其平臺獨立性好、客戶端計算簡單?；趫D形的顯示編碼，與操作系統(tǒng)的窗口操作和顯示命令聯(lián)系緊密，負責處理更新的顯示命令和需要顯示的屏幕數(shù)據(jù)一同從服務器傳送到客戶機，在客戶端處理顯示更新。其平臺獨立性較差、客戶端計算復雜。像素源語能使系統(tǒng)顯示像素區(qū)域的所有更新。它不需要任何有關顯示內容的語義信息。圖形源語，如字形，用于系統(tǒng)從圖像中分離要顯示的字形。

VNC采用基于像素的顯示編碼。其協(xié)議RFB支持2D繪圖源語，如對文本窗口的屏幕區(qū)域，采用單色或雙色的位圖填充。RFB也可設置為僅使用Raw像素編碼，但在默認情況下不采用該編碼。Citrix的MetaFrame、微軟的終端服務和Tarantella采用基于圖形的顯示編碼。其協(xié)議ICA、RDP和AIP支持字形、圖標、圖像和繪圖命令等繪圖源語。

在單獨測試協(xié)議編碼源語對系統(tǒng)的性能影響時（AIP無法關掉高速緩存的選項；RFB無法關掉顯示壓縮），在100 Mbps帶寬網(wǎng)絡環(huán)境，網(wǎng)絡性能測試中，傳輸內容相同的情況下，AIP響應時間最短，其次是采用2D繪圖原語的RFB，而ICA和RDP則具有相同的延遲時間且響應時間最長。在傳送數(shù)據(jù)量方面，如果傳輸相同內容的文本圖像混合網(wǎng)頁，RFB傳輸?shù)臄?shù)據(jù)量最少；AIP、ICA和RDP傳輸?shù)臄?shù)據(jù)量相同且大于RFB。如果是傳輸相同內容的純文本網(wǎng)頁，則RDP和ICA傳輸?shù)臄?shù)據(jù)量最小，AIP次之，RFB最大。由此可見，采用基于圖形的顯示編碼在傳送純文本時比RFB的帶寬效率高。

2．2顯示更新機制

顯示更新機制包括更新時機（Timing of Display Updates）及刷新模式。更新時機有客戶端拉動（Client－pull）和服務器端推動（Server－push）兩種；每種技術又可采用兩種刷新模式，即懶惰更新（Lazy Update）和急切更新（Eager Update）中的一種。客戶端拉動是一種由客戶端驅動的顯示更新技術，由客戶端決定屏幕更新的時機。服務器并不將每次更新都發(fā)送給客戶，只有收到來自客戶機的請求時，才將最近的顯示更新發(fā)送出去。服務器端推動是由服務器驅動的顯示更新技術，由服務器決定屏幕更新的時機。它需要根據(jù)刷新模式來確定何時發(fā)送屏幕更新給客戶。急切模式是當服務器上的應用程序產生繪圖命令時，瘦客戶系統(tǒng)立即將命令轉換為基本的顯示編碼源語并把顯示刷新數(shù)據(jù)發(fā)送到客戶端，它使服務器能跟上應用程序的翻譯命令。懶惰刷新模式是將若干翻譯命令首先緩沖，然后再需要時懶惰地發(fā)送合并的顯示刷新到客戶端。對于實時視頻顯示，懶惰顯示刷新模式導致許多視頻幀在服務器端被合并和覆蓋，使發(fā)送刷新的頻率降低。它雖然能減少數(shù)據(jù)量的傳輸，但影響了系統(tǒng)的視頻性能。

在RFB中采用客戶端拉動的懶惰更新模式。當客戶端請求時，更新被懶惰地發(fā)送。但常常由于客戶運行的VNC已被大量地加載，客戶端變成申請顯示刷新的瓶頸，導致在客戶機端產生下一個更新請求前，服務器端已將那些被合并和覆蓋的視頻丟失了，所以其視頻播放的性能較差。Citrix的MetaFrame和微軟的終端服務依賴于服務器推動的懶惰更新模式。它比RFB的視頻性能要好一些，不會在客戶端產生顯示刷新的瓶頸，但仍然會放棄或者融合服務器端的顯示。AIP使用服務器推動技術，刷新模式則能根據(jù)帶寬情況在急切和懶惰中進行智能選擇。它在100 Mbps的視頻性能測試中表現(xiàn)很好，尤其對于多媒體視頻應用程序。AIP使用懶惰模式來適應較低的帶寬。

在100 Mbps網(wǎng)絡環(huán)境中。RDP、ICA和RFB傳送低質量視頻，相比之下ICA、RDP要比RFB好一些，而AIP能傳送超過90％的視頻質量（可由式（1）計算），但在10 Mbps降到僅有大約50%的視頻質量。傳送的數(shù)據(jù)量從大到小依次為AIP、RDP、ICA和RFB。

2．3壓縮編碼和緩存

壓縮編碼不僅影響服務器將屏幕更新傳送到客戶端時的數(shù)據(jù)量，還決定了將屏幕更新數(shù)據(jù)呈遞給客戶端的顯示引擎設計的簡繁程度。好的壓縮編碼壓縮比高，網(wǎng)絡帶寬要求低，且客戶端能用簡單的顯示引擎快速高效地顯示出來，響應時間短?？蛻舳司彺嬗脕肀４娼?jīng)常使用的顯示元素，如字體和位圖等，使得假如當前所需顯示的元素在緩存中，客戶端就可從緩存中獲得，而不必重復向服務器端發(fā)送請求獲得。在高帶寬下，網(wǎng)絡不是瓶頸，此時使用緩存會造成一些附加的計算，影響平臺性能。在較低帶寬下，性能與數(shù)據(jù)傳輸量有直接關系，緩存和好的壓縮算法有利于提高性能。

RFB主要采用二維運動步長編碼（2D RLE）的變種，如Copy Rectangle、RRE (Rise－and－Run－Length)、CoRRE (Compact RRE)和 Hextile等，缺省時使用Hextile編碼。雖然RFB中壓縮編碼算法壓縮比不是很高，但由于算法簡單，故對客戶端的圖形顯示引擎設計要求較低，客戶端程序很簡單，這使得VNC成為真正的瘦客戶系統(tǒng)。RFB采用本地幀緩沖，如果需要顯示的某一部分數(shù)據(jù)在當前緩沖中，客戶端只需將其拷貝到屏幕上所需的區(qū)域，而無須發(fā)送請求給服務器。但由于RFB僅保留當前顯示的數(shù)據(jù)，沒有提供足夠的歷史記錄，對減少數(shù)據(jù)量的傳輸效果不大。如果僅在屏幕中移動窗口或滾動窗口內的內容時，RFB具有一定的優(yōu)勢。ICA和RDP都使用運行步長（RLE）編碼壓縮；字體和小的位圖保存在客戶端緩存中，大的位圖保存到客戶端磁盤中。AIP使用了RLE和LZW編碼壓縮，并且使用一種自適應機制來應付網(wǎng)絡帶寬的變化，在高帶寬時關閉壓縮，在低帶寬時打開。AIP在客戶端使用顯示對象緩存。

RFB在壓縮純文本數(shù)據(jù)時，可以壓縮到原數(shù)據(jù)量的3%；而在壓縮圖像數(shù)據(jù)和視頻數(shù)據(jù)時，這個比例分別為6%和30%。ICA在壓縮純文本數(shù)據(jù)時，可壓縮到原數(shù)據(jù)的30% ;而在壓縮圖像和視頻數(shù)據(jù)時，壓縮比分別可以達到45%和68%。RDP在壓縮純文本數(shù)據(jù)和圖像數(shù)據(jù)時，可將數(shù)據(jù)量壓縮到原來的40% ；在壓縮視頻數(shù)據(jù)時，壓縮比可達58%。對于視頻數(shù)據(jù)而言，ICA壓縮后的視頻質量會降低近一半，而RDP壓縮后的視頻質量幾乎不變。對于AIP，壓縮時視頻質量從高于90％降到不足30％。AIP不能單獨設置壓縮，當壓縮被打開時，緩存也同時被打開。在100 Mbps帶寬下，其等待時間增加了13%，這主要是由緩存的額外開銷所影響的。

在100 Mbps帶寬下，RFB和RDP使用緩存在等待時間、數(shù)據(jù)傳輸量和視頻性能上幾乎沒有什么影響。ICA的高速緩存使平均網(wǎng)頁等待時間增長了40％。這說明在高帶寬網(wǎng)絡環(huán)境中ICA緩存的額外開銷超過它的好處。但ICA的緩存機制卻減少了數(shù)據(jù)量的傳輸。ICA傳輸文本數(shù)據(jù)、圖像數(shù)據(jù)和視頻數(shù)據(jù)時，數(shù)據(jù)量分別減少為原來的55%、34%和62%。但此時由于傳輸速度減慢、傳輸數(shù)據(jù)量減少，嚴重降低了視頻質量，致使視頻質量從大約50％降到不足5％。這說明ICA高速緩存的額外開銷在高帶寬環(huán)境下超過其對性能的貢獻。

3結束語

由以上對影響瘦客戶平臺性能的幾方面因素的分析可得出以下結論：

（1）在帶寬足夠高的情況下，顯示編碼計算的復雜程度是決定性能的主要因素，而并非其生成數(shù)據(jù)量的大小?；谙袼氐娘@示編碼計算簡單；圖形編碼方式帶寬利用率一般較高，但若屏幕內容為圖文混合時，像素編碼方式卻比圖形編碼方式的帶寬效率高。像素編碼與圖形編碼相比具有更好的平臺獨立性。

（2）顯示更新機制是視頻質量的重要決定因素。帶寬較寬時使用服務器驅動的急切更新模式，能獲得較好的視頻性能；較低帶寬下為減少響應時間，節(jié)省網(wǎng)絡帶寬，使用懶惰更新機制，它通過放棄或者融合顯示更新犧牲了視頻質量?？蛻舳蓑寗尤菀自斐煽蛻粽埱蟮钠款i。

（3）壓縮和緩存都能降低數(shù)據(jù)量的傳輸，但在不同網(wǎng)絡帶寬下，壓縮與緩存在計算開銷和帶寬保留之間存在著平衡的問題。簡言之，當有足夠的網(wǎng)絡帶寬時，減少處理時間是可取的，而在較低的網(wǎng)速下減少傳輸?shù)臄?shù)據(jù)總和是有益的。

借鑒上述平臺的優(yōu)點，使瘦客戶平臺在不同的網(wǎng)絡環(huán)境下都具有較高的性能，并對各種應用傳送的屏幕內容都能很好地適應。要求其具有智能選取顯示編碼（或開發(fā)出具有更好適應性的顯示編碼）和更新機制的能力；智能地控制壓縮和緩沖的打開及關閉。通過智能啟發(fā)式的機制，在用戶不干預的情況下，通過測量自動判斷目前的狀況并動態(tài)適應，從而使瘦客戶平臺具有對客戶機計算能力和帶寬的適應性，即在各種網(wǎng)絡帶寬和客戶機的情況下，都能獲得較高的性能。以上分析為今后開發(fā)具有自我知識產權的高性能瘦客戶系統(tǒng)提供了基礎。

參考文獻：

［1］RICHARDSON T，STAFFORD F Q，WOOD K R，et al.Virtual network computing[J].IEEE Internet Computing，1998，2(1):32－38.

[2]RICHARDSON T.The RFB protocol[S].[S.l.]:RealVNC Ltd，2003.

[3]Microsoft Corporation.Microsoft Windows NT server 4.0， terminal server edition:an architectural overview[R].[S.l.]:Redmond，1998.

[4]Boca research.citrix ICA technology brief[R].[S.l.]:Boca Raton，1999.

[5]Tarantella Corporation.A technical overview，A tarantella white paper[R].[S.l.]:[s.n.]，2001.

[6]NIEH J，YANG S J，NOVIK N.Network computing laboratory[R].[S.l.]:Columbia University，Comparison of Thin－client Computing Architectures，2000.

[7]YANG S J，NIEH J，NOVIK N.Measuring thin－client performance using slow－motion benchmarking[J].ACM Transations on Computer System，2003，21(1):87－115.

[8]RIEDL L R.Technologies of thin－client architectures[R].[S.l.]:[s.n.]，2001.

[9]YANG S J，NIEH J，SELSKY M，et al.The performance of remote display mechanisms for thin－client computing:proceedings of the USENIX Annual Technical Conference[C].[S.l.]:[s.n.]，2002.

注：“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”