Când o aplicație „merge greu”, iar ping-ul pare normal, problema este adesea în stratul TCP, nu în IP. Aici intră în joc patru instrumente care se completează bine pe Linux: ss pentru starea socket-urilor, tcpdump pentru captură de pachete, conntrack pentru vizibilitate asupra fluxurilor urmărite de kernel și analiza retransmisiilor pentru a înțelege dacă vorbim despre pierderi, reordonare sau un blocaj de recepție.
Primul pas este să vezi rapid ce știe kernelul despre conexiuni. Utilitarul ss, parte din iproute2, poate afișa mult mai mult decât o listă de porturi. În practică, combinații precum ss -tanp, ss -ti și ss -o ajută să vezi starea TCP, procesele asociate, informații interne despre conexiune și timer-ele. Documentația man7 arată că ss poate afișa timer-ul TCP în formatul timer:(nume, timp_rămas, retrans), ceea ce este util când suspectezi retransmisii repetate sau expirări de timer. Dacă vezi multe conexiuni blocate în SYN-SENT, problema poate fi pe traseu, pe firewall sau la serviciul de destinație. Dacă vezi ESTAB, dar cu cozi mari ori timer de retransmisie activ, cauți mai departe în trafic.
Al doilea pas este captura controlată cu tcpdump. Scopul nu este „să prinzi tot”, ci să izolezi exact conversația relevantă. Pagina oficială tcpdump confirmă opțiuni esențiale precum -i pentru interfață, -nn pentru a evita rezolvările DNS și de port, -c pentru a limita numărul de pachete, -s pentru snaplen și -w pentru salvarea într-un fișier PCAP. Pentru depanare defensivă, merită capturat cât mai aproape de sursă sau de destinație, ca să reduci ambiguitatea. În plus, unele capturi cer drepturi ridicate, iar analiza trebuie făcută doar pe sisteme și rețele pentru care ai autorizare.
A treia piesă este conntrack. Manualul oficial conntrack-tools explică faptul că utilitarul conntrack interacționează cu subsistemul de connection tracking al kernelului și poate lista fluxuri existente sau asculta evenimente. Asta contează mai ales pe servere cu NAT, firewall local sau politici stateful. Dacă aplicația se plânge de timeout, dar în conntrack vezi intrări UNREPLIED, SYN_SENT sau fluxuri care dispar prea repede, ai un indiciu că problema nu este doar în aplicație. În schimb, dacă fluxul este ESTABLISHED în conntrack, dar aplicația rămâne lentă, analiza se mută spre calitatea transportului, nu doar spre existența sesiunii.
Partea cea mai ușor de interpretat greșit este retransmisia TCP. O retransmisie nu înseamnă automat „rețeaua e stricată”. Poate indica pierdere reală, congestie, reordonare de pachete, un receiver care răspunde cu duplicate ACK sau chiar o captură incompletă. Wireshark documentează separat etichete precum TCP Retransmission, Fast Retransmission, Out-Of-Order și ZeroWindow, tocmai pentru că aceste situații nu sunt echivalente. Dacă vezi duplicate ACK urmate rapid de Fast Retransmission, te uiți la pierdere sau congestie. Dacă vezi ZeroWindow, problema poate fi la receptor, care nu mai poate accepta date suficient de repede. Dacă vezi multe SYN retransmise, verifici filtrarea, traseul și disponibilitatea serviciului.
Merită clarificat și limbajul: SYN inițiază conexiunea, SYN-ACK este răspunsul serverului, iar ACK finalizează handshake-ul în trei pași. RTO este retransmission timeout, adică timer-ul după care TCP retransmite dacă nu primește confirmare; RFC 6298 definește algoritmul standard folosit de emițător pentru calculul și gestionarea acestui timer. MTU și MSS intră în discuție doar când suspectezi fragmentare sau probleme de Path MTU Discovery. Documentația kernel.org arată că Linux are parametri precum tcp_mtu_probing și tcp_base_mss, utili pentru analiză, dar ei nu trebuie modificați impulsiv înainte să confirmi cauza.
O secvență de diagnostic sănătoasă arată așa: confirmi starea cu ss, verifici existența și evoluția fluxului cu conntrack, capturezi strict traficul relevant cu tcpdump și abia apoi interpretezi retransmisiile în context. Dacă sari direct la „tuning TCP”, riști să tratezi simptomul. Dacă, în schimb, corelezi cele patru perspective, poți separa mult mai repede o problemă de aplicație, una de firewall/NAT și una de transport. Exact asta face diferența dintre o intervenție bazată pe presupuneri și un diagnostic defensiv, verificabil și sigur.
Surse
- man7.org — ss(8) Linux manual page
- tcpdump.org — tcpdump(1) man page
- conntrack-tools.netfilter.org — The conntrack-tools user manual
- datatracker.ietf.org — RFC 6298, Computing TCP’s Retransmission Timer
- wireshark.org — Wireshark User’s Guide, TCP Analysis
- kernel.org — Linux networking ip-sysctl documentation
