Paljude ülesannete puhul on viivitused kliendi ja serveri vahel kriitilised, näiteks võrgumängudes, video-/häälkonverentsides, IP-telefonis, VPN-is jne. Kui server on IP-võrgu tasemel kliendist liiga kaugel, segavad viivitused (rahvapäraselt "ping", "lag") tööd.
Serveri geograafiline lähedus ei ole alati võrdne lähedusega IP-marsruutimise tasemel. Näiteks võib mõnes teises riigis asuv server olla teile "lähedasem" kui teie linna server. Kõik on tingitud marsruutimise ja võrgu ehitamise iseärasustest.
Kuidas valida server, mis on võimalikult lähedal kõigile potentsiaalsetele klientidele? Mis on IP-võrgu ühenduvus? Kuidas klienti lähimasse serverisse suunata? Uurime artiklist.
Viivituste mõõtmine
Esiteks, õppigem mõõtma viivitusi. See ülesanne ei ole nii lihtne, kui võib tunduda, sest viivitused võivad erinevate protokollide ja pakettide suuruse puhul erineda. Samuti võite vahele jätta lühiajalisi sündmusi, näiteks mõne millisekundi kestvaid langusi.
ICMP – tavaline ping
Kasutame Unixi pingi utiliiti, mis võimaldab teil käsitsi määrata pakettide saatmise vahelised intervallid, mida Windowsi pingi versioon ei suuda. See on oluline, sest kui pakettide vahel on pikki pause, ei pruugi te lihtsalt näha, mis nende vahel toimub.
Pakendi suurus (valik -s) – vaikimisi saadab ping-utiliit 64 baidi suuruseid pakette. Nii väikeste pakettide puhul ei pruugi suuremate pakettide puhul esinevad nähtused olla märgatavad, mistõttu paneme paketi suuruseks 1300 baiti.
Pakettide vaheline intervall (valik -i) – aeg andmete saatmise vahel. Vaikimisi saadetakse pakette üks kord sekundis, see on väga pikk, tegelikud programmid saadavad sadu ja tuhandeid pakette sekundis, seega määrame intervalliks 0.1 sekundit. Programm lihtsalt ei luba vähemat.
Selle tulemusena näeb käsk välja selline:
ping -s 1300 -i 0.1 yandex.ru
See disain võimaldab teil näha viivitustest realistlikumat pilti.
Ping UDP ja TCP kaudu
Mõnel juhul töödeldakse TCP-ühendusi teisiti kui ICMP-pakette ja seetõttu võivad mõõtmised protokollist olenevalt erineda. Samuti juhtub sageli, et host lihtsalt ei reageeri ICMP-le ja tavaline ping ei tööta. Seda teeb näiteks peremees terve elu. microsoft.com.
Utiliit kuulsa skanneri arendajatelt saab nmap genereerida mis tahes pakette. Seda saab kasutada ka viivituste mõõtmiseks.
Kuna UDP ja TCP töötavad kindlatel, peame konkreetse pordi "pingitama". Proovime pingida TCP 80, st veebiserveri porti:
$ 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
Vaikimisi saadab nping 4 paketti ja peatab. Võimalus -c 0 võimaldab lõputult pakette saata, programmi peatamiseks tuleb vajutada Ctrl+C. Statistika kuvatakse lõpus. Näeme, et keskmine rtt (edasi-tagasi aeg) väärtus on 101 ms.
MTR - traceroute steroididel
Programm My Traceroute on täiustatud utiliit marsruutide jälgimiseks kaughostini. Erinevalt tavalisest süsteemiutiliidist traceroute (Windowsis on see tracert-utiliit), võib see näidata viivitusi igale paketiahela hostile. Samuti saab see jälgida marsruute mitte ainult ICMP, vaid ka UDP ja TCP kaudu.
$ sudo mtr microsoft.com
(Klõpsatav) MTR programmi liides. Algas marsruudi jälgimine saidile microsoft.com
MTR näitab pingi koheselt igale ahelas olevale hostile ning programmi töötamise ajal uuendatakse andmeid pidevalt ja on näha lühiajalisi muudatusi.
Ekraanipildil on näha, et sõlmel #6 on paketikadusid, kuid tegelikult ei vasta see päris tõele, sest mõned ruuterid võivad aegunud TTL-iga paketid lihtsalt ära visata ja veavastust ei tagasta, mistõttu saab paketikadude andmeid siin ignoreerida.
WiFi vs kaabel
See teema ei ole artikli jaoks täiesti asjakohane, kuid minu arvates on see viivituste kontekstis väga oluline. Armastan väga WiFi-d, aga kui mul on vähegi võimalus kaabliga internetti ühendada, siis kasutan seda. Samuti ei julgustan ma inimesi alati WiFi-kaameraid kasutamast.
Kui mängite tõsiseid võrgupille, striimite videoid või kauplete börsil: kasutage Internetti kaabli kaudu.
Siin on visuaalne test WiFi- ja kaabliühenduste võrdlemiseks. See on ping WiFi-ruuterile, st isegi mitte veel Internetti.
(Klõpsatav) WiFi-ruuteriga kaabli ja WiFi kaudu pingimise võrdlus
On näha, et üle WiFi on viivitus 1ms pikem ja vahel on pakette, mille viivitus on kümme korda pikem! Ja see on vaid lühike ajavahemik. Samal ajal toodab sama ruuter stabiilseid viivitusi <1 ms.
Ülaltoodud näites kasutatakse WiFi 802.11n sagedusel 2.4 GHz, WiFi pääsupunktiga on ühendatud ainult sülearvuti ja telefon. Kui pöörduspunktis oleks rohkem kliente, oleksid tulemused palju halvemad. Seetõttu olen ma väga vastu kõikide kontoriarvutite WiFi-le lülitamisele, kui neid on võimalik kaabliga kätte saada.
IP-ühenduvus
Niisiis, oleme õppinud mõõtma serveri viivitusi, proovime leida meile lähima serveri. Selleks saame vaadata, kuidas meie teenusepakkuja marsruutimine töötab. Selleks on teenust mugav kasutada
Saidile sisenedes näeme, et meie IP-aadress kuulub autonoomsesse süsteemi .
Vaadates autonoomsete süsteemide ühenduvusgraafikut, näeme, milliste kõrgema taseme pakkujate kaudu on meie pakkuja muu maailmaga ühendatud. Kõik punktid on klõpsatavad, saate sisse minna ja lugeda, mis teenusepakkujaga on tegemist.
Pakkuja autonoomsete süsteemide ühenduvusgraafik
Selle tööriista abil saate uurida, kuidas on üles ehitatud mis tahes pakkuja kanalid, sealhulgas hostimine. Vaadake, milliste pakkujatega see on otse ühendatud. Selleks peate sisestama bgp.he.net otsingusse serveri IP-aadressi ja vaatama selle autonoomse süsteemi graafikut. Samuti saate aru, kuidas üks andmekeskus või hostingu pakkuja on teisega ühendatud.
Enamik liikluse vahetuspunkte pakuvad spetsiaalset tööriista, mida nimetatakse vaateklaasiks, mis võimaldab teil vahetuspunktis konkreetselt ruuterilt pingida ja jälgida.
Näiteks siin MGTS-ist
Seega saame serverit valides eelnevalt näha, kuidas see erinevatest liikluse vahetuspunktidest välja näeb. Ja kui meie potentsiaalsed kliendid asuvad teatud geograafilises piirkonnas, leiame serverile optimaalse asukoha.
Valige lähim server
Otsustasime oma klientidele optimaalse serveri leidmise protseduuri lihtsustada ja lõime lehe, kus on lähedalasuvate asukohtade automaatne testimine: .
Kui külastate lehte, mõõdab skript viivitused teie brauserist igasse serverisse ja kuvab need interaktiivsel kaardil. Kui klõpsate andmekeskusel, kuvatakse teave koos testitulemustega.
Nupp viib teid kõigi meie andmekeskuste latentsustesti lehele. Katsetulemuste vaatamiseks klõpsake kaardil andmekeskuse punkti
Allikas: www.habr.com