GCP मा स्थिर IP विरुद्ध VPN गति: तीन चर, एउटा परीक्षण

ठेगाना आरक्षित भएपछि स्थानान्तरण छिटो भयो, र निष्कर्ष आफैं लेखियो। तर त्यही परिवर्तनले सुरुङलाई UDP बाट TCP मा सार्यो, परीक्षण अर्को साँझमा सार्यो र सायद अर्को जोनको VM मा अवतरण गरायो। बाह्य ठेगाना आरक्षित गर्नु जीवनचक्रको समस्या समाधान गर्छ: यसले पुनः सुरु हुने बीचमा अन्त्य बिन्दु उही राख्छ। यसमा प्याकेटलाई गति दिने कुनै कार्यविधि छैन, त्यसैले त्यो प्रयोगको गति भिन्नता अन्य चरहरूको हो, र तपाईंको अगाडिको निर्णय अर्को कुन परीक्षण गर्ने भन्ने हो।

आरक्षित ठेगानाले वास्तवमा के किन्छ

Compute Engine इन्स्ट्यान्ससँगै तोकिने र छोडिने अल्पकालीन ठेगानाहरूलाई तपाईंले आरक्षित गरी राख्ने स्थिर ठेगानाहरूबाट छुट्याउँछ। त्यो भिन्नता अवधारण र बिलिङसँग सम्बन्धित छ, प्याकेटले लिने बाटोसँग होइन। स्थिर अन्त्य बिन्दु DNS रेकर्ड, टाढाको पहुँच प्रोफाइल, साझेदार अनुमति सूची र VM पुनः सुरु हुँदा नबदलिनुपर्ने फायरवाल नियमका लागि साँच्चै उपयोगी छ।

एउटा आरक्षित गर्न यी राम्रा कारण हुन्। तीमध्ये कुनै पनि थ्रुपुटको कारण होइन।

तह, ठेगाना र यातायातलाई तीन चरका रूपमा राख्नुहोस्

Google Cloud ले Premium र Standard Network Service Tier पनि बेच्छ, र दुवैले फरक सुविधा उपलब्धतासहित इन्टरनेटतर्फ फरक बाटो लिन्छन्। स्थिर ठेगाना निर्धारण दुवैप्रति अर्थोगोनल छ, त्यसैले स्थिर र Premium लाई VM बारेका असम्बन्धित तथ्यका रूपमा हेर्नुहोस्, समानार्थीका रूपमा होइन। वास्तविक तह, क्षेत्र र संलग्न कुनै पनि इन्टरकनेक्सन वा एट्याचमेन्ट नोट गर्नुहोस्, किनकि तिनले बाटोलाई ठेगानाको लेबलले कहिल्यै नगर्ने तरिकाले वर्णन गर्छन्।

तीन चर, तीन छुट्टै प्रयोग, नत्र परिणाम कथा हो, मापन होइन।

एउटा प्रश्नको उत्तर दिने परीक्षण डिजाइन गर्नुहोस्

स्वीकृत UDP र TCP प्रोफाइल तुलना गर्दा VM, ठेगाना, क्लाइन्टको स्थान, गन्तव्य र कार्यभार स्थिर राख्नुहोस्। प्रत्येक यातायातका लागि सर्भर श्रोता र मिल्ने फायरवाल नियम दुवै आवश्यक छन्; क्लाइन्टमा किवर्ड बदलेर श्रोता नबदली राख्नुले तपाईंको धैर्य मात्र परीक्षण गर्छ। दोहोर्याउन सकिने स्थानान्तरण प्रयोग गर्नुहोस् र दिशा, अवधि, एकल विरुद्ध समानान्तर स्ट्रिम र एकाइहरू नोट गर्नुहोस्, किनकि MB/s र Mb/s आठ गुणा फरक छन्।

VM को CPU पनि नियाल्नुहोस्, किनकि सानो इन्स्ट्यान्स इन्क्रिप्शन वा softirq काममा नेटवर्कभन्दा धेरै अघि सन्तृप्त हुन्छ, र त्यो सीमा ठ्याक्कै प्रदायकको सीमाजस्तै देखिनेछ।

VM र क्लाइन्टका पुनःप्रेषण र हानि काउन्टरले बाटोको समस्यालाई यातायातको समस्याबाट अलग गर्छन्, र प्रगति पट्टीले त्यो गर्न सक्दैन। iperf3 सहितको व्यवहार्य क्रम प्रत्येक यातायातका लागि करिब दस मिनेट लिन्छ। टाढाको छेउमा सर्भर सुरु गर्नुहोस्, प्रत्येक दिशामा तीस सेकेन्ड क्लाइन्ट चलाउनुहोस् र प्रत्येक दिशा तीन पटक दोहोर्याउनुहोस्। प्रत्येक शृंखलाको पहिलो रन फाल्नुहोस्, त्यसपछि TCP रनहरूले छाप्ने पुनःप्रेषण संख्यासँगै प्रेषक र प्रापकको दर तुलना गर्नुहोस्।

UDP र TCP यान्त्रिक रूपमा किन फरक छन्

UDP मा OpenVPN डेटाग्राम बोक्छ र हानि सम्हाल्ने काम एप्लिकेशनको आफ्नै यातायातमा छोड्छ। TCP मा सुरुङको भरपर्दो स्ट्रिम पहिले नै भरपर्दो एप्लिकेशन स्ट्रिममुनि बस्छ, त्यसैले एउटा हराएको खण्डले त्यसपछिको सबै रोक्छ, जबकि बाह्य जडान आफ्नै तालिकाअनुसार पुनः पठाउँछ। यो लाइनको टाउकोको व्यवहार TCP लाई TCP भित्र सुरुङ गर्ने गुण हो, प्रदायकको नीति होइन। MTU र MSS को सम्हालिए पनि दुई मोडबीच फरक छ, जसले त्यही बाटोमा खण्डीकरण व्यवहार बदल्छ।

त्यसैले छिटो TCP परीक्षणले त्यो दिन त्यो बाटोमा TCP छिटो थियो भन्ने मात्र प्रमाणित गर्छ, त्यसभन्दा सामान्य केही होइन।

नतिजा समीक्षा टिक्ने गरी लेख्नुहोस्

समर्थनीय निष्कर्षको एउटा आकार हुन्छ: यो प्रोफाइलले, यो मेसिन आकारमा, यो नेटवर्क तहमा, यो मापिएको कार्यभार यो दिशामा यी परिस्थितिमा टिकाइरह्यो। यसभन्दा फराकिलो कुनै पनि कुरालाई एउटा साँझले दिन सक्नेभन्दा बढी रन चाहिन्छ। यदि ढिलो अवस्था अस्पष्ट रह्यो भने, कुनै पनि प्रदायक कागजातले वर्णन नगर्ने थ्रोटल बनाउनुको सट्टा प्याकेट र स्रोत प्रमाणसहित त्यसलाई अवलोकनका रूपमा राख्नुहोस्।

ठेगानाको स्थिरता र स्थानान्तरणको गति दुवै एउटै परिनियोजनका लागि महत्त्वपूर्ण हुन सक्छन्, र उपयोगी निर्णय प्रत्येक परिवर्तनसँग तपाईं तीमध्ये कुन किन्नुहुन्छ भन्ने हो।