Unterbrochene Transfers fortsetzen: nie von vorn beginnen

Fortsetzbare Übertragungen teilen eine Datei in Abschnitte (Chunks) auf und verfolgen, welche davon erfolgreich übertragen wurden. Bricht die Verbindung ab, setzt der Client beim nächsten noch nicht gesendeten Chunk an — nicht bei Byte null. Der offene Webstandard dafür ist tus.io, ein resumable-Upload-Protokoll, das von SwissTransfer, HexaTransfer, Vimeo, Cloudinary und vielen modernen Übertragungsdiensten implementiert wird. Für Downloads ermöglichen HTTP-Range-Requests (RFC 7233) das Fortsetzen unterbrochener Downloads in Browsern und Tools wie curl oder aria2. Ohne Fortsetzbarkeit ist ein 9,8-GB-Upload, der bei 9,5 GB abbricht, vollständig verloren — mit Fortsetzbarkeit verlieren Sie höchstens 50 MB.

Das Problem nicht-fortsetz­barer Uploads

Ein einfacher Datei-Upload sendet die gesamte Datei als einen einzigen HTTP-POST-Request. Unterbricht irgendetwas die Verbindung — WLAN-Ausfall, VPN-Timeout, Laptop-Ruhezustand, Störung beim ISP — schließt der Server die TCP-Verbindung und verwirft die empfangenen Teilinhalte. Der Client beginnt von vorn.

Bei einem 5-GB-Upload über eine 50-Mbps-Leitung sind das 13 Minuten vergebliche Arbeit. Bei 50 GB sind es über zwei Stunden. Auf mobilen Verbindungen scheitern nicht-fortsetzbare Uploads erschreckend häufig — ein 30-minütiger Upload über 4G gelingt im ersten Versuch selten.

Wie fortsetzbare Protokolle funktionieren

Moderne fortsetzbare Uploads folgen diesem Ablauf:

1. Erstellen: Der Client sendet einen POST an den Server mit der Gesamtgröße und Metadaten. Der Server gibt eine eindeutige URL für diesen Upload zurück und reserviert Speicherplatz.
2. Aufteilen: Der Client zerlegt die Datei in Chunks (üblich: 5–64 MB je Chunk).
3. Übertragen: Der Client sendet jeden Chunk als PATCH-Request mit einem Content-Range- oder Upload-Offset-Header, der die Position im Datenstrom angibt.
4. Bestätigen: Der Server schreibt den Chunk in den Speicher und bestätigt den neuen Offset.
5. Fortsetzen: Fällt die Verbindung aus, sendet der Client einen HEAD-Request an die Upload-URL. Der Server antwortet mit dem aktuellen Offset. Der Client setzt ab dort fort.
6. Abschließen: Sobald der letzte Chunk bestätigt ist, ist der Upload fertig.

Dieses Modell ist in der tus.io-Spezifikation (Version 1.0.0 ist weit verbreitet) definiert. Weitere Varianten sind S3 Multipart Upload und Google Cloud Storage Resumable Uploads.

Tus.io: der offene Standard

Tus ("transloadit upload server") ist ein freies, offenes Protokoll, das von Transloadit gepflegt wird. Die Spezifikation ist unter tus.io verfügbar und wird implementiert durch:

• Client-Bibliotheken: tus-js-client (Browser + Node.js), TUSKit (iOS), tus-android-client, tus-java-client
• Server-Implementierungen: tusd (Go-Referenzserver), tus-node-server und diverse Framework-Integrationen
• Kommerzielle Dienste: SwissTransfer, HexaTransfer, Vimeo, Cloudinary, Transloadit, Uppy Companion Server

Das Protokoll ist bewusst schlank gehalten: vier HTTP-Verben (POST, HEAD, PATCH, OPTIONS) und einige Header (Upload-Offset, Upload-Length, Tus-Resumable). Das hält Implementierungen einfach und interoperabel.

Chunk-Größe abwägen

Die Chunk-Größe ist ein Kompromiss zwischen Wiederherstellungsgranularität und HTTP-Overhead.

| Chunk-Größe | Verlust bei Fehler | Overhead | |---|---|---| | 1 MB | ≤ 1 MB | Hoch (viele Requests) | | 5 MB | ≤ 5 MB | Moderat | | 16 MB | ≤ 16 MB | Niedrig | | 64 MB | ≤ 64 MB | Minimal | | 256 MB | ≤ 256 MB | Kaum Overhead, aber schmerzhaft bei Fehler |

Bei stabilen Verbindungen maximieren 32–64-MB-Chunks den Durchsatz. Bei mobilen oder instabilen WLAN-Verbindungen erholen sich 2–5-MB-Chunks schneller von jedem Ausfall. Dienste wählen als Kompromiss meist einen Standardwert zwischen 5 und 10 MB.

Was Transfers tatsächlich unterbricht

Das Verständnis der Fehlerquellen hilft bei der Bewertung eines Dienstes:

• WLAN-Ausfall: Netzwechsel, Signalverlust, Router-Neustart — sehr häufig.
• Laptop-Ruhezustand: Zuklappen des Deckels unter macOS/Windows. Das Betriebssystem pausiert das Netzwerk; beim Aufwachen müssen Verbindungen oft neu aufgebaut werden.
• Tab-Suspendierung: Moderne Browser suspendieren inaktive Tabs, um Speicher zu sparen. Uploads in einem suspendierten Tab können ins Stocken geraten.
• ISP/Backhaul-Probleme: kurzzeitige Routing-Änderungen, erforderlicher TLS-Neuhandshake.
• VPN-Verbindungswiederherstellung: VPN-Clients verhandeln periodisch neu; die TCP-Verbindung bricht ab.
• Server-seitige Neustarts: Der Übertragungsdienst deployt eine neue Version; laufende Requests schlagen fehl.
• Unternehmens-Firewalls: Firewalls mit Deep Packet Inspection unterbrechen manchmal lang laufende Verbindungen.

Eine solide Resume-Implementierung behandelt all diese Szenarien identisch: neu verbinden, Offset per HEAD abfragen, von dort fortsetzen.

Fortsetzung bei Downloads

HTTP-Range-Requests (RFC 7233) ermöglichen fortsetzbare Downloads. Ein Server, der Accept-Ranges: bytes in den Response-Headern ausgibt, unterstützt Range-Requests. Clients können dann Range: bytes=1000000- senden, um nur Bytes ab Offset 1.000.000 abzurufen.

Browser nutzen das automatisch, wenn Sie im Download-Manager auf „Fortsetzen" klicken. Chrome, Firefox und Safari unterstützen Resume bei Downloads von konformen Servern. Die meisten CDNs (Cloudflare, Fastly, CloudFront) unterstützen Ranges.

Kommandozeilen-Tools bieten mehr Kontrolle:

• curl -C - -O url setzt einen Download an der Abbruchstelle fort.
• wget -c url tut dasselbe.
• aria2c -c -s 16 url lädt mit 16 parallelen Range-Request-Streams herunter.

Dienste mit Resume-Unterstützung

Moderne Übertragungsdienste unterstützen Upload-Resume fast durchgehend:

| Dienst | Upload-Resume | Download-Resume | |---|---|---| | SwissTransfer | Ja (tus-basiert) | Ja (HTTP-Ranges) | | HexaTransfer | Ja (Chunked + tus-kompatibel) | Ja | | WeTransfer | Ja (Chunked Uploads) | Ja | | Dropbox Transfer | Ja | Ja | | Google Drive | Ja (Resumable Upload API) | Ja | | OneDrive | Ja | Ja | | Box | Ja | Ja |

Kostenlose Tarife deaktivieren Resume manchmal, um Upgrades zu fördern — das ist aber 2026 selten geworden. Ältere Dienste ohne Resume-Unterstützung verschwinden von Empfehlungslisten, weil Nutzer die Misserfolge nicht mehr akzeptieren.

Was sich nicht automatisch fortsetzt

Einfache HTTP-POST-Uploads in älteren Anwendungen setzen sich nicht fort. FTP-Transfers variieren historisch — manche Clients und Server unterstützen REST-Befehle, andere nicht. E-Mail-Anhänge lassen sich nicht fortsetzen — bricht ein Gmail-Versand bei 90 % ab, beginnt alles von vorn.

Torrent-basierte Transfers sind von Natur aus fortsetzbar, da das Torrent-Protokoll nachverfolgt, welche Teile bereits verifiziert wurden. Das ist ein Grund, warum BitTorrent bei sehr großen Distributionen lange nützlich blieb.

Fortsetzung mit Ende-zu-Ende-Verschlüsselung

Fortsetzbare Uploads in Kombination mit clientseitiger Verschlüsselung erfordern sorgfältiges Chunking. Die Datei wird in Chunks aufgeteilt, jeder Chunk mit AES-256-GCM und einem eindeutigen IV (Initialization Vector) verschlüsselt und dann hochgeladen. Beim Fortsetzen muss der Client wissen, welche Chunks abgeschlossen sind, und beim nächsten weitermachen.

Da jeder Chunk unabhängig verschlüsselt und authentifiziert ist (GCM-AEAD-Modus), können Teiluploads nicht manipuliert werden. Ein böswilliger Server, der bei Offset 5 GB Daten einfügt, würde bei der Entschlüsselung scheitern — der GCM-Tag-Mismatch wird erkannt.

Implementierungen wie HexaTransfer verwenden chunk-spezifische IVs, die deterministisch aus einem Master-Key und dem Chunk-Index abgeleitet werden. Das Fortsetzen erfordert keine separate IV-Speicherung — die Entschlüsselungsseite leitet sie aus derselben Ableitung neu ab.

Best Practices auf Client-Seite

So maximieren Sie den Erfolg beim Fortsetzen:

• Tab während des Uploads aktiv halten. Browser-Tab-Suspendierung beendet laufende Uploads. Eine „Tab nicht schließen"-Warnung ist in Transfer-UIs Standard.
• Wenn möglich, per LAN-Kabel verbinden. WLAN-Ausfall ist die häufigste Fehlerursache.
• Energiesparmodus während langer Uploads deaktivieren. macOS: caffeinate -i. Windows: Energiesparplan oder das Powertoys-Awake-Dienstprogramm.
• Während des Uploads kein WLAN-Netzwerk wechseln. Die TCP-Verbindung ändert ihre IP und bricht ab.
• Upload abschließen, bevor der Laptop zugeklappt wird. Modernes macOS erhält Uploads manchmal durch kurzen Ruhezustand, aber das ist nicht zuverlässig.

Serverseitig prüfen

Manche Dienste zeigen unvollständige Fortschrittsbalken, die den tatsächlichen Serverzustand nicht widerspiegeln. Nach einem Upload, der eine oder zwei Unterbrechungen überlebt hat, sollten Sie die Seite neu laden und prüfen, ob der Link funktioniert — öffnen Sie ihn im Inkognito-Modus und laden Sie einen kleinen Teil herunter. Hat das Fortsetzen funktioniert, wird die vollständige Datei korrekt heruntergeladen.

Für besonders kritische Szenarien: SHA-256-Hash der Originaldatei berechnen, hochladen und dann durch Hashing der heruntergeladenen Datei prüfen, ob sie übereinstimmt. Eine kryptographische Dateiintegritätsprüfung benötigt rund 10 Sekunden CPU pro Gigabyte und gibt absolute Sicherheit.

Fazit

Fortsetzbare Übertragung ist 2026 eine Grundvoraussetzung — jeder Dienst ohne diese Funktion scheidet für Dateien über wenige Hundert Megabyte sofort aus. Achten Sie auf tus.io-Konformität oder ein äquivalentes Chunked-Upload-Verhalten. Stellen Sie sicher, dass der gewählte Dienst Unterbrechungen graceful handhabt — testen Sie mit einem gezielten Netzwerkabbruch bei einer kleinen Datei, bevor Sie einen großen Transfer anvertrauen.

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