Warum ist RDP über eine schnelle Verbindung träge? — Eingabe, Bildaufbau und Netzwerk getrennt betrachtet

Ein Speedtest meldet Hunderte von Mbit/s, und doch erscheinen im Remotedesktop Zeichen einen Takt zu spät. Scrollen Sie eine Seite voller Fotos, ruckelt der Bildschirm noch stärker.

Der Schlüssel zu diesem Widerspruch ist: viele Daten tragen zu können und auf eine Aktion schnell eine Antwort zu bekommen sind zweierlei. Hinzu kommt, dass der Bildschirm, der als Antwort zurückkommt, auf dem Host-PC erzeugt und auf dem PC vor Ihnen angezeigt wird. Es ist keine Arbeit, die die Netzwerkverbindung allein leistet.¹

Verfolgen wir auf demselben Remotebildschirm, was sich ändert, wenn Sie vom Tippen zum Scrollen und dann zu einer Suche in einer Geschäftsanwendung übergehen. Die Abschnitte 1 bis 4 erklären den Mechanismus, ab Abschnitt 5 folgt der Untersuchungsteil für die tatsächliche Analyse.

1. Eine schnellere Verbindung verkürzt nicht zwangsläufig die Wartezeit auf eine Antwort

Angenommen, Sie tippen ein Zeichen in den Editor auf dem Remoterechner. Was Sie sehen, ist der Bildschirm direkt vor Ihnen, aber der Editor läuft auf dem Host-PC. Ihre Aktion wird dorthin gesendet, die Information über den geänderten Bildschirm kommt hierher zurück, und das Zeichen erscheint.

Welchen Teil dieses Roundtrips stellen die „500 Mbit/s“ aus einem Speedtest also dar?

Es ist eine Zahl dafür, wie viele Daten in einer Sekunde getragen werden können. Auf diese Kapazität kommt es an, wenn die Datei, die Sie herunterladen, groß ist. Was Ihnen beim Tippen eines einzelnen Zeichens auffällt, ist dagegen die Zeit vom Tastendruck bis zur Rückkehr des Ergebnisses. Es ist wie der Unterschied zwischen dem Verbreitern einer Straße und dem Verkürzen der Entfernung zum Ziel.¹

Nehmen wir zur Erklärung an, die Aktion braucht 50 Millisekunden zum Host und die daraus entstehende Bildschirminformation 50 Millisekunden zurück. Dann summiert sich allein die Zeit im Netzwerk auf 100 Millisekunden, also 0,1 Sekunden. Die Verarbeitungszeit auf den PCs an beiden Enden bleibt hier vorerst außen vor.

flowchart TB
    accTitle: Beispiel für die Netzwerkzeit, bis das Ergebnis eines Zeichens zurückkommt
    accDescr: Ein Beispiel, das zur Erklärung je 50 Millisekunden pro Richtung annimmt. Es lässt die Verarbeitungszeit an beiden Enden aus und stellt keine Paketanzahl je Taste dar.
    A["Lokal ein Zeichen tippen"] -->|"Hinweg, 50 ms"| B["Host empfängt die Eingabe"]
    B --> C["Den Bildschirm mit der angewendeten Eingabe senden"]
    C -->|"Rückweg, 50 ms"| D["Das Ergebnis trifft auf Ihrem Rechner ein"]

Abbildung 1: Dauert der Hinweg 50 Millisekunden und der Rückweg 50 Millisekunden, entfallen allein auf das Netzwerk 0,1 Sekunden. Das sind keine gemessenen Werte.

Diese Zeit für den Weg über das Netzwerk und zurück heißt Roundtrip-Zeit (RTT). Selbst wenn Sie auf eine Verbindung wechseln, die mehr tragen kann, bleibt die Wartezeit auf eine Antwort in Abbildung 1 gleich, solange die Roundtrip-Zeit gleich bleibt.¹

Deshalb können Downloads schnell sein, während das Tippen weiterhin einen Takt hinterherhinkt. Betrachten wir als Nächstes den Fall, dass auf derselben Verbindung das Tippen keine Mühe macht, der Bildlauf aber träge wird.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (7 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Bildlauf erhöht die Arbeit beim Senden des Bildschirms

Wenn Sie im Editor ein Zeichen hinzufügen, ändert sich optisch nur ein kleiner Teil des Bildschirms. Scrollen Sie dagegen eine Seite voller Fotos, ändert sich ein weiter Bereich der Anzeige Bild für Bild.

RDP sendet nicht jedes Mal den gesamten Bildschirm unkomprimiert. Es sendet die geänderten Bereiche und hält den Datenverkehr mit inhaltsgerechter Komprimierung und Zwischenspeicherung niedrig. Der Arbeitsaufwand für Aktualisierung und Versand unterscheidet sich zwischen dem Hinzufügen eines Zeichens und Fotos, die sich ständig bewegen.²

flowchart TB
    accTitle: Wie sich die Bildschirmlast zwischen Tippen und Bildlauf ändert
    accDescr: Eine kleine Zeichenänderung und eine fortlaufende Aktualisierung über einen weiten Bereich unterscheiden sich in der Art der Arbeit, den Bildschirm zu erzeugen und zu senden.
    A["Im Editor ein Zeichen hinzufügen"] --> B["Ein kleiner Bereich ändert sich"]
    C["Einen Bildschirm voller Fotos scrollen"] --> D["Ein weiter Bereich ändert sich fortlaufend"]
    B --> E["Der Änderung entsprechend komprimieren und übertragen"]
    D --> E

Abbildung 2: Auf derselben Verbindung unterscheidet sich der Arbeitsaufwand zwischen dem Hinzufügen eines Zeichens und einem weiten Bereich, der sich ständig bewegt.

Dadurch kann es sich beim Lesen eines statischen Dokuments leicht anfühlen, und doch geht der Grafikübertragung der Spielraum aus, sobald Sie zu scrollen beginnen. Auch die Auflösung auf der Remoteseite zu erhöhen oder Monitore hinzuzufügen vergrößert das, was erzeugt und gesendet werden muss.²

Erst jetzt wird klar, warum es sich lohnt, die Auflösung zu senken und zu vergleichen. Es ist kein Zauberspruch, um RDP schneller zu machen, sondern ein Versuch, ob die Reaktionsfähigkeit zurückkehrt, sobald Sie die Arbeit des Erzeugens und Sendens des Bildschirms verringern. Abschnitt 5 behandelt im Einzelnen, wie Sie das ausprobieren.

Wenn das Tippen geht, aber nur der Bildlauf träge ist, kann es daran liegen, dass dieselbe Verbindung weit mehr Bildschirmaktualisierungen bewältigt. Wie steht es dann um den Fall, dass die Verbindung noch Spielraum hat, der Bildschirm aber nicht mitkommt?

3. Auch bei unausgelasteter Verbindung kann der PC, der den Bildschirm erzeugt, Sie warten lassen

Der Bildschirm wird sowohl vor dem Senden als auch nach dem Empfang verarbeitet

Wenn Sie eine Seite mit Fotos scrollen, aktualisiert der Host-PC die Anzeige und wandelt und komprimiert die Bildschirminformation in eine Form, die sich leichter senden lässt. Das ist die Codierung. Der PC vor Ihnen wandelt die eintreffende Information zurück in eine anzeigbare Form. Diese Seite heißt Decodierung.¹

flowchart TB
    accTitle: Bildschirmverarbeitung findet auf beiden Seiten der Verbindung statt
    accDescr: Komprimierung auf dem Host, Übertragung über das Netzwerk sowie Decodierung und Anzeige auf Ihrem eigenen Rechner sind getrennte Schritte, und Bildschirmaktualisierungen fallen zurück, wenn einer davon nicht mitkommt.
    A["Host erzeugt und komprimiert den Bildschirm"] --> B["Die Verbindung trägt die Bildschirminformation"]
    B --> C["Der lokale Rechner wandelt sie zurück in eine anzeigbare Form"]
    C --> D["Auf dem lokalen Bildschirm gezeigt"]

Abbildung 3: Auf dem Host komprimieren, über die Verbindung tragen, auf dem lokalen Rechner in eine Anzeige zurückverwandeln. Jedes ist Arbeit an einem anderen Ort.

Angenommen etwa, das Komprimieren des Bildschirms auf dem Host dauert. Selbst bei unausgelasteter Verbindung warten Sie, bis die zu sendende Information bereit ist. Umgekehrt kommt die Bildschirmaktualisierung auch dann zu spät, wenn die Information zwar eingetroffen ist, der lokale PC aber mit Decodierung und Anzeige nicht mitkommt.³

Der Reflex ist zu denken, der Büro-PC sei leistungsfähig, am lokalen Ende genüge also alles — aber der lokale PC hat weiterhin die Aufgabe, den empfangenen Bildschirm anzuzeigen. Spielraum auf der Verbindung und Spielraum in der Verarbeitung an beiden Enden sind zweierlei.

Friert nur eine Anwendung ein, warten Sie womöglich auf deren Antwort

Betrachten Sie nun einen Fall, in dem auf demselben Remotebildschirm das Drücken von „Suchen“ in einer Geschäftsanwendung diese für mehrere Sekunden einfriert. Nehmen wir zugleich an, Sie können in ein daneben geöffnetes Editor-Fenster normal tippen.

In diesem Fall wollen Sie sehen, worauf die Geschäftsanwendung wartet. Die Anwendung auf dem Host bittet womöglich eine eigene Datenbank, die Suche auszuführen, und die Antwort kommt langsam zurück. Das Lesen einer Datei aus einem freigegebenen Ordner erzeugt dieselbe Art von Warten.⁴

flowchart TB
    accTitle: Jenseits von RDP gibt es noch einen weiteren Gesprächspartner
    accDescr: Zeigt den Fall, dass neben dem Datenverkehr, der lokalen Client und Host verbindet, die Anwendung auf dem Host auf eine Antwort von einem Geschäftsserver wartet.
    A["Lokaler Client"] -->|"RDP"| B["Geschäftsanwendung auf dem Host"]
    B -->|"Such- oder Dateianforderung"| C["Datenbank und Dateifreigaben"]
    C -->|"Die Antwort, auf die die Anwendung wartet"| B

Abbildung 4: Die Geschäftsanwendung jenseits der RDP-Verbindung wartet ihrerseits womöglich auf eine Antwort von noch einem weiteren Server.

Und wenn der Code, der für Bildschirm und Eingabe einer Anwendung zuständig ist, eine lange Aufgabe übernimmt, kommt er nicht zur nächsten Eingabe oder Bildschirmaktualisierung. Ein WPF-UI-Thread, der lange beschäftigt bleibt, erzeugt genau diese Art verzögerter Reaktion. Nur auf die gesamte CPU-Auslastung zu sehen kann ein Warten im Code, der den Bildschirm verwaltet, unsichtbar lassen.⁵

Dass Sie auf einem RDP-Bildschirm warten, heißt nicht, dass RDP Sie warten lässt. Dieser Unterschied „der Editor geht, aber nur die Suche friert ein“ ist ein Anhaltspunkt, den Sie finden können, bevor Sie irgendwelche Netzwerkeinstellungen ändern.

4. Zwischenbilanz: Verbindungsgeschwindigkeit ist nur ein Teil der Reaktionsfähigkeit

Kehren wir zur Ausgangsfrage zurück: Warum ist es träge, wenn die Verbindung schnell ist?

Im Fall des Tippens gab es zwischen dem Senden der Aktion und dem Empfang des Ergebnisses ein Warten auf eine Antwort. Im Fall des Bildlaufs stieg die Menge an Bildschirm, die zu aktualisieren und zu senden ist. Und die Anwendung, die diesen Bildschirm erzeugt, sowie die Grafikverarbeitung auf den PCs an beiden Enden brauchen ebenfalls Zeit.

Eine große Zahl aus einem Speedtest allein sagt Ihnen nicht, ob diese drei in Ordnung sind. Zudem werden der Speedtest-Server und der RDP-Host, der hinter einem VPN oder Gateway liegt, über verschiedene Pfade erreicht. Auch die Senderichtung auf dem Host, der den Bildschirm hinausschiebt, und Stauungen unterwegs spielen mit.¹⁴

Wie angenehm sich RDP anfühlt, entscheidet sich nicht nur daran, wie viel getragen werden kann, sondern daran, wie schnell das Ergebnis einer Aktion sichtbar wird. Damit endet die Erklärung des Mechanismus. Wenn Sie die Langsamkeit tatsächlich untersuchen, wählen Sie mit den folgenden Untersuchungsabschnitten den Vergleich, der zu Ihrem Symptom passt.

5. Untersuchung: Vergleichen Sie zuerst dieselbe Aktion, eine Bedingung nach der anderen

Die Untersuchungsbeispiele setzen den Windows-Client „Remotedesktopverbindung“ und einen Host mit Windows 11 oder Windows Server voraus. Die Befehlsbeispiele zielen auf Windows PowerShell 5.1. Halten Sie Vergleiche auf einem Firmengerät in dem Rahmen, den Ihre Administration erlaubt, und sichern Sie Ihre Arbeit, bevor Sie Einstellungen ändern und sich neu verbinden.

Nutzen Sie die drei obigen Fälle als Einstieg für die Wahl eines Vergleichs. Die Tabelle ist kein Urteil über die Ursache, sondern ein Ausgangspunkt für die Untersuchung.

Wenn der Anmeldebildschirm lange braucht oder es allein bei der Authentifizierung hängt, beginnen Sie mit der Prüfung der Aufzeichnungen zu Verbindungsaufbau und Authentifizierung. Der Einstieg in diese Untersuchung unterscheidet sich von der hier behandelten Eingabe und dem Bildlauf nach dem Verbindungsaufbau.

Ist eine andere Anwendung genauso verzögert?

Tippen Sie in der problematischen Anwendung und im Editor etwa gleich viel Text. Zuerst innerhalb derselben Remotesitzung zu vergleichen lässt Sie den Unterschied zwischen Anwendungen sehen, ohne Host oder Verbindung zu ändern. Prüfen Sie im Task-Manager CPU, Arbeitsspeicher und Datenträger der betreffenden Anwendung auf dem Host sowie die Last des RDP-Clients auf Ihrem eigenen Rechner.⁴

Wenn Sie auf einem anderen Client oder einem anderen erlaubten Pfad vergleichen, wiederholen Sie dort dieselbe Aktion und halten Sie auch das Ergebnis nach dem Zurücknehmen fest. Vergewissern Sie sich auf einem von mehreren Benutzern genutzten Host, dass Sie Ihre eigene Sitzung und Ihre eigenen Prozesse betrachten.

flowchart TB
    accTitle: Begrenzen Sie die Bedingungen, die Sie auf einmal ändern
    accDescr: Ein Ablauf, der eine das Problem reproduzierende Aktion im Ausgangszustand festlegt, nur eine Bedingung ändert und vergleicht und dann auch das Ergebnis nach dem Zurücknehmen prüft.
    A["Dieselbe Aktion mit den ursprünglichen Einstellungen"] --> B["Nur eine Bedingung ändern"]
    B --> C["Dieselbe Aktion wiederholen"]
    C --> D["Zurücknehmen und erneut prüfen"]
    D --> E["Die Bedingung festhalten, die etwas verbessert hat"]

Abbildung 5: Wiederholen Sie dieselbe Aktion im Ausgangszustand, nach der Änderung und nach dem Zurücknehmen und halten Sie fest, welche Bedingung den Unterschied machte.

Auch der Vergleich mit der Arbeit am physischen Bildschirm des Hosts ist aufschlussreich. Beachten Sie jedoch, dass sich Sitzung und Bildaufbaubedingungen zwischen lokalem Arbeiten und RDP unterscheiden können. Gleichen Sie Benutzer, Daten und Anwendungszustand ab und schieben Sie die Ursache nicht auf die Verbindung, nur weil es „am physischen Bildschirm schnell ist“.

Ist der Bildlauf träge, senken Sie die Auflösung auf der Remoteseite

Ändern Sie zuerst entweder die Monitoranzahl oder die Auflösung und scrollen Sie dann dieselbe Seite. Mit mstsc unter Windows können Sie über die Anzeigeeinstellungen vor dem Verbinden oder durch Angabe von Breite und Höhe vergleichen. Prüfen Sie, dass sich der Desktop des Hosts tatsächlich in der Größe geändert hat und nicht nur das Fenster auf Ihrem Rechner kleiner wurde. Manchmal wird ein großer Bildschirm lediglich verkleinert dargestellt.⁶⁷

3840 × 2160 hat die vierfache Pixelzahl von 1920 × 1080, das heißt aber nicht, dass der Datenverkehr immer das Vierfache beträgt. Es hängt von den geänderten Bereichen und davon ab, wie gut die Komprimierung greift. Die Auflösung zu senken ändert außerdem die Grafikverarbeitung an beiden Enden, nicht nur den Verkehr; wenn es etwas verbessert, nehmen Sie das als den Bereich, in dem der Anhaltspunkt liegt.²³

flowchart TB
    accTitle: Was ein Vergleich mit gesenkter Auflösung sagen kann
    accDescr: Die Auflösung auf der Remoteseite zu senken kann sowohl die Grafikverarbeitung als auch die Übertragungslast ändern, sodass eine Verbesserung allein die Ursache nicht auf die Verbindung festlegen kann.
    A["Auflösung auf der Remoteseite senken"] --> B["Grafikverarbeitung auf dem Host ändert sich"]
    A --> C["Die gesendete Informationsmenge ändert sich"]
    A --> D["Anzeigeverarbeitung auf Ihrem Rechner ändert sich"]

Abbildung 6: Die Auflösung zu ändern ist ein Vergleich, der nicht nur die Verbindung betrifft, sondern auch die Grafikverarbeitung auf dem Host und auf Ihrem eigenen Rechner.

Mehrere Bedingungen auf einmal zu ändern, etwa auf einen einzelnen Bildschirm mit niedriger Auflösung zu gehen, ergibt nur einen groben Vergleich. Nehmen Sie nach der Verbesserung einzeln zurück, um die Wirkungen zu trennen, und wählen Sie die Einstellungen für den Alltag auch mit Blick auf die Lesbarkeit von Text.

Wird es langsam, sobald ein Kopier- oder Druckauftrag startet?

Über RDP fließt mehr als der Bildschirm: Auch Informationen für Laufwerke, Drucker und andere Geräte wandern mit. Die Umleitung, die Ihre lokalen Geräte auf der Remoteseite nutzbar macht, kann die Netzwerk- und Verarbeitungslast erhöhen, solange sie genutzt wird. Halten Sie Kopiervorgänge, Cloud-Synchronisierung und Druckaufträge, die Sie selbst gestartet haben, im Rahmen Ihrer Befugnisse an und vergleichen Sie.⁴

flowchart TB
    accTitle: Den Zeitraum vor und nach der Störung auf einer Zeitachse betrachten
    accDescr: Dieselbe Aktion und die Last vor einer Übertragung, während ihr und nach ihrem Anhalten festhalten und vergleichen, wie die Störung mit dieser Arbeit zusammenhängt.
    A["Aktion und Last vor der Übertragung"] --> B["Aktion und Last während der Übertragung"]
    B --> C["Aktion und Last nach dem Anhalten"]
    C --> D["Ob Störung und Erholung zusammenpassen"]

Abbildung 7: Sehen Sie, wie sich die Langsamkeit derselben Aktion und die Last vor der Übertragung, während ihr und nach ihrem Anhalten ändern.

Sie können auch die Umleitung nicht benötigter Geräte einzeln vergleichen. Das ist kein Verfahren, um die vom Betrieb benötigten Audio- und Eingabegeräte pauschal zu deaktivieren oder um Sicherungs- oder Sicherheitsprozesse des Unternehmens eigenmächtig zu stoppen.

6. Untersuchung: Bestätigen Sie mit Zahlen, wo gewartet wird

Bestätigen Sie die Vergleiche aus Abschnitt 5 mit Messungen. Sehen Sie beim Tippen auf die Zahlen für Netzwerk und Eingabewartezeit, beim Bildlauf auf die Zahlen zur Grafikverarbeitung.

Von Ihrem Rechner aus: Netzwerk-Roundtrip und TCP-Verbindung untersuchen

Das Folgende ist ein Beispiel auf Ihrem eigenen Windows-Client. Es setzt voraus, dass Sie sich über das Firmen-LAN oder ein erlaubtes VPN direkt mit dem RDP-Host verbinden und dass der Host den Standard-TCP-Port 3389 nutzt. Der Weg über ein RD-Gateway oder Azure Virtual Desktop ändert sowohl das zu Prüfende als auch den genommenen Pfad. Geben Sie keine Ports frei und ändern Sie keine Firewalleinstellungen.

$target = Read-Host 'Name oder IP-Adresse eines RDP-Hosts, dessen Untersuchung Ihnen erlaubt ist'
if ([string]::IsNullOrWhiteSpace($target)) {
    throw 'Geben Sie das Verbindungsziel an.'
}

# Die ICMP-Antwortzeit mehrfach ansehen. Ein Fehlschlag allein belegt keine RDP-Unerreichbarkeit.
ping.exe -n 20 $target

# Eine Prüfung nur für Konfigurationen, die direkt mit dem Standard-TCP-Port 3389 verbinden.
Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed

ping untersucht die Antwortzeit auf ICMP. Schwanken die Werte zur langsamen Tageszeit stark, halten Sie das fest. ICMP kann auch blockiert sein, dann antwortet nichts. Umgekehrt heißt eine Reihe kleiner Werte nicht, dass Sie die RDP-Grafikübertragung oder die Anwendungsverarbeitung untersucht hätten.⁸

TcpTestSucceeded: True ist ein Ergebnis, das besagt, dass die TCP-Verbindung zu diesem Port gelungen ist. Es misst weder Bandbreite noch UDP noch, wie flüssig Bedienung und Bildschirm nach der Authentifizierung sind. Test-NetConnection hat keinen Schalter -UDP, um UDP zu untersuchen.⁹

Zwanzig ping-Sonden sind eine kurze Beobachtung. Gleichen Sie bei sporadischen Störungen den Zeitpunkt des Symptoms mit den Verbindungsinformationen ab. Azure Virtual Desktop stellt außerdem RTT und geschätzte Bandbreite je Verbindung bereit, aber schließen Sie kurze Hänger nicht allein aufgrund von Mittelwerten aus.¹

Auf dem Host: Das Warten untersuchen, bis die Anwendung die Eingabe abholt

Öffnen Sie perfmon.exe innerhalb der Remotesitzung auf dem Host und fügen Sie, wo die Umgebung es unterstützt, User Input Delay per Process oder User Input Delay per Session hinzu. Die Auswahl von Zielsitzung und -prozess lässt Sie das Warten zwischen dem Einreihen der Eingabe und ihrem Abholen durch die Anwendung beobachten.¹⁰

flowchart TB
    accTitle: Das Intervall, das User Input Delay misst
    accDescr: Das gemessene Intervall reicht von der Eingabewarteschlange auf dem Host bis zum Abholen der Eingabe durch die Anwendung und umfasst weder das Netzwerk noch die Bildschirmanzeige davor und danach.
    A["Eingabe trifft von Ihrem Rechner ein"] --> B["Gelangt in die Eingabewarteschlange auf dem Host"]
    B -->|"Dies wird gemessen"| C["Die Anwendung holt die Eingabe ab"]
    C --> D["Anwendungsverarbeitung und Grafikübertragung"]
    D --> E["Auf Ihrem Rechner angezeigt"]

Abbildung 8: Gemessen wird das Warten in der Eingabewarteschlange auf dem Host. Das ist nicht die Gesamtzeit, bis das Ergebnis auf Ihrem Rechner sichtbar wird.

Der Wert ist die längste Wartezeit innerhalb des Messintervalls. Er wird ab Windows 10 Version 1809 und ab Windows Server 2019 unterstützt, und auf diesen Zielen ist kein Registrierungseintrag zur Aktivierung nötig. Beobachten Sie zunächst im Standardintervall von einer Sekunde. Prüfen Sie Anzeigenamen, verfügbare Leistungsindikatoren und benötigte Berechtigungen gegen Ihre eigene Umgebung.¹⁰

Der Standard-Instanzname je Prozess lautet SessionID:ProcessID <Process Image>. Halten Sie aus PowerShell in derselben Sitzung Zeit und Sitzungs-ID fest.¹⁰¹¹

Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff zzz'
(Get-Process -Id $PID).SessionId
query.exe session

Das Anzeigen der Sitzungen anderer Benutzer kann zusätzliche Berechtigungen erfordern. Gleichen Sie bei Bedarf mit den Aufzeichnungen der Administration ab und entfernen Sie aus geteilten Protokollen Benutzernamen und Hostinformationen, die der Betrieb nicht braucht.¹¹

Selbst wenn dieser Wert niedrig ist, bleiben die Verarbeitung, nachdem die Anwendung die Eingabe abgeholt hat, und die Verzögerung, bis der resultierende Bildschirm zurückkommt, bestehen. Das gemessene Intervall unterscheidet sich von der Roundtrip-Zeit aus Abschnitt 1 und von der empfundenen Zeit zwischen Tastendruck und Erscheinen des Zeichens.

Auf dem Host: Untersuchen, ob Bildschirmaktualisierungen vollständig gesendet werden

Nutzen Sie beim Ruckeln während des Bildlaufs die RemoteFX Graphics-Leistungsindikatoren, wo sie verfügbar sind. Prüfen Sie den Namen der Zielsitzung mit query session oder qwinsta und wählen Sie die passende Instanz. Wo ein Leistungsindikator misst und ob er verfügbar ist, muss gegen Betriebssystem, Hostkonfiguration und Ihre Berechtigungen bestätigt werden.³

Vergleichen Sie während eines Vorgangs, der den Bildschirm aktualisiert, Input Frames/Second mit Output Frames/Second. Ist die Ausgabe niedriger als die Eingabe, gehen unterwegs Frames verloren. Die nach unzureichenden Host-, Netzwerk- und Client-Ressourcen aufgeschlüsselten Frames Skipped/Second-Werte zu betrachten gibt Ihnen einen Anhaltspunkt, wo einzugrenzen ist.³

flowchart TB
    accTitle: Aus verworfenen Frames eingrenzen, wo zu untersuchen ist
    accDescr: Die Eingabe- und Ausgabe-Framezahlen während eines den Bildschirm aktualisierenden Vorgangs vergleichen und mit den Leistungsindikatoren für den Grund des Verwerfens als Anhaltspunkt Verarbeitung, Netzwerk und Anzeigelast abgleichen.
    A["Ein- und Ausgabe beim Bildlauf vergleichen"] --> B["Ist die Ausgabe niedriger, auf verworfene Frames prüfen"]
    B --> C["Die nach Grund aufgeschlüsselten Leistungsindikatoren ansehen"]
    C --> D["Mit Host-, Netzwerk- und lokaler Last abgleichen"]

Abbildung 9: Vergleichen Sie Ein- und Ausgabe beim Bildlauf und gleichen Sie den Grund für verworfene Frames mit der Last auf dem Host, der Verbindung und Ihrem eigenen Rechner ab.

Ist die Framezahl schon auf der Eingabeseite niedrig, aktualisiert die Anwendung den Bildschirm womöglich einfach selten. Eine niedrige Framezahl bei statischem Bildschirm ist nicht ungewöhnlich. Gibt es Aktualisierungen und es ist trotzdem langsam, sehen Sie zusätzlich auf Average Encoding Time, um zu prüfen, ob die Komprimierung auf dem Host dauert.³

Ein Hinweis zum Lesen der Messdokumentation. Die Abbildung in Abschnitt 1 ist eine begriffliche Darstellung zum Verständnis gewöhnlicher Grafikübertragung, keine Behauptung, je Taste werde ein eigenständiges Roundtrip-Paket gesendet. Manche Konfigurationen übertragen Video und Audio über einen eigenen Mechanismus. Nutzen Sie die Protokolle zur Verbindungsqualität von Azure Virtual Desktop und die Dokumentation der Grafik-Leistungsindikatoren, die noch ältere Konfigurationen abdeckt, erst nachdem Sie bestätigt haben, worauf die Funktion zutrifft. Lesen Sie die Zahlen in solcher Dokumentation nicht als gemeinsame Spezifikation im Sinne von „alles RDP ist auf 30 fps begrenzt“.²¹³

7. Untersuchung: Wählen Sie UDP- und GPU-Einstellungen passend zum Befund

Ist das Netzwerk verdächtig, bestätigen Sie zuerst den tatsächlichen Pfad und Transport

RDP nutzt je nach Konfiguration und Netzwerkbedingungen TCP oder UDP. Die Richtlinie „RDP-Transportprotokolle auswählen“ lässt Sie zwischen einer Einstellung, die UDP oder TCP nutzt, und einer, die nur TCP nutzt, wählen. Da es auch ein Verhalten gibt, das TCP nutzt, wenn keine UDP-Verbindung aufgebaut werden kann, sagt die Tatsache, dass Sie verbunden sind, nichts über den Transport. Bestätigen Sie ihn über die Verbindungsinformationen des Clients, die Diagnoseprotokolle des Produkts und die Netzwerkaufzeichnungen der Administration.¹²

flowchart TB
    accTitle: Den Transport bestätigen, bevor Netzwerkeinstellungen verglichen werden
    accDescr: Eine gewöhnliche Direktverbindung von einer über Gateway oder Dienst unterscheiden, den tatsächlichen Pfad und Transport bestätigen und erst dann die erlaubten Vergleiche durchführen.
    A["Der verwendete Client und die Verbindungskonfiguration"] --> B["Tatsächlichen Pfad und ob TCP oder UDP bestätigen"]
    B --> C["Mit dem Zeitpunkt des Symptoms abgleichen"]
    C --> D["Nur die nötigen Einstellungen einzeln vergleichen"]

Abbildung 10: Bestätigen Sie verwendeten Transport und Pfad, gleichen Sie sie mit dem Symptom ab und vergleichen Sie erst dann die nötigen Einstellungen.

RDP Shortpath in Azure Virtual Desktop ist der Mechanismus, der für diesen Dienst einen UDP-Pfad aufbaut. Einschließlich der Nutzung direkter Pfade und Relays lässt er sich nicht in dieselbe Einstellungstabelle stecken wie eine Direktverbindung zu einem hauseigenen PC mit mstsc. Kann Shortpath nicht aufgebaut werden, fällt die Verbindung auf eine TCP-basierte zurück.¹³

Ändern Sie nichts pauschal in der Vorstellung, UDP auszuschalten mache schneller. Gleichen Sie verwendeten Transport, Richtlinien sowie VPN- oder Gateway-Bedingungen ab und vergleichen Sie dann. Die Firewall oder Authentifizierung zu deaktivieren oder den RDP-Port direkt im Internet freizugeben sind keine anzuwendenden Abhilfen.

Ist die Grafikverarbeitung verdächtig, prüfen Sie, ob die GPU dafür genutzt wird

Selbst wenn eine GPU vorhanden ist, folgt daraus nicht, dass der Bildaufbau der Host-Anwendung, die Codierung von RDP und die Decodierung auf Ihrem Rechner sie alle nutzen. Auch Microsofts Dokumentation zur GPU-Konfiguration konfiguriert und überprüft den Bildaufbau in der Remotesitzung und die Hardwarecodierung von Frames getrennt. Untersuchen Sie die unterstützten Betriebssystemversionen, Treiber, Richtlinien und Clientanforderungen.¹⁴

Hat Abschnitt 6 gezeigt, dass die Komprimierungszeit lang ist, ist das der Punkt, an dem die GPU-Nutzung für die Codierung zu prüfen ist. Codierungseinstellungen für eine Anwendung zu ändern, die in der Eingabewarteschlange wartet, zielt an die falsche Stelle. Arbeit, bei der Text lesbar sein soll, und Arbeit, bei der Video flüssig aussehen soll, verlangen zudem unterschiedliche Entscheidungen zwischen Bildqualität, Datenverkehr und Verarbeitungslast.¹⁴²

Entwickler von Geschäftsanwendungen können die Wartezeiten innerhalb einer Anwendung nachvollziehen, indem sie den Empfangszeitpunkt eines Eingabeereignisses, Beginn und Ende der Datenbank- und Dateiverarbeitung sowie den Moment, in dem das Ergebnis die Oberfläche erreichte, jeweils getrennt aufzeichnen. Auch ein Entwurf, der schwere Arbeit vom UI-Thread fernhält, ist wichtig. Beachten Sie, dass ein „Verarbeitung abgeschlossen“-Protokoll auf dem Host keine Aufzeichnung darüber ist, dass die Anzeige auf Ihrem eigenen Bildschirm abgeschlossen wurde.⁵

8. Notizen, die sich bei der Übergabe der Untersuchung lohnen

Beschreiben Sie die langsame Aktion konkret, etwa: „Tippen im Editor ist normal, aber das Scrollen von Fotos stockt.“ Hinterlassen Sie auch die geprüften Bedingungen und die Ergebnisse.

Zeitpunkt des Symptoms, mit Zeitzone:
Host-Betriebssystem, verwendeter Client und Versionen:
Direktverbindung / VPN / RD-Gateway / Azure Virtual Desktop und so weiter:
Die langsame Aktion und Anwendung sowie die Reaktion anderer Anwendungen in derselben Sitzung:
Auflösung und Monitoranzahl auf der Remoteseite:
Gleichzeitig laufende Kopiervorgänge, Druckaufträge und Ähnliches:
Die eine geänderte Bedingung und das Ergebnis nach dem Zurücknehmen:
Auf dem Host und auf Ihrem Rechner beobachtete Last und Leistungsindikatoren:

Wie viel getragen werden kann, wie lange man auf eine Antwort wartet und wie lange es dauert, den Bildschirm zu erzeugen und anzuzeigen. Sobald diese Unterscheidung klar ist, führen Sie „RDP ist langsam“ nicht mehr auf eine einzige Ursache zurück und können bei der Aktion beginnen, die gerade langsam ist.

Verwandte Artikel

• Wie Windows-Sitzungstrennung zu denken ist
• Einen Windows-Datenträger bei 100 % sicher eingrenzen
• Warum dauert „Noch 1 Sekunde“ so lange?

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Ein Speedtest meldet Hunderte von Mbit/s — warum ist die Eingabe in RDP dann langsam?

Wie schnell große Datenmengen bewegt werden und wie lange eine Aktion braucht, bis sie zurückkommt, sind zweierlei. Das Senden der Eingabe, die Anwendungsverarbeitung auf dem Host, das Komprimieren des Bildschirms, die Übertragung und die Anzeige auf Ihrem eigenen Rechner spielen alle mit. Auch der Speedtest-Server und der RDP-Host werden über verschiedene Netzwerkpfade erreicht.

Das Tippen geht, nur der Bildlauf ruckelt. Ist das ein Netzwerkproblem?

Darauf allein lässt sich das nicht eingrenzen. Nehmen die Bildschirmaktualisierungen zu, kommen der Bildaufbau und die Komprimierung auf dem Host, die Übertragung oder das Decodieren und Anzeigen auf Ihrem eigenen Rechner womöglich nicht mit. Ändern Sie Auflösung und Monitoranzahl auf der Remoteseite einzeln und vergleichen Sie, und sehen Sie bei Bedarf auf die Grafik-Leistungsindikatoren.

Wenn der Ping schnell ist, ist die RDP-Kommunikation dann gesund?

Das allein entscheidet es nicht. Ping misst die Antwort auf ICMP und misst weder die RDP-Grafikübertragung noch die Anwendungsverarbeitung. In Konfigurationen über ein RD-Gateway und Ähnliches stimmt womöglich auch der Pfad nicht überein. Unterscheiden Sie bei fehlender Antwort blockiertes ICMP davon, dass RDP selbst nicht erreichbar ist.

Ist „User Input Delay“ die Zeit vom Tastendruck bis zum Erscheinen des Zeichens?

Nein. Es ist ein Leistungsindikator, der misst, wie lange eine Eingabe auf dem Host in der Warteschlange steht, bis der Prozess sie abholt. Es ist nicht die empfundene Verzögerung, die den Netzwerk-Roundtrip, die Anwendungsverarbeitung nach dem Abholen der Eingabe sowie das Komprimieren, Decodieren und Anzeigen des Bildschirms umfasst.

Soll ich UDP deaktivieren, wenn sich RDP langsam anfühlt?

Nicht als pauschale Empfehlung. Prüfen Sie zuerst den tatsächlich verwendeten Transport, den Pfad und die angewendeten Richtlinien. UDP kann nicht verfügbar sein und die Verbindung auf TCP zurückgefallen sein, sodass ein Umschalten auf reines TCP nicht immer schneller macht. Vergleichen Sie unter abgeglichenen Bedingungen mit Erlaubnis Ihrer Administration und nehmen Sie Änderungen zurück, die sich als unnötig erweisen.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.