Wie ist TeamViewer so schnell?

Entschuldigung für die Länge, es ist irgendwie notwendig.

Einführung

Ich entwickle eine Remotedesktopsoftware (nur zum Spaß) in C # 4.0 für Windows Vista / 7. Ich habe grundlegende Hindernisse überwunden: Ich habe ein robustes UDP-Messagingsystem, ein relativ sauberes Programmdesign, einen Spiegeltreiber (den kostenlosen DFMirage-Spiegeltreiber von DemoForge) und NAT-Traversal für alle implementiert NAT-Typen mit Ausnahme von symmetrischen NATs (in Firewall-Situationen von Unternehmen vorhanden).

In Bezug auf die Bildschirmübertragung / -freigabe werde ich dank des Spiegeltreibers automatisch über geänderte Bildschirmbereiche informiert und kann die sich ständig ändernde Bildschirm-Bitmap des Spiegeltreibers einfach in meine eigene Bitmap umwandeln. Dann komprimiere ich den Bildschirmbereich als PNG und sende ihn vom Server an meinen Client. Die Dinge sehen ziemlich gut aus, aber es ist nicht schnell genug. Es ist genauso langsam wie VNC (übrigens verwende ich nicht das VNC-Protokoll, sondern nur ein benutzerdefiniertes Amateurprotokoll).

Von der langsamsten Remotedesktopsoftware bis zur schnellsten beginnt die Liste normalerweise bei allen VNC-ähnlichen Implementierungen und steigt dann auf Microsoft Windows Remotedesktop auf ... und dann auf TeamViewer. Ich bin mir bei CrossLoop, LogMeIn nicht ganz sicher - ich habe sie nicht verwendet, aber TeamViewer ist wahnsinnig schnell. Es ist buchstäblich live. Ich habe einen treeBefehl auf der Eingabeaufforderung ausgeführt und er wurde mit einer Verzögerung von 20 ms aktualisiert. Ich kann nur wenige Millisekunden langsamer im Internet surfen als auf meinem Laptop. Das vertikale Scrollen von Code in Visual Studio hat eine Verzögerungszeit von 50 ms. Überlegen Sie, wie robust die Bildschirmübertragungslösung von TeamViewer sein muss, um all dies zu erreichen.

VNCs verwenden umfragebasierte Hooks, um Bildschirmänderungen zu erkennen und Brute-Force-Bildschirmerfassung / -vergleich im schlimmsten Fall durchzuführen. Im besten Fall verwenden sie einen Spiegeltreiber wie DFMirage. Ich bin auf diesem Niveau. Und sie verwenden das sogenannte RFB-Protokoll.

Microsoft Windows Remote Desktop geht offenbar einen Schritt höher als VNC. Ich habe irgendwo auf StackOverflow gehört, dass Windows Remote Desktop keine Bildschirm-Bitmaps sendet, sondern tatsächliche Zeichenbefehle. Das ist ziemlich brillant, weil es einfach einfachen Text senden kann (zeichnen Sie dieses Rechteck an dieser Koordinate und färben Sie es mit diesem Farbverlauf)! Remotedesktop ist wirklich ziemlich schnell - und es ist die Standardmethode, von zu Hause aus zu arbeiten. Und es wird das sogenannte RDP-Protokoll verwendet.

Jetzt ist mir TeamViewer ein Rätsel. Anscheinend haben sie ihren Quellcode für Version 2 veröffentlicht (TeamViewer ist Version 7 ab Februar 2012). Die Leute haben es gelesen und gesagt, dass Version 2 nutzlos ist - dass es nur ein paar Verbesserungen gegenüber VNC mit automatischer NAT-Durchquerung sind.

Aber Version 7 ... es ist jetzt lächerlich schnell. Ich meine, es ist tatsächlich schneller als Windows Remote Desktop. Ich habe DirectX 3D-Spiele mit TeamViewer gestreamt (mit 1 fps, aber Windows Remote Desktop lässt DirectX nicht einmal laufen).

TeamViewer macht das übrigens alles ohne Spiegeltreiber. Es gibt eine Option, um eine zu installieren, und es wird nur ein bisschen schneller.

Die Frage

Meine Frage ist, wie ist TeamViewer so schnell?Es darf nicht möglich sein. Wenn Sie eine Auflösung von 1920 x 1080 bei einer Tiefe von sogar 24 Bit haben (16-Bit-Tiefe wäre merklich hässlich), sind das immer noch 6.220.800 Bytes Raw. Selbst die Verwendung von libjpeg-turbo (einer der schnellsten JPG-Komprimierungsbibliotheken, die von großen Unternehmen verwendet wird) und die Komprimierung auf 30 KB (seien wir äußerst großzügig) würde einige Zeit in Anspruch nehmen, um die Server von TeamViewer zu durchlaufen (TeamViewer umgeht symmetrische NATs von Unternehmen, indem einfach der Datenverkehr durchgeleitet wird ihre Server). Und diese libjpeg-turbo-Komprimierung würde Zeit brauchen, um komprimiert zu werden. Die JPG-Komprimierung in hoher Qualität dauert 175 Millisekunden für einen vollständigen Screenshot von 1920 x 1080. Und diese Zahl steigt, wenn auf dem Computer des Hosts ein Atom-Prozessor ausgeführt wird. Ich verstehe einfach nicht, wie TeamViewer die Bildschirmübertragung so gut optimiert hat. Auch hier können kleine Bilder stark komprimiert sein. Die Komprimierung dauert jedoch mindestens zehn Millisekunden. Das Komprimieren großer Bilder dauert nicht lange, aber es dauert lange, bis sie fertig sind. Irgendwie schließt TeamViewer diesen gesamten Prozess ab, um ungefähr 20-25 Bilder pro Sekunde zu erhalten. Ich habe einen Netzwerkmonitor verwendet, und TeamViewer ist bei Geschwindigkeiten von 500 Kbit / s und 1 Mbit / s immer noch verzögert (VNC-Software verzögert sich bei dieser Übertragungsrate einige Sekunden). Während meinertreeBeim Eingabeaufforderungstest empfing TeamViewer eingehende Daten mit einer Geschwindigkeit von 1 Mbit / s und führte immer noch 5-6 fps aus. VNC und Remotedesktop tun das nicht. Also, wie?

Die Antworten werden etwas kompliziert und kompliziert sein. Bitte posten Sie Ihre $ 0,02 nicht, wenn Sie nur sagen wollen, dass sie UDP anstelle von TCP verwenden (würden Sie glauben, dass sie TCP tatsächlich genauso erfolgreich verwenden)?

Ich hoffe, dass es hier auf StackOverflow irgendwo einen TeamViewer-Entwickler gibt.

Mögliche Antworten

Wird dies aktualisieren, sobald Leute antworten.

1. Ich bin zuallererst der Meinung, dass TeamViewer eine sehr gute Netzwerksteuerung hat. Zum Beispiel teilen sie große Pakete auf knapp unter die MTU-Größe auf und verschwenden keine Reise. Sie haben wahrscheinlich alle möglichen ausgefallenen Haken, um Bildschirmänderungen zusammen mit extrem schnellen XOR-Bildvergleichen zu erkennen.

Das Grundlegendste dabei ist wahrscheinlich, dass Sie keine statischen Bilder übertragen möchten, sondern nur Änderungen an den Bildern vornehmen möchten , was im Wesentlichen dem Videostream entspricht .

Meine beste Vermutung ist ein sehr effizienter (und stark spezialisierter und optimierter) Bewegungskompensationsalgorithmus, da der größte Teil der tatsächlichen Änderung der allgemeinen Desktop-Nutzung die lineare Bewegung von Elementen (Scrollen von Text, Verschieben von Fenstern usw. im Gegensatz zur Transformation von Elementen) ist.

Die DirectX 3D-Leistung von 1 FPS scheint meine Vermutung in gewissem Maße zu bestätigen.

Die Weiterleitung durch die Server von TeamViewer würde einige Zeit in Anspruch nehmen (TeamViewer umgeht symmetrische NATs von Unternehmen, indem es einfach den Datenverkehr über die Server weiterleitet).

Sie werden feststellen, dass TeamViewer selten Datenverkehr über seine eigenen Server weiterleiten muss. TeamViewer dringt mithilfe von NAT-Traversal in NAT und durch NAT komplizierte Netzwerke ein (ich denke, es ist UDP- Locher , wie Googles Libjingle ).

Sie verwenden ihre eigenen Server, um den Handshake und den Verbindungsaufbau durchzuführen, aber meistens ist die Beziehung zwischen Client und Server P2P (im besten Fall, wenn der Handshake erfolgreich ist). Wenn die NAT-Durchquerung fehlschlägt, leitet TeamViewer den Datenverkehr tatsächlich über seine eigenen Server weiter.

Ich habe dies jedoch nur gesehen, wenn ein Client hinter Double-NAT steckt.

Eine etwas späte Antwort, aber ich schlage vor, Sie werfen einen Blick auf ein nicht bekanntes Codeplex-Projekt namens ConferenceXP

ConferenceXP ist eine Open-Source-Forschungsplattform, die einfache, flexible und erweiterbare Konferenzen und Zusammenarbeit mithilfe von Netzwerken mit hoher Bandbreite und den erweiterten Multimedia-Funktionen von Microsoft Windows bietet. ConferenceXP unterstützt Forscher und Pädagogen bei der Entwicklung innovativer Anwendungen und Lösungen mit Audio- und Videodaten in Sendequalität zur Unterstützung verteilter Zusammenarbeits- und Fernlernumgebungen in Echtzeit.

Die vollständige Quelle (es ist riesig!) Wird bereitgestellt. Es implementiert das RTP-Protokoll .

Es klingt in der Tat mehr nach Video-Streaming als nach Bild-Streaming, wie jemand vorgeschlagen hat. Die JPEG / PNG-Komprimierung ist für diese Geschwindigkeitsarten nicht vorgesehen. Vergessen Sie sie daher.

Stellen Sie sich vor, Sie haben einen Aufzeichnungscodec auf Ihrem System, der einen eingehenden Videostream (Ihren Bildschirm) in Echtzeit aufzeichnen kann. Ein bisschen wie Fraps vielleicht. Stellen Sie sich dann einen Videowiedergabecodec auf der anderen Seite (dem Remote-Client) vor. So wie HD-Rekorder dies können (Live-Aufnahme und sogar Live-Wiedergabe von derselben HD), sollten Sie dies am Ende auch tun. Die HD kann sicherlich keine Bilder schneller liefern, als Sie Ihr Display lesen können. Das ist also kein Engpass. Der Engpass sind die Video-Codecs. Sie werden feststellen, dass der Encoder viel problematischer ist als der Decoder, da alle Decoder größtenteils kostenlos sind.

Ich sage nicht, dass es einfach ist; Ich selbst habe DirectShow zum Codieren einer Videodatei verwendet, und es ist bei weitem nicht in Echtzeit. Aber mit dem richtigen Codec bin ich überzeugt, dass es funktionieren kann.

Meine zufällige Vermutung ist: TV verwendet einen x264- Codec mit einer kommerziellen Lizenz (andernfalls müsste TeamViewer seinen Quellcode veröffentlichen). Irgendwann (vor mehr als 5 Jahren) schrieb der Hauptentwickler von x264 einen Artikel über Verbesserungen, die er für die Codierung mit geringer Verzögerung vorgenommen hat (wenn Sie um einige Frames verzögern, können Encoder besser komprimieren), und er erwähnte einige andere Verbesserungen, die es gab relevant für TeamViewer-ähnliche Verwendung. In diesem Beitrag erwähnte er das Spielen von Beben über Videostream ohne erkennbare Probleme. Damals war ich mir ziemlich sicher, wer der Sponsor dieser Verbesserungen war, da TeamViewer zu dieser Zeit so ziemlich die einzige Option war. x264 ist eine Open Source-Implementierung des H264-Videocodecsund es ist eine wahnsinnig gute Implementierung, es ist die beste. Gleichzeitig ist es sehr gut optimiert. Wahrscheinlich erzielen Sie aufgrund der extrem guten Implementierung von x264 mit TV bei geringerer CPU-Auslastung viel bessere Ergebnisse. AnyDesk und Chrome Remote Desk verwenden libvpx, das nicht so gut ist wie x264 (Optimierung und Videoqualität).

Ich glaube jedoch nicht, dass TeamView das RDP von Microsoft schlagen kann. Für mich ist es das Beste, aber es funktioniert nur zwischen Windows-PCs oder von Mac zu Windows. Fernsehen funktioniert sogar von Handys aus.

Update: Artikel wurde im Januar 2010 geschrieben, so dass die Arbeit vor ungefähr 10 Jahren erledigt wurde. Außerdem habe ich einen Fehler gemacht: Er hat Call of Duty gespielt, nicht Beben. Als Sie Ihre Frage gestellt haben und meine Vermutung richtig ist, hat TeamViewer diese Arbeit seit 3 ​​Jahren verwendet. Lesen Sie diesen Blog-Beitrag aus dem Webarchiv: x264: Die beste Video-Streaming-Plattform mit geringer Latenz der Welt . Als ich den Artikel im Jahr 2010 las, war ich mir sicher, dass das "Startup - das darum gebeten hat, nicht genannt zu werden", das der Autor erwähnt, TeamViewer war.

Seltsamerweise. Nach meiner Erfahrung ist TeamViewer jedoch nicht schneller / reaktionsschneller als VNC, sondern nur einfacher einzurichten. Ich habe ein paar Win-Boxen, in die ich VNC über OpenVPN einbaue (es gibt also eine weitere Overhead-Schicht), und das ist auf billigem Kabel (ab 512), und ich finde, dass TightVNC richtig eingerichtet ist, um auf dieselbe Box viel besser zu reagieren als TeamViewer. RDP (natürlich) umso mehr, als es zum großen Teil GUI-Zeichenbefehle anstelle von Bitmap-Kacheln sendet.

Was uns bringt zu:

1. Warum verwenden Sie VNC nicht? Es gibt eine Vielzahl von Open-Source-Lösungen, und Tight ist wahrscheinlich gerade auf dem neuesten Stand.

2. Fortgeschrittene VNC-Implementierungen verwenden verlustbehaftete Komprimierung und dies scheint bessere Ergebnisse zu erzielen als die von Ihnen gewählte PNG. Außerdem wird beim IIRC der Rest der Nutzlast mit zlib gequetscht. Sowohl j Tight als auch UltraVNC haben sehr optimierte Algen, insbesondere für Windows. Darüber hinaus ist Tight Open Source.

3. Wenn Win Boxen Ihr primäres Ziel sind, ist RDP möglicherweise die bessere Option und verfügt über eine Open Source-Implementierung (rdesktop).

4. Wenn * nix boxen Ihr primäres Ziel ist, ist NX möglicherweise eine bessere Option und verfügt über eine Open Source-Implementierung (FreeNX, wenn auch nicht so optimiert wie das proprietäre Produkt von NoMachine).

Wenn das Komprimieren von JPEG ein Leistungsproblem für Ihr Algo ist, bin ich mir ziemlich sicher, dass der Bildvergleich immer noch die Leistung beeinträchtigen würde. Ich wette, sie verwenden die Best-Case-Komprimierung für jede spezifische Situation, dh verlustbehaftet für große Frames, einige schnell und schmutzig intern verlustfrei für kleinere, vergleichen Bildteile und senden nur verschiedene Sortierungen und eine Reihe anderer Optimierungstricks.

Und viele dieser Tricks müssen in Tight> 2.0 vorhanden sein, da es meiner Erfahrung nach die Leistung von TeamViewer, YMMV, übertrifft.

Auch die Wahl einer JIT-kompilierten Laufzeit über etwas wie C ++ kann Ihren Leistungsvorteil beeinträchtigen, insbesondere bei Computern mit eingeschränktem Speicher (viele Leistungsoptimierungen gehen auf die Toilette, wenn Windows die Auslagerungsdatei intensiv nutzt). Und Sie benötigen Speicher, um frühere Bildzustände für den internen Vergleich auf dem zu halten, was DF Mirage Ihnen bietet.