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 वेगवान होते, आणि त्याहून सामान्य काहीही नाही।

निकाल असा लिहा की तो पुनरावलोकन टिकून राहील

समर्थनीय निष्कर्षाला एक आकार असतो: हे प्रोफाइल, या मशीन आकारावर, या नेटवर्क स्तरावर, हा मोजलेला कामाचा भार या दिशेने या परिस्थितीत टिकवून ठेवला। याहून विस्तृत कशासाठीही एका संध्याकाळी देऊ शकेल त्यापेक्षा जास्त फेऱ्या लागतात। जर हळू प्रकरण अस्पष्ट राहिले, तर कोणतेही पुरवठादार दस्तऐवज वर्णन करत नाही असे थ्रॉटल शोधून काढण्याऐवजी पॅकेट आणि संसाधन पुराव्यासह ते निरीक्षण म्हणून ठेवा।

पत्त्याची स्थिरता आणि हस्तांतरणाचा वेग दोन्ही एकाच तैनातीसाठी महत्त्वाचे असू शकतात, आणि उपयुक्त निर्णय म्हणजे प्रत्येक बदलासह तुम्ही त्यातील कोणते खरेदी करता हे।