Runtime: Singleton HttpClient는 DNS 변경 사항을 존중하지 않습니다.

기본값은 60초이며 원하는 대로 수동으로 설정할 수 있습니다. https://github.com/dotnet/corefx/blob/d0dc5fc099946adc1035b34a8b1f6042eddb0c75/src/System.Net.Http.WinHttpHandler/src/System/Net/Http/WinHttpHandler.cs#L76

같은 속성이 아닌가 싶습니다. 이것은 ConnectionLeaseTimeout이 아니라 연결 시간 초과입니다.

https://msdn.microsoft.com/en-us/library/system.net.servicepoint.connectionleasetimeout.aspx 에 설명된 대로 일부 시나리오에서는 주기적으로 삭제해야 합니다. 그러나 .NET Core에서 동작을 변경할 수 있는 분명한 방법은 없습니다.

@onovotny 예, 명시적 연결을 수행하는 것처럼 보이는 이상한 일입니다. 특정 시간 프레임 후에 닫습니다 . 정말 원한다면 미들웨어로 구현하지 못할 이유가 없습니다. 그것은 단지 HTTP 헤더입니다.

@darrelmiller 그래서 제 영역을 벗어나고 있습니다. 확실하지 않지만... 원래 문제를 해결하는 문서화된 해결 방법이 있다면 큰 이점이 될 것입니다.

@onovotny , .NET Core에는 ServicePointManager 클래스가 없습니다. 이것은 .NET Framework(데스크탑) 문제처럼 들립니다. UserVoice 또는 Connect에서 문제를 여십시오.

@onovotny 내가 이해하는 원래 문제는 서버 측에서 누군가가 DNS 항목을 업데이트하여 호스트 A에 대한 모든 향후 요청이 새 IP 주소로 이동하기를 원한다는 것입니다. 내 생각에 가장 좋은 해결책은 DNS 항목이 변경될 때 호스트 A의 응용 프로그램이 향후 모든 응답에서 클라이언트에 C 연결 : 닫기 헤더를 반환하도록 지시해야 한다는 것입니다. 그러면 모든 클라이언트가 연결을 끊고 새 연결을 설정해야 합니다. 솔루션은 클라이언트에서 시간 초과 값을 갖지 않도록 하여 해당 "임대" 시간 초과가 만료될 때 클라이언트가 연결 : 닫기를 전송합니다.

이것은 사용자 지정 DNS 해석기를 사용하여 DNS 장애 조치를 테스트 하는 Stackoverflow

이것은 절대적으로 문제입니다. @darrelmiller가 제안한 솔루션은 사용 사례에 대한 이해가 부족한 것으로 보입니다.

Azure Traffic Manager를 사용하여 인스턴스의 상태를 평가합니다. 짧은 TTL로 DNS 위에서 작동합니다. 호스트는 자신이 비정상적이라는 것을 마술처럼 알지 못하고 C 연결 : 닫기 헤더를 발행하기 시작합니다. 트래픽 관리자는 비정상 상태를 감지하고 그에 따라 DNS 확인을 조정합니다. 설계상 이것은 클라이언트와 호스트에 완전히 투명합니다... 그대로 트래픽 관리자가 DNS를 확인하는 정적 HttpClient(무의식적으로)가 있는 응용 프로그램은 이전에 확인된 호스트가 비정상 상태가 될 때 새 호스트를 수신하지 않습니다.

netcore 1.1 현재 이 정확한 문제에 대한 해결책을 찾고 있습니다. 어쨌든 나는 타고난 것을 보지 못한다.

@kudoz83 맞습니다. 호스트는 트래픽 관리자가 DNS 확인을 조정한 때를 마술처럼 알지 못합니다. 따라서 내가 말한 이유는

해당 DNS 항목이 변경되면 호스트 A의 응용 프로그램에 알려야 합니다.

연결 : 닫기 헤더를 반환해야 한다고 원본 서버에 알리는 것이 실용적이지 않다고 생각되면 몇 가지 선택만 남게 됩니다.

• 주기적으로 클라이언트 또는 미들웨어와의 연결을 닫고 해당 연결을 다시 여는 비용을 중복 지불합니다.
• 클라이언트가 서비스를 폴링하여 연결을 재설정해야 하는 시기를 알도록 합니다.
• DNS가 언제 전환되었는지 알 수 있을 만큼 똑똑한 미들웨어를 사용하십시오.

그리고 나에 관해서는 유스 케이스를 이해하지 못한다. 원래 문제는 사용 사례가 프로덕션 및 스테이징 슬롯 간 전환과 관련되고 상태 모니터링과 아무 관련이 없는 블로그 게시물을 기반으로 했습니다. 두 시나리오 모두 DNS/슬롯 스위치 알림을 받을 수 있다는 이점이 있습니다.

AFAIK 실패한 호스트에 실패했음을 알리는 방법이 없습니까? 일반적으로 이것은 일종의 오류 상태에 있음을 의미합니다. 원래 게시물은 장애 조치 시나리오에 대해 이야기하고 있습니다.

Azure Traffic Manager는 https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-monitoring에 설명되어 있습니다.

DNS 수준에서 작동하며 클라이언트와 호스트에 투명합니다. DNS 확인을 위해 Traffic Manager를 통해 서로 통신하는 Azure 인스턴스는 HttpClient에 대한 DNS 새로 고침에서 TTL을 설정할 수 없는 상태에서 피클 상태입니다.

HttpClient가 현재 작동하는 방식은 Microsoft의 자체 Azure 서비스 제공과 모순되는 것으로 보입니다. 이것이 요점입니다. 말할 것도 없이, 유사한 서비스(예: Amazon Route 53)는 정확히 동일한 방식으로 작동하며 정확히 동일한 짧은 DNS TTL 종속성을 갖습니다.

분명히 이 문제의 영향을 받았기 때문에 이 스레드를 찾았습니다. 나는 단순히 DNS 장애 조치(failover)가 성공하도록 하기 위해 (성능과 복잡성을 희생하면서) HttpClients를 임의로 다시 만드는 것 외에는 현재로서는 이상적인 해결 방법이 없는 것으로 보입니다.

AFAIK 실패한 호스트에 실패했음을 알리는 방법이 없습니까?

"실패한" 호스트가 코드를 실행할 수 없는 경우 원본 서버가 이를 반환할 수 없기 때문에 HTTP 상태 코드 503이 필요하지 않습니다. 실패한 호스트가 알림을 처리할 수 없는 시나리오가 있지만 이러한 경우에는 활성 TCP/IP 연결을 오랫동안 열어 두지 않을 수도 있습니다.

Ali가 블로그 게시물을 작성하기 전에 원래 Twitter에서 이 주제를 제기했을 때 그는 클라이언트가 계속해서 요청하고 교체된 서버에서 응답을 받을 것이라는 사실에 동의했습니다.

귀하의 상황이 다르며 연결을 안정적으로 닫을 수 있는 원본 서버에 의존할 수 없다는 것을 이해합니다. 내가 이해하지 못하는 것은 귀하의 상황에 대해 HttpMessageHandler를 사용하여 5XX 응답을 감지하고 연결을 닫고 요청을 다시 시도할 수 없는 이유입니다. 또는 더 간단하게 웹 서버가 5XX 상태 코드를 반환할 때마다 연결 : 닫기 를 반환하도록 유도하면 됩니다.

관심 있는 동작이 HttpClient에 없다는 점도 주목할 가치가 있습니다. 기본 HttpHandler 또는 그 아래에 있으며 사용 중인 HttpHandler의 다양한 구현이 있습니다. 제 생각에는 현재 동작이 HTTP가 작동하도록 설계된 방식과 일치합니다. 연결이 열려 있는 동안 DNS 설정이 업데이트될 때 문제가 있다는 데 동의하지만 이것은 .net 문제가 아닙니다. 이것은 HTTP 아키텍처 문제입니다. 그렇다고 해서 .net이 문제를 덜 수 있도록 할 수 있는 것은 아닙니다.

해결책이 무엇이라고 생각하시는지 궁금합니다. 장애 조치 여부에 관계없이 주기적으로 연결을 끊는 ConnectionLeaseTimeout과 같은 것을 다시 구현해야 한다고 생각하십니까? 아니면 더 나은 솔루션이 있습니까?

죄송합니다,

나는 어제 말했던 것처럼 전투적으로 나오지 말았어야 했다. 나쁜 하루를 보내고 있었다.

솔직히 ConnectionLeaseTimeout이 덮개 아래에서 어떻게 작동하는지 모르겠습니다. 원하는 기능은 클라이언트가 삭제될 때까지 이전 DNS 조회를 캐싱하는 것과는 대조적으로 새 연결을 설정하기 전에 새 DNS 조회를 수행하도록 HttpClient를 구성하는 것입니다. 나는 이것이 기존 연결을 죽여야한다고 생각하지 않습니다 ...

@kudoz83 걱정마 우리 모두 그런 날이 있어 :-)

내가 이해한 바에 따르면 ConnectionLeaseTimeout은 말 그대로 클라이언트 측에서 유휴 연결을 주기적으로 닫는 타이머입니다. 코어에 존재하지 않는 ServicePointManager에서 구현됩니다. 이것은 일정 시간 동안 사용하지 않으면 연결을 닫는 "유휴 연결" 시간 초과와 다릅니다.

DNS 클라이언트 캐시 플러시를 허용하는 Win32 호출이 있을 수 있습니다. 그러면 새 연결이 DNS 조회를 수행할 수 있습니다. 급하게 찾아봤는데 못찾았는데 분명 어딘가에 있을거에요.

Windows의 .net core에서 HTTP 연결 관리는 실제로 OS에 맡겨집니다. 가장 가까운 것은 Win32 API WinHttpOpen https://github.com/dotnet/corefx/blob/master/src/System.Net.Http.WinHttpHandler/src/System/Net/Http/WinHttpHandler.cs#에 대한 호출입니다.

DNS 항목에 매우 낮은 TTL을 설정하기 위해 Azure Traffic Manager를 얻는 것이 더 쉽지 않을까요? 오래 지속되는 연결에 대해 걱정하지 않는다면 낮은 TTL은 죽은 서버에 대해 새로운 연결이 설정될 가능성을 최소화해야 합니다.

WinHttpHandler가 구축되는 방식의 장점은 OS 업데이트로 HTTP/2와 같은 것을 무료로 얻을 수 있다는 것입니다. 단점은 관리 코드에서 많은 제어 권한을 얻지 못한다는 것입니다.

@darrelmiller

[ConnectionLeaseTimeout]은 Core에 존재하지 않는 ServicePointManager에서 구현됩니다.

ServicePoint.ConnectionLeaseTimeout 가 .Net Standard 2.0/.Net Core 1.2에서 다시 나오는 것 같습니다. (예를 들어 WinHttpHandler 연결이 이를 준수할지 여부는 알 수 없습니다.)

여기에 약간의 오해가 있다고 생각합니다. DNS TTL은 HTTP/TCP 연결 수명과 완전히 관련이 없습니다.

새 HTTP 연결은 DNS 조회를 수행하고 반환된 호스트 주소에 연결합니다. 동일한 단일 연결을 통해 여러 HTTP 요청을 수행할 수 있지만 일단 HTTP 연결(및 기본 TCP 연결)이 열리면 DNS 조회를 다시 수행하지 않습니다.

이것은 올바른 동작이므로 며칠 동안 지속되는 연결을 통해 1000번의 요청을 하더라도 연결이 변경되지 않았기 때문에 DNS 확인은 문제가 되지 않습니다. 새 HTTP 연결 을 을 하면 새 연결에 대한 DNS 조회가 표시됩니다.

이 DNS 새로 고침은 HttpClient 와 아무 관련이 없으며 기본적으로 HttpClientHandler 사용하고(자체적으로 HttpWebRequest 소켓 스택을 사용함) 모든 DNS 확인은 해당 스택에서 처리됩니다. ServicePointManager 는 특정 호스트에 대한 연결인 해당 스택의 ServicePoint 개체를 관리합니다. ServicePointManager 에는 조정할 수 있는 DNS 조회의 최소 클라이언트 측 캐싱이 있습니다.

기본 설정은 효율성을 위해 연결이 무기한 열려 있도록 하기 위한 것입니다. 연결된 호스트를 사용할 수 없게 되면 연결이 자동으로 끊어져 새 DNS 조회로 새 연결이 발생하지만 DNS TTL은 새 연결을 발생시키지 않습니다. 필요한 경우 앱에 코딩해야 합니다.

다른 DNS 조회를 수행하려면 클라이언트에서 연결을 재설정해야 합니다. TCP 연결의 최대 수명을 강제하거나 connection: close 헤더를 보내거나 HttpClient 또는 기본 ServicePoint 삭제할 수 있습니다. Dns.GetHostAddresses DNS 확인을 수행하고 HTTP 요청 대신 IP 주소를 사용할 수도 있습니다.

도움이 되기를 바랍니다. 이 작업이 중단되면 알려주세요.

@매니건담

여기에 약간의 오해가 있다고 생각합니다. DNS TTL은 HTTP/TCP 연결 수명과 완전히 관련이 없습니다.

예, DNS TTL은 상당히 관련이 없지만 완전히는 아닙니다.

새 HTTP 연결은 DNS 조회를 수행하고 반환된 호스트 주소에 연결합니다.

네, 맞습니다. 그러나 Windows에는 TTL을 존중하는 로컬 DNS 캐시가 있습니다. TTL이 높고 DNS 서버가 DNS 레코드를 변경한 경우 DNS 레코드의 클라이언트 캐싱으로 인해 이전 IP 주소에 대해 새 연결이 열립니다. 내가 알고 있는 유일한 해결 방법은 클라이언트 DNS 캐시를 플러시하는 것입니다.

동일한 단일 연결을 통해 여러 HTTP 요청을 수행할 수 있지만 일단 HTTP 연결(및 기본 TCP 연결)이 열리면 DNS 조회를 다시 수행하지 않습니다.

다시 수정합니다. 교체된 서버가 여전히 응답하는 프로덕션/스테이징 스왑에서 이로 인해 많은 향후 요청이 이전 서버로 이동하게 되며 이는 좋지 않습니다. 그러나 가장 최근의 대화는 서버에 장애가 발생하고 Traffic Manager가 새 서버로 교체되는 시나리오에 대한 것입니다. 실패한 서버에 대한 기존 연결에 어떤 일이 발생하는지 알 수 없습니다. 심각한 하드웨어 오류인 경우 연결이 끊어질 가능성이 높습니다. 그러면 클라이언트가 연결을 다시 설정해야 하므로 낮은 TTL이 유용합니다. 그러나 서버 오류가 서버를 손상시키지 않고 단순히 5XX 응답을 반환하는 경우 서버가 연결 : 닫기 를 반환하여 향후 요청이 새 연결에서 이루어지도록 하는 것이 유용할 것입니다

이 DNS 새로 고침은 기본적으로 HttpClientHandler를 사용하는 HttpClient와 아무 관련이 없습니다(자체적으로 HttpWebRequest 소켓 스택을 사용함).

예 및 아니오. .Net 코어에서 HttpClientHandler가 다시 작성되었으며 더 이상 HttpWebRequest를 사용하지 않으므로 ServicePointManager를 사용하지 않습니다. 따라서이 문제의 이유.

IIS를 자세히 살펴보았고 연결 : 닫기 헤더와 함께 제공되는 5XX 응답을 얻을 수 있는 방법이 없는 것

참고로 이 문제와 임시 솔루션을 다루는 관련 게시물이 있습니다. HttpClient를 조심하십시오

ServicePointManager 중 하나를 .NET Core로 가져와야 합니다.

플랫폼 패리티를 위해 ServicePointManager 및 HttpWebRequest를 가져왔지만 기본 스택이 고급 제어 노브를 노출하지 않는 WinHTTP 또는 Curl로 해석되기 때문에 .Net Core의 대부분의 기능을 지원하지 않습니다.

ServicePointManager를 사용하여 HttpClient를 제어하는 ​​것은 실제로 .Net Framework에서 HttpWebRequest 및 관리되는 HTTP 스택을 사용할 때의 부작용입니다. WinHttpHandler/CurlHandler는 .Net Core에서 사용되기 때문에 SPM은 HttpClient 인스턴스를 제어할 수 없습니다.

또는 이와 유사한 기능은 다른 방법으로 활성화해야 합니다.

다음은 WinHTTP 팀의 답변입니다.

1. 보안상의 이유로 클라이언트가 계속 요청을 보내고 _활성 연결이 있는_ 동안 WinHTTP는 계속 대상 IP를 사용합니다. 이러한 연결이 활성 상태로 유지되는 시간을 제한할 수 있는 방법은 없습니다.
2. 원격 끝점에 대한 모든 연결이 서버에 의해 닫히면 _new_ 연결이 DNS를 쿼리하여 새 IP를 향해 만들어집니다.

클라이언트를 다음 IP로 강제 실행하기 위해 실행 가능한 유일한 솔루션은 서버가 새 연결을 거부하고 기존 연결을 닫도록 하는 것입니다(이 스레드에서 이미 언급됨).
이것은 내가 ATM 문서 에서 이해한 것과 동일

자체적으로 DNS를 캐싱하는 다른 네트워크 어플라이언스 장치(예: 홈 라우터/AP)를 고려할 때 낮은 대기 시간, 고가용성 기술을 위한 솔루션으로 DNS 장애 조치를 권장하지 않습니다. 필요한 경우 제어된 장애 조치에 대한 권장 사항은 적절하게 배수 중지하는 방법을 알고 있는 전용 LB(하드웨어 또는 소프트웨어)를 사용하는 것입니다.

그대로, 트래픽 관리자에 의해 (무의식적으로) DNS를 확인하는 정적 HttpClient가 있는 애플리케이션은 이전에 확인된 호스트가 비정상 상태가 될 때 새 호스트를 수신하지 않습니다.

위에서 언급했듯이 비정상이란 DNS TTL이 만료된 것을 관찰하는 동안 서버가 HTTP 오류 코드를 반환하고 TCP 연결을 닫는 것을 의미한다면 이것은 실제로 버그입니다.

시나리오를 더 자세히 설명하십시오.

1. 장애 조치 중 클라이언트 시스템의 DNS 캐시 및 TTL은 무엇입니까? ipconfig /showdns 및 nslookup -type=soa <domain_name> 를 사용하여 기계가 생각하는 TTL과 신뢰할 수 있는 NS의 TTL을 비교할 수 있습니다.
2. 원격 서버에 대한 활성 연결이 있습니까? netstat /a /n /b 를 사용하여 연결 및 이를 소유하는 프로세스를 볼 수 있습니다.
3. 재현을 생성하면 많은 도움이 됩니다. .Net Core/Framework 버전, 클라이언트/서버용 코드, 네트워크 추적, 원격 DNS LB/트래픽 관리자 관련 등과 같은 사용 가능한 정보를 첨부하십시오.

컴퓨터에 연결하고 TCP/HTTP 연결이 계속 작동한다면 왜 어느 시점에서 서버가 더 이상 적절하지 않다고 가정해야 합니다.
Azure 측면에서 개선의 여지가 있다고 생각합니다. 예를 들어 시스템이 비정상적이거나 환경을 스와핑하는 경우 기존 연결을 닫을 수 있습니다.

또는 그냥 ... 기본 ServicePoint 처분하십시오.

@manigandham 어떻게? 그것은 일회용이 아니며 내가 볼 수있는 유일한 관련 방법은 그룹 이름이 구현 세부 사항 (현재 처리기의 일부 해시)이므로 실제로 사용할 수없는 CloseConnectionGroup 입니다. 또한 HttpClient 에서 ServicePoint를 사용하는 동안(특히 동시에) ServicePoint를 폐기하려고 하면 어떻게 될지 잘 모르겠습니다.

@ohadschn

.NET Core 2.0은 ServicePoint 클래스 및 기능을 다시 제공합니다. https://docs.microsoft.com/en-us/dotnet/api/system.net.servicepoint?view=netcore-2.0

연결 임대 시간 초과를 사용하여 재설정하기 전에 활성 연결에 대한 최대 시간 프레임을 설정할 수 있습니다.

HttpClient 요청이 진행되는 동안 연결을 닫는 것과 관련하여 이상한 점은 없으며 인터넷을 탐색할 때 연결이 끊어지는 것과 같습니다. 요청이 절대 이루어지지 않거나 요청이 이루어지고 응답을 받지 못합니다. 둘 다 http 오류가 반환되어야 하며 애플리케이션에서 이를 처리해야 합니다.

연결 임대 시간 초과 설정을 사용하면 요청이 전송된 후에만 이 작업을 수행하고 시간 제한을 초과하는 다음 요청 전에 재설정하도록 할 수 있습니다.

.NET Core 2.0은 ServicePoint 클래스 및 기능을 다시 제공합니다. https://docs.microsoft.com/en-us/dotnet/api/system.net.servicepoint?view=netcore-2.0
연결 임대 시간 초과를 사용하여 재설정하기 전에 활성 연결에 대한 최대 시간 프레임을 설정할 수 있습니다.

사실, 그것은 기능을 완전히 되돌려주지 않습니다. API 표면이 돌아왔습니다. 그러나 HTTP 스택이 해당 개체 모델을 사용하지 않기 때문에 기본적으로 작동하지 않습니다.

참조: @stephentoub @geoffkizer

이 스레드의 많은 참가자가 이 주제에 대해 "드림 팀"의 일부라고 생각하지만, 오늘날 우리가 가지고 있는 모범 사례에 대해 합의에 도달했는지 여부는 여전히 확실하지 않습니다. 몇 가지 핵심 사항에 대해 이 그룹에서 결정적인 답변을 얻는 것이 좋습니다.

모든 플랫폼이 ServicePointManager 를 지원하지 않는 많은 플랫폼을 대상으로 하는 범용 HTTP 라이브러리가 있고 기본적으로 모범 사례에 따라 HttpClient 인스턴스를 현명하게 관리하는 동작을 제공하려고 한다고 가정해 보겠습니다. DNS 변경/연결 :닫기 헤더와 관련하여 제대로 작동하는지 여부는 고사하고 어떤 호스트가 호출될지 미리 알 수 없습니다.

1. HttpClient 인스턴스를 최적으로 관리하려면 어떻게 해야 합니까? 엔드포인트당 하나? 호스트/스키마/포트당 하나? 말 그대로 총 하나의 싱글톤? (소비자가 기본 헤더 등을 활용하기를 원할 수도 있기 때문에 의심스럽습니다.)

2. 이 DNS 문제를 가장 효과적으로 처리하려면 어떻게 해야 합니까? 1분 후에 인스턴스를 폐기하시겠습니까? "매우 가능성이 낮은" 것으로 취급하고 기본적으로 폐기 동작을 제공하지 않습니까?

(가상의 상황이 아닙니다. 저는 지금 이러한 정확한 질문과 씨름하고 있습니다.)

감사 해요!

나는 드림팀 시험에 초대되지도 않았지만, 당신의 싱글톤 HttpClient 코멘트에 대해 한 가지 통찰력이 있습니다. 첫째, 항상 SendAsync 메소드를 사용하여 다른 헤더와 주소를 지정할 수 있으므로 HttpClient (예: 기본 헤더, 기본 주소)와 유사한 공유 데이터를 제공하는 클래스로 이를 래핑할 수 있습니다. 결국 동일한 단일 클라이언트를 호출합니다. 그러나 더 좋은 점은 모두 동일한 HttpClientHandler 공유하는 여러 HttpClient 인스턴스를 만들 수 있다는 것입니다. https://github.com/dotnet/corefx/issues/5811.

DNS 문제에 대한 합의는 다음과 같습니다.

클라이언트를 다음 IP로 강제 실행하기 위해 실행 가능한 유일한 솔루션은 서버가 새 연결을 거부하고 기존 연결을 닫도록 하는 것입니다.

이것이 실행 가능하지 않은 경우 Darrel Miller는 https://github.com/dotnet/corefx/issues/11224#issuecomment -270498159에서 몇 가지 추가 옵션을 제안했습니다.

@ohadschn 감사합니다. 주제에서 벗어나지 않기를 바랍니다. 하지만 여러 호스트 간에 동일한 HttpClient(또는 HttpClientHandler)를 공유하는 데 _이점_이 있습니까? 내가 틀릴 수 있지만 새 호스트는 새 DNS 조회, 새 연결, 새 소켓을 의미하는 것 같습니다. TIME_WAIT의 소켓을 회수하고 다른 호스트에 사용할 수 있습니까? 나는 그렇지 않다고 생각했지만 우리는 확실히 내 전문 지식의 한계에 도달하고 있습니다. 가능하다면 여러 호스트에서 HttpClient 싱글톤을 사용하는 이점이 아닐까요?

DNS 조언과 관련하여 나는 그것이 가장 합의가 부족한 부분이라고 느꼈고 이해할 만합니다. 서버에서 일어나는 일을 제어할 수 없다면 서버가 올바르게 작동하는지 확인하는 것은 불가능합니다. 나는 인스턴스가 주기적으로 폐기되는 것을 _할 수 있습니다_. 문제는 이것이 대부분의 경우 절충할 가치가 있는지 여부입니다. 판단을 내리는 것은 전적으로 나에게 달려있다고 생각한다. :)

동일한 HttpClient [ Handler ] 공유의 가장 확실한 이점은 단순함입니다. 호스트와 클라이언트 간의 매핑과 같은 것을 유지할 필요가 없습니다. 나는 TIME_WAIT에 대해 잘 알지 못하며 내 전문 지식도 아닙니다.

DNS와 관련하여 서버를 제어하지 않을 때 가능한 한 가지 접근 방식을 언급했습니다. DNS를 주기적으로 쿼리하고 실제 변경이 발생한 경우에만 인스턴스를 폐기하는 메커니즘을 구현할 수도 있습니다.

서버 측에서 발생해야 하는 일을 지정하는 주어진 답변은 이상적인 세계에서는 정확하지만 실제 개발자는 종종 통신하는 전체 서버 측 스택을 제어할 수 없습니다. 그런 점에서 저는 ConnectionLeaseTimeout이라는 개념을 정말 좋아합니다. John과 Jane Doeveloper의 일상 생활 현실에 대한 양보이기 때문입니다.
누군가가 .NET Core에서 이러한 시간 제한을 적용하기 위해 미들웨어를 작성할 것을 제안했습니다. NodaTime 및 System.Collections.Immutable을 기반으로 하는 이 클래스가 작업을 수행합니까?

    public class ConnectionLeaseTimeoutHandler : DelegatingHandler
    {
        private static string GetConnectionKey(Uri requestUri) => $"{requestUri.Scheme}://{requestUri.Host}:{requestUri.Port}";

        private readonly IClock clock;
        private readonly Duration leaseTimeout;
        private ImmutableDictionary<string, Instant> connectionLeases = ImmutableDictionary<string, Instant>.Empty;

        public ConnectionLeaseTimeoutHandler(HttpMessageHandler innerHandler, IClock clock, Duration leaseTimeout)
            : base(innerHandler)
        {
            this.clock = clock;
            this.leaseTimeout = leaseTimeout;
        }

        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            string key = GetConnectionKey(request.RequestUri);
            Instant now = clock.GetCurrentInstant();

            Instant leaseStart = ImmutableInterlocked.GetOrAdd(ref connectionLeases, key, now);

            if (now - leaseStart > leaseTimeout)
            {
                request.Headers.ConnectionClose = true;
                ImmutableInterlocked.TryRemove(ref connectionLeases, key, out leaseStart);
            }

            return base.SendAsync(request, cancellationToken);
        }
    }

@snboisen 제 생각에는 그게 맞는 것

나에게 더 큰 질문은 Connection: close 헤더를 보내는 것이 실행 가능한 솔루션인지 여부입니다. @darrelmiller 가 이 스레드를 촉발한 블로그 게시물의 댓글 에서 말한 것을 여기서 반복할 가치가 있습니다.

ConnectionLeaseTimeout은 오늘 Oren이 언급할 때까지 내가 알지 못했던 이상한 짐승입니다. 임대가 만료된 후 나가는 요청에 C onnection:Close 헤더가 포함되어 서버가 응답을 보낸 후 연결이 종료됩니다. 클라이언트가 적극적으로 요청을 할 때 강제로 연결을 닫는 이상한 방법이기 때문에 이것이 기본값으로 무한대로 설정되어 있는 이유는 이해가 됩니다.

나는 Darrel의 의견을 존중하며 이 전체 접근 방식이 다소 해커처럼 보입니다. 반면에 서버 측에서 일어나는 일을 제어할 수 없는 개발자가 해야 할 일은 무엇입니까? 그것이 _때때로_ 작동한다면 우리가 가진 최선의 선택이 아닐까요? 주기적으로 HttpClient를 폐기하거나 주기적으로 DSN 조회를 수행하는 것보다 확실히 "저렴"합니다.

이 문제에 대해 Azure 티켓이 열려 있습니까?
내 관점에서 보면 Azure의 트래픽 관리자에서 이것이 구현되는 방식을 해결하려고 하는 것 같습니다.
저는 Azure 사용자가 아니므로 멀리서 바라보고 있습니다.

@tmds 나는 본 적이 없지만 다른 사람들이 언급했듯이 이것은 단순한 Azure Traffic Manager 이상과 관련이 있습니다. AWS는 유사한 개념을 가지고 있으며 스테이징/프로덕션 슬롯 스와핑이 있는 Azure App Service가 있습니다. 그리고 다른 클라우드 제공업체도 이 스와핑 메커니즘과 유사한 것을 제공할 것입니다.

@snboisen AWS 및 기타 클라우드 제공업체(어느 쪽?)도 이러한 기능을 구현하기 위해 DNS 시간 초과를 사용하고 있다는 말씀이신가요?

@tmds AWS의 경우 예, 최소한 장애 조치의 경우: https://aws.amazon.com/route53/faqs/#adjust_ttl_to_use_failover
다른 클라우드 제공업체에 대해서는 모르지만 일부 클라우드 제공업체도 마찬가지일 것 같습니다.

@tmds AWS의 경우 예, 최소한 장애 조치의 경우: https://aws.amazon.com/route53/faqs/#adjust_ttl_to_use_failover
다른 클라우드 제공업체에 대해서는 모르지만 일부 클라우드 제공업체도 마찬가지일 것 같습니다.

여기에는 두 가지 문제가 있는 시나리오가 있습니다.

• 클라이언트가 더 이상 존재하지 않는 서버에 연결되었습니다.
• 클라이언트가 현재 오래된 버전의 소프트웨어를 실행 중인 서버에 연결되어 있습니다.

DNS 장애 조치는 첫 번째와 관련이 있습니다. DNS(AWS, Azure 등)에서 연결할 수 없는 서버를 제거하는 것이 적절합니다.
클라이언트에서 이를 감지하는 적절한 방법은 시간 초과 메커니즘입니다. HttpClient에 그러한 속성이 있는지 확실하지 않습니다(설정된 연결에서 최대 응답 시간 초과).
프로토콜 수준에서 최신 websocket 및 http2 프로토콜은 연결 활성을 확인하기 위해 ping/pong 메시지를 정의합니다.

Azure에 문제를 제기할 것을 제안하는 것은 두 번째 시나리오를 위한 것입니다.
클라이언트가 작동 중인 연결을 닫아야 할 이유가 없습니다. 서버가 더 이상 적합하지 않으면 클라이언트의 연결을 끊고 서버에 연결할 수 없도록 설정해야 합니다.
AWS Blue/Green 배포에 대한 좋은 문서를 찾았습니다. https://d0.awsstatic.com/whitepapers/AWS_Blue_Green_Deployments.pdf.
여러 기술을 나열합니다. DNS를 사용하는 사람들의 경우 _DNS TTL 복잡성_을 언급합니다. 로드 밸런서를 사용하는 경우 _DNS 복잡성 없음_.

@tmds 링크 주셔서 감사합니다. 매우 흥미롭습니다.

DNS TTL에 의존하는 것과 로드 밸런서를 사용하는 것이 얼마나 일반적인지 궁금합니다. 후자는 일반적으로 훨씬 더 안정적인 솔루션으로 보입니다.

HttpClient 를 통해 통신하는 Azure App Services에서 2개의 다른 API 앱으로 작업할 때 몇 가지 유사한 동작이 발생했습니다. 우리는 부하 테스트에서 약 250개의 요청을 발견했고 시간 초과가 시작되고 "연결을 설정할 수 없습니다" HttpRequestException - 동시 사용자인지 순차 요청인지는 중요하지 않았습니다.

HttpClient 가 각 요청에서 삭제되도록 using 블록으로 전환했을 때 이러한 예외는 발생하지 않았습니다. 성능 저하가 있는 경우 Singleton에서 using 구문까지 무시할 수 있습니다.

using 블록으로 전환하여 HttpClient 가 각 요청에서 삭제되도록 했을 때 이러한 예외는 수신되지 않았습니다. 성능 저하가 있는 경우 싱글톤에서 using 구문까지 무시할 수 있습니다.

그것은 반드시 성능에 관한 것은 아니며 TCP 연결을 누출하지 않고 SocketException s를 얻는 것에 관한 것입니다.

MSDN에서 :

HttpClient는 한 번 인스턴스화되고 애플리케이션의 수명 동안 재사용되도록 되어 있습니다. 특히 서버 응용 프로그램에서 모든 요청에 ​​대해 새 HttpClient 인스턴스를 생성하면 과부하 상태에서 사용 가능한 소켓 수가 소진됩니다. 그러면 SocketException 오류가 발생합니다.

또한 https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/을 참조

@khellang 링크 주셔서 감사합니다( SocketException s에 대한 설명, 저는 분명히 거기에서 오해가 있었습니다)- 저는 그 게시물과 이와 똑같은 내용을 설명하는 3~4개의 다른 게시물을 보았습니다.

단일 인스턴스화가 의도라는 것을 이해하지만 Azure App Services에서 이를 사용할 때 상당히 적당한 부하(위에서 언급한 250개의 순차 요청)에서 지속적으로 HttpRequestExceptions 에 도달하고 있습니다. 다른 솔루션이 없는 한 HttpClient 것은 이러한 일관된 예외가 발생하지 않도록 하기 위해 구현해야 하는 해결 방법입니다.

나는 모든 보류중인 요청이 명시 적으로 처분 취소하는 "보다 정확한"솔루션은 이러한 예외를 포착하는 것입니다 있으리라 믿고있어 HttpClient , 다시 인스턴스화에게 HttpClient , 그리고 모든 요청을 다시 시도하십시오.

뭔가 좀 엉망인 것 같다.

한 번 인스턴스화되고 응용 프로그램 수명 동안 재사용됩니다.

우리는 더 깨끗한 솔루션을 원하지만 우리 코드에 문제가 있는 것이 아니라 프레임워크의 한계인 것 같습니다. 나는 틀렸다는 것을 기쁘게 생각합니다. 우리가 이것을 의도한 대로 사용하고 이러한 문제가 발생하지 않도록 하는 방법에 대한 지침이 필요합니다.

@snboisen ConnectionLeaseTimeoutHandler를 테스트

HttpClient 인스턴스에서 사용 중인 모든 개별 연결에 대해 "닫기"를 실행하는 방법을 모르겠습니다. 그것은 확실히 이상적이지만 내가 할 일은 HttpClient에 대해 GetOrCreate() 팩토리 메서드를 사용하고 모든 새 연결이 생성되도록 120초마다 새 HttpClient 인스턴스를 만드는 것입니다. 연결을 닫기 위해 모든 요청이 완료되면 이전 HttpClient 인스턴스를 처리하는 방법을 잘 모르겠습니다. 하지만 요청당 새 HttpClient 인스턴스를 만드는 데 문제가 된 적이 없기 때문에 .NET이 이를 처리한다고 생각합니다.

참고로 클라이언트에서 새로 고침이 발생해야 한다고 생각합니다. 서버는 DNS 변경 사항이나 미들웨어 통신을 책임지지 않습니다. DNS의 목적은 IP에 대한 친숙한 이름을 제공하는 것이 아니라 클라이언트와 서버 간의 조정 없이 언제든지 IP를 변경할 수 있도록 이러한 책임을 상쇄하는 것입니다. 완벽한 사용 사례는 AWS 탄력적 IP 주소입니다. 변경 사항은 DNS에만 반영됩니다. AWS는 ec2 인스턴스에서 실행되는 웹 서버에서 "닫기" 헤더를 보내는지 알지 못합니다. AWS는 관리하는 ec2 인스턴스 위에 있는 모든 웹 서버를 인식하지 못할 것입니다. "닫기" 헤더를 통해 전송하지 않는 이전 서버에 대한 시나리오는 동일한 소프트웨어가 DNS에 의해 전환된 모든 트래픽과 함께 새 서버에 배포되는 새 서버 배포입니다. 특히 다시 전환해야 하는 경우 이전 서버에서 아무 것도 변경되지 않아야 합니다. 모든 것이 DNS로 한 곳에서 원활하게 변경되어야 합니다.

여기서 논의된 더 큰 문제와 상관없이 이제 ConnectionLeaseTimeout이 코어에서 구현됩니까? 그렇다면 이 문제가 종료되지 않은 이유는 무엇입니까? 지금 막 문제 없이 원본 게시물과 똑같은 예제를 코딩할 수 있었습니다. 그것이 내 연결 DNS 문제를 해결하는지 여부에 관계없이 핵심에 구현된 _seems_ ConnectionLeaseTimeout _is_입니다.

ServicePointMananager.ConnectionLeaseTimeout은 .NET Core에서 구현되지 않습니다. .NET Core에서 이 속성을 사용하는 것은 금물입니다. .NET Framework에서만 작동합니다. 그리고 기본적으로 이 속성은 .NET Framework에서 "꺼짐"으로 설정됩니다.

단일 인스턴스화가 의도라는 것을 이해하지만 Azure App Services에서 이를 사용할 때 꽤 적당한 부하(위에서 언급한 250개의 순차 요청)에서 HttpRequestExceptions가 지속적으로 발생합니다. 다른 솔루션이 없는 한 HttpClient를 삭제하는 것은 이러한 일관된 예외가 발생하지 않도록 하기 위해 구현해야 하는 해결 방법입니다.

우리는 애플리케이션의 모든 http 요청이 동일한 HttpClient 인스턴스를 재사용할 수 있도록 하는 사용자 정의 API에서 HttpClient 를 래핑하여 소켓 고갈 문제를 성공적으로 해결했습니다. , RestSharp 비슷하지만 이것도 장점 중 하나입니다. 이것을 검색하는 것은 lock{} 뒤에 있습니다. 60분마다 새로운 HttpClient 만들고 대신 다시 전달하기 때문입니다. 이를 통해 웹 애플리케이션에서 대량의 http 요청을 수행할 수 있었습니다(많은 통합으로 인해). 여전히 닫히지 않은 이전 연결을 재사용하지 않습니다. 우리는 약 1년 동안 이 작업을 성공적으로 수행해 왔습니다(소켓 고갈 문제가 발생한 후).

나는 이것에 여전히 성능상의 의미가 있다고 확신하지만(특히 모든 잠금으로 인해) 소켓 고갈로 인해 죽어가는 모든 것보다 낫습니다.

@KallDrexx 왜 '글로벌' 인스턴스를 잠

HttpClient 를 얻는 코드는 다음과 같습니다.

```c#
var timeSinceCreated = DateTime.UtcNow - _lastCreatedAt;
if (timeSinceCreated.TotalSeconds > SecondsToRecreateClient)
{
자물쇠(자물쇠)
{
timeSinceCreated = DateTime.UtcNow - _lastCreatedAt;
if (timeSinceCreated.TotalSeconds > SecondsToRecreateClient)
{
_currentClient = 새로운 HttpClient();
_lastCreatedAt = DateTime.UtcNow;
}
}
}

        return _currentClient;

```

따라서 잠금은 분당 한 번만 발생하므로 여러 스레드가 동시에 새 HttpApiClient 를 만들려고 하지 않습니다. 나는 우리가 더 적극적으로 잠그고 있다고 생각했습니다.

알겠습니다, 그래서 편의상 이유입니다.
또는 타이머 기반(비동기) 업데이트를 사용하거나, 여러 개를 병렬로 생성하도록 허용하거나(스레드 안전하지 않은 지연 초기화 스타일), 다른 동기화 메커니즘을 사용하고 생성 시간 동안 다른 스레드를 차단하지 않습니다. 오래된 것을 재사용할 수 있습니다).

알겠습니다, 그래서 편의상 이유입니다.

편의시설로 분류해야 할지 모르겠습니다.

너무 많은 스레드가 동시에 새로운 HttpClient 를 생성하려고 하면 매분 생성되는 너무 많은 스레드로 인해 소켓이 고갈될 위험이 있습니다. 특히 이전 스레드가 그 1분 동안 소켓을 제대로 정리하지 않은 경우에는 더욱 그렇습니다. (캐스케이드 발생).

게다가, 나는 DateTime 업데이트가 원자적 연산인지 모르기 때문에 여전히 어느 정도의 잠금 조치가 필요합니다. 따라서 일부 스레드는 _lastCreatedAt 값을 읽을 수 있습니다. 업데이트 작업 중입니다.

그리고 모든 스레드가 이전 클라이언트를 재사용하면서 동시에 하나의 스레드가 새 클라이언트를 생성하도록 하려면 복잡한 논리가 많이 필요하므로 한 스레드가 성공적으로 새 클라이언트를 생성하도록 보장합니다. 말할 것도 없이 우리는 한 스레드가 _currentClient 를 반환하지 않고 다른 스레드가 인스턴스를 생성한다고 보장할 수 없기 때문에 여전히 잠금이 필요합니다.

프로덕션에서 위험을 감수하기에는 알려지지 않은 것이 너무 많고 복잡성이 추가되었습니다.

@KallDrexx

• ReaderWriterLockSlim 가 귀하의 용도에 더 적합할 것 같습니다.
• DateTime 할당은 실제 x64를 실행하는 경우 원자적이어야 합니다(단일 ulong 필드가 포함되어 있기 때문에). 잠금 외부에서 DateTime 값을 관찰하고 있기 때문에 그렇지 않은 경우 현재 코드는 스레드로부터 안전하지 않습니다.
• @karelz 가 제안한 타이머 기반 접근 방식은 DateTime 가 전혀 필요하지 않습니다... 타이머는 단순히 HttpClient 합니다. 그래도 HttpClient 필드를 메모리 장벽으로 둘러싸야 합니다( volatile , Interlocked.Exchange 등).

ReaderWriterLockSlim이 귀하의 용도에 더 적합할 것 같습니다.

깔끔한 그 수업에 대해 몰랐어요! 그러나 이것을 언급하면 SemaphoreSlim 도 비동기/대기 친화적이기 때문에( ReaderWriterLockSlim 되지 않음) 사용하는 것에 대해 생각하게 되었으며, 이는 다음과 같은 경우 가능한 스레드 경합에 도움이 될 수 있습니다. 새 HttpClient 이(가) 필요합니다. 그런 다음 다시 ReaderWriterLockSlim 귀하가 올바르게 지적한 잠재적인 DateTime 비원자성 문제를 더 잘 처리할 수 있으므로 이에 대해 생각을 해야 합니다. 감사합니다!

@karelz 가 제안한 타이머 기반 접근 방식은 DateTime이 전혀 필요하지 않습니다... 타이머는 단순히 HttpClient를 전환합니다. 그래도 HttpClient 필드를 일부 메모리 장벽(휘발성, Interlocked.Exchange 등)으로 둘러싸야 합니다.

아 무슨 말인지 잘못 읽었습니다. 그게 말이 되지만, 제대로 하려면 메모리 배리어 메커니즘에 더 익숙해져야 합니다.

감사 해요.

편집: 덧붙이자면, 이것이 내가 이것을 처리하기 위해 무언가를 내장해야 한다고 생각하는 좋은 이유이므로 HttpClient 의 모든 소비자는 이것을 다시 구현하거나 통과할 필요가 없습니다.

.net core 2.0에서도 여전히 문제인지 궁금합니다. 여전히 DNS 변경에 대해 걱정할 필요가 있습니까?

.net core 2.0에서도 여전히 문제인지 궁금합니다. 여전히 DNS 변경에 대해 걱정할 필요가 있습니까?

내 이해는 그것이 Dns 자체의 문제가 아니라 HttpClient 가 기존 연결을 재사용하려고 시도하므로(소켓 고갈 방지를 위해) 따라서 DNS가 변경되더라도 여전히 이전 연결에 연결한다는 것입니다. 이전 연결을 통해 이동하기 때문에 서버.

@KallDrexx , 그래서 그것은 여전히 ​​청록색 배포에 문제가 있음을 의미합니까?

@ 내 이해에서 1년 HttpClient 를 생성하고 이를 Production Green에 대해 사용하는 경우 Blue로 Production을 교체 HttpClient 는 연결이 닫힐 때까지 Green에 대한 열린 연결을 유지합니다.

나는 이것이 오래되었다는 것을 알고 있지만 시간 간격 측정에 DateTime.UtcNow를 사용해서는 안된다고 생각합니다. Stopwatch.GetTimestamp와 같은 단위 시간 소스를 사용합니다. 이렇게 하면 운영자 또는 시간 동기화에 의한 현지 시간 조정에 영향을 받지 않습니다. QPC 값을 되돌리는 버그가 있는 칩셋이 몇 가지 있었지만 지금은 그 중 상당수가 사용되지 않는 것 같습니다.

var sp = ServicePointManager.FindServicePoint(new Uri("http://foo.bar/baz/123?a=ab"));
sp.ConnectionLeaseTimeout = 60*1000; // 1 분

이 코드는 생성자에 있습니까?

@whynotme8998 @lundcm 아닌 것 같아요. HttpClient 가 싱글톤이고 여러 엔드포인트에 액세스하는 경우 생성자가 이를 배치할 올바른 위치가 아닙니다.
이 구현을 확인하십시오. 또한 프로젝트의 README에는 문제를 설명하는 블로그 게시물에 대한 링크가 있습니다. 그 기사는 또한 이 스레드를 가리킵니다.

ConnectionLeaseTimeout 정확히 무엇을 의미하는지 이해하도록 도와줄 수 있는 사람이 있습니까?

내 앱에서 1분으로 설정하면 1분마다 연결 임대 시간이 초과됩니까? 내 백엔드와 대화한다는 것은 정확히 무엇을 의미합니까?

사람들이 백엔드에서 DNS 업데이트에 대해 이야기하는 것을 보았습니까? 표준 Azure Web App에서 ASP.NET 백 엔드를 게시하면 DNS 새로 고침이 발생합니까?

1분 시간 초과는 잠재적으로 DNS가 업데이트되었지만 시간 초과가 아직 발생하지 않은 창을 남길 수 있지 않습니까?

편집하다. 이것을 깨닫는 것은 .NET Standard 2.0에서 작동하지 않습니다. 해결 방법은 무엇입니까?

https://www.stevejgordon.co.uk/introduction-to-httpclientfactory-aspnetcore를 기다리거나 직접 구현하십시오.

ConnectionLeaseTimeout을 변경하면 .netstandard 2.0이 있는 Xamarin에서 작동하지 않습니다!!!

@paradisehuman 나는 당신이 ServicePoint.ConnectionLeaseTimeout 을 의미한다고 가정합니다. AFAIK .NET Core에서도 작동하지 않습니다. .NET Core 2.1에서는 SocketsHttpHandler.PooledConnectionLifetime 도입했습니다. 또한 ASP.NET의 새로운 HttpClientFactory 는 두 가지를 모두 활용할 수 있으며 더 많은 작업을 수행합니다.
Mono/Xamarin에는 자체 네트워킹 스택 구현이 있습니다(네트워킹에 CoreFX 소스 코드를 사용하지 않음). 따라서 자세한 내용과 함께 리포지토리에 버그를 신고하는 것이 가장 좋습니다.

불행히도 현재는 .NET Core를 사용하여 이 작업을 수행할 수 있는 방법이 없습니다. ServicePointManager를 .NET Core로 가져와야 하거나 이와 유사한 기능을 다른 방식으로 활성화해야 합니다.

@onovotny , .NET Core 2.1의 SocketsHttpHandler는 핸들러 수준에서 ConnectionLeaseTimeout과 유사한 목적을 제공하는 PooledConnectionLifetime을 노출합니다. 이 시점에서 해결된 이 문제를 고려할 수 있습니까?

@stephentoub 지금 이것을 보고 있습니다. 예, PooledConnectionLifetime이 이 문제를 해결해야 한다고 생각합니다. 여전히 필요한 것이 있으면 커뮤니티에서 다른 문제를 열 ​​수 있습니다.

@onovotny @karelz @stephentoub ,

이것이 원래의 싱글톤 HttpClient/DNS 문제를 해결하는 최선의 방법에 대한 정확한 요약이라는 데 모두 동의하십니까?

• .NET Framework 2.0 이상에서는 ServicePoint.ConnectionLeaseTimeout 합니다.

• .NET Core 2.1에서는 SocketsHttpHandler.PooledConnectionLifetime 합니다.

• 다른 모든 플랫폼/대상/버전의 경우 신뢰할 수 있는 솔루션/해킹/해결책이 없으므로 시도조차 하지 마십시오.

이 스레드와 다른 스레드(예: ConnectionLeaseTimeout 가 .NET Standard 2.0의 플랫폼 간에 안정적으로 작동하지 않음)에서 계속 학습하면서 라이브러리에서 이를 해결하기 위해 드로잉 보드로 돌아갑니다. 가능한 한 많은 플랫폼/버전에서 작동합니다. 플랫폼 스니핑은 괜찮습니다. 주기적으로 HttpClient 폐기/재작성하는 것이 효과적이라면 괜찮습니다. 정기적인 간격으로 호스트에 connection:close 헤더를 보내는 첫 번째 시도에서 내가 잘못했다고 확신합니다. 조언에 미리 감사드립니다!

@tmenier 다른 모든 플랫폼/타겟/버전의 경우 신뢰할 수 있는 솔루션/해킹/대책이 없으므로 시도조차 하지 마십시오.

항상 정기적으로 인스턴스를 재활용할 수 있습니다(예: 새 인스턴스를 만들고 다른 사람들이 사용하는 정적 변수로 설정).
이것이 HttpClientFactory 가 하는 일입니다. 대신 HttpClientFactory 를 사용하도록 선택할 수 있습니다.

@karelz 감사합니다. 이것이 저에게 앞으로 나아갈 길을 제공한다고 생각합니다. 아마도 플랫폼 스니핑을 건너뛰고 모든 곳에서 인스턴스를 재활용해야 합니까, 아니면 가능한 경우 다른 접근 방식을 사용하는 것이 좋습니다(오버헤드 등을 피하기 위해)?

까다로운 부분은 재활용된 인스턴스를 폐기하는 것이 _언제_ 안전한지 아는 것입니다(동시성/대기 중인 요청에 대해 걱정해야 함). 하지만 HttpClientFactory 처리하는 방법을 엿볼 수 있습니다. 다시 한번 감사합니다.

@tmenier HttpClient 호출마다 인스턴스를 재활용하고 싶지 않습니다 . 그렇게 하면 tcp 소켓이 고갈됩니다. 재활용을 관리해야 합니다(시간 초과 또는 만료될 수 있는 HttpClient 있는 풀 유지.

@KallDrexx 맞습니다. 저는 단 몇 분마다와 같이 싱글톤(또는 "의사"-싱글톤)을 _주기적으로_ 재활용하는 것에 대해 이야기하고 있습니다. 보류 중인 요청이 없는 것으로 확인되면 풀 관리와 죽은 인스턴스의 지연된 처리가 포함될 것이라고 생각합니다.

아 죄송합니다 재활용의 의미를 잘못 이해했습니다.

오래된 것을 버릴 필요가 없습니다. GC가 수집하도록 합니다.
코드는 타이머를 기반으로 주기적으로 새로운 "의사"-싱글톤을 설정하는 것처럼 간단해야 합니다. 더 이상 아무것도 없습니다.

나는 그것들을 폐기하지 않으면 고성능 시나리오에서 http 연결이 부족할 때 속도가 느려질 수 있다는 것을 발견했습니다.

@tmenier .NET Core 2.1에서 https://github.com/dotnet/wcf/blob/master/src/System.Private.ServiceModel/src/System/ 에 완전히 캡슐화된 HttpClientHandler 생성

@edavedian dotnet /wcf repo에서 질문하는 것이 좋습니다. cc @mconnew @Lxiamail

기본 스택은 고급 제어 노브를 노출하지 않는 WinHTTP 또는 Curl로 확인됩니다.

.Net Core에 소켓을 통해 작동하는 HTTP 클라이언트가 있습니까?

.Net Core에 소켓을 통해 작동하는 HTTP 클라이언트가 있습니까?

예, SocketsHttpHandler이며 2.1부터는 기본값입니다.

내가 믿는 RestClient 와 유사하게 HttpClient 캐시 URI'가 적중합니까? 그렇다면 지원하는 버전(.NET Core 3.0/.NET Framework 3.0 등)을 알려주십시오.

프로젝트가 .Net Core 2.1+ 앱인 경우 캐싱이 RestClient 에서만 수행된다는 것을 알 수 있습니다.

내가 믿는 RestClient와 유사하게 HttpClient가 URI를 캐시합니까?

HttpClient는 캐싱을 수행하지 않습니다.

@SpiritBob 어떤 형태의 캐싱을 말하는지 명확하지 않습니다. 이 문제는 종료되었습니다. 질문이 있는 새 문제를 열어 주시면 답을 찾는 데 도움을 드릴 수 있습니다.

@scalablecory 나는

방금 이 스레드를 읽었으며 해결되지 않은 사용 사례가 있었던 것 같습니다.

HttpClientFactory 를 사용할 때 결과 HttpClient 는 다음을 나타내는 내부 SocketException 가 포함된 HttpRequestException 를 수신할 때 자동으로 연결을 닫고 새 DNS 조회를 수행합니다. 호스트가 더 이상 유효하지 않고 DNS가 잠재적으로 변경되었습니다(오류 코드 11001 - 알려진 호스트가 없음)?

그렇지 않은 경우 DNS 레코드에서 TTL이 만료되기 전에 HttpClient 가 DNS 조회를 수행하도록 하는 해결 방법은 무엇입니까?

저는 현재 HttpClientFactory 사용자 정의 HttpMessageHandler ( AddHttpClient<T, U>().ConfigurePrimaryHttpMessageHandler(...) 사용하여 종속성 주입을 통해 구성)와 함께 사용하고 있으며 TTL이 만료되기 전에 DNS 레코드가 변경되면 오류가 발생합니다. 특히 Azure Blob Storage에 많은 업로드를 수행할 때 발생하는 것으로 나타났습니다.