Parallelle uploadtechnieken: bandbreedte maximaliseren

Parallelle uploads splitsen een bestand in chunks (meestal 5 MB tot 100 MB elk) en pushen die over meerdere gelijktijdige TCP-verbindingen, waarmee ze het doorvoerplafond omzeilen dat een enkele stream raakt op links met hoge latentie. Amazon S3 multipart upload, Google Cloud Storage resumable uploads en tus.io implementeren dit allemaal. Op een 1 Gbps-lijn met 80 ms latentie naar de doelserver verzadigt een enkele HTTP PUT doorgaans bij 150 Mbps, terwijl 8 parallelle streams voorbij 900 Mbps duwen. De winst is reëel en voorspelbaar zodra je begrijpt waarom.

Waarom één stream niet genoeg is

TCP's congestion control gebruikt een glijdend venster om te beslissen hoeveel niet-bevestigde data in flight mag zijn. Op een vette, hoge-latentie-pijp vult de standaard venstergrootte (ongeveer 16 MB op Linux 5.x, minder op oudere kernels) zich voordat ACK's terugkeren, en zit de zender stil te wachten. Dit is het "bandwidth-delay product"-probleem, en de reden dat een enkele FTP-overdracht naar een server in Singapore vanuit Parijs rond 30 Mbps uitkomt, zelfs op een gigabitlijn.

Meerdere parallelle verbindingen draaien omzeilt het probleem omdat elke verbinding zijn eigen venster krijgt. Acht streams van 30 Mbps tellen op tot 240 Mbps, en dat is voordat je CDN-edgeselectie meerekent, die vaak verschillende verbindingen via verschillende ingress-punten routeert.

Chunkgrootte en aantal workers

De optimale instelling hangt af van latentie en pakketverlies. Voor overdrachten binnen hetzelfde continent onder 50 ms RTT verzadigen 10 MB chunks met 4 parallelle workers de meeste consumentenlijnen. Voor transcontinentale of verlieslijdende mobiele verbindingen (meer dan 100 ms RTT, meer dan 0,5% pakketverlies) ga je naar 5 MB chunks met 8 tot 16 workers.

S3's multipart API vereist minimaal 5 MB per deel (behalve het laatste), maximaal 5 GB per deel en tot 10.000 delen per upload — het theoretische plafond ligt op ongeveer 48,8 TB per object. Google Cloud Storage staat 32 delen per composite toe en ondersteunt resumable session URI's die tot een week geldig blijven. Azure Blob block blobs accepteren tot 50.000 blocks van 4000 MiB elk.

Voor browser-overdrachten belasten chunks boven 100 MB het RAM van tabbladen die al geladen zijn, dus de meeste web-UI's blijven tussen 5 MB en 20 MB.

Hoe moderne overdrachtsdiensten het daadwerkelijk doen

WeTransfers web-uploader splitst bestanden in chunks van 6 MB en draait 3 tot 5 parallelle XHR-verzoeken. Smash shardt agressiever, met 4 MB chunks over maximaal 8 workers. SwissTransfer gebruikt 50 MB chunks met 4 parallelle streams, wat doorvoer op Zwitserse glasvezellijnen bevoordeelt, maar slechter presteert op onstabiele verbindingen omdat één mislukte chunk 50 MB opnieuw verzenden betekent. Dropbox Transfer leunt op zijn chunked upload API met 8 MB chunks.

De verschillen laten zich zien in echte tests: een 5 GB-bestand op een 500 Mbps-upload naar WeTransfer eindigt in ruwweg 95 seconden; SwissTransfer bij vergelijkbare doorvoer duurt ongeveer 105 seconden door incidentele chunk-retry-overhead.

Hervatbare uploads: de stille superkracht

Chunked uploads ontgrendelen hervatten. Als je Wi-Fi uitvalt bij chunk 47 van 120, begin je niet opnieuw bij nul, maar hervat je vanaf chunk 48. Het tus.io-protocol (een open standaard, nu op versie 2.0) formaliseert dit met HEAD-verzoeken om upload-offset op te vragen en PATCH-verzoeken om toe te voegen, via Upload-Offset- en Upload-Length-headers.

Google Drive's hervatbare upload-API gebruikt session URI's die 7 dagen geldig blijven. Je kunt een laptop laten crashen, opnieuw opstarten, het tabblad heropenen en exact verder gaan waar je gebleven was. Dit is het verschil tussen een bruikbare 10 GB overdracht en een gokje.

Client-side versleuteling verandert de rekening

End-to-end versleutelde overdrachtsdiensten moeten elke chunk op de client versleutelen vóór verzending. AES-256-GCM op 500 MB/s op een moderne laptop-CPU is niet de bottleneck, maar de volgorde telt: versleutel chunk, upload chunk, versleutel volgende chunk. Pipelining met een worker-pool is hier cruciaal. Naïeve implementaties serialiseren versleuteling en upload, waardoor de effectieve doorvoer halveert. Goede implementaties houden 2 tot 4 versleuteling-workers draaiend die 4 tot 8 upload-workers voeden via een begrensde wachtrij.

Daarom draait HexaTransfer AES-256-GCM-versleuteling in Web Workers naast een parallelle XHR-pool, zodat het plafond van 10 GB daadwerkelijk bereikbaar is in de browser zonder op crypto vast te lopen.

Backpressure en limieten aan de serverkant

Meer parallellisme is niet altijd sneller. Als de ontvangende dienst per IP rate-limiet toepast (gebruikelijk bij CloudFront met 25.000 verzoeken per seconde per distributie), kunnen 32 gelijktijdige chunks 503 Slow Down-antwoorden triggeren. HTTP/2 helpt omdat het multiplext over een enkele TCP-verbinding, maar veel CDN's beëindigen HTTP/2 op de edge en fannen HTTP/1.1 uit naar origin, dus de effectieve parallellisme hangt af van edge-configuratie.

Test voordat je overparallelliseert. 8 workers is bijna altijd veilig; 16 is het bovenbereik van wat cloudobject-stores schoon accepteren; 32 begint retries te produceren die meer kosten dan ze opleveren.

Browserlimieten die je moet kennen

Chrome en Firefox cappen gelijktijdige verbindingen per origin op 6 over HTTP/1.1 en effectief onbeperkt over HTTP/2. Als de overdrachtsdienst nog op HTTP/1.1 zit (zeldzaam, maar sommige legacy FTP-over-HTTP-gateways), is je parallellisme-plafond 6 ongeacht hoeveel workers je opspint. Controleer met DevTools: de "Waterfall"-kolom in het Network-paneel toont gestapelde wachtende verzoeken.

Safari op iOS 17 en later verwerkt 6 parallelle XHR schoon, maar begint achtergrondtabs te verwijderen bij ongeveer 1,5 GB RAM-druk, wat telt voor chunked-upload-buffers.

Wanneer parallelle uploads niet helpen

Op asymmetrische residentiële verbindingen (typisch: 1 Gbps down, 40 Mbps up) is je upload de bottleneck, niet de ingest van de server. 8 parallelle streams van 5 MB door een 40 Mbps-pijp duwen gaat niet sneller dan 1 stream van 40 Mbps. Parallellisme helpt wanneer het single-stream plafond onder de capaciteit van de pijp ligt, niet wanneer je de link al verzadigt.

Hetzelfde verhaal voor mobiel: als je één streepje LTE hebt, produceren extra workers vooral hertransmissies.

Waar je op moet letten bij een dienst

Als je een overdrachtstool kiest voor frequente grote bestanden, controleer drie dingen: ondersteunt de dienst hervatbare chunked uploads, hoeveel parallelle workers draait de web-UI, en gebruikt deze HTTP/2 of HTTP/3 naar de edge. Diensten die alle drie raken, verplaatsen een bestand van 10 GB in minuten op een fatsoenlijke verbinding.

Probeer het op hexatransfer.com — gratis, zonder account, tot 10 GB.