VPN वरून फाइल शेअरिंग संथ का वाटते: राउंड ट्रिप्स, Mbps नाही

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

दूरची कार्यप्रत चुकीच्या आकारात आहे

SMB फाइली उघडते, मेटाडेटा वाचते आणि अनेक लहान देवघेवीत पुष्टी देते। मॅप केलेल्या ड्राइव्हवरील आवृत्ती-नियंत्रणाची कार्यप्रत स्थानिक फाइलसिस्टमचा विलंब गृहीत धरते आणि अनेक लहान फाइली वाचते। डेस्कटॉप डेटाबेस वापरकर्ता काम करत असताना पृष्ठे ओढतो। यातील प्रत्येकजण विलंबाला गुणक बनवतो, कारण खर्च क्रिया किती देवघेवी करते यासोबत वाढतो; म्हणून 40 ms चा टनेल काहीशे क्रिया काही सेकंदांत बदलतो। त्या गणितात पेलोडचा आकार जवळपास अप्रस्तुत आहे।

एन्क्रिप्शनचा ओव्हरहेड त्याचा छोटा भाग आहे; हानी अधिक वाईट आहे, कारण एक पुनःप्रेषण आणि कोसळलेली कंजेशन विंडो संबंधित बाइट्सपेक्षा खूप जास्त खर्च करतात।

मेगाबाइटपूर्वी राउंड ट्रिप्स मोजा

क्षमता खरेदी करण्यापूर्वी विलंब मोजा। एक ping सांगते की प्रत्येक देवघेव काय देते।

ping -c 10 fileserver.example.net

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

काम हलवा, बाइट्स नाही

अधिक पाईपसाठी पैसे देण्याऐवजी काम कुठे होते ते बदला। रेपॉझिटरी माउंट करण्याऐवजी सर्व्ह करा, आणि फक्त फरक पाठवणाऱ्या साधनाने मोठ्या प्रमाणात प्रत करा।

rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/

रेपॉझिटरी सर्व्ह केल्यास, hgweb किंवा दूरचे Git करते तसे, क्लायंट स्थानिक क्लोनवर काम करू शकतो, त्यामुळे त्याची फाइलसिस्टम कॉल कधीही टनेल ओलांडत नाहीत। rsync दोन्ही बाजूंनी फिरतो आणि बदललेले ब्लॉक पाठवतो, ज्यामुळे भोळी प्रत देते त्या बहुतेक देवघेवी वाचतात। डेस्कटॉप डेटाबेस सर्व्हर-साइड इंजिनवर असावा आणि क्लायंट फक्त समोरचा इंटरफेस राहावा, किंवा संपूर्ण क्लायंट अंतर्गत होस्टवर चालावा। प्रत्येक पर्याय प्रोटोकॉल किती विलंबाला सामोरा जातो ते बदलतो, आणि तोच मुद्दा आहे।

त्याच आकाराजवळ अडकणे हे MTU चे लक्षण आहे

ping आणि लहान पृष्ठे चालत असताना, जवळपास तितक्याच डेटानंतर थांबणारे मोठे स्थानांतरण बँडविड्थकडे नव्हे तर पॅकेटच्या आकाराकडे निर्देश करते।

ping -M do -s 1400 -c 3 fileserver.example.net

यशस्वी चाचणीचा अर्थ 1428 बाइटचे IP पॅकेट मार्ग विभाजनाशिवाय ओलांडते, कारण ICMP आणि IP शीर्षलेख 28 बाइट जोडतात। विभाजन-प्रतिबंध ध्वजासह अपयश सूचवते की टनेलचे वापरण्यायोग्य MTU सर्व्हर गृहीत धरते त्यापेक्षा लहान आहे। 9000 बाइटचे बफर 1500 बाइटच्या मार्गावर पाठवणारा सर्व्हर विभाजन किंवा टाकाऊपणा भाग पाडतो, आणि ICMP गाळल्यास मार्ग MTU शोध शांतपणे अपयशी होऊ शकतो। टनेलचे MTU कमी करा, सक्षम करा mssfix OpenVPN वर, किंवा सर्व्हरचे बफर लहान करा, नंतर पुष्टीसाठी तेच स्थानांतरण पुन्हा चालवा।

महत्त्वाची असलेली तफावत मोजा

धोरण परवानगी देते तिथे तीच क्रिया तीन प्रकारे चालवा: स्थानिक, टनेलमधून आणि थेट इंटरनेट मार्गाने। प्रत्येकासाठी राउंड-ट्रिप वेळ, एका मोठ्या प्रवाहाचा दर, आणि डिरेक्टरी यादी किंवा ॲप उघडण्यास किती वेळ लागतो ते नोंदवा। स्थानिक फेरीची टनेल फेरीशी तुलना कोणता खर्च प्रभावी आहे ते दाखवते। संथ संपणारी प्रत दर किंवा विलंबाची समस्या सूचवते, तर स्थिर बिंदूवर मरणारी प्रत पॅकेटचा आकार किंवा मार्गातील स्थिती ठेवणाऱ्या उपकरणाकडे निर्देश करते।

फक्त सुरुवातीचे मेगाबाइट ओढले जात असतील तर प्रमाणीकरण आणि मेटाडेटा पाहा; सर्व काही सरपटत असेल तर क्षमता आणि हानी पाहा। जुळणारे कारण सुधारा, आणि WAN लिंक LAN केबलसारखे वागेल अशी अपेक्षा सोडा।