VPN से डाउनलोड सीधे की तुलना में तेज़ क्यों है

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

वक्र का आकार इसे ज़ाहिर कर देता है

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

एक ही फ़ाइल के दो रन, एक सीधा और एक टनल से, यह देखने के लिए पर्याप्त हैं कि पठार है या नहीं।

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

तीन तुलनाएँ, हर एक में एक चर

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

curl -o /dev/null -w '%{speed_download}' https://files.example/big.iso
scp [email protected]:/exports/big.iso /dev/null

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

घंटा भी दर्ज करें, क्योंकि शेपर समय-आधारित हो सकता है और शाम का परीक्षण सुबह के परीक्षण से सहमत न हो। एक ही घंटे के दो रन पूरे दिन में बिखरे दस से अधिक मूल्य के हैं।

यह माप क्या सिद्ध नहीं कर सकता

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

यह यह भी नहीं दिखाता कि सीधा मार्ग दोषपूर्ण है। सीमित मार्ग ठीक वैसे ही काम करता है जैसे इरादा था, वह केवल नीति से सीमित है।

जब आप इसे लिखते हैं तब यह अंतर मायने रखता है। दोष मरम्मत टिकट माँगता है, जबकि नीति अनुबंध के बारे में प्रश्न या उसे दरकिनार करने का निर्णय माँगती है। सीमा को दोष कहने से सहायता वार्ता गलत आधार से शुरू होती है। उसे नीति कहने से आप एक विशिष्ट प्रश्न पूछ सकते हैं जिसका विशिष्ट उत्तर है।

निष्कर्ष को सहायता अनुरोध में बदलें

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

केवल उस संख्या के पीछे भागने के लिए हर एप्लिकेशन को टनल में न धकेलें।

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