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। प्रत्येक बदल उलटवता येण्याजोगा आणि एकाच कामाच्या भारापुरता मर्यादित ठेवा। मोजमाप जे ठीक आहे असे म्हणते ते सोडा, लाइनशी आधीच जुळणारा डाउनलोड वेगही त्यात।

प्रोफाइल, अंतबिंदू आणि दिवसाच्या वेळेसह आधीचे आणि नंतरचे आकडे लिहा, कारण अंतबिंदूसोबत हलणारी अपलोड समस्या राउटिंगचा प्रश्न आहे, आणि उपकरणासोबत हलणारी स्थानिक आहे। तीच नोंद अस्पष्ट तक्रारीचे निर्णयात रूपांतर करते, आणि त्यासाठी त्याच आदेशाच्या दोन फेऱ्या लागतात।