قد يسمح الاحتفاظ بمقبض cURL للعمليات اللاحقة بإعادة استخدام اتصالات مخزنة مؤهلة. لكنه لا يستطيع أن يجعل البروكسي يبقي اتصال TCP مفتوحًا إلى ما لا نهاية.

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

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

احذر من أمثلة PHP القديمة التي تقول إن الاتصال يبقى مفتوحًا "حتى curl_close". توثّق PHP أن curl_close() لا أثر له منذ PHP 8.0 وأنه مهجور اعتبارًا من PHP 8.5. يجب فهم ملكية الموارد وعمر الكائنات في إصدار PHP الذي تنشره.

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

مقالات ذات صلة