On note que le serveur n'a pas reçu les reset d'où la retransmission de paquet qu'il considère perdu faite d’acquittement.[/size]
En effet, bizarre.
Il y a peut-être quelque chose qui ne plait pas au client dans la réponse du serveur, mais ça n'explique pas que le RST n'arrive pas au serveur (la box ?).
On note que le serveur n'a reçu que le premier reset.[/size]
Dans mon cas je n'ai que la première retransmission du serveur (ce qui ne veut pas dire qu'il n'y en a pas d'autres, potentiellement éliminées par la box).
Le client et le serveur ont fermé la connexion TCP en même temps, chacun de son initiative.
Ca génère le premier RST côté client, mais autant dans mon cas avec la latence je ne suis pas 100% sûr, autant dans ton cas je ne comprends pas pourquoi le serveur persiste après l'avoir reçu.
Sur un test simple, openssl s_client server:433, Ctrl+C (le client termine la connexion TCP, sans même avoir envoyé d'Encrypted Alert SSL) :
- sur lafibre.info ou apache.org :
=> FIN,ACK
<= Encrypted Alert
=> RST
<= FIN, ACK
=> RST
- sur
www.google.fr, mozilla.org, mon nginx en local :
=> FIN,ACK
<= FIN,ACK
=> ACK
La premier cas est un peu moins élégant, mais tant que ça s'arrête là (pas de retransmission à priori, à moins que ce soit filtré par ma NB6V) ce n'est pas grave car ça ne fait qu'un petit paquet en plus dans chaque sens.