Auteur Sujet: Tuto:Analyser les problèmes de débit avec Wireshark (exemple avec Freebox Delta) (Lu 30534 fois)

vivien · « **Réponse #48 le:** 18 février 2020 à 20:39:45 »

Oui, intéressé si c'est du mono-connexion (difficile 'analyser quelques chose sur du multi-connexions TCP).

Le trafic étranger ne me gène pas, je filtre toujours sur la connexion TCP de la capture.

Cryptage · « **Réponse #49 le:** 18 février 2020 à 20:54:54 »

C'est du mono-connexion oui, j'ai utilisé cette commande :

Code: [Sélectionner]

iperf3 -c bouygues.testdebit.info -t 20 -i 1 ( -4 ) ( -C bbr)
Le test a été fait à 13h : entre 80-130 Mbps en Cubic et 450-500 Mbps en BBR de mémoire.
--> Je te fais parvenir ça par MP.

vivien · « **Réponse #50 le:** 19 février 2020 à 08:32:34 »

La compression de tes captures est impressionnante : ton .tar.lzma a une taille de 6,2 Mo compressé et fait 3,3 Go décompressé.

Je commence par la capture Cubic IPv6

On voit assez quelques pertes de paquets. Wireshark à tagué 23 paquets "Out-of-Order" et 13 paquets "TCP Fast Restransmission", cela fait donc en réalité 36 paquets perdus.

(Le filtre à utiliser est tcp.analysis.retransmission et tcp.analysis.out_of_order pour voir ces paquets)

La courbe n'est pas une droite parfaite, on voit que le débit baisse à chaque perte de paquet, pour remonter doucement ensuite.

(cliquer sur le graphique pour zoomer)

vivien · « **Réponse #51 le:** 19 février 2020 à 08:40:37 »

Un point important est le début de la connexion : si cela démarre mal, le trafic a de très forte chance d'être limité.

Voici les paquets de données depuis le début.

On note que lors de la 3ème slave d'envoi de paquets, à T=0,074, il y a des traits rouges, correspondants à ce que Wireshark considère comme [TCP Dup ACK] :

(cliquer sur le graphique pour zoomer)

Quand on regarde le détaille, on note qu'un paquet, celui qui commence par 54302 a été retardé de 4 paquets.

Il y a donc un vrai problème dés le début et on voit que l'émetteur à réduit sa vitesse d'émission : Avant on était sur des paquets de 6 à 10 Ko, immédiatement après cette gigue on est majoritairement sur des paquets de 1,5 Ko.

(cliquer sur le graphique pour zoomer)

vivien · « **Réponse #52 le:** 19 février 2020 à 08:49:35 »

On continue avec la capture Cubic IPv4

On voit assez quelques pertes de paquets. Wireshark à tagué 45 paquets "Out-of-Order" et 17 paquets "TCP Fast Restransmission", cela fait donc en réalité 62 paquets perdus.

Attention, ce ne sont pas des paquets de MTU de 1500, ce sont des paquets vu de ton PC, avant qu'ils soient découpés par la carte réseau. Certains paquets retransmis ont une taille de 14546 octets, c'est donc un assemblage de 10 paquets.

En réalité on dépasse donc les 100 paquets perdus.

La courbe n'est pas une droite parfaite, on voit que le débit baisse à chaque perte de paquet, pour remonter doucement ensuite.

(cliquer sur le graphique pour zoomer)

Voici le tout début de la connexion, au note a la 5ème slave de paquets envoyés un éclatement des buffers, on est dans le même cas que Breizh29.

(cliquer sur le graphique pour zoomer)

vivien · « **Réponse #53 le:** 19 février 2020 à 09:01:36 »

Voici la suite de la connexion, avec le même niveau de zoom que celui utilisé pour le tout début de la connexion.

On est à t=0,3 sec donc encore au début et là on observe 3 phénomènes de gigue, déjà observée dans les autres captures.

Pour le premier phénomène de gigue, le comportement de l'émetteur est différent de ce que l'on à vu jusqu'à présent : il va renvoyer le paquet, pensant qu'il est perdu.

C'est inutile car il est acquitté immédiatement derrière, donc l’acquittement correspond au paquet initial reçu avec un peu de retard.

On observe plus tard l’acquittement spécifique au paquet reçu en double.

(cliquer sur le graphique pour zoomer)

Dans la vue par paquet, on voit :
- T=0,335 Le paquet 3110342 est arrivé en retard de 2 paquets
- T=0,335 l'émetteur a renvoyé le paquet présumé perdu dés le second [TCP Dup ACK]
- T=0,348 Le paquet renvoyé en double est acquitté de manière spécifique par le récepteur avec du SACK, pour bien faire comprendre à l'émetteur que le paquet a été reçu en double.

TCP ayant une capacité d’apprentissage, comme l'acquittement spécial, il laissera plus de temps lors des prochains phénomène de gigue pour recevoir l’acquittement. Bref, TCP prend en compte que cette connexion est dégradée et qu'elle a une forte gigue : il faut donc envoyer les paquets à un débit plus réduit (plus ils sont rapprochés, pus il y a un risque d'être dans le désordre à la réception) et en cas d'acquittements qui mentionnent une perte de paquets, laisser plusieurs paquets passer, au ca où cela serait une gigue.

(cliquer sur le graphique pour zoomer)

vivien · « **Réponse #54 le:** 19 février 2020 à 09:14:28 »

La capture BBR en IPv6

En IPv6 Cubic, 240 Mo ont été échangés pendant les 20 secondes (l'axe des ordonnée s’arrête à 240 000 000 octets)

En IPv6 BBR, c'est plus de 1,2 Go qui ont été échangés pendant les 20 secondes (on dépasse 1 200 000 000 sur l'axe des ordonnée)

=> BBR a un débit moyen plus de 5 fois plus élevé à Cubic ici

Vous savez que si BBR est agressif, cela va faire des paquets perdus en masse.

Le filtre tcp.analysis.retransmission annonce 912 paquets, dont la plupart sont d'une grande taille (certains font même 53 Ko)
Le filtre tcp.analysis.out_of_order annonce 13 938 paquets, dont la plupart sont d'une grande taille (certains font même 60 Ko !)

On est donc sur de la perte de paquet massive.

(cliquer sur le graphique pour zoomer)

Comme pour les autres captures, voici le tout début de la connexion.

On remarque que BBR envoi les paquets à un rythme régulier, là où BBR envoi des slave de paquets.

Tout se passe bien quand le débit est réduit, jusqu'à T=0,2 secondes ensuite ce sont des pertes massives.

(cliquer sur le graphique pour zoomer)

vivien · « **Réponse #55 le:** 19 février 2020 à 09:24:24 »

Un point intéressant, c'est que l'on voit à la 15ème seconde du test que le trafic s’arrête un certain temps.

Voici le zoom sur cette période :

(cliquer sur le graphique pour zoomer)

Les paquets d'acquittement sélectif (SACK = selective acknowledgement)sont limités à un maximum de 3 blocs discontinus de paquets reçus correctement, en plus du numéro de séquence suivant immédiatement le dernier numéro de séquence du dernier octet contigu reçu successivement.

Ici on dépasse visiblement 3 blocs discontinus, et il n'est donc pas simple à l'émetteur de faire son choix dans les paquets à ré-émettre.

La situation a visiblement dérapé. Voici le vue par paquets, j'ai coupé la partie droite, c'est simple, tous les paquets d’acquittements sont remplis de 3 blocs discontinus, le maximum possible.

Je dois par contre partir travailler, je ne pourrais pas analyser tout de suite la cause de cette interruption du trafic en BBR.

(cliquer sur le graphique pour zoomer)

On note que quand l'émetteur repart après avoir renvoyé quelques paquets dont il attendait l’acquittement, BBR repart directement au débit maximum, alors que Cubic dans des situation comme celle à repart en "slow start" comme au début d'une connexion TCP, en envoyant quelques paquets puis attendant leur acquittements.

vivien · « **Réponse #56 le:** 19 février 2020 à 14:00:22 »

Capture BBR en IPv4

On a une belle droite : le débit est stable.

Contrairement à la courbe BBR en IPv6, il n'y a pas d'interruption

(cliquer sur le graphique pour zoomer)

Voici la courbe du début de la connexion.

On note deux interruption de courtes durées à T=0,2 sec et T= 0,26 sec

(cliquer sur le graphique pour zoomer)

vivien · « **Réponse #57 le:** 19 février 2020 à 14:01:37 »

On va ensuite avoir régulièrement ces petites coupures, où l’émetteur n'émet plus rien pendant une courte durée.

Un gain de débit est donc encore possible

(cliquer sur le graphique pour zoomer)

(cliquer sur le graphique pour zoomer)

vivien · « **Réponse #58 le:** 19 février 2020 à 14:05:55 »

Un zoom sur un de ces coupures.

Il y a un trait bleu des paquet émis à gauche puis un peu plus à droite un trait bleu en pointillé, ce sont tous les paquets renvoyés.

On note que pendant cette coupure, l’émetteur continue de renvoyer tous les paquets qui lui sont signalés perdus.
C'est uniquement la courbe de gauche qui est mis en pause quelques dizaines de millisecondes.

Pendant cette coupure, le débit est faible est les buffers doit se vider : on n'exploite pas au maximum le débit offert par la ligne dans ces moments là.

(cliquer sur le graphique pour zoomer)

Cryptage · « **Réponse #59 le:** 19 février 2020 à 23:38:40 »

Est-ce que cette analyse te permet de conclure ? Par exemple sur des buffers trop petits comme supposé précédemment ?