HTTPS الدافئ مقابل VPN دافئ: قارن مسار الطلب نفسه

قرأت على الأرجح أن HTTPS يفتح اتصال TCP جديدًا ومصافحة TLS جديدة لكل طلب API، لذا يبدو النفق الذي يبقى مفتوحًا ساعة أرخص. النصف الأول من ذلك غير صحيح عادة. العميل المدعوم يعيد استخدام اتصال قائم لكثير من التبادلات، والقياس الذي يبني عميلًا جديدًا عند كل نداء يقيس دورة الحياة لا الحماية. بقية هذه الصفحة تتناول ما ينبغي قياسه بدلًا من ذلك.

ما تتطلبه إعادة الاستخدام فعلًا

الاستمرارية جزء من نموذج HTTP وليست حيلة: الاتصال الواحد يحمل عدة تبادلات طلب واستجابة. ينتهي الاتصال عندما يغلقه أحد الطرفين، أو عندما يسحب الخادم اتصالًا خاملًا أو محمّلًا زيادة، أو عندما ينص ترويسة أو قاعدة بروتوكول على أن الاتصال لا يمكن إعادة استخدامه. يضع HTTPS تلك المحادثة داخل TLS دون أن يطلب مصافحة جديدة لكل تبادل. لذلك لا يكرر الطلب الثاني مصافحة الطلب الأول إلا إذا أنهى شيء ما الاتصال في أثناء ذلك.

لإعادة الاستخدام شرط واحد تخلفه التطبيقات بسهولة. يجب على العميل الذي ينوي إعادة استخدام الاتصال أن يقرأ جسم الاستجابة كاملًا، والاستجابة المهجورة في منتصفها هي الطريقة المعتادة التي يختفي بها مجمع الاتصالات دون أن يلاحظ أحد.

افحص العميل المدعوم من المكتبة ودورة حياة مجمع الاتصالات بدلًا من افتراض أن التجميع مفعّل أو معطّل. سجّل أيضًا نسخة HTTP المتفاوض عليها، لأن HTTP/2 وHTTP/3 يتعاملان مع إعادة استخدام الاتصالات بشكل مختلف عن HTTP/1.1. اعتبر النسخة المتفاوض عليها جزءًا من القياس لا حاشية.

لماذا يقيس المقارنة دورة الحياة

إنشاء عميل جديد لكل عملية ومقارنته بنفق متصل منذ ساعة يقارن إعداد الاتصال بحالة مستقرة. هذا قياس مشروع، وهو ليس HTTPS مقابل VPN. تشغيلان بالإعداد نفسه للعميل يصفان السلوك أفضل من تشغيل واحد، خصوصًا حين يعمل التشغيل الأول على تسخين محلل أو ذاكرة اتصالات.

أبقِ عملية API والخادم والحساب والبيانات ثابتة، وإلا حملت المقارنة أكثر من متغير واحد. قرر مسبقًا أين تضع المؤقت، لأن الإعداد وتفاوض TLS وتنفيذ التطبيق وتسليم الاستجابة تسهم بدرجات مختلفة في الإجمالي. مؤقت واحد للطلب الأول يصف الإعداد ولا يقول شيئًا عن الحركة المستقرة التي تشغلها فعليًا. اكتب حدود المؤقت إلى جانب الأرقام.

افصل الإعداد البارد عن الطلبات الدافئة

قس الطلب الأول بشكل منفصل عن الطلبات التالية. ثم أضف ما تراه الخدمة فعليًا: فترات الخمول، والدفعات، والتزامن، وحجم الاستجابة، وإعادة الاتصال.

أبقِ التحقق من الشهادات وHTTPS مفعّلين على المسارين، لأن إزالتهما تقيس تصميمًا أمنيًا مختلفًا لا أسرع. إذا غيّر النفق المسار أو موقع البوابة، فأبلغ عن ذلك الفرق بشكل منفصل بدلًا من نسبة كل تغير في التوقيت إلى التشفير، لأن المسار والفقد والانتظار في الصف قد تهيمن على طلب صغير. شغّل كل مسار مرتين عبر المسار نفسه قبل استخلاص نتيجة. سجّل البروتوكول المتفاوض عليه وحدود المؤقت مع التشغيلين.

خطط للاتصال الذي يُغلق

المستمر لا يعني الدائم. قد يغلق خادم أو وسيط أو تغير شبكة اتصالًا خلال فترة خمول، وعلى العميل أن يتعافى عبر السلوك المدعوم من مكتبته. لذلك التعافي آلة حالات: قد يكون الطلب قد اكتمل على الخادم، أو قد يكون فشل قبل أن يقرأه الخادم، والمقبس المغلق لا يخبر المستدعي أي الأمرين حدث. لا يمكن إعادة تشغيل عملية غير متساوية الأثر في ذلك الموضع ببساطة، لأن الإعادة تحول نتيجة غير معروفة إلى كتابة مكررة. هنا يتصرف النفق الدافئ والاتصال الدافئ بالطريقة نفسها، لأن كليهما قد يفشل في اللحظة التي يكون فيها العمل جاريًا.

استخدم آلية إعادة المحاولة أو الآلية المتساوية الأثر الموثقة في الخدمة بدلًا من حلقة تعيد فتح المقبس. اختبر التعافي صراحة بإغلاق اتصال خامل ومراقبة ما يفعله العميل بعد ذلك. إعادة فتح مقبس لا تجعل تكرار نداء يغيّر الحالة آمنًا.

اختر الحدود أولًا ثم اضبط

اختر حدود الشبكة من متطلبات الوصول والثقة قبل تحسين أي شيء. يحمي VPN المقطع بين طرفيه، في حين تظل نقاط نهاية التطبيق وأي مقطع نص صريح خارج النفق مهمة. ثم اضبط دورة حياة الاتصال داخل تلك الحدود. لا يُستنتج أن النفق أرخص إلا من الاعتقاد بأن كل طلب يكرر المصافحة، وهذا الاعتقاد هو ما يُختبر هنا.

قسم الاستمرارية في RFC 9112 هو المرجع لما تعد به إعادة الاستخدام فعلًا، بما في ذلك الشروط التي تنهي الاتصال. اقرأه مرة واحدة قبل أن تثق بقياس يتجاهلها.