Comment TeamViewer est-il si rapide?

Désolé pour la longueur, c’est plutôt nécessaire.

introduction

Je développe un logiciel de bureau à distance (juste pour le plaisir) en C # 4.0 pour Windows Vista / 7. Je me suis heurté à des obstacles de base: j’ai un système de messagerie UDP robuste, une conception de programme relativement propre, un pilote miroir (le pilote de miroir gratuit DFMirage de DemoForge) et j’ai implémenté un parcours NAT pour tous Types de NAT à l’exception des NAT symésortingques (présents dans les situations de pare-feu d’entreprise).

En ce qui concerne le transfert / partage d’écran, grâce au pilote miroir, je suis automatiquement informé des régions d’écran modifiées et je peux simplement regrouper le bitmap d’écran en constante évolution du pilote miroir sur mon propre bitmap. Ensuite, je compresse la zone d’écran en tant que fichier PNG et l’envoie du serveur à mon client. Les choses ont l’air bien, mais ce n’est pas assez rapide. C’est aussi lent que VNC (d’ailleurs, je n’utilise pas le protocole VNC, juste un protocole amateur personnalisé).

Du logiciel de bureau distant le plus lent au plus rapide, la liste commence généralement à toutes les implémentations de type VNC, puis monte à Microsoft Windows Remote Desktop … puis à TeamViewer. Pas tout à fait sûr de CrossLoop, LogMeIn – je ne les ai pas utilisés, mais TeamViewer est incroyablement rapide. C’est littéralement vivre. J’ai exécuté une commande d’ tree sur l’invite de commande et celle-ci a été mise à jour avec un délai de 20 ms. Je peux naviguer sur le Web quelques millisecondes plus lentement que sur mon ordinateur portable. Le code de défilement vertical dans Visual Studio a un décalage de 50 ms. Pensez à la robustesse de la solution de transfert d’écran de TeamViewer pour accomplir tout cela.

Les VNC utilisent des hooks basés sur des sondages pour détecter le changement d’écran et la capture / comparaison d’écran de force brute au pire. Au mieux, ils utilisent un pilote miroir tel que DFMirage. Je suis à ce niveau. Et ils utilisent quelque chose appelé le protocole RFB.

Microsoft Windows Remote Desktop dépasse apparemment VNC. J’ai entendu, quelque part sur StackOverflow, que Windows Remote Desktop n’envoie pas de bitmaps d’écran, mais des commandes de dessin réelles. C’est assez shiny, car il suffit d’envoyer un texte simple (dessinez ce rectangle à cette coordonnée et coloriez-le avec ce dégradé)! Remote Desktop est vraiment rapide – et c’est la méthode standard de travail à domicile. Et il utilise quelque chose appelé le protocole RDP.

Maintenant, TeamViewer est un mystère complet pour moi. Apparemment, ils ont publié leur code source pour la version 2 (TeamViewer est la version 7 en février 2012). Les gens l’ont lu et ont déclaré que la version 2 était inutile – c’est juste quelques améliorations par rapport à VNC avec la traversée NAT automatique.

Mais la version 7 … c’est ridiculement rapide maintenant. Je veux dire, c’est en fait plus rapide que Windows Remote Desktop. J’ai diffusé des jeux DirectX 3D avec TeamViewer (à 1 ips, mais Windows Remote Desktop ne permet même pas à DirectX de fonctionner).

Au fait, TeamViewer fait tout cela sans pilote de miroir. Il y a une option pour en installer une, et ça devient juste un peu plus rapide.

La question

Ma question est: comment TeamViewer est-il si rapide? Cela ne doit pas être possible. Si vous avez une résolution de 1920 par 1080, même à une profondeur de 24 bits (la profondeur de 16 bits serait sensiblement laide), cela rest 6 220 800 octets crus. Même en utilisant libjpeg-turbo (l’une des bibliothèques de compression JPG les plus rapides utilisées par les grandes entresockets), le compresser à 30 Ko (soyons extrêmement généreux) prendrait du temps à traverser les serveurs de TeamViewer (TeamViewer contourne les NAT symésortingques en leurs serveurs). Et cette compression libjpeg-turbo prendrait du temps à se compresser. La compression JPG de haute qualité prend 175 millisecondes pour une capture d’écran complète de 1920 par 1080. Et ce nombre augmente si l’ordinateur de l’hôte exécute un processeur Atom. Je ne comprends tout simplement pas comment TeamViewer a optimisé son transfert d’écran. Encore une fois, les images de petite taille peuvent être fortement compressées, mais la compression nécessite au moins des dizaines de millisecondes. Les images de grande taille ne prennent pas le temps de se compresser, mais prennent beaucoup de temps à passer. En quelque sorte, TeamViewer complète ce processus pour obtenir environ 20 à 25 images par seconde. J’ai utilisé un moniteur réseau et TeamViewer est toujours à la traîne à des vitesses de 500 Kbps et 1 Mbps (décalage du logiciel VNC pendant quelques secondes à ce taux de transfert). Au cours de mon test d’invite de commande dans l’ tree , TeamViewer recevait des données entrantes à un débit de 1 Mbps et continuait à fonctionner entre 5 et 6 images par seconde. VNC et le bureau distant ne le font pas. Alors comment?

Les réponses seront un peu compliquées et compliquées, alors ne postez pas vos 0,02 $ si vous allez seulement dire que c’est parce qu’elles utilisent UDP au lieu de TCP (croyez-vous qu’elles utilisent TCP avec autant de succès).

J’espère qu’il y a un développeur TeamViewer quelque part sur StackOverflow.

Réponses potentielles

Mettra à jour cette fois les gens répondent.

Mes pensées sont, tout d’abord, que TeamViewer dispose d’un très bon contrôle réseau. Par exemple, ils divisent les gros paquets en un peu moins de la taille MTU et ne gaspillent jamais un voyage. Ils ont probablement toutes sortes de crochets de fantaisie pour détecter les changements d’écran avec des comparaisons d’image XOR extrêmement rapides.

La chose la plus fondamentale ici est probablement que vous ne voulez pas transmettre d’images statiques mais que vous modifiez uniquement les images, ce qui est essentiellement analogue au stream vidéo .

Ma meilleure supposition est un algorithme de compensation de mouvement très efficace (et fortement spécialisé et optimisé), car la plupart des changements réels dans l’utilisation générique du bureau sont des mouvements linéaires d’éléments (défilement de texte, fenêtres mobiles, etc.).

La performance DirectX 3D de 1 FPS semble confirmer mon hypothèse dans une certaine mesure.

acheminerait du temps sur les serveurs de TeamViewer (TeamViewer contourne les NAT symésortingques de l’entreprise simplement en transmettant le trafic via leurs serveurs)

Vous constaterez que TeamViewer a rarement besoin de relayer le trafic via ses propres serveurs. TeamViewer pénètre dans les NAT et les réseaux compliqués par NAT en utilisant la traversée de NAT (je pense que c’est du perçage UDP , comme la libjingle de Google ).

Ils utilisent leurs propres serveurs sur middle-man pour établir la connexion et la configuration des connexions, mais la plupart du temps, la relation entre le client et le serveur sera P2P (le meilleur cas, lorsque la poignée de main réussit). Si la traversée NAT échoue, TeamViewer transmettra effectivement le trafic via ses propres serveurs.

Je ne l’ai jamais vu faire cela quand un client a été derrière le double-NAT, cependant.

Une réponse un peu tardive, mais je vous suggère de jeter un oeil à un projet peu connu sur codeplex appelé ConferenceXP

ConferenceXP est une plate-forme de recherche open source qui fournit des services de conférence et de collaboration simples, flexibles et extensibles utilisant des réseaux à large bande passante et les capacités multimédia avancées de Microsoft Windows. ConferenceXP aide les chercheurs et les éducateurs à développer des applications et des solutions innovantes intégrant des données audio et vidéo de qualité broadcast pour les environnements de collaboration dissortingbuée et de formation à distance en temps réel.

La source complète (c’est énorme!) Est fournie. Il implémente le protocole RTP .

Il semble en effet que le streaming vidéo soit plus que le streaming d’images, comme quelqu’un l’a suggéré. La compression JPEG / PNG n’est pas ciblée pour ces types de vitesses, alors oubliez-les.

Imaginez avoir un codec d’enregistrement sur votre système capable d’enregistrer en temps réel un stream vidéo entrant (votre écran). Un peu comme Fraps peut-être. Imaginez ensuite un codec de lecture vidéo de l’autre côté (le client distant). Comme les enregistreurs HD peuvent le faire (enregistrer en direct et même lire en direct à partir du même HD), vous devriez le faire à la fin. La HD ne peut sûrement pas livrer les images plus rapidement que vous ne pouvez lire votre affichage, ce n’est donc pas le goulot d’étranglement. Les goulots d’étranglement sont les codecs vidéo. Vous trouverez le codeur beaucoup plus problématique que le décodeur, car tous les décodeurs sont pour la plupart gratuits.

Je ne dis pas que c’est simple; J’ai moi-même utilisé DirectShow pour encoder un fichier vidéo, et ce n’est pas vraiment le cas en temps réel. Mais étant donné le bon codec, je suis convaincu qu’il peut fonctionner.

Bizarrement. mais selon mon expérience, TeamViewer n’est pas plus rapide / plus réactif que VNC, mais plus facile à configurer. J’ai un couple de win-boxen que je VNC sur OpenVPN dans (il y a donc une autre couche supplémentaire) et c’est sur Cable pas cher (512) et je trouve que TightVNC est bien plus réactif que TeamViewer à la même boîte. RDP (naturellement) d’autant plus que, en grande partie, il envoie des commandes de dessin d’interface graphique au lieu des tuiles bitmap.

Ce qui nous amène à:

Pourquoi n’utilisez-vous pas VNC? Il y a une pléthore de solutions open source, et Tight est probablement au sumt de sa forme actuelle.
Les implémentations avancées de VNC utilisent la compression avec perte et cela semble donner de meilleurs résultats que votre choix de PNG. Aussi, IIRC le rest de la charge utile est également écrasé en utilisant zlib. Bothj Tight et UltraVNC ont des algos très optimisés, en particulier pour Windows. En plus de cela, Tight est open-source.
Si win boxen est votre cible principale, le RDP peut être une meilleure option et a une implémentation opensource (rdesktop)
Si * nix boxen est votre cible principale, NX peut être une meilleure option et une implémentation open source (FreeNX, mais pas aussi optimisée que le produit propriétaire de NoMachine).

Si la compression de JPEG est un problème de performance pour votre algo, je suis presque certain que la comparaison d’image entraînerait encore des performances. Je parierais qu’ils utilisent la meilleure compression pour chaque situation spécifique: perte de données pour les grandes images, certaines sont rapides et sales pour les plus petites, comparent les bits des images et n’envoient que des trucs d’optimisation.

Et beaucoup de ces astuces doivent être présentes dans Tight> 2.0 car, de mon sharepoint vue, je pense que cela bat tout le monde des performances de TeamViewer, YMMV.

De plus, le choix d’un environnement d’exécution compilé JIT sur quelque chose comme C ++ peut prendre une part de votre avantage de performances, en particulier sur les machines à contraintes mémoire (beaucoup de performances sont optimisées lorsque les fenêtres commencent à utiliser le fichier). Et vous aurez besoin de mémoire pour conserver les états d’image précédents pour une comparaison interne au sumt de ce que DF Mirage vous offre.