Parallele Upload-Techniken: Bandbreite maximieren

Parallele Uploads teilen eine Datei in Chunks — typischerweise 5 MB bis 100 MB pro Stück — und übertragen sie über mehrere gleichzeitige TCP-Verbindungen. Damit umgehen sie den Durchsatzdeckel, den ein einzelner Stream auf Hochlatenz-Leitungen erreicht. Amazon S3 Multipart Upload, Google Cloud Storage Resumable Uploads und tus.io setzen alle auf dieses Prinzip. Auf einer 1-Gbps-Leitung mit 80 ms Latenz zum Zielserver saturiert ein einzelner HTTP-PUT typischerweise bei 150 Mbps; acht parallele Streams überschreiten 900 Mbps. Der Gewinn ist real und vorhersehbar, sobald man versteht warum.

Warum ein einzelner Stream nicht ausreicht

TCPs Überlastkontrolle steuert über ein gleitendes Fenster, wie viele unbestätigte Daten gleichzeitig im Umlauf sein dürfen. Auf einer breiten Hochlatenz-Leitung füllt sich das Standardfenster (etwa 16 MB unter Linux 5.x, weniger auf älteren Kerneln), bevor die ACKs zurückkommen — der Sender wartet dann untätig. Das ist das „Bandbreite-Verzögerungs-Produkt"-Problem und der Grund, warum ein einzelner FTP-Transfer von Paris nach Singapur auf einer Gigabit-Leitung bei etwa 30 Mbps deckt.

Mehrere parallele Verbindungen umgehen das Problem, weil jede Verbindung ein eigenes Fenster erhält. Acht Streams à 30 Mbps ergeben 240 Mbps — und das noch bevor die CDN-Edge-Selektion berücksichtigt wird, die verschiedene Verbindungen oft über verschiedene Eintrittspunkte leitet.

Chunk-Größe und Parallelität richtig wählen

Der optimale Wert hängt von Latenz und Paketverlust ab. Für innerhalb desselben Kontinents bei unter 50 ms RTT sind 10-MB-Chunks mit 4 parallelen Workern auf den meisten Consumer-Leitungen ausreichend. Für Interkontinental- oder verlustbehaftete Mobilverbindungen (über 100 ms RTT, über 0,5 % Paketverlust) empfehlen sich 5-MB-Chunks mit 8 bis 16 Workern.

S3s Multipart-API verlangt mindestens 5 MB pro Teil (außer beim letzten), maximal 5 GB pro Teil und bis zu 10.000 Teile pro Upload — das ergibt eine theoretische Obergrenze von rund 48,8 TB pro Objekt. Google Cloud Storage erlaubt 32 Teile pro Composite und unterstützt Resumable-Session-URIs, die bis zu einer Woche gültig bleiben. Azure Blob Block Blobs akzeptieren bis zu 50.000 Blöcke à 4.000 MiB.

Für browserbasierte Transfers beginnen Chunks über 100 MB den RAM von bereits geladenen Tabs zu belasten; die meisten Web-UIs bleiben daher zwischen 5 MB und 20 MB.

Wie moderne Transferdienste das umsetzen

WeTransfers Web-Uploader teilt Dateien in 6-MB-Chunks und startet 3 bis 5 parallele XHR-Anfragen. Smash fragmentiert aggressiver mit 4-MB-Chunks über bis zu 8 Worker. SwissTransfer nutzt 50-MB-Chunks mit 4 parallelen Streams — das bevorzugt den Durchsatz auf Schweizer Glasfaser, liefert aber auf instabilen Verbindungen schlechtere Ergebnisse, weil ein fehlgeschlagener Chunk 50 MB Wiederholung bedeutet. Dropbox Transfer setzt auf seine Chunked-Upload-API mit 8-MB-Chunks.

Die Unterschiede zeigen sich in Praxistests: Eine 5-GB-Datei auf einer 500-Mbps-Uploadleitung zu WeTransfer ist in rund 95 Sekunden fertig; SwissTransfer bei ähnlichem Durchsatz braucht etwa 105 Sekunden durch gelegentlichen Chunk-Retry-Overhead.

Wiederaufnahme: die stille Stärke

Chunked Uploads ermöglichen die Wiederaufnahme. Wenn Ihr WLAN bei Chunk 47 von 120 abbricht, müssen Sie nicht von vorn beginnen — Sie setzen bei Chunk 48 fort. Das tus.io-Protokoll (offener Standard, aktuell Version 2.0) formalisiert das mit HEAD-Anfragen zur Abfrage des Upload-Offsets und PATCH-Anfragen zum Anhängen, gesteuert über die Header Upload-Offset und Upload-Length.

Googles Resumable-Upload-API nutzt Session-URIs, die 7 Tage gültig bleiben. Sie können den Laptop abst 닫ürzen lassen, neu starten, den Tab wieder öffnen und genau dort weitermachen, wo Sie aufgehört haben. Das ist der Unterschied zwischen einem brauchbaren 10-GB-Transfer und einem Münzwurf.

Client-seitige Verschlüsselung verändert die Gleichung

Ende-zu-Ende-verschlüsselte Transferdienste müssen jeden Chunk auf dem Client verschlüsseln, bevor er gesendet wird. AES-256-GCM mit 500 MB/s auf einem modernen Laptop-Prozessor ist nicht der Engpass — aber die Reihenfolge zählt: Chunk verschlüsseln, Chunk hochladen, nächsten Chunk verschlüsseln. Pipelining mit einem Worker-Pool ist hier entscheidend. Naive Implementierungen serialisieren Verschlüsselung und Upload, was den effektiven Durchsatz halbiert. Ordentliche Implementierungen halten 2 bis 4 Verschlüsselungs-Worker bereit, die 4 bis 8 Upload-Worker über eine begrenzte Warteschlange versorgen.

Genau deshalb betreibt HexaTransfer AES-256-GCM-Verschlüsselung in Web Workers parallel zu einem XHR-Pool — das 10-GB-Limit ist so im Browser tatsächlich erreichbar, ohne am Krypto hängen zu bleiben.

Gegendruck und serverseitige Limits

Mehr Parallelität ist nicht immer schneller. Wenn der empfangende Dienst pro IP drosselt (bei CloudFront üblich mit 25.000 Anfragen pro Sekunde je Distribution), können 32 gleichzeitige Chunks 503-„Slow Down"-Antworten auslösen. HTTP/2 hilft, weil es über eine einzige TCP-Verbindung multiplext — viele CDNs terminieren HTTP/2 aber am Edge und fächern zu HTTP/1.1 zum Origin auf, sodass die effektive Parallelität von der Edge-Konfiguration abhängt.

Testen Sie, bevor Sie übertreiben. 8 Worker sind fast immer sicher; 16 sind die Obergrenze, bei der Cloud-Objektspeicher noch sauber mitspielen; 32 erzeugen Retries, die mehr kosten als sie einsparen.

Browser-Limits, die Sie kennen sollten

Chrome und Firefox begrenzen gleichzeitige Verbindungen pro Origin auf 6 über HTTP/1.1 und effektiv unbegrenzt über HTTP/2. Ist der Transferdienst noch auf HTTP/1.1 (selten, aber bei einigen Legacy-FTP-über-HTTP-Gateways der Fall), liegt Ihre Parallelitätsobergrenze unabhängig von der Anzahl der Worker bei 6. Prüfen Sie das in den DevTools: Die Spalte „Waterfall" im Netzwerk-Panel zeigt gestapelte Anfragen in der Warteschlange.

Safari auf iOS 17 und später verarbeitet 6 parallele XHR-Anfragen sauber, beginnt aber bei rund 1,5 GB RAM-Druck Hintergrund-Tabs zu entleeren — das ist relevant für Chunked-Upload-Puffer.

Wann parallele Uploads nicht helfen

Auf asymmetrischen Heimanschlüssen (typisch: 1 Gbps down, 40 Mbps up) ist Ihr Upload der Engpass, nicht die Ingest-Kapazität des Servers. Acht parallele Streams à 5 MB durch eine 40-Mbps-Leitung zu drücken, ist nicht schneller als ein einzelner Stream mit 40 Mbps. Parallelität hilft, wenn die Single-Stream-Grenze unter der Kapazität der Leitung liegt — nicht wenn die Leitung bereits ausgelastet ist.

Das gilt auch für Mobilfunk: Bei einem Balken LTE erzeugen zusätzliche Worker hauptsächlich Retransmits.

Worauf Sie bei einem Dienst achten sollten

Wenn Sie ein Transfer-Tool für häufige große Dateien suchen, prüfen Sie drei Dinge: Unterstützt es wiederaufnehmbare Chunked Uploads? Wie viele parallele Worker startet die Web-UI? Und nutzt es HTTP/2 oder HTTP/3 zum Edge? Dienste, die alle drei erfüllen, schieben eine 10-GB-Datei bei einer ordentlichen Verbindung in Minuten durch.

Auf hexatransfer.com testen — kostenlos, ohne Konto, bis 10 GB.