HTTP range requests verwenden feste cache-Chunks statt Tuning
HTTP range requests ermöglichen es einem Client, ausgewählte Bytes einer Datei anzufordern, statt das gesamte object herunterzuladen. In einem technischen Bericht vom 23. Oktober 2026 beschrieb Cloudflare eine neue Implementierung, die die bereits vom Pingora cache verwendeten Chunks fester Größe nutzt, anstatt von Kunden die Wahl einer Range-Größe zu verlangen. Die Änderung adressiert ein allgemeineres Infrastrukturproblem: Eine einzige manuell ausgewählte Slice-Größe kann nicht jeden Suchsprung in einem Video, jeden fortgesetzten Download, jeden Paketabruf, jede Dateigröße und jedes cache-Layout effizient bedienen.
Ein range request ist besonders bei großen objects nützlich. Ein Videoplayer kann Daten rund um eine neue Wiedergabeposition abrufen, während ein Download-Manager eine unterbrochene Übertragung fortsetzen kann. Paketmanager können nur einen Teil eines Artefakts abrufen, und Clients können das Ende einer Datei untersuchen, ohne zuvor den gesamten davorliegenden Inhalt zu übertragen. Der Client entscheidet, ob er die Anfrage sendet, und verwendet dafür den Range header, der die benötigten Bytepositionen angibt. Cloudflare zufolge wird diese Client-Anfrage nicht verändert. Origin Range Requests ändert stattdessen, wie das Netzwerk die angeforderten Daten beschafft und zurückgibt.
Wenn der origin server, also das System, auf dem die Originaldatei liegt, die Anfrage unterstützt, kann er den HTTP-Status `206 Partial Content` zurückgeben. Ein `Content-Range`-Response-Header gibt an, welche Bytes geliefert wurden und wie groß die vollständige Datei ist. Cloudflare nennt als Beispiel die Bytes 1048576 bis 2097151 einer 524288000 Byte großen Datei mit einem `Content-Length` von 1048576 Byte. Der letztgenannte Header teilt dem Client mit, wie viele Daten die Response enthält.
Cloudflares frühere Implementierung nutzte eine statische Konfiguration für jede zone, also die Konfigurationsgrenze einer Website. Sie ähnelte der in einem nginx-Blogbeitrag beschriebenen cache slicing-Methode: Jede Client-Anfrage wurde auf Abschnitte einer Datei mit fester Größe abgebildet, während Administratoren sowohl die Abschnittsgröße als auch die betreffenden Dateiendungen konfigurierten. Ein cache ist ein temporärer Speicher, der zuvor abgerufene Daten näher bei den Clients vorhält, damit sie erneut bereitgestellt werden können, ohne sie noch einmal vollständig vom origin übertragen zu müssen.
Dieser Ansatz erzwang einen schwierigen Kompromiss. Klein konfigurierte Ranges erzeugten viele kleine Anfragen an den origin und erhöhten den Speicherdruck, während Cloudflare gleichzeitige Anfragen im Arbeitsspeicher zusammenführte. Große Ranges konnten dazu führen, dass das Netzwerk erheblich mehr Daten herunterlud, als der Client angefordert hatte. Da die gewählte Größe Teil des cache key war, also der Kennung zum Auffinden einer gespeicherten Response, wurden durch eine Änderung dieser Einstellung außerdem bestehende Einträge ungültig.
Parallelität verursachte ein weiteres Problem. Anfragen, die demselben konfigurierten Range zugeordnet waren, konnten einander blockieren, selbst wenn die Clients innerhalb dieses Abschnitts weit auseinanderliegende Bytes benötigten. Cloudflares nginx-basierter cache konnte range caching außerdem nicht sicher mit concurrent streaming kombinieren, bei dem Clients mit dem Lesen eines object aus dem cache beginnen können, während der cache es noch empfängt. Wenn beides aktiviert wurde, konnten Responses abgeschnitten werden. Daher musste ein vollständiger Range eintreffen, bevor ein Client ihn lesen konnte, und eine beliebte Datei erforderte für jeden Range einen separaten Abruf vom origin.
Over-fetching konnte sich über mehrere Ebenen fortpflanzen. Nicht benötigte Bytes konnten vom origin zu einem Rechenzentrum übertragen werden, sich zwischen cache-Tiers bewegen und anschließend weiter zum Client gelangen. Jeder Schritt erhöhte die Menge der unnötig übertragenen Daten. Cloudflare kam zu dem Schluss, dass keine einzelne konfigurierte Range-Größe gleichermaßen gut für einen kurzen Suchsprung, einen sequenziellen Download, ein großes Medien-object, jeden origin und jede cache-Topologie funktionierte. Diese internen Einschränkungen wurden dadurch für Kunden zu einer Konfigurationslast.
Der Wechsel von nginx zu einem Pingora-basierten Caching-Server ermöglichte ein anderes Modell. Pingora speichert bereits jede im cache abgelegte Datei als Chunks fester Größe auf der Festplatte, damit unterbrochene Downloads fortgesetzt werden können. Origin Range Requests verwendet diese Chunks erneut. Der edge, also der Netzwerkstandort, der den Client bedient, prüft zunächst, welche der angeforderten Bytes vorhanden sind. Er gibt verfügbare Daten direkt zurück und fordert anschließend die fehlenden Ranges beim origin an, wobei sich die Anfragen an den Chunk-Grenzen ausrichten. Neu abgerufene Daten werden in denselben Chunks gespeichert, die auch für gewöhnliche im cache gespeicherte objects verwendet werden, während der Client nur die von ihm angeforderten Bytes erhält.
Beispielsweise kann eine Client-Anfrage für die Bytes 150 bis 250 dazu führen, dass der cache den vollständigen, entsprechend ausgerichteten Chunk abruft, der dieses Intervall enthält. Die Downstream-Response enthält dennoch nur die Bytes 150 bis 250. Dadurch werden nicht alle zusätzlichen Übertragungen vermieden: Eine Anfrage, die kleiner als ein Chunk ist, kann weiterhin den vollständigen umschließenden Chunk erfordern, und Ranges, die nicht an den Grenzen ausgerichtet sind, benötigen zusätzliche Verarbeitung. Der von Cloudflare genannte Vorteil besteht darin, dass dieser Aufwand begrenzt und vorhersehbar ist, statt durch eine vom Kunden gewählte Größe gesteuert zu werden, deren Auswirkungen auf den cache und den origin möglicherweise unvorhersehbar sind.
Die schwierige technische Aufgabe besteht nicht darin, den Range header zu parsen, sondern eine korrekte Response zusammenzustellen, wenn deren Bytes über die Festplatte, eine Response vom origin und bereits laufende Downloads verteilt sind. Cloudflare zufolge liest der edge zunächst die Header des Assets und die range-coverage metadata, in denen verzeichnet ist, welche Teile verfügbar sind. Er liest die verfügbaren Daten von der Festplatte oder aus dem Streaming-Speicher, ruft fehlende Bereiche über an Chunk-Grenzen ausgerichtete origin requests ab, schreibt vollständig empfangene Bytes, aktualisiert die Metadaten und führt alle Teile zusammen. Anschließend setzt er `Content-Range` und `Content-Length` für die Response an den Client.
Für Organisationen, die entscheiden, wo sie die zugehörige Workload betreiben sollen, bietet AEU Data europäische Cloud- und Dateninfrastruktur an.
Die übertragbare Erkenntnis lautet, dass die teilweise Auslieferung von Dateien am besten funktioniert, wenn ihre Abrufeinheit mit der nativen Speichereinheit des cache übereinstimmt. Dadurch entfällt eine anfällige, kundenseitige Tuning-Einstellung, die Kosten kleiner oder nicht ausgerichteter Anfragen werden begrenzt, und bereits im cache vorhandene, neu abgerufene sowie in-flight-Daten können gemeinsam zu einer Response beitragen.