1. Introduction
1. Introduction
Viele Anwendungen auf mobilen und eingebetteten Geräten benötigen dauerhaften Netzwerkzugang, damit Ereignisse in Echtzeit (z. B. Anrufe oder Nachrichten) zeitnah zugestellt (oder „gepusht") werden können. Diese Geräte haben oft begrenzte Energiereserven; effizientere Erfüllung der Anforderungen nützt dem gesamten Ökosystem.
Ein wesentlicher Energieverbraucher ist das Funkmodul. Funkkommunikation beansprucht einen großen Teil des Energiebudgets.
Unkoordinierte Nutzung persistenter Verbindungen oder Sitzungen durch mehrere Anwendungen kann die Funknutzung unnötig erhöhen, da jede Sitzung eigenen Overhead verursacht. Insbesondere Keep-Alive-Verkehr gegen vorzeitiges Timeout in Middleboxes kann erhebliche Verschwendung bedeuten. Langfristig dominiert Wartungsverkehr, da Ereignisse selten sind.
Die Bündelung aller Echtzeitereignisse in einer Sitzung verbessert die Nutzung von Netz- und Funkressourcen. Ein Dienst bündelt alle Ereignisse und verteilt sie bei Eintreffen an Anwendungen. Es wird nur eine Sitzung benötigt, doppelter Overhead entfällt.
Die W3C Push API [API] beschreibt eine API für konsolidierte Push-Dienste in Webanwendungen. Dieses Dokument ergänzt dies durch ein Protokoll zum:
-
Anfordern der Zustellung einer Push-Nachricht an einen User Agent,
-
Erstellen neuer Push-Abonnements und
-
Überwachen neuer Push-Nachrichten.
Eine standardisierte Zustellung ist besonders für die W3C Push API wichtig, da Anwendungsserver mehrere Push-Dienste nutzen können. Abonnement-, Verwaltungs- und Überwachungsfunktionen werden derzeit proprietär erfüllt; das genügt, bietet aber keine Vorteile der Standardisierung.
Dieses Dokument beschreibt absichtlich keine Auffindung von Push-Diensten; dies bleibt künftiger Arbeit vorbehalten. User Agents werden mit einer Push-Service-URL konfiguriert erwartet.
1.1. Conventions and Terminology
Die Schlüsselwörter „MUST", „MUST NOT", „REQUIRED", „SHALL", „SHALL NOT", „SHOULD", „SHOULD NOT", „RECOMMENDED", „MAY" und „OPTIONAL" sind wie in [RFC2119] beschrieben zu interpretieren.
Folgende Begriffe werden definiert:
application: sowohl Sender als auch Endverbraucher von Push-Nachrichten. Viele Anwendungen haben Komponenten auf dem User Agent und auf Servern.
application server: die Komponente, die üblicherweise auf einem Server läuft und die Zustellung einer Push-Nachricht anfordert.
push message subscription: ein Nachrichtenzustellungskontext zwischen User Agent und Push-Dienst, der mit dem Anwendungsserver geteilt wird. Alle Push-Nachrichten gehören zu einem Abonnement.
push message subscription set: ein Kontext, der mehrere Abonnements in einer Menge sammelt.
push message: eine Nachricht vom Anwendungsserver über den Push-Dienst an den User Agent.
push message receipt: eine Zustellbestätigung vom Push-Dienst an den Anwendungsserver.
push service: ein Dienst, der Push-Nachrichten an User Agents liefert.
user agent: Gerät und Software als Empfänger von Push-Nachrichten.
Beispiele nutzen HTTP/1.1 [RFC7230]. Viele Abläufe sind mit HTTP/1.1 möglich: Abonnement (Abschnitt 4), Zustellungsanforderung (5), Ersetzen (5.4), Bestätigung (6.2). Wo HTTP/2 Server Push nötig ist, wird das Frame-Format aus [RFC7540] verwendet: Empfang (6), Empfang für Abonnementmengen (6.1), Empfang von Quittungen (6.3).
Alle Beispiele nutzen HTTPS auf Port 443 statt des registrierten Ports 1001. Ein Push-Dienst kann HTTP Alternative Services [RFC7838] nutzen (siehe Abschnitt 3); in Beispielen erscheint dies ggf. als Alt-Used [RFC7838].
Beispiele enthalten keine verpflichtenden Verfahren für Verschlüsselung oder Authentifizierung des Anwendungsservers. [VAPID] und [ENCRYPT] zeigen den Ansatz der W3C Push API [API].