The RFB Protocol（RFB協議）簡介

一、簡介
RFB(遠程幀緩衝)是一個用於遠端存取圖形使用者介面的簡單協議。由於它工作在幀緩衝層，所以適用於所有的案頭系統和應用，包括X11,Windows和Macintosh等。
我們把使用者所在的一端（包括顯示器、鍵盤和滑鼠）被稱為RFB用戶端。而幀緩衝發生變化的一端（案頭系統和應用）稱為RFB伺服器。
RFB協議是一個瘦客戶協議。協議設計的重點是減小對用戶端的要求。這樣，用戶端可以運行在多種範圍的硬體上，實現的任務是使用戶端儘可能地簡單。
RFB協議也使得用戶端是“無狀態”的。如果一個用戶端和伺服器斷開了串連，稍後再一次串連到這台伺服器上，使用者的會話不會被關閉，狀態會一直保持著。不同的用戶端可以串連到同一個伺服器上，在新的用戶端上使用者看到的是和原來的用戶端上相同的圖形使用者介面。這樣，使用者的案頭變的完全可移動了。只要有合適的網路連接，使用者就可以訪問他個人的案頭應用，不論他走到哪裡都可以串連到自己的會話上，而這些應用的狀態可以一直保持著。
二、顯示協議
RFB協議的顯示部分基於一個簡單的畫圖原理：“將一個矩形塊的象素點放在給定位置（x，y）上”。這樣做初看起來也許非常低效，因為要將使用者所有的圖形組件都畫出來。但是由於可以為象素資料進行多種不同的編碼，可以根據不同的參數比如網路頻寬、用戶端計算速度和伺服器處理的速度等選擇靈活的編碼方式。
一系列的矩形塊組成了一個幀緩衝更新。一個更新描述了幀緩衝從一個狀態到另一個狀態的變化情況，所以，某些方面，這和音訊幀很類似。每一個更新中的矩形塊經常脫節（？？不懂），但是這不必要。
更新協議是用戶端“命令-驅動”型的。即伺服器只有在收到用戶端的請求才向其發送更新。這使得顯示協議的品質可以調整。用戶端和網路速度越慢，更新率就會越低。對於典型的應用，幀緩衝上相同地區的更新往往非常頻繁。如果用戶端或者網路非常慢，由於非常低的網路傳輸和用戶端更新，幀緩衝上瞬時的狀態都可以被忽略掉。
三、輸入協議
輸入協議是基於鍵盤和多鍵滑鼠裝置的標準工作站模型。當使用者敲了一下鍵盤或者滑鼠，或者移動了一下滑鼠，用戶端把這些輸入事件簡單地傳送給伺服器。輸入事件可以由其它非標準I/O裝置產生，如筆形手寫板引擎也可以產生鍵盤事件。
四、象素資料的表示
RFB用戶端和伺服器最初的互動包括協商將要傳輸的象素資料的格式和編碼類別型。協商被設計成使用戶端的工作儘可能的簡單。底線是伺服器必須可以一直提供用戶端想要的象素資料的格式。但是如果用戶端可以處理多種編碼類別型，它會選擇對伺服器來說最容易產生的編碼。
象素格式是指象素值顏色標記法 最常用的象素格式是24位或16位真彩色，
編碼是指怎樣通過網路把矩形象素點的資料發送出去。每一個矩形象素點的資料被加了一個首碼包括它在螢幕上的位置，矩形象素點的寬度和高度，以及一個“編碼類別型”來描述該象素的編碼方式。然後是經過編碼的資料本身。
五、協議擴充
可以添加新的編碼方式來擴充RFB協議。現在的編碼方式有Raw，CopyRect，RRE，CoRRE，Hextile和ZRLE。實際上，常用的只有ZRLE，Hextile以及CopyRect編碼，因為它們為典型的案頭提供了最好的壓縮方法。
除了真實的編碼，用戶端可以使用“偽編碼”來向伺服器聲明它支援一個特定的協議擴充。不支援擴充協議的伺服器可以簡單的忽略“偽編碼”。注意，這意味著用戶端必須事先假定伺服器不支援協議的擴充，直到從伺服器收到可以支援擴充的聲明。
做到不同的編碼和偽編碼類別型不相衝突很重要。一定要避免類似問題。RFB協議版本和編碼類別型由RealVNC公司維護。
六、訊息協議
RFB協議可以在位元組流或基於訊息的可靠的傳輸上操作。RFB協議分兩個階段：初始握手階段和協議互動階段。
最初的握手階段包括協議版本、安全類型、用戶端初始化訊息、伺服器初始化訊息等。注意用戶端和伺服器都發送一個協議版本訊息。
在伺服器初始化訊息之後RFB協議執行正常的互動階段。在這個階段，用戶端可以發送請求，然後從伺服器接收到結果。所有的訊息都開始於一個訊息類型位元組，後面跟著詳細的訊息資料。
下面關於協議訊息的描述使用了U8、U16、U32、S8、S16和S32基本類型。分別表示8位、16位、32位無符號整型和8位、16位、32位有符號整型資料。多位的整型遵循big endian順序。
PIXEL類型用來指一個象素值
6.1 初始的握手訊息
6.1.1 協議版本
握手從伺服器向用戶端發送一個協議版本的訊息開始。用戶端獲得伺服器支援的RFB協議的最高版本號碼。然後用戶端通過一個簡單的訊息來告訴伺服器實際使用的協議版本號碼（可能和伺服器發送的不一樣。）用戶端不能使用比伺服器所能提供的還高的RFB協議版本。這種機制說明用戶端和伺服器都支援多個等級的向下相容。
目前已經發布的協議版本有RFB3.3、3.7、3.8（RFB3.5有時會被用戶端錯誤的報告，這樣會被伺服器解釋成RFB3.3）。新編碼或者偽編碼類別型一般對協議的版本沒有要求，因為伺服器能簡單的忽略他不認識的編碼。
6.1.2安全
協議版本確定之後,伺服器和用戶端必須協商此次串連的安全類型.
6.6偽編碼
6.6.1 指標的偽編碼
用戶端要求偽編碼是為了在用戶端本地畫滑鼠指標,這樣可以在網路連接慢 的情況下提高顯示效能.
6.6.2 案頭的偽編碼