Zusammenfassung

  • Alt-Svc erlaubt einem Ursprung, ein anderes Protokoll, einen anderen Host und Port anzukündigen, über die seine Ressourcen bei unverändertem Ursprungs-URI verfügbar sein können.
  • Eine frische Ankündigung beweist nicht, dass ein bestimmter Client die Alternative erreicht, für den Ursprung authentifiziert, das erwartete Protokoll ausgehandelt oder dort eine Anfrage abgeschlossen hat.
  • Die Clientwahl ist optional, der Netzkontext zählt, und ein Fehlschlag kann einen Rückfall auslösen, dessen Eigenschaften beobachtet werden müssen.
  • Ein Nachweis des Alternativpfads sollte Alter der Ankündigung, Ursprungsidentität, Authentifizierung, ALPN-Ergebnis, Clientwahl, Anfrageergebnis und Rückfall an einem Beobachtungspunkt verbinden.

Man stelle sich einen Dienst mit Alt-Svc: h3=":443"; ma=86400 vor. Ein Rollout-Dashboard sieht den Header am Ursprung und erklärt die HTTP/3-Migration für abgeschlossen. In einem Zugangsnetz lässt sich die alternative Verbindung jedoch nicht herstellen. Clients bleiben unbemerkt auf der bestehenden Ursprungsverbindung, Anfragen gelingen, und die aggregierte Verfügbarkeit bleibt grün. Die Ankündigung war echt, doch für diese Population fand der behauptete Pfadwechsel nicht statt.

Dies ist ein hypothetischer Betriebsablauf, kein gemeldeter Anbieterfehler. Der Mechanismus arbeitet normal. Der Messfehler besteht darin, Wählbarkeit mit Ausführung gleichzusetzen.

Alternatives Routing bewahrt den Ursprung

RFC 7838 definiert HTTP-Alternativdienste, damit Ressourcen eines Ursprungs autoritativ an einem anderen Netzort und gegebenenfalls mit anderer Protokollkonfiguration verfügbar sind. Die Alternative besteht aus Anwendungsprotokoll, Host und Port. Sie ist Routinginformation zum selben Ursprung, keine Weiterleitung auf eine andere URI.

Der Sicherheitskontext bewahrt diese Identität. Software oberhalb des HTTP-Zugriffs sieht weiterhin ursprüngliches Schema, Host und Port. Bei TLS muss die Alternative ein für den Namen des Ursprungs gültiges Zertifikat vorlegen, nicht nur eines für den alternativen Host.

Die Ankündigung beweist diese Authentifizierung nicht. Sie dokumentiert eine Nominierung. Der sichere Nutzungsnachweis beginnt mit der tatsächlich hergestellten Verbindung und der tatsächlich geprüften Identität.

Wählbarkeit, Aushandlung und Nutzung sind getrennte Ereignisse

Alternativdienste sind für Clients optional. Ein Client kann frische Alternativen nach eigenen Kriterien wählen und die bestehende Verbindung weiter nutzen, während er eine neue aufbaut. Die Serverpräferenz ist daher kein Protokoll der Cliententscheidung.

RFC 7301 definiert Application-Layer Protocol Negotiation innerhalb von TLS. RFC 7838 verlangt, die Alternative als fehlgeschlagen zu behandeln, wenn nicht das erwartete Protokoll ausgehandelt wird. Ein erreichbarer Port oder abgeschlossener TLS-Handshake genügt nicht, wenn das angekündigte Anwendungsprotokoll fehlt.

Für HTTP/3 bildet RFC 9114 HTTP-Semantik auf QUIC ab und verwendet den ALPN-Bezeichner h3. h3 in Alt-Svc ist nicht dasselbe wie eine QUIC-Verbindung, ausgehandeltes HTTP/3 und eine abgeschlossene Anfrage. Jeder Übergang braucht eine eigene Messung.

Bei Nutzung kann Alt-Used den alternativen Dienst anzeigen. Ursprung, CDN, Client und synthetische Sonde sehen jedoch verschiedene Teile der Entscheidung. Eine belastbare Aussage nennt ihren Beobachtungspunkt.

Frische ist kein Gesundheitszustand

Alt-Svc besitzt eine eigene Frischezeit. ma steuert, wie lange die Information zum Aufbau neuer Verbindungen genutzt werden kann, getrennt vom üblichen HTTP-Cache. Ein neuer Wert ersetzt gespeicherte Alternativen, clear macht sie ungültig.

Frische bedeutet nur, dass die Ankündigung regelgemäß wählbar bleibt. Sie garantiert weder aktuelle Erreichbarkeit noch einen Pfad aus jedem Clientnetz, QUIC-Zulässigkeit an jeder Richtliniengrenze, Kapazität oder Latenz.

Bei erkanntem Netzwechsel löschen Clients gewöhnlich Alternativen ohne persist=1. Auch eine persistente Ankündigung deutet nur mögliche weitere Nützlichkeit an; sie bescheinigt weder Erreichbarkeit noch Richtlinie des neuen Netzes.

Rückfall bewahrt den Dienst und kann Fehler verdecken

RFC 7838 erlaubt den Rückfall zum Ursprung oder zu einer anderen Alternative, wenn der gewählte Dienst fehlschlägt oder nicht antwortet. Das schützt Verfügbarkeit, kann aber eine gescheiterte Migration verbergen. Eine erfolgreiche Anfrage belegt den gewünschten Pfad nur, wenn der tatsächliche Pfad identifiziert ist.

Der Rückfall kann stärkere Sicherheitseigenschaften verlieren und eine Downgrade-Fläche bilden. Der Nachweis muss festhalten, welche Alternative wie scheiterte, welcher Pfad sie ersetzte, ob das erlaubt war und welche Eigenschaft sich änderte.

Verfügbarkeit, alternative Nutzung und Rückfallsicherheit sind drei verschiedene Kennzahlen. Eine einzige grüne Erfolgsrate vertritt sie nicht.

Schließen Sie die Änderung mit einem Alternativpfad-Nachweis

Eröffnen Sie den Nachweis bei Beobachtung der Ankündigung. Erfassen Sie Ursprung, exakten Alt-Svc-Wert, Antwortquelle, Zeit, berechnetes Alter, ma, persist, Netzkontext und Clientkohorte. Halten Sie fest, ob sie direkt oder aus einem Cache kam und ob ein späterer Wert sie ersetzte oder löschte.

Für jeden Versuch erfassen Sie Host und Port, Authentifizierung des Ursprungsnamens, angebotenes und ausgehandeltes ALPN, Verbindungsergebnis, Auswahlgrund, Anfragestatus, Latenz, verfügbare Alt-Used-Beobachtung und Rückfallpfad. Fehlschläge und Umgehungen erklären, warum eine frische Ankündigung nicht zu Verkehr wurde.

Schließen Sie eine Rollout-Aussage nur für die belegte Population und Zeit. Ankündigung beweist Nominierung, Authentifizierung die Ursprungsautorität, ALPN die Protokollwahl, und die Anfrage Nutzung und Ergebnis. Erst die Verbindung dieser Ereignisse an einem benannten Beobachtungspunkt beweist den Pfad.

Quellen