Perdón por la longitud, es algo necesario.
Introducción
Estoy desarrollando un software de escritorio remoto (solo por diversión) en C # 4.0 para Windows Vista / 7. He superado 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 espejo DFMirage gratuito de DemoForge) en funcionamiento, y he implementado NAT transversal para todos Tipos de NAT excepto NAT simétricos (presente en situaciones de firewall corporativo).
Con respecto a la transferencia / uso compartido de pantalla, gracias al controlador de espejo, se me notifica automáticamente sobre las regiones de pantalla cambiadas y simplemente puedo ordenar el mapa de bits de la pantalla en constante cambio del controlador de espejo a mi propio mapa de bits. Luego comprimo 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 amateur 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 Escritorio remoto de Microsoft Windows ... y luego ... TeamViewer. No estoy muy seguro acerca de CrossLoop, LogMeIn: no los he usado, pero TeamViewer es increíblemente rápido. Es literalmente en vivo. Ejecuté un tree
comando en el símbolo del sistema y se actualizó con 20 ms de retraso. Puedo navegar por la web solo unos milisegundos más lento que en mi computadora portátil. El código de desplazamiento vertical en Visual Studio tiene un retraso de 50 ms. Piense en lo sólida que debe ser la solución de transferencia de pantalla de TeamViewer para lograr todo esto.
Los VNC utilizan ganchos basados en encuestas para detectar el cambio de pantalla y la captura / comparación de pantalla de fuerza bruta en su peor momento. En su mejor momento, utilizan un controlador de espejo como DFMirage. Estoy a este nivel Y usan algo llamado protocolo RFB.
El escritorio remoto de Microsoft Windows aparentemente va un paso más alto que VNC. Escuché, desde algún lugar de StackOverflow, que el Escritorio remoto de Windows no envía mapas de bits de pantalla, sino comandos de dibujo reales. ¡Eso es bastante brillante, porque puede enviar texto simple (dibuja este rectángulo en esta coordenada y coloréalo 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 dice que la Versión 2 es inútil, que solo son algunas mejoras sobre VNC con el recorrido automático NAT.
Pero la Versión 7 ... es ridículamente rápida ahora. Quiero decir, en realidad es más rápido que el Escritorio remoto de Windows. He transmitido juegos DirectX 3D con TeamViewer (a 1 fps, pero Windows Remote Desktop ni siquiera permite que se ejecute 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 tiene una resolución de 1920 por 1080, incluso a una profundidad de 24 bits (la profundidad de 16 bits sería notablemente fea), todavía son 6.220.800 bytes sin procesar. Incluso usar libjpeg-turbo (una de las bibliotecas de compresión JPG más rápidas utilizadas por las grandes corporaciones), comprimirlo a 30 KB (seamos extremadamente generosos), llevaría tiempo enrutar a través de los servidores de TeamViewer (TeamViewer evita los NAT simétricos corporativos simplemente representando 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 toma 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 tan bien su transferencia de pantalla. Una vez más, las imágenes de pequeño tamaño pueden estar muy comprimidas, pero tome al menos decenas de milisegundos para comprimir. Las imágenes de gran tamaño no tardan en comprimirse, pero tardan mucho en pasar. De alguna manera, TeamViewer completa todo este proceso para obtener aproximadamente 20-25 cuadros por segundo. He usado un monitor de red, y TeamViewer sigue sin retraso a velocidades de 500 Kbps y 1 Mbps (retraso del software VNC durante unos segundos a esa velocidad de transferencia). Durante mitree
Prueba de símbolo del sistema, TeamViewer estaba recibiendo datos entrantes a una velocidad de 1 Mbps y todavía ejecutaba 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 publique sus $ 0.02 si solo va a decir que es porque usan UDP en lugar de TCP (aunque, ¿creería que realmente usan TCP con el mismo éxito?)
Espero que haya un desarrollador de TeamViewer en algún lugar aquí en StackOverflow.
Respuestas potenciales
Actualizará esto una vez que la gente responda.
- Mis pensamientos son, en primer lugar, que TeamViewer tiene un control de red muy bueno. Por ejemplo, dividen paquetes grandes por debajo del tamaño de MTU y nunca desperdician un viaje. Probablemente tengan todo tipo de ganchos elegantes para detectar cambios de pantalla junto con comparaciones de imágenes XOR extremadamente rápidas.