Requisiti: La maggior parte dei siti web ora utilizza principalmente i protocolli Http/1.1 e Http/2.0; per i siti che supportano solo la versione HTTP/2, usare HttpClient per inviare richieste di default, viene inviato System.Net.Http.Http.Http.HttpRequestException: Si è verificato un errore durante l'invio della richiesta. ---> System.IO.IOException: Impossibile leggere dati dalla connessione di trasporto: Il software nel tuo host ha interrotto una connessione stabilita. ---> System.Net.Sockets.SocketException (10053): Il software nel tuo host interrompe una connessione già stabilita. at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(errore Socket, booleano forAsyncThrow).
Storia del protocollo HTTP
Linea temporale
HTTP/0.9
L'obsoleto HTTP/0.9 fu la prima versione del protocollo HTTP, nata nel 1989. È estremamente semplice, permette al client di inviare una richiesta GET e non supporta l'intestazione della richiesta. Poiché non esiste un'intestazione di protocollo, HTTP/0.9 può supportare solo un tipo di contenuto: il testo semplice. Il server può rispondere solo a stringhe in formato HTML, non in altri formati. Quando il server termina di inviare, la connessione TCP viene chiusa.
HTTP/0.9 ha una tipica privazione di stato, in cui ogni visita viene elaborata indipendentemente e disconnessa una volta completata l'elaborazione. Se la pagina richiesta non esiste, non vengono restituiti codici di errore.
HTTP/1
HTTP/1 è un termine collettivo per HTTP 1.0 e HTTP 1.1, che si riferisce alle versioni del protocollo HTTP rispettivamente 1.0 e 1.1.
HTTP 1.0 è stata la seconda versione del protocollo HTTP ed è ancora oggi ampiamente adottata. Ha apportato numerosi miglioramenti e miglioramenti basati su HTTP/0.9, tra cui:
Più formati come immagini, video e binari possono essere inviati oltre al semplice testo
Oltre a e sono stati aggiunti metodi di richiesta POST
Ho cambiato il formato delle richieste e risposte HTTP. Oltre alla parte dati, ogni comunicazione deve includere un'intestazione HTTP che descriva alcuni metadati, cioè viene aggiunta l'intestazione della richiesta
Funzionalità aggiunte come codice di stato delle risposte, supporto multi-carattere, autorizzazione, cache e codifica dei contenuti
Sebbene sia ancora un protocollo senza stato, le connessioni lunghe possono essere supportate aggiungendo l'intestazione "Connection: keep-alive" alla richiesta
HTTP 1.1
HTTP 1.1 è un protocollo standardizzato, e HTTP 1.1 elimina molte ambiguità e introduce diversi miglioramenti.
peculiarità
Elaborazione della cache, HTTP 1.1 introduce più politiche di controllo della cache, come Entity tag, If-Unmodified-Since, If-Match, If-None-Match, ecc., e più header di cache opzionali per controllare la policy della cache.
L'ottimizzazione della larghezza di banda e l'uso delle connessioni di rete introducono un intervallo nell'intestazione della richiesta, che consente di richiedere solo una parte della risorsa, cioè restituire il codice di stato 206, facilitando così agli sviluppatori la libera scelta di sfruttare appieno la larghezza di banda e i collegamenti, e possono usare Range e Content-Range per creare una funzione di ripresa dei breakpoint.
Gestione delle notifiche di errore, sono stati aggiunti 24 nuovi codici di stato di errore in HTTP 1.1.
Aggiungere l'intestazione Host consente di configurare nomi di dominio diversi su server con lo stesso indirizzo IP.
Supporta connessioni lunghe, HTTP 1.1 supporta connessioni lunghe, più richieste e risposte HTTP possono essere trasmesse su una connessione TCP, riducendo il consumo e il ritardo nell'istituzione e chiusura delle connessioni, e Connection:keep-alive è abilitato di default in HTTP 1.1, e i browser generali permettono di stabilire 6 link lunghi contemporaneamente per lo stesso nome di dominio.
È stata aggiunta la tecnologia di pipelining per permettere l'invio di una seconda richiesta prima che la prima risposta venga completamente inviata, per migliorare il blocco delle code, ma l'ordine delle risposte verrà comunque restituito nell'ordine delle richieste.
Supporta il chunking della risposta, impostando il Transfer-Encoding: chunked per chunked response, permettendo di suddividere i dati di risposta in più parti e il server può rilasciare il buffer il prima possibile per ottenere una velocità di risposta più rapida.
HTTP 2.0
HTTP 2.0 ha prestazioni migliori, e ora le pagine web stanno diventando sempre più complesse, evolvendosi persino in applicazioni uniche; la quantità di riproduzione multimediale, la dimensione degli script per migliorare l'interazione sono aumentate molto, e più dati vengono trasmessi tramite richieste HTTP, quindi HTTP 2.0 ha apportato molte ottimizzazioni per l'efficienza della rete.
peculiarità
La Binary Frame Splitting, HTTP 2.0, è un protocollo binario piuttosto che un protocollo testuale che suddivide tutte le informazioni trasmesse in messaggi e frame più piccoli e li codifica in formato binario.
Multiplexando, le richieste parallele possono essere elaborate nello stesso collegamento, tutti gli accessi con lo stesso nome di dominio provengono dalla stessa connessione TCP, i messaggi HTTP vengono suddivisi in frame indipendenti e il server ricompone i messaggi in base a identificatori e intestazioni, rimuovendo i vincoli di ordine e blocco in HTTP 1.1.
La compressione delle intestazioni, che spesso sono simili in una serie di richieste, elimina il costo di duplicazione e trasmissione di dati duplicati.
Nel push-lato server, il server può inviare proattivamente risorse al client senza una richiesta esplicita da parte del client.
HTTP 3.0
HTTP 3.0 è attualmente in fase di formulazione e test, è un nuovo protocollo HTTP in futuro, il protocollo HTTP 3.0 gira sopra il protocollo QUIC, si basa su UDP per ottenere una trasmissione affidabile, compromesso sulla velocità di trasmissione e l'affidabilità della trasmissione e ottimizzando, utilizzando UDP per evitare problemi di blocco della coda TCP e velocizzare la velocità di trasmissione di rete, ma deve anche ottenere un meccanismo di trasmissione affidabile, HTTP 3.0 non è un'estensione di HTTP 2.0, HTTP La 3.0 sarà un protocollo completamente nuovo.
HttpClientHandler VS SocketsHttpHandler
Il gestore di messaggi predefinito utilizzato da HttpClient nel .NET Framework e .NET Core 2.0 e precedenti è HttpClientHandler.
A partire da .NET Core 2.1, le classiSocketsHttpHandler fornisce una classe di rete HTTP di livello superiore(ad esempio HttpClient). L'uso di SocketsHttpHandler offre molti vantaggi:
Le prestazioni sono migliorate significativamente rispetto alle implementazioni precedenti.
Eliminare le dipendenze dalla piattaforma per semplificare il deployment e il servizio. Ad esempio, libcurl non dipende più da .NET Core per macOS e .NET Core per Linux.
Comportamento coerente su tutte le piattaforme .NET.
In .NET 9, HttpClientFactory utilizza SocketsHttpHandler come gestore principale
HttpClientFactory consente di configurare pipeline HttpClient per oggetti HttpMessageHandler nominati e tipizzati. Il gestore più interno, o il gestore che effettivamente invia richieste sulla rete, è chiamato gestore master. Se non configurato, questo handler era sempre stato un HttpClientHandler prima. Sebbene il gestore master predefinito siano i dettagli dell'implementazione, ci sono utenti che vi fanno affidamento. Ad esempio, alcuni utenti fanno cast del gestore principale nelle proprietà dell'impostazione HttpClientHandler come ClientCertificate, UseCookies e UseProxy.
Collegamento:Il login del link ipertestuale è visibile.
La configurazione globale richiede la versione del protocollo HTTP
Il codice è il seguente:
DefaultRequestVersionL'impostazione predefinita è HttpVersion.Version11。
La proprietà DefaultRequestVersion specifica la versione HTTP predefinita da utilizzare per le richieste inviate tramite questa istanza HttpClient, quando costruisce il messaggio HttpRequestMessage da inviare, in particolare chiamando 、、、GetStreamAsyncGetAsyncGetByteArrayAsync, PatchAsyncGetStringAsync, PostAsync e PutAsync.
Proprietà DefaultRequestVersionNon si applica al metodo SendAsync。 Il parametro HttpRequestMessage passato al metodo SendAsync come parametro ha una propria proprietà Version che controlla la versione HTTP utilizzata per la richiesta.
Collegamento:Il login del link ipertestuale è visibile.
HttpVersionPolicy politica di negoziazione
RichiestaVersioneOrInferiore: Usare la versione richiesta, oppure retrocedere a una versione inferiore (ma non superiore a quella richiesta). Questo è il comportamento predefinito. In termini semplici, la versione del protocollo più utilizzata è quella attuale e, se la versione attuale del protocollo non è supportata, verrà declassata.
RichiestaVersioneOSuperioreSuperiore: Utilizzare la versione più alta supportata dal server, ma non inferiore alla versione richiesta. Cioè, sono consentiti gli aggiornamenti e i downgrade al di sotto della versione richiesta non sono consentiti. In termini semplici, usa protocolli di versione superiore per la comunicazione ogni volta che è possibile.
RichiestaVersionesatezza: Usa rigorosamente la versione richiesta, non sono permessi upgrade o downgrade.
HttpClient utilizza il protocollo versione Http/2.0
Il codice di prova è il seguente:
La richiesta utilizza la versione 1.1, e client finale e server negoziano per usare il protocollo 2.0 per comunicare, quindi la risposta finale è la versione 2.0, come mostrato nella figura sottostante:
Riferimento:
Il login del link ipertestuale è visibile.
Il login del link ipertestuale è visibile.
Il login del link ipertestuale è visibile. |
Pubblicato il 31-08-2025 21:16:47
|
|
|
|
Padrone di casa|
Pubblicato il 31-08-2025 21:46:27
|
