संख्याहरूले अर्थ राख्ने गरी VPN को गति कसरी परीक्षण गर्ने
परीक्षण सर्भर स्थिर गर्नुहोस्, तल्लो तह नहल्ने गरी राख्नुहोस् र ढिलाइलाई थ्रुपुटबाट छुट्टै पढ्नुहोस्। टनेलले केही नाप्नु अघि नै बाटो बदल्छ।
गतिको परीक्षणले कहिल्यै VPN नाप्दैन। यसले एउटा बाटो नाप्छ, र टनेल सुरु गर्दा पहिलो बाइट सर्नु अघि नै त्यो बाटोको एक भाग बदलिन्छ। त्यसैले एउटै ल्यापटपले एउटा साइटमा स्वस्थ अंक र अर्कोमा कमजोर अंक देखाउँछ, दुवैतिर केही नबदलेको हुँदा पनि। नतिजालाई बाटोबारेको प्रमाणका रूपमा पढ्नुहोस्, उत्पादनको अंकका रूपमा होइन।
तुलना केही उपयोगी छ कि छैन भन्ने तीन कुराले निर्धारण गर्छ: दुवै दौड एउटै लक्ष्यमा पुगे कि, पहुँच सञ्जाल स्थिर रह्यो कि, र तपाईंले ढिलाइलाई परिमाणसँगै लेख्नुभयो कि।
पहिलो बाइटअघि टनेलले के पुनर्लेखन गर्छ
क्लाइन्टले हरेक प्याकेटलाई अर्को हेडरमा बेर्छ, त्यसैले प्रति प्याकेट उपयोगी पेलोड घट्छ। लागत प्रति स्थानान्तरण होइन, प्रति प्याकेट हुन्छ, अर्थात् ठूलो फाइललाई टनेलबिना पठाइएको त्यही फाइलभन्दा बढी प्याकेट चाहिन्छ। यस्तो अतिरिक्त भार देखिने सेटिङका रूपमा होइन, प्याकेटको संख्याका रूपमा देखिन्छ।
त्यसबाट दुई परिणाम आउँछन्। ठूला ब्लकबाट बनेको परीक्षणले प्रति प्याकेट लागत महसुस गर्छ, धेरै साना अनुरोधबाट बनेको परीक्षणले त्यसको सट्टा आउने-जाने यात्रा महसुस गर्छ। र यदि बाटोको MTU पत्ता लगाउने काम बीचमा कतै अवरुद्ध छ भने टनेल सानो प्याकेट आकारमा अडिन्छ र साइफरसँग कुनै सम्बन्ध नभएको कारणले थ्रुपुट घट्छ।
तपाईं सीमा सिधै हेर्न सक्नुहुन्छ। लिनक्समा खण्डनबिना पार हुने सबैभन्दा ठूलो पेलोड माग्नुहोस्, त्यसपछि टनेल सुरु राखेर दोहोर्याउनुहोस्:
ping -M do -s 1472 -c 3 203.0.113.10
त्यो असफल भयो भने 1,400 मा झर्नुहोस् र फेरि प्रयास गर्नुहोस्। केवल 1,380 बाइट बोक्ने टनेलले तपाईंलाई बाटोमा तल केही बढी थिचिरहेको छ भन्छ, र क्लाइन्टमा कुनै पनि ट्युनिङले त्यो माथि उठाउँदैन।
टनेल सुरु हुँदा परीक्षण सर्भर किन सर्छ
धेरैजसो उपकरणले आफूले देख्ने सार्वजनिक ठेगानाका आधारमा नजिकको सर्भर छान्छन्। टनेल सुरु हुँदा त्यो ठेगाना एक्जिट नोडको हुन्छ, त्यसैले उपकरणले अर्को सहर वा देशको होस्ट छान्न सक्छ। त्यसपछि तपाईं दुई गन्तव्यको तुलना गर्नुहुन्छ, र तिनीहरूबीचको फरकमा एक्जिटदेखि परीक्षण होस्टसम्मको दूरी पनि समावेश हुन्छ।
पहिलो दौडअघि सर्भरलाई नाम वा ID ले स्थिर गर्नुहोस् र त्यसपछिको हरेक दौडमा टिकाइराख्नुहोस्। उपकरणले टिकाउँदैन भने तपाईं नियन्त्रण गर्ने लक्ष्य छान्नुहोस् र आफैं चलाउनुहोस्: iperf3 -c test.example.net -R -t 20 गन्तव्य स्थिर राख्छ र हिजोसँग तुलना गर्न सकिने अंक दिन्छ।
एउटा चर बदल्नुहोस्, र तल्लो तह एक होइन
वायरलेस नै सामान्य लुकेको परिवर्तन हो। ल्यापटप सर्दा सिग्नलको बल बदलिन्छ र छिमेकीले कल सुरु गर्दा च्यानलको व्यस्तता बदलिन्छ, त्यसैले Wi-Fi मा दस मिनेटको फरकमा गरिएका दुई दौड एउटै परीक्षणका पुनरावृत्ति होइनन्। केबल, वा सिग्नल स्तर लेखिएको स्थिर स्थान, त्यो हल्लाको धेरै भाग हटाउँछ। हरेक दौडको सुरु र अन्त्यमा सिग्नल स्तरको टिप्पणी दुई दौड एउटै हुन् कि भनी देखाउन प्रायः पर्याप्त हुन्छ।
उपकरणको भार पनि त्यही टोकरीमा पर्छ। एउटा कोरमा इन्क्रिप्ट गर्ने क्लाइन्ट लिङ्कभन्दा धेरै अघि आफ्नै सीमामा पुग्छ, र पृष्ठभूमिको सिंक अझ चाँडो पुग्छ। दौडका क्रममा CPU हेर्नुहोस् र अरू के खुला थियो लेख्नुहोस्। पावर सेटिङले पनि यहाँ टोक्न सक्छ, किनकि ब्याट्रीमा चल्ने ल्यापटपले लिङ्क व्यस्त हुनुभन्दा धेरै अघि प्रोसेसर सीमित गर्न सक्छ।
| Measurement | What it answers | What it misses |
|---|---|---|
| Download | Bulk capacity along the path | Any question about responsiveness |
| Upload | Capacity from client to exit | Download health |
| RTT to a fixed target | Distance plus queueing | Whether capacity is available |
| Jitter or loss | Stability under load | How much the link can carry |
तल्लो तहको औसत लिनुको सट्टा त्यसलाई स्थिर राख्नुहोस्। मिल्ने तीन दौड फरक कोठामा लिइएका दसभन्दा बढी भन्छन्।
ढिलाइ, हानि र ICMP फरक प्रश्नको उत्तर दिन्छन्
पिङले स्थिर ठेगानामा सानो जाँच पठाउँछ, र धेरै सञ्जालले ICMP लाई कम प्राथमिकतामा जवाफ दिन्छन् वा पूरै बेवास्ता गर्छन्। नआएका जवाफले जाँचको वर्णन गर्छन्, एप्लिकेसनका प्याकेटको होइन। भारमुनि बढ्ने आउने-जाने समयले सामान्यतया लाइन भरिँदै छ भन्ने बुझाउँछ, बाटो लामो भयो भन्ने होइन।
टनेलले ढिलाइ थप्छ कि भनी जान्न एउटा लक्ष्यलाई यससँग र यसबिना तुलना गर्नुहोस्, वा एउटै पहुँच सञ्जालबाट पुग्न सकिने दुई एक्जिटको तुलना गर्नुहोस्। जाँच बारम्बार चलाउनुहोस् र फैलावट हेर्नुहोस्, किनकि औसतले ठ्याक्कै त्यही भिन्नता लुकाउँछ जसले कललाई नचाहिने बनाउँछ।
ढिलो लागेको काममा फर्कनुहोस्
कल अझै टुटिरहँदा सुधार हुने मापन ले अरू कुनै प्रश्नको उत्तर दिएको छ। अनुसन्धान सुरु गरेको काम फेरि चलाउनुहोस्, त्यो बैठक होस्, फाइल साझेदारी होस् वा टाढाको डेस्कटप सत्र होस्। अंक सुधारियो तर काम सुधारिएन भने अवरोध त्यहाँ थियो जहाँ परीक्षण कहिल्यै पुगेन, जस्तै टनेलपछाडिको सर्भर वा तपाईंकोतर्फको अपलिङ्क।
हरेक दौडलाई उपकरण, पहुँच सञ्जाल, अन्त्य बिन्दु, प्रोटोकल, लक्ष्य र समयसँगै लेख्नुहोस्। कहिल्यै नजोडिएको दौड शून्य थ्रुपुट होइन, पहुँचको नतिजा हो, त्यसैले मेट्नुको सट्टा त्यही लेबलमुनि राख्नुहोस्।
अर्को तुलनाअघि छोटो सूची
लक्ष्य स्थिर गर्नुहोस् र किन छान्नुभयो लेख्नुहोस्। बाटोले अनुमति दिने प्याकेट आकार लेख्नुहोस्, ताकि पछिको गिरावटको व्याख्या होस्। पहुँच सञ्जाल एउटै राख्नुहोस्, CPU भार लेख्नुहोस्, र फरक विश्वास गर्नुअघि तीन दौड लिनुहोस्।
त्यसपछि ठ्याक्कै एउटा कुरा बदल्नुहोस् र दोहोर्याउनुहोस्। तपाईंले व्याख्या गर्न सक्ने तुलना ठूलो अंक भएको तुलनाभन्दा राम्रो हुन्छ।