In che modo TeamViewer è così veloce?

Question

Mi dispiace per la lunghezza, è un po 'necessario.

Introduzione

sto sviluppando un software di desktop remoto (solo per divertimento) in C# 4.0 per Windows Vista/7. Ho incontrato ostacoli di base: ho un robusto sistema di messaggistica UDP, un design del programma relativamente pulito, ho un mirror driver (il driver gratuito per DFMirage mirror di DemoForge) attivo e funzionante, e ho implementato NAT traversal per tutti Tipi di NAT ad eccezione di NAT simmetrici (presenti nelle situazioni di firewall aziendale).

Per quanto riguarda il trasferimento/condivisione dello schermo, grazie al driver mirror, mi viene automaticamente notificata la modifica delle aree dello schermo e posso semplicemente effettuare il marshalling della bitmap dello schermo in continua evoluzione del mirror driver sulla mia bitmap. Quindi comprimo la regione dello schermo come PNG e la invio dal server al mio client. Le cose sembrano abbastanza buone, ma non abbastanza veloci. È lento come VNC (btw, non uso il protocollo VNC, solo un protocollo amatoriale personalizzato).

Dal più lento software desktop remoto al più veloce, l'elenco di solito inizia con tutte le implementazioni simili a VNC, quindi sale a Microsoft Windows Remote Desktop ... e poi ... TeamViewer. Non abbastanza sicuro di CrossLoop, LogMeIn - non li ho usati, ma TeamViewer è follemente veloce. È letteralmente vivo. Ho eseguito un comando tree sul prompt dei comandi e aggiornato con 20 ms di ritardo. Posso navigare sul Web solo per pochi millisecondi rispetto al mio portatile. Lo scorrimento verticale del codice in Visual Studio ha un tempo di ritardo di 50 ms. Pensa a quanto sia robusta la soluzione di trasferimento dello schermo di TeamViewer per ottenere tutto ciò.

I VNC utilizzano ganci basati su poll per rilevare il cambio dello schermo e catturare/confrontare lo schermo con forza bruta nei peggiori casi. Al loro meglio, usano un driver mirror come DFMirage. Sono a questo livello E usano qualcosa chiamato il protocollo RFB.

Microsoft Windows Remote Desktop sembra essere un gradino più in alto rispetto a VNC. Ho sentito, da qualche parte su StackOverflow, che Windows Remote Desktop non invia bitmap dello schermo, ma comandi di disegno reali. È abbastanza brillante, perché può solo inviare un testo semplice (traccia questo rettangolo con questa coordinata e coloralo con questo gradiente)! Remote Desktop è davvero veloce - ed è il modo standard di lavorare da casa. E usa qualcosa chiamato il protocollo RDP.

Ora TeamViewer è un mistero completo per me. Apparentemente, hanno rilasciato il loro codice sorgente per la versione 2 (TeamViewer è la versione 7 a febbraio 2012). Le persone lo hanno letto e hanno detto che la Versione 2 è inutile - che sono solo alcuni miglioramenti rispetto a VNC con NAT traversal automatico.

Ma la versione 7 ... è ridicolmente veloce ora. Voglio dire, è in realtà più veloce di Windows Remote Desktop. Ho trasmesso in streaming i giochi DirectX 3D con TeamViewer (a 1 fps, ma Windows Remote Desktop non consente nemmeno l'esecuzione di DirectX).

A proposito, TeamViewer fa tutto questo senza un driver mirror. C'è un'opzione per installarne uno, e diventa solo un po 'più veloce.

La questione

La mia domanda è: come è TeamViewer così veloce? Non deve essere possibile. Se hai una risoluzione 1920 x 1080 con una profondità pari a 24 bit (la profondità di 16 bit sarebbe notevolmente brutta), sono ancora 6220.800 byte grezzi.Anche usando libjpeg-turbo (una delle librerie di compressione JPG più veloci usate dalle grandi aziende), comprimendola fino a 30KB (siamo estremamente generosi), ci vorrebbe del tempo per instradare i server di TeamViewer (TeamViewer ignora i Corporate Symmetric NAT semplicemente delegando il traffico attraverso i loro server). E quella compressione libjpeg-turbo richiederebbe del tempo per comprimerla. La compressione JPG di alta qualità impiega 175 millisecondi per uno screenshot completo di 1920 x 1080. E quel numero sale se il computer dell'host esegue un processore Atom. Semplicemente non capisco come TeamViewer abbia ottimizzato il trasferimento dello schermo così bene. Ancora una volta, le immagini di piccole dimensioni potrebbero essere molto compresse, ma richiedere almeno dieci decimi di millisecondi per comprimerle. Le immagini di grandi dimensioni non richiedono tempo per comprimerle, ma impiegano molto tempo per essere completate. In qualche modo, TeamViewer completa l'intero processo per ottenere circa 20-25 frame al secondo. Ho usato un monitor di rete, e TeamViewer è ancora senza lag alle velocità di 500 Kbps e 1 Mbps (il software VNC è in ritardo per alcuni secondi a quella velocità di trasferimento). Durante il mio test del prompt dei comandi tree, TeamViewer stava ricevendo dati in entrata ad una velocità di 1 Mbps e ancora in esecuzione 5-6 fps. VNC e il desktop remoto non lo fanno. Così come?

Le risposte saranno un po 'complicata e intricata, quindi si prega di non pubblicare il tuo $ 0.02 se si sta solo andando a dire che è perché usano UDP al posto del TCP (ci credereste che in realtà usano il protocollo TCP altrettanto comunque con successo).

Spero ci sia uno sviluppatore di TeamViewer da qualche parte qui su StackOverflow.

potenziali risposte

aggiornerà questa volta che le persone rispondono.

1. I miei pensieri sono, prima di tutto, che TeamViewer ha un controllo di rete molto fine. Ad esempio, dividono pacchetti di grandi dimensioni solo sotto la dimensione MTU e non sprecano mai un viaggio. Probabilmente hanno tutti i tipi di ganci eleganti per rilevare i cambiamenti dello schermo insieme a confronti di immagini XOR estremamente veloci.

Answer 1

La cosa fondamentale qui probabilmente è che non si vuole trasmettere immagini statiche, ma solo cambia alle immagini, che è essenzialmente analogo al flusso il video.

La mia ipotesi migliore è qualche algoritmo di compensazione del movimento molto efficiente (e fortemente specializzata e ottimizzata), perché la maggior parte della variazione effettiva utilizzo del desktop generico è lineare movimento di elementi (scorrimento di testo, finestre in movimento, ecc contrari alla trasformazione di elementi).

Le prestazioni DirectX 3D di 1 FPS sembrano confermare in qualche misura la mia ipotesi.

Answer 2

sarebbe voluto tempo per percorso attraverso i server di TeamViewer (TeamViewer bypassa NAT simmetrici aziendali semplicemente il proxy il traffico attraverso i loro server)

vi accorgerete che TeamViewer ha bisogno di rado di trasmettere il traffico attraverso i propri server. TeamViewer penetra NAT e reti complicate da NAT usando NAT traversal (penso che sia UDP hole-punching, come Google's libjingle).

Usano i propri server per l'handshake e l'impostazione della connessione, ma la maggior parte delle volte la relazione tra client e server sarà P2P (caso migliore, quando il tremolio della mano è riuscito). Se NAT traversal fallisce, TeamViewer in effetti trasmetterà il traffico attraverso i propri server.

L'ho visto sempre e solo quando un client ha superato il doppio NAT.

Answer 3

Stranamente. ma nella mia esperienza TeamViewer non è più veloce/reattivo di VNC, solo più facile da configurare. Ho un paio di win-boxen che I VNC su OpenVPN in (quindi c'è un altro overhead layer) e questo è su Cable economico (512 su) e trovo che TightVNC sia configurato in modo molto più reattivo di TeamViewer allo stesso box. RDP (naturalmente) ancora di più in quanto, in gran parte, invia comandi di disegno della GUI al posto delle tessere bitmap.

Il che ci porta a:

1. Perché non utilizza VNC? Esistono moltissime soluzioni open source e Tight è probabilmente in cima al suo gioco in questo momento.

2. Le implementazioni VNC avanzate utilizzano la compressione con perdita e ciò sembra ottenere risultati migliori di rispetto alla scelta del PNG. Inoltre, IIRC resto del carico utile è anche schiacciato usando zlib. Bothj Tight e UltraVNC hanno algos ottimizzati, specialmente per Windows. Inoltre, Tight è open source.

3. Se boxen vincere sono la vostra RDP obiettivo primario può essere una scelta migliore, e ha un'implementazione opensource (rdesktop)

4. Se * boxen nix sono il vostro obiettivo primario NX può essere una scelta migliore e ha un open implementazione della sorgente (FreeNX, anche se non ottimizzata come il prodotto proprietario di NoMachine).

Se la compressione JPEG è un problema di prestazioni per l'algo, sono abbastanza sicuro che di confronto delle immagini sarebbe ancora portare via alcune prestazioni. Scommetto che usano la compressione best-case per ogni specifica situazione cioè lossy per i frame di grandi dimensioni, alcuni interni veloci e sporchi, per i più piccoli, confrontano bit di immagini e inviano solo differenze di sorta e molti altri trucchi di ottimizzazione.

E molti di questi trucchi devono essere presenti in Tight> 2.0 poiché, ancora una volta, nella mia esperienza, batte fuori dal rendimento di TeamViewer, YMMV.

Anche la scelta di un runtime compilato JIT su qualcosa come C++ potrebbe richiedere una fetta dal margine delle prestazioni, specialmente nelle macchine con vincoli di memoria (un sacco di ottimizzazione delle prestazioni va in bagno quando Windows inizia a utilizzare intensivamente il file di paging). E avrai bisogno di memoria per mantenere i precedenti stati dell'immagine per il confronto interno in cima a ciò che ti offre il miraggio DF.

Answer 4

Sembra davvero come lo streaming video più dello streaming di immagini, come qualcuno ha suggerito. La compressione JPEG/PNG non è mirata per questi tipi di velocità, quindi dimenticatele.

Immagina di avere un codec di registrazione sul tuo sistema che può registrare in tempo reale un flusso video in entrata (il tuo schermo). Forse un po 'come Fraps. Quindi immagina un codec di riproduzione video sull'altro lato (il client remoto). Come i registratori HD possono farlo (registrare dal vivo e persino riprodurre dal vivo dallo stesso HD), così dovresti, alla fine. L'HD sicuramente non può fornire le immagini più velocemente di quanto tu possa leggere sul display, quindi non è questo il collo di bottiglia. Il collo di bottiglia sono i codec video. Troverai l'encoder molto più un problema rispetto al decodificatore, poiché tutti i decoder sono per lo più gratuiti.

Non sto dicendo che sia semplice; Io stesso ho usato DirectShow per codificare un file video, e non è in tempo reale di gran lunga. Ma dato il giusto codec sono convinto che possa funzionare.

Answer 5

Una risposta in ritardo po ', ma io suggerisco di dare un'occhiata a un progetto non ben conosciuto su CodePlex chiamato ConferenceXP

ConferenceXP è una piattaforma open source di ricerca che fornisce semplice, flessibili e conferenze estensibile e collaborazione utilizzando le reti a banda larga e le funzionalità multimediali avanzate di Microsoft Windows. ConferenceXP aiuta ricercatori ed educatori a sviluppare applicazioni e soluzioni innovative che dispongono di audio e video di qualità broadcast a supporto di ambienti di collaborazione e di apprendimento a distanza distribuiti in tempo reale .

È fornita una fonte completa (è enorme!). Implementa il RTP protocol.