Wymagania: Większość stron internetowych obecnie głównie korzysta z protokołów wersji Http/1.1 i Http/2.0, natomiast strony obsługujące tylko wersję protokołu HTTP/2, domyślnie wysyłając żądania przez HttpClient, wyrzucają System.Net.Http.Http.HttpRequestException: Podczas wysyłania żądania wystąpił błąd. ---> System.IO.IOException: Nie można odczytać danych z połączenia transportowego: Oprogramowanie na Twoim hostze przerwało nawiązane połączenie. ---> System.Net.Sockets.SocketException (10053): Oprogramowanie na Twoim hostze przerywa nawiązanie połączenia. at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, boolean forAsyncThrow).
Historia protokołu HTTP
Oś czasu
HTTP/0.9
Przestarzały HTTP/0.9 był pierwszą wersją protokołu HTTP, narodzoną w 1989 roku. Jest niezwykle prosty, pozwala klientowi wysłać żądanie GET i nie obsługuje nagłówka żądania. Ponieważ nie ma nagłówka protokołu, HTTP/0.9 może obsługiwać tylko jeden typ treści – tekst zwykły. Serwer może odpowiadać tylko na ciągi znaków w formacie HTML, a nie w innych formatach. Po zakończeniu wysyłania przez serwer połączenie TCP zostaje zamknięte.
HTTP/0.9 charakteryzuje się typową bezstanowością, gdzie każda wizyta jest przetwarzana niezależnie i rozłączana po zakończeniu przetwarzania. Jeśli żądana strona nie istnieje, nie zwraca się kodów błędów.
HTTP/1
HTTP/1 to zbiorcze określenie HTTP 1.0 i HTTP 1.1, które odnosi się do wersji protokołu HTTP odpowiednio 1.0 i 1.1.
HTTP 1.0 był drugą wersją protokołu HTTP i jest szeroko stosowany do dziś. Wprowadził szereg ulepszeń i ulepszeń opartych na HTTP/0.9, w tym:
Można wysyłać więcej formatów, takich jak obrazy, filmy, pliki binarne poza samym tekstem
Dodatkowo dodano metody POST request
Zmieniono format zapytań i odpowiedzi HTTP. Oprócz części danych, każda komunikacja musi zawierać nagłówek HTTP opisujący niektóre metadane, czyli dodane są informacje o nagłówku żądania
Dodano funkcje takie jak kod statusu odpowiedzi, wsparcie dla wieloznakowych zestawów, autoryzacja, pamięć podręczna i kodowanie treści
Chociaż nadal jest to protokół bezstanowy, długie połączenia można obsłużyć, dodając do żądania nagłówek "Connection: keep-alive"
HTTP 1.1
HTTP 1.1 to ustandaryzowany protokół, a HTTP 1.1 eliminuje wiele niejasności i wprowadza kilka usprawnień.
Osobliwością
Przetwarzanie pamięci podręcznej, HTTP 1.1 wprowadza więcej polityk kontroli pamięci podręcznej, takich jak Entity tag, If-Unmodified-Since (Od czasu), If-Match, If-None-Match itd., oraz więcej opcjonalnych nagłówków cache do kontroli polityki cache.
Optymalizacja przepustowości i wykorzystanie połączeń sieciowych wprowadzają zakres w nagłówku żądania, który pozwala na żądanie tylko jednej części zasobu, czyli zwracanie kodu statusu 206, co ułatwia deweloperom swobodne wykorzystanie przepustowości i łączy oraz możliwość użycia zakresu i zakresu treści do stworzenia funkcji wznowienia punktu przerwania.
Zarządzanie powiadomieniami o błędach, dodano 24 nowe kody statusu błędów w HTTP 1.1.
Dodanie nagłówka Host pozwala na konfigurację różnych nazw domen na serwerach z tym samym adresem IP.
Obsługuje długie połączenia, HTTP 1.1 obsługuje długie połączenia, wiele żądań i odpowiedzi HTTP może być przesyłanych przez połączenie TCP, co zmniejsza zużycie i opóźnienie nawiązywania i zamykania połączeń, a Connection:keep-alive jest domyślnie włączony w HTTP 1.1, a ogólne przeglądarki pozwalają na jednoczesne nawiązywanie 6 długich łączy dla tej samej domeny.
Dodano technologię pipeliningu, która pozwala na wysłanie drugiego żądania przed pełnym wysłaniem pierwszej, aby poprawić blokowanie kolejek, ale kolejność odpowiedzi nadal będzie zwracana w kolejności żądań.
Wspieraj chunkowanie odpowiedzi, ustawiając Transfer-Encoding: chunked dla chunked response, co pozwala na podział danych odpowiedzi na wiele części, a serwer może zwolnić bufor tak szybko, jak to możliwe, aby uzyskać szybszą odpowiedź.
HTTP 2.0
HTTP 2.0 ma lepszą wydajność, a strony internetowe stają się coraz bardziej złożone, a nawet ewoluują w unikalne aplikacje, znacznie wzrosła ilość odtwarzania multimediów, rozmiar skryptów poprawiających interakcję, a więcej danych jest przesyłanych przez żądania HTTP, więc HTTP 2.0 wprowadził wiele optymalizacji pod kątem efektywności sieci.
Osobliwością
Binary Frame Splitting, HTTP 2.0 to protokół binarny, a nie tekstowy, który dzieli wszystkie przesyłane informacje na mniejsze wiadomości i ramki i koduje je w formacie binarnym.
Multipleksowanie, żądania równoległe mogą być przetwarzane w tym samym łączu, wszystkie dostępy pod tą samą domeną pochodzą z tego samego połączenia TCP, wiadomości HTTP są rozdzielane na niezależne ramki, a serwer składa wiadomości na nowo według identyfikatorów i nagłówków, usuwając ograniczenia kolejności i blokowania w HTTP 1.1.
Kompresowanie nagłówków, które często są podobne w serii żądań, eliminuje koszt duplikacji i przesyłania duplikatów danych.
Serwer może proaktywnie przesyłać zasoby do klienta bez wyraźnych żądań ze strony klienta.
HTTP 3.0
HTTP 3.0 jest obecnie w fazie formułowania i testowania, jest nowym protokołem HTTP w przyszłości, protokół HTTP 3.0 zakłada protokół QUIC, opiera się na UDP, aby osiągnąć niezawodną transmisję, kompromis między prędkością i niezawodnością transmisji oraz optymalizacją. Wykorzystanie UDP pozwoli uniknąć problemu blokowania kolejek TCP i przyspieszy prędkość transmisji sieciowej, ale także wymaga zapewnienia niezawodnego mechanizmu transmisji. HTTP 3.0 nie jest rozszerzeniem HTTP 2.0 3.0 będzie zupełnie nowym protokołem.
HttpClientHandler VS SocketsHttpHandler
Domyślnym handlerem wiadomości używanym przez HttpClient w .NET Framework, .NET Core 2.0 i wcześniejszych jest HttpClientHandler.
Zaczynając od .NET Core 2.1, klasySocketsHttpHandler oferuje wyższy poziom klasy sieci HTTP(np. HttpClient). Korzystanie z SocketsHttpHandler oferuje wiele zalet:
Wydajność znacznie się poprawiła w porównaniu z poprzednimi implementacjami.
Eliminacja zależności platform, aby uprościć wdrożenie i obsługę. Na przykład libcurl nie zależy już od .NET Core dla macOS i .NET Core dla Linuksa.
Spójne zachowanie na wszystkich platformach .NET.
W .NET 9 HttpClientFactory używa SocketsHttpHandler jako głównego handlera
HttpClientFactory umożliwia konfigurację potoków HttpClient dla nazwanych i typowanych obiektów HttpMessageHandler. Najbardziej wewnętrzny handler lub handler, który faktycznie wysyła żądania w sieci, nazywany jest handlerem głównym. Jeśli nie był skonfigurowany, ten handler zawsze był wcześniej HttpClientHandlerem. Chociaż domyślnym głównym handlerem są szczegóły implementacyjne, są też użytkownicy, którzy na nim polegają. Na przykład niektórzy użytkownicy przypisują główny handler do właściwości ustawień HttpClientHandler, takich jak ClientCertificates, UseCookies i UseProxy.
Łącze:Logowanie do linku jest widoczne.
Konfiguracja globalna żąda wersji protokołu HTTP
Kod jest następujący:
DefaultRequestVersionDomyślne ustawienie to HttpVersion.Version11。
Właściwość DefaultRequestVersion określa domyślną wersję HTTP do żądań wysyłanych za pomocą tej instancji HttpClient, gdy konstruuje HttpRequestMessage do wysłania, konkretnie przez wywołanie 、、、GetStreamAsyncGetAsyncGetByteArrayAsync, PatchAsyncGetStringAsync, PostAsync i PutAsync.
Własność DefaultRequestVersionNie dotyczy metody SendAsync。 Parametr HttpRequestMessage przekazany metodzie SendAsync jako parametr ma własną właściwość Version, która kontroluje wersję HTTP używaną dla żądania.
Łącze:Logowanie do linku jest widoczne.
Polityka negocjacji HttpVersionPolicy
RequestVersionOrLower: Użyj żądanej wersji lub obniż do niższej wersji (ale nie wyższej niż wymagana wersja). To jest domyślne zachowanie. Mówiąc prosto, najczęściej używaną wersją protokołu jest obecna wersja, a jeśli obecna wersja protokołu nie jest obsługiwana, zostanie ona obniżona.
RequestVersionOrHigher: Używaj najwyższej wersji obsługiwanej przez serwer, ale nie niższej niż żądana wersja. To znaczy, ulepszenia są dozwolone, a cofnięcia poniżej żądanej wersji nie są dozwolone. Mówiąc prosto, używaj protokołów wyższych wersji do komunikacji, kiedy tylko to możliwe.
RequestVersionExact: Ściśle używaj żądanej wersji, nie wolno dokonywać ulepszeń ani cofania poziomu.
HttpClient korzysta z protokołu wersji Http/2.0
Kod testu jest następujący:
Żądanie korzysta z wersji 1.1, a ostateczny klient i serwer negocjują użycie protokołu 2.0 do komunikacji, więc ostateczna odpowiedź to wersja 2.0, jak pokazano na poniższym rysunku:
Odniesienie:
Logowanie do linku jest widoczne.
Logowanie do linku jest widoczne.
Logowanie do linku jest widoczne. |
Opublikowano 2025-8-31 21:16:47
|
|
|
|
Ziemianin|
Opublikowano 31.08.2025 21:46:27
|
