Chunked Transfer sa web development — ano ito, format at prinsipyo ng chunk-based transmission
Chunked Transfer — ay isang mekanismo ng HTTP protocol kung saan ang server ay nagpapadala ng body ng response sa magkakahiwalay na fragment (chunks), nang hindi ipinapahiwatig nang maaga ang kabuuang laki ng data. Ang bawat chunk ay naglalaman ng sarili nitong laki sa hexadecimal format at data ng tinukoy na haba, at nagtatapos sa isang final chunk na may zero na laki. Ayon sa MDN Web Docs, 2025, ang Transfer-Encoding: chunked ay awtomatikong pinapagana ng server kapag ang laki ng response ay hindi alam nang maaga — halimbawa, sa pagbuo ng content on-the-fly o streaming data transmission.
Mga Pangunahing Punto
- Chunked Transfer — pagpapadala ng HTTP response sa mga bahagi nang walang paunang pagsasabi ng Content-Length.
- Transfer-Encoding: chunked — header na nagpapagana ng chunk mode ng data transmission.
- Bawat chunk ay naglalaman ng laki sa hex, data at pangwakas na CRLF, at ang dulo ay minarkahan ng chunk na zero ang laki.
- Streaming — pangunahing aplikasyon ng chunked transfer para sa pagpapadala ng audio, video at SSE events.
- Chunked Transfer ay hindi compatible sa Content-Length header — hindi sila ginagamit nang sabay.
Ano ang Chunked Transfer?
Chunked Transfer ay isang HTTP mechanism na tinukoy sa HTTP/1.1 specification (RFC 7230, seksyon 4.1) na nagpapahintulot sa server na magpadala ng body ng response sa mga bahagi nang hindi ipinapahiwatig ang kabuuang Content-Length. Sa halip na kalkulahin ang laki ng response bago ipadala, agad na sinisimulan ng server ang transmission, nagpapadala ng data sa mga fragment habang handa na ang mga ito. Ang bawat fragment ay may kasamang sariling header ng laki, na nagpapahintulot sa client na buuin ang response mula sa mga piraso.
Ang mechanism ay pinapagana ng header na Transfer-Encoding: chunked. Kapag nakita ng client ang header na ito sa response, alam niya na ang body ay ipapadala sa chunks at dapat basahin ang response sa isang loop: basahin ang laki ng chunk, pagkatapos basahin ang data ng tinukoy na laki, pagkatapos ulitin. Ang proseso ay nagtatapos kapag may nakitang chunk na zero ang laki. Ang Chunked Transfer ay isang mandatoryong bahagi ng HTTP/1.1, suportado ng lahat ng modernong web server at HTTP clients.
Ang pangunahing dahilan para gumamit ng chunked transfer ay dynamic content generation. Kapag ang server ay bumubuo ng response batay sa database query, external API o mahabang pagkalkula, hindi nito alam nang maaga ang laki ng resulta. Sa halip na i-buffer ang buong response sa memory (na mapanganib para sa malalaking volume), pinapagana ng server ang Transfer-Encoding: chunked at nagpapadala ng data habang handa na. Ito ay lalong mahalaga para sa mga server na may limitadong memory at para sa mga response na ang laki ay maaaring napakalaki — mula 100 MB pataas.
Pagkakaiba sa pagitan ng HTTP/1.1 chunked at HTTP/2
Sa HTTP/2, ang chunked transfer mechanism ay hindi umiiral bilang isang hiwalay na feature, dahil ang protocol ay gumagamit ng multiplexing ng streams sa frame level. Sa HTTP/2, ang data ng anumang laki ay ipinapadala sa DATA frames, at ang laki ng body ng response ay hindi kailangang ideklara nang maaga — ang stream ay maaaring isara anumang oras. Mga modernong server ay awtomatikong nagko-convert ng HTTP/1.1 chunked responses sa katumbas na streaming transmission kapag nag-proxy sa HTTP/2 upstream. Ang Chunked Transfer ay nananatiling may kaugnayan para sa HTTP/1.1 connections.
Paano gumagana ang chunk transmission
Kapag nagpasya ang server na gamitin ang Chunked Transfer, hindi nito kinakalkula ang Content-Length, kundi ipinapadala ang header na Transfer-Encoding: chunked. Pagkatapos ang body ng response ay nabubuo bilang isang sequence ng chunks. Bawat chunk ay nagsisimula sa isang linya na naglalaman ng laki ng chunk sa hexadecimal format (walang 0x prefix), na sinusundan ng CRLF ( ). Pagkatapos ay dumarating ang data ng chunk ng tinukoy na laki, na nagtatapos sa CRLF. Ang huling chunk ay may laki na 0, pagkatapos nito ay maaaring sumunod ang trailer headers.
Ang hexadecimal size ay nagpapahintulot sa pagpapadala ng chunks ng anumang laki — mula 1 byte hanggang theoretically unlimited volume. Sa praktika, ang laki ng chunk ay pinipili ng server: tipikal na halaga ay 4 KB, 8 KB o 16 KB. Ang optimal na laki ng chunk ay multiple ng TCP segment size (karaniwang 1460 bytes para sa Ethernet) upang mabawasan ang fragmentation sa transport layer. Ang Nginx ay gumagamit ng 4 KB chunks bilang default, Apache — 8 KB.
Ang client na nakatanggap ng Transfer-Encoding: chunked ay obligadong basahin ang response chunk sa chunk hanggang sa huling zero chunk. Kung hindi sinusuportahan ng client ang chunked transfer, hindi magagamit ng server ang mode na ito. Sa praktika, lahat ng modernong HTTP clients — browser, OkHttp, URLSession, curl — ay ganap na sumusuporta sa chunked responses. Streaming read ay nagpapahintulot sa client na simulan ang pagproseso ng data bago pa matanggap ang buong response, na kritikal para sa performance.
| Elemento ng chunk | Format | Halimbawa |
|---|---|---|
| Laki ng chunk | HEX + CRLF | 1000 |
| Data ng chunk | [laki bytes] + CRLF | [4096 bytes na data] |
| Pangwakas na chunk | 0 | 0 |
| Trailer (opsyonal) | Headers + CRLF | Expires: Wed, 21 Oct 2025 |
Trailer headers sa Chunked Transfer
Sinusuportahan ng Chunked Transfer ang trailer headers — karagdagang HTTP headers na ipinapadala pagkatapos ng huling chunk. Ito ay kapaki-pakinabang para sa metadata na malalaman lamang pagkatapos makumpleto ang pagbuo ng response: halimbawa, Content-MD5 o X-Compression-Ratio. Ang trailer headers ay dapat ideklara sa Trailer header: Content-MD5, X-Compression-Ratio. Sa praktika, bihirang ginagamit ang trailers — karamihan sa mga server ay hindi isinasama ang mga ito sa responses.
Format ng chunked response
Ang chunked response ay may mahigpit na tinukoy na istraktura na dapat i-parse nang tama ng client. Tingnan natin ang isang kumpletong halimbawa ng HTTP response na may Transfer-Encoding: chunked. Pagkatapos ng headers at blangkong linya, magsisimula ang body ng response. Ang istraktura ng body ay isang sequence: laki_chunk data laki_chunk data ... hanggang 0 . Ang bawat laki ay ipinapadala sa hexadecimal number system gamit ang ASCII characters.
Halimbawa ng server response na may Chunked Transfer:
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
7
Hello
6
World!
0
Sa halimbawang ito, ipinapadala ng server ang string “Hello World!” sa dalawang chunks. Ang unang chunk na may 7 bytes ay naglalaman ng “Hello ”, ang pangalawa — 6 bytes “World!”. Kinokolekta ng client ang data mula sa parehong chunks at nakukuha ang kumpletong string. Mahalaga: ang laki ng chunk ay sumasaklaw lamang sa data, hindi kasama ang CRLF separators ng chunks mismo. Ang huling blangkong chunk (0 ) ay nagpapaalam sa client na tapos na ang transmission.
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()
}Pag-parse ng chunked response sa OkHttp
Ang OkHttp ay ganap na nag-a-abstract ng programmer mula sa mga detalye ng Chunked Transfer. Sa pagtanggap ng response na may Transfer-Encoding: chunked, awtomatikong kinokolekta ng OkHttp ang mga chunks at ibinibigay sa programmer ang kumpletong body ng response sa pamamagitan ng response.body?.string(). Para sa streaming processing, ginagamit ang response.body?.source(), na nagbabalik ng BufferedSource at nagpapahintulot sa pagbasa ng data habang dumarating. Hindi kailangang manu-manong i-parse ng programmer ang hex sizes at CRLF — awtomatikong ginagawa ito ng library.
Chunked Transfer vs Content-Length
Ang Content-Length at Transfer-Encoding: chunked ay dalawang magkaeksklusibong paraan upang tukuyin ang laki ng body ng HTTP message. Content-Length ay isang header na naglalaman ng eksaktong laki ng body sa bytes. Ito ay sapilitan para sa mga response na ang laki ay alam nang maaga at para sa mga request na may body (POST, PUT). Ang Content-Length ay nagpapahintulot sa client na mag-allocate nang maaga ng buffer ng tamang laki at suriin kung lahat ng data ay natanggap.
Ang Chunked Transfer ay ginagamit kapag ang laki ng body ay hindi alam nang maaga. Ito ay nangyayari sa tatlong pangunahing scenario: dynamic content generation (halimbawa, database query na ang resulta ay hindi pa natatanggap), streaming ng malalaking file (upang hindi i-buffer ang buong file sa memory) at Server-Sent Events (SSE) para sa real-time na pagpapadala ng events. Ang pagpili sa pagitan ng Content-Length at chunked ay responsibilidad ng server. Kung alam ng server ang laki bago magsimula ang transmission, dapat itong gumamit ng Content-Length bilang mas simple at mas predictable na mechanism.
Ang HTTP/1.1 specification ay nagbabawal sa sabayang paggamit ng Content-Length at Transfer-Encoding: chunked. Kung ang server ay nagpapadala ng parehong headers, dapat balewalain ng client ang Content-Length at i-process ang response bilang chunked. Ang priyoridad ng Transfer-Encoding kaysa sa Content-Length ay itinatag sa RFC 7230 para sa mga kaso kung saan binabago ng proxy server ang body ng response at hindi mapapanatili ang orihinal na Content-Length. Ang ilang lumang HTTP clients ay hindi wastong nagpo-process ng sitwasyong ito, ngunit ang mga modernong implementasyon ay sumusunod sa specification.
Kailan imposible ang Content-Length
May mga scenario kung saan ang Content-Length ay hindi maaaring kalkulahin nang maaga sa prinsipyo. Mga dynamic na ulat na nabuo batay sa request ng user na may filtering at aggregation — hindi alam ng server ang dami ng data hanggang sa makumpleto ang database query. Streaming video na ipinapadala mula sa camera sa real-time — ang laki ay walang katapusan. SSE at long polling para sa mga notification — ang response ay maaaring tumagal nang walang tiyak na panahon. Sa lahat ng kasong ito, ang Chunked Transfer ay ang tanging tamang mechanism.
Streaming batay sa chunked transfer
Ang Chunked Transfer ay nasa pundasyon ng maraming streaming technology sa web. Ang pinakasikat ay Server-Sent Events (SSE), kung saan ang server ay nagpapadala ng events sa client sa pamamagitan ng isang HTTP connection na may Transfer-Encoding: chunked. Ang SSE ay gumagamit ng espesyal na text format (data: mensahe ), ngunit ang transport layer ay ordinaryong chunked transfer. Ang browser ay tumatanggap ng events habang ipinapadala ng server, nang hindi naghihintay na matapos ang response.
Ang audio at video streaming ay umaasa rin sa Chunked Transfer. Ang mga media server tulad ng Nginx RTMP at Wowza Streaming Engine ay nagpapadala ng media data sa chunks sa pamamagitan ng HTTP. Ang player sa client side ay nagsisimulang mag-play kapag natanggap ang unang chunk, nang hindi naghihintay ng kumpletong pag-load ng file. Ito ay nagbabawas ng oras hanggang sa simula ng playback (Time to First Frame) mula sa sampung segundo hanggang 1-2 segundo. Ang YouTube at Netflix ay gumagamit ng eksaktong approach na ito para sa kanilang HTTP streams.
Sa pag-develop ng mobile apps, ang Chunked Transfer ay ginagamit para sa pagpapadala ng malalaking volume ng data nang hindi nilo-load ang buong response sa memory. Sa pag-load ng mga larawan sa pamamagitan ng Coil o Glide sa Android, ang mga library ay nagbabasa ng streaming data sa chunks at dahan-dahang dini-decode ang imahe. Ito ay nagpapahintulot sa pagpapakita ng malalaking larawan (10+ MB) nang walang OutOfMemoryError. Sinusuportahan ng OkHttp ang streaming read sa pamamagitan ng response.body?.byteStream(), na nagbabalik ng InputStream na nagbabasa ng data chunk sa chunk.
Chunked transfer sa gRPC at GraphQL
Ang gRPC ay gumagamit ng HTTP/2, kung saan ang streaming transmission ay naka-embed sa protocol level at hindi nangangailangan ng hiwalay na chunked mechanism. Ang mga GraphQL server na gumagana sa pamamagitan ng HTTP/1.1 ay maaaring gumamit ng Chunked Transfer para sa streaming transmission ng subscription results. Ang Apollo Server at Hasura ay nagpapadala ng chunked responses para sa GraphQL subscriptions, na nagpapadala ng events habang nangyayari ang mga ito. Ang client ay tumatanggap ng real-time updates nang hindi nangangailangan ng polling.
Mga Bentahe at Limitasyon
Ang Chunked Transfer ay nagbibigay ng mahahalagang bentahe para sa web applications. Agad na pagpapadala ng data — hindi bina-buffer ng server ang response bago ipadala, binabawasan ang latency hanggang sa unang byte. Streaming processing — ang client ay maaaring magsimulang mag-process ng data habang dumarating, nang hindi naghihintay ng kumpletong pag-load. Walang limitasyon sa memory — hindi iniimbak ng server ang buong response sa memory, na kritikal para sa malalaking volume ng data. Kakayahang magpadala ng walang katapusang streams — SSE, live video, monitoring.
Gayunpaman, ang Chunked Transfer ay may mga limitasyon. Overhead para sa bawat chunk ay 6-12 bytes para sa laki + CRLF, na para sa malaking bilang ng maliliit na chunks (halimbawa, 100 bytes) ay maaaring tumaas ang laki ng response ng 10-15%. Hindi matukoy ang eksaktong laki — hindi makapag-allocate ang client ng buffer nang maaga o magpakita ng progress bar. Mga problema sa proxy servers — ang ilang lumang proxy ay hindi sumusuporta sa chunked transfer at hindi ma-cache ang mga ganitong response. Kawalan ng suporta sa pagpapatuloy ng pag-download — para sa bahagyang natanggap na chunked responses, hindi magawa ang Range request.
Ayon sa HTTP Archive, 2025, humigit-kumulang 35% ng lahat ng HTTP response ay gumagamit ng Transfer-Encoding: chunked. Sa mga ito, nangingibabaw ang mga dynamic na pahina (60%), API responses (25%) at media streams (15%). Ang mga static na file ay halos palaging gumagamit ng Content-Length dahil ang kanilang laki ay alam nang maaga. Ang bahagi ng chunked responses ay unti-unting bumababa sa paglaganap ng HTTP/2, kung saan ang streaming transmission ay naka-implement sa frame level nang hindi nangangailangan ng karagdagang Transfer-Encoding header.
Mga Praktikal na Rekomendasyon
Sa pag-develop ng mobile apps, gamitin ang Chunked Transfer para sa pag-load ng malalaking file (mga larawan, video) at para sa API requests na nagbabalik ng malalaking data arrays. Ganap na sinusuportahan ng OkHttp ang chunked transfer nang walang karagdagang configuration. Para sa pag-upload sa server (upload), hindi ginagamit ang Chunked Transfer — ang Transfer-Encoding ay hindi ginagamit para sa upload sa HTTP/1.1. Sa iOS, sinusuportahan ng URLSession ang parehong pagpapadala at pagtanggap ng chunked data nang walang espesyal na configuration. Ang streaming parsing ng JSON (halimbawa, sa pamamagitan ng Jackson Streaming API o Moshi) ay nagpapahintulot sa pag-process ng malalaking JSON arrays habang dumarating ang chunked stream.
Mga Madalas Itanong
Paano pinapagana ng server ang Chunked Transfer?
Awtomatikong pinapagana ng server ang Chunked Transfer kapag hindi alam ang laki ng response. Nagdaragdag ang Nginx ng Transfer-Encoding: chunked kung hindi naka-set ang Content-Length. Sa Spring Boot, awtomatikong gumagamit ang StreamingResponseBody at SseEmitter ng chunked transfer. Sa Node.js Express, nagiging chunked ang response kung tatawagin ang res.write() at res.end() nang walang Content-Length.
Maaari bang gamitin nang sabay ang Content-Length at chunked?
Hindi, ipinagbabawal ng HTTP/1.1 specification ang sabayang paggamit ng Content-Length at Transfer-Encoding: chunked. Kung nagpapadala ang server ng parehong headers, dapat balewalain ng client ang Content-Length at i-process ang response bilang chunked. Ang patakarang ito ay itinatag sa RFC 7230 para sa compatibility sa mga proxy server na maaaring magbago ng body ng response.
Anong laki ng chunk ang optimal?
Ang optimal na laki ng chunk ay depende sa scenario. Para sa ordinaryong web pages — 4-8 KB. Para sa video streaming — 16-64 KB. Para sa SSE — minimal na chunks na 1-2 KB para mabawasan ang latency. Ang laki ng chunk ay dapat na multiple ng TCP segment size (1460 bytes para sa Ethernet) upang mabawasan ang fragmentation sa transport layer.
Gumagana ba ang Chunked Transfer sa pamamagitan ng proxy?
Sinusuportahan ng mga modernong proxy server (Nginx, HAProxy, Envoy) ang Chunked Transfer. Maaaring ipasa ng proxy ang chunks nang walang buffering (streaming) o i-buffer ang buong response at ipadala itong muli gamit ang Content-Length. Mga lumang proxy ay maaaring mag-buffer ng chunked response hanggang sa matapos, na nagpapataas ng latency. Nilulutas ng HTTP/2 ang problemang ito sa protocol level.
Ano ang pagkakaiba ng Chunked Transfer sa HTTP chunked encoding?
Iisa lang ang mga ito. Chunked Transfer ang buong pangalan ng mechanism mula sa HTTP/1.1 specification. Ang HTTP chunked encoding ay pareho, minsan ginagamit sa dokumentasyon ng mga library. Ang Transfer-Encoding: chunked ay ang header na nagpapagana ng mode na ito. Lahat ng tatlong termino ay naglalarawan ng parehong mechanism ng pagpapadala ng data sa mga bahagi.
Buod
- Chunked Transfer — HTTP/1.1 mechanism na nagpapadala ng body ng response sa chunks nang walang paunang pagsasabi ng Content-Length.
- Transfer-Encoding: chunked — header na nagpapagana ng chunk transmission; bawat chunk ay naglalaman ng hex size, data at CRLF.
- Pangwakas na chunk na zero ang laki ay nagpapahiwatig ng pagtatapos ng transmission, pagkatapos nito ay maaaring sumunod ang trailer headers.
- Dynamic content streaming — pangunahing aplikasyon: dynamic na pahina, SSE, streaming audio/video, mahabang ulat.
- Ang Content-Length at chunked ay magkaeksklusibo — ipinagbabawal ng specification ang sabayang paggamit ng mga header na ito.
- Mga Bentahe — pagbawas ng latency, pagtipid ng memory, kakayahang magpadala ng walang katapusang streams, at streaming processing sa client side.
- Mga Limitasyon — overhead ng chunk headers, hindi maipakita ang progreso, mga problema sa lumang proxy servers.
Gagawa kami ng mobile application na turnkey
Gumagawa ang IT Sectr ng mga iOS at Android application para sa mga startup at negosyo mula noong 2017. Magpapayo kami sa iyo at magmumungkahi ng pinakamahusay na solusyon.
Basahin din