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 केबल जैसा व्यवहार करेगा।