Arquitetura e fluxo de dados¶
O Drovio assenta em WebRTC para oferecer uma experiência rápida e de baixa latência, com as melhores codificações de áudio e vídeo do momento, AV1, VP9 e VP8, mantendo ao mesmo tempo uma arquitetura ponto a ponto altamente segura e atenta à privacidade.
Visão geral¶
O Drovio é composto por um software de servidor, o Drovio Server, disponível apenas na edição Enterprise, e por um software cliente, a aplicação Drovio. A solução fornece igualmente um client web, que permite juntar-se a qualquer sessão de partilha de ecrã ou a qualquer chamada sem descarregar, instalar nem subscrever seja o que for.
O percurso interativo abaixo segue uma sessão desde a autenticação até aos fluxos, e indica os protocolos e as portas envolvidos em cada passo.
Fluxo de ligação¶
HTTPS · TLS 1.2 / 1.3 · 443
A autenticação no Drovio faz-se em HTTPS, TLS 1.2 ou 1.3. São depois abertas ligações WebSocket entre o Drovio Server e os clientes para transportar toda a sinalização.
Na edição Enterprise, os protocolos e as suites de cifra ativados definem-se com http.tls_protocols e http.tls_cipher_suites.
WebSocket (WSS) · 443
A sinalização, no sentido do WebRTC, designa a troca das capacidades de difusão, os codecs de áudio e vídeo, e das capacidades de rede entre as extremidades, ou seja, os clientes. Os SDP e os candidatos ICE circulam entre o anfitrião e o convidado através do Drovio Server, sobre WebSocket.
O SDP, Session Description Protocol, serve para enumerar os fluxos suportados. Em paralelo, os candidatos ICE disponíveis são recolhidos em cada extremidade, designando cada um um endereço IP, uma porta e uma camada de transporte possíveis. São trocados e formam pares de candidatos. Vários pares são retidos mas apenas um é selecionado para suportar a comunicação ponto a ponto, salvo em caso de reinicialização ICE, que obriga a renegociar a ligação e a selecionar outro. O Drovio trata disso de forma transparente.
STUN · UDP 443
Durante a sinalização, os clientes podem apoiar-se num servidor STUN, Session Traversal Utilities for NAT, para atravessar um NAT. A sua única razão de ser é responder à pergunta «qual é o meu endereço IP público?».
DTLS-SRTP / SCTP · UDP 1024-65535
As ligações ponto a ponto estabelecem-se depois diretamente entre os clientes. Um fluxo de vídeo em direto do ecrã ou da aplicação do anfitrião é enviado aos convidados, acompanhado se for o caso de um fluxo de áudio, microfone ou som do sistema. Os convidados podem também partilhar o seu microfone e enviar ações de rato e de teclado, que o anfitrião pode retirar a qualquer momento, ver Acesso e controlo de sessões. O Drovio Server não intervém durante a sessão de partilha de ecrã, a não ser para recolher algumas estatísticas destinadas a melhorar a experiência, ver Estatísticas.
TURN · UDP/TCP 443 · UDP 49152-65535
Quando as firewalls ou as regras de NAT são demasiado restritivas, as ligações diretas não se conseguem estabelecer entre os clientes. Entram então em ação servidores de retransmissão, TURN, Traversal Using Relays around NAT, que encaminham os pacotes de um cliente para o outro. A comunicação permanece cifrada de ponta a ponta: um servidor de retransmissão encaminha pacotes que não consegue decifrar, uma vez que as chaves são negociadas apenas entre as extremidades.
Na edição Cloud, os servidores STUN e TURN estão alojados na AWS e distribuídos por todo o mundo. Suportam cerca de 15 % das sessões de partilha de ecrã, e é usado o servidor geograficamente mais próximo do utilizador quando necessário. Na edição Enterprise estes servidores são opcionais: podemos ajudá-lo a implantar os seus quando a partilha de ecrã tiver de passar pela Internet, ver Servidor de retransmissão (TURN).
Um servidor de retransmissão não é um proxy aberto. Obter uma alocação exige credenciais de duração limitada derivadas de um segredo partilhado, as alocações expiram ao fim de alguns minutos, e o servidor recusa destinos de loopback e de multicast, pelo que não pode ser voltado contra redes internas. O TLS 1.0 e o 1.1 estão desativados, a sua lista de suites de cifra está restringida às suites ECDHE modernas, e não anuncia a sua versão de software.
Resumo dos protocolos e das portas¶
| Passo | Protocolo(s) | Porta(s) |
|---|---|---|
| Autenticação | HTTPS (TLS 1.2 / 1.3) | TCP 443 |
| Sinalização | HTTPS e WebSocket (WSS) | TCP 443 |
| STUN | UDP | 443 |
| Partilha de ecrã (ponto a ponto) | DTLS-SRTP, DTLS-SCTP | UDP 1024-65535, à saída e no retorno |
| TURN (retransmissão) | UDP / TCP para alcançar o servidor, depois UDP para os fluxos retransmitidos | 443, depois 49152-65535 |
Sobre a gama ponto a ponto. 1024-65535 não é uma lista de portas a abrir num
servidor. São as portas de média do WebRTC: em cada sessão, cada extremidade
escolhe uma porta efémera própria e anuncia-a como candidato ICE. O que uma
firewall tem de autorizar é o UDP de saída e o seu tráfego de retorno, não uma
porta fixa. Onde isso não é possível, a sessão passa para TURN e tudo segue pela
porta 443.
Sobre as portas do servidor de retransmissão. 49152-65535 é a gama de
alocação do próprio servidor, não a dos clientes. Na edição Cloud os nossos
servidores escutam apenas na 443, em UDP e em TCP, o que atravessa a maioria
das firewalls empresariais. Na edição Enterprise as portas são à sua escolha: o
guia Servidor de retransmissão (TURN) sugere a
80 e a 443 pela mesma razão.