Comment TeamViewer est-il si rapide?


158

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.

1
Avez-vous essayé la rétro-ingénierie du protocole? (Il semble qu'ils utilisent PKI pour la configuration de session, donc ce n'est peut-être pas facile, voire faisable du tout)
Kimvais

3
Attendre une réponse à cette question dépend de la volonté d'une entreprise de partager son secret commercial. Leur principal à cela, celui qui les maintient en affaires. Vous avez un non fort, la seule façon d'obtenir un oui est de les appeler. Renseignez-vous sur leurs brevets, je suppose.
Hans Passant

1
Logique. J'attendrai plus de suggestions.
Jason

4
C'est étrange. Je ne trouve pas que ce soit plus rapide que le bureau à distance moi-même - loin de là! RDP pour moi est BEAUCOUP plus rapide - plus comme utiliser une machine virtuelle locale. Êtes-vous en train de tester sur Internet ou sur une sorte de configuration locale? Avez-vous ouvert votre pare-feu pour permettre les connexions directes de Teamviewer?
NickG

1
On dirait que vous testez uniquement sur le réseau local. D'après mon expérience, il semble que TeamViewer utilise une compression avec perte (avec une connexion lente, la qualité est parfois vraiment mauvaise). Se pourrait-il que VNC utilise plus de temps de traitement et moins de bande passante que TeamViewer et vice versa? Ensuite, en fonction de votre environnement (puissance du processeur sur les deux machines et qualité de la liaison réseau), parfois VNC peut être plus rapide, parfois TeamViewer.
Axel

Réponses:


79

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.


1
Theres le codec de capture d'écran TechSmith gratuit. Il compresse efficacement et sans perte.
sinni800

25

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.


5
Très peu de pare-feu d'entreprise permettent la traversée NAT ou UPnP et c'est le marché principal de TeamViewers. Je soupçonne que la plupart des connexions sont relayées dans la vraie vie ...
NickG

20
Parfois, vous pouvez "pousser votre chemin" même à travers les pare-feu d'entreprise / NAT - skype est assez bon pour cela. Fondamentalement, le client A envoie une requête qui sera bloquée par NAT / pare-feu et informe le serveur externe du port utilisé. Le client B obtient ensuite des informations sur le port du serveur externe et se connecte à ce port. Le NAT de A pensera que c'est une réponse à la première requête (qui a vraiment été bloquée par le NAT de B) et la laissera passer. Quand A répond sur cette connexion, le NAT de B le laisse passer car la connexion a été initiée par B. => Vous avez une connexion.
Axel

De nombreuses entreprises n'ont que des proxys http et pas de NAT et de routage vers l'extérieur du tout. Il y a des tunnels Teamviewer via le port http 443. C'est TCP et Teamviewer est TOUJOURS aussi rapide que l'enfer.
sinni800

1
@Daniel: commencez par lire les articles sur «Perforation UDP» et «STUN» sur wikipedia.
Axel

1
@DanielLiuzzi La libjingle open source de Google contient un perforateur: développeurs.google.com/ talk/libjingle/ developer_guide . Ils l'utilisaient (et peuvent encore le faire, je ne sais pas) pour GChat, Hangouts, etc.
Jamie Edwards

14

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 .


1
C'est excellent! J'ai téléchargé les binaires mais il semble qu'il n'y ait personne d'autre en ligne dans les autres salles. Je devrai tester avec un autre ordinateur plus tard. Merci beaucoup!
Jason

6

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.


2

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.


Êtes-vous sûr qu'AnyDesk utilise libvpx? Ils annoncent DeskRT comme leur propre codec conçu spécifiquement pour les environnements de bureau.
tunafish24

0

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.


9
Cela m'ennuie quand les gens suggèrent VNC comme alternative à TeamViewer. Je dirais que vous n'avez peut-être pas utilisé TeamViewer pour connaître les avantages qu'il offre par rapport aux logiciels libres comme VNC? VNC peut être acceptable pour accéder à votre propre ordinateur, mais pour le partage d'écran et l'hébergement de réunions, etc., il ne se compare même pas vaguement. La dernière fois que j'ai vérifié, VNC n'avait même pas de serveurs relais ouverts, donc cela ne fonctionnerait même pas dans 95% des cas car il serait pare-feu (sauf si vous possédez et exploitez votre propre pare-feu ou serveur).
NickG

5
La discussion ne portait pas sur les outils clients VNC par rapport à TeamViewer (dont j'utilise EXTENSIVEMENT les deux au quotidien, bien que j'opère beaucoup de pare-feu et de serveurs et j'en possède un certain nombre). La discussion portait sur le travail interne des protocoles et leur mise en œuvre
Bojan Markovic

Je viens d'essayer UltraVNC et TeamViewer sur un réseau 3G lent, et la différence de performances était énorme. Avec UltraVNC, j'ai rencontré des délais de 1 à 2 secondes entre le clic sur quelque chose sur l'ordinateur distant et la visualisation de la réponse. Trop lent pour être utile. TeamViewer était bien plus rapide (aussi rapide que RDP) et suffisamment rapide pour être utilisable sur le même lien.
John Reynolds

2
Oui. Je suis d'accord avec NickG. TOUTE PERSONNE essayant toujours de postuler que VNC aussi vite que TeamViewer ne doit jamais avoir utilisé TeamViewer. Affirmation ridicule. Cette réponse devrait être rejetée. J'ai utilisé toutes les astuces suggérées dans cet article avec VNC, et cela ne se compare même pas à distance aux performances de TeamViewer.
écraser

Je devais me connecter pour voter pour cette réponse. J'ai utilisé NoMachine, VNC, peu importe là-bas, et même spacedesk, Wired XDisplay sur Android, et vous savez quoi? Teamviewer est le plus rapide, beaucoup plus rapide que le streaming vidéo spacedesk. ANyone suggère VNC = ne jamais utiliser Teamviewer.
Ken Le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.