Krav: De fleste hjemmesider bruger nu primært Http/1.1 og Http/2.0 versionprotokollerne, for hjemmesider, der kun understøtter HTTP/2-protokolversionen, vil HttpClient som standard sende anmodninger System.Net.Http.Http.Http.HttpRequestException: En fejl opstod under afsendelsen af anmodningen. ---> System.IO.IOException: Kan ikke læse data fra transportforbindelsen: Softwaren i din vært har afbrudt en etableret forbindelse. ---> System.Net.Sockets.SocketException (10053): Software i din vært afbryder en etableret forbindelse. på System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError-fejl, Boolean forAsyncThrow).
Historien om HTTP-protokollen
Tidslinje
HTTP/0.9
Den forældede HTTP/0.9 var den første version af HTTP-protokollen, født i 1989. Det er ekstremt simpelt, idet det tillader klienten at sende en GET-anmodning og understøtter ikke anmodningsheaderen. Da der ikke er noget protokolheader, kan HTTP/0.9 kun understøtte én type indhold – almindelig tekst. Serveren kan kun svare på strenge i HTML-format, ikke andre formater. Når serveren er færdig med at sende, lukkes TCP-forbindelsen.
HTTP/0.9 har en typisk tilstandsløshed, hvor hvert besøg behandles uafhængigt og afbrydes, når behandlingen er afsluttet. Hvis den anmodede side ikke eksisterer, returneres der ingen fejlkoder.
HTTP/1
HTTP/1 er en samlebetegnelse for HTTP 1.0 og HTTP 1.1, som refererer til de versioner af HTTP-protokollen, der henholdsvis er 1.0 og 1.1.
HTTP 1.0 var den anden version af HTTP-protokollen og er stadig bredt anvendt i dag. Den har foretaget en række forbedringer og forbedringer baseret på HTTP/0.9, herunder:
Flere formater som billeder, videoer og binære filer kan sendes ud over blot tekst
Derudover er der tilføjet POST-anmodningsmetoder
Ændrede formatet på HTTP-forespørgsler og svar. Ud over datadelen skal hver kommunikation inkludere en HTTP-header, der beskriver nogle metadata, dvs. at anmodningsheader-informationen tilføjes
Tilføjede funktioner såsom responsstatuskode, understøttelse af multi-tegnsæt, autorisation, cache og indholdskodning
Selvom det stadig er en tilstandsløs protokol, kan lange forbindelser understøttes ved at tilføje "Connection: keep-alive"-headeren til forespørgslen
HTTP 1.1
HTTP 1.1 er en standardiseret protokol, og HTTP 1.1 eliminerer meget tvetydighed og introducerer flere forbedringer.
Ejendommelighed
Cache-behandling, HTTP 1.1 introducerer flere cachekontrolpolitikker, såsom Entity tag, If-Unmodified-Since, If-Match, If-None-Match osv., samt flere valgfrie cache-headere til at styre cachepolitikken.
Båndbreddeoptimering og brugen af netværksforbindelser introducerer et interval i anmodningsheaderen, som kun tillader én del af ressourcen at blive anmodet om, nemlig at returnere statuskoden 206, hvilket gør det lettere for udviklere frit at vælge at udnytte båndbredde og links fuldt ud, og kan bruge Range og Content-Range til at skabe en breakpoint-genoptagelsesfunktion.
Fejlmeddelelsesstyring, 24 nye fejlstatuskoder er blevet tilføjet i HTTP 1.1.
Ved at tilføje Host-headeren kan forskellige domænenavne konfigureres på servere med samme IP-adresse.
Understøtter lange forbindelser, HTTP 1.1 understøtter lange forbindelser, flere HTTP-anmodninger og svar kan sendes på en TCP-forbindelse, hvilket reducerer forbruget og forsinkelsen ved etablering og lukning af forbindelser, og Connection:keep-alive er aktiveret som standard i HTTP 1.1, og almindelige browsere tillader oprettelsen af 6 lange links samtidig for det samme domænenavn.
Tilføjet pipeline-teknologi for at tillade en anden anmodning at blive sendt, før det første svar er fuldt udsendt, for at forbedre køblokering, men rækkefølgen af svar vil stadig blive returneret i samme rækkefølge som anmodningerne.
Understøttelse af respons-chunking ved at sætte Transfer-Encoding: chunked for chunked response, hvilket tillader responsdata at blive opdelt i flere dele, og serveren kan frigive bufferen så hurtigt som muligt for at opnå hurtigere responshastighed.
HTTP 2.0
HTTP 2.0 har bedre ydeevne, og nu bliver websider mere og mere komplekse og udvikler sig endda til unikke applikationer; mængden af medieafspilning, størrelsen på scripts for at forbedre interaktionen er også steget meget, og mere data transmitteres via HTTP-anmodninger, så HTTP 2.0 har foretaget mange optimeringer for netværkseffektivitet.
Ejendommelighed
Binær rammeopdeling, HTTP 2.0 er en binær protokol snarere end en tekstprotokol, der opdeler al transmitteret information i mindre beskeder og rammer og koder dem i binært format.
Multiplexing, parallele forespørgsler kan behandles i det samme link, alle adgange under samme domænenavn kommer fra samme TCP-forbindelse, HTTP-beskeder opdeles i uafhængige rammer, og serveren samler beskederne igen efter identifikatorer og headers, hvilket fjerner rækkefølge- og blokeringsbegrænsningerne i HTTP 1.1.
Komprimering af headers, som ofte ligner i en række forespørgsler, fjerner omkostningerne ved duplikering og overførsel af duplikerede data.
Server-side push kan serveren proaktivt sende ressourcer til klienten uden eksplicit anmodning fra klienten.
HTTP 3.0
HTTP 3.0 er i øjeblikket i formulerings- og testfasen, er en ny HTTP-protokol i fremtiden, HTTP 3.0-protokollen kører oven på QUIC-protokollen, er baseret på UDP for at opnå pålidelig transmission, afvejning af transmissionshastighed og transmissionspålidelighed samt optimering, brug af UDP vil undgå TCP-køblokeringsproblemer og øge netværkstransmissionshastigheden, men også for at opnå en pålidelig transmissionsmekanisme, HTTP 3.0 er ikke en udvidelse af HTTP 2.0, HTTP 3.0 bliver en helt ny protokol.
HttpClientHandler VS SocketsHttpHandler
Den standard meddelelseshåndter, der bruges af HttpClient i .NET Framework og .NET Core 2.0 og tidligere, er HttpClientHandler.
Starter med .NET Core 2.1, klasserSocketsHttpHandler tilbyder en højere niveau HTTP-netværksklasse(f.eks. HttpClient). Brugen af SocketsHttpHandler giver mange fordele:
Ydelsen er forbedret markant sammenlignet med tidligere implementeringer.
Eliminer platformafhængigheder for at forenkle implementering og service. For eksempel er libcurl ikke længere afhængig af .NET Core for macOS og .NET Core for Linux.
Ensartet adfærd på tværs af alle .NET-platforme.
I .NET 9 bruger HttpClientFactory SocketsHttpHandler som hovedhandler
HttpClientFactory tillader konfiguration af HttpClient-pipelines for navngivne og typede HttpMessageHandler-objekter. Den inderste handler eller handler, der faktisk sender anmodninger på netværket, kaldes master handler. Hvis den ikke var konfigureret, var denne handler altid en HttpClientHandler før. Selvom standard master-håndtereren er implementeringsdetaljerne, er der brugere, der er afhængige af den. For eksempel kaster nogle brugere hovedhandleren til HttpClientHandler-indstillingen af egenskaber som ClientCertificates, UseCookies og UseProxy.
Sammenkæde:Hyperlink-login er synlig.
Den globale konfiguration anmoder om HTTP-protokolversionen
Koden er som følger:
DefaultRequestVersionStandardindstillingen er HttpVersion.Version11。
DefaultRequestVersion-egenskaben specificerer standard HTTP-versionen, der skal bruges til forespørgsler sendt via denne HttpClient-instans, når den konstruerer HttpRequestMessage, der skal sendes, specifikt ved at kalde 、、、GetStreamAsyncGetAsyncGetAsyncGetGetArrayAsync, PatchAsyncGetStringAsync, PostAsync og PutAsync.
DefaultRequestVersion-egenskabenGælder ikke for SendAsync-metoden。 Parameteren HttpRequestMessage, der sendes til SendAsync-metoden som parameter, har sin egen versionegenskab, der styrer den HTTP-version, der bruges til forespørgslen.
Sammenkæde:Hyperlink-login er synlig.
HttpVersionPolicy forhandlingspolitik
RequestVersionOrLower: Brug den ønskede version, eller nedgrader til en lavere version (men ikke højere end den ønskede version). Dette er standardadfærden. Kort sagt er den mest brugte protokolversion den nuværende version, og hvis den nuværende protokolversion ikke understøttes, vil den blive nedgraderet.
RequestVersionOrHigher: Brug den højeste version, som serveren understøtter, men ikke lavere end den ønskede version. Det vil sige, opgraderinger er tilladt, og nedgraderinger under den ønskede version er ikke tilladt. Kort sagt, brug protokoller i højere versioner til kommunikation, når det er muligt.
RequestVersionExact: Brug strengt den ønskede version, ingen opgraderinger eller nedgraderinger er tilladt.
HttpClient bruger Http/2.0-versionens protokol
Testkoden er som følger:
Anmodningen bruger version 1.1, og den endelige klient og server forhandler om at bruge 2.0-protokollen til kommunikation, så det endelige svar er version 2.0, som vist i figuren nedenfor:
Henvisning:
Hyperlink-login er synlig.
Hyperlink-login er synlig.
Hyperlink-login er synlig. |
Opslået den 31-8-2025 21:16:47
|
|
|
|
Udlejer|
Opslået den 31-8-2025 21:46:27
|
