Изисквания: Повечето уебсайтове сега основно използват протоколите на версиите Http/1.1 и Http/2.0, а за сайтове, които поддържат само версията на протокола HTTP/2, използвайки HttpClient за изпращане на заявки по подразбиране, ще издаде System.Net.Http.Http.HttpRequestException: Възникна грешка при изпращане на заявката. ---> System.IO.IOException: Не може да се чете данни от транспортната връзка: Софтуерът във вашия хост е прекъснал установена връзка. ---> System.Net.Sockets.SocketException (10053): Софтуерът във вашия хост прекъсва установена връзка. в System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, булев за AsyncThrow).
История на HTTP протокола
Хронология
HTTP/0.9
Остарялата HTTP/0.9 беше първата версия на HTTP протокола, създадена през 1989 г. Тя е изключително проста, позволявайки на клиента да изпрати заявка за GET и не поддържа заглавието на заявката. Тъй като няма заглавие на протокола, HTTP/0.9 може да поддържа само един тип съдържание – обикновен текст. Сървърът може да отговаря само на низове във формат HTML, но не и на други формати. Когато сървърът приключи с изпращането, TCP връзката се затваря.
HTTP/0.9 има типично безсъстояние, при което всяко посещение се обработва независимо и се прекъсва след приключване на обработката. Ако поисканата страница не съществува, не се връщат кодове за грешки.
HTTP/1
HTTP/1 е колективен термин за HTTP 1.0 и HTTP 1.1, който се отнася до версиите на HTTP протокола, които са съответно 1.0 и 1.1.
HTTP 1.0 беше втората версия на HTTP протокола и все още се използва широко днес. Тя е направила редица подобрения и подобрения, базирани на HTTP/0.9, включително:
Могат да се изпращат повече формати като изображения, видеа, бинарни файлове отвъд само текст
Освен това са добавени методи за заявки на POST
Променена е формата на HTTP заявките и отговорите. Освен частта с данните, всяка комуникация трябва да включва HTTP заглавие, което описва някои метаданни, т.е. се добавя информация за заглавието на заявката
Добавени са функции като код за статус на отговора, поддръжка на многознакови набори, авторизация, кеширане и кодиране на съдържание
Въпреки че все още е протокол без състояние, дългите връзки могат да се поддържат чрез добавяне на заглавие "Connection: keep-alive" към заявката
HTTP 1.1
HTTP 1.1 е стандартизиран протокол, а HTTP 1.1 премахва много неясноти и въвежда няколко подобрения.
Особеност
Кеш обработка, HTTP 1.1 въвежда повече политики за контрол на кеша, като Entity таг, If-Unmodified-Since, If-Match, If-None-Match и др., както и повече опционални кеш заглавия за контрол на кеш политиката.
Оптимизацията на пропускателната способност и използването на мрежови връзки въвеждат диапазон в заглавието на заявката, който позволява само една част от ресурса да бъде поискана, тоест да се върне кодът за статус 206, което улеснява разработчиците да избират свободно да използват пълна пропускателна способност и връзки, и могат да използват Range и Content-Range за създаване на функция за възобновяване на точка на прекъсване.
Управление на известия за грешки, добавени са 24 нови кода за статус на грешки в HTTP 1.1.
Добавянето на хедъра Host позволява конфигуриране на различни домейн имена на сървъри с един и същ IP адрес.
Поддържа дълги връзки, HTTP 1.1 поддържа дълги връзки, множество HTTP заявки и отговори могат да се предават по TCP връзка, което намалява консумацията и забавянето при установяване и затваряне на връзки, а Connection:keep-alive е активиран по подразбиране в HTTP 1.1, а обикновените браузъри позволяват установяване на 6 дълги връзки едновременно за едно и също домейн име.
Добавена е технология за конвейериране, която позволява изпращане на втора заявка преди първия отговор да бъде изпратена напълно, за да се подобри блокирането на опашките, но редът на отговорите все още ще се връща по реда на заявките.
Поддържайте разделяне на отговор, като зададете Transfer-Encoding: chunked for chunked response, позволявайки данните за отговор да бъдат разделени на няколко части, а сървърът може да освободи буфера възможно най-скоро, за да постигне по-бърза скорост на отговор.
HTTP 2.0
HTTP 2.0 има по-добра производителност, а сега уеб страниците стават все по-сложни и дори се развиват в уникални приложения, обемът на възпроизвеждане на медии, размерът на скриптовете за подобряване на взаимодействието също се увеличи значително, а повече данни се предават чрез HTTP заявки, така че HTTP 2.0 направи много оптимизации за мрежова ефективност.
Особеност
Разделяне на двоични кадри, HTTP 2.0 е двоичен протокол, а не текстов протокол, който разделя цялата предавана информация на по-малки съобщения и кадри и ги кодира в двоичен формат.
Мултиплексиращите паралелни заявки могат да се обработват в една и съща връзка, всички достъпи под едно и също домейн име са от една и съща TCP връзка, HTTP съобщенията се разделят на независими рамки, а сървърът сглобява съобщенията според идентификатори и заглавия, премахвайки ограниченията за реда и блокирането в HTTP 1.1.
Компресирането на заглавията, които често са сходни в серия от заявки, премахва разходите за дублиране и предаване на дублирани данни.
При сървърната страна сървърът може проактивно да изпраща ресурси към клиента без изрично искане от него.
HTTP 3.0
HTTP 3.0 в момента е в етап на формулиране и тестване, това е нов HTTP протокол в бъдеще, протоколът HTTP 3.0 работи върху протокола QUIC, базиран е на UDP за постигане на надеждна скорост на предаване, компромис между скоростта на предаване и надеждността на предаването и оптимизация. Използването на UDP ще избегне проблема с блокирането на опашката на TCP и ще ускори скоростта на предаване в мрежата, но също така трябва да постигне надежден механизъм за предаване, HTTP 3.0 не е разширение на HTTP 2.0, HTTP 3.0 ще бъде напълно нов протокол.
HttpClientHandler VS SocketsHttpHandler
Стандартният обработвач на съобщения, използван от HttpClient в .NET Framework и .NET Core 2.0 и по-стари, е HttpClientHandleler.
Започвайки с .NET Core 2.1, класовеSocketsHttpHandler предоставя по-високо ниво клас за HTTP мрежи(например HttpClient). Използването на SocketsHttpHandler предлага много предимства:
Производителността се е подобрила значително в сравнение с предишните имплементации.
Премахнете зависимостта от платформите, за да опростите внедряването и обслужването. Например, libcurl вече не разчита на .NET Core за macOS и .NET Core за Linux.
Последователно поведение във всички .NET платформи.
В .NET 9 HttpClientFactory използва SocketsHttpHandler като основен обработчик
HttpClientFactory позволява конфигуриране на HttpClient конвейери за именувани и типизирани HttpMessageHandler обекти. Най-вътрешният обработчик или обработвачът, който реално изпраща заявки в мрежата, се нарича главен обработващ оператор. Ако не беше конфигуриран, този обработчик винаги е бил HttpClientHandler преди. Докато стандартният главен обработчик е детайлите на имплементацията, има потребители, които разчитат на него. Например, някои потребители използват основния обработвач към свойствата на настройките на HttpClientHandler като ClientCertificates, UseCookies и UseProxy.
Връзка:Входът към хиперлинк е видим.
Глобалната конфигурация иска версията на HTTP протокола
Кодът е следният:
DefaultRequestVersionСтандартната настройка е HttpVersion.Version11。
Свойството DefaultRequestVersion определя стандартната HTTP версия, която да се използва за заявки, изпращани чрез този HttpClient инстанс, когато конструира HttpRequestMessage за изпращане, по-специално чрез извикване 、、、GetStreamAsyncGetAsyncGetAsyncGetByteArrayAsync, PatchAsyncGetStringAsync, PostAsync и PutAsync.
PropertyDefaultRequestVersionНе се прилага за метода SendAsync。 Параметърът HttpRequestMessage, предаден към метода SendAsync като параметър, има собствено свойство Version, което контролира HTTP версията, използвана за заявката.
Връзка:Входът към хиперлинк е видим.
Политика за преговори по HttpVersionPolicy
RequestVersionOrLower: Използвайте поисканата версия или намалете версията до по-ниска (но не по-висока от желаната). Това е стандартното поведение. С прости думи, най-често използваната версия на протокола е текущата, и ако текущата версия на протокола не се поддържа, тя ще бъде понижена.
RequestVersionOrHigher: Използвайте най-високата версия, поддържана от сървъра, но не по-ниска от поисканата версия. Тоест, ъпгрейди са позволени, а понижавания под желаната версия. С прости думи, използвайте по-високи версии на протоколи за комуникация, когато е възможно.
RequestVersionExact: Използвайте строго поисканата версия, не се допускат ъпгрейди или понижавания.
HttpClient използва протокола за версия Http/2.0
Тестовият код е следният:
Заявката използва версия 1.1, а последният клиент и сървър договарят да използват протокола 2.0 за комуникация, така че крайният отговор е версия 2.0, както е показано на фигурата по-долу:
Препратка:
Входът към хиперлинк е видим.
Входът към хиперлинк е видим.
Входът към хиперлинк е видим. |
Публикувано на 2025-8-31 21:16:47
|
|
|
|
Хазяин|
Публикувано на 2025-8-31 21:46:27
|
