For mange oppgaver er forsinkelser mellom klient og server kritiske, for eksempel i nettspill, video-/talekonferanser, IP-telefoni, VPN osv. Hvis serveren er for langt fra klienten på IP-nettverksnivå, vil forsinkelser (populært kalt "ping", "lag") forstyrre arbeidet.
Geografisk nærhet til en server er ikke alltid lik nærhet på IP-rutingsnivå. Så for eksempel kan en server i et annet land være "nærmere" deg enn en server i byen din. Alt på grunn av særegenhetene ved ruting og nettverksbygging.
Hvordan velge en server som er så nær alle potensielle kunder som mulig? Hva er IP-nettverkstilkobling? Hvordan dirigere en klient til nærmeste server? La oss finne ut av det i artikkelen.
Måling av forsinkelser
La oss først lære hvordan du måler forsinkelser. Denne oppgaven er ikke så enkel som den kan virke fordi forsinkelser kan variere for forskjellige protokoller og pakkestørrelser. Du kan også gå glipp av kortsiktige hendelser, for eksempel fall som varer i noen millisekunder.
ICMP - vanlig ping
Vi vil bruke Unix ping-verktøyet; det lar deg manuelt angi intervallene mellom sending av pakker, noe ping-versjonen for Windows ikke kan gjøre. Dette er viktig fordi hvis det er lange pauser mellom pakkene, kan det hende du rett og slett ikke ser hva som skjer mellom dem.
Pakkestørrelse (alternativ -s) - som standard sender ping-verktøyet pakker på 64 byte i størrelse. Med så små pakker kan det hende at fenomener som oppstår med større pakker ikke merkes, så vi setter pakkestørrelsen til 1300 byte.
Intervall mellom pakker (alternativ -i) — tid mellom datasendinger. Som standard sendes pakker en gang per sekund, dette er veldig langt, ekte programmer sender hundrevis og tusenvis av pakker per sekund, så vi vil sette intervallet til 0.1 sekund. Programmet tillater rett og slett ikke mindre.
Som et resultat ser kommandoen slik ut:
ping -s 1300 -i 0.1 yandex.ru
Denne utformingen lar deg se et mer realistisk bilde av forsinkelser.
Ping via UDP og TCP
I noen tilfeller behandles TCP-tilkoblinger annerledes enn ICMP-pakker, og på grunn av dette kan målinger variere avhengig av protokollen. Det hender også ofte at verten rett og slett ikke svarer på ICMP, og vanlig ping fungerer ikke. Det er det en vert gjør for eksempel hele livet. microsoft.com.
Nytte fra utviklerne av den berømte skanneren nmap kan generere alle pakker. Den kan også brukes til å måle forsinkelser.
Siden UDP og TCP opererer på spesifikke, må vi "pinge" en spesifikk port. La oss prøve å pinge TCP 80, det vil si webserverporten:
$ 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
Som standard sender nping 4 pakker og stopper. Alternativ -c 0 muliggjør endeløs sending av pakker; for å stoppe programmet må du trykke Ctrl+C. Statistikk vil vises på slutten. Vi ser at gjennomsnittlig rtt-verdi (tur-retur-tid) er 101ms.
MTR - traceroute på steroider
Program My Traceroute er et avansert verktøy for å spore ruter til en ekstern vert. I motsetning til det vanlige systemverktøyet traceroute (i Windows er dette tracert-verktøyet), kan det vise forsinkelser til hver vert i pakkekjeden. Den kan også spore ruter ikke bare via ICMP, men også via UDP og TCP.
$ sudo mtr microsoft.com
(Klikkbart) MTR-programgrensesnitt. Rutesporing til microsoft.com startet
MTR viser umiddelbart ping til hver vert i kjeden, og dataene oppdateres kontinuerlig mens programmet kjører og kortsiktige endringer kan sees.
Skjermbildet viser at node #6 har pakketap, men faktisk er dette ikke helt sant, fordi noen rutere ganske enkelt kan forkaste pakker med utløpt TTL og ikke returnere et feilsvar, så pakketapsdataene kan ignoreres her.
WiFi vs kabel
Dette temaet er ikke helt relevant for artikkelen, men etter min mening er det veldig viktig i forbindelse med forsinkelser. Jeg elsker virkelig WiFi, men hvis jeg har selv den minste mulighet til å koble til Internett med en kabel, vil jeg bruke det. Jeg fraråder også alltid folk fra å bruke WiFi-kameraer.
Hvis du spiller seriøse online skytespill, streamer video eller handler på børsen: vennligst bruk Internett via kabel.
Her er en visuell test for å sammenligne WiFi- og kabeltilkoblinger. Dette er et ping til WiFi-ruteren, det vil si ikke engang Internett ennå.
(Klikkbar) Sammenligning av ping til en WiFi-ruter via kabel og via WiFi
Det kan sees at over WiFi er forsinkelsen 1 ms lengre og noen ganger er det pakker med ti ganger lengre forsinkelser! Og dette er bare en kort periode. Samtidig produserer den samme ruteren stabile forsinkelser på <1ms.
I eksemplet ovenfor brukes WiFi 802.11n ved 2.4GHz, kun en bærbar PC og en telefon er koblet til WiFi-tilgangspunktet. Hvis det var flere klienter på tilgangspunktet, ville resultatene vært mye verre. Dette er grunnen til at jeg er så imot å bytte alle kontordatamaskiner til WiFi hvis det er mulig å nå dem med en kabel.
IP-tilkobling
Så vi har lært å måle forsinkelser til serveren, la oss prøve å finne den nærmeste serveren til oss. For å gjøre dette kan vi se på hvordan leverandørens ruting fungerer. Det er praktisk å bruke tjenesten til dette
Når vi går inn på siden ser vi at IP-adressen vår tilhører det autonome systemet .
Ved å se på tilkoblingsgrafen til autonome systemer, kan vi se gjennom hvilke leverandører på høyere nivå leverandøren vår er koblet til resten av verden. Hver av prikkene er klikkbare, du kan gå inn og lese hva slags leverandør det er.
Tilkoblingsgraf over leverandørens autonome systemer
Ved å bruke dette verktøyet kan du studere hvordan kanalene til enhver leverandør, inkludert hosting, er strukturert. Se hvilke leverandører den er direkte koblet til. For å gjøre dette, må du skrive inn serverens IP-adresse i søket etter bgp.he.net og se på grafen til det autonome systemet. Du kan også forstå hvordan ett datasenter eller en vertsleverandør er koblet til en annen.
De fleste trafikkutvekslingspunkter har et spesielt verktøy kalt lookglass, som lar deg pinge og spore fra en bestemt ruter ved utvekslingspunktet.
Her, for eksempel, fra MGTS
Så når vi velger en server, kan vi på forhånd se hvordan den vil se ut fra forskjellige trafikkutvekslingspunkter. Og hvis våre potensielle kunder befinner seg i et bestemt geografisk område, kan vi finne den optimale plasseringen for serveren.
Velg nærmeste server
Vi bestemte oss for å forenkle prosedyren for å finne den optimale serveren for våre klienter og opprettet en side med automatisk testing av nærliggende steder: .
Når du besøker en side, måler skriptet forsinkelsene fra nettleseren til hver server og viser dem på et interaktivt kart. Når du klikker på et datasenter, vises informasjon med testresultater.
Knappen tar deg til latenstestsiden for alle datasentrene våre. For å se testresultatene, klikk på datasenterpunktet på kartet
Kilde: www.habr.com