Remote Desktop Protocols

VNC (Virtual Network Computing) represents a fundamentally different philosophy from RDP's Windows-centric approach. Developed at AT&T's Cambridge Research Laboratory in the late 1990s, VNC was designed around a single, powerful principle: the remote framebuffer should be accessible from anywhere, to any system, using any platform.

This philosophy led to the Remote Framebuffer (RFB) protocol—an elegantly simple specification that treats the remote desktop as a rectangular array of pixels. The server continuously updates this framebuffer as the desktop changes; the client displays it and sends input events back. This conceptual simplicity enables remarkable interoperability: a VNC client on macOS can control a Windows server, a Linux thin client can access a Raspberry Pi, and embedded devices can provide remote interfaces on any browser.

VNC's openness has spawned a diverse ecosystem of implementations. Unlike RDP, which is controlled by Microsoft, the RFB protocol specification has been publicly available since VNC's inception. This openness has produced dozens of VNC implementations—both commercial and open-source—each optimizing for different use cases while maintaining core interoperability.

Understanding VNC is essential for cross-platform remote access, embedded systems, Unix/Linux administration, and scenarios where platform flexibility outweighs the advanced features of proprietary alternatives.

The Remote Framebuffer (RFB) protocol is the foundation of all VNC implementations. Understanding RFB is essential because its design decisions—both strengths and limitations—cascade through every VNC deployment.

Design Philosophy

RFB was designed with several key principles:

1. Thin Client: The client should be as simple as possible, requiring minimal processing power. This enables VNC viewers on constrained devices.

2. Stateless Updates: The server is responsible for managing state. If the client loses track of display state, the server can resend everything.

3. Display-Agnostic: The protocol knows nothing about windows, applications, or UI toolkits. It sees only pixels.

4. Encoding Flexibility: Multiple encoding methods allow optimization for different network conditions and content types.

Protocol Overview

RFB is a simple, message-based protocol running over TCP:

• Default Port: 5900 (or 5900+display_number for multi-display servers)
• Transport: TCP (reliable, ordered delivery)
• Direction: Bidirectional, but asymmetric (more data server→client)
• State: Server-driven; client requests updates, server sends them

Connection Establishment

RFB connection proceeds through three phases:

Phase 1: Protocol Version Handshake

Both sides exchange protocol version strings:

RFB 003.008

The format is 'RFB xxx.yyy' where xxx.yyy is the version number. Common versions:

• 3.3: Original version, limited security
• 3.7: Added security type negotiation
• 3.8: Current standard, refined security handling

Phase 2: Security Negotiation

RFB 3.7+ servers send a list of supported security types:

The client selects one security type, authentication proceeds, and the server reports success or failure.

Phase 3: Initialization

The client sends ClientInit containing a single byte 'shared' flag:

• shared=0: Exclusive access; server may disconnect other clients
• shared=1: Shared access; multiple clients may connect simultaneously

The server responds with ServerInit:

• Framebuffer dimensions: Width and height in pixels
• Pixel format: Bits per pixel, color depth, byte order, color model
• Name: Human-readable desktop name string

RFB defines a small set of message types, reflecting its minimalist design philosophy. Understanding these messages is key to analyzing VNC traffic and developing VNC-compatible software.

Client-to-Server Messages

The base protocol defines four client message types:

1. SetPixelFormat (Type 0)

Sent after initialization or when the client wants to change color depth:

Message-type (1 byte): 0
Padding (3 bytes)
Pixel-format (16 bytes): Detailed format specification

This allows bandwidth optimization—requesting 8-bit color instead of 32-bit reduces data by 4x.

2. SetEncodings (Type 2)

Declarates which encoding types the client supports, in preference order:

Message-type (1 byte): 2
Padding (1 byte)
Number-of-encodings (2 bytes)
Encoding-type[n] (4 bytes each): List of supported encodings

The server will use the first encoding from the client's list that it supports. This extensible mechanism allows new encodings without protocol version changes.

3. FramebufferUpdateRequest (Type 3)

The client requests a display update:

Message-type (1 byte): 3
Incremental (1 byte): 0=full update, 1=changes only
X-position (2 bytes): Starting X coordinate
Y-position (2 bytes): Starting Y coordinate
Width (2 bytes): Region width
Height (2 bytes): Region height

Incremental Updates: When incremental=1, the server sends only regions that have changed since the last update. This is the normal operating mode—the client continuously requests incremental updates, creating a polling loop.

Non-Incremental Updates: When incremental=0, the server sends the entire requested region regardless of changes. Used for initial display or recovering from errors.

4. KeyEvent (Type 4)

Keyboard input:

Message-type (1 byte): 4
Down-flag (1 byte): 1=pressed, 0=released
Padding (2 bytes)
Key (4 bytes): X11 keysym value

VNC uses X11 keysym values for key identification—a platform-neutral key encoding. This works well for standard keys but can be problematic for special keys, international layouts, and input methods.

5. PointerEvent (Type 5)

Mouse input:

Message-type (1 byte): 5
Button-mask (1 byte): Bit flags for each button (bit 0=left, 1=middle, 2=right, 3-7=extra)
X-position (2 bytes): Cursor X coordinate
Y-position (2 bytes): Cursor Y coordinate

Pointer events are absolute coordinates, not relative movements. This simplifies the protocol but requires coordinate translation when the client window is scaled.

6. ClientCutText (Type 6)

Clipboard transfer from client:

Message-type (1 byte): 6
Padding (3 bytes)
Length (4 bytes): Text length
Text (length bytes): Latin-1 encoded text

The original protocol specified Latin-1 (ISO 8859-1) encoding, which is problematic for international text. Extensions handle UTF-8 and other content types.

Server-to-Client Messages

The base protocol defines four server message types:

1. FramebufferUpdate (Type 0)

The primary display update message:

Message-type (1 byte): 0
Padding (1 byte)
Number-of-rectangles (2 bytes): Count of following rectangles
Rectangle[n]: Variable-size rectangle data

Each rectangle specifies:

• Position (x, y) and size (width, height)
• Encoding type (determines data format)
• Pixel data (format depends on encoding)

Multiple rectangles in one update allow efficient batching of changes across the screen.

The Update Request/Response Loop

VNC's fundamental operation pattern:

1. Client sends FramebufferUpdateRequest (incremental=1)
2. Server responds with FramebufferUpdate when changes occur
3. Client renders update and immediately sends another request
4. Loop continues indefinitely

This client-driven model gives the client control over update frequency and allows flow control—if the client is slow to render, it delays requesting the next update, naturally throttling the server.

2. Bell (Type 2)

Simple audio notification:

Message-type (1 byte): 2

No additional data—the client plays its default bell sound. Rudimentary audio support compared to RDP's full audio redirection.

3. ServerCutText (Type 3)

Clipboard transfer from server (same format as ClientCutText).

RFB's encoding flexibility is central to VNC's performance characteristics. Different encodings optimize for different scenarios—understanding their trade-offs is essential for tuning VNC deployments.

Raw Encoding (Type 0)

The simplest encoding: uncompressed pixel data in the specified pixel format.

Structure:

• Width × Height × (bits-per-pixel / 8) bytes of pixel data
• Row-major order, no padding

Use Case:

• LAN connections with abundant bandwidth
• When CPU time exceeds network time
• Debugging and protocol analysis

Bandwidth:

• Full HD at 32bpp = 1920 × 1080 × 4 = 8.3 MB per full frame
• At 30 fps (theoretical): 249 MB/s = 2 Gbps

CopyRect Encoding (Type 1)

Copies pixels from another screen location—no pixel data transmitted.

Structure:

Source x-position (2 bytes)
Source y-position (2 bytes)

Use Case:

• Window movement (copy window content to new location)
• Scrolling (copy visible content, update only new rows)
• Any operation that moves pixels without changing them

Bandwidth:

• Only 4 bytes regardless of region size
• Requires client to retain previous framebuffer content

Tight Encoding (Type 7)

Developed by TightVNC, Tight encoding is one of the most sophisticated standard encodings, combining multiple compression strategies:

Components:

1. Basic Compression: Zlib compression of raw pixel data with optional filtering (palette conversion, gradient filter)

2. Gradient Filter: Predicts pixel values based on neighbors, encodes differences. Effective for photographs and gradients.

3. Palette Optimization: For regions with few colors, sends a color palette and indices. Very efficient for UI elements.

4. JPEG Compression: For photographic regions, uses JPEG encoding. Lossy but dramatically reduces size.

Subencoding Types in Tight:

• FillCompression: Single-color fill (1 pixel per region)
• JpegCompression: JPEG-encoded rectangle
• BasicCompression: Zlib with optional gradient/palette filters
• IndexedColor: Palette-based encoding

Quality Control: Tight supports quality levels (-32 to -23 pseudo-encodings) that control JPEG quality. Lower quality = smaller size, more artifacts.

Tight's Adaptive Selection:

Tight analyzes each rectangle and selects the most appropriate method:

• Few colors → Palette encoding
• Gradients/photos → JPEG or gradient filter
• Text → High-quality or lossless

This content-aware selection makes Tight highly effective across diverse desktop content.

ZRLE Encoding (Type 16)

Zlib Run-Length Encoding became the standard encoding in RFB 3.8:

Structure:

1. Divide rectangle into 64×64 tiles
2. For each tile, analyze pixel content
3. Select subencoding based on number of colors:
   • 1 color: Solid tile (1 byte + padding)
   • 2-16 colors: Packed palette (palette + indices)
   • 17-127 colors: RLE or plain RLE
   • 128+ colors: Raw or RLE with variable-length colors
4. Compress entire tile set with Zlib

Advantages:

• Good general-purpose compression
• Efficient for both text and images
• Single Zlib stream reduces overhead

VNC's original security was minimal—reflecting both its 1990s origins and its initial use in trusted network environments. Modern VNC deployments require careful attention to security, using protocol extensions and external mechanisms to protect remote access.

Original VNC Authentication (Type 2)

The base RFB security uses a simple challenge-response mechanism:

1. Server sends 16-byte random challenge
2. Client encrypts challenge using DES with password-derived key
3. Server verifies response

Critical Weaknesses:

• DES encryption: 56-bit keys, trivially breakable with modern hardware
• Password truncation: Only first 8 characters of password used
• No encryption after auth: All subsequent traffic is plaintext
• No server authentication: Client cannot verify server identity
• Brute-force vulnerable: Simple protocol allows rapid password guessing

VNC Authentication should never be used alone for internet-exposed access.

VeNCrypt (Type 19)

VeNCrypt, introduced by VeNCrypt project and adopted by TigerVNC and others, provides a flexible security framework:

VeNCrypt Structure:

1. Protocol version negotiation (VeNCrypt has its own version)
2. Subtype selection from server-offered list
3. TLS handshake (for encrypted modes)
4. Inner authentication (if required)

VeNCrypt Subtypes:

X.509 Certificate Authentication:

With X509 subtypes:

• Server presents certificate; client validates against CA
• Client may present certificate for mutual authentication
• No passwords transmitted; authentication via PKI
• Appropriate for enterprise deployments with existing PKI

SSH Tunneling

The most common method for securing VNC over untrusted networks:

Client → SSH Server (encrypted) → VNC Server (localhost)

Setup:

1. Establish SSH connection to VNC server host
2. Forward local port to remote VNC port: ssh -L 5901:localhost:5900 user@server
3. Connect VNC client to localhost:5901
4. Traffic flows through SSH tunnel

Advantages:

• Uses existing SSH infrastructure and authentication
• Works with any VNC server/client
• Can forward through jump hosts
• SSH key authentication eliminates passwords

Disadvantages:

• Additional setup step
• Two connections to manage
• May break session if SSH connection drops

View-Only and Access Control

Many VNC implementations support access restrictions:

View-Only Mode:

• Client can observe but not send input
• Useful for monitoring, demonstrations, support observation
• Configured per-connection or via separate view-only password

IP-Based Access Control:

• Whitelist allowed source IP ranges
• Block known malicious ranges
• Often implemented in VNC server configuration

Integration with System Authentication:

Advanced VNC implementations integrate with system authentication:

• PAM integration on Linux (system username/password)
• Windows credential provider integration
• LDAP/Active Directory authentication via plugins
• GSSAPI/Kerberos for single sign-on

Clipboard Security:

Clipboard transfer can be a security concern:

• Sensitive data accidentally exposed
• Bidirectional sync may violate data handling policies
• Some implementations allow disabling clipboard separately from input

The open nature of the RFB protocol has spawned a diverse ecosystem of VNC implementations. Each emphasizes different characteristics—understanding the major players helps in selecting the right tool for specific requirements.

TigerVNC

Forked from TightVNC in 2009, TigerVNC is the leading open-source VNC implementation for Linux environments.

Key Features:

• ZRLE and Tight encoding with JPEG support
• VeNCrypt security (TLS, X.509)
• Native Wayland support (ongoing development)
• Xvnc virtual display server for headless sessions
• Viewer available for Windows, macOS, Linux
• Active development and security updates

Best For:

• Linux server administration
• Headless virtual displays
• Enterprise deployments with security requirements

TightVNC

Originated the Tight encoding and was the primary open-source VNC for many years.

Key Features:

• Tight encoding with efficient compression
• File transfer support (TightVNC-specific extension)
• Windows service mode for server
• Simple, lightweight implementation

Status:

• TightVNC 1.x: Original open-source, somewhat dated
• TightVNC 2.x: Commercial reimplementation for Windows
• Development diverged, many users migrated to TigerVNC

TurboVNC

Optimized for high-performance 3D and video workloads:

Key Features:

• Integration with VirtualGL for 3D application remoting
• Hardware-accelerated encoding (JPEG-turbo)
• Extremely efficient for 3D graphics and visualization
• Low-latency optimizations

Use Cases:

• Scientific visualization remoting
• CAD/CAM application access
• Video editing workstations
• Any GPU-accelerated application

RealVNC (VNC Connect)

Commercial implementation from the original VNC developers:

Key Features:

• Cloud-based connectivity (no port forwarding needed)
• End-to-end 256-bit AES encryption
• File transfer, printing, chat
• Enterprise management console
• Native performance optimizations

Editions:

• Home: Free for personal use (limited features)
• Professional: Business use
• Enterprise: Full feature set, team management

UltraVNC

Windows-focused open-source implementation:

Key Features:

• Mirror driver for efficient Windows capture
• File transfer
• MS-Logon authentication (Windows credentials)
• NAT traversal support (repeater)
• Single-click support tool generation

Best For:

• Windows IT support
• Enterprise Windows deployments
• Self-hosted support infrastructure

noVNC

HTML5/WebSocket-based VNC client:

Key Features:

• Runs in any modern web browser
• No client installation required
• WebSocket proxy converts from TCP
• Touch device support
• Copy/paste, mobile optimization

Architecture:

• noVNC JavaScript client runs in browser
• websockify proxy connects WebSocket to VNC server
• Can be embedded in web applications

Use Cases:

• Cloud console access (KVM, VM management)
• Embedded device interfaces
• Kiosk applications
• Support without client deployment

Understanding the fundamental differences between VNC and RDP helps in selecting the appropriate technology and optimizing deployments.

Philosophical Differences

VNC: Platform-Agnostic Simplicity

VNC treats the remote computer as a black box with a screen and input devices. The protocol knows nothing about the operating system, window manager, or applications. This abstraction provides:

• Universal compatibility: any system with a display can be shared
• Simple implementation: clients are straightforward to develop
• Consistent behavior: what you see is what the remote user sees

RDP: Deep Integration

RDP is tightly coupled with Windows internals. It understands Windows graphics subsystems, authentication mechanisms, and system services. This integration enables:

• Superior efficiency for Windows GUI operations
• Rich feature set (RemoteApp, device redirection)
• Advanced security (NLA, smart cards)
• Multi-session support on server editions

Technical Comparison

Session Model:

• VNC: Shares existing display session. If local user is logged in, remote user sees and controls same session.
• RDP: Creates independent session. Multiple users can have separate desktops on the same server.

Display Capture:

• VNC: Captures final rendered framebuffer (pixels after all processing)
• RDP: Intercepts drawing operations before final rendering (can send instructions instead of pixels)

Input Handling:

• VNC: X11 keysyms (platform-independent but imperfect mapping)
• RDP: Windows scancodes with layout synchronization

Bandwidth Efficiency:

• VNC: Content-dependent; ranges from very efficient (static screen) to bandwidth-hungry (video playback)
• RDP: Generally more efficient, especially for Windows UI with GDI remoting; adapts encoding to content

Connection Establishment:

• VNC: Simple handshake, typically seconds
• RDP: Complex negotiation, may take longer but enables feature richness

When to Use Each:

We've conducted a comprehensive exploration of VNC and the RFB protocol, from its elegant simplicity to its diverse implementation ecosystem. Let's consolidate the essential knowledge.

Looking Forward

With comprehensive understanding of both RDP and VNC—the two dominant remote desktop protocols—we're prepared to examine the performance optimization techniques that maximize their effectiveness. The next page explores how network conditions, encoding choices, and client/server tuning affect the remote desktop experience, providing practical guidance for achieving responsive, efficient remote access.