Padrão Ethernet Fluxos TCP e UDP concorrentes
Por: kustavo • 21/2/2016 • Resenha • 2.484 Palavras (10 Páginas) • 542 Visualizações
Fluxos TCP e UDP concorrentes.
Durante a disputa por recursos de rede, o TCP ajusta a taxa de envio para evitar sobrecarregar tanto no receptor quanto na rede. A limitação da taxa de envio para evitar a sobrecarga de um receptor é chamada de controle de fluxo e limitação da taxa de envio para evitar a sobrecarga da rede é chamada de controle de congestionamento. O UDP não contém algoritmos de controle de fluxo nem de controle de congestionamento, e enviará dados para a rede tão rápido quanto as aplicações produzirem.
O TCP usa o campo Janela de Notificação do Receptor do cabeçalho do segmento TCP para implementar o controle de fluxo. Esse campo especifica a quantidade de dados que a outra extremidade da conexão quer e pode receber. Os emissores de fluxo TCP mantêm outro limite, chamado janela de congestionamento que se inicia com o tamanho máximo de segmento (MMS) igual a 1 e, a a partir daí, aumenta a cada segmento que é confirmado com sucesso. O limite real da taxa do emissor de fluxo TCP é igual ao valor mínimo da janela de notificação do receptor e da janela de congestionamento.
Inicialmente, a janela de congestionamento cresce exponencialmente a cada confirmação. Essa fase de crescimento exponencial é chamada de início lento, uma vez que é mais lento do que enviar imediatamente toda a janela de notificação do receptor. Acima de um limite determinado de maneira adaptativa, o TCP passa a apresentar um aumento aritmético na janela de congestionamento. Essa fase é chamada de impedimento de congestionamento, cada segmento confirmado com sucesso aumenta a janela de congestionamento em 1 MSS.
Se em algum momento um timer de transmissão expirar, sinalizando a perda de um pacote, então a janela de congestionamento será configurada novamente com a tamanho de 1 MSS e um limite entre i início lento e o impedimento de congestionamento com metade do valor da janela de congestionamento no ponto que a perda aconteceu.
O TCP adapta às alterações de fluxo de dados variando a janela de congestionamento, assim como a duração do timer de retransmissão e o limite do início lento. Esses aspectos do TCP permitem que se equilibre as necessidades da rede como um todo, ao mesmo tempo que possibilita que cada fluxo use uma parcela justa da largura de banda.
O UDP não faz nada para limitar a taxa de envio das aplicações, portanto as próprias aplicações que usam UDP devem implementar algoritmos de controle de congestionamento. Essas aplicações são consideradas TCP-Friendly.
Dois fluxos TCP concorrentes
No gráfico da conexão 1, quando há apenas um fluxo (0...1,7s), a linha de crescimento é ingrime, ou seja, há muitos bytes sendo transferidos por unidade de tempo. Quando ocorre a introdução do segundo fluxo (1,7s...6,6s) a linha de crescimento se torna mais plana.
No gráfico da conexão 2, após o fim do fluxo 1 (4,9s...6,6s) a linha de crescimento é mais íngreme.
[pic 1]Figura 1: Gráfico do fluxo 1
[pic 2]Figura 2: Gráfico do fluxo 2
Esses gráficos mostram que o TCP se adapta para compartilhar a largura de banda da rede com outros fluxos. No caso de concorrência ele diminui a taxa de envio e aumenta a taxa de envio se mais largura de banda fica disponível.
UDP concorrendo com TCP
O fluxo TCP tem acesso exclusivo à rede por 2,3 segundos (0...2,3s), o fluxo UDP dura 1,2 segundos (2,3s...3,5s) e o fluxo TCP volta a ter acesso exclusivo à rede por 1,3s (3,5s...4,8s). Durante a conexão UDP a linha é basicamente plana, indicando que o TCP conseguiu realizar pouco ou nenhum progresso na transferência de dados durante esse tempo. Portanto é possível ver que o UDP não é TCP-Friendly.
[pic 3]Figura 3: Gráfico do fluxo TCP
Dois fluxos UDP concorrentes
O primeiro fluxo UDP tem acesso exclusivo por 0,4s (0...0,4s) e o restante do tempo os fluxos compartilham a rede pelo resto da transmissão. No primeiro fluxo 19% dos pacotes não foram vistos na rede e não foi possível verificar a estatística de quantos pacotes chegaram no receptor provavelmente pela perdas dos pacotes especiais de fim de fluxo. No segundo fluxo todos os pacotes foram encontrados na rede, mas apenas 8% conseguiram chegar ao receptor.
Fazer os exercícios de 1 a 7 da seção de Perguntas.
Questão 01 – TCP – UDP
Durante a transmissão UDP foram enviados:
14 pacotes TCP destinados para 192.168.0.102
5 pacotes TCP destinados para 192.168.0.100
Filtro usado:
frame.time_relative >= 2.331609000 && frame.time_relative <= 2.508388000 && tcp && ip.dst == 192.168.0.102
[pic 4]Figura 4: Pacotes destinados à 192.168.0.102
Filtros usado:
frame.time_relative >= 2.331609000 && frame.time_relative <= 2.508388000 && tcp && ip.dst == 192.168.0.100
[pic 5]Figura 5: Pacotes destinados à 192.168.0.100
Questão 02 - TCP - UDP
Durante a transmissão UDP foram transmitidos 15056 bytes pelo TCP.
Durante toda a transmissão foram enviados 2228684 bytes pelo TCP.
Os dados foram obtidos utilizando a opção: statistics -> summary
Filtro usado:
frame.time_relative >= 2.331609000 && frame.time_relative <= 2.508388000 && tcp
[pic 6]Figura 6: Estatísticas de pacotes TCP enviados durante a conexão UDP
Filtro usado:
tcp
[pic 7]Figura 7: Estatísticas de pacotes TCP enviados durante toda a conexão
Questão 03 - TCP - TCP
A inclinação da reta se altera em 1,7 segundos. O segundo fluxo inicia em A segunda conexão inicia em 1.674542 segundos, correspondendo ao tempo na alteração da reta. Isso ocorre porque o TCP se adapta para compartilhar a largura de banda entre os dois fluxos.
Filtro usado:
tcp && ((tcp.srcport==4421 && tcp.dstport == 5001) || (tcp.srcport==5001 && tcp.dstport == 4421))
[pic 8]Figura 8: Gráfico fluxo TCP
Questão 04 - TCP – TCP
Não houve retransmissão de pacotes. O comando tcp.analysis.retransmission não retornou resultados. O TCP regula o fluxo para que ambas conexões possam compartilhar a banda da rede.
Filtro usado:
tcp.analysis.retransmission
Questão 05 - UDP – UDP
Depois da segunda transmissão, foram encontrados 6 pacotes. O intervalo entre os pacotes da porta 4445 à 5001 é composto pelos intervalos dos pacotes: 1653…3704 (0,145s...1,133s). Todos estes pacotes tiveram uma redução no tamanho do quadro para 46 bytes. Isso pode ter ocorrido devido a atuação da aplicação que detectou perdas e/ou atraso de pacotes.
...