¿Por qué el reenvío X11 es tan ineficiente?

Cada vez que inicio remotamente grandes GUI con reenvío X11, incluso con el interruptor -C, la experiencia no responde. Mi pregunta es, ¿qué causa esto a nivel de concepto / protocolo?

Con mi conexión de 25mbit, puedo transmitir video HD a mi computadora sin ningún problema. Por otro lado, la falta de respuesta de las GUI lanzadas de forma remota con reenvío X11 ocurre incluso a través de una LAN de 100 mbits, donde la latencia debería ser cercana a cero.

Entiendo que, a diferencia de la transmisión de video, la latencia se duplicará en el mejor de los casos (ya que la entrada debe enviarse a la máquina remota y solo después de eso puede responder la aplicación), pero internamente, existen otros factores que aumentan la latencia incluso ¿promover, adicional?

En segundo lugar, el ancho de banda. ¿Por qué se come tanto? Cuando se trata de formatos de imagen y video, se utilizan muchos métodos para reducir drásticamente el tamaño.

En el caso de .bmp vs .png, por ejemplo, una imagen cuadrada negra grande tomará mucho menos en la representación .png porque la información no se almacena para cada píxel, sino en una forma de rango por lo que yo entiendo.

En el caso de los videos, se puede guardar una gran cantidad de información enviando la diferencia entre cuadros en lugar de los cuadros completos.

Sé que esto está muy simplificado, pero ¿X11 no utiliza estos métodos? ¿Se comporta en un bitmap-ish o un principio no diferencial en algún nivel? Y si no, ¿por qué ocupa tanto ancho de banda?

El protocolo X11 nunca tuvo la intención de manejar gráficamente (en términos de mapas de bits / texturas) operaciones intensivas. En el día en que X11 se diseñó por primera vez, los gráficos por computadora eran mucho más simples de lo que son hoy.

Básicamente, X11 no envía la pantalla a su computadora, pero envía las instrucciones de visualización para que el servidor X en su computadora local pueda volver a crear la pantalla en su sistema local. Y esto debe hacerse en cada cambio / actualización de la pantalla.
Por lo tanto, su computadora recibe una secuencia de instrucciones como "dibujar una línea en este color desde las coordenadas x, y hasta (xx, yy), dibujar el rectángulo W píxeles de ancho, H píxeles de altura con la esquina superior izquierda en (x, y), etc. "
El cliente local no sabe realmente qué necesita actualizarse y el sistema remoto tiene muy poca información sobre lo que el cliente realmente necesita, por lo que básicamente el servidor debe enviar mucha información redundante que el cliente puede necesitar o no.
Esto es muy eficiente si la pantalla a renderizar consiste en un número limitado de formas gráficas simples y solo se necesita una frecuencia de actualización baja (sin animaciones y demás). Cuál fue el caso en los días en que X11 se desarrolló por primera vez.

Pero las GUI modernas tienen muchos atractivos y mucho de eso debe enviarse desde el sistema remoto a su cliente en forma de mapas de bits / texturas / fuentes que requieren mucho ancho de banda. Y todo tipo de ojos dulces incluye efectos animados que requieren actualizaciones frecuentes. Y las pantallas también se hacen cada vez más grandes, el doble de ancho / alto es 4 veces el número de píxeles.

Por supuesto, con el tiempo, se realizaron mejoras en el protocolo X11 para optimizar esto lo máximo posible, pero el diseño básico subyacente, en esencia, simplemente no se adapta bien a las demandas del tipo de GUI que la gente espera hoy en día.

Otros protocolos (como RDP y VNC) están más diseñados para permitir que el sistema remoto haga todo el trabajo duro y que ese sistema decida qué actualizaciones enviar al cliente (como mapas de bits comprimidos) de la manera más eficiente posible. A menudo, eso resulta ser más eficiente para las GUI modernas.

Ninguno de los métodos es perfecto y puede hacer frente a cada situación igualmente bien. No existe un protocolo de pantalla único que pueda funcionar bien en todos los casos de uso imaginables.
Entonces, en la mayoría de los casos, simplemente prueba todos los protocolos que son compatibles entre su cliente local y el servidor remoto y usa el que brinda los mejores resultados. Y en algunos casos no hay elección y solo tiene que arreglárselas con lo que esté disponible.

La mayoría de los protocolos permiten algunos ajustes de rendimiento, pero muchas de estas configuraciones son solo del lado del servidor y no están disponibles para el usuario promedio. (Y configurarlos correctamente es un poco un arte arcano. Muchos administradores de sistemas no estarán dispuestos a meterse con eso).

En la mayoría de los casos, la forma más fácil de mejorar el rendimiento (a veces de manera bastante dramática) es cambiar a un entorno de escritorio más simple con menos atractivo y renunciar al uso de imágenes de fondo.

Existen principalmente dos razones por las que las conexiones X11 son lentas, las cuales mencionó en su pregunta: ancho de banda y latencia. Para comprender por qué las aplicaciones X11 son lentas en una red, analicemos ambas.

Banda ancha

X11, de forma predeterminada, no comprime los datos de red que se pasan entre la aplicación y el servidor de visualización. Como mencionó, puede usar la opción -C en SSH para habilitar la compresión, y aunque esto ayuda, no está optimizada para comprimir datos gráficos. En comparación con formatos como H.264 que pueden obtener tasas de compresión de 100 a 1, la compresión -C tendrá la suerte de lograr una compresión de 2 a 1. Una mejor solución es usar un códec optimizado de gráficos o video para el video X11, pero debemos tener cuidado de no hacerlo demasiado con pérdida ya que los escritorios generalmente necesitan tener imágenes más nítidas que una película para que el usuario pueda leer claramente el texto y distinguir detalles finos.

Latencia

X11 tiende a tener una latencia alta porque la mayoría de las operaciones requieren múltiples viajes de ida y vuelta entre la aplicación y el servidor de visualización. Cuando se ejecuta en una LAN donde los tiempos de ping miden menos de un milisegundo, estos múltiples viajes de ida y vuelta no se notan, pero a través de una conexión a Internet se suman rápidamente.

Soluciones

Hace varios años, hubo un par de proyectos construidos para abordar los problemas de ancho de banda y latencia inherentes al protocolo X11. lbx (ancho de banda bajo X) y dxpc (compresor de protocolo diferencial X). No creo que lbx haya tenido mucha tracción, pero dxpc se convirtió en la tecnología subyacente utilizada para un producto llamado NX . NX utiliza tanto la compresión con pérdida para reducir los requisitos de ancho de banda como un algoritmo diferencial y el almacenamiento en caché para reducir la cantidad de información de ida y vuelta que crea la alta latencia. He usado NX con bastante frecuencia y encuentro que el rendimiento es casi tan bueno como las aplicaciones locales. Si te sientes con ganas, puedes probar NX y ver si te funciona. La desventaja es que requiere instalar software en ambos extremos de la conexión, mientras que X11 generalmente ya está instalado.