Daudziem uzdevumiem kavēšanās starp klientu un serveri ir būtiska, piemēram, tiešsaistes spēlēs, video/balss konferencēs, IP telefonijā, VPN utt. Ja serveris atrodas pārāk tālu no klienta IP tīkla līmenī, kavēšanās (tautā saukta par “ping”, “lag”) traucēs darbu.
Servera ģeogrāfiskais tuvums ne vienmēr ir vienāds ar tuvumu IP maršrutēšanas līmenī. Tātad, piemēram, serveris citā valstī var būt jums “tuvāk” nekā serveris jūsu pilsētā. Tas viss ir saistīts ar maršrutēšanas un tīkla izveides īpatnībām.
Kā izvēlēties serveri, kas ir pēc iespējas tuvāks visiem potenciālajiem klientiem? Kas ir IP tīkla savienojamība? Kā novirzīt klientu uz tuvāko serveri? To noskaidrosim rakstā.
Kavēšanās mērīšana
Vispirms uzzināsim, kā izmērīt kavēšanos. Šis uzdevums nav tik vienkāršs, kā varētu šķist, jo aizkavēšanās var atšķirties dažādiem protokoliem un pakešu izmēriem. Varat arī palaist garām īslaicīgus notikumus, piemēram, dažas milisekundes ilgus kritumus.
ICMP — regulāra ping
Mēs izmantosim Unix ping utilītu; tas ļauj manuāli iestatīt intervālus starp pakešu nosūtīšanu, ko nevar izdarīt Windows ping versija. Tas ir svarīgi, jo, ja starp paketēm ir garas pauzes, jūs varat vienkārši neredzēt, kas notiek starp tām.
Iepakojuma izmērs (opcija -s) - pēc noklusējuma ping utilīta sūta 64 baitu lieluma paketes. Ar tik mazām paketēm parādības, kas rodas ar lielākām paketēm, var nebūt pamanāmas, tāpēc mēs iestatīsim pakešu lielumu uz 1300 baiti.
Intervāls starp paketēm (opcija -i) — laiks starp datu nosūtīšanu. Pēc noklusējuma paketes tiek sūtītas vienu reizi sekundē, tas ir ļoti garš, reālas programmas sūta simtiem un tūkstošiem pakešu sekundē, tāpēc mēs iestatīsim intervālu uz 0.1 sekundi. Programma vienkārši neļauj mazāk.
Rezultātā komanda izskatās šādi:
ping -s 1300 -i 0.1 yandex.ru
Šis dizains ļauj redzēt reālāku priekšstatu par kavēšanos.
Ping, izmantojot UDP un TCP
Dažos gadījumos TCP savienojumi tiek apstrādāti savādāk nekā ICMP paketes, un tādēļ mērījumi var atšķirties atkarībā no protokola. Bieži gadās arī, ka resursdators vienkārši nereaģē uz ICMP, un parastais ping nedarbojas. Tā, piemēram, saimnieks dara visu mūžu. microsoft.com.
Lietderība no slavenā skenera izstrādātājiem nmap var ģenerēt jebkuras paketes. To var arī izmantot, lai izmērītu kavēšanos.
Tā kā UDP un TCP darbojas ar noteiktiem portiem, mums ir jāpiesaista konkrēts ports. Mēģināsim pārbaudīt TCP 80, tas ir, tīmekļa servera portu:
$ 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
Pēc noklusējuma nping nosūta 4 paketes un apstājas. Opcija -c 0 nodrošina bezgalīgu pakešu sūtīšanu; lai apturētu programmu, jānospiež Ctrl+C. Beigās tiks parādīta statistika. Mēs redzam, ka vidējā rtt (turp un atpakaļ) vērtība ir 101 ms.
MTR - traceroute uz steroīdiem
Programma My Traceroute ir uzlabota utilīta maršrutu izsekošanai uz attālo saimniekdatoru. Atšķirībā no parastās sistēmas utilīta traceroute (operētājsistēmā Windows šī ir tracert utilīta), tā var parādīt aizkavi katram saimniekdatoram pakešu ķēdē. Tas var arī izsekot maršrutus ne tikai caur ICMP, bet arī caur UDP un TCP.
$ sudo mtr microsoft.com
(Noklikšķināms) MTR programmas interfeiss. Sākta maršruta izsekošana vietnē microsoft.com
MTR nekavējoties parāda ping katram ķēdes saimniekdatoram, un dati tiek pastāvīgi atjaunināti, kamēr programma darbojas, un var redzēt īslaicīgas izmaiņas.
Ekrānuzņēmumā redzams, ka mezglā #6 ir pakešu zudumi, taču patiesībā tā nav gluži taisnība, jo daži maršrutētāji var vienkārši izmest paketes ar beidzies TTL un neatgriezt kļūdas atbildi, tāpēc pakešu zuduma datus šeit var ignorēt.
WiFi vs kabelis
Šis temats nav līdz galam atbilstošs rakstam, taču, manuprāt, tas ir ļoti svarīgs aizkavēšanās kontekstā. Es ļoti mīlu WiFi, bet, ja man ir kaut mazākā iespēja pieslēgties internetam ar kabeli, es to izmantošu. Es arī vienmēr atturu cilvēkus no WiFi kameru lietošanas.
Ja spēlējat nopietnas tiešsaistes šāvēja spēles, straumējat video vai tirgojaties biržā: lūdzu, izmantojiet internetu, izmantojot kabeli.
Šeit ir vizuāls tests, lai salīdzinātu WiFi un kabeļa savienojumus. Tas ir ping uz WiFi maršrutētāju, tas ir, vēl nav pat interneta.
(Noklikšķināms) Salīdzinājums ar ping ar WiFi maršrutētāju, izmantojot kabeli un caur WiFi
Redzams, ka pa WiFi aizkave ir par 1ms ilgāka un dažkārt ir paketes ar aizkavēšanos desmit reizes ilgāk! Un tas ir tikai īss laika posms. Tajā pašā laikā tas pats maršrutētājs rada stabilu aizkavi <1 ms.
Iepriekš minētajā piemērā tiek izmantots WiFi 802.11n ar 2.4 GHz, WiFi piekļuves punktam ir pievienots tikai klēpjdators un tālrunis. Ja piekļuves punktā būtu vairāk klientu, rezultāti būtu daudz sliktāki. Tāpēc es esmu ļoti pret visu biroja datoru pārslēgšanu uz WiFi, ja tos ir iespējams sasniegt ar kabeli.
IP savienojamība
Tātad, esam iemācījušies izmērīt aizkavēšanos serverī, mēģināsim atrast mums tuvāko serveri. Lai to izdarītu, mēs varam apskatīt, kā darbojas mūsu pakalpojumu sniedzēja maršrutēšana. Šim nolūkam ir ērti izmantot pakalpojumu
Kad mēs piekļūstam vietnei, mēs redzam, ka mūsu IP adrese pieder autonomai sistēmai .
Aplūkojot autonomo sistēmu savienojamības grafiku, mēs varam redzēt, caur kuriem augstāka līmeņa pakalpojumu sniedzējiem mūsu pakalpojumu sniedzējs ir savienots ar pārējo pasauli. Katrs no punktiem ir noklikšķināms, varat ieiet un izlasīt, kāda veida pakalpojumu sniedzējs tas ir.
Pakalpojumu sniedzēja autonomo sistēmu savienojamības grafiks
Izmantojot šo rīku, varat izpētīt, kā ir strukturēti jebkura pakalpojumu sniedzēja kanāli, tostarp hostings. Skatiet, ar kuriem pakalpojumu sniedzējiem tas ir tieši saistīts. Lai to izdarītu, meklēšanā bgp.he.net ir jāievada servera IP adrese un jāaplūko tā autonomās sistēmas diagramma. Varat arī saprast, kā viens datu centrs vai mitināšanas pakalpojumu sniedzējs ir savienots ar citu.
Lielākā daļa satiksmes apmaiņas punktu nodrošina īpašu rīku, ko sauc par skata stiklu, kas ļauj veikt ping un traceroute no konkrēta maršrutētāja apmaiņas punktā.
Piemēram, šeit no MGTS
Tātad, izvēloties serveri, mēs varam iepriekš redzēt, kā tas izskatīsies no dažādiem trafika apmaiņas punktiem. Un, ja mūsu potenciālie klienti atrodas noteiktā ģeogrāfiskā apgabalā, mēs varam atrast optimālo atrašanās vietu serverim.
Izvēlieties tuvāko serveri
Mēs nolēmām vienkāršot procedūru optimālā servera atrašanai mūsu klientiem un izveidojām lapu ar automātisku tuvumā esošo atrašanās vietu testēšanu: .
Kad apmeklējat lapu, skripts mēra aizkavi no jūsu pārlūkprogrammas uz katru serveri un parāda tos interaktīvā kartē. Noklikšķinot uz datu centra, tiek parādīta informācija ar testa rezultātiem.
Poga novirza uz latentuma pārbaudes lapu visiem mūsu datu centriem. Lai apskatītu testa rezultātus, noklikšķiniet uz datu centra punkta kartē
Avots: www.habr.com