In che modo TeamViewer è così veloce?

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

introduzione

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

Per quanto riguarda il trasferimento / la condivisione dello schermo, grazie al driver mirror, sono automaticamente avvisato delle regioni dello schermo modificate e posso semplicemente eseguire il marshalling della bitmap dello schermo in continua evoluzione del driver del mirror sulla mia bitmap. Quindi comprimo la regione dello schermo come PNG e la invio dal server al mio client. Le cose sembrano piuttosto buone, ma non è abbastanza veloce. È lento quanto VNC (a proposito, non uso il protocollo VNC, solo un protocollo amatoriale personalizzato).

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

I VNC utilizzano hook basati sul poll per rilevare il cambiamento dello schermo e catturare / confrontare lo schermo della forza bruta nel peggiore dei casi. Nel migliore dei casi, usano un driver mirror come DFMirage. Sono a questo livello. E usano qualcosa chiamato il protocollo RFB.

Apparentemente il Desktop remoto di Microsoft Windows supera di un passo 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ò semplicemente inviare un testo semplice (disegna questo rettangolo con questa coordinata e coloralo con questo gradiente)! Il desktop remoto è davvero piuttosto 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). La gente lo ha letto e ha detto che la versione 2 è inutile, che sono solo alcuni miglioramenti rispetto a VNC con attraversamento NAT automatico.

Ma la versione 7 ... è incredibilmente 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 una e diventa solo un po 'più veloce.

La domanda

La mia domanda è: in che modo TeamViewer è così veloce?Non deve essere possibile. Se hai una risoluzione 1920 per 1080 a una profondità anche di 24 bit (una profondità di 16 bit sarebbe notevolmente brutta), questo è ancora 6.220.800 byte grezzi. Anche usando libjpeg-turbo (una delle librerie di compressione JPG più veloci utilizzate dalle grandi aziende), comprimendolo fino a 30 KB (siamo estremamente generosi), ci vorrebbe tempo per instradare attraverso i server di TeamViewer (TeamViewer bypassa i NAT simmetrici aziendali semplicemente inviando traffico attraverso i loro server). E quella compressione libjpeg-turbo richiederebbe del tempo per comprimersi. La compressione JPG di alta qualità richiede 175 millisecondi per uno screenshot completo di 1920 per 1080 per me. E quel numero aumenta se il computer dell'host esegue un processore Atom. Semplicemente non capisco come TeamViewer abbia ottimizzato il loro trasferimento dello schermo così bene. Ancora una volta, le immagini di piccole dimensioni potrebbero essere molto compresse, ma occorrono almeno decine di millisecondi per comprimere. Le immagini di grandi dimensioni non richiedono tempo per essere compresse, ma impiegano molto tempo per passare. 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 a velocità di 500 Kbps e 1 Mbps (ritardo del software VNC per alcuni secondi a quella velocità di trasferimento). Durante il miotreeTest del prompt dei comandi, TeamViewer riceveva i dati in entrata a una velocità di 1 Mbps e continuava a eseguire 5-6 fps. VNC e desktop remoto non lo fanno. Così come?

Le risposte saranno in qualche modo complicate e complesse, quindi per favore non pubblicare i tuoi $ 0,02 se vuoi solo dire che usano UDP invece di TCP (crederesti che effettivamente usano TCP altrettanto correttamente).

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

Risposte potenziali

Lo aggiornerò quando le persone risponderanno.

1. Innanzitutto, penso che TeamViewer abbia un controllo di rete molto preciso. Ad esempio, hanno diviso i pacchetti di grandi dimensioni appena sotto la dimensione MTU e non sprecano mai un viaggio. Probabilmente hanno tutti i tipi di ganci fantasiosi per rilevare i cambiamenti dello schermo insieme a confronti di immagini XOR estremamente veloci.

La cosa fondamentale qui è probabilmente che non si desidera trasmettere immagini statiche ma solo modifiche alle immagini, che è essenzialmente analoga al flusso video .

La mia ipotesi migliore è un algoritmo di compensazione del movimento molto efficiente (e altamente specializzato e ottimizzato), poiché la maggior parte del cambiamento effettivo nell'uso del desktop generico è il movimento lineare degli elementi (scorrimento del testo, spostamento delle finestre, ecc. Rispetto alla trasformazione degli elementi).

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

richiederebbe tempo per instradare i server di TeamViewer (TeamViewer bypassa i NAT simmetrici aziendali semplicemente inviando il traffico attraverso i loro server)

Scoprirai che TeamViewer raramente ha bisogno di inoltrare il traffico attraverso i propri server. TeamViewer penetra in NAT e nelle reti complicate da NAT utilizzando NAT traversal (penso che sia UDP punzonatura , come il libjingle di Google ).

Usano i propri server come intermediario per eseguire l'handshake e la configurazione della connessione, ma il più delle volte la relazione tra client e server sarà P2P (nel migliore dei casi, quando la stretta di mano ha successo). Se l'attraversamento NAT non riesce, TeamViewer inoltra effettivamente il traffico attraverso i propri server.

Tuttavia, l'ho mai visto fare questo solo quando un client era dietro a Double-NAT.

Risposta un po 'in ritardo, ma ti suggerisco di dare un'occhiata a un progetto non ben noto su codeplex chiamato ConferenceXP

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

Viene fornita la fonte completa (è enorme!). Implementa il protocollo RTP .

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 dimenticateli.

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

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

La mia ipotesi casuale è: la TV usa x264 codec che ha una licenza commerciale (altrimenti TeamViewer dovrebbe rilasciare il proprio codice sorgente). Ad un certo punto (più di 5 anni fa), ricordo che lo sviluppatore principale di x264 ha scritto un articolo sui miglioramenti apportati per la codifica a basso ritardo (se il ritardo di alcuni frame gli encoder possono comprimere meglio), oltre a menzionare alcuni altri miglioramenti che erano rilevante per un utilizzo simile a TeamViewer. In quel post ha menzionato la riproduzione del terremoto sul flusso video senza problemi evidenti. All'epoca ero abbastanza sicuro di chi fosse lo sponsor di questi miglioramenti, dato che TeamViewer era praticamente l'unica opzione a quel tempo. x264 è un'implementazione open source di codec video H264 , ed è una pazzesca implementazione, è la migliore. Allo stesso tempo è estremamente ben ottimizzato. Molto probabilmente grazie all'implementazione estremamente buona di x264 si ottengono risultati molto migliori con la TV con un carico di CPU inferiore. AnyDesk e Chrome Remote Desk utilizzano libvpx, che non è buono come x264 (ottimizzazione e qualità video saggia).

Tuttavia, non credo che TeamView possa battere RDP di Microsoft. Per me è il migliore, tuttavia funziona solo tra PC Windows o da Mac a Windows. La TV funziona anche da cellulari.

Aggiornamento: l'articolo è stato scritto nel gennaio 2010, quindi il lavoro è stato svolto circa 10 anni fa. Inoltre, ho fatto un errore: ha giocato a call of duty, non a terremoto. Quando hai pubblicato la tua domanda, se la mia ipotesi è corretta, TeamViewer ha usato quel lavoro per 3 anni. Leggi quel post sul blog dall'archivio web: x264: la migliore piattaforma di streaming video a bassa latenza al mondo . Quando ho letto l'articolo nel 2010, ero sicuro che la "startup - che ha richiesto di non essere nominata" che l'autore menziona fosse TeamViewer.

Stranamente. ma secondo la mia esperienza TeamViewer non è più veloce / più reattivo di VNC, ma solo più facile da configurare. Ho un paio di win-box in cui ho VNC su OpenVPN (quindi c'è un altro layer overhead) e questo è su Cable economico (da 512 in poi) e trovo che TightVNC sia configurato correttamente per essere molto più reattivo di TeamViewer sulla stessa box. RDP (naturalmente) ancora di più, poiché in gran parte invia comandi di disegno della GUI invece di riquadri bitmap.

Il che ci porta a:

1. Perché non stai usando 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 questo sembra ottenere risultati migliori rispetto alla tua scelta di PNG. Inoltre, IIRC anche il resto del payload viene schiacciato usando zlib. Bothj Tight e UltraVNC hanno algoritmi molto ottimizzati, in particolare per Windows. Inoltre, Tight è open source.

3. Se win boxen è il tuo obiettivo primario RDP potrebbe essere un'opzione migliore e ha un'implementazione opensource (rdesktop)

4. Se * nix boxen è il tuo obiettivo principale, NX potrebbe essere un'opzione migliore e ha un'implementazione open source (FreeNX, anche se non ottimizzato come il prodotto proprietario di NoMachine).

Se la compressione di JPEG è un problema di prestazioni per il tuo algo, sono abbastanza sicuro che il confronto delle immagini porterebbe comunque via alcune prestazioni. Scommetto che usano la compressione nel migliore dei casi per ogni situazione specifica, ad es. Con perdita di fotogrammi di grandi dimensioni, alcuni interni veloci e sporchi, per quelli più piccoli, confrontano frammenti di immagini e inviano solo differenze di tipo e un mucchio di altri trucchi di ottimizzazione.

E molti di questi trucchi devono essere presenti in Tight> 2.0 da quando, di nuovo, nella mia esperienza batte di gran lunga il wyse delle prestazioni di TeamViewer, YMMV.

Anche la scelta di un runtime compilato JIT rispetto a qualcosa come C ++ potrebbe prendere una fetta dal limite delle prestazioni, specialmente nelle macchine con memoria limitata (molta ottimizzazione delle prestazioni va in bagno quando Windows inizia a usare intensamente il file di paging). E avrai bisogno di memoria per mantenere gli stati delle immagini precedenti per il confronto interno in cima a ciò che DF Mirage ti offre.