Cómo funciona el navegador web moderno (parte 2)

Mariko Kosaka

Qué sucede en la navegación

Esta es la segunda parte de una serie de 4 blogs sobre el funcionamiento interno de Chrome. En la publicación anterior, analizamos las diferencias procesos y subprocesos manejan diferentes partes de un navegador. En esta publicación, profundizaremos en cómo cada proceso y subproceso se comunican para mostrar un sitio web.

Veamos un caso de uso simple de navegación web: se escribe una URL en un navegador y, luego, el navegador. Recupera datos de Internet y muestra una página. En esta publicación, nos centraremos en la parte en la que un un usuario solicita un sitio y el navegador se prepara para mostrar una página, lo que también se conoce como navegación.

Comienza con un proceso del navegador

Procesos del navegador
Figura 1: IU del navegador en la parte superior, diagrama del proceso del navegador con la IU, la red y el almacenamiento hilo adentro, en la parte inferior

Como ya vimos Parte 1: CPU, GPU, memoria y arquitectura de procesos múltiples, todo fuera de una pestaña es manejado por el proceso del navegador. El proceso del navegador tiene subprocesos como el de IU que dibuja botones y campos de entrada del navegador, el subproceso de red que se ocupa de la pila de red para recibir datos de Internet el subproceso de almacenamiento que controla el acceso a los archivos y mucho más. Cuando escribes una URL en la dirección la entrada es manejada por el subproceso de IU del proceso del navegador.

Navegación sencilla

Paso 1: Controla las entradas

Cuando un usuario comienza a escribir en la barra de direcciones, lo primero que pregunta el subproceso de IU es "¿Es esto un búsqueda o URL?". En Chrome, la barra de direcciones también es un campo de entrada de búsqueda, por lo que el subproceso de IU necesita analizar y decidir si se lo envía a un motor de búsqueda o al sitio que solicitó.

Cómo controlar las entradas del usuario
Figura 1: Subproceso de IU que pregunta si la entrada es una búsqueda o una URL

Paso 2: Inicia la navegación

Cuando un usuario presiona Enter, el subproceso de IU inicia una llamada de red para obtener el contenido del sitio. Ícono giratorio de carga se muestra en la esquina de una pestaña y el subproceso de red pasa por los protocolos correspondientes, como Búsqueda de DNS y conexión TLS para la solicitud.

Inicio de navegación
Figura 2: Subproceso de IU que se comunica con el subproceso de red para navegar a mysite.com

En este punto, el subproceso de red puede recibir un encabezado de redireccionamiento del servidor, como HTTP 301. En ese caso, El subproceso de red se comunica con el subproceso de IU que indica que el servidor solicita un redireccionamiento. Luego, se iniciará otra solicitud de URL.

Paso 3: Lee la respuesta

Respuesta HTTP
Figura 3: Encabezado de respuesta que contiene el tipo de contenido y la carga útil, que son los datos reales

Cuando el cuerpo de la respuesta (carga útil) comienza a recibirse, el subproceso de red analiza los primeros bytes de la transmisión, si es necesario. El encabezado Content-Type de la respuesta debe indicar qué tipo de datos es, pero, como puede faltar o ser incorrecta, Sniffing de tipos de MIME se hace aquí. Esto es una "empresa complicada" como se comenta en el código fuente. Puedes leer el comentario para ver cómo los diferentes navegadores tratan los pares de tipo de contenido y carga útil.

Si la respuesta es un archivo HTML, el siguiente paso sería pasar los datos al renderizador. pero si se trata de un archivo ZIP o algún otro archivo, entonces eso significa que es una solicitud de descarga. deberá pasar los datos al administrador de descargas.

Sniffing de tipos de MIME
Figura 4: Subproceso de red en el que se pregunta si los datos de la respuesta son HTML de un sitio seguro

Aquí también se realiza la verificación de SafeBrowsing. Si el dominio y los datos de respuesta parecen coincidir con un sitio malicioso conocido, el subproceso de red alertas para mostrar una página de advertencia. Además: Brosca Borzante crosante (CORB) control de seguridad para asegurarse de que la información datos no llegan al proceso del renderizador.

Paso 4: Busca un proceso del renderizador

Una vez que se hayan completado todas las verificaciones y el subproceso de red esté seguro de que el navegador debería navegar a la sitio solicitado, el subproceso de red le indica al subproceso de IU que los datos están listos. de IU luego encuentra un renderizador para continuar renderizando la página web.

Cómo buscar el proceso del renderizador
Figura 5: Subproceso de red que indica al subproceso de IU que debe encontrar el proceso del renderizador

Como la solicitud de red puede tardar cientos de milisegundos en obtener una respuesta, un se aplica la optimización para acelerar este proceso. Cuando el subproceso de IU envía una solicitud de URL a el subproceso de red del paso 2, este ya sabe hacia qué sitio se dirige. El subproceso de IU busca o inicia de forma proactiva un proceso del renderizador en paralelo a la solicitud de red. De esta manera, Si todo sale como se espera, el proceso del renderizador ya está en posición de espera cuando el subproceso de red los datos recibidos. Es posible que este proceso de reserva no se use si la navegación redirecciona entre sitios, en en cuyo caso se podría necesitar un proceso diferente.

Paso 5: Confirma la navegación

Ahora que los datos y el proceso del renderizador están listos, se envía una IPC del proceso del navegador al renderizador para confirmar la navegación. También pasa el flujo de datos para que el renderizador puede seguir recibiendo datos HTML. Una vez que el proceso del navegador escucha la confirmación de que la confirmación en el proceso del renderizador, se completó la navegación y se completó la fase de carga del documento. antes de comenzar a usar el servicio.

En este punto, la barra de direcciones está actualizada y el indicador de seguridad y la IU de configuración del sitio reflejan la información del sitio de la nueva página. El historial de la sesión de la pestaña se actualizará, así que puedes avanzar y retroceder. los botones recorrerán el sitio al que se acaba de navegar. Para facilitar el restablecimiento de una pestaña o sesión cuando cierras una pestaña o ventana, el historial de la sesión se almacena en el disco.

Confirma la navegación
Figura 6: IPC entre el navegador y los procesos del renderizador, que solicita la renderización de la página

Paso adicional: Se completó la carga inicial

Una vez que se confirma la navegación, el proceso del renderizador continúa cargando los recursos y renderiza el . Repasaremos los detalles de lo que ocurre en esta etapa en la próxima publicación. Una vez que el procesador el proceso “finaliza” de datos, envía una IPC de vuelta al proceso del navegador (esto ocurre después de Se activaron eventos onload en todos los marcos de la página y terminaron de ejecutarse. En este punto, el subproceso de IU detiene el ícono giratorio de carga en la pestaña.

Digo "finishs" porque el JavaScript del cliente aún podría cargarse. recursos adicionales y renderizar nuevas vistas después de este punto.

Finalizó la carga de la página
Figura 7: IPC desde el procesador hasta el proceso del navegador para notificar que se "cargó" la página

La navegación simple estaba completa. Pero ¿qué sucede si un usuario coloca una URL diferente en la barra de direcciones de nuevo? En el proceso del navegador, se siguen los mismos pasos para navegar al sitio diferente. Pero antes de hacerlo, debe verificar con el sitio renderizado actualmente si le interesa beforeunload.

beforeunload puede crear la pregunta "¿Quieres salir de este sitio?" cuando intentes salir o cerrar la pestaña. Todo lo que está dentro de una pestaña, incluido el código JavaScript, es controlado por el proceso del renderizador, por lo que El proceso del navegador debe comprobar con el proceso del renderizador actual cuando ingresa una nueva solicitud de navegación.

controlador de eventos beforeunload
Figura 8: IPC desde el proceso del navegador hasta un proceso del renderizador que le indica que está a punto de navegar a un sitio diferente

Si la navegación se inició desde el proceso del renderizador (por ejemplo, si el usuario hizo clic en un vínculo o JavaScript del cliente ejecuta window.location = "https://newsite.com") el proceso del renderizador primero verifica los controladores beforeunload. Luego, pasa por el mismo proceso que el proceso del navegador. la navegación iniciada. La única diferencia es que la solicitud de navegación se inicia desde el renderizado en el proceso del navegador.

Cuando se realiza la nueva navegación a un sitio diferente del que está renderizado actualmente, se genera una representación para controlar la nueva navegación, mientras que el proceso de renderización actual se mantiene controlar eventos como unload Para obtener más información, consulta Descripción general de los estados del ciclo de vida de las páginas. y cómo puedes conectarte a eventos con la API de Page Lifecycle.

nueva navegación y descarga
Figura 9: 2 IPC desde un proceso de navegador hasta un nuevo proceso del renderizador que indica que se debe renderizar la página y decirle al proceso anterior que descargue la carga.

En el caso de Service Worker

Un cambio reciente en este proceso de navegación es la introducción de service worker. Un service worker es una forma de escribir el proxy de red en el código de tu aplicación; lo que les permite a los desarrolladores web tener más control sobre lo que a nivel local y cuándo obtener datos nuevos de la red. Si el service worker está configurado para cargar la página de la caché, no es necesario solicitar los datos de la red.

Es importante recordar que el service worker es código JavaScript que se ejecuta en un procesador el proceso de administración de recursos. Pero cuando llega la solicitud de navegación, ¿cómo sabe un proceso del navegador que el sitio tiene una service worker?

Búsqueda de permisos de service workers
Figura 10: Subproceso de red en el proceso del navegador para buscar el alcance del service worker

Cuando se registra un service worker, su alcance se conserva como referencia (puedes leer más sobre el alcance en esta El artículo sobre el ciclo de vida del service worker). Cuando ocurre una navegación, el subproceso de red compara el dominio con el service worker registrado si se registra un service worker para esa URL, el subproceso de IU encuentra un proceso del renderizador en para ejecutar el código del service worker. El service worker puede cargar datos de la caché, lo que elimina la necesidad de solicitar datos de la red o puede solicitar nuevos recursos de la red.

navegación de serviceworker
Figura 11: Subproceso de IU en un proceso de navegador que inicia un proceso de renderizador para controlar el servicio trabajadores; un subproceso de trabajo en un proceso del renderizador y, luego, solicita datos a la red

Puedes ver que este recorrido de ida y vuelta entre el proceso del navegador y el del renderizador podría generar retrasos. si un service worker decide finalmente solicitar datos de la red. La precarga de navegación es un mecanismo para acelerar este mediante la carga de recursos en paralelo al inicio del service worker. Marca estas solicitudes con un encabezado, lo que permite a los servidores decidir si enviar diferentes contenidos a estas solicitudes; p. ej., actualizar datos en vez de un documento completo.

Carga previa de Navigation
Figura 12: Subproceso de IU en un proceso de navegador que inicia un proceso de renderizador para controlar el servicio trabajador mientras inicia una solicitud de red en paralelo

Conclusión

En esta publicación, vimos lo que ocurre durante una navegación y cómo el código de tu aplicación web ya que los encabezados de respuesta y el JavaScript del cliente interactúan con el navegador. Información sobre los pasos en el navegador para obtener datos de la red, lo que facilita la comprensión de por qué las APIs como y precarga. En la próxima publicación, veremos cómo el navegador evalúa las HTML/CSS/JavaScript para renderizar páginas.

¿Te gustó la publicación? Si tienes preguntas o sugerencias para la próxima publicación, obtén noticias tuyas en la sección de comentarios o de @kosamari en Twitter.

Siguiente: Funcionamiento interno de un proceso del renderizador