Consultoria de arquitetura - acesso remoto à câmera web [fechada]

Question

Estou à procura de conselhos arquitetônicos. Eu tenho um cliente que eu construí um site para o qual essencialmente permite aos usuários visualizar suas câmeras web remotamente.

O fluxo atual de dados é o seguinte:

O usuário abre a página para visualizar a imagem da câmera da web. Script JavaScript pesquisa url no servidor (anexado com timestamp exclusivo) a cada 1000 ms

A conexão FTP está habilitada para o usuário FTP da câmera. Câmara Web abre conexão ftp ao servidor. A webcam começa a tirar fotos. Câmara Web envia foto para o servidor ftp.

No pedido de URL de imagem:   Servidor lê a última imagem no disco rígido enviado via ftp para a câmera.   O servidor excluiu todas as imagens antigas do servidor.

Isso está funcionando bem no momento para uma pequena quantidade de usuários / câmeras (cerca de 10 usuários e aproximadamente a mesma quantidade de câmeras), mas estamos começando a nos preocupar com a escalabilidade dessa abordagem.

Meu plano original era em vez de ter os arquivos lidos no servidor, o servidor web abriria uma conexão ftp para o servidor web e leria as últimas imagens diretamente de lá, o que significa que deveríamos escalar horizontalmente com facilidade. Mas os tempos de estabelecimento da conexão ftp eram muito lentos (principalmente devido ao fato de que o PHP fora do boi não consegue manter conexões ftp) e então abandonamos essa abordagem e fomos direto para a leitura do disco rígido.

O provedor de firmware para as câmeras afirma que é possível criar um cliente http que, em vez de usar o ftp para fazer o upload da imagem, pode postar a imagem em um servidor da web. Isso parece bastante plausível para mim, mas estou procurando alguns conselhos arquitetônicos.

Meu pensamento atual é uma simples pilha Nginx / PHP / Redis.

A câmera da Web emite postagens de solicitações da última imagem para o Nginx / PHP e a última imagem para essa câmera é armazenada no Redis.

Os clientes podem então extrair a última imagem do Redis, que deve ser extremamente rápida, pois as imagens sempre serão armazenadas na memória.

O fluxo de dados se tornaria:

O usuário abre a página para visualizar a imagem da câmera da web. Script JavaScript pesquisa url no servidor (anexado com timestamp exclusivo) a cada 1000 ms

A câmera envia uma solicitação http para começar a postar imagens em um URL fornecido A webcam começa a tirar fotos. Câmara Web envia pedidos de mensagens para o servidor o mais rapidamente possível

No pedido de URL de imagem:   Servidor lê a última imagem do redis   Servidor informa ao redis para apagar a imagem posterior

Minhas perguntas são:

1. Existe alguma sobrecarga maior na transferência de imagens via HTTP em vez de FTP?
2. Existe uma maneira simples de calcular quantas câmeras em potencial poderíamos ter streaming de uma só vez?
3. Existe alguma maneira de impedir que os nossos próprios servidores do DOS atinjam solicitações de câmeras da Web?
4. Redis é uma boa solução para esse problema?
5. Devo abandonar a combinação PHP / Ngix e ir para outra coisa?
6. A solução proposta é realmente boa?
7. A adição de HTTPs ao mix fará com que postar a imagem fique muito lenta?

Obrigado antecipadamente

Alan

    

Answer 1

Are there any greater overheads of transferring images via HTTP instead of FTP?

Não realmente. O HTTP é mais fácil de acelerar e armazenar em cache do que o FTP.

Is there a simple way to calculate how many potential cameras we could have streaming at once?

Um único fluxo MPEG4 a 1080p é de cerca de 10Mbit. Essa é uma figura de estimativa. Você deve ser capaz de redimensionar isso de volta à sua resolução real.

Is there any way to prevent potentially DOS'ing our own servers due to web camera requests?

Escale para fora. Há um bom proxy MJPEG do Node.js que usei no passado, que é melhor do que o vídeo onboard de uma câmera servidor.

Is Redis a good solution to this problem?

Provavelmente tão bom quanto qualquer outro. YMMV. Faça alguns testes.

Should I abandoned PHP/Nginx combination and go for something else?

Fique com o que você está confortável.

Is this proposed solution actually any good?

Parece plausível, enquanto se aguarda alguns testes de prova de conceito e benchmarking

Will adding HTTPS to the mix cause posting the image to become too slow?

Possivelmente um pouco, mas provavelmente não em um grau notável. Mais uma vez, você precisará fazer alguns testes. Provavelmente, você pode ter um proxy reverso separado para encerrar as conexões SSL e, dessa forma, poder ter HTTPS para acessar as imagens, mas os uploads não ocorrem via HTTPS (se for o que você deseja).

Há também alguns Cartões aceleradores HTTPS você pode obter servidores reais.