Les forums sont fermés. Ils restent présent pour consultation et archivage.
Vous pouvez désormais poser vos questions directement dans les commentaires en bas de chaque page du site.
Alors n'hésitez pas à participer

ACK et TCP

Bonjour, J'ai une question à propos des ACK sous TCP. Je fais actuellement une analyse de trame d'un client vers un serveur, et j'ai remarqué à plusieurs reprises que la transmission d'un ACK se faisait 0.200s après la réception du paquet. Ceci ne vient pas du réseau car je snif coté client, c'est lui qui reçoit le paquet et qui émet cette ACK 0.200s plus tard(sans donnée juste l'ACK soit les 54 octets de l'entete) . De plus j'ai remarqué que quand le client envoi des donnée avec l'ACK ce délai est ridicule. Le client a t'il un time out afin d'être sur qu'il n'y a pas de donnée a transmettre avec l'ACK? Si oui est ce normal que le time out soit ci long? Quelqu'un aurait il une idée sur le pourquoi de ce délai ci long!!

Bonjour, Il s'agit du comportement de "Delayed ACK" décrit dans la RFC 1122 : un acquittement tous les 2 segments reçus ou lorsque ou à l'expiration du timer (entre 0 et 0.5 sec ; généralement 200 ou 100 ms). L'algorithme de Nagle permet d'éviter d'envoyer trop de petits segments en temporisant afin de remplir les segments. Delayed ACK et Nagle peuvent plomber les performance de TCP. Cf : http://www.stuartcheshire.org/papers/NagleDelayedAck/ Si tu souhaites ne pas attendre le délai, tu peux essayer de passer le flag TCP PUSH à 1.