Збереження дескриптора cURL може дозволити подальшим передаванням повторно використовувати сумісні кешовані з'єднання. Але воно не може змусити проксі тримати TCP-з'єднання відкритим нескінченно.

Інша сторона може закрити простоююче з'єднання, мережевий шлях може зникнути, а подальшій передачі може знадобитися інший маршрут або тунель. Повторне використання — це клієнтська оптимізація, що залежить від цих умов, а не гарантія доступності.

Для повторюваної роботи через одну політику проксі підтримуйте відповідний дескриптор або кеш з'єднань multi-handle живим і уникайте опцій, які навмисно запитують нові з'єднання або забороняють повторне використання, якщо тільки завдання їх не потребує. Перевіряйте фактичну поведінку передавання, перш ніж вважати, що коротший другий запит доводить повторне використання.

Остерігайтеся старих прикладів PHP, де сказано, що з'єднання залишається відкритим «до curl_close». PHP документує, що curl_close() не має жодного ефекту з PHP 8.0 і застарів із PHP 8.5. Володіння ресурсами та час життя об'єктів потрібно розуміти у тій версії PHP, яку ви розгортаєте.

Таймер, що надсилає повторні запити, аби тримати проксі «теплим», додає трафік і все одно не може завадити віддаленій стороні закрити з'єднання. Віддавайте перевагу звичайному керуванню з'єднаннями, обмеженим у часі запитам і чітким правилам повторних спроб, а не обіцянці, що одне проксі-з'єднання завжди виживе.

Схожі статті