Jó napot minden Habra felhasználónak.
Folyamatosan olvasom a Habré cikkeket a Malinka egy-egy funkciójának fejlesztéséről. Úgy döntöttem, hogy megosztom itt a munkáimat.
őstörténet
Egy kábeltelevíziós és internet-hozzáférési szolgáltatást nyújtó cégnél dolgozom. És ahogy az ilyen cégeknél történik, rendszeresen hallok panaszokat arról, hogy a tarifaterv nincs összhangban a szerződésben foglaltakkal. A felhasználó vagy az alacsony sebességre panaszkodik „kábelen keresztül”, majd bizonyos szolgáltatások magas pingjére, néha az internet teljes hiányára a nap bizonyos szakaszaiban. Az ilyen panaszok gyakran egy kéréshalmazba kerülnek, amely alapján az egyik alkalmazott „helyre megy” működő laptoppal, amelyen minden mérést végeznek. És gyakran kiderül, hogy a sebességgel minden rendben van. Az alacsony sebesség pedig valójában mobiltelefonon, wi-fi-n keresztül, az erkélyen. Nos, vagy valami hasonló.
Sajnos nem lehet odamenni egy előfizetőhöz például 21:37-kor, amikor neki a legalacsonyabb a sebessége. Hiszen az alkalmazottak munkaideje korlátozott. A router cseréjének nincs hatása, mert... A wi-fi frekvenciatartománya hazánkban siralmasan zsúfolt.
A rekord — a Fehérorosz Köztársaság állami szolgáltatója erőszakkal bekapcsolja a wi-fit az összes használatra biztosított eszközön, és minden eszközről sugározza a ByFly SSID-t. Akkor is, ha az előfizetőnek nincs internetszolgáltatása, csak otthoni telefonja. Ez a további értékesítés érdekében történt. Ettől a szolgáltatótól vásárolhat kártyát egy kioszkban, csatlakozhat bármely ByFly nevű ponthoz, és a kártya adatainak megadásával internetes szolgáltatásokat vehet igénybe. Tekintettel a városok közel 100%-os lefedettségére, valamint a magánszektor és a vidéki területek jelentős lefedettségére, a csatlakozási pont megtalálása nem jelent problémát.
Külső kommunikációs csatornáink megfigyelései azt mutatják, hogy van egy adott sávszélesség-tartalék. Az előfizetők pedig még csúcsidőben sem fogyasztják el összesen az elérhető csatornákat. Ezt nagyon komolyan gondoljuk. A különböző szolgáltatások és különböző sebességmérő szerverek használata érdekes eredményekhez vezetett. Kiderült, hogy nem minden szolgáltatás egyformán hasznos... Főleg esténként. És nem szabad határozottan megbíznia bennük. Ugyanannak az Ookla hálózatnak sok üzemeltetője nem rendelkezik széles kommunikációs csatornákkal, vagy egymásnak megfelelően működik. Ez azt jelenti, hogy este sokszor szinte lehetetlen őszinte eredményt elérni. Igen, és az autópályák bűnösnek bizonyulnak. Például Japánban a sebesség mérésére tett kísérletek rendkívül katasztrofális eredményeket mutatnak...
Elsődleges döntés
A fotó illusztráció
Két sebességszabályozó szervert telepítettek. Az első az , a második - . A két szolgáltatás teljesítményét összehasonlították. Végül is úgy döntöttünk, hogy megállunk Ooklában, mert... az előfizetők 90%-a használja ezt a szolgáltatást.
Ezután utasításokat írtak a felhasználóknak és az alkalmazottaknak a sebesség mérésére a hálózaton belül és kívül. Azok. A teszt indulásakor alapértelmezés szerint a hálózaton belüli sebességet mérik. A szerver a fejállomásunkon található, és az Ookla megoldás alapértelmezés szerint az előfizetőhöz legközelebb eső szervert választja ki. Így ellenőrizzük saját adatátviteli hálózatunk működését.
Az országon belüli sebességméréshez (a távközlési szolgáltatók számára külön hálózatunk van, amely az ország összes szolgáltatóját és fő adatközpontját egyesíti) az országon belüli szolgáltatót kell választani, és egy második mérést kell végezni. Empirikusan azonosítottunk több olyan szervert, amelyek többé-kevésbé stabil eredményeket adnak a nap bármely szakában, és ezeket az utasítások szerint felsoroltuk.
Nos, hasonló műveletek a külső kommunikációs csatornákhoz. A speedtest szervereken nagy csatornákkal rendelkező nagy szolgáltatókat találtunk, és ajánlásokba írtuk őket (elnézést „Moskva - Rostelecom” és „Riga - Baltcom”, de ezeket a csomópontokat javaslom, hogy megfelelő számokat kapjak. Személy szerint ~870 megabitet kaptam ezek a szerverek csúcsidőben).
Kérdezed, miért ilyen nehézségek? Minden nagyon egyszerű. Egy elég kényelmes eszközt kaptunk, amivel hozzáértő kezekben meg tudjuk állapítani, hogy a hálózatainkban van-e probléma, vagy a köztársasági hálózatban, vagy a gerinchálózattal. Ha valaki arra panaszkodik, hogy valamelyik szolgáltatásból alacsony a letöltési sebesség, akkor megmérhetjük az előfizető csatornájának sebességét, majd összehasonlíthatjuk azzal, amit a szolgáltatástól kap. És ésszerű kimutatni, hogy becsületesen osztjuk ki a szerződésben meghatározott csatornát. Megmagyarázhatjuk az ilyen sebességkülönbségek lehetséges okait is.
Másodlagos megoldás
Az esti/nappali sebességcsökkenés kérdése nyitva marad. Hogyan teheti meg ugyanezt anélkül, hogy az előfizető otthonában lenne? Vegyünk egy olcsó egylapos kártyát gigabites hálózattal és csináljunk belőle úgynevezett szondát. A készüléknek adott időintervallumban sebességmérést kell végeznie a kábel mentén. A megoldás legyen nyílt forráskódú, minél szerényebb, kényelmes admin panellel a mérési eredmények megtekintésére. A készülék legyen a lehető legolcsóbb, hogy könnyen cserélhető legyen és félelem nélkül n napig az előfizetőnél maradhasson.
Реализация
A BananaPI-t (M1 modell) vettük alapul. Valójában két oka van ennek a választásnak.
- Gigabit port.
- Csak hevert az éjjeliszekrényen.
Ezután a python kliens használata mellett döntöttek a Speedtest by Ookla szolgáltatáshoz, amely a sebesség mérésének háttérprogramja. Könyvtár ping sebesség mérésére. No meg php az adminisztrációs panelnek. Az észlelés megkönnyítésére használtam .
Tekintettel arra, hogy a Raspberry erőforrásai nem rugalmasak, az nginx+php-fpm+sqlite3 kombinációt használtuk. Fel akartam adni a MySQL-t nehézsége és redundanciája miatt. Várok egy kérdést az Iperffel kapcsolatban. El kellett hagyni, mert nem lehetett helyitől eltérő irányban használni.
Kezdetben sokak útját követtem ezen az oldalon. Módosítva a speedtest-cli kliens. De aztán egy kis gondolkodás után elvetette ezt az ötletet. Saját munkásomat írtam, amely az eredeti kliens képességeit használja.
A pingek elemzéséhez egyszerűen írtam egy külön kezelőt. A mérésből az átlagértéket vesszük. A ping eszköz képes kezelni mind az IP-címet, mind a domain nevet.
Aszinkron munkát nem értem el. Ebben az esetben nincs rá különösebb szükség.
Az eredmények értékelésére szolgáló adminisztrációs panel meglehetősen minimalista volt.
Ábra. Fő adminisztrációs ablak a tesztelési eredményekkel
Ábra. Tesztbeállítások
Ábra. Frissítse a Speedtest szerverek listáját
Ez minden. Az ötlet térdemen, szabadidőmben valósult meg. A terepi tesztek még nem kezdődtek el. De a közeljövőben prototípusok elindítását tervezzük. Az ottani szolgáltatók és a szolgáltatók ügyfelei egyaránt használhatják. Senki sem zavarja, hogy éjjel-nappal otthon mérjen. Az egyetlen dolog, amit emlékeznie kell, az az, hogy ha aktívan szörföl az interneten vagy letölt valamit, akkor a mérés alacsonyabb lesz, mint a valódi. Ideális esetben tehát a szondát a hálózaton kell hagynia egyedüli forgalomfogyasztóként.
PS: kérlek, ne kritizálj a kód minősége miatt. Autodidakta vagyok, tapasztalat nélkül. Forráskód a következőhöz . A kritikát elfogadják.
Forrás: will.com