VPN अपलोड डाउनलोड से धीमा? तय करें आप किस सीमा से टकराते हैं

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

प्रगति पट्टी से एक जैसी दिखने वाली तीन सीमाएँ

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

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

एक बार में एक दिशा मापें

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

iperf3 डिफ़ॉल्ट रूप से क्लाइंट से भेजता है, इसलिए सादा रन आपका अपलोड पथ मापता है; -R दिशा उलटता है और डाउनलोड मापता है। इन्हें कुछ मिनट के अंतर पर चलाएँ और औसत निकालने के बजाय दोनों संख्याएँ दर्ज करें:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

यदि अपलोड की संख्या डाउनलोड की संख्या का छोटा अंश है और रनों के बीच स्थिर रहती है, तो आकार असममित एक्सेस लाइन से मेल खाता है और टनल कहानी नहीं है। यदि अपलोड रनों के बीच बदलता है या दस सेकंड बाद ढह जाता है, तो आगे पढ़ें।

अपलोड कहाँ बदलता है, उससे तय करें

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

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

रोज़मर्रा के उपयोग के लिए, बैकग्राउंड अपलोड को सीमित करना या उसे मीटिंग के घंटों से बाहर शेड्यूल करना अक्सर किसी भी टनल सेटिंग से अधिक मदद करता है। उस बदलाव को संयुक्त कार्यभार से आँकें: जो बैकअप देर से खत्म होता है लेकिन अब कॉल नहीं बिगाड़ता, वह आमतौर पर बेहतर सौदा है।

जब अटकना धीमेपन को हराता है

ऐसा ट्रांसफर जो दोहराए जा सकने वाले बिंदु पर जम जाता है और फिर से शुरू होता है, दर सीमा की तरह नहीं बल्कि पथ MTU समस्या की तरह व्यवहार करता है। टनल प्रति पैकेट उपयोगी पेलोड घटाती है, और परिणामी ICMP संदेश गिरा देने वाला उपकरण प्रेषक को अनुमान लगाने पर छोड़ देता है। उस पैटर्न का अपना परीक्षण होना चाहिए, क्योंकि मरम्मत दर सेट करने से अलग है। स्थिर निम्न संख्या क्षमता की ओर इशारा करती है, जबकि विस्फोट के बाद सन्नाटा ऐसे पेलोड की ओर इशारा करता है जिसे पथ वहन नहीं कर सकता।

पथ को ऐसे पेलोड से जाँचें जिसका विखंडन न होना चाहिए, फिर टनल इंटरफ़ेस के MTU की तुलना उस मान से करें जो पार होता है:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

यदि बड़ी प्रोब गायब हो जाती है और छोटी सफल होती है, तो हर प्रोटोकॉल के लिए इंटरफ़ेस MTU घटाने के बजाय टनल पर TCP MSS कसें। उस बिंदु के बाद लगातार अटकना प्राप्त करने वाले एप्लिकेशन के स्टोरेज या गति से जुड़ा है, नेटवर्क पथ से नहीं।

क्या बदलें और क्या छोड़ें

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

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