Krav: De flesta webbplatser använder numera främst protokollen för Http/1.1 och Http/2.0, för webbplatser som endast stödjer HTTP/2-protokollversionen, kommer HttpClient som standard att skicka förfrågningar att kasta System.Net.Http.Http.Http.HttpRequestException: Ett fel uppstod vid sändning av förfrågan. ---> System.IO.IOException: Kan inte läsa data från transportanslutningen: Mjukvaran i din värd har avbrutit en etablerad anslutning. ---> System.Net.Sockets.SocketException (10053): Programvara i din värd avbryter en etablerad anslutning. på System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException (SocketError error, boolean forAsyncThrow).
Historik över HTTP-protokollet
Tidslinje
HTTP/0.9
Den föråldrade HTTP/0.9 var den första versionen av HTTP-protokollet, född 1989. Det är extremt enkelt och låter klienten skicka en GET-förfrågan och stöder inte begäransökan. Eftersom det inte finns något protokollhuvud kan HTTP/0.9 endast stödja en typ av innehåll – ren text. Servern kan bara svara på strängar i HTML-format, inte i andra format. När servern är klar med att skicka stängs TCP-anslutningen.
HTTP/0.9 har en typisk tillståndslöshet, där varje besök behandlas oberoende och kopplas bort när bearbetningen är klar. Om den begärda sidan inte finns returneras inga felkoder.
HTTP/1
HTTP/1 är en samterm för HTTP 1.0 och HTTP 1.1, vilket syftar på de versioner av HTTP-protokollet som är 1.0 respektive 1.1.
HTTP 1.0 var den andra versionen av HTTP-protokollet och används fortfarande i stor utsträckning idag. Den har gjort ett antal förbättringar och förbättringar baserade på HTTP/0.9, inklusive:
Fler format som bilder, videor och binärfiler kan skickas utöver bara text
Ovanpå och POST-förfrågningsmetoder har lagts till
Ändrade formatet på HTTP-förfrågningar och svar. Utöver datadelen måste varje kommunikation innehålla en HTTP-header som beskriver viss metadata, dvs. begäran header-informationen läggs till
Tillagda funktioner såsom svarsstatuskod, stöd för flerteckenuppsättningar, auktorisering, cache och innehållskodning
Även om det fortfarande är ett tillståndslöst protokoll kan långa anslutningar stödjas genom att lägga till headern "Connection: keep-alive" i förfrågan
HTTP 1.1
HTTP 1.1 är ett standardiserat protokoll, och HTTP 1.1 eliminerar mycket oklarhet och introducerar flera förbättringar.
egendomlighet
Cachehantering, HTTP 1.1 introducerar fler cachekontrollpolicyer, såsom Entity tag, If-Unmodified-Since, If-Match, If-None-Match, etc., samt fler valfria cachehuvuden för att styra cachepolicyn.
Bandbreddsoptimering och användning av nätverksanslutningar introducerar ett intervall i begäransökan, vilket tillåter endast en del av resursen att begära, det vill säga returnera statuskoden 206, vilket gör det enklare för utvecklare att fritt välja att utnyttja bandbredd och länkar fullt ut, och kan använda Range och Content-Range för att skapa en brytpunktsfunktion för återupptagning.
Felmeddelandehantering, 24 nya felstatuskoder har lagts till i HTTP 1.1.
Genom att lägga till Host-headern kan olika domännamn konfigureras på servrar med samma IP-adress.
Stöd för långa anslutningar, HTTP 1.1 stöder långa anslutningar, flera HTTP-förfrågningar och svar kan överföras på en TCP-anslutning, vilket minskar förbrukningen och fördröjningen vid etablering och stängning av anslutningar, och Connection:keep-alive är aktiverad som standard i HTTP 1.1, och allmänna webbläsare tillåter att 6 långa länkar upprättas samtidigt för samma domännamn.
Införd pipelining-teknik för att möjliggöra att en andra förfrågan skickas innan det första svaret är helt skickat för att förbättra köblockeringen, men svarsordningen kommer fortfarande att returneras i samma ordning som förfrågningarna.
Stöd responschunking, genom att sätta Transfer-Encoding: chunked for chunked response, vilket tillåter att svarsdata delas upp i flera delar, och servern kan släppa bufferten så snart som möjligt för att uppnå snabbare svarshastighet.
HTTP 2.0
HTTP 2.0 har bättre prestanda, och nu blir webbsidor allt mer komplexa och utvecklas till unika applikationer, mängden medieuppspelning, storleken på skript för att förbättra interaktionen har också ökat mycket, och mer data överförs via HTTP-förfrågningar, så HTTP 2.0 har gjort många optimeringar för nätverkseffektivitet.
egendomlighet
Binär ramdelning, HTTP 2.0 är ett binärt protokoll snarare än ett textprotokoll som delar upp all överförd information i mindre meddelanden och ramar och kodar dem i binärt format.
Multiplexing, parallella förfrågningar kan behandlas i samma länk, alla åtkomster under samma domännamn kommer från samma TCP-anslutning, HTTP-meddelanden delas upp i oberoende ramar, och servern sätter ihop meddelandena enligt identifierare och headers, vilket tar bort ordnings- och blockeringsbegränsningarna i HTTP 1.1.
Komprimering av headers, som ofta är liknande i en serie förfrågningar, eliminerar kostnaden för duplicering och överföring av dubbletter av data.
Server-side push kan servern proaktivt skicka resurser till klienten utan att klienten uttryckligen begär det.
HTTP 3.0
HTTP 3.0 är för närvarande i formulerings- och testfasen, är ett nytt HTTP-protokoll i framtiden, HTTP 3.0-protokollet körs ovanpå QUIC-protokollet, är baserat på UDP för att uppnå tillförlitlig överföring, kompromisser med överföringshastighet och överföringstillförlitlighet samt optimera, med UDP undviker TCP-köblockeringsproblem och snabbar upp nätverksöverföringshastigheten, men måste också uppnå en pålitlig överföringsmekanism, HTTP 3.0 är inte en utvidgning av HTTP 2.0, HTTP 3.0 kommer att vara ett helt nytt protokoll.
HttpClientHandler VS SocketsHttpHandler
Standardmeddelandehanteraren som används av HttpClient i .NET Framework och .NET Core 2.0 och tidigare är HttpClientHandler.
Börjar med .NET Core 2.1, klasserSocketsHttpHandler erbjuder en högre nivå HTTP-nätverksklass(t.ex. HttpClient). Att använda SocketsHttpHandler erbjuder många fördelar:
Prestandan har förbättrats avsevärt jämfört med tidigare implementationer.
Eliminera plattformsberoenden för att förenkla driftsättning och service. Till exempel är libcurl inte längre beroende av .NET Core för macOS och .NET Core för Linux.
Konsekvent beteende över alla .NET-plattformar.
I .NET 9 använder HttpClientFactory SocketsHttpHandler som huvudhanterare
HttpClientFactory tillåter konfiguration av HttpClient-pipelines för namngivna och typade HttpMessageHandler-objekt. Den innersta handlern eller den handler som faktiskt skickar förfrågningar i nätverket kallas master handler. Om den inte var konfigurerad var denna hanterare alltid en HttpClientHandler tidigare. Även om standardhandläggaren är implementeringsdetaljerna, finns det användare som är beroende av den. Till exempel kastar vissa användare huvudhanteraren till HttpClientHandler-inställningens egenskaper som ClientCertificates, UseCookies och UseProxy.
Länk:Inloggningen med hyperlänken är synlig.
Den globala konfigurationen begär HTTP-protokollversionen
Koden är följande:
DefaultRequestVersionStandardinställningen är HttpVersion.Version11。
Egenskapen DefaultRequestVersion specificerar standardversionen av HTTP som ska användas för förfrågningar som skickas via denna HttpClient-instans, när den konstruerar HttpRequestMessage för att skicka, specifikt genom att anropa 、、、GetStreamAsyncGetAsyncGetAsyncGetByteArrayAsync, PatchAsyncGetStringAsync, PostAsync och PutAsync.
Egenskapen DefaultRequestVersionGäller inte för SendAsync-metoden。 Parametern HttpRequestMessage som skickas till SendAsync-metoden som parameter har sin egen versionegenskap som styr den HTTP-version som används för förfrågan.
Länk:Inloggningen med hyperlänken är synlig.
HttpVersionPolicy förhandlingspolicy
RequestVersionOrLower: Använd den begärda versionen, eller nedgradera till en lägre version (men inte högre än den begärda versionen). Detta är standardbeteendet. Enkelt uttryckt är den mest använda protokollversionen den nuvarande versionen, och om den nuvarande protokollversionen inte stöds kommer den att nedgraderas.
RequestVersionOrHigher: Använd den version som servern stödjer, men inte lägre än den begärda versionen. Det vill säga, uppgraderingar är tillåtna, och nedgraderingar under den begärda versionen är inte tillåtna. Enkelt uttryckt, använd protokoll i högre version för kommunikation när det är möjligt.
RequestVersionExact: Använd strikt den önskade versionen, inga uppgraderingar eller nedgraderingar är tillåtna.
HttpClient använder protokollet för Http/2.0-versionen
Testkoden är följande:
Förfrågan använder version 1.1, och den slutgiltiga klienten och servern förhandlar om att använda 2.0-protokollet för kommunikation, så det slutgiltiga svaret är version 2.0, som visas i figuren nedan:
Hänvisning:
Inloggningen med hyperlänken är synlig.
Inloggningen med hyperlänken är synlig.
Inloggningen med hyperlänken är synlig. |
Publicerad den 2025-8-31 21:16:47
|
|
|
|
Hyresvärd|
Publicerad den 2025-8-31 21:46:27
|
