¿Qué sucederá cuando ingrese una dirección URL en el cuadro de dirección en el navegador?

1. proceso de solicitud http

http (Protocolo de transferencia de hipertexto) es un protocolo de capa de aplicación basado en el protocolo TCP.

1.1 nombre de dominio URL se resuelve en dirección IP (resolución dns)

Porque el navegador general encuentra y accede al servidor a través de la dirección IP, no a través del nombre de dominio. Por lo tanto, debe intentar encontrar la dirección IP correspondiente para poder acceder al servidor.

Entonces, ¿cómo encuentras la dirección IP?

Se busca capa por capa en la siguiente secuencia: si una capa encuentra la dirección IP, ingresará directamente a la siguiente parte de la conexión TCP.

Caché del navegador → caché del sistema → enrutador → proveedor de servicios de Internet → consulta recursiva

A continuación, describa los siguientes pasos de búsqueda en detalle

1. (Parte del caché del navegador) Averigüe si el caché del navegador tiene la dirección IP correspondiente al nombre de dominio de entrada (si el caché no ha caducado), en caso afirmativo, finalice el análisis; de lo contrario, vaya al paso 2.
2. (Caché del sistema) Averigüe si hay un caché de DNS correspondiente en el caché del sistema (si el caché no ha caducado), si es así, finalice el análisis; de lo contrario, vaya al paso 3.
3. (Router) Envía una solicitud al enrutador al que pertenece la LAN, y si la solicitud tiene una dirección IP, el análisis finaliza, de lo contrario, ingresa al paso 4.
4. (Proveedor de servicios de Internet) envía una solicitud al enrutador al que pertenece la LAN, y si la solicitud tiene una dirección IP, el análisis finaliza, de lo contrario, ingresa al paso 5.
5. (Consulta recursiva) Use la consulta recursiva, desde el servidor de nombres de dominio raíz al servidor de nombres de dominio de nivel superior, desde el servidor de nombres de dominio de nivel superior al servidor consultado, hasta que se encuentre la dirección IP, finaliza el análisis.

1.2 Establecer una conexión TCP de protocolo de enlace de tres vías

Debido a que TCP es similar al orientado a conexión, es una transmisión segura entre el servidor y el cliente. Siempre que se establezca una conexión TCP, prueba que ambas partes pueden enviar o recibir datos normalmente.

El formato del mensaje de transmisión normal de Internet será el siguiente:

Para confirmar el envío o la recepción de datos de ambas partes, se confirma mediante la transmisión de tres paquetes de envío, comúnmente conocido como protocolo de enlace de tres vías de TCP.

El diagrama de flujo del protocolo de enlace de tres vías de TCP es el siguiente:

De acuerdo con el proceso de la figura anterior, se puede dividir en los siguientes tres pasos:

1. El cliente envía un mensaje SYN/Seq al servidor (SYN=1, Seq=X), y el servidor juzga que el envío por parte del cliente es normal.
2. El servidor recibe el mensaje en el paso 1 y envía un mensaje SYN/ACK/Seq al cliente (SYN=1, ACK=1, ack=X+1, Seq=Y), en este momento, el cliente juzga el envío del servidor y recibir normalmente.
3. El cliente recibe el mensaje en el paso 2 y envía un mensaje ACK/Seq (ACK=1, ack=Y+1, Seq=X+1) al servidor En este momento, el cliente juzga que el envío y la recepción del servidor son normales El servidor juzga que el envío y la recepción del cliente son normales.

1.2.1 SYN, Seq, ack, ACK en el mensaje

En el protocolo de enlace de tres vías de TCP se utilizan los siguientes:
① SYN (síncrono): cuando es 1, significa que se determina que necesita establecer una solicitud de conexión.
② Seq (Número de secuencia de número de secuencia): Indica los datos enviados por sí mismo.
③ ack (Número de confirmación del número de reconocimiento): Indica los datos enviados por la otra parte.
④ ACK (confirmación de acuse de recibo): cuando es 1, significa que se confirma la recepción de la solicitud.

1.2.2 ¿Por qué necesitamos usar el apretón de manos de tres vías?

Es para garantizar que la conexión entre el servidor y el cliente sea normal y evitar errores en la conexión entre el envío de mensajes incorrectos entre sí.

De todos modos, si los siguientes uno o dos apretones de manos sucederán de la siguiente manera:

• Un apretón de manos: el valor del servidor solo juzga que la transmisión del cliente es normal.
• Dos apretones de manos: el valor del servidor solo juzga que el envío del cliente es normal, y el cliente solo juzga que el envío y la recepción del servidor son normales.

Por lo tanto, se requiere un apretón de manos de tres vías y la comunicación habitual es:
Cliente: ¿Está en el servidor? quiero conectar
Ropa: Estoy aquí y estableceré una conexión contigo.
Invitado: OK, he recibido tu respuesta y puedo empezar a conectarme.

1.3 Enviar solicitud http

Cuando se ingresa la dirección URL en el cuadro de dirección en el navegador, generalmente se ejecuta una solicitud de obtención, y abrir la página web es solo para obtener los datos de la página del backend del servidor para su análisis. Después de que se establezca la conexión TCP entre el servidor y el cliente, se enviará la solicitud HTTP correspondiente.
Ahora que hablamos de solicitudes http, describamos el principio de las solicitudes de interfaz con más profundidad.
Los métodos de solicitud generalmente se dividen en: get , post , put , delete , options , head , etc. Generalmente, los proyectos usan solicitudes get y post .
La dirección de solicitud del proyecto es usar <protocolo (http o https)>://<host>:<puerto>/<ruta (el nombre de la ruta de la página de configuración del front-end)>?<parámetro (el parámetro utilizado cuando el front-end almacena la solicitud de obtención) > Composición.

Por ejemplo, cuando ingresamos a Baidu y observamos la consola, podemos ver la dirección de solicitud y el método de solicitud correspondiente a la página de inicio de Baidu, como se muestra en la siguiente figura:

1.3.1 Diferencia entre solicitud de obtención y solicitud de publicación en solicitud http

get:
1. Generalmente se usa para obtener datos de la base de datos, y habrá un caché cuando el dato solicitado sea un recurso estático.
2. Los parámetros de la solicitud de front-end se colocan en la URL y el usuario puede ver el contenido de los parámetros solicitados, por lo que la seguridad no es muy buena.
3. La longitud de los datos de la solicitud es limitada, generalmente dentro de 1k.
4. Se puede guardar como marcador del navegador, ya que la dirección de solicitud y los parámetros están en la URL, que se pueden guardar en el historial de navegación del navegador.
5. Las operaciones de retroceso y actualización del navegador no tienen efecto en los datos.
6. El formato de codificación es application/x-www-form-urlencoded.
7. Los parámetros solicitados solo permiten transmitir caracteres ASCII.
8. Al enviar una solicitud, el encabezado http y los datos se enviarán juntos. (un paquete TCP)

post:
1. Generalmente se usa para operaciones como agregar, modificar y eliminar datos.
2. Los parámetros de la solicitud de front-end se envían en el cuerpo del mensaje http, en lugar de escribirse en el cuerpo, por lo que la seguridad es relativamente segura.
3. No hay límite para la longitud de los datos de la solicitud (la longitud de los datos está determinada por el navegador y el servidor)
4. No se puede guardar como un marcador de navegación, porque los parámetros de la solicitud no están escritos en la dirección de la solicitud y el La página informará un error incluso si se accede a ella.
5. Cuando el navegador regrese y se actualice, volverá a enviar una solicitud al backend, que consiste en modificar nuevamente los datos en la base de datos.
6. El formato de codificación no solo incluye aplicación/x-www-form-urlencoded, sino también codificación multipart/form-data.
7. No hay límite a los parámetros de la solicitud.
8. Al enviar una solicitud, el encabezado http se enviará primero y los datos se enviarán cuando el backend devuelva un código de estado de 100 que indica que puede continuar. (dos paquetes TCP)

1.4 El servidor procesa la solicitud y responde en consecuencia

En general, después de que se ejecuta la solicitud de datos, si no hay un dominio cruzado, la interfaz de solicitud no existe o la interfaz de solicitud se agota, se devolverá un código de estado, un aviso de operación de mensaje y datos desde el backend.
El código de estado es básicamente el siguiente:

• 1XX: (información de instrucción) significa que la solicitud ha sido recibida y será procesada posteriormente.
• 2XX: (Éxito) significa que la solicitud es exitosa y se han devuelto los datos correspondientes.
• 3XX: (Redirigir) Para continuar con la solicitud, se requieren más acciones.
• 4XX: (error de cliente) Hay un error de escritura en la interfaz de solicitud, o el parámetro es incorrecto (valor, tipo o formato) y no se puede realizar la operación de solicitud.
• 5XX: (Error del servidor) El servidor no pudo cumplir con una solicitud legítima.

Por ejemplo, cuando ingresamos a Baidu y observamos la consola, podemos ver el código de estado de la solicitud para obtener la página de inicio de Baidu, como se muestra en la siguiente figura:

Intercambio de experiencias personales:
generalmente, cuando el código de estado devuelto por la interfaz de acoplamiento frontal no es 2XX, se requiere el siguiente análisis paso a paso para la resolución de problemas.
1. Primero observe si el resultado de retorno del backend indica qué líneas de PHP informan errores y comuníquese con el padre del backend si hay alguno 2. La
dirección de solicitud de la interfaz está escrita incorrectamente
3. Si el método de solicitud es get type o post tipo
4. Si la ubicación del parámetro es correcta, ya sea para colocarlo en el cuerpo del mensaje http o empalmarlo después de la URL
5. Si se trata de una solicitud de obtención, si el formato de datos transmitido se convierte al formato de código ASCII
6. Si el el formato de codificación correspondiente es correcto
7. Si los parámetros, valores, tipos y formatos transmitidos son los mismos que los siguientes Los documentos de interfaz escritos al final son consistentes
8. Si se verifica todo lo anterior y no hay ningún problema , luego comuníquese con el padre de back-end para ver si hay un problema con el procesamiento comercial de datos.

1.5 El navegador analiza los datos y muestra la página

Tengamos una comprensión general del siguiente proceso específico. El diagrama de flujo específico es el siguiente:

El proceso de análisis específico se dividirá en las siguientes partes:

1. De acuerdo con el análisis de los datos HTML, se genera el árbol DOM correspondiente.
2. Genere el árbol CSSOM correspondiente según el análisis de datos CSS.
3. Atraviese el nodo NODE de cada nivel del árbol DOM, calcule todos los estilos debajo del nodo y genere un árbol DOM con cada nodo que contenga el estilo final. (El árbol DOM y el árbol CSSOM se combinan en consecuencia)
4. Para el árbol DOM que contiene estilos, se coloca en capas de acuerdo con la posición de coordenadas calculada de la página donde se encuentra y las posiciones delantera y trasera de la página para generar el árbol de diseño correspondiente.
5. Finalmente, genere instrucciones de dibujo para la página, divida el área de la página en bloques, rasterice los bloques (la aceleración de GPU confirma la información rgb de cada píxel) y finalmente realice la operación de dibujo en la página.

El proceso de operación desde el análisis de datos hasta la capa inferior de la página representada puede ser engorroso, y me centraré en describir el paso de datos en detalle más adelante.

1.6 Agite cuatro veces para desconectar la conexión TCP

Al desconectar la conexión TCP, se realizan cuatro operaciones de onda. El diagrama de flujo de la onda de cuatro vías TCP es el siguiente:

De acuerdo con el diagrama de flujo anterior, se puede dividir en los siguientes cuatro pasos:

1. El cliente envía un mensaje FIN/seq al servidor (FIN=1, seq=x).En este momento, el cliente le indica al servidor que necesita desconectarse, y el servidor ya sabe que el cliente necesita desconectarse.
2. El servidor recibe el mensaje en el paso 1 y envía un mensaje ACK/ack/seq (ACK=1, seq=y, ack=x+1) al servidor. En este momento, el cliente sabe que el servidor ha recibido la solicitud. para finalizar Abra la operación de conexión y espere a que el servidor complete la última transmisión de datos.
3. Después de un período de tiempo, el servidor continúa enviando mensajes ACK/FIN/ack/seq (ACK=1, FIN=1, seq=z, ack=x+1) al cliente. En este momento, el cliente ya sabe que el servidor envió la última transmisión de datos A se completa, y el servidor está esperando que el cliente confirme la finalización de la última transmisión de datos.
4. Después de recibir el mensaje en el paso 3, el cliente envía un mensaje ACK/ack/seq (ACK=1, ack=z+1, seq=x+1) al servidor, y el cliente espera después de enviarlo. Después de un período de tiempo, cambiará al estado cerrado, y el servidor cambiará al estado cerrado después de recibir la confirmación de la finalización de la transmisión del cliente (el mensaje en el paso 4).

1.6.1 FIN en el mensaje

SYN, Seq, ack, ACK y FIN se utilizan en el protocolo de enlace de cuatro vías de TCP (SYN, Seq, ack y ACK se describen en el protocolo de enlace de tres vías 1.2.1, y aquí solo se analiza FIN): ① FIN: Cuando 1
, Indica que necesita confirmar la desconexión.

1.6.2 ¿Por qué necesita usar cuatro ondas?

Evite que la transmisión de datos incompleta desperdicie recursos o que el cliente y el servidor se apaguen normalmente.

De todos modos, si agitas la mano una, dos o tres veces, ocurrirá lo siguiente:

• Onda de una mano: el cliente no puede confirmar si el servidor ha recibido la solicitud de desconexión y si se ha completado toda la transmisión de datos del servidor.
• Segunda ola: aunque el cliente confirma que ha recibido la primera ola del servidor, no se puede cerrar directamente en este momento, porque aún no se han transmitido todos los datos en el servidor.
• Wave tres veces: aunque el cliente sabe que el servidor conoce la solicitud de desconexión, y el cliente también obtiene todos los datos del servidor, no le dice al servidor que ha recibido el último lote de datos.

Por lo tanto, debe agitar las manos cuatro veces y la comunicación habitual es:
Invitado: ¿Está aquí? necesito desconectar
Servicio: Sé que necesitas desconectarte, esta vez los datos son XXX.
Servidor: Los datos esta vez son YYY, te he enviado todos los datos, puedes prepararte para desconectarte.
Invitado: Vale, he recibido los últimos datos YYY aquí, esperaré un rato tu respuesta, por si no me escuchas. Si no hay problema, cerraré la conexión. Del lado del servidor, también puede cerrar el servidor usted mismo sin esperar mi respuesta.

1.6.3 ¿Por qué el servidor ingresa CLOSE-WAIT cuando recibe el primer movimiento de la mano?

Debido a que el servidor no está seguro de si los datos entre el cliente y el servidor se han transmitido por completo en este momento, no enviará inmediatamente un mensaje sobre FIN=1, ni ejecutará de inmediato el proceso de cierre de conexión, sino que entrará en el estado CLOSE-WAIT .

1.6.4 ¿Por qué el estado ingresa a IME-WAIT cuando el cliente envía la cuarta ola, en lugar de cerrarse de inmediato?

Porque el cliente evita la pérdida del paquete enviado para la cuarta ola en este momento, y el servidor vuelve a enviar el paquete ACK/FIN/ack/seq para la tercera ola.
Si el cliente se cierra directamente, no recibirá el mensaje del servidor y el servidor ha estado esperando la cuarta ola del cliente. Si el estado de transmisión del servidor no está cerrado, se desperdiciarán recursos.