Pentru multe sarcini, întârzierile între client și server sunt critice, de exemplu în jocuri online, conferințe video/voce, telefonie IP, VPN etc. Dacă serverul este prea departe de client la nivel de rețea IP, atunci întârzierile (numite în mod popular „ping”, „lag”) vor interfera cu munca.
Proximitatea geografică a unui server nu este întotdeauna egală cu proximitatea la nivel de rutare IP. Deci, de exemplu, un server din altă țară poate fi „mai aproape” de tine decât un server din orașul tău. Toate datorită particularităților de rutare și construcție a rețelei.
Cum să alegi un server cât mai aproape de toți potențialii clienți? Ce este conectivitatea la rețea IP? Cum să direcționezi un client către cel mai apropiat server? Să aflăm în articol.
Măsurarea întârzierilor
Mai întâi, să învățăm cum să măsurăm întârzierile. Această sarcină nu este atât de simplă pe cât ar părea, deoarece întârzierile pot varia pentru diferite protocoale și dimensiuni de pachete. De asemenea, este posibil să ratați evenimente pe termen scurt, cum ar fi căderile care durează câteva milisecunde.
ICMP - ping obișnuit
Vom folosi utilitarul ping Unix; acesta vă permite să setați manual intervalele dintre trimiterea pachetelor, ceea ce versiunea ping pentru Windows nu le poate face. Acest lucru este important deoarece, dacă există pauze lungi între pachete, este posibil să nu vedeți ce se întâmplă între ele.
Mărimea Pachetului (opțiunea -s) - în mod implicit, utilitarul ping trimite pachete de 64 de octeți. Cu pachete atât de mici, fenomenele care apar cu pachete mai mari pot să nu fie vizibile, așa că vom seta dimensiunea pachetului la 1300 de octeți.
Intervalul dintre pachete (opțiunea -i) — timpul dintre trimiterile de date. Implicit, pachetele sunt trimise o dată pe secundă, aceasta este foarte lungă, programele reale trimit sute și mii de pachete pe secundă, așa că vom seta intervalul la 0.1 secundă. Programul pur și simplu nu permite mai puțin.
Ca rezultat, comanda arată astfel:
ping -s 1300 -i 0.1 yandex.ru
Acest design vă permite să vedeți o imagine mai realistă a întârzierilor.
Ping prin UDP și TCP
În unele cazuri, conexiunile TCP sunt procesate diferit de pachetele ICMP și, din această cauză, măsurătorile pot varia în funcție de protocol. De asemenea, se întâmplă adesea ca gazda pur și simplu să nu răspundă la ICMP, iar ping-ul obișnuit să nu funcționeze. Asta face o gazdă toată viața, de exemplu. microsoft.com.
Utilitate
Deoarece UDP și TCP funcționează pe anumite porturi, trebuie să „ping” un anumit port. Să încercăm să facem ping la TCP 80, adică la portul serverului web:
$ 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
În mod implicit, nping trimite 4 pachete și se oprește. Opțiune -C 0 permite trimiterea nesfârșită de pachete; pentru a opri programul, trebuie să apăsați Ctrl+C. Statisticile vor fi afișate la sfârșit. Vedem că valoarea medie a rtt (timp dus-întors) este de 101 ms.
MTR - traceroute pe steroizi
Program
$ sudo mtr microsoft.com
(Se poate da clic) Interfața programului MTR. A început urmărirea rutei către microsoft.com
MTR arată imediat ping-ul fiecărei gazde din lanț, iar datele sunt actualizate constant în timp ce programul rulează și pot fi văzute modificări pe termen scurt.
Captura de ecran arată că nodul #6 are pierderi de pachete, dar de fapt acest lucru nu este în întregime adevărat, deoarece unele routere pot pur și simplu să arunce pachetele cu un TTL expirat și să nu returneze un răspuns de eroare, astfel încât datele de pierdere a pachetelor pot fi ignorate aici.
WiFi vs cablu
Acest subiect nu este în întregime relevant pentru articol, dar în opinia mea este foarte important în contextul întârzierilor. Îmi place foarte mult WiFi-ul, dar dacă am și cea mai mică oportunitate de a mă conecta la Internet cu un cablu, îl voi folosi. De asemenea, descurajez întotdeauna oamenii să folosească camere WiFi.
Dacă jucați jocuri serioase online, transmiteți videoclipuri sau tranzacționați la bursă: vă rugăm să utilizați internetul prin cablu.
Iată un test vizual pentru a compara conexiunile WiFi și prin cablu. Acesta este un ping către routerul WiFi, adică nici măcar Internetul încă.
(Se poate da clic) Comparație între ping-ul cu un router WiFi prin cablu și prin WiFi
Se vede că prin WiFi întârzierea este cu 1 ms mai mare și uneori apar pachete cu întârzieri de zece ori mai mari! Și aceasta este doar o perioadă scurtă de timp. În același timp, același router produce întârzieri stabile de <1 ms.
În exemplul de mai sus, se folosește WiFi 802.11n la 2.4 GHz, doar un laptop și un telefon sunt conectate la punctul de acces WiFi. Dacă ar fi mai mulți clienți pe punctul de acces, rezultatele ar fi mult mai rele. Acesta este motivul pentru care sunt foarte împotriva comutării tuturor computerelor de birou la WiFi, dacă este posibil să le ajung cu un cablu.
conectivitate IP
Deci, am învățat să măsurăm întârzierile la server, să încercăm să găsim cel mai apropiat server de noi. Pentru a face acest lucru, ne putem uita la modul în care funcționează rutarea furnizorului nostru. Este convenabil să utilizați serviciul pentru aceasta
Când accesăm site-ul, vedem că adresa noastră IP aparține sistemului autonom
Privind graficul de conectivitate al sistemelor autonome, putem vedea prin ce furnizori de nivel superior este conectat furnizorul nostru la restul lumii. Fiecare dintre puncte se poate face clic, puteți intra și citi ce fel de furnizor este.
Graficul de conectivitate al sistemelor autonome ale furnizorului
Folosind acest instrument, puteți studia modul în care sunt structurate canalele oricărui furnizor, inclusiv găzduirea. Vedeți la ce furnizori este conectat direct. Pentru a face acest lucru, trebuie să introduceți adresa IP a serverului în căutarea bgp.he.net și să priviți graficul sistemului său autonom. De asemenea, puteți înțelege modul în care un centru de date sau furnizor de găzduire este conectat la altul.
Majoritatea punctelor de schimb de trafic oferă un instrument special numit oglindă, care vă permite să faceți ping și să urmăriți de la un anumit router la punctul de schimb.
Aici, de exemplu,
Deci, atunci când alegem un server, putem vedea în avans cum va arăta din diferite puncte de schimb de trafic. Iar dacă clienții noștri potențiali sunt localizați într-o anumită zonă geografică, putem găsi locația optimă pentru server.
Selectați cel mai apropiat server
Am decis să simplificăm procedura de găsire a serverului optim pentru clienții noștri și am creat o pagină cu testarea automată a locațiilor din apropiere:
Când vizitați o pagină, scriptul măsoară întârzierile de la browser la fiecare server și le afișează pe o hartă interactivă. Când faceți clic pe un centru de date, sunt afișate informații cu rezultatele testului.
Butonul vă duce la pagina de testare a latenței pentru toate centrele noastre de date. Pentru a vedea rezultatele testului, faceți clic pe punctul centrului de date de pe hartă
Sursa: www.habr.com