Squid, nginx, lighttpd diferencia de proxy inverso

El proxy inverso se puede dividir en dos tipos de la transmisión:
1: modo síncrono (apache-mod_proxy y squid)
2: modo asíncrono (lighttpd y nginx)
en nginx En la introducción, se menciona el modo de transferencia asíncrono y puede reducir el número de conexiones y la presión de back-end. ¿Por qué?
A continuación se explica la diferencia entre la transferencia sincrónica de agente tradicional (apache /squid) y lighttpd, la transferencia asíncrona nginx:
squid, nginx, lighttpd reverse proxy
transferencia síncrona: el navegador inicia la solicitud Luego, la solicitud se transfiere inmediatamente al fondo, por lo que se establece un canal entre el navegador y el fondo. Este canal siempre está presente hasta que se inicia la solicitud hasta que se completa la solicitud. Transferencia asíncrona: el navegador inicia la solicitud, la solicitud no pasa inmediatamente al fondo, pero los datos de la solicitud (encabezado) se reciben primero en nginx, luego nginx envía la solicitud al backend y los datos se devuelven al backend después del procesamiento. En nginx, nginx envía el flujo de datos al navegador. Esto es un poco diferente de lighttpd, que se envía al navegador una vez que se reciben los datos del servidor.
Resumen: El reverso de apache y squid aumentará la carga en la web de back-end, ya que cada solicitud de usuario tendrá un enlace a largo plazo con el servidor de back-end en el proxy, sabiendo que la conexión no desaparecerá hasta que se tomen los datos. Debido a que la velocidad wan es diferente de la velocidad de lan, aunque la velocidad entre lan es extremadamente rápida, la conexión wan del usuario determina este tiempo. El modo light de lighttpd y nginx es que no importa cuán grandes sean los datos que necesitan los usuarios, primero se reciben y luego se conectan con el backend. Esto es muy rápido, por lo que el tiempo de conexión entre el proxy y el backend será muy corto. Las cosas de las diez M también están a los pocos segundos. El backend no necesita mantener tantas conexiones. Lighttpd también es asíncrono a nginx. Lighttpd se envía primero al navegador del cliente, y nginx se dirige al navegador del usuario mientras recopila datos.
entonces que al final lo bueno es?
1. Suponga que el usuario realiza una operación de carga de archivos porque la velocidad de la red del usuario es más lenta, por lo que se tarda media hora en transferir el archivo al servidor. El agente de sincronización de Squid establece una conexión con el fondo después de que el usuario comienza a cargar. Después de media hora, la carga del archivo finaliza. Se puede ver que la conexión del servidor de fondo permanece durante media hora, y el proxy asíncrono de nginx recibe este archivo por primera vez en nginx. Por lo tanto, solo nginx y el usuario mantienen la conexión durante media hora. El servidor de fondo no abre la conexión para esta solicitud dentro de media hora. Después de media hora, el usuario carga y el nginx envía el contenido cargado al fondo. El ancho de banda entre nginx y el fondo es Muy abundante, por lo que tomó solo un segundo enviar la solicitud al fondo, por lo que se puede ver que la conexión del servidor de fondo se mantuvo durante un segundo. La transferencia sincrónica tomó un servidor en segundo plano durante media hora, y la transferencia asíncrona tomó solo un segundo, lo que demuestra que la optimización es muy grande.
2. En el ejemplo anterior, si el servidor de fondo se reinicia por varias razones, el archivo de carga se interrumpe de forma natural, lo que es muy molesto para el usuario. Presumiblemente, todos han subido el archivo y la mitad se interrumpe. Experiencia Después de usar el proxy nginx, el impacto del reinicio del servidor en segundo plano en la carga del usuario se reduce al extremo, y nginx es muy estable y no es necesario reiniciarlo con frecuencia. Incluso si necesita reiniciar, puede usar hail-HUP para reiniciar nginx sin interrupción.
3. La transferencia asíncrona puede hacer que el equilibrador de carga sea más seguro. ¿Por qué lo dice? En otros ecualizadores (lvs /haproxy /apache, etc.), cada solicitud solo tiene una posibilidad. Si el usuario inicia una solicitud y el servidor backend al que está asignada la solicitud solo se bloquea, la solicitud falla. Y como nginx es asíncrono, esta solicitud puede enviarse de vuelta al siguiente fondo, el siguiente fondo devuelve datos normales, por lo que la solicitud puede ser exitosa. Todavía use el ejemplo del archivo de carga del usuario, si no solo usa el proxy nginx, sino también el equilibrio de carga, nginx envía el archivo de carga a uno de los fondos, pero este servidor se reinicia repentinamente, después de que nginx reciba el error, cargará este El archivo se envía a otro fondo, por lo que el usuario no tiene que pasar otra media hora para cargarlo.
4. Si el usuario carga un archivo de 10 GB y el servidor de fondo no lo tiene en cuenta, entonces el servidor de fondo no debería bloquearse. Con nginx, puede bloquear estas cosas en nginx, limitar la función del límite de tamaño de archivo de carga de nginx y el rendimiento de nginx es muy seguro. Deje que los usuarios alternativos en Internet y nginx luchen contra él.
La transferencia asíncrona causará problemas:
El servidor de fondo tiene la función de proporcionar progreso de carga. Si utiliza el agente nginx, no puede obtener progreso. Esto debe ser implementado por un módulo de terceros de nginx.