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

Question

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

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

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

Comments

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

— जोकेवेटी

Answer 1

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

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

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

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

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

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

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

लेकिन 1 पैकेट का क्या? यदि यह आता है, तो क्या मुझे यकीन है कि यह एक पूर्ण पैकेट है, न कि एक टुकड़ा?

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

Comments

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

— जस्टिन ᚅᚔᚈᚄᚒᚔ

Answer 2

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

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

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

Comments

क्या नेटवर्क कार्ड ड्राइवर को कर्नेल नहीं के पैकेट को फिर से समतल करने का ख्याल है?

— ब्लूहल्लु

@Hallucynogenyc: जब तक चीजें बदल नहीं जाती हैं, इंटरनेट प्रोटोकॉल 576 बाइट्स के पैकेटों को उनकी यात्रा के किसी भी बिंदु पर विभाजित करने की अनुमति देने के लिए डिज़ाइन किया गया है, लेकिन उन्हें फिर से जोड़ने के लिए कुछ भी नहीं है लेकिन अंतिम प्राप्तकर्ता की उम्मीद नहीं है। मुझे लगता है कि यह विचार है कि बड़े पैकेट का उपयोग ज्यादातर मामलों में ओवरहेड को कम करने का प्रयास था; एक बार अपनी यात्रा के दौरान किसी बिंदु पर एक पैकेट को विभाजित कर दिया गया था, ओवरहेड पहले से ही फिर से चालू हो गया है इससे पहले कि अंतिम प्राप्तकर्ता कुछ भी मदद करने के लिए उपयुक्त नहीं है, और फिर से विभाजित होने पर चोट लग सकती है।

— सुपरकैट

मेरा मानना ​​है कि जब कोई भी पैकेट जो ५ that६ बाइट्स से अधिक है, विभाजित किया जा सकता है, जो पैकेट उस आकार से नीचे हैं; एम्बेडेड सिस्टम जो विभाजित पैकेट के साथ सौदा नहीं कर सकते हैं, उन्हें इससे बड़ा कुछ भी पूछने से बचना चाहिए।

— सुपरकैट

@ mauro.stettler: मैंने "नंगे धातु" पर एक टीसीपी स्टैक लिखा है (कोड को कई नेटवर्क इंटरफ़ेस चिप से सीधे बात करने के लिए लिखा है)। हार्डवेयर के लिए जो लंबे पैकेट को विभाजित करने के लिए 576-बाइट की सीमा वाले लिंक से बात करता है, सरल है। पैकेट reassembling है बहुत विशेष रूप से एक उनमें से किसी को पूर्ण रूप से प्राप्त होता है से पहले कई अलग अलग पैकेट के टुकड़े प्राप्त हो सकता है और अधिक जटिल,।

— सुपरकैट

कुछ आशा है कि यह छोटे पेलोड (लगभग 10 या 20 बाइट्स ठीक होना चाहिए) के लिए विभाजित नहीं किया जाएगा , क्योंकि आईपीवी 4 पर आईपी पैकेट के लिए प्रत्येक हॉप के लिए "गारंटीकृत अधिकतम आकार" आवश्यक है : कम से कम 68 बाइट्स (सहित आईपी ​​हेडर, और निचले स्तर के हेडर की गिनती नहीं)। en.wikipedia.org/wiki/Maximum_transmission_unit में पहली तालिका देखें । HOSTS से आवश्यक न्यूनतम आकार के 576 बाइट्स से अलग (यानी, ट्रांसमिशन की उत्पत्ति या अंत, सभी मध्यस्थ हॉप नहीं)। और carefull: पेलोड अभी भी कम है (जैसा कि प्रत्येक परत के हेडर कुछ जगह लेते हैं)।

— ओलिवियर डुलैक

Answer 3

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

टीसीपी:

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

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

यूडीपी:

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

डेटा एक ही क्रम में जरूरी नहीं है, और जरूरी नहीं कि सभी पर प्राप्त हो, लेकिन संदेश उनकी संपूर्णता में संरक्षित हैं।

Answer 4

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

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

Answer 5

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

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

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

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

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

Comments

यह गलत है: यदि कोई 10 या 20 बाइट पेलोड के साथ एक पिकेट भेजता है, तो यह 1 पिकेट उत्पन्न करेगा, और जैसा कि मैंने ऊपर कहा है), अगर ipv4 का उपयोग करते हुए, यह अन्य प्रोटोकॉल परतों के सभी हेडर को जोड़ने पर भी फिट होना चाहिए, फिट 68 बाइट्स के भीतर, इस प्रकार यह सुनिश्चित करना कि यह 1 पैकेट में सभी हॉप्स से गुजरता है। Tcp स्टैक नहीं होगा (जैसा कि आपके पहले पैराग्राफ में संकेत दिया गया है) "जब तक mtu भर नहीं जाता है, तब तक प्रतीक्षा करें (यानी, एक पैकेट भेजने के लिए एक उचित आकार बनाने के लिए कई पैकेट जोड़ें)" ... यह व्यवहार स्पष्ट रूप से कई चीजों को तोड़ देगा! भले ही उन "टुकड़ों" को मेजबानों की एक ही जोड़ी से भेजा गया हो)

— ओलिवियर दुलैक

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

— jjmontes