Voir ci-dessous les différences entre HTTP 1.1 et HTTP 2.0 :
Dans le comportement HTTP traditionnel, lors de multiples requêtes sur la même connexion, le client doit attendre la réponse de chaque requête avant d'envoyer la suivante. Cette approche séquentielle augmente significativement le temps de chargement des ressources d'un site web. Pour résoudre ce problème, HTTP/1.1 a introduit une fonctionnalité appelée pipelining, permettant à un client d'envoyer plusieurs requêtes sans attendre les réponses du serveur. Le serveur, à son tour, répond au client dans le même ordre qu'il a reçu les requêtes.
Bien que le pipelining semblait être une solution, il a rencontré des défis :
Dans un effort pour optimiser le chargement des pages depuis les serveurs prenant en charge HTTP/1.1, les navigateurs web ont mis en place une solution. Ils ouvrent six à huit connexions parallèles au serveur, permettant la transmission simultanée de plusieurs requêtes. Ce parallélisme vise à atténuer les problèmes associés au pipelining et à améliorer les temps de chargement des pages.
Le choix de six à huit connexions parallèles par les navigateurs web est basé sur des considérations d'optimisation. Les raisons spécifiques derrière la sélection de ce nombre peuvent impliquer un compromis entre l'utilisation des ressources, l'efficacité du réseau et l'évitement des goulots d'étranglement potentiels.
En réponse aux contraintes rencontrées dans le pipelining, HTTP/2 a introduit une fonctionnalité appelée multiplexage. Le multiplexage permet une communication plus efficace entre le client et le serveur en permettant la transmission simultanée de multiples requêtes et réponses sur une seule connexion.
HTTP/2 utilise un mécanisme de tramage binaire, ce qui signifie que les messages HTTP sont décomposés en unités plus petites et indépendantes appelées trames. Ces trames peuvent être entrelacées et envoyées sur la connexion indépendamment les unes des autres. À la réception, les trames sont réassemblées pour reconstituer le message HTTP d'origine.
Ce mécanisme de tramage binaire est fondamental pour réaliser le multiplexage en HTTP/2. Il permet au navigateur d'envoyer plusieurs requêtes sur la même connexion sans rencontrer de problèmes de blocage. En conséquence, les navigateurs comme Chrome utilisent le même identifiant de connexion pour les requêtes HTTP/2, permettant une communication efficace et ininterrompue entre le client et le serveur.
En essence, la fonctionnalité de multiplexage de HTTP/2, activée par le mécanisme de tramage binaire, améliore l'efficacité et la vitesse d'échange de données entre les clients et les serveurs en facilitant la transmission simultanée de plusieurs requêtes et réponses sur une seule connexion.
Pour améliorer les performances du protocole HTTP/2, les requêtes sont distribuées par défaut dans un pool de threads (32 par défaut) chaque fois qu'une nouvelle requête HTTP/2 est reçue par le serveur. Cela évite les attentes lorsqu'une seule connexion envoie de nombreuses requêtes simultanées qui nécessiteraient un traitement séquentiel (dans le contexte du thread de connexion) en l'absence de ce pool de threads.
Le comportement du pool de threads peut être configuré avec les propriétés suivantes.
Pour affiner les requêtes, en sélectionnant quelles requêtes doivent être traitées dans le pool de threads (car elles sont chronophages) tandis que d'autres peuvent être traitées dans le thread de connexion, vous pouvez utiliser l'événement OnHttp2BeforeAsyncRequest. Cet événement est déclenché avant de mettre la requête en file d'attente dans le pool de threads. Utilisez le paramètre Async pour définir si la requête est threadée ou non.
procedure OnHTTP2BeforeAsyncRequest(Sender: TObject; Connection: TsgcWSConnection; const ARequestInfo: TIdHTTPRequestInfo; var Async: Boolean);
begin
if ARequestInfo.Document = '/fast-request' then
ASync := False;
end;