Boa tarde a todos os usuários habra.
Eu sempre leio artigos sobre Habré sobre o desenvolvimento desta ou daquela funcionalidade no "Malinka". Eu decidi compartilhar meu trabalho aqui.
fundo
Eu trabalho em uma empresa que fornece serviços de TV a cabo e acesso à Internet. E, como é o caso nessas empresas, ouço periodicamente reclamações sobre a inconsistência do plano tarifário com o declarado no contrato. Agora, o usuário reclama da baixa velocidade "sobre o cabo", depois dos altos pings de certos serviços, às vezes da completa ausência da Internet em uma determinada hora do dia. Freqüentemente, essas reclamações acabam no pool de aplicativos, segundo o qual um dos funcionários com um laptop em funcionamento, no qual todas as medições são feitas, é enviado ao site. E, frequentemente, acontece que tudo está em ordem com velocidade. E a baixa velocidade está realmente em um telefone celular, via wi-fi, na varanda. Bem, ou algo assim.
Infelizmente, é impossível ir ao assinante, por exemplo, às 21:37, quando ele tem as velocidades mais baixas. Ainda assim, o dia de trabalho dos funcionários é limitado. A substituição do roteador não tem efeito. a faixa de frequência do wi-fi em nosso país é deplorável.
Para referência - o provedor estatal na República da Bielorrússia ativa o wi-fi em todos os dispositivos fornecidos para uso e transmite o SSID ByFly de cada dispositivo. Mesmo se o assinante não tiver um serviço de Internet, mas apenas um telefone residencial. Isso é feito para vendas adicionais. Você pode comprar um cartão desse operador em uma barraca, conectar-se a qualquer ponto com o nome ByFly e, inserindo dados no cartão, receber serviços de Internet. Considerando quase 100% de cobertura das cidades e significativa cobertura do setor privado e assentamentos rurais, encontrar um ponto de conexão não é um problema.
Observar nossos canais de comunicação externos mostra que existe uma determinada reserva de largura de banda. E os assinantes no total não consomem os canais disponíveis, mesmo na hora do rush. Com isso, somos todos muito sérios. O uso de diferentes serviços e servidores diferentes para medir a velocidade levou a resultados interessantes. Acontece que nem todos os serviços são igualmente úteis ... Especialmente à noite. E você não deve confiar neles sem ambiguidade. Muitos operadores da mesma rede Ookla não possuem canais de comunicação amplos ou trabalham de ponta a ponta. Isso significa que muitas vezes é quase impossível obter um resultado honesto à noite. E as estradas estão pecando. Por exemplo, as tentativas de medir a velocidade no Japão mostram resultados extremamente deploráveis ...
Solução primária
Foto para fins ilustrativos
Dois servidores de controle de velocidade foram implantados. O primeiro é o LibreSpeed , o segundo é o Speedtest da OOKLA . O desempenho de ambos os serviços foi comparado. Decidimos parar em Ookla. até 90% dos assinantes usam esse serviço específico.
Em seguida, foram escritas instruções para usuários e funcionários sobre como medir a velocidade dentro e fora da rede. Essa. ao iniciar o teste, a velocidade é medida na rede por padrão. O servidor está localizado em nossa estação principal e a solução Ookla, por padrão, seleciona o servidor mais próximo do assinante. Assim, verificamos o funcionamento de nossa própria rede de transmissão de dados.
Para medir a velocidade no país (temos uma rede separada para operadoras de telecomunicações, que une todas as operadoras e os principais datacenters do país), você precisa selecionar um provedor no país e medir novamente. Identificamos empiricamente vários servidores que fornecem resultados mais ou menos estáveis a qualquer hora do dia e os prescrevemos conforme recomendado nas instruções.
Bem, ações semelhantes para canais de comunicação externos. Encontramos grandes operadores com grandes canais nos servidores speedtest e os escrevemos nas recomendações (perdoe Moskva - Rostelecom e Riga - Baltcom, mas eu recomendarei esses nós para obter números adequados. Pessoalmente, recebi até ~ 870 megabits desses servidores durante o horário de pico).
Por que, você pergunta, são essas dificuldades? Tudo é muito simples. Recebemos uma ferramenta bastante conveniente que, em mãos capazes, nos permite determinar: há algum problema em nossas redes, há problemas na rede republicana, há problemas com o tronco. Se uma pessoa se queixar de uma baixa velocidade de download de algum serviço, podemos medir a velocidade do canal do assinante e comparar com o que ele recebe do serviço. E argumenta-se que mostre que estamos honestamente destacando o canal prescrito no contrato. E também podemos explicar as possíveis razões para essa diferença de velocidade.
Solução secundária
A questão da queda de velocidade à noite / durante o dia permanece em aberto. Como fazer o mesmo sem estar na casa do assinante? Pegue uma placa única barata com uma rede de gigabit e faça dela uma sonda. O dispositivo deve fazer medições de velocidade através do cabo em um intervalo de tempo especificado. A solução deve ser de código aberto, o mais despretensioso possível, com um painel de administração conveniente para visualizar os resultados da medição. O dispositivo deve ser o mais barato possível, para que possa ser facilmente substituído e deixado com o assinante por n dias sem medo.
Implementação
O BananaPI (modelo M1) foi tomado como base. Na verdade, existem duas razões para escolher.
- Porta Gigabit.
- Ele estava apenas deitado na mesa de cabeceira.
Em seguida, foi decidido usar o cliente speedtest-cli python para o serviço Speedtest by Ookla como um back-end para medir velocidade. Biblioteca de Pythonping para medir a velocidade do ping. Bem, e php para a área de administração. Por uma questão de conveniência, usei o bootstrap .
Devido ao fato de os recursos de framboesa não serem de borracha, um monte de nginx + php-fpm + sqlite3 foi usado. Queríamos abandonar o MySQL devido ao seu peso e redundância. Antecipando uma pergunta sobre o Iperf. Ele teve que ser abandonado devido à impossibilidade de usá-lo em direções diferentes das locais.
Inicialmente segui o caminho de muitos neste site. Modificado o cliente speedtest-cli. Mas então, depois de um pouco de reflexão, ele abandonou a ideia. Eu escrevi meu próprio trabalhador que usa os recursos do cliente original.
Para analisar pings, simplesmente escrevi um manipulador separado. Tomamos o valor médio por medida. Pingovalka conhece um endereço IP e um nome de domínio.
Não consegui trabalho assíncrono. Ela não é particularmente necessária neste caso.
O painel de administração para avaliar os resultados acabou sendo bastante minimalista.
FIG. Atualizando a lista de servidores Speedtest
É isso aí. A ideia foi realizada no joelho, no tempo livre do trabalho. Os testes de campo ainda não começaram. Mas planejamos lançar protótipos em um futuro próximo. Você pode usar os provedores lá e os clientes dos provedores. Ninguém se preocupa em fazer medições em casa o tempo todo. A única coisa a lembrar é que, se você estiver navegando ativamente na Internet ou baixando algo, a medição será mais baixa do que a real. Portanto, idealmente, o probe deve ser deixado na rede como o único consumidor de tráfego.
PS: por favor, não chute pela qualidade do código. Sou autodidata, sem experiência. Código fonte no GitHub . A crítica é aceita.