UDP में MTU 65535 कैसे है लेकिन ईथरनेट 1500 बाइट्स से अधिक फ्रेम आकार की अनुमति नहीं देता है

Question

मैं 100 एमबीपीएस के तेज ईथरनेट का उपयोग कर रहा हूं, जिसका फ्रेम आकार 1500 बाइट्स (मेरी पाठ्यपुस्तक के अनुसार पेलोड के लिए 1472 बाइट्स) से कम है। उस में, मैं संदेश आकार 65507 बाइट्स का एक यूडीपी पैकेट भेजने और प्राप्त करने में सक्षम था, जिसका अर्थ है कि पैकेट का आकार 65507 + 20 (आईपी हैडर) + 8 (यूडीपी हैडर) = 65535 था।

यदि फ़्रेम का पेलोड का आकार स्वयं अधिकतम 1472 बाइट्स (मेरी पाठ्यपुस्तक के अनुसार) है, तो आईपी का पैकेट आकार उस से अधिक कैसे हो सकता है जो यहां 65535 है?

मैंने प्रेषक कोड का उपयोग किया

char buffer[100000];
for (int i = 1; i < 100000; i++)
{
    int len = send (socket_id, buffer, i);
    printf("%d\n", len);
}

प्राप्तकर्ता कोड के रूप में

while (len = recv (socket_id, buffer, 100000))
{
     printf("%d\n". len);
}

मैंने देखा कि send returns -1पर i > 65507और recvप्रिंट करता है या एक पैकेट प्राप्त करता है maximum of length 65507।

Answer 1

यूडीपी डेटाग्राम का एमटीयू के आकार के साथ बहुत कम संबंध है, आप उन्हें उतना बड़ा बना सकते हैं जितना आप 64K तक ऊपर बताए गए हैं। आप उनमें से एक को पूरे पैकेट में भी भेज सकते हैं जब तक कि आप जंबो फ्रेम का उपयोग बड़े आकार के बड़े आरेख के साथ नहीं कर रहे हैं।

हालांकि जंबो फ्रेम को उन सभी उपकरणों द्वारा समर्थित किया जाना है, जो फ्रेम के ऊपर से गुजरेंगे और यह एक समस्या है। व्यावहारिक उद्देश्यों के लिए ईथरनेट फ्रेम सबसे आम ट्रांसपोर्ट आकार हैं, इन के लिए MTU 1500 बाइट्स हैं, मैं कहूंगा कि 1500 आगे जा रहे हैं, लेकिन यह हमेशा नहीं होता है। जब आप अंतर्निहित एमटीयू से बड़ा एक यूडीपी डेटाग्राम बनाते हैं (जो संकेत दिया जाता है कि अक्सर ईथरनेट होता है) तो यह चुपचाप 1500 बाइट फ्रेम में टूट जाएगा। यदि आप इस ट्रैफ़िक को tcpdump करते हैं, तो आपको MTU सीमा पर टूटे हुए कई पैकेट दिखाई देंगे, जिनमें एक फ़्रेग्मेंट नंबर के साथ अधिक फ़्रेग्मेंट फ़्लैग सेट होंगे। पहले पैकेट में एक खंड संख्या 0 और अधिक खंड सेट होंगे और अंतिम में एक गैर-शून्य टुकड़ा संख्या होगी और अधिक टुकड़े सेट नहीं होंगे।

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

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

Comments

Information अधिक टुकड़े के झंडे ’के बारे में अच्छी जानकारी। क्या वह UDP हेडर या IP हेडर में ध्वज है?

— जॉन यीशु

नोट: कुछ OS UDP संचारित नहीं करेंगे यदि डेटा खंडित किया जाएगा। IE लिनक्स डॉक,By default, Linux UDP does path MTU (Maximum Transmission Unit) discovery. This means the kernel will keep track of the MTU to a specific target IP address and return EMSGSIZE when a UDP packet write exceeds it.

— राहली

Answer 2

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

Answer 3

यह बताता है कि आवश्यकतानुसार टीसीपी / आईपी स्टैक को टुकड़े पैकेट की अनुमति देना व्यक्तिगत पैकेट भेजने की तुलना में बहुत कम ओवरहेड है।

Comments

क्या आपका मतलब यह है कि टीसीपी / आईपी अपने आप को खंडित और पुन: प्रस्तुत कर रहा है? यदि हाँ, तो लोग हर समय यह क्यों कहते हैं कि आपके कोड को रिसीवर के छोर पर फिर से ध्यान रखना चाहिए। मैंने अब तक विखंडन नहीं देखा था, लेकिन कई मंचों को देखा था जो यह कह रहे हैं और यहां तक ​​कि लोग इसे स्वीकार कर रहे हैं।

हममें से जो OSI मॉडल को चुनौती देते हैं, क्या आप कृपया अपने उत्तर में थोड़ा और विस्तार जोड़ सकते हैं?

— रॉबर्ट हार्वे

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

— गीकॉर्पोस

Answer 4

UDP MTU के बारे में कुछ भी नहीं जानता है। यूडीपी के पैकेटों का आकार 8 से 65535 बाइट्स तक हो सकता है। यूडीपी के नीचे प्रोटोकॉल परतें या तो एक विशिष्ट आकार का एक पैकेट भेज सकती हैं या फिर उस पैकेट को एक त्रुटि के साथ भेजने के लिए अस्वीकार कर देंगी यदि बहुत बड़ा है।

UDP के नीचे की परत आमतौर पर IP, IPv4 या IPv6 है। और IP पैकेट में 20 (IPv4) / 40 (IPv6) से लेकर 65535 बाइट्स तक कोई भी आकार हो सकता है, जो कि UDP के समान ही है। हालांकि, आईपी विखंडन नामक एक तंत्र का समर्थन करता है । यदि एक आईपी पैकेट आकार में बड़ा है, तो नीचे की परत परिवहन से क्या कर सकती है, आईपी एकल पैकेट को कई पैकेटों में विभाजित कर सकता है जिसे टुकड़े कहते हैं। हर टुकड़ा वास्तव में अपना खुद का एक आईपी पैकेट (अपना खुद का आईपी हेडर) होता है और इसे अपने गंतव्य पर भी भेजा जाता है; उसके बाद सभी टुकड़ों को इकट्ठा करने और अगली उच्च परत (जैसे यूडीपी) पर प्राप्त डेटा को पारित करने से पहले उनमें से पूरा पैकेट फिर से बनाने के लिए गंतव्य का कार्य है।

ईथरनेट प्रोटोकॉल केवल 46 और 1500 बाइट्स के बीच एक पेलोड के साथ फ्रेम को परिवहन कर सकता है (अपवाद हैं लेकिन यह इस उत्तर के दायरे से परे है)। यदि पेलोड डेटा 46 बाइट्स से कम है, तो इसे 46 बाइट्स के बराबर होना चाहिए। यदि पेलोड डेटा 1500 बाइट्स से परे है, तो इंटरफ़ेस इसे स्वीकार करने से इनकार कर देगा। यदि ऐसा होता है, तो यह IP लेयर पर निर्भर करता है कि वह या तो पैकेट को टुकड़ा करने का निर्णय ले, ताकि कोई भी टुकड़ा 1500 बाइट्स से बड़ा न हो या अगली उच्चतर परत के लिए कोई त्रुटि की रिपोर्ट करे यदि विखंडन को निष्क्रिय कर दिया गया है या इस विशेष कनेक्शन के लिए मना किया गया है।

आमतौर पर विखंडन से बचा जाना चाहिए, जैसा कि

• प्रेषक पक्ष पर संसाधनों को बर्बाद कर रहा है।
• यह रिसीवर की तरफ संसाधनों को बर्बाद करता है।
• यह पेलोड डेटा की समान मात्रा के लिए प्रोटोकॉल ओवरहेड को बढ़ाता है।
• यदि एक एकल टुकड़ा खो जाता है, तो पूरा पैकेट खो जाता है।
• यदि एक एकल टुकड़ा दूषित है, तो पूरा पैकेट दूषित है।
• रेज़ेंड के मामले में, सभी टुकड़ों में आक्रोश होना चाहिए।

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

यूडीपी के लिए, हालांकि, यह आवेदन का कार्य स्वयं होगा, क्योंकि यूडीपी एक "गूंगा" प्रोटोकॉल है, इसका अपना कोई प्रबंधन तर्क नहीं है, जो इसे बहुत लचीला, तेज और सरल बनाता है।

केवल यूडीपी आकार जिस पर आप भरोसा कर सकते हैं कि वह हमेशा ट्रांसपोर्टेबल है 576 माइनस 8 बाइट्स यूडीपी हैडर और माइनस 20 (वी 4) / 40 (वी 6) बाइट्स आईपी हेडर, क्योंकि आईपी मानक के लिए आईपी पैकेट प्राप्त करने में सक्षम होने के लिए हर आईपी होस्ट की आवश्यकता होती है 576 बाइट्स का कुल आकार। यदि यह कम से कम उस आकार के पैकेट को स्वीकार नहीं कर सकता है तो आपका प्रोटोकॉल कार्यान्वयन मानक अनुरूप नहीं होगा। ध्यान दें, हालांकि, मानक 576 को विखंडन के बिना नहीं कहता है, इसलिए यहां तक ​​कि 576 बाइट आईपी पैकेट दो मेजबानों के बीच खंडित हो सकता है।

केवल पैकेट आकार जिसे आप विखंडन के बिना परिवहनीय होने का भरोसा कर सकते हैं, IPv4 के लिए 24 बाइट्स और 56 बाइट्स IPv6 हैं, क्योंकि एक टुकड़े के लिए सबसे छोटा IP हेडर 20/48 बाइट्स (v4 / v6) हैं और एक टुकड़ा कम से कम 4/8 होना चाहिए बाइट्स (v4 / v6) पेलोड डेटा। इस प्रकार IP लेयर के नीचे एक ट्रांसपोर्ट सिस्टम जो कि थिसिस साइज के कम से कम पैकेट को ट्रांसपोर्ट नहीं कर सकता, आईपी ट्रैफिक को ट्रांसपोर्ट करने के लिए इस्तेमाल नहीं किया जा सकता है।

और इससे पहले कि कोई टिप्पणी करे कि IPv6 हेडर में केवल 40 बाइट्स हैं: यह सही है लेकिन, IPv4 हेडर के विपरीत, एक मानक IPv6 हेडर में विखंडन के लिए कोई हेडर फ़ील्ड नहीं है। यदि किसी पैकेट को खंडित किया जाना है, तो IPv6 बेस हेडर के नीचे एक विखंडन एक्सटेंशन हेडर जोड़ा जाना चाहिए और यह एक्सटेंशन हेडर 8 बाइट्स लंबा है। IPv4 के विपरीत, IPv6 में विखंडन ऑफसेट 8 बाइट्स में गिना जाता है, न कि 4 बाइट्स इकाइयों में, इस प्रकार एक टुकड़ा केवल एक पेलोड ले जा सकता है जो IPv6 के मामले में 8 बाइट्स का एक बहु है।

Answer 5

आपके प्रश्न का उत्तर देने के लिए, "यदि फ्रेम का पेलोड का आकार स्वयं अधिकतम 1472 बाइट्स (मेरी पाठ्यपुस्तक के अनुसार) है, तो आईपी का पैकेट आकार उस से अधिक कैसे हो सकता है जो यहां 65535 है?"

यह एक ऑफलोडिंग फीचर के कारण है जिसे UFO (UDP Fragmentation Offload) कहा जाता है। कृपया इस लिंक को देखें ।

आप क्रमशः ethtool -k ethX और ethtool -K ethX के माध्यम से ऑफलोडिंग सुविधाओं को सत्यापित और टॉगल कर सकते हैं।

Answer 6

यदि आप आउटगोइंग फ़्रेम की निगरानी कर रहे हैं, तो संभव है कि आपका नेटवर्क एडेप्टर सेगमेंट ऑफ़लोडिंग का समर्थन करता है, और यह सक्षम है। सेगमेंटेशन ऑफलोडिंग सक्षम होने के साथ, नेटवर्क कार्ड स्वयं पैकेट / फ्रेम को उचित आकार में विभाजित करता है, बजाय नेटवर्क स्टैक के। यह कंप्यूटर में सीपीयू को अन्य कार्यों को करने के लिए मुक्त करता है, प्रदर्शन में सुधार करता है। लाइनक्स पर, "एथ्टूल -के [डिवाइस]" ऑफलोड झंडे दिखाएगा।