O que é melhor usar ao desenvolver software - tecnologias nativas ou da web? Holivar sobre esse assunto não terminará em breve, mas poucos argumentarão que é útil duplicar funções nativas para uso em navegadores ou no WebView. E se os aplicativos de chamadas existiam exclusivamente separadamente do navegador, agora são fáceis de implementar na Web. O desenvolvedor Grigory Kuznetsov explicou como usar a tecnologia WebRTC para conexões P2P.
- Como todos sabem, nos últimos anos, existem muitos aplicativos baseados na troca direta de dados entre dois navegadores, ou seja, P2P. Estes são todos os tipos de mensagens instantâneas, bate-papos, discadores, videoconferências. Também podem ser aplicativos que realizam algum tipo de computação distribuída. Os limites da fantasia não são limitados de forma alguma.
Como fazemos essa tecnologia? Imagine que queremos fazer uma ligação de um navegador para outro. E imagine quais etapas precisamos para alcançar esse objetivo. Antes de tudo, parece que a ligação é nossa imagem, nossa voz, imagem e precisamos ter acesso aos dispositivos de mídia conectados ao computador: à câmera e ao microfone. Depois de obter acesso, você precisa de dois navegadores, dois clientes, para se encontrarem. É necessário ajudá-los de alguma forma a se conectar, alcançar, transmitir metainformação.
Quando você chega, precisa iniciar a transferência de dados no modo P2P, ou seja, para garantir a transmissão dos fluxos de mídia. Temos todos os itens necessários, estamos prontos para implementar nossa nova moto legal. Mas isso é uma piada, somos engenheiros e entendemos que é caro, injustificado e arriscado. Portanto, como engenheiros clássicos, vamos primeiro pensar em quais soluções já existem.
Primeiro de tudo, a antiga tecnologia Adobe Flash moribunda. Ela está realmente morrendo e a Adobe deixará de apoiá-lo até 2020. A tecnologia realmente permitirá que você acesse seus dispositivos de mídia; dentro dele, você pode implementar toda a mecânica necessária para ajudar os navegadores a se conectarem, para que eles comecem a transmitir informações P2P, mas você inventará sua bicicleta novamente, porque não existe um padrão único, uma abordagem única para implementar esse método. transferência de dados.
Você pode escrever um plugin para o navegador. É assim que o Skype funciona para os navegadores que não suportam tecnologias mais modernas. Você precisará implementar sua bicicleta, porque não existe um padrão único e isso também é ruim para os usuários, pois o usuário precisará instalar algum tipo de plug-in no navegador e executar ações adicionais. Os usuários não gostam disso e não querem fazê-lo.
E existe a tecnologia WebRTC - o Google Hangouts, o Facebook Messenger trabalham com ele. O Voximplant o utiliza para que você possa fazer suas ligações. Vamos nos aprofundar nisso com mais detalhes. Esta é uma nova tecnologia em desenvolvimento, apareceu em 2011 e continua a se desenvolver. O que ela permite fazer? Tenha acesso à câmera e ao microfone. Estabeleça uma conexão P2P entre dois computadores, dois navegadores. Naturalmente, permite transferir fluxos de mídia em tempo real. Além disso, permite transferir informações, ou seja, qualquer data binária, você também pode transmitir P2P, você pode criar seu próprio sistema de computação distribuído.
Um ponto importante: o WebRTC não fornece aos navegadores uma maneira de se encontrar. Podemos gerar todas as meta-informações necessárias sobre nossos entes queridos, mas como um navegador pode aprender sobre a existência de outro? Como conectá-los? Considere um exemplo.
Existem dois clientes. O primeiro cliente deseja fazer uma chamada para o segundo cliente. O WebRTC fornece todas as informações necessárias para você se identificar. Mas permanece a questão de como encontrar outro navegador, como enviar essa meta-informação, como inicializar a chamada. Isso é deixado para os desenvolvedores, podemos usar absolutamente qualquer método, pegar essas meta-informações, imprimi-las em um pedaço de papel, enviá-las por correio, outro irá usá-las e tudo funcionará.
E podemos criar algum mecanismo de sinalização. Nesse caso, este é um mecanismo de terceiros que nos permitirá, se conhecermos nossos clientes, garantir a transferência entre eles de algumas informações necessárias para estabelecer uma conexão.
Considere um exemplo usando um servidor de sinal. Existe um servidor de sinal que mantém uma conexão constante com nossos clientes, por exemplo, via soquetes da web ou usando HTTP. O primeiro cliente gera meta-informações e as envia ao servidor de sinal usando soquetes da web ou HTTP. Ele também envia parte da informação com a qual deseja se conectar, por exemplo, um apelido ou outra informação.
O servidor de sinal usando esse identificador determina qual cliente precisa redirecionar nossa meta-informação e a encaminha. O segundo cliente pega, usa, instala a si próprio, forma uma resposta e, usando o mecanismo de sinalização, envia para o servidor de sinal, que por sua vez o retransmite para o primeiro cliente. Portanto, atualmente, ambos os clientes têm toda a data e meta-informações necessárias para estabelecer uma conexão P2P. Feito.
Vamos examinar mais de perto exatamente o que os clientes estão trocando, eles estão trocando um datagrama SDP, Session Description Protocol.
Este é essencialmente um arquivo de texto que contém todas as informações necessárias para estabelecer uma conexão. Há informações sobre o endereço IP, sobre as portas que são usadas, sobre que tipo de informação está sendo perseguida entre os clientes, o que é - áudio, vídeo, quais codecs são usados. Tudo o que precisamos está lá.
Preste atenção na segunda linha. Ele mostra o endereço IP do cliente, 192.168.0.15. Obviamente, esse é o endereço IP de um computador que está em alguma rede local. Se tivermos dois computadores, cada um deles na rede local, e cada um souber seu endereço IP nessa rede, eles desejam ligar. Eles serão capazes de fazer isso com esse datagrama? Obviamente não, eles não conhecem os endereços IP externos. Como ser
Vamos nos afastar e ver como o NAT funciona. Na Internet, muitos computadores estão ocultos atrás de roteadores. Existem redes locais nas quais os computadores sabem seus endereços, há um roteador que possui um endereço IP externo e todos esses computadores se destacam com o endereço IP desse roteador. Quando um pacote de um computador na rede local vai para o roteador, o roteador verifica para onde deve ser encaminhado. Se em outra rede local, ele simplesmente a retransmitir, e se você precisar enviá-la para a Internet, será compilada uma tabela de roteamento.
Nós preenchemos o endereço IP interno do computador que deseja encaminhar o pacote, sua porta, definimos o endereço IP externo, o endereço IP do roteador e também fazemos uma alteração de porta. Para que serve? Imagine que dois computadores estão acessando o mesmo recurso e precisamos rotear corretamente os pacotes de resposta. Nós os identificaremos por porta, a porta será exclusiva para cada um dos computadores, enquanto o endereço IP externo corresponderá.
Como viver se houver NAT, se os computadores permanecerem sob o mesmo endereço IP, mas por dentro eles se conhecerão pelo outro?
A estrutura do ICE para o estabelecimento de conectividade com a Internet vem em socorro. Ele descreve maneiras de ignorar o NAT, como estabelecer uma conexão se tivermos o NAT.
Essa estrutura usa o chamado atributo do servidor STUN.
Este é um servidor tão especial, referindo-se ao qual, você pode descobrir seu endereço IP externo. Assim, no processo de estabelecer uma conexão P2P, cada cliente deve fazer uma solicitação a este servidor STUN para descobrir seu endereço IP e gerar informações adicionais, IceCandidate e trocar IceCandidate com o mecanismo de sinalização. Em seguida, os clientes se conhecerão com os endereços IP corretos e poderão estabelecer uma conexão P2P.
No entanto, existem casos mais complicados. Por exemplo, quando o computador está oculto por trás do NAT duplo. Nesse caso, a estrutura do ICE requer o uso de um servidor TURN.
Este é um servidor tão especial que transforma uma conexão cliente-cliente, P2P, em uma conexão cliente-servidor-cliente, ou seja, atua como um relé. A boa notícia para os desenvolvedores é que, independentemente de qual dos três cenários a conexão foi feita, se estamos na rede local, se precisamos recorrer a um servidor STUN ou TURN, a tecnologia da API será idêntica para nós. Simplesmente indicamos no início a configuração dos servidores ICE e TURN, indicamos como acessá-los e, depois disso, a tecnologia faz tudo por nós sob o capô.
Um breve resumo. Para estabelecer uma conexão, você precisa selecionar e implementar algum tipo de mecanismo de sinalização, um certo intermediário que nos ajudará a enviar meta-informações. O WebRTC nos dará toda a meta necessária para isso.
Temos que lutar com o NAT, este é o nosso principal inimigo nesta fase. Mas, para contornar isso, usamos o servidor STUN para descobrir nosso endereço IP externo e usamos o servidor TURN como retransmissão.
O que exatamente estamos transmitindo? Sobre fluxos de mídia.
Fluxos de mídia são canais que contêm faixas dentro de si. As faixas no fluxo de mídia são sincronizadas. Áudio e vídeo não divergem, eles vêm com um único tempo. Você pode criar qualquer número de faixas dentro do fluxo de mídia; as faixas podem ser controladas separadamente; por exemplo, você pode silenciar o áudio, deixando apenas uma imagem. Você também pode transferir qualquer número de fluxos de mídia, o que permite, por exemplo, implementar uma conferência.
Como acessar a mídia de um navegador? Vamos falar sobre a API.
Existe um método getUserMedia que aceita um conjunto de constantes como entrada. Este é um objeto especial em que você indica quais dispositivos deseja acessar, qual câmera e qual microfone. Você especifica as características que deseja ter, qual resolução e também há dois argumentos - successCallback e errorCallback, que são chamados em caso de sucesso ou falha. Implementações de tecnologia mais modernas usam promessas.
Há também um método conveniente enumerateDevices que retorna uma lista de todos os dispositivos de mídia conectados ao seu computador, o que lhe dá a oportunidade de mostrá-los ao usuário, desenhe algum tipo de seletor para que o usuário escolha qual câmera específica deseja usar.
O objeto central na API é RTCPeerConnection. Quando fazemos a conexão, usamos a classe RTCPeerConnection, que retorna o objeto peerConnection. Como configuração, especificamos um conjunto de servidores ICE, ou seja, STUN e TURN, aos quais acessaremos durante o processo de instalação. E há um importante evento onicecandidate que dispara toda vez que precisamos da ajuda do nosso mecanismo de sinalização. Ou seja, a tecnologia WebRTC fez uma solicitação, por exemplo, para um servidor STUN, reconhecemos nosso endereço IP externo, um novo ICECandidate apareceu e precisamos enviá-lo usando um mecanismo de terceiros, o evento foi mais estressante.
Quando estabelecemos uma conexão e queremos inicializar a chamada, usamos o método createOffer () para formar o SDP inicial, oferecer SDP, a mesma meta informação que precisa ser enviada ao parceiro.
Para defini-lo como PeerConnection, usamos o método setLocalDescription (). O interlocutor recebe essas informações pelo mecanismo de sinalização, define-as usando o método setRemoteDescription () e gera uma resposta usando o método createAnswer (), que também é enviado ao primeiro cliente usando o mecanismo de sinalização.
Quando obtivemos acesso à mídia, obtivemos o fluxo de mídia, transferimos para nossa conexão P2P usando o método addStream, e nosso interlocutor descobre isso, ele tem o evento onaddstream aparado. Ele receberá nosso fluxo e poderá exibi-lo.
Você também pode trabalhar com fluxos de dados. É muito semelhante à formação de um peerConnection regular, basta especificar RtpDataChannels: true e chamar o método createDataChannel (). Não vou me debruçar sobre isso em detalhes, porque esse trabalho é muito semelhante ao trabalho com soquetes da web.
Algumas palavras sobre segurança. O WebRTC funciona apenas em HTTPS, seu site deve ser assinado com um certificado. Os fluxos de mídia também são criptografados, usando DTLS. A tecnologia não requer a instalação de nada extra, sem plug-ins, e isso é bom. E não funcionará para criar um aplicativo spyware, o site não escutará ou espionará o usuário, ele mostrará ao usuário um prompt especial, solicitará acesso a ele e o receberá apenas se o usuário permitir acesso a dispositivos de áudio e mídia.
Quanto ao suporte ao navegador - o IE permanece e permanece vermelho. No final do ano passado, o suporte ao Safari foi adicionado, ou seja, todos os navegadores modernos já podem trabalhar com essa tecnologia e podemos usá-la com segurança.
Quero compartilhar um conjunto de todos os tipos de utilitários que o ajudarão se você quiser trabalhar com o WebRTC. Este é principalmente um
adaptador . As tecnologias estão em constante evolução e há uma diferença nas APIs do navegador. A biblioteca de adaptadores elimina essa diferença e facilita o trabalho. Uma biblioteca conveniente para trabalhar com fluxos de dados é o
Peerjs . Você também pode examinar as implementações de código aberto dos
servidores STUN e
TURN . Um grande conjunto de tutoriais, exemplos e artigos está na página
awesome-webrtc , eu recomendo.
A última ferramenta útil para depuração é webrtc-internals. Durante o desenvolvimento, você pode digitar um comando especial na barra de endereços - por exemplo, no navegador Chrome, é Chrome: // webrtc-internals. Você verá uma página com todas as informações sobre sua conexão atual com o WebRTC. Haverá sequências de chamadas nos métodos e todos os datagramas trocados entre navegadores e gráficos que de alguma forma caracterizam sua conexão. Em geral, haverá todas as informações necessárias durante a depuração e o desenvolvimento. Obrigado pela atenção.