Milhões de vídeo chamadas por dia ou "Ligue para a mãe!"

Do ponto de vista do usuário, os serviços de chamada parecem bem simples: você acessa a página para outro usuário, liga, ele pega o telefone, conversa com ele. Lá fora, parece que tudo é simples, mas poucos sabem como fazer esse serviço. Mas Alexander Tobol ( alatobol ) não apenas sabe, mas também compartilha de bom grado sua experiência.



Além disso, a versão em texto do relatório sobre o HighLoad ++ Siberia, com a qual você aprenderá:

• como os serviços de videochamada funcionam sob o capô;
• quão bonito é romper o NAT - isso será interessante para especialistas em jogos que precisam de uma conexão ponto a ponto;
• como o WebRTC funciona, quais protocolos ele inclui;
• como posso ajustar o WebRTC através do BigData.

Sobre o palestrante: Alexander Tobol lidera o desenvolvimento das plataformas de vídeo e fita em ok.ru.

Histórico de videochamadas

O primeiro dispositivo de videochamada apareceu em 1960, era chamado de picherphone, usava redes dedicadas e era extremamente caro. Em 2006, o Skype adicionou videochamadas à sua aplicação. Em 2010, o Flash suportou o protocolo RTMFP e, em Odnoklassniki, lançamos videochamadas em Flash. Em 2016, o Chrome parou de oferecer suporte ao Flash e, em agosto de 2017, reiniciamos as chamadas com a nova tecnologia, sobre a qual falarei hoje. Após finalizar o serviço, por mais seis meses, recebemos um aumento significativo nas chamadas concluídas com sucesso. Recentemente, também temos máscaras nas chamadas.

Arquitetura e TK

Como trabalhamos em uma rede social, não temos tarefas técnicas e não sabemos o que é TK. Geralmente, a ideia se encaixa em uma página e se parece com isso.


O usuário deseja ligar para outros usuários usando um aplicativo da Web ou iOS / Android. Outro usuário pode ter vários dispositivos. A chamada chega a todos os dispositivos, o usuário pega o telefone em um deles e eles conversam. Tudo é simples.

Especificações técnicas

Para fazer um serviço de chamada de qualidade, precisamos entender quais características queremos rastrear. Decidimos começar procurando o que mais incomoda o usuário.

O usuário fica definitivamente irritado se ele atender o telefone e forçado a esperar até que a conexão seja estabelecida.


O usuário fica irritado se a qualidade da chamada for ruim - algo é interrompido, o vídeo está espalhado, o som está borbulhando.


Mas acima de tudo, o usuário fica irritado com o atraso nas chamadas. Latência é uma das características importantes das chamadas. Com latência em uma conversa da ordem de 5 segundos, é absolutamente impossível conduzir um diálogo.


Determinamos por nós mesmos características aceitáveis:

• Iniciar - decidimos que era bom iniciar a chamada em um segundo. I.e. conectar após a resposta do usuário, não deve demorar mais de 1 segundo.
• A qualidade é um indicador muito subjetivo. Você pode medir, por exemplo, a relação sinal-ruído (SNR), mas ainda faltam quadros e outros artefatos. Medimos a qualidade de maneira subjetiva e depois avaliamos a felicidade dos usuários.
• A latência deve ser menor que 0,5 segundos. Se a latência for superior a 0,5 segundos, você já ouvirá atrasos e começará a se interromper.

Polycom é um sistema de conferência instalado em nossos escritórios. Temos latências médias do polycom da ordem de 1,3 segundos. Com esse atraso, você nem sempre se entende. Se o atraso aumentar para 2 segundos, o diálogo não será possível.


Como já lançamos a plataforma, esperávamos aproximadamente um milhão de chamadas por dia. São mil chamadas em paralelo. Se todas as chamadas forem iniciadas pelo servidor, haverá mil megabits por chamada. Isso é apenas 1 gigabit / s, um servidor de ferro será suficiente.

Internet vs TTX

O que pode impedir você de obter recursos interessantes? A Internet!


Na Internet, existem coisas como tempo de ida e volta (RTT), que não podem ser superadas, há uma largura de banda variável, há NAT.

Anteriormente, medimos a velocidade de transmissão nas redes de nossos usuários.


Nós a dividimos de acordo com o tipo de conexão, analisamos o RTT médio, a perda de pacotes, a velocidade e decidimos testar as chamadas nos valores médios de cada uma dessas redes.


Existem outros problemas na Internet:

• Perda de pacote - medimos 0,6% de perda aleatória de pacotes (não consideramos a perda de pacotes de congestionamento com um número excessivo de pacotes).
• Reordenação - você envia pacotes na mesma ordem e a rede os ordena novamente.
• Tremulação - envie um fluxo de vídeo ou áudio em um determinado intervalo e os pacotes se reúnem no lado do cliente em pacotes, por exemplo, devido ao armazenamento em buffer nos dispositivos de rede.
• NAT - descobriu-se que mais de 97% dos usuários estão atrás do NAT. Falaremos sobre o porquê, o que e como.

Considere as configurações de rede listadas acima com um exemplo simples.

Procurei no meu escritório o site da Universidade Estadual de Novosibirsk e recebi um ping tão estranho.


A tremulação média neste exemplo é de 30 ms, ou seja, o intervalo médio entre os tempos de ping adjacentes é de cerca de 30 ms e o ping médio é de 105 ms.

O que é importante nas chamadas, por que lutaremos pelo p2p?


Obviamente, se conseguirmos estabelecer uma conexão P2P entre nossos usuários que estão tentando conversar entre si em São Petersburgo, e não através de um servidor localizado em Novosibirsk, economizaremos cerca de 100 ms de ida e volta e tráfego para este serviço.

Portanto, a maior parte do artigo é dedicada a como obter boas p2p.

História ou legado

Como eu disse, temos um serviço de chamadas desde 2010 e agora o reiniciamos.


Em 2006, quando o Skype começou, o Flash comprou a Amicima, que fabricava a RTMFP. O Flash já possuía RTMP, que em princípio pode ser usado para chamadas e geralmente é usado para streaming. Mais tarde, o Flash abriu a especificação RTMP. Eu me pergunto por que eles precisavam de RTMFP? Em 2010, usamos o RTMFP.

Compare os requisitos para protocolos de chamada e protocolos de streaming reais e veja onde fica essa borda.


O RTMP é mais um protocolo de streaming de vídeo. Ele usa TCP, possui atraso cumulativo. Se você tiver uma boa conexão com a Internet, as chamadas para RTMP funcionarão.

O protocolo RTMFP , apesar da diferença em apenas uma letra, é o protocolo UDP. Está livre de problemas de buffer - aqueles que estão no TCP; É privado de bloqueio de linha de frente - é quando você perde um pacote e o TCP não retorna os seguintes pacotes até que seja hora de enviar o perdido novamente. O RTMFP conseguiu lidar com o NAT e estava enfrentando uma alteração no endereço IP dos clientes. Portanto, lançamos a web no RTMFP em 2010.


Só em 2011 apareceu o rascunho inicial do WebRTC, que ainda não estava totalmente operacional. Em 2012, começamos a oferecer suporte a chamadas no iOS / Android, e aconteceu outra coisa, e em 2016 o Chrome parou de oferecer suporte ao Flash. Nós tivemos que fazer alguma coisa.


Analisamos todos os protocolos de VoIP: como sempre, para fazer algo, começamos a olhar para os concorrentes.

Concorrentes ou por onde começar

Escolhemos os concorrentes mais populares: Skype, WhatsApp, Google Duo (semelhante ao Hangouts) e ICQ.

Para começar, medimos o atraso.


É fácil de fazer. Acima está uma fotografia na qual:

• Cronômetro (consulte o telefone no canto superior esquerdo), que mostra a hora (03:08).
• O telefone próximo faz uma chamada e leva o primeiro telefone como um vídeo. A partir do momento em que a imagem entrou na câmera do telefone, e você a viu, foram necessários cerca de 100 ms.
• Uma chamada para outro telefone (branco) e mais uma vez. Aqui o atraso é de cerca de 310 ms no Google Duo.

Ainda não revelo todas as placas, mas garantimos que esses dispositivos não pudessem estabelecer conexões p2p. Obviamente, as medições foram realizadas em redes diferentes, e este é apenas um exemplo.


O Skype ainda interrompe um pouco. Descobriu-se que, com o Skype, caso não consiga conectar o p2p, o atraso é de 1,1 s.

Nosso ambiente de teste foi complicado. Testamos em diferentes condições (EDGE, 3G, LTE, WiFi), levamos em conta que os canais são assimétricos e eu dou os valores médios de todas as medições.


Para estimar o consumo da bateria, a carga do processador e tudo o mais, decidimos que você pode simplesmente medir a temperatura do telefone com um pirômetro e assumir que essa é uma carga média na GPU do telefone por processador, bateria. Em princípio, é muito desagradável levar um telefone quente ao ouvido e até segurá-lo nas mãos. Parece ao usuário que agora o aplicativo consumirá toda a bateria.


O resultado é:

• Os mais lentos no atraso foram ICQ e Skype, e os mais rápidos - Telegram. Esta não é uma comparação completamente correta, pois o Telegram não possui videochamadas, mas elas têm latência mínima no áudio. WhatsApp (cerca de 200 ms) e Hangouts - 390 ms funcionam muito bem.
• Por temperatura, o Telegram come menos sem vídeo e o Skype mais.
• Em termos de tempo de resposta , o Telegram estabelece a conexão por mais tempo e o mais rápido WhatsApp e Google Duo.

Ótimo, temos algumas métricas!


Testamos a qualidade do vídeo e da voz em redes diferentes, com quedas diferentes e tudo mais. Como resultado, chegamos à conclusão de que o vídeo da mais alta qualidade está no Google Duo e a voz está no Skype , mas isso ocorre em redes "ruins" quando já há distorção. Em geral, todo mundo trabalha aproximadamente medíocre. O WhatsApp tem a imagem mais desfocada.

Vamos ver no que tudo está implementado.


O Skype tem seu próprio protocolo proprietário e todos os outros usam uma modificação do WebRTC ou, geralmente, diretamente do WebRTC. Hangouts, Google Duo, WhatsApp e Facebook Messenger podem trabalhar com a Web, e todos eles têm o WebRTC sob o capô. Eles são todos tão diferentes, com características diferentes, e todos eles têm um WebRTC! Então, você precisa ser capaz de cozinhá-lo corretamente. Além disso, há o Telegram, pelo qual algumas partes do WebRTC são responsáveis ​​pela parte de áudio, há o ICQ, que bifurcou o WebRTC por um longo tempo e continuou desenvolvendo seu próprio caminho.

WebRTC Arquitetura

O WebRTC implica a presença de um servidor de sinalização, um intermediário entre clientes, que é usado para trocar mensagens durante o estabelecimento de uma conexão p2p entre eles. Depois de estabelecer uma conexão direta, os clientes começam a trocar dados de mídia entre si.

WebRTC Demo

Vamos começar com uma demonstração simples. Existem 5 etapas simples para estabelecer uma conexão WebRTC.


Diz o seguinte:

1. Assista a um vídeo e estabeleça uma conexão entre colegas, transfira algum tipo de iceServers (não está claro imediatamente o que é).
   
2. Crie uma oferta SDP e envie-a para sinalização, e a WebRTC de sinalização não será implementada de forma alguma.
   
3. Então você precisa criar um wrapper para o que vem da sinalização, e isso também não faz parte do WebRTC.
   
4. Além disso, troque alguns candidatos.
   
5. Finalmente, obtenha o fluxo de vídeo remoto.
   

Vamos descobrir o que está acontecendo lá e o que precisamos nos implementar.


Olhamos para a foto de baixo para cima. Existe uma biblioteca WebRTC que já está embutida no navegador, suportada pelo Chrome, Firefox etc. Você pode compilá-la no Android / iOS e se comunicar com ela por meio da API e SDP (Session Description Protocol), que descreve a própria sessão. Abaixo vou lhe dizer o que está incluído nele. Para usar esta biblioteca em seu aplicativo, você deve estabelecer uma conexão entre assinantes por meio de sinalização. A sinalização também é o seu serviço que você deve escrever por si próprio, o WebRTC não o fornece.

Ainda neste artigo, discutiremos a rede em ordem, depois em vídeo / áudio e, no final, escreveremos nossa sinalização.

Rede WebRTC ou p2p (na verdade, c2s2c)

Configurar uma conexão p2p parece ser bastante simples.


Temos Alice e Bob que desejam estabelecer uma conexão p2p. Eles pegam seus endereços IP, têm um servidor de sinalização ao qual estão conectados e pelo qual podem trocar esses endereços. Eles trocam endereços, e oh! Eles têm os mesmos endereços, algo deu errado!


De fato, é provável que ambos os usuários estejam atrás de roteadores Wi-Fi e esses sejam seus endereços IP cinza locais. O roteador fornece a eles um recurso como o Network Address Translation (NAT). Como ela trabalha?


Você tem uma sub-rede cinza e um endereço IP externo. Você envia um pacote para a Internet a partir do seu endereço cinza, o NAT o substitui por branco e lembra o mapeamento: de qual porta ele foi enviado, para qual usuário e qual porta ele corresponde. Quando o pacote de retorno chega, ele é resolvido por esse mapeamento e o envia ao remetente. Tudo é simples.

Abaixo está uma ilustração de como fica minha casa.


Este é o meu endereço IP interno e o endereço do roteador (a propósito, também cinza). Se você rastrear e ver a rota, veremos meu roteador Wi-Fi: um pacote de endereços de provedores cinza e um IP branco externo. Portanto, de fato, terei dois NATs: um no qual estou no Wi-Fi e outro no provedor, a menos que, é claro, eu comprei um endereço IP externo dedicado.

O NAT é tão popular porque:

• muitos IPv4s ainda estão faltando e não há endereços suficientes;
• O NAT parece proteger a rede;
• esta é uma função padrão do roteador: conecte-se ao Wi-Fi, existe NAT ali mesmo, funciona.

Portanto, apenas 3% dos usuários ficam com um IP externo, enquanto todo o resto passa pelo NAT.

O NAT permite que você vá com segurança para qualquer endereço em branco. Mas se você não foi a lugar algum, ninguém poderá procurá-lo.


Estabelecer uma conexão P2P é um problema. De fato, Alice e Bob não podem enviar pacotes um para o outro se ambos estiverem atrás do NAT.

O WebRTC possui um protocolo STUN para resolver esse problema. Propõe-se implantar um servidor STUN. Em seguida, Alice se conecta ao servidor STUN, obtém seu endereço IP, envia para Bob via sinalização. Bob também obtém seu endereço IP e o envia para Alice. Eles enviam pacotes um para o outro e, assim, rompem o NAT.


Pergunta : Alice tem uma porta específica aberta, o NAT / Firewall já foi invadido por essa porta e Bob está aberto. Eles conhecem os endereços um do outro. Alice tenta enviar o pacote para Bob, ele envia o pacote para Alice. Você acha que eles podem conversar ou não?

De fato, você está certo em qualquer caso, o resultado depende do tipo de par NAT que os usuários possuem.

Conversão de endereços de rede

Existem 4 tipos de NAT:

1. NAT de cone completo;
   
2. Cone restrito NAT;
   
3. Cone de porta restrita NAT;
   
4. NAT simétrico
   

Na versão básica, Alice envia um pacote para o servidor STUN, ela abre alguma porta. De alguma forma, Bob descobre sua porta e envia um pacote de devolução. Se esse é o NAT de cone completo - o mais fácil que mapeia a porta externa para a porta interna, Bob poderá enviar imediatamente um pacote para Alice, estabelecer uma conexão e eles falarão.


Abaixo está o esquema de interação: Alice de alguma porta envia um pacote para a porta STUN, STUN responde com seu endereço externo. O STUN pode responder de qualquer endereço, se for NAT de cone completo, ele ainda perfurará o NAT e Bob poderá responder no mesmo endereço.


No caso do cone restrito NAT, as coisas são um pouco mais complicadas. Ele se lembra não apenas da porta da qual você precisa mapear para o endereço interno, mas também do endereço externo para o qual você foi. Ou seja, se você estabeleceu uma conexão apenas com o servidor IP STUN, ninguém mais na rede poderá responder e o pacote de Bob não chegará.


Como esse problema é resolvido? Em um esquema simples (veja a ilustração abaixo) assim: Alice envia um pacote para STUN, ele responde com seu IP. O STUN pode responder a partir de qualquer porta, desde que seja um cone restrito NAT. Bob não pode responder Alice porque ele tem um endereço diferente. Alice responde com um pacote, sabendo o endereço IP de Bob. Ela abre o NAT para Bob, Bob responde. Viva, eles conversaram.


Uma opção um pouco mais complicada é o NAT de cone restrito à porta . Mesmo assim, apenas o STUN deve responder exatamente da porta à qual foi acessado. Tudo vai funcionar também.

A coisa mais prejudicial é o NAT simétrico .


No começo, tudo funciona exatamente da mesma maneira - Alice envia o pacote para o servidor STUN, ele responde da mesma porta. Bob não pode responder Alice, mas ela envia o pacote para Bob. E aqui, apesar do fato de Alice enviar um pacote para a porta 4444, o mapeamento aloca uma nova porta para ela. O NAT simétrico é diferente quando cada nova conexão é estabelecida, cada vez que emite uma nova porta no roteador. Conseqüentemente, Bob está batendo na porta da qual Alice foi para STUN, e eles não podem se conectar.

Na direção oposta, se Bob tiver um endereço IP aberto, Alice poderá procurá-lo e eles estabelecerão uma conexão.

Todas as opções são coletadas em uma tabela abaixo.


Isso mostra que quase tudo é possível, exceto quando tentamos estabelecer conexões por meio de NAT simétrico com cone de porta restrito NAT ou NAT simétrico na outra extremidade.


Como descobrimos, o p2p não tem preço para nós em termos de latência, mas se não foi possível instalá-lo, o WebRTC nos oferece um servidor TURN. Quando percebemos que o p2p não será instalado, basta conectar-se ao TURN, que fará proxy de todo o tráfego. No entanto, ao mesmo tempo, você pagará pelo tráfego e os usuários poderão ter alguns atrasos adicionais.

Prática

O Google tem servidores STUN gratuitos. Você pode colocá-los na biblioteca, ele funcionará.

Os servidores TURN possuem credenciais (login e senha). Muito provavelmente, você terá que criar o seu próprio, é bastante difícil encontrar gratuitamente.

Exemplos de servidores STUN gratuitos do Google:

• atordoamento: stun.l.google.com: 19302
• atordoamento: stun1.l.google.com: 19302
• atordoamento: stun2.l.google.com: 19302
• atordoamento: stun3.l.google.com: 19302

E um servidor TURN gratuito com senhas: url: 'turn: 192.158.29.39: 3478? Transport = udp', credencial: 'JZEOEt2V3Qb0y27GRntt2u2PAYA =', nome de usuário: '28224511: 1379330808'.

Usamos coturno .


Como resultado, 34% do tráfego passa pela conexão p2p, todo o resto é proxy através do servidor TURN.

O que mais é interessante no protocolo STUN?

STUN permite determinar o tipo de NAT.


Link do slide

Ao enviar um pacote, você pode indicar que deseja receber uma resposta da mesma porta ou solicitar ao STUN que responda de uma porta diferente, de um IP diferente ou mesmo de um IP e porta diferentes. Assim, para 4 consultas ao servidor STUN, você pode determinar o tipo de NAT .


Contamos os tipos de NAT e constatamos que quase todos os usuários têm NAT simétrico ou NAT de cone restrito à porta. Portanto, acontece que apenas um terço dos usuários pode estabelecer uma conexão p2p.

Você pode perguntar por que estou lhe dizendo tudo isso, se você pudesse pegar o STUN do Google, colocá-lo no WebRTC e parece que tudo vai funcionar.

Porque você pode realmente determinar o tipo de NAT você mesmo.


Este é um link para um aplicativo Java que não faz nada de complicado: apenas envia portas e servidores STUN diferentes e analisa a porta que vê no final. Se você tiver o NAT de cone aberto completo, o servidor STUN terá a mesma porta. Com o cone restrito NAT, você terá portas diferentes para cada solicitação de STUN.


Com o NAT simétrico, acontece assim no meu escritório. Existem portas completamente diferentes.

Mas, às vezes, há um padrão interessante de que para cada conexão, o número da porta aumenta em um.


Ou seja, muitos NATs são configurados para aumentar ou diminuir a porta em uma constante. Essa constante pode ser encontrada e, assim, rompe o NAT simétrico.


Assim, rompemos o NAT - vamos para um servidor STUN, para outro, observamos a diferença, comparamos e tentamos novamente fornecer nossa porta já com esse incremento ou decréscimo. Ou seja, Alice está tentando dar a Bob seu porto, já ajustado para uma constante, sabendo que da próxima vez será exatamente isso.


Então, conseguimos soldar outros 12% ponto a ponto .

De fato, algumas vezes roteadores externos com o mesmo IP se comportam da mesma maneira. Portanto, se as estatísticas forem coletadas e se o Symmetric NAT for um recurso do provedor e não um roteador Wi-Fi do usuário, o delta poderá ser previsto, enviando-o imediatamente ao usuário para que ele o use e não gaste muito tempo determinando-o.

Relé CDN ou o que fazer se você não conseguir estabelecer uma conexão P2P

Se ainda usarmos o servidor TURN e não trabalharmos em p2p, mas no modo real, passando todo o tráfego pelo servidor, ainda podemos adicionar uma CDN. A menos, é claro, que você tenha um playground. Nós temos nossos próprios sites CDN, então para nós foi bastante simples. Mas era necessário determinar onde é melhor enviar uma pessoa: para um site da CDN ou, digamos, para um canal para Moscou. Como não é uma tarefa muito trivial, fizemos o seguinte:

1. Acidentalmente emitido para alguns usuários do site de Moscou, alguns - remotos.
   
2. Coletamos estatísticas sobre o IP do usuário, sobre servidores e sobre as características da rede.
   
3. Pelo maxMind, agrupamos as sub-redes, analisamos as estatísticas e conseguimos entender por IP qual usuário tinha o servidor TURN mais próximo para a conexão.
   

Há uma CDN em Novosibirsk. Se tudo funcionar para você em Moscou, o 99º percentil de RTT será de 1,3 segundos. Através da CDN, tudo funciona muito mais rápido (0,4 segundos).

É sempre melhor usar uma conexão P2P e não usar um servidor? Um exemplo interessante são os dois provedores de Krasnoyarsk, Optibyte e Mobra (os nomes podem ter sido alterados). Por alguma razão, a conexão entre eles no p2p é muito pior do que através do MSK. Provavelmente eles não são amigos um do outro.


Analisamos todos esses casos, enviando usuários aleatoriamente para p2p ou via MSK, coletamos estatísticas e construímos previsões. Sabemos que as estatísticas precisam ser atualizadas; portanto, para alguns usuários, estabelecemos conexões diferentes para verificar se alguma coisa mudou nas redes.

Medimos características simples como tempo de rodada, perda de pacotes, largura de banda - resta saber como compará-las corretamente.


Como entender o que é melhor: Internet de 2 Mbit / s, RTT de 400 ms e perda de pacotes de 5% ou 100 Kbit / s, atraso de 100 ms e escassa perda de pacotes?

Não há resposta exata, a avaliação da qualidade das chamadas de vídeo é muito subjetiva. Portanto, após o término da chamada, pedimos aos usuários que avaliassem a qualidade em asteriscos e definissem as constantes de acordo com os resultados. Descobriu-se que, por exemplo, o RTT é inferior a 300 ms - não importa mais, a taxa de bits é mais importante.

Maiores classificações de usuários no Android e iOS. É visto que os usuários do iOS têm maior probabilidade de colocar uma unidade e mais frequentemente cinco. Não sei por que, provavelmente, as especificidades da plataforma. Mas puxamos as constantes ao longo delas, para que tivéssemos, como nos parece, boas.

De volta ao nosso esboço do artigo, ainda estamos discutindo a rede.

Como é a configuração da conexão?


Enviamos servidores STUN e TURN para PeerConnection (), uma conexão é estabelecida. Alice descobre seu IP, envia-o para sinalizar; Bob aprende sobre o IP de Alice. Alice recebe o IP de Bob. Eles trocam pacotes, talvez rompam com o NAT, talvez configurem TURN e se comuniquem.


Nas 5 etapas para estabelecer a conexão que discutimos anteriormente, descobrimos os servidores, descobrimos onde obtê-los e que os candidatos a ICE são endereços IP externos que trocamos por sinalização. Os endereços IP internos dos clientes, se estiverem dentro do alcance de um Wi-Fi, também podem ser tentados.

Vamos passar para a parte do vídeo.

Vídeo e áudio

O WebRTC suporta um determinado conjunto de codecs de vídeo e áudio, mas você pode adicionar seu próprio codec lá. Basicamente suportado pelo H.264 e VP8 para vídeo . O VP8 é um codec de software, portanto, consome muita bateria. O H.264 não está disponível em todos os dispositivos (geralmente é nativo); portanto, a prioridade padrão está no VP8.

Dentro do SDP (Session Description Protocol), há negociação de codecs: quando um cliente envia uma lista de seus codecs, o outro envia seus próprios com prioridade e eles concordam com quais codecs serão usados ​​para comunicação. Se desejar, você pode alterar a prioridade dos codecs VP8 e H.264 e, devido a isso, pode economizar bateria em alguns dispositivos, onde 264 é nativo. Aqui está um exemplo de como isso pode ser feito. Fizemos isso, parecia-nos que os usuários não reclamavam da qualidade, mas ao mesmo tempo a carga da bateria era consumida muito menos.

Para áudio, o WebRTC possui o OPUS ou o G711 , geralmente todos os OPUS sempre funcionam, nada precisa ser feito com ele.

Abaixo estão as medições de temperatura após 10 minutos de uso.


É claro que testamos diferentes dispositivos. Este é um exemplo de iPhone e, nele, o aplicativo OK usa menos a bateria, porque a temperatura do dispositivo é mínima.

A segunda coisa que você pode ativar se usar o WebRTC é desligar automaticamente o vídeo quando a conexão estiver muito ruim .


Se você tiver menos de 40 Kbps, o vídeo será desligado. Você só precisa marcar a caixa ao criar a conexão, o valor limite pode ser configurado através da interface. Você também pode definir a taxa de bits inicial mínima e máxima.


Isso é uma coisa muito útil. Se, ao estabelecer uma conexão, você souber antecipadamente qual taxa de bits espera, poderá transferi-la, a chamada será iniciada a partir dela e você não precisará adaptá-la. Além disso, se você sabe que costuma ter perda de pacotes ou rebaixamentos de largura de banda em seu canal, o valor máximo também pode ser limitado.

O WhatsApp funciona com vídeos muito ensaboados, mas com pequenos atrasos, pois comprime agressivamente a taxa de bits por cima.

Coletamos estatísticas usando o MaxMind e as mapeamos.


Essa é uma qualidade inicial aproximada que usamos para chamadas em diferentes regiões da Rússia.

Sinalização

Você provavelmente terá que escrever esta parte se quiser fazer chamadas. Existem todos os tipos de armadilhas. Lembre-se da aparência.


Há um aplicativo com sinalização que se conecta e troca com o SDP, e o SDP abaixo é a interface para o WebRTC.

É assim que a sinalização simples se parece:


Alice liga para Bob. Ele se conecta, por exemplo, através de uma conexão de soquete da web. Bob recebe um empurrão no seu celular ou navegador, ou em alguma conexão aberta, se conecta por um soquete da Web e, depois disso, o telefone começa a tocar no bolso. Bob atende o telefone, Alice envia a ele seus codecs e outros recursos do WebRTC que ela suporta. Bob responde a mesma coisa e depois trocam os candidatos que viram. Viva, ligue!

Tudo parece bem longo. Primeiro, até que você estabeleça uma conexão de soquete da Web, até que o push chegue e tudo mais, o telefone de Bob não tocará no bolso. Alice vai esperar o tempo todo, pensar onde Bob está, por que ele não atende o telefone. Após a confirmação, tudo leva segundos e, mesmo em boas conexões, pode levar de 3 a 5 segundos, e em conexões ruins, todos os 10.

Nós devemos fazer algo sobre isso! Você vai me dizer que tudo pode ser feito de maneira muito simples.



Se você já possui uma conexão aberta para o seu aplicativo, pode enviar imediatamente um push para estabelecer uma conexão, conectar-se ao servidor de sinalização desejado e começar imediatamente a fazer chamadas.

Depois, outra otimização. Mesmo se o telefone ainda estiver tocando no seu bolso e você não o atender, você poderá realmente trocar informações sobre os codecs suportados, endereços IP externos, começar a enviar pacotes de vídeo vazios e, em geral, tudo será aquecido. Depois de atender o telefone, tudo ficará ótimo.

Fizemos isso e parecia que tudo estava legal. Mas não.


O primeiro problema é que os usuários frequentemente cancelam a chamada. Eles clicam em "Ligar" e cancelam imediatamente. Consequentemente, o push vai para a chamada e o usuário desaparece (ele perdeu a Internet ou outra coisa). Enquanto isso, o telefone de alguém toca, ele atende o telefone e ele não é esperado lá. Portanto, nossa otimização primitiva para iniciar a chamada o mais rápido possível não funciona realmente.


Com um cancelamento rápido de chamada, há uma segunda coisa prejudicial. Se você gerar o ID da sua conversa no servidor, precisará aguardar uma resposta. Ou seja, você cria uma chamada, obtém um ID e somente depois pode fazer o que quiser: enviar pacotes, trocar, inclusive cancelar a chamada. Essa é uma história muito ruim, porque, até que a resposta chegue, você não pode realmente cancelar nada do cliente. Portanto, é melhor gerar algum tipo de ID no cliente, como um GUID, e dizer que você iniciou a chamada. As pessoas costumam fazer isso: ligaram, cancelaram e ligaram imediatamente novamente. Para evitar que isso estrague, faça um GUID e envie-o.


Parece não ser nada, mas há outro problema. Se Bob tiver dois telefones, ou em algum outro lugar em que o navegador permanecer aberto, todo o nosso esquema mágico para trocar pacotes, estabelecer uma conexão não funcionará se ele responder de repente a partir de outro dispositivo.

O que fazer? Vamos voltar ao nosso esquema básico de sinalização lenta simples e otimizar, enviar o push um pouco antes. O usuário começará a se conectar mais rapidamente, mas isso economizará alguns centavos.


O que fazer com a parte mais longa depois que ele pegou o telefone e iniciou a troca?


Você pode fazer o seguinte. É claro que Alice já conhece todos os seus codecs e pode enviá-los para os dois telefones de Bob. Ela pode resolver todos os seus endereços IP e também enviá-los para sinalização, o que os manterá em sua fila, mas não os enviará a nenhum cliente, para que eles comecem a estabelecer uma conexão com ela com antecedência.

? offer, , , , , , . , codec negotiation, signaling , , . Candidates signaling.

, signaling . , , .

. Google Duo WhatsApp.


, - . , signaling, , , , , , . .

?


: , . , , — signaling , , - , , , .


, , , . . , , , , . , .

, 24/7, -, .




web-socket - load balancer, signaling- -, . Zookeeper Leader Election, signaling, conversation. conversation, .

, NewSQL Cassandra . , . , signaling, , signaling, - , Leader Election Zookeeper, , , .

:

• - , , IP signaling
• Signaling , .
• , , , , .
• .

, .

Cassandra, ( ).

, :

• iceServers ;
• Session Description Protocol;
• ;
• signaling WebRTC , IP ;
• !

:

• delay ;
• ;
• .

Uau!

Security. Man in the middle attack for WebRTC

man in the middle attack for WebRTC. , WebRTC , RTP, 1996 , SDP 1998 SIP.


— RFC RTP, RTP WebRTC.

RFC — audio level, , audio level , . , SDP, , . congestion, -.

WebRTC . 2011 , 2013 Firefox, iOS/Android, 2014 Opera. , - , .


signaling, , DTLS Handshake . , signaling, «» , , , .


, , , HTTPS, WSS .. — ZRTP, , , Telegram.

Telegram , , . , , , , p2p .

?


— . , , . . K, , , .

, , K ₁ K ₂ . . . K ₁ K ₂ , . K ₁ K ₂ : , — , — , . , , - , , .

• «» NAT type symmetric NAT.
• , : 2 relay, , CDN; .
• , .
• signaling.

, RTMFP, , WebRTC, , . ! 4 .

, :

• WebRTC ( https://webrtc.org/native-code/development/ ), iOS/Android, ;
• coturn ( https://github.com/coturn/coturn );
• signaling.

, .

HighLoad++ 4-.

, . , 19 (10 9 -) , - . , , .