एक ही टनल पर दो 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 पर, और सिर्फ़ तीसरा कतार प्रबंधन पर।
विधि को रिकॉर्ड में लिखें
रखने लायक परिणाम डिवाइस, एक्सेस नेटवर्क, एग्ज़िट, मापन सर्वर, दिशा, स्ट्रीम संख्या और अवधि का नाम बताता है। इनके बिना दो संख्याओं की तुलना नहीं हो सकती, और एक संख्या वाला टिकट असल में एक मनोदशा है।
ख़राब रन भी रखें। जिस श्रृंखला में एक एग्ज़िट हर बार रुकावट पैदा करता है, वह औसत से कहीं ज़्यादा जानकारीपूर्ण है, और रुकावटें ही वह चीज़ हैं जो औसत छिपाते हैं।
फिर उस चीज़ को परखें जो सचमुच आपके लिए मायने रखती है। अगर लक्ष्य बड़ा डाउनलोड है, तो फ़ाइल डाउनलोड करें। अगर लक्ष्य कॉल है, तो निष्क्रिय थ्रूपुट के बजाय भार के नीचे लेटेंसी मापें, क्योंकि टनल गति परीक्षण में अच्छा अंक ले सकती है और फिर भी हर मीटिंग को अनसुनी बना सकती है।