Chunk-basierte Upload-Architektur: Design-Guide

Eine Chunk-basierte Upload-Architektur teilt eine Datei in Stücke fester oder variabler Größe und sendet diese unabhängig voneinander – damit ein Netzwerkausfall bei einem 10-GB-Upload keinen Neustart von null erzwingt. Das BSI beschreibt in seiner Technischen Richtlinie TR-03116 zur Cloud-Nutzung explizit, dass Uploads von Dateien über 100 MB durch fortsetzbare Verfahren abgesichert werden sollten. Die zwei dominanten offenen Standards sind AWS S3 Multipart Upload (mindestens 5 MB pro Teil, maximal 10.000 Teile) und das tus.io-Protokoll für fortsetzbare Uploads (weit verbreitet implementiert). Richtig umgesetzt liefern Chunk-Uploads einen 5- bis 10-fachen Durchsatz auf Hochlatenz-Strecken, tolerieren kurze Verbindungsabbrüche und ermöglichen parallele Entschlüsselung auf der Empfängerseite.

Warum monolithische Uploads im großen Maßstab scheitern

Ein einzelner HTTP-PUT einer 5-GB-Datei trifft auf ein halbes Dutzend Fehlerszenarien. TCP-Überlastungsfenster brauchen lange, um sich zu öffnen, was den Durchsatz auf Hochlatenzpfaden weit unter die Leitungskapazität drückt. Browser begrenzen gleichzeitige Verbindungen pro Herkunft auf 6 und lassen den Großteil der Bandbreite ungenutzt. Server-seitige Anfrage-Timeouts (nginx-Standard 60 Sekunden, CloudFront 30 Sekunden für Nicht-Streaming) töten lange Uploads. Mobilfunknetze, die zwischen Zellmasten wechseln, unterbrechen die Verbindung alle paar Minuten. Und ein einzelner Bitfehler erzwingt einen vollständigen Transfer-Neustart. Chunk-Uploads lösen all diese Probleme, indem sie die Arbeitseinheit klein, unabhängig wiederholbar und parallel-freundlich machen.

Chunk-Größe wählen

Chunk-Größe ist ein Kompromiss. Kleinere Chunks erholen sich schneller von Fehlern und bieten feinere Fortschrittsanzeigen, fügen aber mehr HTTP-Overhead hinzu. Größere Chunks amortisieren Handshake- und TLS-Kosten, verschwenden aber Bandbreite, wenn ein Chunk fehlschlägt und neu übertragen werden muss. Typische Bereiche: 1 bis 5 MB für mobile Uploads mit verlustbehafteten Netzwerken, 5 bis 16 MB für Desktop-Web-Uploads, 16 bis 64 MB für Server-zu-Server-Übertragungen auf zuverlässigen Leitungen, und 100 MB oder mehr für S3 Multipart, wo die 10.000-Teil-Grenze größere Chunks bei 1-TB-Dateien erzwingt. Manche Systeme passen dynamisch an – starten klein und skalieren hoch, wenn die Verbindung sich als zuverlässig erweist.

Feste Größe vs. inhaltsbasiertes Chunking

Festes Chunking (beispielsweise alle 8 MB) ist trivial zu implementieren, parallel-freundlich und unterstützt genaue Resume-Offsets. Inhaltsbasiertes Chunking (Content-Defined Chunking), wie in rsync und restic verwendet, wählt Grenzen basierend auf einem Rolling-Hash wie Rabin-Fingerprinting, so dass Einfügungen in der Mitte einer Datei nicht alle nachfolgenden Chunk-Grenzen verschieben. CDC ist hervorragend für Deduplizierung in Backup-Tools, fügt aber Komplexität und CPU-Kosten hinzu, die für reine Dateiübertragung nicht belohnt werden. Für Upload-Architekturen gewinnt festes Chunking durch Einfachheit und lässt sich sauber auf S3-Multipart-Teile oder tus.io-Offsets abbilden.

Fortsetzbare Upload-Protokolle

Das tus.io-Protokoll, implementiert in tusd (Go), tus-js-client, Uppy und vielen Server-Frameworks, verwendet HTTP PATCH mit einem Upload-Offset-Header zum Anhängen von Chunks. Eine HEAD-Anfrage gibt den aktuellen Offset auf dem Server zurück, sodass der Client weiß, wo nach einer Netzwerkunterbrechung weitergemacht werden soll. S3 Multipart Upload verwendet ein anderes Modell: Initiierung des Uploads zum Abrufen einer UploadId, Upload jedes Teils (1-indiziert), dann Senden einer CompleteMultipartUpload-Anfrage mit der Liste der ETags. Clients können ListParts abfragen, um zu sehen, was hochgeladen wurde. Beide Protokolle erhalten den Zustand über Client-Neustarts hinweg und überstehen Verbindungsabbrüche problemlos.

Parallele Upload-Gleichzeitigkeit

Chunks parallel hochzuladen steigert den Durchsatz auf Hochlatenzleitungen dramatisch. HTTP/1.1 begrenzt auf 6 gleichzeitige Verbindungen pro Herkunft in Browsern; HTTP/2 multiplext viele Streams über eine einzelne Verbindung, unterliegt aber dennoch Flusssteuerungsfenstern. Ein typischer Upload-Scheduler reiht Chunks ein und sendet 4 bis 8 parallel, mit Gegendruck, wenn der Server 429 oder 503 signalisiert. Zu viel Parallelität löst ISP-Drosselung und Middlebox-Verbindungsgrenzen aus; zu wenig lässt Bandbreite ungenutzt. Empirisch treffen 4 parallele Streams auf Heimbreitband und 8 bis 16 auf Gigabit-Glasfaser den Sweet-Spot für die meisten Workloads.

Client-seitiger Zustand und Resume-Metadaten

Fortsetzbare Uploads erfordern, dass der Client genug Zustand speichert, um nach einem Browser-Absturz oder Laptop-Neustart fortzufahren. IndexedDB, Teil des Web Storage Standards, speichert Upload-Manifeste mit dem Hash der Datei, der Chunk-Anzahl und welche Chunks erfolgreich waren. Schlüsseln Sie das Manifest nach dem SHA-256-Hash der Datei, damit das erneute Hinzufügen derselben Datei dort weitermacht, wo es aufgehört hat. Bereinigen Sie veraltete Manifeste, die älter als 7 Tage sind, um Aufblähen zu vermeiden. Auf Mobilgeräten kann WKWebView (iOS) und Chrome Custom Tabs (Android) IndexedDB unter Speicherdruck verwerfen – halten Sie daher kritischen Zustand wenn möglich in nativem Speicher.

Server-seitige Chunk-Verarbeitung

Der Server muss Chunks zu einer vollständigen Datei zusammensetzen oder – bei S3 Multipart – die Zusammensetzung an S3 delegieren. Eine minimale Architektur: jedes Chunk-PATCH akzeptieren, in ein temporäres Blob schreiben, das nach Upload-ID und Chunk-Index schlüsselt, den Offset in einem Metadatenspeicher wie Redis oder PostgreSQL aufzeichnen, und bei CompleteMultipartUpload zusammensetzen oder als vollständig markieren. Verwenden Sie Objektspeicher (S3, Cloudflare R2, Backblaze B2) für die Chunk-Blobs statt lokaler Festplatten, da lastverteilte Backends keinen lokalen Zustand teilen können. Bereinigen Sie abgebrochene Uploads nach 24 bis 72 Stunden, um Speicher freizugeben.

Integritätsverifikation pro Chunk und End-to-End

Verifizieren Sie jeden Chunk mit einem Hash beim Upload. S3 Multipages ETag ist ein MD5-Hash pro Teil (oder ein zusammengesetzter Hash für das vollständige Objekt). Für stärkere Integrität: SHA-256 pro Chunk client-seitig berechnen und in einem Header senden; der Server speichert ihn neben dem Chunk und kann ihn beim Wiedereinlesen verifizieren. Nachdem alle Chunks hochgeladen sind: einen Merkle-Tree-Root oder einen Streaming-Hash der zusammengesetzten Datei berechnen und an den Client zurückgeben. Der Client vergleicht mit seinem eigenen Hash der Originaldatei. Bei Abweichung: Re-Upload der betroffenen Chunks auslösen.

Verschlüsselung im Zusammenspiel mit Chunking

Ende-zu-Ende-Verschlüsselung verkompliziert das Chunking leicht. Jeder Chunk braucht seinen eigenen Nonce, um IV-Wiederverwendung in AES-256-GCM zu vermeiden, und die Chunk-Grenzen müssen Teil des Authentifizierungsschemas sein. Ein typischer Ansatz: einen per-Chunk-Schlüssel via HKDF-SHA256 von einem Root-Datei-Verschlüsselungsschlüssel ableiten, wobei der Chunk-Index als Kontextinfo dient, dann jeden Chunk mit AES-256-GCM und einem null- oder inkrementierenden Nonce verschlüsseln. Den Chunk-Index und die Gesamtchunk-Anzahl in den AAD aufnehmen, damit Angreifer Chunks nicht zusammenfügen oder umordnen können. Bei der Entschlüsselung alle Chunks auf Vollständigkeit und Reihenfolge prüfen, bevor der Klartext freigegeben wird.

Alles zusammensetzen

Ein produktionsreifes Chunk-Upload-System kombiniert 5 bis 16 MB Chunks, tus.io oder S3 Multipart für das Protokoll, 4 bis 8 parallele Streams, IndexedDB-gestützten Resume-Zustand, per-Chunk SHA-256-Integritätsprüfungen und optionale per-Chunk Ende-zu-Ende-Verschlüsselung mit einem abgeleiteten Schlüssel. HexaTransfer verwendet client-seitige Chunk-Verschlüsselung mit AES-256-GCM und fortsetzbare Uploads, um 10-GB-Dateien zuverlässig über instabile Verbindungen zu übertragen.

Kostenlos ausprobieren auf hexatransfer.com — kein Konto erforderlich, bis zu 10 GB.