Arquitectura y flujo de datos¶
Drovio se apoya en WebRTC para ofrecer una experiencia rápida y de baja latencia, con las mejores codificaciones de audio y de vídeo del momento, AV1, VP9 y VP8, conservando a la vez una arquitectura entre pares altamente segura y respetuosa con la privacidad.
Visión general¶
Drovio se compone de un software servidor, Drovio Server, disponible únicamente en la edición Enterprise, y de un software cliente, la aplicación Drovio. La solución ofrece además un cliente web, que permite unirse a cualquier sesión de pantalla compartida o a cualquier llamada sin descargar, instalar ni suscribirse a nada.
El recorrido interactivo de más abajo sigue una sesión desde la autenticación hasta los flujos, e indica los protocolos y los puertos implicados en cada paso.
Flujo de conexión¶
HTTPS · TLS 1.2 / 1.3 · 443
La autenticación en Drovio se realiza en HTTPS, TLS 1.2 o 1.3. A continuación se abren conexiones WebSocket entre Drovio Server y los clientes para llevar el conjunto de la señalización.
En la edición Enterprise, los protocolos y las suites de cifrado activados se ajustan con http.tls_protocols y http.tls_cipher_suites.
WebSocket (WSS) · 443
La señalización, en el sentido de WebRTC, designa el intercambio de las capacidades de difusión, es decir los códecs de audio y de vídeo, y de las capacidades de red entre los extremos, esto es, los clientes. Los SDP y los candidatos ICE circulan entre el anfitrión y el invitado por intermedio de Drovio Server, sobre WebSocket.
El SDP, Session Description Protocol, sirve para enumerar los flujos admitidos. En paralelo, los candidatos ICE disponibles se recopilan en cada extremo, y cada uno designa una dirección IP, un puerto y una capa de transporte posibles. Se intercambian y forman pares de candidatos. Se retienen varios pares, pero solo uno se selecciona para llevar la comunicación entre pares, salvo en caso de reinicialización ICE, que obliga a renegociar la conexión y a seleccionar otro. Drovio se encarga de ello de forma transparente.
STUN · UDP 443
Durante la señalización, los clientes pueden apoyarse en un servidor STUN, Session Traversal Utilities for NAT, para atravesar un NAT. Su única razón de ser es responder a la pregunta «¿cuál es mi dirección IP pública?».
DTLS-SRTP / SCTP · UDP 1024-65535
Las conexiones entre pares se establecen luego directamente entre los clientes. A los invitados se les envía un flujo de vídeo en directo de la pantalla o de la aplicación del anfitrión, acompañado en su caso de un flujo de audio, micrófono o sonido del sistema. Los invitados también pueden compartir su micrófono y enviar acciones de ratón y de teclado, que el anfitrión puede retirar en cualquier momento, consulte Acceso y control de las sesiones. Drovio Server no interviene durante la sesión de pantalla compartida, salvo para recopilar algunas estadísticas destinadas a mejorar la experiencia, consulte Estadísticas.
TURN · UDP/TCP 443 · UDP 49152-65535
Cuando los cortafuegos o las reglas de NAT son demasiado restrictivos, las conexiones directas no llegan a establecerse entre los clientes. Entran entonces en juego servidores de retransmisión, TURN por Traversal Using Relays around NAT, que transmiten los paquetes de un cliente al otro. La comunicación sigue cifrada de extremo a extremo: un servidor de retransmisión transmite paquetes que no puede descifrar, ya que las claves se negocian únicamente entre los extremos.
En la edición Cloud, los servidores STUN y TURN están alojados en AWS y desplegados por todo el mundo. Soportan alrededor del 15 % de las sesiones de pantalla compartida, y es el servidor geográficamente más cercano al usuario el que se emplea llegado el caso. En la edición Enterprise, estos servidores son opcionales: podemos ayudarle a desplegar los suyos cuando la pantalla compartida deba pasar por Internet, consulte Servidor de retransmisión (TURN).
Un servidor de retransmisión no es un proxy abierto. Obtener una asignación exige credenciales de duración limitada derivadas de un secreto compartido, las asignaciones caducan al cabo de unos minutos, y el servidor rechaza los destinos de bucle local y de multidifusión, de modo que no puede volverse contra redes internas. TLS 1.0 y 1.1 están desactivados en él, su lista de suites de cifrado se limita a las suites ECDHE modernas, y no anuncia su versión de software.
Resumen de los protocolos y los puertos¶
| Paso | Protocolo(s) | Puerto(s) |
|---|---|---|
| Autenticación | HTTPS (TLS 1.2 / 1.3) | TCP 443 |
| Señalización | HTTPS y WebSocket (WSS) | TCP 443 |
| STUN | UDP | 443 |
| Pantalla compartida (entre pares) | DTLS-SRTP, DTLS-SCTP | UDP 1024-65535, de salida y de retorno |
| TURN (retransmisión) | UDP / TCP para alcanzar el servidor, luego UDP para los flujos retransmitidos | 443, luego 49152-65535 |
Sobre el rango entre pares. 1024-65535 no es una lista de puertos que haya
que abrir en un servidor. Son los puertos de medios de WebRTC: en cada sesión,
cada extremo elige un puerto efímero propio y lo anuncia como candidato ICE. Lo
que un cortafuegos debe autorizar es el UDP saliente y su tráfico de retorno,
no un puerto fijo. Allí donde eso no es posible, la sesión recurre a TURN y todo
pasa por el puerto 443.
Sobre los puertos del servidor de retransmisión. 49152-65535 es el rango de
asignación del propio servidor de retransmisión, no el de los clientes. En la
edición Cloud, los nuestros escuchan solo en el 443, tanto en UDP como en TCP,
lo que atraviesa la mayoría de los cortafuegos corporativos. En la edición
Enterprise es usted quien elige los puertos: la guía
Servidor de retransmisión (TURN) sugiere el 80
y el 443 por la misma razón.