13. Fairness (Fairness)
Typischerweise verlassen sich HTTP-Implementierungen auf den zugrunde liegenden Transport, um Fairness zwischen Verbindungen aufrechtzuerhalten, die um Bandbreite konkurrieren. Wenn ein Vermittler HTTP-Anfragen auf einer Client-Verbindung empfängt, leitet er sie an Backend-Verbindungen weiter. Je nachdem, wie der Vermittler Anfragen über verschiedene Backend-Verbindungen zusammenführt oder aufteilt, können verschiedene Clients unterschiedliche Leistungen erfahren. Diese Varianz kann verstärkt werden, wenn der Vermittler beim Weiterleiten von Anfragen auch Prioritätssignale verwendet. Die Abschnitte 13.1 und 13.2 diskutieren Abschwächungen für diese Verstärkung von Unfairness.
Umgekehrt diskutiert Abschnitt 13.3, wie ein Server bestimmten Verbindungen absichtlich ungleiche Bandbreite basierend auf Prioritätssignalen zuweisen kann.
13.1. Coalescing Intermediaries (Zusammenführende Vermittler)
Wenn ein Vermittler HTTP-Anfragen von mehreren Clients in eine HTTP/2- oder HTTP/3-Verbindung zu einem Backend-Server zusammenführt, können Anfragen, die von einem Client stammen, Signale tragen, die eine höhere Priorität als Anfragen von anderen Clients anzeigen.
Es ist manchmal vorteilhaft für Server, die hinter Vermittlern laufen, Priority-Header-Feldwerte zu befolgen. Beispielsweise könnte ein ressourcenbeschränkter Server die Übertragung von Software-Update-Dateien mit einer Hintergrund-Dringlichkeitsstufe (7) aufschieben. Im schlimmsten Fall könnte jedoch die Asymmetrie zwischen den von mehreren Clients deklarierten Prioritäten dazu führen, dass alle Antworten, die für einen User-Agent bestimmt sind, verzögert werden, bis alle Antworten, die für einen anderen User-Agent bestimmt sind, vollständig gesendet wurden.
Um dieses Fairness-Problem zu mildern, können Server Wissen über Vermittler als weitere Eingabe in ihre Priorisierungsentscheidungen verwenden. Wenn ein Server beispielsweise weiß, dass der Vermittler Anfragen zusammenführt, kann er vermeiden, Antworten vollständig bereitzustellen, und stattdessen Bandbreite zuweisen (z. B. in Round-Robin-Manier). Dies kann funktionieren, wenn die eingeschränkte Ressource die Netzwerkkapazität zwischen dem Vermittler und den User-Agents ist, da der Vermittler Antworten puffert und Chunks gemäß dem von ihm implementierten Priorisierungsschema weiterleitet.
Ein Server kann durch Konfiguration bestimmen, dass eine Anfrage von einem Vermittler kam, oder er kann überprüfen, ob die Anfrage eines der folgenden Header-Felder enthält:
-
Forwarded [FORWARDED], X-Forwarded-For
-
Via (siehe Abschnitt 7.6.3 von [HTTP])
13.2. HTTP/1.x Back Ends (HTTP/1.x-Backends)
Es ist üblich, dass Content Delivery Network (CDN)-Infrastruktur unterschiedliche HTTP-Versionen am Front-End und Back-End unterstützt. Beispielsweise könnte ein clientseitiger Edge HTTP/2 und HTTP/3 unterstützen, während die Kommunikation mit Backend-Servern über HTTP/1.1 erfolgt. Im Gegensatz zur Verbindungszusammenführung "demultiplext" ein CDN Anfragen zu diskreten Verbindungen zu Backends. HTTP/1.1 (oder früher) unterstützt kein Response-Multiplexing innerhalb einer einzelnen Verbindung, daher gibt es kein Fairness-Problem. Backend-Server können (MAY) jedoch weiterhin Client-Header für die Anforderungsplanung verwenden. Backend-Server sollten (SHOULD) nur dann auf der Grundlage von Client-Prioritätsinformationen planen, wenn diese Informationen auf einen einzelnen End-Client beschränkt werden können. Authentifizierung und andere Sitzungsinformationen können diese Verknüpfbarkeit bereitstellen.
13.3. Intentional Introduction of Unfairness (Absichtliche Einführung von Unfairness)
Es ist manchmal vorteilhaft, die Übertragung einer Verbindung relativ zu anderen zu depriorisieren, in dem Wissen, dass dies ein gewisses Maß an Unfairness zwischen Verbindungen und daher zwischen den auf diesen Verbindungen bedienten Anfragen einführt.
Beispielsweise könnte ein Server einen Scavenger-Staukontroller auf Verbindungen verwenden, die nur Antworten mit Hintergrundpriorität tragen (z. B. Software-Update-Images). Dies verbessert die Reaktionsfähigkeit anderer Verbindungen auf Kosten einer verzögerten Bereitstellung von Updates.