Chunked överföringskodning
Chunked överföringskodning är en strömmande dataöverföringsmekanism tillgänglig i Hypertext Transfer Protocol (HTTP) version 1.1, definierad i RFC 9112 §7.1 . Vid chunk-överföringskodning är dataströmmen uppdelad i en serie icke-överlappande "bitar". Bitarna skickas ut och tas emot oberoende av varandra. Ingen kunskap om dataströmmen utanför den för närvarande bearbetade biten är nödvändig för både avsändaren och mottagaren vid varje given tidpunkt.
Varje bit föregås av sin storlek i byte. Sändningen avslutas när en noll-längd del tas emot. Det chunkade nyckelordet i överföringskodningshuvudet används för att indikera chunköverföring.
Chunked överföringskodning stöds inte i HTTP/2 , som tillhandahåller sina egna mekanismer för dataströmning.
Logisk grund
Införandet av chunked encoding gav olika fördelar:
- Chunkad överföringskodning tillåter en server att upprätthålla en beständig HTTP-anslutning för dynamiskt genererat innehåll. I det här fallet kan HTTP Content-Length-huvudet inte användas för att avgränsa innehållet och nästa HTTP-förfrågan/svar, eftersom innehållsstorleken inte är känd ännu. Chunkkodning har fördelen att det inte är nödvändigt att generera hela innehållet innan du skriver rubriken, eftersom det tillåter streaming av innehåll som bitar och uttryckligen signalerar slutet av innehållet, vilket gör anslutningen tillgänglig för nästa HTTP-förfrågan/svar.
- Klumpad kodning gör att avsändaren kan skicka ytterligare rubrikfält efter meddelandetexten. Detta är viktigt i de fall där värdena för ett fält inte kan vara kända förrän innehållet har producerats, till exempel när innehållet i meddelandet måste signeras digitalt. Utan chunkkodning skulle avsändaren behöva buffra innehållet tills det var komplett för att kunna beräkna ett fältvärde och skicka det före innehållet.
Tillämplighet
För version 1.1 av HTTP-protokollet anses den chunkade överföringsmekanismen alltid och hur som helst vara acceptabel, även om den inte är listad i TE ( transfer encoding) request header-fältet, och när den används med andra överföringsmekanismer, ska den alltid tillämpas sist till de överförda uppgifterna och aldrig mer än en gång. Denna överföringskodningsmetod tillåter också att ytterligare entitetshuvudfält skickas efter den sista biten om klienten angav parametern "trailers" som ett argument för TE-fältet. Svarets ursprungsserver kan också besluta att skicka ytterligare entitetstrailers även om klienten inte angav alternativet "trailers" i TE-begäransfältet, men bara om metadata är valfri (dvs. klienten kan använda den mottagna enheten utan dem ). Närhelst trailers används, bör servern lista deras namn i Trailer header-fältet; tre rubrikfältstyper är specifikt förbjudna från att visas som ett trailerfält: Transfer-Encoding , Content-Length och Trailer .
Formatera
Om ett fält för överföringskodning med värdet " chunked " anges i ett HTTP-meddelande (antingen en begäran skickad av en klient eller svaret från servern), består meddelandets brödtext av ett ospecificerat antal bitar, en avslutande chunk, trailer och en sista CRLF-sekvens (dvs. vagnretur följt av radmatning ).
Varje del börjar med antalet oktetter av data den bäddar in uttryckt som ett hexadecimalt tal i ASCII följt av valfria parametrar ( chunk extension ) och en avslutande CRLF-sekvens, följt av chunkdata. Biten avslutas av CRLF.
Om chunkförlängningar tillhandahålls avslutas chunkstorleken med ett semikolon och följs av parametrarna, var och en avgränsad med semikolon. Varje parameter kodas som ett tilläggsnamn följt av ett valfritt likhetstecken och värde. Dessa parametrar kan användas för en löpande meddelandesammanfattning eller digital signatur , eller för att indikera en uppskattad överföringsförlopp, till exempel.
Den avslutande biten är en vanlig bit, med undantaget att dess längd är noll. Den följs av trailern, som består av en (möjligen tom) sekvens av entitetshuvudfält. Normalt skulle sådana rubrikfält skickas i meddelandets rubrik; det kan dock vara mer effektivt att fastställa dem efter att ha bearbetat hela meddelandeenheten. I så fall är det användbart att skicka dessa rubriker i trailern.
Rubrikfält som reglerar användningen av trailers är TE (används i förfrågningar) och Trailers (används i svar).
Använd med kompression
HTTP-servrar använder ofta komprimering för att optimera överföringen, till exempel med Content-Encoding: gzip eller Content-Encoding: deflate . Om både komprimering och chunkkodning är aktiverade, komprimeras först innehållsströmmen, sedan chunk; så själva chunk-kodningen komprimeras inte, och data i varje chunk komprimeras inte individuellt. Fjärrändpunkten avkodar sedan strömmen genom att sammanfoga bitarna och komprimera resultatet.
Exempel
Kodad data
I följande exempel visas tre bitar med längden 4, 6 och 14 (hexadecimalt "E"). Bitstorleken överförs som ett hexadecimalt tal följt av \r\n som en radavgränsare, följt av en bit data av den givna storleken.
4\r\n (byte att skicka) Wiki\r\n (data) 6\r\n (byte att skicka) pedia \r\n (data) E\r\n (byte att skicka) i \r\ n \r\n bitar.\r\n (data) 0\r\n (slutlig byte - 0) \r\n (slutmeddelande)
Obs: chunkstorleken indikerar storleken på chunkdata och exkluderar den efterföljande CRLF ("\r\n"). I det här specifika exemplet räknas CRLF efter "in" som två oktetter mot chunkstorleken 0xE (14). CRLF i sin egen rad räknas också som två oktetter mot chunkstorleken. Periodtecknet i slutet av "bitar" är det 14:e tecknet, så det är det sista datatecknet i den biten. Den CRLF som följer efter perioden är den efterföljande CRLF, så den räknas inte mot chunkstorleken 0xE (14).
Avkodad data
Wikipedia i bitar.
Se även
externa länkar
- "Chunked Transfer Coding" . HTTP/1.1 . juni 2022. sek. 7.1. doi : 10.17487/RFC9112 . RFC 9112 .