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

 

 

 

  • SmashingConf Friburgo 2024
  • Listas de verificación de diseño de interfaz inteligente

  • Índice
    1. ¿Qué hay en una red de todos modos?
      1. Latencia de conexion
      2. Rendimiento de la red
      3. DNS
    2. Medición de la latencia de la red con JavaScript
      1. Protocolo de enlace TCP y mantenimiento HTTP
    3. Medición del rendimiento de la red con JavaScript
      1. Comienzo lento
    4. Resumen y referencias

    Como desarrolladores web, tenemos afinidad por desarrollar con JavaScript. Cualquiera que sea el idioma utilizado en el back-end, JavaScript y el navegador son la principal combinación de idioma y plataforma disponible para el usuario. Tiene muchos usos, desde tontos hasta para mejorar la experiencia.

     

    En este artículo, veremos algunos métodos de manipulación de JavaScript para determinar varias características de la red desde el navegador, características que anteriormente solo estaban disponibles para aplicaciones que interactúan directamente con el sistema operativo. Gran parte de esto se descubrió mientras se creaba el proyecto Boomerang para medir el rendimiento real del usuario.

    ¿Qué hay en una red de todos modos?

    La red tiene muchas capas, pero a los desarrolladores web entre nosotros les importa más HTTP , que se ejecuta sobre TCP e IP (también conocido conjuntamente como el conjunto de protocolos de Internet ). Varias capas están por debajo de eso, pero en su mayor parte, si funciona con cobre, fibra o palomas mensajeras no afecta las capas ni las características que nos interesan.

     

    Latencia de conexion

    La latencia de la red suele ser el tiempo que lleva enviar una señal a través de la red y obtener una respuesta. A menudo también se le llama tiempo de ida y vuelta o tiempo de ping porque es el tiempo informado por el pingcomando. Si bien esto es interesante para los ingenieros de redes que diagnostican problemas de red, los desarrolladores web se preocupan más por el tiempo que lleva realizar una solicitud HTTP y obtener una respuesta. Por lo tanto, definiremos la latencia HTTP como el tiempo que lleva realizar la solicitud HTTP más pequeña posible y obtener una respuesta con un tiempo de procesamiento del servidor insignificante (es decir, lo único que hace el servidor es enviar una respuesta).

    Un buen consejo: la luz y la electricidad viajan a través de fibra y cobre al 66% de la velocidad de la luz en el vacío, o 20 × 10 8 kilómetros por segundo. Una buena aproximación de la latencia de la red entre los puntos A y B es cuatro veces el tiempo que tarda la luz o la electricidad en recorrer la distancia. Greg's Cable Map es un buen recurso para conocer la longitud y el ancho de banda de los cables de redes submarinas. Te dejaré a ti juntar estas piezas.

    Rendimiento de la red

    El rendimiento de la red nos indica qué tan bien se está utilizando una red. Es posible que tengamos una conexión de red de 3 megabits, pero en realidad estamos usando solo 2 megabits porque la red tiene mucho tiempo de inactividad.

    DNS

    DNS es un poco diferente de todo lo que nos importa. Funciona sobre UDP y normalmente ocurre en una capa que es transparente para JavaScript. Veremos cuál es la mejor manera de determinar el tiempo que lleva realizar una búsqueda de DNS.

    Por supuesto, hay mucho más en la red, pero determinar estas características a través de JavaScript en el navegador se vuelve cada vez más difícil.

    Medición de la latencia de la red con JavaScript

    Mi primer instinto fue que medir la latencia simplemente implicaba enviar un paquete en cada sentido y cronometrarlo. Es bastante fácil hacer esto en JavaScript:

    var ts, rtt, img = new Image;img.onload=function() { rtt=(+new Date - ts) };ts = +new Date;img.src="/1x1.gif";

    Iniciamos un temporizador, luego cargamos un GIF de 1 × 1 píxeles y medimos cuándo se onloadactiva su evento. El GIF en sí tiene un tamaño de 35 bytes y, por lo tanto, cabe en un solo paquete TCP incluso con encabezados HTTP agregados.

    Esto funciona un poco, pero tiene resultados inconsistentes. En particular, la primera vez que carga una imagen, tardará un poco más que las cargas posteriores, incluso si nos aseguramos de que la imagen no esté almacenada en caché. Observar los paquetes TCP que atraviesan la red explica lo que sucede, como veremos en la siguiente sección.

    Protocolo de enlace TCP y mantenimiento HTTP

    Al cargar una página web, una imagen o cualquier otro recurso web, un navegador abre una conexión TCP con el servidor web especificado y luego realiza una GETsolicitud HTTP a través de esta conexión. Los detalles de la conexión TCP y la solicitud HTTP están ocultos para los usuarios y también para los desarrolladores web. Sin embargo, son importantes si necesitamos analizar las características de la red.

     

    La primera vez que se abre una conexión TCP entre dos hosts (el navegador y el servidor, en nuestro caso), es necesario "apretar la comunicación". Esto se lleva a cabo enviando tres paquetes entre los dos hosts. El host que inicia la conexión (el navegador en nuestro caso) primero envía un paquete SYN, que en cierto modo significa: “Sincronicemos. Me gustaria hablar contigo. ¿Estás listo para hablar conmigo? Si el otro host (el servidor en nuestro caso) está listo, responde con un ACK, que significa "Reconozco tu SYN". Y también envía su propio SYN, lo que significa: “A mí también me gustaría sincronizarme. ¿Estás listo?" Luego, el navegador web completa el protocolo de enlace con su propio ACK y se establece la conexión. La conexión podría fallar, pero el proceso detrás de un error de conexión está fuera del alcance de este artículo.

    Una vez establecida la conexión, permanece abierta hasta que ambos extremos deciden cerrarla, mediante un apretón de manos similar.

    Cuando lanzamos HTTP sobre TCP, ahora tenemos un cliente HTTP (normalmente un navegador) que inicia la conexión TCP y envía el primer paquete de datos (una GETsolicitud, por ejemplo). Si usamos HTTP/1.1 (que casi todo el mundo hace hoy), entonces el valor predeterminado será usar HTTP keep-alive ( Connection: keep-alive). Esto significa que pueden realizarse varias solicitudes HTTP a través de la misma conexión TCP. Esto es bueno porque significa que reducimos la sobrecarga del protocolo de enlace (tres paquetes adicionales).

    Ahora, a menos que tengamos activada la canalización HTTP (y la mayoría de los navegadores y servidores la desactivan), estas solicitudes se realizarán en serie.

    Ahora podemos modificar un poco nuestro código para tener en cuenta el tiempo del protocolo de enlace TCP y medir la latencia en consecuencia.

    var t=[], n=2, tcp, rtt;var ld = function() { t.push(+new Date); if(t.length n) done(); else { var img = new Image; img.onload = ld; img.src="/1x1.gif?" + Math.random() + '=' + new Date; }};var done = function() { rtt=t[2]-t[1]; tcp=t[1]-t[0]-rtt;};ld();

    Con este código, podemos medir tanto la latencia como el tiempo de intercambio de TCP. Existe la posibilidad de que ya haya una conexión TCP activa y que la primera solicitud se haya realizado en esa conexión. En este caso, los dos tiempos serán muy próximos entre sí. En todos los demás casos, rtt, que requiere dos paquetes, debería ser aproximadamente el 66 % de tcp, que requiere tres paquetes. Tenga en cuenta que digo "aproximadamente", porque la fluctuación de la red y las diferentes rutas en la capa IP pueden hacer que dos paquetes en la misma conexión TCP tarden diferentes períodos de tiempo en llegar.

    Notarás aquí que hemos ignorado el hecho de que es posible que la primera imagen también haya requerido una búsqueda de DNS. Veremos eso en la parte 2.

    Medición del rendimiento de la red con JavaScript

    Nuevamente, nuestro primer instinto con esta prueba fue simplemente descargar una imagen grande y medir cuánto tiempo lleva. Entonces size/timedebería decirnos el rendimiento.

    Para los fines de este código, supongamos que tenemos un objeto global llamado image, con detalles de la URL de la imagen y el tamaño en bits.

     

    // Assume global object// image={ url: …, size: … }var ts, rtt, bw, img = new Image;img.onload=function() { rtt=(+new Date - ts); bw = image.size*1000/rtt; // rtt is in ms};ts = +new Date;img.src=image.url;

    Una vez que este código haya terminado de ejecutarse, deberíamos tener el rendimiento de la red en kilobits por segundo almacenado en bw.

    Desafortunadamente, no es tan simple debido a algo llamado TCP de inicio lento .

    Comienzo lento

    Para evitar la congestión de la red, ambos extremos de una conexión TCP comenzarán a enviar datos lentamente y esperarán una confirmación (un paquete ACK). Recuerde que un paquete ACK significa: "Reconozco lo que me acaba de enviar". Cada vez que recibe un ACK sin tiempo de espera, asume que el otro extremo puede operar más rápido y enviará más paquetes antes de esperar el siguiente ACK. Si un ACK no llega en el plazo esperado, se supone que el otro extremo no puede operar lo suficientemente rápido y, por lo tanto, retrocede.

    Esto significa que nuestra prueba de rendimiento anterior habría estado bien siempre y cuando nuestra imagen sea lo suficientemente pequeña como para caber dentro de la ventana TCP actual, que al principio está configurada en 2. Si bien esto está bien para redes lentas, una red rápida realmente no lo sería. No te preocupes por una imagen tan pequeña.

    En su lugar, intentaremos enviar imágenes de tamaño cada vez mayor y medir el tiempo que tarda cada una en descargarse.

    A los efectos del código, el imageobjeto global es ahora una matriz con la siguiente estructura:

    var image = [ {url: …, size: … }];

    Una matriz facilita la iteración sobre la lista de imágenes y podemos agregar fácilmente imágenes grandes al final de la matriz para probar conexiones de red más rápidas.

    var i=0;var ld = function() { if(i 0) image[i-1].end = +new Date; if(i = image.length) done(); else { var img = new Image; img.onload = ld; image[i].start = +new Date; img.src=image[i].url; } i++;};

    Desafortunadamente, esto falla cuando una conexión muy lenta llega a una de las imágenes más grandes; por lo tanto, agregamos un timeoutvalor para cada imagen, diseñado para que alcancemos velocidades de conexión de red comunes rápidamente. Los detalles de los tamaños y timeoutvalores de las imágenes se enumeran en esta hoja de cálculo .

    Nuestro código ahora se ve así:

    var i=0;var ld = function() { if(i 0) { image[i-1].end = +new Date; clearTimeout(image[i-1].timer); } if(i = image.length || (i 0 image[i-1].expired)) done(); else { var img = new Image; img.onload = ld; image[i].start = +new Date; image[i].timer = setTimeout(function() { image[i].expired=true }, image[i].timeout); img.src=image[i].url; } i++;};

    Esto se ve mucho mejor y también funciona mucho mejor. Pero veríamos mucha variación entre múltiples ejecuciones. La única forma de reducir el error en la medición es ejecutar la prueba varias veces y tomar un valor resumido, como la mediana. Es una compensación entre qué tan preciso debe ser y cuánto tiempo desea que el usuario espere antes de que se complete la prueba. Conseguir que el rendimiento de la red alcance un orden de magnitud suele ser lo más aproximado que se necesita. Saber si la conexión del usuario es de alrededor de 64 Kbps o 2 Mbps es útil, pero determinar si es exactamente de 2048 o 2500 Kbps es mucho menos útil.

    Resumen y referencias

    Eso es todo por la parte 1 de esta serie. Hemos analizado cómo los paquetes que componen una solicitud web pasan entre el navegador y el servidor, cómo esto cambia con el tiempo y cómo podemos usar JavaScript y un poco de conocimiento de estadística para hacer conjeturas fundamentadas sobre las características de la red que estamos trabajando con.

    En la siguiente parte, veremos DNS y la diferencia entre IPv6 e IPv4 y la API WebTiming. Nos encantaría saber qué piensas de este artículo y qué te gustaría ver en la parte 2, así que háznoslo saber en un comentario.

    Hasta entonces, aquí hay una lista de enlaces a recursos que fueron útiles para compilar este documento.

    • Análisis de las características de la red utilizando JavaScript y DOM, Parte 2
    • Rendimiento del sitio web: qué saber y qué puede hacer
    • Diseño basado en datos en el mundo real
    • “ Tamaños de imágenes de ancho de banda ”, hoja de cálculo de Google. Esto se basa en la investigación realizada mientras se creaba Boomerang.
    • Boomerang El proyecto Boomerang en GitHub, donde se ha implementado gran parte de esto.

    (Alabama)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 1

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

    SmashingConf Friburgo 2024 Listas de verificación de diseño de interfaz inteligente Índice ¿Qué hay e

    programar

    es

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

    2024-05-20

     

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

    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