په GCP کې ثابته IP د VPN سرعت سره: درې متغیرونه، یوه ازموینه

د پتې له ریزرو کولو وروسته لیږد ژر شو، او پایله خپله ولیکل شوه. یوازې دا چې هماغه بدلون تونل له UDP څخه TCP ته واړوه، ازموینه بل ماښام ته یووړه او شاید په بل زون کې VM ته کښېناسته. د بهرنۍ پتې ریزرو کول د ژوند دورې ستونزه حل کوي: د بیا پیلونو په اوږدو کې پای ټکی ورته ساتي. دا هېڅ داسې میکانیزم نه لري چې پاکټونه چټک کړي، نو په هغه تجربه کې د سرعت توپیر نورو متغیرونو ته اړه لري، او ستاسو مخې ته پریکړه دا ده چې بل کوم یو وازموئ.

ریزرو شوې پته په رښتیا څه اخلي

Compute Engine هغه لنډمهاله پتې چې له انسټانس سره ګمارل کیږي او خوشې کیږي، له هغو ثابتو پتو نه بېلوي چې تاسو یې ریزرو کوئ او ساتئ. هغه توپیر د ساتنې او بیې اړوند دی، نه هغه لارې چې پاکټ پرې ځي. ثابت پای ټکی د DNS ریکارډونو، له لرې لاسرسي پروفایلونو، د شریکانو د اجازې لیستونو او د فایر وال هغو قواعدو لپاره چې د VM په بیا پیل کېدل ونه بدلېږي، واقعاً ګټور دی.

دا د یوې ریزرو کولو لپاره ښه دلیلونه دي. له دوی څخه هېڅ یو د تېزې تګ دلیل نه دی.

طبقه، پته او ترانسپورت درې متغیرونه وساتئ

Google Cloud د Premium او Standard Network Service Tier طبقې هم پلوري، او دواړه د بېلابېلو ځانګړنو شتون سره انټرنیټ ته بېلې لارې اخلي. ثابته پته ورکول دواړو ته اورتوګونال دی، نو ثابت او Premium د VM په اړه ناتړلي حقایق وګڼئ، نه مترادف. ریښتینې طبقه، سیمه او هر هغه interconnect یا attachment ولیکئ چې په کار کې دی، ځکه دوی لاره داسې بیانوي چې د پتې لیبل به یې هېڅکله ونه کړي.

درې متغیرونه، درې جلا تجربې، که نه نو پایله کیسه ده، نه اندازه کول.

داسې ازموینه ډیزاین کړئ چې یوې پوښتنې ته ځواب ووایي

د منل شوو UDP او TCP پروفایلونو په پرتله کولو کې VM، پته، د کلینټ ځای، منزل او د کار بار ثابت وساتئ. د هر ترانسپورت لپاره د سرور اورېدونکی او د فایر وال سم قواعد دواړه اړین دي؛ په کلینټ کې یوه کلمه بدلول او اورېدونکی بدل نه کول یوازې ستاسو صبر ازموي. تکرارېدونکی لیږد وکاروئ او لور، موده، یوازې او موازي سټریمونه او یوې واحدونه ولیکئ، ځکه MB/s او Mb/s اته ځله توپیر لري.

د VM پروسسر هم وګورئ، ځکه کوچنی انسټانس په کوډ کولو یا softirq کار کې له شبکې ډېر دمخه ډک شي، او هغه حد به بېخي د برابرونکي د حد په څېر ښکاره شي.

د VM او کلینټ د بیا لیږلو او زیان شمارونکي د لارې ستونزه له ترانسپورت ستونزې بېلوي، او د پرمختګ پټۍ دا نشي کولی. iperf3 سره یو عملي ترتیب هر ترانسپورت لپاره شاوخوا لس دقیقې وخت نیسي. سرور په لرې اړخ کې پیل کړئ، کلینټ په هر لوري دیرش ثانیې وچلوئ او هر لوری درې ځله تکرار کړئ. د هرې لړۍ لومړی منډه پرېږدئ، بیا د لیږونکي او ترلاسه کوونکي دواړه کچې د هغو بیا لیږلو له شمېر سره پرتله کړئ چې TCP منډې یې چاپوي.

ولې UDP او TCP په میکانیکي توګه توپیر لري

OpenVPN د UDP له لارې ډاټاګرامونه وړي او د زیان سمبالول د اپلیکیشن خپل ترانسپورت ته پرېږدي. د TCP له لارې د تونل باوري جریان د لا دمخه باوري اپلیکیشن جریان لاندې کېني، نو یو ورک شوی برخه هغه هر څه ودروي چې د هغې شاته دي، پداسې حال کې چې بیرونی تړاو خپل مهالویش ته سم بیا لیږي. دا د کرښې د سر چلند د TCP د TCP دننه تونل کولو ځانګړنه ده، د برابرونکي تګلاره نه. د MTU او MSS سمبالول هم د دوو حالتونو ترمنځ توپیر لري، چې په هماغه لاره کې د ټوټه کېدو چلند بدلوي.

نو ژر TCP ازموینه یوازې دا ثابتوي چې هغه ورځ په هغه لاره TCP ژر و، او له دې ډېر عمومي هېڅ نه.

پایله داسې ولیکئ چې له بیاکتنې تېره شي

د دفاع وړ پایله یو ډول لري: دا پروفایل، په دې ماشین اندازه، په دې شبکه طبقه، دا اندازه شوی کار بار په دې لوري د دې شرایطو لاندې وساته. له دې پراخ هر څه له هغې زیات منډو ته اړتیا لري چې یوه ماښام یې برابرولی شي. که ورو حالت بې توضیحه پاتې شي، د داسې محدودیت جوړولو پرځای چې هېڅ د برابرونکي سند یې نه بیانوي، هغه د پاکټ او سرچینې شاهدانو سره د کتنې په توګه وساتئ.

د پتې ثبات او د لیږد سرعت دواړه کولی شي یوې ګمارنې لپاره مهم وي، او ګټوره پریکړه دا ده چې له هر بدلون سره یې کوم یو اخلئ.