Veb inkişafda Chunked Transfer — bu nədir, format və chunk'larla ötürülmə prinsipi
Chunked Transfer — bu HTTP protokolunun mexanizmidir ki, server cavabın gövdəsini ayrı-ayrı fraqmentlər (chunk'lar) şəklində ötürür, ümumi məlumat ölçüsünü əvvəlcədən göstərmədən. Hər bir chunk öz ölçüsünü onaltılıq formatda və göstərilən uzunluqda məlumatları ehtiva edir və sıfır ölçülü son chunk ilə bitir. MDN Web Docs, 2025-yə görə, Transfer-Encoding: chunked server tərəfindən avtomatik olaraq işə salınır ki, cavabın ölçüsü əvvəlcədən məlum deyil — məsələn, məzmunun yerində yaradılması və ya məlumatların axın ötürülməsində.
Əsas məqamlar
- Chunked Transfer — HTTP cavabının Content-Length göstərmədən hissələrlə ötürülməsi.
- Transfer-Encoding: chunked — chunk rejimini işə salan başlıq.
- Hər bir chunk hex formatında ölçü, məlumatlar və sondakı CRLF ehtiva edir, son isə sıfır ölçülü chunk ilə qeyd olunur.
- Streaming — səs, video və SSE hadisələrinin ötürülməsi üçün chunked transfer-in əsas tətbiqi.
- Chunked Transfer Content-Length başlığı ilə uyğunsuzdur — onlar eyni anda istifadə olunmur.
Chunked Transfer nədir?
Chunked Transfer — HTTP/1.1 spesifikasiyasında (RFC 7230, bölmə 4.1) müəyyən edilmiş mexanizmdir ki, serverə cavabın gövdəsini ümumi Content-Length göstərmədən hissələrlə göndərməyə imkan verir. Cavabın ölçüsünü göndərmədən əvvəl hesablamaq əvizinə server dərhal ötürülməyə başlayır, məlumatları hazır olduqca fraqmentlərlə göndərir. Hər bir fraqment öz ölçü başlığı ilə müşayiət olunur ki, bu da müştəriyə cavabı hissəciklərdən yığmağa imkan verir.
Mexanizm Transfer-Encoding: chunked başlığı ilə işə salınır. Müştəri cavabda bu başlığı gördükdə bilir ki, gövdə chunk'larla ötürüləcək və cavabı dövri olaraq oxumalıdır: chunk ölçüsünü oxu, sonra göstərilən ölçüdə məlumatları oxu, sonra təkrarla. Proses sıfır ölçülü chunk qarşılaşdıqda başa çatır. Chunked Transfer HTTP/1.1-in məcburi hissəsidir və bütün müasir veb serverlər və HTTP müştəriləri tərəfindən dəstəklənir.
Chunked transfer-dən istifadənin əsas səbəbi məzmunun dinamik yaradılmasıdır. Server məlumat bazası sorgusu, xarici API və ya uzunmüddətli hesablama əsasında cavab yaratdıqda, nəticənin ölçüsünü əvvəlcədən bilə bilməz. Bütün cavabı yaddaşda buferləşdirmək əvizə (böyük həcimlər üçün risklidir), server Transfer-Encoding: chunked-i işə salır və məlumatları hazır olduqca göndərir. Bu, xüsusilə məhdud yaddaşlı serverlər və ölçüsü çox böyük ola bilən cavablar üçün vacibdir — 100 MB və daha çox.
HTTP/1.1 chunked ilə HTTP/2 arasındakı fərq
HTTP/2-də chunked transfer mexanizmi ayrıca mövcud deyil, çünki protokol çərçivələr səviyyəsində axınların multipleksasiyasından istifadə edir. HTTP/2-də istənilən ölçüdəki məlumatlar DATA çərçivələrində ötürülür və cavab gövdəsinin ölçüsü əvvəlcədən bildirilməlidir — axın istənilən vaxt bağlana bilər. Müasir serverlər HTTP/1.1 chunked cavablarını HTTP/2 upstream-ə proksi edərkən avtomatik olaraq ekvivalent axın ötürülməsinə çevirir. Chunked Transfer HTTP/1.1 bağlantıları üçün aktual olaraq qalır.
Chunk'larla ötürülmə necə işləyir
Server Chunked Transfer-dən istifadə etməyə qərar verdikdə, Content-Length hesablamır, Transfer-Encoding: chunked başlığını göndərir. Sonra cavabın gövdəsi chunk'lar ardıcıllığı şəklində formalaşdırılır. Hər bir chunk chunk ölçüsünü onaltılıq formatda (0x prefiksi olmadan) ehtiva edən sətrlə başlayır, ardından CRLF ( ) gəlir. Sonra göstərilən ölçüdə chunk məlumatları və CRLF gəlir. Son chunk ölçüsü 0-dır, ondan sonra trailer başlıqları ola bilər.
Onaltılıq ölçü istənilən ölçüdə chunk'ları ötürülməyə imkan verir — 1 baytdan nəzəri olaraq məhdudiyyətsiz həcmə qədər. Təcrübədə chunk ölçüsü server tərəfindən seçilir: tipik dəyərlər 4 KB, 8 KB və ya 16 KB. Optimal chunk ölçüsü TCP seqmentinin ölçüsünə (Ethernet üçün adətən 1460 bayt) bölünən olmalıdır ki, nəqliyyat səviyyəsində fraqmentasiya minimallaşsın. Nginx standart olaraq 4 KB chunk'lardan, Apache isə 8 KB chunk'lardan istifadə edir.
Transfer-Encoding: chunked alan müştəri sonuncu sıfır chunka qədər cavabı chunk-chunk oxumalıdır. Əgər müştəri chunked transfer-i dəstəkləmirsə, server bu rejimdən istifadə edə bilməz. Təcrübədə bütün müasir HTTP müştəriləri — brauzerlər, OkHttp, URLSession, curl — chunked cavabları tam dəstəkləyir. Axın oxuma müştəriyə tam cavabı almamış məlumatları emal etməyə başlamağa imkan verir ki, bu da performans üçün kritik əhəmiyyət daşıyır.
| Chunk elementi | Format | Nümunə |
|---|---|---|
| Chunk ölçüsü | HEX + CRLF | 1000 |
| Chunk məlumatları | [ölçü bayt] + CRLF | [4096 bayt məlumat] |
| Son chunk | 0 | 0 |
| Trailer (isteğə bağlı) | Başlıqlar + CRLF | Expires: Wed, 21 Oct 2025 |
Chunked Transfer-də trailer başlıqları
Chunked Transfer trailer başlıqlarını dəstəkləyir — son chunk'dan sonra ötürülən əlavə HTTP başlıqları. Bu, cavabın yaradılması başa çatdıqdan sonra məlum olan metadatanın ötürülməsi üçün faydalıdır: məsələn, Content-MD5 və ya X-Compression-Ratio. Trailer başlıqları Trailer başlığında bəyan edilməlidir: Content-MD5, X-Compression-Ratio. Təcrübədə trailer nadir istifadə olunur — əksər serverlər onları cavablara daxil etmir.
Chunked cavabın formatı
Chunked cavabı ciddi müəyyən edilmiş struktura malikdir və müştəri onu düzgün təhlil etməlidir. Transfer-Encoding: chunked ilə HTTP cavabının tam nümunəsini nəzərdən keçirək. Başlıqlar və boş sətrdən sonra cavabın gövdəsi başlayır. Gövdənin strukturu ardıcıllıqdır: chunk ölçüsü məlumatlar chunk ölçüsü məlumatlar ... 0 qədər. Hər ölçü ASCII simvolları ilə onaltılıq say sistemində ötürülür.
Chunked Transfer ilə server cavabı nümunəsi:
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
7
Hello
6
World!
0
Bu nümunədə server “Hello World!” sətrini iki chunk ilə ötürür. Birinci chunk 7 bayt ölçüsündə “Hello ”, ikincisi — 6 bayt “World!” ehtiva edir. Müştəri hər iki chunk'dan məlumatları yığır və tam sətri alır. Vacibdir: chunk ölçüsü yalnız məlumatları əhatə edir, chunk'ların öz CRLF ayırıcılarını daxil etmir. Sonuncu boş chunk (0 ) müştəriyə ötürülmənin bitdiyini bildirir.
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-də chunked cavabın təhlili
OkHttp proqramçını Chunked Transfer-in təfərrübatından tamamilə abstraksiya edir. Transfer-Encoding: chunked ilə cavab alındıqda OkHttp avtomatik olaraq chunk'ları yığır və proqramçıya response.body?.string() vasitəsilə tam cavabı təqdim edir. Axın emalı üçün response.body?.source() istifadə olunur ki, o, BufferedSource qaytarır və məlumatları gəldikcə oxumağa imkan verir. Proqramçı əl ilə hex ölçülərini və CRLF-ni təhlil etməlidir — kitabxana bunu avtomatik edir.
Chunked Transfer vs Content-Length
Content-Length və Transfer-Encoding: chunked HTTP mesajının gövdə ölçüsünü göstərməyin iki bir-birini istisna edən üsuludur. Content-Length gövdənin dəqiq ölçüsünü baytlarla ehtiva edən başlıqdır. Ölçüsü əvvəlcədən məlum olan cavablar üçün və gövdəli sorğular (POST, PUT) üçün məcburidir. Content-Length müştəriyə əvvəlcədən lazımi ölçüdə bufer ayırmağa və bütün məlumatların alındığını yoxlamağa imkan verir.
Chunked Transfer gövdənin ölçüsü əvvəlcədən məlum olmadıqda istifadə olunur. Bu, üç əsas ssenaridə baş verir: məzmunun dinamik yaradılması (məsələn, nəticəsi hələ alınmamış verilənlər bazası sorgusu), böyük faylların axın ötürülməsi (bütün faylı yaddaşda buferləşdirməmək üçün) və real vaxt hadisələrinin ötürülməsi üçün Server-Sent Events (SSE). Seçim Content-Length və chunked arasında serverin məsuliyyətidir. Əgər server ölçüsü ötürülməyə başlamazdan əvvəl bilirsə, daha sadə və proqnozlaşdırıla bilən mexanizm kimi Content-Length istifadə etməlidir.
HTTP/1.1 spesifikasiyası Content-Length və Transfer-Encoding: chunked-in eyni vaxtda istifadəsini qadağan edir. Əgər server hər iki başlığı göndərirsə, müştəri Content-Length-i görməməzliyə gəlməli və cavabı chunked kimi emal etməlidir. Transfer-Encoding-in üstünlüyü Content-Length üzərində RFC 7230-da müəyyən edilmişdir ki, proxy server cavabın gövdəsini dəyişdirdikdə və orijinal Content-Length-i saxlaya bilmədikdə tətbiq olunsun. Bəzi köhnə HTTP müştəriləri bu vəziyyəti səhv emal edir, lakin müasir tətbiqlər spesifikasiyaya əməl edir.
Content-Length nə vaxt mümkün deyil
Elə ssenarilər var ki, Content-Length prinsipcə əvvəlcədən hesablana bilməz. İstifadəçi sorğusu əsasında filtrasiya və aqreqasiya ilə yaradılan dinamik hesabatlar — server məlumat bazası sorgusu tamamlanana qədər məlumatın həcmini bilmir. Real vaxtda kameradan ötürülən axın video — ölçü sonsuzdur. Bildirişlər üçün SSE və long polling — cavab qeyri-müəyyən müddət davam edə bilər. Bütün bu hallarda Chunked Transfer yeganə düzgün mexanizmdir.
Chunked transfer əsaslı streaming
Chunked Transfer vebdə bir çox axın texnologiyalarının əsasında dayanır. Ən məşhuru Server-Sent Events (SSE)-dir ki, burada server Transfer-Encoding: chunked ilə bir HTTP bağlantısı vasitəsilə müştəriyə hadisələr göndərir. SSE xüsusi mətn formatından (data: mesaj ) istifadə edir, lakin nəqliyyat təbəqəsi adi chunked transfer-dir. Brauzer hadisələri server göndərdikcə alır, cavabın tamamlanmasını gözləmir.
Audio və video axını da Chunked Transfer-ə əsaslanır. Nginx RTMP və Wowza Streaming Engine kimi media serverləri media məlumatlarını HTTP vasitəsilə chunk'larla göndərir. Müştəri tərəfindəki pleyer ilk chunk alındıqda oxutmağa başlayır, faylın tam yüklənməsini gözləmir. Bu, oxutmanın başlanmasına qədər olan vaxtı (Time to First Frame) onlarla saniyədən 1-2 saniyəyə qədər azaldır. YouTube və Netflix HTTP axınları üçün məhz bu yanaşmadan istifadə edir.
Mobil tətbiqlərin hazırlanmasında Chunked Transfer bütün cavabı yaddaşa yükləmədən böyük həcmdə məlumatların ötürülməsi üçün istifadə olunur. Android-də Coil və ya Glide vasitəsilə şəkillərin yüklənməsi zamanı kitabxanalar axın məlumatlarını chunk'larla oxuyur və təsviri tədricən kodlayır. Bu, böyük şəkilləri (10+ MB) OutOfMemoryError olmadan göstərməyə imkan verir. OkHttp response.body?.byteStream() vasitəsilə axın oxumağı dəstəkləyir ki, o, məlumatları chunk-chunk oxuyan InputStream qaytarır.
gRPC və GraphQL-də chunked transfer
gRPC HTTP/2 istifadə edir ki, burada axın ötürülməsi protokol səviyyəsində qurulub və ayrıca chunked mexanizmi tələb etmir. HTTP/1.1 vasitəsilə işləyən GraphQL serverləri abunə nəticələrinin (subscriptions) axın ötürülməsi üçün Chunked Transfer-dən istifadə edə bilər. Apollo Server və Hasura GraphQL abunələri üçün chunked cavablar göndərir, hadisələri baş verdikcə ötürür. Müştəri polling ehtiyacı olmadan real vaxt yeniləmələri alır.
Üstünlüklər və məhdudiyyətlər
Chunked Transfer veb tətbiqləri üçün əhəmiyyətli üstünlüklər təmin edir. Məlumatların dərhal göndərilməsi — server göndərmədən əvvəl cavabı buferləşdirmir, ilk bayta qədər gecikməni azaldır. Axın emalı — müştəri tam yüklənməni gözləmədən məlumatları gəldikcə emal etməyə başlaya bilər. Yaddaş məhdudiyyətlərinin olmaması — server tam cavabı yaddaşda saxlamır, bu böyük həcmli məlumatlar üçün kritikdir. Sonsuz axınların ötürülməsi imkanı — SSE, canlı video, monitorinq.
Lakin Chunked Transfer-in məhdudiyyətləri var. Hər chunk üçün əlavə yük ölçü + CRLF üçün 6-12 bayt təşkil edir ki, çox sayda kiçik chunk'lar (məsələn, 100 bayt) üçün cavabın ölçüsünü 10-15% artıra bilər. Dəqiq ölçünü göstərə bilməmək — müştəri əvvəlcədən bufer ayıra və ya gedişat paneli göstərə bilməz. Proxy serverlərlə problemlər — bəzi köhnə proxy-lər chunked transfer-i dəstəkləmir və belə cavabları keşləyə bilmir. Yükləmənin bərpasının dəstəklənməməsi — qismən alınmış chunked cavablar üçün Range sorğusu etmək mümkün deyil.
HTTP Archive, 2025-ə görə, bütün HTTP cavablarının təxminən 35% Transfer-Encoding: chunked istifadə edir. Onların arasında dinamik səhifələr (60%), API cavabları (25%) və media axınları (15%) üstünlük təşkil edir. Statik fayllar demək olar ki, həmişə Content-Length istifadə edir, çünki onların ölçüsü əvvəlcədən məlumdur. Chunked cavabların payı HTTP/2-nin yayılması ilə tədricən azalır, çünki HTTP/2-də axın ötürülməsi əlavə Transfer-Encoding başlığına ehtiyac olmadan çərçivə səviyyəsində tətbiq olunur.
Praktik tövsiyələr
Mobil tətbiqlərin hazırlanmasında Chunked Transfer-i böyük faylların (şəkillər, video) yüklənməsi və böyük məlumat massivləri qaytaran API sorğuları üçün istifadə edin. OkHttp əlavə konfiqurasiya olmadan chunked transfer-i tam dəstəkləyir. Serverə yükləmə (upload) üçün Chunked Transfer tətbiq edilmir — HTTP/1.1-də upload üçün Transfer-Encoding istifadə olunmur. iOS-da URLSession xüsusi konfiqurasiya olmadan həm chunked məlumatların göndərilməsini, həm də qəbulunu dəstəkləyir. JSON-un axın təhlili (məsələn, Jackson Streaming API və ya Moshi vasitəsilə) böyük JSON massivlərini chunked axını gəldikcə emal etməyə imkan verir.
Tez-tez verilən suallar
Server Chunked Transfer-i necə işə salır?
Server Chunked Transfer-i avtomatik olaraq işə salır ki, cavabın ölçüsü məlum deyil. Nginx əgər Content-Length təyin edilməyibsə, Transfer-Encoding: chunked əlavə edir. Spring Boot-da StreamingResponseBody və SseEmitter avtomatik olaraq chunked transfer istifadə edir. Node.js Express-də Content-Length olmadan res.write() və res.end() çağırılarsa, cavab chunked olur.
Content-Length və chunked eyni anda istifadə oluna bilərmi?
Xeyr, HTTP/1.1 spesifikasiyası Content-Length və Transfer-Encoding: chunked-in eyni vaxtda istifadəsini qadağan edir. Əgər server hər iki başlığı göndərirsə, müştəri Content-Length-i görməməzliyə gəlməli və cavabı chunked kimi emal etməlidir. Bu qayda RFC 7230-da müəyyən edilmişdir ki, cavabın gövdəsini dəyişdirə bilən proxy serverlərlə uyğunluq təmin olunsun.
Hansı chunk ölçüsü optimaldır?
Optimal chunk ölçüsü ssenaridən asılıdır. Adi veb səhifələr üçün — 4-8 KB. Video axını üçün — 16-64 KB. SSE üçün — gecikməni azaltmaq üçün 1-2 KB minimum chunk'lar. Chunk ölçüsü nəqliyyat səviyyəsində fraqmentasiyanı minimallaşdırmaq üçün TCP seqmentinin ölçüsünə (Ethernet üçün 1460 bayt) bölünən olmalıdır.
Chunked Transfer proxy vasitəsilə işləyirmi?
Müasir proxy serverlər (Nginx, HAProxy, Envoy) Chunked Transfer-i dəstəkləyir. Proxy chunk'ları buferləşdirmədən ötürə (streaming) və ya bütün cavabı buferləşdirib Content-Length ilə yenidən göndərə bilər. Köhnə proxy-lər chunked cavabı tamamlanana qədər buferləşdirə bilər ki, bu da gecikməni artırır. HTTP/2 bu problemi protokol səviyyəsində həll edir.
Chunked Transfer HTTP chunked encoding-dən nə ilə fərqlənir?
Bu eyni şeydir. Chunked Transfer HTTP/1.1 spesifikasiyasındakı mexanizmin tam adıdır. HTTP chunked encoding eyni şeydir, bəzən kitabxanaların sənədlərində istifadə olunur. Transfer-Encoding: chunked — bu rejimi işə salan başlıqdır. Hər üç termin məlumatların hissələrlə ötürülməsinin eyni mexanizmini təsvir edir.
Nəticələr
- Chunked Transfer — Content-Length əvvəlcədən göstərmədən cavabın gövdəsini chunk'larla ötürən HTTP/1.1 mexanizmi.
- Transfer-Encoding: chunked — chunk ötürülməsini işə salan başlıq; hər chunk hex ölçüsü, məlumatlar və CRLF ehtiva edir.
- Sıfır ölçülü son chunk ötürülmənin sonunu bildirir, ondan sonra trailer başlıqları ola bilər.
- Dynamic content streaming — əsas tətbiq: dinamik səhifələr, SSE, axın audio/video, uzun hesabatlar.
- Content-Length və chunked bir-birini istisna edir — spesifikasiya bu başlıqların eyni vaxtda istifadəsini qadağan edir.
- Üstünlüklər — gecikmənin azaldılması, yaddaşa qənaət, sonsuz axınların ötürülməsi və müştəri tərəfində axın emalı.
- Məhdudiyyətlər — chunk başlıqlarına əlavə yük, gedişatı göstərə bilməmək, köhnə proxy serverlərlə problemlər.
Açar təslim mobil tətbiq hazırlayacağıq
IT Sectr 2017-ci ildən startaplar və bizneslər üçün iOS və Android tətbiqləri yaradır. Sizə məsləhət verəcəyik və ən yaxşı həlli təklif edəcəyik.
Həm də oxuyun