Nicolas KOWALSKI a écrit :
>
> - fin de la connexion initiée par le serveur distant, FIN:
>
> 08:29:12.000665 IP 74.125.79.109.995 > 192.168.0.1.51542: F 2051:2051(0) ack
> 444 win 106 <nop,nop,timestamp 2547694355 84435379>
>
> - mais mon serveur continue à envoyer des choses, le QUIT peut-être:
>
> 08:29:12.001353 IP 192.168.0.1.51542 > 74.125.79.109.995: P 444:467(23) ack
> 2052 win 362 <nop,nop,timestamp 84435394 2547694354>
>
> - et seulement maintenant il envoit le FIN-ACK:
>
> 08:29:12.002039 IP 192.168.0.1.51542 > 74.125.79.109.995: F 467:467(0) ack
> 2052 win 362 <nop,nop,timestamp 84435394 2547694354>
>
> - en face, le serveur râle (?), et balance deux RST:
>
> 08:29:12.042022 IP 74.125.79.109.995 > 192.168.0.1.51542: R
> 2894719309:2894719309(0) win 0
> 08:29:12.042276 IP 74.125.79.109.995 > 192.168.0.1.51542: R
> 2894719309:2894719309(0) win 0
>
> C'est un peu étrange quand même.
Je ne suis pas un fin connaisseur des subtilités de TCP, mais j'ai
trouvé ça dans RFC 793 :
Case 2: TCP receives a FIN from the network
If an unsolicited FIN arrives from the network, the receiving TCP
can ACK it and tell the user that the connection is closing. The
user will respond with a CLOSE, upon which the TCP can send a FIN to
the other TCP after sending any remaining data. The TCP then waits
until its own FIN is acknowledged whereupon it deletes the
connection. If an ACK is not forthcoming, after the user timeout
the connection is aborted and the user is told.
Donc le côté qui envoie le FIN devrait s'attendre à ce que l'autre côté
envoie encore des données avant d'envoyer son propre FIN.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4b90fa1c.4000...@plouf.fr.eu.org
