🥇Võitlus millisekundite nimel. Kuidas valida server, millel on madalaim ping

Paljude ülesannete puhul on kliendi ja serveri vahelised viivitused kriitilise tähtsusega, näiteks online-mängudes, video-/häälekonverentsides, IP-telefonis, VPN-is jne. Kui server asub kliendist liiga kaugel IP-võrgu tasandil, siis viivitused (rahva seas tuntud kui "ping", "lag") segavad tööd.

Serveri geograafiline läheduse ei tähenda alati IP-ruteerimise tasandil lähedust. Näiteks võib server teises riigis olla "lähemal" kui server teie linnas. Kõik sõltub ruteerimise ja võrkude ehituse eripäradest.

Kuidas valida serverit, mis on võimalikult lähedal kõigile potentsiaalsetele klientidele? Mis on IP-võrkude seotuse tähendus? Kuidas suunata klient lähimasse serverisse? Vaatame artiklis.

Mõõdame viivitusi

Alustuseks õpime mõõtma viivitusi. See ülesanne ei ole nii lihtne, kui esmapilgul tundub, sest erinevate protokollide ja pakettide suuruste korral võivad viivitused erineda. Samuti ei pruugi märgata lühiajalisi nähtusi, näiteks mõnemillisekundilisi katkemisi.

ICMP — tavaline ping

Kasutame Unix'i tööriista ping, mis võimaldab käsitsi seada pakettide saatmise vahemaid, mida Windowsi versioon ping ei oska. See on oluline, sest kui pakettide vahelised pausid on liiga pikad, ei pruugi me lihtsalt näha, mis nende vahel toimub.

Paketi suurus (valik -s) — vaikimisi saatab ping tööriist 64-baidiseid pakette. Nii väikeste paketide puhul võivad olla märkamata nähtused, mis ilmnevad suuremate pakkide korral, seetõttu seame paketi suuruseks 1300 baiti.

Pakettide vaheline intervall (valik -i) — aeg andmete saatmise vahel. Vaikimisi saadetakse paketid kord sekundis, mis on väga kaua, kuna päris programmid saadavad sadu ja tuhandeid pakette sekundis, seega seame intervalli 0.1 sekundile. Vähemale ei anna programm lihtsalt luba.

Lõppude lõpuks näeb käsk välja nii:

ping -s 1300 -i 0.1 yandex.ru

Selline konstruktsioon võimaldab näha realistlikumat viivituste pilti.

Ping UDP ja TCP kaudu

Mõnel juhul töödeldakse TCP-ühendusi teisiti kui ICMP-pakette, mistõttu mõõtmistulemused võivad erineda protokolli põhjal. Tihti ei vasta host lihtsalt ICMP-le ja tavaline ping ei tööta. Näiteks on host seda kogu elu teinud. microsoft.com.

Tööriist nping tuntud skanneri nmap arendajatelt, suudab genereerida kõiki pakette. Seda saab kasutada ka viivituste mõõtmiseks.
Kuna UDP ja TCP töötavad teatud portidel, peame 'pingima' konkreetset porti. Proovime pingi TCP 80, st veebiserveri porti:

$ sudo nping --tcp -p 80 --delay 0.1 -c 0 microsoft.com

Käivitamine Nping 0.7.80 ( https://nmap.org/nping ) 2020-04-30 13:07 MSK
SAATIS (0.0078s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
SAATIS (0.1099s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
SAADUD (0.2068s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44  seq=1480267007 win=64240 
SAATIS (0.2107s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
SAADUD (0.3046s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44  seq=1480267007 win=64240 
SAATIS (0.3122s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
SAADUD (0.4247s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=42 id=0 iplen=44  seq=2876862274 win=64240 

Max rtt: 112.572ms | Min rtt: 93.866ms | Avg rtt: 101.093ms
Toorikud saadetud: 4 (160B) | Vastatud: 3 (132B) | Kaotatud: 1 (25.00%)
Nping valmis: 1 IP-aadress pingitud 0.43 sekundi jooksul

Vaikimisi saadab nping 4 paketti ja peatub. Valik -c 0 lubab pidevat pakettide saatmist, programm tuleb peatada, vajutades Ctrl+C. Lõpus näidatakse statistikat. Näeme, et keskmine rtt (round-trip time) väärtus on 101ms.

MTR — traceroute steroidide peal

Programm MTR (ingl. My Traceroute) — arenenud tööriist kaughosti marsruudiga jälgimiseks. Erinevalt tavalisest süsteemiteenusest traceroute (Windowsis on see tööriist tracert) suudab see näidata viivitusi iga hostini, kuhu pakett liigub. Samuti oskab see marsruute jälgida mitte ainult ICMP, vaid ka UDP ja TCP kaudu.

$ sudo mtr microsoft.com

(Kliki) MTR programmi liides. Marsruudi jälgimine microsoft.com juurde on käimas.

MTR näitab kohe ping'i iga hosti kohta marsruudis, andmed uuenevad pidevalt, kui programm on käimas, ja saab näha lühiajalisi muudatusi.
Kuvatud ekraanipildil on näha, et sõlmes nr 6 on pakettide kaotus, kuid tegelikult ei ole see päris nii, kuna mõned marsruuterid võivad lihtsalt jätta aegunud TTL-iga paketid tagasi saatmata ning mitte anda veateadet, seega võib siinsed andmed pakettide kaotuse kohta ignoreerida.

WiFi vs kaabel

See teema ei ole täiesti seotud artikliga, kuid minu arvates on see viivituste kontekstis väga oluline. Ma armastan WiFi-d, kuid kui mul on võimalus internetti kaabli kaudu ühendada, siis kasutan seda. Samuti heidan alati inimesi tagasi WiFi kaamerate kasutamisest.
Kui mängite tõsiseid veebivideosid, edastate voogedastust või kauplete börsil, palun kasutage kaabliühendust.

Siin on visuaalne test WiFi ja kaabliühenduse võrdlemiseks. See on ping WiFi ruuterile, seega ei ole see isegi veel internet.

(Kliki siia) WiFi ruuteri pingute võrdlemine kaabli ja WiFi kaudu

On näha, et WiFi kaudu on viivitused 1ms suuremad ja mõnikord on pakette, mille viivitused on kümme korda suuremad! Ja see on ainult lühike ajavahemik. Samal ajal annab sama ruuter stabiilsed viivitused <1ms.

Ülaltoodud näites kasutatakse WiFi 802.11n 2.4GHz sagedusel, WiFi ligipääsupunktiga on ühendatud ainult sülearvuti ja telefon. Kui ligipääsupunktis oleks rohkem kliente, oleks tulemused palju halvemad. Just sellepärast olen vastu kõigi kontorite arvutite üleviimisele WiFi-le, kui on võimalus neid kaabli kaudu ühendada.

IP ühendus

Nii et oleme õppinud mõõtma viivitusi serverini, proovime leida meie lähedal asuva serveri. Selleks saame vaadata, kuidas meie teenusepakkuja marsruudistamine on organiseeritud. Selleks on mugav kasutada teenust bgp.he.net

Saitidele sisenedes näeme, et meie IP-aadress kuulub autonoomsele süsteemile AS42610.

Vaadates autonoomsete süsteemide seotuse graafikut, saame näha, mille kaudu meie pakkuja on seotud ülejäänud maailmaga. Iga punkt on klikkitav, võimaldades tutvuda, mis ettevõte see on.

Autonoomsete süsteemide seotuse graafik pakkuja jaoks

Selle tööriista abil on võimalik uurida, kuidas on seotud mis tahes pakkujate kanalid, sealhulgas hostimine. Vaadake, millega nad on otse ühendatud. Selleks tuleb otsingusse sisestada bgp.he.net IP-aadress ja vaadata tema autonoomse süsteemi graafikut. Samuti võib mõista, kuidas üks andmekeskus või hostingu pakkuja on seotud teisega.

Enamik tõhususe vahetuspunktidest pakub spetsiaalset tööriista, mida nimetatakse looking glass, mis võimaldab teha ping'i ja traceroute'i konkreetse ruuteri küljest vahetuspunktis.

Näiteks looking glass MTT kaudu

Nii et serveri valida, saame eelnevalt vaadata, kuidas ta välja näeb erinevatest tõhususe vahetuspunktidest. Ja kui meie potentsiaalsed kliendid asuvad teatud geograafilises piirkonnas, saame leida optimaalse serveri asukoha.

Valime lähima serveri

Oleme otsustanud lihtsustada meie klientide jaoks optimaalse serveri leidmise protsessi ja loonud lehe automaatse lähima asukohtade testi jaoks: RUVDS andmekeskused.
Lehe külastamisel mõõdab skript viivituseid teie brauserist igasse serverisse ja kuvab need interaktiivsel kaardil. Andmekeskusele klikkides kuvatakse testitulemuste teave.