2. Aperçu du protocole HTTP/2 (HTTP/2 Protocol Overview)
HTTP/2 fournit un transport optimisé (Optimized Transport) pour la sémantique HTTP. HTTP/2 prend en charge toutes les fonctionnalités principales de HTTP/1.1 mais vise à être plus efficace de plusieurs manières.
L'unité de protocole de base dans HTTP/2 est une trame (Frame) (Section 4.1). Chaque type de trame a un objectif différent. Par exemple, les trames HEADERS et DATA forment la base des requêtes et réponses HTTP (Section 8.1) ; d'autres types de trames comme SETTINGS, WINDOW_UPDATE et PUSH_PROMISE sont utilisés pour prendre en charge d'autres fonctionnalités HTTP/2.
Le multiplexage (Multiplexing) des requêtes est réalisé en associant chaque échange requête/réponse HTTP à son propre flux (Stream) (Section 5). Les flux sont largement indépendants les uns des autres, de sorte qu'une requête ou réponse bloquée ou bloquée n'empêche pas la progression sur d'autres flux.
Le contrôle de flux (Flow Control) et la priorisation (Prioritization) garantissent qu'il est possible d'utiliser efficacement les flux multiplexés. Le contrôle de flux (Section 5.2) aide à garantir que seules les données qui peuvent être utilisées par un récepteur sont transmises. La priorisation (Section 5.3) garantit que les ressources limitées peuvent être dirigées vers les flux les plus importants en premier.
HTTP/2 ajoute un nouveau mode d'interaction par lequel un serveur peut pousser des réponses vers un client (Section 8.2). Le push serveur (Server Push) permet à un serveur d'envoyer de manière spéculative des données à un client que le serveur anticipe que le client aura besoin, en échangeant une certaine utilisation du réseau contre un gain potentiel de latence. Le serveur le fait en synthétisant une requête, qu'il envoie sous forme de trame PUSH_PROMISE. Le serveur peut ensuite envoyer une réponse à la requête synthétisée sur un flux séparé.
Étant donné que les champs d'en-tête HTTP utilisés dans une connexion peuvent contenir de grandes quantités de données redondantes, les trames qui les contiennent sont compressées (Section 4.3). Cela a un impact particulièrement avantageux sur les tailles de requête dans le cas courant, permettant de compresser de nombreuses requêtes en un seul paquet.