Chunked Transfer in der Webentwicklung — Was es ist, Format und Prinzip der Übertragung per Chunks
Chunked Transfer ist ein Mechanismus des HTTP-Protokolls, bei dem der Server den Antworttext in einzelnen Fragmenten (Chunks) überträgt, ohne die Gesamtgröße der Daten im Voraus anzugeben. Jeder Chunk enthält seine Größe im hexadezimalen Format und Daten der angegebenen Länge, endend mit einem finalen Chunk der Größe Null. Laut MDN Web Docs, 2025 wird Transfer-Encoding: chunked automatisch vom Server aktiviert, wenn die Antwortgröße im Voraus unbekannt ist — zum Beispiel bei der Generierung von Inhalten im laufenden Betrieb oder bei der Streaming-Datenübertragung.
Wichtigste Punkte
- Chunked Transfer — Übertragung einer HTTP-Antwort in Teilen ohne vorherige Angabe von Content-Length.
- Transfer-Encoding: chunked — der Header, der den Chunk-Übertragungsmodus aktiviert.
- Jeder Chunk enthält seine Größe in Hex, Daten und einen abschließenden CRLF, und das Ende wird durch einen Chunk der Größe Null angezeigt.
- Streaming — die Hauptanwendung von Chunked Transfer für Audio, Video und SSE-Ereignisse.
- Chunked Transfer ist mit dem Content-Length-Header nicht kompatibel — sie werden nicht gleichzeitig verwendet.
Was ist Chunked Transfer?
Chunked Transfer ist ein HTTP-Mechanismus, der in der HTTP/1.1-Spezifikation (RFC 7230, Abschnitt 4.1) definiert ist und es dem Server ermöglicht, den Antworttext in Teilen zu senden, ohne die gesamte Content-Length anzugeben. Anstatt die Antwortgröße vor dem Senden zu berechnen, beginnt der Server sofort mit der Übertragung und sendet Datenfragmente, sobald sie bereit sind. Jedes Fragment wird von einem eigenen Größenheader begleitet, sodass der Client die Antwort aus Teilen zusammensetzen kann.
Der Mechanismus wird durch den Transfer-Encoding: chunked-Header aktiviert. Wenn der Client diesen Header in der Antwort sieht, weiß er, dass der Text in Chunks übertragen wird, und muss die Antwort in einer Schleife lesen: die Chunk-Größe lesen, dann die Daten der angegebenen Größe lesen, dann wiederholen. Der Vorgang endet, wenn ein Chunk der Größe Null gefunden wird. Chunked Transfer ist ein obligatorischer Bestandteil von HTTP/1.1, der von allen modernen Webservern und HTTP-Clients unterstützt wird.
Der Hauptgrund für die Verwendung von Chunked Transfer ist die dynamische Inhaltsgenerierung. Wenn der Server eine Antwort basierend auf einer Datenbankabfrage, einer externen API oder einer langwierigen Berechnung generiert, kann er die Größe des Ergebnisses nicht im Voraus kennen. Anstatt die gesamte Antwort im Speicher zu puffern (was bei großen Datenmengen riskant ist), aktiviert der Server Transfer-Encoding: chunked und sendet Daten, sobald sie verfügbar sind. Dies ist besonders wichtig für Server mit begrenztem Speicher und für Antworten, deren Größe sehr groß sein kann — ab 100 MB und mehr.
Unterschied zwischen HTTP/1.1 Chunked und HTTP/2
In HTTP/2 existiert der Chunked-Transfer-Mechanismus als solcher nicht, da das Protokoll Multiplexing von Streams auf Frame-Ebene verwendet. In HTTP/2 werden Daten beliebiger Größe in DATA-Frames übertragen, und die Größe des Antworttextes muss nicht im Voraus deklariert werden — ein Stream kann jederzeit geschlossen werden. Moderne Server konvertieren automatisch Chunked-Antworten von HTTP/1.1 in eine äquivalente Streaming-Übertragung beim Proxying an einen HTTP/2-Upstream. Chunked Transfer bleibt für HTTP/1.1-Verbindungen relevant.
Wie funktioniert die Übertragung per Chunks
Wenn der Server sich für die Verwendung von Chunked Transfer entscheidet, berechnet er nicht Content-Length, sondern sendet den Transfer-Encoding: chunked-Header. Der Antworttext wird dann als eine Sequenz von Chunks gebildet. Jeder Chunk beginnt mit einer Zeile, die die Chunk-Größe im hexadezimalen Format (ohne das 0x-Präfix) enthält, gefolgt von CRLF ( ). Dann kommen die Chunk-Daten der angegebenen Größe, die mit CRLF enden. Der letzte Chunk hat die Größe 0, nach dem Trailer-Header folgen können.
Die hexadezimale Größe ermöglicht die Übertragung von Chunks beliebiger Größe von 1 Byte bis zu theoretisch unbegrenztem Volumen. In der Praxis wird die Chunk-Größe vom Server gewählt: typische Werte sind 4 KB, 8 KB oder 16 KB. Die optimale Chunk-Größe sollte ein Vielfaches der TCP-Segmentgröße (normalerweise 1460 Bytes für Ethernet) sein, um die Fragmentierung auf der Transportschicht zu minimieren. Nginx verwendet standardmäßig 4 KB Chunks, Apache 8 KB Chunks.
Ein Client, der Transfer-Encoding: chunked erhält, muss die Antwort Chunk für Chunk bis zum abschließenden Null-Chunk lesen. Wenn der Client Chunked Transfer nicht unterstützt, kann der Server diesen Modus nicht verwenden. In der Praxis unterstützen alle modernen HTTP-Clients — Browser, OkHttp, URLSession, curl — Chunked-Antworten vollständig. Streaming-Lesen ermöglicht es dem Client, mit der Datenverarbeitung zu beginnen, bevor die vollständige Antwort empfangen wird, was für die Leistung entscheidend ist.
| Chunk-Element | Format | Beispiel |
|---|---|---|
| Chunk-Größe | HEX + CRLF | 1000 |
| Chunk-Daten | [Größe Bytes] + CRLF | [4096 Bytes Daten] |
| Abschließender Chunk | 0 | 0 |
| Trailer (optional) | Header + CRLF | Expires: Wed, 21 Oct 2025 |
Trailer-Header in Chunked Transfer
Chunked Transfer unterstützt Trailer-Header — zusätzliche HTTP-Header, die nach dem letzten Chunk übertragen werden. Dies ist nützlich für Metadaten, die erst nach Abschluss der Antwortgenerierung bekannt werden: zum Beispiel Content-MD5 oder X-Compression-Ratio. Trailer-Header müssen im Trailer-Header deklariert werden: Trailer: Content-MD5, X-Compression-Ratio. In der Praxis werden Trailer selten verwendet — die meisten Server fügen sie nicht in Antworten ein.
Format einer Chunked-Antwort
Eine Chunked-Antwort hat eine streng definierte Struktur, die der Client korrekt parsen muss. Betrachten wir ein vollständiges Beispiel einer HTTP-Antwort mit Transfer-Encoding: chunked. Nach den Headern und einer leeren Zeile beginnt der Antworttext. Die Textstruktur ist eine Sequenz von: Chunk_Größe Daten Chunk_Größe Daten ... bis 0 . Jede Größe wird in hexadezimaler Notation mit ASCII-Zeichen übertragen.
Beispiel einer Serverantwort mit Chunked Transfer:
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
7
Hello
6
World!
0
In diesem Beispiel überträgt der Server die Zeichenfolge „Hello World!“ in zwei Chunks. Der erste Chunk ist 7 Bytes groß und enthält „Hello “, der zweite ist 6 Bytes groß und enthält „World!“. Der Client sammelt Daten aus beiden Chunks und erhält die vollständige Zeichenfolge. Wichtig: Die Chunk-Größe enthält nur die Daten, nicht die CRLF-Trennzeichen der Chunks selbst. Der abschließende leere Chunk (0 ) benachrichtigt den Client, dass die Übertragung abgeschlossen ist.
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()
}Chunked-Antwort in OkHttp parsen
OkHttp abstrahiert den Entwickler vollständig von den Details des Chunked Transfer. Beim Empfang einer Antwort mit Transfer-Encoding: chunked sammelt OkHttp automatisch die Chunks und stellt dem Entwickler den vollständigen Antworttext über response.body?.string() zur Verfügung. Für die Streaming-Verarbeitung wird response.body?.source() verwendet, das einen BufferedSource zurückgibt und das Lesen von Daten bei ihrem Eintreffen ermöglicht. Der Entwickler muss keine Hex-Größen und CRLF manuell parsen — die Bibliothek erledigt dies automatisch.
Chunked Transfer vs Content-Length
Content-Length und Transfer-Encoding: chunked sind zwei sich gegenseitig ausschließende Methoden zur Angabe der Größe des HTTP-Nachrichtentextes. Content-Length ist ein Header, der die genaue Textgröße in Bytes enthält. Er ist obligatorisch für Antworten, deren Größe im Voraus bekannt ist, und für Anfragen mit Text (POST, PUT). Content-Length ermöglicht es dem Client, einen Puffer der erforderlichen Größe im Voraus zuzuweisen und zu überprüfen, ob alle Daten empfangen wurden.
Chunked Transfer wird verwendet, wenn die Textgröße nicht im Voraus bekannt ist. Dies tritt in drei Hauptszenarien auf: dynamische Inhaltsgenerierung (z. B. eine Datenbankabfrage, deren Ergebnis noch nicht verfügbar ist), Streaming großer Dateien (um zu vermeiden, dass die gesamte Datei im Speicher gepuffert wird) und Server-Sent Events (SSE) für die Echtzeit-Ereignisübertragung. Die Wahl zwischen Content-Length und Chunked liegt in der Verantwortung des Servers. Wenn der Server die Größe vor Beginn der Übertragung kennt, sollte er Content-Length als einfacheren und vorhersagbareren Mechanismus verwenden.
Die HTTP/1.1-Spezifikation verbietet die gleichzeitige Verwendung von Content-Length und Transfer-Encoding: chunked. Wenn der Server beide Header sendet, muss der Client Content-Length ignorieren und die Antwort als Chunked verarbeiten. Die Priorität von Transfer-Encoding gegenüber Content-Length ist in RFC 7230 für Fälle festgelegt, in denen ein Proxyserver den Antworttext ändert und die ursprüngliche Content-Length nicht beibehalten kann. Einige ältere HTTP-Clients behandeln diese Situation falsch, aber moderne Implementierungen folgen der Spezifikation.
Wenn Content-Length unmöglich ist
Es gibt Szenarien, in denen Content-Length grundsätzlich nicht im Voraus berechnet werden kann. Dynamische Berichte, die auf Anfrage mit Filterung und Aggregation generiert werden — der Server kennt das Datenvolumen erst, wenn die Datenbankabfrage abgeschlossen ist. Streaming-Video, das in Echtzeit von einer Kamera übertragen wird — die Größe ist unendlich. SSE und Long Polling für Benachrichtigungen — die Antwort kann unbegrenzt dauern. In all diesen Fällen ist Chunked Transfer der einzig korrekte Mechanismus.
Streaming basierend auf Chunked Transfer
Chunked Transfer liegt vielen Streaming-Technologien im Web zugrunde. Die bekannteste ist Server-Sent Events (SSE), bei der der Server Ereignisse über eine einzige HTTP-Verbindung mit Transfer-Encoding: chunked an den Client sendet. SSE verwendet ein spezielles Textformat (data: Nachricht ), aber die Transportschicht ist gewöhnlicher Chunked Transfer. Der Browser empfängt die Ereignisse, sobald der Server sie sendet, ohne auf den Abschluss der Antwort zu warten.
Audio- und Video-Streaming basiert ebenfalls auf Chunked Transfer. Medienserver wie Nginx RTMP und Wowza Streaming Engine senden Mediendaten in Chunks über HTTP. Der clientseitige Player startet die Wiedergabe, sobald der erste Chunk empfangen wird, ohne auf das vollständige Laden der Datei zu warten. Dies reduziert die Zeit bis zum ersten Frame von zig Sekunden auf 1-2 Sekunden. YouTube und Netflix verwenden genau diesen Ansatz für ihre HTTP-Streams.
In der mobilen Entwicklung wird Chunked Transfer verwendet, um große Datenmengen zu übertragen, ohne die gesamte Antwort in den Speicher zu laden. Beim Laden von Bildern über Coil oder Glide auf Android lesen die Bibliotheken Streaming-Daten Chunk für Chunk und decodieren das Bild schrittweise. Dies ermöglicht die Anzeige großer Bilder (10+ MB) ohne OutOfMemoryError. OkHttp unterstützt Streaming-Lesen über response.body?.byteStream(), das einen InputStream zurückgibt, der Daten Chunk für Chunk liest.
Chunked Transfer in gRPC und GraphQL
gRPC verwendet HTTP/2, bei dem Streaming auf Protokollebene integriert ist und keinen separaten Chunk-Mechanismus erfordert. GraphQL-Server, die über HTTP/1.1 laufen, können Chunked Transfer zum Streaming von Abonnementergebnissen verwenden. Apollo Server und Hasura senden Chunked-Antworten für GraphQL-Abonnements und übertragen Ereignisse, sobald sie auftreten. Der Client erhält Echtzeit-Updates ohne Polling.
Vorteile und Einschränkungen
Chunked Transfer bietet wichtige Vorteile für Webanwendungen. Sofortige Datenübertragung — der Server puffert die Antwort nicht vor dem Senden, wodurch die Latenz bis zum ersten Byte reduziert wird. Streaming-Verarbeitung — der Client kann mit der Datenverarbeitung beginnen, sobald sie eintreffen, ohne auf den vollständigen Download zu warten. Keine Speicherbeschränkungen — der Server speichert die gesamte Antwort nicht im Speicher, was für große Datenmengen entscheidend ist. Fähigkeit zur Übertragung unendlicher Streams — SSE, Live-Video, Überwachung.
Allerdings hat Chunked Transfer Einschränkungen. Overhead für jeden Chunk beträgt 6-12 Bytes für die Größe + CRLF, was bei vielen kleinen Chunks (z. B. jeweils 100 Bytes) die Antwortgröße um 10-15% erhöhen kann. Unmöglichkeit, die genaue Größe anzugeben — der Client kann keinen Puffer im Voraus zuweisen oder eine Fortschrittsanzeige zeigen. Probleme mit Proxyservern — einige ältere Proxys unterstützen Chunked Transfer nicht und können solche Antworten nicht zwischenspeichern. Keine Unterstützung für die Wiederaufnahme von Downloads — für teilweise empfangene Chunked-Antworten können keine Range-Anfragen gestellt werden.
Laut HTTP Archive, 2025 verwenden etwa 35% aller HTTP-Antworten Transfer-Encoding: chunked. Darunter dominieren dynamische Seiten (60%), API-Antworten (25%) und Medienstreams (15%). Statische Dateien verwenden fast immer Content-Length, da ihre Größe im Voraus bekannt ist. Der Anteil der Chunked-Antworten nimmt mit der Verbreitung von HTTP/2 allmählich ab, wo Streaming auf Frame-Ebene ohne einen zusätzlichen Transfer-Encoding-Header implementiert wird.
Praktische Empfehlungen
Verwenden Sie in der mobilen Entwicklung Chunked Transfer zum Herunterladen großer Dateien (Bilder, Videos) und für API-Anfragen, die große Datenarrays zurückgeben. OkHttp unterstützt Chunked Transfer ohne zusätzliche Konfiguration vollständig. Für Uploads zum Server wird Chunked Transfer nicht verwendet — HTTP/1.1 hat kein Transfer-Encoding für Uploads. Auf iOS unterstützt URLSession sowohl das Senden als auch das Empfangen von Chunked-Daten ohne spezielle Konfiguration. Streaming-JSON-Parsing (z. B. über Jackson Streaming API oder Moshi) ermöglicht die Verarbeitung großer JSON-Arrays, sobald sie in einem Chunked-Stream eintreffen.
Häufig gestellte Fragen
Wie aktiviert der Server Chunked Transfer?
Der Server aktiviert Chunked Transfer automatisch, wenn die Antwortgröße unbekannt ist. Nginx fügt Transfer-Encoding: chunked hinzu, wenn Content-Length nicht gesetzt ist. In Spring Boot verwenden StreamingResponseBody und SseEmitter automatisch Chunked Transfer. In Node.js Express wird die Antwort zu Chunked, wenn res.write() und res.end() ohne Content-Length aufgerufen werden.
Können Content-Length und Chunked gleichzeitig verwendet werden?
Nein, die HTTP/1.1-Spezifikation verbietet die gleichzeitige Verwendung von Content-Length und Transfer-Encoding: chunked. Wenn der Server beide Header sendet, muss der Client Content-Length ignorieren und die Antwort als Chunked verarbeiten. Diese Regel wurde in RFC 7230 für die Kompatibilität mit Proxyservern festgelegt, die den Antworttext ändern können.
Was ist die optimale Chunk-Größe?
Die optimale Chunk-Größe hängt vom Szenario ab. Für gewöhnliche Webseiten — 4-8 KB. Für Video-Streaming — 16-64 KB. Für SSE — minimale Chunks von 1-2 KB zur Reduzierung der Latenz. Die Chunk-Größe sollte ein Vielfaches der TCP-Segmentgröße (1460 Bytes für Ethernet) sein, um die Fragmentierung auf der Transportschicht zu minimieren.
Funktioniert Chunked Transfer über Proxys?
Moderne Proxyserver (Nginx, HAProxy, Envoy) unterstützen Chunked Transfer. Der Proxy kann Chunks ohne Pufferung (Streaming) weiterleiten oder die gesamte Antwort puffern und mit Content-Length erneut senden. Ältere Proxys können die Chunked-Antwort bis zum Abschluss puffern, was die Latenz erhöht. HTTP/2 löst dieses Problem auf Protokollebene.
Wie unterscheidet sich Chunked Transfer von HTTP Chunked Encoding?
Es ist dasselbe. Chunked Transfer ist der vollständige Name des Mechanismus aus der HTTP/1.1-Spezifikation. HTTP Chunked Encoding ist dasselbe, wird manchmal in der Dokumentation von Bibliotheken verwendet. Transfer-Encoding: chunked ist der Header, der diesen Modus aktiviert. Alle drei Begriffe beschreiben denselben Mechanismus der Übertragung von Daten in Teilen.
Zusammenfassung
- Chunked Transfer — ein HTTP/1.1-Mechanismus, der den Antworttext in Chunks ohne vorherige Angabe von Content-Length überträgt.
- Transfer-Encoding: chunked — der Header, der die Chunk-Übertragung aktiviert; jeder Chunk enthält eine Hex-Größe, Daten und CRLF.
- Ein abschließender Chunk der Größe Null signalisiert das Ende der Übertragung, nach dem Trailer-Header folgen können.
- Dynamic Content Streaming — der Hauptanwendungsfall: dynamische Seiten, SSE, Streaming-Audio/Video, lange Berichte.
- Content-Length und Chunked schließen sich gegenseitig aus — die Spezifikation verbietet die gleichzeitige Verwendung dieser Header.
- Vorteile — reduzierte Latenz, Speichereinsparung, Fähigkeit zur Übertragung unendlicher Streams und Streaming-Verarbeitung auf der Client-Seite.
- Einschränkungen — Overhead durch Chunk-Header, Unmöglichkeit der Fortschrittsanzeige, Probleme mit älteren Proxyservern.
Wir entwickeln eine mobile Applikation schlüsselfertig
IT Sectr entwickelt seit 2017 iOS- und Android-Apps für Startups und Unternehmen. Wir beraten Sie und schlagen die beste Lösung vor.
Lesen Sie auch