Egress-Kosten senken: Deep Dive in CDN Caching mit Origin Range Requests für große Assets

Ein Nutzer klickt auf Play bei einem 4 GB großen Video oder lädt ein inkrementelles 50-MB-Update-Paket für Ihre Desktop-Software herunter. Der Client sendet einen standardmäßigen HTTP-Request mit dem Header Range: bytes=0-1048575, um lediglich das erste Megabyte zum Puffern des Starts oder zum Auslesen der Datei-Header abzufragen. Ist Ihr Edge-Caching-Layer naiv konfiguriert, leitet Ihr Content Delivery Network (CDN) diesen Request per Forward-Proxy an Ihren Origin-Objektspeicher weiter, indem es das gesamte 4-GB-Archiv über das Netzwerk überträgt, nur um 99,9 % der Daten zu verwerfen, sobald der Nutzer den Stream stoppt.

Multiplizieren Sie diesen einzelnen Request mit Tausenden gleichzeitigen Clients, Media-Scrubbern oder verteilten Software-Updatern, und Ihre Egress-Bandbreitenkosten explodieren über Nacht. Schlimmer noch: Ihr Origin-Storage gerät in eine gravierende I/O-Erschöpfung, die p99-Antwortzeiten in den Bereich mehrerer Sekunden treibt.

Die Lösung dieses Engpasses erfordert ein tiefes technisches Verständnis von Origin Range Requests und CDN Caching. Wenn CDNs und Reverse Proxys Partial-Content-Anfragen ohne koordiniertes Sub-Range-Caching verarbeiten, führt dies zu versteckten Latenzen, Thundering-Herd-Problemen auf den Origin-Objektspeichern und unkontrollierten Egress-Rechnungen.

In diesem Deep Dive analysieren wir, warum naives Range Caching versagt, untersuchen, wie moderne Proxy-Architekturen partielle Abfragen koordinieren, führen eine praktische Proxy-Implementierung durch und erstellen ein praxiserprobtes Runbook für Ihre Infrastruktur.

Die verborgene Mechanik naiver Byte-Range-Requests

Um zu verstehen, warum Range Caching fehlschlägt, müssen wir analysieren, wie Edge Proxys HTTP-Range-Header unter Standardkonfigurationen verarbeiten.

Die HTTP-Spezifikation (RFC 9110) erlaubt es Clients, partielle Ressourcen über den Range-Header anzufordern:

GET /assets/installer-v2.bin HTTP/1.1
Host: downloads.example.com
Range: bytes=0-2097151

Wenn ein Upstream-CDN-Node oder ein Reverse Proxy diesen Request empfängt, folgt er typischerweise einem von drei Verhaltensmustern:

Pass-Through (Kein Caching): Der Proxy leitet den Range-Header unverändert an den Origin weiter. Wenn 10.000 Nutzer dasselbe Video durchsuchen (Scrubbing) oder Metadaten-Blöcke aus ZIP-Archiven laden, treffen 10.000 separate Range Requests Ihren Origin-Objektspeicher (wie AWS S3, Google Cloud Storage oder Cloudflare R2).
Vollständiger Origin-Download (Whole-File Origin Fetching): Der Proxy wandelt den partiellen Request in einen vollständigen GET /assets/installer-v2.bin-Request an den Origin um und versucht, das gesamte 4-GB-Objekt lokal auf der Edge-Festplatte zu speichern. Der Proxy extrahiert die Bytes 0-2097151, um den Client sofort zu bedienen, während er den Rest im Hintergrund weiter streamt. Bricht der Nutzer die Verbindung nach 3 MB ab oder pausiert, bricht der Proxy entweder den Origin-Stream ab (was den Fetch verschwendet) oder lädt Gigabytes herunter, die niemand angefordert hat.
Diskrete Slice-Fragmentierung (Discrete Slice Fragmentation): Der Proxy speichert exakt den angeforderten Byte-Bereich (bytes 0-2097151) als isolierten Cache Key. Fordert ein nachfolgender Client bytes 1048576-3145727 an (mit einer Überlappung von 1 MB), registriert der Proxy einen Cache Miss, da das exakt angeforderte Byte-Fenster mit keinem gecachten Eintrag übereinstimmt. Er fragt den Origin erneut an, wodurch doppelte, überlappende Fragmente auf den Edge-Disks entstehen.

Die realen Kosten: Eine beispielhafte Architekturbetrachtung

Um zu veranschaulichen, wie schnell naives Caching die Infrastrukturbudgets aufzehrt, betrachten wir ein realistisches Szenario:

Sie betreiben eine Softwareplattform, die Game-Asset-Bundles oder KI-Modellgewichte bereitstellt.
Ihr Katalog umfasst 2.000 Dateien mit durchschnittlich jeweils 1,5 GB.
Clients senden täglich 500.000 Range Requests, vor allem zum Lesen von 2-MB-Chunks (z. B. Streaming von Audio, Lesen von Asset-Headern oder Download von Package-Manifesten).
Die Egress-Kosten des Origin-Speichers liegen bei branchenüblichen 0,09 USD pro Gigabyte.

Unter Strategie 2 (Vollständiger Origin-Download): Wenn 10 % dieser Anfragen Cold-Edge-Nodes treffen, die vollständige Dateidownloads initiieren (50.000 vollständige Downloads × 1,5 GB), überträgt Ihr Origin-Egress täglich 75.000 GB (75 TB). Das entspricht rund 6.750 USD pro Tag allein an Origin-Egress-Kosten, obwohl die tatsächlich von End-Clients konsumierte Datenmenge nur 1.000 GB (1 TB) betrug.

Unter Strategie 3 (Diskrete Slice-Fragmentierung) füllen sich die Edge-Disks schnell mit nicht wiederverwendbaren Fragmenten. Die Cache-Hit-Ratio sinkt auf unter 25 %, was permanente Eviction-Schleifen auslöst und die p99-Latenz des Origins saturiert. Ähnliche Architektur-Bottlenecks treten häufig in asynchronen Pipelines auf, vergleichbar mit unpartitionierten Queues beim Isolieren von Consumer-Tests auf einem Shared Message Broker.

Wie intelligente Koordination von Origin Range Requests funktioniert

Moderne Edge-Architekturen, wie Cloudflares Rust-basiertes Pingora-Framework, performante NGINX-Installationen oder maßgeschneiderte Envoy-Sidecars, lösen dieses Problem durch synchronisiertes Slice-Fetching und Origin-Range-Konvertierung.

Anstatt zu raten, was der Client benötigt, oder gigabytegroße Blobs zu laden, standardisiert ein optimierter Edge Proxy Byte-Requests in einheitliche, feste Chunks (typischerweise 1-MB-, 2-MB- oder 8-MB-Slices).

Client Request:
[ Range: bytes=1.5MB - 3.2MB ]
              │
              ▼
      Edge-Proxy-Layer
   (Normalisiert in Slices)
              │
     ┌────────┴────────┐
     ▼                 ▼
Slice 1 (1MB-2MB)   Slice 2 (2MB-3MB)   Slice 3 (3MB-4MB)
 [Cache HIT]         [Cache MISS]        [Cache MISS]
                      │                   │
                      ▼                   ▼
               Vom Origin abrufen   Vom Origin abrufen
               (Range: 2MB-3MB)     (Range: 3MB-4MB)

Hier ist der operative Lebenszyklus eines intelligenten, Range-koordinierenden Proxys:

Alignment und Normalisierung: Wenn ein Client einen beliebigen Range anfordert (z. B. bytes=1572864-3670015), zerlegt der Proxy diesen in normalisierte Slice-Grenzen (z. B. Slice A: 1MB-2MB, Slice B: 2MB-3MB, Slice C: 3MB-4MB).
Prüfung einzelner Slices: Der Proxy prüft seinen lokalen Cache für jedes einzelne Slice.
Gezielte Upstream-Range-Requests: Für jedes nicht gecachte Slice sendet der Proxy einen separaten partiellen Request (Range: bytes=start-end) an den Origin-Objektspeicher. Der Origin überträgt niemals die gesamte Datei, sondern streamt nur die fehlenden 1-MB- oder 2-MB-Segmente.
Upstream Request Collapsing (Coalescing): Wenn zehn gleichzeitige Clients bei kaltem Cache gleichzeitig bytes 0-1048575 anfordern, leitet der Proxy genau einen Range Request an den Origin weiter. Die übrigen neun Requests blockieren asynchron und lesen aus dem eingehenden Datenstrom, sobald Bytes eintreffen.
Zusammensetzen der Client-Antwort: Der Proxy fügt die Slices zu einem einzigen kontinuierlichen HTTP-206-Partial-Content-Stream zusammen und liefert exakt den vom Client angeforderten Bereich aus.

Dieses Design verbessert zwei entscheidende Metriken: Es reduziert den Origin-Egress nahezu auf ein 1:1-Verhältnis zum tatsächlichen Client-Verbrauch und minimiert die p99-Tail-Latency, da Origin-Storage-Nodes lediglich kleine, hochgradig parallelisierbare Block-Streams ausliefern müssen.

Slice-basiertes Range Caching implementieren: Ein praktisches Proxy-Beispiel

Während Enterprise-CDNs Slice Caching oft intern verwalten, können Sie eine identische Mechanik innerhalb Ihres eigenen Applikationsperimeters über Reverse Proxys oder leichtgewichtige Microservices implementieren.

Nachfolgend finden Sie ein vollständiges, lauffähiges Beispiel mit Node.js und TypeScript. Es demonstriert, wie ein benutzerdefiniertes Edge Gateway oder ein Streaming-Microservice eingehende Range Requests normalisiert, in konsistente 1-MB-Chunks aufteilt, einen In-Memory-/Disk-Cache prüft, fehlende Segmente mittels Standard-Range-Headern aus einem Origin-S3/R2-Bucket abruft und das zusammengesetzte Ergebnis an den Client streamt.

import http from 'node:http';
import https from 'node:https';
import { URL } from 'node:url';

const CHUNK_SIZE = 1024 * 1024; // 1 MB normalized slice
const ORIGIN_BASE_URL = 'https://origin-storage.internal.example.com';
const memoryCache = new Map<string, Buffer>();

interface RangeSpan {
  start: number;
  end: number;
}

function parseRangeHeader(rangeHeader: string | undefined, totalSize: number): RangeSpan | null {
  if (!rangeHeader || !rangeHeader.startsWith('bytes=')) return null;
  const parts = rangeHeader.replace('bytes=', '').split('-');
  const start = parseInt(parts[0], 10);
  const end = parts[1] ? parseInt(parts[1], 10) : totalSize - 1;

  if (isNaN(start) || isNaN(end) || start > end || start >= totalSize) {
    return null;
  }
  return { start, end: Math.min(end, totalSize - 1) };
}

async function fetchSliceFromOrigin(assetPath: string, sliceIndex: number): Promise<Buffer> {
  const cacheKey = `${assetPath}_slice_${sliceIndex}`;
  if (memoryCache.has(cacheKey)) {
    return memoryCache.get(cacheKey)!;
  }

  const sliceStart = sliceIndex * CHUNK_SIZE;
  const sliceEnd = sliceStart + CHUNK_SIZE - 1;
  const originUrl = new URL(assetPath, ORIGIN_BASE_URL);

  return new Promise((resolve, reject) => {
    const req = https.get(
      originUrl,
      {
        headers: {
          Range: `bytes=${sliceStart}-${sliceEnd}`,
        },
      },
      (res) => {
        if (res.statusCode !== 206 && res.statusCode !== 200) {
          reject(new Error(`Origin returned status code: ${res.statusCode}`));
          return;
        }

        const chunks: Buffer[] = [];
        res.on('data', (d) => chunks.push(d));
        res.on('end', () => {
          const completeBuffer = Buffer.concat(chunks);
          memoryCache.set(cacheKey, completeBuffer);
          resolve(completeBuffer);
        });
      }
    );
    req.on('error', reject);
  });
}

const server = http.createServer(async (req, res) => {
  const url = new URL(req.url || '/', `http://${req.headers.host}`);
  const assetPath = url.pathname;

  // In production, fetch or query metadata from Redis, database, or HEAD request
  const totalFileSize = 50 * 1024 * 1024; // Simulated 50 MB file

  const range = parseRangeHeader(req.headers.range, totalFileSize);

  if (!range) {
    res.writeHead(416, { 'Content-Range': `bytes */${totalFileSize}` });
    res.end();
    return;
  }

  const firstSliceIndex = Math.floor(range.start / CHUNK_SIZE);
  const lastSliceIndex = Math.floor(range.end / CHUNK_SIZE);

  res.writeHead(206, {
    'Content-Range': `bytes ${range.start}-${range.end}/${totalFileSize}`,
    'Accept-Ranges': 'bytes',
    'Content-Length': range.end - range.start + 1,
    'Content-Type': 'application/octet-stream',
  });

  for (let idx = firstSliceIndex; idx <= lastSliceIndex; idx++) {
    try {
      const sliceBuffer = await fetchSliceFromOrigin(assetPath, idx);
      const sliceStartByte = idx * CHUNK_SIZE;
      const sliceEndByte = sliceStartByte + sliceBuffer.length - 1;

      // Calculate byte offsets within this specific slice
      const extractStart = Math.max(0, range.start - sliceStartByte);
      const extractEnd = Math.min(sliceBuffer.length, range.end - sliceStartByte + 1);

      const subChunk = sliceBuffer.subarray(extractStart, extractEnd);
      res.write(subChunk);
    } catch (err) {
      console.error(`Failed to pipe slice ${idx}:`, err);
      res.destroy();
      return;
    }
  }

  res.end();
});

server.listen(8080, () => {
  console.log('Range caching proxy listening on port 8080');
});

Zentrale Implementierungsprinzipien

Deterministische Cache Keys: Jedes Slice wird über seinen Dateipfad und seinen normalisierten Slice-Index adressiert (${assetPath}_slice_${sliceIndex}). Unabhängig davon, ob ein Client die Bytes 100 bis 5.000 oder 4.000 bis 8.000 anfordert: Beide treffen auf Slice-Index 0.
Speicherbegrenzung (Memory Bounds): Ersetzen Sie in Produktionsumgebungen die einfache In-Memory-Map durch einen LRU-Cache oder lokalen NVMe-Storage mit Consistent Hashing über die Proxy-Worker-Threads hinweg.
Subarray-Windowing: Durch das Zwischenspeichern einheitlicher 1-MB-Slices und die Verwendung von .subarray(extractStart, extractEnd) vermeidet der Proxy unnötige String-Allokationen und Speicherkopien.

Fallstricke in der Produktion: Wo Range Caching scheitert

Die Entwicklung einer Edge-Architektur, die Origin Range Requests koordiniert, birgt subtile Herausforderungen bei Nebenläufigkeit und Cache-Invalidierung. Entwicklungsteams stoßen regelmäßig auf vier typische Fehlerquellen:

1. Inkonsistente ETags und Desynchronisation von Last-Modified

Beim dynamischen Zusammensetzen von Slices muss der Origin garantieren, dass die Datei zwischen dem Abruf von Slice 0 und Slice 10 nicht verändert wurde. Wird während des sequenziellen Slice-Streamings eine aktualisierte Datei bereitgestellt, erhält der Client Bytes aus Version A nahtlos verknüpft mit Bytes aus Version B, was zu binärer Korruption führt.

Lösung: Erzwingen Sie eine strikte Validierung über den If-Range-Header oder vergleichen Sie das ETag des Origins bei jedem abgerufenen Slice. Tritt während der Übertragung ein ETag-Mismatch auf, leeren Sie sofort alle zugehörigen lokalen Slices und starten Sie den Download-Stream des Clients neu.

2. Cache Thundering Herds bei Cold Deployments

Wird ein umfangreiches Update veröffentlicht (wie ein 10-GB-Installer oder Game-Patch), verzeichnen Hunderte Edge-Nodes gleichzeitig Cache Misses in ihren lokalen Caches. Fehlt Request Collapsing, sendet jeder Edge-Node Tausende parallele Range Requests an Ihren Origin-Storage.

Lösung: Aktivieren Sie Request Coalescing (in NGINX bekannt als proxy_cache_use_stale updating oder Lock-Koordination in modernen Proxy-Engines). Der Proxy darf pro fehlendem Slice nur einen einzigen Origin-Fetch ausführen, während nachfolgende Client-Requests auf das Promise dieses exakten Slices warten.

3. Suboptimale Slice-Größen

Die Wahl der falschen Slice-Größe beeinträchtigt die Performance in beiden Extremen:

Zu klein (z. B. 64 KB): Führt zu erheblichem HTTP-Overhead, Verbindungs-Roundtrips und übermäßiger Header-Verarbeitung zwischen Edge und Origin.
Zu groß (z. B. 32 MB): Verursacht Streaming-Latenzspitzen beim Video-Scrubbing und verschwendet Egress-Bandbreite, wenn Clients lediglich Metadaten-Header lesen.
Faustregel: Analysieren Sie die Lesemuster Ihrer Clients. Für Medienstreaming und Binary-Assets mit wahlfreiem Zugriff bieten Slice-Größen zwischen 1 MB und 4 MB meist den besten Kompromiss aus Latenz und Bandbreiteneffizienz.

Die Entwicklung robuster Backend-Infrastrukturen deckt bei Cloud-Netzwerken und Game-Engines oft unerwartete Skalierungsengpässe auf. Teams, die anspruchsvolle Plattformen entwickeln, setzen häufig auf einen erfahrenen Partner für individuelle Softwareentwicklung, um fehlertolerante Streaming-Pipelines zu konzipieren, die Edge-Auslieferung zu optimieren und unerwartete Egress-Kosten zu vermeiden.

Schritt-für-Schritt-Runbook: Origin Range Caching absichern

Folgen Sie diesem fünfstufigen Runbook, um Byte-Range-Caching in Ihrer Infrastruktur zu diagnostizieren, zu konfigurieren und zu verifizieren.

Schritt 1: Aktuelles Verhalten via cURL auditieren
  │
Schritt 2: Edge-Slicing-Regeln konfigurieren
  │
Schritt 3: Origin-Header harmonisieren (ETags & Cache-Control)
  │
Schritt 4: Origin-Egress-Metriken & Cache Hits prüfen
  │
Schritt 5: Automatisierte Invalidierungs- und Concurrency-Tests durchführen

Schritt 1: Aktuelles Edge-Verhalten auditieren

Prüfen Sie, ob Ihr aktueller Proxy oder Ihr CDN vollständige Assets cacht, Ranges unverändert durchreicht oder partielle Chunks korrekt zurückgibt. Führen Sie zwei aufeinanderfolgende Range Requests für denselben Byte-Bereich aus:

curl -svo /dev/null \
  -H "Range: bytes=0-1048575" \
  https://downloads.example.com/assets/bundle.pkg

Überprüfen Sie die Response-Header:

Stellen Sie sicher, dass Accept-Ranges: bytes vorhanden ist.
Prüfen Sie, ob HTTP/1.1 206 Partial Content (oder das HTTP/2-Äquivalent) zurückgegeben wird.
Untersuchen Sie den Cache-Status-Header (z. B. cf-cache-status, x-cache oder age). Beim zweiten Request sollte der Status HIT anzeigen.

Führen Sie anschließend einen Request für einen überlappenden Bereich aus (z. B. bytes=524288-1572863). Zeigt der Cache-Status ein MISS und die Origin-Metriken deuten auf einen vollständigen Asset-Download hin, unterstützt Ihr Proxy kein normalisiertes Slice-Caching.

Schritt 2: Edge-Slicing-Regeln konfigurieren

Wenn Sie NGINX als Reverse Proxy einsetzen, aktivieren Sie das native slice-Modul, um partielle Anfragen automatisch zu koordinieren:

http {
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=range_cache:100m 
                     max_size=50g inactive=7d use_temp_path=off;

    server {
        listen 80;
        server_name downloads.example.com;

        location /assets/ {
            slice             1m;
            proxy_cache       range_cache;
            proxy_cache_key   $uri$is_args$args$slice_range;
            
            # Forward the slice range to the origin
            proxy_set_header  Range $slice_range;
            
            # Collapse multiple requests for the same slice
            proxy_cache_lock  on;
            proxy_cache_lock_timeout 5s;

            # Origin settings
            proxy_pass        https://storage.internal.example.com;
            proxy_http_version 1.1;
            proxy_set_header  Connection "";
            
            # Cache partial content
            proxy_cache_valid 206 200 30d;
        }
    }
}

Beachten Sie die entscheidende Variable: $slice_range. NGINX fängt den beliebigen Range-Header des Clients automatisch ab, zerlegt ihn in 1-MB-Chunks, belegt $slice_range und speichert jedes Slice unter einem eigenen deterministischen Cache Key.

Schritt 3: Origin-Header harmonisieren

Ihr Origin-Storage-Bucket oder Ihre Backend-Anwendung muss verlässliche Cache-Validatoren liefern:

Starke ETags: Stellen Sie sicher, dass ETags über alle Origin-Replikate hinweg konsistent sind. Vermeiden Sie dynamische gzip-/brotli-Kompression bei Binärdateien, da dies das ETag zwischen Requests verändern kann.
Cache-Control: Stellen Sie sicher, dass der Origin Cache-Control: public, max-age=2592000, immutable für statische Release-Bundles ausliefert.

Schritt 4: Origin-Egress-Metriken verifizieren

Überwachen Sie die Egress-Bandbreite und Operations-Metriken Ihres Origin-Buckets während Lastspitzen:

Bytes Out vs. Client Bytes: Vergleichen Sie die Summe der von Clients heruntergeladenen Gigabytes mit dem Origin-Egress in Gigabyte. In einer funktionierenden Slice-Caching-Architektur macht der Origin-Egress nur einen Bruchteil des gesamten Edge-Egress aus (bei populären Assets typischerweise unter 5-10 %).
HTTP-206-Verhältnis: Stellen Sie sicher, dass die Origin-Logs fast ausschließlich Statuscodes des Typs 206 Partial Content anstelle von 200 OK für vollständige Dateien ausweisen.

Schritt 5: Invalidierungs- und Concurrency-Tests durchführen

Simulieren Sie ein paralleles Release mit einem HTTP-Benchmarking-Tool wie k6 oder wrk. Senden Sie 100 gleichzeitige Requests mit zufälligen Byte-Offsets. Beobachten Sie die Origin-Verbindungen: Die Origin-Requests sollten linear mit den angeforderten eindeutigen Slices skalieren, niemals mit der Gesamtzahl verbundener Clients.

Best Practices für die Bereitstellung großer Assets

Um Latenzen gering und Cloud-Hosting-Kosten planbar zu halten, sollten Sie folgende Best Practices berücksichtigen:

Slice-Grenzen an Upstream-Blockgrößen ausrichten: Cloud-Objektspeicher lesen Daten in festen physischen Blöcken. Wenn Sie Ihre Proxy-Slice-Größe (z. B. 2 MB oder 4 MB) an typische Blockgrößen anpassen, minimieren Sie die I/O-Amplification auf dem Storage-Cluster.
Assets mit Range Caching auf dedizierten Hostnames isolieren: Betreiben Sie Assets mit Slice Caching auf separaten Subdomains (z. B. cdn-assets.example.com statt api.example.com). Dadurch isolieren Sie Cache-Lock-Timeouts, große Disk-Allokationen und Proxy-Memory-Pools vom latenzkritischen JSON-Traffic Ihrer Microservices.
Pre-Warming nur für kritische Slices einsetzen: Sie müssen nicht die gesamte 10-GB-Datei über Ihr globales Edge-Netzwerk vorwärmen. Senden Sie bei Veröffentlichung eines Builds automatisierte Anfragen mit Range: bytes=0-2097151 an Ihre primären Edge-Standorte. Das Vorwärmen der ersten 2 MB sichert eine minimale Time-to-First-Byte (TTFB) für die Nutzer, während nachfolgende Chunks erst bei tatsächlichem Bedarf abgerufen werden.
Request Coalescing auf allen Ebenen erzwingen: Deaktivieren Sie niemals Cache Locks oder Request Coalescing für partiellen Content. Ohne Request Collapsing kann der Cache Stampede eines stark frequentierten Releases die Rate Limits Ihres Origin-Speichers überlasten (wie S3-503-SlowDown-Fehler). Wenn Ihr Team Live-Multiplayer-Services oder komplexe Content-Delivery-Pipelines entwickelt, liefert der Blick auf praxiserprobte Architekturansätze für dedizierte Game-Backends wertvolle Einblicke in das Management von Edge-Workloads und hochvolumigen Assets.

Fazit

Die Auslieferung gigabytegroßer Dateien muss weder zu explodierenden Egress-Kosten noch zu hoher Edge-Latenz führen. Eine naive Verarbeitung von Byte-Ranges verschwendet Origin-Bandbreite, da unnötige Daten geladen oder gecachte Fragmente nicht wiederverwendet werden.

Durch normalisiertes Slice Caching, Request Coalescing und standardisierte Origin-Range-Header verwandeln Sie unberechenbaren Partial-Content-Traffic in eine deterministische, hocheffiziente Streaming-Pipeline.

Die Überprüfung Ihrer Proxy-Konfiguration und das Testen Ihrer Edge-Response-Header sind die effektivsten Maßnahmen, um Egress-Lecks vor dem nächsten Release aufzudecken. Sie überlegen, ob Sie Ihre Infrastruktur intern optimieren oder eine Expertenanalyse für Ihr nächstes Release nutzen möchten? Erfahren Sie, wie wir mit individueller Softwareentwicklung performante, skalierbare und kosteneffiziente Systeme realisieren.

Quelle: Origin Range Requests: Große Dateien ohne Range-Request-Tuning ausliefern