Por multaj taskoj, prokrastoj inter la kliento kaj servilo estas kritikaj, ekzemple en interretaj ludoj, video/voĉkonferenco, IP-telefonio, VPN, ktp. Se la servilo estas tro malproksime de la kliento ĉe la IP-reto-nivelo, tiam prokrastoj (populare nomataj "ping", "lag") malhelpos laboron.
Geografia proksimeco de servilo ne ĉiam egalas proksimecon ĉe la IP-vojignivelo. Do, ekzemple, servilo en alia lando povas esti "pli proksima" al vi ol servilo en via urbo. Ĉio pro la proprecoj de vojigo kaj reto-konstruo.
Kiel elekti servilon kiel eble plej proksiman al ĉiuj eblaj klientoj? Kio estas IP-reta konektebleco? Kiel direkti klienton al la plej proksima servilo? Ni eksciu en la artikolo.
Mezurado de malfruoj
Unue, ni lernu kiel mezuri malfruojn. Ĉi tiu tasko ne estas tiel simpla kiel ĝi ŝajnas, ĉar prokrastoj povas varii laŭ malsamaj protokoloj kaj pakaj grandecoj. Vi ankaŭ povas maltrafi mallongdaŭrajn eventojn, kiel trempojn daŭrantajn kelkajn milisekundojn.
ICMP - regula ping
Ni uzos la Uniksan ping-ilaĵon; ĝi permesas al vi mane agordi la intervalojn inter sendado de pakaĵoj, kion la ping-versio por Vindozo ne povas fari. Ĉi tio gravas ĉar se estas longaj paŭzoj inter pakaĵoj, vi simple ne vidas kio okazas inter ili.
Pako grandeco (opcio -s) - defaŭlte, la ping-utilo sendas pakaĵetojn de 64 bajtoj en grandeco. Kun tiaj malgrandaj pakaĵoj, fenomenoj kiuj okazas kun pli grandaj pakaĵoj eble ne estas rimarkeblaj, do ni agordos la pakaĵgrandecon al 1300 bajtoj.
Intervalo inter pakoj (opcio -i) — tempo inter sendado de datumoj. Defaŭlte, pakoj estas senditaj unufoje por sekundo, ĉi tio estas tre longa, realaj programoj sendas centojn kaj milojn da pakaĵoj sekundo, do ni agordos la intervalon al 0.1 sekundo. La programo simple ne permesas malpli.
Kiel rezulto, la komando aspektas jene:
ping -s 1300 -i 0.1 yandex.ru
Ĉi tiu dezajno permesas al vi vidi pli realisman bildon de prokrastoj.
Ping per UDP kaj TCP
En kelkaj kazoj, TCP-konektoj estas prilaboritaj alimaniere ol ICMP-pakaĵetoj, kaj pro tio, mezuradoj povas varii dependi de la protokolo. Ankaŭ ofte okazas, ke la gastiganto simple ne respondas al ICMP, kaj regula ping ne funkcias. Jen kion faras gastiganto dum sia tuta vivo, ekzemple. microsoft.com.
Utileco de la programistoj de la fama skanilo nmap povas generi ajnajn pakojn. Ĝi ankaŭ povas esti uzata por mezuri malfruojn.
Ĉar UDP kaj TCP funkcias sur specifaj, ni devas "pingi" specifan havenon. Ni provu pingi TCP 80, tio estas, la retservila haveno:
$ 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
Defaŭlte, nping sendas 4 pakaĵojn kaj haltas. Opcio -c 0 ebligas senfinan sendon de pakaĵoj; por haltigi la programon, vi devas premi Ctrl+C. Statistikoj estos montritaj ĉe la fino. Ni vidas, ke la averaĝa rtt (revena tempo) valoro estas 101ms.
MTR - traceroute sur steroidoj
La programo Mia Traceroute estas altnivela ilo por spuri itinerojn al fora gastiganto. Male al la kutima sistema ilo traceroute (en Vindozo ĉi tio estas la tracert ilo), ĝi povas montri prokrastojn al ĉiu gastiganto en la pakaĉeno. Ĝi ankaŭ povas spuri itinerojn ne nur per ICMP, sed ankaŭ per UDP kaj TCP.
$ sudo mtr microsoft.com
(Alklakebla) MTR-programa interfaco. Itinera spurado al microsoft.com komenciĝis
MTR tuj montras la ping-on al ĉiu gastiganto en la ĉeno, kaj la datumoj estas konstante ĝisdatigitaj dum la programo funkcias kaj mallongdaŭraj ŝanĝoj videblas.
La ekrankopio montras, ke nodo n-ro 6 havas pakaĵetperdojn, sed fakte ĉi tio ne estas tute vera, ĉar iuj enkursigiloj povas simple forĵeti pakaĵetojn kun eksvalidiĝinta TTL kaj ne resendi erarrespondon, do la pakaĵperdo-datumoj povas esti ignoritaj ĉi tie.
WiFi vs kablo
Ĉi tiu temo ne estas tute rilata al la artikolo, sed laŭ mi ĝi estas tre grava en la kunteksto de prokrastoj. Mi tre amas WiFi, sed se mi havas eĉ la plej etan ŝancon konekti al Interreto per kablo, mi uzos ĝin. Mi ankaŭ ĉiam malkuraĝigas homojn uzi WiFi-fotilojn.
Se vi ludas seriozajn interretajn pafistojn, fluas videon aŭ komercas sur la borso: bonvolu uzi Interreton per kablo.
Jen vida testo por kompari WiFi- kaj kablokonektojn. Ĉi tio estas ping al la WiFi-enkursigilo, tio estas, eĉ ne la Interreto ankoraŭ.
(Alklakebla) Komparo de ping al WiFi-enkursigilo per kablo kaj per WiFi
Videblas, ke tra WiFi la prokrasto estas 1 ms pli longa kaj foje estas pakoj kun prokrastoj dekoble pli longaj! Kaj ĉi tio estas nur mallonga tempodaŭro. Samtempe, la sama enkursigilo produktas stabilajn prokrastojn de <1 ms.
En la supra ekzemplo, WiFi 802.11n ĉe 2.4GHz estas uzata, nur tekokomputilo kaj telefono estas konektitaj al la WiFi-alirpunkto. Se estus pli da klientoj sur la alirpunkto, la rezultoj estus multe pli malbonaj. Tial mi kontraŭas ŝanĝi ĉiujn oficejajn komputilojn al WiFi se eblas atingi ilin per kablo.
IP-konektebleco
Do, ni lernis mezuri malfruojn al la servilo, ni provu trovi la plej proksiman servilon al ni. Por fari tion, ni povas rigardi kiel funkcias la vojigo de nia provizanto. Estas oportune uzi la servon por ĉi tio
Kiam ni aliras la retejon, ni vidas, ke nia IP-adreso apartenas al la aŭtonoma sistemo .
Rigardante la konekteblecan grafikon de aŭtonomaj sistemoj, ni povas vidi per kiuj altnivelaj provizantoj nia provizanto estas konektita al la resto de la mondo. Ĉiu el la punktoj estas klakebla, vi povas eniri kaj legi kia provizanto ĝi estas.
Konektecgrafiko de la aŭtonomiaj sistemoj de la provizanto
Uzante ĉi tiun ilon, vi povas studi kiel la kanaloj de iu ajn provizanto, inkluzive de gastigado, estas strukturitaj. Vidu al kiuj provizantoj ĝi estas rekte konektita. Por fari tion, vi devas enigi la IP-adreson de la servilo en la serĉon de bgp.he.net kaj rigardi la grafikaĵon de ĝia aŭtonoma sistemo. Vi ankaŭ povas kompreni kiel unu datumcentro aŭ gastiga provizanto estas konektita al alia.
Plej multaj trafikinterŝanĝaj punktoj disponigas specialan ilon nomitan spegulo, kiu permesas vin ping kaj spuri de specifa enkursigilo ĉe la interŝanĝpunkto.
Ekzemple, de MGTS
Do, elektante servilon, ni anticipe povas vidi kiel ĝi aspektos de malsamaj trafikinterŝanĝaj punktoj. Kaj se niaj eblaj klientoj situas en certa geografia areo, ni povas trovi la optimuman lokon por la servilo.
Elektu la plej proksiman servilon
Ni decidis simpligi la proceduron por trovi la optimuman servilon por niaj klientoj kaj kreis paĝon kun aŭtomata testado de proksimaj lokoj: .
Kiam vi vizitas paĝon, la skripto mezuras la prokrastojn de via retumilo al ĉiu servilo kaj montras ilin sur interaga mapo. Kiam vi alklakas datumcentron, informoj kun testrezultoj montriĝas.
La butono kondukas vin al la latenta testa paĝo por ĉiuj niaj datumcentroj. Por vidi la testrezultojn, alklaku la datumcentran punkton sur la mapo
fonto: www.habr.com