1. Quem precisa de WebRTC do lado do servidor?
Como todos sabemos, WebRTC é uma tecnologia ponto a ponto que implementa um canal de comunicação entre dois navegadores para transferir áudio, vídeo e quaisquer outros dados com baixa latência. A tecnologia é totalmente gratuita e se seu aplicativo precisar estabelecer comunicação em navegadores para dois participantes remotos, você pode adicionar o código javascript apropriado às páginas da web e o problema será resolvido. Os navegadores se comunicarão diretamente, nenhum servidor é necessário.
O WebRTC do lado do servidor entra em cena quando é necessário que haja mais de dois participantes, e os dados de um participante são transmitidos a vários outros participantes de uma vez.
Nesse caso, um dos participantes pode ser um servidor que estabelecerá comunicação um a um com o primeiro participante, receberá os dados dele, em seguida, estabelecerá a comunicação, também em modo
um a um com os outros participantes e enviará esses dados. Essa. o servidor mantém muitos canais de comunicação ponto a ponto e simplesmente copia os dados para todos esses canais. Na terminologia WebRTC, esse servidor serve como uma Unidade de encaminhamento seletivo (SFU).
No entanto, a comunicação em grupo não é possível apenas com o SFU. Você pode perguntar por que nem todos podem enviar dados para todos, sem nenhum servidor, e acertará em cheio Isso é chamado de MESH - comunicação.
Existem dois pontos principais aqui:
- No esquema MESH, cada participante envia e recebe N-1 fluxos de dados, onde N é o tamanho do grupo. Essa. os requisitos de velocidade de upload para cada participante no esquema MESH aumentam com o crescimento do grupo. Enquanto no esquema SFU, cada participante sempre envia apenas um fluxo. Nem todo participante tem uma velocidade de conexão de rede que pode enviar N-1 streams.
- , MESH - . , , - . MESH , , VP8/VP9/H264 4 . WebRTC – , . , (PeerConnection). , 720p 30% , . .
Por causa desses dois pontos-chave, o esquema MESH torna-se mal implementado com um número crescente de participantes e o esquema SFU tem que ser usado.
Portanto, com um grande número de participantes de comunicação, um servidor (SFU) é necessário.
Vamos dar exemplos de tais aplicativos em que um servidor é necessário:
- Videoconferências com muitos participantes (o adorado Zoom de todos usa o servidor WebRTC, como todos os serviços semelhantes).
- Vigilância por vídeo ao vivo, quando o vídeo é enviado de uma câmera para vários visualizadores e dispositivos de gravação. Sistemas de segurança, monitoramento.
- Sistemas interativos, como leilões online, tutoriais e outros aplicativos da web que exigem baixa latência de áudio / vídeo.
2. Se você ainda precisa de WebRTC do lado do servidor, o que pode usar em 2020?
Serviço na nuvem ou por conta própria?
Aqui, em primeiro lugar, os argumentos usuais de TI a favor de um ou de outro: a nuvem fornecerá e economizará custos de TI com servidores, configuração, escalabilidade. Mas sozinho, se tudo der certo (não há garantia), será muito mais barato. Afinal, você precisa pagar mensalmente por um serviço na nuvem.
Agora, para os argumentos específicos para os aplicativos descritos acima. Se você tem um grande público global, em diferentes países e regiões, será difícil para você juntar tudo sozinho. Por exemplo, um serviço em nuvem é adequado para um leilão da Sotheby's. Mas se você tiver 2-3 filiais da empresa em cidades diferentes, 200-500 usuários, e precisar organizar um webinar / conferência / treinamento, etc. para eles, você pode alugar vários servidores na AWS ou plataformas de hospedagem semelhantes, instalar lá servidor WebRTC do software, e tudo funcionará. Os servidores podem até estar na sua empresa, se a velocidade da conexão à Internet permitir. Bem, para todas as soluções de menor escala, tudo pode ser feito por conta própria.
Atualmente, dois serviços WebRTC em nuvem são bem conhecidos e testados: Millicast e Phenix... Ambos têm cobertura global, boa conectividade entre servidores em continentes diferentes (você precisa?) E, de fato, latência de vídeo (latência) de meio segundo ou menos.
Agora vamos falar sobre “por nossa conta”.
Você precisará do software do servidor WebRTC aqui. Existem 3 maneiras de obter esse servidor.
- Faça você mesmo usando uma API aberta. O mais famoso deles é o Google c ++ WebRTC API . Você também pode usar a API GStreamer . Uma implementação interessante em Go: Pion WebRTC . Você precisará de programadores C ++ habilidosos e de muita paciência e tempo para depurar. Eu escrevi em detalhes sobre as dificuldades dessa abordagem em meu artigo anterior .
- . Ant Media Server, Kurento, Janus, Jitsi. , , , . github , . , , , . , c++ . . , .
- . , , . Red5 Pro, Flashphoner Unreal Media Server.
WebRTC .
Este é o tópico mais problemático. Suponha que sua empresa esteja lançando um produto de software no qual você precise implementar um servidor WebRTC. Que seja um sistema de gravação e vigilância de vídeo para terminais de aeroportos, estações ferroviárias, centros de transporte. Ou equipamento médico com o software já existente para transmitir e gravar vídeo de endoscópios, que precisa ser expandido antes de transmitir este vídeo para um navegador. Ou um sistema de simulação de vôo, no qual é necessário implementar a possibilidade de visualização em um navegador e / ou interação com um usuário remoto. Somos constantemente confrontados com requisitos semelhantes. Seu sistema existente tem muitas limitações. O acesso à Internet pode não estar disponível. Ausência de nuvens. Você não pode abrir portas no servidor. Apenas Windows ou Linux apenas. Às vezes, até mesmo apenas uma determinada versão do Windows, porque o produto existente é aprimorado para isso. Servidor WebRTC,o que é adicionado a tal sistema deve ser ajustado a todas essas restrições.
Aqui, você pode não ter escolha a não ser pegar um servidor de código aberto como o Ant Media Server ou Janus e alterá-lo. Esta é a situação no Linux. Para Windows, o Unreal Media Server é adequado - este é um software escrito e otimizado apenas para o sistema operacional Windows.
O servidor WebRTC consome muitos recursos
Lembre-se disso ao planejar seus recursos. As razões para tal intensidade de recursos são descritas por mim em um artigo anterior , mas a conclusão é que a escalabilidade é alcançada por um processador muito forte ou pela adição de servidores físicos.
Aqui está um diagrama de testes realizados com Unreal Media Server v13.0 na instância AWS EC2 m4.2xlarge: Intel Xeon 8 núcleos CPU E5-2686 v4 @ 2,30 GHz, 32 Gb RAM, Windows Server 2016.
Como você pode ver no diagrama, com 1000 jogadores da web simultâneos para esta câmera IP , a carga do processador é de 5% com o protocolo RTMP e 75% com o protocolo WebRTC, ou seja, O WebRTC consome mais de 10 vezes mais recursos do que o RTMP.