यदि एक टीसीपी पैकेट आंशिक रूप से स्वीकार किया जाता है, तो रिट्रांसमिशन तंत्र कैसे प्रतिक्रिया करेगा?

Question

अगर एक tcp क्लाइंट 10000 से 20000 तक अनुक्रम संख्या के साथ, एक tcp सर्वर पर एक पैकेट भेजता है। tcp seq_ack 20001 के साथ ACK का जवाब देगा।

अगर मैं क्लाइंट से टीसीपी पैकेट को इंटरसेप्ट करता हूं, और पैकेट को 2 tcp सेगमेंट में विभाजित करता हूं, तो 10000 से 15000 तक seq के साथ, और दूसरा 15001 से 20000 तक seq के साथ। और फिर इन 2 TCP सेगमेंट को TCP सर्वर पर भेज दिया जाता है। मान लें कि मार्ग में दूसरा खंड खो गया है। टीसीपी सर्वर 15001 seq_ack के साथ एक ACK का जवाब देगा।

अब चूंकि टीसीपी ग्राहक 10000 से 20000 के साथ एक इंटीग्रल पैकेट भेजते हैं, लेकिन ग्राहक के दृष्टिकोण से, यह 15001 के साथ एक एसीके मिलता है, यह अजीब है। यह कैसे प्रतिक्रिया देगा? सिद्धांत रूप में, क्लाइंट को seq 15001 से 20000 तक बाइट्स को फिर से जमा करना चाहिए, अर्थात्, ग्राहक seq 15001 से नए पैकेट प्रसारित करेगा। लेकिन टीसीपी स्टैक कार्यान्वयन में अभ्यास के बारे में कैसे, यह सिद्धांत के समान है?

मुझे लगता है कि टीसीपी भेजने वाले बफर में, जब एक टीसीपी सेगमेंट भेजा जाता है, तब भी खंड एसीके तक रहता है। जब ACK आता है, तो खंड के लिए ये बाइट्स बफर से साफ हो जाते हैं। सेंड बफ़र में एक पॉइंटर होता है, जब एक ACK आता है, पॉइंटर उस स्थान की ओर इशारा करता है जहाँ ack_seq से संगत होता है। Ack_seq के नीचे आने वाले बाइट्स साफ़ हो जाते हैं। इस तरह से, पूरे खंड को फिर से पढ़ने की जरूरत नहीं है?

Answer 1

इसे चयनात्मक पावती कहा जाता है , और RFC 2018 में परिभाषित टीसीपी विनिर्देश में पहले से ही शामिल है । यह क्लाइंट को वास्तव में सिर्फ 15001 से 20000 तक बाइट्स की अनुमति देगा (क्योंकि वे अलग-अलग पैकेट / सेगमेंट में हैं यदि आपने उन्हें विभाजित किया है जैसा कि आप कहते हैं), लेकिन अधिक दिलचस्प बात यह है कि यह आउट-ऑफ-ऑर्डर पावती भी देता है।

RFC 2018 से:

जब एक ACK जिसमें SACK का विकल्प होता है, तो डेटा भेजने वाला SHOULD भविष्य के संदर्भ के लिए चयनात्मक पावती को रिकॉर्ड करता है। माना जाता है कि डेटा प्रेषक के पास एक ऐसी प्रतिवर्ती कतार होती है जिसमें खंड होते हैं जो अभी तक अनुक्रमित क्रम में प्रेषित नहीं होते हैं, लेकिन स्वीकार किए जाते हैं।

टीसीपी विनिर्देश द्वारा समर्थन SACKकी आवश्यकता नहीं है। यदि क्लाइंट या सर्वर ने चयनात्मक पावती का समर्थन नहीं किया है, तो वास्तव में 10000 से 20000 तक के सभी बाइट्स को फिर से जमा करना होगा।

टीसीपी स्टैक कार्यान्वयन में, क्या यह सिद्धांत के समान है?

आमतौर SACK पर समर्थित है, प्रदर्शन, दक्षता और विलंबता लाभ महत्वपूर्ण हैं - विशेष रूप से इंटरनेट जैसे नेटवर्क में।

हालांकि, ये धारणा सही होनी चाहिए, भले ही आप मैन्युअल रूप से पैकेट में हेरफेर करें जैसा आपने कहा था। आरएफसी 793 के अनुसार , कम से कम, संपूर्ण डेटा विंडो को फिर से जमा करना होगा, लेकिन आवर्ती को पता है कि प्राप्त डेटा कम से कम मान्य है । कार्यान्वयन के विवरण के लिए, धारा 3.3 - आरएफसी 793 से अनुक्रम संख्या ।

संपूर्ण प्रक्रिया की रूपरेखा के लिए और बिना चयनात्मक समर्थन दोनों के समर्थन के लिए, इस लेख को देखें (जिसमें कुछ बहुत उपयोगी चित्र शामिल हैं)।

Comments

यह मेरे लिए थोड़ा अजीब है, क्योंकि टीसीपी स्ट्रीम-आधारित, बाइट-ओरिएंटेड प्रोटोकॉल है। इसे पूरे सेगमेंट को फिर से क्यों लेना चाहिए? ऐसा लगता है कि SAKC के बिना TCP खंड-उन्मुख धारा प्रोटोकॉल है, लेकिन Sack के साथ TCP वास्तविक बाइट-उन्मुख है। मुझे लगता है कि RFC इस पर विशेष रूप से विस्तृत नहीं है।

— मिस्टी

टीसीपी स्टैक अपने भेजने वाले बफर का प्रबंधन कैसे करता है, क्या यह वही है जो मैंने अद्यतन प्रश्न में लिखा था।

— मिस्टी

@misteryes इस लेख की प्रक्रिया को रेखांकित करता है (कुछ महान चित्र के साथ, भी!)।

— ब्रेकथ्रू

आपके द्वारा सुझाए गए लिंक में, ऐसा लगता है कि लेखक अभी भी समस्या को एक खंड-उन्मुख तरीके से चर्चा करता है, वास्तविक बाइट-उन्मुख तरीके से नहीं। है ना?

— 19'13

इससे पहले कि मैं यह सवाल पोस्ट करता, मुझे पता था। बहुत शुरुआत में मुझे नहीं लगता कि SACK का इस सवाल से कोई लेना-देना है। मेरी राय में, यदि TCP बाइट-ओरिएंटेड नहीं है, लेकिन सेगमेंट-ओरिएंटेड है, तो SACK भी समान होना चाहिए। SACK- सक्षम और SACK- अक्षम के बीच अंतर यह है कि SACK के साथ, TCP ack_seq में एक अनुक्रम छेद की अनुमति देता है। लेकिन मुझे लगा कि सीक्वेंस होल एक सेगमेंट से मेल खाता है। जबकि आपके कहने के अनुसार, छेद एक खंड का आधा / हिस्सा हो सकता है।

— मिस्टी

Answer 2

खंड आकार एक कनेक्शन के जीवनकाल में बदल सकते हैं (और कर सकते हैं)। सौभाग्य से, टीसीपी को उस खंड आकार को रिकॉर्ड करने की कोई आवश्यकता नहीं है जो पहले के साथ व्यक्तिगत पैकेट भेजे गए थे। इसलिए, यह निम्न कार्य करेगा:

1. जब भी कोई ACK आता है, उसके अनुसार पहले अनजाने बाइट के लिए पॉइंटर को एडवांस करें और किसी भी अब-अनावश्यक बफर को त्याग दें।
2. जब रिट्रांसमिशन (फास्ट रिट्रांसमिट या टाइमआउट की आवश्यकता होती है, तो पहली एसीके की प्राप्ति के तुरंत बाद नहीं !), यह वर्तमान में मान्य खंड आकार में सूचक से पहली अनजाने बाइट तक शुरू होगा।

दोनों परिचालनों को स्वतंत्र रूप से खंड के आकार से किया जाता है ये बाइट मूल रूप से भेजे गए थे। इसलिए सिद्धांत को अधिकांश कार्यान्वयन से मेल खाना चाहिए।

मुझे समझाने के लिए कुछ पृष्ठभूमि दें:

क्या टीसीपी बाइट्स या सेगमेंट का उपयोग करता है? अनुप्रयोग के लिए, टीसीपी एक बाइट स्ट्रीम इंटरफ़ेस को उजागर करता है। इसके अलावा, सभी हेडर फ़ील्ड और आंतरिक चर बाइट्स में हैं। हालाँकि, सूचना प्रसारित करने के लिए, टीसीपी उन्हें खंडों में बदल देती है, क्योंकि बाइट्स एक-एक करके भेजने से बहुत बेकार हो जाएगा :-)। हर जगह बाइट काउंटरों का उपयोग करने से यह लाभ होता है कि कनेक्शन के जीवनकाल में खंड आकार स्थिर रहने की आवश्यकता नहीं होती है:

• विकल्प पेश किए जा रहे हैं, उदाहरण के लिए किसी रिट्रांसमीटर पर एक सैक को पिग्गीबैक करना (वास्तविक कार्यान्वयन शायद ही कभी इसका सामना करेंगे)
• पथ MTU बदलता है, उदाहरण के लिए पथ के साथ एक लिंक निम्न MTU में बदल जाता है या टोंटी MTU लिंक उठाया जाता है। यह तब होता है जब सुरंग स्थापित होती हैं (वीपीएन, पीपीपीओई) या राउटिंग प्रोटोकॉल एक अलग-एमटीयू लिंक का चयन करता है। यह IPv4 में नॉट फ्रैगमेंट सेट (अधिकांश आधुनिक टीसीपी के लिए सही) के साथ होता है; हमेशा TCPv6 में)।

BTW: SACK यहां जवाब नहीं है, क्योंकि रिसीवर (आमतौर पर) केवल SACK का उपयोग करेगा यदि यह बाइट स्ट्रीम में एक छेद को पहचानता है (यानी, अगर एक पैकेट खो गया लेकिन एक निम्नलिखित पैकेट आ गया)।