RFB (protocolo)
 | Este artículo tiene varios problemas. Ayúdenos a mejorarlo o a discutir estos problemas en la página de discusión . ( Aprenda cómo y cuándo eliminar estos mensajes )
|
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.
Descripción
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.
Historia
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íncrono 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.
Versiones
Las versiones publicadas del protocolo RFB son las siguientes:
| Versión | Publicado | Fecha | Especificación |
|---|---|---|---|
| RFB3.3 | ORL | Enero de 1998 | El protocolo Framebuffer remoto 3.3 |
| RFB3.7 | RealVNC Ltd | Agosto de 2003 | El protocolo Framebuffer remoto 3.7 |
| RFB 3.8 (actual) | RealVNC Ltd | Junio de 2007 | El protocolo Framebuffer remoto 3.8 |
| RFC de la IETF (3.8) | RealVNC Ltd | Marzo de 2011 | RFC 6143 |
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 que entran 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 está separada 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]
Tipos de codificación
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]
- Crudo
- Zlib
- Ajustado
- XZ
- H.264
- PNG apretado
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]
Limitaciones
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 permite una gran flexibilidad (es decir, se puede visualizar cualquier tipo de escritorio), suele ser menos eficiente que las soluciones que tienen una mejor comprensión del diseño gráfico subyacente, como X11 o el escritorio, como RDP . Estos 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 un 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
Véase también
- Comparación de software de escritorio remoto
- Tecnología NX y Xpra para conexiones remotas eficientes del sistema X Window
- CONDIMENTAR
- Protocolo de escritorio remoto (RDP)
Referencias
- ^ "Buffer de cuadros remoto (RFB)". www.iana.org .
- ^ abcde "El protocolo RFB, edición comunitaria". GitHub . 8 de agosto de 2022.
- ^ "VNC Tight Encoder - Resultados de la comparación". www.tightvnc.com .
- ^ Comandante, DR. "Un estudio sobre la utilidad de la codificación H.264 en un entorno VNC". turbovnc.org .
- ^ Richardson, Tristan (2010). "Secciones 6.4.6, 6.5.4". El Protocolo RFB - Versión 3.8 .
Enlaces externos
- El Protocolo RFB - Versión comunitaria
- RFC 6143: Protocolo de búfer de trama remoto (describe la versión 3.8, 2011)
- El Protocolo RFB - Versión 3.8 (2010-11-26)
- El Protocolo RFB - Versión 3.7 (12 de agosto de 2003)
- El Protocolo RFB - Versión 3.3 (1998-01)
