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

रिझॉल्व्हरचे उत्तर हेच बहुतेक तुलना वगळतात तो तपशील आहे, आणि तोच “सुधारणा” स्पष्ट करतो ज्या तोच सर्व्हर लादल्यावर गायब होतात. प्रत्येक वेळी पत्ता वेगळा असेल, तर चाचणीने दोन मार्ग नाही तर दोन गंतव्यांची तुलना केली आहे. थ्रूपुटसह विलंब आणि हानी नोंदवा, कारण एकूण वेगवान पण प्रत्येक संवादात्मक विनंतीला विलंब जोडणारा मार्ग तक्रार करणाऱ्या वर्कलोडसाठी चांगला नाही. विचारून वाट पाहणाऱ्या प्रत्येक गोष्टीसाठी फेरी-प्रवासाचा वेळ मोठ्या प्रमाणातील वेगापेक्षा महत्त्वाचा आहे.

फरक ठेवणे योग्य कधी असते

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

मोजमापाची नोंद कॉन्फिगरेशनसोबत ठेवा. सुधारणा अजूनही आहे का या पुढच्या प्रश्नाचे उत्तर ती देते, आणि मार्ग बदलला की वर्कलोड बदलला हे जाणण्याचा तोच एकमेव मार्ग आहे. तारखेशिवाय नोंद त्या प्रश्नाचे उत्तर अजिबात देऊ शकत नाही.