VPN द्वारे डाउनलोड थेटपेक्षा वेगवान का आहे

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

वक्राचा आकार ते उघड करतो

अंतिम संख्येऐवजी हस्तांतरण पहा। मर्यादित मार्ग सामान्यतः ओळीच्या वेगाजवळ सुरू होतो, त्याचा बर्स्ट हक्क खर्च करतो आणि नंतर मर्यादेवर स्थिर होतो, त्यामुळे सरासरी तुम्ही किती वेळ पाहिले यावर अवलंबून असते। ज्या टनेलने मार्ग खरोखर सुधारला असता ती पहिल्या सेकंदापासूनच चांगली गती दाखवत असती आणि ती टिकवत असती। सपाट भाग हा बोटांचा ठसा आहे, आणि तुम्ही फक्त शिखर नोंदवले तर तो चुकवणे सोपे आहे।

एकाच फाइलच्या दोन फेऱ्या, एक थेट आणि एक टनेलमधून, सपाट भाग आहे का हे पाहण्यासाठी पुरेशा आहेत।

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

तीन तुलना, प्रत्येकात एक चल

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

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

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

तासही नोंदवा, कारण आकारक वेळ-आधारित असू शकतो आणि संध्याकाळची चाचणी सकाळच्या चाचणीशी जुळणार नाही। एकाच तासाच्या दोन फेऱ्या दिवसभरात विखुरलेल्या दहापेक्षा जास्त मूल्याच्या आहेत।

हे मापन काय टिकवू शकत नाही

ते दाखवत नाही की टनेल सर्वसाधारणपणे जलद आहे, ते काही संकुचित करते, किंवा इतर पोर्ट मर्यादित नाहीत। ते एका तासात एका ओळीवरील एक हस्तांतरण वर्णन करते। मर्यादा प्रति सत्र, प्रति ग्राहक किंवा वेळ-आधारित असू शकतात, आणि ऑपरेटर जाहिरात न करता त्या बदलू शकतो।

थेट मार्ग सदोष आहे हेही ते दाखवत नाही। मर्यादित मार्ग नेमका हेतूप्रमाणेच काम करतो, तो फक्त धोरणाने मर्यादित आहे।

तुम्ही हे लिहिता तेव्हा हा फरक महत्त्वाचा आहे। दोष दुरुस्तीचे तिकीट मागतो, तर धोरण कराराबद्दल प्रश्न किंवा ते टाळण्याचा निर्णय मागते। मर्यादेला दोष म्हणणे चुकीच्या आधारावरून सुरू होणारा सहाय्य संवाद निर्माण करते। त्याला धोरण म्हणणे तुम्हाला विशिष्ट उत्तर असलेला विशिष्ट प्रश्न विचारू देते।

शोध सहाय्य विनंतीत बदला

आकडे वापरा आणि निष्कर्ष सोडा। या तासांमध्ये पोर्ट 80 वरून मोठी हस्तांतरणे अपेक्षित गतीच्या सुमारे निम्म्यावर राहतात असे सांगणारी विनंती, सपाट भागाची आकडेवारी जोडून, कृतीयोग्य आहे। VPN जलद आहे असे सांगणारी विनंती तशी नाही, कारण ती ओळीबद्दलच्या निरीक्षणाऐवजी टनेलबद्दलचा दावा म्हणून वाचली जाते। दोन्ही फेऱ्या आणि त्यांच्या वेळमुद्रा जोडा, नंतर ऑपरेटरला धोरण वर्णन करू द्या।

फक्त त्या आकड्यामागे धावण्यासाठी प्रत्येक अनुप्रयोग टनेलमध्ये ढकलू नका।

टनेल अजूनही तुम्हाला अतिरिक्त हॉप, एन्क्रिप्शन आणि अयशस्वीतेच्या नवीन पद्धतींचा खर्च करते, तर मर्यादित पोर्ट तो वापरणाऱ्या इतर सर्वांसाठी मर्यादितच राहतो। मोठी हस्तांतरणे विश्वासार्हपणे पूर्ण व्हायला हवी असताना, कोणता पोर्ट मर्यादा वाहतो याची तुमची स्वतःची नोंद ठेवा। श्रोता पोर्ट 80 वर हलवणे हेदेखील आधीच त्याला बांधलेल्या कोणत्याही वेब सर्व्हरशी टक्कर देते, आणि ते दुरुस्तीऐवजी नवीन व्यत्यय निर्माण करते।