Compression HPACK dans HTTP/2 : comment ça fonctionne ?

HTTP/2 réduit la redondance des échanges web en conservant une seule connexion multiplexée entre le client et le serveur. Or, les requêtes transportent souvent les mêmes champs : cookies, méthode, chemin, type de contenu ou agent utilisateur. HPACK, défini par la RFC 7541, est le format sans perte chargé de réduire leur poids. Il intervient après l’établissement de la connexion, généralement négociée avec ALPN dans HTTP/2, et compresse uniquement les en-têtes, jamais le corps des messages.

Pourquoi HTTP/2 compresse les en-têtes avec HPACK

En HTTP/1.1, chaque requête répète fréquemment des en-têtes volumineux. Cela devient coûteux lorsqu’une page charge de nombreuses ressources, même avec des connexions persistantes. HTTP/2 conserve les en-têtes sous forme de blocs transmis dans des trames HEADERS, et éventuellement CONTINUATION ; PUSH_PROMISE peut aussi en contenir. HPACK remplace ces répétitions par des références courtes vers des valeurs déjà connues. Le gain est particulièrement sensible pour les cookies, les en-têtes de cache et les champs communs à de nombreuses requêtes. Il complète la sécurité de transport fournie par TLS lors d’une connexion HTTPS : TLS chiffre les données, tandis que HPACK réduit la taille des en-têtes avant leur envoi.

Les deux mécanismes de compression utilisés par HPACK

L’encodage statique des en-têtes HTTP fréquents

La table statique est un dictionnaire fixe de 61 entrées. Elle contient des champs très courants, tels que :method: GET, :status: 200, content-type ou cache-control. Chaque entrée possède un index connu à l’avance par le client et le serveur. Si une paire nom-valeur correspond exactement à cette table, l’émetteur transmet simplement son index. Lorsque seul le nom est présent, il peut réutiliser ce nom indexé et envoyer uniquement la valeur. Cette table ne change pas : elle apporte un gain immédiat dès la première requête.

La table dynamique construite pendant la connexion

La table dynamique mémorise les en-têtes observés pendant une connexion donnée. Une entrée est une paire nom-valeur, par exemple accept-language: fr-FR ou un cookie stable. Lorsqu’un émetteur choisit l’indexation incrémentale, il envoie le champ puis l’ajoute à cette table. Les deux extrémités construisent ainsi le même dictionnaire au fil des blocs reçus. Les entrées les plus récentes reçoivent les index dynamiques les plus bas. Cette organisation favorise les valeurs répétées à court terme, sans supposer qu’elles resteront utiles pendant toute la session.

Table statique	Fixe, connue avant tout échange, 61 entrées.
Table dynamique	Évolutive, alimentée par les en-têtes indexés durant la connexion.
Référence indexée	Transmet un index au lieu du nom et de la valeur complets.

Comment HPACK encode et transmet un bloc d’en-têtes

Indexation, littéraux et références aux tables

Un bloc HPACK est une suite de représentations d’en-têtes. L’encodeur choisit, pour chaque champ, la forme la plus adaptée :

• champ indexé : référence à une paire nom-valeur existante ;
• littéral avec indexation incrémentale : le champ est transmis puis mémorisé ;
• littéral sans indexation : il est transmis sans modifier la table ;
• littéral jamais indexé : même principe, avec un signal explicite pour les données sensibles.

Le dernier mode convient notamment à authorization, aux cookies ou à un jeton. Il réduit leur persistance dans le contexte de compression. Le décodeur reconstruit chaque champ, applique les ajouts ou suppressions nécessaires, puis remet la liste d’en-têtes à la couche HTTP/2.

Les entiers à longueur variable et la compression des chaînes

Les index, longueurs et paramètres sont codés avec des entiers à longueur variable. Les premiers bits d’un octet servent de préfixe ; si la valeur dépasse ce que ce préfixe peut contenir, des octets de continuation sont ajoutés. Les petits nombres, très fréquents, occupent donc peu de place. Les chaînes littérales peuvent être envoyées telles quelles ou avec le codage Huffman canonique fixe défini par HPACK. Ce codage est particulièrement utile pour des noms et valeurs textuels fréquents. Il ne dépend pas des données précédentes : il complète les tables plutôt qu’il ne les remplace.

Le déroulement d’une requête HTTP/2 avec la table dynamique

Premier envoi : création des entrées réutilisables

Lors d’une première requête vers /images/logo.svg, le client peut référencer :method: GET dans la table statique. En revanche, un cookie ou un champ accept-language propre à la session doit souvent être envoyé littéralement. S’il est susceptible de revenir, l’encodeur l’émet avec indexation incrémentale. Le serveur décode le bloc dans l’ordre reçu et ajoute exactement la même entrée à sa table dynamique. Cette synchronisation est essentielle : un index dynamique n’a de sens que si les deux tables ont le même contenu au même moment.

Requêtes suivantes : références compactes aux entrées existantes

Pour les ressources suivantes, le client peut désigner l’entrée dynamique créée précédemment par un index. Un en-tête potentiellement long devient alors une référence très courte. Le mécanisme est aussi valable dans l’autre sens, par exemple pour des en-têtes de réponse répétés. Les réponses de cache peuvent ainsi conserver des champs récurrents. Le statut 304 Not Modified, dont le rôle est détaillé dans ce guide sur le code HTTP 304, reste un en-tête HTTP normal : HPACK optimise sa représentation, sans changer sa sémantique.

Taille de table, synchronisation et limites de HPACK

Gestion de la mémoire et éviction des anciennes entrées

La taille maximale de la table dynamique est négociée notamment avec SETTINGS_HEADER_TABLE_SIZE. La valeur initiale courante est de 4 096 octets, sauf réglage différent. La taille d’une entrée correspond à la longueur de son nom et de sa valeur, plus 32 octets de surcharge. Quand la limite est dépassée, les entrées les plus anciennes sont évincées. Une entrée trop grande ne peut pas être conservée. L’encodeur peut annoncer une mise à jour de taille avant un bloc d’en-têtes concerné. SETTINGS_MAX_HEADER_LIST_SIZE indique par ailleurs la taille décodée que le pair est disposé à accepter.

Tables séparées selon le sens de communication

Il n’existe pas une table unique pour toute la connexion. Le client maintient un contexte pour les champs qu’il envoie, et le serveur un autre pour les siens. Chaque décodeur doit traiter les blocs dans leur ordre de réception afin de conserver un état identique à celui de l’encodeur. Cette séparation est importante lorsque plusieurs origines utilisent une même connexion sécurisée, situation liée notamment au nom de serveur indiqué par l’extension SNI de TLS. Les implémentations doivent appliquer strictement les règles d’autorité HTTP/2 et de gestion des secrets.

HPACK face à la compression HTTP classique et aux risques de sécurité

Pourquoi les en-têtes ne sont pas compressés avec gzip

Gzip ou deflate sont adaptés aux corps de réponse, mais leur contexte de compression générique et partagé a créé des risques lorsqu’il mélangeait données contrôlées par un attaquant et secrets. HPACK utilise un format déterministe, des tables explicitement gérées et des contextes limités à une direction sur une connexion HTTP/2. Il ne remplace pas Content-Encoding: gzip pour le HTML, le CSS ou JavaScript : les deux mécanismes interviennent sur des parties distinctes du message.

La protection contre les attaques de type CRIME et BREACH

HPACK a été conçu pour limiter les faiblesses associées à CRIME, notamment en évitant une compression TLS générique des en-têtes. Toutefois, la taille compressée peut toujours révéler des informations si un secret et une valeur contrôlée sont combinés dans le même contexte. Le mode « jamais indexé » réduit l’exposition des champs sensibles dans la table dynamique, mais ne constitue pas une protection absolue contre tous les canaux auxiliaires. BREACH vise surtout la compression des corps de réponse : la défense repose aussi sur l’absence de secrets réfléchis dans des contenus compressés et sur des protections applicatives adaptées.

Chiffres clés de HPACK

Repère technique	Valeur et portée
Entrées de la table statique	61 entrées prédéfinies couvrent des noms et paires nom-valeur HTTP fréquents. Elles sont disponibles dès l’ouverture de la connexion, sans apprentissage préalable.
Taille dynamique initiale	4 096 octets constituent la limite par défaut de la table dynamique, sauf valeur différente annoncée par le pair avec SETTINGS_HEADER_TABLE_SIZE.
Calcul de la taille d’une entrée	32 octets de surcharge s’ajoutent à la longueur du nom et de la valeur. Cette règle détermine l’occupation mémoire et l’éviction des entrées anciennes.
Préfixes des entiers	5, 6 ou 7 bits peuvent servir au premier fragment d’un entier, selon la représentation HPACK. Les valeurs plus grandes utilisent des octets de continuation.
Alphabet Huffman fixe	257 symboles composent la table Huffman canonique : les octets possibles et un symbole de fin, partagé par tous les encodeurs et décodeurs HPACK.

Questions courantes

HPACK est-il encore utilisé avec HTTP/3 ?

Non : HTTP/3 utilise QPACK, un format conçu pour fonctionner avec QUIC. HPACK suppose que les blocs d’en-têtes sont traités dans un ordre fiable, ce qui convient à HTTP/2 sur TCP. QPACK évite qu’une perte de paquet bloque inutilement le décodage d’autres flux, grâce à des instructions de table séparées.

Peut-on désactiver la table dynamique HPACK ?

Oui. Un pair peut annoncer une taille de table dynamique nulle via les paramètres HTTP/2. Les en-têtes peuvent alors encore employer la table statique, des littéraux et le codage Huffman, mais aucune nouvelle entrée n’est mémorisée. C’est un compromis entre économie de bande passante et simplicité de gestion.

Les cookies doivent-ils toujours être marqués « jamais indexé » ?

Pas systématiquement, mais les cookies contenant une session, un jeton ou une donnée personnelle doivent être traités avec prudence. Le mode jamais indexé évite de les conserver dans la table dynamique. Des cookies courts et stables peuvent parfois être indexés par une implémentation, selon sa politique de sécurité et son contexte d’utilisation.

Pourquoi une erreur HPACK peut-elle interrompre une connexion HTTP/2 ?

Parce qu’un bloc invalide peut désynchroniser les tables de l’encodeur et du décodeur. Un index inexistant, une chaîne mal formée ou une mise à jour de taille non conforme empêchent de reconstruire de façon fiable les en-têtes suivants. HTTP/2 traite généralement cette situation comme une erreur de compression de connexion, plutôt que comme une simple erreur isolée de requête.

HPACK réduit-il toujours la taille des en-têtes ?

Non. Sur une première requête, avec des valeurs uniques ou aléatoires, l’ajout d’informations de format et d’indexation peut limiter le gain. Le bénéfice apparaît surtout lorsque les mêmes noms ou valeurs reviennent sur plusieurs échanges d’une même connexion. Des en-têtes très variables peuvent être transmis sans indexation pour éviter d’évincer des entrées plus utiles.

HPACK chiffre-t-il les informations d’en-tête ?

Non. HPACK fournit une compression sans perte, pas du chiffrement. Les données restent lisibles par le client et le serveur après décodage. La confidentialité sur le réseau dépend de TLS ; sans protection de transport, les en-têtes compressés ne constituent pas une mesure de sécurité.

L’essentiel à retenir

HPACK rend les échanges HTTP/2 plus sobres en remplaçant les en-têtes répétés par des références vers des tables partagées. Son efficacité repose sur un équilibre : la table statique accélère les cas courants, tandis que la table dynamique valorise les informations réellement réutilisées pendant une connexion. L’ordre de traitement et la synchronisation des contextes sont donc indispensables à un décodage fiable. Cette optimisation ne doit pas être confondue avec une protection cryptographique. TLS assure la confidentialité en transit, alors que le choix entre indexation, absence d’indexation et marquage sensible limite l’exposition de certaines valeurs. Pour une implémentation robuste, il faut surtout encadrer la taille des tables et éviter de mémoriser durablement les secrets.