RFB协议详解：VNC图形界面远程访问的核心通信标准

5星 · 超过95%的资源需积分: 50 170 浏览量更新于2024-07-20 收藏 110KB PDF 举报

RFB协议，全称为Remote Framebuffer Protocol（远程帧缓冲协议），是Virtual Network Computing（VNC）的核心组成部分。VNC是一个广泛应用于远程访问图形用户界面的工具，它允许客户端通过网络连接查看和控制另一台计算机上的操作系统和应用程序。由于其工作在帧缓冲层，使得RFB协议适用于几乎所有的窗口系统和应用环境。该文档由Internet Engineering Task Force (IETF)的T. Richardson和J. Levine共同编写，属于信息性文档，于2011年3月发布，其标准编号为RFC 6143。IETF发布此类文档旨在分享技术知识，而非作为互联网标准。尽管如此，它代表了IETF社区的共识，并经过了公共审查和互联网工程指导组(IESG)的批准。 RFB协议的主要目标是提供一种高效且可靠的通信机制，使客户端与服务器之间能够交换屏幕更新、键盘输入和鼠标事件，从而实现实时的远程控制。它的设计强调了简单性和兼容性，允许客户端与各种操作系统（如Windows、Linux、Mac OS等）上的服务器无缝协作。在协议实现过程中，RFB包括几个关键组件，例如： 1. 连接阶段：客户端和服务器通过建立TCP连接进行初始化，交换必要的版本信息和加密选项。 2. 认证和授权：可能需要身份验证以确保安全，如密码、证书或SSH隧道。 3. 屏幕编码：支持多种屏幕编码方式，如Zlib压缩、RLE压缩等，以减小数据传输量。 4. 事件流：客户端和服务器间实时传输键入、鼠标移动和按钮点击等事件。 5. 颜色深度和分辨率：协议定义了如何处理不同颜色深度和屏幕分辨率的问题。 6. 多通道支持：允许并发连接，比如多视窗模式或全屏/窗口切换。 7. 安全增强：为了保护隐私，可以启用SSL/TLS加密以加密数据传输。值得注意的是，虽然RFB协议最初是为VNC服务的，但其原理和设计思想也被其他远程桌面和控制软件所采用，成为了远程图形界面通信的标准基础。随着网络安全需求的增加，对RFB协议的安全增强和扩展已成为后续研究和开发的重要方向。总结来说，RFB协议是VNC的核心，它定义了客户端和服务器之间图形界面交互的标准化流程，是远程访问和管理计算机系统的重要工具。了解和掌握RFB协议有助于IT专业人员优化远程访问性能，确保数据安全，以及开发适应现代网络环境的新一代远程控制解决方案。

RFC 6143

The Remote Framebuffer Protocol March 2011

New security types

Adding a new security type gives full flexibility in modifying the

behavior of the protocol without sacrificing compatibility with

existing clients and servers. A client and server that agree on a

new security type can effectively talk whatever protocol they like

after that -- it doesn’t necessarily have to be anything like the

RFB protocol.

See

Section 8 for information on obtaining an ID for a new encoding

or security type.

7. Protocol Messages

The RFB protocol can operate over any reliable transport, either

byte-stream or message based. It usually operates over a TCP/IP

connection. There are three stages to the protocol. First is the

handshaking phase, the purpose of which is to agree upon the protocol

version and the type of security to be used. The second stage is an

initialization phase where the client and server exchange ClientInit

and ServerInit messages. The final stage is the normal protocol

interaction. The client can send whichever messages it wants, and

may receive messages from the server as a result. All these messages

begin with a message-type byte, followed by message-specific data.

The following descriptions of protocol messages use the basic types

U8, U16, U32, S8, S16, and S32. These represent, respectively, 8-,

16-, and 32-bit unsigned integers and 8-, 16-, and 32-bit signed

integers. All multiple-byte integers (other than pixel values

themselves) are in big endian order (most significant byte first).

Some messages use arrays of the basic types, with the number of

entries in the array determined from fields preceding the array.

The type PIXEL means a pixel value of bytesPerPixel bytes, where

bytesPerPixel is the number of bits-per-pixel divided by 8. The

bits-per-pixel is agreed by the client and server, either in the

ServerInit message (

Section 7.3.2) or a SetPixelFormat message

(

Section 7.5.1). See Section 7.4 for the detailed description of the

pixel format.

Several message formats include padding bits or bytes. For maximum

compatibility, messages should be generated with padding set to zero,

but message recipients should not assume padding has any particular

value.

Richardson & Levine Informational [Page 7]

RFC 6143

The Remote Framebuffer Protocol March 2011

7.1. Handshake Messages

When an RFB client and server first connect, they exchange a sequence

of handshake messages that determine the protocol version, what type

of connection security (if any) to use, a password check if the

security type requires it, and some initialization information.

7.1.1. ProtocolVersion Handshake

Handshaking begins by the server sending the client a ProtocolVersion

message. This lets the client know which is the highest RFB protocol

version number supported by the server. The client then replies with

a similar message giving the version number of the protocol that

should actually be used (which may be different to that quoted by the

server). A client should never request a protocol version higher

than that offered by the server. It is intended that both clients

and servers may provide some level of backwards compatibility by this

mechanism.

The only published protocol versions at this time are 3.3, 3.7, and

3.8. Other version numbers are reported by some servers and clients,

but should be interpreted as 3.3 since they do not implement the

different handshake in 3.7 or 3.8. Addition of a new encoding or

pseudo-encoding type does not require a change in protocol version,

since a server can simply ignore encodings it does not understand.

The ProtocolVersion message consists of 12 bytes interpreted as a

string of ASCII characters in the format "RFB xxx.yyy\n" where xxx

and yyy are the major and minor version numbers, left-padded with

zeros:

RFB 003.008\n (hex 52 46 42 20 30 30 33 2e 30 30 38 0a)

7.1.2. Security Handshake

Once the protocol version has been decided, the server and client

must agree on the type of security to be used on the connection. The

server lists the security types that it supports:

+--------------------------+-------------+--------------------------+

| No. of bytes | Type | Description |

| | [Value] | |

+--------------------------+-------------+--------------------------+

| 1 | U8 | number-of-security-types |

| number-of-security-types | U8 array | security-types |

+--------------------------+-------------+--------------------------+

Richardson & Levine Informational [Page 8]

剩余38页未读，继续阅读

house01house

粉丝: 0
资源: 2

RFB协议详解：VNC图形界面远程访问的核心通信标准

myrfb:简单的 RFB 协议实现

VNC源代码及代码笔记 RFB协议分

HBaseGuiClient:用 JavaFX 编写的 Apache HBase 的 GUI 客户端

vnc-rfb-client:纯nodejs RFC 6143（RFB协议VNC）客户端实现，无外部依赖关系

VNC制定的RFB协议分析

RFB协议-中文

js-rfb:RFB协议的前端JavaScript实现

RFB协议中英文参考

RFB协议中文和英文

rfb协议（remote frame buffer）

最新资源