Za mnoge naloge so zamude med odjemalcem in strežnikom kritične, na primer pri spletnih igrah, video/glasovnih konferencah, IP telefoniji, VPN itd. Če je strežnik predaleč od odjemalca na ravni omrežja IP, bodo zamude (popularno imenovane "ping", "zamik") motile delo.
Geografska bližina strežnika ni vedno enaka bližini na ravni usmerjanja IP. Tako vam je lahko na primer strežnik v drugi državi »bližje« kot strežnik v vašem mestu. Vse zaradi posebnosti usmerjanja in gradnje omrežja.
Kako izbrati strežnik, ki je čim bližje vsem potencialnim strankam? Kaj je omrežna povezljivost IP? Kako odjemalca usmeriti na najbližji strežnik? Ugotovimo v članku.
Merjenje zamud
Najprej se naučimo meriti zamude. Ta naloga ni tako preprosta, kot se morda zdi, ker se lahko zakasnitve razlikujejo glede na različne protokole in velikosti paketov. Morda boste zamudili tudi kratkoročne dogodke, kot so padci, ki trajajo nekaj milisekund.
ICMP - navaden ping
Uporabili bomo pripomoček Unix ping, ki omogoča ročno nastavitev intervalov med pošiljanjem paketov, česar različica ping za Windows ne zmore. To je pomembno, ker če so med paketi dolgi premori, morda preprosto ne boste videli, kaj se med njimi dogaja.
Velikost paketa (možnost -s) - privzeto pripomoček ping pošilja pakete velikosti 64 bajtov. Pri tako majhnih paketih pojavi, ki se pojavljajo pri večjih paketih, morda ne bodo opazni, zato bomo velikost paketa nastavili na 1300 bajtov.
Interval med paketi (možnost -i) — čas med pošiljanjem podatkov. Privzeto se paketi pošiljajo enkrat na sekundo, to je zelo dolgo, pravi programi pošiljajo na stotine in tisoče paketov na sekundo, zato bomo interval nastavili na 0.1 sekunde. Manj program enostavno ne dopušča.
Posledično je ukaz videti takole:
ping -s 1300 -i 0.1 yandex.ru
Ta zasnova vam omogoča, da vidite bolj realistično sliko zamud.
Ping prek UDP in TCP
V nekaterih primerih se povezave TCP obdelujejo drugače kot paketi ICMP in zaradi tega se meritve lahko razlikujejo glede na protokol. Pogosto se tudi zgodi, da se gostitelj preprosto ne odzove na ICMP in redni ping ne deluje. To na primer gostitelj počne vse življenje. microsoft.com.
Uporabnost od razvijalcev znanega skenerja nmap lahko ustvari poljubne pakete. Uporablja se lahko tudi za merjenje zamud.
Ker UDP in TCP delujeta na določenih vratih, moramo »pingati« določena vrata. Poskusimo pingati TCP 80, to je vrata spletnega strežnika:
$ sudo nping --tcp -p 80 --delay 0.1 -c 0 microsoft.com
Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2020-04-30 13:07 MSK
SENT (0.0078s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
SENT (0.1099s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.2068s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44 seq=1480267007 win=64240 <mss 1440>
SENT (0.2107s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.3046s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44 seq=1480267007 win=64240 <mss 1440>
SENT (0.3122s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.4247s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=42 id=0 iplen=44 seq=2876862274 win=64240 <mss 1398>
Max rtt: 112.572ms | Min rtt: 93.866ms | Avg rtt: 101.093ms
Raw packets sent: 4 (160B) | Rcvd: 3 (132B) | Lost: 1 (25.00%)
Nping done: 1 IP address pinged in 0.43 seconds
Privzeto nping pošlje 4 pakete in se ustavi. Možnost -c 0 omogoča neskončno pošiljanje paketov, za zaustavitev programa morate pritisniti Ctrl+C. Statistika bo prikazana na koncu. Vidimo, da je povprečna vrednost rtt (čas povratnega potovanja) 101 ms.
MTR - traceroute na steroidih
Program My Traceroute je napreden pripomoček za sledenje poti do oddaljenega gostitelja. Za razliko od običajnega sistemskega pripomočka traceroute (v sistemu Windows je to pripomoček tracert) lahko prikaže zakasnitve vsakemu gostitelju v paketni verigi. Prav tako lahko sledi poti ne samo prek ICMP, ampak tudi prek UDP in TCP.
$ sudo mtr microsoft.com
(Klikniti) Programski vmesnik MTR. Začelo se je sledenje poti do microsoft.com
MTR takoj pokaže ping vsakemu gostitelju v verigi, podatki pa se nenehno posodabljajo med delovanjem programa in lahko se vidijo kratkoročne spremembe.
Posnetek zaslona prikazuje, da ima vozlišče št. 6 izgube paketov, vendar to dejansko ni povsem res, ker lahko nekateri usmerjevalniki preprosto zavržejo pakete s pretečenim TTL in ne vrnejo odgovora o napaki, zato lahko podatke o izgubi paketov tukaj prezremo.
WiFi proti kablu
Ta tema ni povsem relevantna za članek, je pa po mojem mnenju v kontekstu zamud zelo pomembna. Zelo obožujem WiFi, a če bom imel vsaj najmanjšo možnost, da se na internet povežem s kablom, jo bom uporabil. Prav tako ljudi vedno odvračam od uporabe WiFi kamer.
Če igrate resne spletne strelce, pretakate video ali trgujete na borzi: uporabite internet prek kabla.
Tukaj je vizualni test za primerjavo WiFi in kabelskih povezav. To je ping do usmerjevalnika WiFi, torej niti interneta še ni.
(Možno klikniti) Primerjava pinga do WiFi usmerjevalnika prek kabla in prek WiFi
Vidi se, da je preko WiFi zakasnitev daljša za 1ms in včasih so paketi z zakasnitvijo desetkrat daljši! In to je le kratek čas. Istočasno isti usmerjevalnik proizvaja stabilne zakasnitve <1ms.
V zgornjem primeru je uporabljen WiFi 802.11n pri 2.4 GHz, na dostopno točko WiFi sta povezana samo prenosnik in telefon. Če bi bilo na dostopni točki več odjemalcev, bi bili rezultati veliko slabši. Zato sem tako proti preklopu vseh pisarniških računalnikov na WiFi, če jih je mogoče doseči s kablom.
IP povezljivost
Torej, naučili smo se meriti zamude do strežnika, poskusimo najti nam najbližji strežnik. Da bi to naredili, lahko pogledamo, kako deluje usmerjanje našega ponudnika. Za to je priročno uporabljati storitev
Ko dostopamo do strani, vidimo, da naš naslov IP pripada avtonomnemu sistemu .
Z vpogledom v graf povezljivosti avtonomnih sistemov lahko vidimo, prek katerih ponudnikov višjega nivoja je naš ponudnik povezan s tujino. Vsaka od pik je klikljiva, lahko vstopite in preberete, za katerega ponudnika gre.
Graf povezljivosti avtonomnih sistemov ponudnika
S tem orodjem lahko preučite, kako so strukturirani kanali katerega koli ponudnika, vključno z gostovanjem. Oglejte si, s katerimi ponudniki je neposredno povezan. Če želite to narediti, morate v iskanje bgp.he.net vnesti naslov IP strežnika in si ogledati graf njegovega avtonomnega sistema. Prav tako lahko razumete, kako je en podatkovni center ali ponudnik gostovanja povezan z drugim.
Večina točk za izmenjavo prometa ponuja posebno orodje, imenovano look glass, ki vam omogoča ping in traceroute iz določenega usmerjevalnika na točki izmenjave.
Tukaj, na primer, iz MGTS
Tako lahko že pri izbiri strežnika vnaprej vidimo, kako bo videti z različnih točk izmenjave prometa. In če se naše potencialne stranke nahajajo na določenem geografskem območju, lahko najdemo optimalno lokacijo za strežnik.
Izberite najbližji strežnik
Odločili smo se poenostaviti postopek iskanja optimalnega strežnika za naše stranke in ustvarili stran s samodejnim testiranjem bližnjih lokacij: .
Ko obiščete stran, skript izmeri zakasnitve od vašega brskalnika do vsakega strežnika in jih prikaže na interaktivnem zemljevidu. Ko kliknete na podatkovni center, se prikažejo informacije z rezultati testiranja.
Gumb vas popelje na stran za preizkus zakasnitve za vse naše podatkovne centre. Za ogled rezultatov testa kliknite na točko podatkovnega centra na zemljevidu
Vir: www.habr.com