Vir baie take is vertragings tussen die kliënt en bediener van kritieke belang, byvoorbeeld in aanlynspeletjies, video-/stemkonferensies, IP-telefonie, VPN, ens. As die bediener op die IP-netwerkvlak te ver van die kliënt af is, sal vertragings (algemeen "ping", "lag") met werk inmeng.
Geografiese nabyheid van 'n bediener is nie altyd gelyk aan nabyheid op die IP-roeteervlak nie. So, byvoorbeeld, kan 'n bediener in 'n ander land "nader" aan jou wees as 'n bediener in jou stad. Alles as gevolg van die eienaardighede van roetering en netwerkkonstruksie.
Hoe om 'n bediener te kies wat so na as moontlik aan alle potensiële kliënte is? Wat is IP-netwerkverbinding? Hoe om 'n kliënt na die naaste bediener te rig? Kom ons vind uit in die artikel.
Meet vertragings
Kom ons leer eers hoe om vertragings te meet. Hierdie taak is nie so eenvoudig soos dit mag lyk nie, want vertragings kan verskil vir verskillende protokolle en pakkiegroottes. Jy kan ook korttermyn-gebeurtenisse mis, soos dalings wat 'n paar millisekondes duur.
ICMP - gereelde ping
Ons sal die Unix-ping-nutsding gebruik; dit laat jou toe om die intervalle tussen die stuur van pakkies handmatig in te stel, wat die ping-weergawe vir Windows nie kan doen nie. Dit is belangrik, want as daar lang pouses tussen pakkies is, kan jy eenvoudig nie sien wat tussen hulle gebeur nie.
Pakkie grootte (opsie -s) - by verstek stuur die ping-hulpprogram pakkies van 64 grepe groot. Met sulke klein pakkies sal verskynsels wat met groter pakkies voorkom dalk nie opmerklik wees nie, so ons sal die pakkiegrootte op 1300 grepe stel.
Interval tussen pakkies (opsie -i) — tyd tussen dataversendings. By verstek word pakkies een keer per sekonde gestuur, dit is baie lank, regte programme stuur honderde en duisende pakkies per sekonde, so ons sal die interval op 0.1 sekonde stel. Die program laat eenvoudig nie minder toe nie.
As gevolg hiervan lyk die opdrag soos volg:
ping -s 1300 -i 0.1 yandex.ru
Hierdie ontwerp laat jou toe om 'n meer realistiese prentjie van vertragings te sien.
Ping via UDP en TCP
In sommige gevalle word TCP-verbindings anders verwerk as ICMP-pakkies, en as gevolg hiervan kan metings verskil afhangende van die protokol. Dit gebeur ook dikwels dat die gasheer eenvoudig nie op ICMP reageer nie, en gereelde ping werk nie. Dit is wat 'n gasheer byvoorbeeld sy hele lewe lank doen. microsoft.com.
Nuts van die ontwikkelaars van die bekende skandeerder nmap kan enige pakkies genereer. Dit kan ook gebruik word om vertragings te meet.
Aangesien UDP en TCP op spesifiekes werk, moet ons 'n spesifieke poort "ping". Kom ons probeer om TCP 80 te ping, dit wil sê die webbedienerpoort:
$ 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
By verstek stuur nping 4 pakkies en stop. Opsie -c 0 maak eindelose stuur van pakkies moontlik; om die program te stop, moet jy Ctrl+C druk. Statistieke sal aan die einde gewys word. Ons sien dat die gemiddelde rtt (heen en terug-tyd) waarde 101ms is.
MTR - traceroute op steroïede
Program My Traceroute is 'n gevorderde hulpmiddel om roetes na 'n afgeleë gasheer op te spoor. Anders as die gewone stelselhulpmiddel traceroute (in Windows is dit die tracert-hulpmiddel), kan dit vertragings aan elke gasheer in die pakkieketting wys. Dit kan ook roetes opspoor, nie net via ICMP nie, maar ook via UDP en TCP.
$ sudo mtr microsoft.com
(Klikbare) MTR-programkoppelvlak. Roete-opsporing na microsoft.com het begin
MTR wys onmiddellik die ping aan elke gasheer in die ketting, en die data word voortdurend opgedateer terwyl die program loop en korttermynveranderinge kan gesien word.
Die skermkiekie wys dat node #6 pakkieverliese het, maar in werklikheid is dit nie heeltemal waar nie, want sommige routers kan eenvoudig pakkies met 'n verstreke TTL weggooi en nie 'n foutreaksie terugstuur nie, so die pakkieverliesdata kan hier geïgnoreer word.
WiFi vs kabel
Hierdie onderwerp is nie heeltemal relevant tot die artikel nie, maar na my mening is dit baie belangrik in die konteks van vertragings. Ek is baie lief vir WiFi, maar as ek net die geringste geleentheid het om met 'n kabel aan die internet te koppel, sal ek dit gebruik. Ek raai mense ook altyd af om WiFi-kameras te gebruik.
As jy ernstige aanlyn shooters speel, video stroom of op die aandelebeurs handel dryf: gebruik asseblief die internet via kabel.
Hier is 'n visuele toets om WiFi en kabelverbindings te vergelyk. Dit is 'n ping na die WiFi-roeteerder, dit wil sê, nog nie eens die internet nie.
(Klikbaar) Vergelyking van ping met 'n WiFi-roeteerder via kabel en via WiFi
Dit kan gesien word dat oor WiFi die vertraging 1ms langer is en soms is daar pakkies met vertragings tien keer langer! En dit is net 'n kort tydperk. Terselfdertyd produseer dieselfde router stabiele vertragings van <1ms.
In die voorbeeld hierbo word WiFi 802.11n by 2.4GHz gebruik, slegs 'n skootrekenaar en 'n foon is aan die WiFi-toegangspunt gekoppel. As daar meer kliënte op die toegangspunt was, sou die resultate baie erger wees. Dit is hoekom ek so daarteen is om alle kantoorrekenaars na WiFi oor te skakel as dit moontlik is om hulle met 'n kabel te bereik.
IP konneksie
So, ons het geleer om vertragings na die bediener te meet, kom ons probeer om die naaste bediener aan ons te vind. Om dit te doen, kan ons kyk hoe ons verskaffer se roete werk. Dit is gerieflik om die diens hiervoor te gebruik
Wanneer ons toegang tot die webwerf kry, sien ons dat ons IP-adres aan die outonome stelsel behoort .
Deur na die verbindingsgrafiek van outonome stelsels te kyk, kan ons sien deur watter hoërvlakverskaffers ons verskaffer aan die res van die wêreld gekoppel is. Elkeen van die kolletjies is klikbaar, jy kan ingaan en lees watter soort verskaffer dit is.
Verbindingsgrafiek van die verskaffer se outonome stelsels
Deur hierdie hulpmiddel te gebruik, kan u bestudeer hoe die kanale van enige verskaffer, insluitend hosting, gestruktureer is. Kyk met watter verskaffers dit direk gekoppel is. Om dit te doen, moet u die bediener se IP-adres in die soektog na bgp.he.net invoer en na die grafiek van sy outonome stelsel kyk. U kan ook verstaan hoe een datasentrum of gasheerverskaffer aan 'n ander gekoppel is.
Die meeste verkeersuitruilpunte bied 'n spesiale hulpmiddel genaamd kykglas, wat jou in staat stel om van 'n spesifieke roeteerder by die uitruilpunt te ping en naspoor.
Byvoorbeeld, van MGTS
Dus, wanneer ons 'n bediener kies, kan ons vooraf sien hoe dit sal lyk vanaf verskillende verkeersuitruilpunte. En as ons potensiële kliënte in 'n sekere geografiese gebied geleë is, kan ons die optimale ligging vir die bediener vind.
Kies die naaste bediener
Ons het besluit om die prosedure vir die vind van die optimale bediener vir ons kliënte te vereenvoudig en het 'n bladsy geskep met outomatiese toetsing van nabygeleë liggings: .
Wanneer jy 'n bladsy besoek, meet die skrif die vertragings van jou blaaier na elke bediener en wys dit op 'n interaktiewe kaart. Wanneer jy op 'n datasentrum klik, word inligting met toetsresultate vertoon.
Die knoppie neem jou na die latency-toetsbladsy vir al ons datasentrums. Om die toetsresultate te sien, klik op die datasentrumpunt op die kaart
Bron: will.com