¿Cuáles son las series de pasos que suceden cuando se solicita una URL desde el campo de dirección de un navegador?

Por lo que sé….

Cuando ingresas a google.com en la barra de direcciones del navegador, sucede la siguiente serie de cosas

1. el navegador necesita conocer la dirección IP numérica, por lo que primero busca en la memoria caché de su navegador, seguido de la memoria caché del sistema operativo, la memoria caché del enrutador, la memoria caché DNS del ISP, luego comienza una búsqueda recursiva en el servidor DNS del ISP a través del servidor de nombres TLD hasta encontrar la IP requerida dirección.

Existe un concepto de equilibrador de carga que también entra en juego. Es solo una pieza de hardware que escucha en una dirección IP particular y reenvía las solicitudes a otros servidores. Los sitios principales suelen utilizar equilibradores de carga caros de alto rendimiento

2. después de obtener la IP, el navegador envía una solicitud HTTP al servidor web

3. el servidor de google responde con una redirección permanente (301). le dice al navegador que vaya ” http://www.google.com/&quot ; en lugar de” http://google.com/&quot ;

4. El navegador sigue la redirección y envía otra solicitud Get

5. El servidor envía una respuesta HTML al cliente. el tipo de contenido del encabezado indica al navegador que represente el contenido de la respuesta como HTML, en lugar de decir que lo descargue como un archivo.

6.El navegador comienza a procesar el HTML y envía la solicitud de objeto incrustado en HTML, ya que muchos sitios entregan sus archivos CSS, imágenes / Sprite y archivos de secuencias de comandos desde una red de entrega de contenido ( CDN ). el navegador volverá a enviar la solicitud GET para cada una de las URL incrustadas, que de nuevo sigue el mismo procedimiento de búsqueda y otros pasos mencionados anteriormente.

7. Después de esto, el navegador puede enviar más solicitudes de AJAX para comunicarse con el servidor web incluso después de que la página se muestre.

así que esta es la imagen más amplia de cómo funciona esto. Hay muchos detalles de bajo nivel que omití intencionalmente (porque no los conozco: p)

Buena vieja pregunta de entrevista:

1. En el momento en que escribimos la primera letra, comenzará a buscar marcadores e historial y le dará sugerencias significativas.
2. Analizar URL, recuperar protocolo y página de índice principal
3. Si no contiene ninguna URL válida, busque en el motor de búsqueda predeterminado del navegador; de lo contrario, busque DNS.
4. La conversión de NO ASCII ocurre, utilizará una codificación insignificante para convertir la URL.
5. El navegador verifica la lista HSTS (HTTP Strict Transport Security). agregue HTTPS si la URL se encuentra en la lista, de lo contrario envíela a través de HTTP.
6. Búsqueda DNS: a quién buscar, 1. Caché DNS del navegador 2. Caché del sistema operativo 3. Llame al servidor DNS que enrutador local / enrutador ISP.
7. Obtenga la dirección IP del servidor DNS / puerta de enlace predeterminada utilizando ARP (Protocolo de resolución de direcciones).
8. abra el puerto 53 y eleve un UDP a un servidor DNS (TCP / UDP depende del tamaño de la respuesta), si la puerta de acceso predeterminada seguirá este procedimiento de forma recursiva.
9. Una vez que tengamos una dirección IP del servidor de destino, inicia la solicitud http (puerto 80) / https (puerto 443) y solicitará la conexión de socket TCP.
10. La solicitud llega a la capa de red para llenar el encabezado TCP, la capa de transporte para llenar el encabezado IP, la capa de enlace de datos para el encabezado de trama de Ethernet.
11. El paquete fluye en la red en digital o celular.
12. Apretón de manos de 3 vías entre el servidor y el cliente y los datos se envían al cliente a pedido.
13. Apretón de manos de seguridad de la capa de transporte. El navegador obtiene los datos.
14. El navegador hace 1. análisis (html, css, js, etc.) 2. representación (construcción del árbol DOM, representará la página y la GPU).
15. El motor de script Java se inicia para realizar acciones dinámicas.

Gracias por el A2A. Tomemos una visión general de alto nivel de una solicitud HTTP del navegador cuando se accede a Facebook:

1. Ingresa ” http: //facebook.com&quot ; en la barra de direcciones.
2. El navegador resuelve esto a la dirección IP numérica (esto puede ser almacenado en caché por el sistema operativo o requerir un viaje a un servidor DNS).
3. El navegador emite una solicitud “HTTP / GET”. Transmite una HttpRequest que incluye metadatos sobre el navegador, las preferencias del usuario (como el idioma preferido) y las cookies almacenadas para ese dominio.
4. Los servidores de Facebook reciben la solicitud y su código comienza a elaborar una respuesta.
• Facebook utilizará la información transmitida, incluidas las cookies, para determinar quién es el usuario y qué información enviar
5. Facebook devuelve una respuesta HTTP que incluye una línea de estado (200 OK, etc.). Encabezados que incluyen tipo de contenido, etc. y el cuerpo HTML.
6. El navegador recibe la Respuesta y comienza a analizarla para mostrarla.
• El cuerpo HTML incluirá enlaces a CSS, JS e imágenes. Todo esto activará llamadas adicionales a los servidores para recuperar esos bits
7. El motor de diseño del navegador comenzará a armar la página final para su visualización.
• La información CSS puede alterar el diseño y el aspecto de la página.
• JS y DHTML pueden alterar el diseño de la página
8. La página final se ensambla y se presenta al usuario final.

El artículo de Wikipedia Wikipedia Hyper Text Protocol es un buen punto de partida para el ciclo de vida de una solicitud HTTP.

Esta es, con mucho, la respuesta más brillante y completa que he encontrado para esta pregunta:

Mareante pero profundidad invisible

Acabas de ir a la página de inicio de Google.

Simple, ¿no es así?

¿Qué acaba de pasar?

Bueno, cuando sabes un poco sobre cómo funcionan los navegadores, no es tan simple. Acaba de poner en juego HTTP, HTML, CSS, ECMAscript y más. Esas son en realidad tecnologías tan increíblemente complejas que harán que cualquier ingeniero se maree si piensa demasiado en ellas, y de tal manera que ninguna compañía pueda lidiar con toda esa complejidad.

Simplificamos

Acabas de conectar tu computadora a http://www.google.com .

Simple, ¿no es así?

¿Qué acaba de pasar?

Bueno, cuando sabes un poco sobre cómo funcionan las redes, no es tan simple. Acaba de poner en juego DNS, TCP, UDP, IP, Wifi, Ethernet, DOCSIS, OC, SONET y más. Esas son en realidad tecnologías tan increíblemente complejas que harán que cualquier ingeniero se maree si piensa demasiado en ellas, y de tal manera que ninguna compañía pueda lidiar con toda esa complejidad.

Simplificamos

Acaba de escribir http://www.google.com en la barra de ubicación de su navegador.

Simple, ¿no es así?

¿Qué acaba de pasar?

Bueno, cuando sabes un poco sobre cómo funcionan los sistemas operativos, no es tan simple. Acaba de poner en juego un kernel, una pila de host USB, un despachador de entrada, un controlador de eventos, un indicador de fuente, un rasterizador de subpíxeles, un sistema de ventanas, un controlador de gráficos y más, todos aquellos escritos en alto – lenguajes de nivel que procesan compiladores, enlazadores, optimizadores, intérpretes y más. Esas son en realidad tecnologías tan increíblemente complejas que harán que cualquier ingeniero se maree si piensa demasiado en ellas, y de tal manera que ninguna compañía pueda lidiar con toda esa complejidad.

Simplificamos

Acabas de presionar una tecla en tu teclado.

Simple, ¿no es así?

¿Qué acaba de pasar?

Bueno, cuando sabes un poco sobre cómo funcionan los periféricos de entrada, no es tan simple. Acaba de poner en juego un regulador de potencia, un antirrebote, un multiplexor de entrada, una pila de dispositivos USB, una pila de concentrador USB, todo eso implementado en un solo chip. Ese chip está construido alrededor de obleas en rodajas finas de lingotes de silicio monocristalino altamente purificadas, dopadas con pequeñas cantidades de otros átomos que son arrojados a la estructura cristalina, interconectados con múltiples capas de aluminio o cobre, que se depositan de acuerdo con patrones de alta calidad. Luz ultravioleta de energía que se enfoca con una precisión de una fracción de micra, conectada al mundo exterior a través de delgados hilos de oro, todo dentro de un embalaje hecho de una resina dimensional y térmicamente estable. Los patrones de dopaje y las interconexiones implementan transistores, que se agrupan para crear puertas lógicas. En algunas partes del chip, las puertas lógicas se combinan para crear funciones aritméticas y bit a bit, que se combinan para crear una ALU. En otra parte del chip, las puertas lógicas se combinan en bucles biestables, que se alinean en filas, que se combinan con selectores para crear un banco de registro. En otra parte del chip, las puertas lógicas se combinan en controladores de bus y decodificadores de instrucciones y microcódigo para crear un programador de ejecución. En otra parte del chip, se combinan en multiplexores de dirección y datos y circuitos de temporización para crear un controlador de memoria. Hay aún más. Esas son en realidad tecnologías tan increíblemente complejas que harán que cualquier ingeniero se maree si piensa demasiado en ellas, y de tal manera que ninguna compañía pueda lidiar con toda esa complejidad.

¿Podemos simplificar más?

De hecho, muy aterrador, no, no podemos. Apenas podemos comprender la complejidad de un solo chip en un teclado de computadora y, sin embargo, no hay un nivel más simple. El siguiente paso nos lleva al software que se utiliza para diseñar la lógica del chip, y ese software en sí tiene un nivel de complejidad que requiere volver al principio del ciclo.

Las computadoras de hoy son tan complejas que solo pueden diseñarse y fabricarse con computadoras un poco menos complejas. A su vez, las computadoras utilizadas para el diseño y la fabricación son tan complejas que solo pueden diseñarse y fabricarse con computadoras un poco menos complejas. Tendría que pasar por muchos de estos bucles para volver a un nivel que posiblemente podría reconstruirse desde cero.

Una vez que comienza a comprender cómo funcionan nuestros dispositivos modernos y cómo se crean, es imposible no sentirse mareado por la profundidad de todo lo que está involucrado, y no estar asombrado por el hecho de que funcionan en absoluto, cuando la ley de Murphy dice que simplemente no deberían funcionar.

Para los no tecnólogos, todo esto es una caja negra. Ese es un gran éxito de la tecnología: todas esas capas de complejidad están completamente ocultas y las personas pueden usarlas sin siquiera saber que existen. Esa es la razón por la cual muchas personas pueden encontrar las computadoras tan frustrantes de usar: hay tantas cosas que posiblemente pueden salir mal que algunas de ellas inevitablemente ocurrirán, pero la complejidad es tan profunda que es imposible que la mayoría de los usuarios puedan hacer algo sobre cualquier error

Por eso también es tan difícil para los tecnólogos y los no tecnólogos comunicarse juntos: los tecnólogos saben demasiado sobre demasiadas capas y los no tecnólogos saben muy poco sobre muy pocas capas para poder establecer una comunicación directa efectiva. La brecha es tan grande que ya ni siquiera es posible que una sola persona sea un intermediario entre esos dos grupos, y es por eso que, por ejemplo, terminamos con esos centros de llamadas de soporte técnico enrevesados ​​y sus múltiples niveles. Sin estas estructuras de soporte tan profundas, terminas con la situación frustrante que vemos cuando los usuarios finales tienen acceso a una base de datos de errores que utilizan directamente los ingenieros: ni los usuarios finales ni los ingenieros obtienen la información que necesitan para lograr sus objetivos.

Es por eso que la prensa convencional y la población en general han hablado tanto sobre la muerte de Steve Jobs y comparativamente tan poco sobre la de Dennis Ritchie: la influencia de Steve estaba en un nivel que la mayoría de la gente podía ver, mientras que la de Dennis era mucho más profunda. Por un lado, puedo imaginar dónde estaría el mundo de la informática sin el trabajo que hizo Jobs y las personas que él inspiró: probablemente un poco menos brillante, un poco más beige, un poco más cuadrado. Sin embargo, en el fondo, nuestros dispositivos seguirían funcionando de la misma manera y harían lo mismo. Por otro lado, literalmente no puedo imaginar dónde estaría el mundo de la informática sin el trabajo que hizo Ritchie y las personas que inspiró. A mediados de los años 80, la influencia de Ritchie se había apoderado, e incluso en aquel entonces quedaba muy poco del mundo anterior a Ritchie.

Finalmente, por último pero no menos importante, es por eso que nuestro sistema de patentes está roto: la tecnología ha hecho un trabajo tan sorprendente al ocultar su complejidad que las personas que regulan y administran el sistema de patentes apenas son conscientes de la complejidad de lo que están regulando y corriendo. Ese es el mejor cambio de bicicletas: al igual que las discusiones proverbiales en el ayuntamiento sobre una planta de energía nuclear terminan siendo sobre el color de la pintura para el cobertizo de bicicletas de la planta, las discusiones sobre patentes sobre los sistemas informáticos modernos terminan siendo sobre el tamaño de la pantalla y el orden de los iconos, porque en ambos casos, ese es el único aspecto que las personas involucradas en la discusión son capaces de discutir, a pesar de que son irrelevantes para la función real del sistema general que se está discutiendo.

Fuente: profundidad vertiginosa pero invisible

Cuando presionamos el botón Intro, suceden las siguientes cosas en cuestión de segundos:

1. El navegador envía la dirección web a un servidor DNS que la traduce a la dirección IP correspondiente. Esto se envía de vuelta al navegador (cliente).
2. El navegador envía una solicitud al servidor solicitando páginas html, atributos, scripts e imágenes.
3. El servidor responde enviando los datos requeridos en forma de paquetes. Los paquetes se serializan y numeran para el navegador de destino.
4. A medida que entran los paquetes, el navegador intenta hacer uso de lo que haya llegado y decodifica y muestra la página web resultante.

Tan increíble verdad!

Mucho, depende de qué tan profundo quieras ir detallando:

Paso 1: solicitar un registro

Comienza pidiéndole a su computadora que resuelva un nombre de host, como visitar ‘ Google ‘ en un navegador web. El primer lugar donde se ve su computadora es su caché de DNS local, que almacena la información de DNS que la computadora ha recuperado recientemente.

Paso 2: pregunte a los servidores DNS recursivos

Si los registros no se almacenan localmente, su computadora consulta (o contacta) los servidores DNS recursivos de su ISP. Estas máquinas realizan el trabajo preliminar de las consultas DNS en nombre de sus clientes. Los servidores DNS recursivos tienen sus propios cachés, que verifican antes de continuar con la consulta.

Paso 3: Pregunte a los servidores DNS raíz

Si los servidores DNS recursivos no tienen el registro en caché, se ponen en contacto con los servidores de nombres raíz. Estos trece servidores de nombres contienen punteros para todos los dominios de nivel superior (TLD), como ‘.com’, ‘.net’ y ‘.org’. Si está buscando ‘Google.’, Los servidores de nombres raíz buscan en el TLD el dominio (‘Google’) y dirigen la consulta a los servidores de nombres DNS de TLD responsables de todos los punteros ‘.com’.

Paso 4: pregunte a los servidores DNS de TLD

Los servidores DNS de TLD no almacenan los registros DNS para dominios individuales; en cambio, realizan un seguimiento de los servidores de nombres autorizados para todos los dominios dentro de su TLD. Los servidores DNS de TLD miran la siguiente parte de la consulta de derecha a izquierda – ‘Google’ – luego dirigen la consulta a los servidores de nombres autorizados para ‘Google’.

Paso 5: pregunte a los servidores DNS autorizados

Los servidores de nombres autorizados contienen todos los registros DNS para un dominio determinado, como registros de host (que almacenan direcciones IP), registros MX (que identifican servidores de nombres para un dominio), etc. Como está buscando la dirección IP de ‘Google’, el servidor recursivo consulta a los servidores de nombres autorizados y solicita el registro de host de ‘Google’.

Paso 6: Recuperando el registro

El servidor DNS recursivo recibe el registro de host para ‘Google’ de los servidores de nombres autorizados y almacena el registro en su caché local. Si alguien más solicita el registro de host para ‘Google’, los servidores recursivos ya tendrán la respuesta y no necesitarán pasar por el proceso de búsqueda nuevamente hasta que el registro caduque del caché.

Paso 7: ¡La respuesta!

Finalmente, el servidor recursivo devuelve el registro de host a su computadora. Su computadora almacena el registro en su caché, lee la dirección IP del registro y luego pasa esta información al navegador web. Luego, su navegador abre una conexión a la dirección IP ’72 .14.207.99 ‘en el puerto 80 (para HTTP), y nuestro servidor web pasa la página web a su navegador, que muestra Google.

Cuando ingrese la URL, la aplicación del navegador verificará la caché DNS para su dirección IP. Si no hay ninguno presente, el navegador creará una solicitud DNS que se enviará a su servidor DNS local como un paquete UDP / IP. El DNS local verificará su caché y si la IP de la URL solicitada no está presente, realizará consultas iterativas o recursivas a los servidores raíz y autorizados. Recibirá la dirección IP como respuesta de una consulta DNS y la reenviará a su máquina.

Una vez que la aplicación del navegador recibe la dirección IP, creará un socket TCP y se conectará al servidor remoto con esta dirección IP. Todos los paquetes de su máquina serán enrutados por su enrutador a la red externa. Tenga en cuenta que su enrutador realizará NAT y modificará los encabezados de capa 2 para el enrutamiento hop-hop.

La conexión TCP se establecerá después del protocolo de enlace TCP de 3 vías entre su computadora y el servidor remoto. Luego, podrá acceder al sitio web y sus contenidos. Tenga en cuenta que, en las aplicaciones que requieren autenticación (capa de seguridad), habría una comunicación cifrada de credenciales para autenticarlo.

En primer lugar, comencemos por comprender cómo nos conectamos a Internet para que podamos solicitar páginas web como amazon.com. Cada computadora conectada a Internet necesita una DIRECCIÓN IP. Esta dirección IP es única para cualquier computadora conectada a Internet (en una red local Para, por ejemplo, un grupo de amigos que usan el mismo enrutador wifi, es la dirección IP del enrutador lo que es único). Existe una idea errónea de que la DIRECCIÓN IP que ve cuando abre la lista de los dispositivos conectados a Internet desde el mismo enrutador es la dirección IP única, pero no, es exclusiva de la red privada que es su red doméstica. Muchas otras computadoras pueden tener la misma dirección IP al mismo tiempo cuando están en otras redes Entonces, cuando ve una dirección IP como 192.168.1.1, no tiene que gritar que nadie más conectado a Internet tiene la misma dirección IP. Esta es su dirección IP privada. Su dirección MAC es única y sí. puedes decir con seguridad que tu dirección mac es la única dirección mac conectada a internet en cualquier momento.

Ahora volviendo a la dirección IP del enrutador que se asigna dinámicamente usando el protocolo DHCP cada vez que desea conectarse a Internet. DHCP viene junto con el software de red del conjunto de protocolos TCP / IP.

DHCP es parte de la capa de aplicación y asigna a un enrutador una DIRECCIÓN IP única durante un tiempo en un contrato de arrendamiento. Este número único se asigna desde el conjunto de direcciones disponibles con su proveedor de servicios de Internet en el servidor DHCP.

Ahora que está conectado a Internet, solicitará la página web de Amazon. El navegador ahora se comunica con el caché del navegador para verificar si este sitio ha sido visitado previamente y si tiene la dirección IP del sitio web. busca en el caché del sistema operativo, el caché del enrutador, el caché DNS del ISP y luego comienza una búsqueda recursiva en el servidor DNS del ISP hasta que encuentra la dirección IP requerida. Después de obtener la IP, el navegador envía una solicitud HTTP al servidor web. El servidor envía una respuesta HTML al cliente. El navegador ahora comienza a procesar el HTML y envía la solicitud de objetos incrustados en HTML a medida que muchos sitios entregan su CSS, Imágenes, archivos y scripts de una red de entrega de contenido ( CDN ). El navegador enviará nuevamente la solicitud HTTP GET para cada una de las URL incrustadas, que nuevamente sigue el mismo procedimiento de búsqueda y otros pasos mencionados anteriormente. Después de esto, el navegador puede enviar más solicitudes de AJAX para comunicarse con el servidor web incluso después de que la página se muestre.

( https://www.tutorialspoint.com/w …)

Un usuario ingresa una URL en un navegador (por ejemplo, Google .com. Esta solicitud se pasa a un servidor de nombres de dominio).

El servidor de nombres de dominio devuelve una dirección IP para el servidor que aloja el sitio web (por ejemplo, 68.178.157.132).

El navegador solicita la página del servidor web utilizando la dirección IP especificada por el servidor de nombres de dominio.

El servidor web devuelve la página a la dirección IP especificada por el navegador que solicita la página. La página también puede contener enlaces a otros archivos en el mismo servidor, como imágenes, que el navegador también solicitará.

El navegador recopila toda la información y la muestra en su computadora en forma de página web.

Para comprender el intrincado funcionamiento de una resolución de nombre de host, primero deberá examinar los siguientes términos:
1. URI: Identificador único de recursos (identificador uniforme de recursos)
2. Nombre de host (nombre de host)
3. Nombre de dominio (nombre de dominio)
4. Diferencia entre un nombre de dominio y un nombre de host (direcciones IP, nombres de host y nombres de dominio)
5. TLD ( http://en.wikipedia.org/wiki/Top …)
5. Servidor de nombres autorizado (¿Qué es el servidor de nombres autorizado?)

Una explicación abstracta:

Entonces, lo que básicamente sucede es que un URI se resuelve de derecha a izquierda.
ejemplo: ” http: //www.ex.com.&quot ; Aquí el último punto se refiere al servidor de nombres raíz, por lo que la primera consulta debe ir al servidor de nombres raíz solicitando la dirección IP del nombre de host requerido.
El servidor de nombres raíz redirige la consulta al TLD “.com” que a su vez redirige la consulta a otro servidor.
Ahora ingresa el servidor de nombres “ex.com”. Este es el servidor que contiene el archivo de hosts que tiene la entrada de dirección IP correspondiente al nombre de host requerido. Y finalmente, esta IP se envía de vuelta al cliente.

Ahora en la práctica, se manejan billones de consultas cada día y no es factible contactar al servidor de nombres raíz para cada consulta. Por lo tanto, se utiliza el almacenamiento en caché. El nivel de almacenamiento en caché puede variar de la memoria caché del navegador, la memoria caché del sistema operativo, la memoria caché DNS local, los servidores de caché DNS, etc.

Aumentando la respuesta anterior de Shanmugasundaram-Muthuswamy
Si vamos más abajo en el camino “técnico”. HTTP está diseñado sobre TCP IP, por lo que una vez que se resuelva la dirección IP de Google, se realizará un apretón de manos tcp.
Dado que Google tiene por defecto HTTPS, también se realizará un protocolo de enlace SSL, y se intercambiará la clave pública, que se utilizará para cifrar / descifrar más solicitudes.

Técnicamente, hacer una solicitud HTTP se puede explicar de manera diferente en todas las diferentes capas de la red.

Primero, necesita la dirección IP del servidor. Si ha visitado ese sitio anteriormente, es posible que su navegador haya almacenado en caché la dirección (o incluso toda la página). Si no, lo primero que debe hacer su navegador es enviar una solicitud a un servidor DNS. Si el servidor DNS lo tiene en caché, responderá con la dirección. De lo contrario, se conectará a otro servidor DNS para que pueda escalar su solicitud.

Una vez que el navegador conoce la dirección, intercambiará algunos paquetes con el servidor para abrir una conexión TCP, y luego realizará una solicitud HTTP para el archivo especificado en la URL. Si todo va bien, el servidor devolverá el archivo.

Si el archivo es HTML, puede hacer referencia a otros archivos, como CSS, JS, imágenes, etc. El navegador realizará solicitudes por separado al servidor para esos.

Finalmente, el navegador lee el HTML y lo muestra en la pantalla (un proceso muy complicado en sí mismo).

Pasé por alto muchos detalles, pero ese es el panorama general.

Los siguientes pasos son: –

1. Primero, el navegador verifica el caché; Si el objeto solicitado está en caché y es nuevo, continúa con el paso 9
2. el navegador solicita al sistema operativo o al navegador la dirección IP del servidor (almacenada en la memoria caché)
3. El sistema operativo realiza una búsqueda de DNS y responde la dirección IP al navegador
4. el navegador abre una conexión TCP al servidor (este paso es mucho más complejo con HTTPS)
5. el navegador envía la solicitud HTTP a través de la conexión TCP
6. el navegador recibe una respuesta HTTP y puede cerrar la conexión TCP o reutilizarla para otra solicitud
7. el navegador verifica si la respuesta es una redirección o una respuesta condicional (códigos de estado de resultado 3xx), solicitud de autorización (401), error (4xx y 5xx), etc .; estos se manejan de manera diferente a las respuestas normales (2xx)
8. si se puede almacenar en caché, la respuesta se almacena en caché.
9. El navegador decodifica la respuesta.
10. el navegador determina qué hacer con la respuesta (por ejemplo, ¿es una página HTML, es una imagen, es un clip de sonido?)
11. El navegador luego usa el analizador HTML para volver a crear la estructura del documento que luego se le presentará en la pantalla. Si encuentra referencias a recursos externos, como imágenes, archivos css, archivos javascript, estos se entregan de la misma manera que el documento HTML.

Paso 1: el usuario escribe la url del sitio.

Paso 2: Inicialmente, la dirección IP respectiva de la url se verifica en la memoria caché del navegador si la dirección IP ya está almacenada en caché y luego se lleva a cabo la siguiente acción:

i) El navegador establece la conexión TCP entre el servidor IP obtenido y el navegador después de que las páginas web y los datos se procesan en el navegador y ahora el usuario puede comunicarse con el servidor utilizando los métodos GET y POST.

Y si la dirección IP de la url no está en la memoria caché del navegador, siga los siguientes pasos:

Paso 3: el navegador envía la solicitud al sistema operativo para buscar IP en su caché. Si la IP no está allí en el caché del sistema operativo, el sistema operativo envía la solicitud al servidor DNS y, si no se encuentra allí, nuevamente la solicitud se envía a otros servidores DNS, esto tiene lugar hasta que se obtenga la IP.

Paso 4: con la ayuda de IP obtenida en el navegador del Paso 3, configure la conexión TCP entre el servidor IP y el cliente.

Paso 5: Después de establecer la conexión, el navegador envía una solicitud HTTP GET al servidor y obtiene todos los archivos y datos necesarios.

Paso 6: Luego, el navegador obtiene la respuesta del servidor en forma de código de respuesta y datos. Se devuelven diferentes códigos de respuesta según el estado de la situación.

Paso 7: Después de la obtención exitosa de datos, el cliente puede interactuar con el sitio web utilizando la solicitud POST, como completar el formulario y enviarlo de nuevo al servidor.

Este proceso de solicitud y respuesta continúa hasta que el cliente cierra el sitio web.

1. el navegador verifica el caché; Si el objeto solicitado está en caché y es nuevo, salte al # 9
2. el navegador solicita al sistema operativo la dirección IP del servidor
3. El sistema operativo realiza una búsqueda de DNS y responde la dirección IP al navegador
4. el navegador abre una conexión TCP al servidor (este paso es mucho más complejo con HTTPS)
5. el navegador envía la solicitud HTTP a través de la conexión TCP
6. el navegador recibe una respuesta HTTP y puede cerrar la conexión TCP o reutilizarla para otra solicitud
7. el navegador verifica si la respuesta es una redirección o una respuesta condicional (códigos de estado de resultado 3xx), solicitud de autorización (401), error (4xx y 5xx), etc .; estos se manejan de manera diferente a las respuestas normales (2xx)
8. si se puede almacenar en caché, la respuesta se almacena en caché
9. respuesta de decodificación del navegador (por ejemplo, si está comprimido)
10. el navegador determina qué hacer con la respuesta (por ejemplo, ¿es una página HTML, es una imagen, es un clip de sonido?)
11. el navegador proporciona una respuesta u ofrece un cuadro de diálogo de descarga para tipos no reconocidos

Mira este video … Si aún no lo has hecho. Este video borrará la mayoría de sus consultas. Te aconsejaría que leyeras más sobre DNS.

Continuaré con la brillante respuesta de EO Stinson y explicaré un poco más de lo que sucede del lado del cliente después de que el navegador (¡ojalá!) Reciba el HTML de regreso del servidor …

1. En cuanto al análisis del HTML en sí, esto implica que el navegador convierta cada etiqueta (, , , etc.) que encuentre en ‘tokens’. Si tomáramos el de un documento HTML simple, por ejemplo, los tokens se verían así: ‘StartTag: head’, ‘Tag: meta’, ‘Tag: link’, ‘EndTag: head’.
2. A continuación, el navegador convierte esos tokens en objetos de nodo.
3. Al examinar la relación padre / hijo entre estos objetos de nodo recién creados, el navegador puede construir el modelo de objeto del documento, también conocido como DOM.
4. El navegador buscará cualquier CSS requerido y una vez que reciba una respuesta, creará el modelo de objeto CSS. Considere que se trata de un mapa de todos los selectores CSS necesarios y sus respectivas propiedades / valores. El CSSOM permite al navegador atravesar y aplicar CSS a elementos en el DOM cuando sea necesario.
5. El DOM y el CSSOM se combinan para crear el ‘árbol de renderizado’, una fusión de los dos modelos de objetos que incluye solo el contenido visible requerido para renderizar la página; por lo que, por ejemplo, no se incluirán elementos con su estilo establecido en ‘display: none’.
6. La siguiente etapa es ‘diseño’ (Chrome), también conocido como ‘reflujo’ (Firefox), que implica que el navegador calcule la ubicación y el tamaño de todos los elementos que se mostrarán dentro de la ventana gráfica.
7. El paso final se conoce como ‘pintar’ (Chrome) o ‘rasterizar’ (Firefox), e implica que el navegador convierta cada nodo en el árbol de renderizado a píxeles reales en la pantalla.

¡Suceden muchas cosas! Aquí hay un resumen general que omite muchos pasos.

1. La URL se traduce a una IP de destino (búsqueda de DNS). P.ej. mycoolwebsite.com -> 10.252.1.23
2. Se envía una solicitud (la información de su navegador, IP, cookies, etc.) al servidor utilizando la dirección IP resuelta.
3. El servidor (host del sitio web) devuelve el contenido del sitio web. Estos son archivos html, css, js, image, etc.
4. Su navegador web ejecuta muchas comprobaciones de seguridad y construye la página web.

Esto se explica bien en Lo que realmente sucede cuando navegas a una URL en el blog por Igor Ostrovsky en http://igoro.com/archive/what-re… .