Krav: De fleste nettsteder bruker nå hovedsakelig Http/1.1- og Http/2.0-versjonsprotokollene, for nettsteder som kun støtter HTTP/2-protokollversjonen, vil som standard bruke HttpClient for å sende forespørsler, kaste System.Net.Http.Http.Http.HttpRequestException: En feil oppstod under sendingen av forespørselen. ---> System.IO.IOException: Kan ikke lese data fra transportforbindelsen: Programvaren i verten din har avbrutt en etablert forbindelse. ---> System.Net.Sockets.SocketException (10053): Programvare i verten din avbryter en etablert tilkobling. på System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException (SocketError-feil, Boolean forAsyncThrow).
Historikken til HTTP-protokollen
Tidslinje
HTTP/0.9
Den utdaterte HTTP/0.9 var den første versjonen av HTTP-protokollen, født i 1989. Det er ekstremt enkelt, lar klienten sende en GET-forespørsel og støtter ikke forespørselshodet. Siden det ikke finnes noe protokollhode, kan HTTP/0.9 bare støtte én type innhold – ren tekst. Serveren kan kun svare på strenger i HTML-format, ikke andre formater. Når serveren er ferdig med å sende, lukkes TCP-tilkoblingen. HTTP/0.9 har en typisk tilstandsløshet, der hvert besøk behandles uavhengig og frakobles når behandlingen er fullført. Hvis den forespurte siden ikke eksisterer, returneres ingen feilkoder.
HTTP/1
HTTP/1 er en samlebetegnelse for HTTP 1.0 og HTTP 1.1, som refererer til versjonene av HTTP-protokollen som er henholdsvis 1.0 og 1.1. HTTP 1.0 var den andre versjonen av HTTP-protokollen og er fortsatt mye brukt i dag. Den har gjort en rekke forbedringer og forbedringer basert på HTTP/0.9, inkludert:
Flere formater som bilder, videoer og binærfiler kan sendes utover bare tekst I tillegg er POST-forespørselsmetoder lagt til Endret formatet på HTTP-forespørsler og svar. I tillegg til datadelen må hver kommunikasjon inkludere en HTTP-header som beskriver noe metadata, det vil si at forespørselsheader-informasjonen legges til Lagt til funksjoner som responsstatuskode, støtte for flertegnssett, autorisasjon, cache og innholdskoding Selv om det fortsatt er en tilstandsløs protokoll, kan lange forbindelser støttes ved å legge til headeren "Connection: keep-alive" i forespørselen
HTTP 1.1
HTTP 1.1 er en standardisert protokoll, og HTTP 1.1 eliminerer mye tvetydighet og introduserer flere forbedringer.
Eiendommelighet
Cache-prosessering, HTTP 1.1 introduserer flere cache-kontrollpolicyer, som Entity tag, If-Unmodified-Since, If-Match, If-None-Match osv., samt flere valgfrie cache-headere for å kontrollere cache-policyen. Båndbreddeoptimalisering og bruk av nettverkstilkoblinger introduserer et område i forespørselsheaderen, som tillater at kun én del av ressursen kan forespørres, det vil si returnere statuskoden 206, noe som gjør det enklere for utviklere å fritt velge å utnytte båndbredde og lenker fullt ut, og kan bruke Range og Content-Range for å lage en breakpoint-gjenopptakelsesfunksjon. Feilvarslingshåndtering, 24 nye feilstatuskoder er lagt til i HTTP 1.1. Ved å legge til Host-headeren kan ulike domenenavn konfigureres på servere med samme IP-adresse. Støtte lange forbindelser, HTTP 1.1 støtter lange forbindelser, flere HTTP-forespørsler og svar kan sendes på en TCP-tilkobling, noe som reduserer forbruket og forsinkelsen ved etablering og lukking av forbindelser, og Connection:keep-alive er aktivert som standard i HTTP 1.1, og generelle nettlesere tillater at 6 lange lenker etableres samtidig for samme domenenavn. Lagt til pipeline-teknologi for å tillate at en andre forespørsel sendes før det første svaret er fullstendig sendt for å forbedre køblokkeringen, men rekkefølgen på svarene vil fortsatt returneres i samme rekkefølge som forespørslene. Støtte respons-chunking, ved å sette Transfer-Encoding: chunked for chunked response, slik at responsdataene kan deles opp i flere deler, og serveren kan frigjøre bufferen så tidlig som mulig for å oppnå raskere responshastighet.
HTTP 2.0
HTTP 2.0 har bedre ytelse, og nå blir nettsider mer og mer komplekse, og utvikler seg til og med unike applikasjoner, mengden medieavspilling, størrelsen på skript for å forbedre interaksjonen har også økt mye, og mer data overføres via HTTP-forespørsler, så HTTP 2.0 har gjort mange optimaliseringer for nettverkseffektivitet.
Eiendommelighet
Binær rammedeling, HTTP 2.0 er en binær protokoll snarere enn en tekstprotokoll som deler all overført informasjon i mindre meldinger og rammer og koder dem i binært format. Multiplexing, parallelle forespørsler kan behandles i samme lenke, alle tilganger under samme domenenavn kommer fra samme TCP-tilkobling, HTTP-meldinger deles opp i uavhengige rammer, og serveren setter sammen meldingene etter identifikatorer og headers, og fjerner rekkefølge- og blokkeringsbegrensningene i HTTP 1.1. Komprimering av headere, som ofte er like i en serie forespørsler, fjerner kostnadene ved duplisering og overføring av dupliserte data. Server-side push, serveren kan proaktivt sende ressurser til klienten uten eksplisitt forespørsel fra klienten.
HTTP 3.0
HTTP 3.0 er for øyeblikket i formulerings- og testfasen, er en ny HTTP-protokoll i fremtiden, HTTP 3.0-protokollen kjører oppå QUIC-protokollen, er basert på UDP for å oppnå pålitelig overføring, avveining av overføringshastighet og overføringspålitelighet og optimalisere, bruk av UDP vil unngå TCP-køblokkeringsproblemer og øke hastigheten på nettverksoverføringen, men også for å oppnå en pålitelig overføringsmekanisme, HTTP 3.0 er ikke en utvidelse av HTTP 2.0, HTTP 3.0 vil være en helt ny protokoll.
HttpClientHandler VS SocketsHttpHandler
Standard meldingshåndterer brukt av HttpClient i .NET Framework og .NET Core 2.0 og tidligere er HttpClientHandler.
Starter med .NET Core 2.1, klasserSocketsHttpHandler tilbyr en høyere nivå HTTP-nettverksklasse(f.eks. HttpClient). Å bruke SocketsHttpHandler gir mange fordeler:
Ytelsen har forbedret seg betydelig sammenlignet med tidligere implementeringer. Eliminer plattformavhengigheter for å forenkle distribusjon og service. For eksempel er ikke libcurl lenger avhengig av .NET Core for macOS og .NET Core for Linux. Konsistent oppførsel på tvers av alle .NET-plattformer.
I .NET 9 bruker HttpClientFactory SocketsHttpHandler som hovedhandler
HttpClientFactory tillater konfigurasjon av HttpClient-pipelines for navngitte og typede HttpMessageHandler-objekter. Den innerste handleren, eller handleren som faktisk sender forespørsler på nettverket, kalles master handler. Hvis den ikke var konfigurert, var denne handleren alltid en HttpClientHandler før. Selv om standard hovedhandler er implementasjonsdetaljene, finnes det brukere som er avhengige av den. For eksempel kaster noen brukere hovedhandleren til HttpClientHandler-innstillingsegenskapene som ClientCertificates, UseCookies og UseProxy.
Lenke:Innloggingen med hyperkoblingen er synlig.
Den globale konfigurasjonen ber om HTTP-protokollversjonen
Koden er som følger:
DefaultRequestVersionStandardinnstillingen er HttpVersion.Version11。
Egenskapen DefaultRequestVersion spesifiserer standard HTTP-versjon som skal brukes for forespørsler sendt via denne HttpClient-instansen, når den konstruerer HttpRequestMessage som skal sendes, spesifikt ved å kalle 、、、GetStreamAsyncGetAsyncGetAsyncGetByteArrayAsync, PatchAsyncGetStringAsync, PostAsync og PutAsync.
DefaultRequestVersion-egenskapenGjelder ikke for SendAsync-metoden。 HttpRequestMessage-parameteren som sendes til SendAsync-metoden som en parameter har sin egen Version-egenskap som styrer HTTP-versjonen som brukes for forespørselen.
Lenke:Innloggingen med hyperkoblingen er synlig.
HttpVersionPolicy forhandlingspolicy
RequestVersionOrLower: Bruk den forespurte versjonen, eller nedgrader til en lavere versjon (men ikke høyere enn den etterspurte). Dette er standardoppførselen. Enkelt sagt er den mest brukte protokollversjonen den nåværende versjonen, og hvis den nåværende protokollversjonen ikke støttes, vil den bli nedgradert.
RequestVersionOrHigher: Bruk den høyeste versjonen som støttes av serveren, men ikke lavere enn den forespurte versjonen. Det vil si at oppgraderinger er tillatt, og nedgraderinger under den forespurte versjonen er ikke tillatt. Enkelt sagt, bruk protokoller i høyere versjon for kommunikasjon når det er mulig.
RequestVersionExact: Bruk strengt den ønskede versjonen, ingen oppgraderinger eller nedgraderinger er tillatt.
HttpClient bruker Http/2.0-versjonsprotokollen
Testkoden er som følger:
Forespørselen bruker versjon 1.1, og den endelige klienten og serveren forhandler om å bruke 2.0-protokollen for kommunikasjon, så det endelige svaret er versjon 2.0, som vist i figuren nedenfor:
Referanse:
Innloggingen med hyperkoblingen er synlig.
Innloggingen med hyperkoblingen er synlig.
Innloggingen med hyperkoblingen er synlig. |