HTTPS گرم در برابر VPN گرم: همان مسیر درخواست را مقایسه کنید

احتمالاً خوانده‌اید که HTTPS برای هر درخواست API یک اتصال TCP تازه و یک دست‌دادن TLS تازه باز می‌کند، بنابراین تونلی که یک ساعت باز می‌ماند ارزان‌تر به نظر می‌رسد. نیمهٔ اول این حرف معمولاً نادرست است. کارخواهِ پشتیبانی‌شده برای بسیاری از تبادل‌ها از اتصال برقرارشده دوباره استفاده می‌کند، و سنجشی که برای هر فراخوانی کارخواه تازه می‌سازد چرخهٔ عمر را می‌سنجد نه محافظت را. باقی این صفحه دربارهٔ چیزی است که به‌جای آن باید سنجید.

آنچه استفادهٔ دوباره واقعاً می‌خواهد

ماندگاری بخشی از مدل HTTP است نه ترفند: یک اتصال چندین تبادل درخواست و پاسخ را حمل می‌کند. اتصال زمانی پایان می‌یابد که یکی از دو طرف آن را ببندد، وقتی سرور اتصالی بی‌کار یا بیش‌ازحد بارگذاری‌شده را کنار بگذارد، یا وقتی سرآیند یا قاعدهٔ پروتکل بگوید که اتصال را نمی‌توان دوباره به کار برد. HTTPS آن گفتگو را درون TLS جای می‌دهد بدون آنکه برای هر تبادل دست‌دادن تازه بخواهد. پس درخواست دوم دست‌دادن درخواست اول را تکرار نمی‌کند مگر آنکه چیزی در این فاصله اتصال را پایان داده باشد.

استفادهٔ دوباره یک شرط هم دارد که برنامه‌ها آسان می‌شکنند. کارخواهی که قصد دارد اتصال را دوباره به کار برد باید کل پیکرهٔ پاسخ را بخواند، و پاسخی که نیمه‌کاره رها شود راه معمول ناپدیدشدن مخزن اتصال‌هاست بی‌آنکه کسی متوجه شود.

کارخواه پشتیبانی‌شدهٔ کتابخانه و چرخهٔ عمر مخزن اتصال‌ها را بررسی کنید، نه آنکه فرض کنید استخرسازی روشن یا خاموش است. نسخهٔ مذاکره‌شدهٔ HTTP را هم ثبت کنید، چون HTTP/2 و HTTP/3 استفادهٔ دوباره از اتصال را متفاوت از HTTP/1.1 مدیریت می‌کنند. نسخهٔ مذاکره‌شده را بخشی از سنجش بدانید نه پانویس.

چرا مقایسه چرخهٔ عمر را می‌سنجد

ساختن کارخواه تازه برای هر عملیات و مقایسهٔ آن با تونلی که یک ساعت متصل بوده، برپاسازی اتصال را با حالت پایدار مقایسه می‌کند. این سنجش مشروعی است و مقایسهٔ HTTPS با VPN نیست. دو اجرا با همان پیکربندی کارخواه رفتار را بهتر از یکی توصیف می‌کنند، به‌ویژه وقتی اجرای نخست یک حل‌کننده یا حافظهٔ اتصال را گرم می‌کند.

عملیات API، سرور، حساب و داده را ثابت نگه دارید، وگرنه مقایسه بیش از یک متغیر را حمل می‌کند. از پیش تصمیم بگیرید زمان‌سنج را کجا می‌گذارید، چون برپاسازی، مذاکرهٔ TLS، اجرای برنامه و تحویل پاسخ سهم متفاوتی در مجموع دارند. یک زمان‌سنج برای درخواست نخست برپاسازی را توصیف می‌کند و دربارهٔ ترافیک پایدارِی که واقعاً اجرا می‌کنید چیزی نمی‌گوید. مرزهای زمان‌سنج را کنار عددها بنویسید.

برپاسازی سرد را از درخواست‌های گرم جدا کنید

درخواست نخست را جدا از درخواست‌های بعدی بسنجید. سپس آنچه را خدمت واقعاً می‌بیند بیفزایید: دوره‌های بی‌کاری، جهش‌ها، هم‌زمانی، اندازهٔ پاسخ و اتصال‌های دوباره.

اعتبارسنجی گواهی و HTTPS را روی هر دو مسیر روشن بگذارید، چون برداشتن آن‌ها طراحی امنیتی متفاوتی را می‌سنجد نه طراحی سریع‌تر. اگر تونل مسیر یا مکان دروازه را تغییر می‌دهد، آن تفاوت را جدا گزارش کنید به‌جای آنکه هر تغییر زمانی را به رمزنگاری نسبت دهید، چون مسیر، افت و صف می‌توانند بر یک درخواست کوچک چیره شوند. پیش از نتیجه‌گیری هر مسیر را دو بار روی همان مسیر اجرا کنید. پروتکل مذاکره‌شده و مرزهای زمان‌سنج را همراه با هر دو اجرا ثبت کنید.

برای اتصالِ بسته‌شده برنامه داشته باشید

پایدار به معنای همیشگی نیست. سرور، واسط یا تغییری در شبکه می‌تواند اتصال را در دورهٔ بی‌کاری ببندد، و کارخواه باید با رفتار پشتیبانی‌شدهٔ کتابخانهٔ خود بازیابی کند. آن بازیابی یک ماشین حالت دارد: ممکن است درخواست روی سرور کامل شده باشد یا پیش از خواندنِ سرور شکست خورده باشد، و سوکت بسته به فراخواننده نمی‌گوید کدام رخ داده است. عملیات غیرخودتوان در آن جایگاه را نمی‌توان ساده دوباره پخش کرد، چون پخش دوباره نتیجهٔ نامعلوم را به نوشتن تکراری تبدیل می‌کند. اینجا تونل گرم و اتصال گرم یکسان رفتار می‌کنند، چون هر دو می‌توانند در لحظه‌ای که کار در جریان است شکست بخورند.

از سازوکار مستندِ تلاش دوباره یا خودتوانیِ خدمت استفاده کنید نه حلقه‌ای که سوکت را دوباره باز می‌کند. بازیابی را آشکارا بیازمایید: اتصال بی‌کار را ببندید و ببینید کارخواه سپس چه می‌کند. بازکردن دوبارهٔ سوکت تکرار یک فراخوانی تغییردهندهٔ حالت را ایمن نمی‌کند.

نخست مرز را برگزینید، سپس تنظیم کنید

مرز شبکه را از الزام‌های دسترسی و اعتماد انتخاب کنید پیش از آنکه چیزی را بهینه کنید. VPN قطعهٔ میان همتایان خود را محافظت می‌کند، در حالی که نقطه‌های پایانی برنامه و هر قطعهٔ متن روشن بیرون تونل همچنان مهم‌اند. سپس چرخهٔ عمر اتصال را درون آن مرز تنظیم کنید. نتیجهٔ ارزان‌تر بودن تونل تنها از این باور برمی‌آید که هر درخواست دست‌دادن را تکرار می‌کند، و همین باور است که اینجا آزموده می‌شود.

بخش ماندگاری در RFC 9112 مرجع آن چیزی است که استفادهٔ دوباره واقعاً وعده می‌دهد، از جمله شرط‌هایی که اتصال را پایان می‌دهند. یک بار آن را بخوانید پیش از آنکه به سنجشی که آن‌ها را نادیده می‌گیرد اعتماد کنید.