See below the differences between HTTP 1.1 and HTTP 2.0:
Bij traditioneel HTTP-gedrag moet de client bij het maken van meerdere verzoeken via dezelfde verbinding wachten op het antwoord van elk verzoek voordat het volgende wordt verzonden. Deze sequentiële aanpak verhoogt de laadtijd van de resources van een website aanzienlijk. Om dit probleem aan te pakken introduceerde HTTP/1.1 een functie genaamd pipelining, waardoor een client meerdere verzoeken kan verzenden zonder te wachten op de antwoorden van de server. De server antwoordt op zijn beurt op de client in dezelfde volgorde als hij de verzoeken heeft ontvangen.
Hoewel pipelining een oplossing leek, had het uitdagingen:
In een poging het laden van pagina's te optimaliseren van servers die HTTP/1.1 ondersteunen, implementeerden webbrowsers een tijdelijke oplossing. Ze openen zes tot acht parallelle verbindingen met de server, waardoor meerdere verzoeken tegelijk kunnen worden verzonden. Dit parallellisme is bedoeld om de problemen met pipelining te verminderen en de algehele laadtijden van pagina's te verbeteren.
De keuze van zes tot acht parallelle verbindingen door webbrowsers is gebaseerd op optimalisatieoverwegingen. De specifieke redenen voor het selecteren van dit aantal kunnen een afweging zijn tussen resourcegebruik, netwerkefficiëntie en het vermijden van mogelijke knelpunten.
Als reactie op de beperkingen van pipelining introduceerde HTTP/2 een functie genaamd multiplexing. Multiplexing maakt efficiëntere communicatie mogelijk tussen client en server door de gelijktijdige overdracht van meerdere verzoeken en antwoorden via één verbinding mogelijk te maken.
HTTP/2 maakt gebruik van een binair framingsmechanisme, wat betekent dat HTTP-berichten worden opgesplitst in kleinere, onafhankelijke eenheden die frames worden genoemd. Deze frames kunnen worden afgewisseld en onafhankelijk van elkaar over de verbinding worden verzonden. Aan de ontvangzijde worden de frames opnieuw samengesteld om het originele HTTP-bericht te reconstrueren.
Dit binaire framemechanisme is fundamenteel voor het bereiken van multiplexing in HTTP/2. Het stelt de browser in staat meerdere verzoeken over dezelfde verbinding te verzenden zonder blokkeerproblemen. Als gevolg hiervan gebruiken browsers zoals Chrome dezelfde verbindings-ID voor HTTP/2-verzoeken, wat efficiënte en ononderbroken communicatie tussen client en server mogelijk maakt.
In essentie verbetert de multiplexingfunctie van HTTP/2, mogelijk gemaakt door het binaire framemechanisme, de efficiëntie en snelheid van gegevensuitwisseling tussen clients en servers door gelijktijdige verzending van meerdere verzoeken en antwoorden over één verbinding mogelijk te maken.
Om de prestaties van het HTTP/2-protocol te verbeteren, worden de verzoeken standaard verzonden in een pool van threads (standaard 32) elke keer dat een nieuw HTTP/2-verzoek door de server wordt ontvangen. Dit voorkomt wachttijden wanneer een enkele verbinding veel gelijktijdige verzoeken verzendt die sequentiële verwerking zouden vereisen (in de context van de verbindingsthread) zonder deze threadpool.
The behavior of the pool of threads can be geconfigureerd with het volgende properties.
Om de verzoeken nauwkeurig af te stemmen, en te selecteren welke verzoeken in de threadpool moeten worden verwerkt (omdat ze tijdrovend zijn) terwijl andere in de verbindingsthread kunnen worden verwerkt, kunt u de gebeurtenis OnHttp2BeforeAsyncRequest gebruiken. Deze gebeurtenis wordt geactiveerd voordat het verzoek in de threadpool wordt geplaatst. Gebruik de parameter Async om in te stellen of het verzoek in een thread wordt uitgevoerd of niet.
procedure OnHTTP2BeforeAsyncRequest(Sender: TObject; Connection: TsgcWSConnection; const ARequestInfo: TIdHTTPRequestInfo; var Async: Boolean);
begin
if ARequestInfo.Document = '/fast-request' then
ASync := False;
end;