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
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ó.
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.
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
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.
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.
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.
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.
Cómo navegar a un sitio diferente
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.
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.
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?
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.
Precarga de Navigation
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.
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