God eftermiddag til alle Habra-brugere.
Jeg læser konstant artikler på Habré om udviklingen af denne eller hin funktionalitet på Malinka. Jeg besluttede at dele mit arbejde her.
forhistorie
Jeg arbejder for en virksomhed, der tilbyder kabel-tv og internetadgang. Og som det sker i sådanne virksomheder, hører jeg med jævne mellemrum klager over tarifplanens uoverensstemmelse med det, der står i kontrakten. Enten klager brugeren over lav hastighed "via kabel", så over høje ping fra visse tjenester, nogle gange over det fuldstændige fravær af internettet på bestemte tidspunkter af dagen. Ofte ender sådanne klager i en pulje af anmodninger, baseret på hvilken en af medarbejderne går "på stedet" med en fungerende bærbar computer, hvorpå alle målinger foretages. Og ofte viser det sig, at alt er fint med hastigheden. Og den lave hastighed er faktisk på en mobiltelefon, via wi-fi, på balkonen. Nå, eller noget lignende.
Desværre er det ikke muligt at gå til en abonnent for eksempel klokken 21:37, hvor denne har de laveste hastigheder. Medarbejdernes arbejdstid er trods alt begrænset. Udskiftning af routeren har ingen effekt, fordi... Frekvensområdet for wi-fi i vores land er sørgeligt rodet.
For the record — den statslige udbyder i Republikken Hviderusland tvangsaktiverer wi-fi på alle enheder, der leveres til brug, og udsender ByFly SSID fra hver enhed. Også selvom abonnenten ikke har internettjeneste, men kun en hjemmetelefon. Dette blev gjort for mersalg. Du kan købe et kort fra denne operatør i en kiosk, oprette forbindelse til ethvert punkt ved navn ByFly og, ved at indtaste dataene fra kortet, modtage internettjenester. I betragtning af næsten 100 % dækning af byer og betydelig dækning af den private sektor og landdistrikter, er det ikke et problem at finde et forbindelsespunkt.
Observationer af vores eksterne kommunikationskanaler viser, at der er en given båndbreddereserve. Og abonnenter forbruger ikke de tilgængelige kanaler i alt, selv i myldretiden. Vi er meget seriøse omkring dette. Brugen af forskellige tjenester og forskellige hastighedsmålingsservere førte til interessante resultater. Det viser sig, at ikke alle tjenester er lige nyttige... Især om aftenen. Og du skal bestemt ikke stole på dem. Mange operatører af det samme Ookla-netværk har ikke brede kommunikationskanaler eller arbejder ryg mod ryg. Det betyder, at det om aftenen ofte er næsten umuligt at få et ærligt resultat. Ja, og motorvejene viser sig at være syndige. For eksempel viser forsøg på at måle hastighed i Japan ekstremt katastrofale resultater...
Primær beslutning
Billedet er kun til illustrative formål.
To hastighedskontrolservere blev installeret. Den første er , Sekundet - . Ydelsen af begge tjenester blev sammenlignet. Vi besluttede trods alt at stoppe ved Ookla, fordi... op til 90 % af abonnenterne bruger denne tjeneste.
Dernæst blev der skrevet instruktioner til brugere og medarbejdere om, hvordan man måler hastigheder i og uden for netværket. De der. Når testen starter, måles hastigheden i netværket som standard. Serveren er placeret i vores hovedende, og Ookla-løsningen vælger som standard den server, der er tættest på abonnenten. På denne måde kontrollerer vi driften af vores eget datatransmissionsnetværk.
For at måle hastighed i landet (vi har et separat netværk for teleoperatører, som forener alle operatører og hoveddatacentre i landet), skal du vælge en udbyder i landet og foretage en anden måling. Vi har empirisk identificeret adskillige servere, der giver mere eller mindre stabile resultater på ethvert tidspunkt af dagen og har listet dem som anbefalet i instruktionerne.
Nå, lignende handlinger for eksterne kommunikationskanaler. Vi fandt store operatører med store kanaler på speedtest-servere og skrev dem i anbefalinger (undskyld "Moskva - Rostelecom" og "Riga - Baltcom", men jeg vil anbefale disse noder for at få tilstrækkelige tal. Personligt modtog jeg op til ~870 megabit fra disse servere i myldretiden).
Hvorfor, spørger du, sådanne vanskeligheder? Alt er meget enkelt. Vi har modtaget et ret praktisk værktøj, som i dygtige hænder giver os mulighed for at afgøre, om der er problemer i vores netværk, om der er problemer i det republikanske netværk, eller om der er problemer med rygraden. Hvis en person klager over lav downloadhastighed fra en tjeneste, kan vi måle hastigheden på abonnentens kanal og derefter sammenligne den med, hvad han modtager fra tjenesten. Og det er rimeligt at vise, at vi ærligt tildeler den kanal, der er angivet i kontrakten. Vi kan også forklare de mulige årsager til en sådan forskel i hastigheder.
Sekundær løsning
Spørgsmålet om hastighedsfaldet om aftenen/om dagen er fortsat åbent. Hvordan gør man det samme uden at være hjemme hos abonnenten? Tag et billigt singleboard-kort med gigabit-netværk og lav en såkaldt probe ud af det. Enheden skal tage hastighedsmålinger langs kablet med et givet tidsinterval. Løsningen skal være open source, så uhøjtidelig som muligt, med et praktisk adminpanel til visning af måleresultater. Enheden skal være så billig som muligt, så den let kan udskiftes og efterlades hos abonnenten i n dage uden frygt.
implementering
BananaPI (model M1) blev taget som grundlag. Der er faktisk to grunde til dette valg.
- Gigabit port.
- Den lå bare i natbordet.
Dernæst blev det besluttet at bruge python-klienten til Speedtest by Ookla-tjenesten som en backend til måling af hastighed. bibliotek at måle ping-hastighed. Nå, og php til admin panelet. For at lette opfattelsen brugte jeg .
På grund af det faktum, at Raspberrys ressourcer ikke er fleksible, blev kombinationen nginx+php-fpm+sqlite3 brugt. Jeg ønskede at opgive MySQL på grund af dets tyngde og redundans. Jeg forventer et spørgsmål vedrørende Iperf. Det måtte opgives på grund af umuligheden af at bruge det i andre retninger end lokale.
Til at begynde med fulgte jeg manges vej på dette websted. Ændrede speedtest-cli-klienten. Men så, efter at have tænkt lidt, opgav han denne idé. Jeg skrev min egen arbejder, der bruger den oprindelige klients muligheder.
For at analysere ping skrev jeg simpelthen en separat handler. Vi tager gennemsnitsværdien fra målingen. Pingværktøjet kan håndtere både IP-adresse og domænenavn.
Jeg opnåede ikke asynkront arbejde. Det er ikke specielt nødvendigt i dette tilfælde.
Adminpanelet til evaluering af resultater viste sig at være ret minimalistisk.
Fig. Hovedadminvindue med testresultater
Fig. Testindstillinger
Fig. Opdater listen over Speedtest-servere
Det er alt. Idéen blev implementeret på mine knæ, i min fritid. Feltforsøg er endnu ikke begyndt. Men vi planlægger at lancere prototyper i den nærmeste fremtid. Det kan bruges både af udbydere der og af udbyderes kunder. Ingen generer dig med at tage mål derhjemme døgnet rundt. Det eneste du skal huske er, at hvis du aktivt surfer på internettet eller downloader noget, så vil målingen være lavere end den rigtige. Så ideelt set skal du lade sonden være på netværket som den eneste trafikforbruger.
PS: vær venlig ikke at kritisere mig for kvaliteten af koden. Jeg er selvlært uden erfaring. Kildekode til . Kritik accepteres.
Kilde: www.habr.com