NX - Turbolader für Linux- und Windows-Terminalserver

NX macht von sich reden: als neue Technik für höchst effiziente Verbindungen zu Terminal- & Applikations-Servern. Selbst bei langsamen Leitungen zeitigt NX "Turbolader"-Effekte. NX beschleunigt Zugriffe auf entfernte X11 (Unix, Linux), RDP (Windows) und VNC Server (beliebiges OS).

Von Horst Bräuner

Vortrag auf dem Business- & Behördenkongress des LinuxTag 2004

Vorwort

Wäre es nicht wünschenswert, von überallher "seine" eigenen Programme, Dokumente, Dateien und Daten benutzen zu können? Und dies ohne immer den eigenen Rechner mitzunehmen? Brauchen die Planer von Desktop- Migrationen nicht mehr Spielräume? Sollten sie nicht Linux- und Windows-Anwendungen fallweise und nach Bedarf, beliebig auf ein und demselben Desktop "mischen" können - ohne erst teure und aufwändige Software installieren zu müssen?

NX macht von sich reden: als neue Technik für höchst effiziente Verbindungen zu Terminal- & Applikations-Servern. Selbst bei langsamen Leitungen zeitigt NX "Turbolader"-Effekte. NX beschleunigt Zugriffe auf entfernte X11 (Unix, Linux), RDP (Windows) und VNC Server (beliebiges OS). NX ist GPL und wird derzeit als Freie Software in KDE eingebaut. Hinsichtlich der Performanz braucht KDE/NX keinen Vergleich zu etablierten, teuren, proprietären Lösungen (Citrix, Tarantella) zu scheuen. Desktop-Migrationen mit Hilfe von KDE/NX gelingen leichter, wie erste Praxisfälle zeigen. NX ermöglicht selbst über langsame Leitungen Verbindungen zu einem entfernten Arbeitsplatzrechner mit graphischer Benutzeroberfläche. Es überwindet zugleich mühelos die Grenzen verschiedener Betriebssysteme und Prozessor-Platformen. Fast beliebig kreuz und quer vermittelt es Sessionzugriffe von Linux, Windows, Solaris, Mac OS X, Zaurus oder iPAQ Clients aus auf Linux-, Solaris-, Windows- oder VNC-Applikationsserver.

NX ist sehr effizient. Es geht sparsam mit Bandbreite um. Trotzdem geniesst der Benutzer eine hervorragende Arbeitsgeschwindigkeit. NX verwendet drei verschiedene Techniken:

eine effiziente Kompression des normalen X-Verkehrs.
einen intelligenten Mechanismus zum Speichern und Wiederverwenden ("Cachen") bereits zuvor übertragener Daten.
eine äusserst drastische Reduzierung zeitraubender X "round-trips" auf beinahe Null.

Problemstellung

Was ist "X" überhaupt? X ist das Grundsystem für grafische Benutzeroberflächen in der Unix-Welt. Die derzeit verbreitetste Version ist X11.

Alten Linux-Hasen ist längst bekannt, warum X11 gerne mit dem Attribut "netzwerktransparent" belegt wird: denn X11 lässt den Anwender beliebige Programme eines weit entfernten Drittrechners "fernsteuern", indem es deren Bildschirm-Anzeige auf den lokalen Bildschirm umlenkt (und entsprechende lokale Tastatur- und Mausbefehle weiterleitet). Innerhalb eines LANs funktioniert das hervorragend und ist eine bewährte Technik. Bei einer Internet-Verbindung reicht jedoch nicht mal eine DSL-Leitung mit 512 kBit/sec für dauerhaft angenehme Arbeitsgeschwindigkeit.

In der Sprachregelung der X-Experten ist der X-Server das (lokale) Programm, welches die Fenster und Dialoge auf den Bildschim malt, und die Maus- und Tastatureingaben des Benutzers entgegennimmt. Der X-Client ist das Program selbst. X-Client und X-Server kommunizieren über das X-Protocol.

X-Client und X-Server sprechen miteinander selbst dann "X", wenn beide auf demselben Rechner zu Hause sind. Falls X-Client (das Programm) und X-Server (die Bildschirmdarstellung) räumlich getrennt und auf verschiedenen Rechner ablaufen, erfolgt die Kommunikation per TCP/IP-Verbindung, über normale Netzwerk-Sockets. Falls sich beide auf ein und demselben Rechner befinden, halten sie ihre Verbindung mittels Unix Domain Sockets aufrecht. (Unix Domain Sockets sind eine spezielle Form von Named Pipes. Named Pipes dienen der Inter Process Communication, IPC).

Das X-Protokoll definiert ca. 160 verschiedene op-codes. op-codes sind im Prinzip Anforderungen des X-Clients an den X-Server (oder umgekehrt, dessen Mitteilungen an den X-Client). Die Client-"requests" enthalten Anweisungen zum Zeichnen von Linien, Punkten und Füllungen. Aus diesen Primitiven setzen sich letztlich die Fenster-Elemente zusammen. Viele X-Client Anforderungen erwarten eine Antwort (reply) vom X-Server. Der X-Server kann den X-Client per event-Benachrichtung über Maus-Betätigung oder Tastatur-Eingaben des Anwenders informieren - oder auch einfach eine Fehlermeldung (error) senden.

Plain Vanilla X Flowchart (showing X Requests, X Replies, X Events and X Errors)

Horst Bräuner

Plain Vanilla X Flowchart (showing X Requests, X Replies, X Events and X Errors)

Zusammengehörige Paare von X-Client-requests und X-Server-replys bilden jeweils einen roundtrip. (Allerdings erfordert nicht jeder request auch tatsächlich einen reply.)

"roundtrips" sind Gift für die Effizienz remote ablaufender X-Client/Server-Verbindungen. Insbesondere bei schmalbandigen Leitungen mit hoher Latenz-Zeit machen sie ihre bremsende Wirkung deutlich geltend. Für ein Übermass an roundtrips verantwortlich ist allerdings nicht das X-Protokoll selbst. Dieses ist eigentlich sehr effektiv konzipiert. Es sind uneffektiv programmierte GUI-Programme (KDE, Gnome) und ihre Basisbibliotheken (Qt, Gtk), denen der "Schwarze Peter" zuzuschieben ist.

Über eine Modem-Verbindung kostet ein roundtrip typischerweise 500 msec Zeitverlust (über eine Internetverbindung lässt dieser sich leicht per ping messen).

Bis zu einem gewissen Punkt kann eine höhere Leitungskapazität die remote X11-Geschwindigkeit noch steigern. Allerdings nützt es der Geschwindigkeit dann nichts, die Leitung dicker zu machen, wenn die Applikation bei ungenutzter Bandbreite "Däumchen dreht", weil es auf die Antwort des X-Servers warten muss. Typischerweise rechnete man seither bei Linux-Terminalservern pro aktivem Benutzer eine Bandbreite von ca. 5 MBit/sec. In einem 100 MBit-LAN wird es ab 15 Benutzern bereits sehr eng...

Microsoft und Citrix hatten hier lange Zeit die Nasen vorn: RDP- oder ICA/Metaframe-Verbindungen zu Windows Terminal Servern waren bei gleichen Leitungsbedingungen deutlich performanter als das traditionelle Unix-"X". Citrix kann berets über ISDN-Leitungen (64 kBit/sec) gut laufen.

Lösung

Von der italienischen Software-Firma NoMachine entwickelt und unter die GPL gestellt, macht NX langsamen Linux- und Unix-Terminalservern jetzt Beine.

Horst Bräuner

Flowchart mit NX

Der NX-Turbo beschleunigt die remote-Darstellung und -Verwendung von X-Programmen über langsame Verbindungen auf eine Geschwindigkeit, die um Grössenordungen schneller ist als das "pure X11". Einige Messwerte machen die Gewinne durch NX deutlich.

KDE-Aufstart. Der Aufstart einer KDE-Session lässt bei einer "normalen" und unkomprimierten X-Session ca. 4,5 bis 6 MegaByte über die Leitung wandern, bei jedem Hochfahren. Unter Verwendung einer "ssh -C"-Option (Standardkomprimierungs-Verfahren bei SSH) fliessen immer noch knapp 1,9 MByte über den Draht. Bei einer NX-Verbindung sind es nur noch ca. 35 kByte (beim 2. und jedem späteren Start...).
Mozilla-Start über GSM-Modem. Mozilla-1.2 initiiert für seine Startphase ca. 6.000 roundtrips. GSM-Modemverbindungen (als Standardfunktion mit jedem Mobiltelefon möglich) stellen eine Bandbreite von 9.600 Baud für Datenübertragung zur Verfügung. Ein roundtrip bei einer GSM-Modem-Verbindung benötigt typischerweise ca. 500 Millisekunden. Startet Mozilla per X über einen 9600 Baud GSM-Modem-Link, reicht die nötige Wartezeit buchstäblich aus, um eine Tasse Kaffee aufzubrühen und zu geniessen: es sind ganze 7 Minuten! Per NX, über dieselbe GSM-Modemverbindung, ist Mozilla nach 20 Sekunden betriebsbereit - denn die roundtrips auf der Fernleitung sind nur noch wenige Dutzend an der Zahl.
Effektive X-Kompression und Bandbreiten-Bedarf. In seiner höchsten Kompressionsstufe (für langsame Modemverbindungen) erreicht NX eine effektive Kompression von ca. 70:1 (im Durchschnitt über alle getesteten Applikationen). Einzel-Bereiche erreichen mehr als 200:1 in der Spitze, andere "nur" 10:1. Eine Vollbild-KDE-Session, unter Verwendung von OpenOffice (Textverarbeitung), KMail (e-Mail) und Konqueror (Web-Browser) erfordert im Schnitt ca. 40 kBit/sec Bandbreite, um flüssiges Arbeiten zu ermöglichen. In anderen Worten: eine ISDN-Einwahlverbindung ins Firmennetz reicht locker, um Heimarbeitsplätze zu betreiben. Im LAN nehmen 150 gleichzeitige Sessions nur 60% der nominellen Bandbreite eines ungeswitchten 10 MBit/sec-Links weg. Bei Einsatz von geswitchten 100 MBit-Netzen ist Bandbreite erst recht kein Schwachpunkt mehr.