01.Le Contexte
Deux captures m'ont été transmises (une en Cubic, une en BBR) sans autre contexte d'infrastructure. Le travail consiste à reconstruire un scénario minimal à partir des seules traces (handshake, MSS/MTU, débit, RTT, retransmissions) et à interpréter prudemment les diagnostics automatiques de Wireshark, qui peuvent être biaisés par les conditions de capture (offloads, capture multi‑interfaces, timestamps).
01bis. Périmètre & Jeu de données
Les tests portent sur une unique conversation TCP par capture.
PCAP1 : client 10.x.x.x → serveur nPerfServer (212.27.59.208) en HTTPS/TLS 1.3 (port 443).
PCAP2 : client 10.x.x.x → serveur nPerfServer (212.27.59.161) en HTTP (port 81) avec téléchargement de /arcep/1G.bin (User‑Agent XCAL Smart). Le chiffrement TLS limite l'observation applicative sur PCAP1, mais n'empêche pas l'analyse du comportement TCP.
Le RTT issu des timestamps de capture est utilisé ici comme indicateur qualitatif. En présence de capture -i any et/ou de GRO, l'ordre et la granularité des segments peuvent être altérés, ce qui génère des alertes (segments “non capturés”, ACK “unseen”) sans nécessairement refléter un défaut réseau.
02.Analyse & Preuve par l'Image
Les figures ci‑dessous documentent l'analyse : protocoles/ports, séquence SYN/SYN‑ACK/ACK, paramètres TCP négociés (dont MSS), puis indicateurs de performance (débit, fenêtre/bytes in flight) et événements de perte (dupACK/retransmissions). L'objectif est de corréler plusieurs signaux sur la fenêtre de test (~10 s), en tenant compte des limites de capture.
Slide 1 – Avant-Propos
- Audit Algorithmique : Étude comparative de la gestion de congestion (BBR vs Cubic).
- Expertise Wireshark : Qualification technique des alertes et élimination des faux positifs liés aux conditions de capture.
- Objectif : Reconstruire le scénario réel à partir de traces brutes.
Slide 2 – Synthèse de l'audit algorithmique, comparaison directe et métriques observées
Slide 3 – Synthèse des artefacts : identification et qualification des alertes Wireshark.
Slide 4 – Identification des flux : protocoles, ports et services observés.
Slide 5 – Analyse du Handshake TCP : identification des MSS et options négociées.
Slide 6 – Profil de débit Cubic : observation de la dynamique en "dent de scie".
Slide 7 – Qualification des anomalies : distinction entre perte réelle et artefact.
- Identification technique : Les alertes "Previous segment not captured" sont corrélées aux fonctions de déchargement matériel (GRO/LRO).
- Diagnostic de fiabilité : Confirmation de l'intégrité du flux TCP malgré les biais d'observation introduits par l'interface de capture.
Slide 8 – Profil de débit BBR : observation d'un flux lissé et optimisé.
03.Résultats & Enseignements
- PCAP1 (Cubic) : montée rapide du débit puis oscillations, avec pertes détectées (dupACK / fast retransmission) et ajustement de la fenêtre de congestion.
- PCAP2 (BBR) : montée plus progressive et stabilisation du débit, sans retransmissions ni dupACK marquants sur la période observée.
- Les alertes Wireshark majoritaires (“previous segment not captured”, “ACKed unseen segment”) sont compatibles avec des artefacts de capture (tcpdump -i any + SLL, offload GRO), plutôt qu'avec une anomalie TCP réelle.
- Le couple MSS/MTU diffère entre captures et peut traduire un MSS clamping par un équipement intermédiaire ; c'est un point à contrôler car il influence segmentation et performance.
- Pour confirmer les écarts Cubic/BBR, il faut répéter les tests (durée plus longue, conditions radio/réseau variées) avec une capture maîtrisée : interface ciblée et offloads désactivés le temps de la mesure.