Learn Remote Desktop - Architecture & How VNC/RDP Work

#Introduction

In episode 1 you learned about the origins of remote desktop. Episode 2 goes deeper: how do VNC and RDP actually work behind the scenes? You don't need to become a protocol author, but understanding this architecture will save you when you face slow connections, black screens, or choppy refreshes.

This episode has three focus areas: the server-client communication model in the RFB protocol, the encoding mechanism that determines bandwidth efficiency, and the RDP architecture along with NLA. By the end of this episode, you'll know why VNC sometimes feels "heavy" on slow networks, and why RDP excels in those scenarios.

#VNC Architecture (RFB)

#Server-to-Client Model

VNC works on a server-to-client pattern: the server holds the framebuffer — the pixel representation of the shared screen — and sends chunks of the screen to the viewer. The reverse direction carries only input events: mouse movement, clicks, and key presses.

This is why VNC is so portable: because what's transferred is pixels, not application instructions, VNC can share almost any system that can render graphics — Linux, Windows, even systems with no GUI at all.

#Display, Ports, and vncpasswd

Every VNC server has a display number. Display :0 means port 5900, display :1 means port 5901, and so on, following the formula 5900 + display number. Connections can be made in two formats:

• host:display — for example server:1
• host:port — for example 192.168.1.20:5901

When a server is first created, you must set a password with vncpasswd. This is the password the viewer will be asked for during the handshake:

vncpasswd

The vncpasswd command writes the password to the ~/.vnc/passwd file in encrypted form (DES). This file is used by the server to validate the client when a connection is opened. Security details — including the weaknesses of VNC passwords — will be covered in episode 12.

#Encodings: Compression and Quality

#What Is an Encoding

Because VNC sends pixels, how those pixels are encoded greatly determines speed. This mechanism is called encoding, and each client-server pair agrees on which encoding to use during the handshake. The four most important encodings:

• Raw — send pixels as-is, with no compression. Fastest to process, most bandwidth-hungry.
• Hextile — split the screen into 16x16 tiles and send only the tiles that changed.
• ZRLE — layered zlib compression with run-length encoding; very bandwidth-efficient.
• Tight — a combination of JPEG and zlib; most efficient for photos and smooth gradients.

#How Encodings Affect Quality and Latency

Choosing an encoding is a trade-off between CPU, bandwidth, and quality:

• Tight encoding saves bandwidth but needs more CPU for compression/decompression — ideal for WAN.
• Hextile is light on CPU and quite efficient for small-area changes — good on LAN.
• Raw is only for special cases like debugging, since it consumes bandwidth.

vncviewer -encodings zrle server:1

The -encodings zrle option on vncviewer tells the viewer to prioritize ZRLE. In episode 19 we'll explore this tuning further when we cover performance and bandwidth optimization.

#RDP Architecture

#Bidirectional Client-Server

Unlike VNC, RDP isn't just "sending pixels." RDP is a bidirectional protocol that separates data presentation, input, and peripheral channels into distinct layers. An RDP connection can carry not only the screen and input, but also clipboard, printer, sound, and drive mapping — all in a single session.

The default RDP port is 3389. RDP servers on Linux typically use xrdp, which we'll cover thoroughly in episode 15.

#NLA: Network Level Authentication

One of RDP's key security features is NLA (Network Level Authentication). With NLA, the client must authenticate — usually with user credentials — before the full desktop session is built. This prevents attacks where an attacker interacts with a fake login screen or wastes server resources.

xfreerdp /v:192.168.1.20 /u:arman /sec:nla

The xfreerdp /v:... /sec:nla command forces NLA authentication to the RDP server. Compared to VNC, whose authentication is "password before the screen," RDP authenticates the full user with the Windows/Linux mechanism.

#VNC and RDP Comparison

#When Each One Excels

With an understanding of the architecture, you can compare them fairly:

The rule of thumb: on a LAN with a fast connection, VNC with Tight/Hextile encoding is nearly indistinguishable from RDP. On a WAN with limited bandwidth, RDP almost always wins because its compression was designed for it. But VNC remains the champion for cross-platform use and for cases where you only need to see the screen, not map drives or printers.

LAN  ->  VNC (hextile / tight)
WAN  ->  RDP (NLA + built-in compression)

#Conclusion

Episode 2 opened the black box of VNC and RDP: the server-to-client model in RFB with framebuffer delivery, the 5900 + display port formula, the role of vncpasswd, the Tight/Hextile/ZRLE encoding mechanisms that determine quality and latency, and the RDP architecture with NLA and peripheral channels.

Key takeaways:

• VNC sends pixel framebuffers; RDP is a layered bidirectional protocol.
• The VNC port formula: 5900 plus the display number, and it can be addressed as host:display.
• Encoding determines the bandwidth vs CPU vs quality trade-off.
• Tight saves bandwidth on WAN; Hextile is light and suited for LAN.
• RDP uses NLA: authentication before the full desktop session is created.

In the next episode, episode 3, we start hands-on: installing a VNC server on Linux — choosing between x11vnc, TigerVNC, TightVNC, and GNOME Remote Desktop, complete with install commands for Debian/Ubuntu, RHEL/Rocky, and Arch. Make sure your server machine is ready, because starting this episode we're seriously getting our hands dirty with the terminal.