Was sind Origin-Server?

Origin-Server speichern oder erzeugen die maßgebliche Version von Inhalten. Caches und Content Delivery Networks rufen diese Inhalte vom Origin-Server ab, wenn sie eine Anfrage nicht lokal beantworten können.

HTTP definiert einen Origin-Server als ein Programm, das maßgebliche Antworten für eine bestimmte Zielressource erzeugen kann. In einer Auslieferungsarchitektur ist er das vorgelagerte System, das ein CDN oder Reverse Proxy kontaktiert, wenn keine gespeicherte Antwort zur Wiederverwendung vorliegt: ein Objektspeicher, ein Webserver, ein Packager, der Manifeste zusammenstellt, oder ein Dienst, der auf Anfrage abgeleitete Varianten erzeugt. Für den Client erscheint das CDN selbst als Origin-Server. HTTP bezeichnet einen solchen Vermittler als Gateway oder Reverse Proxy. Gültigkeitsdauern, Validatoren, Cache-Schlüssel und die Unterstützung von Bereichsanfragen bestimmen, wie viele Anfragen den Origin-Server erreichen. Ein häufig angefragtes Objekt, das abläuft oder noch nie gecacht wurde, kann diese Anfragen dort bündeln. Der Begriff hat nichts mit einem Web-Ursprung zu tun, also der Kombination aus Schema, Host und Port, die Browser für die Same-Origin-Policy und CORS verwenden.

Muss jedes abgelaufene Objekt erneut vom Origin-Server heruntergeladen werden? Nicht, wenn der Origin-Server Validatoren sendet. Ein Cache mit einer veralteten Antwort kann eine bedingte Anfrage anhand des gespeicherten Werts von ETag (in If-None-Match) oder des gespeicherten Datums von Last-Modified (in If-Modified-Since) stellen. Bei unverändertem Inhalt antwortet der Origin-Server mit 304 (Not Modified), ohne die Repräsentation erneut zu senden. Der Origin-Server muss weiterhin jede Validierungsanfrage empfangen und beantworten, die an ihn weitergeleitet wird. Validatoren reduzieren also die übertragenen Bytes, allein jedoch nicht die Anzahl der Anfragen.
Wie verhindere ich, dass viele Edge-Standorte jeweils dasselbe Objekt abrufen? Leiten Sie ihre Anfragen bei Cache-Misses über eine gemeinsame Cache-Ebene vor dem Origin-Server. Ohne diese Ebene kann jeder Cache-Standort bei einem Cache-Miss eine eigene Anfrage für denselben Inhalt senden. Amazon CloudFront Origin Shield, das Shielding von Fastly und Cloudflare Smart Tiered Cache leiten diese Anfragen alle über eine festgelegte übergeordnete Ebene. Die Topologie Generic Global von Cloudflare wählt übergeordnete Ebenen dagegen aus regionalen Pools aus. CloudFront und Fastly fassen außerdem gleichzeitige Anfragen für dasselbe nicht gecachte Objekt zusammen, sodass im günstigsten Fall nur eine Anfrage an den Origin-Server entsteht. Fastly nennt eine Einschränkung: Stellt sich heraus, dass die Antwort nicht gecacht werden kann, etwa weil sie nur für einen einzelnen Nutzer bestimmt ist, muss jede wartende Anfrage anschließend einzeln an den Origin-Server gesendet werden. AWS zufolge eignet sich Origin Shield möglicherweise nicht für dynamische Inhalte, die per Proxy an den Origin-Server weitergeleitet werden, für Inhalte mit geringer Cache-Eignung oder für selten angefragte Inhalte. Origin Shield wird separat berechnet.
Was erhalten Zuschauer, während der Origin-Server ausgefallen ist? Antworten, die in einem Cache noch frisch sind, werden weiterhin ausgeliefert. Für veraltete Antworten gilt laut HTTP: Ein Cache darf sie nur ausliefern, wenn er keine Verbindung hat oder dies ausdrücklich erlaubt wurde. Er darf sie überhaupt nicht ausliefern, wenn die Antwort no-cache oder must-revalidate enthält oder, bei einem gemeinsam genutzten Cache wie einem CDN, proxy-revalidate oder s-maxage. Wenn keine dieser Direktiven greift, erlaubt die Direktive stale-if-error aus RFC 5861 die Auslieferung, wenn der Origin-Server 500, 502, 503 oder 504 zurückgibt oder nicht erreichbar ist. Ihr Wert begrenzt, wie lange die Antwort veraltet sein darf, gerechnet ab ihrem Ablauf und nicht ab Beginn des Ausfalls: Mit max-age=600, stale-if-error=1200 kann die Antwort im Fehlerfall noch verwendet werden, bis sie insgesamt 1800 Sekunden alt ist. Für geplante Wartungsarbeiten muss der Wert die Zeit seit dem Ablauf plus die Ausfalldauer abdecken. Das Verhalten von CDNs unterscheidet sich im Detail: CloudFront dokumentiert, dass es stale-if-error anwendet, wenn der Origin-Server nicht erreichbar ist oder einen 5xx-Status zurückgibt. Dabei gilt der kleinere Wert aus dem Wert der Direktive und der maximalen TTL. Ohne die Direktive liefert CloudFront ein noch gespeichertes, abgelaufenes Objekt weiterhin aus, wenn der Origin-Server einen 5xx-Status zurückgibt. Keine Einstellung hilft bei einem Objekt, das nie im Cache lag oder nicht mehr gespeichert ist. CloudFront weist außerdem darauf hin, dass es ein selten angefragtes Objekt möglicherweise aus dem Cache entfernt, während der Origin-Server weiterhin ausgefallen ist.
Kann ein korrekt arbeitender Origin-Server über ein CDN trotzdem die falsche Variante ausliefern? Ja, wenn die Antwort von etwas abhängt, das der Cache-Schlüssel nicht berücksichtigt. HTTP legt zwei Regeln fest: Eine gespeicherte Antwort mit einem Header namens Vary darf nur für Anfragen wiederverwendet werden, deren dort benannte Header-Felder übereinstimmen. Außerdem darf ein gemeinsam genutzter Cache die Antwort auf eine Anfrage mit Authorization nur wiederverwenden, wenn die Antwort dies ausdrücklich erlaubt. Ein CDN setzt die Regel für Vary nicht unbedingt wie beschrieben um: Cloudflare dokumentiert, dass es Werte von Vary standardmäßig nicht bei Cache-Entscheidungen berücksichtigt und sie nur für Vary: Accept-Encoding oder bei konfigurierter Vary-Einstellung beachtet. Prüfen Sie deshalb, ob Ihr CDN die in Vary benannten Header berücksichtigt, oder nehmen Sie diese selbst in den Cache-Schlüssel auf. Dasselbe gilt für alle anderen Eingaben, die die Antwort verändern, etwa ein Cookie oder einen Abfrageparameter, den das CDN laut Konfiguration ignoriert: Nehmen Sie die jeweilige Eingabe in den Cache-Schlüssel auf oder kennzeichnen Sie die Antwort als nicht cachebar.
Können Clients das CDN umgehen und den Origin-Server direkt anfragen? Das ist möglich, wenn der Origin-Server öffentlich erreichbar ist und seine Adresse bekannt wird. Dabei werden der Cache und die Schutzmaßnahmen des CDNs umgangen. Cloudflare nennt folgende Optionen: nur die IP-Bereiche des CDNs zulassen, was Cloudflare als mäßig sicher und anfällig für IP-Spoofing einstuft; einen geheimen Anfrage-Header verlangen; das CDN mit einem TLS-Clientzertifikat authentifizieren (Authenticated Origin Pulls); oder einen Tunnel nutzen, der ausschließlich ausgehende Verbindungen aufbaut, sodass der Origin-Server keine öffentlich routbare Adresse hat. Für Amazon S3 als Origin-Server nennt AWS drei Aufgaben: eine CloudFront-Ursprungszugriffssteuerung erstellen, die Anfragen von CloudFront an den Bucket signiert, und sie der Distribution zuordnen; ihr Leseberechtigung für die Dateien erteilen, was die Dokumentation mit einer auf diese Distribution beschränkten Bucket-Richtlinie umsetzt; und allen anderen die Berechtigung entziehen, Dateien über Amazon S3-URLs zu lesen. Das Signieren allein lässt einen öffentlich lesbaren Bucket weiterhin erreichbar.

Konfigurieren Sie einen Origin-Server so, dass er nur die vom CDN benötigten Dateien und Vorgänge zugänglich macht. Ein langsamer oder ausgefallener Origin-Server verzögert Anfragen bei Cache-Misses, Revalidierungen und die Auslieferung nicht cachebarer Inhalte, weil Edge-Caches diese Anfragen nicht lokal beantworten können. Objekte, die im Edge-Cache noch frisch sind, können weiterhin ausgeliefert werden.

Mit dem Smart CDN von Transloadit gibt es zwei vorgelagerte Ebenen. Ihre Originaldateien bleiben in Ihrem eigenen Speicher, etwa einem Amazon-S3-Bucket, und ein Template importiert sie von dort. Wenn das CDN für eine angefragte URL keine Kopie im Cache hat, führt Transloadit das Template aus. Der Robot /file/serve übergibt das Ergebnis an das CDN. Damit übernimmt die Template-Ausführung für tlcdn.com die Rolle des Origin-Servers, und Ihr Bucket ist die dahinterliegende Quelle. /file/serve setzt in dieser Antwort den Header Cache-Control; der zugehörige Parameter cache_duration legt sowohl max-age als auch s-maxage fest. Das bestimmt, wie oft Anfragen wieder das Template und Ihren Speicher erreichen.

Die Dokumentation zu /file/serve rät von der Nutzung ohne vorgeschaltetes CDN ab, weil jede Anfrage ohne Cache-Treffer die Transformation erneut ausführen würde. Die hier verlinkten Seiten beschreiben nicht, was ausgeliefert wird, wenn Ihr Speicher bei einem Cache-Miss nicht erreichbar ist, oder ob ein abgelaufenes Ergebnis weiterhin ausgeliefert werden kann.

Entdecken Sie Transloadits Möglichkeiten zur Auslieferung

Was sind Origin-Server?

So funktionieren Origin-Server

Wichtige Fakten

Wann Origin-Server wichtig sind

So hilft Transloadit bei Origin-Servern

Quellen

Machen Sie aus Medienwissen eine funktionierende Pipeline