Követelmények: A legtöbb weboldal ma már főként a Http/1.1 és Http/2.0 verziós protokollokat használja, azoknál a weboldalaknál, amelyek csak az HTTP/2 protokoll verziót támogatják, és alapértelmezett kérések küldésére HttpClient-et használnak, akkor a System.Net.Http.Http.Http.RequestException kódot adják ki: Hiba történt a kérés küldése közben. ---> System.IO.IOException: Nem tudunk adatokat olvasni a transzfer kapcsolatról: A hosztoda szoftvere megszakította a létrehozott kapcsolatot. ---> System.Net.Sockets.SocketException (10053): A hosztományban lévő szoftver megszakítja a meglévő kapcsolatot. at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, Boolean forAsyncThrow) címen.
A HTTP protokoll története
Idővonal
HTTP/0.9
Az elavult HTTP/0.9 volt az első HTTP protokoll verziója, amely 1989-ben született. Ez rendkívül egyszerű, lehetővé teszi a kliens számára, hogy GET kérést küldjön, és nem támogatja a kérés fejléceit. Mivel nincs protokollfejléce, az HTTP/0.9 csak egy típusú tartalmat támogat – a tiszta szöveget. A szerver csak HTML formátumú stringekre tud válaszolni, más formátumokra nem. Amikor a szerver befejezte az küldést, a TCP kapcsolat zárul. A HTTP/0.9-nek tipikus állapottalansága van, ahol minden látogatást önállóan dolgoznak fel, és a feldolgozás befejezése után megszakítják a kapcsolatot. Ha a kért oldal nem létezik, akkor hibakódok nem jelennek meg.
HTTP/1
A HTTP/1 a HTTP 1.0 és HTTP 1.1 együttes kifejezése, amely a HTTP protokoll 1.0 és 1.1 verzióira utal. A HTTP 1.0 volt a HTTP protokoll második verziója, és ma is széles körben elterjedt. Számos fejlesztést és fejlesztést hajtott végre az HTTP/0.9 alapján, többek között:
Több formátum, mint például képek, videók, binárisok, a szöveg túlmutató formátumok is elküldhetők Ráadásul a POST kérési módszerek is hozzáadásra kerültek Megváltoztattam a HTTP kérések és válaszok formátumát. Az adatrész mellett minden kommunikációnak tartalmaznia kell egy HTTP fejlécet, amely leír bizonyos metaadatokat, azaz a kérés fejléce információját adják hozzá Hozzáadott funkciók, mint például válaszállapotkód, többkarakteres halmaz-támogatás, hitelesítés, gyorsítótár és tartalomkódolás Bár továbbra is állapot nélküli protokoll, a hosszú kapcsolatok támogathatók azzal, hogy hozzáadják a "Connection: keep-alive" fejlécét a kéréshez
HTTP 1.1
A HTTP 1.1 egy szabványosított protokoll, és a HTTP 1.1 sok kétértelműséget szüntet, valamint számos fejlesztést vezet be.
jellemző vonás
Gyorsítótárfeldolgozás során a HTTP 1.1 több gyorsítótár-vezérlési szabályzatot vezet be, mint például Entity tag, If-Unmodified-Since, If-Match, If-None-Match stb., valamint több opcionális cache fejlécet a cache politika szabályozására. A sávszélesség optimalizálása és a hálózati kapcsolatok használata egy tartományt vezet be a kérés fejlécébe, amely lehetővé teszi, hogy az erőforrás csak egy részét kérje, azaz visszaadja a 206 státuszkódot, ami megkönnyíti a fejlesztők számára, hogy szabadon válasszák a sávszélesség és a kapcsolatok teljes kihasználását, és a Tartomány és a Tartalom-tartomány segítségével megszakítási pont újraindítási függvényt hozhatnak létre. Hibaértesítés-kezelés, 24 új hibastátuszkódot adtak hozzá a HTTP 1.1-ben. A Host fejléc hozzáadása lehetővé teszi, hogy különböző domainneveket konfiguráljanak ugyanazzal az IP-címmel rendelkező szervereken. Támogatja a hosszú kapcsolatokat, a HTTP 1.1 támogatja a hosszú kapcsolatokat, több HTTP kérés és válasz továbbítható egy TCP kapcsolaton, csökkentve a kapcsolatok létrehozásának és lezárásának fogyasztását és késleltetését, a Connection:keep-alive alapértelmezett HTTP 1.1-ben, és általános böngészők lehetővé teszik, hogy egyszerre 6 hosszú link hozzanak létre ugyanazon domainnéven. Hozzáadták a pipelin technológiát, amely lehetővé teszi, hogy egy második kérést küldjenek az első válasz teljes elküldése előtt, javítva a sorblokkolás javítását, de a válaszok sorrendje továbbra is a kérések sorrendjében kerül vissza. Támogatja a válasz chunkolást a Transfer-Encoding: chunked for chunked response beállításával, lehetővé téve a válaszadatok több részre bontását, és a szerver a lehető leghamarabb kiszabadíthatja a puffert a gyorsabb válaszsebesség érdekében.
HTTP 2.0
A HTTP 2.0 jobb teljesítményt nyújt, és most, hogy a weboldalak egyre összetettebbek, sőt, egyedi alkalmazásokká is fejlődnek, a médialejátszás mennyisége, a interakció javítására szolgáló szkriptek mérete is jelentősen nőtt, és több adatot továbbítanak HTTP kéréseken keresztül, így a HTTP 2.0 sok optimalizálást végzett a hálózati hatékonyság érdekében.
jellemző vonás
Bináris keretfelosztás, a HTTP 2.0 egy bináris protokoll, nem pedig szöveges protokoll, amely minden továbbított információt kisebb üzenetekre és keretekre bont, majd bináris formátumban kódolja. Multiplexelés, párhuzamos kérések ugyanabban a linkben feldolgozhatók, minden hozzáférés ugyanazon domainnéven ugyanabból a TCP kapcsolatból származik, a HTTP üzenetek független keretekre bontódnak, és a szerver az üzeneteket azonosítók és fejlécek szerint összeállítja, megszüntetve a HTTP 1.1 sorrendjét és blokkolási korlátozásait. A fejlécek tömörítése, amelyek gyakran hasonlóak a kérések sorozatában, megszünteti a duplikált adatok duplikálásának és továbbításának költségeit. Szerveroldali push-ban a szerver proaktívan tud erőforrásokat továbbítani az ügyfélnek anélkül, hogy kifejezetten kérné az ügyféltől.
HTTP 3.0
A HTTP 3.0 jelenleg a kidolgozás és tesztelés szakaszában van, egy új HTTP protokoll a jövőben, a HTTP 3.0 protokoll a QUIC protokoll fölött fut, UDP-n alapul, hogy megbízható átvitel, kompromisszumot biztosítson az átviteli sebesség és az átvitel megbízhatósága érdekében, optimalizálja, az UDP használata elkerüli a TCP sorblokkoló problémát, felgyorsítja a hálózati átviteli sebességet, de megbízható átviteli mechanizmust is kell elérni, a HTTP 3.0 nem a HTTP 2.0 kiterjesztése, HTTP A 3.0 teljesen új protokoll lesz.
HttpClientHandler VS SocketsHttpHandler
A HttpClient alapértelmezett üzenetkezelője a .NET Framework-ben és a .NET Core 2.0-ban vagy korábbi verziókban a HttpClientHandler.
A .NET Core 2.1-től kezdve, az osztályokA SocketsHttpHandler magasabb szintű HTTP hálózati osztályt biztosít(pl. HttpClient). A SocketsHttpHandler használata számos előnyt kínál:
A teljesítmény jelentősen javult a korábbi megvalósításokhoz képest. Megszüntetni a platformfüggőségeket a telepítés és szolgáltatás egyszerűsítése érdekében. Például a libcurl már nem függ a macOS-hez való .NET Core-tól és a Linuxhoz való .NET Core-tól. Következetes viselkedés minden .NET platformon.
A .NET 9-ben a HttpClientFactory a SocketsHttpHandlert használja fő kezelőként
A HttpClientFactory lehetővé teszi a HttpClient pipeline konfigurálását a név és gépelt HttpMessageHandler objektumokhoz. A legbelső kezelőt, vagyis azt a kezelőt, aki ténylegesen küld kérelmeket a hálózaton, a master handlernek nevezik. Ha nem volt konfigurálva, ez a kezelő korábban mindig HttpClientHandler volt. Bár az alapértelmezett master handler a megvalósítási részletek, vannak felhasználók, akik erre támaszkodnak. Például néhány felhasználó a fő kezelőt a HttpClientHandler beállítási tulajdonságokra irányítja, mint például ClientCertificates, UseCookies és UseProxy.
Láncszem:A hiperlink bejelentkezés látható.
A globális konfiguráció a HTTP protokoll verziót kéri
A kódex a következő:
DefaultRequestVersionAz alapértelmezett beállítás a HttpVersion.Version11。
A DefaultRequestVersion tulajdonság megadja az alapértelmezett HTTP verziót, amelyet a HttpClient példányon keresztül küldött kérésekhez kell használni, amikor létrehozza a küldendő HttpRequestMessage-t, kifejezetten a 、、、GetStreamAsyncGetAsyncGetByteArrayAsync, PatchAsyncGetStringAsync, PostAsync és PutAsync.
DefaultRequestVersion tulajdonságNem vonatkozik a SendAsync módszerre。 A SendAsync metódusnak paraméterként átadott HttpRequestMessage paraméternek saját verzió tulajdonsága van, amely szabályozza a kéréshez használt HTTP verziót.
Láncszem:A hiperlink bejelentkezés látható.
HttpVersionPolicy tárgyalási politika
RequestVersionOrLower: Használd a kért verziót, vagy válts le alacsonyabb verzióra (de nem magasabbra a kívánt verziónál). Ez az alapértelmezett viselkedés. Egyszerűen fogalmazva, a legtöbbet használt protokollverzió a jelenlegi verzió, és ha a jelenlegi protokollverzió nem támogatott, akkor visszaminősítik.
RequestVersionOrHigher: A szerver által támogatott legmagasabb verziót használjuk, de nem alacsonyabb a kért verziónál. Vagyis a fejlesztések engedélyezettek, és a kívánt verzió alá vezető leminősítések nem engedélyezettek. Egyszerűen fogalmazva, amikor lehetséges, használj magasabb verziójú protokollokat a kommunikációhoz.
RequestVersionExact: Kizárólag a kért verziót használd, nem engedélyezett a fejlesztések vagy visszaminősítések.
A HttpClient a Http/2.0 verziós protokollt használja
A tesztkód a következő:
A kérés az 1.1-es verziót használja, és a végső kliens és a szerver tárgyalnak, hogy a 2.0-as protokollt használják a kommunikációhoz, így a végső válasz a 2.0-as verzió, ahogy az alábbi ábrán látható:
Utalás:
A hiperlink bejelentkezés látható.
A hiperlink bejelentkezés látható.
A hiperlink bejelentkezés látható. |