TCP SACK et DSACK dans Wireshark : diagnostiquer la perte de paquets, l'option sack_perm et la retransmission dans les PCAP

L'analyse de la retransmission TCP devient beaucoup plus précise lorsque l'accusé de réception sélectif est disponible. Les utilisateurs recherchent « TCP SACK pcap », « DSACK Wireshark », « dupliquer SACK », « retransmission parasite », « réorganisation TCP contre perte de paquets » et « capture sélective de paquets ACK » lorsqu'une trace montre des ACK en double, des retransmissions et des paquets dans le désordre, mais la cause première n'est pas claire.

La chirurgie PCAP est utile car la preuve SACK est contenue dans les options TCP. Si vous supprimez les mauvais paquets, perdez la poignée de main ou séparez les ACK des données, le diagnostic devient plus faible.

Ce que SACK ajoute

Les ACK TCP traditionnels reconnaissent le prochain octet attendu. Si un segment est manquant mais que des segments ultérieurs arrivent, le récepteur ne peut que continuer à accuser l'écart.

SACK laisse le récepteur dire : "Il me manque toujours cette plage antérieure, mais j'ai reçu ces plages ultérieures."

Cela permet de distinguer :

• Perte réelle de paquets.
• Livraison hors commande.
• Paquets en double.
• Comportement du récepteur.
• Comportement de récupération de l'expéditeur.

SACK doit être négocié

La capacité SACK est négociée dans le SYN et le SYN-ACK. Si la capture démarre après la poignée de main, vous ne savez peut-être pas si SACK a été autorisé.

Conservez toujours :

• SYN.
• SYN-ACK.
• Option SACK autorisée.
• Option d'échelle de fenêtre.
• Option d’horodatage si présente.

C'est pourquoi un « petit pcap autour de la retransmission » peut s'avérer insuffisant.

Dupliquer des ACK avec des blocs SACK

Les ACK en double ne signifient pas tous la même chose. Un ACK en double avec des blocs SACK peut indiquer à l'expéditeur exactement quelles plages d'octets ultérieures sont arrivées.

Preuves à inspecter :

• Numéro ACK.
• SACK bord gauche et bord droit.
• Blocs SACK répétés.
• Nouvelles informations SACK.
• Si les données manquantes apparaissent ultérieurement.
• La retransmission comble-t-elle le vide?

C’est bien plus efficace que de simplement compter les ACK en double.

Perte de paquets ou réorganisation

Si un segment arrive en retard mais n'est pas perdu, SACK peut indiquer que des données ultérieures ont déjà été reçues. L'expéditeur peut retransmettre, puis le paquet d'origine peut également arriver. Cela peut paraître compliqué.

Questions :

• Le segment original est-il arrivé en retard ?
• La retransmission est-elle arrivée en premier ?
• DSACK a-t-il signalé ultérieurement des données en double ?
• Existe-t-il un chemin qui réorganise les paquets ?
• Les salves traversent-elles plusieurs liens, tunnels ou chemins à charge équilibrée ?

La chirurgie PCAP peut aider à isoler la plage de séquences exacte et à comparer l’ordre des paquets.

Ce que signifie DSACK

Duplicate SACK peut signaler que des données en double ont été reçues. Ceci est utile pour identifier les retransmissions parasites ou les réorganisations.

Les preuves DSACK peuvent suggérer :

• L'expéditeur a retransmis inutilement.
• Le réseau a livré les données originales en retard.
• Le point de capture a vu des doublons.
• Le récepteur a obtenu à la fois les octets d'origine et les octets retransmis.
• Paquets dupliqués par la Middlebox.

C'est une conclusion différente de « le paquet a été perdu ».

Retransmissions parasites

Une retransmission n'est pas toujours une preuve de perte. Il peut être déclenché par :

• Reordering.
• Comportement ACK retardé.
• Capturez les artefacts de déchargement.
• Délai de retransmission trop court.
• Compression ACK.
• Calendrier de virtualisation.
• Asymétrie du chemin.

SACK et DSACK aident à prouver si les données étaient réellement manquantes ou simplement en retard.

Le point de capture est important

Si le pcap est unilatéral ou pris derrière un NAT, l'interprétation de SACK peut être délicate. Un paquet peut être absent de votre point de capture mais présent chez le récepteur.

Pratique utile :

• Comparez les captures côté expéditeur et côté récepteur.
• Gardez les horodatages synchronisés.
• Conserver les numéros de séquence.
• Évitez de supprimer les paquets ACK uniquement.
• Notez l’emplacement de déchargement et de capture.

L'analyse SACK sans paquets ACK n'est pas une analyse.

Liste de contrôle de débogage

Utilisez ce flux de travail :

1. Conservez la poignée de main TCP.
2. Confirmez que SACK est autorisé.
3. Recherchez le premier ACK en double.
4. Décodez les blocs SACK.
5. Mappez les plages SACK aux paquets de données.
6. Identifiez les plages de séquences retransmises.
7. Vérifiez DSACK.
8. Séparez la perte de la réorganisation.
9. Vérifiez le point de capture et le contexte de déchargement.
10. Conservez les paquets avant/après autour de l’événement de récupération.

Diagnostic final

TCP SACK et DSACK fournissent des preuves précises de la perte de paquets, de la réorganisation, de la livraison en double et des retransmissions parasites. La clé est de préserver les options de prise de contact, les paquets ACK uniquement, les blocs SACK et les plages de séquences retransmises.

PCAP Surgery aide à conserver ces preuves intactes afin que l’analyse des pertes TCP puisse aller au-delà des décomptes génériques d’ACK en double.