1. casa
  2. Domanda e risposta
  3. Qual è il motivo e come evitare [FIN, ACK], [RST] e [RST, ACK]

Qual è il motivo e come evitare [FIN, ACK], [RST] e [RST, ACK]

2013-03-03 20 views
11

Qual è il motivo e come evitare lo [FIN, ACK], [RST] e [RST, ACK]?Qual è il motivo e come evitare [FIN, ACK], [RST] e [RST, ACK]

È dovuto a una mancata corrispondenza tra i parametri TCP degli SO? Cosa significa quando il server risponde [FIN, ACK] in una connessione TCP/IP?

10.118.113.237 è una scatola Solaris, mentre 10.118.110.63 è una scatola 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

fonte

2013-03-03 Sergio Pettena

risposta

35

Ecco una spiegazione approssimativa dei concetti.

[ACK] è la conferma che il pacchetto di dati inviato in precedenza è stato ricevuto.

[FIN] viene inviato da un host quando vuole terminare la connessione; il protocollo TCP richiede che entrambi gli endpoint inviino la richiesta di terminazione (ad esempio FIN).

Quindi, supponiamo

  • host A invia un pacchetto di dati al ospite B
  • e poi serie B vuole chiudere la connessione.
  • L'host B (in base alla tempistica) può rispondere con [FIN,ACK] indicando che ha ricevuto il pacchetto inviato e desidera chiudere la sessione.
  • Host A dovrebbe poi rispondere con un [FIN,ACK] che indica che ha ricevuto la richiesta di terminazione (la ACK parte) e che anche si chiuderà la connessione (la parte FIN).

Tuttavia, se host A vuole chiudere la sessione dopo l'invio del pacchetto, sarebbe solo inviare un [FIN] pacchetto (niente a riconoscere), ma ospite B avrebbe risposto con [FIN,ACK] (riconosce la richiesta e risponde con FIN).

Infine, alcuni stack TCP eseguono la terminazione half-duplex, ovvero possono inviare [RST] anziché il solito [FIN,ACK]. Ciò accade quando l'host chiude attivamente la sessione senza elaborare tutti i dati che gli sono stati inviati. Linux è un sistema operativo che fa proprio questo.

È possibile trovare una spiegazione più dettagliata e completa here.

fonte

2013-03-03 03:37:30 isedev

+5

L'invio di un RST non è una "terminazione half duplex", ma interrompe entrambi i lati della connessione. Il normale protocollo FIN/ACK è la terminazione half-duplex. – EJP

+0

Indipendentemente dai pacchetti [FIN, ACK] e [RST], la connessione tra entrambi gli HOST si trova nello stato ESTABLISHED. Potrebbe lo stack TCP inviare [RST] e [FIN, ACK] a causa di configurazioni di rete sbagliate (un lato full duplex 100Mbps, l'altro half duplex 10Mbps, configurazione firewall errata, parametri tcp OS errati, ecc.)? –

+3

@EJP Vedere la sezione 4.2.2.13 di RFC 1122: "Un host può implementare una sequenza di chiusura TCP" half duplex ", in modo che un'applicazione che ha chiamato CLOSE non possa continuare a leggere i dati dalla connessione.Se un tale host emette una chiamata CLOSE mentre i dati ricevuti sono ancora in sospeso in TCP, o se vengono ricevuti nuovi dati dopo che CLOSE viene chiamato, il suo TCP DOVREBBE inviare un RST per mostrare che i dati sono andati persi. "I pacchetti [FIN] vengono inviati da entrambi endpoint quando tutti i dati sono stati letti - questo è full duplex, non metà e completamente sincrono (nel senso che TUTTI i dati devono essere letti in anticipo). – isedev

Problemi correlati

 Problemi correlati