सवाल क्या टीसीपी और यूडीपी पैकेट टुकड़ों में विभाजित हो सकते हैं?


क्या टीसीपी पैकेट टुकड़े से रिसीवर तक पहुंच सकते हैं?

उदाहरण के लिए, यदि मैं टीसीपी प्रोटोकॉल का उपयोग करके 20 बाइट भेजता हूं, तो क्या मैं 100% सुनिश्चित कर सकता हूं कि मुझे एक बार में बिल्कुल 20 बाइट मिलेगा, 10 बाइट्स नहीं तो 10 अन्य बाइट्स या तो?

और यूडीपी प्रोटोकॉल के लिए एक ही सवाल है।
मुझे पता है कि यूडीपी अविश्वसनीय है और पैकेट बिल्कुल नहीं पहुंच सकते हैं या अलग-अलग क्रम में पहुंच सकते हैं, लेकिन एक पैकेट के बारे में क्या? अगर यह आता है, तो क्या मैं सुनिश्चित कर सकता हूं कि यह एक पूरा पैकेट है, न कि टुकड़ा?


37
2017-08-27 10:02


मूल


स्पष्टीकरण का एक बिंदु: इसे एक टीसीपी सेगमेंट और यूडीपी डेटाग्राम कहा जाता है। वे पैकेट नहीं हैं। टीसीपी = सेगमेंट, यूडीपी = डेटाग्राम, आईपी = पैकेट, ईथरनेट = फ़्रेम, अन्य सभी परतों (AFAIK) पर उन्हें केवल पीडीयू (प्रोटोकॉल डेटा इकाइयां) कहा जाता है। - joeqwerty


जवाब:


क्या टीसीपी पैकेट टुकड़े से रिसीवर तक पहुंच सकते हैं?

हाँ। आईपी ​​विखंडन का समर्थन करता है, हालांकि टीसीपी आम तौर पर पथ एमटीयू निर्धारित करने की कोशिश करता है और इसके कारणों को प्रदर्शन कारणों से छोटे रखता है। Fragmentation डेटाग्राम हानि दर विनाशकारी रूप से बढ़ जाती है। यदि किसी पथ में 10% पैकेट की हानि दर है, तो दो पैकेट में डेटाग्राम को खंडित करने से डेटाग्राम हानि दर लगभग 20% हो जाती है। (यदि पैकेट खो गया है, तो डेटाग्राम खो गया है।)

हालांकि आपको इसके बारे में चिंता करने की ज़रूरत नहीं है, और न ही टीसीपी परत करता है। आईपी ​​परत पूरे डेटाग्राम में पैकेट को फिर से इकट्ठा करता है।

उदा। यदि मैं टीसीपी प्रोटोकॉल का उपयोग करके 20 बाइट भेजता हूं, तो क्या मैं 100% सुनिश्चित कर सकता हूं कि मुझे एक बार में बिल्कुल 20 बाइट मिलेगा, 10 बाइट्स नहीं तो 10 अन्य बाइट्स या तो?

नहीं, लेकिन इसका पैकेट से कोई लेना देना नहीं है। टीसीपी मूल रूप से एक बाइट स्ट्रीम प्रोटोकॉल है जो एप्लिकेशन संदेश सीमाओं को सुरक्षित नहीं रखता है।

और यूडीपी प्रोटोकॉल के लिए एक ही सवाल है। मुझे पता है कि यूडीपी अविश्वसनीय है और पैकेट बिल्कुल नहीं पहुंच सकते हैं या विभिन्न क्रम में पहुंच सकते हैं,

टीसीपी के लिए भी यही सच है। पैकेट पैकेट हैं। अंतर यह है कि टीसीपी ने प्रोटोकॉल में रीट्री और रीडरिंग की है जबकि यूडीपी नहीं है।

लेकिन 1 पैकेट के बारे में क्या? अगर यह आता है, तो क्या मैं सुनिश्चित कर सकता हूं कि यह एक पूरा पैकेट है, न कि टुकड़ा?

नहीं, लेकिन यह आपकी समस्या नहीं है। यूडीपी प्रोटोकॉल डेटाग्राम reassembly संभालती है। यह अपने काम का हिस्सा है। (वास्तविकता में, आईपी प्रोटोकॉल यूडीपी प्रोटोकॉल के लिए करता है, इसलिए यूडीपी केवल आईपी के शीर्ष पर स्तरित होने से करता है।) यदि डेटाग्राम दो पैकेट पर विभाजित हो जाता है, तो आईपी प्रोटोकॉल यूडीपी प्रोटोकॉल के लिए इसे फिर से इकट्ठा करेगा, इसलिए आप पूरा डेटा देखेंगे।


29
2017-08-27 10:27



नौसिखिया पाठकों के लिए अंतिम बिट को स्पष्ट करने के लायक हो सकता है: आप पूरा डेटा देखेंगे  सवाल में डेटाग्राम के लिए। यदि स्प्लिट पैकेट में से कोई भी खो जाता है, तो डेटाग्राम खो जाता है और यूडीपी परत कभी इसके बारे में नहीं जान पाएगी। जब तक डेटाग्राम में सभी पैकेट प्राप्त होते हैं, तब तक उन्हें आईपी परत पर इकट्ठा किया जाएगा और फिर यूडीपी परत तक पहुंचाया जाएगा। यह डेटास्ट्रीम में "भाग" गायब होने की संभावना को रोकता नहीं है। पेडेंट नहीं बनना, लेकिन जब मैं इस सामान को सीख रहा था, तो मैंने पाठ्यपुस्तक के माध्यम से दूसरे या तीसरे पास तक आईपी फ्रैग और यूडीपी हानि के बीच अंतर को कम नहीं किया। - Justin ᚅᚔᚈᚄᚒᚔ


आप यह सुनिश्चित नहीं कर सकते कि वे वास्तव में शारीरिक रूप से एक बार आते हैं। टीसीपी / यूडीपी के नीचे डेटा लिंक परतें यदि आप चाहें तो अपने पैकेट को विभाजित कर सकती हैं। विशेष रूप से यदि आप अपने नियंत्रण के बाहर इंटरनेट या किसी भी नेटवर्क पर डेटा भेजते हैं तो इसकी भविष्यवाणी करना मुश्किल है।

लेकिन कोई फर्क नहीं पड़ता कि डेटा एक पैकेट या रिसीवर पर एकाधिक पैकेट में आता है। ओएस को इन पैकेटों के संयोजन को सारणीबद्ध करना चाहिए, इसलिए आपके आवेदन के लिए यह अभी भी सबकुछ एक साथ आने जैसा दिखता है। इसलिए, जब तक कि आप कर्नेल हैकर नहीं हैं, ज्यादातर मामलों में आपको चिंता करने की आवश्यकता नहीं है यदि यह डेटा एक या कई पैकेट में स्थानांतरित हो जाता है।

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


19
2017-08-27 10:04



क्या नेटवर्क कार्ड चालक कर्नेल को फिर से इकट्ठा करने वाले पैकेटों का ख्याल नहीं रखता है? - bluehallu
@Hallucynogenyc: जब तक चीजें बदलती नहीं हैं, इंटरनेट प्रोटोकॉल को 576 बाइट्स से अधिक पैकेट को अपनी यात्रा पर किसी भी समय विभाजित करने की अनुमति देने के लिए डिज़ाइन किया गया है, लेकिन अंतिम प्राप्तकर्ता को फिर से संयोजित करने के अलावा कुछ भी उम्मीद नहीं है। मुझे लगता है कि विचार यह है कि ज्यादातर पैकेटों का उपयोग ज्यादातर मामलों में ओवरहेड को कम करने का प्रयास था; एक बार पैकेट को अपनी यात्रा पर किसी बिंदु पर विभाजित कर दिया गया है, तो ओवरहेड पहले से ही खर्च कर चुका है ताकि अंतिम प्राप्तकर्ता किसी भी चीज की मदद करने के लिए उपयुक्त न हो, और अगर इसे फिर से विभाजित किया जाए तो उसे चोट पहुंच सकती है। - supercat
मेरा मानना ​​है कि 576 बाइट्स से अधिक होने वाले किसी भी पैकेट को विभाजित किया जा सकता है, उस आकार से नीचे वाले पैकेट नहीं हो सकते हैं; एम्बेडेड सिस्टम जो स्प्लिट पैकेट से निपट नहीं सकते हैं, उससे भी ज्यादा कुछ पूछने से बचना चाहिए। - supercat
@ mauro.stettler: मैंने "नंगे धातु" पर एक टीसीपी स्टैक लिखा है (कोड को कई नेटवर्क इंटरफ़ेस चिप पर सीधे बात करने के लिए लिखना)। हार्डवेयर के लिए जो लंबे पैकेट को विभाजित करने के लिए 576-बाइट सीमा वाले लिंक से बात करता है, सरल है। पैकेट रीसाइंबलिंग है बहुत अधिक जटिल, विशेष रूप से जब से उनमें से किसी को पूर्ण रूप से प्राप्त होने से पहले कई अलग-अलग पैकेट के टुकड़े मिल सकते हैं। - supercat
कुछ उम्मीद है कि इसे विभाजित नहीं किया जाएगा छोटे पेलोड (लगभग 10 या 20 बाइट ठीक होना चाहिए), क्योंकि प्रत्येक के लिए "गारंटीकृत अधिकतम आकार" आवश्यक है कूद ipv4 पर आईपी paquets के लिए: कम से कम 68 बाइट्स (आईपी शीर्षलेख सहित, और निचले स्तर के शीर्षकों की गणना नहीं)। में पहली तालिका देखें en.wikipedia.org/wiki/Maximum_transmission_unit। HOSTS से आवश्यक न्यूनतम आकार के 576 बाइट से अलग (यानी, संचरण की उत्पत्ति या अंत, सभी मध्यस्थ हॉप नहीं)। और सावधान: द पेलोड अभी भी कम है (क्योंकि प्रत्येक परत के शीर्षलेख कुछ जगह लेते हैं)। - Olivier Dulac


उदाहरण। संगत पात्रों के ब्लॉक भेजने के लिए मेल खाते हैं () कॉल:

टीसीपी:

Send: AA BBBB CCC DDDDDD E         Recv: A ABB B BCC CDDD DDDE

भेजे गए सभी आंकड़ों को क्रम में प्राप्त किया जाता है, लेकिन एक ही भाग में जरूरी नहीं है।

यूडीपी:

Send: AA BBBB CCC DDDDDD E         Recv: CCC AA E

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


14
2017-08-27 16:22





उदा। यदि मैं टीसीपी प्रोटोकॉल का उपयोग करके 20 बाइट भेजता हूं, तो क्या मैं 100% सुनिश्चित कर सकता हूं कि मैं   एक बार में बिल्कुल 20 बाइट प्राप्त होंगे, 10 बाइट्स नहीं तो 10 अन्य   बाइट्स या तो?

नहीं, टीसीपी एक स्ट्रीम प्रोटोकॉल है, यह डेटा को क्रम में रखता है लेकिन यह संदेश द्वारा इसे समूहित नहीं करता है। दूसरी तरफ यूडीपी संदेश उन्मुख है, लेकिन अविश्वसनीय है। SCTP दोनों दुनिया में सर्वश्रेष्ठ है लेकिन मूल रूप से प्रयोग योग्य नहीं है क्योंकि एनएटी इंटरनेट को तोड़ते हैं।


5
2017-08-27 10:19





कुछ आश्वासन है कि यदि आप एक टीसीपी धारा की शुरुआत में 20 बाइट भेजते हैं, तो यह दो 10 बाइट टुकड़ों के रूप में नहीं पहुंच जाएगा। ऐसा इसलिए है क्योंकि टीसीपी स्टैक ऐसे छोटे सेगमेंट नहीं भेजेगा: न्यूनतम एमटीयू आकार है। हालांकि, अगर प्रेषण धारा के बीच में कहीं भी है, तो सभी दांव बंद हैं। यह हो सकता है कि आपका प्रोटोकॉल स्टैक एक सेगमेंट भरने और इसे भेजने के लिए डेटा के 10 बाइट लेता है, और फिर अगले दस बाइट्स दूसरे सेगमेंट पर जाते हैं।

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

दूसरी तरफ, डेटा के विभाजन का मतलब है कि आंशिक पढ़ा जा सकता है। एक प्राप्त ऑपरेशन संभावित रूप से जाग सकता है और डेटा प्राप्त कर सकता है जब एक सेगमेंट के रूप में कम से कम आता है। व्यापक रूप से कार्यान्वित सॉकेट एपीआई में, एक प्राप्त कॉल 20 बाइट्स के लिए पूछ सकता है, लेकिन यह 10 के साथ वापस आ सकता है। बेशक, उस पर एक बफरिंग परत बनाया जा सकता है जो 20 बाइट प्राप्त होने तक अवरुद्ध हो जाएगा, या कनेक्शन ब्रेक हो जाएगा। POSIX दुनिया में, वह एपीआई मानक I / O धाराएं हो सकती है: आप कर सकते हैं fdopen एक प्राप्त करने के लिए एक सॉकेट वर्णनकर्ता FILE * धारा, और आप उपयोग कर सकते हैं fread इस पर एक बफर भरने के लिए कि पूर्ण अनुरोध कई से संतुष्ट है read कॉल के रूप में लेता है।

यूडीपी डेटाग्राम डेटा फ्रेम। प्रत्येक प्रेषण कॉल एक डेटाग्राम उत्पन्न करता है (लेकिन कॉर्किंग के बारे में नीचे देखें)। दूसरी तरफ एक पूर्ण डेटाग्राम प्राप्त होता है (और, सॉकेट एपीआई में, इसे पकड़ने के लिए पर्याप्त बफर निर्दिष्ट करना होगा, या अन्यथा डेटाग्राम छोटा कर दिया जाएगा)। बड़े डेटाग्राम आईपी विखंडन द्वारा खंडित हो जाते हैं, और अनुप्रयोगों के लिए पारदर्शी रूप से फिर से इकट्ठे होते हैं। यदि कोई टुकड़ा गुम है, तो संपूर्ण डेटाग्राम खो गया है; उस स्थिति में आंशिक डेटा पढ़ने का कोई तरीका नहीं है।

इंटरफ़ेस में एक्सटेंशन मौजूद हैं जो कई संचालन को एक डेटाग्राम निर्दिष्ट करने की इजाजत देता है। लिनक्स में, एक सॉकेट "कॉर्क किया जा सकता है" (भेजने से रोका जा सकता है)। जबकि यह कॉर्क किया गया है, लिखित डेटा एक इकाई में इकट्ठा किया जाता है। फिर जब सॉकेट "uncorked" है, एक एकल डेटाग्राम भेजा जा सकता है।


1
2017-08-27 16:56



यह झूठा है: यदि कोई 10 या 20 बाइट्स पेलोड के साथ एक पैकेट भेजता है, तो यह 1 पीक्वेट उत्पन्न करेगा, और (जैसा कि मैंने ऊपर कहा है), यदि आईपीवी 4 का उपयोग करते हैं, तो इसे अन्य प्रोटोकॉल परतों के सभी शीर्षकों को जोड़ने के दौरान भी फिट होना चाहिए 68 बाइट्स के भीतर, इस प्रकार यह सुनिश्चित करना कि यह 1 पैकेट में सभी होप्स के माध्यम से हो। टीसीपी स्टैक नहीं होगा (जैसा कि आपके पहले अनुच्छेद में संकेत दिया गया है) "एक पैकेट भेजने के लिए एमटीयू भरने तक प्रतीक्षा करें (यानी, एक उचित आकार के लिए कई पैकेट जोड़ें)! ... यह व्यवहार कई चीजों को तोड़ देगा ( भले ही उन "टुकड़े" को मेजबानों की एक ही जोड़ी से भेजा गया हो) - Olivier Dulac
@OlivierDulac: यह गलत है। टीसीपी आमतौर पर नेटवर्क उपयोग को अनुकूलित करने की कोशिश करते हुए पैकेट उत्पन्न करता है, इसलिए 20 बाइट्स दो अलग-अलग पैकेट में समाप्त हो सकते हैं जैसा कि कज़ द्वारा समझाया गया है। इसका उपयोग करके नियंत्रित किया जा सकता है TCP_NODELAY सॉकेट विकल्प, जो नागाल्स एल्गोरिदम को अक्षम करता है जो पैकेट को बाइट्स भेजता है, यदि आपके एप्लिकेशन को तेज़ टीसीपी नेटवर्किंग की आवश्यकता है। इसके अलावा, 68 बाइट्स पैकेट लंबाई के लिए डी-फैक्टो मानक नहीं है: 1500 बाइट्स एक सामान्य सामान्य मान है (यह वास्तव में नेटवर्क के बीच बदलता है)। - jjmontes