Gefühlte Geschwindigkeit: Latenz, Transport und die Kosten der Bildqualität

Wenn Nutzer „langsam“ sagen, meinen sie selten Rechenleistung

Eine Gruppe meldet, die Sitzungsumgebung fühle sich zäh an: Tastatureingaben erscheinen verzögert, Scrollen ruckelt. Auf den Session Hosts liegen Prozessor- und Speicherauslastung im grünen Bereich. Beides ist wahr — und es ist kein Widerspruch.

Was ein Mensch als Geschwindigkeit erlebt, ist die Spanne zwischen Tastendruck und Bildschirmreaktion. Sie entsteht aus dem Rundweg zwischen Client und Host, nicht aus der Rechenleistung dahinter. Dieses Modul behandelt die drei Größen, die diesen Rundweg bestimmen: die Laufzeit, den Transport und das, was RDP über die Leitung schickt.

Was RDP überhaupt überträgt

RDP bündelt mehrere Dynamic Virtual Channels in einen Datenkanal: getrennte Kanäle für Grafik, Eingabe, Geräteumleitung, Drucken und weitere. Der mit Abstand größte Anteil ist die Grafik — denn übertragen wird das fertige Bild des entfernten Desktops.

• Übertragen wird nur, was sich ändert. Ohne sichtbare Bildaktualisierung fließen keine Grafikdaten.
• Ist das Clientfenster minimiert, sendet der Session Host überhaupt keine Grafikaktualisierungen mehr.
• Eingaben sind winzig: Für die meisten Vorgänge weniger als 100 Byte vom Client zum Host.
• Selbst eine völlig untätige Sitzung hält die Verbindung — mit Lebenszeichen von rund 20 Byte alle fünf Sekunden.

Dynamic Virtual Channel — Ein eigenständiger Datenkanal innerhalb einer RDP-Verbindung. Grafik, Eingabe, Geräteumleitung und Drucken laufen je in eigenen Kanälen und werden gemeinsam über den gewählten Transport übertragen.

Latenz gegen Bandbreite

Die beiden Größen werden ständig verwechselt, obwohl sie unterschiedliche Symptome erzeugen und auf unterschiedliche Maßnahmen reagieren.

Laufzeit

Bestimmt, wie unmittelbar sich Eingaben anfühlen. Sie folgt der Entfernung und dem Pfad — eine Leitungsverbreiterung ändert daran nichts.

Bandbreite

Bestimmt, wie viel gleichzeitig übertragen werden kann. Relevant für Grafik, Video, Dateiübertragung und Drucken.

Verlust und Schwankung

Zerstören das Erlebnis stärker als eine gleichmäßig etwas höhere Laufzeit — ruckeln statt verzögern.

RDP arbeitet dabei nicht mit festen Obergrenzen. Es misst laufend die verfügbare Bandbreite und die Paketrundlaufzeit und wählt daraufhin Kodierung, Bildrate und Kompression. Steht die Leitung zur Verfügung, nutzt es sie; braucht eine andere Anwendung sie, zieht sich RDP zurück und senkt die Bildqualität. Das ist der Grund, warum dieselbe Umgebung sich an zwei Tagen unterschiedlich anfühlt, ohne dass sich etwas geändert hat.

Was eine Sitzung wirklich kostet

Die Dokumentation nennt Messwerte je Tätigkeit — ein Monitor, 1920×1080, einmal im Standardmodus und einmal im Modus H.264/AVC 444. Die Tabelle lohnt genaues Lesen, weil sie eine verbreitete Annahme widerlegt.

Untätig

0,3 Kbit/s — in beiden Modi.

Textverarbeitung

100–150 Kbit/s im Standardmodus, 200–300 mit H.264/AVC 444.

Tabellenkalkulation

150–200 Kbit/s im Standardmodus, 400–500 mit H.264/AVC 444.

Präsentationen

4–4,5 Mbit/s im Standardmodus, 1,6–1,8 mit H.264/AVC 444.

Grafikreiches Surfen

6–6,5 Mbit/s im Standardmodus, 0,9–1 mit H.264/AVC 444.

Vollbildvideo

7,5–8,5 Mbit/s im Standardmodus, 2,5–3,1 mit H.264/AVC 444.

Die Zahlen gelten für einen Monitor in 1920×1080. Höhere Auflösung, mehrere Monitore oder eine höhere Bildrate der Anwendung erhöhen den Bedarf zusätzlich — und zwar unabhängig von der Tätigkeit.

Der Transport: erst TCP, dann UDP

Jede Verbindung beginnt mit einem TCP-basierten Reverse-Connect-Transport über das Azure-Virtual-Desktop-Gateway. Danach versucht RDP, parallel eine UDP-Verbindung aufzubauen — RDP Shortpath.

Der Unterschied ist spürbar: UDP liefert laut Dokumentation eine zuverlässigere Verbindung und gleichmäßigere Latenz, TCP dagegen die beste Verträglichkeit mit beliebigen Netzkonfigurationen und die höchste Erfolgsquote beim Verbindungsaufbau. Gelingt Shortpath, wandern alle virtuellen Kanäle — Grafik, Eingabe, Geräteumleitung — auf den neuen Transport.

Zwei Wege zum UDP-Transport

Verwaltete Netze

Direkte Sicht über ExpressRoute oder VPN. Auf den Session Hosts lauscht ein UDP-Port — standardmäßig 3390.

Öffentliche Netze, direkt

Über STUN: Client und Host ermitteln ihre öffentlichen Adressen und verbinden sich direkt.

Öffentliche Netze, weitergeleitet

Über TURN: Ein Vermittlungsserver leitet weiter, wenn direkt nichts geht.

• Die Kontaktaufnahme mit dem STUN-Server läuft über UDP-Port 3478.
• Jede Sitzung nutzt einen dynamisch zugewiesenen UDP-Port aus dem Bereich 49152–65535; Port 65330 ist davon ausgenommen, er ist intern von Azure belegt.
• Die TURN-Weiterleitung liegt im Adressbereich 51.5.0.0/16.
• Sind beide Wege verfügbar, gewinnt schlicht der zuerst zustande gekommene — es gibt keine Bewertung, welcher besser wäre.

Warum Shortpath scheitert

Fällt eine Verbindung auf TCP zurück, funktioniert alles weiter — nur eben mit schwankenderer Latenz. Die dokumentierten Ursachen sind überschaubar und lohnen eine Prüfliste.

• Eine Firewall blockiert UDP. Dann bleibt nur der TCP-Rückfall.
• TCP-basierte VPN-Lösungen: Sie tragen zwar UDP im Inneren, bringen aber die Überlastkontrolle von TCP mit — die Dokumentation nennt das ausdrücklich als bremsend und empfiehlt UDP-basierte VPNs.
• Doppeltes NAT oder Carrier-Grade-NAT auf dem Weg des Clients.
• Force-Tunneling, wenn Nutzer ohnehin über das Internet zugreifen.
• Cloud-Dienste zur Paketinspektion im Pfad.
• Symmetrisches NAT — etwa bei Azure Firewall zusammen mit NAT Gateway. Dann trägt nur noch die Weiterleitung über TURN.
• Abgeschaltetes UPnP auf dem Heimrouter der Nutzenden verringert die Chance auf eine direkte Verbindung.

Die Gegenrichtung ist genauso wichtig: Damit eine direkte Verbindung überhaupt zustande kommen kann, brauchen die Session Hosts ausgehende UDP-Erreichbarkeit ins Internet. Wo Nutzer sich aufhalten, lässt sich in den meisten Fällen nicht vorhersagen, und entsprechend wenig lässt sich einschränken. Wer den Portbereich verkleinern will, kann das tun — aber er muss ihn öffnen.

Bandbreite bewusst begrenzen

In den meisten Fällen ist eine Begrenzung unnötig und schadet dem Erlebnis. Auf knappen oder nach Volumen abgerechneten Strecken kann sie trotzdem gewollt sein — dann über eine richtlinienbasierte Dienstgüte.

Die Regel greift dabei nicht auf RDP als Anwendung, sondern auf den Dienst dahinter: Sie filtert auf die ausführbare Datei svchost.exe und auf UDP mit Quellport 3390. Per PowerShell entsteht sie über New-NetQosPolicy mit einer Drosselrate in Bit je Sekunde.

Die Stellschrauben heißen RDP-Eigenschaften

Alles, was das Erlebnis steuert, steckt in den RDP-Eigenschaften des Host Pools. Sie landen in der .rdp-Datei, die der Client für jede Ressource erhält, und sie gelten je Pool — nicht je Nutzer und nicht je Client.

Bemerkenswert ist der Auslieferungszustand. Die Standardwerte eines Host Pools sind durchweg großzügig: Zwischenablage, Laufwerke, Drucker, serielle Schnittstellen, Smartcards, USB-Geräte und WebAuthn sind umgeleitet, und auch mehrere Monitore sind erlaubt.

redirectclipboard:i:1

Zwischenablage umgeleitet — Standard.

drivestoredirect:s:*

Alle lokalen Laufwerke in der Sitzung verfügbar — Standard.

redirectprinters:i:1

Lokale Drucker umgeleitet — Standard.

use multimon:i:1

Mehrere Monitore erlaubt — Standard, und unmittelbar bandbreitenwirksam.

videoplaybackmode:i:1

Effizientes Multimedia-Streaming für Videowiedergabe — Standard.

redirectwebauthn:i:1

WebAuthn-Anfragen wandern an das lokale Gerät — Standard.

Jede dieser Eigenschaften ist zugleich eine Erlebnis- und eine Sicherheitsentscheidung. Dieses Modul betrachtet die Bandbreiten- und Funktionsseite; die Frage, welche Umleitung an der Sitzungsgrenze überhaupt erlaubt sein darf, gehört in die Sitzungssicherheit.

Die Diagnose einer zähen Sitzung

Was das Erlebnis noch prägt

• Auflösung und Monitorzahl wirken linear auf den Grafikbedarf — zwei Monitore sind ungefähr der doppelte Aufwand.
• Geräteumleitungen belegen eigene virtuelle Kanäle. Jede aktivierte Umleitung ist zugleich Funktion und Datenpfad; die Sicherheitsseite davon behandelt das Modul zur Sitzungssicherheit.
• Drucken kann punktuell enorme Mengen erzeugen — ein 200-seitiger Druckauftrag ist ein anderer Lastfall als ein Arbeitstag in der Textverarbeitung.
• Untätigkeit kostet nichts: Ohne Bildaktualisierung fließt praktisch nichts, und ein minimiertes Fenster erzeugt gar keine Grafikdaten.

Der ehrliche Preis jeder Stellschraube

Hosts näher an die Nutzer

Wirkt auf die Laufzeit wie nichts anderes — und verdoppelt Pool, Abbildpflege und Kapazitätsplanung.

H.264/AVC 444

Entlastet grafikreiche Arbeit deutlich — und verteuert Text- und Tabellenarbeit spürbar.

Auflösung senken

Senkt den Bedarf sofort — und ist für die Betroffenen die sichtbarste Verschlechterung von allen.

Umleitungen abschalten

Spart Kanäle und schließt Datenpfade — und nimmt Nutzern Funktionen, die sie für ihre Arbeit brauchen.

Drosselung per Dienstgüte

Macht Volumen planbar — und begrenzt das Erlebnis genau dann, wenn viel los ist. Sie setzt zudem Shortpath für verwaltete Netze voraus.

Keine dieser Maßnahmen ist umsonst. Die Reihenfolge im Betrieb ist trotzdem meist dieselbe: erst messen, wen es trifft und wie weit er entfernt ist; dann den Transport prüfen; dann die Tätigkeit gegen die Leitung halten. Alles davor ist Raten.

Und eine Warnung zum Schluss, die aus der Natur der dynamischen Anpassung folgt: Weil RDP Bildqualität und Bildrate laufend an die gemessenen Netzbedingungen anpasst, verbirgt es leichte Verschlechterungen. Eine Strecke, die langsam schlechter wird, erzeugt lange keine Fehlermeldung — sie erzeugt ein Bild, das ein wenig unschärfer und ein wenig träger wird. Nutzer gewöhnen sich daran und melden erst, wenn es unerträglich ist. Wer das Erlebnis steuern will, misst deshalb Laufzeit und Transport regelmäßig, statt auf Meldungen zu warten.