10. Server Scheduling (Server-Planung)

Es ist im Allgemeinen vorteilhaft für HTTP-Server, alle Antworten so früh wie möglich zu senden. Beim Bedienen mehrerer Anfragen über eine einzelne Verbindung kann es jedoch Konkurrenz zwischen Anfragen um Ressourcen wie Verbindungsbandbreite geben. Dieser Abschnitt beschreibt Überlegungen dazu, wie Server die Sendefolge konkurrierender Antworten planen, wenn eine solche Konkurrenz besteht.

Server-Planung ist ein Priorisierungsprozess, der auf vielen Eingaben basiert; Prioritätssignale sind nur eine Form der Eingabe. Faktoren wie Implementierungswahl oder Bereitstellungsumgebung spielen ebenfalls eine Rolle. Jede gegebene Verbindung kann viele dynamische Permutationen haben. Aus diesen Gründen ist es nicht möglich, einen universellen Planungsalgorithmus zu beschreiben. Dieses Dokument bietet einige grundlegende, nicht erschöpfende Empfehlungen dazu, wie Server auf Prioritätsparameter reagieren könnten. Es beschreibt nicht im Detail, wie Server Prioritätssignale mit anderen Faktoren kombinieren. Endpunkte können sich nicht auf eine bestimmte Behandlung basierend auf Prioritätssignalen verlassen. Das Ausdrücken von Priorität ist nur ein Vorschlag.

Es wird empfohlen (RECOMMENDED), dass Server den Dringlichkeitsparameter (Abschnitt 4.1) respektieren, wo möglich, indem sie Antworten höherer Dringlichkeit vor Antworten niedrigerer Dringlichkeit senden.

Der inkrementelle Parameter gibt an, wie Clients ankommende Antwortbytes verarbeiten. Es wird empfohlen (RECOMMENDED), dass Server den inkrementellen Parameter (Abschnitt 4.2) respektieren, wo möglich.

Nicht-inkrementelle Antworten derselben Dringlichkeit sollten (SHOULD) bedient werden, indem Bandbreite in aufsteigender Reihenfolge nach Stream-ID zugewiesen wird, was der Reihenfolge entspricht, in der Clients die Anfragen gestellt haben. Dies stellt sicher, dass Clients die Anforderungsreihenfolge verwenden können, um die Antwortreihenfolge zu beeinflussen.

Inkrementelle Antworten derselben Dringlichkeit sollten (SHOULD) bedient werden, indem Bandbreite zwischen ihnen geteilt wird. Der Nachrichteninhalt inkrementeller Antworten wird verwendet, sobald er in Teilen oder Chunks empfangen wird. Clients könnten mehr davon profitieren, Teile aller solcher Ressourcen zu erhalten, anstatt die Gesamtheit einer einzelnen Ressource. Die Größe des Ressourcenteils, der zur Leistungsverbesserung benötigt wird, variiert. Einige Ressourcentypen platzieren kritische Elemente früh; andere Ressourcen können Informationen progressiv nutzen. Dieses Schema spezifiziert nicht explizit, wie Server Größe, Typ oder andere Eingaben verwenden sollten, um zu entscheiden, wie priorisiert werden soll.

Es kann Szenarien geben, in denen Server mehrere inkrementelle und nicht-inkrementelle Antworten auf derselben Dringlichkeitsstufe planen müssen. Strikte Einhaltung der Planungsrichtlinien basierend auf Dringlichkeit und Anforderungsgenerierungsreihenfolge könnte zu suboptimalen Client-Ergebnissen führen, da frühe nicht-inkrementelle Antworten die Bereitstellung später ausgegebener inkrementeller Antworten blockieren könnten. Folgende Beispiele solcher Herausforderungen:

1. Auf derselben Dringlichkeitsstufe eine nicht-inkrementelle Anfrage für eine große Ressource, gefolgt von einer inkrementellen Anfrage für eine kleine Ressource.

2. Auf derselben Dringlichkeitsstufe eine inkrementelle Anfrage unbestimmter Länge, gefolgt von einer nicht-inkrementellen großen Ressource.

Es wird empfohlen (RECOMMENDED), dass Server solche Verhungerung nach Möglichkeit vermeiden. Die Art und Weise, dies zu tun, ist eine Implementierungsentscheidung. Beispielsweise könnten Server Antworten bestimmter inkrementeller Typen basierend auf anderen Informationen wie der Inhaltsgröße präventiv senden.

Die optimale Planung von Server-Pushes ist schwierig, insbesondere wenn gepushte Ressourcen mit aktiven gleichzeitigen Anfragen konkurrieren. Es gibt viele Faktoren, die Server bei der Planung berücksichtigen können, wie den Typ oder die Größe der gepushten Ressource, die Priorität der Anfrage, die den Push ausgelöst hat, die Anzahl aktiver gleichzeitiger Antworten, die Priorität anderer aktiver gleichzeitiger Antworten usw. Es gibt keine allgemeine Anleitung zur besten Anwendung dieser Faktoren. Zu einfache Server könnten mit zu hoher Priorität pushen und Client-Anfragen blockieren oder mit zu niedriger Priorität pushen und Antworten verzögern, wodurch das beabsichtigte Ziel des Server-Pushes negiert wird.

Prioritätssignale sind ein Faktor bei der Server-Push-Planung. Das Konzept von Parameterwert-Standards gilt etwas anders, da es kein explizites Client-Signal für die anfängliche Priorität gibt. Server können Prioritätssignale anwenden, die in Ursprungsantworten bereitgestellt werden; siehe Zusammenführungsrichtlinien in Abschnitt 8. In Abwesenheit von Ursprungssignalen könnte die Anwendung von Standardparameterwerten suboptimal sein. Was auch immer Server über die Planung gepushter Antworten entscheiden, sie können die erwartete Priorität an Clients signalisieren, indem sie ein Priority-Feld im PUSH_PROMISE- oder HEADERS-Frame einbeziehen.

10.1. Intermediaries with Multiple Backend Connections (Vermittler mit mehreren Backend-Verbindungen)

Ein Vermittler, der eine HTTP-Verbindung bedient, kann Anfragen über mehrere Backend-Verbindungen verteilen. Wenn er Priorisierungsregeln strikt anwendet, können Anfragen niedrigerer Priorität keinen Fortschritt machen, während Anfragen mit höherer Priorität in Bearbeitung sind. Diese Blockierung kann sich auf Backend-Verbindungen ausbreiten, was Peers als Verbindungsstillstand interpretieren könnten. Endpunkte implementieren üblicherweise Schutz gegen Stillstände, wie das abrupte Schließen von Verbindungen nach einer gewissen Zeit. Um die Wahrscheinlichkeit des Auftretens zu verringern, können Vermittler vermeiden, der Prioritätsordnung strikt zu folgen und stattdessen allen von ihnen weitergeleiteten Anfragen eine kleine Menge Bandbreite zuweisen, damit jede im Laufe der Zeit Fortschritte machen kann.

Ähnlich sollten (SHOULD) Server eine gewisse Menge Bandbreite Streams zuweisen, die als Tunnel fungieren.

---