Há algumas semanas, ativamos discretamente o suporte para tunelamento TCP bilateral na nuvem vLine, tornando-nos os primeiros. provedor de infraestrutura WebRTC Para permitir a conexão através de firewalls que bloqueiam UDP. Isso pode não parecer interessante ou importante, mas na verdade faz toda a diferença entre ter um serviço que "geralmente se conecta" e um que "simplesmente funciona". Vamos explicar:
Uma das muitas vantagens do WebRTC é a relativa facilidade de configuração inicial. Basta iniciar uma instância do aprortc No backend para sinalização, basta copiar e colar um pouco de JavaScript e, pronto, você estará fazendo videochamadas no seu aplicativo (na verdade, é um pouco mais complicado do que isso, mas um bom desenvolvedor web consegue facilmente ter um chat de vídeo de demonstração funcionando em um ou dois dias).
Infelizmente, o caminho da demonstração ao serviço de nível de produção pode ser mais desafiador do que você imagina (e mais caro!). Geralmente, acontece assim:
Nível 1: ATORDOAMENTO
Você começa fazendo suas primeiras chamadas em uma rede local e tudo funciona perfeitamente. Que ótimo! Então você tenta ligar para alguém fora do seu firewall e uma de duas coisas acontecerá.
1) Se por acaso você copiou e colou o endereço do servidor STUN do Google do código-fonte do apprtc, sua chamada será bem-sucedida e você ficará satisfeito (embora possa ter algumas dúvidas persistentes sobre se é correto usar um serviço não documentado para o qual o Google não deu permissão explícita a desenvolvedores terceirizados). Observe o silêncio do Google sobre o assunto. este tópico).
2) Se você não tiver um servidor STUN configurado, sua chamada falhará. Uma breve pesquisa revelará que STUN é um protocolo que o navegador usa para determinar seu endereço IP público e abrir uma brecha no firewall. Portanto, se você quiser se conectar através de um firewall, precisará de um servidor STUN. Algumas horas depois, você terá um servidor de código aberto funcionando no EC2. Uma instância pequena deve ser suficiente ($43,92 por mês), mas provavelmente você vai querer executar pelo menos duas para garantir a disponibilidade, de preferência em regiões diferentes ($87,84 por mês).
Nível 2: GIRAR
Você faz mais algumas chamadas de teste e todas funcionam. Tudo parece bem. Então você tenta fazer uma chamada entre duas redes corporativas e ela falha. Grrr. Enquanto pesquisava sobre STUN, você leu sobre outro protocolo chamado TURN Isso é usado para retransmitir dados nos casos em que o navegador não consegue estabelecer uma conexão ponto a ponto. Você não tinha certeza se era estritamente necessário, mas uma pesquisa mais aprofundada revela que o STUN é suficiente apenas para conectar cerca de 80% chamadas. Se isso não for suficiente para você (e provavelmente não será), você precisará de um servidor TURN.
Um pouco tópicos da lista de discussão Mais tarde, você terá um servidor TURN funcionando em sua instância EC2. Na verdade, a taxa de transferência de rede em uma instância pequena pode ser bastante imprevisível se outras pessoas estiverem usando sua interface de rede compartilhada, então você deve considerar obter uma instância maior. Uma instância média ($87,84 por mês) funciona muito bem, mas para obter a maior previsibilidade e a menor instabilidade (jitter), você precisará de uma instância extra grande ($351,36 por mês), que lhe dará “alto desempenho de rede”Na verdade, serão dois ($703,52 por mês), para garantir a disponibilidade.
Claro, como você está retransmitindo vídeo, também precisará levar em consideração os custos de largura de banda. O preço base do EC2 é $0,12 por GB. Ao analisar os números, você pode começar a se perguntar o que impede que outra pessoa use o servidor público que você acabou de configurar e aumente seus gastos com banda larga. Aqui está uma boa resposta: tópico da lista de discussão Sobre o assunto. Resumo: não há uma maneira eficaz de evitar isso, dada a forma como o protocolo TURN funciona e o fato de as credenciais TURN precisarem estar presentes no seu JavaScript, onde qualquer pessoa pode encontrá-las.
Mas não vamos nos prender aos detalhes financeiros. Agora você pode ligar para seus amigos em outras empresas de tecnologia. Incrível! Aí você tenta ligar para alguém em uma grande empresa, de outro ramo, e não dá certo. Puxa vida. Você achava que a TURN tinha tudo sob controle.
Vinte minutos depois, após uma breve pesquisa, você descobre que a implementação de alocação TURN do Chrome suporta apenas o retransmissão de pacotes UDP. O Chrome 28 adicionará suporte para... alocação Um servidor TURN sobre TCP, mas os pacotes ainda serão retransmitidos via UDP. Opa, isso ainda não resolve seu problema quando o firewall bloqueia o tráfego UDP.
Nível 3: Nuvem vLine
É aqui que entra em ação nosso novo suporte a túneis TCP. Ele não depende da implementação TURN do Chrome, portanto, funciona no Chrome atualmente. Além disso, funciona mesmo se ambas as partes estiverem atrás de firewalls que bloqueiam UDP. Tudo o que é necessário é acesso à internet pela porta 443 (a porta HTTPS), que a grande maioria dos firewalls permite.
Você não precisa fazer nada de especial para habilitar o túnel TCP no seu serviço vLine. Basta usar o vline.js para construir seu aplicativo e nós nos conectaremos usando o melhor método disponível para cada chamada. Executamos um rede global de servidores de alta disponibilidade, Assim, garantimos a melhor qualidade de chamada possível para todos os seus usuários, em qualquer lugar do mundo, mesmo atrás de firewalls que bloqueiam tudo, exceto o tráfego TCP na porta HTTPS. E, caso esteja se perguntando, ainda utilizamos DTLS de ponta a ponta, portanto, nossos servidores nunca veem seus fluxos de mídia não criptografados.
Nosso objetivo é uma taxa de conexão de 100%. Se você tiver uma rede onde as chamadas não estão sendo conectadas, por favor... nos avise.
Nota 1: Se você quiser testar isso bloqueando o UDP no seu firewall, lembre-se de deixar a porta DNS (53) aberta.
Nota 2: Alguns firewalls ultrarrestritivos que realizam inspeção de pacotes com estado ainda podem bloquear conexões, pois, embora o navegador esteja usando a porta HTTPS, ele não está realmente usando SSL/TLS (nunca encontramos um firewall assim na prática, mas eles existem). O Chrome em breve oferecerá suporte a conexões WebRTC sobre TLS, momento em que também poderemos contornar esses firewalls.