Transloadit

Was ist CDN-Caching?

CDN-Caching speichert Kopien von Inhalten an geografisch verteilten Edge-Standorten. Anfragen können so nahe bei ihren Empfängern beantwortet werden, ohne dieselbe Repräsentation wiederholt vom Origin-Server abzurufen.

So funktioniert CDN-Caching

Ein CDN ordnet eine Anfrage einem Edge-Standort zu und versucht, ein dort oder in einem zwischengeschalteten Shield-Cache gespeichertes Objekt wiederzuverwenden. Bei einem Cache-Miss ruft das Netzwerk die Repräsentation von einem vorgelagerten Cache oder Origin-Server ab und speichert sie anschließend gemäß den Regeln für Aktualität und Cache-Eignung. Jeder Standort füllt seinen eigenen Cache. Deshalb kann ein Objekt in einer Region bereits im Cache liegen und in einer anderen noch einen Cache-Miss verursachen. Ein selten angefragtes Objekt kann vor Ablauf seiner Gültigkeit verdrängt werden. Bei Medien können unveränderliche Segmente und abgeleitete Varianten lange Gültigkeitsdauern erhalten. Manifeste und Antworten, die von einer Autorisierung abhängen, erfordern dagegen meist kürzere Gültigkeitsdauern oder eine gezieltere Behandlung.

Wichtige Fakten

  1. Das Manifest eines Streams und seine Mediensegmente benötigen unterschiedliche Gültigkeitsdauern. Bei HLS wird eine Live-Medienplaylist etwa einmal pro Zieldauer durch eine neue Version mit mindestens einem neuen Segment ersetzt. RFC 8216 verlangt dies frühestens nach der Hälfte und spätestens nach dem Eineinhalbfachen dieser Dauer. Ein Edge, der die Playlist länger behält, verbirgt daher neue Segmente vor den Playern. Eine mit VOD gekennzeichnete Playlist darf sich nicht ändern und kann wie eine statische Datei zwischengespeichert werden. Segmente werden getrennt von der Playlist abgerufen, jeweils unter einer eigenen URL oder als Bytebereich einer größeren Datei. Sie können lange Gültigkeitsdauern erhalten, sofern der Packager die Bytes unter einer veröffentlichten URL niemals ändert. Die Spezifikation selbst garantiert dies nicht. Der Entwurf von Apple für die zweite Ausgabe von HLS empfiehlt in seinem Serverprofil für niedrige Latenz, gewöhnliche Playlist-Antworten für die halbe Zieldauer zwischenzuspeichern und die Gültigkeitsdauer mit Cache-Control mitzuteilen.
  2. Der Cache-Schlüssel bestimmt, welche Anfragen denselben Eintrag nutzen. Seine Voreinstellung unterscheidet sich je nach CDN. Bei Amazon CloudFront besteht der Standardschlüssel aus dem Domainnamen der Distribution und dem URL-Pfad, ohne Abfragezeichenfolgen, Header oder Cookies. Bei Cloudflare umfasst er Schema, Host und Pfad samt Abfragezeichenfolge sowie den Header Origin der Anfrage. Deshalb wird dieselbe URL beim Abruf mit und ohne Origin getrennt gespeichert. Google Cloud CDN verwendet für Backend-Dienste den vollständigen Anfrage-URI. Anfragen nutzen denselben Eintrag, wenn ihre Schlüssel identisch sind. Das kann bereits durch eine Voreinstellung geschehen: Bei CloudFront erhalten URLs, die sich nur in der Abfragezeichenfolge unterscheiden, standardmäßig dieselbe zwischengespeicherte Antwort. Nehmen Sie jeden Anfragewert, der die Antwort verändert, in den Schlüssel auf und lassen Sie alle anderen weg. Denn eine Komponente, die zwischen Anfragen variiert, ohne die Antwort zu verändern, teilt den Cache auf und senkt die Trefferquote.
  3. Ermitteln Sie bei großen Dateien, wie das CDN Anfragen mit Range behandelt, denn dies beeinflusst die Last am Origin-Server und das Sprungverhalten bei der Wiedergabe. CloudFront leitet eine Anfrage nach einem nicht zwischengespeicherten Bereich an den Origin-Server weiter, fordert dabei möglicherweise einen größeren Bereich an und speichert den zurückgegebenen Teil im Cache. Unterstützt der Origin-Server keine Bereichsanfragen, empfängt CloudFront das gesamte Objekt und speichert es im Cache. Google Cloud CDN füllt seinen Cache mit eigenen Byte-Bereichsanfragen, sobald es erfasst hat, dass der Origin-Server diese unterstützt. Dafür sind Accept-Ranges: bytes, eine bekannte Gesamtlänge sowie sowohl Last-Modified als auch ein starker ETag erforderlich. Fehlt diese Unterstützung am Origin-Server, gilt eine deutlich niedrigere maximal zwischenspeicherbare Größe. Fastly speichert große Objekte nur dann in Teilen im Cache, wenn Segmented Caching aktiviert ist. Ein Origin-Server, der Bereichsanfragen korrekt beantwortet, ist daher eine Voraussetzung dafür, große Medien in Teilen zwischenzuspeichern.
  4. Ob eine Antwort für das Caching infrage kommt, wird unabhängig davon entschieden, wie lange sie frisch bleibt. Die Regel ist anbieterspezifisch. Cloudflare speichert Inhalte standardmäßig anhand der Dateiendung im Cache und speichert HTML oder JSON nur mit einer entsprechenden Regel. Der Standardmodus von Google Cloud CDN speichert statische Inhaltstypen anhand von Content-Type im Cache und benötigt für HTML und JSON explizite Anweisungen. Eine Antwort, die ein Cookie setzt, wird von Google Cloud CDN nicht zwischengespeichert. Cloudflare speichert sie je nach Konfiguration entweder ebenfalls nicht oder entfernt das Cookie und speichert die Antwort im Cache. Bleibt ein erwarteter Cache-Treffer aus, lesen Sie den vom CDN gemeldeten Cache-Status: Bei Cloudflare zeigt der Antwort-Header CF-Cache-Status den Wert MISS, wenn die Antwort für das Caching infrage kam, aber nicht in diesem Cache lag, BYPASS, wenn die Antwort des Origin-Servers nicht zwischengespeichert werden konnte, und DYNAMIC, wenn die Anfrage von Anfang an nicht für das Caching infrage kam.

Wann CDN-Caching wichtig ist

Konfigurieren Sie CDN-Caching, um die Latenz bei Medien zu senken, den Origin-Server zu entlasten und Lastspitzen abzufangen. Ungeeignete Cache-Schlüssel oder Frischeregeln können dazu führen, dass falsche Varianten ausgeliefert werden oder Nutzer veraltete Inhalte erhalten.

So hilft Transloadit beim CDN-Caching

Transloadits Smart CDN schaltet der Verarbeitung auf Abruf einen CDN-Cache vor. Anfragen an eine URL unter tlcdn.com werden vom Robot /tlcdn/deliver beantwortet, der Ergebnisse zwischenspeichert und von Edge-Standorten ausliefert. Bei einem Cache-Miss wird die Assembly für das Template ausgeführt. Bei einem Cache-Treffer antwortet der Edge-Knoten, ohne etwas auszuführen. Die vom Robot /file/serve gesendeten Werte für Cache-Control legen fest, wie lange ein zwischengespeichertes Ergebnis frisch bleibt.

Die erste Anfrage für eine URL, die noch nicht im Cache liegt, umfasst die Zeit für den Abruf der Quelldaten und die Verarbeitung. Die aktuellen Standardlebensdauern stehen auf der Seite zu /file/serve und werden hier nicht wiederholt, da sie sich ändern können.

Entdecken Sie Transloadits Möglichkeiten zur Auslieferung

Quellen

Machen Sie aus Medienwissen eine funktionierende Pipeline

Verbinden Sie Uploads, Verarbeitung, KI, Storage und Auslieferung über eine deklarative API – um Encoding-Stack, Skalierung und ständig wechselnde Formate müssen Sie sich nicht selbst kümmern.

Transloadit kostenlos ausprobieren