Chunked Transfer a webfejlesztésben — mi ez, formátum és a chunk-alapú átvitel elve
Chunked Transfer — a HTTP protokoll egy olyan mechanizmusa, amelyben a szerver a válasz törzsét különálló fragmentumokban (chunkokban) továbbítja anélkül, hogy előre megadná az adatok teljes méretét. Minden chunk tartalmazza a saját méretét hexadecimális formátumban és a megadott hosszúságú adatokat, és egy nulla méretű végső chunkkal végződik. A MDN Web Docs, 2025 szerint a Transfer-Encoding: chunked automatikusan bekapcsolásra kerül a szerver által, amikor a válasz mérete nem ismert előre — például tartalom menet közbeni generálásakor vagy adatok streamelésekor.
Főbb pontok
- Chunked Transfer — HTTP-válasz részenkénti továbbítása a Content-Length előzetes megadása nélkül.
- Transfer-Encoding: chunked — a chunk-alapú adatátviteli módot bekapcsoló fejléc.
- Minden chunk tartalmazza a méretet hex formátumban, az adatokat és a záró CRLF-et, a végét pedig egy nulla méretű chunk jelzi.
- Streaming — a chunked transfer fő alkalmazása audio, video és SSE események továbbítására.
- A Chunked Transfer nem kompatibilis a Content-Length fejléccel — nem használhatók egyidejűleg.
Mi az a Chunked Transfer?
A Chunked Transfer a HTTP/1.1 specifikációban (RFC 7230, 4.1 szakasz) meghatározott HTTP-mechanizmus, amely lehetővé teszi a szerver számára, hogy a válasz törzsét részekben küldje el a teljes Content-Length megadása nélkül. Ahelyett, hogy a válasz méretét elküldés előtt kiszámítaná, a szerver azonnal megkezdi az átvitelt, az adatokat fragmensekben küldve, amint elkészülnek. Minden fragmenshez tartozik egy saját méretfejléc, amely lehetővé teszi a kliens számára, hogy a választ darabokból összeállítsa.
A mechanizmus a Transfer-Encoding: chunked fejléc által aktiválódik. Amikor a kliens ezt a fejlécet látja a válaszban, tudja, hogy a törzs chunkokban kerül továbbításra, és egy ciklusban kell olvasnia a választ: olvassa el a chunk méretét, majd a megadott méretű adatokat, majd ismételje meg. A folyamat akkor ér véget, amikor egy nulla méretű chunkot talál. A Chunked Transfer a HTTP/1.1 kötelező része, amelyet minden modern webszerver és HTTP-kliens támogat.
A chunked transfer használatának fő oka a dinamikus tartalomgenerálás. Amikor a szerver egy adatbázis-lekérdezés, külső API vagy hosszadalmas számítás alapján generál választ, nem tudja előre a eredmény méretét. Ahelyett, hogy a teljes választ a memóriában pufferelné (ami nagy mennyiségek esetén kockázatos), a szerver bekapcsolja a Transfer-Encoding: chunked-et, és az adatokat elkészültükkor küldi el. Ez különösen fontos a korlátozott memóriájú szerverek és a nagyon nagy méretű válaszok esetében — 100 MB-tól felfelé.
Különbség a HTTP/1.1 chunked és a HTTP/2 között
A HTTP/2-ben a chunked transfer mechanizmus mint olyan nem létezik, mivel a protokoll a streamek multiplexálását használja keret szinten. A HTTP/2-ben bármilyen méretű adat DATA keretekben kerül továbbításra, és a válasz törzsének méretét nem kell előre deklarálni — a streambármikor lezárható. A modern szerverek automatikusan konvertálják a HTTP/1.1 chunked válaszokat egyenértékű streaming átvitelre, amikor HTTP/2 upstream-re proxyznak. A Chunked Transfer továbbra is releváns a HTTP/1.1 kapcsolatokhoz.
Hogyan működik a chunk-alapú átvitel
Amikor a szerver úgy dönt, hogy Chunked Transfer-t használ, nem számítja ki a Content-Length-t, hanem elküldi a Transfer-Encoding: chunked fejlécet. Ezután a válasz törzse chunkok sorozataként jön létre. Minden chunk egy sorral kezdődik, amely a chunk méretét tartalmazza hexadecimális formátumban (0x előtag nélkül), amelyet CRLF ( ) követ. Ezután jön a megadott méretű chunk adat, CRLF-fel zárva. Az utolsó chunk mérete 0, amely után trailer fejlécek következhetnek.
A hexadecimális méret lehetővé teszi bármilyen méretű chunk továbbítását — 1 bájttól elméletileg korlátlan mennyiségig. A gyakorlatban a chunk méretét a szerver választja meg: tipikus értékek 4 KB, 8 KB vagy 16 KB. Az optimális chunk méret a TCP-szegmens méretének (Ethernet esetében általában 1460 bájt) többszöröse kell, hogy legyen a fragmentáció minimalizálása érdekében a szállítási rétegben. Az Nginx alapértelmezés szerint 4 KB-os chunkokat használ, az Apache — 8 KB-osakat.
A Transfer-Encoding: chunked-et kapott kliens köteles a választ chunkról chunkra olvasni a végső nulla chunkig. Ha a kliens nem támogatja a chunked transfer-t, a szerver nem használhatja ezt a módot. A gyakorlatban minden modern HTTP-kliens — böngészők, OkHttp, URLSession, curl — teljes mértékben támogatja a chunked válaszokat. A streaming olvasás lehetővé teszi a kliens számára, hogy az adatok feldolgozását a teljes válasz kézhezvétele előtt megkezdje, ami kritikus a teljesítmény szempontjából.
| Chunk elem | Formátum | Példa |
|---|---|---|
| Chunk mérete | HEX + CRLF | 1000 |
| Chunk adatai | [méret bájt] + CRLF | [4096 bájt adat] |
| Záró chunk | 0 | 0 |
| Trailer (opcionális) | Fejlécek + CRLF | Expires: Wed, 21 Oct 2025 |
Trailer fejlécek a Chunked Transfer-ben
A Chunked Transfer támogatja a trailer fejléceket — további HTTP fejléceket, amelyek az utolsó chunk után kerülnek továbbításra. Ez olyan metaadatokhoz hasznos, amelyek csak a válasz generálásának befejezése után válnak ismertté: például Content-MD5 vagy X-Compression-Ratio. A trailer fejléceket a Trailer fejlécben kell deklarálni: Content-MD5, X-Compression-Ratio. A gyakorlatban a trailerek ritkán használatosak — a legtöbb szerver nem illeszti be őket a válaszokba.
A chunked válasz formátuma
A chunked válasz szigorúan meghatározott szerkezettel rendelkezik, amelyet a kliensnek helyesen kell elemeznie. Vizsgáljuk meg a HTTP-válasz teljes példáját Transfer-Encoding: chunked-del. A fejlécek és az üres sor után kezdődik a válasz törzse. A törzs szerkezete egy sorozat: chunk_méret adatok chunk_méret adatok ... egészen 0 -ig. Minden méret a hexadecimális számrendszerben kerül továbbításra ASCII karakterekkel.
Példa szerver válaszra Chunked Transfer-rel:
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
7
Hello
6
World!
0
Ebben a példában a szerver a „Hello World!” sztringet két chunkban továbbítja. Az első 7 bájtos chunk tartalmazza a „Hello ”, a második — 6 bájt „World!”. A kliens összegyűjti az adatokat mindkét chunkból, és megkapja a teljes sztringet. Fontos: a chunk mérete csak az adatokat foglalja magában, nem tartalmazza a chunkok CRLF elválasztóit. A végső üres chunk (0 ) értesíti a klienst az átvitel végéről.
kotlin
import java.net.HttpURLConnection
import java.io.BufferedReader
import java.io.InputStreamReader
fun readChunkedResponse() {
val url = java.net.URL("https://stream.example.com/data")
val connection = url.openConnection() as HttpURLConnection
val reader = BufferedReader(
InputStreamReader(connection.inputStream)
)
var line: String?
while (reader.readLine().also { line = it } != null) {
println("Chunk: $line")
}
reader.close()
}Chunked válasz elemzése OkHttp-ban
Az OkHttp teljesen elvonatkoztatja a programozót a Chunked Transfer részleteitől. A Transfer-Encoding: chunked-del érkező válasz fogadásakor az OkHttp automatikusan összegyűjti a chunkokat, és a programozó rendelkezésére bocsátja a teljes választörzset a response.body?.string() segítségével. Streaming feldolgozáshoz a response.body?.source() használatos, amely egy BufferedSource-t ad vissza, és lehetővé teszi az adatok beérkezésükkor történő olvasását. A programozónak nem kell manuálisan elemeznie a hex méreteket és CRLF-eket — a könyvtár ezt automatikusan elvégzi.
Chunked Transfer vs Content-Length
A Content-Length és a Transfer-Encoding: chunked a HTTP-üzenet törzsméretének megadásának két egymást kizáró módja. Content-Length egy fejléc, amely a törzs pontos méretét tartalmazza bájtokban. Kötelező azoknál a válaszoknál, amelyek mérete előre ismert, és a törzzsel rendelkező kéréseknél (POST, PUT). A Content-Length lehetővé teszi a kliens számára, hogy előre megfelelő méretű puffert allokáljon, és ellenőrizze, hogy minden adat megérkezett.
A Chunked Transfer akkor használatos, amikor a törzs mérete előre nem ismert. Ez három fő forgatókönyvben fordul elő: dinamikus tartalomgenerálás (például egy adatbázis-lekérdezés, amelynek eredménye még nem érkezett meg), nagy fájlok streamelése (hogy ne a teljes fájl pufferelődjön a memóriában) és Server-Sent Events (SSE) valós idejű események továbbítására. A választás a Content-Length és a chunked között a szerver felelőssége. Ha a szerver ismeri a méretet az átvitel megkezdése előtt, akkor a Content-Length-t kell használnia egyszerűbb és kiszámíthatóbb mechanizmusként.
A HTTP/1.1 specifikáció tiltja a Content-Length és a Transfer-Encoding: chunked egyidejű használatát. Ha a szerver mindkét fejlécet elküldi, a kliensnek figyelmen kívül kell hagynia a Content-Length-t, és a választ chunked-ként kell feldolgoznia. A Transfer-Encoding elsőbbsége a Content-Length felett az RFC 7230-ban került meghatározásra azokban az esetekben, amikor egy proxy szerver módosítja a válasz törzsét, és nem tudja megtartani az eredeti Content-Length-t. Néhány régebbi HTTP-kliens helytelenül kezeli ezt a helyzetet, de a modern implementációk követik a specifikációt.
Amikor a Content-Length lehetetlen
Vannak olyan forgatókönyvek, amikor a Content-Length elvileg nem számítható ki előre. Dinamikus jelentések, amelyek a felhasználói kérés alapján szűréssel és aggregálással készülnek — a szerver nem ismeri az adatmennyiséget az adatbázis-lekérdezés befejezéséig. Streaming video, amelyet valós időben továbbítanak egy kameráról — a méret végtelen. SSE és long polling értesítésekhez — a válasz határozatlan ideig tarthat. Mindezekben az esetekben a Chunked Transfer az egyetlen helyes mechanizmus.
Streaming chunked transfer alapokon
A Chunked Transfer számos streaming technológia alapját képezi a weben. A legismertebb a Server-Sent Events (SSE), ahol a szerver egyetlen HTTP-kapcsolaton keresztül, Transfer-Encoding: chunked segítségével küld eseményeket a kliensnek. Az SSE speciális szövegformátumot használ (data: üzenet ), de a szállítási réteg közönséges chunked transfer. A böngésző az eseményeket a szerver általi elküldésükkor kapja, anélkül, hogy megvárná a válasz befejezését.
Az audio és video streaming szintén a Chunked Transfer-re támaszkodik. A médiaszerverek, mint a Nginx RTMP és a Wowza Streaming Engine, HTTP-n keresztül chunkokban küldik a médiaadatokat. A kliens oldali lejátszó az első chunk megérkezésekor elkezdi a lejátszást, anélkül, hogy megvárná a fájl teljes betöltését. Ez csökkenti a lejátszás megkezdéséig eltelt időt (Time to First Frame) több tíz másodpercről 1-2 másodpercre. A YouTube és a Netflix pontosan ezt a megközelítést használja a HTTP streamekhez.
A mobilalkalmazás-fejlesztésben a Chunked Transfer nagy adatmennyiségek továbbítására szolgál anélkül, hogy a teljes választ a memóriába töltené. A képek Coil vagy Glide segítségével történő betöltésekor Androidon a könyvtárak chunkokban olvassák a streaming adatokat, és fokozatosan dekódolják a képet. Ez lehetővé teszi nagy képek (10+ MB) megjelenítését OutOfMemoryError nélkül. Az OkHttp támogatja a streaming olvasást a response.body?.byteStream() segítségével, amely egy InputStream-et ad vissza, ami az adatokat chunkról chunkra olvassa.
Chunked transfer gRPC-ben és GraphQL-ben
A gRPC HTTP/2-t használ, ahol a streaming átvitel protokoll szinten be van építve, és nem igényel külön chunked mechanizmust. A HTTP/1.1-en keresztül működő GraphQL szerverek használhatják Chunked Transfer-t az előfizetések (subscriptions) eredményeinek streamelésére. Az Apollo Server és a Hasura chunked válaszokat küld a GraphQL előfizetésekhez, az eseményeket azok bekövetkezésekor továbbítva. A kliens valós idejű frissítéseket kap anélkül, hogy pollingra lenne szüksége.
Előnyök és korlátozások
A Chunked Transfer fontos előnyöket biztosít a webalkalmazások számára. Az adatok azonnali elküldése — a szerver nem puffereli a választ elküldés előtt, csökkentve a késleltetést (latency) az első bájtig. Streaming feldolgozás — a kliens elkezdheti az adatok feldolgozását azok beérkezésekor, anélkül, hogy megvárná a teljes betöltést. Nincs memóriakorlátozás — a szerver nem tárolja a teljes választ a memóriában, ami kritikus nagy adatmennyiségek esetén. Végtelen streamek továbbításának lehetősége — SSE, élő video, monitorozás.
A Chunked Transfer-nek azonban vannak korlátozásai. Többletterhelés minden egyes chunknál 6-12 bájt a méret + CRLF, ami nagyszámú kis chunk (például 100 bájt) esetén 10-15%-kal növelheti a válasz méretét. A pontos méret megadásának lehetetlensége — a kliens nem tud előre puffert allokálni vagy folyamatjelző sávot mutatni. Problémák a proxy szerverekkel — néhány régebbi proxy nem támogatja a chunked transfer-t, és nem tudja gyorsítótárazni az ilyen válaszokat. A letöltés folytatásának támogatásának hiánya — részlegesen fogadott chunked válaszokhoz nem lehet Range kérést intézni.
A HTTP Archive, 2025 szerint az összes HTTP-válasz körülbelül 35%-a használja a Transfer-Encoding: chunked-et. Ezek között a dinamikus oldalak (60%), az API-válaszok (25%) és a média streamek (15%) dominálnak. A statikus fájlok szinte mindig Content-Length-t használnak, mivel a méretük előre ismert. A chunked válaszok aránya fokozatosan csökken a HTTP/2 elterjedésével, ahol a streaming átvitel keret szinten van megvalósítva, anélkül, hogy szükség lenne egy további Transfer-Encoding fejléc.
Gyakorlati ajánlások
A mobilalkalmazás-fejlesztésben használja a Chunked Transfer-t nagy fájlok (képek, videók) betöltésére és olyan API-kérésekhez, amelyek nagy adattömböket adnak vissza. Az OkHttp teljes mértékben támogatja a chunked transfer-t további konfiguráció nélkül. Szerverre történő feltöltéshez (upload) a Chunked Transfer nem alkalmazható — a Transfer-Encoding nem használatos upload esetén a HTTP/1.1-ben. iOS-en az URLSession különleges konfiguráció nélkül támogatja mind a chunked adatok küldését, mind fogadását. A JSON streaming elemzése (például a Jackson Streaming API-n vagy a Moshi-n keresztül) lehetővé teszi nagy JSON-tömbök feldolgozását a chunked adatfolyam beérkezésekor.
Gyakran Ismételt Kérdések
Hogyan kapcsolja be a szerver a Chunked Transfer-t?
A szerver automatikusan bekapcsolja a Chunked Transfer-t, amikor a válasz mérete nem ismert. Az Nginx hozzáadja a Transfer-Encoding: chunked-et, ha a Content-Length nincs beállítva. A Spring Boot-ban a StreamingResponseBody és a SseEmitter automatikusan chunked transfer-t használnak. A Node.js Express-ben a válasz chunked lesz, ha a res.write() és res.end() hívása Content-Length nélkül történik.
Használható-e a Content-Length és a chunked egyidejűleg?
Nem, a HTTP/1.1 specifikáció tiltja a Content-Length és a Transfer-Encoding: chunked egyidejű használatát. Ha a szerver mindkét fejlécet elküldi, a kliensnek figyelmen kívül kell hagynia a Content-Length-t, és a választ chunked-ként kell feldolgoznia. Ezt a szabályt az RFC 7230 határozza meg a proxy szerverekkel való kompatibilitás érdekében, amelyek módosíthatják a válasz törzsét.
Mekkora chunk méret az optimális?
Az optimális chunk méret a forgatókönyvtől függ. Általános weboldalak esetén — 4-8 KB. Video streaming esetén — 16-64 KB. SSE esetén — minimális, 1-2 KB-os chunkok a késleltetés csökkentése érdekében. A chunk méretének a TCP-szegmens méretének (Ethernet esetén 1460 bájt) többszörösének kell lennie a szállítási rétegbeli fragmentáció minimalizálása érdekében.
Működik-e a Chunked Transfer proxyn keresztül?
A modern proxy szerverek (Nginx, HAProxy, Envoy) támogatják a Chunked Transfer-t. A proxy továbbíthatja a chunkokat pufferelés nélkül (streaming), vagy pufferelheti a teljes választ, és újraküldheti Content-Length segítségével. A régebbi proxyk pufferelhetik a chunked választ a befejezésig, ami növeli a késleltetést. A HTTP/2 protokoll szinten oldja meg ezt a problémát.
Miben különbözik a Chunked Transfer a HTTP chunked encoding-tól?
Ugyanaz. A Chunked Transfer a mechanizmus teljes neve a HTTP/1.1 specifikációból. A HTTP chunked encoding ugyanaz, néha a könyvtárak dokumentációjában használatos. A Transfer-Encoding: chunked az a fejléc, amely ezt a módot bekapcsolja. Mindhárom kifejezés ugyanazt az adatok részenkénti továbbítási mechanizmusát írja le.
Összefoglalás
- Chunked Transfer — HTTP/1.1 mechanizmus, amely a válasz törzsét chunkokban továbbítja a Content-Length előzetes megadása nélkül.
- Transfer-Encoding: chunked — a chunk átvitelt bekapcsoló fejléc; minden chunk tartalmaz hex méretet, adatokat és CRLF-et.
- Nulla méretű záró chunk jelzi az átvitel végét, amely után trailer fejlécek következhetnek.
- Dynamic content streaming — fő alkalmazás: dinamikus oldalak, SSE, streaming audio/video, hosszú jelentések.
- A Content-Length és a chunked kölcsönösen kizárják egymást — a specifikáció tiltja e fejlécek egyidejű használatát.
- Előnyök — késleltetés csökkentése, memóriamegtakarítás, végtelen streamek továbbításának lehetősége és streaming feldolgozás a kliens oldalán.
- Korlátozások — chunk fejlécek többletterhelése, a folyamatjelző megjelenítésének lehetetlensége, problémák a régebbi proxy szerverekkel.
Kulcsrakész mobilalkalmazást fejlesztünk
Az IT Sectr 2017 óta készít iOS és Android alkalmazásokat induló vállalkozásoknak és vállalkozásoknak. Tanácsot adunk, és a legjobb megoldást javasoljuk.
Olvassa el is