Connexion TCP N°0 :
Effectivement la réception des ACK + DUP ACK ensemble est très étrange.
Si on suppose que le problème est sur le PC, alors ça peut être :
- un bug dans l'offload (mais il n'y en a pas énormèment sur du Realtek)
- un bug autour des fonctionalités d'économie d'énergie (green ethernet, ASPM, ...)
Il y a eu pas mal de changements dans r8169 autour de l'ASPM, j'ai un patch local pour ne pas désactiver l'horloge du Realtek car l'ASPM est activé par mon BIOS (sans désactivation possible), et la sortie du mode L1.2 est trop lente ce qui engendre des pertes de trames Ethernet si le réseau ne supporte pas le controle de flux, avec comme résultat des performances catastrophiques).
Je suggère d'essayer des kernels différents, ou une autre carte réseau (par exemple en USB).
Connexion TCP N°2 :
Le serveur a reçu le FIN du client, mais envoit pourtant les données (peut-être des buffers quelque part, ou le comportement du programme), c'est autorisé par le TCP.
Connexion TCP N°3 :
La fermeture simultanée arrive à cause des Encrypted Alert (le serveur reçoit celui du client, et donc envoie le sien et le FIN, sauf que le client a envoyé son FIN immédiatement).
Jusque là, j'ai la même chose sur apache.org par exemple, mais je ne comprends pas pourquoi le serveur persiste après avoir reçu le RST.
Les connexions N°2 et N°3 semblent effectivement avoir été annulées par le client, mais le délai entre l'ACK et le paquet Application Data du client est étrange (respectivement 44ms et 100ms), surtout que l'Encrypted Alert suit (je ne voit aucun cas où le client voudrait faire un GET pour l'annuler immédiatement).
Peut-être que ce sont des connexions spéculatives (network.http.speculative-parallel-limit ?) qui sont finalement annulées car plus nécessaires, mais je ne sais pas quelles données pourraient être envoyées par le client.
Malheureusement Debian/Ubuntu n'activent pas le support de SSLKEYLOGFILE (
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format) donc impossible de déchiffrer les échanges dans Wireshark.