2. HTTP/2 Protocol Overview (Aperçu du protocole HTTP/2)

HTTP/2 fournit un transport optimisé pour la sémantique HTTP. HTTP/2 prend en charge toutes les fonctionnalités principales d'HTTP mais vise à être plus efficace que HTTP/1.1.

HTTP/2 est un protocole de couche application orienté connexion (Connection-Oriented Application-Layer Protocol) qui s'exécute sur une connexion TCP ([TCP]). Le client est l'initiateur de la connexion TCP.

L'unité de protocole de base dans HTTP/2 est une trame (Frame, Section 4.1). Chaque type de trame sert 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 des requêtes (Multiplexing) 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 une réponse bloquée ou bloquée n'empêche pas la progression sur d'autres flux.

L'utilisation efficace du multiplexage dépend du contrôle de flux (Flow Control) et de la priorisation (Prioritization). Le contrôle de flux (Section 5.2) garantit qu'il est possible d'utiliser efficacement les flux multiplexés en limitant les données transmises à ce que le récepteur est capable de gérer. La priorisation (Section 5.3) garantit que les ressources limitées sont utilisées de manière plus efficace. Cette révision d'HTTP/2 déprécie le schéma de signalisation de priorité de [RFC7540].

Étant donné que les champs 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.

Enfin, HTTP/2 ajoute un nouveau mode d'interaction optionnel par lequel un serveur peut pousser des réponses vers un client (Section 8.4). Ceci est destiné à permettre à un serveur d'envoyer de manière spéculative des données à un client que le serveur anticipe que le client aura besoin, échangeant une certaine utilisation du réseau contre un gain de latence potentiel. Le serveur le fait en synthétisant une requête, qu'il envoie en tant que trame PUSH_PROMISE. Le serveur est ensuite capable d'envoyer une réponse à la requête synthétique sur un flux séparé.

2.1. Document Organization (Organisation du document)

La spécification HTTP/2 est divisée en quatre parties :

• Démarrage d'HTTP/2 (Starting HTTP/2, Section 3) couvre comment une connexion HTTP/2 est initiée.

• Les couches de trame (Frame Layer, Section 4) et de flux (Stream Layer, Section 5) décrivent la manière dont les trames HTTP/2 sont structurées et formées en flux multiplexés.

• Les définitions de trame (Frame Definitions, Section 6) et d'erreur (Error Definitions, Section 7) incluent des détails sur les types de trames et d'erreurs utilisés dans HTTP/2.

• Les mappages HTTP (HTTP Mappings, Section 8) et les exigences supplémentaires (Additional Requirements, Section 9) décrivent comment la sémantique HTTP est exprimée en utilisant des trames et des flux.

Bien que certains concepts de couche de trame et de flux soient isolés d'HTTP, cette spécification ne définit pas une couche de trame complètement générique. Les couches de trame et de flux sont adaptées aux besoins d'HTTP.

2.2. Conventions and Terminology (Conventions et terminologie)

Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.

Toutes les valeurs numériques sont en ordre d'octets réseau (Network Byte Order). Les valeurs sont non signées sauf indication contraire. Les valeurs littérales sont fournies en décimal ou hexadécimal selon les cas. Les littéraux hexadécimaux sont préfixés par "0x" pour les distinguer des littéraux décimaux.

Cette spécification décrit les formats binaires en utilisant les conventions décrites dans la section 1.3 de RFC 9000 [QUIC]. Notez que ce format utilise l'ordre d'octets réseau et que les bits de valeur élevée sont listés avant les bits de valeur faible.

Les termes suivants sont utilisés :

client : Le point de terminaison qui initie une connexion HTTP/2. Les clients envoient des requêtes HTTP et reçoivent des réponses HTTP.

connexion (connection) : Une connexion de couche transport entre deux points de terminaison.

erreur de connexion (connection error) : Une erreur qui affecte l'ensemble de la connexion HTTP/2.

point de terminaison (endpoint) : Le client ou le serveur de la connexion.

trame (frame) : La plus petite unité de communication au sein d'une connexion HTTP/2, constituée d'un en-tête et d'une séquence d'octets de longueur variable structurée selon le type de trame.

pair (peer) : Un point de terminaison. Lorsqu'on discute d'un point de terminaison particulier, "pair" fait référence au point de terminaison distant par rapport au sujet principal de discussion.

récepteur (receiver) : Un point de terminaison qui reçoit des trames.

émetteur (sender) : Un point de terminaison qui transmet des trames.

serveur (server) : Le point de terminaison qui accepte une connexion HTTP/2. Les serveurs reçoivent des requêtes HTTP et envoient des réponses HTTP.

flux (stream) : Un flux bidirectionnel de trames au sein de la connexion HTTP/2.

erreur de flux (stream error) : Une erreur sur un flux HTTP/2 individuel.

Enfin, les termes "passerelle (gateway)", "intermédiaire (intermediary)", "proxy" et "tunnel" sont définis dans la section 3.7 de [HTTP]. Les intermédiaires agissent à la fois comme client et serveur à différents moments.

Le terme "contenu (content)" tel qu'il s'applique aux corps de message est défini dans la section 6.4 de [HTTP].

---