J'utilise firefox pour visiter un serveur web fonctionnant sur un ordinateur de mon réseau local. Je remarque que parfois TCP n'accuse pas réception des paquets qu'il reçoit. Par exemple, dans les paquets capturés suivants :
https://docs.google.com/file/d/0B-LaBUj9KtQhS0RYNXF1RjZTa2M/edit?usp=sharing
les 7ème, 9ème et 11ème paquets sont des ACK dupliqués, le navigateur reçoit les paquets TCP 6,8 et 10, mais la pile TCP du navigateur n'accuse pas réception des paquets reçus, pourquoi ?
C'est le cas.
Vous voyez probablement Accusé de réception différé TCP Dans ce cas, le destinataire peut attendre jusqu'à 500 ms pour envoyer un paquet ACK combiné qui accuse réception de plusieurs paquets reçus. C'est un bon moyen de réduire la surcharge lorsque vous avez beaucoup de paquets et que vous ne vous souciez pas particulièrement de la latence.
Cela peut augmenter la latence perçue, et c'est donc cette fonctionnalité que l'on voit désactivée dans de nombreux "correctifs TCP" que l'on peut trouver pour les jeux : en fixant la valeur de TCP_ACKNOWLEDGE_DELAY à 0, Windows enverra tous les ACK immédiatement au lieu d'essayer de les regrouper. Ceci a l'inconvénient de créer plus de trafic réseau, avec peu d'avantages. Il s'agit de donne l'impression de réduire la latence mais les paquets de données ne sont pas envoyés plus vite.
Ce n'est pas le cas.
Il reconnaît simplement chaque octet du flux, ce qui est très différent. Pour une raison quelconque, le TCP du récepteur (celui sur lequel tourne le navigateur) manque le segment n° 6. Comme le récepteur demande immédiatement sa retransmission, il a dû le recevoir avec une erreur de somme de contrôle.
Tous les segments reçus par la suite (8, 10, 12) sont des segments non ordonnés et déclenchent des acks en double, dont le but est de demander la retransmission du segment n° 6. Comme le chemin de communication entre le récepteur et l'expéditeur subit une certaine latence, l'expéditeur s'en aperçoit un peu tard, réduit la longueur de son tuyau (ou fenêtre de congestion) et retransmet les données contenues dans le segment n° 6.
Ensuite, une autre chose intéressante se produit dans le segment #15 : le récepteur n'envoie pas d'accusé de réception cumulatif sur 8, 10, 12 mais accuse réception uniquement du segment #14, ce qui signifie qu'il a écarté 8, 10 et 12, soit parce qu'ils étaient également sujets à la corruption de données, soit parce qu'il s'agit d'une implémentation TCP très simple. Vous pouvez activer l'évaluation de la somme de contrôle TCP dans wireshark, (il échoue ici à chaque segment sortant en raison du fait que le système d'exploitation laisse le champ de somme de contrôle invalide pour que la carte ethernet puisse l'évaluer) et il confirme la première interprétation : erreurs de somme de contrôle sur 8, 10, 12. Il doit y avoir un lien très bruyant sur le chemin.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
