Ghid pentru Ping și Traceroute
Cum testează Ping și Traceroute de la XGM o gazdă publică, ce înseamnă latența, pierderea de pachete și hopurile și de ce unele gazde nu răspund la ping.
Ce măsoară ping
Ping trimite pachete mici de tip ICMP echo request și așteaptă răspunsuri echo reply. Fiecare răspuns arată timpul dus-întors, adică timpul scurs de la trimiterea cererii până la primirea răspunsului. Rezumatul adaugă pierderea de pachete, proporția cererilor rămase fără răspuns, și timpii dus-întors minim, mediu și maxim. Măsurătoarea nu spune singură dacă un serviciu funcționează; arată doar că pachetele ajung la destinație și se pot întoarce. Rămâne totuși cel mai rapid prim pas pentru a separa o problemă de rețea de una din aplicație.
Instrumentul Ping de la XGM rezolvă mai întâi numele gazdei, verifică dacă adresa este publică și trimite ping exact către acea adresă, de pe serverul XGM. Rezultatul arată așadar accesibilitatea de pe un server din internet, nu de pe conexiunea dumneavoastră. Adresa rezolvată este afișată împreună cu rezultatul, ca să știți care dintre mai multe adrese a fost testată. Distincția contează mai ales când în rețeaua de la birou există un firewall sau un VPN. O verificare făcută din exterior este cea mai practică modalitate de a afla dacă problema este la dumneavoastră sau la gazdă.
Cum folosiți Ping și Traceroute
- Deschideți Ping și introduceți un nume de gazdă public sau o adresă IP, de exemplu
example.comori192.0.2.80. - Citiți verdictul: toate răspunsurile au venit, pierdere parțială sau niciun răspuns, împreună cu adresa interogată.
- Dacă există pierdere sau latență mare, treceți la modul Traceroute cu aceeași gazdă, ca să vedeți traseul.
- Comparați cu un test din propria rețea (
pingșitracerouteoritracertpe calculatorul dumneavoastră), ca să deosebiți problemele locale de cele îndepărtate.
# Linux and macOS
ping -c 4 example.com
traceroute example.com
# Windows
ping -n 4 example.com
tracert example.comCum citiți rezultatele ping
| Verdict | Semnificație | De făcut |
|---|---|---|
| A răspuns la fiecare pachet | Gazda răspunde la ICMP fără pierderi | Accesibilitatea este în regulă; dacă ceva pare lent, priviți latența |
| S-au pierdut n% dintre pachete | Unele cereri nu au primit răspuns | Rulați din nou; o pierdere persistentă sugerează congestie sau o legătură defectă |
| Niciun răspuns | Toate cererile au expirat | ICMP poate fi blocat; testați serviciul cu Scanner de porturi |
| Acceptă conexiuni TCP | ICMP nu a fost disponibil pe serverul XGM, așa că au fost testate porturile TCP 443 și 80 | Gazda este accesibilă pe acele porturi |
| Timp dus-întors | Situație tipică |
|---|---|
| Sub 20 ms | Același oraș sau aceeași regiune ori un nod CDN din apropiere |
| 20–80 ms | Același continent |
| 80–200 ms | Între continente |
| Peste 200 ms | Trasee foarte lungi, legături prin satelit sau congestie |
Latența depinde mai mult decât de orice altceva de distanța fizică, pentru că lumina are nevoie de timp ca să străbată fibra. O gazdă aflată în spatele unui CDN răspunde deseori dintr-o locație apropiată de serverul XGM, ceea ce spune puțin despre locul serverului de origine. Variația dintre răspunsuri, numită jitter, contează pentru voce și video mai mult decât media. O singură valoare mare provine de obicei dintr-o congestie trecătoare de moment. De aceea, repetarea măsurătorii de câteva ori și privirea distribuției oferă o imagine mai sigură decât un singur număr.
De ce o gazdă nu răspunde la ping
Multe rețele aruncă intenționat cererile ICMP echo, fie la un firewall, fie chiar pe gazdă. Furnizorii de cloud le blochează adesea implicit în grupurile de securitate, iar unele servicii mari limitează rata sau ignoră complet ping-ul. Site-ul sau serverul de mail poate fi perfect sănătos în timp ce ping arată 100% pierdere. Din acest motiv, un rezultat de ping nu este singur o dovadă de indisponibilitate. Dovada reală este dacă serviciul folosit de utilizatori răspunde sau nu.
Ca să testați un serviciu, nu ICMP, conectați-vă la portul lui. Scanner de porturi testează porturi TCP precum 443 pentru HTTPS sau 25 pentru e-mail, iar Antete HTTP arată dacă un site chiar răspunde. O gazdă care refuză ping-ul, dar acceptă conexiuni pe 443, este funcțională. Construiți-vă monitorizarea după aceeași logică, ca să evitați alarmele inutile. Cel mai corect mod de a supraveghea un serviciu este să vorbiți protocolul pe care îl vorbește el.
Cum permiteți ping pe serverul dumneavoastră
Cum citiți un traceroute
Traceroute trimite pachete cu limite de hop din ce în ce mai mari. Fiecare router care aruncă un pachet pentru că limita a fost atinsă răspunde cu un mesaj ICMP time-exceeded, care îi dezvăluie adresa și timpul până la el. Rezultatul este o listă de hopuri de la serverul XGM către gazdă, până la 12 hopuri. Lista arată doar traseul de ducere; drumul de întoarcere poate trece prin cu totul alte routere. De aceea ieșirea traceroute nu este o dovadă, ci un indiciu despre locul unde merită să priviți.
1 192.0.2.1 0.6 ms
2 198.51.100.9 1.8 ms
3 * * *
4 203.0.113.14 12.4 ms
5 203.0.113.77 13.1 ms
6 192.0.2.80 13.6 ms reached| Tipar | De obicei înseamnă |
|---|---|
* * * la un hop, hopurile următoare în regulă | Acel router nu răspunde la sondele traceroute; nu este o problemă |
| Latența sare la un hop și rămâne mai mare | O legătură fizică lungă, precum traversarea unui ocean |
| Latența sare la un hop, apoi scade din nou | Acel router tratează cu prioritate mică propriile răspunsuri; nu este o problemă |
| Stele de la un hop până la final | Un firewall blochează sondele sau traseul este rupt acolo |
| Aceleași adrese care se repetă | O buclă de rutare |
Contează doar o problemă care se păstrează până la ultimul hop. Routerele răspund adesea lent sau deloc la traceroute, deși transportă perfect traficul real, așa că un singur hop lent ori tăcut la mijloc este rareori cauza a ceva. Nu acuzați un router intermediar înainte de a vedea că problema se propagă până la destinație. Când evaluați ieșirea, priviți ultima linie, adică timpul de răspuns al gazdei înseși. Liniile dintre ele capătă sens numai dacă problema continuă de acolo la fiecare hop.
Cum folosiți rezultatele pentru diagnostic
- Trimiteți ping de la XGM și din propria rețea. Dacă XGM ajunge la gazdă, iar dumneavoastră nu, problema este între dumneavoastră și internet.
- Dacă niciunul nu ajunge, testați portul serviciului. Dacă portul răspunde, doar ICMP este blocat.
- Dacă pierderea sau latența începe la un hop și continuă până la destinație, problema este în acea rețea sau după ea; proprietarul adreselor poate fi găsit cu Informații IP.
- Verificați DNS: un nume de gazdă care se rezolvă la o adresă veche trimite ping-ul către mașina greșită. Folosiți Căutare DNS.
- Trimiteți rezultatul furnizorului dumneavoastră, împreună cu ora testului, adresa interogată și traceroute-ul.
Pentru problemele intermitente, rulați verificările de mai multe ori de-a lungul unei perioade. O singură rulare poate nimeri un vârf scurt, iar tiparul din timp este o dovadă mult mai convingătoare pentru un tichet de suport la furnizor. Notați ora și rezultatul fiecărui test și, dacă se poate, repetați aceeași măsurătoare la ore diferite. Astfel se vede dacă problema ține de orele de vârf sau este permanentă. Cu o evidență de câteva zile, cealaltă parte nu mai poate respinge problema pe baza unei singure măsurători.
Întrebări frecvente
De ce arată ping 100% pierdere pentru un site care funcționează?
Gazda sau firewallul ei blochează cererile ICMP echo. Testați în schimb portul site-ului cu Scanner de porturi; dacă portul 443 răspunde, site-ul este accesibil.
Pot trimite ping unei adrese IP private?
Nu. XGM refuză adresele private, de loopback și interne, pentru că testul rulează de pe un server public. O mașină din rețeaua internă trebuie testată din interiorul acelei rețele.
De ce este adresa IP interogată diferită de cea la care mă așteptam?
Numele gazdei are mai multe adrese sau se rezolvă altfel de pe serverul XGM decât din rețeaua dumneavoastră, de exemplu printr-un CDN. Rezultatul arată adresa exactă testată, așa că nu rămâne nicio îndoială despre ce copie a fost măsurată.
Ce înseamnă un timp de ping bun?
Depinde de distanță. Zeci de milisecunde în interiorul unui continent sunt normale, iar peste 100 de milisecunde între continente este de așteptat. Mai important decât valoarea absolută este cum evoluează ea în timp pentru aceeași destinație.
Ce înseamnă * * * în traceroute?
Acel hop nu a răspuns la timp la sondă. Dacă hopurile următoare răspund, routerul doar ignoră traceroute, iar traseul este în regulă. Este o configurație foarte răspândită în rețelele marilor furnizori.
Folosește ping un port?
Nu. ICMP nu are porturi. Când ICMP nu este disponibil, instrumentul trece la teste de conexiune TCP pe porturile 443 și 80 și spune asta în rezultat, ca să nu rămână neclar cum a fost obținută măsurătoarea.
De ce se oprește traceroute înainte de destinație?
Firewallurile din apropierea destinației aruncă adesea sondele traceroute, iar instrumentul se oprește după 12 hopuri. Un serviciu poate fi în continuare accesibil; testați-i portul. Ultimele hopuri lipsă nu sunt singure un semn de defecțiune.
Este IPv6 acceptat?
Adresele sunt acceptate atunci când serverul XGM poate ajunge la ele. Dacă un nume de gazdă are atât adrese IPv4, cât și IPv6, una dintre ele este aleasă și afișată împreună cu rezultatul. Dacă vreți o anumită familie, introduceți direct adresa.