Tengo un servidor back-end (Apache) que está demasiado lejos de la mayoría de nuestros usuarios, por lo que nuestra idea es implementar un proxy inverso más cercano que actuará como caché.
A primera vista funcionó de maravilla. Los archivos estáticos almacenados en caché se entregan extremadamente rápido, pero para cualquier otra cosa, el proxy inverso (NGINX) necesita conectarse al servidor back-end, lo que lleva algún tiempo para el protocolo de enlace SSL, lo que hace que estas primeras solicitudes sean lentas.
Estaba buscando información sobre esto pero no pude encontrar una manera de mantener esta conexión. ¿Hay alguna manera de hacerlo?
Incluso intenté aprender más sobre websockets, pero todas las implementaciones que pude encontrar fueron para responder a una solicitud específica, no para mantener la conexión intermediando ambos servidores web (NGINX en el proxy inverso y Apache en el back-end).
¿Alguno de ustedes tiene alguna idea o consejo sobre qué estudiar/usar/buscar para lograrlo?
¡Muchas gracias de antemano!
Respuesta1
En nginx solo puedes especificarkeepalivepara una conexión ascendente si la conexión está definida en unupstreambloquear. Por ejemplo:
upstream backend {
server private-api.example.com:443;
keepalive 32;
}
Aquí, keepaliveespecifica el número máximo de conexiones abiertas simultáneas a los servidores ascendentes porproceso de trabajo.
Para utilizar el upstream, especifica su nombre en proxy_passlugar de la dirección de backend.
Por ejemplo, si utilizó anteriormente:
proxy_pass https://private-api.example.com:443;
Lo cambiarías a:
proxy_pass https://backend;
Literalmente sustituya el nombre del upstream por el definido server.
También debe configurar la versión HTTP en 1.1 (porque, de manera bastante absurda, su valor predeterminado es 1.0) y borrar el encabezado de Conexión:
proxy_http_version 1.1;
proxy_set_header Connection "";
Tenga en cuenta que también hay un keepalive_timeoutelemento que puede definir y upstreamque quizás necesite sintonizar. De forma predeterminada, son 60 segundos, por lo que si una conexión está inactiva durante ese tiempo, se cerrará, incluso si hay menos keepaliveconexiones abiertas. El servidor backend tendrá su propio tiempo de espera de mantenimiento de actividad que también deberá ajustar por separado.