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é les obstacles de base: j'ai un système de messagerie UDP robuste, une conception de programme relativement propre, j'ai un pilote miroir (le pilote miroir gratuit DFMirage de DemoForge) opérationnel, et j'ai implémenté la traversée NAT pour tous Types de NAT à l'exception des 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 du miroir, je suis automatiquement informé des régions d'écran modifiées et je peux simplement rassembler le bitmap d'écran en constante évolution du pilote du miroir vers mon propre bitmap. Ensuite, je compresse la zone de l'écran au format PNG et je l'envoie du serveur à mon client. Les choses semblent plutôt bonnes, mais ce n'est pas assez rapide. C'est tout aussi lent que VNC (btw, je n'utilise pas le protocole VNC, juste un protocole amateur personnalisé).
Du logiciel de bureau à distance le plus lent au plus rapide, la liste commence généralement à toutes les implémentations de type VNC, puis grimpe vers 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 en direct. J'ai exécuté une tree
commande sur l'invite de commande et elle 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 temps de latence de 50 ms. Pensez à la robustesse de la solution de transfert d'écran de TeamViewer pour accomplir tout cela.
Les VNC utilisent des crochets basés sur des sondages pour détecter le changement d'écran et la capture / comparaison d'écran par force brute. Au mieux, ils utilisent un pilote de miroir comme DFMirage. Je suis à ce niveau. Et ils utilisent quelque chose appelé le protocole RFB.
Microsoft Windows Remote Desktop va apparemment un cran plus haut que 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 génial, car il peut simplement envoyer du texte simple (dessiner ce rectangle à cette coordonnée et le colorer avec ce dégradé)! Le Bureau à distance est vraiment assez rapide - et c'est la façon 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 une 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 fps, mais Windows Remote Desktop ne permet même pas à DirectX de fonctionner).
À propos, TeamViewer fait tout cela sans pilote de miroir. Il existe une option pour en installer un, et cela devient un peu plus rapide.
La question
Ma question est la suivante: comment TeamViewer est-il si rapide?Cela ne doit pas être possible. Si vous avez une résolution de 1920 x 1080 à même une profondeur de 24 bits (une profondeur de 16 bits serait visiblement moche), cela reste 6 220 800 octets bruts. Même utiliser libjpeg-turbo (l'une des bibliothèques de compression JPG les plus rapides utilisées par les grandes entreprises), la compresser à 30 Ko (soyons extrêmement généreux), prendrait du temps à acheminer via les serveurs de TeamViewer (TeamViewer contourne les NAT symétriques d'entreprise en envoyant simplement le trafic par proxy. 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 pour moi. 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 si bien optimisé son transfert d'écran. Encore une fois, les images de petite taille peuvent être fortement compressées, mais prenez au moins des dizaines de millisecondes pour compresser. Les images de grande taille ne prennent pas de temps à compresser, mais prennent beaucoup de temps à passer. D'une manière ou d'une autre, TeamViewer termine tout ce 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 est retardé pendant quelques secondes à ce taux de transfert). Pendant montree
Test d'invite de commandes, TeamViewer recevait des données entrantes à un débit de 1 Mbps et fonctionnait toujours entre 5 et 6 ips. VNC et le bureau à distance ne font pas cela. Alors, comment?
Les réponses seront quelque peu compliquées et complexes, donc s'il vous plaît ne publiez pas votre 0,02 $ si vous voulez seulement dire 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 ceci une fois que les gens auront répondu.
- Mes pensées sont, tout d'abord, que TeamViewer a un contrôle de réseau très fin. Par exemple, ils divisent les gros paquets juste en dessous de la taille MTU et ne perdent jamais un voyage. Ils ont probablement toutes sortes de crochets sophistiqués pour détecter les changements d'écran ainsi que des comparaisons d'images XOR extrêmement rapides.