Monissa tehtävissä asiakkaan ja palvelimen väliset viiveet ovat kriittisiä, esimerkiksi verkkopeleissä, video-/äänineuvotteluissa, IP-puheluissa, VPN:ssä jne. Jos palvelin on liian kaukana asiakkaasta IP-verkkotasolla, viiveet (yleensä "ping", "lag") häiritsevät työtä.
Palvelimen maantieteellinen läheisyys ei aina vastaa IP-reititystason läheisyyttä. Joten esimerkiksi palvelin toisessa maassa voi olla "lähempänä" sinua kuin palvelin kaupungissasi. Kaikki johtuu reitityksen ja verkon rakentamisen erityispiirteistä.
Kuinka valita palvelin, joka on mahdollisimman lähellä kaikkia potentiaalisia asiakkaita? Mikä on IP-verkkoyhteys? Kuinka ohjata asiakas lähimmälle palvelimelle? Otetaan selvää artikkelista.
Viiveiden mittaaminen
Ensin opetellaan mittaamaan viiveitä. Tämä tehtävä ei ole niin yksinkertainen kuin miltä se saattaa näyttää, koska viiveet voivat vaihdella eri protokollien ja pakettikokojen mukaan. Saatat myös missata lyhytaikaisia tapahtumia, kuten muutaman millisekunnin kestäviä laskuja.
ICMP - tavallinen ping
Käytämme Unix ping -apuohjelmaa, jonka avulla voit asettaa manuaalisesti pakettien lähetysvälit, mitä Windowsin ping-versio ei pysty tekemään. Tämä on tärkeää, koska jos pakettien välillä on pitkiä taukoja, et ehkä yksinkertaisesti näe, mitä niiden välillä tapahtuu.
Paketin koko (optio -s) - oletusarvoisesti ping-apuohjelma lähettää paketteja, joiden koko on 64 tavua. Tällaisilla pienillä paketeilla suuremmilla paketeilla esiintyvät ilmiöt eivät välttämättä ole havaittavissa, joten asetamme paketin kooksi 1300 tavua.
Pakettien välinen aikaväli (vaihtoehto -i) — aika datalähetysten välillä. Oletuksena paketit lähetetään kerran sekunnissa, tämä on erittäin pitkä, oikeat ohjelmat lähettävät satoja ja tuhansia paketteja sekunnissa, joten asetamme väliksi 0.1 sekuntia. Ohjelma ei yksinkertaisesti salli vähempää.
Tämän seurauksena komento näyttää tältä:
ping -s 1300 -i 0.1 yandex.ru
Tämän suunnittelun avulla voit nähdä realistisemman kuvan viiveistä.
Ping UDP:n ja TCP:n kautta
Joissakin tapauksissa TCP-yhteyksiä käsitellään eri tavalla kuin ICMP-paketteja, ja tästä johtuen mittaukset voivat vaihdella protokollasta riippuen. Usein käy myös niin, että isäntä ei yksinkertaisesti vastaa ICMP:hen, eikä tavallinen ping toimi. Näin esimerkiksi isäntä tekee koko elämänsä. microsoft.com.
Apuohjelma kuuluisan skannerin kehittäjiltä nmap voi luoda mitä tahansa paketteja. Sitä voidaan käyttää myös viiveiden mittaamiseen.
Koska UDP ja TCP toimivat tietyissä porteissa, meidän on "pingoitava" tietty portti. Yritetään pingata TCP 80, eli verkkopalvelimen portti:
$ 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
Oletusarvoisesti nping lähettää 4 pakettia ja pysähtyy. Vaihtoehto -c 0 mahdollistaa loputtoman pakettien lähettämisen; pysäyttääksesi ohjelman, sinun on painettava Ctrl+C. Tilastot näytetään lopussa. Näemme, että keskimääräinen rtt-arvo (paluumatka-aika) on 101 ms.
MTR - traceroute steroideilla
Ohjelma My Traceroute on edistynyt apuohjelma reittien jäljittämiseen etäisäntään. Toisin kuin tavallinen järjestelmäapuohjelma traceroute (Windowsissa tämä on tracert-apuohjelma), se voi näyttää viiveitä jokaiselle pakettiketjun isännälle. Se voi myös jäljittää reittejä ICMP:n lisäksi myös UDP:n ja TCP:n kautta.
$ sudo mtr microsoft.com
(Napsautettava) MTR-ohjelman käyttöliittymä. Reitin jäljitys osoitteeseen microsoft.com aloitettiin
MTR näyttää välittömästi pingin jokaiselle ketjun isännälle, ja tiedot päivitetään jatkuvasti ohjelman ollessa käynnissä ja lyhyen aikavälin muutoksia voidaan nähdä.
Kuvakaappaus osoittaa, että solmussa #6 on pakettihäviöitä, mutta itse asiassa tämä ei ole täysin totta, koska jotkut reitittimet voivat yksinkertaisesti hylätä paketit, joiden TTL on vanhentunut, eivätkä palauta virhevastausta, joten pakettihäviötiedot voidaan jättää huomiotta.
WiFi vs kaapeli
Tämä aihe ei ole täysin relevantti artikkelin kannalta, mutta mielestäni se on erittäin tärkeä viivästysten yhteydessä. Rakastan todella WiFi-yhteyttä, mutta jos minulla on pieninkin mahdollisuus muodostaa yhteys Internetiin kaapelilla, käytän sitä. Olen myös aina kieltänyt ihmisiä käyttämästä WiFi-kameroita.
Jos pelaat vakavia online-räiskintäpelejä, suoratoistat videoita tai käytät kauppaa pörssissä: käytä Internetiä kaapelin kautta.
Tässä on visuaalinen testi WiFi- ja kaapeliyhteyksien vertaamiseksi. Tämä on ping WiFi-reitittimeen, eli ei vielä edes Internetiin.
(Kliksoitava) Ping-kutsu WiFi-reitittimeen kaapelin ja WiFin kautta
On nähtävissä, että WiFi-yhteydellä viive on 1 ms pidempi ja joskus paketeissa on kymmenen kertaa pidempi viive! Ja tämä on vain lyhyt aika. Samanaikaisesti sama reititin tuottaa vakaat <1 ms:n viiveet.
Yllä olevassa esimerkissä käytetään WiFi 802.11n taajuudella 2.4 GHz, vain kannettava tietokone ja puhelin on yhdistetty WiFi-tukiasemaan. Jos tukiasemassa olisi enemmän asiakkaita, tulokset olisivat paljon huonommat. Tästä syystä vastustan kaikkien toimistotietokoneiden vaihtamista WiFi-verkkoon, jos ne on mahdollista saavuttaa kaapelilla.
IP-yhteys
Olemme siis oppineet mittaamaan viiveitä palvelimelle, yritetään löytää meille lähin palvelin. Tätä varten voimme tarkastella, kuinka palveluntarjoajamme reititys toimii. Palvelua on kätevä käyttää tähän tarkoitukseen
Kun käymme sivustolla, näemme IP-osoitteemme kuuluvan autonomiseen järjestelmään .
Katsomalla autonomisten järjestelmien liitettävyyskaaviota voimme nähdä, minkä korkeamman tason palveluntarjoajien kautta tarjoajamme on yhteydessä muuhun maailmaan. Jokainen piste on napsautettava, voit mennä sisään ja lukea, millainen palveluntarjoaja se on.
Yhteyskaavio palveluntarjoajan autonomisista järjestelmistä
Tämän työkalun avulla voit tutkia, kuinka minkä tahansa palveluntarjoajan kanavat, mukaan lukien hosting, on rakennettu. Katso, mihin palveluntarjoajiin se on suoraan yhteydessä. Tätä varten sinun on syötettävä palvelimen IP-osoite bgp.he.net-hakuun ja katsottava sen autonomisen järjestelmän kaaviota. Voit myös ymmärtää, kuinka yksi datakeskus tai hosting-palveluntarjoaja on yhdistetty toiseen.
Useimmat liikenteen vaihtopisteet tarjoavat erikoistyökalun nimeltä look glass, jonka avulla voit pingata ja jäljittää tietystä reitittimestä vaihtopisteessä.
Esimerkiksi, MGTS:ltä
Joten palvelinta valittaessa voimme nähdä etukäteen, miltä se näyttää eri liikenteen vaihtopisteistä. Ja jos potentiaaliset asiakkaamme sijaitsevat tietyllä maantieteellisellä alueella, voimme löytää palvelimelle optimaalisen sijainnin.
Valitse lähin palvelin
Päätimme yksinkertaistaa menettelyä optimaalisen palvelimen löytämiseksi asiakkaillemme ja loimme sivun, joka testaa automaattisesti lähellä olevia sijainteja: .
Kun vierailet sivulla, komentosarja mittaa viiveet selaimeltasi kullekin palvelimelle ja näyttää ne interaktiivisella kartalla. Kun napsautat datakeskusta, näyttöön tulee tiedot testituloksista.
Painike vie sinut kaikkien palvelinkeskustemme latenssitestisivulle. Voit tarkastella testituloksia napsauttamalla datakeskuspistettä kartalla
Lähde: will.com