Veja abaixo as diferenças entre HTTP 1.1 e HTTP 2.0:
No comportamento tradicional do HTTP, ao fazer múltiplas requisições pela mesma conexão, o cliente precisa esperar pela resposta de cada requisição antes de enviar a próxima. Essa abordagem sequencial aumenta significativamente o tempo de carregamento dos recursos de um site. Para resolver esse problema, o HTTP/1.1 introduziu um recurso chamado pipelining, permitindo que um cliente envie múltiplas requisições sem esperar pelas respostas do servidor. O servidor, por sua vez, responde ao cliente na mesma ordem em que recebeu as requisições.
Embora o pipelining parecesse ser uma solução, ele enfrentou desafios:
Em um esforço para otimizar o carregamento de páginas a partir de servidores que suportam HTTP/1.1, os navegadores web implementaram uma solução alternativa. Eles abrem de seis a oito conexões paralelas com o servidor, permitindo a transmissão simultânea de múltiplas requisições. Esse paralelismo visa mitigar os problemas associados ao pipelining e melhorar os tempos gerais de carregamento da página.
A escolha de seis a oito conexões paralelas pelos navegadores web baseia-se em considerações de otimização. As razões específicas por trás da seleção desse número podem envolver um equilíbrio entre utilização de recursos, eficiência de rede e a prevenção de potenciais gargalos.
Em resposta às restrições encontradas no pipelining, o HTTP/2 introduziu um recurso chamado multiplexing. O Multiplexing permite uma comunicação mais eficiente entre o cliente e o servidor ao habilitar a transmissão concorrente de múltiplas requisições e respostas sobre uma única conexão.
O HTTP/2 utiliza um mecanismo de framing binário, o que significa que as mensagens HTTP são divididas em unidades menores e independentes chamadas frames. Esses frames podem ser intercalados e enviados pela conexão de forma independente uns dos outros. Na extremidade receptora, os frames são remontados para reconstruir a mensagem HTTP original.
Este mecanismo de framing binário é fundamental para alcançar a multiplexação no HTTP/2. Ele permite que o navegador envie várias requisições pela mesma conexão sem encontrar problemas de bloqueio. Como resultado, navegadores como o Chrome utilizam o mesmo ID de conexão para requisições HTTP/2, permitindo uma comunicação eficiente e ininterrupta entre o cliente e o servidor.
Em essência, o recurso de multiplexação do HTTP/2, habilitado pelo mecanismo de binary framing, aprimora a eficiência e a velocidade da troca de dados entre clientes e servidores, facilitando a transmissão simultânea de múltiplas requisições e respostas sobre uma única conexão.
Para melhorar o desempenho do protocolo HTTP/2, as requisições são despachadas por padrão em um pool de threads (por padrão, 32) cada vez que uma nova requisição HTTP/2 é recebida pelo servidor. Isso evita esperas quando uma única conexão envia muitas requisições concorrentes que exigiriam processamento sequencial (no contexto da thread de conexão) na ausência deste pool de threads.
O comportamento do pool de threads pode ser configurado com as propriedades a seguir.
Para ajustar finamente as requisições, selecionando quais requisições devem ser processadas no pool de threads (porque consomem muito tempo) enquanto outras podem ser processadas na thread de conexão, você pode usar o evento OnHttp2BeforeAsyncRequest. Este evento é gerado antes de enfileirar a requisição no pool de threads. Utilize o parâmetro Async para definir se a requisição é processada em thread ou não.
procedure OnHTTP2BeforeAsyncRequest(Sender: TObject; Connection: TsgcWSConnection; const ARequestInfo: TIdHTTPRequestInfo; var Async: Boolean);
begin
if ARequestInfo.Document = '/fast-request' then
ASync := False;
end;