Escrevemos nosso protocolo sobre o UDP

As primeiras transmissões ao vivo da cena apareceram na Rússia há quase 70 anos e foram transmitidas a partir de uma estação de televisão móvel (PTS), que parecia um trólebus e permitia a transmissão de fora do estúdio. E apenas três anos atrás, o Periscope permitiu usar um telefone celular em vez de um "trólebus".

Mas esse aplicativo apresentava vários problemas relacionados, por exemplo, a atrasos na transmissão, a incapacidade de assistir a transmissões em alta qualidade etc.


Seis meses depois, no verão de 2016, o Odnoklassniki lançou seu aplicativo móvel de transmissão ao vivo OK, no qual eles tentaram resolver esses problemas.

Alexander Tobol é responsável pela parte técnica do vídeo em Odnoklassniki e, no Highload ++ 2017, ele falou sobre como escrever seu protocolo UDP e por que isso pode ser necessário.

Com a transcrição do relatório, você aprenderá tudo sobre outros protocolos de streaming de vídeo, quais são as nuances e quais truques são necessários.


Eles dizem que devemos sempre começar com a arquitetura e o TK - supostamente é impossível sem isso! Então vamos lá.

Arquitetura e TK

No slide abaixo, está o diagrama da arquitetura de qualquer serviço de streaming: o vídeo é alimentado na entrada, convertido e transmitido na saída . Adicionamos um pouco mais de requisitos a essa arquitetura: o vídeo deve ser fornecido a partir de desktops e telefones celulares, e a saída deve ir para os mesmos desktops, telefones celulares, smartTV, Chromcast, AppleTV e outros dispositivos - todos os vídeos em que é possível reproduzir.


Em seguida, passamos aos termos de referência. Se você tem um cliente, você tem TK. Se você é uma rede social, não possui TK. Como fazer as pazes?

Obviamente, você pode entrevistar os usuários e descobrir tudo o que eles querem. Mas haverá um monte de desejos que não se correlacionam com o que as pessoas realmente precisam.

Decidimos seguir o caminho oposto e vimos o que os usuários NÃO queriam ver no serviço de transmissão.

• A primeira coisa que o usuário não deseja é ver o atraso no início da transmissão .
  
• O usuário não deseja ver uma imagem de fluxo de baixa qualidade .
  
• Se a transmissão for interativa quando o usuário se comunicar com seu público (próximas transmissões ao vivo, chamadas etc.), ele não deseja ver o atraso entre a serpentina e o espectador .
  

É assim que um serviço de streaming normal se parece. Vamos ver o que pode ser feito para fazer um serviço de streaming regular em vez do habitual.


Você pode começar analisando todos os protocolos de streaming, selecionar os mais interessantes e compará-los. Mas fizemos de forma diferente.

O que os concorrentes têm?

Começamos explorando os serviços da concorrência. Periscópio aberto - o que eles têm?

Como sempre, o principal é arquitetura.


Sara Hyder, engenheira líder do Periscope, escreve que eles usam o Wowza para o back-end. Se lermos um pouco mais de artigos, veremos o que eles transmitem usando o protocolo RTMP e o distribuiremos no RTMP ou no HLS. Vamos ver o que são esses protocolos e como eles funcionam.

Testamos o Periscope em nossos três requisitos principais.

Eles têm uma velocidade inicial aceitável (menos de um segundo em boas redes), uma qualidade constante de cerca de 600 px (não HD) e, ao mesmo tempo, atrasos podem ser de até 12 segundos .

A propósito, como medir o atraso na transmissão?

Esta é uma fotografia de uma medição de atraso. Há um telefone celular com um temporizador. Ligamos a transmissão e vemos a imagem deste telefone na tela. Por 0,15 milissegundos, a imagem caiu no sensor da câmera e foi removida da memória de vídeo para a tela do telefone. Depois disso, ligamos o navegador e assistimos à transmissão.

Ai! Ela está um pouco atrasada - cerca de 12 segundos.

Para descobrir os motivos do atraso, analisamos o fluxo de vídeo.

Portanto, existe um telefone celular, o vídeo sai da câmera e entra no buffer de vídeo. Aqui os atrasos são mínimos (± 0,15 ms). Em seguida, o codificador codifica o sinal, empacota-o em um pacote e envia-o para o buffer do soquete. Tudo voa para a web. Além disso, o mesmo acontece no dispositivo receptor.

Basicamente, há dois pontos difíceis a serem considerados:

• codificação / decodificação de vídeo;
  
• protocolos de rede .
  

Codificação / decodificação de vídeo

Vou contar um pouco sobre codificação. Você o encontrará de qualquer maneira se fizer a transmissão ao vivo de baixa latência.

O que é um vídeo? Este é um conjunto de quadros, mas não é simples. Os quadros são de três tipos: quadro I, P e B:

• I-frame é apenas jpg. De fato, este é um quadro de referência, não depende de ninguém e contém uma imagem clara.
  
• O quadro P depende apenas dos quadros anteriores.
  
• O quadro B complicado pode depender do futuro. Isso significa que, para calcular o quadro b, é necessário que os quadros futuros também venham da câmera. Somente então um quadro b pode ser decodificado com algum atraso.
  

Isso mostra que os quadros B são prejudiciais . Vamos tentar removê-los.

1. Se você transmitir a partir de um dispositivo móvel, tente ativar o perfil da linha de base . Isso desativará o quadro B.
   
2. Você pode tentar configurar o codec e reduzir o atraso de quadros futuros para que os quadros cheguem mais rapidamente.
   
3. Outra coisa importante no ajuste do codec é a inclusão de CBR (taxa de bits constante).
   

Como os codecs funcionam é ilustrado no slide acima. Neste exemplo, o vídeo é uma imagem estática, sua codificação economiza espaço em disco, porque quase nada muda lá, e a taxa de bits do vídeo é baixa. As mudanças estão ocorrendo - a entropia está aumentando, a taxa de bits do vídeo está aumentando - é ótimo armazenar em disco.

Porém, no momento em que as alterações ativas começaram e a taxa de bits aumentou, provavelmente todos os dados não entrariam na rede. É exatamente o que acontece quando você faz uma chamada de vídeo e começa a ligar, e seu assinante diminui a velocidade da imagem. Isso ocorre porque a rede não tem tempo para se adaptar à alteração da taxa de bits.

É preciso incluir CBR . Nem todos os codecs do Android o suportam corretamente, mas eles se esforçam por isso. Ou seja, você precisa entender que, com o CBR, você não terá a imagem perfeita do mundo, como na figura inferior, mas ainda vale a pena ativá-la.

4. E no back-end, você precisa adicionar o codec de zerolatência ao H264 - isso permitirá que você não faça dependências nos quadros para o futuro.

Protocolos de transferência de vídeo

Considere quais protocolos de streaming o setor oferece. Dividi-os condicionalmente em dois tipos:

1. protocolos de streaming;
   
2. protocolos de segmento.
   

Protocolos de streaming são protocolos do mundo das chamadas p2p: RTMP, webRTC, RTSP / RTP . Eles diferem na medida em que os usuários concordam em qual canal eles têm, selecione a taxa de bits do codec de acordo com o canal. E eles também têm equipes adicionais desse tipo, como "me dê uma chance de referência". Se você perdeu um quadro, nesses protocolos você pode solicitá-lo novamente.

A diferença entre os protocolos de segmento é que ninguém negocia com ninguém. Eles cortam o vídeo em segmentos, armazenam cada segmento em várias qualidades e o cliente pode escolher qual segmento assistir. Cada segmento começa com um quadro de referência.

Considere os protocolos em mais detalhes. Vamos começar com os protocolos de streaming e descobrir quais problemas podemos encontrar se usarmos protocolos de streaming para streaming de broadcast.

Protocolos de Streaming

O periscópio usa RTMP. Esse protocolo apareceu em 2009 e, a princípio, a Adobe não o especificou completamente. Então ele teve um certo tipo de dificuldade com o fato de a Adobe querer vender exclusivamente seu servidor. Ou seja, o RTMP se desenvolveu bastante difícil. Seu principal problema é que ele usa o TCP , mas por algum motivo o Periscope o escolheu.



Se você ler em detalhes, o Periscope usa o RTMP para transmitir com um pequeno número de visualizadores. Apenas essas transmissões, se você tiver um canal insuficiente, provavelmente não poderá assistir.



Considere um exemplo específico. Há um usuário com um canal estreito de comunicação que está assistindo a sua transmissão. Você concorda com ele no RTMP sobre baixa taxa de bits e começa a transmitir pessoalmente para ele.

Um usuário com Internet legal chega até você, você também tem Internet legal, mas você já concordou com baixa qualidade com alguém, e acontece que este terceiro com Internet legal está assistindo a um fluxo de baixa qualidade, apesar do fato de que poderia parece bom.

Decidimos corrigir esse problema. Tornamos possível que o RTMP seja truncado individualmente para cada cliente, ou seja, os streamers negociam com o servidor, transmitem com a qualidade mais alta possível e cada cliente recebe a qualidade que a rede permite.

Uau!

Mas ainda assim, temos RTMP sobre TCP e ninguém nos assegurou de bloquear o início da fila.



Isso é ilustrado na figura: recebemos quadros de áudio e vídeo, o RTMP os compacta, talvez eles os misturem de alguma forma e voam para a rede.

Mas suponha que perdemos um pacote. É possível que o mesmo pacote perdido amarelo - esse geralmente seja um quadro P de algum anterior - possa ter sido descartado. Talvez, no mínimo, alguém possa reproduzir áudio. Mas o TCP não nos fornecerá o restante dos pacotes, pois garante a entrega e a sequência de pacotes . De alguma forma, devemos lidar com isso.


Há outro problema com o uso do protocolo TCP no streaming.

Digamos que temos um buffer e alta largura de banda de rede. Nós geramos pacotes de alta resolução do nosso codec lá. Então - op! - a rede começou a funcionar pior. No codec, já indicamos que a taxa de bits precisa ser reduzida, mas os pacotes prontos já estão na fila e você não pode removê-los de nenhuma maneira. O TCP está desesperado para enviar pacotes HD através do nosso 3G.

Como não temos gerenciamento de buffer, nem priorização, o TCP é extremamente inadequado para streaming .



Vamos dar uma olhada nas redes móveis agora. Pode ser surpreendente para os residentes das capitais, mas nossa rede móvel média é mais ou menos assim:

• Tráfego de 1,1 Mbps;
  
• 0,1% de perda de pacotes;
  
• RTT médio de 300 ms.
  

E se você observar algumas regiões e operadores específicos, eles terão uma porcentagem média diária de perda de pacotes superior a 3% e o RTT de 600 ms é normal.

O TCP é, por um lado, um protocolo interessante - é muito difícil ensinar um carro a dirigir imediatamente em rodovias e fora de estrada. Mas ensiná-la também a voar sobre redes sem fio era muito difícil.

Perder até 0,001% dos pacotes resulta em uma redução de 30% na taxa de transferência. Ou seja, nosso usuário não utiliza o canal em 30% devido à ineficiência do protocolo TCP em redes com perda aleatória de pacotes.

Em certas regiões, a perda de pacotes atinge 1% e o usuário possui cerca de 10% da largura de banda.

Portanto, não faremos TCP .

Vamos ver o que mais há no mundo do streaming a partir do UDP.

O protocolo WebRTC funcionou muito bem para chamadas p2p. Em sites muito populares, eles escrevem que usá-lo para chamadas é muito legal, mas para fornecer vídeo e música não é bom.

Seu principal problema é que ele negligencia perdas . Com todas as situações estranhas, ele simplesmente cai.

Ainda há algum problema em seu apego às chamadas, o fato é que ele criptografa tudo. Portanto, se você transmitir transmissões e não for necessário criptografar todo o fluxo de áudio / vídeo iniciando o WebRTC, você sobrecarregará seu processador de qualquer maneira. Você pode não precisar disso.



O streaming RTP é o protocolo básico para transmissão de dados através de UDP. Abaixo, no slide à direita, há um conjunto de extensões e RFCs que precisavam ser implementados no WebRTC para adaptar esse protocolo para chamadas. Em princípio, você pode tentar fazer algo assim - discar um conjunto de extensões para o RTP e obter streaming UDP. Mas é muito difícil .

O segundo problema é que, se um de seus clientes não suportar nenhuma extensão, o protocolo não funcionará.

Protocolos de segmento

Um bom exemplo de um protocolo de vídeo segmentado é o MPEG-Dash . Consiste em um arquivo de manifesto que você publica no seu portal. Ele contém links para arquivos de diferentes qualidades; no início do arquivo, existe um índice que indica em qual local do arquivo qual segmento inicia.



O vídeo inteiro é dividido em segmentos, por exemplo, por 3 segundos, cada segmento começa com um quadro de referência. Se você assistir a esse vídeo e sua taxa de bits mudar, apenas no lado do cliente começará a ter o segmento da qualidade que você precisa.

Outro exemplo de streaming segmentado é o HLS .

O MPEG-Dash é uma solução do Google, funciona bem no Android, e a solução da Apple é mais antiga, possui várias desvantagens.



A primeira delas é que o manifesto principal contém links para manifestos secundários, os manifestos secundários para cada qualidade específica contêm links para cada segmento individual e cada segmento individual é representado por um arquivo separado.

Se você olhar ainda mais detalhadamente, dentro de cada segmento estará o MPEG2-TS. Este protocolo também foi feito para o satélite; seu tamanho de pacote é de 188 bytes . É muito inconveniente compactar vídeos com esse tamanho, principalmente porque você fornece um cabeçalho pequeno o tempo todo.

De fato, isso é difícil não apenas para servidores, que para processar 40 GB de tráfego devem coletar 26 milhões de pacotes , mas também é difícil para o cliente. Portanto, quando reescrevemos o player iOS no MPEG-Dash, vimos alguns ganhos de desempenho.



Mas a Apple não fica parada. Em 2016, eles finalmente anunciaram que têm a oportunidade de empurrar um fragmento do MPEG4 no HLS. Eles prometeram adicionar isso apenas para desenvolvedores, mas parece que agora o suporte para macOS e iOS deve aparecer.

Ou seja, parece que o fluxo de fragmentos é conveniente - venha, pegue o fragmento desejado, comece pelo quadro de referência - ele funciona.

Menos: é claro que o quadro de referência a partir do qual você iniciou não é o quadro que aquele que transmite agora o possui. Portanto, sempre há um atraso .

Em geral, é possível finalizar o HLS com atrasos da ordem de 5 segundos, alguém diz que conseguiu 4, mas, em princípio, a decisão de usar o streaming de fragmentos para tradução não é muito boa .

Dificuldade vs Atraso

Vamos examinar todos os protocolos disponíveis e classificá-los por dois parâmetros:

• a latência que eles dão entre a transmissão e o visualizador;
• complexidade

Quanto menor o atraso que o protocolo garante, mais complexo é.

O que nós queremos?

Queremos criar um protocolo UDP para transmissão de 1 a N com um atraso comparável à comunicação p2p, com a opção de criptografia opcional de pacotes, dependendo da transmissão pública ou privada.

Que outras opções existem? Você pode esperar, por exemplo, quando o Google lançar seu QUIC.

Vou lhe contar um pouco o que é. O Google está posicionando o Google QUIC como um substituto para o TCP - um tipo de TCP 2.0. Ele foi desenvolvido desde 2013, agora não possui uma especificação, mas está totalmente disponível no Google Chrome, e parece-me que às vezes o ativam em alguns usuários para ver como ele funciona. Em princípio, você pode acessar as configurações, ativar o QUIC, acessar qualquer site do Google e obter esse recurso via UDP.

Decidimos não esperar até que todos especifiquem e arquivar nossa decisão.

Requisitos de protocolo:

1. Multithreading , ou seja, temos vários fluxos - controle, vídeo, áudio.
   
2. Uma garantia de entrega opcional - o fluxo de controle tem 100% de garantia, o vídeo de que precisamos menos - podemos deixar o quadro lá, ainda gostaríamos de áudio.
   
3. Priorização de fluxos - para que o áudio avance e o gerente geralmente voe.
   
4. Criptografia opcional : todos os dados ou apenas cabeçalhos e dados críticos.
   

Este é um triângulo padrão: se uma boa rede, alta qualidade e baixa latência. Assim que uma rede instável aparece, os pacotes começam a desaparecer, equilibramos qualidade e atraso. Temos uma escolha: esperar até que a rede melhore e enviar tudo o que acumulou ou desistir e, de alguma forma, viver com ela.

Se você classificar os protocolos por esse princípio, poderá ver que quanto menor o tempo de espera, pior a qualidade - uma conclusão bastante simples.

Queremos inserir nosso protocolo na zona em que os atrasos se aproximam do WebRTC, mas ao mesmo tempo sermos capazes de pressioná-lo um pouco, porque afinal não temos chamadas, mas transmissões. O usuário deseja finalmente receber um fluxo de qualidade.

Desenvolvimento

Vamos começar a escrever o protocolo UDP, mas primeiro observe as estatísticas.



Estas são as nossas estatísticas sobre redes móveis. Pode-se observar que a Internet média é um pouco mais que megabit, perda de pacotes de cerca de 1% é normal e RTT na região de 600 ms - no 3G, esses são apenas valores médios.

Vamos nos concentrar nisso ao escrever o protocolo - vamos lá!

Protocolo UDP

Abrimos soquete UDP, tiramos os dados, empacotamos, enviamos. Pegamos o segundo pacote do codec, ainda enviamos. Tudo parece estar ótimo!



Mas temos a seguinte imagem: se começarmos a enviar pacotes UDP aleatoriamente para soquete, de acordo com as estatísticas, no 21º pacote, a probabilidade de atingir será de apenas 85%. Ou seja, a perda de pacotes já será de 15%, o que não é bom. Isso precisa ser corrigido.



Isso é fixo como padrão. A ilustração ilustra a vida sem o Pacer e a vida com o Pacer .

O marcapasso é uma coisa que espalha pacotes no tempo e controla sua perda; Ele analisa o que é perda de pacotes agora, dependendo disso, ele se adapta à velocidade do canal.

Como lembramos, para redes móveis, a perda de pacotes de 1-3% é a norma. Por conseguinte, devemos de alguma forma trabalhar com isso. E se perdermos pacotes?

Retransmitir

No TCP, como você sabe, existe um algoritmo de retransmissão rápido: enviamos um pacote, o segundo, se o pacote for perdido, depois de um tempo (período de retransmissão) enviamos o mesmo pacote.

Quais são as vantagens? Sem problemas, sem redundância, mas há um período de retransmissão negativo.



Parece ser muito simples: depois de algum tempo, você precisará repetir o pacote se não tiver recebido confirmação. Logicamente, esse pode ser um tempo igual ao tempo de ping. ping — , RTT time , , .

, , , , jitter: ping-. , , 46 . jitter — 50.



. RTT , , acknowledge . , RFC6298, TCP , .

jitter. jitter ping 15%. , retransmit period , , 20% , RTT.



retransmit. acknowledge . , , . retransmit period, . , .

, retransmit . , , packet loss 5%, 400 , 400 1 packet-drop, , retransmit period , .

, . , , acknowledge . , — , , speculative retransmit .

retransmit, .

. , Forward Error Correction ? , , XOR. , , .



! round trip, .

, , ? XOR — , Reed-Solomon, Fountain codes .. : K , N , N .

!

, , , Forward Error Correction negative acknowledgement.

NACK

, parity protection ( ) , .

NACK:

• , negative acknowledgement, .
  
• FEC.
  

, :

1. , FEC + NACK;
   
2. , Fast retransmit.
   

, .



, , ( ). , , 11 , 60-80 . , , .

6 .



, , . , . , Wi-Fi 22 5 , 3G 34 8 .



: , 90% packet loss 10 , gap 25 , — FEC + NACK Fast retransmit?

, , , Google, QUIC 2013 , Forward Error Correction , , . 2015 .

FEC + NACK, .

, .



, , c :

• 1 / ;
  
• 1% packet loss;
  
• 300 RTT;
  
• 1 000 — ;
  
• 1 000 .
  

10 . packet loss 1% 1 000 10. — 100 1 — , 2 , .

, . 500- , 10 .

:

• 500 Forward Error Correction. , .
  
• NACK, , .
  
• Fast Retransmit, .
  

Forward Error Correction , — gap 200-300 .

Fast Retransmit

: , 10 , , , retransmit period , .



, retransmit period 350 , packet gap — 25-30 , 100. , , retransmit , .

, .

UDP , .



, , p/b-. . , .

, , , , , , 0,5 .

, , , , p/b, , , .

MTU

Como estamos escrevendo o protocolo, teremos que lidar com a fragmentação de IP. Eu acho que muitas pessoas sabem disso, mas por via das dúvidas, vou contar brevemente.



Temos um servidor, ele envia alguns pacotes para a rede, eles chegam ao roteador e, no seu nível, a MTU (unidade máxima de transmissão) fica menor que o tamanho do pacote que chegou. Ele divide o pacote em grande e pequeno (aqui 1100 e 400 bytes) e envia.

Em princípio, não há problema, tudo se reunirá no cliente e funcionará. Mas se perdermos 1 pacote, eliminamos todos os pacotes, além de obtermos custos adicionais para os cabeçalhos dos pacotes. Portanto, se você estiver escrevendo seu protocolo, é ideal trabalhar na quantidade de MTU.

Como contar?

De fato, o Google não se incomoda, coloca cerca de 1200 bytes no seu QUIC e não o seleciona, porque a fragmentação de IP coletará todos os pacotes.



Fazemos exatamente o mesmo - primeiro definimos um tamanho padrão e começamos a enviar pacotes - deixe fragmentá-los.

Paralelamente, execute um thread separado e crie um soquete com o sinalizador de proibição de fragmentação para todos os pacotes. Se o roteador encontrar um pacote desse tipo e não puder fragmentar esses dados, ele eliminará o pacote e possivelmente enviará a você via ICMP que há problemas, mas, muito provavelmente, o ICMP será fechado e isso não acontecerá. Portanto, simplesmente tentamos, por exemplo, três vezes enviar um pacote de um determinado tamanho em algum intervalo. Se não atingir, acreditamos que o MTU foi excedido e o reduzimos ainda mais.

Assim, tendo o MTU da interface da Internet que está no dispositivo e algum MTU mínimo, simplesmente selecionamos o MTU correto por pesquisa unidimensional. Depois disso, ajustamos o tamanho do pacote no protocolo.

De fato, às vezes muda. Ficamos surpresos, mas no processo de troca de Wi-Fi, etc. MTU está mudando. É melhor não parar esse processo paralelo e corrigir o MTU de tempos em tempos.



Maior distribuição de MTU no mundo. Temos cerca de 1100 bytes no portal.

Criptografia

Dissemos que desejamos gerenciar opcionalmente a criptografia. Nós fazemos a opção mais simples - Diffie-Hellman em curvas elípticas. Fazemos isso opcionalmente - criptografamos apenas os pacotes de controle e os cabeçalhos para que o homem do meio não possa receber a chave de transmissão, interceptá-la e assim por diante.



Se a transmissão for privada, também podemos adicionar a criptografia de todos os dados.

Os pacotes são criptografados com o AES-256 de forma independente, para que a queda de pacotes não afete a criptografia adicional de pacotes.

Priorização

Lembre-se, queríamos mais priorização do protocolo.



Temos metadados, quadros de áudio e vídeo, enviamos com sucesso para a rede. Então nossa rede queima no inferno e por um longo tempo não funciona - entendemos que precisamos descartar pacotes.

Principalmente descartamos pacotes de vídeo, depois tentamos eliminar o áudio e nunca tocamos nos pacotes de controle, porque dados como alterações de resolução e outros problemas importantes podem passar por eles.

Bun adicional sobre UDP

Se você escrever seu protocolo UDP, por exemplo, com comunicação bidirecional, precisará entender que há NAT Unbinding e a chance de não encontrar o cliente de volta no servidor.



No slide, há momentos em que não foi possível acessar o cliente a partir do servidor via UDP.

Muitos céticos dizem que os roteadores são projetados de tal maneira que o NAT Unbinding exclui principalmente as rotas UDP. Mas o exposto acima mostra que se o Keep-Alive ou o ping tiver menos de 30 segundos, com uma probabilidade de 99%, será possível alcançar o cliente.

Disponibilidade de UDP em dispositivos móveis no mundo

O Google diz 6%, mas descobriu-se que 7% dos usuários móveis não podem usar UDP . Nesse caso, deixamos nosso lindo protocolo com priorização, criptografia e tudo, apenas no TCP.

No UDP, o VOIP agora funciona no WebRTC, no Google QUIC e muitos jogos funcionam no UDP. Portanto, eu não acreditaria que o UDP será fechado em dispositivos móveis.

Como resultado, nós:

• Reduzido o atraso entre a serpentina e o observador para 1 s.
  
• Nos livramos do efeito cumulativo nos buffers, ou seja, a transmissão não fica para trás.
  
• O número de barracas na platéia diminuiu .
  
• Eles foram capazes de suportar o streaming em dispositivos móveis FullHD.
  

• O atraso em nosso aplicativo móvel OK Live é 25 ms - 10 ms a mais do que o scanner da câmera funciona, mas não é tão assustador.
  
• Webcasting mostra um atraso de apenas 690 ms - espaço!
  

O que mais pode transmitir no Odnoklassniki

• Aceita nosso protocolo OKMP de dispositivos móveis;
  
• pode aceitar RTMP e WebRTC;
  
• fornece HLS, MPEG-Dash, etc.
  

Se você tomou cuidado, percebeu que eu disse que podemos pegar, por exemplo, o WebRTC do usuário e convertê-lo em RTMP.



Há uma nuance. De fato, o WebRTC é um protocolo orientado a pacotes e usa o codec de áudio OPUS. Você não pode usar o OPUS no RTMP.

Em servidores back-end, usamos RTMP em qualquer lugar. Portanto, tivemos que fazer mais algumas correções no FF MPEG, o que nos permite inserir o OPUS no RTMP, convertê-lo em AAC e fornecê-lo aos usuários que já estão no HLS ou em qualquer outra coisa.

Como é dentro de nós?

• Usuários que usam um dos protocolos carregam o vídeo original em nosso servidor de upload.
  
• Lá, implantamos o protocolo.
  
• Enviamos RTMP para um dos servidores de transformação de vídeo.
  
• O original é sempre armazenado em um armazenamento distribuído para que nada se perca.
  
• Depois disso, todos os vídeos vão para o servidor de distribuição.
  

Para ferro, temos o seguinte:


Vou falar um pouco mais sobre a tolerância a falhas:

• Os servidores de upload são distribuídos em diferentes datacenters, protegendo IPs diferentes.
  
• Os usuários vêm, recebem IP no DNS.
  
• O servidor de upload envia o vídeo para os servidores de fatia, eles cortam e dão aos servidores de distribuição.
  
• Para transmissões mais populares, começamos a adicionar um número maior de servidores de distribuição.
  
• Salvamos tudo o que veio do usuário no repositório, para que mais tarde possamos criar um arquivo de transmissão e não perder nada.
  
• Armazenamento tolerante a falhas distribuído por três data centers.
  

Para determinar qual servidor é atualmente responsável pela tradução, usamos o ZooKeeper . Para cada tradução, armazenamos um nó e fazemos nós efêmeros para cada servidor. De fato, isso permite que um fluxo crie uma fila de servidores que serão processados. Sempre o líder atual nesta linha está envolvido no processamento de fluxo.

Testaremos a tolerância a falhas rapidamente. Começamos imediatamente com o desaparecimento de todo o data center.

O que vai acontecer?

• O usuário DNS receberá o próximo IP de outro servidor de upload.
  
• A essa altura, o ZooKeeper entenderá que o servidor nesse data center morreu e selecionará o servidor de fatiamento para outro.
  
• Os servidores de download descobrirão quem agora é responsável pela transformação desse fluxo e o distribuirão.
  

Em princípio, tudo isso acontecerá com atrasos mínimos.

Usando o protocolo no produto

Criamos o aplicativo móvel de transmissão ao vivo OK. Está totalmente integrado ao portal. Os usuários podem se comunicar, realizar transmissões ao vivo, há um mapa de transmissões, uma lista de transmissões populares - em geral, tudo o que você deseja.



Também adicionamos a capacidade de transmitir em FullHD. Você pode conectar uma câmera de ação no Android a um dispositivo Android.



Agora, temos um mecanismo que permite transmissões ao vivo. Por exemplo, traçamos uma linha direta com o presidente por meio do OK Live e a transmitimos para todo o país . Os usuários assistiram e, através do fluxo que se aproximava, podiam entrar no ar e fazer suas perguntas.

Isto é, de fato, dois fluxos que se aproximam com um atraso mínimo fornecem um certo formato de conferência pública.

De fato, nos encontramos em algum lugar em 2 segundos - um segundo lá e um segundo atrás. Lembre-se do “carrinho” de que falei no início do artigo - agora parece dois caminhões enormes. Para transmissão de TV, remover da câmera e misturar tudo com um atraso de cerca de 1-2 s é completamente normal.

De fato, conseguimos reproduzir algo comparável ao atual TCP moderno.



As transmissões ao vivo são a tendência atual. No último ano e meio, no portal OK, eles triplicaram (não sem a ajuda do aplicativo OK Live).



Todas as transmissões são gravadas por padrão. Temos cerca de 50 mil fluxos por dia, isso gera cerca de 17 terabytes de tráfego por dia, mas, em geral, todo o vídeo no portal gera cerca de um petabyte de dados por mês.



O que conseguimos:

• Poderia garantir a duração do atraso entre a serpentina e o público.
  
• Criamos o primeiro aplicativo móvel FullHD para streaming em um canal de Internet móvel que muda dinamicamente.
  
• Tivemos a oportunidade de perder data centers e, ao mesmo tempo, não interromper a transmissão
  

O que você aprendeu:

• O que é vídeo e como transmiti-lo.
  
• Você pode escrever seu protocolo UDP se tiver certeza de que possui uma tarefa muito específica e usuários específicos.
  
• Sobre a arquitetura de qualquer serviço de streaming - o vídeo entra na entrada, converte e sai.
  

Na Highload ++ Siberia, Alexander Tobol promete falar sobre o serviço de chamada OK, será interessante saber o que foi aplicado a partir do que foi discutido neste artigo e o que teve que ser implementado completamente novamente.

Na mesma seção, são planejados relatórios sobre tópicos altamente especializados:

• Eugene Rossinsky (ivi) no sistema para coletar estatísticas detalhadas sobre a operação dos nós CDN.
  
• Anton Rusakova (Badoo) sobre a integração de sistemas de pagamento sem usar seu próprio faturamento.