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

Želite mjeriti latenciju mreže? Možete početi s jednostavnim, ugrađenim alatima naredbenog retka poput ping i traceroute kako biste brzo dobili uvid u Vrijeme povratnog putovanja (RTT). Ili možete otvoriti alate za razvojne programere u svom pregledniku kako biste vidjeli kako kašnjenja utječu na ono što vaši korisnici zapravo doživljavaju.

Ove metode pružaju vam brzi, korisni pregled koliko vremena treba da podatkovni paket putuje od izvora, dođe do odredišta i vrati se natrag.

Zašto je mjerenje latencije neizbježno

Prije nego što pređemo na "kako", razgovarajmo o "zašto". Za programere i mrežne inženjere, latencija nije samo broj na ekranu; to je nevidljiva ruka koja oblikuje cijelo korisničko iskustvo. U današnjim aplikacijama, milisekunde su sve. Čak i malo kašnjenje može biti razlika između usluge koja se čini trenutnom i one koja se čini pokvarenom.

Pomislite na stvarne posljedice:

• Odgovornost API-ja: Jedan spor API poziv može stvoriti domino efekt, usporavajući sve, od učitavanja korisničkog profila do obrade kritične uplate.
• Podaci u stvarnom vremenu: Za online igre, prijenos uživo ili financijsko trgovanje, niska i dosljedna latencija je apsolutna osnova. Bez toga, ove aplikacije jednostavno ne rade.
• Zadržavanje korisnika: Postoji izravna poveznica između sporih web stranica i aplikacija i viših stopa napuštanja i napuštenih košarica. Ove stvari ozbiljno utječu na konačni rezultat.

Razlikovanje ključnih pojmova latencije

Da biste točno izmjerili latenciju mreže, morate znati što gledate. Dva najosnovnija pojma su Vrijeme povratnog putovanja (RTT) i latencija u jednom smjeru.

RTT je ukupno vrijeme potrebno da signal ode od točke A do točke B i vrati se natrag. To je najčešća mjera koju ćete vidjeti jer je jednostavna za mjerenje—samo trebate pristup jednom kraju veze.

Latencija u jednom smjeru, kao što ime sugerira, mjeri vrijeme potrebno da podaci putuju samo u jednom smjeru. Ovo je mnogo složenije mjerenje jer zahtijeva savršeno sinkronizirane satove na oba kraja. Međutim, to je daleko precizniji pokazatelj za asimetrične veze, gdje se vaši putovi za prijenos i preuzimanje ponašaju vrlo različito.

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

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

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

Iz mog iskustva, brzi test na obližnji poslužitelj može pokazati savršeno prihvatljiv 20-40 ms. No, taj broj može lako narasti na više od 200 ms za promet koji mora prijeći ocean, što može biti prekretnica za performanse vaše aplikacije.

Da bismo razumjeli žargon s kojim ćete se susresti, evo brzog referentnog vodiča.

Ključni pojmovi latencije na prvi pogled

Pojam	Što mjeri	Zašto je važan
Latencija (Ping)	Vrijeme potrebno da jedan podatkovni paket putuje od izvora do odredišta i natrag. Mjeri se u milisekundama (ms).	Ovo je sirova mjera kašnjenja. Niska latencija je ključna za aplikacije u stvarnom vremenu poput igara, VoIP-a i videokonferencija.
Vrijeme povratnog putovanja (RTT)	U osnovi isto kao latencija, ovo je ukupno trajanje za slanje signala plus vrijeme potrebno za primanje potvrde.	RTT je najčešći i praktičan način mjerenja latencije s jedne točke, što ga čini mjerom za alate poput ping.
Latencija u jednom smjeru	Vrijeme potrebno da paket putuje od izvora do odredišta u jednom smjeru.	Pruža detaljniji uvid, posebno za asimetrične mreže gdje putovi za prijenos i preuzimanje imaju različite latencije.
Jitter	Varijacija latencije tijekom vremena. Mjeri dosljednost vremena dolaska paketa.	Visok jitter je jednako loš kao i visoka latencija za streaming medija i online pozive, uzrokujući trzanje, keširanje i greške.
Propusnost	Maksimalna količina podataka koja se može prenijeti preko mrežne veze u određenom vremenskom razdoblju. Mjeri se u Mbps ili Gbps.	Često se miješa s brzinom, propusnost se odnosi na kapacitet. Možete imati visoku propusnost, ali i dalje patiti od visoke latencije.

Ovi pojmovi su temelji za razumijevanje bilo kojeg problema s performansama mreže.

Ovdje postaje važno imati dostupne, integrirane alate. Umjesto da pokrećete složene dijagnostičke alate, moderni dodaci za preglednike i alati za razvoj mogu vam pružiti uvide koji su vam potrebni bez napuštanja vašeg radnog toka. Riječ je o tome da mjerenje latencije postane beznaporno, rutinsko dio izrade i održavanja izvrsnog softvera.

Uzimanje u obzir alata za latenciju naredbenog retka

Da biste stvarno osjetili performanse svoje mreže, morate otvoriti terminal. Naredbeni redak je mjesto gdje ćete pronaći temeljne alate koji vam daju sirove, nefiltrirane podatke o vašoj vezi. Riječ je o tome da vidite što se stvarno događa s paketima koji se kreću između vas i odredišta, i to je bitan prvi korak za svakog programera koji ozbiljno želi mjeriti latenciju.

Klasični, osnovni alat je ping. Izuzetno je jednostavan: šalje mali podatkovni paket (ICMP echo zahtjev) na poslužitelj i samo čeka da se vrati. To jednostavno povratno putovanje je osnova za izračunavanje Vrijeme povratnog putovanja (RTT) i daje vam trenutnu provjeru zdravlja veze.

Vaša prva provjera latencije s Pingom

Pokretanje ping testa ne može biti lakše. Pokrenite svoj terminal ili naredbeni prozor, upišite ping i slijedite ga s domenom koju želite testirati.

Prema zadanim postavkama, ping će se nastaviti zauvijek na macOS-u i Linuxu, dok Windows šalje samo četiri paketa i prestaje. Za bilo koju pravu analizu, želite kontrolirati ovo. Slanje deset ili dvadeset paketa daje vam mnogo pouzdaniju sliku stabilnosti veze nego samo nekoliko.

Jednom kada završi, dobit ćete uredan sažetak s ključnim brojevima:

• Poslani/primljeni paketi: Ovo vam govori je li došlo do gubitka podataka tijekom puta. Čak i mali gubitak paketa je veliki crveni alarm za probleme s mrežom.
• Vrijeme povratnog putovanja min/avg/max/mdev: Ovo su vaši osnovni statistički podaci o latenciji. Dobivate najbolje vrijeme (min), prosjek (avg) i najgore vrijeme (max). mdev (srednja devijacija) je vaša mjera jittera—koliko se latencija razlikuje od jednog paketa do drugog.

Pazite na razliku između vašeg minimalnog i maksimalnog RTT-a. Ako je široka, vaša veza je nestabilna, čak i ako prosjek izgleda u redu. Ovaj jitter može biti daleko disruptivniji za aplikacije u stvarnom vremenu poput video poziva ili igara nego veza koja je dosljedno malo spora.

Uobičajena greška je samo baciti pogled na prosječni RTT. Prosjek od 50ms može izgledati u redu, ali ako je vaš minimum 20ms a maksimum 250ms, korisničko iskustvo će se činiti nesigurnim i nepouzdanim. Uvijek gledajte cijeli raspon kako biste razumjeli jitter.

Praćenje staze s Traceroute i MTR

Što radite kada ping otkrije visoku latenciju ili gubitak paketa? Vaš sljedeći zadatak je otkriti gdje je problem. To je ono za što je traceroute (ili tracert na Windowsu) namijenjen. Mapira cijeli put koji vaši paketi prolaze, pokazujući vam svaki "skok"—svaki usmjerivač—između vašeg računala i konačnog odredišta.

Svaka linija u traceroute izlazu je skok, a obično prikazuje tri odvojena mjerenja latencije do te točke. Ovo vam omogućuje da precizno odredite uzrokuje li određeni usmjerivač duž puta 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 poput supernapunjenog alata koji kombinira ping i traceroute. Neprestano šalje pakete na svaki skok na ruti, dajući vam uživo, ažurirani prikaz latencije i gubitka paketa na svakoj točki. Ovo ga čini izuzetno učinkovitim u hvatanju povremenih problema koje bi jedan traceroute vjerojatno propustio.

Zašto vaš izbor alata ima značaj

Alat koji odaberete i kako ga konfigurirate može drastično promijeniti vaše rezultate. Ovo je posebno istinito u ultra-brzim, niskolatencijskim okruženjima poput oblaka podataka.

Zaista je prilično otkriće koliko se brojevi mogu razlikovati. U detaljnom eksperimentu koji je proveo Google Cloud, standardni ping test izvijestio je o prosječnom RTT-u od 146 mikrosekundi. No, kada su koristili drugi alat koji šalje transakcije jedna za drugom bez pauze, RTT je pao na samo 66.59 mikrosekundi—više od dvostruko brže!

Ovo je savršen primjer zašto ping ponekad može precijeniti latenciju. Pokazuje da je razumijevanje kako alat radi ključno za dobivanje mjerenja kojima možete vjerovati.

Pronalaženje maksimalne brzine vaše veze s iperf

Latencija nije uvijek cijela slika. Ponekad trebate znati maksimalnu količinu podataka koju vaša veza zapravo može prenijeti—njenu propusnost. Za taj posao, alat koji želite je iperf.

Dok ping mjeri kašnjenje, iperf se fokusira na propusnost. Radi tako da postavlja klijent-poslužitelj vezu i zatim šalje što više podataka može između njih tijekom određenog vremenskog razdoblja.

Da biste koristili iperf, trebat će vam dva računala:

1. Na jednom računalu pokrenite iperf u modu poslužitelja. Samo će stajati i slušati vezu.
2. Na drugom računalu pokrenite iperf u modu klijenta, usmjeravajući ga na adresu poslužitelja.

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 za stresno testiranje mrežne veze i otkrivanje što ona zapravo može.

Mjerenje latencije iz perspektive korisnika

Dok alati naredbenog retka 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. Ovdje preusmjeravamo naš fokus s terminala na sam preglednik. Ono što se događa unutar preglednika govori mnogo bogatiju, relevantniju priču o performansama.

Nikada se ne radi samo o jednom povratnom putovanju paketa. Latencija koju korisnik osjeća je složeni koktel DNS pretraživanja, TCP rukovanja, TLS pregovora, vremena obrade poslužitelja i, naravno, vremena potrebnog za stvarno prikazivanje sadržaja na ekranu. Na sreću, moderni preglednici dolaze opremljeni moćnim ugrađenim alatima koji nam pomažu analizirati cijeli ovaj proces.

Uronite u alate za razvoj preglednika

Svaki glavni preglednik—Chrome, Firefox, Edge, Safari—opremljen je paketom alata za razvoj. Kartica "Mreža" unutar ovih alata je vaš zapovjedni centar za razumijevanje kako se vaša stranica učitava. Sve prikazuje u dijagramu vodopada, što je vizualni prikaz svakog pojedinog zahtjeva koji preglednik šalje za prikaz stranice.

Ovaj prikaz vodopada je neprocjenjiv. Možete precizno vidjeti koliko je vremena svakom resursu trebalo za preuzimanje, od početnog HTML dokumenta i CSS stilova do slika i API poziva. Što je još važnije, razlaže životni ciklus svakog zahtjeva u različite faze:

• DNS pretraživanje: Vrijeme potrebno za rješavanje imena domene u IP adresu.
• Početna veza: Vrijeme provedeno uspostavljajući TCP vezu s poslužiteljem.
• SSL/TLS rukovanje: Preopterećenje potrebno za uspostavljanje sigurne veze.
• Vrijeme do prvog bajta (TTFB): Ovo je velika stvar. Mjeri koliko je dugo preglednik čekao prije nego što je primio prvi bajt podataka s poslužitelja.
• Preuzimanje sadržaja: Vrijeme provedeno zapravo preuzimajući resurs.

Visok TTFB, na primjer, klasičan je znak sporog backend-a ili problema s obradom na strani poslužitelja—nešto što jednostavan ping test nikada ne bi otkrio. Analizom ovog vodopada možete brzo uočiti koji resursi blokiraju prikazivanje ili jednostavno predugo traju za učitavanje.

Ključna lekcija iz mog iskustva je ne gledati samo na ukupno vrijeme učitavanja, već tražiti najduže trake u vodopadu. Jedna neoptimizirana slika ili spor API treće strane mogu zadržati cijelu stranicu kao ta hostage, stvarajući loše korisničko iskustvo čak i ako je ostatak stranice munjevito brz.

Programatsko mjerenje s Timing API-jima

Za automatizirana i precizna mjerenja, možete iskoristiti ugrađene JavaScript API-je preglednika. 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 razumjeli kako vaša stranica funkcionira za stvarne posjetitelje širom svijeta.

Ove metrike možete dobiti s nekoliko redaka JavaScript-a, izravno u konzoli preglednika. Na primjer, za dobivanje osnovnih vremenskih mjerenja performansi za glavno učitavanje stranice, možete koristiti performance.getEntriesByType('navigation'). Ovo vraća objekt ispunjen vrijednim vremenskim oznakama.

Iz tih podataka možete izračunati vitalne metrike:

• Vrijeme DNS pretraživanja: domainLookupEnd - domainLookupStart
• Vrijeme TCP rukovanja: connectEnd - connectStart
• Vrijeme do prvog bajta (TTFB): responseStart - requestStart
• Ukupno vrijeme učitavanja stranice: loadEventEnd - startTime

Ovaj pristup omogućuje vam izradu prilagođenih nadzornika ili slanje podataka o performansama vašim 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 zainteresirane, imamo koristan vodič o odabiru najboljeg formata slike za vašu web stranicu.

Ubrzavanje provjera s integriranim alatima

Prebacivanje između terminala, alata za razvoj preglednika i prilagođenih skripti može brzo postati dosadno. Tu integrirane ekstenzije preglednika mogu značajno olakšati vaš radni proces unificirajući te provjere. Na primjer, ShiftShift Extensions paket uključuje ugrađeni Speed Test alat koji možete odmah otvoriti iz bilo koje kartice.

To vam daje brz, privatnosti usmjeren način za mjerenje brzine preuzimanja, brzine prijenosa i latencije vaše veze bez potrebe za navigacijom na zasebnu web stranicu ili otvaranjem terminala. Budući da je dio većeg alata, možete izvršiti provjeru brzine, formatirati JSON odgovor i provjeriti kolačić sve iz iste unificirane palete naredbi. Ova vrsta integracije čini provjere performansi prirodnim, bez trenja dijelom svakodnevnog razvojnog procesa.

Kako dizajnirati test latencije koji zapravo daje korisne informacije

Svako može pokrenuti ping naredbu i dobiti broj. No, ako želite podatke kojima možete vjerovati—podatke koji vam pomažu donijeti stvarne odluke—morate biti promišljeni. Jedno, izolirano mjerenje je samo trenutni snimak. Da biste doista razumjeli ponašanje vaše mreže, morate razmišljati kao detektiv, uzimajući u obzir odakle testirate, koliko često testirate i što zapravo tražite.

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

U dijagramu u nastavku razrađuju se svi mali kašnjenja koja se zbrajaju u ono što korisnik osjeća kada učitava web stranicu. To je odličan podsjetnik da jednostavni mrežni ping ne počinje ni približno pričati cijelu priču.

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

Odabir vaših testnih krajnjih točaka

Prvo pravilo pouzdanog testiranja je da geografija ima značaj. Test iz vašeg ureda u New Yorku do poslužitelja niz ceste u New Jerseyju ne govori apsolutno ništa o iskustvu vaših kupaca u Tokiju. Da biste dobili realističnu sliku, morate testirati iz raznolikih lokacija koje zapravo odražavaju vašu korisničku bazu.

Vaš popis krajnjih točaka trebao bi obuhvatiti nekoliko ključnih područja:

• Vaši najveći korisnički centri: Gdje većina vaših kupaca živi? Testirajte odatle.
• Međukontinentalne staze: Pogledajte što se događa kada podaci moraju prijeći ocean. Testirajte između Europe i Sjeverne Amerike, ili Azije i SAD-a, kako biste razumjeli dugoročne performanse.
• Vaši oblačni regije: Ako ste na AWS-u, Azure-u ili GCP-u, testirajte povezivost do i između specifičnih regija podatkovnih centara na kojima se oslanjate.

Širenje vaših testova na ovaj način stvara mnogo točniju kartu globalnih performansi. Pomaže vam u prepoznavanju specifičnih uskih grla koja biste inače potpuno propustili. Ovo je također dobar trenutak da dvostruko provjerite vašu postavku domene; možete pronaći korisne savjete o kako provjeriti dostupnost domene i srodnim konfiguracijama kako biste osigurali da je sve u redu.

Pronalaženje pravog ritma testiranja

Mrežni uvjeti su stalno u promjeni. Mijenjaju se tijekom dana, tjedna, pa čak i minute. Test koji se provodi u 3 ujutro u utorak može izgledati fantastično, ali taj rezultat je beskoristan ako vaš vršni promet dolazi u 14 sati u petak kada su svi online.

Da biste dobili pravi osnovni nivo, morate dosljedno testirati tijekom vremena. Miješajte:

• Izvršite testove tijekom vršnih poslovnih sati.
• Planirajte neke za noćne prozore održavanja.
• Ne zaboravite vikende, kada obrasci prometa mogu biti potpuno drugačiji.

Ponovnim uzorkovanjem podataka možete izgladiti nasumične vrhove i padove. Tako prepoznajete ponavljajuće probleme, poput zagušenja mreže svakog radnog dana poslijepodne odmah nakon ručka.

Ne zaboravite na jitter

Prosječna latencija je solidna polazna točka, ali često skriva zloćudniji problem: jitter. Jitter je jednostavno varijacija vaše latencije tijekom vremena. Razmislite o tome—stabilna veza s predvidljivim 80ms kašnjenjem često je mnogo bolja za aplikacije u stvarnom vremenu od one koja prosječuje 50ms ali divlja između 10ms i 200ms.

Jitter je tiha ubica korisničkog iskustva za sve što je u stvarnom vremenu, poput VoIP poziva, video konferencija ili online igara. Visok jitter uzrokuje preskočeni zvuk, zamrznuti video i frustrirajuće kašnjenje koje čini da aplikacija izgleda potpuno slomljeno, čak i kada prosječna latencija izgleda dobro na papiru.

Razumijevanje jittera znači gledati izvan prosjeka. To je neprepoznati zlikovac jer otkriva zašto prosjeci sami mogu biti tako obmanjujući. Na primjer, podaci iz Pandora FMS pokazuju da jitter preko 30ms može povećati stope gubitka paketa u igrama na 15%—dovoljno da igru učini neigrivom. Mjerenje standardne devijacije vaših rezultata latencije prvi je korak ka stavljanju broja na tu nestabilnost.

Popis za provjeru dizajna testa latencije

Da sve to povežete, evo brzog popisa za provjeru koji će vas voditi. Slijedeći ove korake pomoći će osigurati da su podaci koje prikupite i točni i zaista korisni.

Stavka popisa za provjeru	Zašto je to važno	Akcijski savjet
Definirajte jasne ciljeve	Ne možete mjeriti ono što ne definirate. Rješavate li specifičan problem ili uspostavljate osnovnu liniju?	Zapišite svoj cilj prije nego što počnete. "Dijagnosticirati kašnjenje za korisnike u jugoistočnoj Aziji" bolji je cilj od "provjeriti latenciju."
Odaberite raznolike krajnje točke	Jedna staza ne predstavlja vaše globalno korisničko iskustvo.	Odaberite 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 temeljen na vremenu poput zagušenja u vršnim satima.	Planirajte testove da se automatski pokreću svake sat vremena tijekom tjedna kako biste uhvatili puni ciklus ponašanja mreže.
Mjerite jitter	Prosjeci skrivaju neuredne performanse koje uništavaju aplikacije u stvarnom vremenu.	Ne gledajte samo prosječni RTT. Izračunajte standardnu devijaciju ili koristite alat poput mtr koji prikazuje min/max/avg latenciju.
Koristite prave alate	ping je dobar za brzu provjeru, ali alati poput mtr ili iperf pružaju dublje uvide.	Za web performanse koristite alate za razvoj preglednika. Za sirove mrežne staze, mtr je odličan izbor.
Dokumentirajte sve	Zaboravit ćete "zašto" iza vašeg testa za šest mjeseci.	Zadržite jednostavan dnevnik: datum, vrijeme, krajnje točke, korišteni alat i kratku bilješku o onome što ste primijetili.

Metodičkim pristupom prelazite iz jednostavnog mjerenja latencije u stvarno razumijevanje iste. Ovaj promišljeni pristup ono je što odvaja nasumični broj od pouzdane indikacije performansi.

Razumijevanje brojeva (i što izbjegavati)

U redu, pokrenuli ste svoje testove i imate hrpu podataka. Ovdje počinje pravi posao—prevođenje tih sirovih brojeva u nešto što zapravo ima smisla. Podaci vam pričaju priču o zdravlju vaše mreže; samo trebate naučiti kako je čitati.

Na primjer, iznenadni skok u vremenu povratnog putovanja (RTT) na traceroute je klasičan trag. Ako latencija skoči na trećem skoku i ostane visoka do kraja, vjerojatno ste pronašli svoj problem: to je taj treći usmjerivač ili veza odmah nakon njega. No, budite oprezni. Ako samo taj jedan skok pokazuje visoku latenciju, a konačno odredište je još uvijek brzo, možda je to samo usmjerivač konfiguriran da deprioritizira točno onakvu vrstu prometa koju vaš test koristi. To je uobičajena lažna uzbuna koja vas može odvesti u zabludu.

Dekodiranje jittera i gubitka paketa

Gledajući izvan jednostavnog RTT-a, pronaći ćete najkritičnije uvide. Visok jitter, što je samo fancy izraz za neurednu latenciju, može biti daleko disruptivniji od latencije koja je dosljedno visoka. Ovo je posebno istinito za sve što je u stvarnom vremenu.

Ako vaši rezultati pokazuju prosječni 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 trzaje u video pozivima i kašnjenja koja izazivaju bijes u online igrama.

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

Jedna od najvećih grešaka koje vidim da ljudi čine je pretpostavka da jedan test govori cijelu priču. Mrežni uvjeti se stalno mijenjaju. Test proveden u 3 ujutro izgledat će potpuno drugačije od onog u 3 popodne tijekom vršnih poslovnih sati. Jedini način da dobijete pravi osnovni nivo performansi je kroz dosljedno, ponovljeno testiranje.

Da biste se suočili s problemima, vrijedi istražiti posvećene alate za praćenje mrežnih performansi. Ovo mijenja vaš pristup od frenetike popravljanja stvari kada se pokvare do proaktivnog održavanja zdravlja vaše mreže.

Najčešće greške u mjerenju

Čak i s najboljim alatima na svijetu, nekoliko jednostavnih grešaka može učiniti vaše rezultate potpuno beskorisnima. Izbjegavanje ovih uobičajenih zamki je ne pregovarati ako želite podatke kojima možete vjerovati.

• Testiranje preko Wi-Fi-a: Ozbiljno, samo nemojte. Bežične veze su poznate po svojoj nestabilnosti, sklone smetnjama od svega, od mikrovalnih pećnica do usmjerivača vašeg susjeda. Za bilo kakvo ozbiljno testiranje latencije, priključite se Ethernet kabelom. To je jedini način da dobijete stabilnu, pouzdanu osnovnu liniju.
• Zaboravljanje na VPN opterećenje: VPN-ovi su odlični za sigurnost, ali dodaju dodatnu stanicu i enkripciju na putu vašeg prometa. Ovo će uvijek povećati latenciju. Ako pokušavate dijagnosticirati sporu vezu korisnika, jedno od vaših prvih pitanja treba biti, "Jeste li na VPN-u?" Testiranje s i bez njega pokazat će vam točno koliko kašnjenja dodaje.
• Ignoriranje lokalnog zagušenja mreže: Vaši rezultati testiranja bit će iskrivljeni ako netko drugi na vašoj mreži koristi svu propusnost. Ako kolega strimuje 4K video ili preuzima velike datoteke dok testirate, vaši brojevi latencije bit će napuhani, a vi ćete završiti jureći problem koji ne postoji.

Još jedan suptilan, ali kritičan faktor je alat koji odaberete. Kao što smo obradili, različiti alati mjere latenciju na različite načine. Uvijek budite dosljedni s alatima koje koristite za usporedbu i osigurajte da razumijete što svaki od njih zapravo mjeri—bilo da se radi o jednostavnom ICMP ehu ili složenom zahtjevu na razini aplikacije. I zapamtite, performanse mogu biti pogođene mnogim slojevima; na primjer, ako se bavite web performansama, naš vodič o Cookie Editor Chrome Extension može pokazati kako elementi s klijentske strane igraju ulogu.

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

Česta pitanja o mrežnoj latenciji

Čak i s pravim alatima, nekoliko uobičajenih pitanja uvijek se čini da se pojavljuju kada počnete istraživati mrežnu latenciju. Prođimo kroz neka od najčešćih koje čujem kako bismo vam pomogli da razumijete svoje rezultate.

Što je zapravo "dobar" broj latencije?

Ovo je klasično pitanje "to ovisi", ali definitivno možemo postaviti neke čvrste standarde. "Dobra" latencija potpuno je relativna na ono što pokušavate postići.

• Općenito pregledavanje weba: Za većinu nas, sve ispod 100ms RTT će se činiti savršeno u redu. Stranice se brzo učitavaju, a nećete primijetiti nikakvo stvarno kašnjenje.
• Natjecateljsko online igranje: Ovdje svaka milisekunda ima značaj. Ozbiljni igrači i trgovci s visokom frekvencijom traže latenciju daleko ispod 20ms. To je razlika između pobjede i gubitka.
• Video pozivi i VoIP: Ovdje je dosljednost ključna. Trebate stabilnu latenciju ispod 150ms i nizak jitter (manje od 30ms) kako biste izbjegli taj preskočeni, nesinkronizirani osjećaj ili, još gore, prekinute pozive.

Kao pravilo, većina mrežnih stručnjaka koje poznajem klasificira sve ispod 50ms kao nisku latenciju. Od 50-150ms je umjerena, a kada pređete 150ms, počinjete osjećati usporavanje na većini interaktivnih aplikacija.

Zašto moji ping i rezultati brzinskog testa preglednika nikada ne odgovaraju?

Ovo je fantastično pitanje i super uobičajena točka zbunjenosti. To se događa jer je naredba ping i brzinski test preglednika temeljno različiti alati koji mjere različite stvari.

Za početak, gotovo sigurno komuniciraju s različitim poslužiteljima. Kada pingate domenu, ciljate specifičnu metu. Brzinski test weba, s druge strane, dizajniran je da pronađe geografski blizak poslužitelj iz svoje vlastite mreže kako bi vam dao najbolji mogući rezultat.

Protokoli su također potpuno različiti. Ping koristi vrlo lagani protokol nazvan ICMP. Većina testova preglednika radi preko TCP-a, što zahtijeva cijeli proces postavljanja (trokutasta razmjena) samo da bi se uspostavila veza. To inicijalno uzajamno slanje dodaje malo vremena prije nego što pravi test uopće počne.

Konačno, testovi preglednika često uključuju više od samo vremena putovanja mrežom. Njihov broj "latencije" može uključivati vrijeme obrade poslužitelja ili čak male kašnjenja unutar samog preglednika, što može napuhati konačni broj u usporedbi s sirovim ICMP pingom.

Kako mogu zapravo smanjiti svoju mrežnu latenciju?

Smanjenje latencije je sve o pronalaženju i uklanjanju uskih grla, bilo da se nalaze u vašem uredu ili širom interneta.

Prvo mjesto za provjeru je vaše neposredno okruženje. Najefikasnija promjena koju možete napraviti je prelazak s Wi-Fi na žičnu Ethernet vezu. To je promjena koja značajno poboljšava stabilnost i brzinu. Ako morate koristiti Wi-Fi, približite se svom usmjerivaču i prebacite se na 5GHz opseg ako možete—obično je manje zagušen.

Pogledajući izvan vaše lokalne mreže, ponekad zamjena DNS-a može pomoći. Korištenje bržeg DNS poslužitelja može skratiti milisekunde od vremena inicijalne veze kada tražite web stranicu.

Ako pokušavate poboljšati pristup usluzi koju kontrolirate, rješenje je Mreža za isporuku sadržaja (CDN). Ona funkcionira tako da fizički smješta kopije vašeg sadržaja bliže vašim korisnicima. A ako koristite VPN, pokušajte ga isključiti. Taj dodatni skok i sloj enkripcije gotovo uvijek dodaju latenciju.

Vidjela sam korporativne VPN-ove koji dodaju čak 70ms na vrijeme povratka. To može pretvoriti odličnu vezu u frustrirajuće sporu. Uvijek testirajte s i bez vašeg VPN-a kako biste vidjeli kakav udarac na performanse zapravo trpite.

Koja je stvarna razlika između latencije i propusnosti?

Ispravno razumijevanje ovoga je temeljno za razumijevanje performansi mreže. Lako ih je pomiješati, ali mjere dvije vrlo različite stvari.

Evo analogije koju uvijek koristim: zamislite to kao autocestu.

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

Možete imati ogromnu autocestu s deset traka (ogromna propusnost) s ograničenjem brzine od 20 mph (visoka latencija). Na kraju biste mogli premjestiti tonu podataka, ali stvari u stvarnom vremenu poput video poziva bile bi bolno spore. S druge strane, veza s vrlo niskom latencijom djeluje nevjerojatno brzo i responzivno, čak i ako njena propusnost nije ogromna. Za sjajno iskustvo stvarno vam je potrebna dobra ravnoteža oboje.

---

Spremni ste učiniti testiranje performansi neodvojivim dijelom vašeg svakodnevnog radnog toka? Suite ShiftShift Extensions stavlja moćan Speed Test, JSON formatator i desetke drugih alata za programere izravno u vaš preglednik, dostupnih s jednom naredbom. Prestani žonglirati karticama i počni raditi pametnije. Preuzmite ShiftShift Extensions besplatno i unaprijedite svoju produktivnost danas.