[轉]VNC文章匯總

VNC協議分析 

 

原文連結： http://blog.csdn.net/forever_feng/archive/2009/10/20/4703088.aspx

 

VNC(Virtual Network Computing)是基於RFB（Remote Frame Buffer）協議進行通訊的，是一個基於平台無關的簡單顯示協議的超級瘦客戶系統，

由Cambridge的AT&T實驗室設計開發的。

vnc的預設連接埠是main:5900（C/S）和http:5800（B/S）連接埠。

RFB (遠程幀緩衝) 是一個遠程圖形使用者的簡單協議，因為它工作在幀緩衝層級上，所以它可以應用於所有的視窗系統，例如：X11,Windows和Mac系統。

遠程終端使用者使用機器（比如顯示器、鍵盤、滑鼠）的叫做RFB用戶端，提供幀緩衝變化的被稱為RFB伺服器。

RFB是基於tcp的一個應用程式層協議。

RFB 是真正意義上的“瘦客機”協議。RFB協議設計的重點在於減少對用戶端的硬體需求。這樣用戶端就可以運行在許多不同的硬體上，客戶機的任務實現上就會盡量的簡單。

RFB協議對於用戶端是無狀態的。也就是說：如果用戶端從伺服器端斷開，那麼如果它重新串連相同的伺服器，用戶端的狀態會被儲存。甚至，一個不同的用戶端可以用來串連相同的RFB伺服器。而在新的用戶端已經能夠獲得與前一個用戶端相同的使用者狀態。因此，使用者的應用介面變的非常便捷。

只要合適的網路連接存在，那麼使用者就可以使用自己的應用程式，並且這些應用會一直儲存，即使在不同的存取點也不會變化。這樣無論在哪，系統都會給使用者提供一個熟悉、獨特的計算環境。

顯示協議是建立在“把像素資料放在一個由x,y 定位的方框內”這單一圖形基礎之上的。

乍一看上去，把這麼多的使用者介面組件繪製出來是非常低效的方法。但是，允許不同的像素資料編碼方式，使得我們在處理不同的參數（如：網路頻寬，用戶端的繪製速度，伺服器處理速度）有了很大程度的靈活性。

通過矩形的序列來完成幀緩衝的更新。一次更新代表著從一個可用幀緩衝狀態轉換到另一個可用，因此有點和視頻的楨類似。儘管矩形的更新一般是分開的，但是並不是必須的。

顯示協議的更新部分是由用戶端通過命令驅動的。也就是說，更新只是在伺服器端響應用戶端的請求時發生的。這樣就讓協議更新品質是可變的。用戶端/網路越慢，更新速度也就越慢。對於一些應用來說，相同地區的更新是連續不斷的。如果用一個慢的用戶端，那麼幀緩衝的緩衝狀態是可以被忽略的。這樣也可以減少對用戶端網路速度和繪製速度的要求。

輸入協議是基於標準工作站的鍵盤和滑鼠等裝置的連線協定。

輸入事件就是通過把用戶端的輸入發送到伺服器端。

這些輸入事件也可以通過非標準的I /O 裝置來綜合。

例如，手寫筆引擎可能產生一個鍵盤事件。

初始的互動涉及到RFB用戶端和伺服器之間傳輸像素資料格式和編碼方式的協調。這種協調被設計的讓用戶端的工作盡量簡單。而設計的底線是：伺服器必須按照用戶端的要求格式來提供像素資料。如果用戶端可以同樣的處理多種資料格式或編碼格式，那麼一般會選擇伺服器端易於產生的格式。

像素格式涉及如何通過像素值來實現不同顏色的重現。最常用的一般像素格式是24 位或16 位的“真彩色”，它通過位來直接實現像素值到紅、綠、藍亮度的轉換。8 位“顏色映射”可以任意映射像素值到RGB亮度的轉換。

編碼指一個矩形的像素資料如何通過網線傳輸。每個像素資料的矩形都加上了一個頭，給定矩形在螢幕上的X、Y座標、矩形的寬和高，以及指定的編碼類別型。而後資料本身就是採用這種特定的編碼方式。

資料本身遵循特定的編碼。目前的編碼方式主要有Raw、CopyRect、RRE、Hextile 和ZRLE.在實際應用中我們一般使用ZRLE、Hextile 和CopyRect，因為它們提供了典型案頭的最好壓縮。其他可能的編碼方式還包括，用於靜態圖片的JPEG和用於生動影像有效傳輸的MPEG。

協議可以通過增加新的編碼方式來進行擴充。

協議可以通過以下方式進行擴充：

新的編碼方式

一種新的協議可以通過與現存的用戶端和服務端進行相關相容的添加。因為現存的伺服器將會忽略它們所不支援的新編碼方式。所以用戶端通過新的編碼方式進行請求也就不會有結果返回。

偽編碼方式

除了真正的編碼方式，用戶端也可以請求“偽編碼”通告伺服器，它支援某一協議的擴充。伺服器如果不支援這種擴充，那麼它將忽略。值得注意的是：用戶端必須先假設伺服器端不支援這種擴充，直到它獲得伺服器端支援的確認。

新的安全方式

添加一個新型的安全方式會帶來無限的靈活性，它通過修改協議的一些行為，但是並沒有犧牲現存用戶端和伺服器端的相容性。用戶端和伺服器端可以通過協議好的安全方式進行交流，當然並不一定與RFB協議類似。

無論如何你都不應使用不同的版本號碼。

RFB協議的版本是由RealVNC公司來制定的。如果你使用一個不同的協議版本可能與RFB/VNC不相容，要保證協議的相容性，請聯絡RealVNC公司。這樣會減少在編碼方式和安全類型上的衝突。

RFB協議可以進行可靠的傳輸，如位元組流或基於訊息的。和大多數協議一樣，它也是通過TCP /IP協議簇串連。協議由三步完成串連。首先是握手報文，目的是對協議版本和加密方式進行協商。第二步是初始化報文，主要用於客戶和伺服器的初始化訊息。最後就是正常協議的互動，用戶端可以按需發送訊息，然後可以獲得伺服器的回複。

所有的訊息以訊息類型開始，接下來是特定的訊息資料。

協議訊息描述的基本類型有：U8、U16、U32、S8、S16、S32。

U表示不帶正負號的整數，S表示有符號整數。

所有位元組整數（除了像素值本身）遵從big endian順序。

big endian或者little endian跟cpu有關，從而影響整數在記憶體中的排列順序。big endian是高位元組在前，little endian是低位元組在前，網路位元組序一般是big-endian。

PIXEL代表一個像素值bytesPerPixel位元組，8XbytesPerPixel = bits-per-pixel。

1、vnc伺服器發送所能夠支援的最高RFB協議版本號碼給用戶端，比如：“RFB 003.006/n”，即版本號碼為3.6，版本號碼固定格式為×××.×××，不足部分前面補零。

2、用戶端回複將要使用的版本號碼，格式如上。用戶端的版本號碼必須小於或等於伺服器版本號碼。這樣伺服器可以實現向後相容。

3、目前發布的協議版本主要有3.3、3.7、3.8（3.5版本被報告存在問題），最高版本號碼為4.0。

（一）v3.7以上版本安全類型

伺服器發送所支援的安全類型列表

如果用戶端能支援伺服器的某一安全類型，那麼用戶端就會發送一個位元組來確認串連

的安全類型:

如果安全類型數是0，那麼串連失敗（例如伺服器不支援客戶請求版本號碼），這樣就

會有字串來描述失敗原因：

伺服器在發送原因字串後，就會關閉串連。

（二）3.7以下版本（以vnc認證為例）

1、伺服器發送一個無符號的32位整數標識一個安全類型（與認證有關）。

安全類型：

其他認證類型：

說明：

①0，串連失敗（例如伺服器不支援客戶請求版本號碼），這樣就會有字串來描述失敗原因：

伺服器發送完reason-string就關閉串連。

②NONE，不需要認證（不要輸密碼），協議資料將被使用明文發送。

V3.8 以上版本， 還會帶有安全結果的訊息。

V3.3 和 3.7 協議直接進入初始報文.

③VNC認證，協議資料將採用明文發送，伺服器發送一個16 位元組的隨機數。

用戶端使用DES對驗證進行加密，使用使用者密碼作為密鑰，把16 位元組的回複返回到伺服器。

隨之而來的就是安全結果訊息。

2、伺服器發送16位隨機數。

3、用戶端使用DES對驗證進行加密，使用使用者密碼作為密鑰，把加密後的16位元組返回給伺服器。

4、伺服器對安全認證進行確認，傳回值為無符號32位整數，如果為0則表示成功，1表示失敗。如果不成功，伺服器直接關閉串連。

V3.8 以上版本 如果不成功，就會有字串來描述失敗原因，並關閉串連。

對於V3.8以下，如果不成功，伺服器直接關閉串連。

1、用戶端發送一個位元組的初始化訊息。

如果允許伺服器其他客戶繼續串連，那麼共用標誌應該是非零（真）。否則，伺服器將

斷開其他客戶的串連。

2、伺服器發送初始化訊息，主要告知用戶端伺服器的幀緩衝的高、寬、象素格式和案頭相關的名稱。

這個跟實現有關，有些實現是先發送24個位元組，然後再發送案頭名字字串。名稱字串格式如：sh-yinghua -1 ( 192.168.70.69 )。

幀緩衝寬度一般為水平解析度的大小，幀緩衝高度一般是垂直解析度的大小，比如1024×768等。

象素格式主要包括以下段：

伺服器象素定義伺服器本來的象素格式，這種象素格式會被一直使用，除非用戶端使

用設定象素格式訊息來請求另一種象素格式。bits-per-pixel是表示每個像素值需要的位元。這個數字必須大於等於depth，而depth用來表示像素值中有用的位元。目前位每象素必須是8,16 或32——小於8 位象素不被支援。如果多位元組象素被看做big-endian,那麼Big-endian 標誌非零。當然了，這對8 位每象素沒有任何意義。

如果真彩標誌非零，那麼最後6 項規定如何按照象素值來確定紅、綠、藍的亮度。紅的最

大值是紅色的最大值（＝2 ^n - 1, n 表示用在紅色上的位元)。注意這個值一般在big endian

的順序中。紅色-替換表示要得到最低明顯bit 所需要的替換個數。綠色最大值、綠色-替換和藍色最大值、藍色-替換和紅色類似。要在0—紅色最大值之間找一個紅色值，按照以下步驟進行：

• 遵循big-endian 標誌進行象素值。(例如：如果big-endian 標誌為0，主機的位元組順序是big endian，然後交換)。

• 使用紅色—替換將右邊替換。

• 和紅色最大值進行邏輯與(按照主機位元組順序)。

如果真彩標誌是零，那麼伺服器使用的象素值不是直接由紅、綠、藍的亮度組成，但是

服務為索引到顏色圖中去。顏色圖中的項目是由伺服器使用“設定顏色面板條目” （FixColourMapEntries）訊息進行設定的。

說明：位/象素一般為顯示設定的顏色品質位元。

目前的任何伺服器都還不能支援FixColourMapEntries訊息，只有基於X的伺服器才能支援顏色映射。實際上，為了能夠完全支援顏色映射，用戶端大概需要能夠指定特殊的、伺服器不會使用的像素值。這可能會加在未來的協議版本裡。

所有用戶端到伺服器的訊息第一個位元組都為訊息類型，資料類型U8。

客戶到伺服器的訊息在本文中有如下定義：

其餘的註冊訊息類型有：

值得注意的是：如果要發送未在本文中定義的訊息，那麼必須得到伺服器端的訊息確認。

設定象素格式訊息

“幀緩衝更新”訊息中設定什麼格式的象素值如何設定。

如果用戶端沒有發送“設定象素格式”訊息，那麼伺服器發送的象素值將遵循在伺服器初始化訊息中所包括的象素格式。

如果真彩標誌是零，那麼意味著使用“顏色面板”，只要用戶端發送顏色面板空的訊息，或者是面板項被伺服器端重設，伺服器可以使用設定顏色面板項目進行顏色面板的設定。

註：其中的象素格式如在上文中的描述。

設定編碼格式

設定編碼方式可以來確定伺服器發送象素資料的類型。訊息中編碼方式的順序是用戶端

按照優先順序來排列(第一個擁有最高的優先順序)。伺服器可能選擇這種順序，也可能不選擇。

象素資料也可以使用“原始編碼”如果沒有具體說明。

除了基本的編碼方式，用戶端也可以請求“偽編碼”通告伺服器它支援某一種擴充協議。如果伺服器不支援這種擴充，它就會忽略這種偽編碼。注意：這意味著用戶端在得到伺服器的確認之前都要假設伺服器並不支援它的擴充。

接下來就是編碼數目個編碼類別型的重複

由編碼類別型決定編碼格式。

請求幀緩衝更新

通知伺服器，客戶對框架緩衝區中的某個地區感興趣，這個地區由x座標、y座標、寬度和高度幾個參數限定。

伺服器通常對FramebufferUpdateRequest訊息的響應，是發送一條FramebufferUpdate訊息。

注意，可以發送一條FramebufferUpdate訊息用來回複幾條FramebufferUpdateRequest訊息。

伺服器假定客戶保留了幀伺服器中它感興趣的所有部分的副本。這意味著，伺服器通常只需要向客戶發送增量部分的更新。

但是，如果由於某種原因，客戶丟失了它所需要的一個特定地區的內容，就發送一條FramebufferUpdateRequest訊息，把訊息中的incremental置為0（false）。這要求伺服器把指定地區的全部內容儘可能快地發送過來。這個地區的更新不會使用copy rectangle編碼方式。

如果客戶沒有丟失它感興趣地區的任何內容，就發送一條FramebufferUpdateRequest訊息，把訊息中的incremental設為非零（true）。當框架緩衝區中的指定地區發生變化時，伺服器會發送一條FramebufferUpdate訊息。

注意，在FramebufferUpdateRequest和FramebufferUpdate之間可能會有一段不確定長的間隔。

對於速度快的客戶，它可能希望以固定頻率發送增量的FramebufferUpdateRequests訊息，以避免佔用網路資源。

增量標誌為0時，表示必鬚髮送完整內容過來。 按鍵事件

某一個鍵的按下與釋放。如果某一個鍵被按下，那麼按下標誌非零。釋放的時候變為零。

在X Window 系統中鍵本身被賦值為“keysym”。

對於大多數鍵來說，“keysym”與ASCII碼相對應，具體參考《The Xlib ReferenceManual》或者參考。在Linux上為/usr/include/X11/keysymdef.h。

對於大多數普通鍵，“keysym”和ASCII碼的值是一致的（前面3個位元組為0，最後一個位元組為ASCII碼）。其他的命令鍵為：

滑鼠(指標)事件

檢測指標移動或者某一個鍵的按下或釋放。指標目前在(x座標、y 座標），滑鼠按鍵的各鍵採用1到8位元遮罩標識，0 表示鬆開，1 表示按下。

拿普通滑鼠來說，全零表示滑鼠移動，第1，2，3 分別對應左、中、右鍵。對於滑輪滑鼠來說，滾輪向上對應第4位，滾輪向下對應第5位。

拖動操作是不斷的發送左鍵按下的訊息，並變換滑鼠的座標。

用戶端文本剪下

用戶端有新的ISO8859 - 1(Latin - 1) 文本在它的剪下緩衝裡，行的末尾通過新行字元(值為10)來表示。 需要無斷行符號（值為13)。目前還沒有找到傳輸非Latin - 1 字元集的方法。

伺服器到客戶訊息在本文中定義如下：

其餘註冊的訊息類型：

注意在伺服器發送訊息之前必須確認用戶端支援相關擴充，通常在請求“偽編碼”的

時候使用。 幀緩衝更新

幀緩衝更新是由一系列像素資料矩形而組成，這些矩形會被用戶端送入它的幀緩衝中。

它是對用戶端幀緩衝更新要求的響應。而在請求和響應之間有可能存在不確定時期。

隨著像素資料矩形的個數，每個矩形包括以下內容：

後面就是特定編碼的資料。 設定顏色面板條目

當像素格式使用“顏色面板”時，訊息告訴用戶端對應像素值如何映射為RGB亮度。

下面就是重複具體的色彩

目前對顏色映射的支援還很少甚至沒有。這方面已經做了一些初步的工作，但是還沒有完成。

目前，只有基於X 的伺服器能夠完全支援顏色映射。 響鈴

如果有響鈴事件，就在用戶端上響鈴。

伺服器剪下文本

如果伺服器的剪下板有新內容，伺服器主動發送該訊息給用戶端

本文的編碼類別型

其他編碼類別型

 Raw 編碼）

即採用原始的像素資料，而不進行任何的加工處理。在這種情況下，對於一個寬度乘以高度（即面積）為N的矩形，資料就由N個像素值組成，這些值表示按照掃描線順序從左至右排列的每個像素。很明顯，這種編碼方式是最簡單的，也是效率最低的。

RFB要求所有的客戶都必須能夠處理這種原始編碼的資料，並且在客戶沒有特別指定需要某種編碼方式的時候，RFB伺服器就預設產生原始編碼。

 CopyRect編碼）

CopyRect 編碼方式對於用戶端在某些已經有了相同的象素資料的時候是非常簡單和有效。這種編碼方式在網路中表現為x,y 座標。讓用戶端知道去拷貝那一個矩形的象素資料。它可以應用於很多種情況。最明顯的就是當使用者在螢幕上移動某一個視窗的時候，還有在視窗內容滾動的時候。在最佳化畫的時候不是很明顯，一個比較智能的伺服器可能只會發送一次，因為它知道在用戶端的幀緩衝裡已經存在了。

複製矩形編碼並不是完全獨立地發送所有的資料矩形，而是對於像素值完全相同的一組矩形，只發送第一個矩形全部資料，隨後的矩形則只需要發送左上方X、Y座標。實際上，複製矩形編碼主要指的就是隨後的這一系列X、Y座標，而對於第一個矩形具體採用何種編碼類別型並沒有限制，僅僅需要知道第一個矩形在框架緩衝區中的位置，以便於完成複製操作。因此，往往是把複製矩形編碼和其它針對某一個矩形的編碼類別型結合使用。

接下來使用CopyRect 編碼方式發送相同的式樣。

 rise-and-run-length，RRE）

RRE表示提升和運行長度，正如它名字暗示的那樣，它實質上表示二維向量的運行長度編碼。RRE把矩形編碼成可以被客戶機的圖形引擎翻譯的格式。RRE不適合複雜的案頭，但在一些情況下比較有用。

RRE的思想就是把像素矩形的資料分成一些子領域，和一些壓縮原始地區的單元。最近最佳的分區方式一般是比較容易計算的。

編碼是由像素值組成的，Vb(基本上是在矩形中最常用的像素值）和一個計數N，緊接著是N的子矩形列表，這些裡面由數組組成，(x,y)是對應子矩形的座標，表示子矩形上-左的座標值，(w,h) 則表示子矩形的寬高。用戶端可以通過繪製使用背景像素資料值，然後再根據子矩形來繪製原始矩形。

二維行程編碼本質上是對行程編碼的一個二維類比，而其壓縮度可以保證與行程編碼相同甚至更好。而且更重要的是，採用RRE編碼的矩形被傳送到用戶端以後，可以立即有效地被最簡單的圖形引擎所還原。

在傳輸中，資料以下面的頭開始描述：

後面跟隨重複的子矩形結構：

 編碼

CoRRE是RRE的變體，它把發送的最大矩形限制在255×255個像素以內，用一個位元組就能表示子矩形的維度。如果伺服器想要發送一個超出限制的矩形，則只要把它劃分成幾個更小的RFB矩形即可。“對於通常的案頭，這樣的方式具有比RRE更好的壓縮度”。

實際上，如果進一步限制矩形的大小，就能夠獲得最好的壓縮度。“矩形的最大值越小，決策的尺度就越好”。但是，如果把矩形的最大值限制得太小，就增加了矩形的數量，而由於每個RFB矩形都會有一定的開銷，結果反而會使壓縮度變差。所以應該選擇一個比較恰當的數字。在目前的實現中，採用的最大值為48×48。  編碼

Hextile 是RRE編碼的變種，矩形被分割成16×16 小片，允許每個小片的維數為4位，

總共16 位。

把原始矩形劃分成小塊是預定義的，這意味著每個塊的位置與大小不需要明確地指定。

矩形被分割的小片從上開始，遵守自左到右，自頂向下的順序。小片的編碼內容按照預定的順序進行編碼。如果整個矩形的寬度不是16 的整數倍，那麼每行最後的小片也相應減少。高度也類似。

每個小片可以使用raw 編碼，也可以是RRE編碼的變種，用一個類型位元組來進行說明即可。每個小片有一個背景像素值。但是，如果小片的背景像素值和前一個小片相同，那麼就不需要明確定義。如果小片的子矩形有相同的像素值，那麼前景像素值就可以只定義一次。和背景像素值一樣，前景像素值也可以通過前一個小片獲得。

因此由小片組成的資料是按照順序進行編碼的。每一個小片以子編碼類別型的位元組開始。它是位元的掩碼組成。

如果Raw 位被設定，那麼其餘的位就無效；接著是寬X高像素值（寬和高是小片的寬

高）。否則其他的位就有效。

背景定義-如果設定，那麼像素值就會跟著小片的背景色：

在矩形中的第一片非Raw 小片必須設定這一位，如果不設定，那麼它的背景就會和上

一片相同。

前景定義-如果設定，那麼像素值就會定義小片中所有子矩形的前景色彩。

如果這一位被設定，那麼子矩形著色位必須為0。

任意子矩形-如果設定，那麼一個位元組包含著子矩形的個數。

如果這一位不設定，那麼就不會有子矩形。（例如，整個小片就是背景顏色）

子矩形著色-如果設定，那麼任意子矩形的像素值的優先順序都高於子矩形的顏色定義，

因此子矩形是：

如果不設定，所有子矩形都是前景色彩的顏色，如果前景定義沒有設定，那麼前景色彩和

前一個片的相同。子矩形就是：

每一個子矩形的位置和大小都是使用兩位進行定義，x - and - y - position 和width -

And - height。最重要的四位x - an d - y - posi tion 定義X的位置，不重要的定義Y位置。最

重要的四位width - and - height 定義寬度- 1，不重要的定義高度- 1。  編碼

ZRLE(Zlib Run - Length Encoding),它結合了zlib 壓縮，片技術、調色盤和運行長度

編碼。在傳輸中，矩形以4 位元組長度地區開始，緊接著是zlib 壓縮的資料，一個單一的

zlib“流”對象被用在RFB協議的串連上，因此ZRLE矩形必須嚴格的按照順序進行編碼和

解碼。

zlibData 在沒有壓縮之前，代表了由64x64 像素組成的從左至右，從高到低的順序

的片，和hextile 編碼有點類似。如果整個矩形的寬度不是64 的整數倍，那麼每行最後的

小片也相應減少。高度也類似。

ZRLE編碼利用了一種新的壓縮像素CPIXEL(Compres se d PIXEL)。這個和PIXEL有著

相同的像素格式，除了真彩標誌是非零，位每像素是32，色深不大於24。所有的位組成紅，

綠和藍的亮度填充最不重要的或最重要的三位元組。如果CPIXEL只有3 位元組長，並且包含有

合適的最不重要或最重要3 位元組。那麼bytesPerCPixel 就是CPIXEL的位元組數。

每片都是以子編碼類別型位元組開始，如果片被使用運行長度編碼，那麼本位元組的最高位

就會被設定。其餘7 位表示繪圖樣式-零表示沒有樣式，1 表示片為單色，2 - 127 表示對應

的樣式。可能的子編碼值如下：

0 - Raw 像素資料 寬X高像素值（寬和高為對應片的寬和高，對應像素值如下：

2 - 16 -打包的樣式類型。對應像素值是由palet teSize(=子編碼)像素值，打包像素值組

成，每個打包像素值表示為一位地區服從樣式索引（0 表示第一個條目），對應

palet teSize 2，1 位被使用，palet teSize 3，4 有兩位被使用，從5 - 16 均有4 位地區被

使用。位的地區被打包成位元組，最重要的位表示最左邊像素。因為片並不是8,4,2 像素寬的

乘積，所以填充位被用來按照位元組數排列每一個行。

m 表示打包像素的位元組數。對於palet teSize 2 就是floor((width + 7) / 8) x height，

相應3,4 就是floor((width + 3) / 4) x height，而5 - 16 就是floor((width + 1) / 2)x

height。

17 - 127 未使用(對於palet te RLE並沒有什麼優勢）。

128 -簡單RLE 它由一些不斷重複的執行組成，一直到片結束。執行可能從一行的結束到另一行的開始。每一次運行是通過一個像素值和像素值長度來表示的。長度一般為1 個或多個位元組。經過計算多於所有位元組總和+ 1 作為長度。除了255 任何位元組值都隱含最後的位元組。例如長度1 表示為[0]，255 表示為[254]，256 表示為[255，0]，257 表示為[255，1]，510 表示為[255，254]，511 表示為[255，255，0]等等。

129 -未使用

130 - 255 調色RLE。調色緊跟其後，由palet teSize = (subencoding - 128) 像素值組成：

接下來就合簡單RLE相似，一些不斷重複的執行組成，一直到片結束。執行長度通過

調色盤索引來表示。

如果執行長度使用多於一位來表示調色盤索引，並且最高位被設定。那麼就會帶有執行長度。

指標/滑鼠偽編碼

如果用戶端請求指標/滑鼠偽編碼，那麼就是說它有能力進行本地繪製滑鼠。這樣就可以明顯改善傳輸效能。伺服器通過發送帶有偽滑鼠編碼的偽矩形來設定滑鼠的形狀作為更新的一部分。偽矩形的x 和y 表示滑鼠的熱點，寬和高表示用像素來表示滑鼠的寬和高。包含寬X高像素值的資料帶有位元遮罩。位元遮罩是由從左至右，從上到下的掃描線組成，而每一掃描線被填充為floor((width +7) / 8)。對應每一位元組最重要的位表示最左邊像素，對應1 位表示相應指標的像素是正確的。

案頭大小偽編碼

如果用戶端請求案頭大小偽編碼，那麼就是說它能處理幀緩衝寬/高的改變。伺服器通過發送帶有案頭大小偽編碼的偽矩形作為上一個矩形來完成一次更新。偽矩形的x 和y 被忽略，而寬和高表示幀緩衝新的寬和高。沒有其他的資料與偽矩形有關。

RealVNC VNC Server採用的RFB（遠程框架緩衝區）協議允許用戶端與服務端協商合適的認證方法，協議的實現上存在設計錯誤，遠程攻擊者可以繞過認證無需口令實現對伺服器的訪問。

具體操作細節如下：

1) 服務端發送其版本“RFB 003.008/n”

2) 用戶端回複其版本“RFB 003.008/n”

3) 服務端發送1個位元組，等於所提供安全類型的數量

3a) 服務端發送位元組數組說明所提供的安全類型

4) 用戶端回複1個位元組，從3a的數組中選擇安全類型

5) 如果需要的話執行握手，然後是服務端的“0000”

RealVNC 4.1.1或之前版本在實現RFB 003.008協議時沒有檢查判斷在上面第4步中用戶端所發送的位元組是否為伺服器在3a步中所提供的，因此認證就從服務端轉移到了用戶端。攻擊者可以強制用戶端請求“Type 1 - None”為安全類型，無需口令欄位便可以訪問伺服器。

危害:遠程攻擊者可以繞過認證無需口令實現對伺服器的訪問。

解決方案：檢查用戶端請求的安全類型是否為伺服器支援的類型之一，否則中斷連線，或者禁止無認證的安全類型。

 

---------------------------------------------------------------------------------------------------------------------------------------------------

  用 VNC 遠程圖形化登入 Linux (VNC 全螢幕顯示)  原文連結： http://www.cnblogs.com/cy163/archive/2007/05/23/757625.html VNC簡介』 
網路遙控技術是指由一部電腦（主控端）去控制另一部電腦（被控端），而且當主控端在控制端時，就如同使用者親自坐在被控端前操作一樣，可以執行被控端的應用程式，及使用被控端的系統資源。 
VNC（Virtual Network Computing）是一套由AT&T實驗室所開發的可操控遠端電腦的軟體，其採用了GPL授權條款，任何人都可免費取得該軟體。VNC軟體主要由兩個部分組成： VNC server及VNC viewer。使用者需先將VNC server安裝在被控端的電腦上後，才能在主控端執行VNC viewer控制被控端。 
（在windows中也由一套著名的網路遙控軟體――Symantec公司推出的pcAnywhere。 
VNC server與VNC viewer支援多種作業系統，如Unix系列（Unix，Linux，Solaris等），windows及MacOS，因此可將VNC server 及VNC viewer分別安裝在不同的作業系統中進行控制。如果目前操作的 主控端電腦沒有安裝VNC viewer，也可以通過一般的網頁瀏覽器來控制被控端。 
整個VNC啟動並執行工作流程如下： 
（1） VNC用戶端通過瀏覽器或VNC Viewer串連至VNC Server。 
（2） VNC Server傳送一交談視窗至用戶端，要求輸入串連密碼，以及存取的VNC Server顯示裝置。 
（3） 在用戶端輸入聯機密碼後，VNC Server驗證用戶端是否具有存取許可權。 
（4） 若是用戶端通過VNC Server的驗證，用戶端即要求VNC Server顯示案頭環境。 
（5） VNC Server通過X Protocol 要求X Server將畫面顯示控制權交由VNC Server負責。 
（6） VNC Server將來由 X Server的案頭環境利用VNC通訊協定送至用戶端，並且允許用戶端控制VNC Server的案頭環境及輸入裝置。

『VNC的安裝與使用』 
本人的作業環境：被控端 Redhat8.0，主控端Windows XP。 
1． 載VNC Server與VNC viewer. 
VNC Server下載地址：h