گرم HTTPS بمقابلہ گرم VPN: وہی درخواست راستہ موازنہ کریں

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

دوبارہ استعمال دراصل کیا مانگتا ہے

استقامت HTTP ماڈل کا حصہ ہے، کوئی حیلہ نہیں: ایک کنکشن کئی درخواست اور جواب کے تبادلے اٹھاتا ہے۔ کنکشن اس وقت ختم ہوتا ہے جب کوئی فریق اسے بند کرے، جب سرور غیر فعال یا زیادہ بوجھ والا کنکشن ہٹا دے، یا جب کوئی ہیڈر یا پروٹوکول قاعدہ کہے کہ کنکشن دوبارہ استعمال نہیں ہو سکتا۔ HTTPS اس گفتگو کو TLS کے اندر رکھتا ہے بغیر یہ مطالبہ کیے کہ ہر تبادلے کے لیے نیا مصافحہ ہو۔ اس لیے دوسری درخواست پہلی درخواست کا مصافحہ نہیں دہراتی، الا یہ کہ درمیان میں کسی چیز نے کنکشن ختم کر دیا ہو۔

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

لائبریری کے معاون کلائنٹ اور کنکشنوں کے تالاب کا زندگی دورانیہ دیکھیں، بجائے یہ فرض کرنے کے کہ پولنگ آن یا آف ہے۔ گفت و شنید شدہ HTTP ورژن بھی لکھیں، کیونکہ HTTP/2 اور HTTP/3 کنکشنوں کے دوبارہ استعمال کو HTTP/1.1 سے مختلف طریقے سے سنبھالتے ہیں۔ گفت و شنید شدہ ورژن کو پیمائش کا حصہ سمجھیں، حاشیہ نہیں۔

موازنہ زندگی کا دورانیہ کیوں ناپتا ہے

ہر عمل کے لیے نیا کلائنٹ بنانا اور اسے ایک گھنٹے سے منسلک سرنگ سے موازنہ کرنا کنکشن کے قیام کو مستحکم حالت سے موازنہ کرنا ہے۔ یہ جائز پیمائش ہے، اور یہ HTTPS بمقابلہ VPN نہیں۔ ایک ہی کلائنٹ ترتیب کے ساتھ دو رنز ایک سے بہتر رویہ بیان کرتے ہیں، خاص طور پر جب پہلا رن کسی حل کنندہ یا کنکشن کیش کو گرم کرتا ہے۔

API عمل، سرور، اکاؤنٹ اور ڈیٹا کو مستقل رکھیں، ورنہ موازنہ ایک سے زیادہ متغیر اٹھاتا ہے۔ پہلے سے طے کریں کہ ٹائمر کہاں رکھیں گے، کیونکہ قیام، TLS گفت و شنید، اطلاقیے کا اجرا اور جواب کی ترسیل کل میں مختلف حصہ ڈالتے ہیں۔ پہلی درخواست کا ایک ٹائمر قیام کی خصوصیت بتاتا ہے اور اس مستحکم ٹریفک کے بارے میں کچھ نہیں کہتا جو آپ واقعی چلاتے ہیں۔ ٹائمر کی حدیں اعداد کے ساتھ لکھیں۔

ٹھنڈا قیام گرم درخواستوں سے الگ کریں

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

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

بند ہونے والے کنکشن کے لیے منصوبہ بنائیں

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

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

پہلے حد چنیں، پھر ترتیب دیں

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

RFC 9112 میں استقامت کا حصہ اس بات کا حوالہ ہے جو دوبارہ استعمال واقعی وعدہ کرتا ہے، بشمول وہ شرطیں جو کنکشن ختم کرتی ہیں۔ انہیں نظر انداز کرنے والی پیمائش پر بھروسہ کرنے سے پہلے اسے ایک بار پڑھیں۔