1. घर
  2. सवाल और जवाब
  3. [एफआईएन, एसीके], [आरएसटी] और [आरएसटी, एसीके]

[एफआईएन, एसीके], [आरएसटी] और [आरएसटी, एसीके]

2013-03-03 11 views
11

से बचने का कारण क्या है और [FIN, ACK], [RST] और [RST, ACK] से बचने का कारण क्या है?[एफआईएन, एसीके], [आरएसटी] और [आरएसटी, एसीके]

क्या यह एसओएस के टीसीपी पैरामीटर के बीच कुछ विसंगति के कारण है? इसका अर्थ यह है कि सर्वर टीसीपी/आईपी कनेक्शन में [FIN, ACK] का जवाब देता है?

10.118.113.237 एक सोलारिस बॉक्स है, जबकि 10.118.110.63 एक लिनक्स बॉक्स है।

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

स्रोत

2013-03-03 Sergio Pettena

उत्तर

35

यहाँ अवधारणाओं का एक मोटा व्याख्या है।

[ACK] यह स्वीकृति है कि पहले भेजा गया डेटा पैकेट प्राप्त हुआ था।

[FIN] एक होस्ट द्वारा भेजा जाता है जब वह कनेक्शन को समाप्त करना चाहता है; टीसीपी प्रोटोकॉल को एंडपॉइंट्स को समाप्ति अनुरोध भेजने की आवश्यकता होती है (यानी FIN)।

तो,

  • मेजबान एकमेजबान बी
  • करने के लिए एक डाटा पैकेट भेजता है और उसके बाद मेजबान बी कनेक्शन बंद करना चाहता है लगता है।
  • होस्ट बी (समय के आधार पर) [FIN,ACK] के साथ प्रतिक्रिया दे सकता है यह दर्शाता है कि इसे भेजा गया पैकेट प्राप्त हुआ और सत्र बंद करना चाहता है।
  • होस्ट एक तो एक [FIN,ACK] यह दर्शाता है कि यह समाप्ति अनुरोध (ACK हिस्सा) प्राप्त के साथ जवाब देना चाहिए और यह भी कनेक्शन (FIN हिस्सा) बंद हो जाएगा कि।

हालांकि, अगर मेजबान एक पैकेट भेजने के बाद सत्र को बंद करना चाहता है, यह केवल एक [FIN] पैकेट (स्वीकार करने के लिए कुछ भी नहीं है), लेकिन मेजबान बी[FIN,ACK] के साथ जवाब होगा (अनुरोध स्वीकार करता है और प्रतिक्रिया करता भेजना होगा FIN के साथ)।

अंत में, कुछ टीसीपी स्टैक अर्ध-डुप्लेक्स समाप्ति निष्पादित करते हैं, जिसका अर्थ है कि वे सामान्य [FIN,ACK] के बजाय [RST] भेज सकते हैं। ऐसा तब होता है जब होस्ट सक्रिय रूप से सत्र को बंद कर देता है, जो उस डेटा को संसाधित किए बिना संसाधित करता है। लिनक्स एक ऑपरेटिंग सिस्टम है जो यह करता है।

आप अधिक विस्तृत और व्यापक स्पष्टीकरण here पा सकते हैं।

स्रोत

2013-03-03 03:37:30 isedev

+5

एक आरएसटी भेजना 'आधा-डुप्लेक्स समाप्ति' नहीं है, यह कनेक्शन के दोनों तरफ निरस्त कर रहा है। सामान्य एफआईएन/एसीके प्रोटोकॉल अर्ध-डुप्लेक्स समाप्ति है। – EJP

+0

स्वतंत्र रूप से [एफआईएन, एसीके] पैकेज और [आरएसटी] पैकेज दोनों HOST के बीच कनेक्शन स्थापित स्थिति में है। क्या टीसीपी स्टैक [आरएसटी] और [एफआईएन, एसीके] गलत नेटवर्क कॉन्फ़िगरेशन (एक तरफ पूर्ण डुप्लेक्स 100 एमबीपीएस, अन्य आधा डुप्लेक्स 10 एमबीपीएस, गलत फ़ायरवॉल कॉन्फ़िगरेशन, गलत ओएस टीसीपी पैरामीटर इत्यादि) भेज सकता है? –

+3

@EJP आरएफसी 1122 के खंड 4.2.2.13 देखें: "एक होस्ट मई" आधे-डुप्लेक्स "टीसीपी क्लोज़ अनुक्रम को कार्यान्वित कर सकता है, ताकि एक एप्लिकेशन जिसे CLOSE कहा जाता है, कनेक्शन से डेटा को पढ़ना जारी नहीं रख सकता है।यदि ऐसा होस्ट एक बंद कॉल जारी करता है, जबकि प्राप्त डेटा अभी भी टीसीपी में लंबित है, या यदि बंद होने के बाद नया डेटा प्राप्त होता है, तो उसका टीसीपी एक आरएसटी भेज सकता है ताकि यह दिखाया जा सके कि डेटा खो गया था। "[FIN] पैकेट दोनों से भेजे जाते हैं अंतराल जब सभी डेटा पढ़ा गया है - यह पूर्ण-डुप्लेक्स है, आधा नहीं, और पूरी तरह सिंक्रोनस (इस अर्थ में कि सभी डेटा पहले से पढ़ा जाना चाहिए) – isedev

संबंधित मुद्दे

 संबंधित मुद्दे