ns 3 project
1.0.0
% Alfred Tso Chun Fai 20012065g % Projeto COMP5311: Análise de desempenho de TCP e UDP
novapágina
Você até se pergunta por que o navegador Chrome parece muito mais rápido que o Firefox ao assistir vídeos do Youtube? Sim, e como um estudante curioso, liguei o Wireshark e capturei algum tráfego e o que descobri foi isso.
De acordo com o wiki 1 , o QUIC é usado por mais da metade de todas as conexões do navegador Chrome aos servidores do Google.
QUIC é um protocolo que visa melhorar aplicações web que atualmente utilizam TCP 2 , estabelecendo uma série de UDP multiplexados e alguns até o chamam de "TCP/2". O próximo HTTP/3 (Internet-Draft de fevereiro de 2021) supostamente também usa QUIC.
Espere... Estamos usando o UDP para substituir o TCP? Fomos informados de que o UDP não é confiável, por que ele pode ter como objetivo "obsoletar" o TCP. A comparação dos dois protocolos (TCP e UDP) é semelhante à comparação do trem com o avião, em vez de Boeing com Airbus (ambos os transportes ). No entanto, ainda podemos compará-los com algumas métricas importantes para ter uma ideia do que este QUIC escolheu para melhorar o UDP.
novapágina
novapágina
Comparar o protocolo da camada de transporte não é uma tarefa fácil, pois há muitos fatores que podem afetar o resultado:
Alguns parâmetros dentro do protocolo (TCP, por exemplo) são deixados para a implementação (o que dá origem à impressão digital TCP/IP, permitindo que o ator mal-intencionado identifique, entre outras coisas, o sistema operacional do host), o que significa que essas diferenças podem ter um efeito sutil no medição de desempenho
A rota imediata seguida pelos pacotes certamente afetaria o resultado, de modo que os roteadores imediatos, os gargalos dos links intermediários e outros tráfegos também poderiam afetar os resultados.
Conforme mencionado acima, muitas vezes podemos não ter certeza sobre a largura de banda desses links imediatos ou simplesmente sobre o link entre o cliente e o servidor. Um dos artigos mencionados presumiu que o link não teria colisões.
Vimos que o buffer pode ter impactado o desempenho desses protocolos e não apenas o lado do software é relevante, a parte do hardware também é importante e muitas vezes não conseguimos controlar esses detalhes de nível inferior.
Na maioria dos trabalhos anteriores, os autores frequentemente implementam um programa personalizado para conduzir o experimento, também precisamos considerar o efeito de como essas implementações de software podem afetar o resultado, digamos, o intervalo pelo qual os pacotes UDP são enviados e se há limitação em a linguagem usada em relação, para o nosso propósito atual, aos intervalos de envio.
Dadas todas essas considerações, utilizaremos uma topologia de rede simples com configurações o mais próximas possível da realidade. Onde os detalhes subjacentes, como tamanho da fila de buffer ou protocolos, usaremos os mesmos para ambos os protocolos. Como tal, compararemos TCP e UDP sobre IPv4 em hosts um-para-um com fio usando taxa de transferência, atraso médio e jitter médio como nossos indicadores de desempenho.
Enviaremos pacotes 10, 100 e range(1e4, 1e5, 1e4) , cada um com 1472 bytes em aplicação UDP e o número equivalente de bytes em uma aplicação TCP para observar os fluxos de aplicações TCP e UDP.
JitterSum contém a soma de todos os valores de jitter de atraso (variação de atraso) de ponta a ponta para todos os pacotes recebidos do fluxo. Aqui definimos jitter de um pacote como a variação do atraso em relação ao último pacote do fluxo, ou seja
novapágina
A primeira questão ao projetar o referido experimento é simular ou não. A simulação pode ser melhor em nosso estudo, pois podemos ter mais controle sobre as considerações que mencionamos. A maior desvantagem é como podemos ter certeza de que o resultado é “real”? A resposta para isso é que, desde que tenhamos um escopo claramente definido para o experimento e verificações frequentes de sanidade desses escopos, podemos ter uma ideia de quão “reais” os resultados podem ser.
ns-3 é um simulador de rede de eventos discretos de código aberto usado principalmente para fins de pesquisa ou educacionais, escrito em C++. O próprio simulador possui uma documentação abrangente disponível online.
Para o nosso propósito atual, precisamos apenas entender as principais abstrações do ns-3
{largura=75%}
É como os processos do nosso computador, ele usa “soquetes” para enviar dados para a camada inferior. Instalaremos um BulkSendApplication pronto para uso no ns-3 usando soquete TCP e um UDPClient e um UDPServer para enviar pacotes UDP e um FlowMonitor para ambos os casos para monitorar os pacotes.
Estaremos enviando pacotes em um intervalo de 2 microssegundos, que é o atraso do canal subjacente especificado abaixo
Aqui se refere à carga útil. Como o MTU é 1.500, naturalmente desejaremos usar 1.500 bytes. O cabeçalho IP e o cabeçalho UDP, entretanto, requerem 20 + 8 bytes, portanto devemos usar 1472 em vez de 5 . Isto é confirmado na simulação; o uso de pacotes de 1.500 bytes pode prejudicar o desempenho da taxa de transferência.
BulkSendApplication"Este gerador de tráfego simplesmente envia dados o mais rápido possível até MaxBytes ou até que o aplicativo seja interrompido (se MaxBytes for zero). Depois que o buffer de envio da camada inferior é preenchido, ele espera até que haja espaço livre para enviar mais dados, essencialmente mantendo um fluxo constante de dados.".
Definimos MaxBytes como Total Bytes (PacketCount * PacketSize) do UDP para comparar o desempenho e SendSize não importa em alguns experimentos
Também chamado de InternetStackHelper , que geralmente inclui UDP, TCP Sockets, IPv4 e, para nosso propósito atual TrafficControlLayer , que inclui uma fila e quando estiver cheia notificará a camada superior
Isso corresponde tanto ao hardware (placas de interface de rede, NICs) quanto aos drivers de software deles e também inclui uma fila para pacotes, portanto, há dois níveis de enfileiramento no ns-3
São os hosts finais pelos quais podemos instalar Application , InternetStack e NetDevice , semelhantes ao nosso computador. Estaremos criando dois Node e conectando-os com algo semelhante a um cabo Ethernet.
Fornece canal de comunicação para Node e usaremos um canal CSMA (como Ethernet). O detalhe importante aqui é a escolha destes atributos disponíveis para ajustes: MTU, DataRate e Delay. Estaremos usando MTU padrão (sem quadro Jumbo, às vezes disponível para redes específicas), gigabit e um atraso de 2 microssegundos. A razão para 2 microssegundos é que a luz viaja 600 m, em comparação com outros estudos que usam atraso de 0.
novapágina
Os resultados são os seguintes:
Observamos que a taxa de transferência UDP para 14.720, 147.200 bytes enviados excedeu 1.000 Mbps (nossa largura de banda é de 1 Gbps). Em seguida, analisamos a perda de pacotes
Podemos ver que em 147.200 bytes, 97 de 100 pacotes são perdidos. É seguro dizer que devemos abandonar estes 2 e investigar mais detalhadamente
Também podemos ver que a taxa de transferência do TCP aumentou gradualmente e se estabilizou em cerca de 400 Mbps.
Devido à falta de controle de tráfego, os pacotes UDP podem ficar “presos” nas filas das camadas inferiores. O resultado também pode ser devido ao nosso envio rápido e sempre ativo de pacotes que causa o congestionamento. Mais investigações serão necessárias para confirmar, como reduzir o buffer para ver se o atraso realmente aumenta.
O atraso médio apresentou quedas logo após o "pico" e depois aumentou gradualmente novamente. Isso pode ser devido ao ajuste cwnd para evitar congestionamentos. Mais investigações são necessárias, pois precisamos confirmar se o algoritmo para controle de congestionamento realmente produz tais padrões porque há muitas opções para isso no ns-3 (Veno, Cubic... etc).
Espera-se que o jitter médio diminua à medida que o sistema se "estabilize" e a variação no atraso seja menor.
A ausência de controle de tráfego no UDP significa que os pacotes serão continuamente empurrados para baixo na pilha e enviados sem interferência, a variação no atraso deve ser mínima, enquanto o atraso dos pacotes consecutivos pode ser grande devido ao referido controle de tráfego.
novapágina
O BulkSendApplication certificou-se de que, uma vez preenchido o buffer de envio da camada inferior, ele esperaria. Portanto, o único lugar onde podemos descartar pacotes é no canal no qual precisaremos introduzir o erro.
UDPClient não possui esse controle de tráfego, portanto pudemos observar a perda de pacotes.
Pode ser simplesmente o rendimento (maior rendimento) e o jitter (menor variação de atraso). O maior atraso médio deve-se principalmente à falta de controle de tráfego que o QUIC pretende mover o “algoritmo de controle congestionado para o espaço do usuário… em vez do espaço do kernel” 1 .
https://github.com/alfredtso/ns-3-project
novapágina
recursos de treinamento ns-3
Rascunho HTTP/3
RÁPIDO ↩ ↩ 2
QUIC GoogleDoc ↩
Yuan-Cheng Lai, Ahsan Ali, Md. Shohrab Hossain, Ying-Dar Lin,Modelagem de desempenho e análise de fluxos TCP e UDP em redes definidas por software, Journal of Network and Computer Applications, Volume 130, 2019, páginas 76-88, ISSN 1084-8045 ↩
Jingyi He, S.-H.Gary Chan, Desempenho de TCP e UDP para Internet em redes ópticas de comutação de pacotes, Redes de Computadores, Volume 45, Edição 4, 2004, Páginas 505-521, ISSN 1389-1286 ↩
Eric Gamess, Rina Surós, Um modelo de limite superior para taxa de transferência TCP e UDP em IPv4 e IPv6, Journal of Network and Computer Applications,Volume 31, Edição 4, 2008, Páginas 585-602, ISSN 1084-8045 ↩ ↩ 2
Shahrudin Awang Nor, Raaid Alubady, Wisam Abduladeem Kamil, desempenho simulado dos protocolos TCP, SCTP, DCCP e UDP na rede 4G, Procedia Computer Science, Volume 111, 2017, páginas 2-7, ISSN 1877-0509 ↩
