Zahteve: Večina spletnih strani zdaj večinoma uporablja protokole različic Http/1.1 in Http/2.0, za spletne strani, ki podpirajo le različico protokola HTTP/2, uporaba HttpClient za pošiljanje zahtevkov privzeto vrže System.Net.Http.Http.HttpRequestException: Med pošiljanjem zahteve je prišlo do napake. ---> System.IO.IOException: Ni mogoče prebrati podatkov s transportne povezave: Programska oprema na vašem gostitelju je prekinila vzpostavljeno povezavo. ---> System.Net.Sockets.SocketException (10053): Programska oprema v vašem gostitelju prekine vzpostavljeno povezavo. at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, Boolean forAsyncThrow).
Zgodovina HTTP protokola
Časovnica
HTTP/0.9
Zastareli HTTP/0.9 je bila prva različica HTTP protokola, nastala leta 1989. Je izjemno preprost, saj odjemalcu omogoča pošiljanje GET zahteve in ne podpira glave zahteve. Ker ni protokolne glave, HTTP/0.9 podpira le eno vrsto vsebine – navadno besedilo. Strežnik lahko odgovarja le na nize v HTML formatu, ne pa na druge formate. Ko strežnik konča pošiljanje, se TCP povezava zapre.
HTTP/0.9 ima tipično brezstanje, kjer se vsak obisk obdeluje neodvisno in po končani obdelavi prekine. Če zahtevane strani ni, se kode napak ne vrnejo.
HTTP/1
HTTP/1 je skupni izraz za HTTP 1.0 in HTTP 1.1, ki se nanaša na različici HTTP protokola, ki sta 1.0 in 1.1.
HTTP 1.0 je bila druga različica HTTP protokola in je še danes široko sprejeta. Na osnovi HTTP/0.9 je izvedel številne izboljšave in izboljšave, med drugim:
Več formatov, kot so slike, videoposnetki, binarne datoteke, je mogoče poslati onkraj zgolj besedila
Poleg tega so dodane tudi metode za POST zahteve
Spremenili smo format HTTP zahtevkov in odgovorov. Poleg podatkovnega dela mora vsaka komunikacija vsebovati HTTP glavo, ki opisuje nekatere metapodatke, tj. dodane so informacije o glavi zahteve
Dodane funkcije, kot so koda statusa odziva, podpora za večznakovne nize, avtorizacija, predpomnilnik in kodiranje vsebin
Čeprav je še vedno protokol brez stanja, je mogoče podpreti dolge povezave z dodajanjem glave "Connection: keep-alive" v zahtevo
HTTP 1.1
HTTP 1.1 je standardiziran protokol, HTTP 1.1 pa odpravi veliko nejasnosti in uvaja več izboljšav.
Posebnost
Obdelava predpomnilnika, HTTP 1.1 uvaja več politik nadzora predpomnilnika, kot so Entity tag, If-Unmodified-Since , If-Match, If-None-Match itd., ter več opcijskih glav predpomnilnika za nadzor politike predpomnilnika.
Optimizacija pasovne širine in uporaba omrežnih povezav uvajata razpon v glavi zahteve, ki omogoča zahtevo le enega dela vira, torej vrnitve statusne kode 206, kar razvijalcem olajša svobodno izbiro za polno uporabo pasovne širine in povezav ter lahko uporabijo Range in Content-Range za ustvarjanje funkcije za obnovitev prelomne točke.
Upravljanje obvestil o napakah, v HTTP 1.1 je bilo dodanih 24 novih kod statusa napak.
Dodajanje glave Host omogoča konfiguracijo različnih domen na strežnikih z istim IP naslovom.
Podpira dolge povezave, HTTP 1.1 podpira dolge povezave, več HTTP zahtevkov in odgovorov se lahko prenaša prek TCP povezave, kar zmanjšuje porabo in zakasnitev vzpostavljanja in zapiranja povezav, Connection:keep-alive pa je privzeto omogočen v HTTP 1.1, splošni brskalniki pa omogočajo vzpostavitev 6 dolgih povezav hkrati za isto domeno.
Dodana je bila tehnologija cevovoda, ki omogoča pošiljanje druge zahteve pred popolnim pošiljanjem prvega odgovora, kar izboljša blokiranje čakalnih vrst, vendar se vrstni red odgovorov še vedno vrača po vrstnem redu zahtev.
Podprite razdeljevanje odzivov z nastavitvijo Transfer-Encoding: delno za razdeljen odziv, kar omogoča razdelitev podatkov odziva na več delov, strežnik pa lahko medpomnilnik sprosti čim prej za hitrejšo odzivnost.
HTTP 2.0
HTTP 2.0 ima boljšo zmogljivost, spletne strani postajajo vse bolj kompleksne in se celo razvijajo v edinstvene aplikacije, količina predvajanja medijev, velikost skript za izboljšanje interakcije se je prav tako močno povečala, več podatkov pa se prenaša prek HTTP zahtevkov, zato je HTTP 2.0 naredil veliko optimizacij za učinkovitost omrežja.
Posebnost
Binary Frame Splitting, HTTP 2.0 je binarni protokol, ne besedilni protokol, ki vse prenesene informacije razdeli na manjša sporočila in okvirje ter jih kodira v binarni obliki.
Multipleksirane, vzporedne zahteve je mogoče obdelovati v isti povezavi, vsi dostopi pod isto domeno so iz iste TCP povezave, HTTP sporočila so razdeljena na neodvisne okvirje, strežnik pa ponovno sestavi sporočila glede na identifikatorje in glave, s čimer odstrani omejitve vrstnega reda in blokiranja v HTTP 1.1.
Stiskanje glav, ki so pogosto podobne v seriji zahtev, odstrani stroške podvajanja in prenosa podvojenih podatkov.
Pri strežniškem potisku lahko strežnik proaktivno potiska vire odjemalcu brez izrecne zahteve odjemalca.
HTTP 3.0
HTTP 3.0 je trenutno v fazi oblikovanja in testiranja, je nov HTTP protokol v prihodnosti, HTTP 3.0 protokol teče na vrhu QUIC protokola, temelji na UDP za dosego zanesljivega prenosa, kompromis med hitrostjo prenosa in zanesljivostjo prenosa ter optimizacijo. Uporaba UDP bo preprečila težave z blokiranjem TCP čakalnih vrst in pospešila hitrost prenosa v omrežju, hkrati pa je potrebna tudi zanesljiva prenosna mehanika. HTTP 3.0 ni razširitev HTTP 2.0, HTTP 3.0 bo povsem nov protokol.
HttpClientHandler VS SocketsHttpHandler
Privzeti obdelovalnik sporočil, ki ga uporablja HttpClient v .NET Frameworku in .NET Core 2.0 ter starejših, je HttpClientHandler.
Začenši z .NET Core 2.1, razrediSocketsHttpHandler zagotavlja višji razred HTTP omrežij(npr. HttpClient). Uporaba SocketsHttpHandler ponuja številne prednosti:
Zmogljivost se je bistveno izboljšala v primerjavi s prejšnjimi implementacijami.
Odpravite odvisnosti platform, da poenostavite uvajanje in storitev. Na primer, libcurl ni več odvisen od .NET Core za macOS in .NET Core za Linux.
Dosledno vedenje na vseh .NET platformah.
V .NET 9 HttpClientFactory uporablja SocketsHttpHandler kot glavni handler
HttpClientFactory omogoča konfiguracijo HttpClient cevovodov za poimenovane in tipizirane objekte HttpMessageHandler. Najbolj notranji handler ali handler, ki dejansko pošilja zahteve v omrežju, imenujemo master handler. Če ni konfiguriran, je bil ta handler prej vedno HttpClientHandler. Čeprav je privzeti glavni upravljalnik podrobnosti implementacije, obstajajo uporabniki, ki se nanj zanašajo. Na primer, nekateri uporabniki glavni handler prenesejo na lastnosti nastavitev HttpClientHandler, kot so ClientCertificates, UseCookies in UseProxy.
Povezava:Prijava do hiperpovezave je vidna.
Globalna konfiguracija zahteva različico protokola HTTP
Koda je naslednja:
DefaultRequestVersionPrivzeta nastavitev je HttpVersion.Version11。
Lastnost DefaultRequestVersion določa privzeto različico HTTP, ki se uporablja za zahteve, poslane s to instanco HttpClient, ko sestavi HttpRequestMessage za pošiljanje, natančneje z klicem 、、、GetStreamAsyncGetAsyncGetByteArrayAsync, PatchAsyncGetStringAsync, PostAsync in PutAsync.
Lastnost DefaultRequestVersionNe velja za metodo SendAsync。 Parameter HttpRequestMessage, ki se kot parameter posreduje metodi SendAsync, ima svojo lastnost Version, ki nadzoruje HTTP različico, uporabljeno za zahtevo.
Povezava:Prijava do hiperpovezave je vidna.
Politika pogajanj HttpVersionPolicy
RequestVersionOrLower: Uporabite zahtevano različico ali znižajte različico na nižjo različico (vendar ne višjo od zahtevane različice). To je privzeto vedenje. Preprosto povedano, najbolj uporabljena različica protokola je trenutna različica, in če trenutna različica protokola ni podprta, bo ta znižana.
RequestVersionOrHigher: Uporabite najvišjo različico, ki jo podpira strežnik, vendar ne nižjo od zahtevane različice. To pomeni, da so nadgradnje dovoljene, nadgradnje pod zahtevano različico pa niso dovoljene. Preprosto povedano, kadar je mogoče, uporabljajte protokole višjih različic za komunikacijo.
RequestVersionExact: Strogo uporabljajte zahtevano različico, nadgradnje ali nadomeščanja niso dovoljena.
HttpClient uporablja protokol različice Http/2.0
Testna koda je naslednja:
Zahteva uporablja različico 1.1, končni odjemalec in strežnik pa se dogovorita za uporabo protokola 2.0 za komunikacijo, zato je končni odgovor različica 2.0, kot je prikazano na spodnji sliki:
Referenčni:
Prijava do hiperpovezave je vidna.
Prijava do hiperpovezave je vidna.
Prijava do hiperpovezave je vidna. |
Objavljeno 31. 8. 2025 ob 21:16:47
|
|
|
|
Najemodajalec|
Objavljeno 31. 8. 2025 ob 21:46:27
|
