Når man bygger en applikasjon med ASP.NET, brukes en instans av HttpClient-klassen for å gjøre en HTTP-forespørsel. Å bruke HttpClient kan virke enkelt. Noen potensielle problemer oppdages imidlertid ikke før applikasjonen er under tung belastning.
Problemer knyttet til den opprinnelige HttpClient-klassen levert i .NET:Innloggingen med hyperkoblingen er synlig.
HttpClient, mens IDisposable implementeres, er det ikke en foretrukket operasjon å erklære og instansiere det i useing-setningen, fordiNår man frigir et HttpClient-objekt, gjør ikke den underliggende socketen detmomentantfrigivelse, noe som kan føre til problemer med utmattelse av sokkelen.
Problemet er egentlig ikke HttpClient selv, men standardkonstruktøren av HttpClient, siden den oppretter en ny faktisk HttpMessageHandler-instans med "socket exhaustion" og DNS-endringsproblemene nevnt ovenfor.
Opprette HttpClient direkte (feil bruk)
Instansier HttpClient-objektet direkte, og legg til med for å garantere kallet til Dispose-metoden, koden er som følger:
Kall grensesnittet 5 ganger, send en HTTP-forespørsel med HttpClient, og sjekk nettverkstilkoblingen med følgende kommando:
Du kan se at når HttpClient frigjøres, er forbindelsen mellom den lokale datamaskinen og målserverenTIME_WAITVed høy samtidighet rapporteres feilen som følger:
Kan ikke koble til den eksterne serveren
System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted.
For spørsmål kan du også referere til:
Opprett en HttpClinet med IHttpClientFactory (korrekt bruk)
Ved bruk av DI-avhengighetsinnsprøytning er IHttpClientFactory det samme som HttpLinet, som er laget med IHttpClientFactory.
Legg til tjenesten i oppstartsfilen, koden er som følger:
HomeController-kontrollerkoden er som følger:
Vi bruker også HttpClinet for å sende 5 forespørsler gjennom samtalegrensesnittet, og maskinen etablerer kun en forbindelse med målserveren, og forbindelsen gjenbrukes under forespørselsprosessen. Som vist nedenfor:
IHttpClientFactory samler fabrikkopprettede HttpMessageHandler-instanser i en pool for å redusere ressursforbruket. Når du oppretter en ny HttpClient-instans, kan du gjenbruke HttpMessageHandler-instansen i poolen hvis levetiden ikke har utløpt.
{
"Livstid": "Singleton",
"ServiceType": "System.Net.Http.IHttpClientFactory",
"ImplementationType": "Microsoft.Extensions.Http.DefaultHttpClientFactory"
},
{
"Livstid": "Singleton",
"ServiceType": "System.Net.Http.IHttpMessageHandlerFactory",
"ImplementationType": "Microsoft.Extensions.Http.DefaultHttpClientFactory"
}
Ved å bruke IHttpClientFactory i en DI-aktivert applikasjon, kan du unngå:
- Løs problemet med ressursutmattelse ved å dele HttpMessageHandler-instansen.
- Løs DNS-stagnasjon ved periodisk å gå i loop gjennom HttpMessageHandler-instanser.
I tillegg finnes det andre måter å løse de ovennevnte problemene på ved bruk av SocketsHttpHandler-instanser med lang levetid.
- Opprett en instans av SocketsHttpHandler ved oppstart av appen og bruk den gjennom hele appens livssyklus.
- Konfigurer PooledConnectionLifetime til riktig verdi basert på DNS-oppdateringstiden.
- Opprett en instans av HttpClient ved å bruke ny HttpClient(handler, disposeHandler: false) etter behov.
Tilnærmingen ovenfor løser ressursstyringsproblemer på en lignende måte som IHttpClientFactory.
- SocketsHttpHandler mellom HttpClient-instanseneFelles forbindelser。 Denne delingen forhindrer utmattelse av sokkelen.
- SocketsHttpHandler slår tilkoblinger basert på PooledConnectionLifetime for å unngå at DNS blir utdatert.
For mer bruk og konfigurasjon, vennligst se til:
Innloggingen med hyperkoblingen er synlig.
Innloggingen med hyperkoblingen er synlig.
|
Publisert på 14.05.2022 19:37:21
|
|
|
|
Vert|
Publisert på 14.05.2022 19:38:14
|
Publisert på 14.05.2022 22:36:06
|
