Como o JS funciona: comunicações WebRTC e P2P

Hoje estamos publicando uma tradução da parte 18 de uma série de materiais dedicados a tudo relacionado ao JavaScript. Aqui falaremos sobre a tecnologia WebRTC, que visa organizar o intercâmbio direto de dados entre aplicativos de navegador em tempo real.

Revisão

O que é o WebRTC? Para começar, vale dizer que a abreviação RTC significa Comunicação em tempo real (comunicação em tempo real). Isso por si só fornece muitas informações sobre essa tecnologia.

O WebRTC ocupa um nicho muito importante entre os mecanismos da plataforma web. Anteriormente, as tecnologias P2P (redes ponto a ponto, ponto a ponto, redes ponto a ponto, ponto a ponto) usadas por aplicativos como bate-papos na área de trabalho davam a eles oportunidades que os projetos da Web não tinham. O WebRTC faz a diferença para as tecnologias da web.

O WebRTC, se observarmos essa tecnologia em termos gerais, permitirá que aplicativos da Web criem conexões P2P, que discutiremos abaixo. Além disso, abordaremos os seguintes tópicos aqui para mostrar a imagem completa da estrutura interna do WebRTC:

• Comunicações P2P.
• Firewalls e tecnologia NAT Traversal.
• Sinalização, sessões e protocolos.
• API WebRTC

Comunicações P2P

Suponha que dois usuários tenham lançado, cada um em seu próprio navegador, um aplicativo que permita organizar um bate-papo por vídeo usando o WebRTC. Eles querem estabelecer uma conexão P2P. Após a decisão, precisamos de um mecanismo que permita que os navegadores dos usuários se encontrem e estabeleçam a comunicação levando em consideração os mecanismos de proteção de informações disponíveis nos sistemas. Após estabelecer uma conexão, os usuários poderão trocar informações multimídia em tempo real.

Uma das principais dificuldades associadas às conexões P2P do navegador é que os navegadores precisam primeiro descobrir um ao outro e, em seguida, estabelecer uma conexão de rede baseada em soquetes para fornecer transferência de dados bidirecional. Sugerimos discutir as dificuldades associadas à instalação dessas conexões.

Quando um aplicativo da web precisa de alguns dados ou recursos, ele os baixa do servidor e é isso. O endereço do servidor é conhecido pelo aplicativo. Se estamos falando, por exemplo, sobre a criação de um bate-papo P2P, cuja operação se baseia na conexão direta de navegadores, os endereços desses navegadores não são conhecidos antecipadamente. Como resultado, para estabelecer uma conexão P2P, você terá que lidar com alguns problemas.

Firewalls e Protocolo NAT Transversal

Computadores comuns, como regra, não têm endereços IP externos estáticos atribuídos a eles. A razão para isso é que esses computadores geralmente estão localizados atrás de firewalls e dispositivos NAT.

O NAT é um mecanismo que converte endereços IP locais internos localizados atrás de um firewall em endereços IP globais externos. A tecnologia NAT é usada, primeiramente, por razões de segurança e, em segundo lugar, devido às restrições impostas pelo IPv4 ao número de endereços IP globais disponíveis. É por isso que aplicativos da Web que usam o WebRTC não devem confiar no fato de o dispositivo atual ter um endereço IP estático global.

Vamos ver como o NAT funciona. Se você estiver em uma rede corporativa e conectado ao Wi-Fi, seu computador receberá um endereço IP que existe apenas atrás do seu dispositivo NAT. Suponha que este seja o endereço IP 172.0.23.4. Para o mundo exterior, no entanto, seu endereço IP pode parecer 164.53.27.98. O mundo externo, como resultado, vê suas solicitações como vindas do endereço 164.53.27.98, mas graças ao NAT, as respostas às solicitações feitas pelo seu computador a serviços externos serão enviadas para o seu endereço interno 172.0.23.4. Isso acontece usando tabelas de tradução. Observe que, além do endereço IP, também é necessário um número de porta para a rede.

Como o NAT está envolvido no processo de interação do sistema com o mundo exterior, o navegador, para estabelecer uma conexão WebRTC, precisa saber o endereço IP do computador no qual o navegador que você deseja se comunicar está executando.

É aqui que os servidores STUN (Utilitários de transferência de sessão para NAT) e TURN (Traversal usando relés em torno de NAT) entram em cena. Para garantir a operação da tecnologia WebRTC, uma solicitação é feita primeiro ao servidor STUN, a fim de descobrir seu endereço IP externo. Na verdade, estamos falando de uma solicitação feita a um servidor remoto para descobrir a partir de qual endereço IP o servidor recebe essa solicitação. Após receber uma solicitação semelhante, o servidor remoto enviará uma resposta contendo o endereço IP visível para ele.

Com base na suposição de que esse esquema está operacional e que você recebeu informações sobre seu endereço IP e porta externos, poderá informar outros participantes do sistema (nós os chamaremos de colegas) sobre como entrar em contato diretamente com você. Esses pares também podem fazer o mesmo usando servidores STUN ou TURN e podem informar quais endereços são atribuídos a eles.

Sinalização, sessões e protocolos

O processo de descoberta de informações de rede, descrito acima, é parte de um grande sistema de sinalização, que, no caso do WebRTC, é baseado no padrão JSEP (JavaScript Session Establishment Protocol). A sinalização inclui descoberta de recursos de rede, criação e gerenciamento de sessões, segurança de comunicação, coordenação de parâmetros de mídia, tratamento de erros.

Para que a conexão funcione, os pares devem concordar com os formatos de dados que eles trocarão e coletar informações sobre os endereços de rede do computador no qual o aplicativo está sendo executado. O mecanismo de sinalização para compartilhar essas informações críticas não faz parte da API WebRTC.

A sinalização não é definida pelo padrão WebRTC e não é implementada em sua API para fornecer flexibilidade nas tecnologias e protocolos utilizados. A sinalização e os servidores que a suportam são de responsabilidade do desenvolvedor do aplicativo WebRTC.

Com base na suposição de que seu aplicativo WebRTC em execução no navegador é capaz de determinar o endereço IP externo do navegador usando STUN, conforme descrito acima, a próxima etapa é discutir os parâmetros da sessão e estabelecer uma conexão com outro navegador.

A discussão inicial dos parâmetros da sessão e o estabelecimento de uma conexão são feitos usando um protocolo de sinalização / comunicação especializado em comunicações multimídia. Esse protocolo, além disso, é responsável por cumprir as regras sob as quais a sessão é gerenciada e finalizada.

Um desses protocolos é chamado SIP (Session Initiation Protocol). Observe que, devido à flexibilidade do subsistema de sinalização WebRTC, o SIP não é o único protocolo de sinalização que pode ser usado. O protocolo de sinalização selecionado, além disso, deve funcionar com um protocolo de camada de aplicativo chamado SDP (Session Description Protocol), usado ao usar o WebRTC. Todos os metadados relacionados aos dados multimídia são transmitidos usando o protocolo SDP.

Qualquer par (isto é, um aplicativo usando o WebRTC) que tenta entrar em contato com outro par gera um conjunto de rotas candidatas para o protocolo ICE (Interactive Connectivity Establishment). Os candidatos representam uma combinação de endereço IP, porta e protocolo de transporte que podem ser usados. Observe que um computador pode ter muitas interfaces de rede (com fio, sem fio etc.), para que possam ser atribuídos vários endereços IP, um para cada interface.

Aqui está um diagrama com o MDN que ilustra o processo acima de troca de dados.

O processo de troca de dados necessário para estabelecer uma conexão P2P

Estabelecer uma conexão

Cada par primeiro descobre seu endereço IP externo como descrito acima. Em seguida, são criados dinamicamente "canais" de dados de sinalização, que servem para detectar pares e dar suporte à troca de dados entre eles, para discutir os parâmetros da sessão e sua instalação.

Esses "canais" são desconhecidos e inacessíveis ao mundo exterior; um identificador exclusivo é necessário para acessá-los.

Observe que, devido à flexibilidade do WebRTC e ao fato de o processo de sinalização não ser definido pelo padrão, o conceito de "canais" e a ordem de seu uso podem variar um pouco, dependendo das tecnologias utilizadas. De fato, alguns protocolos não requerem um mecanismo de "canal" para organizar a troca de dados. Para os fins deste material, assumimos que os "canais" na implementação do sistema são utilizados.

Se dois ou mais pares estiverem conectados ao mesmo "canal", eles terão a oportunidade de trocar dados e discutir informações da sessão. Esse processo é semelhante a um modelo de editor-assinante . Em geral, o ponto que inicia a conexão envia uma "oferta" usando um protocolo de sinalização como SIP ou SDP. O iniciador espera receber uma "resposta" do destinatário da proposta, que está conectado ao "canal" considerado.

Depois que a resposta é recebida, ocorre o processo de determinar e discutir os melhores candidatos a ICE coletados por cada festa. Após a seleção dos candidatos ideais para ICE, são acordados os parâmetros de dados que serão trocados entre pares e o mecanismo de roteamento de rede (endereço IP e porta).

Em seguida, uma sessão de soquete de rede ativa é estabelecida entre pares. Além disso, cada par cria fluxos de dados locais e pontos finais de canais de dados, e a transmissão bidirecional de dados multimídia começa a usar a tecnologia aplicada.

Se o processo de negociação para escolher o melhor candidato a ICE não for bem-sucedido, o que às vezes acontece devido à falha de firewalls e sistemas NAT, é usada uma opção de backup, que consiste em usar, como retransmissão, um servidor TURN. Esse processo envolve um servidor que atua como intermediário que retransmite os dados trocados entre pares. Observe que esse esquema não é uma conexão P2P real na qual os pares transmitem dados diretamente entre si.

Ao usar um fallback usando TURN para troca de dados, cada ponto não precisa mais saber como se comunicar com os outros e como transferir dados para ele. Em vez disso, os colegas precisam saber qual servidor TURN externo precisa enviar dados multimídia em tempo real e de qual servidor eles precisam receber durante a sessão de comunicação.

É importante entender que agora era uma maneira alternativa de organizar as comunicações. Os servidores TURN devem ser muito confiáveis, ter uma grande largura de banda e poder de computação sério, dar suporte ao trabalho com quantidades potencialmente grandes de dados. Portanto, o uso de um servidor TURN obviamente leva a custos adicionais e a um aumento na complexidade do sistema.

API WebRTC

Existem três categorias principais de APIs que existem no WebRTC:

• A API Media Capture and Streams é responsável pela captura e streaming de mídia. Essa API permite conectar-se a dispositivos de entrada, como microfones e webcams, e receber fluxos de mídia deles.
• API RTCPeerConnection Usando a API desta categoria, é possível, a partir de um terminal do WebRTC, enviar, em tempo real, o fluxo capturado de dados de áudio ou vídeo via Internet para outro terminal do WebRTC. Usando esta API, você pode criar conexões entre a máquina local e o ponto remoto. Ele fornece métodos para conectar-se a um ponto remoto, gerenciar a conexão e monitorar seu status. Seus mecanismos são usados ​​para fechar conexões desnecessárias.
• API RTCDataChannel Os mecanismos representados por esta API permitem a transferência de dados arbitrários. Cada canal de dados está associado a uma interface RTCPeerConnection.

Vamos falar sobre essas APIs.

Captura de mídia e fluxos de API

A API Media Capture and Streams, geralmente chamada de API Media Stream ou Stream API, é uma API que suporta o trabalho com fluxos de dados de áudio e vídeo, métodos para trabalhar com eles. Usando esta API, você pode definir restrições relacionadas aos tipos de dados; aqui existem retornos de chamada para a conclusão bem-sucedida e malsucedida de operações que são usadas ao usar mecanismos assíncronos para trabalhar com dados e eventos gerados durante a operação.

O método getUserMedia() da API getUserMedia() solicita ao usuário permissão para trabalhar com dispositivos de entrada que produzem fluxos MediaStream com faixas de áudio ou vídeo contendo os tipos de mídia solicitados. Esse fluxo pode incluir, por exemplo, uma faixa de vídeo (sua fonte é uma fonte de hardware ou de vídeo virtual, como uma câmera, gravador de vídeo, serviço de compartilhamento de tela etc.), uma faixa de áudio (fontes de áudio físicas ou virtuais podem formar a mesma, como um microfone, um conversor de analógico para digital etc.) e possivelmente outros tipos de faixas.

Este método retorna a promessa que resolve para o objeto MediaStream . Se o usuário rejeitar a solicitação de permissão ou a mídia correspondente não estiver disponível, a promessa será resolvida, respectivamente, com um NotFoundError PermissionDeniedError ou NotFoundError .

Você pode acessar o singleton MediaDevice através do objeto navigator :

 navigator.mediaDevices.getUserMedia(constraints) .then(function(stream) { /*   */ }) .catch(function(err) { /*   */ }); 

Observe que, quando você chama o método getUserMedia() , precisa passar para ele um objeto de constraints que informa à API que tipo de fluxo ele deve retornar. Aqui você pode configurar várias coisas, incluindo a câmera que deseja usar (frontal ou traseira), taxa de quadros, resolução e assim por diante.

A partir da versão 25, os navegadores baseados no Chromium permitem transferir áudio de getUserMedia() elementos de áudio ou vídeo (no entanto, observe que os elementos de mídia serão desativados por padrão).

O método getUserMedia() também pode ser usado como um nó de entrada para a API de áudio da Web :

 function gotStream(stream) {   window.AudioContext = window.AudioContext || window.webkitAudioContext;   var audioContext = new AudioContext();   //  AudioNode     var mediaStreamSource = audioContext.createMediaStreamSource(stream);   //       ,    ,   //       !   mediaStreamSource.connect(audioContext.destination); } navigator.getUserMedia({audio:true}, gotStream); 

Limitações relacionadas à proteção de informações pessoais

A captura não autorizada de dados de um microfone ou câmera é uma séria interferência na vida pessoal do usuário. Portanto, o uso de getUserMedia() prevê a implementação de requisitos muito específicos para notificar o usuário sobre o que está acontecendo e para gerenciar permissões. O método getUserMedia() sempre deve obter permissão do usuário antes de abrir qualquer dispositivo de entrada que colete mídia, como uma webcam ou microfone. Os navegadores podem oferecer a opção de uma configuração única de permissão para um domínio, mas são solicitados a solicitar permissão pelo menos na primeira vez em que acessam dispositivos de mídia, e o usuário deve conceder explicitamente essa permissão.

Além disso, as regras relacionadas à notificação ao usuário sobre o que está acontecendo são importantes aqui. É necessário que os navegadores exibam um indicador que indique o uso de um microfone ou câmera. A exibição desse indicador não depende da presença no sistema de indicadores de hardware indicando a operação de tais dispositivos. Além disso, os navegadores devem mostrar um indicador de que a permissão para usar o dispositivo de entrada foi concedida, mesmo que o dispositivo não seja usado em algum momento para registrar dados relevantes.

Interface RTCPeerConnection

A interface RTCPeerConnection é uma conexão WebRTC entre o computador local e o ponto remoto. Ele fornece métodos para conectar-se a um sistema remoto, para suportar a conexão e monitorar seu status e para fechar a conexão depois que ela não é mais necessária.

Aqui está um diagrama da arquitetura WebRTC demonstrando o papel do RTCPeerConnection.


Função RTCPeerConnection

Da perspectiva do JavaScript, o principal conhecimento que pode ser extraído da análise deste diagrama é que o RTCPeerConnection abstrai o desenvolvedor da Web de mecanismos complexos localizados em níveis mais profundos do sistema. Os codecs e protocolos usados ​​pelo WebRTC fazem um ótimo trabalho para permitir a troca de dados em tempo real, mesmo ao usar redes não confiáveis. Aqui estão algumas das tarefas resolvidas por esses mecanismos:

• Perda de pacotes de máscara.
• Cancelamento de eco.
• Adaptação de largura de banda.
• Buffer dinâmico para eliminar a instabilidade.
• Controle de volume automático.
• Redução e supressão de ruído.
• "Limpando" a imagem.

API RTCDataChannel

Assim como os dados de áudio e vídeo, o WebRTC suporta a transmissão em tempo real de outros tipos de dados. A API RTCDataChannel permite organizar uma troca P2P de dados arbitrários.

Existem muitos cenários para usar esta API. Aqui estão alguns deles:

• Jogos
• Bate-papo em tempo real.
• Transferência de arquivos.
• Organização de redes descentralizadas.

Essa API visa o uso mais eficiente dos recursos da API RTCPeerConnection e permite organizar um sistema de troca de dados poderoso e flexível em um ambiente P2P. Entre suas características estão as seguintes:

• Trabalho eficaz com sessões usando RTCPeerConnection.
• Suporte para vários canais de comunicação usados ​​simultaneamente com priorização.
• Suporte para métodos confiáveis ​​e não confiáveis ​​de entrega de mensagens.
• Gerenciamento de segurança interno (DTLS) e congestionamento.

A sintaxe aqui é semelhante à usada ao trabalhar com a tecnologia WebSocket. O método send() e o evento da message são aplicados aqui:

 var peerConnection = new webkitRTCPeerConnection(servers,   {optional: [{RtpDataChannels: true}]} ); peerConnection.ondatachannel = function(event) {   receiveChannel = event.channel;   receiveChannel.onmessage = function(event){       document.querySelector("#receiver").innerHTML = event.data;   }; }; sendChannel = peerConnection.createDataChannel("sendDataChannel", {reliable: false}); document.querySelector("button#send").onclick = function (){   var data = document.querySelector("textarea#send").value;   sendChannel.send(data); } 

WebRTC no mundo real

No mundo real, a comunicação WebRTC requer servidores. Os sistemas não são muito complicados; graças a eles, a seguinte sequência de ações é implementada:

• Os usuários descobrem um ao outro e trocam informações um sobre o outro, por exemplo, nomes.
• Os aplicativos clientes WebRTC (pares) trocam informações de rede.
• Os colegas trocam informações sobre dados de mídia, como formato e resolução de vídeo.
• Os aplicativos cliente WebRTC estabelecem uma conexão ignorando gateways e firewalls NAT .

Em outras palavras, o WebRTC precisa de quatro tipos de funções do servidor:

• Meios para descobrir usuários e organizar sua interação.
• Sinalização.
• Ignore o NAT e os firewalls.
• Servidores de retransmissão usados ​​quando uma conexão P2P não pode ser estabelecida.

O protocolo STUN e sua extensão TURN são usados ​​pelo ICE para permitir que o RTCPeerConnection trabalhe com mecanismos de desvio NAT e para lidar com outras dificuldades encontradas ao transmitir dados por uma rede.

Como já mencionado, o ICE é um protocolo para conectar pares, como dois clientes de bate-papo por vídeo. No início da sessão de comunicação, o ICE tenta conectar os pares diretamente, com o menor atraso possível, via UDP. Durante esse processo, os servidores STUN têm uma única tarefa: permitir que o parceiro atrás do NAT aprenda seu endereço e porta públicos. Dê uma olhada nesta lista de servidores STUN disponíveis (o Google também possui esses servidores).


Servidores STUN

Detecção de Candidatos ICE

Se a conexão UDP não puder ser estabelecida, o ICE tentará estabelecer uma conexão TCP: primeiro por HTTP e depois por HTTPS. Se uma conexão direta não puder ser estabelecida - em particular, devido à incapacidade de ignorar NATs e firewalls corporativos, o ICE usará um intermediário (relé) na forma de um servidor TURN. Em outras palavras, o ICE primeiro tentará usar o STUN com o UDP para conexão direta de pares e, se isso não funcionar, ele usará uma opção de fallback com um locatário na forma de um servidor TURN. O termo "pesquisa de candidatos" refere-se ao processo de pesquisa de interfaces e portas de rede.


Localizando interfaces e portas de rede adequadas

Segurança

Aplicativos de comunicação em tempo real ou plug-ins relacionados podem levar a problemas de segurança. Em particular, estamos falando sobre o seguinte:

• Dados de mídia não criptografados ou outros dados podem ser interceptados ao longo do caminho entre navegadores ou entre um navegador e um servidor.
• Um aplicativo pode, sem o conhecimento do usuário, gravar e transmitir dados de vídeo e áudio para um invasor.
• Juntamente com um plug-in ou aplicativo com aparência inofensiva, um vírus ou outro software malicioso pode chegar ao computador do usuário.

O WebRTC possui vários mecanismos projetados para lidar com essas ameaças:

• As implementações do WebRTC usam protocolos seguros como DTLS e SRTP .
• Para todos os componentes dos sistemas WebRTC, o uso de criptografia é obrigatório. Isso também se aplica aos mecanismos de sinalização.
• WebRTC não é um plugin. Os componentes WebRTC são executados na caixa de proteção do navegador e não em um processo separado. Os componentes são atualizados quando o navegador é atualizado.
• O acesso à câmera e ao microfone deve ser concedido explicitamente. E, quando uma câmera ou microfone é usado, esse fato é exibido claramente na interface do usuário do navegador.

Sumário

O WebRTC é uma tecnologia muito interessante e poderosa para projetos que usam a transferência de qualquer dado entre navegadores em tempo real. O autor do material diz que sua empresa, SessionStack , utiliza mecanismos tradicionais para troca de dados com usuários, envolvendo o uso de servidores. No entanto, se eles usassem o WebRTC para resolver os problemas correspondentes, isso permitiria organizar a troca de dados diretamente entre navegadores, o que levaria a uma diminuição no atraso na transferência de dados e a reduzir a carga na infraestrutura da empresa.

Caros leitores! Você usa a tecnologia WebRTC em seus projetos?