Cerințe: Majoritatea site-urilor folosesc acum în principal protocoalele versiune Http/1.1 și Http/2.0, pentru site-urile care suportă doar versiunea protocolului HTTP/2, folosind HttpClient pentru a trimite cereri implicit, va afișa System.Net.Http.Http.HttpRequestException: A apărut o eroare în timpul trimiterii cererii. ---> System.IO.IOException: Imposibilitatea de a citi date de la conexiunea de transport: Software-ul din gazda ta a întrerupt o conexiune stabilită. ---> System.Net.Sockets.SocketException (10053): Software-ul din gazda ta întrerupe o conexiune deja existentă. la System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, boolean forAsyncThrow).
Istoricul protocolului HTTP
Cronologie
HTTP/0.9
Învechitul HTTP/0.9 a fost prima versiune a protocolului HTTP, născută în 1989. Este extrem de simplă, permițând clientului să trimită o cerere GET și nu suportă antetul cererii. Deoarece nu există un antet de protocol, HTTP/0.9 poate suporta doar un singur tip de conținut – text simplu. Serverul poate răspunde doar la șiruri în format HTML, nu și în alte formate. Când serverul termină de trimis, conexiunea TCP este închisă.
HTTP/0.9 are o stare tipică fără stare, în care fiecare vizită este procesată independent și deconectată când procesarea este finalizată. Dacă pagina solicitată nu există, nu sunt returnate coduri de eroare.
HTTP/1
HTTP/1 este un termen colectiv pentru HTTP 1.0 și HTTP 1.1, care se referă la versiunile protocolului HTTP 1.0 și respectiv 1.1.
HTTP 1.0 a fost a doua versiune a protocolului HTTP și este adoptat pe scară largă și astăzi. A realizat o serie de îmbunătățiri și îmbunătățiri bazate pe HTTP/0.9, inclusiv:
Mai multe formate, precum imagini, videoclipuri, binare, pot fi trimise dincolo de simpla textură
Peste și au fost adăugate metode de cerere POST
S-a schimbat formatul cererilor și răspunsurilor HTTP. Pe lângă partea de date, fiecare comunicare trebuie să includă un antet HTTP care descrie anumite metadate, adică se adaugă informații despre antetul cererii
Funcții adăugate precum codul de stare a răspunsului, suportul pentru seturi multi-caractere, autorizare, cache și codificare de conținut
Deși este încă un protocol fără stare, conexiunile lungi pot fi suportate prin adăugarea antetului "Connection: keep-alive" la cerere
HTTP 1.1
HTTP 1.1 este un protocol standardizat, iar HTTP 1.1 elimină multă ambiguitate și introduce mai multe îmbunătățiri.
Particularitate
Procesarea cache-ului, HTTP 1.1 introduce mai multe politici de control al cache-ului, cum ar fi eticheta entității, If-Unmodified-Since, If-Match, If-None-Match etc., precum și mai multe antete de cache opționale pentru a controla politica cache-ului.
Optimizarea lățimii de bandă și utilizarea conexiunilor de rețea introduc un interval în antetul cererii, care permite solicitarea unei singure părți a resursei, adică returnarea codului de stare 206, ceea ce facilitează pentru dezvoltatori alegerea liberă de a folosi pe deplin lățimea de bandă și legăturile și pot folosi Range și Content-Range pentru a crea o funcție de reluare a punctelor de întrerupere.
Gestionarea notificărilor de eroare, au fost adăugate 24 de coduri noi de stare de eroare în HTTP 1.1.
Adăugarea antetului Host permite configurarea unor nume de domenii diferite pe servere cu aceeași adresă IP.
Suportă conexiuni lungi, HTTP 1.1 suportă conexiuni lungi, mai multe cereri și răspunsuri HTTP pot fi transmise pe o conexiune TCP, reducând consumul și întârzierea stabilirii și închiderii conexiunilor, iar Connection:keep-alive este activat implicit în HTTP 1.1, iar browserele generale permit stabilirea a 6 legături lungi simultan pentru același nume de domeniu.
S-a adăugat tehnologie de pipelining pentru a permite trimiterea unei a doua cereri înainte ca primul răspuns să fie trimis complet, pentru a îmbunătăți blocarea cozilor, dar ordinea răspunsurilor va fi totuși returnată în ordinea cererilor.
Suportă fragmentarea răspunsului, prin setarea Transfer-Encoding: chunked pentru chunked response, permițând divizarea datelor de răspuns în mai multe părți, iar serverul poate elibera buffer-ul cât mai curând posibil pentru a obține o viteză de răspuns mai rapidă.
HTTP 2.0
HTTP 2.0 are performanțe mai bune, iar acum paginile web devin din ce în ce mai complexe și chiar evoluează în aplicații unice, cantitatea de redare media, dimensiunea scripturilor pentru îmbunătățirea interacțiunii a crescut considerabil, iar mai multe date sunt transmise prin cereri HTTP, astfel că HTTP 2.0 a făcut multe optimizări pentru eficiența rețelei.
Particularitate
Binary Frame Splitting, HTTP 2.0 este un protocol binar, nu un protocol text, care împarte toate informațiile transmise în mesaje și cadre mai mici și le codifică în format binar.
Prin multiplexare, cererile paralele pot fi procesate în aceeași legătură, toate accesurile sub același nume de domeniu provin din aceeași conexiune TCP, mesajele HTTP sunt împărțite în cadre independente, iar serverul reasamblează mesajele conform identificatorilor și anteturilor, eliminând ordinea și blocând constrângerile în HTTP 1.1.
Comprimarea anteturilor, care sunt adesea similare într-o serie de cereri, elimină costul duplicării și transmiterii datelor duplicate.
La push-ul pe partea de server, serverul poate trimite proactiv resurse către client fără o solicitare explicită din partea acestuia.
HTTP 3.0
HTTP 3.0 este în prezent în faza de formulare și testare, este un nou protocol HTTP în viitor, HTTP 3.0 rulează peste protocolul QUIC, se bazează pe UDP pentru a obține transmisie fiabilă, schimbând viteza de transmisie și fiabilitatea transmisiei și optimizare, folosind UDP va evita problema blocării cozii TCP și va accelera viteza de transmisie în rețea, dar este necesar să se asigure un mecanism de transmisie fiabil, HTTP 3.0 nu este o extensie a HTTP 2.0, HTTP 3.0 va fi un protocol complet nou.
HttpClientHandler VS SocketsHttpHandler
Managerul implicit de mesaje folosit de HttpClient în .NET Framework și .NET Core 2.0 și versiunile anterioare este HttpClientHandler.
Începând cu .NET Core 2.1, cursuriSocketsHttpHandler oferă o clasă de rețea HTTP de nivel superior(de exemplu, HttpClient). Utilizarea SocketsHttpHandler oferă multe avantaje:
Performanța s-a îmbunătățit semnificativ comparativ cu implementările anterioare.
Eliminați dependențele de platformă pentru a simplifica implementarea și serviciul. De exemplu, libcurl nu mai depinde de .NET Core pentru macOS și .NET Core pentru Linux.
Comportament consecvent pe toate platformele .NET.
În .NET 9, HttpClientFactory folosește SocketsHttpHandler ca handler principal
HttpClientFactory permite configurarea pipeline-urilor HttpClient pentru obiecte HttpMessageHandler numite și tipare. Handler-ul cel mai intern sau handler-ul care trimite efectiv cereri pe rețea se numește handler principal. Dacă nu era configurat, acest handler era întotdeauna un HttpClientHandler înainte. Deși handler-ul principal implicit este detaliul implementării, există utilizatori care se bazează pe el. De exemplu, unii utilizatori castează handler-ul principal către proprietățile setării HttpClientHandler, cum ar fi ClientCertificate, UseCookies și UseProxy.
Legătură:Autentificarea cu hyperlink este vizibilă.
Configurația globală solicită versiunea protocolului HTTP
Codul este următorul:
DefaultRequestVersionSetarea implicită este HttpVersion.Version11。
Proprietatea DefaultRequestVersion specifică versiunea HTTP implicită care trebuie folosită pentru cererile trimise folosind această instanță HttpClient, atunci când construiește HttpRequestMessage de trimis, în special apelând 、、、GetStreamAsyncGetAsyncGetByteArrayAsync, PatchAsyncGetStringAsync, PostAsync și PutAsync.
Proprietatea DefaultRequestVersionNu se aplică metodei SendAsync。 Parametrul HttpRequestMessage transmis metodei SendAsync ca parametru are propria proprietate Version care controlează versiunea HTTP folosită pentru cerere.
Legătură:Autentificarea cu hyperlink este vizibilă.
HttpVersionPolitica de negociere a politicii
RequestVersionOrLower: Folosiți versiunea solicitată sau retrogradați la o versiune inferioară (dar nu mai sus decât versiunea solicitată). Acesta este comportamentul implicit. Pe scurt, cea mai folosită versiune de protocol este cea curentă, iar dacă versiunea curentă nu este suportată, va fi retrogradată.
RequestVersionOrHigher: Folosește cea mai înaltă versiune suportată de server, dar nu mai mică decât versiunea solicitată. Adică, upgrade-urile sunt permise, iar downgrade-urile sub versiunea solicitată nu sunt permise. Pe scurt, folosește protocoale de versiune superioară pentru comunicare ori de câte ori este posibil.
RequestVersionExact: Folosește strict versiunea solicitată, nu sunt permise upgrade-uri sau downgrade-uri.
HttpClient folosește protocolul versiune Http/2.0
Codul testului este următorul:
Cererea folosește versiunea 1.1, iar clientul final și serverul negociază să folosească protocolul 2.0 pentru comunicare, astfel încât răspunsul final este versiunea 2.0, așa cum este prezentat în figura de mai jos:
Referință:
Autentificarea cu hyperlink este vizibilă.
Autentificarea cu hyperlink este vizibilă.
Autentificarea cu hyperlink este vizibilă. |
Postat la 2025-8-31 21:16:47
|
|
|
|
Proprietarul|
Postat la 2025-8-31 21:46:27
|
