Chunked Transfer dalam pengembangan web — apa itu, format dan prinsip pengiriman chunk
Chunked Transfer — adalah mekanisme protokol HTTP di mana server mengirimkan body respons dalam fragmen terpisah (chunk), tanpa menentukan ukuran total data sebelumnya. Setiap chunk berisi ukurannya dalam format heksadesimal dan data dengan panjang yang ditentukan, serta diakhiri dengan chunk akhir berukuran nol. Menurut MDN Web Docs, 2025, Transfer-Encoding: chunked diaktifkan secara otomatis oleh server ketika ukuran respons tidak diketahui sebelumnya — misalnya, saat menghasilkan konten secara langsung atau mengirimkan data secara streaming.
Poin Utama
- Chunked Transfer — pengiriman respons HTTP dalam bagian tanpa menentukan Content-Length sebelumnya.
- Transfer-Encoding: chunked — header yang mengaktifkan mode pengiriman data chunk.
- Setiap chunk berisi ukuran dalam hex, data, dan CRLF penutup, serta akhir ditandai dengan chunk berukuran nol.
- Streaming — penerapan utama chunked transfer untuk mengirimkan audio, video, dan event SSE.
- Chunked Transfer tidak kompatibel dengan header Content-Length — keduanya tidak digunakan bersamaan.
Apa itu Chunked Transfer?
Chunked Transfer adalah mekanisme HTTP yang didefinisikan dalam spesifikasi HTTP/1.1 (RFC 7230, bagian 4.1) yang memungkinkan server mengirimkan body respons dalam bagian tanpa menentukan Content-Length total. Alih-alih menghitung ukuran respons sebelum pengiriman, server segera memulai transmisi, mengirimkan data dalam fragmen saat sudah siap. Setiap fragmen disertai dengan header ukurannya sendiri, memungkinkan klien untuk merakit respons dari potongan-potongan.
Mekanisme ini diaktifkan oleh header Transfer-Encoding: chunked. Ketika klien melihat header ini dalam respons, ia tahu bahwa body akan dikirim dalam chunk dan harus membaca respons dalam satu siklus: baca ukuran chunk, lalu baca data dengan ukuran yang ditentukan, lalu ulangi. Proses berakhir ketika chunk berukuran nol ditemukan. Chunked Transfer adalah bagian wajib dari HTTP/1.1, didukung oleh semua server web modern dan klien HTTP.
Alasan utama penggunaan chunked transfer adalah pembuatan konten dinamis. Ketika server menghasilkan respons berdasarkan kueri basis data, API eksternal, atau perhitungan yang lama, ia tidak dapat mengetahui ukuran hasilnya sebelumnya. Alih-alih mem-buffer seluruh respons di memori (yang berisiko untuk volume besar), server mengaktifkan Transfer-Encoding: chunked dan mengirimkan data saat sudah siap. Ini sangat penting untuk server dengan memori terbatas dan untuk respons yang ukurannya bisa sangat besar — mulai dari 100 MB ke atas.
Perbedaan antara HTTP/1.1 chunked dan HTTP/2
Dalam HTTP/2, mekanisme chunked transfer tidak ada sebagai fitur terpisah, karena protokol menggunakan multipleksasi aliran di tingkat frame. Dalam HTTP/2, data dengan ukuran berapa pun dikirimkan dalam frame DATA, dan ukuran body respons tidak perlu dideklarasikan sebelumnya — aliran dapat ditutup kapan saja. Server modern secara otomatis mengonversi respons chunked HTTP/1.1 menjadi transmisi streaming yang setara saat melakukan proxy ke upstream HTTP/2. Chunked Transfer tetap relevan untuk koneksi HTTP/1.1.
Bagaimana cara kerja pengiriman chunk
Ketika server memutuskan untuk menggunakan Chunked Transfer, ia tidak menghitung Content-Length, melainkan mengirimkan header Transfer-Encoding: chunked. Kemudian body respons dibentuk sebagai urutan chunk. Setiap chunk dimulai dengan baris yang berisi ukuran chunk dalam format heksadesimal (tanpa awalan 0x), diikuti oleh CRLF ( ). Kemudian datang data chunk dengan ukuran yang ditentukan, diakhiri dengan CRLF. Chunk terakhir memiliki ukuran 0, setelah itu dapat diikuti header trailer.
Ukuran heksadesimal memungkinkan pengiriman chunk dengan ukuran berapa pun — dari 1 byte hingga volume yang secara teoritis tidak terbatas. Dalam praktiknya, ukuran chunk dipilih oleh server: nilai tipikal adalah 4 KB, 8 KB, atau 16 KB. Ukuran chunk yang optimal adalah kelipatan dari ukuran segmen TCP (biasanya 1460 byte untuk Ethernet) untuk meminimalkan fragmentasi di tingkat transportasi. Nginx menggunakan chunk 4 KB secara default, Apache — 8 KB.
Klien yang menerima Transfer-Encoding: chunked wajib membaca respons chunk demi chunk hingga chunk nol terakhir. Jika klien tidak mendukung chunked transfer, server tidak dapat menggunakan mode ini. Dalam praktiknya, semua klien HTTP modern — browser, OkHttp, URLSession, curl — sepenuhnya mendukung respons chunked. Pembacaan streaming memungkinkan klien untuk mulai memproses data sebelum menerima respons lengkap, yang sangat penting untuk kinerja.
| Elemen chunk | Format | Contoh |
|---|---|---|
| Ukuran chunk | HEX + CRLF | 1000 |
| Data chunk | [ukuran byte] + CRLF | [4096 byte data] |
| Chunk akhir | 0 | 0 |
| Trailer (opsional) | Header + CRLF | Expires: Wed, 21 Oct 2025 |
Header trailer dalam Chunked Transfer
Chunked Transfer mendukung header trailer — header HTTP tambahan yang dikirimkan setelah chunk terakhir. Ini berguna untuk metadata yang baru diketahui setelah pembuatan respons selesai: misalnya, Content-MD5 atau X-Compression-Ratio. Header trailer harus dideklarasikan dalam header Trailer: Content-MD5, X-Compression-Ratio. Dalam praktiknya, trailer jarang digunakan — sebagian besar server tidak menyertakannya dalam respons.
Format respons chunked
Respons chunked memiliki struktur yang ditentukan secara ketat yang harus diuraikan dengan benar oleh klien. Mari kita lihat contoh lengkap respons HTTP dengan Transfer-Encoding: chunked. Setelah header dan baris kosong, body respons dimulai. Struktur body adalah urutan: ukuran_chunk data ukuran_chunk data ... hingga 0 . Setiap ukuran dikirimkan dalam sistem bilangan heksadesimal dengan karakter ASCII.
Contoh respons server dengan Chunked Transfer:
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
7
Hello
6
World!
0
Dalam contoh ini, server mengirimkan string “Hello World!” dalam dua chunk. Chunk pertama berukuran 7 byte berisi “Hello ”, yang kedua — 6 byte “World!”. Klien mengumpulkan data dari kedua chunk dan mendapatkan string lengkap. Penting: ukuran chunk hanya mencakup data, tidak termasuk pemisah CRLF dari chunk itu sendiri. Chunk kosong terakhir (0 ) memberi tahu klien bahwa transmisi telah berakhir.
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()
}Menguraikan respons chunked di OkHttp
OkHttp sepenuhnya mengabstraksi programmer dari detail Chunked Transfer. Saat menerima respons dengan Transfer-Encoding: chunked, OkHttp secara otomatis mengumpulkan chunk dan menyediakan body respons lengkap kepada programmer melalui response.body?.string(). Untuk pemrosesan streaming, digunakan response.body?.source(), yang mengembalikan BufferedSource dan memungkinkan pembacaan data saat tiba. Programmer tidak perlu menguraikan ukuran hex dan CRLF secara manual — pustaka melakukannya secara otomatis.
Chunked Transfer vs Content-Length
Content-Length dan Transfer-Encoding: chunked adalah dua cara yang saling eksklusif untuk menentukan ukuran body pesan HTTP. Content-Length adalah header yang berisi ukuran body yang tepat dalam byte. Ini wajib untuk respons yang ukurannya diketahui sebelumnya dan untuk permintaan dengan body (POST, PUT). Content-Length memungkinkan klien untuk mengalokasikan buffer dengan ukuran yang tepat sebelumnya dan memeriksa apakah semua data telah diterima.
Chunked Transfer digunakan ketika ukuran body tidak diketahui sebelumnya. Ini terjadi dalam tiga skenario utama: pembuatan konten dinamis (misalnya, kueri basis data yang hasilnya belum diterima), pengiriman streaming file besar (untuk tidak mem-buffer seluruh file di memori) dan Server-Sent Events (SSE) untuk mengirimkan event secara real-time. Pilihan antara Content-Length dan chunked adalah tanggung jawab server. Jika server mengetahui ukuran sebelum transmisi dimulai, ia harus menggunakan Content-Length sebagai mekanisme yang lebih sederhana dan lebih dapat diprediksi.
Spesifikasi HTTP/1.1 melarang penggunaan simultan Content-Length dan Transfer-Encoding: chunked. Jika server mengirimkan kedua header, klien harus mengabaikan Content-Length dan memproses respons sebagai chunked. Prioritas Transfer-Encoding atas Content-Length ditetapkan dalam RFC 7230 untuk kasus di mana server proxy memodifikasi body respons dan tidak dapat mempertahankan Content-Length asli. Beberapa klien HTTP lama memproses situasi ini secara tidak benar, tetapi implementasi modern mengikuti spesifikasi.
Kapan Content-Length tidak mungkin
Ada skenario di mana Content-Length pada prinsipnya tidak dapat dihitung sebelumnya. Laporan dinamis yang dihasilkan berdasarkan permintaan pengguna dengan pemfilteran dan agregasi — server tidak mengetahui volume data hingga kueri basis data selesai. Video streaming yang dikirimkan dari kamera secara real-time — ukurannya tidak terbatas. SSE dan long polling untuk notifikasi — respons dapat berlangsung tanpa batas waktu. Dalam semua kasus ini, Chunked Transfer adalah satu-satunya mekanisme yang benar.
Streaming berbasis chunked transfer
Chunked Transfer mendasari banyak teknologi streaming di web. Yang paling terkenal adalah Server-Sent Events (SSE), di mana server mengirimkan event ke klien melalui satu koneksi HTTP dengan Transfer-Encoding: chunked. SSE menggunakan format teks khusus (data: pesan ), tetapi lapisan transportasinya adalah chunked transfer biasa. Browser menerima event saat server mengirimkannya, tanpa menunggu respons selesai.
Streaming audio dan video juga bergantung pada Chunked Transfer. Server media seperti Nginx RTMP dan Wowza Streaming Engine mengirimkan data media dalam chunk melalui HTTP. Pemutar di sisi klien mulai memutar ketika chunk pertama diterima, tanpa menunggu file dimuat sepenuhnya. Ini mengurangi waktu hingga pemutaran dimulai (Time to First Frame) dari puluhan detik menjadi 1-2 detik. YouTube dan Netflix menggunakan pendekatan ini untuk streaming HTTP mereka.
Dalam pengembangan aplikasi seluler, Chunked Transfer digunakan untuk mengirimkan data dalam jumlah besar tanpa memuat seluruh respons ke memori. Saat memuat gambar melalui Coil atau Glide di Android, pustaka membaca data streaming dalam chunk dan mendekode gambar secara bertahap. Ini memungkinkan menampilkan gambar besar (10+ MB) tanpa OutOfMemoryError. OkHttp mendukung pembacaan streaming melalui response.body?.byteStream(), yang mengembalikan InputStream yang membaca data chunk demi chunk.
Chunked transfer dalam gRPC dan GraphQL
gRPC menggunakan HTTP/2, di mana transmisi streaming terintegrasi di tingkat protokol dan tidak memerlukan mekanisme chunked terpisah. Server GraphQL yang bekerja melalui HTTP/1.1 dapat menggunakan Chunked Transfer untuk mengirimkan streaming hasil langganan (subscriptions). Apollo Server dan Hasura mengirimkan respons chunked untuk langganan GraphQL, mentransmisikan event saat terjadi. Klien menerima pembaruan real-time tanpa perlu polling.
Keuntungan dan Keterbatasan
Chunked Transfer memberikan keuntungan penting untuk aplikasi web. Pengiriman data segera — server tidak mem-buffer respons sebelum pengiriman, mengurangi latensi hingga byte pertama. Pemrosesan streaming — klien dapat mulai memproses data saat tiba, tanpa menunggu pemuatan penuh. Tanpa batasan memori — server tidak menyimpan respons lengkap di memori, yang penting untuk volume data besar. Kemampuan mengirimkan streaming tak terbatas — SSE, video langsung, pemantauan.
Namun, Chunked Transfer memiliki keterbatasan. Overhead untuk setiap chunk adalah 6-12 byte untuk ukuran + CRLF, yang untuk sejumlah besar chunk kecil (misalnya, 100 byte) dapat meningkatkan ukuran respons sebesar 10-15%. Ketidakmampuan untuk menentukan ukuran yang tepat — klien tidak dapat mengalokasikan buffer sebelumnya atau menampilkan bilah kemajuan. Masalah dengan server proxy — beberapa proxy lama tidak mendukung chunked transfer dan tidak dapat menyimpan respons semacam itu dalam cache. Kurangnya dukungan untuk melanjutkan pengunduhan — untuk respons chunked yang diterima sebagian, permintaan Range tidak dapat dilakukan.
Menurut HTTP Archive, 2025, sekitar 35% dari semua respons HTTP menggunakan Transfer-Encoding: chunked. Di antaranya, halaman dinamis (60%), respons API (25%), dan streaming media (15%) mendominasi. File statis hampir selalu menggunakan Content-Length karena ukurannya diketahui sebelumnya. Pangsa respons chunked secara bertahap menurun dengan penyebaran HTTP/2, di mana transmisi streaming diimplementasikan di tingkat frame tanpa memerlukan header Transfer-Encoding tambahan.
Rekomendasi Praktis
Dalam pengembangan aplikasi seluler, gunakan Chunked Transfer untuk memuat file besar (gambar, video) dan untuk permintaan API yang mengembalikan array data besar. OkHttp sepenuhnya mendukung chunked transfer tanpa konfigurasi tambahan. Untuk unggahan ke server (upload), Chunked Transfer tidak berlaku — Transfer-Encoding tidak digunakan untuk upload di HTTP/1.1. Di iOS, URLSession mendukung baik pengiriman maupun penerimaan data chunked tanpa konfigurasi khusus. Penguraian JSON secara streaming (misalnya, melalui Jackson Streaming API atau Moshi) memungkinkan pemrosesan array JSON besar saat streaming chunked tiba.
Pertanyaan Umum
Bagaimana server mengaktifkan Chunked Transfer?
Server mengaktifkan Chunked Transfer secara otomatis ketika ukuran respons tidak diketahui. Nginx menambahkan Transfer-Encoding: chunked jika Content-Length tidak ditetapkan. Di Spring Boot, StreamingResponseBody dan SseEmitter secara otomatis menggunakan chunked transfer. Di Node.js Express, respons menjadi chunked jika res.write() dan res.end() dipanggil tanpa Content-Length.
Bisakah Content-Length dan chunked digunakan bersamaan?
Tidak, spesifikasi HTTP/1.1 melarang penggunaan simultan Content-Length dan Transfer-Encoding: chunked. Jika server mengirimkan kedua header, klien harus mengabaikan Content-Length dan memproses respons sebagai chunked. Aturan ini ditetapkan dalam RFC 7230 untuk kompatibilitas dengan server proxy yang dapat memodifikasi body respons.
Ukuran chunk apa yang optimal?
Ukuran chunk yang optimal tergantung pada skenario. Untuk halaman web biasa — 4-8 KB. Untuk streaming video — 16-64 KB. Untuk SSE — chunk minimal 1-2 KB untuk mengurangi latensi. Ukuran chunk harus merupakan kelipatan dari ukuran segmen TCP (1460 byte untuk Ethernet) untuk meminimalkan fragmentasi di tingkat transportasi.
Apakah Chunked Transfer bekerja melalui proxy?
Server proxy modern (Nginx, HAProxy, Envoy) mendukung Chunked Transfer. Proxy dapat meneruskan chunk tanpa buffering (streaming) atau mem-buffer seluruh respons dan mengirimkannya kembali dengan Content-Length. Proxy lama dapat mem-buffer respons chunked hingga selesai, yang meningkatkan latensi. HTTP/2 memecahkan masalah ini di tingkat protokol.
Apa perbedaan Chunked Transfer dengan HTTP chunked encoding?
Ini adalah hal yang sama. Chunked Transfer adalah nama lengkap mekanisme dari spesifikasi HTTP/1.1. HTTP chunked encoding adalah hal yang sama, kadang digunakan dalam dokumentasi pustaka. Transfer-Encoding: chunked adalah header yang mengaktifkan mode ini. Ketiga istilah tersebut menggambarkan mekanisme yang sama untuk mengirimkan data dalam bagian.
Ringkasan
- Chunked Transfer — mekanisme HTTP/1.1 yang mengirimkan body respons dalam chunk tanpa menentukan Content-Length sebelumnya.
- Transfer-Encoding: chunked — header yang mengaktifkan pengiriman chunk; setiap chunk berisi ukuran hex, data, dan CRLF.
- Chunk akhir berukuran nol menandakan akhir transmisi, setelah itu dapat diikuti header trailer.
- Dynamic content streaming — penerapan utama: halaman dinamis, SSE, streaming audio/video, laporan panjang.
- Content-Length dan chunked saling eksklusif — spesifikasi melarang penggunaan simultan header-header ini.
- Keuntungan — pengurangan latensi, penghematan memori, kemampuan mengirimkan streaming tak terbatas, dan pemrosesan streaming di sisi klien.
- Keterbatasan — overhead header chunk, ketidakmampuan menampilkan kemajuan, masalah dengan server proxy lama.
Kami akan mengembangkan aplikasi seluler turnkey
IT Sectr membuat aplikasi iOS dan Android untuk startup dan bisnis sejak 2017. Kami akan memberi saran dan mengusulkan solusi terbaik.
Baca juga