공유 .NET IWebProxy는 동시 요청에서 안전한가?
IWebProxy 구현의 동시성 계약과 자동 프록시 검색으로 인한 지연을 구분합니다.
IWebProxy 는 프록시 정책을 설명합니다. 모든 구현에 동일한 동시성 보장을 제공하지는 않습니다. 작업자 작업 간에 인스턴스 하나를 공유하기 전에 구체적인 구현과 그것이 속한 런타임을 확인하세요.
인터페이스는 대상에 따라 달라지는 경로 쿼리와 자격 증명을 노출합니다. 사용자 지정 구현은 고정 주소, 변경 가능한 상태 또는 자동 구성을 참조할 수 있습니다. 이러한 선택은 안전성과 성능 모두에 영향을 줍니다.
구성 변경을 요청 처리 밖에 두세요
하나의 공유 프록시 개체를 임시 메모로 사용하지 마세요. 작업 B가 경로를 선택하는 동안 작업 A를 위해 주소나 자격 증명을 변경하면 소유권이 불분명해집니다. 클라이언트에 넘기기 전에 정책을 구성하세요. 프록시 계정이나 엔드포인트가 다른 작업에는 별도로 소유된 클라이언트 구성을 사용하세요.
과거 WebProxy 문서는 인스턴스 멤버에 대한 스레드 안전성 보장을 제공하지 않았습니다. 해당 계약을 관련 구현에 적용하세요. 동기화가 필요하면 모든 읽기 측과 쓰기 측이 참여해야 합니다. 래퍼 잠금은 원래 개체를 직접 사용하는 호출자를 조정할 수 없습니다.
GetProxy 의 긴 지연은 대신 검색이나 PAC 평가와 관련될 수 있습니다. Microsoft는 WinHTTP에 대해 차단 검색을 문서화합니다. 이 설명은 클라이언트가 해당 백엔드를 사용할 때 적용됩니다. 경로 조회는 연결 및 응답 시간과 별도로 측정하세요. 느린 조회를 직렬화하면 대기열만 생길 수 있습니다.
고정 엔드포인트는 고정 경로를 의도한 경우 검색을 제거할 수 있습니다. 변경되는 시스템 정책에서 URI 하나를 캡처하면 향후 결정도 버리게 됩니다. 레거시 코드를 유지 관리할 때 이 차이를 보존하세요. 새로운 HTTP 작업에는 HttpClient와 지원되는 처리기 구성을 사용하세요.