Padrão Ethernet Fluxos TCP e UDP concorrentes

...

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

[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.

Filtro usado:

udp && udp.srcport == 4445 && udp.dstport == 5001 && frame.time_relative > 0.475264

[pic 9]Figura 9: Pacotes UDP após segunda transmissão

Questão 06 - UDP – UDP

O último a chegar não possui uma vantagem fundamental, uma vez que sem a atuação da aplicação, não há controle sobre fluxo UDP. Para realizar o teste poderia ser feito o mesmo teste com equipamentos de outros fabricantes e com outras aplicações.

Questão 07 - UDP – UDP

Alteração do buffer para 1000 bytes. Neste caso os datagramas serão reduzidos para 1000 bytes ao invés do padrão de 8192 bytes. O rastreios seriam em torno de 8 vezes maiores.

Realizar o que foi solicitado na seção de Discussão e Investigação.

Questão 01

O número sequencial indica a posição relativa, dentro do stream de bytes da conexão. Refere-se ao fluxo de dados que vai na mesma direção do segmento. Com 32 bytes é possível enviar numa mesma conexão até (233-1) = 8589934591 bits = 1GB, já que essa é a maior sequencia que é possível ser informada.

O número de confirmação indica qual é a próxima posição do stream de bytes da conexão que se espera receber. Como também precisa guardar as posição relativas (em bytes), deve possuir um campo com o mesmo tamanho do número sequencial (32 bis). Refere-se ao fluxo de dados na direção contrária ao segmento.

A janela de notificação do receptor indica quantos bytes o receptor possui capacidade de receber em seu buffer sem enviar o aviso de recepção. Com 16 bits é possível definir definir a janela com até (217-1) = 131071 bits = 16384 bytes.

Questão 02

Como foi visto anteriormente, o UDP não é amigáveis com o TCP (TCP-Friendly), ou seja, não possui mecanismos para compartilhar banda da rede. Desda forma o UDP pode consumir a banda de rede de forma egoísta, prejudicando o tráfego dos pacotes TCP.

Questão 03

As conexões TCP procuram sempre se adaptar às condições da rede, compartilhando a largura de banda de maneira justa, aproveitando a banda disponível. As aplicações baseadas em UDP, quando competem com tráfegos TCP, tendem a ocupar toda a banda disponível, pois não reagem a nenhuma notificação de congestionamento da rede. Aplicações UDP amigáveis com o TCP (TCP-Friendly), apresentar mecanismos de controle de congestionamento, permitindo a adaptar os fluxos UDP para coexistirem com as conexões TCP sem prejudicá-las.

Questão 04

TCP Tahoe

Como a primeira implementação de algoritmo de controle de congestionamento TCP, o TCP Tahoe começa seu funcionamento com a utilização do Slow Start (Partida Lenta), o qual inicia o envio de dados com um segmento e de acordo com o envio e reconhecimento bem sucedido dos segmentos, a taxa de envio vai aumentando exponencialmente até ocorrer perda. A janela de congestionamento (Congestion Window – CWND) é a medida dinâmica da transmissão de dados da rede. Essa janela impõe limite ao envio de dados do transmissor. A janela CWND começa com o valor de 1 segmento e vai crescendo a cada RTT (Round Trip Time) que representa o tempo decorrido a transmissão de um pacote e o recebimento do ACK. Se houver um evento de perda de pacote, o remetente TCP reestabelece o valor da janela CWND para 1, e o processo de partida lenta se inicia novamente.

No momento em que o processo de Partida Lenta se inicia novamente, o remetente TCP também estabelece o valor de uma segunda variável chamada ssthresh (slow start threshold – Limiar de Partida Lenta) para CWND / 2 – metade do valor da janela de congestionamento, isso quando o congestionamento for detectado. Dessa forma, no segundo modo de uso, se a janela de congestionamento CWND for menor que a variável ssthresh, a janela continua a crescer exponencialmente, mas se a janela de congestionamento CWND se igualar ou ficar maior que o valor da variável ssthresh, a Partida Lenta termina e o TCP