एकाच बोगद्यावर दोन VPN वेग चाचण्या वेगळ्या का पडतात
नवीन एक्झिट चाचणी सर्व्हर बदलते आणि संथ सुरुवात निकाल बदलते. गंतव्य निश्चित करा, स्ट्रीमची संख्या जुळवा आणि प्रोसेसरचा खर्च लिंकच्या क्षमतेपासून वेगळा करा.
दोन फेऱ्या, एक बोगदा, आणि संख्या तीन पटीने वेगळ्या आहेत. त्यांच्यामध्ये बोगदा बदलला नाही. जे बदलले ते मोजमाप आहे: तुमच्या दिसणाऱ्या स्थानावरून सर्व्हर निवडणारी चाचणी साइट, नळी एक संथ सुरुवात भरते की सहा, हे ठरवणारी स्ट्रीमची संख्या आणि मार्ग योग्यरीत्या वापरला जाण्यापूर्वीच संपणारा इतका छोटा कालावधी. वेग चाचण्या चुकीच्या नाहीत, पण त्या लोक त्यांना विचारतात त्या प्रश्नापेक्षा अरुंद प्रश्नाचे उत्तर देतात।
नवीन एक्झिट पत्ता चाचणीचे गंतव्य बदलतो
बहुतेक चाचणी साइट स्वयंचलितपणे मोजमाप सर्व्हर निवडतात, आणि तुमचे कनेक्शन कुठून येत असल्याचे दिसते याकडे पाहून अंशतः निवडतात. बोगदा सुरू करा आणि तुमचा दिसणारा देश बदलतो, त्यामुळे निवडलेला सर्व्हर बदलतो, आणि तुलना आता दोन वेगळ्या होस्ट्सकडे जाणाऱ्या दोन वेगळ्या मार्गांना व्यापते.
निकाल कोणत्याही प्रकारे VPN चे मोजमाप नाही. तो तुम्ही न निवडलेल्या सर्व्हरकडे जाणाऱ्या तुमच्या मार्गाचे मोजमाप आहे, आणि दोन फेऱ्यांमधील फरक बोगद्याने केलेल्या कोणत्याही गोष्टीपेक्षा त्या सर्व्हरच्या पीअरिंगमुळे ठरू शकतो.
दुसरे काहीही बदलण्यापूर्वी गंतव्य निश्चित करा. प्रत्येक विश्वासार्ह साधन तुम्हाला स्पष्टपणे सर्व्हर निवडू देत नाही, आणि जेव्हा देत नाही तेव्हा निकाल पृष्ठ सहसा वापरलेल्या सर्व्हरचे नाव सांगते, जे दोन्ही फेऱ्या तुलनीय नाहीत हे लक्षात घेण्यासाठी पुरेसे आहे. साइटने काय पाहिले हे तिच्या निवडीवर विश्वास ठेवण्यापूर्वी तपासा:
curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'जर फेऱ्यांमध्ये देश बदलला असेल, तर चाचणीने त्यानंतर निवडलेले सर्वही बदलले. प्रत्येक निकालाच्या पुढे दिसलेला एक्झिट लिहा आणि गोंधळ बहुतांश मिटतो.
संथ सुरुवात बहुतेक छोट्या चाचण्या संपल्यानंतर संपते
TCP कनेक्शन लिंकच्या वेगाने सुरू होत नाही. ते लहान कोंडीच्या खिडकीने सुरू होते, जवळपास प्रत्येक राऊंड ट्रिपला ती दुप्पट करते, आणि अनेक राऊंड ट्रिपनंतरच मार्गाच्या क्षमतेपर्यंत पोहोचते. जास्त लेटन्सी असलेल्या मार्गावर दहा सेकंदांची चाचणी तिच्या आयुष्याचा बराचसा भाग त्या चढाईत घालवू शकते.
म्हणूनच जास्त लेटन्सी असलेला बोगदा छोट्या चाचणीत पात्रतेपेक्षा वाईट गुण मिळवतो, आणि म्हणूनच लांब फेरी कोणतेही संरचना बदल न करता जास्त संख्या नोंदवते. RFC 6349 थ्रूपुट चौकट हे स्पष्टपणे हाताळते, आणि म्हणूनच गंभीर मोजमापे स्थिर अवस्थेपर्यंत पोहोचण्यासाठी पुरेसा वेळ चालतात. उपग्रह मार्गावर पाच सेकंदांची फेरी मार्ग नव्हे, त्वरणक मोजते.
एका संख्येवर विश्वास ठेवण्याऐवजी कनेक्शनचे टप्पे पाहा. Curl प्रत्येक टप्पा स्वतंत्रपणे नोंदवते, त्यामुळे वेळ हातमिळवणीत जातो का, चढाईत की हस्तांतरणात हे दिसते:
curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
https://mirror.example.net/testfile.binतेच गंतव्य गाठण्यासाठी सलग दोन वेळा चालवा. जर दुसरी फेरी खूप वेगवान असेल, तर तुम्ही मार्ग नव्हे, चढाई मोजत होता, आणि फक्त पहिली फेरी वापरणारी कोणतीही तुलना संशयास्पद आहे.
एक स्ट्रीम आणि सहा स्ट्रीम वेगवेगळ्या गोष्टी मोजतात
एक TCP स्ट्रीम ती हवेत ठेवू शकणाऱ्या खिडकीने मर्यादित असते, जी अंदाजे राऊंड ट्रिप वेळ गुणिले वेग इतकी असते. लांब मार्गावर ते गुणाकार एक स्ट्रीम वापरेल त्यापेक्षा जास्त असते, त्यामुळे एक डाउनलोड असलेल्या क्षमतेपेक्षा कमी दाखवतो. सहा समांतर स्ट्रीम ही तफावत भरतात आणि मोठी संख्या देतात.
iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.netदोन्ही संख्या खऱ्या आहेत. एका स्ट्रीमची संख्या एक डाउनलोड काय करेल हे सांगते, जे सहसा ब्राउझर टॅबला मिळते. समांतर संख्या मार्ग एकूण काय वाहू शकतो हे सांगते, जे टोरेंट किंवा बहुभाग डाउनलोड वापरू शकतो. एकाला दुसऱ्यासारखे उद्धृत करणे हाच निरोगी बोगदा विनाकारण बदलण्याचा मार्ग आहे.
समांतर निकालाची एका स्ट्रीमच्या निकालाशी तुलना करणे हा लोक VPN ने त्यांचा वेग अर्धा केला असा निष्कर्ष काढण्याचा सर्वात सामान्य मार्ग आहे. पद्धत जुळवा, मग तुलना करा. तिसऱ्या आदेशातील खूण गहाळ संदर्भ जोडते: जास्त जिटर असलेला मार्ग दोन्ही पद्धतींमध्ये असंगत निकाल देईल, आणि कोणतीही स्ट्रीम संख्या ते सुधारत नाही.
एन्क्रिप्शन प्रोसेसरचा वेळ घेते, एन्कॅप्स्युलेशन बाइट घेते
लिंक कितीही वेगवान असो, प्रत्येक पॅकेटवर दोन यंत्रणा चालतात. एन्क्रिप्शन प्रति बाइट प्रोसेसर वापरते, आणि एन्कॅप्स्युलेशन हेडर बाइट जोडते जे लिंकला तरीही वाहावे लागतात. दोन्ही मर्यादा म्हणून दिसतात, आणि त्यांची लक्षणे वेगळी आहेत.
प्रोसेसरची मर्यादा पठारासारखी दिसते: तुम्ही कितीही स्ट्रीम जोडा, थ्रूपुट वाढणे थांबते, आणि लिंक मोकळी असताना मशीनचा प्रोसेसर व्यस्त असतो. लहान राउटर किंवा फोनवर हीच बहुतेक खरी मर्यादा असते, आणि म्हणूनच वेगवान लाइनही साधारण बोगदा देऊ शकते.
बाइटचा खर्च कमी पण स्थिर असतो. जादा हेडर म्हणजे प्रति पॅकेट कमी पेलोड, आणि ठराविक कमाल प्रसारण एकक असलेल्या मार्गावर ते मोठ्या हस्तांतरणांमध्ये संथ सरासरीऐवजी थांबा म्हणून दिसणारे तुकडे होणे किंवा काळी भोक निर्माण करू शकतात.
| Observation | Likely mechanism | What to measure |
|---|---|---|
| Throughput flat as streams increase | CPU per packet on one core | Per-core utilisation during the test |
| Fast small transfers, stalled large ones | MTU and fragmentation | Payload size at which it breaks |
| Good average, unusable calls | Queueing delay behind a full buffer | Latency under load |
हे तीन बहुतेक गोंधळले जातात, कारण वापरकर्ते सर्वांना «VPN संथ आहे» असे म्हणतात. फक्त पहिले मोठ्या मशीनला प्रतिसाद देते, फक्त दुसरे लहान MTU ला, आणि फक्त तिसरे रांगा व्यवस्थापनाला.
पद्धत नोंदीत लिहा
ठेवण्यासारखा निकाल उपकरण, प्रवेश नेटवर्क, एक्झिट, मोजमाप सर्व्हर, दिशा, स्ट्रीम संख्या आणि कालावधी यांची नावे घेतो. त्यांशिवाय दोन संख्यांची तुलना होऊ शकत नाही, आणि एक संख्या असलेले तिकीट प्रत्यक्षात एक मनःस्थिती आहे.
वाईट फेऱ्याही ठेवा. ज्या मालिकेत एक एक्झिट प्रत्येक वेळी थांबा निर्माण करतो ती सरासरीपेक्षा खूप जास्त माहितीपूर्ण असते, आणि थांबे हेच सरासरी लपवतात.
मग तुम्हाला खरोखर महत्त्वाचे असलेले तपासा. उद्देश मोठा डाउनलोड असेल तर फाइल डाउनलोड करा. उद्देश कॉल असेल तर निष्क्रिय थ्रूपुटऐवजी भाराखालील लेटन्सी मोजा, कारण बोगदा वेग चाचणीत चांगले गुण मिळवू शकतो आणि तरीही प्रत्येक बैठक ऐकू न येणारी करू शकतो.