Chunk-gebaseerde upload-architectuur: complete ontwerpgids

Een chunk-gebaseerde uploadarchitectuur splitst een bestand in stukken van vaste of variabele grootte en verstuurt ze onafhankelijk, zodat een netwerkstoring geen herstart van 10 GB vanaf nul veroorzaakt. De twee dominante open standaarden zijn AWS S3 Multipart Upload (minimaal 5 MB per onderdeel, maximaal 10.000 onderdelen) en het hervatbare protocol van tus.io (breed geïmplementeerd). Goed uitgevoerd leveren chunk-uploads 5 tot 10 keer hogere doorvoer op verbindingen met hoge latentie, tolereren ze korte verbreking en maken ze parallelle decryptie aan de ontvangzijde mogelijk. De AVG stelt eisen aan de betrouwbaarheid van gegevensoverdracht; een robuuste chunked-uploadarchitectuur is onderdeel van de technische maatregelen die organisaties moeten nemen. Hieronder staat hoe je er een bouwt die ook in productie standhoudt.

Waarom monolithische uploads mislukken op schaal

Een enkele HTTP PUT van een bestand van 5 GB kan op een half dozijn manieren mislukken. TCP-congestievensters hebben lang de tijd nodig om op te schalen, waardoor de doorvoer op paden met hoge latentie ver onder de linkcapaciteit blijft. Browsers beperken gelijktijdige verbindingen per origin tot 6, waardoor het meeste bandbreedte onbenut blijft. Server-side request-timeouts — nginx-standaard 60 seconden, CloudFront 30 seconden voor niet-streamingverkeer — onderbreken lange uploads. Mobiele netwerken die tussen zendmasten schakelen, verbreken de verbinding om de paar minuten. En één enkele bitfout dwingt de volledige overdracht te herstarten. Chunked uploads lossen dit alles op door de werkeenheid klein, onafhankelijk herhaalbaar en parallel-vriendelijk te maken.

De juiste chunkgrootte kiezen

Chunkgrootte is een afweging. Kleinere chunks herstellen sneller van fouten en bieden fijnere voortgangs-granulariteit, maar voegen meer HTTP-overhead toe. Grotere chunks amortiseren handshake- en TLS-kosten, maar verspillen bandbreedte wanneer een chunk mislukt en opnieuw verstuurd moet worden. Typische bereiken: 1 MB tot 5 MB voor mobiele uploads op verliesrijke netwerken, 5 MB tot 16 MB voor desktop-webuploads, 16 MB tot 64 MB voor server-naar-server overdrachten op betrouwbare verbindingen, en 100 MB of meer voor S3 Multipart waarbij het plafond van 10.000 onderdelen grotere chunks vereist voor bestanden van 1 TB. Sommige systemen passen de grootte dynamisch aan: klein beginnen en opschalen naarmate de verbinding betrouwbaar blijkt.

Vaste grootte versus inhoudsgedefinieerde chunking

Vaste chunking — bijvoorbeeld elke 8 MB — is eenvoudig te implementeren, parallel-vriendelijk en ondersteunt exacte hervatoffsets. Inhoudsgedefinieerde chunking, gebruikt in rsync en restic, kiest grenzen op basis van een rolling hash zoals Rabin-vingerafdrukken, zodat invoegingen midden in een bestand niet alle volgende chunkgrenzen verschuiven. Inhoudsgedefinieerde chunking is uitstekend voor deduplicatie in back-uptools, maar voegt complexiteit en CPU-kosten toe die bij pure bestandsoverdracht niet worden beloond. Voor uploadarchitecturen wint vaste chunking op eenvoud en sluit het netjes aan bij S3 multipart-onderdelen of tus.io-offsets.

Hervatbare uploadprotocollen

Het tus.io-protocol — geïmplementeerd in tusd (Go), tus-js-client, Uppy en vele server-frameworks — gebruikt HTTP PATCH met een Upload-Offset-header om chunks toe te voegen. Een HEAD-verzoek geeft de huidige offset op de server terug, zodat de client weet waar hij moet hervatten na een netwerkonderbreking. S3 Multipart Upload werkt anders: initieer de upload om een UploadId te krijgen, upload elk onderdeel (1-geïndexeerd) en stuur een CompleteMultipartUpload-verzoek met de lijst van ETags. Clients kunnen ListParts opvragen om te zien wat al geüpload is. Beide protocollen bewaren de staat over client-herstarts en gaan soepel om met verbindingsverbreking.

Parallelle uploadconcurrentie

Chunks parallel uploaden verhoogt de doorvoer aanzienlijk op verbindingen met hoge latentie. HTTP/1.1 is beperkt tot 6 gelijktijdige verbindingen per origin in browsers; HTTP/2 multiplext veel streams over één verbinding, maar is nog steeds onderhevig aan flow-controlvensters. Een typische uploadplanner plaatst chunks in een wachtrij en verstuurt er 4 tot 8 parallel, met tegendruk wanneer de server een 429 of 503 geeft. Te veel parallelisme activeert ISP-shaping en middelboxverbindingslimieten; te weinig laat bandbreedte ongebruikt. Empirisch bereiken 4 parallelle streams op thuisbreedband en 8 tot 16 op gigabitvezel het zoete punt voor de meeste workloads.

Client-side staat en hervatmetadata

Hervatbare uploads vereisen dat de client genoeg staat onthoudt om te hervatten na een browsercrash of laptop-afsluiting. IndexedDB, onderdeel van de Web Storage-standaard, slaat uploadmanifesten op met de hash van het bestand, het aantal chunks en welke chunks succesvol waren. Gebruik de SHA-256-hash van het bestand als sleutel voor het manifest, zodat hetzelfde bestand opnieuw toevoegen verdergaat waar het was gebleven. Verouderde manifesten ouder dan 7 dagen opruimen voorkomt bloat. Op mobiel kunnen WKWebView (iOS) en Chrome Custom Tabs (Android) IndexedDB verwijderen onder geheugendruk, dus bewaar kritieke staat in native opslag indien mogelijk.

Server-side afhandeling van chunks

De server moet chunks samenvoegen tot een volledig bestand, of met S3 Multipart de samenvoeging delegeren aan S3. Een minimale architectuur: accepteer elke chunk-PATCH, schrijf naar een tijdelijke blob met als sleutel upload-ID en chunk-index, registreer de offset in een metadata-opslag zoals Redis of PostgreSQL, en stel bij CompletePart samen of markeer als voltooid. Gebruik object-opslag — S3, Cloudflare R2, Backblaze B2 — voor de chunk-blobs in plaats van lokale schijf, want load-balanced backends kunnen lokale staat niet eenvoudig delen. Verwijder verlaten uploads na 24 tot 72 uur om opslag vrij te maken.

Integriteitsverificatie per chunk en end-to-end

Verifieer elke chunk met een hash bij upload. De ETag van S3 Multipart is een MD5-hash per onderdeel (of een samengestelde hash voor het volledige object). Voor sterkere integriteit: bereken SHA-256 per chunk aan de clientzijde en stuur het mee in een header; de server slaat het op naast de chunk en kan het bij herlezing verifiëren. Nadat alle chunks geüpload zijn, bereken een Merkle-boomwortel of een streaming-hash van het samengevoegde bestand en stuur het terug naar de client. De client vergelijkt met zijn eigen hash van het originele bestand. Een mismatch activeert een herüpload van de betreffende chunks.

Samenspel van versleuteling en chunking

End-to-end versleuteling maakt chunking iets complexer. Elk chunk heeft zijn eigen nonce nodig om IV-hergebruik in AES-GCM te voorkomen, en de chunkgrenzen moeten deel uitmaken van het authenticatieschema. Een typische aanpak: leid een per-chunk-sleutel af via HKDF-SHA256 vanuit een root bestandsversleutelingssleutel, gebruik de chunk-index als contextinformatie, en versleutel elk chunk met AES-256-GCM en een nul of oplopende nonce. Voeg de chunk-index en het totale aantal chunks toe aan de AAD, zodat aanvallers chunks niet kunnen vervangen of herordenen. Verifieer bij decryptie dat alle chunks aanwezig en in de juiste volgorde zijn voordat de leesbare tekst wordt vrijgegeven.

Observeerbaarheid voor chunk-gebaseerde systemen

Instrumenteer elke chunk. Te volgen meetwaarden: geüploade chunks per seconde, p50/p95/p99 upload-latentie per chunk, herhaalpogingspercentage per chunk en het percentage verlaten uploads. Dashboards in Grafana of Datadog onthullen regressies snel. Gedistribueerde traces via OpenTelemetry koppelen een clientsessie aan de server-side afhandeling van chunks. Log gestructureerde gebeurtenissen in JSON zodat ze doorzoekbaar zijn in Loki, Elasticsearch of Splunk. Wanneer een klant een trage upload meldt, toont de trace precies welke chunks vastliepen en waarom.

Alles samengevat

Een productieklaar chunked-uploadsysteem combineert chunks van 5 MB tot 16 MB, tus.io of S3 Multipart als protocol, 4 tot 8 parallelle streams, IndexedDB-backed hervatstatus, SHA-256-integriteitscontroles per chunk, en optionele E2EE per chunk met een afgeleide sleutel. HexaTransfer gebruikt client-side chunked versleuteling met AES-256-GCM en hervatbare uploads om bestanden van 10 GB betrouwbaar te verwerken via onstabiele verbindingen.

Probeer het op https://hexatransfer.com — gratis, geen account, maximaal 10 GB.