VNC vs RDP: Wie sich drei Protokollfamilien unterscheiden

Sie versuchen, ein Remote-Access-Tool auszuwählen, und das Marketing listet tausend identische Funktionen auf. Die eigentliche Entscheidung liegt in der zugrunde liegenden Protokollfamilie: wie Pixel erzeugt werden, wie Eingaben geliefert werden und wo der Datenverkehr terminiert. Dieser Artikel vergleicht VNC, RDP und moderne Relay/Codecs anhand der Aspekte, die die Nutzererfahrung wirklich beeinflussen — Bandbreiteneffizienz, Latenz, Sitzungsmodell, NAT‑Traversal und die sicherheitsrelevanten Kompromisse, die IT interessieren sollten.

Drei Protokollfamilien — eine kurze Übersicht

In der Praxis gibt es drei Familien, denen Sie begegnen werden.

• Framebuffer-scrape (klassisches VNC und Forks): der Server erfasst Pixeldaten vom Display und sendet Rechtecke von Pixeln an den Client.
• Display-primitive remoting (Microsoft RDP family): anstatt Pixel zu senden, überträgt der Server höherstufige Zeichenbefehle, Objektlisten oder komprimierte Frame-Deltas und nutzt Caching, Schrift-/Glyph-Übertragungen und virtuelle Kanäle.
• Codec-relay hybrids (AnyDesk, TeamViewer, RustDesk, Tenvo-style tools): verwenden moderne Videocodecs (H.264/AV1/VP8 oder proprietäre), plus Broker-Verbindungen/Relays und aggressive Transporttricks für WANs.

Diese Kategorien spiegeln direkt wider, wie sich ein Tool im Alltag anfühlt: beim Tippen, wie flüssig Video wiedergegeben wird, ob es ohne Firewall-Änderungen über NAT funktioniert und wer Ihre Sitzung sehen kann.

Worin sie sich unterscheiden — die fünf relevanten Achsen

Die meisten Checklisten zählen Screensharing, Dateiübertragung und Chat auf — das sind orthogonale Features. Die Faktoren, die wirklich zählen, sind Bandbreiteneffizienz, Latenz (Round‑Trip für Eingaben), Sitzungsmodell (Konsole vs. Nutzer‑Session), NAT‑Traversal und der Ort, an dem Verschlüsselung terminiert.

Bandbreiteneffizienz: rohe Pixel vs. decodierte Frames

VNC‑artige Framebuffer‑Scraper senden Pixelrechtecke. Ohne Codec erreichen Sie sehr schnell mehrere zehn Megabit: ein unkomprimiertes 1920×1080 RGB‑Frame ist ~6MB, bei 8–10 fps sind Sie bereits bei ~400–500 Mbps. Moderne VNC‑Implementierungen fügen Encodings (Tight, ZRLE) hinzu und können H.264 nutzen, was hilft — historisch wurde VNC jedoch nicht für bandbreitenarme WANs entworfen.

RDP gewinnt in der Regel an Bandbreite bei typischen Office‑Workloads, weil es höherwertige Operationen sendet: Fensteraktualisierungen, Bitmap‑Caching, Text und manchmal GPU‑komprimierte Frames. Bei Produktivitätsaufgaben (E‑Mail, Office, Terminals) liegen RDP‑Sessions über WAN häufig im Bereich von 100–800 kbps, weil wiederkehrende UI‑Elemente gecacht werden und Vektoroperationen kompakt sind.

Codec‑Relay‑Tools verwenden Videocodecs mit Hardwarebeschleunigung und adaptiven Bitraten. Über ein WAN liefern sie in der Regel das beste visuelle Ergebnis pro Mbps für Vollmotion‑Inhalte (Video, Animationen) — etwa 1–5 Mbps für ein vernünftiges 1080p‑Desktopbild, abhängig vom Codec und Bewegung. Sie schneiden auch besser ab, wenn viele Pixel gezeichnet werden (Video‑Wiedergabe, bildschirmintensive Anwendungen) im Vergleich zu einfachem VNC.

Latenz und Eingabefühl: Semantik der Ereignisse zählt

Latenz besteht aus zwei Teilen: Netzwerk‑RTT und Protokollverhalten. VNC sendet rohe Eingabeereignisse und wartet dann auf Pixeländerungen; bei hoher RTT fällt das Tippverhalten träge aus, weil jeder Tastenanschlag eine Paint‑Roundtrip auslösen kann. RDP mildert das, indem es höherstufige Eingaben sendet und der Server lokal rendert, bevor ein Ergebnis zurückkommt; Microsoft hat zudem adaptiven Transport (UDP‑Fallback) und Client‑seitige Vorhersage in neueren Versionen ergänzt, um das Tippen zu glätten.

Codec‑Relay‑Tools lassen sich für niedrige Latenz optimieren, indem sie UDP, Low‑Delay‑Encoder‑Einstellungen und aggressive Frame‑Pacing nutzen. Sie müssen Frames komprimieren, sodass sehr kleine interaktive Elemente (Mauszeiger, Texteinfügemarke) hinterherhinken können, sofern das Tool den Cursor nicht lokal zeichnet oder einen separaten Niedriglatenz‑Kanal für den Pointer verwendet. In der Praxis: für administrative Arbeit und die meisten UIs wirken RDP und moderne Relay‑Codecs reaktionsschnell; klassisches VNC fühlt sich auf latenzstarken Verbindungen oft träge an.

Sitzungsmodell und Mehrbenutzerverhalten

RDP erstellt auf Windows Server/Pro häufig separate virtuelle Sessions — Sie können mehrere unabhängige Logins mit jeweils eigenem Desktop und Nutzerkontext haben. Auf Windows ist das ein relevanter Unterschied: RDP bietet Sitzungsisolation, pro‑Session Credentials und kann headless Server‑Workloads betreiben. Hinweis: Windows 10/11 Home enthält den RDP‑Serverhost mit Mehrbenutzerfunktionen nicht.

VNC spiegelt typischerweise die Konsolen‑Session (die physische Anzeige). Das ist einfach für Screen‑Sharing und Troubleshooting am Arbeitsplatz, eignet sich aber nicht, wenn Sie isolierte Sessions pro Nutzer benötigen. Einige VNC‑Varianten lassen sich so konfigurieren, dass sie virtuelle X11‑Sessions auf Linux erzeugen, aber das ist ein zusätzlicher Konfigurationsschritt.

Codec‑Relay‑Tools spiegeln in der Regel die Konsole per Design (Sie verbinden sich mit dem physischen Desktop) und fügen Multi‑User‑Verwaltungsfunktionen auf Anwendungsebene hinzu: Session‑Einladungen, Berechtigungs‑Prompts oder agentenbasierte unbeaufsichtigte Zugänge. Das Sitzungsmodell wird hier vom Produkt definiert, weniger von der Protokollklasse.

NAT‑Traversal, Ports und reale Konnektivität

Klassische Protokolle erwarten geöffnete Ports: RDP verwendet standardmäßig TCP/3389 und VNC TCP/5900 plus Display‑Offset. Das bedeutet Portfreigaben oder VPNs für Zugriff übers Internet — daher wählen viele Teams Brokered‑Tools. Wenn Sie rohes RDP oder VNC über das Internet betreiben wollen, rechnen Sie mit Firewall‑ und NAT‑Aufwand: Port‑Forwarding, statische IPs oder ein VPN.

Moderne Relay‑basierte Tools implementieren ein Broker+Relay‑Modell: die Clients registrieren sich beim Broker, versuchen Peer‑to‑Peer über STUN/UDP‑Hole‑Punch und fallen auf einen Relay (TURN) zurück, wenn direkte Konnektivität scheitert. Dieses Verhalten erklärt, warum Produkte wie AnyDesk, TeamViewer und Tenvo ohne Port‑Forwarding funktionieren. Lesen Sie unseren Remote Desktop ohne Port‑Forwarding erklärt für eine kompakte Übersicht dieser Techniken.

Sicherheit: Wer kann die Sitzung sehen?

Sicherheit wirkt in Marketingtexten oft simpel, aber die entscheidende Frage ist, wo TLS endet. Eine direkte Peer‑to‑Peer‑Verbindung kann Ende‑zu‑Ende zwischen Clients sein. Wenn eine Sitzung einen verwalteten Relay durchläuft, terminiert TLS beim Relay‑Betreiber — dieser ist technisch in der Lage, Sitzungsdaten zu entschlüsseln und zu inspizieren, weil das Relay den TLS‑Kanal beendet. Jedes Tool, das einen verwalteten Relay nutzt, trägt diese betriebliche Wahrheit unabhängig von Buzzwords.

RDP unterstützt Network Level Authentication (NLA) und lässt sich innerhalb von VPNs betreiben; viele Unternehmen schützen RDP zusätzlich mit Zugangskontrollen. VNC‑Implementierungen variieren stark — manche unterstützen TLS‑Transport, andere nicht; viele benötigen für sicheren Internet‑Einsatz zusätzlich SSH‑ oder VPN‑Tunnels. Unser Primer Ist Remote Desktop sicher? Ein ehrliches Bedrohungsmodell legt die Angreifermodelle dar, gegen die Sie testen sollten.

Wann Sie welche Wahl treffen sollten — Praxisempfehlungen

Wählen Sie nach Anwendungsfall, nicht nach Feature‑Checkbox.

• LAN‑Administration und einfaches Fernsteuern einer lokalen Workstation: VNC oder ein leichtgewichtiges Framebuffer‑Tool ist akzeptabel. Es ist simpel und spiegelt die Konsole.
• Verwalteter Mehrbenutzer‑Serverzugang, Windows‑Server‑Administration oder wenn Sie separate Nutzer‑Sessions und geringere Bandbreite für typische Office‑Aufgaben benötigen: RDP ist in der Regel die beste Wahl.
• Remote‑Support über das öffentliche Internet, gemischte NAT‑Umgebungen oder wenn Sie die beste visuelle Qualität für Video/Artwork brauchen: wählen Sie ein modernes Relay/Codec‑Tool. Diese Tools bieten auch die unkomplizierteste Out‑of‑the‑Box‑Erfahrung über Firewalls hinweg.

Für compliance‑bewusste Deployments wählen Sie ein verwaltetes Relay nur, wenn Sie akzeptieren, dass der Relay‑Betreiber technischen Zugriff auf Sitzungsdaten hat. Self‑Hosting macht nur dann Sinn, wenn eine schriftliche Vorgabe es erfordert (Datenresidenz, isoliertes Netzwerk oder eine explizite Compliance‑Regel). Die Vor‑ und Nachteile behandeln wir in Self‑Hosted Remote Desktop: Warum, wie und was schiefgeht.

Betriebliche Aspekte: Skalierung, Auditierung und TCO

Eine Relay‑Fleet zu betreiben ist mehr als eine VM zu starten. Bereitschaftsdienst, Patching, Zertifikats‑Lifecycle, Geo‑Redundanz und Schlüssel‑Custody sind wiederkehrende Kosten. Ein verwalteter Relay (Tenvo’s Multi‑Region‑Relay ist hier die Standardempfehlung) ist in der Regel günstiger, sobald Sie diese betrieblichen Aufwände einrechnen. Tenvo’s Managed‑Angebot vereinfacht außerdem die Konnektivität über NATs und bietet Free $0 / Lite $2.99/mo / Pro $7.99/mo Pläne — nützliche Preispunkte für Teams, die die TCO abwägen.

Wenn Sie aus Richtliniengründen self‑hosten müssen, kalkulieren Sie die Personentage: rechnen Sie mit Wartungsaufwand und gelegentlichen Ausfällen, wenn Sie nicht in Redundanz und Zertifikatsmanagement investieren. Für eine Checkliste zu Sicherheitskontrollen und Deployment‑Hygiene siehe unsere verlinkten Beiträge weiter oben.

Praktische Checkliste zur Auswahl eines Protokolls/Tools

• Benötigen Sie Konsolen‑Spiegelung oder virtuelle Sessions? (Konsole = VNC/proprietär; virtuell = RDP.)
• Werden Sie über latenzstarke Verbindungen arbeiten? (Wenn ja, bevorzugen Sie RDP oder moderne codec‑basierte Tools gegenüber klassischem VNC.)
• Übertragen Sie Video oder Vollbild‑Animationen? (Codec‑Relay‑Tools handhaben bewegte Inhalte am besten.)
• Verbietet Ihre Organisation Drittanbieter‑Relays? (Wenn ja, bereiten Sie sich auf Self‑Hosting und die daraus entstehende TCO vor.)
• Benötigen Sie Enterprise‑Funktionen wie SSO, Audit‑Logs und Policy‑Kontrollen? (Das sind Produkt‑Level‑Entscheidungen; vergleichen Sie Enterprise‑Angebote und testen Sie Logging im Vorfeld.)

Zwei realistische Performance‑Beispiele

Beispiel 1 — Remote‑Administration über eine 60 ms WAN‑Leitung: RDP oder ein moderner codec‑basierter Relay liefern fast immer ein reaktiveres Tippgefühl als VNC, wegen gecachter Zeichenprimitive und adaptivem Transport.

Beispiel 2 — Ein 1080p‑Video auf der entfernten Maschine von einem anderen Kontinent ansehen: ein Codec‑Relay‑Tool mit H.264/AV1‑Hardware‑Decode benötigt 1–6 Mbps bei guter visueller Qualität; klassisches VNC wirkt entweder blockig oder verbraucht mehrere zehn Megabit, wenn Sie die Framerate erhöhen.

Abschließendes: Passen Sie das Protokoll an das Problem an

Hören Sie auf zu fragen, ob Produkt X Dateiübertragung oder Chat hat — fragen Sie stattdessen, welche Protokollfamilie es nutzt und ob diese Familie zu Ihren Randbedingungen passt: geringe Bandbreite, hohe Latenz, mehrere Nutzer oder Compliance. RDP ist die pragmatische Default‑Wahl für Windows‑Server‑artige Nutzung und bandbreitenarme Produktivität. VNC macht auf LANs für einfache Konsolen‑Spiegelung weiterhin Sinn. Wenn Sie zuverlässige Internet‑Konnektivität, Codec‑Effizienz und minimale Firewall‑Arbeit brauchen, ist ein modernes Relay/Codec‑Produkt praktisch — beachten Sie jedoch stets den Trade‑off durch die Relay‑Termination.

Wenn Sie es praktisch testen möchten: folgen Sie dem Workflow ohne Port‑Forwarding und prüfen Sie Latenz plus Codec‑Qualität auf Ihren tatsächlichen Leitungen. Unser Remote Desktop ohne Port‑Forwarding erklärt beschreibt die Schritte, wie Sie Konnektivität testen, ohne Ihre Firewall‑Regeln zu ändern.

Bereit, ein modernes Relay mit Multi‑Region‑Failover und einfacher Verwaltung auszuprobieren? Laden Sie einen nativen Client für macOS, Windows oder Linux herunter oder testen Sie den Browser‑Client in der öffentlichen Beta bei Tenvo. Unser Managed‑Relay ist die Default‑Empfehlung, sofern Sie keine schriftliche Compliance‑Vorgabe zum Self‑Hosting haben. Holen Sie sich die Clients unter Tenvo herunterladen.