Når man bygger en applikation med ASP.NET, bruges en instans af HttpClient-klassen til at lave en HTTP-anmodning. At bruge HttpClient kan virke enkelt. Dog opdages nogle potentielle problemer først, når applikationen er under kraftig belastning.
Problemer relateret til den oprindelige HttpClient-klasse, der leveres i .NET:Hyperlink-login er synlig.
HttpClient, mens man implementerer IDisposable, er det ikke en foretrukken operation at erklære og instansiere det i using statement, fordiNår man frigiver et HttpClient-objekt, gør den underliggende socket det ikkestraksløslade, hvilket kan give problemer med udtømning af sokkel.
Problemet er egentlig ikke selve HttpClient, men standardkonstruktøren af HttpClient, da den opretter en ny faktisk HttpMessageHandler-instans med de nævnte "socket exhaustion"- og DNS-ændringsproblemer.
Oprettelse af HttpClient direkte (forkert brug)
Instansier HttpClient-objektet direkte, og tilføj ved at garantere kaldet til Dispose-metoden, koden er som følger:
Kald interfacet 5 gange, send en HTTP-forespørgsel med HttpClient, og tjek netværksforbindelsen med følgende kommando:
Du kan se, at når HttpClient frigives, er forbindelsen mellem den lokale computer og målserverenTIME_WAITI tilfælde af høj samtidighed rapporteres fejlen som følger:
Kan ikke oprette forbindelse til den eksterne server
System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted.
For spørgsmål kan du også henvise til:
Opret en HttpClinet med IHttpClientFactory (korrekt brug)
Ved brug af DI-afhængighedsinjektion er IHttpClientFactory det samme som HttpLinet, som oprettes ved hjælp af IHttpClientFactory.
Tilføj tjenesten til opstartsfilen, koden er som følger:
HomeController-controllerkoden er som følger:
Vi bruger også HttpClinet til at sende 5 forespørgsler gennem opkaldsinterfacet, og maskinen etablerer kun en forbindelse med målserveren, og forbindelsen genbruges under anmodningsprocessen. Som vist nedenfor:
IHttpClientFactory samler fabriksoprettede HttpMessageHandler-instanser i en pulje for at reducere ressourceforbruget. Når du opretter en ny HttpClient-instans, kan du genbruge HttpMessageHandler-instansen i poolen, hvis levetiden ikke er udløbet.
{
"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 at bruge IHttpClientFactory i en DI-aktiveret applikation kan du undgå:
- Løs problemet med ressourceudtømning ved at dele HttpMessageHandler-instansen.
- Opløs DNS-stagnation ved periodisk at loope gennem HttpMessageHandler-instanser.
Derudover findes der andre måder at løse ovenstående problemer på ved hjælp af SocketsHttpHandler-instanser med lang levetid.
- Opret en instans af SocketsHttpHandler ved app-opstart og brug den gennem hele appens livscyklus.
- Konfigurér PooledConnectionLifetime til den passende værdi baseret på DNS-opdateringstiden.
- Opret en instans af HttpClient ved brug af den nye HttpClient(handler, disposeHandler: false) efter behov.
Ovenstående tilgang løser ressourcestyringsproblemer på en lignende måde som IHttpClientFactory.
- SocketsHttpHandler mellem HttpClient-instanserneDelte forbindelser。 Denne deling forhindrer udtømning af sokkel.
- SocketsHttpHandler looper forbindelser baseret på PooledConnectionLifetime for at undgå DNS-stagnation.
For mere brug og konfiguration, se venligst:
Hyperlink-login er synlig.
Hyperlink-login er synlig.
|
Opslået på 14/05/2022 19.37.21
|
|
|
|
Udlejer|
Opslået på 14/05/2022 19.38.14
|
Opslået på 14/05/2022 22.36.06
|
