Kako meriti mrežnu latenciju: praktični vodič za programere

Saznajte kako da izmerite mrežnu latenciju uz ovaj sveobuhvatan vodič. Pokrivamo osnovne alate kao što su ping i traceroute, kao i tehnike testiranja zasnovane na pretraživaču.

Kako meriti mrežnu latenciju: praktični vodič za programere

Želite da izmerite latenciju mreže? Možete početi sa jednostavnim, ugrađenim alatima komandne linije kao što su ping i traceroute kako biste brzo dobili uvid u Round-Trip Time (RTT). Ili, možete otvoriti alate za razvoj u vašem pretraživaču da vidite kako kašnjenja utiču na ono što vaši korisnici zapravo doživljavaju.

Ove metode vam daju brz, koristan pregled koliko vremena je potrebno da paket podataka putuje od izvora do odredišta i vrati se nazad.

Zašto je merenje latencije neophodno

Pre nego što pređemo na "kako", hajde da razgovaramo o "zašto". Za programere i mrežne inženjere, latencija nije samo broj na ekranu; to je nevidljiva ruka koja oblikuje celokupno korisničko iskustvo. U današnjim aplikacijama, milisekunde su sve. Čak i malo kašnjenje može biti razlika između usluge koja deluje trenutno i one koja deluje pokvareno.

Pomisli na stvarne posledice:

  • API odgovornost: Jedan spor API poziv može stvoriti domino efekat, usporavajući sve, od učitavanja korisničkog profila do obrade kritične uplate.
  • Tokovi podataka u realnom vremenu: Za online igre, uživo video ili finansijsko trgovanje, niska i dosledna latencija je apsolutna osnova. Bez toga, ove aplikacije jednostavno ne funkcionišu.
  • Zadržavanje korisnika: Postoji direktna veza između sporih web sajtova i aplikacija i viših stopa napuštanja i napuštenih korpi za kupovinu. Ove stvari ozbiljno utiču na krajnji rezultat.

Razlikovanje ključnih koncepata latencije

Da biste tačno izmerili latenciju mreže, morate znati šta gledate. Dva najosnovnija koncepta su Round-Trip Time (RTT) i latencija u jednom pravcu.

RTT je ukupno vreme potrebno da signal ode od tačke A do tačke B i vrati se nazad. To je najčešća metrika koju ćete videti jer je jednostavna za merenje—potrebno je samo pristupiti jednom kraju veze.

Latencija u jednom pravcu, kao što ime sugeriše, meri vreme potrebno da podaci putuju u samo jednom pravcu. Ovo je mnogo složenije merenje jer zahteva savršeno sinhronizovane satove na obe tačke. Međutim, to je daleko precizniji pokazatelj za asimetrične veze, gde se vaši putanje za upload i download ponašaju veoma različito.

Važnost svega ovoga postaje kristalno jasna kada radite ozbiljno testiranje performansi opterećenja, gde se teorija susreće sa stvarnošću i uska grla se otkrivaju.

Da bismo stavili neke brojke na to, stručnjaci za praćenje mreže obično klasifikuju latenciju ovako:

  • Niska latencija: Ispod 50 milisekundi
  • Umerena latencija: 50-150 ms
  • Visoka latencija: Iznad 150 ms

Iz mog iskustva, brzi test na obližnjem serveru može pokazati savršeno prihvatljiv 20-40 ms. Ali taj broj može lako porasti na više od 200 ms za saobraćaj koji mora preći okean, što može biti presudno za performanse vaše aplikacije.

Da bismo razjasnili žargon koji ćete sresti, evo brzog referentnog vodiča.

Ključni koncepti latencije na prvi pogled

Koncept Šta meri Zašto je važno
Latencija (Ping) Vreme potrebno da jedan paket podataka putuje od izvora do odredišta i nazad. Mereno u milisekundama (ms). Ovo je sirova mera kašnjenja. Niska latencija je ključna za aplikacije u realnom vremenu kao što su igre, VoIP i video konferencije.
Round-Trip Time (RTT) Suštinski isto kao latencija, ovo je ukupno trajanje za slanje signala plus vreme za primanje potvrde. RTT je najčešći i praktičan način merenja latencije sa jedne tačke, što ga čini osnovnom metrikom za alate kao što je ping.
Latencija u jednom pravcu Vreme potrebno da paket putuje od izvora do odredišta u jednom pravcu. Pruža detaljniji uvid, posebno za asimetrične mreže gde putanje za upload i download imaju različite latencije.
Jitter Varijacija latencije tokom vremena. Mera je doslednosti vremena dolaska paketa. Visok jitter je jednako loš kao visoka latencija za striming medije i online pozive, uzrokujući trzanje, keširanje i greške.
Propusnost Maksimalna količina podataka koja može biti prenesena preko mrežne veze u datom vremenskom periodu. Mereno u Mbps ili Gbps. Često se meša sa brzinom, propusnost se odnosi na kapacitet. Možete imati visoku propusnost, ali i dalje trpeti visoku latenciju.

Ovi koncepti su osnovni za razumevanje bilo kog problema sa performansama mreže.

Tajmer koji meri milisekunde povezan sa pametnim telefonima i laptopom, ilustrujući latenciju mreže.

Ovo je trenutak kada postaju važni dostupni, integrisani alati. Umesto da pokrećete složene dijagnostičke alate, moderni dodaci za pretraživače i alati za razvoj mogu vam pružiti uvide koji su vam potrebni bez napuštanja vašeg radnog toka. Radi se o tome da merenje latencije postane beznaporno, rutinsko deo izrade i održavanja odličnog softvera.

Uzimanje stvari u svoje ruke sa alatima za latenciju komandne linije

Da biste zaista osetili performanse vaše mreže, morate otvoriti terminal. Komandna linija je mesto gde ćete pronaći osnovne alate koji vam daju sirove, nefiltrirane podatke o vašoj vezi. Radi se o tome da vidite šta se zaista dešava sa paketima koji se kreću između vas i odredišta, i to je osnovni prvi korak za svakog programera koji ozbiljno želi da meri latenciju.

Klasični, osnovni alat je ping. Izuzetno je jednostavan: šalje mali paket podataka (ICMP echo zahtev) na server i samo čeka da se vrati. To jednostavno putovanje je osnova za izračunavanje Round-Trip Time (RTT) i daje vam trenutnu proveru zdravlja veze.

Vaša prva provera latencije sa Pingom

Pokretanje ping testa ne može biti lakše. Pokrenite svoj terminal ili komandni prompt, otkucajte ping, i pratite ga sa domenom koju želite da testirate.

Podrazumevano, ping će se nastaviti zauvek na macOS-u i Linux-u, dok Windows šalje samo četiri paketa i staje. Za bilo koju pravu analizu, želećete da kontrolišete ovo. Slanje deset ili dvadeset paketa daje vam mnogo pouzdaniju sliku stabilnosti veze nego samo nekoliko.

Kada završi, dobićete uredan pregled sa ključnim brojevima:

  • Paketi poslati/primljeni: Ovo vam govori da li je neki podatak izgubljen tokom puta. Čak i mala količina gubitka paketa je veliki crveni signal za probleme sa mrežom.
  • Round-trip min/avg/max/mdev: Ovo su vaši osnovni statistički podaci o latenciji. Dobićete najbolje vreme (min), prosek (avg), i najgore vreme (max). mdev (srednja devijacija) je vaša mera jittera—koliko se latencija razlikuje od jednog paketa do drugog.

Pazite na razliku između vašeg minimuma i maksimuma RTT. Ako je široka, vaša veza je nestabilna, čak i ako prosek izgleda u redu. Ovaj jitter može biti daleko disruptivniji za aplikacije u realnom vremenu kao što su video pozivi ili igre nego veza koja je dosledno malo spora.

Uobičajena greška je samo baciti pogled na prosečan RTT. Prosek od 50ms može izgledati u redu, ali ako je vaš minimum 20ms a maksimum 250ms, korisničko iskustvo će delovati isprekidano i nepouzdano. Uvek gledajte celu paletu da biste razumeli jitter.

Praćenje staze sa Traceroute i MTR

Šta radite kada ping otkrije visoku latenciju ili gubitak paketa? Vaš sledeći zadatak je da otkrijete gde je problem. To je ono za šta je traceroute (ili tracert na Windows-u) namenjen. Mapira celu stazu koju vaši paketi prolaze, pokazujući vam svaki "hop"—svaki ruter—između vašeg računara i konačnog odredišta.

Svaka linija u traceroute izlazu je hop, i obično prikazuje tri odvojena merenja latencije do te tačke. Ovo vam omogućava da precizno odredite da li neki specifičan ruter duž staze uzrokuje značajno usporavanje ili gubitak paketa.

Ali traceroute je trenutni pregled. Za dinamičniji, kontinuirani uvid, većina mrežnih stručnjaka koje poznajem zaklinje se u MTR (My Traceroute). MTR je kao supernapunjen alat koji kombinuje ping i traceroute. Neprekidno šalje pakete na svaki hop na ruti, dajući vam uživo, ažurirani prikaz latencije i gubitka paketa na svakoj tački. Ovo ga čini izuzetno efikasnim u hvatanju povremenih problema koje bi jedan traceroute verovatno propustio.

Zašto je vaš izbor alata važan

Alat koji odaberete i kako ga konfigurišete može drastično promeniti vaše rezultate. Ovo je posebno tačno u ultra-brzim, nisko-latentnim okruženjima kao što su cloud data centri.

Zaista je prilično otkrovenje koliko se brojevi mogu razlikovati. U detaljnom eksperimentu koji je sproveo Google Cloud, standardni ping test je izvestio prosečan RTT od 146 mikrosekundi. Ali kada su koristili drugi alat koji šalje transakcije jedna za drugom bez pauze, RTT je pao na samo 66.59 mikrosekundi—više od dva puta brže!

Ovo je savršen primer zašto ping ponekad može preceniti latenciju. Pokazuje da je razumevanje kako alat funkcioniše ključno za dobijanje merenja kojima možete verovati.

Pronalaženje maksimalne brzine vaše veze sa iperf

Latencija nije uvek cela slika. Ponekad morate znati maksimalnu količinu podataka koju vaša veza može zaista preneti—njenu propusnost. Za taj posao, alat koji želite je iperf.

Dok ping meri kašnjenje, iperf se fokusira na propusnost. Radi tako što postavlja klijent-server vezu i zatim šalje što više podataka može između njih tokom određenog vremenskog perioda.

Da biste koristili iperf, biće vam potrebne dve mašine:

  1. Na jednoj mašini, pokrenite iperf u server modu. Samo će stajati i slušati vezu.
  2. Na drugoj mašini, pokrenite iperf u klijent modu, usmeravajući ga na adresu servera.

Klijent će se povezati i test će početi. Izlaz vam govori ukupne prenesene podatke i, što je najvažnije, bitrate (vaša propusnost) u megabitima ili gigabitima po sekundi. To je savršen način da testirate mrežnu vezu i saznate šta je zaista sposobna.

Merenje latencije iz perspektive korisnika

Dok alati komandne linije daju sirov, nefiltriran pogled na vašu mrežu, jedina latencija koja zaista ima značaj za web aplikaciju je ono što krajnji korisnik zapravo doživljava. Ovo je trenutak kada preusmeravamo fokus sa terminala na sam pretraživač. Ono što se dešava unutar pretraživača govori mnogo bogatiju, relevantniju priču o performansama.

Nikada se ne radi samo o jednom paketu i njegovom putovanju. Latencija koju korisnik oseća je složen koktel DNS pretraga, TCP rukovanja, TLS pregovora, vremena obrade servera, i naravno, vremena potrebnog da se sadržaj zapravo prikaže na ekranu. Na sreću, moderni pretraživači dolaze opremljeni moćnim ugrađenim alatima koji nam pomažu da analiziramo ceo ovaj proces.

Uronite u alate za razvoj pretraživača

Svaki glavni pretraživač—Chrome, Firefox, Edge, Safari—dolazi opremljen paketom alata za razvoj. "Mrežni" tab unutar ovih alata je vaš komandni centar za razumevanje kako se vaš sajt učitava. Prikazuje sve u dijagramu vodopada, što je vizuelni prikaz svakog pojedinačnog zahteva koji pretraživač pravi da prikaže stranicu.

Ovaj prikaz vodopada je neprocenjiv. Možete precizno videti koliko je vremena bilo potrebno da se preuzme svaki resurs, od inicijalnog HTML dokumenta i CSS stilova do slika i API poziva. Što je još važnije, razlaže životni ciklus svakog zahteva na različite faze:

  • DNS pretraga: Vreme potrebno da se razreši naziv domena u IP adresu.
  • Inicijalna veza: Vreme provedeno u uspostavljanju TCP veze sa serverom.
  • SSL/TLS rukovanje: Preopterećenje potrebno za uspostavljanje sigurne veze.
  • Vreme do prvog bajta (TTFB): Ovo je veoma važno. Mera je koliko je pretraživač čekao pre nego što je primio prvi bajt podataka sa servera.
  • Preuzimanje sadržaja: Vreme provedeno u stvarnom preuzimanju resursa.

Visok TTFB, na primer, je klasičan znak sporog backend-a ili problema sa obradom na serveru—nešto što jednostavan ping test nikada ne bi otkrio. Analizom ovog vodopada, možete brzo uočiti koji resursi blokiraju renderovanje ili jednostavno predugo traju da se učitaju.

Ključna lekcija iz mog iskustva je da ne gledate samo na ukupno vreme učitavanja, već da tražite najduže trake u vodopadu. Jedna neoptimizovana slika ili spor API treće strane mogu zadržati celu stranicu kao ta hostage, stvarajući loše korisničko iskustvo čak i ako je ostatak sajta munjevito brz.

Programatsko merenje sa Timing API-ima

Za automatizovana i precizna merenja, možete iskoristiti ugrađene JavaScript API-e pretraživača. Navigation Timing API i Resource Timing API daju vam programatski pristup istim detaljnim podacima o performansama koje vidite u alatima za razvoj. Ovo je savršeno za prikupljanje podataka o stvarnom korisničkom nadzoru (RUM) kako biste razumeli kako vaš sajt funkcioniše za stvarne posetioce širom sveta.

Možete dobiti ove metrike sa samo nekoliko linija JavaScript-a, direktno u konzoli pretraživača. Na primer, da biste dobili osnovne performanse vremena za učitavanje glavne stranice, možete koristiti performance.getEntriesByType('navigation'). Ovo vraća objekat ispunjen vrednim vremenskim oznakama.

Na osnovu tih podataka, možete izračunati vitalne metrike:

  • Vreme DNS pretrage: domainLookupEnd - domainLookupStart
  • Vreme TCP rukovanja: connectEnd - connectStart
  • Vreme do prvog bajta (TTFB): responseStart - requestStart
  • Ukupno vreme učitavanja stranice: loadEventEnd - startTime

Ovaj pristup vam omogućava da izgradite prilagođene kontrolne table ili pošaljete podatke o performansama svojim analitičkim alatima, pružajući vam kontinuirani uvid u stvarne performanse vaše aplikacije. U web razvoju, optimizacija slika je uobičajen način za poboljšanje ovih metrika; za one koji su zainteresovani, imamo koristan vodič o izboru najboljeg formata slike za vašu veb stranicu.

Ubrzavanje provere sa integrisanim alatima

Prebacivanje između terminala, alata za razvoj u pretraživaču i prilagođenih skripti može brzo postati dosadno. Tu integrisane ekstenzije pretraživača mogu zaista olakšati vaš radni tok objedinjavanjem ovih provera. Na primer, ShiftShift Extensions paket uključuje ugrađeni Speed Test alat koji možete odmah otvoriti iz bilo koje kartice.

To vam pruža brz, privatnosti orijentisan način da izmerite brzinu preuzimanja, brzinu otpremanja i latenciju vaše veze bez potrebe da idete na posebnu veb stranicu ili otvarate terminal. Pošto je deo većeg alata, možete izvršiti proveru brzine, formatirati JSON odgovor i proveriti kolačić sve iz iste objedinjene palete komandi. Ova vrsta integracije čini provere performansi prirodnim, bez trenja delom svakodnevnog razvoja.

Kako dizajnirati test latencije koji zaista govori nešto

Bilo ko može da pošalje ping komandu i dobije broj nazad. Ali ako želite podatke kojima možete zaista verovati—podatke koji vam pomažu da donosite prave odluke—morate biti promišljeniji. Jedno, izolovano merenje je samo trenutni snimak. Da biste zaista razumeli ponašanje vaše mreže, morate razmišljati kao detektiv, razmatrajući odakle testirate, koliko često testirate i šta zapravo tražite.

Dobro dizajniran test pretvara sirove brojeve u akcione uvide. Loše dizajniran? To je samo šum.

Dijagram ispod razlaže sve male kašnjenja koja se sabiraju u ono što korisnik oseća kada učitava veb stranicu. To je sjajan podsetnik da jednostavan mrežni ping čak ni ne počinje da govori celu priču.

Dijagram toka koji ilustruje proces latencije korisnika, detaljno prikazujući DNS pretragu, TTFB i DOM učitavanje.

Kao što možete videti, od inicijalne DNS pretrage do konačnog renderovanja, više koraka doprinosi ukupnom vremenu čekanja.

Izbor vaših testnih tačaka

Prvo pravilo pouzdanog testiranja je da geografija ima značaj. Test iz vašeg kancelarije u Njujorku do servera niz ulicu u Nju Džersiju ne govori vam apsolutno ništa o iskustvu vaših kupaca u Tokiju. Da biste dobili realnu sliku, morate testirati iz različitih lokacija koje zapravo odražavaju vašu korisničku bazu.

Vaša lista tačaka treba da pokriva nekoliko ključnih oblasti:

  • Vaši najveći korisnički centri: Gde većina vaših kupaca živi? Testirajte odatle.
  • Međukontinentalni putevi: Pogledajte šta se dešava kada podaci moraju da pređu okean. Testirajte između Evrope i Severne Amerike, ili Azije i SAD-a, da biste razumeli performanse na duge staze.
  • Vaši cloud regioni: Ako ste na AWS, Azure ili GCP, testirajte povezanost do i između specifičnih regiona data centara na kojima se oslanjate.

Širenje vaših testova na ovaj način stvara mnogo tačniju mapu globalnih performansi. Pomaže vam da uočite specifične uska grla u regionima koja biste inače potpuno propustili. Ovo je takođe dobar trenutak da proverite vašu postavku domena; možete pronaći korisne savete o kako proveriti dostupnost domena i srodnim konfiguracijama kako biste osigurali da je sve u redu.

Pronalaženje pravog ritma testiranja

Mrežni uslovi su stalno u promeni. Menjaju se tokom dana, nedelje, pa čak i minuta. Test koji se izvrši u 3 ujutro u utorak može izgledati fantastično, ali taj rezultat je beskoristan ako vaš vrhunac saobraćaja dolazi u 2 popodne u petak kada su svi online.

Da biste dobili pravu osnovu, morate dosledno testirati tokom vremena. Mešajte:

  • Izvršavajte testove tokom vrhunskih poslovnih sati.
  • Planirajte neke za noćne prozore održavanja.
  • Ne zaboravite vikende, kada obrasci saobraćaja mogu biti potpuno drugačiji.

Ponavljanjem uzorkovanja podataka možete izravnati nasumične vrhove i padove. Ovako uočavate ponavljajuće probleme, poput zagušenja mreže svake radne popodne odmah nakon ručka.

Ne zaboravite na jitter

Prosečna latencija je solidna polazna tačka, ali često skriva ozbiljniji problem: jitter. Jitter je jednostavno varijacija u vašoj latenciji tokom vremena. Razmislite o tome—stabilna veza sa predvidljivim 80ms kašnjenjem je često mnogo bolja za aplikacije u realnom vremenu od one koja prosečno ima 50ms ali se divlja između 10ms i 200ms.

Jitter je tiha ubica korisničkog iskustva za sve što je u realnom vremenu, poput VoIP poziva, video konferencija ili online igara. Visok jitter uzrokuje seckanje zvuka, zamrzavanje videa i frustrirajuće vrhove kašnjenja koji čine da aplikacija izgleda potpuno pokvareno, čak i kada prosečna latencija izgleda dobro na papiru.

Razumevanje jitter-a znači gledati izvan proseka. To je neprepoznati zlikovac jer otkriva zašto proseci sami mogu biti tako obmanjujući. Na primer, podaci iz Pandora FMS pokazuju da jitter preko 30ms može povećati stope gubitka paketa u igrama na 15%—dovoljno da igra postane neigriva. Merenje standardne devijacije vaših rezultata latencije je prvi korak ka stavljanju broja na tu nestabilnost.

Lista provere dizajna testa latencije

Da sve ovo povežete, evo brze liste provere koja će vas voditi. Prateći ove korake, pomoći ćete da osigurate da su podaci koje prikupite i tačni i zaista korisni.

Stavka na listi provere Zašto je to važno Akcioni savet
Definišite jasne ciljeve Ne možete meriti ono što ne definišete. Da li rešavate specifičan problem ili uspostavljate osnovu? Zapišite svoj cilj pre nego što počnete. "Dijagnostikujte kašnjenje za korisnike u jugoistočnoj Aziji" je bolji cilj od "proverite latenciju."
Izaberite raznolike tačke Jedan put ne predstavlja vaše globalno korisničko iskustvo. Izaberite 3-5 lokacija: jednu lokalnu, jednu na drugom kontinentu i nekoliko u vašim ključnim korisničkim tržištima.
Uspostavite ritam Jednokratni testovi propuštaju obrasce zasnovane na vremenu poput zagušenja u vrhunskim satima. Planirajte testove da se automatski izvršavaju svake nedelje kako biste uhvatili ceo ciklus ponašanja mreže.
Merite jitter Proseci skrivaju neuredne performanse koje uništavaju aplikacije u realnom vremenu. Ne gledajte samo prosečan RTT. Izračunajte standardnu devijaciju ili koristite alat poput mtr koji prikazuje min/max/prosečnu latenciju.
Koristite prave alate ping je dobar za brzu proveru, ali alati poput mtr ili iperf pružaju dublje uvide. Za web performanse, koristite alate za razvoj u pretraživaču. Za sirove mrežne puteve, mtr je odličan izbor.
Dokumentujte sve Zaboravićete "zašto" iza vašeg testa za šest meseci. Zadržite jednostavan dnevnik: datum, vreme, tačke, korišćeni alat i kratak zapis o onome što ste primetili.

Postajući metodični, prelazite od jednostavnog merenja latencije do njenog pravog razumevanja. Ovaj promišljen pristup je ono što odvaja nasumičan broj od pouzdanog indikatora performansi.

Razumevanje brojeva (i šta izbegavati)

Grafikon koji prikazuje vrhove signala sa povećalom, pored Wi-Fi i Ethernet ikona.

U redu, izvršili ste svoje testove i imate gomilu podataka. Ovo je trenutak kada pravi posao počinje—prevod tih sirovih brojeva u nešto što zaista ima značenje. Podaci vam pričaju priču o zdravlju vaše mreže; samo treba da naučite kako da je pročitate.

Na primer, iznenadni skok u vremenu povratnog puta (RTT) na traceroute je klasičan trag. Ako latencija skoči na trećem skoku i ostane visoka do kraja, verovatno ste pronašli svoj problem: to je taj treći ruter ili veza odmah nakon njega. Ali budite oprezni. Ako samo taj jedan skok pokazuje visoku latenciju, a konačna destinacija je još uvek brza, možda je to samo ruter konfigurisan da de-prioritizuje tačno onakav saobraćaj kakav koristi vaš test. To je uobičajena lažna uzbuna koja vas može odvesti u zabludu.

Dekodiranje jitter-a i gubitka paketa

Gledajući izvan jednostavnog RTT-a, pronaći ćete najkritičnije uvide. Visok jitter, što je samo fancy izraz za neusklađenu latenciju, može biti daleko disruptivniji od latencije koja je dosledno visoka. Ovo je posebno tačno za sve što je u realnom vremenu.

Ako vaši rezultati pokazuju prosečan RTT od 40ms, ali je minimum bio 10ms a maksimum 150ms, vaša veza je nestabilna. Ta ogromna varijacija je upravo ono što uzrokuje dosadne zastoje u video pozivima i frustrirajuće vrhove kašnjenja u online igrama.

Gubitak paketa je još veća crvena zastava. Čak i 1% gubitak paketa može potpuno oslabiti TCP-bazirane aplikacije, primoravajući ih da neprekidno ponovo šalju podatke i usporavajući sve do usporavanja. Kada pogledate svoje rezultate testiranja, svaka stvarna razlika između poslatih i primljenih paketa treba odmah da se istraži.

Jedna od najvećih grešaka koje vidim da ljudi prave je pretpostavka da jedan test govori celu priču. Mrežni uslovi se stalno menjaju. Test koji se izvrši u 3 ujutro će izgledati potpuno drugačije od onog u 3 popodne tokom vrhunskih poslovnih sati. Jedini način da dobijete pravu osnovu performansi je kroz dosledno, ponovljeno testiranje.

Da biste preduhitrili probleme, vredi istražiti posvećene alate za monitoring mrežnih performansi. Ovo menja vaš pristup od frenetike popravljanja stvari kada se pokvare do proaktivnog održavanja zdravlja vaše mreže.

Najčešće greške u merenju

Čak i sa najboljim alatima na svetu, nekoliko jednostavnih grešaka može učiniti vaše rezultate potpuno beskorisnim. Izbegavanje ovih uobičajenih zamki je neophodno ako želite podatke kojima možete zaista verovati.

  • Testiranje preko Wi-Fi-a: Ozbiljno, samo nemojte. Bežične veze su poznate po svojoj nestabilnosti, podložne smetnjama od svega, od mikrotalasnih pećnica do rutera vašeg komšije. Za bilo kakvo ozbiljno testiranje latencije, povežite se putem Ethernet kabla. To je jedini način da dobijete stabilnu, pouzdanu osnovu.
  • Zaboravljanje VPN opterećenja: VPN-ovi su odlični za sigurnost, ali dodaju dodatnu stanicu i enkripciju na putu vašeg saobraćaja. Ovo će uvek povećati latenciju. Ako pokušavate da dijagnostikujete sporu vezu korisnika, jedno od vaših prvih pitanja treba da bude, "Da li ste na VPN-u?" Testiranje sa i bez njega će vam pokazati koliko kašnjenja dodaje.
  • Ignorisanje lokalnog zagušenja mreže: Vaši rezultati testiranja će biti iskrivljeni ako neko drugi na vašoj mreži koristi sav propusni opseg. Ako kolega strimuje 4K video ili preuzima velike datoteke dok testirate, vaši brojevi latencije će biti uvećani, a vi ćete se naći u potrazi za problemom koji ne postoji.

Još jedan suptilan, ali kritičan faktor je alat koji izaberete. Kao što smo pokrili, različiti alati mere latenciju na različite načine. Uvek budite dosledni sa alatima koje koristite za poređenje i uverite se da razumete šta svaki od njih zaista meri—bilo da je to jednostavan ICMP echo ili složen zahtev na aplikacionom nivou. I zapamtite, performanse mogu biti pogođene mnogim slojevima; na primer, ako se bavite web performansama, naš vodič o Cookie Editor Chrome Extension može pokazati kako klijentski elementi igraju ulogu.

Pravilnim tumačenjem vaših rezultata u pravom kontekstu i izbegavanjem ovih uobičajenih grešaka, preći ćete iznad samo prikupljanja brojeva. Počećete da razumete zašto iza performansi vaše mreže, a to je ključ za izgradnju bržih, pouzdanijih sistema.

Česta pitanja o mrežnoj latenciji

Čak i sa pravim alatima, nekoliko uobičajenih pitanja uvek se čini da se pojavljuju kada počnete da istražujete mrežnu latenciju. Hajde da prođemo kroz neka od najčešćih koje čujem kako bismo vam pomogli da razumete svoje rezultate.

Šta je zapravo "dobar" broj latencije?

Ovo je klasično pitanje "zavisi", ali definitivno možemo postaviti neke solidne standarde. "Dobra" latencija je potpuno relativna na ono što pokušavate da postignete.

  • Opšte pretraživanje veba: Za većinu nas, sve ispod 100ms RTT će se činiti savršeno u redu. Stranice se brzo učitavaju, i nećete primetiti nikakvo stvarno kašnjenje.
  • Takmičarsko online igranje: Ovo je mesto gde svaka milisekunda ima značaj. Ozbiljni igrači i trgovci sa visokim frekvencijama traže latenciju daleko ispod 20ms. To je razlika između pobede i gubitka.
  • Video pozivi i VoIP: Ovde je doslednost ključna. Potrebna vam je stabilna latencija ispod 150ms i nizak jitter (manje od 30ms) kako biste izbegli to seckanje, van sinhronizacije ili, još gore, prekinute pozive.

Kao pravilo, većina mrežnih stručnjaka koje poznajem klasifikuje sve ispod 50ms kao nisku latenciju. Od 50-150ms je umerena, a kada pređete 150ms, počećete da osećate usporavanje na većini interaktivnih aplikacija.

Zašto moji ping i rezultati testiranja brzine pretraživača nikada ne odgovaraju?

Ovo je fantastično pitanje i veoma česta tačka zabune. Dešava se zato što komanda ping i test brzine zasnovan na pretraživaču su fundamentalno različiti alati koji mere različite stvari.

Za početak, gotovo sigurno komuniciraju sa različitim serverima. Kada pingujete domen, udarate na specifičnu metu. Test brzine veba, s druge strane, dizajniran je da pronađe geografski blizak server iz svoje mreže kako bi vam dao najbolji mogući rezultat.

Protokoli su takođe potpuno različiti. Ping koristi vrlo lagan protokol nazvan ICMP. Većina testova pretraživača radi preko TCP-a, što zahteva ceo proces postavljanja ( "trostruko rukovanje") samo da bi se uspostavila veza. To inicijalno prebacivanje dodaje malo vremena pre nego što pravi test uopšte počne.

Na kraju, testovi pretraživača često uključuju više od samo čistog vremena putovanja mrežom. Njihov broj "latencije" može uključivati vreme obrade servera ili čak male kašnjenja unutar samog pretraživača, što može uvećati konačnu cifru u poređenju sa sirovim ICMP pingom.

Kako mogu zapravo smanjiti svoju mrežnu latenciju?

Smanjenje latencije se svodi na pronalaženje i eliminisanje uskih grla, bilo da se nalaze u vašem uredu ili širom interneta.

Prvo mesto koje treba proveriti je vaše neposredno okruženje. Najefikasnija promena koju možete napraviti je prelazak sa Wi-Fi na žičanu Ethernet vezu. To je promena koja značajno utiče na stabilnost i brzinu. Ako morate koristiti Wi-Fi, približite se svom ruteru i pređite na 5GHz opseg ako možete—obično je manje zagušen.

Pogledajući šire od vaše lokalne mreže, ponekad zamena DNS-a može pomoći. Korišćenje bržeg DNS servera može skratiti vreme inicijalne veze za milisekunde kada tražite veb sajt.

Ako pokušavate da poboljšate pristup usluzi koju kontrolišete, rešenje je Mreža za isporuku sadržaja (CDN). Ona funkcioniše tako što fizički postavlja kopije vašeg sadržaja bliže vašim korisnicima. A ako koristite VPN, pokušajte da ga isključite. Taj dodatni skok i sloj enkripcije gotovo uvek dodaju latenciju.

Video sam korporativne VPN-ove koji dodaju čak 70ms na vreme povratnog putovanja. To može pretvoriti odličnu vezu u frustrirajuće sporu. Uvek testirajte sa i bez vašeg VPN-a da vidite kakav uticaj na performanse zapravo imate.

Koja je prava razlika između latencije i propusnosti?

Razumevanje ovoga je ključno za razumevanje performansi mreže. Lako je pomešati ih, ali mere dve veoma različite stvari.

Evo analogije koju uvek koristim: zamislite to kao autoput.

  • Propusnost je koliko traka autoput ima. Više traka znači da više automobila (podataka) može putovati u isto vreme.
  • Latencija je ograničenje brzine. Ona određuje koliko brzo jedan automobil (paket podataka) može da pređe od A do B.

Možete imati ogroman autoput sa deset traka (ogromna propusnost) i ograničenje brzine od 20 mph (visoka latencija). Na kraju biste mogli preneti tonu podataka, ali stvari u realnom vremenu poput video poziva bi bile bolno spore. S druge strane, veza sa veoma niskom latencijom deluje neverovatno brzo i responzivno, čak i ako njena propusnost nije ogromna. Za sjajno iskustvo zaista vam je potrebna dobra ravnoteža oboje.


Spremni da testiranje performansi učinite neodvojivim delom vašeg svakodnevnog radnog toka? ShiftShift Extensions paket donosi moćan test brzine, JSON formatirator i desetine drugih alata za programere direktno u vaš pregledač, dostupnih jednim komandom. Prestani da žongliraš sa karticama i počni da radiš pametnije. Preuzmite ShiftShift Extensions besplatno i unapredite svoju produktivnost danas.

Preporučene ekstenzije