RDP vs VNC: sessions vs screen sharing, security, speed, and when to use each

Short answer: RDP gives you a login session of your own on the remote machine and sends the screen as drawing data and compressed video, with sound, clipboard and drive sharing built in. VNC copies the pixels of a screen that already exists, such as a physical monitor or a virtual machine’s console, to whoever connects. Use RDP for daily work on a Windows server or a Linux desktop. Use VNC to control a Mac, to share a live screen, or, through your provider’s console, to rescue a server whose network or RDP has stopped answering.

Session vs framebuffer: the difference that decides everything

RDP is session-based. When you connect to Windows over RDP, Windows logs you in to a session that exists only for that connection, with its own desktop, programs and clipboard. Nobody sitting at the server sees it. Windows Server allows two administrative RDP sessions at the same time without extra licences. A Windows client edition allows one, and an RDP login there locks the local screen. xrdp brings the same model to Linux: each login starts its own X session.

VNC is framebuffer-based. The server reads an image of a screen, sends the parts that changed, and injects your mouse and keyboard into that same screen. Everyone connected sees the same picture and moves the same pointer. That is exactly what you want for helping someone or for watching a machine boot, and exactly wrong for several people working at once. On Linux, TigerVNC can also create virtual X displays: display :1 listens on port 5901, display :2 on 5902, and each is a separate desktop you manage yourself.

The same idea explains your provider’s console. The hypervisor that runs a virtual server has a VNC server of its own, attached to the virtual graphics card. It shows the picture a monitor would show: firmware, boot messages, the Windows “Getting ready” screen, the login prompt. None of it depends on the network inside the VM.

Which is more secure, RDP or VNC?

RDP

Current Windows encrypts RDP with TLS and, with Network Level Authentication (NLA) enabled, checks your credentials before it builds a desktop. That cuts the work an attacker can make the server do. The weak point is exposure. Port 3389 is scanned constantly, and an internet-facing RDP login gets password guesses around the clock. The fixes are well known: allow the port only from your own IP, use strong passwords and an account lockout policy, and keep NLA on. The full list is in securing a Windows RDP server.

VNC

The base protocol is older and plainer. RFC 6143 defines two security types: none, and a DES challenge-response with the password cut to eight characters, which the RFC itself calls weak and unsuitable for untrusted networks. RFB also encrypts nothing on its own. Modern servers add their own layers. TigerVNC offers TLS-wrapped VNC authentication first by default but still accepts the plain kind, and that default TLS uses no certificate, so it encrypts the session without proving which server you reached. Commercial products bring their own encryption and accounts. Still, the safe default for any VNC server on a VPS is to listen on localhost only and reach it through an SSH tunnel. On the server, start TigerVNC with -localhost (or set localhost in its config), then on your computer:

ssh -N -L 5901:127.0.0.1:5901 alice@203.0.113.10

Leave it running and point the VNC viewer at 127.0.0.1:5901. Replace alice and 203.0.113.10 with your user and server; 5901 is display :1.

Verdict: out of the box, a Windows RDP server is much safer to expose than a typical VNC server. Neither belongs on the open internet without an IP restriction or a tunnel in front of it.

Which is faster?

RDP usually feels faster over the internet, because it sends less. The RDP server knows about windows, text, cursors and repeated bitmaps, caches what the client has already seen, and on current Windows can encode busy regions such as video with H.264 through its graphics pipeline when the client supports it. It detects the available bandwidth, adjusts to it, and can run over UDP. Typing and window dragging stay usable on modest connections.

VNC sends pixels. Scrolling a web page or playing a video changes most of the screen, and all of it has to travel. Encodings such as ZRLE, or Tight with JPEG, cut the size, and a good implementation on a fast link feels fine. Across the internet, the same desktop over VNC is generally more sluggish than over RDP, and VNC carries no sound in the base protocol.

When is each one the right tool?

• Daily work on a Windows server: RDP. It is built into every Windows Server edition, and every platform has a client. A Windows VPS is reached this way.
• A graphical desktop on a Linux server: usually RDP through xrdp, because each user gets a session of their own and the Windows client works unchanged. The setup is in xrdp on Ubuntu and Debian. VNC through TigerVNC is the alternative if you prefer a VNC viewer.
• Controlling a Mac: VNC. macOS has no RDP server, but its Screen Sharing accepts VNC viewers once you allow them in the sharing settings.
• Helping someone at their own screen: VNC or a VNC-based support tool, because you both see the same picture.
• A Windows Home PC: VNC or a third-party tool. Windows Home can connect out over RDP but cannot accept RDP connections.
• A server that does not answer: the provider’s VNC console. It is the only option that works before the operating system has a network.

Which clients do you need?

• RDP from Windows: Remote Desktop Connection (mstsc) is built in. Microsoft’s Windows App is the newer client and also covers macOS, iOS and Android.
• RDP from Linux: Remmina with its RDP plugin, or FreeRDP on the command line.
• VNC from anywhere: TigerVNC Viewer and RealVNC Viewer run on all desktop platforms. On a Mac, the Screen Sharing app connects to VNC servers too, and Remmina handles VNC with its VNC plugin.

To see what a server offers before you install anything, test the ports from your own computer. An open 3389 means RDP; an open 5900 or 5901 usually means a VNC server:

Test-NetConnection 203.0.113.10 -Port 3389
Test-NetConnection 203.0.113.10 -Port 5901

nc -zv -w 5 203.0.113.10 3389
nc -zv -w 5 203.0.113.10 5901

From a browser, the open port checker runs the same TCP test from our server in Amsterdam, one port per check.

RDP and VNC do not get in each other’s way. On a virtual server you already have both: RDP or SSH inside the operating system for daily work, and VNC at the hypervisor for the console. Running a VNC server inside the VM as well is rarely worth the extra open port.

The provider’s VNC console is a rescue tool, not a workstation

Most VPS panels have a browser console: a web-based VNC client connected to the hypervisor, not to anything inside your server. That is its strength. It keeps working in situations where RDP and SSH cannot:

• A firewall rule or a changed port blocks 3389 or 22.
• A broken network configuration leaves the server with no address.
• Windows is still preparing itself after an order or a reinstall, or it is installing updates.
• The machine hangs during boot, or boots into a recovery screen.
• RDP is disabled, or NLA refuses an expired password.

On VMHeaven, every KVM server has this console in the panel. It runs in the browser, with a button that sends Ctrl+Alt+Del to the server, a field that types pasted text into the console for you, and a full-screen mode. A Ctrl+Alt+Del pressed on your own keyboard stays with your own computer, which is why the button exists. On Windows the button opens the security screen; on Linux it may reboot the server, depending on the configuration, so the panel asks first. Logging in through the console uses the Windows console session, which does not take one of the two administrative RDP slots.

For anything longer than a repair, go back to RDP or SSH. Fix what locked you out, then reconnect normally. If you are not sure what that is, Remote Desktop can’t connect walks through the checks in order.

Common mistakes

• A VNC server open on port 5900 to the whole internet with a classic eight-character password. Bind it to localhost and tunnel through SSH.
• RDP open to everyone on 3389. Restrict the firewall rule to your IP addresses; moving the port only reduces the noise.
• VNC for several Linux users at once on a single shared screen. Give each a session of their own through xrdp, or one Xvnc display per user.
• Working day to day in the provider console. It is built for repairs, not comfort: no sound, no file transfer, no shared clipboard.
• Typing a long random password into a VNC console by hand. Use the panel’s paste field, which types the text for you key by key. If characters still come out wrong, the server uses a different keyboard layout than the console assumes (a German layout swaps Y and Z, for example), so check the result in a text field first.

If you want a Windows server you reach over RDP and can always rescue through a console, the Windows RDP plans give you the full Administrator account on a KVM server of your own, with the VNC console and reinstall in the panel. Linux servers on the Standard KVM line come with the same console.

Frequently asked