GLINT: protocolo propietario para conectar al usuario al escritorio remoto

Temas tratados en el evento:

El evento de hoy está dirigido por Ruslán Belov, director de producto de Space VDI. Comentó que los protocolos de acceso son un tema interesante y complejo. Y comenzó hablando del protocolo GLINT, de los problemas de los protocolos y para qué se necesita un protocolo de este tipo. Mencionó brevemente la historia mundial de los protocolos.

Es decir, lo primero son las ventajas y características del protocolo, cómo podemos configurar y adaptar GLINT a una solución específica, su ancho de banda. Veremos cómo se comporta el protocolo al cambiar el ancho de banda. Veremos qué opciones hay para interactuar con los periféricos de conexión de dispositivos. Y lo más importante, son los planes de desarrollo de nuestro protocolo, hacia dónde nos dirigimos, qué funcionalidades adicionales aparecerán.

En cuanto a los propios protocolos, hemos identificado y definido los siguientes requisitos para el propio protocolo de acceso: garantizar la consistencia al decodificar el vídeo, es decir, que la imagen no se deteriore y que el usuario pueda trabajar cómodamente en entornos VDI, en diferentes perfiles. Es necesario tener en cuenta este punto, es decir, nuestro algoritmo de pulsación y las opciones, respectivamente, de visualización de la propia imagen en el lado del cliente, es decir, que todo esté en tiempo real con la mínima latencia. Para ello, también es necesario adaptar el protocolo a la arbitraje de flujos en canales virtuales y otras opciones de transmisión de diferentes señales, es decir, no sólo la propia imagen que proviene de la captura de fotogramas de la sesión remota, sino también la gestión de la entrada y salida de dispositivos, es decir, como USB, cámaras, teclado, ratón y otros.

Capacidad de respuesta en tiempo real, es decir, garantizar el equilibrio del tráfico, la determinación de latencias, la captura de fotogramas clave para poder seguir construyendo esta imagen. Y el último punto es la recuperación y la predicción. Es decir, en caso de que haya habido alguna caída en la red, o haya habido algún otro problema con la carga en el rendimiento de los propios dispositivos, para que el propio protocolo pueda entender qué fotogramas necesita mostrar, cuáles omitir. Y, en consecuencia, lo último es la predicción, pero aquí ya hay opciones para las nuevas tecnologías, es decir, los sistemas neuronales, como los juegos en la nube o similares, que en algunos casos los procesadores que tienen núcleos para redes neuronales pueden predecir fotogramas específicos, aumentando así el número de fotogramas, es decir, los FPS, y permitiendo proporcionar la fluidez de la propia imagen, así como la calidad de la visualización.

Y la pregunta más importante es, ¿para qué se necesita un protocolo, para qué inventar algo, cuando ya existe el protocolo RDP en el mercado, todo el mundo lo usa, satisface las necesidades del mercado y está muy bien optimizado por la propia empresa Microsoft? Este es precisamente uno de los primeros problemas de este protocolo, es precisamente el protocolo propietario de la empresa Microsoft, pero aquí mismo tiene la ventaja de que establece estándares, tiene derecho a ello, es uno de los primeros que apareció en el mundo del acceso remoto, por lo que puede establecer las reglas de cómo podemos construir nuestro protocolo. Por supuesto, cada protocolo tiene sus propias características. Y en cuanto a la desventaja de RDB, está organizado precisamente para el ecosistema de Microsoft. Si utilizamos servidores terminales, RDS, etc., entonces RDP es la mejor solución en este sentido, porque de forma nativa permiten proporcionar acceso remoto a dichas soluciones.

Pero si ya pasamos al mercado actual, a la situación actual del sistema operativo en nuestro país, es decir, ya son sistemas operativos basados en núcleos Linux, es decir, Astra Linux, RedOS, entonces la solución RDP dificulta el desarrollo y la adaptación a estos sistemas operativos.

Por lo tanto, aparecen varias soluciones, como Open RDP, SPICE, VNC, que proporcionan una base de paquetes abierta, y podemos utilizar estos desarrollos y adaptarlos a nuestro ecosistema. De estos protocolos, que quería señalar en el entorno VDI, son respectivamente el protocolo RDP, el protocolo BLAST y ECA, es decir, el protocolo Citrix. Aquí no se muestra en la diapositiva, pero también es muy popular y se utiliza con frecuencia. Las ventajas de estos protocolos se indican aquí, es decir, un gran soporte tanto de periféricos como de opciones de cifrado. BLAST tiene su propia tecnología propietaria con equilibrio, pero tanto RDP está diseñado precisamente para su propia infraestructura, es decir, para Windows, y BLAST está diseñado precisamente para funcionar correctamente en VMware. Todo esto no permite tomarlo y aplicarlo a VDI en nuestras soluciones.

Y por lo tanto, lo primero que se utilizó fue el protocolo SPICE, VNC, como FreeRDP y xRDP. Pueden permitir proporcionar acceso remoto, pero tienen grandes desventajas. En algunos paquetes, no hay soporte de sonido, no hay, por ejemplo, transferencia de algunos dispositivos y además se adaptan mal a los canales deficientes, lo cual es la principal característica para la solución VDI. Es decir, cuando construimos una red, calculamos los recursos para cada usuario, debemos entender claramente que necesitamos el máximo ancho de banda para, respectivamente, distribuirlo entre los usuarios y estar seguros de que, por ejemplo, en modo de sesión cargada, cuando tenemos cientos de usuarios y al mismo tiempo están conectados a alguna videoconferencia, es decir, hay transmisión de vídeo, audio, dispositivos periféricos involucrados, que nuestro canal lo soporta y cumplimos con los parámetros necesarios.

En cuanto al protocolo GLINT, tiene la configuración más amplia para el perfil de uso. Es decir, si entramos en la configuración del propio protocolo Glint, podemos ver un gran número de parámetros que podemos ajustar a determinados escenarios. En un futuro próximo, planeamos lanzar una versión simplificada de esta configuración, es decir, como en algunas aplicaciones hay una opción de baja calidad, calidad media, alta calidad o adaptación al ancho de banda. Planeamos implementar esta opción para que a los administradores que configuran ya esta configuración en los clientes, sea más fácil entender cómo configurar para un escenario de uso específico. Y además de esto, también una de las principales características es el acceso centralizado a la configuración del protocolo desde el propio administrador. Esta es también una ventaja del protocolo propietario, porque es nuestro, podemos adaptarlo a los sistemas VDI, podemos gestionar la configuración no directamente desde la parte del cliente. Lo principal, respectivamente, es el acceso a la cuenta de dominio, es decir, sin esto no se puede. Y si tomamos soluciones basadas en Open Source, entonces en algunos casos no existe esta posibilidad. O hay que añadir código, o conectar algunas bibliotecas adicionales.

Limitación del ancho de banda establecido, es decir, es lo que podemos indicar para un ancho de banda específico y por encima de él los usuarios no ocuparán el canal. Disponibilidad en modos de entorno de software protegido Astra Linux, aquí se entiende que para las soluciones Space manager y Space client... (Space manager es un broker que gestiona las conexiones de los usuarios, se basa en el sistema operativo Astra Linux, bajo el cual construimos nuestro VDI). Se admiten otros sistemas operativos. Desde la parte del cliente, es un amplio espectro de estos sistemas operativos. En la parte del servidor, ofrecemos la posibilidad de precisamente dos sistemas operativos: RedOS y Astrа Linux. Aquí por ahora estos dos sistemas operativos porque ahora son los más demandados en el mercado nacional. Y con Astra Linux estamos realizando una evaluación de la compatibilidad en modo de programa protegido.

Selección del protocolo de seguridad, gestión de la calidad del muestreo de sonido. Y también esto es lo principal, es la flexibilidad en la adaptación a soluciones específicas. La segunda cualidad principal de un protocolo propietario es que podemos cambiar la base de código. Por lo tanto, ya el cliente puede influir en el desarrollo del protocolo y proponer algunas soluciones que sean necesarias para su infraestructura. Y lo último es la transmisión de la señal de control de los dispositivos del usuario al servidor para cualquier programa y aplicación que requiera muchos recursos. Aquí la cualidad importante del protocolo GLINT es que, incluso si hay un ancho de banda del canal muy bajo, continuará su interacción con la sesión remota, no se interrumpirá y nos proporcionará señales a la parte del cliente. Incluso se nos proporcionarán fotogramas de 4 píxeles, no veremos nada, pero la estabilidad del propio protocolo continuará, es decir, se realizará la autoconexión. Y cuando se restaure nuestra red, respectivamente, el protocolo ocupará el ancho de banda que necesite y continuará su interacción. Esta es otra ventaja sobre las soluciones de código abierto.

Nuestro protocolo utiliza paquetes freeRDP. Decidimos dedicarnos a esto al principio del establecimiento de nuestro protocolo. Tomamos este protocolo precisamente por el hecho de que se adapta muy bien a Linux y es muy fácil de personalizar. Queda poco del propio freeRDP, es decir, hemos reescrito tanto la parte del cliente como la del servidor, pero cuando aparecen nuevas soluciones de freeRDP, intentamos verlas, reescribir el código precisamente para nuestras soluciones.

Por lo tanto, aquí no encontrará el propio GLINT en ningún repositorio externo, está allí con nosotros, y esta es también su ventaja, donde nadie podrá hacer sus variantes que violen la seguridad. Posibilidades de un trabajo cómodo en VDI, pero esto, como ya he dicho, la solución de outsourcing freeRDP no permite trabajar cómodamente en VDI, porque ocupa todo el ancho de banda, con bajos anchos de banda del canal empieza a desmoronarse e incluso a desconectarse. En algún momento puede que no tengamos una sesión GLINT, pero al mismo tiempo todo se mantendrá. Aquí todo está genial, y esto se debe a que hemos dividido el protocolo en módulos que permiten optimizar este protocolo en una parte específica. Es decir, bitrate, framerate, sonido y varias opciones de trabajo con otros canales virtuales. Es decir, tanto el portapapeles, como la conexión de dispositivos, y el resto de opciones.

En cuanto a las mediciones. Aquí se puede ver el gráfico de medición del protocolo GLINT (ver diapositiva anterior). Se realizó al medir la velocidad del flujo a 30 megabits por segundo. Aquí podemos ver que GLINT muestra el valor medio en cada escenario. Es decir, aquí tenemos el escenario: trabajo con modelado 3D, trabajo con la visualización de YouTube a pantalla completa, en un medio de pantalla, navegación web, presentación, trabajo con tablas y trabajo en un editor de texto. El propio protocolo, si se mira en cuanto a RDP, intenta ocupar el máximo ancho de banda, por lo que vemos aquí que llega a los 30 megabits por segundo en el caso de los valores medios, y en los valores máximos puede ocupar un ancho de banda mayor. Incluso si se limita, en la primera conexión tomará la cantidad necesaria de fotogramas y distribuirá la carga más adelante. Bluetooth, respectivamente, tiene un menor ancho de banda del canal, en este caso no lo ocupa todo e intenta mantener los valores medios, es decir, aproximadamente como el protocolo BLAST, si se mira este gráfico.

Pasemos ahora a los periféricos. Las posibilidades de GLINT en los periféricos son amplias, esto es tanto la conexión a teclado y ratón con cable, el trabajo con dispositivos USB, como memorias flash o la transferencia de directorios.

El trabajo con SmartCAD y tokens actualmente se implementa precisamente para los tokens ruToken. En la versión actual se está ampliando esta posibilidad y de esto ya hablamos en nuestra hoja de ruta. Trabajo con auriculares USB y reproducción de sonido, trabajo con auriculares, respectivamente, auriculares de 3,5 mm. Trabajo con cámara USB con compresiones, trabajo con cámaras integradas y trabajo con dos monitores para la solución, cuando es necesario, respectivamente, transmitir la imagen a dos monitores.