Chunked Transfer veb-ishlanmada — bu nima, format va chunk'larda uzatish prinsipi
Chunked Transfer — bu HTTP protokoli mexanizmi bo'lib, unda server javob tanasini alohida fragmentlar (chunk'lar) ko'rinishida uzatadi, ma'lumotlarning umumiy hajmini oldindan ko'rsatmasdan. Har bir chunk o'z hajmini o'n oltilik formatda va belgilangan uzunlikdagi ma'lumotlarni o'z ichiga oladi va nol hajmli yakuniy chunk bilan tugaydi. MDN Web Docs, 2025 ma'lumotlariga ko'ra, Transfer-Encoding: chunked server tomonidan avtomatik ravishda yoqiladi, bunda javob hajmi oldindan noma'lum — masalan, kontentni joyida yaratish yoki ma'lumotlarni streaming uzatishda.
Asosiy ma'lumotlar
- Chunked Transfer — HTTP javobini Content-Length oldindan ko'rsatmasdan qismlarga bo'lib uzatish.
- Transfer-Encoding: chunked — chunk rejimini yoqadigan sarlavha.
- Har bir chunk hex formatida hajm, ma'lumotlar va yakuniy CRLF ni o'z ichiga oladi, oxiri nol hajmli chunk bilan belgilanadi.
- Streaming — audio, video va SSE hodisalarini uzatish uchun chunked transferning asosiy qo'llanilishi.
- Chunked Transfer Content-Length sarlavhasi bilan mos kelmaydi — ular bir vaqtda ishlatilmaydi.
Chunked Transfer nima?
Chunked Transfer — bu HTTP/1.1 spetsifikatsiyasida (RFC 7230, 4.1-bo'lim) aniqlangan HTTP mexanizmi bo'lib, serverga javob tanasini umumiy Content-Length ko'rsatmasdan qismlarga bo'lib yuborish imkonini beradi. Javob hajmini yuborishdan oldin hisoblash o'rniga, server darhol uzatishni boshlaydi, ma'lumotlarni tayyor bo'lgach fragmentlarda yuboradi. Har bir fragment o'z hajm sarlavhasi bilan birga keladi, bu esa mijozga javobni qismlardan yig'ish imkonini beradi.
Mexanizm Transfer-Encoding: chunked sarlavhasi bilan yoqiladi. Mijoz javobda ushbu sarlavhani ko'rganida, tana chunk'larda uzatilishini biladi va javobni tsiklda o'qishi kerak: chunk hajmini o'qish, keyin belgilangan hajmdagi ma'lumotlarni o'qish, keyin takrorlash. Jarayon nol hajmli chunk uchraganda tugaydi. Chunked Transfer HTTP/1.1 ning majburiy qismi bo'lib, barcha zamonaviy veb-serverlar va HTTP mijozlari tomonidan qo'llab-quvvatlanadi.
Chunked transfer dan foydalanishning asosiy sababi kontentni dinamik yaratish dir. Server ma'lumotlar bazasi so'rovi, tashqi API yoki uzoq davom etadigan hisoblash asosida javob yaratganda, natija hajmini oldindan bila olmaydi. Butun javobni xotirada buferlash o'rniga (bu katta hajmlar uchun xavfli), server Transfer-Encoding: chunked ni yoqadi va ma'lumotlarni tayyor bo'lgach yuboradi. Bu, ayniqsa, cheklangan xotiraga ega serverlar va hajmi juda katta bo'lishi mumkin bo'lgan javoblar uchun muhimdir — 100 MB va undan yuqori.
HTTP/1.1 chunked va HTTP/2 o'rtasidagi farq
HTTP/2 da chunked transfer mexanizmi alohida mavjud emas, chunki protokol freymlar darajasida oqimlarni multipleksatsiyalashdan foydalanadi. HTTP/2 da istalgan hajmdagi ma'lumotlar DATA freymlarida uzatiladi va javob tanasining hajmini oldindan e'lon qilish shart emas — oqim istalgan vaqtda yopilishi mumkin. Zamonaviy serverlar HTTP/1.1 chunked javoblarini HTTP/2 upstream ga proksi qilishda avtomatik ravishda ekvivalent oqim uzatishga o'tkazadi. Chunked Transfer HTTP/1.1 ulanishlari uchun dolzarbligicha qoladi.
Chunk'larda uzatish qanday ishlaydi
Server Chunked Transfer dan foydalanishga qaror qilganda, Content-Length hisoblamaydi, Transfer-Encoding: chunked sarlavhasini yuboradi. Keyin javob tanasi chunk'lar ketma-ketligi sifatida shakllantiriladi. Har bir chunk o'n oltilik formatda (0x prefiksisiz) chunk hajmini o'z ichiga olgan qator bilan boshlanadi, undan keyin CRLF ( ) keladi. Keyin belgilangan hajmdagi chunk ma'lumotlari va CRLF keladi. Oxirgi chunk hajmi 0 ga teng, undan keyin trailer sarlavhalari bo'lishi mumkin.
O'n oltilik hajm istalgan hajmdagi chunk'larni uzatish imkonini beradi — 1 baytdan nazariy jihatdan cheksiz hajmgacha. Amalda chunk hajmi server tomonidan tanlanadi: odatiy qiymatlar 4 KB, 8 KB yoki 16 KB. Optimal chunk hajmi TCP segmenti hajmiga (Ethernet uchun odatda 1460 bayt) karrali bo'lishi kerak, transport darajasida fragmentatsiyani minimallashtirish uchun. Nginx standart sifatida 4 KB chunk'lardan, Apache esa 8 KB chunk'lardan foydalanadi.
Transfer-Encoding: chunked olgan mijoz oxirgi nol chunkkacha javobni chunk-chunk o'qishi shart. Agar mijoz chunked transferni qo'llab-quvvatlamasa, server bu rejimdan foydalana olmaydi. Amalda barcha zamonaviy HTTP mijozlari — brauzerlar, OkHttp, URLSession, curl — chunked javoblarni to'liq qo'llab-quvvatlaydi. Oqim bilan o'qish mijozga to'liq javobni olmasdan ma'lumotlarni qayta ishlashni boshlash imkonini beradi, bu ishlash uchun juda muhimdir.
| Chunk elementi | Format | Misol |
|---|---|---|
| Chunk hajmi | HEX + CRLF | 1000 |
| Chunk ma'lumotlari | [hajm bayt] + CRLF | [4096 bayt ma'lumot] |
| Yakuniy chunk | 0 | 0 |
| Trailer (ixtiyoriy) | Sarlavhalar + CRLF | Expires: Wed, 21 Oct 2025 |
Chunked Transfer da trailer sarlavhalari
Chunked Transfer trailer sarlavhalarini qo'llab-quvvatlaydi — oxirgi chunkdan keyin uzatiladigan qo'shimcha HTTP sarlavhalari. Bu javob yaratish tugaganidan keyin ma'lum bo'ladigan metama'lumotlar uchun foydalidir: masalan, Content-MD5 yoki X-Compression-Ratio. Trailer sarlavhalari Trailer sarlavhasida e'lon qilinishi kerak: Content-MD5, X-Compression-Ratio. Amalda trailer kamdan-kam ishlatiladi — aksariyat serverlar ularni javoblarga kiritmaydi.
Chunked javob formati
Chunked javob qat'iy belgilangan tuzilishga ega bo'lib, mijoz uni to'g'ri tahlil qilishi kerak. Transfer-Encoding: chunked bilan HTTP javobining to'liq misolini ko'rib chiqaylik. Sarlavhalar va bo'sh qatordan keyin javob tanasi boshlanadi. Tana tuzilishi ketma-ketlikdir: chunk_hajmi ma'lumotlar chunk_hajmi ma'lumotlar ... 0 gacha. Har bir hajm ASCII belgilar bilan o'n oltilik sanoq tizimida uzatiladi.
Chunked Transfer bilan server javobiga misol:
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
7
Hello
6
World!
0
Ushbu misolda server “Hello World!” qatorini ikkita chunk bilan uzatadi. Birinchi chunk 7 bayt hajmda “Hello ”, ikkinchisi — 6 bayt “World!” ni o'z ichiga oladi. Mijoz ikkala chunk'dan ma'lumotlarni yig'adi va to'liq qatorni oladi. Muhim: chunk hajmi faqat ma'lumotlarni o'z ichiga oladi, chunk'larning CRLF ajratgichlarini o'z ichiga olmaydi. Yakuniy bo'sh chunk (0 ) mijozga uzatish tugaganini bildiradi.
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()
}OkHttp da chunked javobni tahlil qilish
OkHttp dasturchini Chunked Transfer tafsilotlaridan butunlay abstraksiya qiladi. Transfer-Encoding: chunked bilan javob olinganda, OkHttp avtomatik ravishda chunk'larni yig'adi va dasturchiga response.body?.string() orqali to'liq javob tanasini taqdim etadi. Oqim bilan qayta ishlash uchun response.body?.source() ishlatiladi, u BufferedSource qaytaradi va ma'lumotlarni kelishi bilan o'qish imkonini beradi. Dasturchi qo'lda hex hajmlarini va CRLFni tahlil qilishi shart emas — kutubxona buni avtomatik bajaradi.
Chunked Transfer vs Content-Length
Content-Length va Transfer-Encoding: chunked HTTP xabarining tana hajmini ko'rsatishning ikkita bir-birini istisno qiluvchi usulidir. Content-Length tananing aniq hajmini baytlarda o'z ichiga olgan sarlavhadir. Hajmi oldindan ma'lum bo'lgan javoblar va tanali so'rovlar (POST, PUT) uchun majburiydir. Content-Length mijozga oldindan tegishli hajmdagi bufer ajratish va barcha ma'lumotlar olinganligini tekshirish imkonini beradi.
Chunked Transfer tana hajmi oldindan noma'lum bo'lganda ishlatiladi. Bu uchta asosiy stsenariyda sodir bo'ladi: kontentni dinamik yaratish (masalan, natijasi hali olinmagan ma'lumotlar bazasi so'rovi), katta fayllarni streaming uzatish (butun faylni xotirada buferlamaslik uchun) va Server-Sent Events (SSE) real vaqt hodisalarini uzatish uchun. Tanlov Content-Length va chunked o'rtasida serverning mas'uliyatidir. Agar server uzatish boshlanishidan oldin hajmni bilsa, Content-Length ni oddiyroq va bashorat qilinadigan mexanizm sifatida ishlatishi kerak.
HTTP/1.1 spetsifikatsiyasi Content-Length va Transfer-Encoding: chunked ni bir vaqtda ishlatishni taqiqlaydi. Agar server ikkala sarlavhani yuborsa, mijoz Content-Length ni e'tiborsiz qoldirishi va javobni chunked sifatida qayta ishlashi kerak. Transfer-Encoding ning ustunligi Content-Length ustidan RFC 7230 da proxy server javob tanasini o'zgartirganda va original Content-Length ni saqlab qola olmagan holatlar uchun belgilangan. Ba'zi eski HTTP mijozlari bu vaziyatni noto'g'ri qayta ishlaydi, ammo zamonaviy implementatsiyalar spetsifikatsiyaga amal qiladi.
Content-Length qachon mumkin emas
Content-Length ni printsipial jihatdan oldindan hisoblab bo'lmaydigan stsenariylar mavjud. Foydalanuvchi so'rovi asosida filtrlash va agregatsiya bilan yaratiladigan dinamik hisobotlar — server ma'lumotlar bazasi so'rovi tugaguniga qadar ma'lumotlar hajmini bilmaydi. Kameradan real vaqtda uzatiladigan streaming video — hajm cheksiz. Bildirishnomalar uchun SSE va long polling — javob cheksiz davom etishi mumkin. Barcha bu holatlarda Chunked Transfer yagona to'g'ri mexanizmdir.
Chunked transfer asosidagi streaming
Chunked Transfer vebdagi ko'plab streaming texnologiyalarining asosida yotadi. Eng mashhuri Server-Sent Events (SSE) bo'lib, unda server Transfer-Encoding: chunked bilan bitta HTTP ulanishi orqali mijozga hodisalarni yuboradi. SSE maxsus matn formatidan (data: xabar ) foydalanadi, ammo transport darajasi oddiy chunked transferdir. Brauzer hodisalarni server yuborganicha oladi, javobning tugashini kutmaydi.
Audio va video streaming ham Chunked Transfer ga tayanadi. Nginx RTMP va Wowza Streaming Engine kabi media serverlari media ma'lumotlarini HTTP orqali chunk'larda yuboradi. Mijoz tomonidagi pleyer birinchi chunk olinganda ijro etishni boshlaydi, faylning to'liq yuklanishini kutmaydi. Bu ijro etish boshlanishigacha bo'lgan vaqtni (Time to First Frame) o'nlab soniyalardan 1-2 soniyagacha kamaytiradi. YouTube va Netflix o'zlarining HTTP oqimlari uchun aynan shu yondashuvdan foydalanadilar.
Mobil ilovalarni ishlab chiqishda Chunked Transfer butun javobni xotiraga yuklamasdan katta hajmdagi ma'lumotlarni uzatish uchun ishlatiladi. Android da Coil yoki Glide orqali tasvirlarni yuklashda kutubxonalar streaming ma'lumotlarni chunk'larda o'qiydi va tasvirni asta-sekin dekodlaydi. Bu katta tasvirlarni (10+ MB) OutOfMemoryError xatosiz ko'rsatish imkonini beradi. OkHttp response.body?.byteStream() orqali streaming o'qishni qo'llab-quvvatlaydi, u ma'lumotlarni chunk-chunk o'qiyotgan InputStream ni qaytaradi.
gRPC va GraphQL da chunked transfer
gRPC HTTP/2 dan foydalanadi, bunda oqim uzatish protokol darajasida o'rnatilgan va alohida chunked mexanizmini talab qilmaydi. HTTP/1.1 orqali ishlaydigan GraphQL serverlari obunalar (subscriptions) natijalarini streaming uzatish uchun Chunked Transfer dan foydalanishi mumkin. Apollo Server va Hasura GraphQL obunalari uchun chunked javoblarni yuboradi, hodisalarni yuzaga kelganida uzatadi. Mijoz polling zaruratisiz real vaqt yangilanishlarini oladi.
Afzalliklar va cheklovlar
Chunked Transfer veb-ilovalar uchun muhim afzalliklarni taqdim etadi. Ma'lumotlarni zudlik bilan yuborish — server yuborishdan oldin javobni buferlamaydi, birinchi baytgacha kechikishni kamaytiradi. Oqim bilan qayta ishlash — mijoz to'liq yuklanishni kutmasdan ma'lumotlarni kelishi bilan qayta ishlashni boshlashi mumkin. Xotira cheklovlarining yo'qligi — server to'liq javobni xotirada saqlamaydi, bu katta hajmdagi ma'lumotlar uchun juda muhim. Cheksiz oqimlarni uzatish imkoniyati — SSE, jonli video, monitoring.
Biroq Chunked Transfer ning cheklovlari bor. Har bir chunk uchun qo'shimcha yuk hajm + CRLF uchun 6-12 baytni tashkil qiladi, bu juda ko'p kichik chunk'lar (masalan, 100 bayt) uchun javob hajmini 10-15% ga oshirishi mumkin. Aniq hajmni ko'rsata olmaslik — mijoz oldindan bufer ajrata olmaydi yoki taraqqiyot panelini ko'rsata olmaydi. Proksi-serverlar bilan muammolar — ba'zi eski proksi chunked transferni qo'llab-quvvatlamaydi va bunday javoblarni keshlay olmaydi. Yuklashni qayta tiklash qo'llab-quvvatlanmasligi — qisman olingan chunked javoblar uchun Range so'rovi amalga oshirilmaydi.
HTTP Archive, 2025 ma'lumotlariga ko'ra, barcha HTTP javoblarining taxminan 35% Transfer-Encoding: chunked dan foydalanadi. Ular orasida dinamik sahifalar (60%), API javoblari (25%) va media oqimlari (15%) ustunlik qiladi. Statik fayllar deyarli har doim Content-Length dan foydalanadi, chunki ularning hajmi oldindan ma'lum. Chunked javoblarning ulushi HTTP/2 ning tarqalishi bilan asta-sekin kamayadi, chunki HTTP/2 da oqim uzatish qo'shimcha Transfer-Encoding sarlavhasiga ehtiyoj sezmasdan freym darajasida amalga oshiriladi.
Amaliy tavsiyalar
Mobil ilovalarni ishlab chiqishda Chunked Transfer ni katta fayllarni (tasvirlar, video) yuklash va katta ma'lumotlar massivlarini qaytaradigan API so'rovlari uchun ishlating. OkHttp chunked transferni qo'shimcha sozlamalarsiz to'liq qo'llab-quvvatlaydi. Serverga yuklash (upload) uchun Chunked Transfer qo'llanilmaydi — HTTP/1.1 da upload uchun Transfer-Encoding ishlatilmaydi. iOS da URLSession maxsus konfiguratsiyasiz chunked ma'lumotlarni yuborish va qabul qilishni qo'llab-quvvatlaydi. JSON ni oqim bilan tahlil qilish (masalan, Jackson Streaming API yoki Moshi orqali) katta JSON massivlarini chunked oqimi kelishi bilan qayta ishlash imkonini beradi.
Ko'p beriladigan savollar
Server Chunked Transfer ni qanday yoqadi?
Server Chunked Transfer ni avtomatik ravishda yoqadi, bunda javob hajmi noma'lum. Nginx agar Content-Length o'rnatilmagan bo'lsa, Transfer-Encoding: chunked qo'shadi. Spring Boot da StreamingResponseBody va SseEmitter avtomatik ravishda chunked transferdan foydalanadi. Node.js Express da Content-Lengthsiz res.write() va res.end() chaqirilsa, javob chunked bo'ladi.
Content-Length va chunked ni bir vaqtda ishlatish mumkinmi?
Yo'q, HTTP/1.1 spetsifikatsiyasi Content-Length va Transfer-Encoding: chunked ni bir vaqtda ishlatishni taqiqlaydi. Agar server ikkala sarlavhani yuborsa, mijoz Content-Length ni e'tiborsiz qoldirishi va javobni chunked sifatida qayta ishlashi kerak. Bu qoida RFC 7230 da javob tanasini o'zgartirishi mumkin bo'lgan proksi-serverlar bilan moslik uchun belgilangan.
Qaysi chunk hajmi optimal?
Optimal chunk hajmi stsenariyga bog'liq. Oddiy veb-sahifalar uchun — 4-8 KB. Video streaming uchun — 16-64 KB. SSE uchun — kechikishni kamaytirish uchun 1-2 KB minimal chunk'lar. Chunk hajmi transport darajasida fragmentatsiyani minimallashtirish uchun TCP segmenti hajmiga (Ethernet uchun 1460 bayt) karrali bo'lishi kerak.
Chunked Transfer proksi orqali ishlaydimi?
Zamonaviy proksi-serverlar (Nginx, HAProxy, Envoy) Chunked Transfer ni qo'llab-quvvatlaydi. Proksi chunk'larni buferlamasdan uzatishi (streaming) yoki butun javobni buferlab, Content-Length bilan qayta yuborishi mumkin. Eski proksi chunked javobni tugagunicha buferlashi mumkin, bu kechikishni oshiradi. HTTP/2 bu muammoni protokol darajasida hal qiladi.
Chunked Transfer HTTP chunked encoding dan qanday farq qiladi?
Bu bir xil narsa. Chunked Transfer HTTP/1.1 spetsifikatsiyasidagi mexanizmning to'liq nomidir. HTTP chunked encoding xuddi shu narsa, ba'zan kutubxonalar hujjatlarida ishlatiladi. Transfer-Encoding: chunked — bu rejimni yoqadigan sarlavha. Uchala atama ham ma'lumotlarni qismlarga bo'lib uzatishning bir xil mexanizmini tavsiflaydi.
Xulosa
- Chunked Transfer — Content-Length ni oldindan ko'rsatmasdan javob tanasini chunk'larda uzatuvchi HTTP/1.1 mexanizmi.
- Transfer-Encoding: chunked — chunk uzatishni yoqadigan sarlavha; har bir chunk hex hajm, ma'lumotlar va CRLF ni o'z ichiga oladi.
- Nol hajmli yakuniy chunk uzatish tugaganini bildiradi, undan keyin trailer sarlavhalari bo'lishi mumkin.
- Dynamic content streaming — asosiy qo'llanilishi: dinamik sahifalar, SSE, streaming audio/video, uzoq hisobotlar.
- Content-Length va chunked bir-birini istisno qiladi — spetsifikatsiya bu sarlavhalarni bir vaqtda ishlatishni taqiqlaydi.
- Afzalliklari — kechikishni kamaytirish, xotirani tejash, cheksiz oqimlarni uzatish va mijoz tomonda oqim bilan qayta ishlash.
- Cheklovlari — chunk sarlavhalariga qo'shimcha yuk, taraqqiyotni ko'rsata olmaslik, eski proksi-serverlar bilan muammolar.
Biz kalit topshirig'i bilan mobil ilovani ishlab chiqamiz
IT Sectr 2017-yildan beri startaplar va korxonalar uchun iOS va Android ilovalarini yaratadi. Biz sizga maslahat beramiz va eng yaxshi yechimni taklif qilamiz.
Shuningdek o'qing