|
|
Veröffentlicht am 31.8.2025, 21:16:47
|
|
|
|
Anforderungen: Die meisten Websites verwenden heute hauptsächlich die Protokolle der Versionen Http/1.1 und Http/2.0; für Websites, die nur die HTTP/2-Protokollversion unterstützen, wird standardmäßig System.Net.Http.Http.Http.HttpRequestException angezeigt: Beim Senden der Anfrage trat ein Fehler auf. ---> System.IO.IOException: Daten aus der Transportverbindung können nicht lesen: Die Software in Ihrem Host hat eine hergestellte Verbindung abgebrochen. ---> System.Net.Sockets.SocketException (10053): Software in Ihrem Host bricht eine hergestellte Verbindung ab. bei System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException (SocketError-Fehler, Boolean forAsyncThrow).
Geschichte des HTTP-Protokolls
Zeitstrahl
HTTP/0.9
Das veraltete HTTP/0.9 war die erste Version des HTTP-Protokolls, geboren 1989. Es ist extrem einfach, erlaubt es dem Client, eine GET-Anfrage zu senden, und unterstützt den Request-Header nicht. Da es keinen Protokollkopf gibt, kann HTTP/0.9 nur eine Art von Inhalt unterstützen – Klartext. Der Server kann nur auf Zeichenketten im HTML-Format antworten, nicht auf andere Formate. Wenn der Server mit dem Senden fertig ist, wird die TCP-Verbindung geschlossen.
HTTP/0.9 weist eine typische Zustandslosigkeit auf, bei der jeder Besuch unabhängig verarbeitet und nach Abschluss der Verarbeitung getrennt wird. Wenn die angeforderte Seite nicht existiert, werden keine Fehlercodes zurückgegeben.
HTTP/1
HTTP/1 ist ein Sammelbegriff für HTTP 1.0 und HTTP 1.1, der sich auf die Versionen des HTTP-Protokolls bezieht, die jeweils 1.0 und 1.1 sind.
HTTP 1.0 war die zweite Version des HTTP-Protokolls und wird bis heute weit verbreitet verwendet. Es hat eine Reihe von Verbesserungen und Verbesserungen auf Basis von HTTP/0.9 vorgenommen, darunter:
Mehr Formate wie Bilder, Videos und Binärdateien können über nur Text hinaus gesendet werden
Darüber hinaus wurden POST-Anfragemethoden hinzugefügt
Das Format der HTTP-Anfragen und -Antworten wurde geändert. Zusätzlich zum Datenteil muss jede Kommunikation einen HTTP-Header enthalten, der einige Metadaten beschreibt, d. h. die Informationen des Anfragekopfes werden hinzugefügt
Hinzugefügte Funktionen wie Antwortstatuscode, Unterstützung für mehrere Zeichensätze, Autorisierung, Cache und Inhaltskodierung
Obwohl es sich weiterhin um ein zustandsloses Protokoll handelt, können lange Verbindungen unterstützt werden, indem der Header "Connection: keep-alive" zur Anfrage hinzugefügt wird
HTTP 1.1
HTTP 1.1 ist ein standardisiertes Protokoll, und HTTP 1.1 beseitigt viele Unklarheiten und bringt mehrere Verbesserungen mit sich.
Besonderheit
Cache-Verarbeitung, HTTP 1.1 führt weitere Cache-Kontrollrichtlinien ein, wie Entity Tag, If-Unmodified-Since, If-Match, If-None-Match usw., sowie weitere optionale Cache-Header zur Steuerung der Cache-Policy.
Bandbreitenoptimierung und die Nutzung von Netzwerkverbindungen führen im Request-Header einen Bereich ein, der nur einen Teil der Ressource anfordern lässt, nämlich den 206-Statuscode zurückzugeben, was es Entwicklern erleichtert, die Bandbreite und Links frei zu nutzen, und Range sowie Content-Range nutzen können, um eine Breakpoint-Resumptionsfunktion zu erstellen.
Fehlerbenachrichtigungsverwaltung: In HTTP 1.1 wurden 24 neue Fehlerstatuscodes hinzugefügt.
Das Hinzufügen des Host-Headers ermöglicht es, verschiedene Domainnamen auf Servern mit derselben IP-Adresse zu konfigurieren.
Unterstützung für lange Verbindungen, HTTP 1.1 unterstützt lange Verbindungen, mehrere HTTP-Anfragen und -Antworten können auf einer TCP-Verbindung übertragen werden, was den Verbrauch und die Verzögerung beim Aufbau und Schließen von Verbindungen reduziert, und Connection:keep-alive ist in HTTP 1.1 standardmäßig aktiviert, und allgemeine Browser erlauben es, 6 lange Links gleichzeitig für denselben Domainnamen herzustellen.
Hinzugefügte Pipelining-Technologie, die es ermöglicht, eine zweite Anfrage zu senden, bevor die erste Antwort vollständig gesendet wird, um die Warteschlangenblockierung zu verbessern, aber die Reihenfolge der Antworten wird weiterhin in der Reihenfolge der Anfragen zurückgegeben.
Unterstützung von Response-Chunking, indem Transfer-Encoding: Chunked für Chunked Response gesetzt wird, wodurch die Antwortdaten in mehrere Teile aufgeteilt werden können, und der Server kann den Puffer so schnell wie möglich freigeben, um eine schnellere Reaktionsgeschwindigkeit zu erzielen.
HTTP 2.0
HTTP 2.0 hat eine bessere Leistung, und inzwischen werden Webseiten immer komplexer und entwickeln sich sogar zu einzigartigen Anwendungen – die Menge an Medienwiedergabe, die Größe der Skripte zur Verbesserung der Interaktion ist ebenfalls stark gestiegen, und mehr Daten werden über HTTP-Anfragen übertragen, sodass HTTP 2.0 viele Optimierungen zur Netzwerkeffizienz vorgenommen hat.
Besonderheit
Binary Frame Splitting, HTTP 2.0, ist ein binäres Protokoll und kein Textprotokoll, das alle übermittelten Informationen in kleinere Nachrichten und Rahmen aufteilt und diese im binären Format kodiert.
Durch Multiplexing können parallele Anfragen in derselben Verbindung verarbeitet werden, alle Zugriffe unter demselben Domainnamen stammen von derselben TCP-Verbindung, HTTP-Nachrichten werden in unabhängige Frames aufgeteilt, und der Server setzt die Nachrichten entsprechend Identifikatoren und Headern wieder zusammen, wodurch die Reihenfolge und Blockierungsbeschränkungen in HTTP 1.1 entfernt werden.
Das Komprimieren von Headern, die oft in einer Reihe von Anfragen ähnlich sind, beseitigt die Kosten für Duplikation und Übertragung duplizierter Daten.
Serverseitig kann der Server proaktiv Ressourcen an den Client weiterleiten, ohne dass der Client ausdrücklich angefordert wird.
HTTP 3.0
HTTP 3.0 befindet sich derzeit in der Formulierungs- und Testphase, ist ein neues HTTP-Protokoll in der Zukunft. Das HTTP 3.0-Protokoll läuft auf dem QUIC-Protokoll, basiert auf UDP, um zuverlässige Übertragung zu erreichen, Übertragungsgeschwindigkeit und Übertragungszuverlässigkeit abzuwägen und zu optimieren. Die Verwendung von UDP vermeidet TCP-Warteschlangenblockade und beschleunigt die Übertragungsgeschwindigkeit des Netzwerks, erfordert aber auch einen zuverlässigen Übertragungsmechanismus. HTTP 3.0 ist keine Erweiterung von HTTP 2.0, HTTP. 3.0 wird ein komplett neues Protokoll sein.
HttpClientHandler VS SocketsHttpHandler
Der Standard-Nachrichtenhandler, der von HttpClient im .NET Framework und .NET Core 2.0 und früher verwendet wird, ist HttpClientHandler.
Beginnend mit .NET Core 2.1, KurseSocketsHttpHandler bietet eine höherstufige HTTP-Netzwerkklasse(z. B. HttpClient). Die Nutzung von SocketsHttpHandler bietet viele Vorteile:
Die Leistung hat sich im Vergleich zu früheren Implementierungen deutlich verbessert.
Eliminieren Sie Plattformabhängigkeiten, um Bereitstellung und Service zu vereinfachen. Zum Beispiel ist libcurl nicht mehr auf .NET Core für macOS und .NET Core für Linux angewiesen.
Konsistentes Verhalten über alle .NET-Plattformen hinweg.
In .NET 9 verwendet HttpClientFactory SocketsHttpHandler als Haupthandler
HttpClientFactory ermöglicht die Konfiguration von HttpClient-Pipelines für benannte und typisierte HttpMessageHandler-Objekte. Der innerste Handler oder der Handler, der tatsächlich Anfragen im Netzwerk sendet, wird Master Handler genannt. Wenn nicht konfiguriert, war dieser Handler vorher immer ein HttpClientHandler. Während der Standard-Master-Handler die Implementierungsdetails sind, gibt es Nutzer, die darauf angewiesen sind. Zum Beispiel casten einige Benutzer den Haupthandler auf die Einstellungseigenschaften von HttpClientHandler wie ClientCertificates, UseCookies und UseProxy.
Verbinden:Der Hyperlink-Login ist sichtbar.
Die globale Konfiguration fordert die HTTP-Protokollversion an
Der Code lautet wie folgt:
DefaultRequestVersionDie Standardeinstellung ist HttpVersion.Version11。
Die Eigenschaft DefaultRequestVersion legt die Standard-HTTP-Version fest, die für Anfragen verwendet werden soll, die über diese HttpClient-Instanz gesendet werden, wenn sie die HttpRequestMessage zum Senden erstellt, speziell indem sie 、、、GetStreamAsyncGetAsyncGetAsyncGetGetByteArrayAsync, PatchAsyncGetStringAsync, aufruft, PostAsync und PutAsync.
DefaultRequestVersion-EigenschaftGilt nicht für die SendAsync-Methode。 Der HttpRequestMessage-Parameter, der als Parameter an die SendAsync-Methode übergeben wird, hat eine eigene Versionseigenschaft, die die HTTP-Version steuert, die für die Anfrage verwendet wird.
Verbinden:Der Hyperlink-Login ist sichtbar.
HttpVersionPolicy-Verhandlungspolitik
RequestVersionOrLower: Verwenden Sie die gewünschte Version oder gehen Sie auf eine niedrigere Version herunter (aber nicht höher als die gewünschte Version). Das ist das Standardverhalten. Einfach ausgedrückt ist die am häufigsten verwendete Protokollversion die aktuelle, und wenn die aktuelle Protokollversion nicht unterstützt wird, wird sie herabgestuft.
RequestVersionOrHigher: Verwenden Sie die vom Server höchste unterstützte Version, aber nicht niedrigere als die gewünschte Version. Das heißt, Upgrades sind erlaubt, und Downgrade unterhalb der gewünschten Version sind nicht erlaubt. Einfach ausgedrückt: Verwenden Sie nach Möglichkeit höherwertige Protokolle für die Kommunikation.
RequestVersionExact: Verwenden Sie ausschließlich die gewünschte Version, keine Upgrades oder Downgrades sind erlaubt.
HttpClient verwendet das Protokoll der Versionenversion Http/2.0
Der Testcode ist wie folgt:
Die Anfrage verwendet Version 1.1, und der endgültige Client und Server verhandeln, um das Protokoll 2.0 zur Kommunikation zu nutzen, sodass die endgültige Antwort Version 2.0 ist, wie in der untenstehenden Abbildung dargestellt:
Referenz:
Der Hyperlink-Login ist sichtbar.
Der Hyperlink-Login ist sichtbar.
Der Hyperlink-Login ist sichtbar. |
Vorhergehend:MinIO-Speicher (iii) Kopieren-hochladen (migrieren) lokale Dateien in den Minio-BucketNächster:.NET/C# wandelt PDFs basierend auf ImageMagick, GhostScript in Bilder um
|
Vermieter|
Veröffentlicht am 31.8.2025, 21:46:27
|
