VPN डाउनलोड आपके सीधे कनेक्शन को क्यों हरा सकता है

टनल जोड़िए, एक बड़ा डाउनलोड शुरू कीजिए और आप देखेंगे कि वह उसी फ़ाइल की बिना टनल वाली गति से लगभग दोगुनी रफ़्तार से चलता है। यह विज्ञापन जैसा लगता है, पर घरेलू लाइन पर यह सच्चा माप भी हो सकता है। आम कारण एक पोर्ट से बंधी गति सीमा है: टनल आपका स्थानांतरण वहाँ ले जाता है जहाँ शेपर नहीं देखता, और लाइन की असली क्षमता पहली बार दिखती है।

यानी दिलचस्प आंकड़ा यह नहीं है कि VPN कितना तेज़ था। यह है कि आपकी लाइन का कितना हिस्सा आपको कभी नहीं मिला, और क्यों।

एक सीमा जो पोर्ट का पीछा करती है, मार्ग का नहीं

एक एक्सेस प्रदाता ग्राहक के हिसाब से प्रोटोकॉल या गंतव्य पोर्ट के अनुसार थ्रूपुट सीमित कर सकता है, और पोर्ट 80 पसंदीदा लक्ष्य है क्योंकि सामान्य ब्राउज़िंग का बहुत सा हिस्सा इसी का उपयोग करता है। सीमा अक्सर पहले पैकेट से लागू नहीं होती: स्थानांतरण लाइन की गति के करीब शुरू होता है, बर्स्ट भत्ता जला देता है और फिर सीमित आंकड़े पर ठहर जाता है। पहले कुछ सेकंड स्वस्थ दिखते हैं और बाकी स्थानांतरण नहीं।

वही बाइट किसी दूसरे पोर्ट से भेजिए और 80 पर बैठा शेपर उन्हें कभी नहीं देखता। टनल सीधे कनेक्शन को हराती दिखती है, हालाँकि उसने एक हॉप, एन्क्रिप्शन और अपना अतिरिक्त भार जोड़ा है। सुधार मार्ग में नहीं, बल्कि एक नियम की अनुपस्थिति में हुआ है।

इसीलिए यह असर फ़ाइलों और गंतव्यों में इतना एक जैसा रहता है। अगर सीमा पोर्ट पर है, तो उस पोर्ट से जाने वाली हर चीज़ एक ही तरह बर्ताव करती है, फ़ाइल का आकार कोई भी हो और मेज़बान कोई भी हो। अलग नियम खींचने वाला गंतव्य अलग वक्र दिखाता है, और वह अंतर अपने आप में निदानक है।

शिखर नहीं, समतल मापिए

शिखर स्थानांतरण का सबसे कम जानकारी देने वाला हिस्सा है, क्योंकि बफ़र भरते समय हर कनेक्शन अच्छा दिखता है। नोट कीजिए कि गति कहाँ ठहरती है और कितनी देर वहाँ रहती है।

curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/

इस जोड़ी को उसी मशीन पर, उसी घंटे, तुलनीय नेटवर्क के मेज़बानों के सामने एक के बाद एक चलाइए। एक नमूना कुछ साबित नहीं करता; हर एक के दो रन में वक्र का आकार ही बर्स्ट भत्ते को स्थिर सीमा से अलग करता है। यह लिखिए कि गति कहाँ सपाट होती है, यह नहीं कि पहले सेकंड ने क्या दिखाया, क्योंकि बर्स्ट ठीक वही है जो शेपर सीमित करना शुरू करने से पहले देता है। स्थानांतरण के बाकी हिस्से तक टिकने वाला शांत समतल ही तुलना का आंकड़ा है।

फ़ाइल को पहले से संपीड़ित रखिए ताकि परिवहन संपीड़न को व्याख्या के रूप में न पेश किया जा सके। PDF या आर्काइव उस चर को हटा देता है, और किसी को यह दलील देने से भी रोकता है कि टनल ने पेलोड दबाया है। अगर दोनों स्थानांतरण एक ही फ़ाइल उपयोग करते हैं, तो बचा हुआ एकमात्र अंतर मार्ग और पोर्ट है। हर आंकड़े के साथ औज़ार और पोर्ट लिखिए, वरना दूसरा रन पहले से तुलनीय नहीं है।

कारण को अलग करने वाली तीन तुलनाएँ

इन्हें क्रम से कीजिए और पैटर्न साफ़ होते ही रुक जाइए, क्योंकि हर एक अलग कहानी को बाहर करती है।

1. वही डाउनलोड सामान्य वेब मार्ग से और दूसरे पोर्ट पर किसी स्थानांतरण औज़ार से दोहराइए, तुलनीय क्षमता वाले मेज़बान से।
2. दोनों को असंपीड्य फ़ाइल के साथ दोहराइए, ताकि संपीड़न उम्मीदवार रह न जाए।
3. अगर टनल सर्वर आप ख़ुद चलाते हैं, तो उसे फिर से पोर्ट 80 पर बाँधिए, क्लाइंट प्रोफ़ाइल ऐसे ठीक कीजिए कि दोनों सिरे सहमत हों, और फिर स्थानांतरित कीजिए। अगर टनल अब सीमित वेब गति पर बैठी है, तो पाबंदी पोर्ट का पीछा करती है, VPN का नहीं।

तीसरा चरण निर्णायक है, और यही वह चरण है जिसे लोग छोड़ देते हैं क्योंकि इसमें कॉन्फ़िगरेशन बदलना पड़ता है। इसके बिना आपने दिखाया है कि दो चीज़ें अलग हैं, यह नहीं कि पोर्ट कारण है।

यह माप किस चीज़ का समर्थन नहीं कर सकता

यह नहीं दिखाता कि टनल आम तौर पर तेज़ है, कि वह कुछ संपीड़ित करती है, या कि लाइन के दूसरे पोर्ट अप्रतिबंधित हैं। यह इस स्थानांतरण का, इस लाइन पर, इस घंटे में वर्णन करता है। सीमाएँ सत्र के हिसाब से, ग्राहक के हिसाब से या दिन के समय के हिसाब से लागू हो सकती हैं, और बिना सूचना बदल सकती हैं।

यह यह भी साबित नहीं करता कि सीधा मार्ग टूटा है। सीमित मार्ग अब भी काम करता है; वह जानबूझकर सीमित है, और जानबूझकर बनी नीति मरम्मत की प्रतीक्षा करती ख़राबी नहीं है।

और यह निश्चित रूप से यह जायज़ नहीं ठहराता कि सब कुछ टनल से गुज़ारा जाए। पोर्ट 80 पर हर एप्लिकेशन सीमित ही रहता है, जबकि आप जो भी मोड़ते हैं वह अब एक अतिरिक्त हॉप और एक अतिरिक्त विफलता विधि पर निर्भर है।

निष्कर्ष को कुछ व्यवहार्य बनाइए

अवलोकन को फ़ैसला नहीं, माप के रूप में लिखिए: पोर्ट 80 पर बड़े स्थानांतरण उसी फ़ाइल के दूसरे पोर्ट पर मिलने वाली गति के लगभग आधे पर ठहरते हैं, इन घंटों में, इस लाइन पर, ये नमूने संलग्न करके। यह ऐसा सहायता अनुरोध है जिसकी कोई जाँच कर सकता है।

«VPN तेज़ है» ऐसा नहीं है। यह एन्क्रिप्शन के अतिरिक्त भार के बारे में जवाब न्योता देता है, और वह जवाब तकनीकी रूप से सही है जबकि किसी को कुछ काम का नहीं बताता। नमूनों की संख्या, घंटा और पोर्ट संलग्न कीजिए, ताकि पाठक पैटर्न दोहरा सके।

अगर आप बड़े स्थानांतरणों के लिए दूसरा पोर्ट इस्तेमाल करते रहने का फ़ैसला करते हैं, तो अपने रिकॉर्ड में यह चेतावनी लिखिए: किसी श्रोता को पोर्ट 80 पर ले जाना वहाँ पहले से बँधे किसी भी वेब सर्वर से टकराता है, और परिणामी विफलता पोर्ट टकराव नहीं, टूटी टनल जैसी दिखती है।