VPN की गति कैसे जाँचें ताकि संख्याएँ कुछ मायने रखें
परीक्षण सर्वर को स्थिर करें, निचली परत को अचल रखें और विलंब को थ्रूपुट से अलग पढ़ें। टनल कुछ भी मापने से पहले ही मार्ग बदल देती है।
गति का परीक्षण कभी VPN को नहीं मापता। वह एक मार्ग मापता है, और टनल चालू करने पर पहला बाइट हिलने से पहले ही उस मार्ग का एक हिस्सा बदल जाता है। इसीलिए एक लैपटॉप एक साइट पर स्वस्थ आँकड़ा और दूसरी पर खराब आँकड़ा दिखाता है, जबकि दोनों ओर कुछ भी नहीं बदला। परिणाम को मार्ग के बारे में सबूत की तरह पढ़ें, किसी उत्पाद के स्कोर की तरह नहीं।
तीन बातें तय करती हैं कि तुलना कुछ काम की है या नहीं: क्या दोनों रन एक ही लक्ष्य पर पहुँचे, क्या एक्सेस नेटवर्क स्थिर रहा, और क्या आपने मात्रा के साथ विलंब दर्ज किया।
पहले बाइट से पहले टनल क्या फिर से लिखती है
क्लाइंट हर पैकेट को एक और हेडर में लपेटता है, इसलिए प्रति पैकेट उपयोगी पेलोड घट जाता है। लागत प्रति पैकेट है, प्रति स्थानांतरण नहीं, यानी एक बड़ी फ़ाइल को बिना टनल भेजी उसी फ़ाइल से अधिक पैकेट चाहिए। ऐसा अतिरिक्त बोझ पैकेट की संख्या के रूप में दिखता है, किसी दिखने वाली सेटिंग के रूप में नहीं।
इससे दो परिणाम निकलते हैं। बड़े ब्लॉक से बना परीक्षण प्रति पैकेट लागत महसूस करता है, जबकि बहुत सारे छोटे अनुरोधों से बना परीक्षण इसके बदले आने-जाने का समय महसूस करता है। और अगर मार्ग का MTU पता लगाना कहीं रास्ते में अवरुद्ध है, तो टनल छोटे पैकेट आकार पर टिक जाती है और थ्रूपुट ऐसे कारण से गिरता है जिसका सिफ़रों से कोई संबंध नहीं है।
आप सीमा को सीधे देख सकते हैं। लिनक्स में विखंडन के बिना पार होने वाला सबसे बड़ा पेलोड माँगें, फिर टनल चालू रखकर दोहराएँ:
ping -M do -s 1472 -c 3 203.0.113.10
अगर वह विफल हो, तो 1,400 पर उतरें और फिर कोशिश करें। जो टनल केवल 1,380 बाइट ढोती है, वह आपको बता रही है कि मार्ग में और नीचे कुछ दबा रहा है, और क्लाइंट पर कोई भी ट्यूनिंग उसे ऊपर नहीं उठाएगी।
टनल चालू होने पर परीक्षण सर्वर क्यों हट जाता है
अधिकांश उपकरण जो सार्वजनिक पता वे देखते हैं उसके आधार पर पास का सर्वर चुनते हैं। टनल चालू होने पर वह पता एग्ज़िट नोड का होता है, इसलिए उपकरण किसी दूसरे शहर या देश का होस्ट चुन सकता है। तब आप दो गंतव्यों की तुलना कर रहे होते हैं, और उनके बीच का अंतर एग्ज़िट से परीक्षण होस्ट तक की दूरी भी शामिल करता है।
पहले रन से पहले सर्वर को नाम या ID से स्थिर करें और उसके बाद हर रन में उसे पकड़े रखें। अगर उपकरण उसे नहीं पकड़ता, तो ऐसा लक्ष्य चुनें जिसे आप नियंत्रित करते हैं और उसे खुद चलाएँ: iperf3 -c test.example.net -R -t 20 गंतव्य को स्थिर रखता है और आपको ऐसा आँकड़ा देता है जिसकी तुलना कल से कर सकते हैं।
एक चर बदलें, और निचली परत एक नहीं है
वायरलेस ही आम छिपा बदलाव है। लैपटॉप हिलने पर सिग्नल की ताकत बदलती है और पड़ोसी के कॉल शुरू करने पर चैनल की व्यस्तता बदलती है, इसलिए Wi-Fi पर दस मिनट के अंतर पर किए दो रन एक ही परीक्षण की पुनरावृत्ति नहीं हैं। तार, या सिग्नल स्तर लिखकर रखी गई स्थिर जगह, उस शोर का अधिकांश हटा देती है। हर रन के शुरू और अंत में सिग्नल स्तर की टिप्पणी आमतौर पर यह दिखाने के लिए पर्याप्त होती है कि दो रन एक साथ हैं या नहीं।
डिवाइस का भार भी उसी टोकरी में है। एक कोर पर एन्क्रिप्ट करने वाला क्लाइंट लिंक से बहुत पहले अपनी सीमा पर पहुँच जाता है, और पृष्ठभूमि का सिंक उससे भी जल्दी पहुँच जाता है। रन के दौरान CPU देखें और लिखें कि और क्या खुला था। पावर सेटिंग्स यहाँ भी काट सकती हैं, क्योंकि बैटरी पर चलता लैपटॉप लिंक के व्यस्त होने से बहुत पहले प्रोसेसर को सीमित कर सकता है।
| Measurement | What it answers | What it misses |
|---|---|---|
| Download | Bulk capacity along the path | Any question about responsiveness |
| Upload | Capacity from client to exit | Download health |
| RTT to a fixed target | Distance plus queueing | Whether capacity is available |
| Jitter or loss | Stability under load | How much the link can carry |
निचली परत का औसत लेने के बजाय उसे अचल रखें। सहमत तीन रन अलग-अलग कमरों में लिए दस से अधिक बताते हैं।
विलंब, हानि और ICMP अलग-अलग सवालों के जवाब देते हैं
पिंग एक स्थिर पते पर छोटी जाँच भेजता है, और बहुत से नेटवर्क ICMP का जवाब कम प्राथमिकता पर देते हैं या उसे पूरी तरह अनदेखा कर देते हैं। अनुपस्थित जवाब जाँच का वर्णन करते हैं, ऐप्लिकेशन के पैकेट का नहीं। भार के नीचे बढ़ता आने-जाने का समय आमतौर पर बताता है कि कतार भर रही है, यह नहीं कि मार्ग लंबा हो गया।
यह जानने के लिए कि टनल विलंब जोड़ती है या नहीं, एक लक्ष्य की तुलना उसके साथ और उसके बिना करें, या एक ही एक्सेस नेटवर्क से पहुँचने योग्य दो एग्ज़िट की तुलना करें। जाँच को बार-बार चलाएँ और फैलाव देखें, क्योंकि औसत ठीक उसी भिन्नता को छिपाता है जो कॉल को बेकार बनाती है।
उस काम पर लौटें जो धीमा लगा था
जो माप कॉल के टुकड़े-टुकड़े होते रहने पर भी सुधरता है उसने कुछ और जवाब दिया है। जिस काम से जाँच शुरू हुई थी उसे फिर चलाएँ, चाहे वह बैठक हो, फ़ाइल साझा करना हो या दूरस्थ डेस्कटॉप सत्र हो। अगर आँकड़ा सुधरा और काम नहीं, तो अड़चन कहीं ऐसी जगह थी जहाँ परीक्षण कभी पहुँचा ही नहीं, जैसे टनल के पीछे का सर्वर या आपकी ओर का अपलिंक।
हर रन को डिवाइस, एक्सेस नेटवर्क, एंडपॉइंट, प्रोटोकॉल, लक्ष्य और समय के साथ दर्ज करें। जो रन कभी जुड़ा ही नहीं वह शून्य थ्रूपुट नहीं बल्कि पहुँच का परिणाम है, इसलिए उसे मिटाने के बजाय उसी लेबल के नीचे रखें।
अगली तुलना से पहले एक छोटी सूची
लक्ष्य को स्थिर करें और लिखें कि आपने उसे क्यों चुना। मार्ग जो पैकेट आकार अनुमत करता है उसे दर्ज करें, ताकि बाद की गिरावट की व्याख्या हो। एक्सेस नेटवर्क को एक जैसा रखें, CPU भार लिखें, और अंतर पर विश्वास करने से पहले तीन रन लें।
फिर ठीक एक चीज़ बदलें और दोहराएँ। जिस तुलना को आप समझा सकते हैं वह बड़े आँकड़े वाली तुलना से बेहतर है।