終端服務的桌面影像壓縮

國

立

交

通

大

學

電機學院通訊與網路科技產業研發碩士班

碩

士

論

文

終端服務的桌面影像壓縮

Desktop Image Compression in Terminal Service

研 究 生：李宗學

指導教授：張文鐘 教授

終端服務的桌面影像壓縮

Desktop Image Compression in Terminal Service

研 究 生：李宗學 Student：Tsung-Hsueh Lee

指導教授：張文鐘 Advisor：Wen-Thong Chang

國 立 交 通 大 學

電機學院通訊與網路科技產業研發碩士班

碩 士 論 文

A Thesis

Submitted to College of Electrical and Computer Engineering National Chiao Tung University

in partial Fulfillment of the Requirements for the Degree of

Master in

Industrial Technology R & D Master Program on Communication Engineering

January 2008

Hsinchu, Taiwan, Republic of China

終端服務的桌面影像壓縮

研究生：李宗學 指導教授：張文鐘博士

國立交通大學電機學院產業研發碩士班

摘要

隨著網路的發展，單純的多媒體串流已經不能滿足使用者的需求，除了影音的傳送， 使用者需要應用程式的分享，利用 Client／Server 機制分享桌面，因此，終端服務的圖形 壓縮為本論文的主題。 首先說明 VNC、X Window 以及 RDP 的差異，並分別比較其優缺點， RDP 的圖形傳 送方式採取不同的畫面使用不同的指令，在文字部分傳送 1 bpp 的點陣字型，圖形部分則 傳送參數由 Client 端繪製，複雜的圖片則傳送 bitmap，由於 RDP 以 T.128 為基礎，因此介 紹 T.128（Multipoint Applocation Sharing Protocol）的標準，對於畫面的命令處理方式 T.128 有特別說明指令的定義及相關參數。 在實驗環境以 rdesktop 為主體，藉由程式碼的修改，進行畫面指令的分析，透過實驗 畫面的結果瞭解桌面圖形壓縮方式，為了驗證 RDP 的圖形壓縮方式適合使用在 thin client 的架構中，最後透過 rdesktop 進行資料量的分析。 本論文的重點在於遠端圖形傳遞上資料壓縮的分析，除了影片播放外，Window 作業 系統中的應用程式大多能順暢的操作，影片播放時由於畫面不斷更新，播放畫面越大資料 量越多，忽略的畫面也越多，在 Client／Server 的架構中，除了影片播放外，其他的應用 程式畫面傳送都可以利用 RDP 連線進行資料傳輸，最後藉由實驗結果推論出 RDP Server 的畫面切割原理。

Desktop Image Compression in Terminal Service

Student：Tsung-Hsueh Lee Advisor：Dr.Wen-Thong Chang

Industrial Technology R & D Master Program of

Electrical and Computer Engineering College

National Chiao Tung University

ABSTRACT

Along with the network development, multimedia sharing can not satisfy users.

Except the video and music transmission, users need the application sharing. We

can use client/server computing to share the application. This thesis is to discuss

the desktop image compression.

First, we will explain the difference between VNC (Virtual Network

Computing), X Window and RDP (Remote Desktop Protocol).For image

transmission, RDP server according to different display uses different order. For

text transmission, RDP server sends 1bpp bitmaps to RDP client. For simple

graphics transmission, RDP server sends a parameter order to client. When client

receive an order it will draw a graphic on the window. For the picture transmission,

RDP server sends bitmaps to client. RDP Protocol is based on T.128 (Multipoint

Applicaion Sharing Protocol), so we introduce the T.128 Protocol.

Our research is based on rdesktop program. We modify the source code, in

order to analysis the display components. We use rdesktop to connect RDP server.

During the transmission, we calculate the packets size from server.

Besides video playing, other applications can get a smooth transmission. We

demonstrate that using RDP protocol to deliver application images can get high

performance in data compression.Finally, make a conclusion of terminal desktop

image compression.

致謝

碩士生涯這兩年，首先感謝的是我的指導教授 張文鐘 博士，感謝老師於學業上的教 導，我才能夠順利完成碩士學位。同時也感謝 林大衛教授、黃仲陵教授及何文楨主任於口 試時的指導，有了您的指導才使得這篇論文更趨完善。 另外，感謝實驗室學長姐，素仙、程翔在研究上給予的協助，同時也感謝實驗室同學 們，文賢、明山、政達、峻權和振偉，感謝你們陪我度過兩年碩士生涯，與你們一同修課 研究的歲月裡是值得珍惜及懷念。 最重要的要感謝我的父母，有你們的支持，讓我在經濟上、生活上沒有任何負擔，有 你們的陪伴，我才能無後顧之憂的完成學位。感謝我的女朋友，在遇到挫折時給我的鼓勵。 最後，感謝這兩年曾給我協助、給我鼓勵的朋友們，謝謝你們。 誌於 2008.春 新竹。交大 宗學

目錄

摘要 ...iii ABSTRACT ... iv 致謝 ... v 目錄 ...vi 圖目錄 ...ix 圖目錄 ...ix 表目錄 ...xii 第一章 緒論 ... 1 1.1 動機...1 1.2 研究背景...1 1.3 論文架構...2 第二章 遠端桌面介紹 ... 3 2.1 VNC ...3 2.1.1 VNC 簡介 ...3 2.1.2 VNC 的圖形編碼 ...4 2.1.3 VNC 優缺點分析 ...5 2.2 X Window ...6 2.2.1 X window 的架構...6 2.2.2 X Window 的網路透明性 ...7 2.2.3 X Client 和 X Server 的繪圖管道...8 2.2.4 X Window 優缺點分析 ...10 2.3 RDP...10 2.3.1 RDP 簡介...10 2.3.2 RDP Session...11 2.3.3 RDP 操作原則...12 2.4 遠端桌面系統的綜合比較...12 2.4.1 畫面更新方式...12 2.4.2 Server/Client 訊息傳遞方式 ...12 2.4.3 系統比較...13 第三章 RDP 通訊協定介紹 ... 14

3.1 RDP Protocol Stack and Pack Format ...14

3.1.1 RDP Protocol Stack...14

3.1.2 RDP 封包格式...15

3.2 ITU-T T.128 畫面更新指令探討 ...17

3.2.1 Primary orders...18

3.2.1.2 Pattern Blt ...19 3.2.1.3 Screen Blt...19 3.2.1.4 Memory Blt...20 3.2.1.5 Text ...21 3.2.1.6 Rectangle...23 3.2.1.7 Line ...24 3.2.1.8 Desktop Save ...24 3.2.2 Secondary orders...25 3.2.2.1 Cache Bitmap...25 3.2.2.2 Cache ColorTable...26 3.3 點陣圖更新...27 第四章 RDP Client 實做與程式分析... 29 4.1 rdesktop...29 4.2 RDP order 處理流程 ...30 4.3 Primary order 的處理 ...37 4.3.1 text order ...37 4.3.2 圖形指令...43 4.3.3 其他命令...52 4.4 Secondary Order 的處理 ...58 4.4.1 process_bmpcache ...59 4.4.2 process_bmpcache2 ...60 4.4.3 process_colcache...61 4.4.4 process_fontcache ...61 4.4.5 process_raw_bmpcache ...61 4.5 Bitmap 編碼方式...62 4.6 RDP Cache 類別 ...62 第五章 實驗數據與畫面分析 ... 64 5.1 RDP 封包分析...65 5.2 畫面命令結構分析...66 5.3 桌面資料量分析...72 5.4 文書處理資料量統計...75 5.4.1 Microsoft Word ...75 5.4.2 Notepad ...78 5.5 網頁畫面數據統計...80 5.5.1 開啟交大首頁...80 5.5.2 開啟 google 網頁...82 5.6 Microsoft PowerPoint 畫面資料統計 ...83 5.7 影片播放...86 第六章 結論 ... 88 6.1 結論...88

6.2 未來發展與現況...89

6.2.1 現在 Windows RDP Client ...89

6.2.2 透過編碼技術播放影片...89

圖目錄

圖 1. VNC 系統架構... 3 圖 2. VNC 的 RRE 編碼方式... 4 圖 3. VNC 的 Hextile 編碼... 5 圖 4. X Window 系統架構... 6 圖 5. X Client 和 X Server 溝通程序 ... 7

圖 6. X protocol round trip time... 10

圖 7. RDP Session ... 11 圖 8. RDP Protocol Stack ... 14 圖 9. RDP 結構 ... 15 圖 10. MCS Data Format ... 15 圖 11. 兩種不同 RDP PDU 的封包資料型態... 17 圖 12. rdesktop 處理流程 ... 30 圖 13. RDP 封包類型判斷 ... 31

圖 14. RDP header 中 RDP PDU Type 欄位 ... 31

圖 15. RDP Process Data PDU... 32

圖 16. RDP Data PDU Type 欄位說明 ... 33

圖 17. RDP Data 內的 Update PDU type 欄位 ... 34

圖 18. 處理 update pdu 函數呼叫 ... 34

圖 19. RDP order 處理流程 ... 36

圖 20. RDP Primary order 定義的 TYPE 類型 ... 37

圖 21. TEXT2 ORDER 的結構 ... 37

圖 22. text order 函數呼叫流程... 38

圖 23. 利用 rdesktop 登入遠端畫面 ... 39

圖 24. 利用 rdesktop 連線到遠端桌面 ... 39

圖 25. 利用 rdesktop 連線到遠端 Command Line ... 40

圖 26. 利用 rdesktop 開啟遠端 Notepad... 40

圖 27.(a) rdesktop 遠端連線 Internet Explorer 開啟網頁（變動前） ... 41

圖 27.(b) rdesktop 遠端連線 Internet Explorer 開啟網頁（變動後） ... 41

圖 28.(a) 利用 rdesktop 開啟遠端 Word（剛開啟） ... 42

圖 28.(b) 利用 rdesktop 開啟遠端 Word（拖曳後）... 42 圖 29. RECT ORDER 的結構 ... 43 圖 30. rect order 處理流程... 43 圖 31. 正常的遠端登入畫面 ... 44 圖 32. 利用修改後的 rdesktop 進行遠端登入 ... 44 圖 33. 利用修改後的 rdesktop 顯示遠端桌面 ... 45 圖 34.(a) rdesktop 顯示遠端網頁矩形特徵（剛開啟）... 46 圖 34.(b) rdesktop 顯示遠端網頁矩形特徵（變動後）... 46

圖 35. 利用修改後的 rdesktop 開啟遠端 PowerPoint... 47 圖 36. POLYGON ORDER 結構... 47 圖 37. 多邊形處理流程 ... 48 圖 38. 多邊形外框 ... 49 圖 39. 多邊形 EvenOddRule ... 49 圖 40. 多邊形 WindingRule... 49 圖 41. ELLIPSE ORDER 參數結構... 50 圖 42. rdesktop 橢圓形的定義 ... 51 圖 43. LINE ORDER 參數結構 ... 51 圖 44. PATBLT ORDER 參數架構... 52 圖 45. SCREENBLT ORDER 參數結構 ... 53 圖 46. screen blt 命令處理流程... 53 圖 47. DESKSAVE ORDER 參數結構 ... 54 圖 48.(a) 原本的視窗畫面... 55 圖 48.(b) 拉出選單目錄後的畫面 ... 55 圖 48.(c) 暫存在 desktop cache 中的畫面資料 ... 56 圖 49. MEMBLT ORDER 結構... 56 圖 50. memory blt 封包處理流程 ... 57 圖 51. RDP 連線中 Memory blt 顯示位置 ... 58 圖 52. process_secondary_order 函數呼叫流程 ... 58 圖 53. rdp5 process bmpcache 封包格式 ... 59 圖 54. process bmpcache 封包格式... 59 圖 55. process bmpcache2 程式處理流程... 60 圖 56. RDP Font Glyph 結 ... 61 圖 57. RDP 封包與 TCP 封包關係圖... 65 圖 58. 時間軸上的 RDP 指令程序 ... 66 圖 59. 登入畫面指令組成 ... 66

圖 60. memory blt 中 sourceX 和 sourceY 參數說明... 68

圖 61.(a) 一般 RDP 連線的桌面... 72 圖 61.(b) 利用修改後 rdesktop 連線的遠端桌面... 72 圖 62. 一般 RDP 連線開啟 Word ... 76 圖 63. 利用修改後 rdesktop 開啟遠端 Word ... 76 圖 64. 一般 RDP 連線開啟遠端 Notepad... 78 圖 65. 利用修改後 rdesktop 開啟遠端 Notepad... 79 圖 66. 一般 RDP 連線 RDP Server 開啟交大首頁 ... 81 圖 67. 利用修改的 rdesktop 連線 RDP Server 開啟交大首頁 ... 81 圖 68. 一般 RDP 連線開啟 google 網頁 ... 82

圖 69. 利用修改 rdesktop 連線 RDP Server 開啟 google 網頁 ... 83

圖 70. 一般 RDP 連線開啟 PowerPoint... 84

表目錄

表 1. RDP 版本比較 ... 10 表 2. 遠端桌面系統比較 ... 13 表 3. ROP 類型介紹 ... 17 表 4. Destination Blt 參數及說明... 19 表 5. Pattern Blt 參數及說明... 19 表 6. Screen Blt 參數及說明 ... 20 表 7. Memory Blt order 參數說明... 21 表 8. Text order 參數說明... 22 表 9. Rectangle order 參數說明... 23 表 10. Line order 參數說明 ... 24

表 11. Desktop Save order 參數說明... 25

表 12. Cache Bitmap order 參數說明... 26

表 13. Cache Colortable order 參數說明... 27

表 14. 點陣圖更新封包參數 ... 27 表 15. bitmap cache 類別... 62 表 16. RDP 連線的桌面資料量整理 ... 73 表 17. RDP 連線的桌面命令分析 ... 73 表 18. RDP 連線桌面資料壓縮 ... 74 表 19. RDP 連線遠端桌面資料統計 ... 74 表 20. RDP 連線的 Word 資料量 ... 77 表 21. RDP 連線的 Word 命令分析 ... 77 表 22. RDP 連線桌面資料壓縮 ... 78 表 23. 開啟 Word 畫面所使用的 cache 數量 ... 78 表 24. RDP 連線的 Notepad 資料量... 79 表 25. RDP 連線的 Notepad 命令分析... 80 表 26. RDP 連線開啟交大首頁資料量 ... 82 表 27. RDP 連線開啟 google 網頁資料量 ... 83 表 28. RDP 連線開啟 PowerPoint 資料量... 85 表 29. RDP 連線播放 PowerPoint 投影片... 85 表 30. RDP 連線遠端播放影片的資料量 ... 86

第一章 緒論

1.1

動機

隨著無線通訊技術的進步，從 3G 頻寬 2.4Mbps 到 WiMAX 頻寬 70Mbps，這樣的 無線通訊技術是否可以應用在手機或是 PDA 上面呢?手機是現代人身上都有的通訊工 具，利用手機的操控透過 WiMAX 連線到辦公室或是家中的電腦，不管何時何地 （Anytime，Anywhere）都能處理事情，然而手機的處理速度有限以及電池的耗電量 不宜過大，因此我們利用現今遠端桌面操控的技術實現在手機上，將手機視為 thin client 利用遠端桌面連線到終端伺服器（Terminal Server），一切資料處理、行動計算都 在遠端的電腦完成，手機需負責兩件事情，一、接收處理後的圖形結果並顯示在螢幕 上，二、透過手機操作將輸入封包傳遞給遠端的 Server。 由於手機上的操作沒有多餘的鍵盤輸入或是滑鼠，因此透過手機觸控螢幕的點選 及手寫輸入應該是最適合的輸入方式，另外在顯示部分由於手機螢幕不像一般電腦螢 幕那麼大，因此在文字及圖形顯示部分必須清晰，輪廓線條要清楚，最適合的方式就 是現在的遠端桌面連線系統，透過彩度壓縮的方式傳送過來，也就是說傳送過來的圖 形、文字或許彩度不高，但是其文字清晰不影響使用者操作，適合應用在手機的操作 上。 相較於現行視訊串流（例如：VLC 或是 live555）[1]採用頻率（frequency doamin） 壓縮方式保留了彩度卻犧牲了高頻變化的圖形部分，遠端桌面系統的畫面傳輸保留了 高頻變化部分犧牲了彩度（space doamin），這樣的方式和視訊串流的壓縮方式明顯不 同，遠端桌面的畫面傳輸壓縮部份較有利於使用在終端服務的圖形介面上。因此，將 對遠端桌面的畫面更新傳輸進行探討，如果直接傳送完整 800x600 的畫面以 pixel 依序 傳送，每張畫面的資料量達到 960K Btytes，造成龐大的傳輸量，本論文以探討畫面的 傳輸編碼方式為目標，並完成畫面的資料分析以及影片播放的區塊定位。

1.2

研究背景

遠端桌面是一種讓使用者操控遠端系統的方式，一般來說，桌面系統的圖形具有 以下特性： i. 桌面的圖形結構上運用了大量的多邊形及線條。 ii. 桌面的文字需要清晰，使用者要能清楚辨別文字。 iii. 桌用的圖形具有重複性。 RDP 滿足了這方面應用的需求，在影像資料複雜的地方，RDP Server 將影像採取 點陣圖的方式傳送到 Client，而背景單純的文字部分，就採用 1 bpp 的點陣字型將文字

傳遞過來，這樣的機制符合色彩壓縮的原則且保留了高頻的變化，另外在重複出現的 點陣圖中，使用了 Cache 將資料暫存，因此本論文對微軟的 RDP 畫面傳送進行探討， 將透過開放源碼 rdesktop[2]的程式設計，進行遠端桌面的畫面剖析。

rdesktop 為建立在 unix 系統上的 RDP Client，由於其程式的開放性，我們將利用 rdsktop 做為本論文的實驗環境，透過程式碼的修改編譯，提供我們分析遠端桌面的影 像傳輸及快取暫存的機制。

1.3

論文架構

瞭解了本論文的動機和研究背景後，第二章將介紹現行的遠端桌面系統，其中 較廣為使用的就是 VNC[3]、X-window 和 RDP，本章將進行比較分析;第三章將進行 RDP 原理分析，RDP 的設計建構於 T.128 協定（Multipoint application sharing），本章 將說明 RDP Stack 及 RDP 協定分析，RDP 指令可分為 primary order 和 secondary order， 這部份也將在第三章詳細說明。第四章將說明 RDP Client 實做以及 rdesktop 程式分 析，針對每個指令的流程進行說明，並將畫面解析的結果記錄下來;第五章則是實驗數 據結果及畫面指令分析，由 Cient 推測出 Server 的指令判斷機制;第六章為結論及未來 發展。

第二章 遠端桌面介紹

現行遠端桌面連線系統有很多，常見的有 VNC、X-window 和微軟的 RDP（Remote Desktop Protocol)，我們將針對這三種不同架構的遠端連線系統加以介紹，並於本章的 最後一節討論這些架構的綜合比較。

2.1

VNC

Virtual Network Computing（VNC）是現行的遠端桌面連線系統之一，最初發展是 在 1995 年由英國劍橋的 Olivetti & Oracle 實驗室發展出來，公開且免費的通訊協定， 至今已發展多種版本，為跨平台的遠端桌面連線程式。

2.1.1 VNC 簡介

VNC 透過 Remote Frame Buffer (RFB) Protocol[4]控制遠端的電腦，VNC 為一套跨 平台的應用程式，在操作端安裝 VNC Viewer 就是我們所說的 Client，在遠端的電腦安 裝 VNC Server，可以多台 Clients 在同一個時間連接同一個 Server，另外，可透過 JAVA Applet 使用網路瀏覽器連接到安裝 VNC Server 的電腦。VNC 的架構可以分為 VNC Server 和 VNC Client（Viewer），彼此溝通的通訊協定為 RFB Protocol，如圖 1。 VNC Server：負責接收 Client 傳送過來的鍵盤或是滑鼠的輸入訊號後，並提供一套桌 面分享機制，畫面改變的資料量透過 TCP/IP 傳送到 Client。

VNC Client：根據收到的資料，將 Client 端顯示 Server 的畫面，並根據接收到的資料 做更新。

RFB Protocol：一個簡單的原則，將 Server 的點陣圖（bitmap）資料放到螢幕上指定的 X、Y 座標。

2.1.2 VNC 的圖形編碼 在圖形傳輸時，根據不同的網路頻寬，Client/Server 處理資料的速度，VNC Protocol 提供了多種編碼方式，主要有 Raw、Copy-Rect、RRE、Hextile 以及 ZRLE，接下來根 據這幾種編碼方式說明。 z RAW：直接傳送圖形的資訊圖形資料不經過壓縮，傳送 pixel 資料由左至右 依序傳送，任何版本的 VNC 都支援這樣的編碼方式，因此造成資料量驚人。 z Copy-Rect（Copy Rectangle encoding)：將 framebuffer 中的圖形位置由一塊區

域複製到另一塊區域，是一種簡單有效率的方法，Client 端的 buffer 已經暫 存了這塊區域的資料，Server 只要將 x、y 的座標告知 Client，只要複製 buffer 中的資料，便可以在畫面中顯示出來，可以節省網路頻寬。這樣的情形發生 在移動桌面內的視窗時，由於視窗內的資料並沒有改變，只需要改變顯示的 區域，透過這樣的方法可以降低頻寬的使用。 z RRE：這種編碼方式是將同樣的 pixel 壓縮成單一數值重複計算，在 VNC 中 實現的方法就是將要傳送的矩型區域中的顏色資訊，找出分布最多的顏色當 做背景色，然後根據其他顏色的分布定義出多個子區域（Sub-rectangle)並記 錄該區域的顏色、位置以及大小，如圖 2.，這樣的方法在面積大顏色單純的 區塊（例如：單色的桌布畫面），但是不適合於背景複雜的區塊。 圖 2. VNC 的 RRE 編碼方式

z Hextile：Hextile 算是 RRE 原理變化，將一個矩形區域以 tile 為單位切割，每 個 tile 為 16 x 16 pixels，每個 tiles 的順序由左至右、由上至下依序切割，如 果一個矩形區域，寬不是 16 的倍數那麼最後一個 tile 的寬度就會窄一點，相 同情形，如果高不能被 16 整除，那麼最後一個 tile 的高度就會短一點。每個 tile 可以使用 Raw 編碼或是 RRE 編碼，如果採用 Raw 編碼就直接記錄這個

tile 的 pixel 顏色資訊;如果採用 RRE 編碼，每個 tile 有自己的背景顏色，如 果其背景顏色和前一個 tile 的背景顏色一樣，就不需要明確定義；另外尚需 定義 tile 中，所有 subrectangle 前景顏色，並記錄下來，如果前景顏色都一致， 只需要紀錄一次。每個 tile 中的 subrectangle 都需要清楚的定義前景顏色和 x、 y 座標以及長、寬。 圖 3. VNC 的 Hextile 編碼

z ZRLE：Zib Run-Length Encoding（ZRLE），是結合了 zlib 壓縮、titling、調色 盤和 run-length 編碼技術。傳輸的時候，矩形區域以 4 個 bytes 開始，緊接著 是 zlib 壓縮資料，唯一的 zlib stream 傳送在 RFB protocol 連線上，因此 ZRLE 區域必須精確的依序編碼和解碼。Zlib 資料在還沒解壓縮之前，代表了 64 x 64 個 pixels，由左到右、從上到下，類似於 hextile 切割方式，如果高和寬不是 64 的整數倍，那麼最後一筆資料區域會小一點。 2.1.3 VNC 優缺點分析 VNC 最大的優點就是其跨平台的性質，透過其簡單的傳輸協定，在不同作業系 統、應用程式都能夠使用，此外，其協定的開放及免費性質，任何想應用的實驗環境 都可以實現或是自行設計。 VNC 在影像傳送有個缺點，假設我們要播放 640 x 480(pixels)的影片，VNC Server 就必需每秒傳送 30 張 16 位元的高彩圖片，每秒傳輸資料量為 17.58 MBytes，這樣的 結果不利於在低頻寬的網路上使用，不適合播放動態影片，造成使用者觀賞影片時， Client 播放影片畫面有遲滯的現象發生。

2.2

X Window

X Window 系統（也常稱為 X11 或 X）是一種以點陣圖方式顯示的視窗系統。最 初是 1984 年麻省理工學院的研究，之後變成 UNIX、Linux 等作業系統所一致適用的 標準化軟體工具套件及顯示架構的運作協定，經過二十多年的演進，現今已成為工業 標準。 2.2.1 X window 的架構 X Window 與一般的作業系統不同，在設計時就是以 Client/Server 為理念，整個 X Window 可以分為幾個部份：X Server、X Client、X Protocol 和 X Library，系統架構如 下圖所示。

圖 4. X Window 系統架構

z X Server：負責控制顯示卡將影像畫在顯示器上，並且管理鍵盤和滑鼠的事 件 ， 產 生 視 窗 、 對 應 視 窗 及 刪 除 視 窗， 這 部 份 要 特 別 說 明 ， 與 一 般 的 Client/Server 名詞定義有點差異，X Server 定義為 Display Server，而應用程 式端稱為 X Client。

z X Client：在 X Window 下的應用程式，要求特定的 X Server 作特定的動作。 主要的工作為：1、向 X Server 提出需求，2、接收來自 X Server 的事件訊息， 3、接收來自 X Server 的錯誤訊息。

z X Protocol[5]：X Client 和 X Server 的通訊協定，定義 Requests、Reply、Error 和 Events，這部份將在 2.2.2 節詳細說明。

z X Library：簡稱 X Lib，大部分 X window 上的應用程式以 X Library 來建立 GUI 元件，例如：按鈕（botton）、目錄（menus）等等。

2.2.2 X Window 的網路透明性

由於 X Window 系統採用網路訊息協定作為應用程式（X Client）和顯示介面（X Server）的溝通管道，而不是一般作業系統常見的函式呼叫，X Client 和 X Server 之間 就是夠過可靠的位元組資料流作為溝通。一般來說，如果 X Client 和 X Server 在同一 台電腦，就以內部程序通訊（IPC，InterProcess Communication）方式溝通;如果 X Client 和 X Server 在不同的機器上，利用程式介面 X Lib 透過可靠的網路協定（例如：TCP/IP） 進行溝通。X Protocol 定義了四種封包做為溝通的機制，如圖 5.。 圖 5. X Client 和 X Server 溝通程序 z 請求（Request）：客戶端請求伺服器的資訊，或者請求伺服器執行一個動作。 z 回應（Respone）：伺服器回應請求。但是並非所有的請求都會產生回覆。 z 事件（Event）：伺服器傳送事件給客戶端，例如，鍵盤或滑鼠的輸入，或移 動、調整視窗。 z 錯誤（Error）：如果請求無效時，伺服器會傳送一個錯誤封包。

當 X Client 要向 X Server 發出要求（Request）時，可透過網路向執行的 X Server 發出要求，然後交給 X Server 處裡。X Server 向 X Client 通知事件（Event）時，也可 以透過網路傳送。Request 和 Reply 的封包沒有長度限制，而 Event 和 Error 則有固定 32 bytes 的長度限制。網路透明化的性質，就是不同機器上的應用程式可以在同一台 電腦上顯示結果，這樣的特性乃是 X Window 不同於其他系統的一大特點。

2.2.3 X Client 和 X Server 的繪圖管道

瞭解了 X window 的架構及網路透明性，我們的重點還是影像畫面的繪製與傳遞， 關於 Window 的繪圖功能以及 Client/Server 之間傳遞的影像資訊，X Window 提供了一 些原則：

z X Server 將螢幕規劃為可重疊的視窗階層（window hierarchy），每個應用程 式可以使用多個視窗，依實際需要，重新規劃大小、位置。每個 GUI 中，視 窗就是一個頂層視窗(Top Level Window)，除了根視窗(Root Window)以外， 每個視窗都有一個 Parent Window，也就是說，Client 建立一個視窗就是在現 存的視窗下建立一個子視窗，所以 Client 所建立的視窗都是以樹狀結構去建 立的，樹狀結構的根就是 root window。 z X Server 的繪圖是立即性的，X Server 並沒有儲存繪圖序列的動作，而是收 到資料後立即繪出畫面。X Window 繪圖是以位元對映（bit-mapped）導向， 所有繪圖動作均以視窗定位，因此 X Client 可以在視窗內畫出東西，而不用 考慮視窗在哪個地方。

z X Window 顯示圖片（images），由於影像的資料量很大，因此 X Lib 提供了 一個 XImage 結構，允許使用者操作影像。XImage 支持多種格式的影像資料 並且操作影像中的 pixmaps。 在使用者圖形介面下，常會需要顯示一張圖片在畫面上，Xlib 提供了直接在 Client 和 Server 之間傳送影片的函數，這些函數都會使用 XImage 結構來作為函數的輸入參 數，這裡提供一套顯示圖片的方法，這個方法也是本論文架構 rdesktop 使用的方法， 以下進行說明： 1、宣告變數 XImage *image; Pixmap bitmap; 2、呼叫 XCreatePixmap

bitmap=XCreatePixmap(display, drawable, width, height, depth) 建立一個 pixmap 的結構

3、呼叫 XCreateImage

image=XCreateImage(display, visual, depth, format, offset, data, width, height, bitmap_pad, bytes_per_line)

建立影像資料結構，並定義相關參數 4、XInitImage(image)

XImage 在使用前，必須先經過初始化的動作。 5、將建立的影像資料結構放入 bitmap 中

XPutImage(display, bitmap, GC, image, source X, source Y, destination X, destination Y, width, height)

X Server 利用 pixmap 支援影像功能，pixmap 實際是一塊存放 bits per pixel 的圖形 儲存區，他的深度就是每一個 pixel 使用的位元數，pixmap 利用來存放影像，當我們 在 pixmap 做圖時，就如同在 window 做圖一樣，只是沒有顯示在螢幕上，因此 X window 的可繪圖區（drawable）其實就是泛指視窗（window）和 pixmap。由於 pixmap 是系 統資源，所以使用前必須創建它，當一個 pixmap 創立後，其內容是未被定義的，唯有 透過 X Lib 的做圖函數在其中作圖，才可以設置它，在利用函數將其複製到視窗中就 可以顯示了。瞭解了 X Window 做圖方式後，接下來說明 X Client 和 X Server 之間的 交談方式，X Server 存放了資源（Resources）提供 X Client 使用識別碼（identifiers） 操作，以下對各個資源做說明。 z 視窗（window）：這項資源是工作站上的矩型面積，使用者可利用視窗來觀 看輸出結果，當應用程式產生需要顯示的圖形時，必須指定一個視窗來輸出。 每個視窗都必須有一個根視窗（root window），整個螢幕就是一個根視窗。 z 繪圖環境（graphical contexts,GC）：這部份是用來追蹤圖形的屬性，例如：前 景顏色、背景顏色、線條寬度、字型等等。每一個圖形輸出的請求必須參照 GC，X Window 提供 X Client 請求產生、改變或是刪除一個 GC。 z 字型（fonts）：這項資源包括了在視窗上顯示文字有關的資料，描述一組文字 的大小及樣式，這部份 X Server 通常有字型可供選擇，X Client 說明字元大 小、字元空間、字體，利用編碼（ASCII、ISO Latin-1 等等）由 X Server 顯 示。 z 顏色對映表（color maps）：這項資源將應用程式所輸出的圖形資料轉換成視 窗畫面上可見的顏色。 z 像數對映表（pixmaps）：這樣資源和視窗很相似，主要的差別在於使用者無 法在畫面上看到，對於 X Client 和 X Server 之間複製資料相當有用。 當 X Client 向 X Server 請求建立某個資源的時候，同時也指定了一個識別碼給特 定的資源，例如：建立一個視窗的時候，X Client 指定了視窗的屬性和識別碼，這個 識別碼便和這個視窗關聯。X Client 為了避免衝突，這些資源不可有相同的識別碼， 資源建立後，識別碼就成為 X Client 和 X Server 溝通的特定識別。當建立資源的 X Client 關閉和 X Server 的連線後，資源就會正常解除（destroy）。

這些繪圖的功能與處理程序都交由 X Library 來實現，X Library 是建立於 C 語言 的函式，Client/Server 通訊協定都仰賴這個函式庫來完成，現行有些 X Window 高階的 程式語言(例如：GTK+)，就是建構在 X Lib 函式庫的基礎上。

2.2.4 X Window 優缺點分析

X Window 是一套已經發展成熟且公開的標準，其中 X Client 和 X Server 又是以 訊息溝通為主，X Server 屬於顯示部分，而 X Client 屬於運算處理部份，這樣的溝通 方式可以降低頻寬的使用。但是，這樣的溝通方式造成冗長的 round trip time。round trip time 就是 X Client 和 X Server 溝通時，因為太多的 request 和 response 造成訊息往返時 間長，如圖.6。這樣的情形造成影像傳送時，因為冗長的 round trip time 降低資料傳輸 效益，可能 X Client 要求 X Server 做一個畫面的更新，卻需要雙方都傳遞訊息，造成 過多的訊息往返時間。

圖 6. X protocol round trip time

2.3

RDP

Remote Desktop Protocol，簡稱 RDP[6][7]。RDP 是微軟根據 ITU T.120 協議系列 所制定的一套未公開發表的數據通訊協議。透過網路連接 RDP Server 將應用程式顯示 畫面傳送到 RDP Client，RDP Client 將滑鼠、鍵盤等輸入訊息傳送給 RDP Server。

2.3.1 RDP 簡介

RDP 是 Windows 作業系統使用的 Terminal Service 通訊協定，其版本從 version 4.0 開始，演進到現在 version 6.0 版[8]，以下根據各個版本支援的作業系統與特色做比較， 如下表。

表 1. RDP 版本比較

Version

Operating System

Feature

4.0 Windows NT 4.0 Server, Terminal Server Edition

支援 8 bpp bitmap cache clipboard mapping 複製區塊 5.0 (rdesktop) Windows 2000 Professional 支援 16 bpp 列印到用戶端印表機 針對網路頻寬使用的改進 以 56 bit 或 128 bit 加密 5.1 Windows XP Professional 支援 24 bpp 支援聲音轉向播放

Version

Operating System

Feature

5.2 Windows Server 2003 Windows CE 5.0（用戶端) Windows CE 6.0（用戶端) 安全機制 SSL 用戶端支援取用 5.3 Windows Vista

Windows Server “Longhorm”

支援 32 bpp 支援單一程式的分享 不管 RDP 版本如何演進，其依舊是商業產品，因此其通訊協定實際運作方式並未 公開，本論文的架構建立於開放程式碼 rdesktop 的環境下，未來的章節都將以 rdesktop 作為實驗的基礎。 2.3.2 RDP Session 這一節，我們將介紹關於 RDP Session 建立流程及資料交換方式，在 Session 建立 初期，RDP Client 根據 TCP/IP 位址連線到 RDP Server，RDP Client 告訴 RDP Server 自己支援的密碼和 MAC 算法，第二步 RDP Server 告訴 RDP Client 所選擇的密碼和 MAC 算法、Server 隨機碼和 RSA public key，第三步 RDP Client 發送用 RSA 演算法 加密後的 Client 隨機碼給 RDP Server，雙方通訊的資料都經過 RC4 加密，以確保通訊 安全。RDP Server 使用命令（order)控制 RDP Client 畫面的更新，而 RDP Client 將控 制的 input 傳給 RDP Serer，整個 Session 通訊流程如下圖。

圖 7. RDP Session

關於 RDP 遠端桌面協定詳細的訊息交換方式以及 RDP Server 對於畫面更新的處 理將在第三章作詳細的介紹，接下來將針對之前介紹的遠端桌面系統做個綜合性的比 較。

2.3.3 RDP 操作原則

RDP 在畫面傳送上，以命令（order）為操作方式，可以分為 primary order 和 secondary order，Primary order 主要的工作在於處理線條、矩形或是出現過的點陣圖和 文字，Secondary order 則是傳遞首次出現的 bitmap 和文字。在終端服務的桌面圖形傳 輸上，畫面中 bitmap 的傳送，可以說是主要的資料量，RDP 的 bitmap 傳送方式有兩 種方式：

一、 RDP Server 先利用 secondary order 的 bitmap cache 將 bitmap 傳送到 RDP Client 暫存起來，隨後馬上傳送一個 memory blt 將 bitmap cache 中的 bitmap 資料，依據 cache id 和 cache index 將指定的 bitmap 取出，將 bitmap 依據指定的位置顯示在螢幕上，通 常主要的畫面傳送都是利用這樣的方法。

二、 RDP Server 直接傳送 bitmap 資料，並給予座標位置，RDP Client 收到後，直 接將資料顯示在畫面上，傳遞的 bitmap 通常為視窗的外框或是工作列表邊緣線，在畫 面傳送上，佔很小的比例，這部份的畫面更新方式稱為 bitmap updates。

2.4

遠端桌面系統的綜合比較

根據先前所介紹的遠端桌面系統，這章節將對系統特性以及更新方式做個比較。 2.4.1 畫面更新方式 Server 和 Client 之間的畫面更新方式可以分為以下幾種： z RAW：所有的更新圖片，不經過壓縮編碼，每個 pixel 的資料依序傳送，可 以想像資料量很大，假設傳送一張 640 x 480 大小的 16 位元高彩圖片，就需 要 614.4K Bytes。VNC 支援這樣的編碼方式機制。 z 2D draw primitives：利用區塊填色的方法將圖形編碼，通常是一種非失真編 碼的方式，VNC 的畫面編碼主要以這樣的方法。

z Low level graphic：除了圖形編碼的方法之外，還利用一些簡單的指令，例如： 字型、多邊形、線條等等的指令呼叫 Client 繪圖，RDP 便是利用這樣的更新 方式進行畫面更新。

z High level graphic：除了 2D draw primitives 和 Low level graphic，還支援視窗 的建立和管理，X Window 所利用的 X Protocol 就是屬於這類。

2.4.2 Server/Client 訊息傳遞方式

Server 和 Client 的訊息傳遞方式主要可以分為兩種，Server Push 就是由 Server 主 動決定何時傳送更新畫面到 Client；Client Pull 就是由 Client 向 Server 要求傳送更新，

使用 Server Push 的系統，其畫面更新較為平順但是相對資料量較大，而 Client Pull 則 是只有在使用者輸入訊息時，才會通知 Server 作畫面更新的傳送，但是其資料量較少。 2.4.3 系統比較 瞭解了畫面編碼方式及系統更新方式，根據這些特點我們將針對這幾個系統做分 析比較，說明如表 2.。 表 2. 遠端桌面系統比較 系統 畫面編碼方式 更新方式 壓縮方式 cache license VNC Compressed Pixel Data Client pull RLE RAW Client frame buffer GPL RDP Low level graphics Server push

2D RLE YES proprietary X window High level

graphics

Server push

第三章 RDP 通訊協定介紹

微軟的遠端桌面連線系統主要建立於 ITU-T T.120 系列，為了暸解整個 RDP 的程 序以及封包包裝程序，3.1 節我們將針對 RDP Protocol Stack 說明，了解 RDP Protocol 協議的結構；由於我們的研究重點在於遠端桌面畫面的傳送與剖析，因此 3.2 節我們 將針對 ITU-T T.128（Multipoint Application Sharing）文件部分探討，對於畫面的傳送 指令進行解析。

3.1

RDP Protocol Stack and Pack Format

3.1.1 RDP Protocol Stack RDP Protocol 是基於 ITU-T T.120 協議系列的擴充[9]，做為多點通訊協議，可在 不同虛擬通道中傳輸數據，並利用加密機制確保通訊安全，本身的協議層次結構如下 圖 8.所示。 圖 8. RDP Protocol Stack 在一個網路上傳輸的封包建立在 TCP/IP 之上，因此最底層是 TCP/IP 層，TCP 層 上面是一個與 RDP 協議無關的標準統一層 ISO 層，ISO 的標準就是 RFC 2126(Open System Interconnection over TCP)，RDP 通訊協定的特性即多點傳輸與多通道傳輸，因 此 ISO 層上面是 MCS（Multipoint Communication Service）層，MCS 層上面是 Secure 層，這層完成加密套件（cipher suite）的協商、密碼的生成、MAC 的生成、數據加/ 解密以及 MAC 值得計算和驗證，最上面是 RDP 層，這層是以 T.128（ASP，Multipoint Application Sharing Protocol）為建立的基礎，因此一個完整的 RDP 封包其結構應該是 如下頁圖.9。在 3.1.2 我們將針對 RDP 封包格式深入說明。

圖 9. RDP 結構

3.1.2 RDP 封包格式

一個完整的 RDP 封包包含了 IP header、TCP header、ISO header、MCS header、 SEC header、RDP header 和資料。由於 TCP 層與 RDP 協議無關，因此本節針對其他 四層的封包格式進行說明。

z ISO 資料格式：RFC2126 定義了 TPKT 封包 header，第一個 byte 定義了 ISO 版本，接下來一個 byte 為保留，然後封包總長度佔了 2 個 bytes，接下來為 1 byte 的 ISO header 長度，然後是 ISO_PDU_CODE 佔了 1 個 bytes 代表 TPDU 的類型，然後是 padding，接下來是資料。

z MCS 資料格式：T.125 針對 MCS 層的封包 header 定義，MCSPDU header 共 8 個 bytes，第一個 byte 是 MCSPDU type，接下來兩個 bytes 是 mcs_usrid， 這個值是在建立連線時，由 RDP Server 分配，並在 MCSPDU 中作為資料回 傳給 RDP Client，做為此後通訊時 RDP Client 的身分辨識。第 4、5 個 bytes 是 channel id，這個數值有兩種方式取得，一種是 RDP Client 向 RDP Server 發出請求，RDP Server 處理這個請求並分配一個 channel id，攜帶在 MCSPDU 的資料中傳給 RDP Client；另一種方式是由 RDP Client 自行指定，將感興趣 頻道的 channel id 填寫於第 4、5 個 bytes 的欄位後，發出 MCSPDU。第 6 個 byte 是 flag，一般設定為 0x70 換成 01110000。第 7、8 個 bytes 是長度，這 個長度不包括自己 MCSPDU header 長度，簡單說就是第 8 個 byte 之後到 MCSPDU 最後一位元的長度，整個 MCS 數據格式如下圖 10.

圖 10. MCS Data Format

z Security 資料格式：SEC 層是 RSA 加密算法而不是網路協議，因此沒有資料 格式，但是 RDP 對資料加密時，也需要傳遞資料加/解密的訊息，例如：public

key，這個和網路分層包裝標頭（header）性質一樣，因此我們可以用資料格 式來敘述。由於 RSA 的加解密流程已經在 2.3.2 RDP Session 小節說明過了， 這裡就不多做說明。如果未獲得通訊協定許可那麼將傳送 4 個 bytes 的 sec_flags；如果是進行加密時，則傳送 4 個 bytes 的 sec_flags 和 8 個 bytes 的 public key；如果已經通過認證，那麼就不傳送這個欄位的資料。

z RDP 封包格式：

RDP PDU header 格式可分為四個領域：

1. 長度：定義包括 RDP PDU header 在內的整個封包的大小

2. 固定領域：1 byte 的版本(version)、1 byte 的 RDP PDU TYPE、2 bytes 的 userid。

3. 可變長度：根據 RDP PDU TYPE 的數值有兩種變化，當 RDP PDU TYPE 定義為資料型態（DATA）時，這個欄位的長度為 12 bytes（包含：4 bytes shareid、2 bytes streamid、2 bytes 的剩餘長度、1 byte 的 TYPE、1 byte 的 壓縮標記、2 bytes 的壓縮長度）；當 RDP PDU TYPE 是其他三種型態 （Demand Active(要求認證)、Confirm Active（認證許可）、Deactive(解除 認證)）時，這個可變長度欄位的長度為 0。

4. 資料領域：攜帶的資料是複雜的多媒體訊息，由 TYPE 欄位定義。 RDP 封包格式分為以下兩類，一類是資料傳送封包，格式如圖 11.(a)、 一類是驗證（請求、同意、解除）封包，格式如圖 11.(b)。

(b) RDP PDU TYPE 是其他三種狀態 圖 11. 兩種不同 RDP PDU 的封包資料型態 在 RDP 資料傳輸時，資料由 RDP、SEC、MCS、ISO 往下到 TCP、IP 層包裝， 便形成一個完整的 RDP 資料封包在網路上傳遞，其中值得注意的是在一個 RDP 連線 中，連線前畫面更新封包都是以 RDP PDU DATA 的類型傳送，至於傳送的內容依據封 包內 TYPE 欄位所決定。

3.2

ITU-T T.128 畫面更新指令探討

RDP 是以 T.128 為基礎，因此在介紹 RDP 之前先針對 T.128 指令更新做說明，這 一節先了解 T.128 在 Application Sharing 方面做的規範，我們針對 ASP PDU DATA 中 TYPE 欄位為 ASP UPDATE PDU 的封包做探討，本論文的目標是針對遠端桌面傳送過 來的畫面進行解析，因此將探討 UpdatePDU 也就是畫面更新指令的原理部份。在介紹 指令內容前，我們先說明 ROP 這個參數，ROP 是 Raster Operation 的簡稱，中文稱為 光柵操作參數，主要是進行點陣圖的處理就是點陣圖的 pixel 和背景的 pixel 做位元運 算，可分為三種類型，如下表 3.。 表 3. ROP 類型介紹 ROP 類型 描述 ROP2 將筆或刷子與目標點陣圖進行結合。 ROP3 將刷子、源點陣圖和目標點陣圖依照不同參數內容進行結合

ROP4 使用二進位位元“遮罩”(mask)點陣圖結合前景 ROP3 和背景 ROP3。遮罩使用 0 和 1 標記使用 ROP3 的位元

在 RDP 中沒有使用 ROP4，而 ROP3 也都以 ROP2 完成，因此我們以 ROP2 作為 說明，當 Windows 畫線條的時候，實際上執行畫筆（pen）和目標畫線區域做 pixel 的

位元布林運算稱為「ROP」，也就是說決定最後顯示的顏色，舉例說明，一個黑色的背

景畫上黑色的線條，那麼顯示結果就看不到黑色線條了，因此這部份 Windows GDI 定義 ROP 操作方式來決定顯示的線條顏色。由於畫筆和目標為兩種元素因此稱為 「ROP2」，Windows 定義了 16 種 ROP2 的代碼，表示 Windows 組合畫筆 pixel 和目標

pixel 的方法，底下我們根據 rdesktop 所定義的類型，進行說明，以下 D 代表目標區域 的 pixel 數值，P 代表畫筆的數值。

static int rop2_map[] = {

GXclear, /* 0 不管畫筆和目標數值，顯示黑色線條*/ GXnor, /* DPon 目標和畫筆先做 or，再做 not */ GXandInverted, /* DPna 畫筆先做 not，再和目標做 and*/ GXcopyInverted, /* Pn 畫筆做反向*/

GXandReverse, /* PDna 目標做 not 後，再跟畫筆做 and*/ GXinvert, /* Dn 目標做 not*/

GXxor, /* DPx 目標和畫筆做 xor*/

GXnand, /* DPan 目標和畫筆先做 and 再做 not*/ GXand, /* DPa 目標和畫筆做 and*/

GXequiv, /* DPxn 目標和畫筆做 xor 再做 not*/ GXnoop, /* D 以目標為顏色，不考慮畫筆*/ GXorInverted, /* DPno 畫筆做 not 後，和目標做 or */ GXcopy, /* P 以畫筆為主(一般情況)*/

GXorReverse, /* PDno 目標先 not，再和畫筆做 or */ GXor, /* DPo 目標和畫筆做 or*/

GXset /* 1 不管畫筆和目標的數值，顯示白色線條 */ };

RDP 定義 order 的操作時，只有 primary order 使用到 ROP 的參數，因為 primary order 是實際對畫面進行處理的命令，而 secondary order 則是用來進行影像或是文字的 暫存，瞭解了 ROP 操作方式，繼續說明 T.128 的文件探討，T.128[10]定義了畫面更新 的封包為 UpdatePDU orders，一般來說分成兩種類型：

z 主要命令（Primary orders）：主要是繪圖指令，將顯示的畫面命令發送給其他 的 ASCE（Application Sharing Conference Entity），指的就是 RDP Client。 z 次要命令（Secondary orders）：提供資訊給 Primary orders，一般來說是 colormap

或是 bitmap cache 的資料。

在一個 RDP 連線中，如果傳送一張沒出現過的 bitmap，其傳送方式一定是先傳送 一個 secondary order (bmpcache order)，接著傳送 primary order(memory order)方式傳 送，接下來針對 primary order 和 secondary order 做說明。

3.2.1 Primary orders Primary orders 主要是處理點陣圖及線條、矩形，接下來將針對幾個主要命令做說 明。首先在介紹各個指令之前，我們先說明 Blt（Block Transfer）意思就是將某段記憶 體區段的資料複製到另一個記憶體區段，從來源端（source）到目的端（destination）， 也就是將記憶體資料顯示在螢幕之意，在 Primary orders 中會有部分的命令使用這樣的 方式。

3.2.1.1 Destination Blt

當 RDP Client 收到這個命令時，將桌面的指定矩形區域的畫面資料，根據不同的 ROP3 參數對 destination bitmap 做處理，大小受到指定邊界限制，Destination Blt 的參 數及敘述如表 4.。

表 4. Destination Blt 參數及說明

參數 敘述

Primary Order Header 主要命令的 header 敘述

destLeft (Coordinate) Destination Blt 所指定區域最左邊 X 座標 destTop (Coordinate) Destination Blt 所指定區域最上邊 Y 座標 destWidh(Coordinate) Destination Blt 所指定區域的寬度

destHeigth(Coordinate) Destination Blt 所指定區域的高度

ROP3 指定的 ROP3 參數類型，在這個命令中必須參考目標區

域的圖形資料，但不用參考來源區域的內容 nonStandardParameters 這個參數只能適用在 AS Protocol 的 base mode

3.2.1.2 Pattern Blt

當 Client 收到 Pattern Blt order 時，依據 ROP3 參數指定的動作，在畫面上進行目 標區域（destination rectagle）和刷子（brush，就是指填滿區塊）的 raster operation， 其區塊大小受到指定的邊界限制。這個指令在 RDP 應用中，主要是傳輸 1 byte 的圖樣 依據命令內容在目標區塊中進行更新，這部份通常是 RDP 連線時，閃爍游標傳送就是 依靠這個命令，Pattern Blt 的參數敘述，參考表.5

表 5. Pattern Blt 參數及說明

參數 敘述

Primary Order Header 主要命令的標頭敘述

destLeft (Coordinate) 所指示桌面繪圖區域最左邊 X 座標 destTop (Coordinate) 所指示桌面繪圖區域最上邊 Y 座標 destWidth(Coordinate) 所指示桌面繪圖區域矩形的寬度 destHeigth(Coordinate) 所指示桌面繪圖區域矩形的高度 ROP3 說明 ROP3 參數所指定的動作 backgroundColor 這個參數用來指定背景的顏色 foregroundColor 這個參數用來指定前景的顏色 brush 說明顯示的圖樣類型

nonStandardParameters 這個參數只能適用在 AS Protocol 的 base mode

3.2.1.3 Screen Blt

當 ASCE 收到 Screen Blt 命令時，依據 ROP3 參數內容，在桌面顯示上對來源區 塊（source rectangles）和目標區塊（destination rectangle）做 raster operation，其大小 依然受到指定的邊界所限制。

z 一個來源區域(source rectangle)的大小、位置，由 sourceX、sourceY 以及 destWidth、 destHeigth 定義出來。

z 一個目標矩形(destination rectangle)由 destLeft、destTop、destWidth 及 destHeight 這幾個參數定義。 z destWidth 和 destHeight 兩個參數定義了來源區域和目標區域的寬度及高度，這樣 可以避免，畫面複製的時候產生延展(stretching)。 z 來源(Source)矩形區域可能會和目標(destination)矩形區域發生重疊（overlap）。 由以上的敘述，我們可以利用這個指令來完成 RDP 的桌面視窗拖曳，透過這個指 令避免拖曳視窗時，產生重繪畫面所產生的資料量，關於 Screen Blt 的參數，參考表.6。 表 6. Screen Blt 參數及說明 參數 敘述

Primary Order Header 主要命令的標頭敘述

destLeft (Coordinate) 在桌面視窗上定義出移動後影像位置的 X 座標 destTop (Coordinate) 在桌面視窗上定義出移動後影像位置的 Y 座標 destWidth (Coordinate) 移動後的影像，使用了幾個像素(pixel)

destHeigth (Coordinate) 移動後的影像，使用了幾個像素(pixel)

ROP3 ROP3 參數的使用定義，這個命令中需要參考來源

（source）區域的資料，不用考慮 pattern 的資料。 sourceX (Coordinate) 移動前的影像位置，其左上角的 X 座標

sourceY (Coordinate) 移動前的影像位置，其左上角的 Y 座標 nonStandardParameters 只使用在 AS Protocol 的 base mode

RDP 連線中畫面開啟後，在視窗的移動上，利用 Screen Blt 做為視窗的移動指令， 透過這樣的方式，節省資料量的傳送，RDP 在 Screen Blt 的參數定義與 T.128 的 Screen Blt 定義一致。

3.2.1.4 Memory Blt

傳 送 指 令 的 ASCE 需 要 先 確 認 bitmapCacheID ， bitmapCacheIndex 和 colorTableCacheIndex 三個參數，這些資料是之前透過次要命令（secondary order）快 取（cache）暫存下來的 bitmap 和 colortable 資訊。當 ASCE（RDP Client）收到從遠端 ASCE 傳來的 Memory Blt 命令時，會依據 ROP3 參數指定類型，對 cache bitmap 和目 標的區域（destination rectangle）做 raster operation，這裡的目標區域指的就是螢幕的 背景，Memory Blt order 的參數敘述如表 7.。

z 來源的 bitmap（暫存在 bitmap cache）是由 sourceX、sourceY 參數以及 destWidth、 destHeight 所定義。

z 目的端區域是由 destLeft、destTop 以及 destWidth、destHeight 參數所定義。 z destWidth 和 destHeight 參數定義了暫存 bitmap 和目的區域寬、高，這樣可以避

免畫面的延伸。

z Cached bitmap bits 需要使用參照的 cached colortable 來比對自己的色彩。 表 7. Memory Blt order 參數說明

參數 敘述

Primary Order Header 主要命令的標頭(Primary Order Header)

colorTableCacheIndex 這 個 參 數 指 定 應 該 使 用 那 一 個 cached colortable bitmapCacheID 這個參數結合 bitmapCacheIndex 參數，指定在 Memory Blt 中要用到哪個 bitmap destLeft (Coordinate) 定義目標區域在桌面的 X 座標 destTop (Coordinate) 定義目標區域在桌面的 Y 座標 destWidth (Coordinate) 定義目標矩形的寬度，單位是 pixel

destHeight (Cooedinate) 定義目標矩形的高度，單位是 pixel

ROP3 定義 ROP3 的操作類型

sourceX (coordinate) 參考 cached bitmap 定義 source X 座標 sourceY (coordinate) 參考 cached bitmap 定義 source Y 座標

bitmapCacheIndex 結合 bitmapCacheID 參數，指定這個 Memory Blt 要用哪一個 cached bitmap

nonStandardParameters 這部份只使用在 AS protocol 的 base mode

在 RDP 協議中，傳送 memory blt order 之前必須先傳送 bitmap cache order 給 Client，將 bitmap 資料暫存於 Client cache 中，memoey blt order 功能就是將 Server 呼 叫 Client 將 bitmap 取出後，根據座標顯示於畫面上，這部份將在第四章做說明，

3.2.1.5 Text

Text order 設定字體位置的方式，依據 Y 座標的位置定義字元格（cell）的底線 （baseline）或是定義字元格的左上角（left，top），建議使用 baseline 定位，因為對於 終端電腦要利用左上角定位出一個字體的正確位置、大小、字型是有難度的，當 ASCE 傳送 Text order 並同意使用底線定位法時，雙方就已經透過協議定位出字體的底線位 置。這個指令中必須設定命令的 textFlags 參數中 BaseLine Start bit 為 true，並給予 startX 和 startY 參數值，以決定第一個字元格的底線啟始位置。反之，如果這個指令不是使 用底線定位法，那麼 startX 和 startY 的座標位置就是說明了字元格的左上角位置。ASCE 收到 Text order 後，依據訊息在桌面上畫出字體，依據下來的規則：

z 字體將會畫在前景，如果背景混合模式（backMixMode）是不透明的，那麼 字元格（character cell）背景就會畫在視窗背景上面。

是定義出第一個字元格的左邊及底線 pixel 位置；反之，如果沒有設定 Baseline Start bit flag，那麼 startX 和 startY 就是定義第一個字元格的左邊上 面 pixel 位置。 z 字元定位在任何 extraSpacing 向所有字元所請求，任何空白間隔是向空白的 字元所請求。 z 在本地端畫出來的字型是由符合傳送的 ASCE FontID，任何附加的特質是由 textFlags 或是 fontWeight 參數所指示。 z 如果本地的字型是可變化大小的，字體是由所支援的 fontWidth 和 fontHeigth 所決定，否則將字型的高度寬度將由字體固定。 z 畫出的字體是由 fontWeight（字體粗細）、Italic（斜體）、Underline（底線） 以及 StrikeOut（刪除，也就是畫中間線）所決定，這些參數都在 textFlags 定義。 關於 Text order 的相關參數及其敘述，如下表 8.。 表 8. Text order 參數說明 參數 敘述

Primary Order Header 主要命令的 header 敘述

backMixMode 這個參數說明文字與背景混合模式

startX (Coordinate) 這個參數定義了文字的起始座標，以左邊的 X 座標 為基準

startY (Coordinate) 這個參數說明了文字在遠端桌面的起始 Y 座標。如 果 Baseline Start bit flag 有設定，那麼 startY 座標就 是 cell 的底部；反之，如果 Baseline Start bit flag 沒 有設定，那麼 startY 座標就是 cell 的頂端 pixel backgroundColor 說明使用哪個背景顏色 foregroundColor 說明所使用的前景顏色 extraSpacing 這個參數指定附加空間給適用的單獨字元，如果這 個參數的值是 0，說明了沒有附加的空間 totalBreakSpacing 這個參數說明了所有附加空間可以被使用在空白 字元（也就是空格），如果值是 0 就是說明了這個 Text 指令中沒有適用的空格 breakCount 這個參數是說明空白字元的數量，如果值是 0 就是 說明了這個 Text 指令中沒有使用空格或是沒有空 白字元 fontHeight 字型的大小，說明字型高的部份使用了多少 pixels fontWidth 字型的大小，說明字型寬的部份使用了多少 pixels fontWeight 指示字型的粗細，這個值介於 0 到 1000，大致上可 分為細(light)≦400＜一般(normal) ≦700＜粗(bold)

參數 敘述

textFlags 說明了字型的附加特性，定義 bit flag 數值如下：

z 斜體（Italic） z 底線（Underline） z 刪除（StrikeOut） z Baseline Start

fontID 傳送 ASCE 的 fontID，經過雙方協商後所定義。

codePointList 字型代號

nonStandardParameters 這部份只使用在 AS protocol 的 base mode，選擇性 的列出 non-standard 參數

由於 T.128 是原則上的標準，在實際 RDP 在連線中有些參數定義與 T.128 不完全 一樣，在 RDP 中並沒有定義 fontWidth 和 fontHeight 參數，實際上操作過程將在第四 章說明，RDP 運用 text order 取出存放在 font cache 中的文字，透過這樣的方式，對於 重複出現的文字，可以節省資料的傳輸。

3.2.1.6 Rectangle

RDP Client 收到 Rectangle 命令時，執行兩個動作。使用 ROP2 參數光柵操作 (raster operation)，使用了刷子(brush)和背景混合模式(background mix mode)來完成矩 形內部的顏色，範圍由邊界所限制。他也使用另外的 ROP2 參數光柵操作，就是筆 (pen)和背景混合模式(background mix mode)，這樣完成只有邊框的矩形。

z 實體矩形的座標定義為 destLeft+1、destTOP+1、desyRigtht-1 和 destBottom-1。 z 矩形邊框線條則定義為座標點的序列（destLeft, destTop），(destRight, destTop)，

(destRigh, destBottom)，(destLeft, destBottom)，(destLeft, destTop)。

這個指令在 RDP 協定上，用來傳送畫面中矩形的繪圖指令參數說明，如表 9.。 表 9. Rectangle order 參數說明

參數 敘述

Primary Order Header 主要指令的標頭定義

backMixMode 定義這個 Rectangle 指令的背景混合模式 destLeft (Coordinate) 這說明了虛擬桌面上的左邊 X 座標位置 destTop (Coordinate) 這說明了虛擬桌面上的上邊 Y 座標位置 destRight (Coordinate) 這說明了虛擬桌面上的右邊 X 座標位置 destBottom (Coordinate) 這說明了遠端桌面上的底部 Y 座標位置 backGroundColor 說明 Rectangle 指令所用的背景顏色 foreGroundColoe 說明 Rectangle 指令所用的前景顏色 brush(Group) Rectangle 指令所用的刷子，於矩形內部填色

ROP2 說明這個 Rectangle 指令所使用的 ROP2 參數

pen(Group) Rectangle 指令所用的筆，用於矩形外框線條 nonStandard Parameters 這個參數只使用在 AS Protocol 的 base mode

RDP 協議和 T.128 參數定義有些許差異，其中 T.128 定義了矩形的左上角和右下 角座標位置，Remote Desktop Protocol 則是定義了矩形的左上角座標以及寬、高，而 且在 RDP 中並沒有定義 ROP 參數，因為在 RDP 的連線中，Rectangle order 都是不透 明的填充矩形，RDP 的實際操作過程將在第四章說明。RDP 畫面傳送中，對於單純背 景中，RDP Server 將背景視為 rectangle，透過傳送 rect order 方次進行更新。

3.2.1.7 Line

ASCE（Client）接收到 Line 命令後，使用 ROP2 參數來完成指令，使用筆(pen) 和背景混合模式(background mix mode)來劃線，在虛擬桌面上從起點(startX、startY) 到終點(startX、startY)，線條的前景顏色由筆(Pen)決定，RDP 在畫面組成上使用 Line order 完成畫面上線條的描述。

表 10. Line order 參數說明

參數 敘述

Primary Order Header 定義 Primary Order Header

backMixMode 定義這個 Line 指令跟背景的混合情形 startX (Coordinate) 定義線條起始點的 X 座標 startY (Coordinate) 定義線條起始點的 Y 座標 endX (Coordinate) 定義線條終點的 X 座標 endY (Coordinate) 定義線條終點的 Y 座標 backgroundColor 定義背景顏色

ROP2 這個 Line 指令中所使用的 ROP2

pen(Group) 這個參數所使用的 pen

nonStandard Parameters 這個參數只使用在 AS Protocol 的 base mode

3.2.1.8 Desktop Save 視窗管理員(window manager)提供一個本地的操作來儲存或復原本地的桌面區 域，不論是自行啟動的程式或是在應用程式控制下啟動的畫面。 z 使用者拉下了目錄，使得應用程式擋住一部分的主要視窗(area A)。 z 使用者選擇了一個視窗項目開啟了對話視窗擋住了一部分的應用程式視窗(area B)。 z 使用者選擇了對話按鈕，開啟了功能選項擋住了對話視窗或是擋住了應用程式視 窗 (area C) 。 z 使用者關閉了所有的對話視窗。 視窗管理員提供了一個儲存/復原(save/restore)機制，area A 被儲存目錄拉下時， 並且在關閉其他對話窗時復原。類似的情況下，area B 在對話視窗開啟後，就會被儲 存，area C 在第二個對話視窗建立後，便被儲存。area B 和 area C 在對話視窗關閉後 復原，有些區域可能會同時儲存，但是儲存和復原的原則是最後儲存先復原(last in， fast out)。

Desktop save 機制要求開啟 Client 的 desktop cache 以儲存保留的區域。當儲存區 域發生變化在一般 ASCE 所連結的應用程式，ASCE 會傳送 Desktop Save 指令給所有 連結的 ASCE，並說明那個區域該儲存，隨後 ASCEs 儲存桌面顯示上的指定區域資料 到 desktop cache。Desktop cache 是有系統的組合 tiles，大小依據指定的 X、Y 決定。 一般來說，ASCE 的效能根據相關儲存及復原的 tile 大小，以及 cache 所佔用的記憶體 空間來決定。

Desktop Save 指令說明了儲存(save)或是復原(restore)的動作，並定義處理的區域 (一般是 rectangle)和 cache 中 pixel 偏移量(offset)，傳送的 ASCE 計算 pixel offset 是根 據 desktop cache 以及 X、Y 所定義的大小。如果這是儲存(save)操作，累積的 pixel offset 加入指定區域的 pixels 值。如果這是復原(restore)操作，累積的 pixel offset 減掉指定區 域的 pixels 值，也就是將 desktop cache 暫存空間釋放出來。當傳送的 ASCE 偵測到 Cache 滿了以後，就不傳送 Desktop Save 指令除了 restore 的區域已經存在 desktop cache 中。 那麼關於儲存或是復原的區域就需要重新繪製了，關於 Desktop Save 命令的參數，定 義在表 11.。

表 11. Desktop Save order 參數說明

參數 敘述

Primary Order Header 主要指令的標頭

saveOffset 接收的 ASCE desktop ache 中的 pixel offset desktopLeft Desktop 區域的左邊 X 座標

desktopTop Desktop 區域的上面 Y 座標 desktopRight Desktop 區域的右邊 X 座標 desktopBottom Desktop 區域的底部 Y 座標

action 定義在 Desktop Save 指令中，說明了處理動作是儲存

(Save)還是復原(Restore)

nonStandardParmaters 這個參數只能適用在 AS Protocol 的 base mode

3.2.2 Secondary orders

在 T.128 協議中，Secondary orders 提供資訊 Primary orders 處理時所需要的資料， 一般來說是 colormap 或是 bitmap 暫存（cache）的資料以下針對各個命令做說明。

3.2.2.1 Cache Bitmap

Server 應該要進一步確認 Cache Bitmap order 的參數應該反映出 Bitmap 的結果和 Bitmap Cache 的協議結果，說明如下：

z 當 Bitmap capability 數值說明了支援 bitmap 壓縮(Compressed)的時候，就應 該傳送 Cache Bitmap (Compressed) order。

z bitmap BitsPerPixel 參數等於協議後 sendingBitsPerPixel 的值。

z 在 bitmap cache 中 CacheIndex 參數(value)少於協商後項目（entry）的數量。 z Bitmap 的大小(在任何壓縮後)適合於商議後的 bitmap cache area 的最大 cell

尺寸。

Server 必須負責指定 cacheID 和 cacheIndex 參數，並且將 bitmap 資料傳送給 Client 的暫存中並且更新資料，因此需要了解先前傳送的 Cache Bitmap 命令來追蹤 Client 的 bitmap cache 使用程度。當 Client 收到 Server 送來的 Cache Bitmap 命令時，依照 CacheID 和 CacheIndex 將資料暫存，新的 bitmap 資料會取代原本的資料。RDP 協議 中利用這樣的指令建立點陣圖快取（Bitmap Cache）可以有效降低相同點陣圖資料重 複傳送，有效降低頻寬的使用，關於 Cache Bitmap order 的參數說明如下表 12.。

表 12. Cache Bitmap order 參數說明

參數 敘述

Secondary Order Header 由於 Cache Bitmap 指令(order)是 Secondary Order，因 此這個參數定義 Secondary Order Header

cacheID 說明這個 bitmap 應該存放在哪個 cache 中

bitmapWidth 這個參數定義了 bitmap 的寬度，以 pixels 為單位 bitmapHeight 這個參數定義了 bitmap 的高度，以 pixels 為單位 bitmapsBitsPerPixel 這個參數定義了 bitmap 資料的 bits-per-pixel

cacheIndex 這個參數指示了在 CacheID 參數所指定的 cache 哪一 個快取項目(cache entry)該使用，認可的 values 取決於 在每一個 Bitmap cache 的 cell 商議後的結果

bitmapData 這個參數就是快取的 bitmap data，這個值可能是未經

壓縮的

nonStandardParameters 這部份只使用在 AS protocol 的 base mode

3.2.2.2 Cache ColorTable

Server 傳送 ASCE 時，需要更進一步的確定 Cache ColorTable order 參數反映 Bitmap 的輸出以及 ColorTable Cache 商議結果。

z Colortable 項目的數量是根據商議後所傳送的 BPP (SendingBitsPerPixel)數值， 也就是說 Colortable entries 數量等於 2 的 n 次方，其中 n 為 SendingBitsPerPixel 數值。

z 在 Colortable cache 中的 CacheIndex 數值小於 negotiated entry 的數量。

當 Bitmap.sendingBitsPerPixel 為 1 的時候，ASCE 將不傳送 Cache ColorTable 指 令，舉例來說，AS protocol 定義了 Colortable，說明數值 0 是黑、1 是白。發送命令 的 ASCE（Server）負責分配 CacheIndex 參數以及更新遠端 ASCE（Client）的 Colortable

cache，根據事先傳送的 Cache ColorTable 指令(orders)，ASCE（Server）需要追蹤 維護所屬的 Colortable cache。

ASCE 收到 Cache ColorTable order 後，便會將所支援的 Colortable 放到它的 entry CacheIndex 的 Colortable Cache area，並替換這個 slot 中原有的資料。一個 Colortable 包含了 16 或是 256 組 RGB 的色彩值，Colortable 中色彩的排列是重要的，而且是 依 Colortable 的 順 序 從 0 到 15 或 是 0 到 255 ， 數 值 的 多 寡 由 傳 送 的 BPP(sendingBitsPerPixel)決定。關於 Cache ColorTable 的參數說明如表 13.。

表 13. Cache Colortable order 參數說明

參數 敘述

Secondary Order Header 這個參數定義 Secondary Order Header

cacheIndex 這個參數說明了該使用哪個 colortable cache 中 的 cache entry，認可的 values 取決於在每一個 Bitmap cache 的 cell 大小商議後的結果

colorTable 這個參數列出了色彩值，由暫存的 colortable 所 組成。在 AS Protocol base mode 下，colotable 有 可能包含選擇性的色彩訊息

nonStandardParameters 這部份只使用在 AS protocol 的 base mode，選擇 性的列出 non-standard 參數 在實際 RDP 連線中，Colortable 只有在顯示為 256 色時才會使用，對於本論文的 操作環境為 16 位元的顯示並沒有使用到 Cache Colortable 的命令。

3.3

點陣圖更新

當收到一個 UpdatePDU（更新的資料封包）包含點陣圖資料（bitmap data），收到 的 ASCE（Client）經過解壓縮後，必須從來源 bitmap 複製到虛擬桌面上的目標矩形， 大小為目標矩形的寬、高，如果 bitmap 的大小超過目標的寬、高，那麼接收的 ASCE 將會裁切 bitmap 大小到目標矩形上，ASCE 會根據收到的 UpdatePDU 調色盤轉換點陣 圖 pixel 的數值，相關的點陣圖更新（Bitmap updates）參數如表 14.

表 14. 點陣圖更新封包參數

參數 敘述

ShareData Header ShareData 的標頭檔

destLeft 定義點陣圖要顯示在桌面上的左上角 X 座標

destTop 定義點陣圖要顯示在桌面上的左上角 Y 座標

destRight 定義點陣圖要顯示在桌面上的右下角 Y 座標

參數 敘述

width 說明點陣圖(bitmap)的寬度(以 pixels 來計算)，點陣圖

的寬度至少要大於或等於目標矩形的寬度

height 說明點陣圖(bitmap)的高度(以 pixels 來計算)，點陣圖

的高度至少要大於或等於目標矩形的高度 BitsPerPixel 每個 pixel 使用 bits 數量

compressedFlag 這個參數說明了 bitmap 資料有沒有壓縮

bitmapData 這個參數是 bitmap 的資料，可以是壓縮或是沒壓縮

nonStandardParameters 這個參數僅同意在 AS Protocol 的 base mode

點陣圖更新在 RDP 的協定上，通常為視窗外框的繪製或是桌面工作列的邊緣線， 在一個視窗系統中，使用 bitmap updates 更新的比例不高。 瞭解了整個 ITU-T T.128 的指令說明以及畫面的點陣圖更新後，由於 T.128 只是原 則上的應用標準，在 RDP 實際操作上，我們仍需要依靠 rdesktop 進行實驗，推論一個 RDP 連線的程序以及每個 order 的參數架構。第四章我們將利用 rdesktop 這個程式進 行畫面的解析，也是本論文的實驗系統架構，從實驗中，我們可以了解遠端桌連線的 畫面更新分為影像、文字和圖形，在影像的傳送上先傳送一個 bmpcache order 將影像 儲存在 client 的 bmpcache 中，之後 RDP Server 傳送 memory blt 到 Client，由 Client 依據 Cache id and Cache index 取出 bitmap，在依據指定的座標位置將影像顯示上去， 因此 RDP 的影像傳送便是先傳送 secondary order 再傳送一個 primary order，除了重複 出現的 bitmap 只要傳送 memory blt 外，都是依據影像暫存的機制進行。文字部分， RDP Server 也是先傳送一個 fontcache 傳送點陣字型到 Client，由 Client 暫存到 fontcache 中，之後 RDP Server 傳送 text order 取出文字，並顯示在指定位置。而圖形的方式都 是 RDP Server 傳送參數指令到 Client，由 Client 呼叫繪圖函數處理，整個 RDP 的運作 原則就是如此，我們將在第四章詳細說明實做過程。

第四章 RDP Client 實做與程式分析

本章說明 RDP Client 的程式運作流程，由於 RDP 的 Server 和 Client 都是微軟發 展出來的商業產品，因此本研究的程式架構以 rdesktop 為實驗環境，接收畫面的命令 並透過程式的修改，針對不同指令將畫面的各項特徵顯示出來。

4.1

rdesktop

rdesktop 是一個開放源碼的 RDP Client，其操作平台在 unix、linux 作業系統下， 主要是參照 RDP 協定經過不斷嘗試，進行反組譯完成的程式。

Rdesktop 建立了 TCP_connect，建立網路連接以及網路控制碼 sock，從最底層的 tcp layer 建立 sock，利用 tcp_recv（）接收來自 TCP 的封包，去掉 TCP header 將 TCP 封包中的 Payload 取出，之後資料經過 iso_recv（）處理後變成標準傳輸格式，再交由 mcs_recv（）整合成多點通訊（multipoint communication）數據格式，由 sec_recv（） 得到密碼 sec flag 解密之後就是標準 RDP 封包格式，依據 rdp_recv（）接收來自底層 RDP 封包由於，我們的重點在於畫面更新及圖形傳遞方式，因此接下來的章節，我們 著重在 rdesktop 處理 order 的實作部份，在處理 Server 傳過來的資料時，rdp_recv 一次 接收一個 RDP 封包的資料量，封包長度不固定，隨著 order 一筆一筆處理，處理完之 後，再透過 tcp_recv 接收下一個 TCP 封包，重覆相同的步驟將 RDP Packet 一筆筆從 底層讀取出來，進行處理。RDP 封包透過 TCP/IP 進行資料傳輸，RDP 封包在上層，

之後一層層往下封裝，每一層在資料的前端加上一段 header，方便對資料（data）、命

令(order)進行分類，實際上對於每一層的 header，rdesktop 定義了不同的結構進行解析。 在畫面傳遞上 RDP Server 將多個 order 包裝在 RDP Packet 傳送出去，將 RDP Packet 存入 TCP 的 Payload，假設 RDP 資料量超過最大尺寸，TCP 便將 RDP 封包分開傳送， 之後由 RDP Client TCP Layer 接收重組。Rdesktop 對於網路封包的結構定義如下： Typedef struct stream

{

unsigned char *p; //定義指標變數，用於指出現在的資料位置 unsigned char *end; //資料結束位置

unsigned char *data;//TCP/IP 資料的起始位置，開啟一段記憶體區塊，將資料放入區 unsigned int size; //通常為資料大小

unsigned char *iso_hdr; //iso layer 的 header 指標 unsigned char *mcs_hdr;//mcs layer 的 header 指標 unsigned char *sec_hdr; //sec layer 的 header 指標 unsigned char *rdp_hdr; //rdp layer 的 header 指標 }*STREAM;

rdesktop 利用這樣方式，解開每一層 header 讀取資料，對於資料處理和未處理的 定位都由 p 指標來完成。