Logo

Kapitel 2 Upload-Pfad: Chunking, Parallelität und Wiederaufnahme (zentral)

Auf der Upload-Seite besteht das Ziel darin, bei schwankenden Netzwerken der „Sättigung der Bandbreite“ so nahe wie möglich zu kommen und zugleich die Kosten von Fehlern auf ein Minimum zu begrenzen (nur fehlgeschlagene Chunks werden erneut übertragen). Zusammen erklären diese beiden Ziele weitgehend, warum sich Uploads schneller anfühlen.

2.1 Chunking

  • Der Client MUSS die Datei in mehrere Chunks aufteilen; ein Chunk ist die kleinste Einheit für Upload und Wiederholung.
  • Chunks SOLLTEN eine feste Größe haben (oder eine Größenregel je Datei), um die Planung der Parallelität und die Darstellung des Zustands zu vereinfachen.
  • Unmittelbarer Vorteil: Jeder Fehler betrifft nur einen Chunk, nicht die gesamte Datei.

2.2 Paralleler Upload

Der Zweck der Parallelität sind nicht „mehr Threads“, sondern die Umgehung dreier praktischer Einschränkungen einer einzelnen Verbindung in realen Netzwerken:

  • Slow Start und Fensterwachstum: Eine einzelne Verbindung läuft langsam hoch, besonders bei hoher regionsübergreifender RTT.
  • Link-Jitter: Jitter auf einer Verbindung kann die Gesamtgeschwindigkeit senken; Parallelität glättet den Effekt.
  • Traffic-Shaping pro Flow: Manche Netzwerke drosseln einen einzelnen Flow; mehrere Flows können der Bandbreitenobergrenze näherkommen (im Rahmen der Compliance-Vorgaben).
  • Der Client SOLLTE eine begrenzte Parallelität verwenden (z. B. 4–12) und sie auf schwächeren Geräten senken, um Speicherspitzen zu vermeiden.
  • Der Client KANN die Parallelität anpassen: erhöhen, wenn der Durchsatz steigt; senken, wenn die Fehlerrate steigt.

2.3 Idempotenz und Wiederholung

  • Wiederholte Uploads desselben Chunks MÜSSEN idempotent sein: Doppelte Übermittlungen dürfen einen bereits abgeschlossenen Zustand nicht beschädigen.
  • Der Server SOLLTE die Eindeutigkeit über (transferId, fileId, chunkIndex) oder eine gleichwertige Bedingung erzwingen.
  • Der Client MUSS Wiederholungsversuche mit exponentiellem Backoff implementieren; bei Fehlern SOLLTEN nur die fehlgeschlagenen Chunks erneut versucht werden.

2.4 Fortsetzbarer Upload

  • Der Server MUSS antworten können, „welche Chunks bereits hochgeladen wurden“, damit der Client abgeschlossene Chunks überspringen kann.
  • Die Menge der hochgeladenen Chunks SOLLTE als Bitmap bzw. Range-Set dargestellt werden, damit die Größe des Zustands nicht linear mit der Anzahl der Chunks wächst.
  • Geschwindigkeitsvorteil: Nach Netzwerkunterbrechungen, Browserabstürzen oder Netzwechseln beginnt die Wiederaufnahme nicht wieder bei 0 %.

2.5 „Beim Hochladen teilen“ (optional)

  • Das System KANN eine nutzbare Transferkennung und einen Freigabelink erzeugen, während der Upload noch läuft, um Zustellungsabläufe zu beschleunigen.
  • Wenn das Teilen vor Abschluss des Uploads erlaubt ist, MUSS eindeutig festgelegt sein, was Empfänger sehen: Unvollständige Inhalte sind noch nicht herunterladbar, oder es wird nur der Fortschritt angezeigt.