Boas tardes a todos os usuarios de Habra.
Leo constantemente artigos sobre Habré sobre o desenvolvemento desta ou aquela funcionalidade en Malinka. Decidín compartir aquí o meu traballo.
prehistoria
Traballo para unha empresa que ofrece servizos de televisión por cable e acceso a Internet. E, como ocorre neste tipo de empresas, periódicamente escoito queixas sobre a incoherencia do plan tarifario co que consta no contrato. Ou o usuario quéixase da baixa velocidade "por cable", despois dos pings altos de determinados servizos, ás veces da completa ausencia de Internet a determinadas horas do día. Moitas veces, este tipo de queixas acaban nun conxunto de solicitudes, en función das cales un dos empregados vai "in situ" cun portátil que funciona, no que se toman todas as medicións. E, moitas veces, resulta que todo está ben coa velocidade. E a baixa velocidade é en realidade nun teléfono móbil, a través de wi-fi, no balcón. Ben, ou algo semellante.
Desafortunadamente, non é posible acudir a un abonado, por exemplo, ás 21:37, cando ten as velocidades máis baixas. Despois de todo, o horario de traballo dos empregados é limitado. A substitución do enrutador non ten ningún efecto, porque... O rango de frecuencias para wi-fi no noso país está lamentablemente desordenado.
Para o rexistro — o fornecedor estatal da República de Bielorrusia activa o wi-fi en todos os dispositivos previstos para o seu uso e transmite o SSID ByFly desde cada dispositivo. Aínda que o abonado non teña servizo de Internet, senón só un teléfono doméstico. Isto fíxose para vendas adicionais. Podes mercar unha tarxeta deste operador nun quiosco, conectarte a calquera punto chamado ByFly e, introducindo os datos da tarxeta, recibir servizos de Internet. Dada a cobertura case do 100% das cidades e unha importante cobertura do sector privado e das zonas rurais, atopar un punto de conexión non é un problema.
As observacións das nosas canles de comunicación externas mostran que existe unha reserva de ancho de banda determinada. E os subscritores non consumen as canles dispoñibles en total, nin sequera nas horas punta. Estamos moi serios con isto. O uso de diferentes servizos e diferentes servidores de medición de velocidade levou a resultados interesantes. Resulta que non todos os servizos son igualmente útiles... Sobre todo polas noites. E definitivamente non debes confiar neles. Moitos operadores da mesma rede de Ookla non teñen canles de comunicación amplas ou traballan adosado. Isto significa que á noite é case imposible obter un resultado honesto. Si, e as autoestradas resultan pecaminosas. Por exemplo, os intentos de medir a velocidade en Xapón mostran resultados extremadamente desastrosos...
Decisión primaria
A foto é só para fins ilustrativos.
Desplegáronse dous servidores de control de velocidade. O primeiro é , o segundo - . Comparouse o rendemento de ambos os servizos. Despois de todo, decidimos parar en Ookla porque... ata o 90% dos subscritores utilizan este servizo.
A continuación, escribíronse instrucións para usuarios e empregados sobre como medir as velocidades dentro e fóra da rede. Eses. Cando comeza a proba, por defecto mídese a velocidade dentro da rede. O servidor está situado na nosa cabeceira e a solución Ookla selecciona por defecto o servidor máis próximo ao subscritor. Deste xeito comprobamos o funcionamento da nosa propia rede de transmisión de datos.
Para medir a velocidade dentro do país (temos unha rede separada para operadores de telecomunicacións, que une a todos os operadores e os principais centros de datos do país), cómpre seleccionar un provedor dentro do país e realizar unha segunda medición. Identificamos empíricamente varios servidores que dan resultados máis ou menos estables a calquera hora do día e enumerámolos segundo se recomenda nas instrucións.
Pois accións similares para as canles de comunicación externas. Atopamos grandes operadores con grandes canles en servidores speedtest e escribiunos en recomendacións (perdón "Moskva - Rostelecom" e "Riga - Baltcom", pero recomendarei estes nodos para obter números adecuados. Persoalmente, recibín ata ~870 megabits de estes servidores durante as horas punta).
Por que, pregunta, tales dificultades? Todo é moi sinxelo. Recibimos unha ferramenta bastante cómoda que, en mans capaces, permite determinar se hai problemas nas nosas redes, se hai problemas na rede republicana ou se hai problemas coa columna vertebral. Se unha persoa se queixa da baixa velocidade de descarga dalgún servizo, podemos medir a velocidade da canle do abonado e despois comparala co que recibe do servizo. E é razoable demostrar que asignamos honestamente a canle especificada no contrato. Tamén podemos explicar as posibles razóns de tal diferenza de velocidades.
Solución secundaria
A cuestión da baixada de velocidade polas noites/durante o día segue aberta. Como facer o mesmo sen estar na casa do abonado? Colle unha tarxeta barata dunha placa única cunha rede gigabit e fai unha chamada sonda. O dispositivo debe tomar medidas de velocidade ao longo do cable nun intervalo de tempo determinado. A solución debe ser de código aberto, o máis sen pretensións posible, cun panel de administración conveniente para ver os resultados das medicións. O dispositivo debe ser o máis barato posible para poder substituílo facilmente e deixalo ao abonado durante n días sen medo.
Implantación
Tomouse como base BananaPI (modelo M1). En realidade, hai dúas razóns para esta elección.
- Porto Gigabit.
- Estaba só tirado na mesiña de noite.
A continuación, decidiuse usar o cliente Python para o servizo Speedtest by Ookla como backend para medir a velocidade. Biblioteca para medir a velocidade de ping. Ben, e php para o panel de administración. Para facilitar a percepción usei .
Debido ao feito de que os recursos de Raspberry non son flexibles, utilizouse a combinación nginx+php-fpm+sqlite3. Quería renunciar a MySQL pola súa pesadez e redundancia. Previo unha pregunta sobre Iperf. Houbo que abandonalo ante a imposibilidade de utilizalo en direccións distintas ás locais.
Inicialmente seguín o camiño de moitos neste sitio. Modificouse o cliente speedtest-cli. Pero despois, despois de pensalo un pouco, abandonou esta idea. Escribín ao meu propio traballador que utiliza as capacidades do cliente orixinal.
Para analizar os pings, simplemente escribín un controlador separado. Tomamos o valor medio da medición. A ferramenta de ping pode xestionar tanto o enderezo IP como o nome de dominio.
Non conseguín traballo asíncrono. Non é especialmente necesario neste caso.
O panel de administración para avaliar os resultados resultou ser bastante minimalista.
Fig Fiestra de administración principal cos resultados das probas
Fig Configuración de proba
Fig Actualiza a lista de servidores Speedtest
Iso é todo. A idea púxose en práctica nos meus xeonllos, no meu tempo libre. As probas de campo aínda non comezaron. Pero temos previsto lanzar prototipos nun futuro próximo. Pode ser usado tanto polos provedores alí como polos clientes dos provedores. Ninguén che molesta en tomar medidas na casa durante todo o día. O único que debes lembrar é que se navegas activamente por Internet ou descargas algo, entón a medida será inferior á real. Polo tanto, o ideal é deixar a sonda na rede como único consumidor de tráfico.
PD: non me critiques pola calidade do código. Son autodidacta sen experiencia. Código fonte para . Acéptanse as críticas.
Fonte: www.habr.com