TsgcWebSocketHTTPServer | HTTP/2 Server Threads

Di seguito sono riportate le differenze tra HTTP 1.1 e HTTP 2.0:

 

HTTP 1.1

Nel comportamento HTTP tradizionale, quando si effettuano più richieste sulla stessa connessione, il client deve attendere la risposta di ogni richiesta prima di inviare la successiva. Questo approccio sequenziale aumenta significativamente il tempo di caricamento delle risorse di un sito web. Per risolvere questo problema, HTTP/1.1 ha introdotto una funzionalità chiamata pipelining, che consente a un client di inviare più richieste senza attendere le risposte del server. Il server, a sua volta, risponde al client nello stesso ordine in cui ha ricevuto le richieste.

 

Sebbene il pipelining sembrasse una soluzione, ha incontrato alcune difficoltà:

 

 

 

Nel tentativo di ottimizzare il caricamento delle pagine dai server che supportano HTTP/1.1, i browser web hanno implementato una soluzione alternativa. Aprono da sei a otto connessioni parallele al server, consentendo la trasmissione simultanea di più richieste. Questo parallelismo mira a mitigare i problemi associati al pipelining e a migliorare i tempi complessivi di caricamento delle pagine.

 

La scelta di sei-otto connessioni parallele da parte dei browser web si basa su considerazioni di ottimizzazione. Le ragioni specifiche alla base di questa scelta potrebbero implicare un compromesso tra utilizzo delle risorse, efficienza della rete e prevenzione di potenziali colli di bottiglia.

 

 

HTTP 2.0

In risposta ai vincoli incontrati nel pipelining, HTTP/2 ha introdotto una funzionalità chiamata multiplexing. Il multiplexing consente una comunicazione più efficiente tra client e server, abilitando la trasmissione concorrente di più richieste e risposte su una singola connessione.

 

HTTP/2 utilizza un meccanismo di framing binario, il che significa che i messaggi HTTP vengono suddivisi in unità più piccole e indipendenti chiamate frame. Questi frame possono essere intercalati e inviati sulla connessione indipendentemente l'uno dall'altro. Sul lato ricevente, i frame vengono riassemblati per ricostruire il messaggio HTTP originale.

 

Questo meccanismo di framing binario è fondamentale per realizzare il multiplexing in HTTP/2. Consente al browser di inviare più richieste sulla stessa connessione senza incorrere in problemi di blocco. Di conseguenza, browser come Chrome utilizzano lo stesso ID di connessione per le richieste HTTP/2, permettendo una comunicazione efficiente e ininterrotta tra client e server.

In sostanza, la funzionalità di multiplexing di HTTP/2, abilitata dal meccanismo di framing binario, migliora l'efficienza e la velocità dello scambio di dati tra client e server facilitando la trasmissione simultanea di più richieste e risposte su una singola connessione.

 

 

TsgcWebSocketHTTPServer

Per migliorare le prestazioni del protocollo HTTP/2, le richieste vengono distribuite per impostazione predefinita in un pool di thread (32 per impostazione predefinita) ogni volta che il server riceve una nuova richiesta HTTP/2. Ciò evita attese quando una singola connessione invia molte richieste concorrenti che richiederebbero un'elaborazione sequenziale (nel contesto del thread di connessione) in assenza di questo pool di thread.

 

Il comportamento del pool di thread può essere configurato con le seguenti proprietà.

 

 

Per ottimizzare le richieste, selezionando quali richieste devono essere elaborate nel pool di thread (perché richiedono molto tempo) mentre altre possono essere elaborate nel thread di connessione, può utilizzare l'evento OnHttp2BeforeAsyncRequest. Questo evento viene generato prima di accodare la richiesta nel pool di thread. Utilizzi il parametro Async per impostare se la richiesta deve essere eseguita su thread o meno.

 


procedure OnHTTP2BeforeAsyncRequest(Sender: TObject; Connection: TsgcWSConnection; const ARequestInfo: TIdHTTPRequestInfo; var Async: Boolean);
begin
  if ARequestInfo.Document = '/fast-request' then
    ASync := False;
end;