Desde sgcWebSockets 2024.2.0 el servidor HTTP/2 se ha mejorado al recibir peticiones HTTP/2. Ahora, por defecto, cuando el servidor recibe una nueva petición HTTP/2, esta se encola y es despachada por uno de los hilos del Pool of Threads. Esto evita el problema cuando se envían varias peticiones usando la misma conexión y estas se procesan de forma secuencial.
Mira a continuación las diferencias entre HTTP 1.1 y HTTP 2.0:
HTTP 1.1
En el comportamiento tradicional de HTTP, al hacer múltiples peticiones sobre la misma conexión, el cliente tiene que esperar la respuesta de cada petición antes de enviar la siguiente. Este enfoque secuencial aumenta significativamente el tiempo de carga de los recursos de un sitio web. Para abordar este problema, HTTP/1.1 introdujo una característica llamada pipelining, que permite a un cliente enviar múltiples peticiones sin esperar las respuestas del servidor. El servidor, a su vez, responde al cliente en el mismo orden en que recibió las peticiones.
Aunque el pipelining parecía ser una solución, se enfrentó a retos:
- Ignorancia del servidor o corrupción de respuestas: algunos servidores o ignoraban las peticiones pipelined o corrompían las respuestas, lo que llevaba a una comunicación poco fiable.
- Head-of-Line Blocking: la primera petición en el pipeline podía bloquear las peticiones siguientes, provocando un retraso en el procesamiento de otras peticiones. Este fenómeno, conocido como head-of-line blocking, daba lugar a tiempos de carga de página más lentos.
En un esfuerzo por optimizar la carga de páginas desde servidores compatibles con HTTP/1.1, los navegadores web implementaron una solución alternativa. Abren de seis a ocho conexiones paralelas al servidor, lo que permite la transmisión simultánea de múltiples peticiones. Este paralelismo busca mitigar los problemas asociados al pipelining y mejorar los tiempos de carga de página en general.
La elección de seis a ocho conexiones paralelas por parte de los navegadores web se basa en consideraciones de optimización. Las razones específicas detrás de la selección de este número pueden implicar un compromiso entre la utilización de recursos, la eficiencia de la red y la evitación de posibles cuellos de botella.
HTTP 2.0
En respuesta a las restricciones encontradas en el pipelining, HTTP/2 introdujo una característica llamada multiplexing. Multiplexing permite una comunicación más eficiente entre el cliente y el servidor al habilitar la transmisión concurrente de múltiples peticiones y respuestas sobre una única conexión.
HTTP/2 utiliza un mecanismo de framing binario, lo que significa que los mensajes HTTP se descomponen en unidades más pequeñas e independientes llamadas frames. Estos frames se pueden intercalar y enviar sobre la conexión de forma independiente entre sí. En el extremo receptor, los frames se reensamblan para reconstruir el mensaje HTTP original.
Este mecanismo de framing binario es fundamental para lograr el multiplexing en HTTP/2. Permite al navegador enviar múltiples peticiones sobre la misma conexión sin encontrarse con problemas de bloqueo. Como resultado, navegadores como Chrome utilizan el mismo ID de conexión para las peticiones HTTP/2, lo que permite una comunicación eficiente e ininterrumpida entre el cliente y el servidor.
En esencia, la característica de multiplexing de HTTP/2, habilitada por el mecanismo de framing binario, mejora la eficiencia y la velocidad del intercambio de datos entre clientes y servidores al facilitar la transmisión concurrente de múltiples peticiones y respuestas sobre una única conexión.
Componente TsgcWebSocketHTTPServer
Para mejorar el rendimiento del protocolo HTTP/2, las peticiones se despachan por defecto en un Pool Of Threads (por defecto 32) cada vez que el servidor recibe una nueva petición HTTP/2; esto evita esperas cuando una sola conexión envía muchas peticiones concurrentes que requerirían procesamiento secuencial (en el contexto del hilo de la conexión) en ausencia de este pool de hilos.
El comportamiento del PoolOfThreads puede configurarse mediante las siguientes propiedades.
- HTTP2Options.PoolOfThreads.Enabled: (por defecto true) permite despachar las peticiones http/2 en el pool de hilos en lugar del hilo de la conexión.
- HTTP2Options.Threads: (por defecto 32) el número de hilos usados para gestionar las peticiones HTTP/2. Establece un número acorde al número de procesadores de tu servidor.
Para afinar las peticiones, seleccionando cuáles deben procesarse en el Pool Of Threads (porque consumen mucho tiempo) mientras que otras pueden procesarse en el hilo de la conexión, puedes usar el evento OnHttp2BeforeAsyncRequest; este evento se lanza antes de encolar la petición en el pool de hilos, usa el parámetro Async para establecer si la petición es threaded o no.
procedure OnHTTP2BeforeAsyncRequest(Sender: TObject; Connection: TsgcWSConnection; const ARequestInfo: TIdHTTPRequestInfo; var Async: Boolean);
begin
if ARequestInfo.Document = '/time-consuming-request' then
ASync := False;
end;