के VPN सिधा जडानभन्दा छिटो हुन सक्छ?

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

सुरुङले बदल्न सक्ने तीन कुरा

पहिलो ट्रान्जिट हो। इन्टरनेट राउटिङ मापिएको ढिलाइ नभई अपरेटरको नीति र व्यापारिक सम्बन्धअनुसार चल्छ, त्यसैले VPN प्रदायकमार्फत मार्ग सिधा मार्गभन्दा फरक नेटवर्कबाट जान सक्छ। यसले भिडभाड भएको आदानप्रदान बिन्दु बेवास्ता गर्न वा राम्रो peering भएको बिन्दुमा अवतरण गर्न सक्छ, र त्यत्तिकै सजिलै नराम्रो पनि हुन सक्छ।

दोस्रो गन्तव्य हो। बाहिर जाने ठेगाना बदलिँदा प्रायः DNS जवाफ बदलिन्छ, र सामग्री नेटवर्कले तपाईंलाई अर्को क्यास वा क्षेत्र दिन सक्छ। त्यसपछि सुधारको केही भाग सुरुङको नभई नयाँ सर्भरको हुन्छ। एउटै होस्टनाम क्लाइन्टमा केही नबदली नजिकको वा कम भार भएको सर्भरमा अवतरण गर्न सक्छ।

तेस्रो ढुवानीको व्यवहार हो। इन्क्याप्सुलेसनले प्रभावकारी प्याकेट आकार बदल्छ, र हानि भएको बीच भाग बेवास्ता गर्ने सुरुङले TCP प्रवाहलाई बारम्बार पछि हट्नुको सट्टा यसको विन्डो बढाउन दिन सक्छ। यीमध्ये कुनै पनि सार्वभौमिक गति बढाउने संयन्त्र होइन; प्रत्येक अवलोकन गर्नुपर्ने सर्त हो। तिनलाई अलग गर्नु नै जिज्ञासालाई तथ्यमा बदल्छ।

जुन यसले बदल्न सक्दैन

सुरुङमा केही पनि यन्त्र र नेटवर्कबीचको लिङ्कमा क्षमता थप्दैन। भरिएको Wi-Fi च्यानल, भिडभाड भएको अन्तिम माइल वा सीमित मोबाइल योजनाले दुवै मार्गलाई उस्तै सीमित गर्छ, र सुरुङबाट गरिएको गति परीक्षण त्यो सीमा नाघ्न सक्दैन। उही लिङ्कले इन्क्याप्सुलेट गरिएका प्याकेट बोक्छ, त्यसैले इन्क्याप्सुलेसनले क्षमता खर्च गर्न सक्छ तर कहिल्यै सिर्जना गर्न सक्दैन। बदलिने कुरा प्याकेटहरू त्यो लिङ्क छोडेपछि कहाँ जान्छन् भन्ने हो। त्यसैले छिटो सुरुङ नतिजाको व्याख्या सधैं पहिलो हपभन्दा माथि हुन्छ।

सर्भर पक्षका सीमा पनि त्यत्तिकै उदासीन छन्। यदि टाढाको होस्टले ढिलो सेवा दिन्छ भने, राम्रो मार्गले ढिलो जवाफलाई मात्र बढी कुशलतापूर्वक पुर्‍याउँछ, र प्रयोगकर्ता अझै पर्खिरहन्छ। भारमा रहेको साझा स्रोत त्यही क्षणमा दुवै मार्गमा ढिलो देखिन्छ।

मार्गहरूको उचित तुलना गर्नुहोस्

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

mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com

रिजोल्भरको जवाफ त्यो विवरण हो जुन अधिकांश तुलनाले छोड्छन्, र उही सर्भर थोपिएपछि हराउने “सुधार” व्याख्या गर्छ। यदि ठेगाना हरेक पटक फरक हुन्छ भने, परीक्षणले दुई मार्ग नभई दुई गन्तव्यको तुलना गरेको हो। थ्रुपुटको साथमा ढिलाइ र हानि रिपोर्ट गर्नुहोस्, किनभने समग्रमा छिटो तर हरेक अन्तरक्रियात्मक अनुरोधमा ढिलाइ थप्ने मार्ग गुनासो गर्ने कार्यभारका लागि राम्रो होइन। सोधेर पर्खने हरेक कुराका लागि राउन्ड-ट्रिप समय ठूलो मात्राको गतिभन्दा महत्त्वपूर्ण छ।

कहिले फरक राख्न लायक हुन्छ

यदि स्वीकृत सुरुङले कुनै निश्चित कार्यभारलाई भरपर्दो रूपमा सुधार्छ भने, त्यो वैध सञ्चालन विकल्प हो: कार्यभार, मापन र प्रयोग गरिएको बाहिर जाने मार्ग अभिलेख गर्नुहोस्। उपयोगी अभिलेखले एउटा होस्ट, सुरुङले बनाएको बाहिर जाने ठेगाना, रिजोल्भरको जवाफ र त्यही दिन सिधा मार्गका त्यही संख्याहरू उल्लेख गर्छ। त्यो अर्को इन्जिनियरलाई तुलना दोहोर्‍याउन पर्याप्त छ, फेरि बहस गर्न होइन। यो अझै प्रमाण होइन कि प्रदायकले केही थ्रोटल गर्दैछ, र यो अन्य अनुप्रयोग वा अन्य घण्टामा लागू हुँदैन।

मापनको अभिलेख कन्फिगरेसनसँगै राख्नुहोस्। यसले सुधार अझै छ कि भन्ने अर्को प्रश्नको जवाफ दिन्छ, र मार्ग बदलियो कि कार्यभार भन्ने थाहा पाउने एउटै मार्ग हो। मिति नभएको अभिलेखले त्यो प्रश्नको जवाफ बिल्कुलै दिन सक्दैन।