Exigences : La plupart des sites web utilisent désormais principalement les protocoles Http/1.1 et Http/2.0, pour les sites qui ne supportent que la version HTTP/2, utiliser HttpClient pour envoyer les requêtes par défaut affichera System.Net.Http.Http.Http.HttpRequestException : Une erreur s’est produite lors de l’envoi de la requête. ---> System.IO.IOException : Impossible de lire les données de la connexion de transport : Le logiciel de votre hôte a interrompu une connexion établie. ---> System.Net.Sockets.SocketException (10053) : Le logiciel de votre hôte interrompt une connexion établie. at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, booléen forAsyncThrow).
Histoire du protocole HTTP
Chronologie
HTTP/0.9
L’obsolète HTTP/0.9 fut la première version du protocole HTTP, née en 1989. C’est extrêmement simple, permettant au client d’envoyer une requête GET et ne prend pas en charge l’en-tête de requête. Comme il n’y a pas d’en-tête de protocole, HTTP/0.9 ne peut prendre en charge qu’un seul type de contenu : le texte brut. Le serveur ne peut répondre qu’aux chaînes de caractères au format HTML, pas dans d’autres formats. Lorsque le serveur a fini d’envoyer, la connexion TCP est fermée.
HTTP/0.9 présente une absence d’état typique, où chaque visite est traitée indépendamment et déconnectée une fois le traitement terminé. Si la page demandée n’existe pas, aucun code d’erreur n’est renvoyé.
HTTP/1
HTTP/1 est un terme collectif désignant HTTP 1.0 et HTTP 1.1, qui désigne respectivement les versions du protocole HTTP 1.0 et 1.1.
HTTP 1.0 était la deuxième version du protocole HTTP et est encore largement adopté aujourd’hui. Il a apporté un certain nombre d’améliorations et d’améliorations basées sur HTTP/0.9, notamment :
Plus de formats tels que des images, des vidéos, des binaires peuvent être envoyés au-delà du simple texte
En plus d’une méthode de requête POST a été ajoutée
Changement de format des requêtes et réponses HTTP. En plus de la partie données, chaque communication doit inclure un en-tête HTTP qui décrit certaines métadonnées, c’est-à-dire que l’information de l’en-tête de la requête est ajoutée
Fonctions ajoutées telles que le code d’état des réponses, la prise en charge des jeux multi-caractères, l’autorisation, le cache et l’encodage de contenu
Bien qu’il reste un protocole sans état, les connexions longues peuvent être prises en charge en ajoutant l’en-tête « Connection : keep-alive » à la requête
HTTP 1.1
HTTP 1.1 est un protocole standardisé, et HTTP 1.1 élimine beaucoup d’ambiguïté et introduit plusieurs améliorations.
particularité
Traitement du cache, HTTP 1.1 introduit davantage de politiques de contrôle du cache, telles que l’étiquette Entity, If-Unmodified-Since, If-Match, If-None-Match, etc., ainsi que davantage d’en-têtes de cache optionnelles pour contrôler la politique de cache.
L’optimisation de la bande passante et l’utilisation des connexions réseau introduisent une plage dans l’en-tête de requête, qui ne permet qu’une seule partie de la ressource d’être demandée, c’est-à-dire de retourner le code d’état 206, ce qui facilite aux développeurs le choix libre d’utiliser pleinement la bande passante et les liens, et peuvent utiliser Range et Content-Range pour créer une fonction de reprise de points d’arrêt.
Gestion des notifications d’erreur, 24 nouveaux codes d’état d’erreur ont été ajoutés en HTTP 1.1.
L’ajout de l’en-tête Host permet de configurer différents noms de domaine sur des serveurs avec la même adresse IP.
Prend en compte les connexions longues, HTTP 1.1 prend en charge les connexions longues, plusieurs requêtes et réponses HTTP peuvent être transmises sur une connexion TCP, réduisant la consommation et le délai d’établissement et de fermeture des connexions, et Connection :keep-alive est activé par défaut dans HTTP 1.1, et les navigateurs généraux permettent d’établir 6 liens longs simultanément pour le même nom de domaine.
Ajout de la technologie de pipeline pour permettre l’envoi d’une seconde requête avant que la première réponse ne soit entièrement envoyée afin d’améliorer le blocage de files d’attente, mais l’ordre des réponses sera toujours retourné dans l’ordre des requêtes.
Support le segment de réponse en définissant le Transfer-Encoding : chunked pour chunked response, permettant de diviser les données de réponse en plusieurs parties, et le serveur peut libérer le tampon dès que possible pour obtenir une vitesse de réponse plus rapide.
HTTP 2.0
HTTP 2.0 offre de meilleures performances, et désormais les pages web deviennent de plus en plus complexes, et évoluent même vers des applications uniques, la quantité de lecture média, la taille des scripts pour améliorer l’interaction ont également beaucoup augmenté, et plus de données sont transmises via des requêtes HTTP, donc HTTP 2.0 a apporté beaucoup d’optimisations pour l’efficacité du réseau.
particularité
La division binaire des trames, HTTP 2.0, est un protocole binaire plutôt qu’un protocole textuel qui divise toutes les informations transmises en messages et trames plus petits et les encode en format binaire.
Multiplexage, les requêtes parallèles peuvent être traitées dans le même lien, tous les accès sous le même nom de domaine proviennent de la même connexion TCP, les messages HTTP sont décomposés en trames indépendantes, et le serveur réassemble les messages selon les identifiants et les en-têtes, supprimant les contraintes d’ordre et de blocage dans HTTP 1.1.
La compression des en-têtes, souvent similaires dans une série de requêtes, supprime le coût de duplication et de transmission de données dupliquées.
Côté serveur, le serveur peut proactivement envoyer des ressources vers le client sans demande explicite du client.
HTTP 3.0
HTTP 3.0 est actuellement en phase de formulation et de test, c’est un nouveau protocole HTTP à venir, HTTP 3.0 fonctionne au-dessus du protocole QUIC, est basé sur UDP pour assurer une transmission fiable, un compromis entre vitesse de transmission et fiabilité et optimisation, utilisant UDP pour éviter le blocage de files d’attente TCP et accélérer la vitesse de transmission réseau, mais il doit aussi garantir un mécanisme de transmission fiable, HTTP 3.0 n’est pas une extension de HTTP 2.0, HTTP La 3.0 sera un protocole complètement nouveau.
HttpClientHandler VS SocketsHttpHandler
Le gestionnaire de messages par défaut utilisé par HttpClient dans le .NET Framework et .NET Core 2.0 et versions antérieures est HttpClientHandler.
À partir de .NET Core 2.1, classesSocketsHttpHandler fournit une classe réseau HTTP de niveau supérieur(par exemple HttpClient). L’utilisation de SocketsHttpHandler offre de nombreux avantages :
Les performances se sont nettement améliorées par rapport aux implémentations précédentes.
Éliminer les dépendances de la plateforme pour simplifier le déploiement et le service. Par exemple, libcurl ne dépend plus de .NET Core pour macOS et .NET Core pour Linux.
Comportement cohérent sur toutes les plateformes .NET.
Dans .NET 9, HttpClientFactory utilise SocketsHttpHandler comme gestionnaire principal
HttpClientFactory permet de configurer des pipelines HttpClient pour des objets HttpMessageHandler nommés et tapés. Le gestionnaire le plus interne ou le gestionnaire qui envoie effectivement les requêtes sur le réseau est appelé le gestionnaire maître. S’il n’était pas configuré, ce gestionnaire a toujours été un HttpClientHandler auparavant. Bien que le gestionnaire maître par défaut soit les détails de l’implémentation, certains utilisateurs s’y fient. Par exemple, certains utilisateurs distribuent le gestionnaire principal vers les propriétés de paramètre HttpClientHandler telles que ClientCertificates, UseCookies et UseProxy.
Lien:La connexion hyperlientérée est visible.
La configuration globale demande la version du protocole HTTP
Le code est le suivant :
DefaultRequestVersionLe réglage par défaut est HttpVersion.Version11。
La propriété DefaultRequestVersion spécifie la version HTTP par défaut à utiliser pour les requêtes envoyées via cette instance HttpClient, lorsqu’elle construit le message HttpRequestMessage à envoyer, spécifiquement en appelant 、、、GetStreamAsyncAsyncGetAsyncGetByteArrayAsync, PatchAsyncGetStringAsync, PostAsync et PutAsync.
Propriété DefaultRequestVersionCela ne s’applique pas à la méthode SendAsync。 Le paramètre HttpRequestMessage transmis à la méthode SendAsync en tant que paramètre possède sa propre propriété Version qui contrôle la version HTTP utilisée pour la requête.
Lien:La connexion hyperlientérée est visible.
Politique de négociation HttpVersionPolicy
RequestVersionOrLower: Utiliser la version demandée, ou rétrograder à une version inférieure (mais pas supérieure à la version demandée). C’est le comportement par défaut. En termes simples, la version de protocole la plus utilisée est la version actuelle, et si la version actuelle n’est pas prise en charge, elle sera rétrogradée.
DemandeVersionOuSupérieur: Utiliser la version la plus élevée prise en charge par le serveur, mais pas inférieure à la version demandée. C’est-à-dire que les mises à niveau sont autorisées, et les rétrogradations en dessous de la version demandée ne sont pas autorisées. En termes simples, utilisez des protocoles de version supérieure pour la communication dès que possible.
RequestVersionExact: Utilisez strictement la version demandée, aucune mise à niveau ou rétrogradation n’est autorisée.
HttpClient utilise le protocole de la version Http/2.0
Le code de test est le suivant :
La requête utilise la version 1.1, et le client final et le serveur négocient pour utiliser le protocole 2.0 afin de communiquer, donc la réponse finale est la version 2.0, comme montré dans la figure ci-dessous :
Référence:
La connexion hyperlientérée est visible.
La connexion hyperlientérée est visible.
La connexion hyperlientérée est visible. |
Publié le 31-08-2025 à 21:16:47
|
|
|
|
Propriétaire|
Publié le 31-08-2025 à 21:46:27
|
