Вимоги: Більшість сайтів зараз переважно використовують протоколи версій 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 для chunked response (chunked), що дозволяє розділити дані відповіді на кілька частин, а сервер може якнайшвидше звільнити буфер для швидшої швидкості відповіді.
HTTP 2.0
HTTP 2.0 має кращу продуктивність, і тепер веб-сторінки стають дедалі складнішими і навіть еволюціонують у унікальні додатки, обсяг відтворення медіа, розмір скриптів для покращення взаємодії також значно зросли, і більше даних передається через HTTP-запити, тому HTTP 2.0 зробив багато оптимізацій для ефективності мережі.
особливість
Розділення бінарних кадрів, HTTP 2.0 — це двійковий протокол, а не текстовий протокол, який розбиває всю передану інформацію на менші повідомлення та кадри та кодує їх у бінарному форматі.
Мультиплексування, паралельні запити можуть оброблятися в одному й тому ж посиланні, усі доступи під одним доменним ім'ям здійснюються з одного TCP-з'єднання, HTTP-повідомлення розбиваються на незалежні кадри, а сервер збирає повідомлення відповідно до ідентифікаторів і заголовків, усуваючи обмеження порядку та блокування в HTTP 1.1.
Стиснення заголовків, які часто схожі у серії запитів, зменшує вартість дублювання та передачі дублікатів даних.
Серверний push дозволяє серверу проактивно передавати ресурси клієнту без явного запиту від клієнта.
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 і раніше, є HttpClientHandler.
Починаючи з .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.
Властивість DefaultRequestVersionНе застосовується до методу 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
|
