13. Fairness (Équité)
En règle générale, les implémentations HTTP dépendent du transport sous-jacent pour maintenir l'équité entre les connexions en concurrence pour la bande passante. Lorsqu'un intermédiaire reçoit des requêtes HTTP sur une connexion client, il les transmet aux connexions backend. Selon la façon dont l'intermédiaire fusionne ou divise les requêtes entre différentes connexions backend, différents clients peuvent connaître des performances différentes. Cette variance peut être amplifiée si l'intermédiaire utilise également des signaux de priorité lors de la transmission des requêtes. Les Sections 13.1 et 13.2 discutent des atténuations pour cette amplification de l'inéquité.
À l'inverse, la Section 13.3 discute de la façon dont un serveur peut intentionnellement allouer une bande passante inégale à certaines connexions sur la base de signaux de priorité.
13.1. Coalescing Intermediaries (Intermédiaires de fusion)
Lorsqu'un intermédiaire fusionne des requêtes HTTP de plusieurs clients en une connexion HTTP/2 ou HTTP/3 vers un serveur backend, les requêtes provenant d'un client peuvent porter des signaux indiquant une priorité plus élevée que les requêtes d'autres clients.
Il est parfois bénéfique pour les serveurs fonctionnant derrière des intermédiaires d'obéir aux valeurs du champ d'en-tête Priority. Par exemple, un serveur à ressources limitées pourrait différer la transmission de fichiers de mise à jour logicielle avec un niveau d'urgence en arrière-plan (7). Cependant, dans le pire des cas, l'asymétrie entre les priorités déclarées par plusieurs clients pourrait entraîner le retard de toutes les réponses destinées à un agent utilisateur jusqu'à ce que toutes les réponses destinées à un autre agent utilisateur aient été envoyées dans leur intégralité.
Pour atténuer ce problème d'équité, les serveurs peuvent utiliser la connaissance des intermédiaires comme une autre entrée dans leurs décisions de priorisation. Par exemple, si un serveur sait que l'intermédiaire fusionne les requêtes, il peut alors éviter de servir les réponses dans leur intégralité et allouer plutôt la bande passante (par exemple, de manière circulaire). Cela peut fonctionner si la ressource contrainte est la capacité réseau entre l'intermédiaire et les agents utilisateurs, car l'intermédiaire met en mémoire tampon les réponses et transmet les morceaux selon le schéma de priorisation qu'il implémente.
Un serveur peut déterminer qu'une requête provient d'un intermédiaire par configuration, ou il peut vérifier si la requête inclut l'un des champs d'en-tête suivants :
-
Forwarded [FORWARDED], X-Forwarded-For
-
Via (voir Section 7.6.3 de [HTTP])
13.2. HTTP/1.x Back Ends (Backends HTTP/1.x)
Il est courant pour l'infrastructure de réseau de distribution de contenu (CDN) de prendre en charge différentes versions HTTP sur le front-end et le back-end. Par exemple, un edge orienté client peut prendre en charge HTTP/2 et HTTP/3 tandis que la communication avec les serveurs backend est effectuée en utilisant HTTP/1.1. Contrairement à la fusion de connexions, un CDN "démultiplexe" les requêtes vers des connexions discrètes vers les backends. HTTP/1.1 (ou antérieur) ne prend pas en charge le multiplexage des réponses au sein d'une seule connexion, il n'y a donc pas de problème d'équité. Cependant, les serveurs backend peuvent (MAY) toujours utiliser les en-têtes client pour la planification des requêtes. Les serveurs backend devraient (SHOULD) planifier sur la base des informations de priorité client uniquement lorsque ces informations peuvent être limitées à un seul client final. L'authentification et d'autres informations de session peuvent fournir cette liaison.
13.3. Intentional Introduction of Unfairness (Introduction intentionnelle d'inéquité)
Il est parfois bénéfique de déprioriser la transmission d'une connexion par rapport à d'autres, sachant que cela introduit un degré d'inéquité entre les connexions et, par conséquent, parmi les requêtes servies sur ces connexions.
Par exemple, un serveur pourrait utiliser un contrôleur de congestion scavenger sur les connexions qui ne transportent que des réponses de priorité en arrière-plan (par exemple, des images de mise à jour logicielle). Cela améliore la réactivité d'autres connexions au prix du retard de la livraison des mises à jour.