Bonjour à tous les utilisateurs d'habra.
Je lis constamment des articles sur Habré sur le développement de telle ou telle fonctionnalité sur le "Malinka". J'ai décidé de partager mon travail ici.
Contexte
Je travaille dans une entreprise qui fournit des services de télévision par câble et d'accès Internet. Et, comme c'est le cas dans de telles entreprises, j'entends périodiquement des plaintes concernant l'incohérence du plan tarifaire indiqué dans le contrat. Désormais, l'utilisateur se plaint de la faible vitesse "over the cable", puis des pings élevés de certains services, parfois de l'absence totale d'Internet à une certaine heure de la journée. Souvent, de telles plaintes aboutissent dans le pool d'applications, selon lequel l'un des employés avec un ordinateur portable en état de marche, sur lequel toutes les mesures sont effectuées, est envoyé sur le site. Et, souvent, il s'avère que tout est en ordre avec la rapidité. Et la basse vitesse est en fait sur un téléphone mobile, via wi-fi, sur le balcon. Eh bien, ou quelque chose comme ça.
Malheureusement, il est impossible de se rendre chez l'abonné par exemple à 21h37, alors qu'il a les vitesses les plus basses. Pourtant, la journée de travail des employés est limitée. Le remplacement du routeur n'a aucun effet. la gamme de fréquences pour le wi-fi dans notre pays est déplorablement encombrée.
Pour référence - le fournisseur d'État de la République de Biélorussie active de force le Wi-Fi sur tous les appareils fournis pour l'utilisation et diffuse le SSID ByFly à partir de chaque appareil. Même si l'abonné ne dispose pas d'un service Internet, mais uniquement d'un téléphone résidentiel. Ceci est fait pour des ventes supplémentaires. Vous pouvez acheter une carte de cet opérateur dans un stand, vous connecter à n'importe quel point avec le nom ByFly et, en entrant les données de la carte, recevoir des services Internet. Compte tenu d'une couverture de près de 100% des villes et d'une couverture significative du secteur privé et des agglomérations rurales, trouver un point de connexion n'est pas un problème.
L'observation de nos canaux de communication externes montre qu'il existe une réserve de bande passante donnée. Et les abonnés au total ne consomment pas les chaînes disponibles, même aux heures de pointe. Avec cela, nous sommes tous très sérieux. L'utilisation de différents services et de différents serveurs pour mesurer la vitesse a conduit à des résultats intéressants. Il s'avère que tous les services ne sont pas également utiles ... Surtout le soir. Et vous ne devriez pas leur faire confiance sans ambiguïté. De nombreux opérateurs du même réseau Ookla ne disposent pas de canaux de communication larges ou travaillent de bout en bout. Cela signifie qu'il est souvent presque impossible d'obtenir un résultat honnête le soir. Et les autoroutes pèchent. Par exemple, les tentatives de mesure de la vitesse au Japon donnent des résultats extrêmement déplorables ...
Solution primaire
Photo à titre indicatif
Deux serveurs de contrôle de vitesse ont été déployés. Le premier est LibreSpeed , le second est le Speedtest d'OOKLA . La performance des deux services a été comparée. Nous avons décidé de nous arrêter à Ookla. jusqu'à 90% des abonnés utilisent ce service particulier.
Ensuite, des instructions ont été rédigées pour les utilisateurs et les employés sur la façon de mesurer la vitesse à l'intérieur et à l'extérieur du réseau. Ceux. lors du démarrage du test, la vitesse est mesurée par défaut dans le réseau. Le serveur est situé à notre siège social et la solution Ookla sélectionne par défaut le serveur le plus proche de l'abonné. Ainsi, nous vérifions le fonctionnement de notre propre réseau de transmission de données.
Pour mesurer la vitesse dans le pays (nous avons un réseau distinct pour les opérateurs de télécommunications, qui réunit tous les opérateurs et les principaux centres de données du pays), vous devez sélectionner un fournisseur dans le pays et mesurer à nouveau. Nous avons identifié empiriquement plusieurs serveurs qui donnent des résultats plus ou moins stables à tout moment de la journée et les avons prescrits comme recommandé dans les instructions.
Eh bien, des actions similaires pour les canaux de communication externes. Nous avons trouvé de grands opérateurs avec de grands canaux sur des serveurs de test de vitesse et les avons écrits dans des recommandations (pardonnez à Moskva - Rostelecom et Riga - Baltcom, mais je recommanderai ces nœuds pour obtenir des nombres adéquats. Personnellement, j'ai reçu jusqu'à ~ 870 mégabits de ces serveurs aux heures de pointe).
Pourquoi, demandez-vous, de telles difficultés? Tout est très simple. Nous avons reçu un outil assez pratique qui, entre de bonnes mains, nous permet de déterminer: y a-t-il des problèmes dans nos réseaux, y a-t-il des problèmes dans le réseau républicain, y a-t-il des problèmes avec le tronc. Si une personne se plaint d'une faible vitesse de téléchargement d'un service, nous pouvons mesurer la vitesse du canal de l'abonné, puis comparer avec ce qu'il reçoit du service. Et il est soutenu pour montrer que nous mettons honnêtement en évidence le canal prescrit dans le contrat. Et nous pouvons également expliquer les raisons possibles d'une telle différence de vitesse.
Solution secondaire
La question de la baisse de vitesse le soir / pendant la journée reste ouverte. Comment faire tout de même sans être chez l'abonné? Prenez une carte simple bon marché avec un réseau gigabit et faites-en une soi-disant sonde. L'appareil doit mesurer la vitesse à travers le câble à un intervalle de temps spécifié. La solution doit être open source, aussi simple que possible, avec un panneau d'administration pratique pour afficher les résultats de mesure. L'appareil doit être aussi bon marché que possible, afin de pouvoir être facilement remplacé et laissé chez l'abonné pendant n jours sans crainte.
la mise en oeuvre
BananaPI (modèle M1) a été pris comme base. Il y a en fait deux raisons de choisir.
- Port Gigabit.
- Il était juste allongé sur la table de chevet.
Ensuite, il a été décidé d'utiliser le client python speedtest-cli pour le service Speedtest by Ookla comme backend pour mesurer la vitesse. Bibliothèque Pythonping pour mesurer la vitesse de ping. Eh bien, et php pour la zone d'administration. Pour des raisons de commodité, j'ai utilisé bootstrap .
En raison du fait que les ressources de framboise ne sont pas en caoutchouc, un tas de nginx + php-fpm + sqlite3 a été utilisé. Nous voulions abandonner MySQL en raison de sa lourdeur et de sa redondance. Anticiper une question concernant Iperf. Il a dû être abandonné en raison de l'impossibilité de l'utiliser dans des directions autres que locales.
Au départ j'ai suivi le chemin de beaucoup sur ce site. Modification du client speedtest-cli. Mais ensuite, après une petite réflexion, il abandonna l'idée. J'ai écrit mon propre worker qui utilise les capacités du client d'origine.
Pour analyser les pings, j'ai simplement écrit un gestionnaire distinct. Nous prenons la valeur moyenne par mesure. Pingovalka connaît à la fois une adresse IP et un nom de domaine.
Je n'ai pas réalisé de travail asynchrone. Elle n'est pas particulièrement nécessaire dans ce cas.
Le panneau d'administration pour évaluer les résultats s'est avéré assez minimaliste.
Figure. Mise à jour de la liste des serveurs Speedtest
C'est tout. L'idée s'est réalisée sur le genou, en temps libre du travail. Les tests sur le terrain n'ont pas encore commencé. Mais nous prévoyons de lancer des prototypes dans un proche avenir. Vous pouvez utiliser à la fois les fournisseurs et les clients des fournisseurs. Personne ne prend la peine de mettre des mesures à la maison 24 heures sur 24. La seule chose à retenir est que si vous surfez activement sur le net ou téléchargez quelque chose, la mesure s'avérera inférieure à la vraie. Ainsi, idéalement, la sonde devrait être laissée sur le réseau en tant que seul consommateur de trafic.
PS: merci de ne pas céder pour la qualité du code. Je suis autodidacte sans expérience. Code source sur GitHub . La critique est acceptée.