performance - gratis - ¿Cómo es TeamViewer tan rápido?

teamviewer descargar (5)

tomaría tiempo para enrutar a través de los servidores de TeamViewer (TeamViewer pasa por alto los NAT simétricos corporativos simplemente transfiriendo el tráfico a través de sus servidores)

Descubrirá que TeamViewer rara vez necesita retransmitir tráfico a través de sus propios servidores. TeamViewer penetra en NAT y en redes complicadas mediante NAT mediante el cruce de NAT (creo que es perforación UDP , como la libjingle de Google ).

Utilizan sus propios servidores para intermediarios con el fin de establecer la conexión y el establecimiento de la conexión, pero la mayoría de las veces la relación entre el cliente y el servidor será P2P (el mejor caso, cuando el apretón de manos sea exitoso). Si el cruce de NAT falla, entonces TeamViewer retransmitirá el tráfico a través de sus propios servidores.

Sin embargo, solo lo he visto hacerlo cuando un cliente ha estado detrás de la doble NAT.

Perdón por la duración, es un poco necesario.

Introducción

Estoy desarrollando un software de escritorio remoto (solo por diversión) en C # 4.0 para Windows Vista / 7. He superado los obstáculos básicos: tengo un sistema de mensajería UDP robusto, un diseño de programa relativamente limpio, tengo un controlador espejo (el controlador de espejo DFMirage gratuito de DemoForge) en funcionamiento, y he implementado NAT transversal para todos Tipos de NAT excepto NAT simétricos (presentes en situaciones de firewall corporativo).

En cuanto a la transferencia / uso compartido de la pantalla, gracias al controlador de espejo, me notifican automáticamente las regiones de la pantalla cambiadas y simplemente puedo ordenar el mapa de bits de la pantalla siempre cambiante del controlador espejo en mi propio mapa de bits. Luego comprime la región de la pantalla como PNG y la envío desde el servidor a mi cliente. Las cosas se ven bastante bien, pero no es lo suficientemente rápido. Es tan lento como VNC (por cierto, no uso el protocolo VNC, solo un protocolo aficionado personalizado).

Desde el software de escritorio remoto más lento hasta el más rápido, la lista generalmente comienza en todas las implementaciones similares a VNC, luego sube a Microsoft Windows Remote Desktop ... y luego ... TeamViewer. No estoy seguro de CrossLoop, LogMeIn: no los he usado, pero TeamViewer es increíblemente rápido. Es bastante literalmente en vivo. Ejecuté un comando de tree en Símbolo del sistema y se actualizó con 20 ms de retraso. Puedo navegar por la web solo unos pocos milisegundos más lento que en mi computadora portátil. El desplazamiento vertical del código en Visual Studio tiene un tiempo de retardo de 50 ms. Piense en la solidez de la solución de transferencia de pantalla de TeamViewer para lograr todo esto.

Las VNC utilizan ganchos basados en sondeos para detectar el cambio de pantalla y la captura / comparación de la pantalla de fuerza bruta en el peor de los casos. En el mejor de los casos, utilizan un controlador de espejo como DFMirage. Estoy en este nivel. Y usan algo llamado protocolo RFB.

Microsoft Windows Remote Desktop aparentemente va un paso más arriba que VNC. Escuché, desde algún lugar en StackOverflow, que Windows Remote Desktop no envía mapas de bits en pantalla, sino comandos de dibujo reales. Eso es bastante brillante, porque puede simplemente enviar texto simple (dibuje este rectángulo en esta coordenada y coloréelo con este degradado). Remote Desktop realmente es bastante rápido, y es la forma estándar de trabajar desde casa. Y usa algo llamado protocolo RDP.

Ahora TeamViewer es un completo misterio para mí. Aparentemente, lanzaron su código fuente para la Versión 2 (TeamViewer es la Versión 7 a partir de febrero de 2012). La gente lo ha leído y ha dicho que la Versión 2 es inútil, que solo se trata de algunas mejoras sobre VNC con cruce NAT automático.

Pero la Versión 7 ... es ridículamente rápida ahora. Quiero decir, en realidad es más rápido que Windows Remote Desktop. Transmití juegos DirectX 3D con TeamViewer (a 1 fps, pero Windows Remote Desktop ni siquiera permite la ejecución de DirectX).

Por cierto, TeamViewer hace todo esto sin un controlador espejo. Hay una opción para instalar uno, y se vuelve un poco más rápido.

La pregunta

Mi pregunta es, ¿cómo es TeamViewer tan rápido? No debe ser posible. Si tienes una resolución de 1920 por 1080 a una profundidad de hasta 24 bits (la profundidad de 16 bits sería notablemente fea), aún hay 6.220.800 bytes sin procesar. Incluso utilizando libjpeg-turbo (una de las bibliotecas de compresión JPG más rápidas utilizadas por grandes corporaciones), comprimirlo a 30 KB (seamos extremadamente generosos) llevaría tiempo enrutar a través de los servidores de TeamViewer (TeamViewer omite los NAT simétricos corporativos simplemente transfiriendo el tráfico a través de sus servidores). Y esa compresión libjpeg-turbo tomaría tiempo para comprimir. La compresión JPG de alta calidad demora 175 milisegundos para una captura de pantalla completa de 1920 por 1080 para mí. Y ese número aumenta si la computadora del host ejecuta un procesador Atom. Simplemente no entiendo cómo TeamViewer ha optimizado su transferencia de pantalla tan bien. De nuevo, las imágenes de pequeño tamaño pueden estar muy comprimidas, pero toman al menos decenas de milisegundos para comprimirlas. Las imágenes de gran tamaño no tardan en comprimir, pero demoran mucho en llegar. De alguna manera, TeamViewer completa todo este proceso para obtener aproximadamente 20-25 fotogramas por segundo. Utilicé un monitor de red y TeamViewer aún no tiene lag a velocidades de 500 Kbps y 1 Mbps (retraso del software VNC durante unos segundos a esa velocidad de transferencia). Durante la prueba del símbolo del sistema de mi tree , TeamViewer recibía datos entrantes a una velocidad de 1 Mbps y seguía funcionando a 5-6 fps. VNC y el escritorio remoto no hacen eso. ¿Así que cómo?

Las respuestas serán algo complicadas e intrincadas, así que no publiques tus $ 0.02 si solo vas a decir que es porque usan UDP en lugar de TCP (¿creerías que realmente usan TCP tan exitosamente).

Espero que haya un desarrollador de TeamViewer en algún lugar de StackOverflow.

Posibles respuestas

Actualizará esto una vez que la gente responda.

Lo primero que pienso es que TeamViewer tiene un control de red muy preciso. Por ejemplo, dividen paquetes grandes por debajo del tamaño de MTU y nunca pierden un viaje. Probablemente tengan todo tipo de ganchos elegantes para detectar cambios en la pantalla junto con comparaciones de imágenes XOR extremadamente rápidas.

Extrañamente. pero en mi experiencia, TeamViewer no es más rápido / responde mejor que VNC, solo que es más fácil de configurar. Tengo un par de win-boxen que conecto con VNC sobre OpenVPN (así que hay otra capa superior) y eso es con Cable barato (512 en adelante) y encuentro que TightVNC configuró correctamente para ser mucho más receptivo que TeamViewer al mismo boxen. RDP (naturalmente) aún más, ya que en gran parte envía comandos de dibujo de GUI en lugar de mosaicos de mapa de bits.

Lo que nos lleva a:

¿Por qué no estás usando VNC? Hay una plétora de soluciones de código abierto, y Tight probablemente esté en la cima de su juego en este momento.
Las implementaciones avanzadas de VNC usan compresión con pérdida y eso parece lograr mejores resultados que su elección de PNG. Además, IIRC el resto de la carga útil también se aplasta con zlib. Bothj Tight y UltraVNC tienen algos muy optimizados, especialmente para Windows. Además de eso Tight es de código abierto.
Si win boxen es su objetivo principal, RDP puede ser una mejor opción y tiene una implementación de código abierto (rdesktop)
Si * nix boxen es su objetivo principal, NX puede ser una mejor opción y tiene una implementación de código abierto (FreeNX, aunque no tan optimizado como el producto propietario de NoMachine).

Si comprimir JPEG es un problema de rendimiento para tu algo, estoy bastante seguro de que la comparación de imágenes aún te quitará algo de rendimiento. Apuesto a que usan la mejor compresión de caso para cada situación específica, es decir, con pérdida de fotogramas grandes, algunos internall rápidos y sucios, sin menos para los más pequeños, comparan bits de imágenes y envían solo diferencias de tipo y un montón de otros trucos de optimización.

Y muchos de esos trucos deben estar presentes en Tight> 2.0, ya que, de nuevo, en mi experiencia, supera al rendimiento de TeamViewer wyse, YMMV.

Además, la elección de un tiempo de ejecución compilado JIT sobre algo como C ++ podría reducir el margen de rendimiento, especialmente en máquinas con memoria limitada (una gran cantidad de ajuste de rendimiento va al baño cuando Windows comienza a usar el archivo de paginación de forma intensiva). Y necesitará memoria para mantener los estados previos de la imagen para una comparación interna encima de lo que DF Mirage le ofrece.

Probablemente, lo más fundamental aquí es que no desea transmitir imágenes estáticas, sino solo cambios en las imágenes, que en esencia son análogos a la transmisión de video .

Mi mejor opción es algún algoritmo de compensación de movimiento muy eficiente (y altamente especializado y optimizado), porque la mayor parte del cambio real en el uso de escritorios genéricos es movimiento lineal de elementos (desplazamiento de texto, ventanas móviles, etc. opuesto a la transformación de elementos).

El rendimiento de DirectX 3D de 1 FPS parece confirmar mi suposición hasta cierto punto.

Suena como la transmisión de video más que la transmisión de imágenes, como alguien sugirió. La compresión JPEG / PNG no está enfocada para este tipo de velocidades, así que olvídate de ellas.

Imagine tener un códec de grabación en su sistema que pueda grabar en tiempo real una transmisión de video entrante (su pantalla). Un poco como Fraps quizás. Luego imagine un códec de reproducción de video en el otro lado (el cliente remoto). Como los grabadores de HD pueden hacerlo (grabar en vivo e incluso reproducir en vivo desde el mismo HD), al final también debería hacerlo. La HD seguramente no puede entregar imágenes más rápido de lo que puede leer su pantalla, por lo que ese no es el cuello de botella. El cuello de botella son los códecs de video. El codificador será mucho más problemático que el decodificador, ya que todos los decodificadores son en su mayoría gratuitos.

No digo que sea simple; Yo mismo he usado DirectShow para codificar un archivo de video, y no es en tiempo real por mucho. Pero dado el codec correcto, estoy convencido de que puede funcionar.

Un poco tarde de respuesta, pero sugiero que eche un vistazo a un proyecto no muy conocido en codeplex llamado ConferenceXP

ConferenceXP es una plataforma de investigación de código abierto que ofrece conferencias y colaboración simples, flexibles y extensibles utilizando redes de gran ancho de banda y las capacidades avanzadas de multimedia de Microsoft Windows. ConferenceXP ayuda a los investigadores y educadores a desarrollar aplicaciones y soluciones innovadoras que ofrecen audio y video con calidad de transmisión en apoyo de entornos de colaboración distribuida y aprendizaje a distancia en tiempo real.

La fuente completa (¡es enorme!) Se proporciona. Implementa el protocolo RTP .