Un IWebProxy .NET partagé est-il sûr lors de requêtes simultanées ?
Distinguez le contrat de concurrence d'une implémentation d'IWebProxy des délais causés par la découverte automatique de proxy.
IWebProxy décrit une politique de proxy. Il ne confère pas à chaque implémentation les mêmes garanties de concurrence. Avant de partager une instance entre tâches, identifiez son implémentation concrète et l'environnement d'exécution auquel elle appartient.
L'interface expose des requêtes d'itinéraire dépendant de la destination et des informations d'identification. Une implémentation personnalisée peut consulter une adresse fixe, un état mutable ou une configuration automatique. Ces choix affectent à la fois la sécurité et les performances.
Gardez les changements de configuration hors du traitement des requêtes
Évitez d'utiliser un objet proxy partagé comme brouillon : modifier son adresse ou ses informations d'identification pour la tâche A pendant que la tâche B sélectionne un itinéraire rend la propriété floue. Configurez une politique avant de la remettre au client. Pour les charges de travail ayant différents comptes ou points de terminaison proxy, utilisez des configurations client détenues séparément.
La documentation historique de WebProxy ne garantissait pas la sûreté des threads pour les membres d'instance. Appliquez ce contrat à l'implémentation correspondante. Si une synchronisation est nécessaire, chaque lecteur et chaque rédacteur doivent y participer ; un verrou d'enveloppe ne peut pas coordonner les appelants qui utilisent directement l'objet d'origine.
Une longue pause dans GetProxy peut plutôt concerner la découverte ou l'évaluation PAC. Microsoft documente une découverte bloquante pour WinHTTP ; cette explication s'applique lorsque le client utilise ce moteur. Mesurez la recherche d'itinéraire séparément du temps de connexion et de réponse. Sérialiser une recherche lente ne fait que créer une file d'attente.
Un point de terminaison fixe peut supprimer la découverte lorsqu'un itinéraire fixe est voulu. Capturer un seul URI d'une politique système changeante écarte aussi ses décisions futures. Préservez cette distinction lors de la maintenance de code hérité ; utilisez HttpClient et sa configuration de gestionnaire prise en charge pour les nouveaux travaux HTTP.