What Is VNC?

Run a Speed Test

VNC — Virtual Network Computing — shares a computer's graphical desktop over a network by transmitting framebuffer updates to the viewer and sending keyboard and mouse input back. Unlike RDP, VNC works across platforms — connecting Windows, macOS, and Linux in any combination.

How VNC Works: The RFB Protocol

VNC is built on the Remote Framebuffer (RFB) protocol, originally developed at Olivetti Research Laboratory and AT&T Laboratories Cambridge in the late 1990s. RFB operates at the level of the pixel framebuffer — the rectangular grid of pixels that makes up the screen — rather than at a higher-level graphical abstraction.

The protocol works as follows: the VNC viewer connects to the VNC server and requests the current screen state. The server sends the full framebuffer initially, then sends only rectangular updates covering the regions that changed since the last frame. The viewer applies these updates to its local copy of the framebuffer and displays the result. When the user interacts with the viewer — typing or moving the mouse — those input events are sent back to the server, which injects them into the remote system's input queue as if a local keyboard and mouse were attached.

VNC Port and Display Numbers

VNC servers use a port numbering scheme tied to X11 display numbers. Display :0 corresponds to port 5900, display :1 to port 5901, display :2 to port 5902, and so on. A VNC server running on a single-display system (the typical case) listens on TCP 5900. When you start a headless VNC session for a second user on display :1, it listens on 5901.

Some VNC server packages also serve a legacy HTTP-based Java applet viewer on port 5800 (5800 + display number), but this functionality is largely obsolete now that browsers no longer support Java applets. Modern browser-based VNC access uses noVNC, which communicates via WebSockets typically on port 6080 or a custom HTTPS port.

VNC Encodings and Performance

The efficiency of a VNC session depends heavily on the encoding used to compress framebuffer updates. Raw encoding sends uncompressed pixel data — fast to encode but uses enormous bandwidth, impractical over anything but a LAN. ZRLE (Zlib Run-Length Encoding) applies zlib compression to run-length-encoded pixel blocks and works well for desktop environments with large areas of solid color. Tight encoding applies JPEG compression to complex regions and zlib to simpler areas, making it the best choice for low-bandwidth connections. Hextile and CoRRE are older encodings still supported for compatibility.

Even with Tight encoding, VNC is slower than RDP on high-latency connections. RDP performs server-side rendering — the Windows machine composes the final display and sends compressed output. VNC sends the raw pixel result after rendering, which means more data travels the network. On a fast local network the difference is imperceptible; over a 50 ms WAN connection, RDP feels significantly more responsive.

VNC Implementations

Several independent VNC implementations exist. RealVNC is the commercial descendant of the original AT&T Labs implementation and offers both free and paid tiers, with cloud-assisted connectivity in its paid version. TigerVNC is an actively maintained open-source fork focused on performance and security, widely used as the default VNC server on Linux distributions. TightVNC targets Windows and emphasizes the Tight encoding for bandwidth efficiency. LibVNCServer is a C library for embedding VNC server and client functionality in other applications.

On macOS, Apple's built-in Screen Sharing feature is a VNC server — it implements the standard RFB protocol and accepts connections from any VNC client. Apple's own Screen Sharing app and Remote Desktop client add proprietary extensions for better performance between Apple devices, but the base VNC compatibility remains.

VNC Security: The Problem with Default Configuration

VNC's default security is inadequate for any internet-facing deployment. The standard VNC authentication mechanism uses a DES-based challenge-response that protects the password exchange but leaves the entire session — every pixel of your screen, every keystroke — transmitted without encryption. An attacker who can observe network traffic between your VNC viewer and server can reconstruct your entire session.

Some VNC implementations support TLS-wrapped connections (VeNCrypt), which adds proper encryption. RealVNC's commercial product uses TLS by default. However, many deployments use default settings, and even VeNCrypt is not universally supported across implementations. The practical recommendation is to always tunnel VNC over SSH or inside a VPN regardless of which VNC software you use.

Tunneling VNC Over SSH

SSH local port forwarding is the standard method for securing VNC connections. The command ssh -L 5901:localhost:5900 user@remote-host creates a tunnel: port 5901 on your local machine forwards to port 5900 on the remote machine through the encrypted SSH channel. You then point your VNC viewer at localhost:5901. All VNC traffic travels inside the SSH tunnel — encrypted and authenticated. The VNC server can be configured to listen only on loopback (127.0.0.1) so it is unreachable without the tunnel, which is the correct configuration for any internet-facing host.

Web-Based VNC with noVNC

noVNC is an open-source HTML5 VNC client that runs entirely in a browser using WebSockets. A WebSocket proxy (typically websockify) bridges the browser's WebSocket connection to the VNC server's TCP socket. This allows full VNC access from any modern browser without installing a VNC client — useful for server management consoles, cloud provider web interfaces, and Proxmox or oVirt VM consoles. noVNC supports Tight and ZRLE encodings and handles clipboard integration. The WebSocket connection can be secured with TLS, making noVNC suitable for production use when properly configured behind an HTTPS reverse proxy.

VNC vs RDP vs TeamViewer Compared

Feature VNC RDP TeamViewer
Platform support (server) Windows, macOS, Linux Windows native; Linux via xrdp Windows, macOS, Linux, mobile
Protocol Open RFB standard Proprietary Microsoft Proprietary TeamViewer
Default port TCP 5900 TCP 3389 TCP 443 / 5938 (relay)
Built-in encryption Weak by default; VeNCrypt optional Yes (TLS) Yes (AES-256)
Performance Good on LAN; slower over WAN Excellent (server-side rendering) Good; adapts to connection quality
Setup complexity Low–Medium (tunnel recommended) Low on Windows Very low (no port forwarding needed)
Cost Free (open source options) Free (included with Windows) Free for personal; paid for commercial

Frequently Asked Questions

What is the difference between VNC and RDP?

VNC and RDP both provide graphical remote desktop access, but they work differently. RDP performs server-side rendering — the remote Windows machine renders the desktop and sends compressed display data optimized for network transmission. VNC transmits raw framebuffer pixel data (with compression), which is less efficient over slow or high-latency connections. RDP is Windows-native and faster; VNC works on any operating system and is cross-platform. VNC also lacks RDP's built-in drive, printer, and audio redirection channels.

What port does VNC use?

VNC uses TCP port 5900 plus the display number. Display :0 uses port 5900, display :1 uses port 5901, display :2 uses port 5902, and so on. When a VNC server is configured with a single display (the most common case), it listens on TCP 5900. Some VNC implementations also offer an HTTP-based viewer on port 5800 that serves a Java applet for browser-based access, though this is largely obsolete. When tunneling VNC over SSH, you forward the remote 5900 to a local port and connect locally.

Is VNC secure without a VPN?

VNC's built-in security is weak by default. The standard VNC authentication uses a challenge-response scheme based on DES that protects the password but leaves the session data unencrypted. Anyone on the network path can watch the framebuffer stream. For any connection over the internet or an untrusted network, VNC must be tunneled over SSH (ssh -L 5901:localhost:5900 user@remote) or carried inside a VPN. Running a VNC server with its port exposed directly to the internet is a serious security risk.

How do I connect to a Linux desktop using VNC?

Install a VNC server on the Linux machine — TigerVNC and TightVNC are common choices. Run vncserver :1 to start a virtual display on port 5901 (set a VNC password with vncpasswd first). On your local machine, open an SSH tunnel: ssh -L 5901:localhost:5901 user@remote-host. Then connect your VNC viewer (RealVNC Viewer, TigerVNC Viewer, or Remmina) to localhost:5901. The session travels encrypted through the SSH tunnel. For persistent desktop sessions, configure the VNC server as a systemd service.

What is the RFB protocol?

RFB stands for Remote Framebuffer Protocol. It is the open protocol underlying all VNC implementations, defined originally by Olivetti Research Laboratory and AT&T Laboratories Cambridge. RFB operates at the level of the framebuffer — the pixel grid representing the screen — rather than at a higher graphical abstraction layer. The server sends rectangular updates of changed screen regions to the viewer; the viewer sends keyboard and mouse events back. The protocol is deliberately simple and platform-independent, which is why VNC works across any operating system combination.

Can VNC access a macOS desktop?

Yes. macOS includes a built-in VNC server under System Settings > General > Sharing > Screen Sharing. Enable Screen Sharing and set a VNC password. Any VNC viewer can then connect to the Mac's IP on port 5900. Apple's own Screen Sharing app (in /System/Library/CoreServices/Applications/) provides the best experience for Mac-to-Mac connections because it uses Apple Remote Desktop extensions. For cross-platform access, standard VNC clients work correctly with macOS's built-in VNC server.

Related Guides

More From This Section