Bonan posttagmezon al ĉiuj uzantoj de Habra.
Mi senĉese legas artikolojn pri Habré pri la disvolviĝo de tiu aŭ alia funkcio ĉe Malinka. Mi decidis dividi mian laboron ĉi tie.
antaŭhistorio
Mi laboras por kompanio, kiu provizas kablotelevidon kaj servojn de interreta aliro. Kaj, kiel okazas en tiaj kompanioj, mi periode aŭdas plendojn pri la nekongrueco de la tarifa plano kun tio, kio estas deklarita en la kontrakto. Aŭ la uzanto plendas pri malalta rapideco "per kablo", tiam pri altaj pingoj de certaj servoj, foje pri la kompleta foresto de Interreto en certaj horoj de la tago. Ofte tiaj plendoj finiĝas en aro da petoj, surbaze de kiuj unu el la dungitoj iras "surloke" kun funkcianta tekkomputilo, sur kiu ĉiuj mezuradoj estas prenitaj. Kaj, ofte, rezultas, ke ĉio estas bone kun la rapideco. Kaj la malalta rapido estas fakte sur poŝtelefono, per wi-fi, sur la balkono. Nu, aŭ io simila.
Bedaŭrinde, ne eblas iri al abonanto, ekzemple, je 21:37, kiam li havas la plej malaltajn rapidojn. Post ĉio, la laborhoroj de la dungitoj estas limigitaj. Anstataŭigi la enkursigilon ne efikas, ĉar... La frekvenca gamo por wi-fi en nia lando estas lamente malorda.
Por referenco — la ŝtata provizanto en la Respubliko de Belorusio perforte ŝaltas wi-fi sur ĉiuj aparatoj provizitaj por uzo kaj dissendas la ByFly SSID de ĉiu aparato. Eĉ se la abonanto ne havas Interretan servon, sed nur hejman telefonon. Ĉi tio estis farita por pliaj vendoj. Vi povas aĉeti karton de ĉi tiu operatoro ĉe kiosko, konektiĝi al iu ajn punkto nomata ByFly kaj, enigante la datumojn de la karto, ricevi interretajn servojn. Surbaze de preskaŭ 100% priraportado de grandurboj kaj signifa priraportado de la privata sektoro kaj kamparaj areoj, trovi ligpunkton ne estas problemo.
Observoj de niaj eksteraj komunikadkanaloj montras ke ekzistas antaŭfiksita bendolarĝa rezervo. Kaj abonantoj ne konsumas la disponeblajn kanalojn entute, eĉ dum pinhoro. Ni estas tre seriozaj pri ĉi tio. La uzo de malsamaj servoj kaj malsamaj rapidecmezurserviloj kondukis al interesaj rezultoj. Montriĝas, ke ne ĉiuj servoj estas same utilaj... Precipe vespere. Kaj vi nepre ne devus fidi ilin. Multaj funkciigistoj de la sama Ookla reto ne havas larĝajn komunikajn kanalojn, aŭ laboras dors-al-dorso. Ĉi tio signifas, ke vespere estas ofte preskaŭ neeble akiri honestan rezulton. Jes, kaj la ŝoseoj montriĝas pekaj. Ekzemple, provoj mezuri rapidecon en Japanio montras ekstreme katastrofajn rezultojn...
Primara decido
La foto estas nur por ilustraj celoj.
Du rapideckontrolserviloj estis deplojitaj. La unua estas , la dua - . La agado de ambaŭ servoj estis komparita. Post ĉio, ni decidis halti ĉe Ookla ĉar... ĝis 90% de abonantoj uzas ĉi tiun servon.
Poste, instrukcioj estis skribitaj por uzantoj kaj dungitoj pri kiel mezuri rapidojn ene kaj ekster la reto. Tiuj. Kiam la testo komenciĝas, defaŭlte la rapideco ene de la reto estas mezurita. La servilo situas ĉe nia kapfino, kaj la solvo Ookla defaŭlte elektas la servilon plej proksiman al la abonanto. Tiamaniere ni kontrolas la funkciadon de nia propra reto de transdono de datumoj.
Por mezuri rapidecon ene de la lando (ni havas apartan reton por telekomunikaj telefonistoj, kiu kunigas ĉiujn funkciigistojn kaj ĉefajn datumcentrojn ene de la lando), vi devas elekti provizanton ene de la lando kaj preni duan mezuradon. Ni empirie identigis plurajn servilojn, kiuj donas pli-malpli stabilajn rezultojn en ajna momento de la tago kaj listigis ilin kiel rekomenditaj en la instrukcioj.
Nu, similaj agoj por eksteraj komunikaj kanaloj. Ni trovis grandajn funkciigistojn kun grandaj kanaloj sur speedtest-serviloj kaj skribis ilin en rekomendoj (pardonu "Moskva - Rostelecom" kaj "Riga - Baltcom", sed mi rekomendos ĉi tiujn nodojn por akiri taŭgajn nombrojn. Persone, mi ricevis ĝis ~870 megabitojn de ĉi tiuj serviloj dum pinthoroj).
Kial, vi demandas, tiaj malfacilaĵoj? Ĉio estas tre simpla. Ni ricevis sufiĉe oportunan ilon, kiu, en kapablaj manoj, ebligas al ni determini ĉu estas problemoj en niaj retoj, ĉu estas problemoj en la respublika reto, aŭ ĉu estas problemoj kun la spino. Se persono plendas pri malalta elŝuta rapideco de iu servo, ni povas mezuri la rapidecon de la kanalo de la abonanto kaj poste kompari ĝin kun tio, kion li ricevas de la servo. Kaj estas racie montri, ke ni honeste atribuas la kanalon specifitan en la kontrakto. Ni ankaŭ povas klarigi la eblajn kialojn de tia diferenco en rapidoj.
Malĉefa solvo
Restas malfermita la demando pri la rapidecfalo en la vesperoj/dum la tago. Kiel fari la samon sen esti ĉe la hejmo de la abonanto? Prenu malmultekostan unu-tabulkarton kun gigabita reto kaj faru tiel nomatan sondilon el ĝi. La aparato devas preni rapidecmezuradon laŭ la kablo je antaŭfiksita tempintervalo. La solvo devus esti malferma fonto, kiel eble plej senpretenda, kun oportuna administra panelo por vidi mezurrezultojn. La aparato estu kiel eble plej malmultekosta por ke ĝi povu esti facile anstataŭigita kaj lasita ĉe la abonanto dum n tagoj sen timo.
Реализация
BananaPI (modelo M1) estis prenita kiel bazo. Estas fakte du kialoj por ĉi tiu elekto.
- Gigabit-haveno.
- Ĝi nur kuŝis en la noktostango.
Poste, estis decidite uzi la python-klienton por la servo Speedtest de Ookla kiel backend por mezuri rapidecon. biblioteko por mezuri ping-rapidecon. Nu, kaj php por la administra panelo. Por facileco de percepto mi uzis .
Pro la fakto, ke la rimedoj de Raspberry ne estas flekseblaj, la kombinaĵo nginx+php-fpm+sqlite3 estis uzata. Mi volis rezigni MySQL pro ĝia pezeco kaj redundo. Mi antaŭvidas demandon pri Iperf. Ĝi devis esti forlasita pro la malebleco uzi ĝin en aliaj direktoj ol lokaj.
Komence mi sekvis la vojon de multaj en ĉi tiu retejo. Modifis la klienton speedtest-cli. Sed poste, iom pripensinte, li forlasis tiun ĉi ideon. Mi skribis mian propran laboriston kiu uzas la kapablojn de la originala kliento.
Por analizi pingojn, mi simple skribis apartan pritraktilon. Ni prenas la mezan valoron de la mezurado. La ping-ilo povas trakti kaj IP-adreson kaj domajnan nomon.
Mi ne atingis nesinkronan laboron. Ĝi ne estas precipe bezonata en ĉi tiu kazo.
La administra panelo por taksi rezultojn montriĝis sufiĉe minimumisma.
Figuro: Ĉefa administra fenestro kun testaj rezultoj
Figuro: Testaj agordoj
Figuro: Ĝisdatigu la liston de Speedtest-serviloj
Tio estas ĉio. La ideo estis efektivigita sur miaj genuoj, en mia libera tempo. Kampaj provoj ankoraŭ ne komenciĝis. Sed ni planas lanĉi prototipojn baldaŭ. Ĝi povas esti uzata kaj de provizantoj tie kaj de klientoj de provizantoj. Neniu ĝenas vin preni mezurojn hejme ĉirkaŭ la horloĝo. La nura afero, kiun vi devas memori, estas, ke se vi aktive navigas interrete aŭ elŝutas ion, tiam la mezurado estos pli malalta ol la vera. Do, ideale, vi devas lasi la sondilon en la reto kiel la sola trafika konsumanto.
PS: bonvolu ne kritiki min pro la kvalito de la kodo. Mi estas memlernanta sen sperto. Fontkodo por . Kritiko estas akceptita.
fonto: www.habr.com