Como desarrollador de software, definitivamente tendrá una comprensión completa y jerárquica de cómo funcionan las aplicaciones de red, y esto también incluye las tecnologías utilizadas en estas aplicaciones: como navegadores, HTTP, HTML, servidores web, procesamiento de requisitos, etc.
Este artículo estudiará más en profundidad lo que sucede en segundo plano cuando ingrese una URL ~
1. En primer lugar, debe ingresar la URL deseada en el navegador : 2. El navegador busca la dirección IP del nombre de dominioEl primer paso en la navegación es descubrir su dirección IP accediendo al nombre de dominio. El proceso de búsqueda de DNS es el siguiente:
Golpe de almacenamiento en caché: el navegador almacena en caché los registros de DNS por un período de tiempo. Curiosamente, el sistema operativo no le dice al navegador el tiempo para almacenar el registro DNS, de modo que diferentes navegadores almacenen un tiempo auto-fijo (que oscila entre 2 minutos y 30 minutos). Caché del sistema: si el registro requerido no se encuentra en el caché del navegador, el navegador hará una llamada del sistema (GethostByName en Windows). Esto le permite obtener registros en el caché del sistema. Cache del enrutador: a continuación, la solicitud de consulta anterior se envía al enrutador, que generalmente tiene su propio caché DNS. ISP DNS Cache: lo siguiente que debe verificar es el servidor donde el ISP almacena DNS. Aquí es donde generalmente se pueden encontrar los registros de caché correspondientes. Búsqueda recursiva: el servidor DNS de su ISP comienza con el servidor de nombres de dominio, desde el servidor de nombre de dominio de nivel superior .com hasta el servidor de nombres de dominio de Facebook. En general, habrá nombres de dominio en el servidor de nombres de dominio .com en el caché de los servidores DNS, por lo que el proceso de coincidencia con el servidor de nivel superior no es tan necesario.La búsqueda recursiva de DNS se muestra en la figura a continuación:
DNS es un poco preocupante, es decir, todo el nombre de dominio como wikipedia.org o facebook.com parece corresponder a una dirección IP separada. Afortunadamente, hay varias formas de eliminar este cuello de botella:
Loop DNS es la solución al devolver múltiples IP cuando DNS busca. Por ejemplo, Facebook.com en realidad corresponde a cuatro direcciones IP. Un equilibrador de carga es un dispositivo de hardware que escucha una dirección IP específica y reenvía las solicitudes de red a un servidor de clúster. Algunos sitios grandes generalmente usan este costoso equilibrador de carga de alto rendimiento. El DNS geográfico mejora la escalabilidad al mapear los nombres de dominio a múltiples direcciones IP diferentes en función de la ubicación geográfica del usuario. De esta manera, diferentes servidores no pueden actualizar el estado de sincronización, pero es muy bueno mapear el contenido estático. Anycast es una tecnología de enrutamiento que mapea múltiples hosts físicos con direcciones IP. El único inconveniente es que el protocolo de cualquier Cast y TCP no se adapta bien, por lo que rara vez se usan en esas soluciones.La mayoría de los servidores DNS usan cualquier CASTCAS para obtener búsquedas DNS eficientes y de baja latencia.
3. El navegador envía una solicitud HTTP al servidor webDebido a las páginas dinámicas como las páginas de inicio de Facebook, expirarán pronto e incluso inmediatamente en el caché del navegador después de la apertura, y no hay duda de que no pueden leerlas.
Entonces, el navegador enviará una solicitud al servidor donde se encuentra Facebook:
Obtenga http://facebook.com/ http/1.1Aceptar: Aplicación/Aplicación X-MS, Image/JPEG, Aplicación/XAML+XML, [...]
Agente de usuario: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; wow64; [...]
Aceptación de aceptación: GZIP, desinflar
Conexión: mantener alive
Anfitrión: Facebook.com
Cookie: DATR = 1265876274-[...]; locale = en_us; lsd = ww [...]; c_user = 2101 [...]
Obtenga esta solicitud define la URL que se lee: http://facebook.com/. El navegador en sí define (encabezado de agente de usuario ), y qué tipo de encabezado correspondiente ( aceptar y codificar ) quiere aceptar. El encabezado de conexión requiere que el servidor no cierre la conexión TCP para solicitudes posteriores.
La solicitud también contiene cookies para el nombre de dominio almacenado por el navegador. Es posible que ya sepa que en diferentes solicitudes de página, las cookies son valores clave que coinciden con el estado de un sitio web. De esta manera, las cookies almacenarán el nombre de usuario de inicio de sesión, la contraseña asignada por el servidor y algunas configuraciones de usuario. Las cookies se almacenan en el cliente como un documento de texto y se envían al servidor cada vez que solicitan.
Hay muchas herramientas para ver la solicitud HTTP original y sus herramientas correspondientes. El autor prefiere usar Fiddler y, por supuesto, hay otras herramientas como Firebug. Este software puede ser de gran ayuda al optimizar el sitio web.
Además de obtener solicitudes, hay otro tipo de solicitud que se envía, que a menudo se usa al enviar formularios. Envíe una solicitud para pasar sus parámetros a través de la URL (por ejemplo: http://robozzle.com/puzzle.aspx?id=85). Enviar la solicitud envía sus parámetros después del encabezado del cuerpo de la solicitud.
Las barras como http://facebook.com/ son cruciales. En este caso, el navegador puede agregar barras de manera segura. Para direcciones como http://example.com/folderororfile, debido a que el navegador no sabe si FoolerOrFile es una carpeta o un archivo, no puede agregar automáticamente cortes. En este momento, el navegador accederá directamente a la dirección sin cortar, y el servidor responderá a una redirección, lo que resulta en un apretón de manos innecesario.
4. Respuesta de redirección permanente del servicio de FacebookLa imagen muestra la respuesta enviada al navegador por el servidor de Facebook:
Http/1.1 301 se movió permanentementeCache-Control: privado, sin almacén, no-cache, debe revalidar, post-check = 0,
Pre-verificación = 0
Expira: sábado, 01 de enero de 2000 00:00:00 GMT
Ubicación: http://www.facebook.com/
P3P: CP = Ley DSP
Pragma: no cache
Set-Cookie: Made_Write_Conn = eliminado; expiras = thu, 12-feb-2009 05:09:50 gmt;
ruta =/; dominio = .facebook.com; httponly
Tipo de contenido: texto/html; Charset = UTF-8
X-Cnection: Cerrar
Fecha: Vie, 12 de febrero de 2010 05:09:51 GMT
Contenido-longitud: 0
El servidor responde a una respuesta de redirección permanente 301, para que el navegador visite http://www.facebook.com/ en lugar de http://facebook.com/.
¿Por qué el servidor tiene que redirigir en lugar de enviar directamente el contenido web que los usuarios quieren ver? Hay muchas respuestas interesantes a esta pregunta.
Una de las razones está relacionada con las clasificaciones de motores de búsqueda. Verá, si una página tiene dos direcciones, como http://www.igoro.com/ y http://igoro.com/, los motores de búsqueda los considerarán como dos sitios web, lo que resulta en una disminución en los enlaces de búsqueda para cada uno y bajando así las clasificaciones. Los motores de búsqueda saben lo que significa 301 redirección permanente, por lo que clasificarán el acceso a las direcciones con www y sin www en la misma clasificación del sitio web.
Otra cosa es que el uso de diferentes direcciones hará que la amabilidad de los caché empeore. Cuando una página tiene varios nombres, puede aparecer varias veces en el caché.
5. Dirección de redirección de rastreo del navegadorAhora, el navegador sabe que http://www.facebook.com/ es la dirección correcta a acceder, por lo que enviará otra solicitud GET:
Obtener http://www.facebook.com/ http/1.1Aceptar: Aplicación/Aplicación X-MS, Image/JPEG, Aplicación/XAML+XML, [...]
Aceptar el idioma: EN-US
Agente de usuario: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; wow64; [...]
Aceptación de aceptación: GZIP, desinflar
Conexión: mantener alive
Cookie: LSD = XW [...]; c_user = 21 [...]; x-referer = [...]
Host: www.facebook.com
La información del encabezado tiene el mismo significado que en la solicitud anterior.
6. El servidor maneja la solicitudEl servidor recibe la solicitud de búsqueda, luego procesa y devuelve una respuesta.
Esta parece ser una tarea avanzada en la superficie, pero de hecho, hay muchas cosas interesantes que suceden en el medio: ¡un sitio web simple como el blog del autor, y mucho menos un sitio web como Facebook!
Software del servidor web El software del servidor web (como IIS y Apache) recibe una solicitud HTTP y luego determina qué procesamiento de solicitud se realiza para manejarlo. El procesamiento de solicitudes es un programa que puede leer la solicitud y generar HTML para responder (como ASP.NET, PHP, Ruby ...).Para dar el ejemplo más simple, el procesamiento de requisitos se puede almacenar en una jerarquía de archivos que mapea la estructura de direcciones del sitio. La dirección como http://example.com/folder1/page1.aspx asignará el archivo /httpdocs/folder1/page1.aspx. El software del servidor web se puede configurar para ser el procesamiento de solicitudes correspondiente manualmente por la dirección, de modo que la dirección de publicación de Page1.aspx pueda ser http://example.com/folder1/page1.
Procesamiento de solicitud La solicitud maneja la solicitud de lectura y sus parámetros y cookies. Leerá y actualizará algunos datos y dirá que los datos se almacenan en el servidor. El procesamiento de requisitos luego genera una respuesta HTML.Todos los sitios web dinámicos enfrentan una dificultad interesante: cómo almacenar datos. La mitad de los sitios web pequeños tendrán una base de datos SQL para almacenar datos. El almacenamiento de grandes cantidades de datos y/o sitios web muy visitados tiene que encontrar algunas formas de asignar la base de datos a múltiples máquinas. Las soluciones incluyen: fragmentación (basado en valores clave primarios, las tablas de datos se dispersan en múltiples bases de datos), replicación y bases de datos simplificadas que utilizan una consistencia semántica débil.
Delegar el trabajo al procesamiento por lotes es una tecnología barata para mantener los datos actualizados. Por ejemplo, Facebook necesita actualizar las noticias a tiempo, pero las funciones de las personas que puede conocer con el soporte de datos solo necesitan actualizarse todas las noches (el autor adivina que es, se desconoce cómo mejorar la función). Las actualizaciones de trabajo por lotes pueden hacer que algunos datos menos importantes estén desactualizados, pero pueden hacer que las actualizaciones de datos sean más rápidas y concisas.
7. El servidor envía una respuesta HTMLLa imagen es la respuesta generada y devuelta por el servidor:
Http/1.1 200 OKCache-Control: privado, sin almacén, no-cache, debe revalidar, post-check = 0,
Pre-verificación = 0
Expira: sábado, 01 de enero de 2000 00:00:00 GMT
P3P: CP = Ley DSP
Pragma: no cache
Encodificación de contenido: GZIP
Tipo de contenido: texto/html; Charset = UTF-8
X-Cnection: Cerrar
Ecodificación de transferencia: fortado
Fecha: Vie, 12 de febrero de 2010 09:05:55 GMT
2b3tn@[...]
El tamaño de respuesta completo es de 35 kb, la mayoría de los cuales se transfieren como tipo de blob después de la clasificación.
El terminal de codificación de contenido le dice al navegador que todo el cuerpo de respuesta se comprime usando el algoritmo GZIP. Después de descomprimir el bloque Blob, puede ver el HTML esperado de la siguiente manera:<! Doctype html público -// w3c // dtd xhtml 1.0 Strict // eshttp://www.w3.org/tr/xhtml1/dtd/xhtml1-strict.dtd>
<html xmlns = http: //www.w3.org/1999/xhtml xml: lang = en
lang = en id = Facebook class = no_js>
<Evista>
<meta http-oquiv = content-type content = text/html; charset = utf-8 />
<meta http-oquiv = content-language content = en />
...
Con respecto a la compresión, la información del encabezado explica si esta página está almacenada en caché, cómo hacerlo si se almacena en caché, qué cookies se deben establecer (este punto no se encuentra en la respuesta anterior), información de privacidad, etc.
Tenga en cuenta que el tipo de contenido está configurado en texto/html en el encabezado. El encabezado permite que el navegador represente el contenido de respuesta en HTML en lugar de descargarlo en el formulario de archivo. El navegador decidirá cómo interpretar la respuesta basada en la información del encabezado, pero también considerará otros factores como el contenido de extensión de URL.
8. El navegador comienza a mostrar HTMLCuando el navegador no acepta completamente todos los documentos HTML, comienza a mostrar esta página:
9. El navegador envía para obtener objetos incrustados en HTMLCuando el navegador muestra HTML, nota las etiquetas que necesitan obtener el contenido de otras direcciones. En este momento, el navegador enviará una solicitud GET para recuperar los archivos.
Aquí hay algunas URL que necesitamos para volver a realizar cuando visitamos Facebook.com:
imagen http://static.ak.fbcdn.net/rsrc.php/z12e0/hash/8q2anwu7.gifhttp://static.ak.fbcdn.net/rsrc.php/zbs5c/hash/7hwy7at6.gif
... mesa de estilo CSS
http://static.ak.fbcdn.net/rsrc.php/z448z/hash/2plh8s4n.css
http://static.ak.fbcdn.net/rsrc.php/zane1/hash/cvtutcee.css
... archivos JavaScript
http://static.ak.fbcdn.net/rsrc.php/zemoa/hash/c8yzb6ub.js
http://static.ak.fbcdn.net/rsrc.php/z6r9l/hash/cq2lgbs8.js
…
Todas estas direcciones pasan por un proceso similar a la lectura HTML. Entonces, el navegador buscará estos nombres de dominio en DNS, enviará solicitudes, redireccionamientos, etc.
Pero a diferencia de las páginas dinámicas, los archivos estáticos permiten que el navegador se almacene en caché. Es posible que algunos archivos no necesiten comunicarse con el servidor y se leen directamente desde el caché. La respuesta del servidor contiene la información de la fecha límite para los archivos estáticos, por lo que el navegador sabe cuánto tiempo deben almacenarse en caché. Además, cada respuesta puede contener un encabezado ETAG (el valor de la entidad de la variable solicitada) que funciona como el número de versión. Si el navegador observa que la información de la versión ETAG del archivo ya existe, la transferencia del archivo se detendrá de inmediato.
¿Intenta adivinar qué representa fbcdn.net en la dirección? La respuesta inteligente es la red de distribución de contenido de Facebook. Facebook usa la red de distribución de contenido (CDN) para distribuir archivos estáticos como imágenes, tablas CSS y archivos JavaScript. Por lo tanto, estos archivos estarán respaldados en muchos centros de datos de CDN en todo el mundo.
El contenido estático a menudo representa el tamaño del ancho de banda del sitio y también se puede copiar fácilmente a través de un CDN. Por lo general, los sitios web usan CDN de terceros. Por ejemplo, los archivos estáticos de Facebook son alojados por Akamai, el mayor proveedor de CDN.
Por ejemplo, cuando intenta hacer ping static.ak.fbcdn.net, puede obtener una respuesta de cierto servidor AKAMAI.NET. Curiosamente, cuando vuelves a hacer ping, el servidor de respuesta puede ser diferente, lo que significa que la carga de equilibrio detrás de escena está comenzando a funcionar.
10. El navegador envía una solicitud asíncrona (AJAX)Guiado por el Gran Espíritu de Web 2.0, el cliente permanece en contacto con el servidor después de que se complete la pantalla de la página.
Tome la función de chat de Facebook como ejemplo, se mantendrá en contacto con el servidor para actualizar su estado de amigos brillantes y grises de manera oportuna. Para actualizar el estado de amigo de estos avatares, el código JavaScript ejecutado en el navegador enviará una solicitud asíncrona al servidor. Esta solicitud asíncrona se envía a una dirección específica, que es una solicitud de búsqueda o envío de productos construidos en el programa. O en el ejemplo de Facebook, el cliente envía una solicitud a http://www.facebook.com/ajax/chat/buddy_list.php para obtener la información de estado de la que en línea en su amigo.
Cuando se trata de este patrón, debemos hablar sobre Ajax, JavaScript y XML asíncrono. Aunque no hay una razón clara por la que el servidor responde en formato XML. Déjame darte otro ejemplo. Para solicitudes asíncronas, Facebook devolverá algunos fragmentos de código JavaScript.
Entre otras cosas, la herramienta Fiddler le permite ver solicitudes asincrónicas enviadas por su navegador. De hecho, no solo puede servir pasivamente como espectador de estas solicitudes, sino también atacar activamente para modificarlas y reenviarlas. Las solicitudes de AJAX son muy fáciles de ser engañadas, pero realmente hacen que esos desarrolladores de juegos en línea que obtienen puntajes están deprimidos. (Por supuesto, no mientas a otros así ~)
La función de chat de Facebook proporciona un caso interesante de AJAX: presionar los datos del servidor al cliente. Debido a que HTTP es un protocolo de respuesta de solicitud, el servidor de chat no puede enviar nuevos mensajes al cliente. En cambio, el cliente tiene que sondear el lado del servidor cada pocos segundos para ver si hay alguna noticia nueva.
La encuesta para estas situaciones es una técnica interesante para reducir la carga del servidor. Si el servidor no tiene mensajes nuevos cuando se encuesta, ignora el cliente. Cuando el nuevo mensaje del cliente aún no se ha agotado, el servidor encontrará la solicitud inacabada y devolverá el nuevo mensaje al cliente como respuesta.