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। प्रत्येक परिवर्तन उल्टाउन सकिने र एउटै कामको भारमा सीमित राख्नुहोस्। मापनले ठीक छ भन्ने कुराहरू छोड्नुहोस्, लाइनसँग पहिले नै मेल खाने डाउनलोड गति पनि सहित।

प्रोफाइल, अन्तबिन्दु र दिनको समयसँगै पहिले र पछिका संख्याहरू लेख्नुहोस्, किनकि अन्तबिन्दुसँगै सर्ने अपलोड समस्या राउटिङको प्रश्न हो, र उपकरणसँगै सर्ने स्थानीय हो। त्यही अभिलेखले अस्पष्ट गुनासोलाई निर्णयमा बदल्छ, र यसको लागत एउटै आदेशका दुई रन हुन्।