Ротація проксі між запитами, з'єднаннями та сеансами
Перевірте, що насправді ротує сервіс ротаційного проксі, перш ніж додавати Connection: close до кожного запиту застосунку.
Другий запит через той самий шлюз цілком законно може використовувати ту саму публічну IP-адресу. Перевірте, який термін життя сервіс використовує для своєї ротації:
| Одиниця ротації | Що порівнювати |
|---|---|
| Запит | Наступна операція застосунку та спостережуваний для неї вихід |
| З'єднання | Чи клієнт повторно використав сумісне з'єднання, чи відкрив інше |
| Сеанс постачальника | Документований вхід для «липкого» сеансу та його термін життя |
Connection: close не є універсальною інструкцією для шлюзу. Для HTTPS усередині CONNECT заголовок запиту до сайту передається всередині TLS пункту призначення. Він не повідомляє зовнішньому проксі, яку публічну IP-адресу призначити. Семантика HTTP/1.1, специфічна для з'єднання, також не може переноситися без змін у кожну версію HTTP чи транспорт.
Якщо документований сервіс на з'єднання потребує нового з'єднання, використовуйте керування життєвим циклом, яке підтримує клієнт, і враховуйте повторні витрати на встановлення TCP/TLS. Якщо ротація йде за сеансом постачальника, повторне підключення може зберегти і цей сеанс, і його вихід.
Записуйте окремо ідентифікатор запиту, кінцеву точку, відповідний ключ сеансу та джерело, спостережуване на боці призначення. Закриття з'єднання підтверджує лише ту подію життєвого циклу; перевіряйте вихід, вибраний для наступної операції, за фактичним контрактом ротації сервісу.