¿Qué sucede en el proceso de representación del navegador desde que se ingresa la URL hasta que el navegador muestra la página?
Primero comprenda la composición de la URL:
Como se puede ver en la URL anterior, una URL completa incluye las siguientes partes:
1. Parte del protocolo : La parte del protocolo de la URL es "". En una URL, la dirección IP también se puede usar como nombre de dominio
3. Parte del puerto: después del nombre de dominio está el puerto, y ":" se usa como separador entre el nombre de dominio y el puerto. El puerto no es una parte necesaria de una URL. Si se omite la parte del puerto, se utilizará el puerto predeterminado 80
4. Parte del directorio virtual: comenzando desde el primer "/" después del nombre de dominio hasta. el último "/", es la parte del directorio virtual. El directorio virtual tampoco es una parte obligatoria de una URL. El directorio virtual en este ejemplo es "/news/"
5. Parte del nombre del archivo: comenzando desde el último "/" después del nombre de dominio y terminando con "?", es la parte del nombre del archivo. Si no hay "?", comienza desde el último "/" después del nombre de dominio y termina con "#", que es la parte del archivo. Si no hay "" ni "#", entonces comienza. desde el último "/" después del nombre de dominio y termina con él como parte del nombre del archivo. El nombre del archivo en este ejemplo es "index.asp". La parte del nombre del archivo no es una parte necesaria de una URL. Si se omite esta parte, se utilizará el nombre del archivo predeterminado
6. Parte ancla: desde el principio hasta el final de "#", es la parte del ancla. La parte ancla en este caso es "nombre". La parte de anclaje no es una parte necesaria de una URL.
7. Parte de parámetro: la parte entre "?" y "#" es la parte de parámetro, también llamada parte de búsqueda y parte de consulta. La parte del parámetro en este ejemplo es "boardID=5&ID=24618&page=1". Los parámetros pueden permitir múltiples parámetros y "&" se utiliza como separador entre parámetros.
A muchas grandes empresas les gusta hacer esta pregunta de entrevista: ¿Qué sucede cuando ingresas la URL y ves la página? , resumamos hoy. En pocas palabras, *** tiene los siguientes procesos
Echemos un vistazo a los detalles específicos
Después de ingresar la URL www.google.com, primero en el nombre de dominio local servidor Busque, si no lo encuentra, vaya al servidor de nombres de dominio raíz para buscar, y luego vaya al servidor de nombres de dominio de nivel superior com para buscar, y así sucesivamente, hasta que encuentre la dirección IP, y luego regístrela localmente para la siguiente uso del tiempo. El proceso general es -> .com -> google.com -> www.google.com. (Puede pensar que escribo más..., pero ese no es el caso. Este... corresponde al servidor de nombres de dominio raíz. De forma predeterminada, el último dígito de todas las URL es... Dado que de forma predeterminada, para comodidad de los usuarios, generalmente se omite, el navegador lo agregará automáticamente al solicitar DNS)
Ahora que entendemos el proceso específico de análisis, podemos ver que el *** anterior ha pasado por N procesos, y cada proceso. Tiene un cierto consumo y tiempo de espera, ¡así que tenemos que encontrar la manera de solucionar este problema!
Hay varios niveles de caché en DNS, en orden de distancia desde el navegador, existen los siguientes tipos: caché del navegador, caché del sistema, caché del enrutador, caché del servidor IPS, caché del servidor de nombres de dominio raíz, superior. Caché del servidor de nombres de dominio de nivel, caché del servidor de nombres de dominio principal.
Ingrese: chrome://dns/ en su navegador Chrome, podrá ver el caché DNS del navegador Chrome.
El caché del sistema existe principalmente en /etc/hosts (sistema Linux)
Verifique si el navegador tiene un caché
Utilice Cache-Control y Expires para verificar si hay un caché fuerte, si llega al disco local, el html se recuperará directamente (el código de estado es 200 del caché del disco (o memoria), memoria o disco
Si no se alcanza el caché seguro, se iniciará una solicitud al servidor (la siguiente conexión TCP se realiza primero. El servidor usa Etag y Last-Modify para confirmar con el servidor si se ha devuelto la respuesta). cambiado (negociar caché). Si no hay cambios, devuelve un código de estado (304 No modificado). El navegador toma el caché local.
Si no es el caché fuerte ni el anterior. Cuando se alcanza la memoria caché negociada, se devuelve el resultado de la solicitud.
No sé si has notado esto. Cuando visitas, la respuesta no es el mismo servidor (con diferentes direcciones IP) Generalmente, las grandes empresas tienen cientos o miles de servidores. Para admitir el acceso, suponiendo que solo haya un servidor, ¿cuánto rendimiento y capacidad de almacenamiento necesita para admitir una cantidad tan grande de accesos? DNS puede devolver la IP de una máquina adecuada al usuario, por ejemplo, en función de la carga de cada máquina, la distancia de la máquina a la ubicación geográfica del usuario, etc. Este proceso es el equilibrio de carga de DNS
Protocolo TCP Un protocolo de enlace de tres vías establece la conexión.
Traducido a lengua vernácula:
¿Por qué 3 veces? : Evite conexiones históricas y confirme que la solicitud enviada por el cliente es la persona que se comunica esta vez.
¿Por qué no 4 veces? : 3 veces es suficiente y la cuarta es una pérdida
El proceso de establecer una conexión es utilizar el modo cliente-servidor. Supongamos que el host A es el cliente y el host B es el servidor.
El protocolo de enlace de tres vías se utiliza para evitar que el segmento de solicitud de conexión fallida se transmita repentinamente al Host B, provocando así un error. El segmento de solicitud de conexión fallida significa que la solicitud de conexión enviada por el host A no recibe confirmación del host B, por lo que después de un período de tiempo, el host A reenvía la solicitud de conexión al host B, la solicitud de conexión se establece con éxito y los datos La transmisión se completa en secuencia. Considere una situación tan especial. La primera solicitud de conexión enviada por el host A no se perdió, pero el nodo de red provocó un retraso en llegar al host B. El host B pensó que era una nueva conexión iniciada por el host A, por lo que el host B aceptó la conexión. y Se envía una confirmación al host A, pero el host A simplemente la ignora en este momento. El host B ha estado esperando que el host A envíe datos, lo que resulta en un desperdicio de recursos del host B.
No es posible utilizar dos apretones de manos debido al caso especial de solicitudes de conexión fallidas mencionado anteriormente. En el protocolo de enlace de tres vías, tanto el cliente como el servidor tienen un proceso de envío de sincronización y recepción de reconocimiento. Ambas partes pueden recibir después del envío, lo que indica que la comunicación está lista.
¿Por qué no un protocolo de enlace de cuatro vías? ¿apretón de manos? Todos deben conocer el famoso Acuerdo del Ejército Azul y el Ejército Rojo en las comunicaciones. Este ejemplo muestra que las comunicaciones no pueden ser 100% confiables y el protocolo de enlace de tres vías anterior ya ha preparado la comunicación. Agregar más protocolos de enlace no mejorará significativamente la confiabilidad. No mejorará significativamente la confiabilidad.
Primer apretón de manos:
El cliente envía un paquete de sincronización (Seq=x) al servidor y entra en el estado SYN_SEND, esperando la confirmación del servidor
Cuando el servidor recibe el paquete syn, debe confirmar el SYN del cliente (ack=x+1) y, al mismo tiempo, también envía un paquete SYN (Seq=y ), es decir, el paquete SYN + ACK En este momento El servidor ingresa al estado SYN_RECV
El tercer apretón de manos:
El cliente recibe el paquete SYN ACK del servidor y envía un paquete de confirmación ACK (ack = y + 1) al servidor. Una vez completado el envío, el cliente y el servidor ingresan al estado ESTABLECIDO y completan el protocolo de enlace de tres vías.
El paquete transmitido durante el proceso de protocolo de enlace no contiene datos. Una vez completado el protocolo de enlace de tres vías, el cliente y el servidor comienzan oficialmente a transmitir datos. Idealmente, una vez que se establece una conexión TCP, la conexión TCP se mantendrá hasta que cualquiera de las partes cierre activamente la conexión.
Primero debe solicitar un certificado de CA e instalarlo en el servidor (un archivo, configurar nginx para admitir la escucha en el puerto 443, abrir SSL y establecer la ruta del certificado)
El el navegador envía la solicitud;
El sitio web selecciona un conjunto de algoritmos de cifrado y algoritmos hash que admite a partir de las reglas de cifrado enviadas por el navegador y, por supuesto, envía un certificado con una clave pública. El certificado también contiene mucha información, como la dirección del sitio web, la autoridad emisora del certificado, el tiempo de vencimiento, etc.
El navegador analiza el certificado.
Verificar la validez del certificado. Por ejemplo, si la autoridad emisora es legal y si la dirección del sitio web en el certificado es consistente con la dirección visitada. Si no es legal, el navegador le indicará que el certificado no es confiable. Si es legal, el navegador lo mostrará. un pequeño candado.
Si es legal, o el usuario acepta un certificado ilegal, el navegador generará una cadena de contraseñas de números aleatorios (es decir, claves) y las cifrará con la clave pública proporcionada en el certificado.
Calcule el mensaje de protocolo de enlace utilizando el hash acordado, cifre el mensaje utilizando el número aleatorio generado (es decir, la clave) y finalmente envíe todos los mensajes generados previamente al servidor del sitio web.
El servidor web analiza el mensaje. Utilice la clave privada existente para descifrar la clave, luego utilice la clave para descifrar el mensaje de protocolo de enlace enviado y verifique si es coherente con el enviado por el navegador. Luego, la clave se utiliza para cifrar un mensaje de protocolo de enlace y se envía al navegador.
El navegador descifra y calcula el HASH del mensaje de protocolo de enlace. Si es coherente con el HASH enviado por el servidor, el proceso de protocolo de enlace finaliza en este momento. Todos los datos de comunicación posteriores se cifrarán utilizando la contraseña aleatoria. generado por el navegador anterior y utilizando un algoritmo de cifrado simétrico. Aquí, el navegador y el sitio web se envían mensajes de protocolo de enlace cifrados entre sí y los verifican. El propósito es garantizar que ambas partes hayan obtenido la misma contraseña y puedan cifrar y descifrar los datos normalmente, como prueba para la posterior transmisión de datos reales.
Envío de solicitudes HTTP
En primer lugar, comprendamos un poco el puerto de HTTP es 80/8080, mientras que el puerto de HTTPS es 443.
El proceso de envío de solicitudes HTTP Consiste en construir un mensaje de solicitud HTTP y enviarlo al puerto especificado del servidor a través del protocolo TCP. El mensaje de solicitud consta de una línea de solicitud, un encabezado de solicitud y un cuerpo de solicitud.
Línea de solicitud
El formato de la línea de solicitud es Método Solicitud-URL Versión HTTP CRLF, por ejemplo: GET index.html HTTP/1.1 Los métodos más utilizados son: GET, POST, PUT , BORRAR , OPCIONES , CABEZA .
Diferencias entre los métodos de solicitud comunes
Aquí mostramos principalmente la diferencia entre POST y GET
Diferencias comunes
Tenga en cuenta que también puede el cuerpo está oculto en GET y los parámetros están incluidos en POST
Diferencias clave
GET generará un paquete de datos TCP, mientras que POST generará dos paquetes de datos TCP.
En detalle:
Tenga en cuenta que no todos los navegadores enviarán paquetes de datos dos veces, Firefox solo los envía una vez
Encabezado de solicitud
p>El encabezado de la solicitud permite al cliente pasar información adicional sobre la solicitud e información sobre el propio cliente al servidor.
Como se puede ver en la figura, campos como Aceptar, Aceptar-Codificación, Aceptar-Idioma, Control de caché, Conexión y Cookie se utilizan en el encabezado de la solicitud. Aceptar se utiliza para especificar qué tipos de información acepta el cliente. Aceptar-Codificación es similar a Aceptar en que se utiliza para especificar el método de codificación a aceptar. La conexión está configurada en Keep-alive para indicarle al cliente que no es necesario cerrar la conexión TCP después de que se complete esta solicitud HTTP. Esto permite que la siguiente solicitud HTTP utilice el mismo canal TCP y ahorra tiempo para establecer una conexión TCP.
Texto de solicitud
Cuando se utilizan POST, PUT y otros métodos, generalmente se requiere que el cliente pase datos al servidor. Estos datos se almacenan en el cuerpo de la solicitud. Hay cierta información relacionada con el cuerpo de la solicitud en el encabezado de la solicitud, por ejemplo: las aplicaciones web actuales generalmente usan la arquitectura Rest y el formato de datos solicitados generalmente es json. En este momento, debe configurar el tipo de contenido: aplicación/json.
Cosas más importantes: almacenamiento en caché HTTP
HTTP es un caché de cliente. A menudo pensamos que el navegador tiene una base de datos en caché para guardar algunos archivos estáticos. A continuación lo dividimos en lo siguiente. presente brevemente el almacenamiento en caché HTTP desde este aspecto
Reglas de almacenamiento en caché
Las reglas de almacenamiento en caché se dividen en almacenamiento en caché forzado y almacenamiento en caché negociado
Almacenamiento en caché forzado
Cuando hay datos que el cliente necesita en la base de datos de caché, el cliente los saca directamente y los usa (si los datos no están invalidados cuando el servidor de caché no tiene los datos requeridos). , el cliente solicitará los datos al servidor.
También conocido como caché de comparación. El cliente primero obtendrá un identificador almacenado en caché de la base de datos de caché y luego verificará con el servidor si el identificador no es válido. Si no es válido, el servidor devolverá 304, para que el cliente pueda ir directamente a la base de datos de caché para tomarlo. Si no es válido, el servidor devolverá datos nuevos
Almacenamiento en caché forzado
Para el almacenamiento en caché forzado, se utilizarán dos campos en el encabezado de la respuesta del servidor para indicarlo. - Caduca y Cache-Control.
Expires
El valor de Expires es el tiempo de vencimiento de los datos devueltos por el servidor. Cuando el tiempo de solicitud al realizar la solicitud nuevamente es menor que el tiempo devuelto, los datos almacenados en caché se utilizarán directamente. Sin embargo, dado que la hora del servidor y la hora del cliente pueden ser diferentes, esto también provocará errores de acierto en la caché. Por otro lado, Expires es un producto de HTTP1.0, por lo que la mayoría de ellos ahora son reemplazados por Cache-Control.
Cache-Control
Cache-Control tiene muchos atributos y diferentes atributos tienen diferentes significados.
Caché de negociación
El caché de negociación debe compararse para determinar si se puede utilizar.
La primera vez que el navegador solicita datos, el servidor responderá al cliente con el identificador de caché y los datos, y el cliente hará una copia de seguridad de ellos en el caché. Al realizar una nueva solicitud, el cliente enviará el identificador en el caché al servidor, y el servidor juzgará en función de este identificador. Si no ha caducado, se devolverá un código de estado 304. El navegador puede utilizar los datos almacenados en caché directamente después de recibir este código de estado.
Para el almacenamiento en caché de negociación, debemos centrarnos en comprender el identificador de caché. A continuación, nos centraremos en presentar sus dos soluciones de almacenamiento en caché.
Última modificación
Última modificación: cuando el servidor responde a la solicitud, le indicará al navegador la hora de la última modificación del recurso.
Literalmente, significa: a partir de un determinado momento, si el archivo ha sido modificado.
La diferencia entre los dos es que uno se descarga después de la modificación y el otro no. Descargar sólo después de la modificación.
La última modificación es buena, pero no particularmente buena, porque si un recurso se modifica en el servidor, pero su contenido real no ha cambiado en absoluto, se devolverá porque la hora de la última modificación no coincide. La entidad completa se entrega al cliente (incluso si la caché del cliente tiene exactamente el mismo recurso). Para resolver este problema, HTTP1.1 introdujo Etag.
Etag
Etag: cuando el servidor responde a la solicitud, este campo le dice al navegador el identificador único generado por el servidor para el recurso actual (el las reglas de generación están determinadas por el servidor)
Sin embargo, en las aplicaciones reales, Etag se calcula utilizando un algoritmo, y el algoritmo ocupará recursos informáticos del lado del servidor. Todos los recursos del lado del servidor son valiosos, por lo que Etag lo es. raramente usado.
Ventajas del almacenamiento en caché
Solicitud del proceso de ejecución para diferentes actualizaciones
Escribe la URL en la barra de direcciones del navegador y presiona Enter
F5
Ctrl+F5
El servidor procesa la solicitud y devuelve el mensaje HTTP
Procesará la conexión TCP y el protocolo HTTP Analícelo y encapsúlelo en un objeto de solicitud HTTP de acuerdo con el formato del mensaje para que lo utilice la capa superior. Esta parte del trabajo generalmente la realiza el servidor web. Los servidores web que he usado incluyen Tomcat, Nginx y Apache, etc. Los mensajes HTTP también se dividen en tres partes: código de estado, encabezado de respuesta y mensaje de respuesta.
Código de estado
El código de estado consta de 3 dígitos El primer dígito define la categoría de respuesta y tiene cinco valores posibles:
Normalmente El más común. Los códigos de estado encontrados son: 200, 204, 301, 302, 304, 400, 401, 403, 404, 422, 500
Diferencias comunes de códigos de estado
200 Éxito
La solicitud es exitosa, generalmente el servidor proporciona los recursos necesarios.
204 Sin contenido
El servidor procesó exitosamente la solicitud pero no devolvió ningún contenido.
301 movida permanentemente
La página web solicitada se ha movido permanentemente a una nueva ubicación. Cuando el servidor devuelve esta respuesta (en respuesta a una solicitud GET o HEAD), automáticamente reenvía al solicitante a la nueva ubicación.
302 Movimiento temporal
El servidor está respondiendo actualmente a solicitudes de una página en una ubicación diferente, pero el solicitante debe continuar usando la ubicación original para futuras solicitudes.
304 No Modificado
La página web solicitada no ha sido modificada desde la última solicitud. Cuando el servidor devuelve esta respuesta, no se devuelve ningún contenido de la página web.
400 Solicitud incorrecta
El servidor no comprende la sintaxis de la solicitud.
401 No autorizado
La solicitud requiere autenticación.
Para las páginas web que requieren iniciar sesión, el servidor puede devolver esta respuesta.
403 Prohibido
El servidor rechazó la solicitud.
404 No encontrado
El servidor no puede encontrar la página web solicitada.
422 No se puede procesar
El formato de la solicitud es correcto, pero no puede responder debido a errores semánticos
500 Error interno del servidor
El servidor encontró un error, la solicitud no se puede completar.
Encabezado de respuesta
Los campos comunes del encabezado de respuesta son: Servidor, Conexión....
Mensaje de respuesta
Los archivos HTML, CSS y JS que solicita del servidor se colocan aquí
Este es el proceso de análisis y representación de Webkit. página.
Este proceso implica dos conceptos importantes: reflujo y redibujado. Todos los nodos DOM existen en forma de modelos de caja, y el navegador necesita calcular la posición y el ancho. Una vez determinado el ancho, alto, tamaño, color y otros atributos de la página, el navegador comienza a dibujar el contenido. Este proceso se denomina redibujado. El navegador debe pasar por estos dos procesos cuando abre la página por primera vez, pero este proceso consume muchísimo rendimiento, por lo que debemos intentar reducir el reflujo y el redibujado de la página
Puede haber Operaciones DOM, solicitudes de red http iniciadas por ajax, etc.
web-socket, ajax, etc., este proceso suele ser para obtener datos
setTimeout, setInterval, Promise y otras macro tareas y micro colas de tareas
Cuando el árbol de representación Cuando el tamaño, la estructura o ciertos atributos de algunos o todos los elementos de un documento cambian, el proceso por el que el navegador vuelve a representar parte o la totalidad del documento se denomina reflujo.
Operaciones que provocarán el reflujo:
Algunas propiedades y métodos comúnmente utilizados que provocarán el reflujo:
Cuando se cambia el estilo de un elemento en la página, no afecta su apariencia en la página. Al cambiar la posición en el flujo del documento (por ejemplo: color, color de fondo, visibilidad, etc.), el navegador asignará el nuevo estilo al elemento y lo volverá a dibujar. se llama redibujar.
El motor JS del navegador completa el análisis de JS. Dado que JavaScript se ejecuta en un solo hilo, significa que solo puede hacer una cosa a la vez. Al hacer esto, otras cosas se ponen en cola, pero algunas tareas consumen más tiempo (como las operaciones IO), por lo que las tareas son. divididas en tareas sincrónicas y tareas asincrónicas, todas las tareas sincrónicas se ejecutan en el hilo principal para formar una pila de ejecución, y las tareas asincrónicas esperan cuando se borra la pila de ejecución para ver si hay algo que ver. las tareas asincrónicas. Si hay algo que hacer, se extrae al hilo principal para su ejecución, y así sucesivamente (cuándo ocurrirá la retribución, Amitabha), se forma el bucle de eventos. peces gordos
Veamos primero un fragmento de código
Creo que todos deberían conocer el resultado. Este artículo presenta principalmente el análisis de JavaScript. En cuanto a Promise, lo discutiremos en la siguiente sección
JavaScript es un lenguaje de subproceso único, aunque Web-Worker se propone en H5 y puede simular subprocesos múltiples. , todavía es de naturaleza de un solo subproceso, decir que es de múltiples subprocesos es una tontería.
Al ser un solo hilo, la ejecución de cada evento debe ser secuencial. Por ejemplo, cuando vas al banco a retirar dinero, lo hace la persona que está delante y la que está detrás. espera, si la persona de delante hace una o dos horas más tarde, la gente detrás de mí probablemente esté loca. Por lo tanto, cuando el motor JS del navegador procesa JavaScript, se divide en tareas sincrónicas y tareas asincrónicas.
Podemos claramente. ver esta imagen
motor js Hay un proceso de monitoreo que verificará continuamente si la pila de ejecución del hilo principal está vacía. Una vez que esté vacía, irá a la cola de eventos para verificar si hay una función en espera. ser llamado. Se estima que después de leer esto, tendrá una cierta comprensión del bucle de eventos, pero de hecho, lo que vemos correctamente no es tan simple. Por lo general, veremos Promise, setTimeout, Process.nextTick (). y estoy confundido.
Diferentes tareas ingresarán a diferentes colas de tareas para su ejecución. Una vez que el motor JS comienza a funcionar, inicia el primer ciclo en la tarea macro (el script se ejecuta primero, pero me gusta sacarlo y llamarlo directamente a la pila de ejecución cuando todas las tareas en la pila de ejecución del hilo principal). están borradas, vaya a la microtarea. Eche un vistazo, si hay tareas esperando a ser ejecutadas, ejecute todas las microtareas (de hecho, inserte sus funciones de devolución de llamada en la pila de ejecución para su ejecución), luego vaya a la macrotarea para encontrar la. tarea que primero ingresa a la cola para ejecutarse y luego va al hilo principal después de ejecutar esta tarea Ejecute una tarea (por ejemplo, ejecute una tarea como ```console.log ("hola mundo")) y luego vaya. a la microtarea después de que se borra la pila de ejecución. Este ciclo se repite (cuándo es el momento de tomar represalias)
Siguiente Mire un fragmento de código
Echemos un vistazo a su ejecución<. /p>
El proceso de ejecución específico es más o menos así.