क्या 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

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

कब अंतर रखना उचित है

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

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