Qu'est-ce que la raison et comment éviter le [FIN, ACK] , [RST] et [RST, ACK]
Qu'est-ce que la raison et comment éviter le [FIN, ACK]
, [RST]
et [RST, ACK]
?
Est-il dû à une certaine inadéquation entre les paramètres TCP de SOs? Ce qui signifie-t-il lorsque le serveur répond [FIN, ACK]
dans une connexion TCP/IP?
10.118.113.237
est un Solaris boîte, tandis que 10.118.110.63
est une machine sous Linux.
No. Time Source Destination Protocol Length Info
1 0.000000000 10.118.113.237 10.118.110.63 TCP 68 mmpft > 39679 [FIN, ACK] Seq=1 Ack=1 Win=49232 Len=0 TSval=62389927 TSecr=355193509
2 0.000015000 10.118.110.63 10.118.113.237 TCP 56 39679 > mmpft [RST] Seq=1 Win=0 Len=0
4 0.119357000 10.118.110.63 10.118.113.237 TCP 68 39707 > mmpft [ACK] Seq=1 Ack=93 Win=54 Len=0 TSval=355208473 TSecr=62389939
5 0.119475000 10.118.113.237 10.118.110.63 TCP 62 mmpft > 39707 [RST, ACK] Seq=93 Ack=1 Win=0 Len=0
6 0.321336000 10.118.110.63 10.118.113.237 TCP 76 55603 > mmpft [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=355208524 TSecr=0 WS=128
7 0.321835000 10.118.113.237 10.118.110.63 TCP 80 mmpft > 55603 [SYN, ACK] Seq=0 Ack=1 Win=49232 Len=0 TSval=62389959 TSecr=355208524 MSS=1460 WS=1 SACK_PERM=1
8 0.321854000 10.118.110.63 10.118.113.237 TCP 68 55603 > mmpft [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSval=355208524 TSecr=62389959
9 0.322552000 10.118.110.63 10.118.113.237 DIAMETER 276 cmd=Capabilities-ExchangeRequest(257) flags=R--- appl=Diameter Common Messages(0) h2h=3f3197c e2e=e9200846
10 0.322891000 10.118.113.237 10.118.110.63 TCP 68 mmpft > 55603 [ACK] Seq=1 Ack=209 Win=49024 Len=0 TSval=62389959 TSecr=355208524
11 0.342554000 10.118.113.237 10.118.110.63 TCP 68 mmpft > 39707 [FIN, ACK] Seq=93 Ack=1 Win=49232 Len=0 TSval=62389961 TSecr=355200968
12 0.342567000 10.118.110.63 10.118.113.237 TCP 56 39707 > mmpft [RST] Seq=1 Win=0 Len=0
13 0.346940000 10.118.113.237 10.118.110.63 DIAMETER 312 cmd=Capabilities-ExchangeAnswer(257) flags=---- appl=Diameter Common Messages(0) h2h=3f3197c e2e=e9200846
14 0.347021000 10.118.110.63 10.118.113.237 TCP 68 55603 > mmpft [ACK] Seq=209 Ack=245 Win=6912 Len=0 TSval=355208530 TSecr=62389961
15 4.288733000 10.118.113.237 10.118.110.63 TCP 68 mmpft > 39652 [FIN, ACK] Seq=1 Ack=1 Win=49232 Len=0 TSval=62390356 TSecr=355186382
16 4.288757000 10.118.110.63 10.118.113.237 TCP 56 39652 > mmpft [RST] Seq=1 Win=0 Len=0
17 4.398722000 10.118.113.237 10.118.110.63 DIAMETER 160 [TCP Retransmission] cmd=Device-WatchdogRequest(280) flags=R--- appl=Diameter Common Messages(0) h2h=f889ad2 e2e=5f8035e4
18 4.398734000 10.118.110.63 10.118.113.237 TCP 56 39707 > mmpft [RST] Seq=1 Win=0 Len=0
19 4.938748000 10.118.113.237 10.118.110.63 DIAMETER 160 cmd=Device-WatchdogRequest(280) flags=R--- appl=Diameter Common Messages(0) h2h=f889ad0 e2e=5f8035df
20 4.938770000 10.118.110.63 10.118.113.237 TCP 56 39598 > mmpft [RST] Seq=1 Win=0 Len=0
21 5.498759000 10.118.113.237 10.118.110.63 TCP 68 mmpft > 39544 [FIN, ACK] Seq=1 Ack=1 Win=49232 Len=0 TSval=62390477 TSecr=355156526
22 5.498783000 10.118.110.63 10.118.113.237 TCP 56 39544 > mmpft [RST] Seq=1 Win=0 Len=0
23 5.648780000 10.118.113.237 10.118.110.63 TCP 68 mmpft > 55774 [FIN, ACK] Seq=1 Ack=1 Win=49232 Len=0 TSval=62390492 TSecr=355111580
24 5.648804000 10.118.110.63 10.118.113.237 TCP 56 55774 > mmpft [RST] Seq=1 Win=0 Len=0
25 5.942885000 10.118.113.237 10.118.110.63 TCP 68 mmpft > 55828 [FIN, ACK] Seq=1 Ack=1 Win=49232 Len=0 TSval=62390521 TSecr=355126129
26 5.942901000 10.118.110.63 10.118.113.237 TCP 56 55828 > mmpft [RST] Seq=1 Win=0 Len=0
27 6.668742000 10.118.113.237 10.118.110.63 TCP 68 mmpft > 55666 [FIN, ACK] Seq=1 Ack=1 Win=49232 Len=0 TSval=62390594 TSecr=355081310
28 6.668760000 10.118.110.63 10.118.113.237 TCP 56 55666 > mmpft [RST] Seq=1 Win=0 Len=0
29 7.258815000 10.118.113.237 10.118.110.63 TCP 68 mmpft > 55720 [FIN, ACK] Seq=1 Ack=1 Win=49232 Len=0 TSval=62390653 TSecr=355096418
31 7.418827000 10.118.113.237 10.118.110.63 DIAMETER 160 cmd=Device-WatchdogRequest(280) flags=R--- appl=Diameter Common Messages(0) h2h=f889acd e2e=5f8035d9
32 7.418835000 10.118.110.63 10.118.113.237 TCP 56 39490 > mmpft [RST] Seq=1 Win=0 Len=0
33 12.948752000 10.118.113.237 10.118.110.63 DIAMETER 160 [TCP Retransmission] cmd=Device-WatchdogRequest(280) flags=R--- appl=Diameter Common Messages(0) h2h=f889ad2 e2e=5f8035e4
34 12.948776000 10.118.110.63 10.118.113.237 TCP 56 39707 > mmpft [RST] Seq=1 Win=0 Len=0
35 30.030087000 10.118.113.237 10.118.110.63 DIAMETER 160 [TCP Retransmission] cmd=Device-WatchdogRequest(280) flags=R--- appl=Diameter Common Messages(0) h2h=f889ad2 e2e=5f8035e4
36 30.030113000 10.118.110.63 10.118.113.237 TCP 56 39707 > mmpft [RST] Seq=1 Win=0 Len=0
38 30.369302000 10.118.110.63 10.118.113.237 TCP 68 55603 > mmpft [ACK] Seq=209 Ack=337 Win=6912 Len=0 TSval=355216035 TSecr=62392964
39 30.369413000 10.118.113.237 10.118.110.63 TCP 62 mmpft > 55603 [RST, ACK] Seq=337 Ack=209 Win=0 Len=0
40 30.571231000 10.118.110.63 10.118.113.237 TCP 76 55630 > mmpft [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=355216086 TSecr=0 WS=128
41 30.571603000 10.118.113.237 10.118.110.63 TCP 80 mmpft > 55630 [SYN, ACK] Seq=0 Ack=1 Win=49232 Len=0 TSval=62392984 TSecr=355216086 MSS=1460 WS=1 SACK_PERM=1
42 30.571620000 10.118.110.63 10.118.113.237 TCP 68 55630 > mmpft [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSval=355216086 TSecr=62392984
43 30.572253000 10.118.110.63 10.118.113.237 DIAMETER 276 cmd=Capabilities-ExchangeRequest(257) flags=R--- appl=Diameter Common Messages(0) h2h=3f3197d e2e=e9200847
44 30.572638000 10.118.113.237 10.118.110.63 TCP 68 mmpft > 55630 [ACK] Seq=1 Ack=209 Win=49232 Len=0 TSval=62392984 TSecr=355216086
45 30.579815000 10.118.113.237 10.118.110.63 TCP 68 mmpft > 55603 [FIN, ACK] Seq=337 Ack=209 Win=49232 Len=0 TSval=62392985 TSecr=355208530
46 30.579826000 10.118.110.63 10.118.113.237 TCP 56 55603 > mmpft [RST] Seq=209 Win=0 Len=0
47 30.581517000 10.118.113.237 10.118.110.63 DIAMETER 312 cmd=Capabilities-ExchangeAnswer(257) flags=---- appl=Diameter Common Messages(0) h2h=3f3197d e2e=e9200847
48 30.581553000 10.118.110.63 10.118.113.237 TCP 68 55630 > mmpft [ACK] Seq=209 Ack=245 Win=6912 Len=0 TSval=355216088 TSecr=62392985
49 34.138766000 10.118.113.237 10.118.110.63 TCP 68 mmpft > 39679 [FIN, ACK] Seq=1 Ack=1 Win=49232 Len=0 TSval=62393341 TSecr=355193509
50 34.138790000 10.118.110.63 10.118.113.237 TCP 56 39679 > mmpft [RST] Seq=1 Win=0 Len=0
OriginalL'auteur Sergio Pettena | 2013-03-03
Vous devez vous connecter pour publier un commentaire.
Ici est une ébauche d'explication des concepts.
[ACK]
est la reconnaissance que l'envoyé précédemment paquet de données a été reçu.[FIN]
est envoyé par un hôte quand il veut mettre fin à la connexion, le protocole TCP nécessite à la fois des points de terminaison pour envoyer la demande de résiliation (c'est à direFIN
).Donc, supposons que
[FIN,ACK]
indiquant qu'il a reçu le paquet envoyé et veut fermer la session.[FIN,ACK]
indiquant qu'il a reçu la demande de résiliation (laACK
partie) et qu'il va fermer la connexion (leFIN
partie).Toutefois, si l'hôte d'Un veut fermer la session après l'envoi du paquet, il ne serait d'envoyer un
[FIN]
paquet (rien à reconnaître), mais hôte B permettrait de répondre avec[FIN,ACK]
(accusé de réception de la demande et répond avecFIN
).Enfin, certaines piles TCP effectuer half-duplex de résiliation, ce qui signifie qu'ils peuvent envoyer
[RST]
au lieu de l'habituel[FIN,ACK]
. Cela se produit lorsque l'hôte activement ferme la session sans traitement de toutes les données qui ont été envoyées. Linux est un système d'exploitation qui fait juste cela.Vous pouvez trouver un plus détaillée et plus complète explication ici.
Indépendamment de la [FIN, ACK] paquets et [RST] les paquets de la connexion entre l'HÔTE est dans le statut ÉTABLI. Pourrait Pile TCP envoyer le [RST] et [FIN, ACK] en raison de mauvaises configurations de réseau (un côté full duplex 100 mbps, l'autre moitié en duplex de 10 mbits / s, mauvaise configuration du pare-feu, mauvais OS paramètres tcp, etc) ?
Voir la section 4.2.2.13 de la RFC 1122: "UN hôte PEUT mettre en œuvre un "half-duplex" TCP près de la séquence, de sorte qu'une application qui a appelé à PROXIMITÉ ne peut pas continuer à lire les données de la connexion. Si un hôte envoie un appel à PROXIMITÉ, tandis que les données reçues sont toujours en attente de TCP, ou si de nouvelles données sont reçues après la clôture est appelée, ses TCP DOIT envoyer une première à montrer que les données ont été perdues." [FIN] les paquets sont envoyés à partir de deux points de terminaison lorsque toutes les données ont été lire - et c'est full-duplex, pas à moitié, et entièrement synchrone (dans le sens que TOUTES les données doivent être lues à l'avance).
duplex et/ou la vitesse de la liaison incompatibilité entraîne normalement une quantité importante de tombée et de le retransmettre les paquets (ce qui pourrait entraîner une augmentation de la [RST] comte). Mais [RST] lui-même n'est pas une indication sûre de cette mauvaise configuration, vous devriez vérifier la pile TCP statistiques (par exemple, la commande netstat -s sur Unix/Linux) à la place. Il est possible que certains pare-feu pourrait envoyer la TVD sur connexion délais d'inactivité. Toutefois, il semble à partir de votre trace que la plupart des [RST] en réponse à la [FIN,ACK], de sorte qu'il est plus probable que le half-duplex séquence de fin.
OriginalL'auteur isedev