Voilà, ma question concerne le dessin ci-dessous.
Il décrit une connexion entre A et B du début jusqu'à la fin. Le texte en noir est la base, à moi de remplir, j'ai donc mis tout le rouge (plus la plupart des flèches)
Pour chaque message, le tag indique le type de message, les deux chiffres entre parenthèses sont les numéros de séquence et d'accusé.
Mon problème principal concerne l'endroit du cercle rouge, le renvoi des données est-il déclenché par la réception d'un ACK (accusé de réception) "éronné" ou par le passement du délai (symbolisé par la flèche verticale ?
Sinon, à part ce point sensible, le reste est conforme au comportement de TCP ?
 

 
merci pour votre aide

Je pencherais plutôt pour un désynchronisation entre l'émetteur et le récepteur: côté serveur, apres l'envoi de DATA[26], se déclenche un timeout (200ms il me semble) en attendant un ack de ce segment, auquel cas, il reessaiera de renvoyer ledit segment. Or côté client, il attend le segment b+1 et voit arriver b+27 => désynchronisation (depuis les recnete versions de TCP, au moindre probleme, pouf reset) donc il y a reset du client

hum...d'accord. Mais n'est-ce pas possible que le client se comporte avec le message FIN comme il se comporterais avec des données ? Dans le cas de données, et bien on avancerait pas encore la fenêtre, puisqu'il y aurait un trou, mais dès que ce trou serait comblé, on avance directement de plusieures éléments.
En tout cas, merci pour ta réponse ...même si je dois bien avouer que pour le coup elle ne me satisfait pas pleinement... peut-être dans une ancienne version du protocole ?

Aprés vérification, TCP fait le coup du reset moins souvent que je ne le croyais
 
Donc dans ton cas, ce que tu as mis est bon, l'envoi du segement DATA[26] déclenche un timeout (30s à 2 minute après vérification, 200ms est pour un autre cas ).
 
Pendant ce temps, le serveur envoit son FIN, acquitté par le client => connexion client ->serveur fermée
 
Voila, ce que je n'avais pas capté, au même moment que la réception du ACK, le timeout du serveur expire et il renvoit DATA[26] => ack du client qui attend bien b+28 (b+27 ayant déjà été reçu ) inclus dans un FIN.
 
Il manque juste une flèche cote serveur qui renvoit un ack pour le FIN du client

Je n'ai pas tout compris là    
Arrête-moi si je me trompe, mais le client ne peux pas acquitter le message FIN puisque sa séquence est bien plus élevée que ne l'est sa valeur d'accusé à ce moment-là. Donc deux options, soit il attend les 26 octets manquant, sans rien faire, puis envoi ACK+FIN dans un message, soit il envoi le ACK que j'ai mis sur le dessin (le même qu'auparavant à priori, puisqu'incrémenter l'accusé pour signifier la réception du FIN semble peu judicieux). Du coup, s'il envoi ce ACK, le serveur renvoi ses données parce-qu'il reçoit ce message ? Ou plutôt parce-que son timeout expire    
Mon problème exact concerne le comportement du client lorsqu'il reçoit un message de FIN à séquence supérieure à son accusé.
 
En tout cas merci de ton aide, tu t'es même documenté pour moi, il ne fallait pas

 
Il y a une erreur que je n'avais pas vu, d'ou ton probleme de comprehension
En effet, le SYN envoyé par le serveur doit être SYN(b+27;a+2)("j'envoie le segment n°a+1 et j'attend de recevoir le segment n°a+2" ); car le serveur a envoyé un segment DATA[26](b+1;a+1) avant mais ne sais pas encore que le segment a été perdu (pas d'expiration encore du timeout associé à ce segment).
Alors le client doit envoyer un ACK(a+2;b+28) et sait donc qu'il lui manque le segment a+1.
 
Enfin, le serveur ferme la connexion client ->serveur par un ACK(b+28;a+3).
 
Ensuite, la question d'une fermeture de connexion, alors qu'un segment manque me turlupine du coup. Je me renseigne
 
PS: j'espere pas trop m'etre embrouille ou t'avoir embrouille