GCP లో స్థిర IP వర్సెస్ VPN వేగం: మూడు వేరియబుల్స్, ఒక పరీక్ష

చిరునామా రిజర్వ్ అయిన తర్వాత బదిలీ వేగవంతమైంది, మరియు ముగింపు తనంతట తానే రాసుకుంది. కానీ అదే మార్పు టన్నెల్‌ను UDP నుండి TCP కి మార్చింది, పరీక్షను మరో సాయంత్రానికి మార్చింది మరియు బహుశా మరో జోన్‌లోని VM పై దిగింది. బాహ్య చిరునామాను రిజర్వ్ చేయడం జీవిత చక్ర సమస్యను పరిష్కరిస్తుంది: పునఃప్రారంభాల మధ్య ముగింపు బిందువును అదే విధంగా ఉంచుతుంది. ప్యాకెట్లను వేగవంతం చేసే ఏ యంత్రాంగం దానిలో లేదు, కాబట్టి ఆ ప్రయోగంలోని వేగ భేదం ఇతర వేరియబుల్స్ కు చెందుతుంది, మరియు మీ ముందున్న నిర్ణయం తర్వాత ఏది పరీక్షించాలనేది.

రిజర్వ్ చేసిన చిరునామా నిజంగా ఏమి కొంటుంది

Compute Engine ఇన్‌స్టాన్స్‌తో కేటాయించబడి విడుదలయ్యే తాత్కాలిక చిరునామాలను, మీరు రిజర్వ్ చేసి ఉంచుకునే స్థిర చిరునామాల నుండి వేరు చేస్తుంది. ఆ భేదం నిల్వ మరియు బిల్లింగ్‌కు సంబంధించినది, ప్యాకెట్ వెళ్లే మార్గానికి కాదు. స్థిరమైన ముగింపు బిందువు DNS రికార్డులు, రిమోట్ యాక్సెస్ ప్రొఫైల్స్, భాగస్వామి అనుమతి జాబితాలు మరియు VM పునఃప్రారంభమైనప్పుడు మారకూడని firewall నియమాలకు నిజంగా ఉపయోగకరం.

ఒకటి రిజర్వ్ చేయడానికి ఇవి మంచి కారణాలు. వాటిలో ఏదీ throughput కారణం కాదు.

పొర, చిరునామా మరియు రవాణాను మూడు వేరియబుల్స్ గా ఉంచండి

Google Cloud Premium మరియు Standard Network Service Tier లను కూడా అమ్ముతుంది, రెండూ వేర్వేరు ఫీచర్ లభ్యతతో ఇంటర్నెట్‌కు వేర్వేరు మార్గాలు తీసుకుంటాయి. స్థిర చిరునామా కేటాయింపు రెండింటికీ ఆర్థోగోనల్, కాబట్టి స్థిర మరియు Premium లను VM గురించి సంబంధం లేని వాస్తవాలుగా చూడండి, పర్యాయపదాలుగా కాదు. వాస్తవ పొర, ప్రాంతం మరియు సంబంధిత ఏదైనా interconnect లేదా attachment ను నమోదు చేయండి, ఎందుకంటే అవి చిరునామా లేబుల్ ఎప్పటికీ చేయని విధంగా మార్గాన్ని వివరిస్తాయి.

మూడు వేరియబుల్స్, మూడు వేర్వేరు ప్రయోగాలు, లేకపోతే ఫలితం కథ, కొలత కాదు.

ఒక ప్రశ్నకు సమాధానమిచ్చే పరీక్షను రూపొందించండి

ఆమోదించిన UDP మరియు TCP ప్రొఫైల్స్ ను పోలుస్తున్నప్పుడు VM, చిరునామా, క్లయింట్ స్థానం, గమ్యం మరియు పని భారాన్ని స్థిరంగా ఉంచండి. ప్రతి రవాణాకు సర్వర్ శ్రోత మరియు సరిపోలే firewall నియమాలు రెండూ అవసరం; క్లయింట్‌లో కీవర్డ్ మార్చి శ్రోతను మార్చకుండా వదిలేస్తే మీ ఓర్పు మాత్రమే పరీక్షించబడుతుంది. పునరావృతమయ్యే బదిలీని ఉపయోగించి దిశ, వ్యవధి, ఒకటి వర్సెస్ సమాంతర స్ట్రీమ్‌లు మరియు యూనిట్లను నమోదు చేయండి, ఎందుకంటే MB/s మరియు Mb/s ఎనిమిది రెట్లు భిన్నం.

VM యొక్క CPU ను కూడా గమనించండి, ఎందుకంటే చిన్న ఇన్‌స్టాన్స్ ఎన్‌క్రిప్షన్ లేదా softirq పనిలో నెట్‌వర్క్ కంటే చాలా ముందే సంతృప్తమవుతుంది, ఆ పరిమితి సరిగ్గా సేవా ప్రదాత పరిమితిలా కనిపిస్తుంది.

VM మరియు క్లయింట్ నుండి పునఃప్రసారం మరియు నష్ట కౌంటర్లు మార్గ సమస్యను రవాణా సమస్య నుండి వేరు చేస్తాయి, పురోగతి బార్ అలా చేయలేదు. iperf3 తో పని చేయగల క్రమం ప్రతి రవాణాకు సుమారు పది నిమిషాలు పడుతుంది. సర్వర్‌ను దూరపు వైపు ప్రారంభించి, ప్రతి దిశలో ముప్పై సెకన్లు క్లయింట్‌ను నడపండి మరియు ప్రతి దిశను మూడు సార్లు పునరావృతం చేయండి. ప్రతి శ్రేణి మొదటి పరుగును పారేయండి, ఆపై TCP పరుగులు ముద్రించే పునఃప్రసార సంఖ్యతో పాటు పంపేవారు మరియు స్వీకరించేవారి రేట్లను పోల్చండి.

UDP మరియు TCP యాంత్రికంగా ఎందుకు భిన్నం

UDP పై OpenVPN డేటాగ్రామ్‌లను మోసుకెళ్తుంది మరియు నష్ట నిర్వహణను అప్లికేషన్ యొక్క స్వంత రవాణాకు వదిలిస్తుంది. TCP పై టన్నెల్ యొక్క నమ్మదగిన స్ట్రీమ్ ఇప్పటికే నమ్మదగిన అప్లికేషన్ స్ట్రీమ్ క్రింద కూర్చుంటుంది, కాబట్టి ఒక పోయిన సెగ్మెంట్ దాని వెనుక ఉన్నదంతా ఆపేస్తుంది, బాహ్య కనెక్షన్ తన స్వంత షెడ్యూల్ ప్రకారం తిరిగి పంపుతుంది. ఆ వరుస తల ప్రవర్తన TCP ను TCP లోపల టన్నెల్ చేయడం యొక్క లక్షణం, సేవా ప్రదాత విధానం కాదు. MTU మరియు MSS నిర్వహణ కూడా రెండు మోడ్‌ల మధ్య భిన్నం, ఇది అదే మార్గంలో ఫ్రాగ్మెంటేషన్ ప్రవర్తనను మారుస్తుంది.

కాబట్టి వేగవంతమైన TCP పరీక్ష ఆ రోజు ఆ మార్గంలో TCP వేగవంతమని మాత్రమే నిరూపిస్తుంది, అంతకంటే సాధారణమైనది ఏదీ కాదు.

సమీక్షను తట్టుకునేలా ఫలితాన్ని రాయండి

సమర్థించదగిన ముగింపుకు ఒక రూపం ఉంది: ఈ ప్రొఫైల్, ఈ మెషిన్ పరిమాణంలో, ఈ నెట్‌వర్క్ పొరపై, ఈ కొలిచిన పని భారాన్ని ఈ దిశలో ఈ పరిస్థితుల్లో నిలబెట్టింది. దీని కంటే విస్తృతమైన దేనికైనా ఒక సాయంత్రం ఇవ్వగలిగిన దానికంటే ఎక్కువ పరుగులు అవసరం. నెమ్మదైన సందర్భం వివరణ లేకుండా మిగిలితే, ఏ సేవా ప్రదాత పత్రం వివరించని పరిమితిని కల్పించడం బదులు ప్యాకెట్ మరియు వనరుల సాక్ష్యంతో పాటు దానిని పరిశీలనగా ఉంచండి.

చిరునామా స్థిరత్వం మరియు బదిలీ వేగం రెండూ ఒకే విస్తరణకు ముఖ్యమైనవి కావచ్చు, ఉపయోగకరమైన నిర్ణయం ప్రతి మార్పుతో మీరు వాటిలో ఏది కొంటున్నారు అనేది.