Чи безпечний спільний .NET IWebProxy під час одночасних запитів?

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

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

Тримайте зміни конфігурації поза обробкою запитів

Уникайте використання одного спільного об'єкта проксі як чернетки: зміна його адреси або облікових даних для завдання A, поки завдання B вибирає маршрут, робить володіння неясним. Налаштуйте політику перед передачею клієнту. Для навантажень із різними обліковими записами проксі або кінцевими точками використовуйте окремо власні конфігурації клієнта.

Історична документація WebProxy не давала гарантії безпеки потоків для членів екземпляра. Застосуйте цей контракт до відповідної реалізації. Якщо потрібна синхронізація, кожен читач і письменник повинні брати участь; блокування-обгортка не може координувати виклики, що безпосередньо використовують початковий об'єкт.

Довга пауза в GetProxy може натомість стосуватися виявлення або оцінки PAC. Microsoft документує блокувальне виявлення для WinHTTP; це пояснення застосовується, коли клієнт використовує цей бекенд. Вимірюйте пошук маршруту окремо від часу з'єднання та відповіді. Серіалізація повільного пошуку може лише створити чергу.

Фіксована кінцева точка може усунути виявлення, коли передбачено фіксований маршрут. Захоплення одного URI зі змінної системної політики також відкидає її майбутні рішення. Зберігайте цю відмінність під час підтримки старого коду; для нової роботи з HTTP використовуйте HttpClient і підтримувану конфігурацію обробника.