För många uppgifter är förseningar mellan klient och server kritiska, till exempel i onlinespel, video/röstkonferenser, IP-telefoni, VPN, etc. Om servern är för långt från klienten på IP-nätverksnivå, kommer fördröjningar (populärt kallade "ping", "lag") att störa arbetet.
En servers geografiska närhet är inte alltid lika med närhet på IP-routingnivå. Så till exempel kan en server i ett annat land vara "närmare" dig än en server i din stad. Allt på grund av särdragen med routing och nätverkskonstruktion.
Hur väljer man en server som är så nära alla potentiella kunder som möjligt? Vad är IP-nätverksanslutning? Hur dirigerar man en klient till närmaste server? Låt oss ta reda på det i artikeln.
Mätning av förseningar
Låt oss först lära oss hur man mäter förseningar. Den här uppgiften är inte så enkel som den kan verka eftersom förseningar kan variera för olika protokoll och paketstorlekar. Du kan också missa kortsiktiga händelser, som fall som varar i några millisekunder.
ICMP - vanlig ping
Vi kommer att använda Unix-pingverktyget; det låter dig manuellt ställa in intervallen mellan att skicka paket, vilket pingversionen för Windows inte kan göra. Detta är viktigt eftersom om det är långa pauser mellan paketen, kanske du helt enkelt inte ser vad som händer mellan dem.
Paketstorlek (alternativ -s) - som standard skickar pingverktyget paket med en storlek på 64 byte. Med så små paket kanske fenomen som uppstår med större paket inte märks, så vi ställer in paketstorleken till 1300 byte.
Intervall mellan paket (alternativ -i) — tid mellan datasändningar. Som standard skickas paket en gång per sekund, detta är väldigt långt, riktiga program skickar hundratals och tusentals paket per sekund, så vi kommer att sätta intervallet till 0.1 sekund. Programmet tillåter helt enkelt inte mindre.
Som ett resultat ser kommandot ut så här:
ping -s 1300 -i 0.1 yandex.ru
Denna design låter dig se en mer realistisk bild av förseningar.
Pinga via UDP och TCP
I vissa fall bearbetas TCP-anslutningar annorlunda än ICMP-paket, och på grund av detta kan mätningarna variera beroende på protokollet. Det händer också ofta att värden helt enkelt inte svarar på ICMP, och vanlig ping fungerar inte. Det är till exempel vad en värd gör hela sitt liv. microsoft.com.
Verktyg från utvecklarna av den berömda skannern nmap kan generera alla paket. Den kan också användas för att mäta förseningar.
Eftersom UDP och TCP fungerar på specifika, måste vi "pinga" en specifik port. Låt oss försöka pinga TCP 80, det vill säga webbserverporten:
$ 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 skickar nping 4 paket och stoppar. Alternativ -c 0 möjliggör oändlig sändning av paket; för att stoppa programmet måste du trycka på Ctrl+C. Statistik kommer att visas i slutet. Vi ser att det genomsnittliga rtt-värdet (tur- och returtid) är 101ms.
MTR - traceroute på steroider
Program My Traceroute är ett avancerat verktyg för att spåra rutter till en fjärrvärd. Till skillnad från det vanliga systemverktyget traceroute (i Windows är detta tracert-verktyget), kan det visa förseningar för varje värd i paketkedjan. Den kan också spåra rutter inte bara via ICMP, utan också via UDP och TCP.
$ sudo mtr microsoft.com
(Klickbart) MTR-programgränssnitt. Ruttspårning till microsoft.com har startat
MTR visar omedelbart ping till varje värd i kedjan, och data uppdateras ständigt medan programmet körs och kortsiktiga förändringar kan ses.
Skärmdumpen visar att nod #6 har paketförluster, men i själva verket är detta inte helt sant, eftersom vissa routrar helt enkelt kan kassera paket med en utgången TTL och inte returnera ett felsvar, så paketförlustdata kan ignoreras här.
WiFi vs kabel
Det här ämnet är inte helt relevant för artikeln, men enligt mig är det väldigt viktigt i samband med förseningar. Jag älskar verkligen WiFi, men om jag har ens den minsta möjlighet att ansluta till internet med en kabel så kommer jag att använda det. Jag avråder också alltid människor från att använda WiFi-kameror.
Om du spelar seriösa online shooters, streamar video eller handlar på börsen: använd internet via kabel.
Här är ett visuellt test för att jämföra WiFi och kabelanslutningar. Detta är en ping till WiFi-routern, det vill säga inte ens internet än.
(Klickbar) Jämförelse av ping till en WiFi-router via kabel och via WiFi
Det kan ses att över WiFi är fördröjningen 1ms längre och ibland finns det paket med tio gånger längre förseningar! Och det här är bara en kort tidsperiod. Samtidigt producerar samma router stabila fördröjningar på <1ms.
I exemplet ovan används WiFi 802.11n vid 2.4GHz, endast en bärbar dator och en telefon är anslutna till WiFi-åtkomstpunkten. Om det fanns fler klienter på åtkomstpunkten skulle resultaten bli mycket sämre. Det är därför jag är så emot att byta alla kontorsdatorer till WiFi om det är möjligt att nå dem med en kabel.
IP-anslutning
Så vi har lärt oss att mäta förseningar till servern, låt oss försöka hitta den server som ligger närmast oss. För att göra detta kan vi titta på hur vår leverantörs routing fungerar. Det är bekvämt att använda tjänsten för detta
När vi går in på sidan ser vi att vår IP-adress tillhör det autonoma systemet .
Genom att titta på anslutningsgrafen för autonoma system kan vi se genom vilka leverantörer på högre nivå vår leverantör är ansluten till resten av världen. Var och en av prickarna är klickbara, du kan gå in och läsa vilken typ av leverantör det är.
Anslutningsdiagram över leverantörens autonoma system
Med det här verktyget kan du studera hur kanalerna hos alla leverantörer, inklusive hosting, är uppbyggda. Se vilka leverantörer den är direkt ansluten till. För att göra detta måste du ange serverns IP-adress i sökningen efter bgp.he.net och titta på grafen för dess autonoma system. Du kan också förstå hur ett datacenter eller en värdleverantör är ansluten till en annan.
De flesta trafikutbytespunkter tillhandahåller ett speciellt verktyg som kallas lookglas, som låter dig pinga och spåra från en specifik router vid utbytespunkten.
Här, till exempel, från MGTS
Så när vi väljer en server kan vi i förväg se hur den kommer att se ut från olika trafikutbytespunkter. Och om våra potentiella kunder finns i ett visst geografiskt område kan vi hitta den optimala platsen för servern.
Välj närmaste server
Vi bestämde oss för att förenkla proceduren för att hitta den optimala servern för våra kunder och skapade en sida med automatisk testning av närliggande platser: .
När du besöker en sida mäter skriptet förseningarna från din webbläsare till varje server och visar dem på en interaktiv karta. När du klickar på ett datacenter visas information med testresultat.
Knappen tar dig till latenstestsidan för alla våra datacenter. För att se testresultaten, klicka på datacenterpunkten på kartan
Källa: will.com