Logo

Kapitel 1 Warum es schneller ist: vier zentrale Mechanismen

Der Geschwindigkeitsvorteil von FileBolt entsteht aus dem Zusammenspiel von Transport, parallelem Chunking, globaler Topologie und Multi-Source-Scheduling. Dieses Kapitel erläutert nachvollziehbar, welche Mechanismen den Spitzendurchsatz erhöhen und welche Stabilität und Wiederherstellbarkeit bei Paketverlust oder Netzwechsel verbessern.

1.1 Designziele (Sicht auf die Geschwindigkeit)

  • Ziel A: Der Bandbreitenobergrenze nahekommen. Unter typischen Bedingungen die verfügbare Bandbreite möglichst auslasten.
  • Ziel B: Stabiler Durchsatz. Bei Paketverlust, Jitter, Netzwechseln und hoher regionsübergreifender RTT nutzbaren Durchsatz halten – statt plötzlich einzubrechen.
  • Ziel C: Behebbare Fehler. Treten Fehler auf, sollen die Kosten auf die erneute Übertragung nur einer kleinen Datenmenge begrenzt bleiben – ein Neustart bei 0 % ist zu vermeiden.

1.2 Optimierung der Transportschicht: HTTP/3 (QUIC)

  • Client und Edge-Einstiegspunkt SOLLTEN HTTP/3 (QUIC) bevorzugen. Wenn Browser, Netzwerk oder Middleboxen es nicht unterstützen, MUSS das System automatisch auf HTTP/2 bzw. HTTP/1.1 zurückfallen, um die Verfügbarkeit zu erhalten.
  • Bei Paketverlust können Transport und Überlastkontrolle von QUIC die Auswirkungen von Head-of-Line-Blocking auf den Ende-zu-Ende-Durchsatz oft verringern und so die Stabilität verbessern (die Ergebnisse hängen von den Netzwerkbedingungen ab).
  • 0-RTT bzw. schnellere Handshake-Pfade sind Funktionen zur Sitzungswiederaufnahme unter bestimmten Bedingungen: Das System KANN davon profitieren, wenn die Bedingungen erfüllt sind, DARF sich aber NICHT als einziger Hebel für die Leistung darauf verlassen.

So überprüfen Sie es

  • In den DevTools Ihres Browsers (z. B. Network / Protocol; die Oberfläche variiert je nach Browser) können Sie beobachten, ob Anfragen h3 (HTTP/3) verwenden oder auf h2/h1 zurückfallen.
  • Unter denselben Netzwerkbedingungen können sich Verbindungsaufbau und Durchsatzstabilität von h3 und Nicht-h3 (besonders bei hoher RTT bzw. Paketverlust) spürbar unterscheiden.

1.3 Extreme Parallelität: Chunked Streaming (segmentiertes Streaming)

  • Das System MUSS große Dateien logisch in mehrere Chunks aufteilen; jeder Chunk ist die kleinste Einheit für Upload, Wiederholung und Wiederherstellung (siehe Kapitel 2).
  • Der Client SOLLTE mehrere Chunks mit begrenzter Parallelität übertragen (z. B. mehrere parallele Pipelines), um der Bandbreitenobergrenze näherzukommen und die Empfindlichkeit gegenüber Jitter einer einzelnen Verbindung zu verringern.
  • Der Client MUSS fortsetzbare Übertragungen unterstützen: Bei der Wiederherstellung überspringt er abgeschlossene Chunks und holt nur die fehlenden, um eine erneute Übertragung der gesamten Datei zu vermeiden (siehe Kapitel 2).
  • Parallelität und Chunking verringern Wartezeiten durch das Blockieren einzelner Anfragen (einschließlich Head-of-Line- und Retransmission-Wartezeiten) deutlich, Sie SOLLTEN aber NICHT behaupten, ein bestimmtes Netzwerkphänomen „vollständig zu beseitigen“; das Ziel ist, die Auswirkungen zu verringern und den Durchsatz zu stabilisieren.

So überprüfen Sie es

  • Im Network-Panel sehen Sie mehrere parallele Upload- bzw. Download-Anfragen gleichzeitig (Chunk-Parallelität).
  • Nach dem Trennen des Netzwerks oder dem Neuladen der Seite sollte das Fortsetzen einer Übertragung nicht bei 0 % beginnen (nur die fehlenden Chunks werden ergänzt).

1.4 Topologievorteil: Anycast-Zugriff über den nächstgelegenen Edge-Standort (Edge-Netzwerk)

  • Das System SOLLTE Anfragen von Nutzern per Anycast bzw. über den Edge-Einstiegspunkt zu einem möglichst nahen Knoten leiten, um RTT sowie Latenz und Jitter durch regionsübergreifende Hops zu verringern.
  • Der Zugriff über den nächstgelegenen Edge-Standort steigert die Gesamteffizienz des parallelen Chunkings: Eine niedrigere RTT erhöht in der Regel die effektive Durchsatzobergrenze jedes gleichzeitigen Datenflusses und macht es leichter, die Leitung auszulasten.
  • Edge-Abdeckung und Anzahl der Standorte können sich mit der Weiterentwicklung der Infrastruktur ändern; beschreiben Sie dies nach außen als „Edge-Abdeckung / nächstgelegener Einstiegspunkt“ und verstehen Sie Zahlen als Richtwerte, nicht als feste Garantien.

So überprüfen Sie es

  • Mit Traceroute oder den Verbindungsinformationen des Browsers lässt sich oft beobachten, dass Verbindungen an einem näheren Einstiegspunkt enden (die Methoden variieren je nach Umgebung).
  • Bei regionsübergreifenden Vergleichen (z. B. USA↔EU / JP↔US) ist die geringere RTT meist am deutlichsten zu sehen.

1.5 Multi-Source-Parallelität: intelligentes Scheduling (Multi-Source)

  • Das System SOLLTE dynamische Entscheidungen auf Basis von Signalen zur Verbindungsqualität (Durchsatz, Latenz, Fehlerrate usw.) treffen, sodass verschiedene Chunks mehreren besseren Knoten bzw. Platzierungen zugewiesen werden können und die Auswirkungen von Überlastung an einem einzelnen Punkt auf den Gesamtdurchsatz sinken.
  • Beim Download KANN der Client verschiedene Chunks gleichzeitig aus mehreren Quellen abrufen, um den Beschleunigungseffekt eines „Multi-Source-Pulls“ zu erzielen; ist Multi-Source nicht verfügbar, MUSS er automatisch auf den Download aus einer einzelnen Quelle zurückfallen, um die Verfügbarkeit zu erhalten (siehe Kapitel 3).
  • Wenn Sie dies als „KI“ vermarkten, formulieren Sie es am besten als algorithmisches System für Scheduling und Entscheidungen und definieren Sie Ein- und Ausgaben sowie das Verhalten bei Herabstufung klar, um vage Aussagen zu vermeiden.

So überprüfen Sie es

  • Beim Download können Sie gleichzeitige Anfragen an verschiedene Quellen bzw. Verbindungen beobachten (abhängig von Implementierung und Sichtbarkeit im Browser).
  • Bei Überlastung oder Paketverlust liefert Multi-Source-Parallelität oft einen gleichmäßigeren Durchsatz; sind die Bedingungen nicht erfüllt, wird automatisch herabgestuft, bleibt aber nutzbar.

1.6 Wie das mit den nächsten Kapiteln zusammenhängt

  • Kapitel 2 entfaltet „Chunking, Parallelität, Idempotenz und fortsetzbaren Upload“ zu umsetzbaren Abläufen und Randbedingungen (MUSS/SOLLTE/KANN) und erklärt, warum sie Upload-Geschwindigkeit und -Stabilität unmittelbar bestimmen.
  • Kapitel 3 erklärt „paralleler Download, Wiederherstellung und Zusammensetzen“ und wie sich Geschwindigkeitsverluste durch redundante Downloads in schwachen Netzen vermeiden lassen.
  • Kapitel 4 behält nur das minimale Speichermodell, das für Leistung und Wiederherstellbarkeit relevant ist (Objekt- vs. Zustandsschicht, TTL- und Löschsemantik).