Comment va TeamViewer si vite?
Désolé pour la longueur, c'est un peu nécessaire.
Introduction
Je développe un logiciel de bureau à distance (juste pour le plaisir) en C # 4.0 pour Windows Vista/7. J'ai surmonté des obstacles de base: j'ai un système de messagerie UDP robuste, une conception de programme relativement propre, un pilote de miroir (le pilote de miroir gratuit DFMirage de DemoForge) est opérationnel et j'ai implémenté NAT parcours pour tous les types NAT sauf les NAT symétriques (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 averti des régions d'écran modifiées et je peux simplement marshaler le bitmap d'écran en constante évolution du pilote miroir en mon propre bitmap. Ensuite, je compresse la région d’écran au format PNG et l’envoie du serveur à mon client. Les choses s'annoncent plutôt 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 par toutes les implémentations de type VNC, puis monte vers Microsoft Windows Remote Desktop ... puis ... TeamViewer. Pas tout à fait sûr de CrossLoop, LogMeIn - je ne les ai pas utilisées, mais TeamViewer est incroyablement rapide. C'est littéralement vivre. J'ai exécuté une commande tree sur l'invite de commande, qui 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 défilement vertical du code dans Visual Studio a un délai de 50 ms. Réfléchissez à la robustesse de la solution de transfert d'écran de TeamViewer pour accomplir tout cela.
Les VNC utilisent des points d'ancrage basés sur l'interrogation pour détecter les changements d'écran et les captures d'écran de force brute/comparaison 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 va apparemment un peu plus haut que VNC. J'ai entendu dire, quelque part sur StackOverflow, que Windows Remote Desktop n'envoyait pas de bitmaps d'écran, mais des commandes de dessin réelles. C'est assez brillant, car il ne peut envoyer que du texte simple (dessinez ce rectangle à cette coordonnée et colorez-le avec ce dégradé)! Le bureau à distance est vraiment rapide - et c'est la manière standard de travailler à 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 dit que la version 2 était inutile - qu'il ne s'agissait que de quelques améliorations par rapport à VNC avec la traversée automatique NAT.
Mais la version 7 ... c'est ridiculement rapide maintenant. Je veux dire, c'est en fait plus rapide que Windows Remote Desktop. J'ai visionné des jeux DirectX 3D avec TeamViewer (à 1 ips, mais Windows Remote Desktop ne permet même pas l'exécution de DirectX).
À propos, TeamViewer fait tout cela sans un pilote miroir. Il existe une option pour en installer une, et cela devient un peu plus rapide.
La question
Ma question est, comment va TeamViewer si vite? Cela ne doit pas être possible. Si vous avez une résolution de 1920 par 1080 à une profondeur même de 24 bits (une profondeur de 16 bits serait vraiment moche), il reste encore 6 220 800 octets bruts. Même en utilisant libjpeg-turbo (une des bibliothèques de compression JPG les plus rapides utilisées par les grandes entreprises), le compresser à 30 Ko (soyons extrêmement généreux) prendrait du temps à passer par les serveurs de TeamViewer (TeamViewer contourne les NAT symétriques de l'entreprise en faisant simplement passer le trafic proxy à travers leurs serveurs). Et cette compression libjpeg-turbo prendrait du temps à compresser. Une compression JPG de haute qualité prend 175 millisecondes pour une capture d'écran complète de 1920 sur 1080 pour moi. Et ce nombre augmente si l'ordinateur de l'hôte utilise un processeur Atom. Je ne comprends tout simplement pas comment TeamViewer a si bien optimisé le transfert d'écran. De nouveau, les images de petite taille peuvent être fortement compressées, mais prennent au moins des dizaines de millisecondes à compresser. Les images de grande taille ne se compressent pas mais prennent beaucoup de temps. TeamViewer termine l’ensemble du processus pour obtenir environ 20 à 25 images par seconde. J'ai utilisé un moniteur réseau et TeamViewer est toujours sans décalage à des vitesses de 500 Kbps et 1 Mbps (le logiciel VNC diffère de quelques secondes à ce taux de transfert). Lors de mon test d'invite de commandes tree, TeamViewer recevait des données entrantes à un débit de 1 Mbps et continuait à exécuter une cadence de 5 à 6 ips. VNC et le bureau à distance ne font pas cela. Alors comment?
Les réponses seront un peu compliquées et complexes, donc , n’envoyez pas vos 0,02 $ si vous dites que c’est parce qu’ils utilisent UDP au lieu de TCP (croiriez-vous qu’ils utilisent réellement TCP avec autant de succès)?.
J'espère qu'il y a un développeur TeamViewer quelque part ici sur StackOverflow.
Réponses potentielles
Mettra à jour cette fois les gens répondent.
- Tout d’abord, je pense que TeamViewer dispose d’un très bon contrôle réseau. Par exemple, ils divisent les gros paquets à un peu moins de la taille du MTU et ne gaspillent jamais un voyage. Ils ont probablement toutes sortes de crochets sophistiqués pour détecter les changements d’écran, ainsi que des comparaisons extrêmement rapides XOR.
La chose la plus fondamentale ici est probablement que vous ne voulez pas transmettre d’images statiques mais seulement des modifications aux images, ce qui est essentiellement analogue à flux vidéo.
Ma meilleure hypothèse est un algorithme de compensation de mouvement très efficace (et très spécialisé et optimisé), car la majeure partie du changement réel dans l'utilisation du bureau générique est un mouvement linéaire éléments (texte défilant, fenêtres en mouvement, etc. opposés à la transformation des éléments).
Les performances de DirectF 3D de 1 FPS semblent confirmer mon hypothèse dans une certaine mesure.
cela prendrait du temps de passer par les serveurs de TeamViewer (TeamViewer contourne les NAT symétriques de l'entreprise en faisant simplement passer le trafic proxy par le biais de leurs serveurs)
Vous constaterez que TeamViewer a rarement besoin de relayer le trafic via ses propres serveurs. TeamViewer pénètre NAT et les réseaux compliqués par NAT en utilisant NAT traversal (je pense que c'est perforation UDP , comme Google's libjingle ).
Ils utilisent leurs propres serveurs comme intermédiaires pour établir la liaison et établir la connexion, mais la plupart du temps, la relation entre le client et le serveur sera P2P (dans le meilleur des cas, lorsque la poignée de main est réussie). Si la traversée NAT échoue, TeamViewer relayera le trafic via ses propres serveurs.
Je ne l'ai jamais vu faire cela que lorsqu'un client a été derrière le double-NAT, cependant.
Réponse un peu tardive, mais je vous suggère de regarder un projet mal connu sur codeplex appelé ConferenceXP
ConferenceXP est une plate-forme de recherche open source qui fournit une conférence et une collaboration simples, flexibles et extensibles à l'aide de réseaux à bande passante élevée et des fonctionnalités multimédia avancées de Microsoft Windows. ConferenceXP aide les chercheurs et les enseignants à développer des applications et des solutions innovantes intégrant des fonctions audio et vidéo de qualité diffusion, compatibles avec les environnements de collaboration distribuée et d'apprentissage à distance en temps réel.
La source complète (c'est énorme!) Est fournie. Il implémente le protocole RTP .
Cela ressemble en effet à du streaming vidéo plutôt qu’au streaming d’images, comme l’a suggéré quelqu'un. La compression JPEG/PNG n'est pas ciblée pour ces types de vitesses, alors oubliez-les.
Imaginez que votre système dispose d'un codec d'enregistrement capable d'enregistrer en temps réel un flux vidéo entrant (votre écran). Un peu comme Fraps peut-être. Ensuite, imaginez 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 disque dur), vous devriez le faire à la fin. La HD ne peut sûrement pas fournir des images plus rapidement que vous ne pouvez lire votre écran, ce qui ne constitue pas un goulot d'étranglement. Les goulots d'étranglement sont les codecs vidéo. Vous constaterez que le codeur est bien 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 en temps réel. Mais étant donné le bon codec, je suis convaincu que cela 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 (donc il y a une autre couche de frais généraux) et qui est sur le câble bon marché (512 vers le haut) et je trouve correctement configuré TightVNC pour être beaucoup plus réactif que TeamViewer à même boxen. RDP (naturellement) d'autant plus que, dans l'ensemble, il envoie des commandes de dessin de l'interface graphique au lieu de tuiles bitmap.
Ce qui nous amène à:
Pourquoi n'utilisez-vous pas VNC? Il existe une pléthore de solutions open source, et Tight est probablement au top de son jeu en ce moment.
Les implémentations avancées de VNC utilisent une compression avec perte et cela semble donner de meilleurs résultats que votre choix de PNG. En outre, le reste de la charge utile de l'IIRC est également réduit à l'aide de zlib. Bothj Tight et UltraVNC ont des algorithmes très optimisés, en particulier pour Windows. En plus de cela, Tight est open-source.
Si Win Boxen est votre cible principale, RDP peut être une meilleure option et dispose d’une implémentation opensource (rdesktop).
Si * nix boxen est votre cible principale, NX peut être une meilleure option et dispose d'une implémentation à source ouverte (FreeNX, bien que ce ne soit pas aussi optimisé que le produit propriétaire de NoMachine).
Si compresser le JPEG est un problème de performances pour votre algo, je suis presque certain que la comparaison d’images diminuerait encore les performances. Je parierais qu'ils utilisent la compression optimale pour chaque situation spécifique, c'est-à-dire avec des pertes pour les grandes images, des erreurs rapides et vides pour les plus petites, comparent des fragments d'image et n'envoient que des diffs de tri et d'autres astuces d'optimisation.
Et beaucoup de ces astuces doivent être présentes dans Tight> 2.0, car, selon mon expérience, il bat l’enfer de la performance TeamViewer wyse, YMMV.
De plus, le choix d'une exécution JIT compilée sur quelque chose comme le C++ peut prendre une part de votre performance, particulièrement dans les machines à mémoire limitée (beaucoup de réglages de performance vont aux toilettes lorsque Windows commence à utiliser le fichier d'échange de manière intensive). Et vous aurez besoin de mémoire pour conserver les états d'image précédents aux fins de comparaison interne au-dessus de ce que vous donne DF mirage.