VPN डाउनलोड सर्वर के अपलोड से सीमित क्यों होता है

क्लाइंट तेज़ डाउनलिंक दिखाता है, सर्वर फ़ाइबर कनेक्शन पर बैठा है, और फिर भी स्थानांतरण रेंगता है। लोग जिस संख्या की तुलना करते हैं वह आमतौर पर क्लाइंट के प्लान पर छपी होती है, जबकि पैकेट वास्तव में पहले सर्वर के आउटबाउंड एक्सेस लिंक को पार करता है। वही लिंक वह बजट है जिसमें स्थानांतरण को फ़िट होना है। छोटे घरेलू कनेक्शन पर यह पथ की सबसे छोटी संख्या है।

आपने जो संख्या पढ़ी वह गलत दिशा में थी

दूरस्थ क्लाइंट की ओर डाउनलोड टनल के सर्वर सिरे पर अपलोड क्षमता खर्च करता है। सर्वर की विज्ञापित डाउनलोड दरें विपरीत दिशा बताती हैं और इस दिशा के बारे में कुछ नहीं कहतीं। वही असमानता उलट जाती है जब क्लाइंट अपलोड करता है, इसलिए एक दिशा ठीक लग सकती है जबकि दूसरी बेकार हो।

एनकैप्सुलेशन ओवरहेड और कोई भी प्रतिस्पर्धी ट्रैफ़िक उसी बजट का हिस्सा खर्च करते हैं। दोनों में से कोई ऐसे स्पीड टेस्ट में दिखता नहीं जो केवल क्लाइंट मापता है।

पथ को बजट के रूप में लिखें

पैकेट को जिन-जिन सीमाओं को पार करना है उन सबकी सूची बनाएँ और हर एक को उसी इकाई में संख्या दें। स्रोत से डिलीवरी, सर्वर पर प्रोसेसिंग, सर्वर की अपलिंक, बीच का पथ, क्लाइंट की डाउनलिंक और क्लाइंट पर प्रोसेसिंग — सभी लागू होते हैं। उपयोगी दर इनमें सबसे छोटी है, ओवरहेड घटाकर, और उस छत के ऊपर कोई ट्यूनिंग परिणाम नहीं बदलती। मापने से पहले सूची लिख लें, क्योंकि यह बताती है कि किस संख्या पर भरोसा न करें।

सर्वर की 20 Mbit/s अपलिंक और क्लाइंट की 100 Mbit/s डाउनलिंक के साथ, सर्वर क्लाइंट के ध्यान देने से बहुत पहले स्थानांतरण सीमित कर देता है। ओवरहेड और कोई भी समवर्ती स्थानांतरण और हिस्सा लेते हैं, और संतृप्त अपलिंक पावती भी विलंबित करती है, जो TCP स्थानांतरण को कच्ची छत से नीचे धीमा कर देता है। दोनों में से कोई प्रभाव प्लान तुलना में दिखता नहीं।

मेगाबिट और मेगाबाइट अलग रखें, और बताएँ कि हर आँकड़ा एन्क्रिप्टेड लिंक ट्रैफ़िक मापता है या एप्लिकेशन पेलोड। इन दोनों को मिलाना ही बजट के न मिलने का सबसे आम कारण है। हर आँकड़े को उसकी इकाई और माप बिंदु के साथ लेबल करें।

बोर्ड वास्तव में आपको कहाँ महँगा पड़ता है

एक्सेस लिंक पर्याप्त बड़ा होने पर एंडपॉइंट हार्डवेयर दिखने लगता है, और तभी प्रोसेसर का महत्व रहता है। मॉडल, इंटरफ़ेस व्यवस्था और प्रयुक्त कार्यान्वयन पहचानें। किसी पुराने बोर्ड की साझा बस के बारे में एक अवलोकन हर बाद के संशोधन का वर्णन नहीं करता।

एक CPU औसत के बजाय अलग-अलग प्रोसेसिंग पथ की तुलना करें। मध्यम समग्र भार एक संतृप्त कोर छिपा सकता है जो हर पैकेट का सारा काम कर रहा हो, और क्लॉक आवृत्ति प्रोसेसर डिज़ाइनों के बीच प्रदर्शन स्कोर के रूप में नहीं जाती। पैकेट दर उतनी ही मायने रखती है जितनी थ्रूपुट, क्योंकि छोटे पैकेट बड़े पैकेट से प्रति बाइट अधिक महँगे पड़ते हैं। उन पैकेट आकारों से मापें जो आपका वर्कलोड वास्तव में उपयोग करता है।

तापीय और शक्ति सीमाएँ भी निरंतर व्यवहार तय करती हैं। छोटा विस्फोट उत्कृष्ट लग सकता है जबकि दस मिनट का स्थानांतरण थ्रॉटल हो जाता है, इसलिए कुछ सेकंड का बेंचमार्क रात्रि बैकअप के लिए खराब मार्गदर्शक है।

विक्रेता का प्रदर्शन मार्गदर्शन एक्सेस बैंडविड्थ, CPU, पैकेट प्रोसेसिंग, ट्रांसपोर्ट और पैकेट आकार को अलग-अलग बाधाओं में बाँटता है। साइफ़र बदलने से पहले इसे पढ़ना उचित है, क्योंकि साइफ़र परिवर्तन शायद ही कभी उस सीमा को हिलाता है जो कभी सीमा थी ही नहीं।

साइफ़र बदलने से पहले मापें

एक दिशात्मक परीक्षण चलाएँ जो टनल के माध्यम से वास्तव में प्राप्त दर बताए, फिर तुलना के लिए वही परीक्षण कच्चे इंटरफ़ेस पर चलाएँ। इन दोनों संख्याओं का अंतर टनल की लागत है, और दो छतों में से छोटी बताती है कि किस सीमा पर हमला करना है।

तुलना करते समय सुरक्षा नीति अक्षुण्ण रखें। कमज़ोर साइफ़र या ओवरक्लॉक किए बोर्ड के साथ मिला पुराना परिणाम मौजूदा परिनियोजन की योजना नहीं है।

iperf3 -c 10.44.0.1 -R -t 30
iperf3 -c 10.44.0.1 -t 30
ethtool eth0 | grep -i speed

उसी रन के एंडपॉइंट अवलोकनों के बगल में दिशात्मक परिणाम रखें। अगला परिवर्तन मापी गई छत को लक्षित करना चाहिए, न कि उस घटक को जो स्पेसिफ़िकेशन शीट पर सबसे छोटा दिखता है।