Comment TeamViewer est-il si rapide?

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 treecommande 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 montreeTest 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.

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

La chose la plus fondamentale ici est probablement que vous ne voulez pas transmettre d'images statiques mais uniquement des modifications des images, ce qui est essentiellement analogue au flux vidéo. .

Ma meilleure hypothèse 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 des ordinateurs de bureau génériques sont linéaires. mouvement des éléments (texte défilant, fenêtres mobiles, etc., par opposition à la transformation des éléments).

Les performances DirectX 3D de 1 FPS semblent confirmer dans une certaine mesure mon hypothèse.

prendrait du temps à acheminer via les serveurs de TeamViewer (TeamViewer contourne les NAT symétriques de l'entreprise en transmettant simplement 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 le NAT et les réseaux compliqués par NAT à l'aide de la traversée NAT (je pense que c'est du poinçonnage UDP , comme le libjingle de Google ).

Ils utilisent leurs propres serveurs comme intermédiaires afin de faire la poignée de main et la configuration de 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 relèvera effectivement le trafic via ses propres serveurs.

Cependant, je ne l'ai jamais vu faire cela que lorsqu'un client était derrière le double NAT.

Réponse un peu tardive, mais je vous suggère de jeter un œil à un projet peu connu sur codeplex appelé ConferenceXP

ConferenceXP est une plate-forme de recherche open source qui fournit des conférences et une collaboration simples, flexibles et extensibles à l'aide de réseaux à large bande passante et des capacités multimédias avancées de Microsoft Windows. ConferenceXP aide les chercheurs et les éducateurs à développer des applications et des solutions innovantes qui présentent un son et une vidéo de qualité diffusion pour soutenir la collaboration distribuée en temps réel et les environnements d'apprentissage à distance.

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

Cela ressemble en effet à un streaming vidéo plus qu'à un 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 qui peut enregistrer en temps réel un flux 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 certainement pas fournir des images plus rapidement que vous ne pouvez lire votre écran, ce n'est donc pas le goulot d'étranglement. Le goulot d'étranglement sont les codecs vidéo. Vous trouverez l'encodeur 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 de loin en temps réel. Mais avec le bon codec, je suis convaincu que cela peut fonctionner.

Ma supposition aléatoire est la suivante: la télévision utilise le codec x264 qui a une licence commerciale (sinon TeamViewer devrait publier son code source). À un moment donné (il y a plus de 5 ans), je me souviens que le principal développeur de x264 avait écrit un article sur les améliorations qu'il avait apportées à l'encodage à faible délai (si vous retardez de quelques images, les encodeurs peuvent mieux compresser), en plus il a mentionné d'autres améliorations qui étaient pertinent pour une utilisation de type TeamViewer. Dans cet article, il a mentionné la lecture de tremblement de terre sur un flux vidéo sans problème notable. À l'époque, j'étais assez sûr de savoir qui était le sponsor de ces améliorations, car TeamViewer était à peu près la seule option à l'époque. x264 est une implémentation open source du codec vidéo H264, et c'est une mise en œuvre incroyablement bonne, c'est la meilleure. En même temps, il est extrêmement bien optimisé. Très probablement, grâce à une très bonne implémentation de x264, vous obtenez de bien meilleurs résultats avec la télévision avec une charge CPU inférieure. AnyDesk et Chrome Remote Desk utilisent libvpx, qui n'est pas aussi bon que x264 (optimisation et qualité vidéo).

Cependant, je ne pense pas que TeamView puisse battre le RDP de Microsoft. Pour moi, c'est le meilleur, mais cela fonctionne uniquement entre les PC Windows ou entre Mac et Windows. La télévision fonctionne même à partir de mobiles.

Mise à jour: l'article a été écrit en janvier 2010, de sorte que le travail a été effectué il y a environ 10 ans. Aussi, j'ai fait une erreur: il a joué à Call of Duty, pas à trembler. Lorsque vous avez posté votre question, si ma supposition est correcte, TeamViewer utilisait ce travail depuis 3 ans. Lisez cet article de blog à partir de l'archive Web: x264: la meilleure plate-forme de streaming vidéo à faible latence au monde . Quand j'ai lu l'article en 2010, j'étais sûr que le "démarrage - qui a demandé à ne pas être nommé" que l'auteur mentionne était TeamViewer.

Bizarrement. mais d'après mon expérience, TeamViewer n'est pas plus rapide / plus réactif que VNC, seulement plus facile à configurer. J'ai quelques win-boxen dans lesquels je VNC sur OpenVPN (il y a donc une autre couche de surcharge) et c'est sur un câble bon marché (512 et plus) et je trouve que TightVNC correctement configuré est beaucoup plus réactif que TeamViewer au même boxen. RDP (naturellement) d'autant plus qu'il envoie en grande partie des commandes de dessin GUI au lieu de tuiles bitmap.

Ce qui nous amène à:

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

2. Les implémentations VNC avancées utilisent la compression avec perte et cela semble donner de meilleurs résultats que votre choix de PNG. En outre, IIRC le reste de la charge utile est également écrasé en utilisant zlib. Bothj Tight et UltraVNC ont des algos très optimisés, en particulier pour les fenêtres. En plus de cela, Tight est open-source.

3. Si win boxen est votre cible principale, RDP peut être une meilleure option et a une implémentation open source (rdesktop)

4. Si * nix boxen est votre cible principale, NX peut être une meilleure option et a une implémentation open source (FreeNX, bien que pas aussi optimisé que le produit propriétaire de NoMachine).

Si la compression JPEG est un problème de performances pour votre algo, je suis presque sûr que la comparaison d'images enlèverait toujours certaines performances. Je parie qu'ils utilisent la compression du meilleur cas pour chaque situation spécifique, c'est-à-dire avec perte pour les grandes images, certains internes rapides et sales sans perte pour les plus petits, comparent des bits d'images et n'envoient que des diffs de sorte et un tas d'autres astuces d'optimisation.

Et beaucoup de ces astuces doivent être présentes dans Tight> 2.0 car encore une fois, d'après mon expérience, cela bat l'enfer de la performance de TeamViewer wyse, YMMV.

De plus, le choix d'un runtime compilé JIT par rapport à quelque chose comme C ++ peut prendre une part de vos performances, en particulier dans les machines à mémoire limitée (beaucoup de réglages des performances 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 pour une comparaison interne au-dessus de ce que DF mirage vous offre.