Cum citim pierderea de pachete înainte de a da vina pe cablu

O pierdere de două procente pe parcursul unei serii lungi de ping pare o cifră pe care se poate acționa, și rareori este. Nu spune unde au dispărut răspunsurile, dacă au dispărut împreună sau cum a trăit acel interval o anumită aplicație. O pierdere răspândită uniform pe un minut și o pierdere adunată într-un singur schimb produc rezultate foarte diferite pentru același procentaj.

Comparați trei măsurători în loc să vă încredeți într-una: ce a văzut sonda, ce au făcut contoarele interfeței și la ce a așteptat de fapt aplicația.

Ce măsoară de fapt un procentaj de ping

O sondă de ecou testează o direcție a unui protocol cu o singură dimensiune de pachet, la ritmul pe care l-ați ales. Un tunel care transportă o încărcare mare face cu totul altceva, iar o legătură care aruncă sonde mici nu este neapărat legătura care dăunează transferului. Procentajul strivește și informația de timp care contează cel mai mult, pentru că zece răspunsuri pierdute într-un singur val nu sunt același lucru cu zece răspunsuri pierdute la o oră distanță. Nu vă poate spune nici care parte a tunelului a aruncat ceva.

Păstrați rezultatul sondei ca indiciu despre cale. Apoi căutați momentul și limita care l-au produs.

Comparați diferențele contoarelor, nu totalurile pe viață

Luați citiri cu marcă de timp înainte și după fereastra în care a apărut simptomul, la ambele capete și pe orice port de comutator pe care îl controlați. Notați volumul de trafic împreună cu erori, eliminări și modificări ale stării legăturii, pentru că un total diferit de zero acumulat de-a lungul lunilor descrie istoria, nu acest incident. Un contor care s-a mișcat cu trei în timpul pauzei este o observație diferită de un contor care arată trei mii și nu s-a schimbat niciodată.

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

Pachetele eliminate din cauza erorilor de recepție și pachetele eliminate din alte motive trăiesc în contoare separate, iar această distincție schimbă pasul următor. Contoarele de erori indică nivelul fizic sau nivelul driverului, în timp ce presiunea cozilor și eliminările de politică indică undeva deasupra. Păstrați și direcția și numele interfeței, pentru că o creștere a erorilor de recepție pe o legătură ascendentă și un contor de pachete de tunel nu sunt interschimbabile.

Dacă un driver expune contoare fizice detaliate, citiți-le prin documentația acelui adaptor. A atribui un singur sens fiecărui câmp numit „drop” la doi producători este felul în care o banală particularitate contabilă devine un diagnostic de hardware.

Cum un segment pierdut devine o așteptare lungă

O aplicație poate aștepta mult mai mult decât o singură călătorie dus-întors după ce pierde un segment. TCP estimează timpul dus-întors, calculează un temporizator de retransmisie din acea estimare și se retrage când și o retransmisie eșuează, așa că un singur segment pierdut în momentul nepotrivit poate opri o cerere pentru un interval vizibil. Acel mecanism este specificat în RFC 6298 și explică de ce o rată de pierdere care pare trivială poate fi totuși resimțită.

Totuși nu fiecare pauză este un timeout de retransmisie. Aceeași așteptare poate veni din rezolvarea numelor, dintr-un server lent sau dintr-o aplicație care își reîncearcă propria cerere după un eșec. Separați aceste cazuri aliniind operația eșuată cu observațiile de transport și cu evenimentele de sesiune ale tunelului însuși. O întrerupere pe calea datelor fără reconectare este un eveniment diferit de o nouă strângere de mână și un schimb de acreditări.

Unde captura este permisă, țineți-o îngustă. Ce aveți nevoie este să știți dacă pachetele sau confirmările așteptate se opresc la o limită anume, nu faptul că undeva într-o urmă aglomerată există o retransmisie.

Schimbați o singură limită fără a le mișca pe celelalte

Dacă dovezile indică o legătură locală, înlocuiți un cablu sau un port aprobat ca comparație controlată și lăsați tot restul în pace. Mențineți capătul, aplicația și sarcina de lucru comparabile și schimbați exact o limită pe încercare. Compararea unui laptop cu cablu cu unul fără fir în timp ce schimbați și ieșirile și protocoalele nu vă spune nimic ce puteți atribui.

Contoarele locale curate nu certifică restul căii. Ele delimitează partea pe care o vedeți, iar raportul onest spune ce limite au fost observate și care nu. La final doriți o afirmație că o observație s-a schimbat când a avut loc o intervenție, nu o anecdotă despre un cablu prost ridicată la rang de regulă universală.