Logo

Kapitel 1 Warum es schneller ist: Vier Schlüsselmechanismen

Der Geschwindigkeitsvorteil von FileBolt ergibt sich aus einer Kombination aus Transport, parallelem Chunking, globaler Topologie und Multi-Source-Planung. In diesem Kapitel wird auf überprüfbare Weise erläutert, welche Mechanismen den Spitzendurchsatz verbessern und welche die Stabilität und Wiederherstellbarkeit bei Paketverlust oder Netzwerkwechsel verbessern.

1.1 Designziele (Geschwindigkeitsansicht)

  • Ziel A: Annäherung an die Bandbreitenobergrenze. Versuchen Sie unter typischen Bedingungen, die verfügbare Bandbreite auszulasten.
  • Ziel B: Stabiler Durchsatz. Halten Sie den nutzbaren Durchsatz bei Verlust, Jitter, Netzwerkwechsel und hoher regionsübergreifender RTT aufrecht – anstatt plötzlich zusammenzubrechen.
  • Ziel C: Behebbare Fehler. Wenn Fehler auftreten, begrenzen Sie die Kosten auf die erneute Übertragung nur einer kleinen Datenmenge – vermeiden Sie einen Neustart bei 0 %.

1.2 Transportschichtoptimierung: HTTP/3 (QUIC)

  • Der Client- und Edge-Ingress SOLLTE HTTP/3 (QUIC) bevorzugen. Wenn der Browser, das Netzwerk oder die Middleboxen dies nicht unterstützen, MUSS das System automatisch auf HTTP/2/HTTP/1.1 zurückgreifen um die Verfügbarkeit zu wahren.
  • Bei Paketverlust kann die Transport- und Überlastungskontrolle von QUIC häufig die Auswirkungen der Head-of-Line-Blockierung auf den End-to-End-Durchsatz reduzieren und so die Stabilität verbessern (Ergebnisse hängen von den Netzwerkbedingungen ab).
  • 0-RTT/schnellere Handshake-Pfade sind Funktionen zur Sitzungswiederaufnahme unter bestimmten Bedingungen: Das System KANN davon profitieren, wenn Bedingungen erfüllt sind, DARF sich jedoch NICHT auf sie als einzigen Leistungshebel verlassen.

So überprüfen Sie

  • In den DevTools Ihres Browsers (z. B. Netzwerk/Protokoll; Benutzeroberfläche variiert je nach Browser) können Sie beobachten, ob Anfragen h3 (HTTP/3) verwenden oder auf h2/h1 zurückgreifen.
  • Unter den gleichen Netzwerkbedingungen können der Vergleich von h3- und nicht-h3-Verbindungsaufbau und Durchsatzstabilität (insbesondere bei hohem RTT/Verlust) deutliche Unterschiede aufweisen.

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

  • Das System MUSS große Dateien logisch in mehrere Blöcke aufteilen; Jeder Block ist die Mindesteinheit für Upload/Wiederholung/Wiederherstellung (siehe Kapitel 2).
  • Der Client SOLLTE mehrere Blöcke mit begrenzter Parallelität übertragen (z. B. mehrere parallele Pipelines), um näher an die Bandbreitenobergrenze zu kommen und die Empfindlichkeit gegenüber Jitter bei einzelnen Verbindungen zu verringern.
  • Der Client MUSS eine wiederaufnehmbare Übertragung unterstützen: Bei der Wiederherstellung müssen abgeschlossene Blöcke übersprungen und nur die fehlenden abgerufen werden, um eine erneute Übertragung der gesamten Datei zu vermeiden (siehe Kapitel 2).
  • Durch Parallelität und Chunking werden die Wartezeiten, die durch die Blockierung einzelner Anfragen verursacht werden (einschließlich Head-of-Line- und Retransmission-Wartezeiten), erheblich reduziert. Sie SOLLTEN jedoch NICHT behaupten, ein bestimmtes Netzwerkphänomen „vollständig zu eliminieren“. Ziel ist es, die Auswirkungen zu reduzieren und den stabilen Durchsatz zu verbessern.

So überprüfen Sie

  • Im Netzwerkbereich können Sie mehrere parallele Upload-/Download-Anfragen gleichzeitig beobachten (Chunk-Parallelität).
  • Nach dem Trennen des Netzwerks oder dem Aktualisieren der Seite sollte die Wiederaufnahme einer Übertragung nicht bei 0 % beginnen (nur fehlende Blöcke werden vervollständigt).

1.4 Topologievorteil: Anycast-Next-Edge-Zugriff (Edge-Netzwerk)

  • Das System SOLLTE Benutzeranfragen über Anycast/Edge-Ingress an einen nächstgelegenen Knoten weiterleiten, um RTT und die durch regionsübergreifende Hops verursachte Latenz/Jitter zu reduzieren.
  • Der Nearest-Edge-Zugriff verbessert die Gesamteffizienz für paralleles Chunking: Eine niedrigere RTT erhöht in der Regel die effektive Durchsatzobergrenze jedes gleichzeitigen Datenflusses und erleichtert so die Auslastung der Verbindung.
  • Die Randabdeckung und die Anzahl der Standorte können sich mit der Weiterentwicklung der Infrastruktur ändern. Beschreiben Sie dies nach außen hin als „Edge Coverage/nächster Eingang“ und betrachten Sie Zahlen als Orientierung und nicht als feste Garantien.

So überprüfen Sie

  • Mithilfe von Traceroute- oder Browser-Verbindungsinformationen können Sie häufig beobachten, dass Verbindungen bei einem näheren Eingang beendet werden (Methoden variieren je nach Umgebung).
  • Bei regionalen Vergleichen (z. B. USA↔EU / JP↔US) ist die RTT-Reduzierung normalerweise am deutlichsten sichtbar.

1.5 Multi-Source-Parallelität: Intelligente Planung (Multi-Source)

  • Das System SOLLTE dynamische Entscheidungen basierend auf Verbindungsqualitätssignalen (Durchsatz, Latenz, Fehlerrate usw.) treffen, sodass unterschiedliche Chunks mehreren besseren Knoten/Platzierungen zugewiesen werden können. Reduzierung der Auswirkungen von Einzelpunktüberlastungen auf den Gesamtdurchsatz.
  • Beim Herunterladen kann der Client verschiedene Blöcke gleichzeitig von mehreren Quellen abrufen, um einen „Multi-Source-Pull“-Beschleunigungseffekt zu erzielen. Wenn Multi-Source nicht verfügbar ist, MUSS automatisch auf einen Single-Source-Download umgestellt werden um die Verfügbarkeit zu wahren (siehe Kapitel 3).
  • Wenn Sie dies als „KI“ vermarkten, ist es am besten, es als algorithmisches System zur Planung und Entscheidungsfindung zu formulieren und Eingaben/Ausgaben und Abbauverhalten klar zu definieren, um vage Behauptungen zu vermeiden.

So überprüfen Sie

  • Während des Downloads können Sie gleichzeitige Anfragen von verschiedenen Quellen/Verbindungen beobachten (je nach Implementierung und Browser-Sichtbarkeit).
  • Bei Überlastung oder Verlust sorgt die Parallelität mehrerer Quellen häufig für einen stabileren Durchsatz. Wenn die Bedingungen nicht erfüllt sind, wird es automatisch herabgesetzt, bleibt aber verwendbar.

1.6 Wie sich dies auf die nächsten Kapitel überträgt

  • Kapitel 2 erweitert „Chunking, Parallelität, Idempotenz und fortsetzbarer Upload“ um umsetzbare Abläufe und Einschränkungen (MUSS/SOLL/KANN) und erklärt, warum sie die Upload-Geschwindigkeit und -Stabilität direkt beeinflussen.
  • Kapitel 3 erklärt „paralleles Herunterladen, Wiederherstellen und erneutes Zusammenfügen“ und wie man Geschwindigkeitsverluste durch redundante Downloads in schwachen Netzwerken vermeidet.
  • Kapitel 4 behält nur das minimale Speichermodell bei, das für Leistung und Wiederherstellbarkeit relevant ist (Objekt- vs. Zustandsschichten, TTL-/Löschsemantik).