RFB (« remote framebuffer ») es un protocolo simple y abierto para el acceso remoto a interfaces gráficas de usuario . Debido a que funciona a nivel de framebuffer, es aplicable a todos los sistemas y aplicaciones de ventanas, incluidos Microsoft Windows , macOS , X Window System y Wayland . RFB es el protocolo utilizado en Virtual Network Computing (VNC) y sus derivados.
De manera predeterminada, un visor/cliente utiliza el puerto TCP 5900 para conectarse a un servidor (o 5800 para acceder a través de un navegador), pero también se puede configurar para que utilice cualquier otro puerto. Como alternativa, un servidor puede conectarse a un visor en "modo de escucha" (de manera predeterminada, en el puerto 5500). Una ventaja del modo de escucha es que el sitio del servidor no tiene que configurar su firewall/NAT para permitir el acceso en los puertos especificados; la carga recae en el visor, lo que resulta útil si el sitio del servidor no tiene conocimientos informáticos, mientras que se esperaría que el usuario del visor tenga más conocimientos.
Aunque RFB comenzó como un protocolo relativamente simple, se ha mejorado con funciones adicionales (como transferencias de archivos) y técnicas de compresión y seguridad más sofisticadas a medida que se ha desarrollado. Para mantener una compatibilidad cruzada perfecta entre las distintas implementaciones de cliente y servidor VNC, los clientes y servidores negocian una conexión utilizando la mejor versión de RFB y las opciones de compresión y seguridad más adecuadas que ambos puedan admitir.
RFB se desarrolló originalmente en Olivetti Research Laboratory (ORL) como una tecnología de visualización remota para ser utilizada por un cliente ligero simple con conectividad de modo de transferencia asíncrona llamado Videotile. Para mantener el dispositivo lo más simple posible, RFB se desarrolló y se utilizó en lugar de cualquiera de las tecnologías de visualización remota existentes.
RFB encontró un segundo uso más duradero cuando se desarrolló VNC. VNC se lanzó como software de código abierto y la especificación RFB se publicó en la web. Desde entonces, RFB ha sido un protocolo gratuito que cualquiera puede usar.
Cuando se cerró ORL en 2002, algunas de las personas clave detrás de VNC y RFB formaron RealVNC , Ltd., con el fin de continuar con el desarrollo de VNC y mantener el protocolo RFB. El protocolo RFB actual está publicado en el sitio web de RealVNC.
Las versiones publicadas del protocolo RFB son las siguientes:
Los desarrolladores tienen la libertad de añadir tipos de codificación y seguridad adicionales, pero deben reservar números de identificación únicos para estos con los encargados del mantenimiento del protocolo para que los números no entren en conflicto. Los números de tipo en conflicto causarían confusión al establecer una conexión y romperían la compatibilidad cruzada entre implementaciones. La lista de tipos de codificación y seguridad fue mantenida por RealVNC Ltd y es independiente de la especificación del protocolo para que se puedan añadir nuevos tipos sin necesidad de volver a publicar la especificación. Desde diciembre de 2012, la lista pasó a manos de la IANA . [1]
El proyecto TigerVNC aloja una versión comunitaria de la especificación del protocolo RFB que tiene como objetivo documentar todas las extensiones existentes . [2]
Varias codificaciones forman parte de la negociación. Algunas de las codificaciones son pseudocodificaciones que se utilizan para anunciar la capacidad de manejar una determinada extensión. [ cita requerida ] Las codificaciones incluyen: [2]
De las codificaciones basadas en imágenes definidas públicamente, las más eficientes son los tipos de codificación Tight. TightVNC define dos tipos de codificaciones: la codificación Tight (una mezcla de relleno de rectángulo, paleta y degradado con zlib y JPEG, más una "compresión básica" de Zlib más filtro) [3] y la codificación Tight PNG (codificación Tight con compresión básica reemplazada por datos PNG ).
Se ha investigado el formato H.264 para codificar datos RFB, pero un desarrollador de TurboVNC describió los resultados preliminares (utilizando el formato Open H.264) como mediocres . Se vuelve más eficiente con menos fotogramas I (fotogramas clave), pero el uso de la CPU sigue siendo un problema. [4]
En términos de transferencia de datos del portapapeles, "actualmente no hay forma de transferir texto fuera del conjunto de caracteres Latin-1". [5] Una extensión de pseudocodificación común resuelve el problema al usar UTF-8 en un formato extendido. [2] : § 7.7.27
El protocolo VNC se basa en píxeles. Aunque esto genera una gran flexibilidad (es decir, se puede mostrar cualquier tipo de escritorio), a menudo es menos eficiente que las soluciones que tienen una mejor comprensión del diseño gráfico subyacente, como X11 o el escritorio como RDP . Esos protocolos envían primitivas gráficas o comandos de alto nivel en una forma más simple (por ejemplo, abrir una ventana), mientras que RFB solo envía los datos de píxeles sin procesar, aunque comprimidos.
El protocolo VNC expresa el estado de los botones del ratón en un solo byte, como binario arriba/abajo. Esto limita el número de botones del ratón a ocho (efectivamente 7, dada la convención del botón 0 que significa "desactivado"). Muchos ratones modernos enumeran 9 o más botones, lo que hace que los botones de avance/retroceso no tengan efecto sobre RFB. Una extensión "GII" resuelve este problema. [2] : § 7.7.11
No existe ningún estándar para transferir datos de sonido, con la única excepción de que el servidor puede indicar que el cliente debe reproducir una campana (pitido audible, sonido de notificación). [2] : § 7.6.3