Análisis de las características de la red utilizando JavaScript y DOM, Parte 2

 

 

 

  • ¡Registro!
  • Taller de diseño conductual, con Susan y Guthrie Weinschenk

  • Índice
    1. DNS explicado
    2. Medición de los tiempos de búsqueda de DNS
    3. Medición del soporte y la latencia de IPv6
    4. La API de sincronización de navegación
    5. La API de información de red
    6. Resumen
      1. Referencias
      2. Otras lecturas

    La API de sincronización de navegación proporciona fácil acceso a información precisa sobre la sincronización de la página, pero aún es insuficiente para obtener una imagen completa. Ya sea que necesitemos admitir navegadores que actualmente no implementan Navigation Timing u obtener información sobre recursos no incluidos en la página actual, asegúrese de obtener más información sobre el ancho de banda de la red del usuario o si su soporte para IPv6 es mejor o peor que su soporte. para IPv4. Todas las técnicas presentadas aquí se desarrollaron mientras se escribía Boomerang, aunque no todas llegaron al código todavía.

     

    En la Parte 1 de esta serie, analizamos cómo funcionan los protocolos subyacentes de la Web y cómo podemos usar JavaScript para estimar sus características de rendimiento. En esta segunda parte, veremos DNS, IPv6 y la nueva especificación W3C para la API NavigationTiming .

    DNS explicado

    Cada dispositivo conectado a Internet se identifica mediante una dirección numérica conocida como dirección IP. Las dos formas de direcciones IP que se ven en la Internet abierta son IPv4, que es un número de 32 bits representado a menudo como una serie de cuatro números decimales separados por puntos, por ejemplo 80.72.139.101, e IPv6, que es un número de 128 bits representado como una serie de múltiples números hexadecimales separados por dos puntos, por ejemplo 2607:f298:1:103::c8c:a407.

    Estas direcciones son buenas para que las comprendan las computadoras; Ocupan una cantidad fija de bytes y pueden procesarse fácilmente, pero son difíciles de recordar para los humanos. Tampoco son muy buenos para la marca y, a menudo, están vinculados a una ubicación geográfica o a un proveedor de servicios de infraestructura (como un ISP o un proveedor de hosting).

     

    Para solucionar estas deficiencias, se inventó el " Sistema de nombres de dominio ". En su forma más simple, DNS crea una asignación entre un nombre legible por humanos, como " www.smashingmagazine.com" y su dirección legible por máquina ( 80.72.139.101). DNS puede contener mucha más información, pero esto es todo lo importante para este artículo.

    Por ahora, nos centraremos en la latencia de DNS y en cómo podemos medirla usando JavaScript desde el navegador. La latencia de DNS es importante porque el navegador necesita realizar una búsqueda de DNS para cada nombre de host único del que necesita descargar recursos, incluso si varios nombres de host se asignan a la misma dirección IP.

    Vista más grande

    Medición de los tiempos de búsqueda de DNS

    La forma sencilla de medir el tiempo de búsqueda de DNS desde JavaScript sería medir primero la latencia de un host usando su dirección IP y luego medirla nuevamente usando su nombre de host. La diferencia entre los dos debería darnos tiempo de búsqueda de DNS. Utilizamos los métodos desarrollados en la Parte 1 para medir la latencia.

    El problema con este enfoque es que si el navegador ya ha realizado una búsqueda de DNS en este nombre de host, esa búsqueda se almacenará en caché y realmente no obtendremos una diferencia. Lo que necesitamos es un registro DNS comodín y un servidor web escuchando en él. Carlos Bueno escribió un excelente artículo sobre esto en el blog de YDN hace unos años y creó el código que usa boomerang.

    Antes de ver el código, echemos un vistazo rápido a cómo funcionan las búsquedas de DNS con el siguiente diagrama (simplificado):

    De izquierda a derecha: el cliente aquí es el navegador, el servidor DNS es (normalmente) el ISP del usuario, el servidor de nombres raíz sabe dónde buscar la mayoría de los dominios (o a quién preguntar si no los conoce), y finalmente, el servidor autorizado, que es el servidor DNS del propietario del sitio web.

    Cada una de estas capas tiene su propio caché, y ese caché generalmente permanece mientras el TTL del servidor autorizado (conocido como "Tiempo de vida") lo indique; pero no todos los servidores siguen las especificaciones (y ese es un tema completo en sí mismo).

    Ahora, veamos el código:

    var dns_time;function start() { var gen_url, img, t_start, t_dns, t_http, random = Math.floor(Math.random()*(2147483647)).toString(36); // 1. Create a random hostname within our domain gen_url = "https://*.foo.com".replace(/*/, random); var A_loaded = function() { t_dns = new Date().getTime() - t_start; // 3. Load another image from the same host (see step 2 below) img = new Image(); img.onload = B_loaded; t_start = new Date().getTime(); img.src = gen_url + "image-l.gif?t=" + (new Date().getTime()) + Math.random(); }; var B_loaded = function() { t_http = new Date().getTime() - t_start; img = null; // 4. DNS time is the time to load the image with uncached DNS // minus the time to load the image with cached DNS dns_time = t_dns - t_http; }; // 2. Load an image from the random hostname img = new Image(); img.onload = A_loaded; t_start = new Date().getTime(); img.src = gen_url + "image-l.gif?t=" + (new Date().getTime()) + Math.random();}

    Repasemos el código rápidamente. Lo que hemos hecho aquí es lo siguiente:

     

    1. Cree un nombre de host aleatorio con el prefijo de nuestro dominio comodín. Esto garantiza que nadie almacene en caché la búsqueda del nombre de host.
    2. Cargue una imagen desde este host y mida el tiempo que tarda en cargarse.
    3. Cargue otra imagen del mismo host y mida el tiempo que tarda en cargarse.
    4. Calcule la diferencia entre los dos tiempos medidos.

    El primer período de tiempo medido incluye el tiempo de búsqueda de DNS, el tiempo de intercambio de TCP y la latencia de la red. El segundo tiempo medido incluye la latencia de la red.

    Sin embargo, este enfoque tiene dos desventajas. Primero, mide el tiempo de búsqueda de DNS en el peor de los casos, es decir, el tiempo que lleva realizar una búsqueda de DNS si su nombre de host no está almacenado en caché por ningún servidor DNS intermedio. En la práctica, este no es siempre el caso. No hay una manera fácil de solucionar esto sin la ayuda de los navegadores, y llegaremos a eso más adelante al final de este artículo.

    Además, lo que probablemente dificulta la implementación para la mayoría de las personas es la configuración de un registro DNS comodín. Esto no siempre es posible si no controlas tus servidores DNS. Muchos proveedores de alojamiento compartido no le permitirán configurar un registro DNS comodín. Lo único que puedes hacer en este caso es trasladar los proveedores de hosting, o al menos los proveedores de DNS.

    Medición del soporte y la latencia de IPv6

    Técnicamente, medir IPv6 no debería ser un tema aparte; sin embargo, incluso una década después de su introducción, la adopción de IPv6 sigue siendo bastante baja. Los ISP se han estado conteniendo porque no muchos sitios web ofrecen soporte para IPv6, y los propietarios de sitios web se han estado conteniendo porque no muchos de sus usuarios tienen soporte para IPv6 y no están seguros de cómo afectará esto al rendimiento o la experiencia del usuario.

    La prueba de IPv6 en boomerang le ayuda a determinar si sus usuarios son compatibles con IPv6 y cómo se compara su latencia de IPv6 con la latencia de IPv4. No verifica si su compatibilidad con IPv6 no funciona o no (pero consulte la página de prueba de IPv6 de Google si desea saberlo).

    La prueba de IPv6 consta de dos partes:

    1. Primero, verificamos si podemos conectarnos a un host usando su dirección IPv6 y, si podemos, medimos cuánto tiempo lleva.
    2. A continuación, intentamos conectarnos a un nombre de host que solo se resuelva en una dirección IPv6.

    La primera prueba nos dice si la red del usuario puede realizar conexiones IPv6. El segundo nos dice si su servidor DNS puede buscar registros AAAA. Necesitamos ejecutar la prueba en este orden porque no podremos probar correctamente el DNS si fallan las conexiones a nivel de IP.

    El código es muy similar a la prueba de DNS, excepto que no necesitamos un registro DNS comodín:

     

    var ipv6_url = "https://[2600:1234::d155]/image-l.gif", host_url = "https://ipv6.foo.com/image-l.gif", timeout: 1200, ipv6_latency='NA', dnsv6_latency='NA', timers: { ipv6: { start: null, end: null }, host: { start: null, end: null } };var img, rnd = "?t=" + (new Date().getTime()) + Math.random(), timer=0, error = null;img = new Image();function HOST_loaded() { // 4. When image loads, record its time timers['host'].end = new Date().getTime(); clearTimeout(timer); img.onload = img.onerror = null; img = null; // 5. Calculate latency done();}function error(which) { // 6. If any image fails to load or times out, terminate the test immediately timers[which].supported = false; clearTimeout(timer); img.onload = img.onerror = null; img = null; done();}function done() { if(timers['ipv6'].end !== null) { ipv6_latency = timers.ipv6.end - timers.ipv6.start; } if(timers['host'].end !== null) { dnsv6_latency = timers.host.end - timers.host.start; }}img.onload = function() { // 2. When image loads, record its time timers['ipv6'].end = new Date().getTime(); clearTimeout(timer); // 3. Then load image with hostname that only resolves to ipv6 address img = new Image(); img.onload = HOST_loaded; img.onerror = function() { error('host') }; timer = setTimeout(function() { error('host') }, timeout); timers['host].start = new Date().getTime(); img.src = host_url + rnd;};img.onerror = function() { error('ipv6') };timer = setTimeout(function() { error('ipv6') }, timeout);this.timers['ipv6'].start = new Date().getTime();// 1. Load image with ipv6 addressimg.src = ipv6_url + rnd;

    Sí, este código se puede refactorizar para hacerlo más pequeño, pero eso haría que fuera más difícil de explicar. Esto es lo que hacemos: Fulares Portabebes

    1. Primero cargamos una imagen desde un host usando su dirección IPv6 . Esto verifica que podamos establecer una conexión de red a una dirección IPv6. Si su red, navegador o sistema operativo no es compatible con IPv6, esto fallará y se activará el evento onerror.
    2. Si la imagen se carga, sabemos que se admiten conexiones IPv6. Registramos el tiempo que usaremos para medir la latencia más adelante.
    3. Luego intentamos cargar una imagen usando un nombre de host que solo se resuelve en una dirección IPv6. Es importante que este nombre de host no se resuelva en una dirección IPv4 o esta prueba podría pasar incluso si el servidor DNS no puede manejar IPv6.
    4. Si esto tiene éxito, sabemos que nuestro servidor DNS puede buscar y devolver registros AAAA (el equivalente IPv6 de A). Registramos el tiempo.
    5. Y luego sigue adelante y calcula la latencia. Podemos comparar esto con nuestra latencia de IPv4 y latencia de DNS. Este también sería un lugar apropiado para llamar a cualquier función de devolución de llamada para decir que la prueba se completó.
    6. Si alguna de las cargas de imágenes disparó un evento de error o si se agotó el tiempo de espera, finalizamos la prueba inmediatamente. En ese caso, cualquier prueba que no se haya ejecutado tiene su variable correspondiente ( ipv6_latencyo dnsv6_latency) configurada en "NA", lo que indica que no es compatible.

    Hay otras formas de probar la compatibilidad con IPv6 con la ayuda del lado del servidor, por ejemplo, hacer que su servidor configure una cookie que indique si se cargó a través de IPv4 o IPv6. Esto sólo funciona bien si su página de prueba y su página de imágenes están en el mismo dominio.

     

    La API de sincronización de navegación

    La API NavigationTiming es una interfaz proporcionada por muchos navegadores modernos que brinda a los desarrolladores de JavaScript información detallada sobre el tiempo que el navegador pasó en los distintos estados de descarga de una página. La especificación aún se encuentra en estado de borrador, pero a la fecha de este artículo, Internet Explorer, Chrome y Firefox la admiten. Actualmente, Safari y Opera no son compatibles con la API.

    Los desarrolladores de JavaScript obtienen acceso al objeto NavigationTiming a través de window.performance.timing. Prueba esto ahora. Si está utilizando Chrome, IE 9+ o Firefox 8+, abra una consola web e inspeccione el contenido de window.performance.timing.

    El siguiente diagrama explica el orden de los eventos cuyo tiempo aparece en el objeto. Veamos algunos de ellos:

    Vista más grande | Fuente de imagen

    Ahora los elementos que nos interesa medir son:

    1. Tiempo de carga de la página Obtenemos el tiempo de carga de la página completa tomando la diferencia entre loadEventEndy navigationStart. Este último nos indica cuándo el usuario inició la carga de la página, ya sea haciendo clic en un enlace o ingresándolo en la barra de URL de su navegador. Este último nos indica cuándo onloadterminó el evento. Si no estamos interesados ​​en el tiempo de ejecución del onloadevento, podríamos usarlo loadEventStarten su lugar.
    2. Latencia de red/aplicación La latencia de red es el tiempo desde que el navegador inicia la descarga hasta el momento en que aparece el primer byte. Ahora, parte de esta latencia podría atribuirse a que la aplicación hace algo antes de enviar bytes, pero no hay forma de saberlo desde el lado del cliente. Usamos la diferencia entre requestStarty responseStart.
    3. Tiempo de conexión TCP El tiempo de conexión TCP es la diferencia entre connectStarty connectEnd; sin embargo, si la conexión se realiza a través de SSL, esto incluye el tiempo para negociar un protocolo de enlace SSL. Deberías tener eso en cuenta y usarlo secureConnectionStarten lugar de connectEndsi existe y si te importa la diferencia.
    4. Latencia de DNS La latencia de DNS es la diferencia entre domainLookupStarty domainLookupEnd.

    Importante : Usamos una combinación de tiempos window.performance.timingpara determinar cada uno de estos.

    Si bien esto parece bueno en su mayor parte y realmente le dice lo que experimentan sus usuarios, hay algunas advertencias que debe tener en cuenta . Si el DNS ya está almacenado en caché, la latencia del DNS será 0. De manera similar, si el navegador utiliza una conexión TCP persistente, el tiempo de conexión TCP será 0. Si el documento se lee desde la memoria caché, la latencia de la red será 0. Tenga en cuenta estos puntos y utilícelos para determinar qué fracción de sus usuarios hace un uso eficaz de las cachés de aplicaciones disponibles.

     

    La interfaz Navigation Timing nos proporciona muchos más temporizadores, pero varios de ellos están restringidos por la misma política de origen del navegador. Estos incluyen detalles sobre redirecciones y descarga de la página anterior. Otros temporizadores relacionados con el DOM ya tienen eventos de JavaScript equivalentes, a saber readystatechange, DOMCompletey loadeventos.

    La API de información de red

    Otra API interesante relacionada con la red es la API de información de red . Si bien no está estrictamente relacionado con el rendimiento, ayuda a hacer conjeturas sobre el rendimiento esperado de la red. Actualmente, esta API solo es compatible con dispositivos Android y se expone a través del navigator.connection.typeobjeto. En particular, le indica si el dispositivo está utilizando actualmente Ethernet, Wi-Fi, 2G o 3G.

    Un artículo que recomiendo leer sería el de David Calhoun que muestra algunos buenos ejemplos sobre cómo optimizar según la velocidad de conexión. Tanto el artículo como los comentarios son de lectura útil.

    Resumen

    Si bien la API de sincronización de navegación brinda fácil acceso a información precisa sobre la sincronización de la página, aún es insuficiente para obtener una imagen completa. Aún existe algún beneficio al estimar diversas características de desempeño utilizando las técnicas mencionadas anteriormente en esta serie.

    Ya sea que necesitemos admitir navegadores que actualmente no implementan Navigation Timing u obtener información sobre recursos no incluidos en la página actual, asegúrese de obtener más información sobre el ancho de banda de la red del usuario o si su soporte para IPv6 es mejor o peor que su soporte. para IPv4: una combinación de métodos nos brinda la mejor imagen general.

    Todas las técnicas presentadas aquí se desarrollaron mientras se escribía Boomerang, aunque no todas llegaron al código todavía.

    Referencias

    Los siguientes enlaces ayudaron a escribir este artículo y pueden consultarse para obtener más información sobre temas específicos:

    • El sistema de nombres de dominio : artículo de WikiPedia que explica qué es DNS y cómo funciona.
    • RFC 1035: Especificación DNS : Uno de los RFC sobre DNS, este detalla la especificación e implementación.
    • Registros DNS comodín : artículo de WikiPedia que explica el DNS comodín.
    • IPv4 : artículo de WikiPedia sobre la revisión 4 del protocolo de direccionamiento IP.
    • IPv6 : artículo de WikiPedia sobre la revisión 6 del protocolo de direccionamiento IP.
    • Página de prueba de IPv6 de Google : le indica si su navegador, sistema operativo y proveedor de red admiten IPv6 y si esa compatibilidad funciona correctamente o no.
    • Túneles IPv6 de Hurricane Electric : cree un túnel IPv6 sobre su red IPv4 para obtener soporte IPv6 (más útil para pruebas) antes de que lo haga su ISP.
    • La especificación NavTiming : borrador de especificación W3C para la API NavTiming del navegador.
    • API de información de red : borrador de especificación del W3C para la API de información de red.

    (Créditos de la imagen en portada: Vlasta Juricek )

    Otras lecturas

    • Rendimiento del sitio web: qué saber y qué puede hacer
    • Diseño basado en datos en el mundo real
    • Una hoja de ruta para convertirse en un experto en pruebas A/B
    • Pruebas multivariadas 101: un método científico para optimizar el diseño

    (il, ea, mrn)Explora más en

    • Codificación
    • javascript
    • Actuación





    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Análisis de las características de la red utilizando JavaScript y DOM, Parte 2

    Análisis de las características de la red utilizando JavaScript y DOM, Parte 2

    ¡Registro! Taller de diseño conductual, con Susan y Guthrie Weinschenk Índice DNS explicado

    programar

    es

    https://aprendeprogramando.es/static/images/programar-analisis-de-las-caracteristicas-de-la-red-utilizando-javascript-y-dom-823-0.jpg

    2024-05-20

     

    Análisis de las características de la red utilizando JavaScript y DOM, Parte 2
    Análisis de las características de la red utilizando JavaScript y DOM, Parte 2

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20