Após o prenúncio das partes anteriores, você deve ter uma compreensão geral do processo de interação de áudio e vídeo P2P. Você pode sentir que o processo é complicado e envolve até mesmo a camada inferior da rede. Mas não se preocupe, o WebRTC fez muito por nós, facilitando o desenvolvimento de áudio e vídeo. Então, o que é exatamente o WebRTC?
WebRTC (Web Real-Time Communications) é uma tecnologia de comunicação em tempo real que permite que aplicativos de rede ou sites estabeleçam uma conexão peer-to-peer (Peer-to-Peer) entre navegadores sem intermediários para obter streaming de vídeo e/ou a transmissão de fluxos de áudio ou outros dados arbitrários. Esses padrões incluídos no WebRTC permitem que os usuários criem compartilhamento de dados e teleconferência ponto a ponto (ponto a ponto) sem instalar nenhum plug-in ou software de terceiros.
WebRTC não é a tecnologia original do Google. Em 2010, o Google adquiriu a Global IP Solutions, desenvolvedora de software VoIP, por aproximadamente US$ 68,2 milhões e, assim, adquiriu a tecnologia WebRTC de propriedade da empresa. Hoje em dia, as tecnologias de serviços de comunicação de áudio e vídeo da Internet são geralmente tecnologias proprietárias, como o Skype , que precisam instalar plug-ins ou clientes de desktop para realizar funções de comunicação. O Google espera que os desenvolvedores da Web possam criar aplicativos de bate-papo por vídeo ou voz diretamente no navegador.A Global IP Solutions já produziu clientes móveis baseados em WebRTC para Android, Windows Mobile e iPhone. O Google tornou o WebRTC de código aberto desta vez, esperando que os fabricantes de navegadores possam incorporar a tecnologia diretamente no navegador, de modo a facilitar os desenvolvedores da Web.
Suplemento de conceito
Além dos conceitos mencionados anteriormente, deixe-me adicionar alguns conceitos relacionados
recurso de link interativo
Estabelecimento de Conectividade Interativa (ICE): Uma estrutura de protocolo que permite que seu navegador estabeleça uma conexão com um navegador de mesmo nível. Em uma rede real, há muitos motivos pelos quais uma simples conexão direta de A para B não pode ser concluída como desejado. Isso requer ignorar o firewall que impede que a conexão seja estabelecida, atribuindo ao seu dispositivo um endereço visível exclusivo (geralmente a maioria dos nossos dispositivos não possui um endereço de rede público fixo) e, se o roteador não permitir que o host se conecte diretamente, você tem que passar um O servidor encaminha os dados. Você deve ter descoberto que este ICE é um resumo de nossos métodos de conexão anteriores, como STUN e TURN. Formalmente, devido à estrutura do ICE, nosso trabalho de desenvolvimento é bastante simplificado e o ICE selecionará automaticamente o método de conexão de acordo com a prioridade;
servidor de sinalização
Signal server (servidor de sinal): troca os endereços de comunicação entre os pares, após obterem seus próprios endereços de comunicação via STUN, cadastram-se no servidor de sinalização para troca de endereços de comunicação entre os dispositivos, completando assim a conexão P2P;
Protocolo de Descrição da Sessão
Protocolo de descrição de sessão (Session Description Protocol, SDP): Um protocolo que descreve o conteúdo de uma conexão multimídia, como resolução, formato, codificação, algoritmo de criptografia, etc. Antes de iniciar uma conexão P2P, é necessário negociar um protocolo de sessão suportado por ambas as partes. Quando um usuário inicia uma chamada WebRTC para outro usuário, uma descrição específica chamada oferta é criada. A descrição inclui todas as informações sobre a configuração da chamada proposta pelo chamador. O destinatário então responde com uma resposta, que é a descrição do final da chamada. Dessa forma, dois dispositivos compartilham entre si as informações necessárias para trocar dados de mídia; um SDP descreve o conteúdo assim ("="Não pode haver espaços em ambos os lados)
v=0
o=- 212360934117607227 2 IN IP4 127.0.0.1
s=-
t=0 0
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
a=rtpmap:111 opus/48000/2
......
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 121 127 120 125 107 108 109 35 36 124 119 123 118 114 115 116
a=rtpmap:96 VP8/90000
......
Uma descrição SDP consiste em uma sessão e várias descrições de mídia. A descrição da sessão vai de v= até a primeira descrição de mídia (1 a 4 linhas) e a descrição de mídia vai de m= até a próxima descrição de mídia (5 a 6 linhas— - áudio, linhas 8-9 - vídeo).
descrição no nível da sessão
Existem muitos campos de descrição da sessão, os mais importantes são 4 campos
- v=: número da versão UDP, excluindo a versão secundária* o=: uma descrição do iniciador da sessão > o=*
<username>: nome do usuário, quando você não se importa com o nome do usuário, pode usar "-" em seu lugar; *<session id>: string de número, deve ser único em toda a sessão, e é recomendável usar timestamp NTP; *<version>: número da versão, o valor da versão será incrementado toda vez que os dados da sessão forem modificados; *<network type>: tipo de rede, geralmente "IN", que significa "internet"; *<address type>: tipo de endereço, geralmente IP4; *<address>: endereço IP - Nome da Sessão: Indica uma sessão * t=: descrição do horário de início e término,
t=<start time> <stop time>, quando ambos os eventos são 0, significa uma sessão persistente ##### SDP no WebRTC
Algumas modificações foram feitas no SDP no WebRTC e algumas outras descrições foram adicionadas com base no original
// 音频使用9端口收发;
// UDP / TLS / RTP / SAVPF 表示使用 dtls / srtp 协议对数据加密传输;
m = audio 9 UDP / TLS / RTP / SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
// 网络描述, webRTC不使用
c = IN IP4 0.0.0.0
// 设置rtcp地址和端口, webRTC不使用
a = rtcp: 9 IN IP4 0.0.0.0
// 安全验证信息
a=ice-ufrag:duP8
a=ice-pwd:/7pIrSvgESATKPZUVzHhLQ0E
a=ice-options:trickle
// 音频流媒体描述
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
descrição da mídia
- m=: Indica uma sessão,
m=<media> <port> <transport> <fmt list>*<media>: Tipo de mídia, como áudio/vídeo, etc.; *<port>: Porta; *<transport>: Protocolo de transporte, existem dois tipos—RTP/AVP e UDP; *<fmt list>: Formato de mídia, ou seja, o lista de tipo de carga útil de dados (Payload Type ). - a=*:
a=<type>oua=<type>:<value>, o tipo tem dois tipos rtpmap e fmap
Agora vamos melhorar o diagrama esquemático do gateway anterior e adicionar alguns conceitos aqui
Coletar endereços de candidatos
A chamada coleção de endereços candidatos é obter seu próprio endereço comunicável através do servidor STUN mencionado anteriormente.
| Tipos de | pseudônimo | Como enviar para peer | uso |
|---|---|---|---|
| Candidatos anfitriões | hospedar | servidor de sinalização | O endereço de transporte local obtido da placa de rede, se este endereço estiver atrás do NAT, é o endereço da intranet |
| Candidatos à reflexão do servidor | srflx | servidor de sinalização | O endereço de transporte obtido da verificação de vinculação enviada ao servidor de atordoamento. Se este endereço estiver atrás do NAT, é o endereço de rede pública do NAT mais externo |
| Candidatos à reflexão de pares | prflx | Solicitação de vinculação de atordoamento | O endereço de transporte obtido da solicitação Stun Binding enviada pelo par. Este é um novo tipo de candidato que ocorre durante as verificações de conectividade |
| Candidatos de revezamento | retransmissão | servidor de sinalização | O endereço de transporte do servidor de retransmissão de mídia. Adquirido usando a solicitação TURN Allocate |
trocar endereços de candidatos
A envia o endereço do candidato coletado na primeira etapa para B através do servidor de sinalização, e B também envia o endereço do candidato coletado para A. Depois de receber todos os endereços do candidato de B, A comparará seu próprio endereço do candidato com o endereço do candidato do mesmo nível. um arranjo completo e armazená-lo na tabela de estado. Por exemplo, o host de A neste momento é 192.168.0.100:60000, srflx é 11.102.30.3:30110, o host de B é 192.168.0.15:10001, srflx é 1.10.108.25:30110, a tabela de status é a seguinte
| endereço da placa de rede local | endereço de par | Estado |
|---|---|---|
| 192.168.1.105:60001 | 192.168.0.204:40001 | Verificação de atordoamento não realizada |
| 172.16.40.6:60003 | 192.168.0.204:40001 | Verificação de atordoamento não realizada |
| 192.168.1.105:60001 | 11.92.14.8:50002 | Verificação de atordoamento não realizada |
| 172.16.40.6:60003 | 11.92.14.8:50002 | Verificação de atordoamento não realizada |
| 192.168.1.105:60001 | 192.168.0.181:40003 | Verificação de atordoamento não realizada |
| 172.16.40.6:60003 | 192.168.0.181:40003 | Verificação de atordoamento não realizada |
Neste momento, todos os status de registro não são verificados STUN, e a verificação STUN de cada registro será realizada na próxima etapa.
verificação STUN
Nós introduzimos o processo de inspeção STUN antes, se você esquecer, você pode revisar a perfuração p2p
conectar, inicializar mídia
Após a conclusão da verificação do STUN, a conexão é preparada. Neste momento, a tabela de status no P2PTransportChannel registrou o custo de cada registro (envolvendo muitos fatores, como o tempo decorrido desde o envio de uma solicitação de Stun até o recebimento de uma resposta. .).
**Quando houver dados Rtp de vídeo a serem enviados, verifique o primeiro registro na tabela de status, se julgar que seu status está pronto para enviar, ele usará esta conexão para enviar. Caso contrário, desista da tarefa de envio diretamente. **Ou seja, a tarefa do módulo de mídia não será afetada pelo estado da conexão, apenas verifica o estado quando está prestes a enviar, e desiste de enviar caso não esteja conectado.
Para garantir que as regras de filtragem e mapeamento NAT não expirem durante uma sessão de mídia, o ICE envia continuamente verificações de conexão stun contra candidatos em uso. Em termos leigos, é "polling".Se a resposta do STUN expirar, aumentará o custo, o que se reflete na tabela de status conforme a prioridade é reduzida, ou seja, a tabela de status do P2PTransportChannel é em tempo real.
Finalmente
Organizou 75 perguntas de entrevista de alta frequência sobre JS e forneceu respostas e análises, o que basicamente pode garantir que você possa lidar com as perguntas do entrevistador sobre JS.
Amigos necessitados, você pode clicar no cartão abaixo para receber e compartilhar gratuitamente