GCP میں مستقل IP اور VPN کی رفتار: تین متغیرات، ایک آزمائش

پتہ محفوظ ہونے کے بعد منتقلی تیز ہو گئی، اور نتیجہ خود لکھا گیا۔ صرف یہ کہ اسی تبدیلی نے سرنگ کو UDP سے TCP پر بھی منتقل کیا، آزمائش کو دوسری شام پر لے گئی اور ممکنہ طور پر کسی اور زون کے VM پر اتار دیا۔ بیرونی پتہ محفوظ کرنا زندگی چکر کا مسئلہ حل کرتا ہے: یہ دوبارہ شروع ہونے کے دوران آخری نقطہ یکساں رکھتا ہے۔ اس میں کوئی ایسا طریقہ کار نہیں جو پیکٹوں کو تیز کرے، اس لیے اس تجربے میں رفتار کا فرق دیگر متغیرات کا ہے، اور آپ کے سامنے فیصلہ یہ ہے کہ آگے کس چیز کی آزمائش کریں۔

محفوظ شدہ پتہ واقعی کیا خریدتا ہے

Compute Engine ان عارضی پتوں کو جو مثال کے ساتھ مختص اور جاری ہوتے ہیں، ان مستقل پتوں سے الگ کرتا ہے جو آپ محفوظ کرتے اور رکھتے ہیں۔ یہ فرق برقراری اور بلنگ سے متعلق ہے، اس راستے سے نہیں جو پیکٹ طے کرتا ہے۔ مستحکم آخری نقطہ DNS ریکارڈ، دور دراز رسائی پروفائل، شراکت دار اجازت فہرستوں اور فائر وال قواعد کے لیے واقعی مفید ہے جو VM کے دوبارہ شروع ہونے پر تبدیل نہیں ہونے چاہئیں۔

ایک محفوظ کرنے کی یہ اچھی وجوہات ہیں۔ ان میں سے کوئی بھی تھرو پٹ کی وجہ نہیں ہے۔

سطح، پتہ اور ترسیل کو تین متغیرات کے طور پر رکھیں

Google Cloud Premium اور Standard Network Service Tier بھی بیچتا ہے، اور دونوں مختلف خصوصیات کی دستیابی کے ساتھ انٹرنیٹ کی طرف الگ راستے لیتے ہیں۔ مستقل پتہ بندی دونوں کے لیے عمودی ہے، اس لیے مستقل اور Premium کو VM کے بارے میں غیر متعلق حقائق سمجھیں، ہم معنی الفاظ نہیں۔ اصل سطح، علاقہ اور شامل کوئی بھی interconnection یا attachment درج کریں، کیونکہ وہ راستے کو ایسے بیان کرتے ہیں جیسے پتے کا لیبل کبھی نہیں کرے گا۔

تین متغیرات، تین الگ تجربات، ورنہ نتیجہ کہانی ہے، پیمائش نہیں۔

ایسی آزمائش ڈیزائن کریں جو ایک سوال کا جواب دے

منظور شدہ UDP اور TCP پروفائلز کا موازنہ کرتے وقت VM، پتہ، کلائنٹ کی جگہ، منزل اور کام کا بوجھ مستقل رکھیں۔ ہر ترسیل کے لیے سرور سننے والا اور مطابق فائر وال قواعد دونوں ضروری ہیں؛ کلائنٹ میں کوئی کلیدی لفظ بدل کر سننے والے کو بغیر تبدیلی چھوڑ دینا صرف آپ کے صبر کا امتحان ہے۔ قابل تکرار منتقلی استعمال کریں اور سمت، دورانیہ، واحد اور متوازی سٹریمز اور اکائیاں درج کریں، کیونکہ MB/s اور Mb/s آٹھ گنا مختلف ہیں۔

VM کے CPU پر بھی نظر رکھیں، کیونکہ چھوٹی مثال انکرپشن یا softirq کام میں نیٹ ورک سے بہت پہلے سیر ہو جاتی ہے، اور وہ حد بالکل فراہم کنندہ کی حد جیسی دکھے گی۔

VM اور کلائنٹ سے دوبارہ بھیجنے اور نقصان کے شمار کنندگان راستے کے مسئلے کو ترسیل کے مسئلے سے الگ کرتے ہیں، اور پیش رفت پٹی یہ نہیں کر سکتی۔ iperf3 کے ساتھ قابل عمل ترتیب ہر ترسیل کے لیے تقریباً دس منٹ لیتی ہے۔ سرور کو دور والے سرے پر شروع کریں، کلائنٹ کو ہر سمت میں تیس سیکنڈ چلائیں اور ہر سمت تین بار دہرائیں۔ ہر سلسلے کی پہلی دوڑ پھینک دیں، پھر TCP دوڑوں کے چھاپے جانے والے دوبارہ بھیجنے کی تعداد کے ساتھ بھیجنے والے اور وصول کرنے والے کی شرحیں موازنہ کریں۔

UDP اور TCP میکانی طور پر کیوں مختلف ہیں

OpenVPN UDP پر ڈیٹا گرام لے جاتا ہے اور نقصان سے نمٹنے کا کام ایپلیکیشن کی اپنی ترسیل پر چھوڑ دیتا ہے۔ TCP پر سرنگ کا قابل اعتماد سلسلہ پہلے سے قابل اعتماد ایپلیکیشن سلسلے کے نیچے بیٹھتا ہے، اس لیے ایک گمشدہ حصہ اپنے پیچھے سب کچھ روک دیتا ہے، جبکہ بیرونی رابطہ اپنے شیڈول کے مطابق دوبارہ بھیجتا ہے۔ قطار کے سر کا یہ رویہ TCP کو TCP کے اندر سرنگ بنانے کی خصوصیت ہے، فراہم کنندہ کی پالیسی نہیں۔ MTU اور MSS کی ہینڈلنگ بھی دو طریقوں کے درمیان مختلف ہے، جو اسی راستے پر ٹکڑوں کی تقسیم کا رویہ بدل دیتی ہے۔

اس لیے تیز تر TCP آزمائش صرف یہ ثابت کرتی ہے کہ اس دن اس راستے پر TCP تیز تر تھا، اور اس سے زیادہ عام کچھ نہیں۔

نتیجہ ایسے لکھیں کہ وہ جائزے میں ٹک جائے

قابل دفاع نتیجے کی ایک شکل ہوتی ہے: یہ پروفائل، اس مشین کے سائز پر، اس نیٹ ورک سطح پر، یہ ماپا گیا کام کا بوجھ اس سمت میں ان حالات میں برقرار رکھا۔ اس سے وسیع کسی چیز کے لیے ایک شام کے فراہم کر سکنے سے زیادہ دوڑیں درکار ہیں۔ اگر سست معاملہ غیر واضح رہے تو کسی فراہم کنندہ کی دستاویز میں بیان نہ کی گئی حد ایجاد کرنے کے بجائے پیکٹ اور وسیلے کے ثبوت کے ساتھ اسے مشاہدے کے طور پر رکھیں۔

پتے کا استحکام اور منتقلی کی رفتار دونوں ایک ہی تعیناتی کے لیے اہم ہو سکتے ہیں، اور مفید فیصلہ یہ ہے کہ ہر تبدیلی کے ساتھ آپ ان میں سے کون سی خریدتے ہیں۔