Za mnoge zadatke kašnjenja između klijenta i poslužitelja su kritična, na primjer u online igrama, video/glasovnim konferencijama, IP telefoniji, VPN-u itd. Ako je poslužitelj predaleko od klijenta na razini IP mreže, tada će kašnjenja (popularno nazvana “ping”, “lag”) ometati rad.
Geografska blizina poslužitelja nije uvijek jednaka blizini na razini IP usmjeravanja. Tako vam, na primjer, poslužitelj u drugoj zemlji može biti "bliži" nego poslužitelj u vašem gradu. Sve zbog osobitosti usmjeravanja i izgradnje mreže.
Kako odabrati poslužitelj koji je što bliži svim potencijalnim klijentima? Što je IP mrežna povezanost? Kako usmjeriti klijenta na najbliži server? Otkrijmo u članku.
Mjerenje kašnjenja
Prvo, naučimo kako mjeriti kašnjenja. Ovaj zadatak nije tako jednostavan kao što se može činiti jer kašnjenja mogu varirati za različite protokole i veličine paketa. Također možete propustiti kratkoročne događaje, kao što su padovi koji traju nekoliko milisekundi.
ICMP - regularni ping
Koristit ćemo Unix ping uslužni program; on vam omogućuje ručno postavljanje intervala između slanja paketa, što verzija pinga za Windows ne može. Ovo je važno jer ako postoje duge pauze između paketa, možda jednostavno nećete vidjeti što se događa između njih.
Veličina Paketa (opcija -s) - prema zadanim postavkama uslužni program ping šalje pakete veličine 64 bajta. Kod tako malih paketa, fenomeni koji se javljaju kod većih paketa možda neće biti vidljivi, stoga ćemo postaviti veličinu paketa na 1300 bajtova.
Interval između paketa (opcija -i) — vrijeme između slanja podataka. Prema zadanim postavkama, paketi se šalju jednom u sekundi, ovo je jako dugo, pravi programi šalju stotine i tisuće paketa u sekundi, pa ćemo postaviti interval na 0.1 sekundu. Manje program jednostavno ne dopušta.
Kao rezultat, naredba izgleda ovako:
ping -s 1300 -i 0.1 yandex.ru
Ovaj dizajn omogućuje vam da vidite realniju sliku kašnjenja.
Ping putem UDP i TCP
U nekim se slučajevima TCP veze obrađuju drugačije od ICMP paketa i zbog toga mjerenja mogu varirati ovisno o protokolu. Također se često događa da host jednostavno ne odgovara na ICMP, a redovni ping ne radi. To je ono što voditelj radi cijeli život, na primjer. microsoft.com.
Korisnost od programera poznatog skenera nmap može generirati bilo koje pakete. Također se može koristiti za mjerenje kašnjenja.
Budući da UDP i TCP rade na određenim portovima, moramo "pingati" određeni port. Pokušajmo pingati TCP 80, odnosno port web poslužitelja:
$ 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
Prema zadanim postavkama, nping šalje 4 paketa i zaustavlja se. Opcija -c 0 omogućuje beskonačno slanje paketa, za zaustavljanje programa potrebno je pritisnuti Ctrl+C. Statistika će biti prikazana na kraju. Vidimo da je prosječna vrijednost rtt (vrijeme povratnog putovanja) 101 ms.
MTR - traceroute na steroidima
Program My Traceroute je napredni uslužni program za praćenje ruta do udaljenog glavnog računala. Za razliku od uobičajenog uslužnog programa sustava traceroute (u sustavu Windows ovo je uslužni program tracert), može pokazati kašnjenja svakom hostu u lancu paketa. Također može pratiti rute ne samo putem ICMP-a, već i putem UDP-a i TCP-a.
$ sudo mtr microsoft.com
(Može se kliknuti) MTR programsko sučelje. Započelo je praćenje rute do microsoft.com
MTR odmah pokazuje ping svakom hostu u lancu, a podaci se stalno ažuriraju dok program radi i mogu se vidjeti kratkoročne promjene.
Snimka zaslona pokazuje da čvor #6 ima gubitke paketa, ali zapravo to nije sasvim točno, jer neki usmjerivači mogu jednostavno odbaciti pakete s isteklim TTL-om i ne vratiti odgovor na pogrešku, tako da se podaci o gubitku paketa ovdje mogu zanemariti.
WiFi vs kabel
Ova tema nije u potpunosti relevantna za članak, ali je po mom mišljenju vrlo važna u kontekstu kašnjenja. Jako volim WiFi, ali ako budem imao i najmanju priliku za spajanje na internet kabelom, iskoristit ću je. Također uvijek obeshrabrujem ljude da koriste WiFi kamere.
Ako igrate ozbiljne online pucačine, streamate video ili trgujete na burzi: koristite internet putem kabela.
Evo vizualnog testa za usporedbu WiFi i kabelskih veza. Ovo je ping na WiFi ruter, odnosno još nije ni internet.
(Može se kliknuti) Usporedba pinga na WiFi usmjerivač putem kabela i putem WiFi-a
Vidi se da je preko WiFi-a kašnjenje duže za 1ms a ponekad ima paketa s kašnjenjem i deset puta! A ovo je samo kratko vrijeme. U isto vrijeme, isti usmjerivač proizvodi stabilna kašnjenja od <1ms.
U gornjem primjeru koristi se WiFi 802.11n na 2.4 GHz, samo su prijenosno računalo i telefon spojeni na WiFi pristupnu točku. Da je na pristupnoj točki bilo više klijenata, rezultati bi bili puno lošiji. Zbog toga sam toliko protiv prebacivanja svih uredskih računala na WiFi ako je do njih moguće doći kabelom.
IP povezivost
Dakle, naučili smo mjeriti kašnjenja do poslužitelja, pokušajmo pronaći nama najbliži poslužitelj. Da bismo to učinili, možemo pogledati kako funkcionira usmjeravanje našeg pružatelja usluga. Za to je prikladno koristiti uslugu
Kada pristupimo stranici, vidimo da naša IP adresa pripada autonomnom sustavu .
Promatrajući graf povezanosti autonomnih sustava, možemo vidjeti preko kojih je pružatelja više razine naš pružatelj povezan s ostatkom svijeta. Na svaku točkicu se može kliknuti, možete ući i pročitati o kakvom se pružatelju radi.
Graf povezanosti autonomnih sustava pružatelja usluga
Pomoću ovog alata možete proučiti kako su strukturirani kanali bilo kojeg pružatelja usluge, uključujući hosting. Pogledajte s kojim je pružateljima usluga izravno povezan. Da biste to učinili, morate unijeti IP adresu poslužitelja u pretragu za bgp.he.net i pogledati grafikon njegovog autonomnog sustava. Također možete razumjeti kako je jedan podatkovni centar ili pružatelj usluge hostinga povezan s drugim.
Većina točaka za razmjenu prometa nudi poseban alat koji se zove look glass, koji vam omogućuje ping i traceroute s određenog usmjerivača na točki razmjene.
Ovdje, na primjer, iz MGTS-a
Dakle, pri odabiru poslužitelja možemo unaprijed vidjeti kako će izgledati s različitih točaka razmjene prometa. A ako se naši potencijalni klijenti nalaze na određenom geografskom području, možemo pronaći optimalnu lokaciju za poslužitelj.
Odaberite najbliži poslužitelj
Odlučili smo pojednostaviti proceduru pronalaska optimalnog poslužitelja za naše klijente i izradili stranicu s automatskim testiranjem obližnjih lokacija: .
Kada posjetite stranicu, skripta mjeri kašnjenja od vašeg preglednika do svakog poslužitelja i prikazuje ih na interaktivnoj karti. Kada kliknete na podatkovni centar, prikazuju se informacije s rezultatima testiranja.
Gumb vas vodi na stranicu za testiranje latencije za sve naše podatkovne centre. Za pregled rezultata testa kliknite na točku podatkovnog centra na karti
Izvor: www.habr.com