Web geliştirmede Chunked Transfer — nedir, formatı ve parçalı aktarım prensibi
Chunked Transfer, sunucunun yanıt gövdesini toplam veri boyutunu önceden belirtmeden ayrı parçalar (chunks) halinde ilettiği bir HTTP protokolü mekanizmasıdır. Her parça, onaltılık formatta kendi boyutunu ve belirtilen uzunluktaki verileri içerir ve sıfır boyutlu son bir parça ile biter. MDN Web Docs, 2025'e göre, Transfer-Encoding: chunked, yanıt boyutu önceden bilinmediğinde sunucu tarafından otomatik olarak etkinleştirilir — örneğin, anlık içerik oluşturma veya veri akışı aktarımı sırasında.
Ana Noktalar
- Chunked Transfer — Content-Length önceden belirtilmeden HTTP yanıtının parçalar halinde iletilmesi.
- Transfer-Encoding: chunked — parçalı veri aktarım modunu etkinleştiren başlık.
- Her parça onaltılık boyut, veri ve sonunda CRLF içerir ve sıfır boyutlu bir parça ile son belirtilir.
- Streaming — ses, video ve SSE olaylarının iletilmesi için chunked transfer'in ana kullanımı.
- Chunked Transfer, Content-Length başlığı ile uyumsuzdur — aynı anda kullanılmazlar.
Chunked Transfer Nedir?
Chunked Transfer, HTTP/1.1 spesifikasyonunda (RFC 7230, bölüm 4.1) tanımlanan ve sunucunun toplam Content-Length belirtmeden yanıt gövdesini parçalar halinde göndermesine izin veren bir HTTP mekanizmasıdır. Sunucu, göndermeden önce yanıt boyutunu hesaplamak yerine, veri parçaları hazır oldukça hemen iletmeye başlar. Her parçaya kendi boyut başlığı eşlik eder ve istemcinin yanıtı parçalardan birleştirmesine olanak tanır.
Mekanizma Transfer-Encoding: chunked başlığı ile etkinleştirilir. İstemci yanıtta bu başlığı gördüğünde, gövdenin parçalar halinde iletileceğini bilir ve yanıtı bir döngüde okumalıdır: parça boyutunu oku, ardından belirtilen boyuttaki verileri oku, ardından tekrarla. Süreç, sıfır boyutlu bir parçayla karşılaşıldığında sona erer. Chunked Transfer, HTTP/1.1'in zorunlu bir parçasıdır ve tüm modern web sunucuları ve HTTP istemcileri tarafından desteklenir.
Chunked transfer kullanmanın ana nedeni dinamik içerik oluşturmadır. Sunucu, bir veritabanı sorgusu, harici API veya uzun hesaplama temelinde yanıt oluşturduğunda, sonucun boyutunu önceden bilemez. Yanıtın tamamını bellekte arabelleğe almak yerine (büyük hacimler için risklidir), sunucu Transfer-Encoding: chunked'i etkinleştirir ve veriler kullanılabilir oldukça gönderir. Bu, sınırlı belleğe sahip sunucular ve boyutu çok büyük olabilecek yanıtlar için (100 MB ve üzeri) özellikle önemlidir.
HTTP/1.1 Parçalı ve HTTP/2 Arasındaki Fark
HTTP/2'de, protokol çerçeve düzeyinde akış çoğullama kullandığından, parçalı aktarım mekanizması olarak mevcut değildir. HTTP/2'de herhangi bir boyuttaki veri DATA çerçevelerinde iletilir ve yanıt gövdesinin boyutunun önceden bildirilmesi gerekmez — bir akış herhangi bir anda kapatılabilir. Modern sunucular, bir HTTP/2 yukarı akışına proxy yaparken HTTP/1.1 parçalı yanıtları otomatik olarak eşdeğer akışlı iletimine dönüştürür. Chunked Transfer, HTTP/1.1 bağlantıları için geçerliliğini korur.
Parçalı Aktarım Nasıl Çalışır
Sunucu Chunked Transfer kullanmaya karar verdiğinde, Content-Length hesaplamaz, bunun yerine Transfer-Encoding: chunked başlığını gönderir. Yanıt gövdesi daha sonra bir parça dizisi olarak oluşturulur. Her parça, onaltılık formatta (0x ön eki olmadan) parça boyutunu içeren bir satırla başlar ve ardından CRLF ( ) gelir. Ardından belirtilen boyuttaki parça verileri gelir ve CRLF ile biter. Son parçanın boyutu 0'dır ve ardından trailer başlıkları gelebilir.
Onaltılık boyut, 1 bayttan teorik olarak sınırsız hacme kadar her boyuttaki parçanın iletilmesine olanak tanır. Pratikte parça boyutu sunucu tarafından seçilir: tipik değerler 4 KB, 8 KB veya 16 KB'dir. Optimum parça boyutu, taşıma katmanında parçalanmayı en aza indirmek için TCP segment boyutunun (Ethernet için genellikle 1460 bayt) katı olmalıdır. Nginx varsayılan olarak 4 KB, Apache ise 8 KB parça kullanır.
Transfer-Encoding: chunked alan bir istemci, yanıtı sonlandırıcı sıfır parçaya kadar parça parça okumalıdır. İstemci parçalı aktarımı desteklemiyorsa, sunucu bu modu kullanamaz. Pratikte tüm modern HTTP istemcileri — tarayıcılar, OkHttp, URLSession, curl — parçalı yanıtları tam olarak destekler. Akışlı okuma, istemcinin tam yanıtı almadan önce veri işlemeye başlamasına olanak tanır ve bu, performans için kritiktir.
| Parça Öğesi | Format | Örnek |
|---|---|---|
| Parça Boyutu | HEX + CRLF | 1000 |
| Parça Verisi | [boyut bayt] + CRLF | [4096 bayt veri] |
| Sonlandırıcı Parça | 0 | 0 |
| Trailer (isteğe bağlı) | Başlıklar + CRLF | Expires: Wed, 21 Oct 2025 |
Chunked Transfer'de Trailer Başlıkları
Chunked Transfer, trailer başlıklarını destekler — son parçadan sonra iletilen ek HTTP başlıkları. Bu, yanıt oluşturma tamamlandıktan sonra bilinen meta veriler için kullanışlıdır: örneğin, Content-MD5 veya X-Compression-Ratio. Trailer başlıkları, Trailer başlığında bildirilmelidir: Trailer: Content-MD5, X-Compression-Ratio. Pratikte trailer'lar nadiren kullanılır — çoğu sunucu bunları yanıtlara dahil etmez.
Chunked Yanıt Formatı
Parçalı bir yanıt, istemcinin doğru şekilde ayrıştırması gereken kesin olarak tanımlanmış bir yapıya sahiptir. Transfer-Encoding: chunked ile bir HTTP yanıtının tam bir örneğini ele alalım. Başlıklar ve boş bir satırdan sonra yanıt gövdesi başlar. Gövde yapısı şu dizidir: parça_boyutu veri parça_boyutu veri ... 0 'ye kadar. Her boyut, ASCII karakterleri kullanılarak onaltılık gösterimde iletilir.
Chunked Transfer ile sunucu yanıtı örneği:
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
7
Hello
6
World!
0
Bu örnekte sunucu, “Hello World!” dizgisini iki parçada iletir. İlk parça 7 bayttır ve “Hello ” içerir, ikincisi 6 bayttır ve “World!” içerir. İstemci her iki parçadan veri toplar ve tam dizgiyi alır. Önemli: parça boyutu yalnızca verileri içerir, parçaların kendisinin CRLF ayırıcılarını içermez. Sonlandırıcı boş parça (0 ), istemciye iletimin tamamlandığını 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("Parça: $line")
}
reader.close()
}OkHttp'de Parçalı Yanıtı Ayrıştırma
OkHttp, geliştiriciyi Chunked Transfer'in detaylarından tamamen soyutlar. Transfer-Encoding: chunked ile bir yanıt alındığında, OkHttp otomatik olarak parçaları toplar ve geliştiriciye response.body?.string() aracılığıyla tam yanıt gövdesini sağlar. Akışlı işleme için, response.body?.source() kullanılır, bu bir BufferedSource döndürür ve veriler geldikçe okumaya olanak tanır. Geliştiricinin onaltılık boyutları ve CRLF'yi manuel olarak ayrıştırması gerekmez — kütüphane bunu otomatik olarak yapar.
Chunked Transfer vs Content-Length
Content-Length ve Transfer-Encoding: chunked, bir HTTP mesajının gövde boyutunu belirtmenin birbirini dışlayan iki yoludur. Content-Length, gövdenin bayt cinsinden tam boyutunu içeren bir başlıktır. Boyutu önceden bilinen yanıtlar ve gövdeli istekler (POST, PUT) için zorunludur. Content-Length, istemcinin gerekli boyutta bir arabelleği önceden ayırmasına ve tüm verilerin alındığını doğrulamasına olanak tanır.
Chunked Transfer, gövde boyutu önceden bilinmediğinde kullanılır. Bu, üç ana senaryoda gerçekleşir: dinamik içerik oluşturma (örneğin, sonucu henüz mevcut olmayan bir veritabanı sorgusu), büyük dosyaların akışlı iletimi (dosyanın tamamını bellekte arabelleğe almamak için) ve gerçek zamanlı olay iletimi için Server-Sent Events (SSE). Seçim Content-Length ve parçalı arasında sunucunun sorumluluğundadır. Sunucu, iletim başlamadan önce boyutu biliyorsa, daha basit ve öngörülebilir bir mekanizma olarak Content-Length kullanmalıdır.
HTTP/1.1 spesifikasyonu, Content-Length ve Transfer-Encoding: chunked'in eşzamanlı kullanımını yasaklar. Sunucu her iki başlığı da gönderirse, istemci Content-Length'u yok saymalı ve yanıtı parçalı olarak işlemelidir. Öncelik, RFC 7230'da, bir proxy sunucusunun yanıt gövdesini değiştirdiği ve orijinal Content-Length'u koruyamadığı durumlar için belirlenmiştir. Bazı eski HTTP istemcileri bu durumu yanlış işler, ancak modern uygulamalar spesifikasyonu takip eder.
Content-Length'un Mümkün Olmadığı Durumlar
Content-Length'un temelde önceden hesaplanamadığı senaryolar vardır. Dinamik raporlar filtreleme ve toplama ile talep üzerine oluşturulur — sunucu, veritabanı sorgusu tamamlanana kadar veri hacmini bilemez. Gerçek zamanlı olarak kameradan iletilen akışlı video — boyut sonsuzdur. Bildirimler için SSE ve long polling — yanıt süresiz olarak devam edebilir. Tüm bu durumlarda, Chunked Transfer tek doğru mekanizmadır.
Chunked Transfer Tabanlı Streaming
Chunked Transfer, web'deki birçok akış teknolojisinin temelini oluşturur. En bilineni Server-Sent Events (SSE)'dir, sunucunun Transfer-Encoding: chunked ile tek bir HTTP bağlantısı üzerinden istemciye olaylar gönderdiği yapıdır. SSE özel bir metin formatı (data: mesaj ) kullanır, ancak taşıma katmanı sıradan parçalı aktarımdır. Tarayıcı, sunucu gönderdikçe olayları alır, yanıtın tamamlanmasını beklemez.
Ses ve video akışı da Chunked Transfer'a dayanır. Nginx RTMP ve Wowza Streaming Engine gibi medya sunucuları, HTTP üzerinden medya verilerini parçalar halinde gönderir. İstemci tarafı oynatıcı, ilk parça alınır alınmaz oynatmaya başlar, dosyanın tamamen yüklenmesini beklemez. Bu, ilk kareye kadar geçen süreyi onlarca saniyeden 1-2 saniyeye düşürür. YouTube ve Netflix, HTTP akışları için tam olarak bu yaklaşımı kullanır.
Mobil geliştirmede, Chunked Transfer, yanıtın tamamını belleğe yüklemeden büyük hacimli verileri aktarmak için kullanılır. Android'de Coil veya Glide aracılığıyla resim yüklenirken, kütüphaneler akış verilerini parça parça okur ve resmi kademeli olarak çözer. Bu, OutOfMemoryError olmadan büyük resimlerin (10+ MB) görüntülenmesine olanak tanır. OkHttp, response.body?.byteStream() aracılığıyla akışlı okumayı destekler ve verileri parça parça okuyan bir InputStream döndürür.
gRPC ve GraphQL'de Chunked Transfer
gRPC, akışın protokol düzeyinde yerleşik olduğu HTTP/2'yi kullanır ve ayrı bir parçalı mekanizma gerektirmez. HTTP/1.1 üzerinde çalışan GraphQL sunucuları, abonelik sonuçlarını akışlamak için Chunked Transfer kullanabilir. Apollo Server ve Hasura, GraphQL abonelikleri için parçalı yanıtlar gönderir ve olaylar gerçekleştikçe iletir. İstemci, yoklama gerektirmeden gerçek zamanlı güncellemeler alır.
Avantajlar ve Sınırlamalar
Chunked Transfer, web uygulamaları için önemli avantajlar sağlar. Anında veri gönderme — sunucu, göndermeden önce yanıtı arabelleğe almaz ve ilk bayta kadar olan gecikmeyi azaltır. Akışlı işleme — istemci, tam indirmeyi beklemeden veriler geldikçe işlemeye başlayabilir. Bellek sınırlaması yok — sunucu, yanıtın tamamını bellekte saklamaz, bu büyük veri hacimleri için kritiktir. Sonsuz akışları iletme yeteneği — SSE, canlı video, izleme.
Ancak Chunked Transfer'ın sınırlamaları vardır. Ek yük her parça için boyut + CRLF'nin 6-12 baytıdır ve çok sayıda küçük parça (örneğin, her biri 100 bayt) için yanıt boyutunu %10-15 artırabilir. Kesin boyutu belirtememe — istemci önceden bir arabellek ayıramaz veya ilerleme çubuğu gösteremez. Proxy sunucularıyla sorunlar — bazı eski proxy'ler parçalı aktarımı desteklemez ve bu tür yanıtları önbelleğe alamaz. İndirme sürdürme desteği yok — kısmen alınan parçalı yanıtlar için Range istekleri yapılamaz.
HTTP Archive, 2025'e göre, tüm HTTP yanıtlarının yaklaşık %35'i Transfer-Encoding: chunked kullanır. Bunlar arasında dinamik sayfalar (%60), API yanıtları (%25) ve medya akışları (%15) baskındır. Statik dosyalar, boyutları önceden bilindiği için neredeyse her zaman Content-Length kullanır. Parçalı yanıtların payı, akışın ek bir Transfer-Encoding başlığı gerektirmeden çerçeve düzeyinde uygulandığı HTTP/2'nin benimsenmesiyle kademeli olarak azalmaktadır.
Pratik Öneriler
Mobil geliştirmede, büyük dosyaları (resim, video) indirmek ve büyük veri dizileri döndüren API istekleri için Chunked Transfer kullanın. OkHttp, ek yapılandırma gerektirmeden parçalı aktarımı tam olarak destekler. Sunucuya yükleme için Chunked Transfer kullanılmaz — HTTP/1.1'de yüklemeler için Transfer-Encoding yoktur. iOS'ta URLSession, özel yapılandırma gerektirmeden hem parçalı veri göndermeyi hem de almayı destekler. Akışlı JSON ayrıştırma (Jackson Streaming API veya Moshi aracılığıyla), parçalı bir akışta büyük JSON dizilerinin geldikçe işlenmesine olanak tanır.
Sıkça Sorulan Sorular
Sunucu Chunked Transfer'i nasıl etkinleştirir?
Sunucu, yanıt boyutu bilinmediğinde Chunked Transfer'i otomatik olarak etkinleştirir. Nginx, Content-Length ayarlanmamışsa Transfer-Encoding: chunked ekler. Spring Boot'ta, StreamingResponseBody ve SseEmitter otomatik olarak parçalı aktarım kullanır. Node.js Express'te, Content-Length olmadan res.write() ve res.end() çağrılırsa yanıt parçalı hale gelir.
Content-Length ve chunked aynı anda kullanılabilir mi?
Hayır, HTTP/1.1 spesifikasyonu Content-Length ve Transfer-Encoding: chunked'in eşzamanlı kullanımını yasaklar. Sunucu her iki başlığı da gönderirse, istemci Content-Length'u yok saymalı ve yanıtı parçalı olarak işlemelidir. Bu kural, yanıt gövdesini değiştirebilecek proxy sunucularıyla uyumluluk için RFC 7230'da belirlenmiştir.
Optimum parça boyutu nedir?
Optimum parça boyutu senaryoya bağlıdır. Sıradan web sayfaları için — 4-8 KB. Video akışı için — 16-64 KB. SSE için — gecikmeyi azaltmak için 1-2 KB minimum parçalar. Parça boyutu, taşıma katmanında parçalanmayı en aza indirmek için TCP segment boyutunun (Ethernet için 1460 bayt) katı olmalıdır.
Chunked Transfer proxy üzerinden çalışır mı?
Modern proxy sunucuları (Nginx, HAProxy, Envoy) Chunked Transfer'i destekler. Proxy, parçaları arabelleğe almadan (akışlı) iletebilir veya yanıtın tamamını arabelleğe alıp Content-Length ile yeniden gönderebilir. Eski proxy'ler, parçalı yanıtı tamamlanana kadar arabelleğe alabilir ve gecikmeyi artırabilir. HTTP/2 bu sorunu protokol düzeyinde çözer.
Chunked Transfer, HTTP chunked encoding'den nasıl farklıdır?
Aynı şeydir. Chunked Transfer, HTTP/1.1 spesifikasyonundaki mekanizmanın tam adıdır. HTTP chunked encoding aynıdır, bazen kütüphane dokümantasyonunda kullanılır. Transfer-Encoding: chunked, bu modu etkinleştiren başlıktır. Üç terim de verileri parçalar halinde iletmenin aynı mekanizmasını tanımlar.
Özet
- Chunked Transfer — Content-Length önceden belirtilmeden yanıt gövdesini parçalar halinde ileten bir HTTP/1.1 mekanizması.
- Transfer-Encoding: chunked — parçalı aktarımı etkinleştiren başlık; her parça onaltılık boyut, veri ve CRLF içerir.
- Sıfır boyutlu sonlandırıcı parça iletimin sonunu belirtir, ardından trailer başlıkları gelebilir.
- Dinamik içerik akışı — ana kullanım durumu: dinamik sayfalar, SSE, akışlı ses/video, uzun raporlar.
- Content-Length ve parçalı birbirini dışlar — spesifikasyon bu başlıkların eşzamanlı kullanımını yasaklar.
- Avantajlar — azaltılmış gecikme, bellek tasarrufu, sonsuz akışları iletme yeteneği ve istemci tarafında akışlı işleme.
- Sınırlamalar — parça başlıklarından kaynaklanan ek yük, ilerleme gösterememe, eski proxy sunucularıyla sorunlar.
Anahtar teslim bir mobil uygulama geliştireceğiz
IT Sectr, 2017'den beri girişimler ve işletmeler için iOS ve Android uygulamaları oluşturmaktadır. Size danışmanlık yapacak ve en iyi çözümü önereceğiz.
Ayrıca okuyun