Logo

Kapitel 2 Upload-Pfad: Chunking, Parallelität und Wiederaufnahme (Schlüssel)

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

2.1 Chunking

  • Der Client MUSS die Datei in mehrere Teile aufteilen; Ein Chunk ist die Mindesteinheit für den Upload/Wiederholungsversuch.
  • Chunks SOLLTEN eine feste Größe (oder eine Größe-nach-Datei-Richtlinie) verwenden, um die Parallelitätsplanung und Statusdarstellung zu vereinfachen.
  • Unmittelbarer Vorteil: Jeder Fehler betrifft nur einen Teil, nicht die gesamte Datei.

2.2 Paralleler Upload

Der Zweck der Parallelität besteht nicht in „mehr Threads“, sondern darin, drei praktische Einschränkungen einer einzelnen Verbindung in realen Netzwerken zu vermeiden:

  • Langsamer Start und Fensterwachstum: Eine einzelne Verbindung baut sich langsam auf, insbesondere bei hoher regionsübergreifender RTT.
  • Link-Jitter: Jitter auf einer Verbindung kann die Gesamtgeschwindigkeit verringern; Parallelität glättet den Effekt.
  • Pro-Flow-Formung: Einige Netzwerke drosseln einen einzelnen Fluss. Mehrere Datenflüsse können näher an die Bandbreitenobergrenze herankommen (im Rahmen von Compliance-Einschränkungen).
  • Der Client SOLLTE eine begrenzte Parallelität verwenden (z. B. 4–12) und diese auf schwächeren Geräten verringern, um Speicherspitzen zu vermeiden.
  • Der Client KANN die Parallelität anpassen: erhöhen, wenn der Durchsatz steigt; sinken, wenn die Fehlerquote steigt.

2.3 Idempotenz und Wiederholung

  • Wiederholte Uploads desselben Blocks MÜSSEN idempotent sein: Doppelte Übermittlungen dürfen einen bereits abgeschlossenen Status nicht beschädigen.
  • Der Server SOLLTE die Eindeutigkeit mit (transferId, fileId, chunkIndex) oder einer gleichwertigen Einschränkung erzwingen.
  • Der Client MUSS exponentielle Backoff-Wiederholungsversuche implementieren; Fehler SOLLTEN nur fehlgeschlagene Blöcke erneut versuchen.

2.4 Fortsetzbarer Upload

  • Der Server MUSS antworten können, „welche Chunks bereits hochgeladen wurden“, damit der Client abgeschlossene Chunks überspringen kann.
  • Der hochgeladene Satz SOLLTE als Bitmap/Bereichssatz dargestellt werden, um zu vermeiden, dass die Statusgröße linear mit der Blockanzahl wächst.
  • Geschwindigkeitsvorteil: Nach Netzwerkunterbrechungen, Browserabstürzen oder Netzwerkwechsel erfolgt die Wiederaufnahme nicht bei 0 %.

2.5 „Beim Hochladen teilen“ (optional)

  • Das System generiert möglicherweise eine verwendbare Übertragungskennung und einen Freigabelink, während der Upload noch läuft, um die Lieferabläufe zu beschleunigen.
  • Wenn das Teilen vor Abschluss des Uploads erlaubt ist, MUSS deutlich angegeben werden, was die Empfänger sehen: Unvollständiger Inhalt kann noch nicht heruntergeladen werden oder es wird nur der Fortschritt angezeigt.