stringtranslate.com

Medición del rendimiento de la red

El rendimiento de una red se puede medir con distintas herramientas disponibles en diferentes plataformas. En esta página se explica la teoría que sustenta lo que estas herramientas pretenden medir y los problemas relacionados con estas mediciones.

Razones para medir el rendimiento en redes. A menudo, a la gente le preocupa medir el rendimiento máximo de datos en bits por segundo de un enlace de comunicaciones o acceso a la red. Un método típico para realizar una medición es transferir un archivo "grande" de un sistema a otro y medir el tiempo necesario para completar la transferencia o copia del archivo. Luego, el rendimiento se calcula dividiendo el tamaño del archivo por el tiempo para obtener el rendimiento en megabits , kilobits o bits por segundo.

Lamentablemente, los resultados de un ejercicio de este tipo suelen dar como resultado un rendimiento útil inferior al rendimiento teórico máximo de datos, lo que lleva a la gente a creer que su enlace de comunicaciones no está funcionando correctamente. De hecho, hay muchos gastos generales que se tienen en cuenta en el rendimiento, además de los gastos generales de transmisión, entre ellos la latencia , el tamaño de la ventana de recepción TCP y las limitaciones del sistema, lo que significa que el rendimiento útil calculado no refleja el rendimiento máximo alcanzable. [1]

Teoría: Breve resumen

El ancho de banda máximo se puede calcular de la siguiente manera: [2]

donde RWIN es la ventana de recepción TCP y RTT es el tiempo de ida y vuelta de la ruta. El tamaño máximo de la ventana TCP en ausencia de la opción de escala de ventana TCP es de 65 535 bytes . Ejemplo: Ancho de banda máximo = 65 535 bytes / 0,220 s = 297 886,36 B/s * 8 = 2,383 Mbit /s. En una única conexión TCP entre esos puntos finales, el ancho de banda probado se restringirá a 2,376 Mbit/s incluso si el ancho de banda contratado es mayor.

Software de prueba de ancho de banda

El software de prueba de ancho de banda se utiliza para determinar el ancho de banda máximo de una red o conexión a Internet . Por lo general, se realiza intentando descargar o cargar la máxima cantidad de datos en un período de tiempo determinado, o una cierta cantidad de datos en el mínimo tiempo. Por este motivo, las pruebas de ancho de banda pueden retrasar las transmisiones de Internet a través de la conexión a Internet mientras se realizan y pueden provocar cargos por datos inflados.

Nomenclatura

El rendimiento de los enlaces de comunicaciones se mide en bits por segundo (bit/s), kilobits por segundo (kbit/s), megabits por segundo (Mbit/s) y gigabits por segundo (Gbit/s). En esta aplicación, kilo, mega y giga son los prefijos estándar del SI que indican la multiplicación por 1.000 ( kilo ), 1.000.000 ( mega ) y 1.000.000.000 ( giga ).

Los tamaños de archivo se miden normalmente en bytes ( lo más habitual son kilobytes , megabytes y gigabytes , donde un byte son ocho bits). En los libros de texto modernos, un kilobyte se define como 1000 bytes, un megabyte como 1 000 000 de bytes, etc., de acuerdo con el estándar de la Comisión Electrotécnica Internacional (IEC) de 1998. Sin embargo, la convención adoptada por los sistemas Windows es definir 1 kilobyte como 1024 (o 2 10 ) bytes, lo que equivale a 1  kibibyte . De forma similar, un tamaño de archivo de "1 megabyte" es 1024 × 1024 bytes, lo que equivale a 1 mebibyte ), y "1 gigabyte" 1024 × 1024 × 1024 bytes = 1 gibibyte ).

Uso confuso e inconsistente de sufijos

Es habitual que la gente abrevie expresiones de uso común. Para los tamaños de archivo, es habitual que alguien diga que tiene un archivo de '64 k' (es decir, 64 kilobytes) o un archivo de '100 meg' (es decir, 100 megabytes). Cuando se habla de velocidades de bits de circuitos , la gente utilizará indistintamente los términos rendimiento , ancho de banda y velocidad, y se referirá a un circuito como un circuito de '64 k' o un circuito de '2 meg', es decir, 64 kbit/s o 2 Mbit/s (consulte también la Lista de anchos de banda de conexión ). Sin embargo, un circuito de '64 k' no transmitirá un archivo de '64 k' en un segundo. Esto puede no ser obvio para aquellos que no están familiarizados con las telecomunicaciones y la informática, por lo que a veces surgen malentendidos. En realidad, un archivo de 64 kilobytes tiene un tamaño de 64 × 1.024 × 8 bits y el circuito de 64 k transmitirá bits a una velocidad de 64 × 1.000 bit/s, por lo que el tiempo necesario para transmitir un archivo de 64 kilobytes a través del circuito de 64 k será al menos (64 × 1.024 × 8)/(64 × 1.000) segundos, lo que equivale a 8,192 segundos.

Compresión

Algunos equipos pueden mejorar la situación comprimiendo los datos a medida que se envían. Esta es una característica de la mayoría de los módems analógicos y de varios sistemas operativos populares . Si el archivo de 64 k puede reducirse mediante compresión , se puede reducir el tiempo de transmisión. Esto se puede hacer de forma invisible para el usuario, por lo que un archivo muy comprimible puede transmitirse considerablemente más rápido de lo esperado. Como esta compresión "invisible" no se puede desactivar fácilmente, se deduce que, al medir el rendimiento mediante archivos y cronometrar el tiempo de transmisión, se deben utilizar archivos que no se puedan comprimir. Normalmente, esto se hace utilizando un archivo de datos aleatorios, que se vuelve más difícil de comprimir cuanto más se acerca a la aleatoriedad.

Suponiendo que los datos no se pueden comprimir, los 8,192 segundos necesarios para transmitir un archivo de 64 kilobytes a través de un enlace de comunicaciones de 64 kilobits/s es un tiempo mínimo teórico que no se alcanzará en la práctica. Esto se debe al efecto de los gastos generales que se utilizan para formatear los datos de una manera acordada de modo que ambos extremos de una conexión tengan una vista coherente de los datos.

Hay al menos dos problemas que no son inmediatamente obvios a la hora de transmitir archivos comprimidos:

  1. La compresión no mejora el rendimiento de la red en sí. Desde la perspectiva de extremo a extremo (del servidor al cliente), la compresión sí mejora el rendimiento. Esto se debe a que el contenido de información para la misma cantidad de transmisión aumenta a través de la compresión de archivos.
  2. La compresión de archivos en el servidor y el cliente requiere más recursos del procesador en ambos extremos. El servidor tiene que usar su procesador para comprimir los archivos, si no lo ha hecho ya. El cliente tiene que descomprimir los archivos al recibirlos. Esto puede considerarse un gasto (para el servidor y el cliente) en beneficio de un mayor rendimiento de extremo a extremo (aunque el rendimiento no ha cambiado para la red en sí). [3]

Gastos generales y formatos de datos

[4]

Un enlace de comunicaciones común utilizado por muchas personas es el enlace serial asíncrono de inicio y parada , o simplemente "asincrónico". Si tiene un módem externo conectado a su computadora de casa u oficina, lo más probable es que la conexión sea a través de una conexión serial asíncrona. Su ventaja es que es simple: se puede implementar utilizando solo tres cables: Enviar, Recibir y Tierra de señal (o Señal común). En una interfaz RS-232 , una conexión inactiva tiene un voltaje negativo continuo aplicado. Un bit "cero" se representa como una diferencia de voltaje positivo con respecto a la Tierra de señal y un bit "uno" es un voltaje negativo con respecto a la tierra de señal, por lo tanto indistinguible del estado inactivo. Esto significa que necesita saber cuándo comienza un bit "uno" para distinguirlo de inactivo. Esto se hace acordando de antemano qué tan rápido se transmitirán los datos a través de un enlace, luego usando un bit de inicio para señalar el comienzo de un byte: este bit de inicio será un bit "cero". Los bits de parada son bits "uno", es decir, voltaje negativo.

En realidad, se habrán acordado más cosas de antemano: la velocidad de transmisión de bits, el número de bits por carácter, la paridad y el número de bits de parada (que indican el final de un carácter). Por lo tanto, la designación 9600-8-E-2 sería 9.600 bits por segundo, con ocho bits por carácter, paridad par y dos bits de parada.

Una configuración habitual de una conexión serial asíncrona sería 9600-8-N-1 (9600 bit/s, 8 bits por carácter, sin paridad y 1 bit de parada): un total de 10 bits transmitidos para enviar un carácter de 8 bits (un bit de inicio, los 8 bits que componen el byte transmitido y un bit de parada). Esto supone una sobrecarga del 20%, por lo que un enlace serial asíncrono de 9600 bit/s no transmitirá datos a 9600/8 bytes por segundo (1200 bytes/s), sino, en este caso, a 9600/10 bytes por segundo (960 bytes/s), lo que es considerablemente más lento de lo esperado.

La cosa puede empeorar. Si se especifica la paridad y utilizamos dos bits de parada, el consumo de energía para transportar un carácter de 8 bits es de 4 bits (un bit de inicio, un bit de paridad y dos bits de parada), ¡o el 50%! En este caso, una conexión de 9600 bit/s transportará 9600/12 bytes/s (800 bytes/s). Las interfaces seriales asíncronas normalmente admiten velocidades de transmisión de bits de hasta 230,4 kbit/s. Si se configura sin paridad y con un bit de parada, esto significa que la velocidad de transmisión de bytes es de 23,04 kbytes/s.

La ventaja de la conexión serial asíncrona es su simplicidad. Una desventaja es su baja eficiencia en el transporte de datos. Esto se puede superar utilizando una interfaz síncrona . En este tipo de interfaz, se agrega una señal de reloj en un cable separado y los bits se transmiten en sincronía con el reloj (la interfaz ya no tiene que buscar los bits de inicio y fin de cada carácter individual); sin embargo, es necesario tener un mecanismo para garantizar que los relojes de envío y recepción se mantengan sincronizados, por lo que los datos se dividen en tramas de múltiples caracteres separados por delimitadores conocidos. Hay tres esquemas de codificación comunes para comunicaciones en tramas: HDLC , PPP y Ethernet.

HDLC

Cuando se utiliza HDLC , en lugar de que cada byte tenga un inicio, paridad opcional y uno o dos bits de parada, los bytes se agrupan en una trama . El inicio y el final de la trama se señalan mediante la "bandera", y la detección de errores se lleva a cabo mediante la secuencia de comprobación de trama. Si la trama tiene una dirección de tamaño máximo de 32 bits, una parte de control de tamaño máximo de 16 bits y una secuencia de comprobación de trama de tamaño máximo de 16 bits, la sobrecarga por trama podría ser de hasta 64 bits. Si cada trama transportara un solo byte, la eficiencia de procesamiento de datos sería extremadamente baja. Sin embargo, los bytes normalmente se agrupan, de modo que incluso con una sobrecarga máxima de 64 bits, las tramas que transportan más de 24 bytes son más eficientes que las conexiones seriales asíncronas. Como las tramas pueden variar en tamaño porque pueden tener diferentes cantidades de bytes transportados como datos, esto significa que la sobrecarga de una conexión HDLC no es fija. [5]

PPP

El " protocolo punto a punto " (PPP) está definido en los documentos de solicitud de comentarios de Internet RFC 1570, RFC 1661 y RFC 1662. Con respecto a la estructuración de paquetes, PPP es bastante similar a HDLC, pero admite métodos orientados a bits y a bytes ("relleno de octetos") para delimitar tramas mientras mantiene la transparencia de los datos. [6]

Ethernet

Ethernet es una tecnología de " red de área local " (LAN), que también está enmarcada. La forma en que se define eléctricamente la trama en una conexión entre dos sistemas es diferente de la tecnología de red de área amplia que utiliza HDLC o PPP implementados, pero estos detalles no son importantes para los cálculos de rendimiento. Ethernet es un medio compartido, por lo que no se garantiza que solo los dos sistemas que están transfiriendo un archivo entre sí tengan acceso exclusivo a la conexión. Si varios sistemas intentan comunicarse simultáneamente, el rendimiento entre cualquier par puede ser sustancialmente menor que el ancho de banda nominal disponible. [7]

Otros protocolos de bajo nivel

Los enlaces punto a punto dedicados no son la única opción para muchas conexiones entre sistemas. También se pueden utilizar servicios basados ​​en Frame Relay , ATM y MPLS . Al calcular o estimar el rendimiento de los datos, es necesario comprender los detalles del formato de trama/celda/paquete y la implementación detallada de la tecnología. [8]

Relé de trama

Frame Relay utiliza un formato HDLC modificado para definir el formato de trama que transporta los datos. [9]

cajero automático

El modo de transferencia asíncrona (ATM) utiliza un método radicalmente diferente para transportar datos. En lugar de utilizar tramas o paquetes de longitud variable, los datos se transportan en celdas de tamaño fijo. Cada celda tiene 53 bytes de longitud, con los primeros 5 bytes definidos como encabezado y los siguientes 48 bytes como carga útil. Las redes de datos suelen requerir paquetes de datos de más de 48 bytes, por lo que existe un proceso de adaptación definido que especifica cómo se deben dividir los paquetes de datos más grandes de manera estándar para que los transporten las celdas más pequeñas. Este proceso varía según los datos transportados, por lo que en la nomenclatura ATM existen diferentes capas de adaptación ATM . El proceso definido para la mayoría de los datos se denomina capa de adaptación ATM n.º 5 o AAL5 .

Para comprender el rendimiento de los enlaces ATM es necesario saber qué capa de adaptación ATM se ha utilizado para los datos transportados. [10]

MPLS

La conmutación de etiquetas multiprotocolo (MPLS) añade una etiqueta o encabezado estándar, conocido como "etiqueta", a los paquetes de datos existentes. En determinadas situaciones, es posible utilizar MPLS de forma "apilada", de modo que se añadan etiquetas a los paquetes que ya han sido etiquetados. Las conexiones entre sistemas MPLS también pueden ser "nativas", sin un protocolo de transporte subyacente, o los paquetes etiquetados MPLS pueden transportarse dentro de paquetes de retransmisión de tramas o HDLC como cargas útiles. Los cálculos correctos de rendimiento deben tener en cuenta estas configuraciones. Por ejemplo, un paquete de datos podría tener dos etiquetas MPLS adjuntas mediante "apilamiento de etiquetas", que luego se colocarían como carga útil dentro de una trama HDLC. Esto genera más sobrecarga que debe tenerse en cuenta que una sola etiqueta MPLS adjunta a un paquete que luego se envía de forma "nativa", sin un protocolo subyacente a un sistema receptor. [11]

Protocolos de nivel superior

Pocos sistemas transfieren archivos y datos simplemente copiando el contenido del archivo en el campo "Datos" de las tramas HDLC o PPP; se utiliza otra capa de protocolo para formatear los datos dentro del campo "Datos" de la trama HDLC o PPP. El protocolo más utilizado es el Protocolo de Internet (IP), definido por RFC 791. Esto impone sus propios costos.

De nuevo, pocos sistemas simplemente copian el contenido de los archivos en paquetes IP, sino que utilizan otro protocolo que administra la conexión entre dos sistemas: TCP ( Protocolo de control de transmisión ), definido por RFC 1812. Esto agrega su propia sobrecarga.

Por último, una capa de protocolo final gestiona el proceso de transferencia de datos propiamente dicho. Un protocolo que se utiliza habitualmente para ello es el " protocolo de transferencia de archivos " [12].

Véase también

Referencias

  1. ^ Comer, DE (2008). Redes informáticas e Internet, quinta edición
  2. ^ "Modelado matemático del rendimiento del protocolo TCP" (PDF) .
  3. ^ Comer, DE (2008). Redes informáticas e Internet, quinta edición
  4. ^ Comer, DE (2008). Redes informáticas e Internet, quinta edición
  5. ^ Cisco System, Inc. (2001-2006). Guía de configuración de IP de Cisco IOS
  6. ^ Lydia Parziale, DT (2006). TUTORIAL Y DESCRIPCIÓN TÉCNICA SOBRE TCP/IP
  7. ^ Lammle, T. (2002). Cisco Certified Network Associate. Londres
  8. ^ Lydia Parziale, DT (2006). TUTORIAL Y DESCRIPCIÓN TÉCNICA SOBRE TCP/IP
  9. ^ Comer, DE (2008). Redes informáticas e Internet, quinta edición
  10. ^ Comer, DE (2008). Redes informáticas e Internet, quinta edición
  11. ^ Smith, S. (2003). Introducción a MPLS. CISCO
  12. ^ Lydia Parziale, DT (2006). TUTORIAL Y DESCRIPCIÓN TÉCNICA SOBRE TCP/IP

Enlaces externos