No SFHTML5 Tudo sobre WebRTC Durante um encontro do MeetUp no início desta semana (naquele evento, nosso CEO, Ben Strong, falou sobre o assunto), uma pergunta persistiu: se o WebRTC é ponto a ponto, por que precisamos de servidores STUN e TURN?
O WebRTC precisa funcionar 100% do tempo.
O WebRTC pode ser a solução definitiva para a comunicação. O que poderia ser melhor do que conexões ponto a ponto de vídeo, áudio e dados baseadas em código aberto?
Muitos desenvolvedores criaram aplicações WebRTC sem servidores STUN ou TURN. E elas funcionam bem. Na maioria das vezes. É o "resto do tempo" que gera dúvidas. A menos que você tenha certeza de que sua solução WebRTC funciona em TODAS as situações, é difícil confiar nela como seu sistema principal.
É aí que entram os servidores.
Precisa conectar-se a várias redes? Você precisará de um servidor.
O WebRTC funciona perfeitamente ao conectar navegadores dentro da mesma rede local. Mas assim que você começa a acessar dados fora da sua rede – através de um firewall corporativo, por exemplo – você vai precisar de um pouco mais de, digamos, poder de fogo.
As configurações de firewall não permitem a entrada de WebRTC sem o uso do protocolo STUN (Session Traversal Utilities for NAT) ou TURN (Traversal Using Relays around NAT). É por isso que você precisará de um servidor.
O STUN tenta abrir uma brecha no firewall para que sua chamada possa ser transmitida. Esse protocolo funciona na maioria das vezes. Se uma conexão for estabelecida usando STUN, você terá criado uma conexão ponto a ponto. Isso é ótimo porque uma conexão baseada em STUN não exige muito processamento da CPU ou da rede do servidor.
Quando o STUN não é suficiente, o protocolo TURN é necessário. Quando o TURN é usado, a conexão é retransmitida pelo servidor e não é ponto a ponto. A conexão retransmitida utiliza tanto a rede quanto o poder de processamento do servidor, o que limita o número de conexões que podem ser gerenciadas em um único servidor simultaneamente. (E se você precisar de muitas conexões, precisará de muitos servidores.)
Como o sistema determina o que é necessário?
O ICE é o protocolo seguido para determinar qual caminho usar, desde o menos complicado: o host, usado quando a conexão WebRTC está na mesma rede local, até os progressivamente mais complicados: os protocolos STUN e TURN, ambos exigindo servidores.
Certo, então preciso de um servidor. E agora?
Se você decidiu usar o WebRTC e precisa de confiabilidade de acordo com o padrão 100%, então você está no território dos servidores.
O que é importante considerar ao pensar em seus servidores? Acreditamos que você deva ter três prioridades:
- Latência
- Backup e redundância
- Balanceamento de carga (rede e CPU)
Existem vários caminhos disponíveis para construir sua infraestrutura de servidor. A melhor opção para você dependerá de suas habilidades de desenvolvimento, tempo disponível e orçamento.
Opção um: AWS. Muitos detalhes sobre o uso da AWS, incluindo algumas implicações de preço, estão descritos em nossa publicação de junho., Tunelamento WebRTC sobre TCP (e por que isso é importante). Um aspecto importante da AWS é que você pode selecionar suas próprias prioridades em relação à latência e à redundância.
Opção dois: Servidor TURN de código aberto. (Um exemplo pode ser encontrado) aqui.Muitos puristas determinados a construir sua própria solução considerarão esse caminho. Sua tarefa será garantir que os servidores estejam em funcionamento em locais com baixa latência para todos os usuários (distribuídos geograficamente) e que possam ser dimensionados para suportar a carga.
Opção três: vLine para desenvolvedores. Passamos mais de dois anos focados exclusivamente na criação de uma plataforma WebRTC que funciona 100% do tempo. Para aqueles que desejam adicionar funcionalidades baseadas em WebRTC ao seu site, mas querem investir seus recursos no restante do negócio – e não em acompanhar a rápida evolução do cenário WebRTC.
Uma maneira rápida de ter uma ideia da qualidade da nossa plataforma é usar Link vLine, que se baseia na mesma plataforma global que você pode usar para sua solução.
Teremos todo o prazer em responder às suas perguntas. Envie-nos um e-mail para [email protected] ou encontre-nos @vlineinc.