Ontwikkeling van 'n sone vir die meting van internetspoed

Ontwikkeling van 'n sone vir die meting van internetspoed
Goeie middag aan alle Habra gebruikers.

Ek lees gedurig artikels op Habré oor die ontwikkeling van hierdie of daardie funksionaliteit op Malinka. Ek het besluit om my werk hier te deel.

voorgeskiedenis

Ek werk vir 'n maatskappy wat kabeltelevisie en internettoegangsdienste verskaf. En, soos in sulke maatskappye gebeur, hoor ek van tyd tot tyd klagtes oor die inkonsekwentheid van die tariefplan met wat in die kontrak staan. Óf die gebruiker kla oor lae spoed "via kabel", dan oor hoë pings van sekere dienste, soms oor die volledige afwesigheid van die internet op sekere tye van die dag. Dikwels beland sulke klagtes in 'n poel van versoeke, gebaseer op watter een van die werknemers met 'n werkende skootrekenaar "ter plaatse" gaan, waarop alle mates geneem word. En dikwels blyk dit dat alles goed is met die spoed. En die lae spoed is eintlik op 'n selfoon, via wi-fi, op die balkon. Wel, of iets soortgelyks.

Ongelukkig is dit nie moontlik om na 'n intekenaar te gaan, byvoorbeeld om 21:37, wanneer hy die laagste spoed het nie. Die werknemers se werksure is immers beperk. Die vervanging van die router het geen effek nie, want... Die frekwensiereeks vir wi-fi in ons land is jammerlik deurmekaar.

Vir die rekord — die staatsverskaffer in die Republiek van Wit-Rusland skakel Wi-Fi met geweld aan op alle toestelle wat vir gebruik voorsien is en saai die ByFly SSID vanaf elke toestel uit. Selfs al het die intekenaar nie internetdiens nie, maar slegs 'n tuisfoon. Dit is gedoen vir bykomende verkope. Jy kan 'n kaart by hierdie operateur by 'n kiosk koop, aan enige punt genaamd ByFly koppel en, deur die data van die kaart in te voer, internetdienste ontvang. Gegewe byna 100% dekking van stede en aansienlike dekking van die private sektor en landelike gebiede, is dit nie 'n probleem om 'n verbindingspunt te vind nie.

Waarnemings van ons eksterne kommunikasiekanale toon dat daar 'n gegewe bandwydte-reserwe is. En intekenare verbruik nie die beskikbare kanale in totaal nie, selfs nie tydens spitstyd nie. Ons is baie ernstig hieroor. Die gebruik van verskillende dienste en verskillende spoedmetingsbedieners het tot interessante resultate gelei. Dit blyk dat nie alle dienste ewe nuttig is nie... Veral in die aande. En jy moet hulle beslis nie vertrou nie. Baie operateurs van dieselfde Ookla-netwerk het nie wye kommunikasiekanale nie, of werk rug-aan-rug. Dit beteken dat dit dikwels in die aand amper onmoontlik is om 'n eerlike resultaat te kry. Ja, en die snelweë blyk sondig te wees. Byvoorbeeld, pogings om spoed te meet in Japan toon uiters rampspoedige resultate ...

Primêre besluit

Ontwikkeling van 'n sone vir die meting van internetspoed
Die foto is slegs vir illustratiewe doeleindes.

Twee spoedbeheerbedieners is ontplooi. Die eerste een is LibreSpeed, die tweede - Spoedtoets van OOKLA. Die prestasie van beide dienste is vergelyk. Ons het immers besluit om by Ookla te stop, want... tot 90% van intekenare gebruik hierdie diens.

Vervolgens is instruksies vir gebruikers en werknemers geskryf oor hoe om spoed binne en buite die netwerk te meet. Dié. Wanneer die toets begin, word die spoed binne die netwerk by verstek gemeet. Die bediener is by ons hoofpunt geleë, en die Ookla-oplossing kies standaard die bediener naaste aan die intekenaar. Op hierdie manier kontroleer ons die werking van ons eie data-oordragnetwerk.

Om spoed binne die land te meet (ons het 'n aparte netwerk vir telekommunikasie-operateurs, wat alle operateurs en hoofdatasentrums binne die land verenig), moet jy 'n verskaffer binne die land kies en 'n tweede meting neem. Ons het verskeie bedieners empiries geïdentifiseer wat min of meer stabiele resultate gee op enige tyd van die dag en het hulle gelys soos aanbeveel in die instruksies.

Wel, soortgelyke aksies vir eksterne kommunikasiekanale. Ons het groot operateurs met groot kanale op spoedtoetsbedieners gevind en dit in aanbevelings geskryf (jammer "Moskva - Rostelecom" en "Riga - Baltcom", maar ek sal hierdie nodusse aanbeveel om voldoende getalle te kry. Persoonlik het ek tot ~870 megabit ontvang vanaf hierdie bedieners tydens spitstye).

Hoekom, vra jy, sulke probleme? Alles is baie eenvoudig. Ons het 'n redelik gerieflike hulpmiddel ontvang wat ons in bekwame hande toelaat om vas te stel of daar probleme in ons netwerke is, of daar probleme in die republikeinse netwerk is, en of daar probleme met die ruggraat is. As 'n persoon kla oor lae aflaaispoed van een of ander diens, kan ons die spoed van die intekenaar se kanaal meet en dit dan vergelyk met wat hy van die diens ontvang. En dit is redelik om te wys dat ons die kanaal wat in die kontrak gespesifiseer is, eerlik toeken. Ons kan ook die moontlike redes vir so 'n verskil in spoed verduidelik.

Sekondêre oplossing

Die vraag oor die spoeddaling in die aande/bedags bly oop. Hoe om dieselfde ding te doen sonder om by die intekenaar se huis te wees? Neem 'n goedkoop enkelbordkaart met 'n gigabit-netwerk en maak 'n sogenaamde sonde daarvan. Die toestel moet spoedmetings langs die kabel op 'n gegewe tydsinterval neem. Die oplossing moet oopbron wees, so onpretensieus as moontlik, met 'n gerieflike administrasiepaneel om metingsresultate te sien. Die toestel moet so goedkoop as moontlik wees sodat dit maklik vervang kan word en vir n dae sonder vrees by die intekenaar gelaat kan word.

Implementering

Ontwikkeling van 'n sone vir die meting van internetspoed

BananaPI (model M1) is as basis geneem. Daar is eintlik twee redes vir hierdie keuse.

  1. Gigabit-poort.
  2. Dit het net in die nagkassie rondgelê.

Vervolgens is besluit om die python-kliënt te gebruik speedtest-cli vir die Speedtest by Ookla-diens as 'n backend om spoed te meet. biblioteek Pythonping om pingspoed te meet. Wel, en php vir die admin paneel. Vir gemak van persepsie het ek gebruik bootstrap.

As gevolg van die feit dat Raspberry se hulpbronne nie buigsaam is nie, is die nginx+php-fpm+sqlite3-kombinasie gebruik. Ek wou MySQL prysgee weens die swaar en oortolligheid daarvan. Ek verwag 'n vraag oor Iperf. Dit moes laat vaar word weens die onmoontlikheid om dit in ander rigtings as plaaslike rigtings te gebruik.

Ek het aanvanklik die pad van baie op hierdie webwerf gevolg. Het die speedtest-cli-kliënt gewysig. Maar toe, nadat hy 'n bietjie gedink het, het hy hierdie idee laat vaar. Ek het my eie werker geskryf wat die vermoëns van die oorspronklike kliënt gebruik.

Om pings te ontleed, het ek eenvoudig 'n aparte hanteerder geskryf. Ons neem die gemiddelde waarde uit die meting. Die ping-instrument kan beide IP-adres en domeinnaam hanteer.

Ek het nie asinchroniese werk behaal nie. Dit is nie veral nodig in hierdie geval nie.

Die administrasiepaneel vir die evaluering van resultate was redelik minimalisties.

Ontwikkeling van 'n sone vir die meting van internetspoedFig. Hoof admin venster met toets resultate

Ontwikkeling van 'n sone vir die meting van internetspoedFig. Toets instellings

Ontwikkeling van 'n sone vir die meting van internetspoed
Fig. Dateer die lys van Speedtest-bedieners op

Dis al. Die idee is op my knieë geïmplementeer, in my vrye tyd. Veldtoetse het nog nie begin nie. Maar ons beplan om prototipes in die nabye toekoms bekend te stel. Dit kan beide deur verskaffers daar en deur kliënte van verskaffers gebruik word. Niemand pla jou om 24 uur per dag by die huis metings te neem nie. Die enigste ding wat u moet onthou, is dat as u aktief op die internet blaai of iets aflaai, die meting laer sal wees as die regte een. Dus, ideaal gesproke, moet jy die sonde op die netwerk laat as die enigste verkeersverbruiker.

NS: moet my asseblief nie kritiseer vir die kwaliteit van die kode nie. Ek is selfonderrig met geen ondervinding nie. Bronkode vir GitHub. Kritiek word aanvaar.

Bron: will.com

Voeg 'n opmerking