1. Zuhause
  2. Frage und Antwort
  3. Was ist der Grund und wie vermeidet man die [FIN, ACK], [RST] und [RST, ACK]

Was ist der Grund und wie vermeidet man die [FIN, ACK], [RST] und [RST, ACK]

2013-03-03 5 views
11

Was ist der Grund und wie man die [FIN, ACK], [RST] und [RST, ACK] vermeiden kann?Was ist der Grund und wie vermeidet man die [FIN, ACK], [RST] und [RST, ACK]

Liegt es an einem Ungleichgewicht zwischen den TCP-Parametern der SO's? Was bedeutet es, wenn der Server in einer TCP/IP-Verbindung auf [FIN, ACK] antwortet?

10.118.113.237 ist eine Solaris-Box, während 10.118.110.63 eine Linux-Box ist.

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

Quelle

2013-03-03 Sergio Pettena

Antwort

35

Hier ist eine grobe Erklärung der Konzepte.

[ACK] ist die Bestätigung, dass das zuvor gesendete Datenpaket empfangen wurde.

[FIN] wird von einem Host gesendet, wenn die Verbindung beendet werden soll; das TCP-Protokoll erfordert, dass beide Endpunkte die Beendigungsanfrage senden (d. h. FIN).

So nehme

  • Host A ein Datenpaket
  • -Host B sendet und dann Host B will die Verbindung schließen.
  • Host B (je nach Timing) kann mit [FIN,ACK] antworten, dass es das gesendete Paket empfangen hat und die Sitzung schließen möchte.
  • Host A sollte dann mit einem [FIN,ACK] reagieren darauf hinweist, dass es die Beendigungsanforderung empfangen wird (der ACK Teil), und dass es auch die Verbindung schließen (der FIN Teil).
    •

Wenn jedoch Host A will die Sitzung nach dem Senden des Pakets schließen, wäre es nur ein [FIN] Paket (nichts zu bestätigen) schicken, aber Host B mit [FIN,ACK] reagieren würde (bestätigt die Anforderung und antwortet mit FIN).

Schließlich führen einige TCP-Stacks eine Halbduplex-Terminierung durch, was bedeutet, dass sie [RST] anstelle des üblichen [FIN,ACK] senden können. Dies geschieht, wenn der Host die Sitzung aktiv beendet, ohne alle Daten zu verarbeiten, die an ihn gesendet wurden. Linux ist ein Betriebssystem, das genau das tut.

Sie können eine ausführlichere und umfassendere Erklärung finden here.

Quelle

2013-03-03 03:37:30 isedev

+5

Senden einer RST ist nicht "Halbduplex-Terminierung", es bricht beide Seiten der Verbindung ab. Das normale FIN/ACK-Protokoll ist eine Halbduplex-Terminierung. – EJP

+0

Unabhängig von den Paketen [FIN, ACK] und [RST] befindet sich die Verbindung zwischen den beiden HOST im Status ESTABLISHED. Könnte TCP Stack wegen falscher Netzwerkkonfigurationen (eine Seite Vollduplex 100Mbps, die andere Halbduplex 10Mbps, falsche Firewallkonfiguration, falsche OS tcp Parameter usw.) die [RST] und [FIN, ACK] senden? –

+3

@EJP Siehe Abschnitt 4.2.2.13 von RFC 1122: "Ein Host kann eine Halbduplex-TCP-Schließsequenz implementieren, so dass eine Anwendung, die CLOSE aufgerufen hat, nicht weiter Daten von der Verbindung lesen kann.Wenn ein solcher Host einen CLOSE-Aufruf absetzt, während die empfangenen Daten in TCP noch ausstehen, oder wenn neue Daten empfangen werden, nachdem CLOSE aufgerufen wurde, SOLLTE sein TCP eine RST senden, um zu zeigen, dass Daten verloren gegangen sind. "[FIN] -Pakete werden von beiden gesendet Endpunkte, wenn alle Daten gelesen wurden - dies ist Vollduplex, nicht die Hälfte und vollständig synchron (in dem Sinne, dass ALLE Daten vorher gelesen werden müssen). – isedev

Verwandte Themen

 Verwandte Themen