ns 3 project
1.0.0
% Alfred Tso Chun Fai 20012065g % Proyecto COMP5311: Análisis de rendimiento de TCP y UDP
nueva página
¿Incluso me pregunto por qué el navegador Chrome se siente mucho más rápido que Firefox cuando mira videos de Youtube? Lo hago y, como estudiante curioso, encendí Wireshark y capturé algo de tráfico y lo que encontré fue esto.
Según wiki 1 , QUIC es utilizado por más de la mitad de todas las conexiones desde el navegador web Chrome a los servidores de Google.
QUIC es un protocolo que tiene como objetivo mejorar las aplicaciones web que actualmente utilizan TCP 2 estableciendo una serie de UDP multiplexados y algunos incluso lo llamaron "TCP/2". Se supone que el próximo HTTP/3 (borrador de Internet a partir de febrero de 2021) también utilizará QUIC.
Espera... ¿Estamos usando UDP para reemplazar a TCP? Nos dijeron que UDP no es confiable, ¿por qué puede apuntar a "hacer obsoleto" a TCP? La comparación de los dos protocolos (TCP y UDP) es similar a comparar un tren con un avión en lugar de un Boeing con un Airbus (ambos transporte ). Sin embargo, todavía podemos compararlos con algunas métricas clave para vislumbrar en qué este QUIC eligió UDP para mejorar.
nueva página
nueva página
Comparar el protocolo de la capa de transporte no es una tarea fácil, ya que hay muchos factores que podrían afectar el resultado:
Algunos parámetros dentro del protocolo (TCP, por ejemplo) se dejan en manos de la implementación (lo que da lugar a la huella digital TCP/IP, que permite a un actor malicioso identificar, entre otras cosas, el sistema operativo del host), lo que significa que estas diferencias podrían tener un efecto sutil en la medición del desempeño
La ruta inmediata tomada por los paquetes ciertamente afectaría el resultado, por lo que los enrutadores inmediatos, los enlaces de cuello de botella intermedios y otro tráfico también podrían afectar los resultados.
Como se mencionó anteriormente, es posible que a menudo no estemos seguros del ancho de banda de esos enlaces inmediatos o simplemente del enlace entre el cliente y el servidor. Uno de los artículos mencionados partía del supuesto de que el enlace no tendría colisiones.
Hemos visto que el búfer podría haber impactado el rendimiento de estos protocolos y no sólo el lado del software es relevante, sino que la parte del hardware también importa y, a menudo, no podíamos controlar estos detalles de nivel inferior.
En la mayoría de los trabajos anteriores, los autores a menudo implementan un programa personalizado para realizar el experimento, también debemos considerar el efecto de cómo estas implementaciones de software podrían afectar el resultado, digamos el intervalo en el que se envían los paquetes UDP, y si existen limitaciones en el lenguaje se utiliza en cuanto a, para nuestro propósito actual, los intervalos de envío.
Dadas todas estas consideraciones, utilizaremos una topología de red simple con configuraciones lo más cercanas a la realidad posible. Cuando se trate de detalles subyacentes, como el tamaño de la cola del búfer o los protocolos, usaremos los mismos para ambos protocolos. Como tal, compararemos TCP y UDP sobre IPv4 en hosts uno a uno cableados utilizando el rendimiento, el retraso promedio y la fluctuación promedio como nuestros indicadores de rendimiento.
Enviaremos 10, 100 y paquetes range(1e4, 1e5, 1e4) , cada uno de 1472 bytes en una aplicación UDP y el número equivalente de bytes en una aplicación TCP para observar los flujos de las aplicaciones TCP y UDP.
JitterSum contiene la suma de todos los valores de fluctuación de retardo (variación de retardo) de extremo a extremo para todos los paquetes recibidos del flujo. Aquí definimos la fluctuación de un paquete como la variación del retraso con respecto al último paquete del flujo, es decir
nueva página
La primera cuestión al diseñar dicho experimento es simular o no. La simulación podría ser mejor en nuestro estudio ya que podemos tener más control sobre las consideraciones que mencionamos. El mayor inconveniente es ¿cómo podemos estar seguros de que el resultado es "real"? La respuesta a esto es que siempre que tengamos un alcance claramente definido para el experimento y controles frecuentes de cordura en estos alcances, podremos tener una idea de cuán "reales" pueden ser los resultados.
ns-3 es un simulador de red de eventos discretos de código abierto que se utiliza principalmente con fines educativos o de investigación escrito en C++. El propio simulador dispone de una documentación completa disponible online.
Para nuestro propósito actual, sólo necesitamos comprender las principales abstracciones de ns-3
{ancho=75%}
Es como los procesos en nuestra computadora, utiliza "sockets" para enviar datos a la capa inferior. Instalaremos una BulkSendApplication lista para usar en ns-3 usando un socket TCP y un UDPClient y un UDPServer para enviar paquetes UDP y un FlowMonitor en ambos casos para monitorear los paquetes.
Enviaremos paquetes en un intervalo de 2 microsegundos, que es el retraso del canal subyacente que se especifica a continuación.
Aquí se refiere a la carga útil. Dado que MTU es 1500, naturalmente querremos utilizar 1500 bytes. Sin embargo, el encabezado IP y el encabezado UDP requieren 20 + 8 bytes, por lo que deberíamos usar 1472 en lugar de 5 . Esto se confirma en la simulación; el uso de paquetes de 1500 bytes podría perjudicar el rendimiento.
BulkSendApplication"Este generador de tráfico simplemente envía datos lo más rápido posible hasta MaxBytes o hasta que se detiene la aplicación (si MaxBytes es cero). Una vez que se llena el búfer de envío de la capa inferior, espera hasta que haya espacio libre para enviar más datos, esencialmente manteniendo un flujo constante de datos".
Configuramos MaxBytes en Bytes totales (PacketCount * PacketSize) de UDP para comparar el rendimiento y SendSize no importa en algunos experimentos.
También se llama InternetStackHelper , que generalmente incluye UDP, TCP Sockets, IPv4 y, para nuestro propósito actual, TrafficControlLayer , que incluye una cola y, cuando esté llena, notificará a la capa superior.
Esto corresponde tanto al hardware (Tarjetas de interfaz de red, NIC) como a los controladores de software de los mismos y también incluye una cola para paquetes, por lo que hay dos niveles de cola en ns-3
Son los hosts finales mediante los cuales podemos instalar Application , InternetStack y NetDevice , de manera similar a nuestra computadora. Crearemos dos Node y los conectaremos con algo similar a un cable Ethernet.
Proporciona un canal de comunicación a Node y usaremos un canal CSMA (como Ethernet). Los detalles importantes aquí es la elección de estos atributos disponibles para ajustar: MTU, DataRate y Delay. Usaremos MTU estándar (sin trama Jumbo, a veces disponible para una red específica), gigabit y un retraso de 2 microsegundos. La razón de 2 microsegundos es que la luz viaja 600 m, en comparación con otros estudios que utilizan un retraso de 0.
nueva página
Los resultados son los siguientes:
Observamos que el rendimiento de UDP para 14720, 147200 bytes enviados superó los 1000 Mbps (nuestro ancho de banda es de 1 Gbps). Luego analizamos la pérdida de paquetes.
Podemos ver que en 147200 Bytes se pierden 97 de 100 paquetes. Es seguro decir que deberíamos descartar estos 2 e investigar más a fondo.
También podemos ver que el rendimiento de TCP aumentó gradualmente y se estabilizó en alrededor de 400 Mbps.
Debido a la falta de control del tráfico, los paquetes UDP pueden quedar "atascados" en las colas de la capa inferior. El resultado también podría deberse a que nuestro rápido envío permanente de paquetes causa la congestión. Será necesario realizar más investigaciones para confirmarlo, como reducir el buffer para ver si el retraso realmente aumenta.
El retraso promedio mostró caídas justo después del "pico" y luego volvió a aumentar gradualmente. Esto podría deberse al ajuste cwnd para evitar la congestión. Se necesita más investigación ya que debemos confirmar que el algoritmo para el control de la congestión realmente produce tales patrones porque hay muchas opciones para ello en ns-3 (Veno, Cubic... etc.)
Se espera que la fluctuación promedio disminuya a medida que el sistema se "estabilice" y la variación en el retardo sea menor.
La ausencia de control de tráfico en UDP significa que los paquetes se empujarán continuamente hacia abajo en la pila y se enviarán sin interferencias; la variación en el retraso debe ser mínima, mientras que el retraso de los paquetes consecutivos podría ser grande debido a dicho control de tráfico.
nueva página
BulkSendApplication se aseguró de que una vez que se llenara el búfer de envío de la capa inferior, esperaría. Entonces, el único lugar donde podemos descartar paquetes es en el canal en el que necesitaremos introducir el error.
UDPClient no tiene tal control de tráfico por lo que pudimos observar la pérdida de paquetes.
Podría ser simplemente el rendimiento (mayor rendimiento) y la fluctuación (menor variación de retraso). El mayor retraso promedio se debe principalmente a la falta de control del tráfico que el QUIC pretende mover el "algoritmo de control de congestión al espacio del usuario... en lugar del espacio del núcleo" 1 .
https://github.com/alfredtso/ns-3-project
nueva página
recursos de formación ns-3
Borrador HTTP/3
RÁPIDO ↩ ↩ 2
QUIC Google Doc ↩
Yuan-Cheng Lai, Ahsan Ali, Md. Shohrab Hossain, Ying-Dar Lin, Modelado de rendimiento y análisis de flujos TCP y UDP sobre redes definidas por software, Journal of Network and Computer Applications, Volumen 130, 2019, páginas 76-88, ISSN 1084-8045 ↩
Jingyi He, S.-H.Gary Chan, Rendimiento de TCP y UDP para Internet a través de redes ópticas de conmutación de paquetes, Computer Networks, volumen 45, número 4, 2004, páginas 505-521, ISSN 1389-1286 ↩
Eric Gamess, Rina Surós, Un modelo de límite superior para el rendimiento de TCP y UDP en IPv4 e IPv6, Journal of Network and Computer Applications, volumen 31, número 4, 2008, páginas 585-602, ISSN 1084-8045 ↩ ↩ 2
Shahrudin Awang Nor, Raaid Alubady, Wisam Abduladeem Kamil, Rendimiento simulado de los protocolos TCP, SCTP, DCCP y UDP en una red 4G, Procedia Computer Science, volumen 111, 2017, páginas 2-7, ISSN 1877-0509 ↩
