|
|
Zveřejněno 31. 8. 2025 21:16:47
|
|
|
|
Požadavky: Většina webů nyní používá převážně protokoly verzí Http/1.1 a Http/2.0, pro weby, které podporují pouze verzi protokolu HTTP/2, používají HttpClient pro odesílání požadavků ve výchozím nastavení System.Net.Http.Http.HttpRequestException: Při odeslání požadavku došlo k chybě. ---> System.IO.IOException: Nelze číst data z transportního připojení: Software na vašem hostiteli přerušil navázané připojení. ---> System.Net.Sockets.SocketException (10053): Software na vašem hostiteli přeruší navázané spojení. at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, Boolean forAsyncThrow).
Historie HTTP protokolu
Časová osa
HTTP/0.9
Zastaralý HTTP/0.9 byl první verzí protokolu HTTP, která vznikla v roce 1989. Je to extrémně jednoduché, umožňuje klientovi odeslat požadavek GET a nepodporuje hlavičku požadavku. Protože neexistuje protokolová hlavička, HTTP/0.9 může podporovat pouze jeden typ obsahu – prostý text. Server může reagovat pouze na řetězce ve formátu HTML, nikoli na jiné formáty. Když server ukončí odesílání, TCP spojení je uzavřeno.
HTTP/0.9 má typický bezstavový stav, kdy je každá návštěva zpracovávána nezávisle a po dokončení zpracování je odpojena. Pokud požadovaná stránka neexistuje, nejsou vráceny žádné chybové kódy.
HTTP/1
HTTP/1 je souhrnný termín pro HTTP 1.0 a HTTP 1.1, což označuje verze HTTP protokolu 1.0 a 1.1.
HTTP 1.0 byla druhou verzí HTTP protokolu a je široce využívána dodnes. Provedl řadu vylepšení a vylepšení založených na HTTP/0.9, včetně:
Lze posílat více formátů, jako jsou obrázky, videa, binární soubory nad rámec pouhého textu
Navíc byly přidány metody POST požadavků
Změnil jsem formát HTTP požadavků a odpovědí. Kromě datové části musí každá komunikace obsahovat HTTP hlavičku, která popisuje nějaká metadata, tj. přidává se informace o hlavičce požadavku
Přidány funkce jako kód stavu odpovědi, podpora víceznakových sad, autorizace, cache a kódování obsahu
Ačkoliv je stále bezstavový protokol, dlouhá spojení lze podpořit přidáním hlavičky "Connection: keep-alive" k požadavku
HTTP 1.1
HTTP 1.1 je standardizovaný protokol a HTTP 1.1 odstraňuje mnoho nejasností a přináší několik vylepšení.
zvláštnost
Zpracování cache, HTTP 1.1 zavádí více politik řízení cache, jako jsou Entity tag, If-Unmodified-Since (If-Unmodified-Since ), If-Match (If-Match), If-None-Match atd., a další volitelné hlavičky cache pro kontrolu cache politiky.
Optimalizace šířky pásma a využití síťových připojení zavádějí rozsah v hlavičce požadavku, který umožňuje požadavek pouze na jednu část zdroje, tedy vrácení stavového kódu 206, což usnadňuje vývojářům volně využít šířku pásma a spojení a mohou použít rozsah a rozsah obsahu k vytvoření funkce obnovení bodu přerušení.
Správa hlášení chyb, bylo přidáno 24 nových kódů stavů chyb v HTTP 1.1.
Přidání hlavičky Host umožňuje konfiguraci různých doménových jmen na serverech se stejnou IP adresou.
Podporuje dlouhá spojení, HTTP 1.1 podporuje dlouhá spojení, přes TCP spojení lze přenášet více HTTP požadavků a odpovědí, což snižuje spotřebu a zpoždění při navazování a zavírání spojení, a Connection:keep-alive je ve výchozím nastavení povolen v HTTP 1.1, zatímco běžné prohlížeče umožňují současně navázat 6 dlouhých odkazů pro stejnou doménu.
Přidáno technologie pipeliningu, která umožňuje odeslání druhého požadavku před tím, než je první odpověď plně odeslána, aby se zlepšilo blokování front, ale pořadí odpovědí bude stále vráceno v pořadí požadavků.
Podporujte chunking odpovědí nastavením Transfer-Encoding: chunked pro chunked response, což umožňuje rozdělit data odpovědí na více částí a server může co nejdříve uvolnit buffer pro rychlejší rychlost odezvy.
HTTP 2.0
HTTP 2.0 má lepší výkon a nyní se webové stránky stávají stále složitějšími a dokonce se vyvíjejí v unikátní aplikace, množství přehrávání médií, velikost skriptů pro zlepšení interakce se také výrazně zvýšila a více dat je přenášeno přes HTTP požadavky, takže HTTP 2.0 provedl mnoho optimalizací pro efektivitu sítě.
zvláštnost
Binární rozdělení rámců, HTTP 2.0 je binární protokol, nikoli textový protokol, který rozděluje veškeré přenášené informace na menší zprávy a rámce a kóduje je v binárním formátu.
Multiplexující, paralelní požadavky lze zpracovávat ve stejném spojení, všechny přístupy pod stejným doménovým jménem jsou ze stejného TCP spojení, HTTP zprávy jsou rozděleny do nezávislých rámců a server znovu sestavuje zprávy podle identifikátorů a hlaviček, čímž odstraňuje pořadí a blokování v HTTP 1.1.
Komprese hlaviček, které jsou často podobné v řadě požadavků, snižuje náklady na duplikaci a přenos duplicitních dat.
Server-side push umožňuje serveru proaktivně přesouvat zdroje klientovi bez explicitního požadavku od klienta.
HTTP 3.0
HTTP 3.0 je momentálně ve fázi formulace a testování, je to nový protokol HTTP v budoucnu, protokol HTTP 3.0 běží nad protokolem QUIC, je založen na UDP pro dosažení spolehlivého přenosu, kompromis mezi rychlostí a spolehlivostí přenosu a optimalizaci, použití UDP předchází problému blokování fronty TCP a urychlí přenosovou rychlost sítě, ale také vyžaduje spolehlivý mechanismus přenosu, HTTP 3.0 není rozšířením HTTP 2.0, HTTP 3.0 bude zcela nový protokol.
HttpClientHandler VS SocketsHttpHandler
Výchozím handlerem zpráv používaným HttpClient v .NET Frameworku a .NET Core 2.0 a starších verzích je HttpClientHandler.
Začínáme s .NET Core 2.1, třídySocketsHttpHandler poskytuje vyšší úroveň HTTP síťové třídy(např. HttpClient). Používání SocketsHttpHandler nabízí mnoho výhod:
Výkon se výrazně zlepšil oproti předchozím implementacím.
Odstraňte závislosti na platformě pro zjednodušení nasazení a servisu. Například libcurl už nezávisí na .NET Core pro macOS a .NET Core pro Linux.
Konzistentní chování napříč všemi .NET platformami.
V .NET 9 používá HttpClientFactory jako hlavní handler SocketsHttpHandler
HttpClientFactory umožňuje konfiguraci HttpClient pipeline pro pojmenované a typované objekty HttpMessageHandler. Nejvnitřnější handler nebo handler, který skutečně posílá požadavky do sítě, se nazývá master handler. Pokud nebyl nakonfigurován, tento handler byl vždy dříve HttpClientHandler. Zatímco výchozím hlavním handlerem jsou detaily implementace, někteří uživatelé na něj spoléhají. Například někteří uživatelé přenášejí hlavní handler do nastavení HttpClientHandler, jako jsou ClientCertificates, UseCookies a UseProxy.
Propojit:Přihlášení k hypertextovému odkazu je viditelné.
Globální konfigurace požaduje verzi HTTP protokolu
Kód je následující:
DefaultRequestVersionVýchozí nastavení je HttpVersion.Version11。
Vlastnost DefaultRequestVersion specifikuje výchozí verzi HTTP, která se použije pro požadavky odesílané pomocí této instance HttpClient, když vytváří HttpRequestMessage pro odeslání, konkrétně voláním 、、、GetStreamAsyncGetAsyncGetByteArrayAsync, PatchAsyncGetStringAsync, PostAsync a PutAsync.
Vlastnost DefaultRequestVersionNeplatí pro metodu SendAsync。 Parametr HttpRequestMessage, který byl předán metodě SendAsync jako parametr, má vlastní vlastnost Version, která řídí HTTP verzi použitou pro požadavek.
Propojit:Přihlášení k hypertextovému odkazu je viditelné.
Vyjednávací politika HttpVersionPolicy
RequestVersionOrLower: Použijte požadovanou verzi, nebo snižujte na nižší verzi (ale ne vyšší než požadovaná verze). To je výchozí chování. Jednoduše řečeno, nejpoužívanější verzí protokolu je aktuální verze, a pokud není podporována aktuální verze protokolu, bude degradována.
RequestVersionOrHigher: Použijte nejvyšší verzi podporovanou serverem, ale ne nižší než požadovaná verze. To znamená, že jsou povoleny upgrady a snížené verze pod požadovanou verzi nejsou povoleny. Jednoduše řečeno, používejte pro komunikaci protokoly vyšší verze, kdykoli je to možné.
RequestVersionExact: Používejte přísně požadovanou verzi, nejsou povoleny žádné upgrady ani downgrade.
HttpClient používá protokol verze Http/2.0
Testovací kód je následující:
Požadavek používá verzi 1.1 a konečný klient a server vyjednávají o komunikaci pomocí protokolu 2.0, takže konečná odpověď je verze 2.0, jak je znázorněno na obrázku níže:
Odkaz:
Přihlášení k hypertextovému odkazu je viditelné.
Přihlášení k hypertextovému odkazu je viditelné.
Přihlášení k hypertextovému odkazu je viditelné. |
Předchozí:MinIO úložiště (iii) Kopírování, nahrávání (migrace) lokálních souborů do minio bucketuDalší:.NET/C# převádí PDF na obrázky založené na ImageMagick, GhostScript
|
Pronajímatel|
Zveřejněno 31. 8. 2025 21:46:27
|
