Mérje meg a hálózati késleltetést, mielőtt ez problémává válna

A hálózat sebességét általában teljesítményként határozzák meg: hány megabites vagy gigabites sebességgel képes a hálózat egy másodperc alatt átjutni a csövein. Ez természetesen fontos, de van egy másik tényező is, amelyet figyelembe kell venni, és manapság ez gyakran legalább annyira fontos (és néha még fontosabb is), mint a nyers sebesség. Ez a tényező a késés. A késleltetés meghatározásának legjobb módja a késés: az az időtartam, amikor egy csomagot vagy csomagcsoportot a forrástól a rendeltetési helyig eljuttatnak, és általában milliszekundumban (ms) mérik. A felhasználók számára még a nagy késési idõbeli különbségeket sem lehet észrevenni a mindennapi alkalmazásuk során. Vagyis ha nem használnak késésfüggő alkalmazásokat. A késéssel kapcsolatos érzékeny alkalmazások listája az utóbbi időben növekszik, ezért a késés olyan fontos. A legtöbb alkalmazás beállíthatja a lassabb latenciát, de néhányuk - különösen azok, amelyek a video streamingre vagy másfajta állandó adattáblára támaszkodnak - kilapulhatnak, ha a minimális késleltetési teljesítmény nem teljesül.

A késleltetés tájának megváltoztatása szempontjából kulcsfontosságú hajtóerő a felhőalapú szolgáltatás. A felhőszolgáltatások, függetlenül attól, hogy magán adatközpontokban vagy nyilvános felhőkben futnak, például az Amazon Web Services (AWS) vagy a Google Cloud, szükségszerűen az adatközponttól távol helyezkednek el. Általában a felhőalapú szolgáltatások elérési útja a nyilvános interneten keresztül vezet. A legtöbb hálózati forgalom esetén az internet-kapcsolat rendben van. De a késleltetés-érzékeny alkalmazások számára az internet kiszámíthatatlan vadon, mely milliszekundum alatt nyugodt lehet, a következő pedig viharos. Ennek oka az, hogy az adatút ki van téve az útválasztás és a feldolgozás késéseinek. Ezek olyan tényezők, amelyeket sem az informatikai személyzet, sem a felhőszolgáltatás informatikai szakemberei nem tudnak ellenőrizni.

Mi a késés?

Kétféle késleltetés létezik, amelyek befolyásolják a felhőszolgáltatásokat. Az egyik az az idő, amely alatt az adatok áthaladnak a hálózaton egyik pontról a másikra. Ezt korlátozza a kapcsolat "vezetéksebessége", vagyis az üvegszálas optikai kábelen keresztüli fénysebesség, vagy a Cat X rézkábel mentén futó adatok jelsebessége. Minden esetben közvetlenül kapcsolódik a megtett távolsághoz. A legfontosabb, hogy az átvitelhez szükséges idő okozta késésekkel nem lehet semmit megtenni, kivéve ha közelebb kerül a felhő-szolgáltatóhoz vagy kiválasztja a használt felhőszolgáltatáshoz legközelebbi szerverhelyet, bár nem minden felhőszolgáltatás adja meg ezt a lehetőséget.

A második típusú késést a késések feldolgozása vagy néha a rossz útválasztás okozza. Minden alkalommal, amikor az adatcsomag áthalad egy eszközön, rövid késleltetés van, amíg az útválasztó vagy a kapcsoló eldönti, hova tovább kell küldeni. További késések vannak a tűzfalakban vagy más biztonsági eszközökben a csomagok ellenőrzése és a kiszolgálók által, amikor adatkérést kapnak, megtalálják a tárolójában, cselekednek a kérésen, és válaszot küldenek. Noha a késések mindegyike rövid, összeadódnak. Időnként, ha az adatközponttól a felhőben lévő adatokig tartó útja túlterhelt, akkor a késések és így a késés valóban összeadódhatnak.

Mérje meg a késést a traceroute segítségével

Szerencsére meglehetősen egyszerű az adatok késleltetésének mérése, és ez semmit sem jelent. Ennek megismeréséhez futtassa a parancssort a választott operációs rendszerben (OS), és hajtsa végre a Traceroute parancsot. A Microsoft Windows rendszerben beírja a "tracert" parancsot a parancssorba, majd a rendeltetési hely nevét, esetleg "aws.amazon.com" vagy "cloud.google.com". (Lásd az alábbi képernyőképet.)

Apple OS X vagy Linux rendszeren ugorjon a terminál ablakra, és írja be: traceroute -I companydomain.com. Alternatív megoldásként a domain nevet kicserélheti egy tényleges IP-címre. Azt szeretné, ha a -I kapcsolót úgy szeretné, hogy a traceroute az Internet Control Message Protocol (ICMP) protokollt használja, amelyre szüksége van a késés pontos méréséhez.

Nem számít az operációs rendszernek, amit a képernyőn lát, az egyes útválasztók válaszai az ellenőrzendő webhely elérési útja mentén, valamint az időmérés mp-ben. Add össze ezeket, és ez a késésed. Ha többször futtatja a parancsot, akkor észreveszi, hogy ugyanazok az útválasztók nem mindig jelennek meg. Ennek oka az, hogy az adatcsomagok a parancs futtatásakor eltérő internetes útvonalakat vehetnek igénybe. Néhány út hosszabb lehet, mint mások, növeli az általános késleltetést. Üdvözöljük a késés az interneten.

Kattintson a képernyőképre a nagyításhoz.

Mérje meg a késést a hálózatkezelő eszközökkel

A vállalati hálózatért felelős informatikai szakembereknek lesz valamilyen hálózati megfigyelő eszköz, amely lehetővé teszi a lapok áttekintését arról, mi fut a vezetékükön és hogyan működik a forgalom. A hálózati késleltetést más módon is ellenőrizheti. Ha ez egy jól bemutatott eszköz, akkor megvannak a saját késleltetési mérési funkciói. Például a Spiceworks-nek saját Traceroute szoftvere van, amely a TCP-t (Transmission Control Protocol) használja, ahelyett, hogy a korábban körvonalazott nyomkövetési funkcióban használt ICMP protokollt használta volna. Ezt a Ping parancsban is használják. Bizonyos esetekben a TCP pontosabb lehet, mivel néhány útválasztót úgy konfigurálnak, hogy ne válaszoljon az ICMP csomagokra.

Egy másik jó példa a Paessler AG, amely a Paessler PRTG Network Monitor-ot értékesíti. Ez az eszköz a többi funkcióval együtt biztosítja a hálózati késleltetést. A Paessler AG rendelkezik szoftverének ingyenes verziójával, valamint ingyenes próbaverzióval. Megvizsgálom a PRTG Network Monitor-ot, beleértve a késleltetési képességeit, miközben tesztem az eszközt egy közelgő PCMag-felülvizsgálathoz.

"A ping-idõn túl, ha ezt minden idõszakban megmérjük, ez a késés alapszintje" - magyarázta Greg Ross, a Paessler AG vezető rendszermérnöke. "Lebonthatja az utat, és kiértékelheti az útvonal minden ugrását. Ezt megtehetjük egy útvonal nyomkövetési számával.

"A másik szempont a szolgáltatásminőség ellenőrzése, amely a jitter és a fordulási időt veszi figyelembe köztem és a végpont között" - mondta Ross. Azt mondta, hogy az ilyen megfigyelés a késés más okait is feltárhatja, például késleltetett csomagokat vagy rendben levő csomagokat.

Csökkentse a késés hatását

Ha alkalmazásai nehézségekbe ütköznek a magas késleltetési időkkel, akkor néhány dolgot megtehetsz a látencia hatásainak enyhítésére, még akkor is, ha nem tudja megszüntetni. Az első annak megvizsgálása, hogy melyik domain névrendszer (DNS) szolgáltatást használja, ha nincs saját DNS-kiszolgálója. A lappangás egyik rejtett oka a késés, amely akkor fordul elő, amikor a használt DNS-kiszolgáló megkeresi az elérni kívánt webhely IP-címét.

Egy távoli DNS-kiszolgáló vezet be a késleltetést, akárcsak az, amely egyszerűen nem teljesít jól. Saját kiszolgálójával csökken a keresési idő, feltéve, hogy a cím szerepel a kiszolgáló tábláiban. Ellenkező esetben meg kell várnia, amíg a következő DNS-kiszolgálót felkéri a sorba. A gyakran látogatott webhelyek esetében ez csökkentheti a késleltetést.

Ha külön kapcsolattal rendelkezik, akkor csökken a késés is, feltéve, hogy valóban elkötelezett, vagyis van egy kapcsolat egy meghatározott vonalon keresztül. Ez fizikai szálas kapcsolat lehet, ha elég közel vagy, vagy egy szállítótól bérelt vonal. Ily módon csökkenti az érintett útválasztók számát, és csökkenti az útválasztási hibák esélyét, amelyek késést okozhatnak.

És természetesen csökkentheti a távolságot. Az M2 Optics által szolgáltatott táblázatok szerint 100 KM rost közel 500 mikrosekundum késleltetést vezet be. Ez fél milliszekundum, tehát láthatja, hogy a távolság hogyan növeli a késleltetést.

Tartsa kicsiben azt a komlószámot

Nem számít, milyen „gyógymódot” használ a késleltetés kezelésére, mindenképpen mérlegelje, hogy ez hogyan befolyásolja a hálózat más aspektusait. Például, ha a felhőt katasztrófa utáni helyreállításhoz (DR) használja, akkor a túl közel történő mozgatás a saját problémáit okozhatja, mivel nem akarja, hogy ugyanaz a katasztrófa a DR webhelyére kerüljön, mint az adatközpont.

Általában csökkentheti a késést, ha csökkenti a komló számát az útjában, és a probléma megoldására többféle módon van lehetőség. A korábban említetteken kívül garantált lehet a sávszélesség a torlódások okozta késés csökkentése érdekében, vagy redundáns szolgáltatók is lehetnek, hogy alkalmazásod valós időben a lehető legkevesebb késéssel választhassa meg az utat.

Noha a fizikai törvények megsértése nélkül nem tudja kiküszöbölni a késést, nem hagyhatja figyelmen kívül. Az olyan népszerű alkalmazásokkal, mint a valós idejű streaming analitika, a videokonferencia és akár a vállalat Voice-over-IP (VoIP) forgalma, mind egyre későbbre érzékenyebbé válnak, ha bekapcsolja a hálózat késleltetését, még mielőtt problémává válik, akkor fizetni fog osztalék a sorban.