Utvikling av en sone for måling av hastigheten på Internett

God ettermiddag til alle Habra-brukere.

Jeg leser stadig artikler på Habré om utviklingen av denne eller hin funksjonaliteten på Malinka. Jeg bestemte meg for å dele arbeidet mitt her.

forhistorie

Jeg jobber for et selskap som tilbyr kabel-TV og internettilgangstjenester. Og som det skjer i slike selskaper, hører jeg med jevne mellomrom klager på at tariffplanen ikke samsvarer med det som står i kontrakten. Enten klager brukeren over lav hastighet "via kabel", så over høye ping fra visse tjenester, noen ganger over fullstendig fravær av Internett på bestemte tider av dagen. Ofte ender slike klager i en samling av forespørsler, basert på hvilken en av de ansatte går "på stedet" med en fungerende bærbar datamaskin, som alle målinger blir tatt på. Og ofte viser det seg at alt er bra med hastigheten. Og den lave hastigheten er faktisk på en mobiltelefon, via wi-fi, på balkongen. Vel, eller noe lignende.

Dessverre er det ikke mulig å gå til en abonnent, for eksempel klokken 21:37, når han har lavest hastighet. De ansattes arbeidstid er tross alt begrenset. Å bytte ruteren har ingen effekt, fordi... Frekvensområdet for wi-fi i vårt land er sørgelig rotete.

For ordens — den statlige leverandøren i Republikken Hviterussland slår på wi-fi med makt på alle enheter som er levert for bruk og kringkaster ByFly SSID fra hver enhet. Selv om abonnenten ikke har Internett-tjeneste, men kun en hjemmetelefon. Dette ble gjort for mersalg. Du kan kjøpe et kort fra denne operatøren i en kiosk, koble til et hvilket som helst punkt som heter ByFly og, ved å legge inn dataene fra kortet, motta Internett-tjenester. Gitt nesten 100 % dekning av byer og betydelig dekning av privat sektor og landlige områder, er det ikke noe problem å finne et tilknytningspunkt.

Observasjoner av våre eksterne kommunikasjonskanaler viser at det er en gitt båndbreddereserve. Og abonnenter bruker ikke de tilgjengelige kanalene totalt, selv i rushtiden. Vi er veldig seriøse med dette. Bruken av forskjellige tjenester og forskjellige hastighetsmålingsservere førte til interessante resultater. Det viser seg at ikke alle tjenester er like nyttige... Spesielt på kveldstid. Og du bør absolutt ikke stole på dem. Mange operatører av samme Ookla-nettverk har ikke brede kommunikasjonskanaler, eller jobber rygg mot rygg. Dette gjør at det på kvelden ofte er nesten umulig å få et ærlig resultat. Ja, og motorveiene viser seg å være syndige. For eksempel viser forsøk på å måle hastighet i Japan ekstremt katastrofale resultater...

Primærbeslutning

Bildet er kun for illustrative formål.

To hastighetskontrollservere ble utplassert. Den første er LibreSpeed, sekund - Speedtest fra OOKLA. Ytelsen til begge tjenestene ble sammenlignet. Tross alt bestemte vi oss for å stoppe på Ookla fordi... opptil 90 % av abonnentene bruker denne tjenesten.

Deretter ble det skrevet instruksjoner for brukere og ansatte om hvordan man måler hastigheter i og utenfor nettverket. De. Når testen starter, måles hastigheten i nettverket som standard. Serveren er plassert i hovedenden vår, og Ookla-løsningen velger som standard serveren nærmest abonnenten. På denne måten kontrollerer vi driften av vårt eget dataoverføringsnettverk.

For å måle hastighet i landet (vi har et eget nettverk for teleoperatører, som forener alle operatører og hoveddatasentre i landet), må du velge en leverandør i landet og ta en ny måling. Vi har empirisk identifisert flere servere som gir mer eller mindre stabile resultater til enhver tid på dagen og har listet dem opp som anbefalt i instruksjonene.

Vel, lignende handlinger for eksterne kommunikasjonskanaler. Vi fant store operatører med store kanaler på speedtest-servere og skrev dem i anbefalinger (beklager "Moskva - Rostelecom" og "Riga - Baltcom", men jeg vil anbefale disse nodene for å få tilstrekkelige tall. Personlig mottok jeg opptil ~870 megabit fra disse serverne i rushtiden).

Hvorfor, spør du, slike vanskeligheter? Alt er veldig enkelt. Vi har fått et ganske praktisk verktøy som, i dyktige hender, lar oss finne ut om det er problemer i nettverkene våre, om det er problemer i det republikanske nettverket, eller om det er problemer med ryggraden. Hvis en person klager over lav nedlastingshastighet fra en tjeneste, kan vi måle hastigheten til abonnentens kanal og deretter sammenligne den med det han mottar fra tjenesten. Og det er rimelig å vise at vi ærlig tildeler kanalen spesifisert i kontrakten. Vi kan også forklare mulige årsaker til en slik forskjell i hastigheter.

Sekundær løsning

Spørsmålet om fartsfallet på kveldstid/dag står åpent. Hvordan gjøre det samme uten å være hjemme hos abonnenten? Ta et billig enkeltkort med gigabit-nettverk og lag en såkalt probe av det. Enheten skal ta hastighetsmålinger langs kabelen ved et gitt tidsintervall. Løsningen bør være åpen kildekode, så upretensiøs som mulig, med et praktisk adminpanel for visning av måleresultater. Enheten bør være så billig som mulig slik at den enkelt kan byttes ut og stå hos abonnenten i n dager uten frykt.

implementering

BananaPI (modell M1) ble lagt til grunn. Det er faktisk to grunner til dette valget.

1. Gigabit port.
2. Den ble bare liggende på nattbordet.

Deretter ble det bestemt å bruke python-klienten speedtest-cli for Speedtest by Ookla-tjenesten som en backend for måling av hastighet. bibliotek Pythonping for å måle pinghastighet. Vel, og php for adminpanelet. For å lette oppfatningen brukte jeg bootstrap.

På grunn av det faktum at Raspberrys ressurser ikke er fleksible, ble kombinasjonen nginx+php-fpm+sqlite3 brukt. Jeg ønsket å gi opp MySQL på grunn av dens tyngde og redundans. Jeg forventer et spørsmål angående Iperf. Den måtte forlates på grunn av umuligheten av å bruke den i andre retninger enn lokale.

Til å begynne med fulgte jeg veien til mange på denne siden. Endret speedtest-cli-klienten. Men så, etter å ha tenkt litt, forlot han denne ideen. Jeg skrev min egen arbeider som bruker egenskapene til den opprinnelige klienten.

For å analysere ping, skrev jeg ganske enkelt en egen behandler. Vi tar gjennomsnittsverdien fra målingen. Pingverktøyet kan håndtere både IP-adresse og domenenavn.

Jeg oppnådde ikke asynkront arbeid. Det er ikke spesielt nødvendig i dette tilfellet.

Administrasjonspanelet for å evaluere resultater viste seg å være ganske minimalistisk.

Fig. Hovedadminvindu med testresultater

Fig. Testinnstillinger

Fig. Oppdater listen over Speedtest-servere

Det er alt. Ideen ble implementert på mine knær, på fritiden. Feltprøver har ennå ikke begynt. Men vi planlegger å lansere prototyper i nær fremtid. Den kan brukes både av tilbydere der og av klienter til leverandører. Ingen plager deg med å ta målinger hjemme hele døgnet. Det eneste du bør huske er at hvis du aktivt surfer på Internett eller laster ned noe, vil målingen være lavere enn den virkelige. Så ideelt sett må du la sonden være på nettverket som den eneste trafikkforbrukeren.

PS: vennligst ikke kritiser meg for kvaliteten på koden. Jeg er selvlært uten erfaring. Kildekode for GitHub. Kritikk er akseptert.

Kilde: www.habr.com