टीसीपी द्वारा पावती की गारंटी नहीं है कि डेटा वितरित किया गया है

Question

RFC 793 में TCP सेगमेंट की पावती के बारे में एक हिस्सा है:

जब टीसीपी डेटा युक्त सेगमेंट को प्रसारित करता है, तो वह एक प्रतिलेखन कतार पर एक कॉपी डालता है और एक टाइमर शुरू करता है; जब उस डेटा की पावती प्राप्त हो जाती है, तो खंड को कतार से हटा दिया जाता है। यदि टाइमर समाप्त होने से पहले पावती प्राप्त नहीं हुई है, तो खंड को फिर से लिखा गया है।

टीसीपी द्वारा एक पावती यह गारंटी नहीं देती है कि डेटा अंतिम उपयोगकर्ता को दिया गया है , लेकिन केवल यह कि टीसीपी प्राप्त करने वाले ने ऐसा करने की जिम्मेदारी ली है।

अब, यह दिलचस्प है। हमारी एनओसी में, हम अक्सर अपने नेटवर्क और बाहरी क्लाइंट नेटवर्क के बीच कनेक्टिविटी के मुद्दों का निवारण करते हैं और जब भी हम किसी फ़ायरवॉल पर ट्रैफ़िक को सूँघते हैं और दोनों दिशाओं में भेजे गए और प्राप्त SYN और ACK बिट्स देखते हैं, तो हम मानते हैं कि कनेक्टिविटी स्थापित हो गई है और समस्या के पास कुछ भी नहीं है नेटवर्क के साथ करते हैं।

लेकिन अब इस RFC ने मुझे यह सोचने पर मजबूर कर दिया - टीसीपी कनेक्शन स्थापित होने पर मुझे (Wireshark की स्थापना के बिना) क्या जाँच करनी चाहिए लेकिन उपयोगकर्ता अभी भी कनेक्टिविटी समस्याओं का सामना कर रहे हैं?

Comments

इस वाक्य का क्या अर्थ है, यह वाक्य का शाब्दिक अंग्रेजी अर्थ है: यह तथ्य कि नेटवर्क ड्राइवर ने डेटा प्राप्त किया (और रिसेप्शन को स्वीकार किया) यह गारंटी नहीं देता है कि अंतिम उपयोगकर्ता डेटा प्राप्त करता है। उदाहरण के लिए, वेब सर्वर में एक बग हो सकता है। अपने समापन प्रश्न के संबंध में: यह पता लगाने का एकमात्र तरीका है कि क्या अंतिम उपयोगकर्ता को डेटा प्राप्त हुआ है, उन्हें कॉल करना और उनसे पूछना है।

— जोर्ग डब्ल्यू मित्तग

Answer 1

RFC का यह हिस्सा ऑपरेटिंग सिस्टम पर जिम्मेदारी से गुजरने के बारे में है या जो भी प्रक्रिया का अगला चरण है। यह मूल रूप से परतों के पृथक्करण से संबंधित है।

टीसीपी द्वारा एक पावती यह गारंटी नहीं देती है कि डेटा अंतिम उपयोगकर्ता को दिया गया है, लेकिन केवल यह कि टीसीपी प्राप्त करने वाले ने ऐसा करने की जिम्मेदारी ली है।

मैंने हमेशा इसके बारे में इस तरह से सोचा है:

• ACK को भेजने और क्लाइंट प्रक्रिया तक पहुंचने वाले डेटा के बीच OS क्रैश हो सकता है ("क्लाइंट" का अर्थ है OS का क्लाइंट, "क्लाइंट क्लाइंट" नहीं)
• क्लाइंट प्रक्रिया छोटी गाड़ी या दुर्घटनाग्रस्त हो सकती है, या इसके आने वाले डेटा से निपटने के लिए गोल होने की अपेक्षा प्रत्याशित से अधिक धीमी हो सकती है, या वास्तव में केवल इसे गैर-स्पष्ट परिस्थितियों में पढ़ सकती है
• यदि क्लाइंट डेटा को आगे भेज रहा है, तो शायद एक डिस्क फ़ाइल पर, फ़ाइल अभी तक लिखी या फ्लश नहीं की गई हो सकती है
• यदि क्लाइंट टीसीपी द्वारा डेटा को आगे भेज रहा है, तो दूर की ओर टीसीपी ने डेटा प्रेषित नहीं किया हो सकता है, एक एसीके प्राप्त किया है, या दूर की प्रक्रिया ने सफलतापूर्वक डेटा का उपभोग किया है

सभी यह कह रहे हैं कि यह एक लेयर 3 पावती है ("मैं आपकी बाइट्स सुनता हूं") एक उच्च लेयर पावती नहीं है। उदाहरण के लिए टीसीपी एसीके के बीच के अंतर पर विचार करें, 250 OKअगले-हॉप मेल गेटवे के बाद एसएमटीपी एक संदेश, एक संदेश रसीद संदेश (उदाहरण के लिए आरएफसी 3798 ), एक संदेश-खोलने वाला ट्रैकिंग पिक्सेल, एक पीए से धन्यवाद-नोट, स्वीकार करता है । और एक जवाब "हाँ मैं करूँगा।"

एक अन्य ठोस उदाहरण एक प्रिंटर होगा:

• इससे पहले कि वह जानता है कि उसके अंत में क्या है, उसे डेटा को तुरंत ACK करना चाहिए (एक पोस्टस्क्रिप्ट फ़ाइल हो सकती है, जिसमें शामिल की गई लाइब्रेरी से शुरू की गई TCP TCP विंडो से बड़ी है)
• इसमें एक स्थिति क्वेरी हो सकती है ("क्या आपके पास पेपर है?", जिसे वह स्पष्ट रूप से निष्पादित कर सकता है)
• इसमें एक प्रिंट कमांड हो सकता है ("कृपया इसे प्रिंट करें", जिसे यह विफल हो सकता है, यदि कागज से बाहर हो)

मेरा सुझाव है कि यदि उपयोगकर्ता ACKs देख रहे हैं और भेज रहे हैं, लेकिन अभी भी कनेक्टिविटी समस्याओं का सामना कर रहे हैं, तो यह परिमाण के आदेश हैं कि अधिक सख्ती से नेटवर्क से संबंधित किसी भी चीज की तुलना में भीड़, OS या अनुप्रयोग समस्याएँ हैं।

निदान के लिए मैं सुझाव देता हूं कि विशेष रूप से एसीके के बजाय, रिट्रांसमीट की तलाश करें।

Comments

एक अन्य बुलेट आइटम: भले ही क्लाइंट प्रक्रिया ठीक चल रही हो, हो सकता है कि यह अभी तक डेटा को न पढ़े।

— बरमार

क्लाइंट प्रक्रिया (यदि यह आलसी या विकृत लग रहा है) बस recv()सॉकेट पर कभी कॉल नहीं कर सकती है , तो उस स्थिति में प्राप्त डेटा टीसीपी सॉकेट के प्राप्त-बफर में अनिश्चित काल तक रहेगा।

— जेरेमी फ्रिज़र

दोनों का धन्यवाद, ग्राहक की प्रक्रिया धीमी, छोटी, चंचल हो सकती है, यह सुझाव देने के लिए इसे अपडेट किया गया।

— जोनाथनजो

आप यह सुनिश्चित करने के लिए ACK पर भरोसा नहीं कर सकते हैं कि आवेदन ने आपके इनपुट को संसाधित किया है, आपको एक आवेदन परत ACK या चेक लागू करना होगा। इसे दूसरे संदर्भ में रखा जाए। औद्योगिक नियंत्रण नेटवर्क के लिए क्लाइंट पक्ष पर एक आईपी स्टैक के साथ टीएसएन का उपयोग करते हुए, टीसीपी एसीके यह गारंटी देने के लिए पर्याप्त नहीं है कि प्रक्रिया चर को कुंडी लगाई गई थी। अर्थात, आप सिस्टम को सुरक्षित या सेवा-योग्य स्थिति में रखने के लिए TCP ACK पर भरोसा नहीं कर सकते हैं, आपके पास एक एप्लीकेशन लेयर सर्विस से पावती होनी चाहिए कि मशीन में अपना हाथ रखना सुरक्षित है।

— 19

Answer 2

RFC परिप्रेक्ष्य से, "अंतिम उपयोगकर्ता" अनुप्रयोग है। इस बात की कोई गारंटी नहीं है कि आवेदन को डेटा मिला है, बस टीसीपी प्रक्रिया ने इसे प्राप्त किया है।

आपके एनओसी के दृष्टिकोण से, नेटवर्क कार्य कर रहा है और डेटा अंतिम होस्ट तक पहुंच गया है। मुमकिन है, कि आप सभी की परवाह है।

Answer 3

आप इसे इस तरह देख सकते हैं।

आप M.Smith हैं और आप M.Toto को एक पत्र भेजना चाहते हैं (व्यक्ति आवेदन परत हैं)।

पत्र भेजने के लिए, आप अपने स्थानीय डाकघर ए पर जाते हैं, जो पत्र को एम.टोटो स्थानीय डाकघर बी (डाक घर टीसीपी परत हैं) को भेजेगा।

आपके बीच सब कुछ अच्छी तरह से चल सकता है, पोस्ट ऑफिस ए और पोस्ट ऑफिस बी - बी पोस्ट ऑफिस ए के लिए एक एसीके भेजेंगे। पोस्ट ऑफिस B और M.Toto के बीच कुछ भी हो सकता है।

यह मूल रूप से RFC का कहना है।