¿Qué partes de un servidor web son síncronas?

Answer 1

Existen diferentes arquitecturas de servidores web … pero creo que es seguro decir que uno de los primeros pasos es poner en cola las solicitudes entrantes.

Cada solicitud hecha al servidor web viene a través del puerto TCP 80/443 por defecto.
En el nivel de TCP / OS, un nuevo socket se pone en cola para manejar la solicitud.
(El primer nivel de comportamiento asíncrono ocurre fuera del proceso del servidor web).

El servidor web está escuchando estos puertos, y es notificado por el sistema operativo de la llegada.
El servidor web recoge la solicitud y la coloca en una cola de procesamiento.
(Este es el siguiente nivel de comportamiento asíncrono, dentro del proceso del servidor web)

Los primeros servidores web tendrían un conjunto de procesos de trabajo . Cuando un proceso de trabajo estaba inactivo, sacaría una solicitud de la cola para procesarla.

Por ejemplo, algunas tareas bien definidas que se realizan:
– comprobación de memoria / caché para respuesta válida / no caducada
– realice I / O simple y recupere el archivo del disco
– redirigir a un servidor de aplicaciones (php, ruby, procesador de nodo)
(o utilizando un módulo interno para el procesamiento)
– …

El mayor avance se produjo en 2005. 10 años después de que se lanzara Apache, Nginx lanzó un subproceso de trabajo diseñado que proporcionó una respuesta mucho mejor para el problema C10K (cliente concurrente 10,000).

Los subprocesos son procesos ligeros que pueden realizar muy bien pequeñas tareas bien definidas y requieren menos uso de CPU / memoria que un proceso completo. Tiene sentido si se están procesando una gran cantidad de solicitudes pequeñas, querrá reducir el procesamiento innecesario y el almacenamiento de memoria para dar cabida a un mayor número de solicitudes.

Un poco de lectura en Forking vs Threading, ya que creo que está utilizando la terminología de forma incorrecta.

Answer 2

Su presunción sobre las capas OSI es absolutamente correcta. Como sabe, el servidor HTTP es un servidor sin estado , es decir, cada solicitud se trataría como una solicitud individual y NO está relacionada con las solicitudes anteriores. Ese es el motivo al final de las solicitudes que requiere mantener la conexión activa o cerrada.

Ahora venga a la respuesta, Transport Layer es responsable de la comunicación de host a host, por lo que hasta que el servidor HTTP cierre la conexión (es decir, Conexión: cierre de encabezado) es sincrónico. Porque golpea los reintentos o espera a que se cierre la conexión. (Por favor vea la siguiente figura)

De la imagen de arriba, está claro que hubo un período de espera de 193.375 ms. Luego, si la conexión no es síncrona, inmediatamente volverá a aparecer en el mismo sitio web para la página de índice y quedará atrapada en el bucle infinito, ya que HTTP es un servidor sin estado (séptima capa de aplicación). Así que IMHO debajo de la capa de aplicación (en este caso HTTP) es síncrono.

Por favor, corríjame si estoy equivocado.