¿Cómo funciona un servidor web no bifurcado?

Question

No bifurcaciones (también conocido como single-threaded o select() -based) servidores web como lighttpd o nginx son ganando en popularidad cada vez más.

Si bien hay una gran cantidad de documentos que explican la bifurcación de servidores (en varios niveles de detalle), la documentación para servidores no bifurcables es escasa.

Busco a un ojos de pájaro vista de cómo un servidor no se bifurcan web funciona. (Pseudo-) código o un diagrama de máquina de estado, desglosado al mínimo mínimo, sería genial.

Conozco los siguientes recursos y los encontré útiles.

• The World of SELECT()
• thttpd source code
• Lighttpd internal states

Sin embargo, estoy interesado en los principios, no de los detalles de implementación.

Específicamente:

• ¿Por qué este tipo de servidor llama a veces no bloqueante, cuando select() esencialmente bloques?

• El procesamiento de una solicitud puede llevar un tiempo. ¿Qué ocurre con las nuevas solicitudes durante este tiempo cuando no hay un hilo o proceso de escucha específico? ¿El procesamiento de la solicitud se ha interrumpido de alguna manera o se ha cortado el tiempo?

Editar: Como lo entiendo, mientras se procesa una solicitud (por ejemplo ficheros de lectura o escritura de cgi plazo) el servidor no puede aceptar nuevas conexiones. ¿No significaría esto que un servidor de este tipo podría perder muchas conexiones nuevas si se ejecuta una secuencia de comandos CGI, digamos unos 2 segundos más o menos?

Answer 1

pseudocódigo básica:

setup 
while true 
    select/poll/kqueue 
    with fd needing action do 
     read/write fd 
     if fd was read and well formed request in buffer 
      service request 
     other stuff 

• Aunque select() & amigos bloquean, Toma de E/S no está bloqueando. Solo estás bloqueado hasta que tengas algo divertido que hacer.
• Procesamiento de solicitudes individuales normalmente involucradas leyendo un descriptor de archivo de un archivo (recurso estático) o proceso (recurso dinámico) y luego escribiendo en el socket. Esto puede hacerse fácilmente sin guardar mucho estado.
• Por lo tanto, service request arriba significa abrir un archivo, agregarlo a la lista para select, y observar que las cosas leídas desde allí salen a un socket determinado. Sustituya FastCGI por archivo cuando sea apropiado.

EDIT:

• No estoy seguro sobre los otros, pero nginx tiene 2 procesos: un maestro y un trabajador. El maestro escucha y luego envía la conexión aceptada al trabajador para su procesamiento.

Answer 2

select() PLUS no bloqueante I/O esencialmente le permite gestionar/responder a múltiples conexiones, ya que vienen en un solo hilo (multiplexación), en lugar de tener múltiples hilos/procesos manejan un zócalo de cada uno. El objetivo es minimizar la relación entre la huella del servidor y el número de conexiones.

Es eficiente porque este único subproceso aprovecha el alto nivel de conexiones de socket activas necesarias para alcanzar la saturación (ya que podemos hacer E/S sin bloqueo en múltiples descriptores de archivos).

La razón es que se requiere muy poco tiempo para reconocer los bytes disponibles, interpretarlos y luego decidir los bytes apropiados para poner en la secuencia de salida. El trabajo de E/S real se maneja sin bloquear esta cadena del servidor.

Este tipo de servidor siempre está esperando una conexión, al bloquear en select(). Una vez que obtiene uno, maneja la conexión, luego vuelve a seleccionar el() en un bucle infinito. En el caso más simple, este hilo del servidor NO bloquea ningún otro momento además de cuando está configurando la E/S.

Si hay una segunda conexión que entra, se manejará la próxima vez que el servidor seleccione(). En este punto, la primera conexión aún podría estar recibiendo, y podemos comenzar a enviar a la segunda conexión, desde el mismo hilo del servidor. Este es el objetivo.

Busque "multiplexing network sockets" para obtener recursos adicionales.

O tratar de programación Unix Red por Stevens, Fenner, Rudoff