क्या छोटा VPN MTU तेज़ है? वास्तविक साक्ष्य की तुलना करें
कम MTU पथ की सीमा से बच सकता है और फिर भी थ्रूपुट की कीमत चुका सकता है। बदलाव रखने से पहले वास्तविक बाधा, पैकेट ओवरहेड और कार्यभार की तुलना करें।
टनल बड़े स्थानांतरण गिरा देता है पर पिंग गुज़रने देता है, इसलिए सलाह जल्दी आती है: MTU घटाइए। सुधार कभी-कभी काम करता है, और फिर उसे हर नेटवर्क पर हर प्रोफ़ाइल पर लगाया जाता है। यहीं एक लक्षित मरम्मत स्थायी प्रदर्शन-कर बन जाती है। जो तुलना करनी है वह पथ की वास्तविक सीमा और उससे नीचे हर पैकेट को छोटा करने की लागत के बीच है।
MTU घटाने पर वास्तव में क्या सिकुड़ता है
हर पैकेट आपका डेटा ले जाने से पहले हेडर ले जाता है। 1500 बाइट के ईथरनेट पथ पर IPv4 और TCP 40 बाइट लेते हैं और पेलोड के लिए 1460 छोड़ते हैं; एनकैप्सुलेशन ऊपर बाहरी IP, UDP और टनल हेडर जोड़ता है, इसलिए भीतरी पेलोड बजट फिर गिरता है। इंटरफ़ेस का MTU घटाना उस बजट को जानबूझकर छोटा करता है।
लागत बाइटों की संख्या के नहीं, पैकेटों की संख्या के समानुपाती है। वही फ़ाइल अधिक पैकेटों में बँटी होने पर अधिक व्यवधान, अधिक रूटिंग निर्णय और पथ के हर डिवाइस पर अधिक प्रति-पैकेट प्रोसेसिंग माँगती है। जो राउटर पहले से प्रति-सेकंड पैकेट सीमा के करीब है, वहाँ यह गोलाई की त्रुटि नहीं, असली धीमापन है। स्थानांतरण ख़ुद सफल होने पर भी लागत दिखती है।
इसीलिए छोटा MTU किसी बाधा का बाईपास है, सामान्य अनुकूलन नहीं। यह उस पथ के मुक़ाबले विश्वसनीयता ख़रीदता है जो बड़ा फ़्रेम नहीं ले जा सकता, और जिन पैकेटों को घटाने की ज़रूरत नहीं थी उन सब पर ओवरहेड वसूलता है।
छोटा MTU कब सही सुधार है
क्लासिक लक्षण विशिष्ट है: TCP हैंडशेक पूरा होता है, छोटे उत्तर आते हैं, और बड़ा डाउनलोड अटक जाता है या रीसेट हो जाता है। 1472 बाइट पर न-विखंडित बिट वाला पिंग विफल होता है जबकि 1400 बाइट का पिंग सफल होता है, जो ऐसे पथ की ओर इशारा करता है जो पूर्ण-आकार का पैकेट नहीं ले जा सकता और वह ICMP संदेश नहीं पहुँचाता जो प्रेषक से छोटा करने को कहता।
पथ MTU की खोज उन्हीं ICMP विखंडन-आवश्यक संदेशों पर निर्भर है। जब फ़ायरवॉल उन्हें गिरा देता है, प्रेषक बड़ा पैकेट बार-बार दोहराता रहता है और कनेक्शन अटका दिखता है। टनल की ओर MTU घटाना दोहराव से बचाता है, और वह उस नेटवर्क के लिए वैध मरम्मत है।
पहुँच प्रौद्योगिकियाँ भी अपनी सीमाएँ लगाती हैं: PPPoE आम तौर पर 1492 पर सीमित होता है, कुछ मोबाइल और DSL पथ नीचे हैं, और नेस्टेड टनल ओवरहेड दो बार घटाते हैं। गाइड से संख्या नक़ल करने के बजाय वास्तविक पथ मापिए, और याद रखिए कि IPv6 उसे ले जाने वाले हर लिंक पर कम से कम 1280 बाइट MTU माँगता है, जैसा RFC 8200 निर्दिष्ट करता है।
एक बदलने से पहले तीन नियंत्रणों की तुलना करें
MTU, MSS और विखंडन अलग-अलग परतों के अलग-अलग नियंत्रण हैं, और ग़लत को बदलने से लक्षण अपनी जगह रह जाता है।
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
MSS सीमित करना अक्सर सबसे कम हस्तक्षेप वाली मरम्मत है क्योंकि यह केवल TCP को प्रभावित करती है और इंटरफ़ेस को दूसरे ट्रैफ़िक के लिए खुला छोड़ती है। कम इंटरफ़ेस MTU अधिक व्यापक और समझने में आसान है, इसीलिए यह उपभोक्ता राउटरों पर आम है, पर यह एक प्रोटोकॉल की समस्या का बिल हर प्रोटोकॉल से वसूलता है।
न-विखंडित व्यवहार बंद करना विखंडन की अनुमति देकर लक्षण छिपाता है, और यह आम तौर पर विलंब को और बिगाड़ता है जबकि उस प्रतिक्रिया को तोड़ता है जो सही आकार खोज लेती। इसे स्थायी समाधान के रूप में टालिए।
एक संख्या के बजाय समझौते को मापिए
न-विखंडित प्रोब से पथ की सीमा खोजिए, ऊँचाई से शुरू कीजिए और उत्तर आने तक नीचे उतरिए:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10फिर दोनों सेटिंग्स पर वास्तविक कार्य की तुलना करें: वही फ़ाइल स्थानांतरण, वही एंडपॉइंट और वही नेटवर्क। पूर्णता का समय और पुनःप्रेषण दर्ज करें, उदाहरण के लिए nstat -az TcpRetransSegs से, और यदि टनल छोटे राउटर पर समाप्त हो तो डिवाइस का CPU देखें। छोटा कृत्रिम थ्रूपुट परीक्षण उस अटकाव को चूक सकता है जो कुछ मेगाबाइट के बाद ही दिखता है।
घटाने के बाद पैकेट काउंटर बढ़ेंगे क्योंकि वही स्थानांतरण अब अधिक पैकेट लेता है। यह अपेक्षित है और उच्च थ्रूपुट का प्रमाण नहीं। पूर्ण हुए एप्लिकेशन डेटा, पुनःप्रेषण की संख्या और प्रतिक्रियाशीलता की तुलना करें, केवल पैकेट दर की नहीं।
बदलाव चरणों में लाइए और उसे सीमित रखिए
मूल मान दर्ज करें, एक नियंत्रण बदलें, और उसे स्थायी बनाने से पहले माप दोहराएँ। यदि साक्ष्य लाभ नहीं दिखाते, तो पिछला मान उसी इंटरफ़ेस कमांड से बहाल करें जो आपने उसे सेट करने के लिए इस्तेमाल की थी:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500परिणाम को उसी नेटवर्क तक सीमित रखिए जिसे उसकी ज़रूरत थी। जिस प्रोफ़ाइल को होटल के Wi-Fi, मोबाइल हॉटस्पॉट और दफ़्तर के LAN पर चलना है, उसे उनमें से किसी की भी माँगा गया सबसे कम मान विरासत में नहीं मिलना चाहिए, जब तक कि क्लाइंट पथ न पहचान सके।
सही मान वह सबसे बड़ा MTU है जो पथ पर टिकता है, वह सबसे छोटा नहीं जो लक्षण मिटा दे। पथ, प्रोब का परिणाम और वापसी दर्ज कीजिए, और पहुँच नेटवर्क बदलने पर सेटिंग फिर देखिए।