Retransmissions TCP et ACK en double dans PCAP : comment lire le modèle avant de blâmer le serveur
Comment interpréter les retransmissions TCP, les ACK en double, les retransmissions rapides et les paquets dans le désordre dans les captures de paquets sans passer au mauvais propriétaire.
Les retransmissions TCP et les ACK en double font partie des sujets d'analyse de paquets les plus recherchés, car ils apparaissent dans les cas d'applications lentes, les problèmes de transfert de fichiers, les problèmes d'ingestion vidéo, les plaintes VPN et les incidents de connectivité cloud. L'erreur est de considérer chaque retransmission comme une preuve que le serveur est mauvais.
Un PCAP peut afficher la perte de paquets, la réorganisation, la congestion, les artefacts de point de capture ou le retard d'application. Le modèle compte.
Que signifient les ACK en double
Un ACK en double signifie souvent que le récepteur a reçu des données au-delà d'un segment manquant et demande toujours le prochain octet attendu. Plusieurs ACK en double peuvent déclencher une retransmission rapide. Dans un analyseur de paquets, cela peut apparaître à côté d'étiquettes telles qu'ACK en double, retransmission rapide, retransmission ou dans le désordre.
Les questions utiles sont :
- quelle direction a des ACK en double ?
- est-ce qu'une retransmission s'ensuit ?
- la retransmission répare-t-elle l'écart ?
- la capture est-elle proche de l'expéditeur, du destinataire ou du chemin intermédiaire ?
- les paquets sont-ils simplement en panne ?
- le retard d'application se produit-il avant ou après la récupération du transport ?
Sans direction ni point de capture, l’étiquette à elle seule constitue une preuve faible.
La direction vous indique où chercher
Si les retransmissions apparaissent principalement du serveur au client, le chemin de transfert peut perdre des données du serveur au client. S'ils apparaissent principalement du client vers le serveur, inspectez la direction opposée. Si des ACK en double sont vus au point de capture de l’expéditeur, ils prouvent que l’expéditeur a reçu des ACK répétés. S'ils ne sont vus qu'à proximité du destinataire, l'expéditeur ne les a peut-être pas encore vus.
C’est pourquoi les captures multipoints sont puissantes mais aussi risquées. Ils doivent être soigneusement alignés. Les différences horaires entre les hôtes de capture peuvent donner lieu à de fausses conclusions.
Un produit hors service n'est pas toujours une perte
Les paquets peuvent arriver dans le désordre sans être perdus. L'équilibrage de charge, les chemins parallèles, le placement des captures, la virtualisation et le comportement de déchargement de la carte réseau peuvent tous affecter l'ordre observé. Un analyseur de paquets peut signaler un trafic dans le désordre, mais l'application peut récupérer sans délai significatif.
Rechercher:
- retransmission après des ACK en double
- informations ACK sélectives
- augmentation du temps aller-retour
- changements de taille de fenêtre
- perte répétée à des tailles de rafales similaires
- corrélation avec les blocages d'applications
Cela sépare les réorganisations inoffensives des pertes qui affectent l'expérience utilisateur.
Ne modifiez pas avant d'avoir compris
Dans les flux de travail de chirurgie PCAP, l’analyse TCP doit être un examen des preuves avant la mutation. Vous pouvez éventuellement découper, anonymiser, diviser ou annoter une capture. Mais préservons d’abord le modèle de transport. La réécriture des horodatages ou la suppression de paquets avant d'analyser le comportement de retransmission peut détruire les preuves de synchronisation.
Un flux de travail sécurisé :
- conserver la capture originale
- identifier la conversation TCP
- inspecter le sens des retransmissions
- comparer les numéros de séquence et les numéros ACK
- enregistrer les hypothèses sur les points de capture
- alors seulement, produisez une copie tronquée ou anonymisée
L’objectif n’est pas seulement un fichier plus petit. L’objectif est de présenter un dossier défendable.
La place de la chirurgie PCAP
PCAP Surgery est conçu pour la capture de paquets de preuves et les modifications contrôlées. Pour les cas de retransmission TCP, cela devrait aider les ingénieurs à inspecter les métadonnées des paquets, à isoler une conversation et à préparer un transfert propre sans perdre le raisonnement.
Les résultats utiles incluent :
- points de terminaison de conversation
- nombre de paquets
- nombre de retransmissions
- dupliquer le modèle ACK
- directionality
- timing autour de l’échec
- si la sortie éditée a conservé les preuves de séquence
C'est ce dont les ingénieurs réseau, les équipes back-end et les fournisseurs ont besoin pour discuter de la propriété. Une étiquette de retransmission est un indice. Une capture directionnelle, horodatée et reproductible en est la preuve.
Si votre requête de recherche est « TCP duplicate ACK PCAP » ou « Analyse de retransmission TCP », commencez par le modèle, la direction et le point de capture avant de blâmer le serveur, le client ou le réseau.