（文章是基于刚刚做过的一个项目，对相关知识点进行总结回顾。主要内容均是对之前收集资料的总结概括，很多内容转载自其它地方。因为时间比较长，没有一一记录转载地址，特此感谢！）

一、简介

　　RFB(远程帧缓冲)是一个用于远程访问图形用户接口的简单协议。适用于所有的桌面系统和应用，包括X11,Windows和Macintosh等。

　　RFB是基于tcp的一个应用层协议。

　　我们把用户所在的一端（包括显示器、键盘和鼠标）被称为RFB客户端。而帧缓冲发生变化的一端（桌面系统和应用）称为RFB服务器。

　　RFB协议是一个瘦客户协议。协议设计的重点是减小对客户端的要求。这样，客户端可以运行在多种范围的硬件上，实现的任务是使客户端尽可能地简单。

　　RFB协议也使得客户端是“无状态”的。如果一个客户端和服务器断开了连接，稍后再一次连接到这台服务器上，用户的会话不会被关闭，状态会一直保持着。不同的客户端可以连接到同一个服务器上，在新的客户端上用户看到的是和原来的客户端上相同的图形用户接口。这样，用户的桌面变的完全可移动了。只要有合适的网络连接，用户就可以访问他个人的桌面应用，不论他走到哪里都可以连接到自己的会话上，而这些应用的状态可以一直保持着。

二、显示协议

　　RFB协议的显示部分基于一个简单的画图原理：“将一个矩形块的象素点放在给定位置（x，y）上”。这样做初看起来也许非常低效，因为要将用户所有的图形组件都画出来。但是由于可以为象素数据进行多种不同的编码，可以根据不同的参数比如网络带宽、客户端计算速度和服务器处理的速度等选择灵活的编码方式。一系列的矩形块组成了一个帧缓冲更新。一个更新描述了帧缓冲从一个状态到另一个状态的变化情况，所以，某些方面，这和音频的帧很类似。

　　更新协议是客户端“命令-驱动”型的。即服务器只有在收到客户端的请求才向其发送更新。这使得显示协议的质量可以调整。客户端和网络速度越慢，更新率就会越低。对于典型的应用，帧缓冲上相同区域的更新往往非常频繁。如果客户端或者网络非常慢，由于非常低的网络传输和客户端更新，帧缓冲上瞬时的状态都可以被忽略掉。

三、输入协议

　　输入协议是基于键盘和多键鼠标设备的标准工作站模型。当用户敲了一下键盘或者鼠标，或者移动了一下鼠标，客户端把这些输入事件简单地传送给服务器。输入事件可以由其它非标准I/O设备产生，如笔形手写板引擎也可以生成键盘事件，之后服务端对事件进行相应处理。事件按照RFB协议规定的格式进行发送即可。

四、象素数据的表示

　　RFB客户端和服务器最初的交互包括协商将要传输的象素数据的格式和编码类型。协商被设计成使客户端的工作尽可能的简单。底线是服务器必须可以一直提供客户端想要的象素数据的格式。但是如果客户端可以处理多种编码类型，它会选择对服务器来说最容易生成的编码。

　　象素格式是指象素值颜色表示法 最常用的象素格式是24位或16位真彩色。，它通过位来直接实现像素值到红、绿、蓝亮度的转换。8 位“颜色映射”可以任意映射像素值到RGB亮度的转换。

　　编码是指怎样通过网络把矩形象素点的数据发送出去。每一个矩形象素点的数据被加了一个前缀包括它在屏幕上的位置，矩形象素点的宽度和高度，以及一个“编码类型”来描述该象素的编码方式。然后是经过编码的数据本身。

　　目前的编码方式主要有Raw、CopyRect、RRE、Hextile 和ZRLE.在实际应用中我们一般使用ZRLE、Hextile 和CopyRect，因为它们提供了典型桌面的最好压缩。其他可能的编码方式还包括，用于静态图片的JPEG和用于动态图像有效传输的MPEG。协议可以通过增加新的编码方式来进行扩展。（编码的具体描述见其它文章）

五、协议扩展(添加新的编码方式)

　　协议可以通过以下方式进行扩展：

　　新的编码方式：

　　一种新的协议可以通过与现存的客户端和服务端进行相关兼容的添加。因为现存的服务器将会忽略它们所不支持的新编码方式。所以客户端通过新的编码方式进行请求也就不会有结果返回。

　　伪编码方式：

　　除了真正的编码方式，客户端也可以请求“伪编码”通告服务器，它支持某一协议的扩展。服务器如果不支持这种扩展，那么它将忽略。值得注意的是：客户端必须先假设服务器端不支持这种扩展，直到它获得服务器端支持的确认。

　　新的安全方式：

　　添加一个新型的安全方式会带来无限的灵活性，它通过修改协议的一些行为，但是并没有牺牲现存客户端和服务器端的兼容性。客户端和服务器端可以通过协议好的安全方式进行交流，当然并不一定与RFB协议类似。

　　无论如何你都不应使用不同的版本号。

　　RFB协议的版本是由RealVNC公司来制定的。如果你使用一个不同的协议版本可能与RFB/VNC不兼容，要保证协议的兼容性，请联系RealVNC公司。这样会减少在编码方式和安全类型上的冲突。