Buenas tardes a todos los usuarios de habra.
Constantemente leo artículos sobre Habré sobre el desarrollo de esta o aquella funcionalidad en el "Malinka". Decidí compartir mi trabajo aquí.
Antecedentes
Trabajo en una empresa que brinda servicios de televisión por cable y acceso a Internet. Y, como es el caso en tales compañías, escucho periódicamente quejas sobre la inconsistencia del plan tarifario con el establecido en el contrato. Ahora el usuario se queja de la baja velocidad "por cable", luego de los altos pings de ciertos servicios, a veces de la ausencia total de Internet en un momento determinado del día. A menudo, tales quejas terminan en el conjunto de aplicaciones, según el cual uno de los empleados con una computadora portátil en funcionamiento, en el que se realizan todas las mediciones, se envía al sitio. Y, a menudo, resulta que todo está en orden con rapidez. Y la baja velocidad es en realidad en un teléfono móvil, a través de wi-fi, en el balcón. Bueno, o algo así.
Desafortunadamente, es imposible ir al suscriptor, por ejemplo, a las 21:37, cuando tiene las velocidades más bajas. Aún así, la jornada laboral de los empleados es limitada. Reemplazar el enrutador no tiene ningún efecto. El rango de frecuencia para wi-fi en nuestro país está desordenadamente desordenado.
Como referencia : el proveedor estatal en la República de Bielorrusia enciende por la fuerza el wifi en todos los dispositivos provistos para su uso y transmite el SSID ByFly desde cada dispositivo. Incluso si el suscriptor no tiene un servicio de Internet, sino solo un teléfono residencial. Esto se hace para ventas adicionales. Puede comprar una tarjeta de este operador en un puesto, conectarse a cualquier punto con el nombre ByFly y, al ingresar datos de la tarjeta, recibir servicios de Internet. Teniendo en cuenta casi el 100% de cobertura de las ciudades y una cobertura significativa del sector privado y los asentamientos rurales, encontrar un punto de conexión no es un problema.
Observar nuestros canales de comunicación externos muestra que hay una reserva de ancho de banda dada. Y los suscriptores en total no consumen los canales disponibles, incluso durante las horas pico. Con esto todos somos muy serios. El uso de diferentes servicios y diferentes servidores para medir la velocidad ha dado resultados interesantes. Resulta que no todos los servicios son igualmente útiles ... Especialmente por las tardes. Y no debes confiar en ellos sin ambigüedades. Muchos operadores de la misma red Ookla no tienen canales de comunicación amplios, o trabajan de extremo a extremo. Esto significa que a menudo es casi imposible obtener un resultado honesto por la noche. Y las carreteras están pecando. Por ejemplo, los intentos de medir la velocidad en Japón muestran resultados extremadamente deplorables ...
Solución primaria
Foto con fines ilustrativos
Se implementaron dos servidores de control de velocidad. El primero es LibreSpeed , el segundo es el Speedtest de OOKLA . Se comparó el desempeño de ambos servicios. Decidimos parar en Ookla. Hasta el 90% de los suscriptores utilizan este servicio en particular.
A continuación, se escribieron instrucciones para usuarios y empleados sobre cómo medir la velocidad dentro y fuera de la red. Aquellos. Al iniciar la prueba, la velocidad se mide dentro de la red de forma predeterminada. El servidor está ubicado en nuestra estación central, y la solución Ookla, por defecto, selecciona el servidor más cercano al suscriptor. Por lo tanto, verificamos el funcionamiento de nuestra propia red de transmisión de datos.
Para medir la velocidad dentro del país (tenemos una red separada para operadores de telecomunicaciones, que une a todos los operadores y los principales centros de datos dentro del país), debe seleccionar un proveedor dentro del país y volver a medir. Identificamos empíricamente varios servidores que dan resultados más o menos estables en cualquier momento del día y los prescribimos como se recomienda en las instrucciones.
Bueno, acciones similares para canales de comunicación externos. Encontramos operadores grandes con canales grandes en servidores de prueba rápida y los escribimos en recomendaciones (perdone Moskva - Rostelecom y Riga - Baltcom, pero recomendaré estos nodos para obtener números adecuados. Personalmente, recibí hasta ~ 870 megabits de estos servidores durante las horas pico).
¿Por qué, preguntas, son tales dificultades? Todo es muy simple. Hemos recibido una herramienta bastante conveniente que, en manos capaces, nos permite determinar: ¿hay algún problema en nuestras redes, hay problemas en la red republicana, hay problemas con el enlace troncal? Si una persona se queja de una baja velocidad de descarga de algún servicio, podemos medir la velocidad del canal del suscriptor y luego compararlo con lo que recibe del servicio. Y se argumenta que demuestra que estamos destacando honestamente el canal prescrito en el contrato. Y también podemos explicar las posibles razones de tal diferencia en la velocidad.
Solución secundaria
La cuestión de la caída de velocidad en las tardes / durante el día permanece abierta. ¿Cómo hacer lo mismo sin estar en la casa del suscriptor? Tome una placa única barata con una red gigabit y haga una llamada sonda con ella. El dispositivo debe tomar medidas de velocidad a través del cable en un intervalo de tiempo especificado. La solución debe ser de código abierto, lo más sencilla posible, con un panel de administración conveniente para ver los resultados de la medición. El dispositivo debe ser lo más barato posible para que pueda ser reemplazado fácilmente y dejado al suscriptor durante n días sin temor.
Implementación
Se tomó como base BananaPI (modelo M1). En realidad, hay dos razones para elegir.
- Puerto Gigabit.
- Él solo estaba acostado en la mesita de noche.
A continuación, se decidió utilizar el cliente speedtest-cli python para el servicio Speedtest by Ookla como back-end para medir la velocidad. Biblioteca de Python para medir la velocidad del ping. Bueno, y php para el área de administración. Por conveniencia, usé bootstrap .
Debido al hecho de que los recursos de frambuesa no son de goma, se utilizó un montón de nginx + php-fpm + sqlite3. Queríamos abandonar MySQL debido a su gran peso y redundancia. Anticipando una pregunta sobre Iperf. Tuvo que ser abandonado debido a la imposibilidad de usarlo en direcciones distintas a las locales.
Inicialmente seguí el camino de muchos en este sitio. Modificado el cliente speedtest-cli. Pero luego, después de una pequeña reflexión, abandonó la idea. Escribí a mi propio trabajador que usa las capacidades del cliente original.
Para analizar pings, simplemente escribí un controlador separado. Tomamos el valor promedio por medición. Pingovalka conoce una dirección IP y un nombre de dominio.
No logré trabajo asincrónico. Ella no es particularmente necesaria en este caso.
El panel de administración para evaluar los resultados resultó ser bastante minimalista.
Higo. Actualización de la lista de servidores Speedtest
Eso es todo. La idea se realizó en la rodilla, en el tiempo libre del trabajo. Las pruebas de campo aún no han comenzado. Pero planeamos lanzar prototipos en el futuro cercano. Puede utilizar tanto proveedores allí como clientes de proveedores. Nadie se molesta en poner medidas en casa durante todo el día. Lo único que debe recordar es que si está navegando activamente por la red o descargando algo, la medición será más baja que la real. Entonces, idealmente, la sonda debe dejarse en la red como el único consumidor de tráfico.
PD: no patees por la calidad del código. Soy autodidacta sin experiencia. Código fuente en GitHub . La crítica es aceptada.