networking - tabla - tcp vs udp diferencias

La forma correcta de calcular el rendimiento del enlace (2)

Depende de cómo se defina "Rendimiento". Por lo general, puede ser uno de los siguientes.

Número de bytes (o bits) enviados en un período de tiempo fijo;
Número de bytes (o bits) enviados y recibidos en el extremo receptor en un período de tiempo fijo;

Puede aplicar estas definiciones a todas las capas cuando las personas hablan sobre el rendimiento. En la capa de aplicación, la segunda definición significa que los bytes realmente han sido recibidos por el receptor al final de la aplicación. Algunas personas lo llaman "buen rendimiento". En la capa de Transporte, digamos TCP, la 2da definición significa que se reciben los ACK de TCP correspondientes. Para mí, la mayoría de la gente debería estar interesada en que los bytes realmente son recibidos por el receptor. Entonces, la segunda definición es generalmente lo que las personas quieren decir con "rendimiento".

Ahora, una vez que tenemos una definición clara de rendimiento (2da definición). Podemos analizar cómo medir el rendimiento de manera correcta.

Por lo general, las personas usan TCP o UDP para medir el rendimiento de la red.

TCP: la gente generalmente mide el rendimiento de TCP solo en el extremo del remitente. En cuanto a los paquetes recibidos con éxito por el receptor, los ACK enviarán de vuelta. Por lo tanto, el propio remitente sabrá cuántos bytes se envían y reciben en el extremo del receptor. Dividido este número por el tiempo de medición, sabremos el rendimiento.

Pero, hay dos cosas que deben notarse durante la medición de rendimiento de TCP:

¿El lado del emisor siempre está lleno de buffer durante la medición? es decir, durante el período de medición, el remitente siempre debe tener paquetes para enviar. Es importante para la medición correcta del rendimiento. por ejemplo, si configuro mi tiempo de medición en 60 segundos, pero mi archivo ha finalizado la transmisión en 40 segundos. Luego hay 20 segundos que la red está realmente inactiva. Subestimaré el rendimiento.
La velocidad TCP está regulada por el tamaño de la ventana de congestión, el tiempo de inicio lento, el tamaño de la ventana del remitente (y la ventana del receptor). La configuración subóptima de estos parámetros dará como resultado un rendimiento del TCP subestimado. Aunque la mayor parte de la implementación moderna de TCP debe tener una configuración bastante buena de todos estos, es difícil para un probador asegurarse al 100% de que todas estas configuraciones sean óptimas.

Debido a estas limitaciones / riesgos de TCP en la estimación del rendimiento de la red, un buen número de investigadores utilizará UDP para medir el rendimiento de la red.

UDP: Como UDP no envía un ACK de regreso una vez que los paquetes se reciben con éxito, las personas tienen que medir el rendimiento en el extremo del receptor. O bien, si no se puede acceder fácilmente al extremo del receptor, las personas pueden comparar los registros en los lados del emisor y del receptor para determinar el rendimiento. Sin embargo, este inconveniente se ve mitigado por algunas herramientas de medición de rendimiento. Por ejemplo, iperf tiene números de secuencia incrustados en su carga útil personalizada, para que pueda detectar cualquier pérdida. Además, se enviará un informe del receptor al remitente para mostrar el rendimiento.

Como UDP por naturaleza solo está enviando lo que tiene a la red y no esperando los comentarios. Su rendimiento (recuerde la 2da definición) una vez medida será la capacidad real (o ancho de banda) de la red.

Por lo tanto, generalmente, el rendimiento medido por UDP debe ser mayor que el de TCP, aunque la diferencia debe ser pequeña (~ 5% -10%).

Una de las desventajas más importantes de la medición del rendimiento UDP es que, al usar UDP, también se debe asegurar que el buffer del lado del emisor debe estar lleno. (De lo contrario, da como resultado un rendimiento inferior al estimado como TCP). Este paso será un poco complicado. En iperf, uno puede especificar la velocidad de envío por la opción -b. Aumentar el valor -b en diferentes rondas de prueba convergerá el rendimiento medido. Por ejemplo, en mi gigabit ethernet, primero uso -b 100k en la prueba. El rendimiento medido es de 100 Kbps. Luego realizo las siguientes iteraciones para converger el rendimiento máximo que es la capacidad de mi ethernet.

-b 1m -> rendimiento: 1Mbps

-b 10m -> rendimiento: 10Mbps

-b 100m -> rendimiento: 100Mbps

-b 200 m -> rendimiento: 170 Mbps

-b 180m -> rendimiento: 175Mbps (esto debería ser bastante cercano a la capacidad real)

He leído algunos artículos en línea y tengo una muy buena idea sobre TCP y UDP en general. Sin embargo, todavía tengo algunas dudas de las cuales estoy seguro que no están completamente claras.

¿Cuál es la forma correcta de calcular el rendimiento?

( Can''t we just divide Total number of bytes received by total time taken ? )

¿Cuál es esa característica clave en TCP que hace que tenga un rendimiento mucho más alto que UDP?

ACTUALIZAR:

Entendí que TCP usa Windows, que no es más que la cantidad de segmentos que se pueden enviar antes de esperar realmente Agradecimientos. Pero mi duda es que en los segmentos UDP se envían continuamente sin molestarse por los Agradecimientos. Por lo tanto, no hay gastos generales adicionales en UDP. Entonces, ¿por qué el rendimiento de TCP es mucho mayor que el de UDP?

Finalmente,

Es esto cierto ?

TCP throughput = (TCP Window Size / RTT) = BDP / RTT = (Link Speed in Bytes/sec * RTT)/RTT = Link Speed in Bytes/sec

Si es así, el rendimiento de TCP siempre es igual a la velocidad de Know Link. Y dado que los RTT se cancelan entre sí, el rendimiento de TCP ni siquiera depende de RTT.

He visto en algunas herramientas de análisis de red como iperf, prueba de rendimiento de Passmark, etc. que el rendimiento de TCP / UDP cambia con el tamaño de bloque.

¿De qué manera el rendimiento depende del tamaño del Bloque? ¿El tamaño del Bloque es igual a la ventana TCP o al tamaño del datagrama UDP?

¿Cuál es la forma correcta de calcular el rendimiento?

Hay varias formas, dependiendo de qué es exactamente lo que quiere medir. Todos se reducen a dividir una cierta cantidad de bits (o bytes) por algún tiempo, como usted menciona; lo que varía es qué bits está contando o (más raramente) qué momentos de tiempo está considerando para medir la duración.

Los factores que debe tener en cuenta son:

¿En qué capa de la pila de red está midiendo el rendimiento?

Si mides en la capa de aplicación, todo lo que importa es qué datos útiles transmites al otro extremo. Por ejemplo, si está transfiriendo un archivo de 6 kB, la cantidad de datos que cuenta al medir el rendimiento es de 6 kB (es decir, 6.000 bytes, no bits, y tenga en cuenta el multiplicador de 1000, no 1024; estas convenciones son comunes en las redes )

Por lo general, esto se conoce como goodput y puede ser diferente de lo que realmente se envía en la capa de transporte (como en TCP o UDP), por dos razones:

1. Gastos generales debido a los encabezados

Cada capa en la red agrega un encabezado a los datos que introduce una sobrecarga debido a su tiempo de transmisión. Además, la capa de transporte divide sus datos en segmentos; esto se debe a que la capa de red (como en IPv4 o IPv6) tiene un tamaño máximo de paquete denominado MTU , típicamente 1.500 B en redes Ethernet. Este valor incluye el tamaño del encabezado de la capa de red (por ejemplo, el encabezado IPv4, que es de longitud variable pero generalmente 20 B de largo) y el encabezado de la capa de transporte (para TCP, también es variable en longitud pero generalmente 40 B de largo). Esto lleva a un tamaño máximo de segmento MSS (número de bytes de datos, sin encabezados, en un segmento) de 1500 - 40 - 20 = 1440 bytes.

Por lo tanto, si queremos enviar 6 kB de datos de capa de aplicación, debemos dividirlo en 6 segmentos, 5 de 1440 bytes cada uno y uno de 240 bytes. Sin embargo, en la capa de red terminamos enviando 6 paquetes, 5 de 1500 bytes cada uno y uno de 300 bytes, para un total de 6.3 kB.

Aquí no he considerado el hecho de que la capa de enlace (como en Ethernet ) agrega su propio encabezado y posiblemente también un sufijo, lo que aumenta aún más la sobrecarga. Para Ethernet esto es 14 bytes para el encabezado Ethernet, opcionalmente 4 bytes para la etiqueta VLAN, luego un CRC de 4 bytes y un espacio de 12 bytes, para un total de 36 bytes por paquete.

Si considera un enlace de tasa fija, digamos de 10 Mb / s, dependiendo de lo que mida obtendrá un rendimiento diferente. Normalmente quieres uno de estos:

El buen rendimiento, es decir, el rendimiento de la capa de aplicación, si lo que quiere medir es el rendimiento de la aplicación. Para este ejemplo, divide 6 kB por la duración de la transferencia.
El rendimiento de la capa de enlace, si lo que quiere medir es el rendimiento de la red. Para este ejemplo, divide 6 kB + TCP overhead + IP overhead + Ethernet overhead = 6.3 kB + 6 * 36 B = 6516 B por la duración de la transferencia.

Gastos generales de retransmisión

Internet es una red de mejor esfuerzo, lo que significa que los paquetes se entregarán si es posible, pero también pueden descartarse. Las gotas de paquete son corregidas por la capa de transporte, en el caso de TCP; para UDP, no existe tal mecanismo, lo que significa que a la aplicación no le importa si algunas partes de los datos no se entregan, o si la aplicación implementa la retransmisión en sí misma sobre UDP.

La retransmisión reduce el rendimiento por dos motivos:

a. Algunos datos deben enviarse nuevamente, lo que lleva tiempo. Esto introduce un retraso que es inversamente proporcional a la velocidad del enlace más lento en la red entre el emisor y el receptor (también conocido como el cuello de botella). segundo. La detección de que algunos datos no fueron entregados necesita retroalimentación del receptor al remitente. Debido a los retrasos de propagación (a veces llamados latencia, causados por la velocidad finita de la luz en el cable), la retroalimentación solo puede ser recibida por el emisor con cierta latencia, lo que ralentiza la transmisión aún más. En la mayoría de los casos prácticos, esta es la contribución más significativa al retraso adicional causado por la retransmisión.

Claramente, si usa UDP en lugar de TCP y no le preocupa la pérdida de paquetes, obtendrá un mejor rendimiento. Pero para muchas aplicaciones, la pérdida de datos no se puede tolerar, por lo que dicha medición no tiene sentido.

Hay algunas aplicaciones que sí usan UDP para transferir datos. Uno es BitTorrent, que puede usar TCP o un protocolo que ellos diseñaron llamado uTP , que emula TCP sobre UDP, pero apunta a ser más eficiente con muchas conexiones paralelas. Otro protocolo de transporte implementado a través de UDP es QUIC , que también emula TCP y ofrece la multiplexación de múltiples transferencias paralelas a través de una sola conexión, y reenvía la corrección de errores para reducir las retransmisiones.

Discutiré un poco la corrección de errores hacia adelante ya que está relacionada con su pregunta sobre el rendimiento. Una forma ingenua de implementarlo es enviando cada paquete dos veces; en caso de que uno se pierda, el otro todavía tiene una posibilidad de ser recibido. Esto reduce la cantidad de retransmisiones a la mitad, pero también reduce a la mitad su buen rendimiento ya que envía datos redundantes (¡tenga en cuenta que la red o el rendimiento de la capa de enlace sigue siendo el mismo!). En algunos casos, esto está bien; especialmente si la latencia es muy grande, como en enlaces intercontinentales o por satélite. Además, existen algunos métodos matemáticos donde no tiene que enviar una copia completa de los datos; por ejemplo, para cada n paquetes que envíe, envíe otro reduntant que sea el XOR (o alguna otra operación aritmética) de ellos; si el redundante se pierde, no importa; si se pierde uno de los n paquetes, puede reconstruirlo basándose en el redundante y el otro n-1. De este modo, puede configurar la sobrecarga introducida por la corrección de error de reenvío a cualquier cantidad de ancho de banda que pueda ahorrar.

Cómo está midiendo el tiempo de transferencia

¿La transferencia se completó cuando el emisor terminó de enviar el último bit a través del cable o también incluye el tiempo que tarda el último bit en llegar al receptor? Además, ¿incluye el tiempo que lleva obtener una confirmación del receptor, indicando que todos los datos se han recibido con éxito y no se necesita retransmisión?

Realmente depende de lo que quieras medir. Tenga en cuenta que para transferencias grandes, un tiempo de ida y vuelta adicional es insignificante en la mayoría de los casos (a menos que se esté comunicando, por ejemplo, con una sonda en Marte).

¿Cuál es esa característica clave en TCP que hace que tenga un rendimiento mucho más alto que UDP?

Esto no es verdad, aunque es un concepto erróneo común.

Además de retransmitir datos cuando sea necesario, TCP también ajustará su velocidad de envío para que no provoque la caída de paquetes al congestionar la red. El algoritmo de ajuste se ha perfeccionado durante décadas y, por lo general, converge rápidamente a la velocidad máxima admitida por la red (en realidad, el vínculo de cuello de botella). Por esta razón, generalmente es difícil superar el rendimiento de TCP.

Con UDP, no hay límite de velocidad en el emisor. UDP permite que la aplicación envíe todo lo que quiera. Pero si intenta enviar más de lo que la red puede manejar, se eliminarán algunos de los datos, lo que reducirá su rendimiento y también hará que el administrador de la red que está congestionando se enfade. Esto significa que enviar tráfico UDP a altas velocidades no es práctico (a menos que el objetivo sea hacer una red DoS).

Algunas aplicaciones de medios usan UDP pero limitan la velocidad de la transferencia en el emisor a un ritmo muy pequeño. Esto se usa típicamente en aplicaciones VoIP o Radio por Internet, donde requiere muy poco rendimiento pero baja latencia. Supongo que esta es una de las razones de la idea errónea de que UDP es más lento que TCP; ese no es el caso, UDP puede ser tan rápido como lo permita la red.

Como dije antes, hay protocolos como uTP o QUIC, implementados en UDP, que logran un rendimiento similar al TCP.

Es esto cierto ?

TCP throughput = (TCP Window Size / RTT)

Sin pérdida de paquetes (y retransmisiones), esto es correcto.

TCP throughput = BDP / RTT = (Link Speed in Bytes/sec * RTT)/RTT = Link Speed in Bytes/sec

Esto es correcto solo si el tamaño de la ventana está configurado con el valor óptimo. BDP / RTT es la velocidad de transferencia óptima (máxima posible) en la red. La mayoría de los sistemas operativos modernos deberían poder configurarlo de manera óptima.

¿De qué manera el rendimiento depende del tamaño del Bloque? ¿El tamaño del Bloque es igual a la ventana TCP o al tamaño del datagrama UDP?

No veo ningún tamaño de bloque en la documentación de iperf .

Si se refiere al tamaño de la ventana TCP, si es más pequeño que BDP, entonces su rendimiento será inferior al óptimo (porque pierde el tiempo esperando ACK en lugar de enviar más datos; si es necesario, puedo explicarlo más). Si es igual o superior al BDP, entonces logrará un rendimiento óptimo.