Buenas tardes a todos los usuarios de Habra.
Constantemente leo artículos en Habré sobre el desarrollo de tal o cual funcionalidad en Malinka. Decidí compartir mi trabajo aquí.
Prehistoria
Trabajo para una empresa que brinda servicios de televisión por cable y acceso a Internet. Y, como ocurre en este tipo de empresas, periódicamente escucho quejas sobre la inconsistencia del plan tarifario con lo establecido en el contrato. O 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 ciertos momentos del día. A menudo, estas quejas terminan en un conjunto de solicitudes, según las cuales uno de los empleados va "al lugar" con una computadora portátil en funcionamiento, en la que se toman todas las medidas. Y, a menudo, resulta que todo va bien con la velocidad. Y la baja velocidad es en realidad en un teléfono móvil, vía wifi, en el balcón. Bueno, o algo parecido.
Lamentablemente, no es posible acudir a un abonado, por ejemplo, a las 21:37, cuando tiene las velocidades más bajas. Al fin y al cabo, el horario laboral de los empleados es limitado. Reemplazar el enrutador no tiene ningún efecto, porque... La gama de frecuencias de Wi-Fi en nuestro país está lamentablemente saturada.
Para el registro — el proveedor estatal en la República de Bielorrusia activa por la fuerza la conexión Wi-Fi en todos los dispositivos previstos para su uso y transmite el SSID ByFly desde cada dispositivo. Incluso si el suscriptor no tiene servicio de Internet, sino solo un teléfono residencial. Esto se hizo para ventas adicionales. Puedes comprar una tarjeta de este operador en un quiosco, conectarte a cualquier punto denominado ByFly y, ingresando los datos de la tarjeta, recibir servicios de Internet. Dada una cobertura de casi el 100% de las ciudades y una cobertura significativa del sector privado y las áreas rurales, encontrar un punto de conexión no es un problema.
Las observaciones de nuestros canales de comunicación externos muestran que existe una determinada reserva de ancho de banda. Y los suscriptores no consumen el total de canales disponibles, ni siquiera en las horas pico. Nos tomamos esto muy en serio. El uso de diferentes servicios y diferentes servidores de medición de velocidad condujo a resultados interesantes. Resulta que no todos los servicios son igual de útiles... Especialmente por las noches. Y definitivamente no deberías confiar en ellos. Muchos operadores de la misma red de Ookla no tienen canales de comunicación amplios ni trabajan espalda con espalda. Esto significa que por la noche a menudo es casi imposible obtener un resultado honesto. Sí, y las carreteras resultan pecaminosas. Por ejemplo, los intentos de medir la velocidad en Japón arrojan resultados extremadamente desastrosos...
decisión primaria
La foto es para fines ilustrativos.
Se desplegaron dos servidores de control de velocidad. El primero es , segundo - . Se comparó el desempeño de ambos servicios. Después de todo, decidimos parar en Ookla porque... Hasta el 90% de los suscriptores utilizan este servicio.
A continuación, se escribieron instrucciones para usuarios y empleados sobre cómo medir velocidades dentro y fuera de la red. Aquellos. Cuando comienza la prueba, de forma predeterminada se mide la velocidad dentro de la red. El servidor está ubicado en nuestra cabecera y la solución Ookla selecciona por defecto el servidor más cercano al suscriptor. De esta forma comprobamos 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 principales centros de datos del país), debe seleccionar un proveedor dentro del país y realizar una segunda medición. Hemos identificado empíricamente varios servidores que dan resultados más o menos estables en cualquier momento del día y los hemos enumerado según lo recomendado en las instrucciones.
Pues acciones similares para los canales de comunicación externos. Encontramos grandes operadores con grandes canales en los servidores de prueba de velocidad y los escribimos en recomendaciones (lo siento, "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, tales dificultades? Todo es muy sencillo. Recibimos una herramienta bastante conveniente que, en manos capaces, nos permite determinar si hay problemas en nuestras redes, si hay problemas en la red republicana o si hay problemas con la red troncal. Si una persona se queja de la baja velocidad de descarga de algún servicio, podemos medir la velocidad del canal del suscriptor y luego compararla con la que recibe del servicio. Y es razonable demostrar que asignamos honestamente el canal especificado en el contrato. También podemos explicar las posibles razones de tal diferencia de velocidades.
Solución secundaria
La cuestión de la reducción de la velocidad por la tarde o durante el día sigue abierta. ¿Cómo hacer lo mismo sin estar en casa del abonado? Tome una tarjeta económica de placa única con una red gigabit y haga con ella la llamada sonda. El dispositivo debe tomar medidas de velocidad a lo largo del cable en un intervalo de tiempo determinado. La solución debe ser de código abierto, lo más sencilla posible y con un panel de administración conveniente para ver los resultados de las mediciones. El dispositivo debe ser lo más económico posible para que pueda reemplazarse fácilmente y dejarse con el suscriptor durante n días sin temor.
implementación
Se tomó como base BananaPI (modelo M1). En realidad, hay dos razones para esta elección.
- Puerto gigabit.
- Estaba tirado en la mesa de noche.
A continuación, se decidió utilizar el cliente Python. para el servicio Speedtest by Ookla como backend para medir la velocidad. biblioteca para medir la velocidad del ping. Bueno, y php para el panel de administración. Para facilitar la percepción utilicé .
Debido a que los recursos de Raspberry no son flexibles, se utilizó la combinación nginx+php-fpm+sqlite3. Quería abandonar MySQL debido a su pesadez y redundancia. Anticipo una pregunta sobre Iperf. Tuvo que ser abandonado ante la imposibilidad de utilizarlo en direcciones distintas a las locales.
Inicialmente seguí el camino de muchos en este sitio. Modificó el cliente speedtest-cli. Pero luego, después de pensar un poco, abandonó esta idea. Escribí mi propio trabajador que utiliza las capacidades del cliente original.
Para analizar los pings, simplemente escribí un controlador independiente. Tomamos el valor medio de la medición. La herramienta de ping puede manejar tanto la dirección IP como el nombre de dominio.
No logré el trabajo asincrónico. En este caso no es especialmente necesario.
El panel de administración para evaluar los resultados resultó ser bastante minimalista.
La figura. Ventana de administración principal con resultados de pruebas
La figura. Configuración de prueba
La figura. Actualizar la lista de servidores Speedtest
Eso es todo. La idea la implementé de rodillas, en mi tiempo libre. Las pruebas de campo aún no han comenzado. Pero tenemos previsto lanzar prototipos en un futuro próximo. Puede ser utilizado tanto por los proveedores allí como por los clientes de los proveedores. Nadie te molesta en tomar medidas en casa las XNUMX horas del día. Lo único que debes recordar es que si navegas activamente por Internet o descargas algo, la medida será inferior a la real. Por lo tanto, lo ideal es dejar la sonda en la red como el único consumidor de tráfico.
PD: no me critiquen por la calidad del código. Soy autodidacta sin experiencia. código fuente para . Se aceptan críticas.
Fuente: habr.com