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 केबलजस्तै व्यवहार गर्छ भन्ने अपेक्षा छोड्नुहोस्।