IWebProxy はプロキシ ポリシーを表します。すべての実装に同じ並行性の保証を与えるわけではありません。ワーカー タスク間で 1 つのインスタンスを共有する前に、その具体的な実装と、それが属するランタイムを特定してください。

このインターフェイスは、宛先に依存するルート クエリと資格情報を公開します。カスタム実装は、固定アドレス、可変状態、または自動構成を参照する場合があります。これらの選択は安全性とパフォーマンスの両方に影響します。

構成の変更を要求処理の外に保つ

1 つの共有プロキシ オブジェクトを下書きとして使わないでください。ジョブ B がルートを選択している間にジョブ A 用にそのアドレスや資格情報を変更すると、所有権が不明確になります。クライアントに渡す前にポリシーを構成してください。異なるプロキシ アカウントやエンドポイントを持つワークロードでは、別々に所有されるクライアント構成を使用します。

従来の WebProxy のドキュメントは、インスタンス メンバーに対するスレッド セーフティの保証を示していませんでした。その契約を対応する実装に適用してください。同期が必要な場合は、すべての読み取り側と書き込み側が参加する必要があります。ラッパー ロックは、元のオブジェクトを直接使う呼び出し元を調整できません。

GetProxy での長い停止は、代わりに検出または PAC 評価に関係している場合があります。Microsoft は WinHTTP のブロックする検出を文書化しています。この説明は、クライアントがそのバックエンドを使う場合に当てはまります。ルート検索は接続時間や応答時間とは別に測定してください。遅い検索を直列化しても、キューができるだけです。

固定エンドポイントは、固定ルートを意図している場合に検出を排除できます。変化するシステム ポリシーから 1 つの URI を取り出すことも、将来の判断を捨ててしまいます。レガシ コードを保守するときはこの区別を保ってください。新しい HTTP 作業には HttpClient とそのサポートされるハンドラー構成を使用してください。

関連記事