10. Server Scheduling (Planification du serveur)
Il est généralement bénéfique pour les serveurs HTTP d'envoyer toutes les réponses aussi tôt que possible. Cependant, lors du traitement de plusieurs requêtes sur une seule connexion, il peut y avoir une concurrence entre les requêtes pour des ressources telles que la bande passante de connexion. Cette section décrit les considérations sur la façon dont les serveurs planifient l'ordre d'envoi des réponses concurrentes lorsqu'une telle concurrence existe.
La planification du serveur est un processus de priorisation basé sur de nombreuses entrées ; les signaux de priorité ne sont qu'une forme d'entrée. Des facteurs tels que le choix d'implémentation ou l'environnement de déploiement jouent également un rôle. Toute connexion donnée peut avoir de nombreuses permutations dynamiques. Pour ces raisons, il n'est pas possible de décrire un algorithme de planification universel. Ce document fournit quelques recommandations de base, non exhaustives, sur la façon dont les serveurs pourraient agir sur les paramètres de priorité. Il ne décrit pas en détail comment les serveurs combinent les signaux de priorité avec d'autres facteurs. Les points de terminaison ne peuvent pas dépendre d'un traitement particulier basé sur les signaux de priorité. Exprimer la priorité n'est qu'une suggestion.
Il est recommandé (RECOMMENDED) que les serveurs respectent le paramètre urgency (Section 4.1) dans la mesure du possible, en envoyant les réponses de plus haute urgence avant les réponses de moindre urgence.
Le paramètre incremental indique comment les clients traitent les octets de réponse arrivant. Il est recommandé (RECOMMENDED) que les serveurs respectent le paramètre incremental (Section 4.2) dans la mesure du possible.
Les réponses non incrémentales de même urgence devraient (SHOULD) être servies en allouant la bande passante dans l'ordre croissant par ID de flux, ce qui correspond à l'ordre dans lequel les clients ont fait les requêtes. Ce faisant, cela garantit que les clients peuvent utiliser l'ordre des requêtes pour influencer l'ordre des réponses.
Les réponses incrémentales de même urgence devraient (SHOULD) être servies en partageant la bande passante entre elles. Le contenu du message des réponses incrémentales est utilisé au fur et à mesure qu'il est reçu en parties ou en morceaux. Les clients peuvent bénéficier davantage de la réception de portions de toutes ces ressources plutôt que de l'intégralité d'une seule ressource. La taille de la portion de ressource nécessaire pour améliorer les performances varie. Certains types de ressources placent des éléments critiques tôt ; d'autres ressources peuvent utiliser progressivement les informations. Ce schéma ne spécifie pas explicitement comment les serveurs devraient utiliser la taille, le type ou toute autre entrée pour décider comment prioriser.
Il peut y avoir des scénarios où les serveurs doivent planifier plusieurs réponses incrémentales et non incrémentales au même niveau d'urgence. Le respect strict des directives de planification basées sur l'urgence et l'ordre de génération des requêtes pourrait entraîner des résultats sous-optimaux pour le client, car les réponses non incrémentales précoces pourraient bloquer le service des réponses incrémentales émises plus tard. Voici des exemples de tels défis :
-
Au même niveau d'urgence, une requête non incrémentale pour une grande ressource suivie d'une requête incrémentale pour une petite ressource.
-
Au même niveau d'urgence, une requête incrémentale de longueur incertaine suivie d'une grande ressource non incrémentale.
Il est recommandé (RECOMMENDED) que les serveurs évitent une telle famine dans la mesure du possible. Le moyen de le faire est une décision d'implémentation. Par exemple, les serveurs pourraient envoyer de manière préventive des réponses de certains types incrémentaux basés sur d'autres informations telles que la taille du contenu.
La planification optimale des push de serveur est difficile, en particulier lorsque les ressources poussées sont en concurrence avec les requêtes concurrentes actives. Il existe de nombreux facteurs que les serveurs peuvent prendre en compte lors de la planification, tels que le type ou la taille de la ressource poussée, la priorité de la requête qui a déclenché le push, le nombre de réponses concurrentes actives, la priorité d'autres réponses concurrentes actives, etc. Il n'y a pas de conseils généraux sur la meilleure façon d'appliquer ces éléments. Des serveurs trop simples pourraient pousser à une priorité trop élevée et bloquer les requêtes des clients ou pousser à une priorité trop faible et retarder les réponses, niant l'objectif visé du push de serveur.
Les signaux de priorité sont un facteur dans la planification des push de serveur. Le concept de valeurs par défaut des paramètres s'applique quelque peu différemment, car il n'y a pas de signal client explicite pour la priorité initiale. Les serveurs peuvent appliquer les signaux de priorité fournis dans les réponses d'origine ; voir les directives de fusion données dans la Section 8. En l'absence de signaux d'origine, l'application de valeurs de paramètres par défaut pourrait être sous-optimale. Quelle que soit la décision des serveurs concernant la planification des réponses poussées, ils peuvent signaler la priorité attendue aux clients en incluant un champ Priority dans la trame PUSH_PROMISE ou HEADERS.
10.1. Intermediaries with Multiple Backend Connections (Intermédiaires avec plusieurs connexions backend)
Un intermédiaire desservant une connexion HTTP peut répartir les requêtes sur plusieurs connexions backend. Lorsqu'il applique strictement les règles d'ordonnancement de priorité, les requêtes de priorité inférieure ne peuvent pas progresser tandis que les requêtes de priorité supérieure sont en cours. Ce blocage peut se propager aux connexions backend, que les pairs peuvent interpréter comme un blocage de connexion. Les points de terminaison implémentent généralement une protection contre les blocages, comme la fermeture brutale des connexions après un certain délai. Pour réduire la probabilité que cela se produise, les intermédiaires peuvent éviter de suivre strictement l'ordre de priorité et allouer plutôt une petite quantité de bande passante à toutes les requêtes qu'ils transmettent afin que chacune puisse progresser au fil du temps.
De même, les serveurs devraient (SHOULD) allouer une certaine quantité de bande passante aux flux agissant comme des tunnels.