INF01154 Redes de Computadores N Turma B Laboratório 5

Transcrição

1 INF01154 Redes de Computadores N Turma B Laboratório 5 André Moraes Vítor De Araújo 1. Instalar o software Polycom PVX e estabelecer uma chamada em duplas. Medir o atraso ida e volta da transmissão com câmera (não é com captura de tela). Disparar o xnote stopwatch na máquina A. A máquina A filma (com a webcam) a tela da máquina A, transmitindo essa imagem para a máquina B. A máquina B filma a tela. Na máquina A é recebida a imagem transmitida, do seu próprio cronômetro. Captura-se a tela e obtém-se o atraso. Observa-se que o cronômetro exibido diretamente pela máquina conta 01:06.03, enquanto o visto com atraso de ida e volta conta 01: Logo, o atraso é de 0.42 segundo. 2. Instalar o sniffer de redes Wireshark e fazer uma comunicação em duplas via PVX. Sugestão: usar filtros: ip.src==... ou RTCP ou RTP ou... a. Identificar cabeçalhos RTP e RTCP (mostrar uma imagem com RTP e outra com

2 RTCP no wireshark). Qual a diferença de direção e quantidade de pacotes de cada um? Os pacotes RTP são bastante freqüentes (vários são enviados a cada segundo, como se pode observar pelos timestamps dos pacotes).

3 Os pacotes RTCP são menos freqüentes (um pequeno conjunto de pacotes é enviado a cada aproximadamente 2 segundos). A direção dos pacotes RTP se dá no sentido do transmissor da imagem/áudio para o receptor que visualizará ela. Como no exemplo estamos filmando nos dois sentidos, há envio de RTPs por ambas as máquinas. As duas atuam como transmissor /receptor. No RTCP, tanto o transmissor quanto o receptor fazem envios de pacote para uma mesma conexão. b. Para o RTP, identificar e justificar os campos versão, Payload Type, Sequence Number, timestamp.

4 Versão: indica a versão do protocolo RTP que está sendo empregada. No caso, trata-se da versão 2, definida pela RFC Ela pode ser encontrada em: Payload type: código indicando o tipo de dado transportado pela área de dados do pacote. No caso, são usados os códigos 126 e 127, cujo significado é definido dinamicamente por meios externos ao RTP. [RFC 1889, página 8, Non-RTP means] Sequence number: (16 bits) Serve para o receptor detectar perda de pacotes e a aplicação tomar alguma medida para restauração ou recuperação do erro: Por exemplo: em caso de vídeo, costuma-se manter o mesmo quadro anterior recebido ok. Isso dá a sensação de congelamento da imagem. O RTP não oferece garantia de entrega, apenas de detecção em caso de perda. Timestamp: Serve para o receptor saber quando deverá ser reproduzido o quadro recebido. A granularidade do tempo informado depende da aplicação. c. Descobrir quais pacotes são de áudio e quais são de vídeo. Justificar, utilizando como base a diferença entre tamanho e quantidade dos pacotes de cada fluxo. Utilize como apoio

5 o timestamp dos pacotes. Sugere-se fortemente filtrar por fluxo. Observa-se que os pacotes com payload type igual a 126 têm cerca de 934 bytes e ocorrem em intervalos de aproximadamente segundo. Os com payload type igual a 127 têm cerca de 294 bytes, e ocorrem em intervalos de segundo. Conclui-se daí que os pacotes com tipo 126 correspondem ao vídeo, enquanto os com tipo 127 correspondem ao áudio. 3. Para a codificação de áudio utilizada e características do laboratório, calcule: a. Tempo médio de inserção 2,24 *10-5 s. b. Atraso no meio físico, supondo 40m a distância entre sua máquina e o switch do INF. Como tanto a origem quanto o destino ficam a 40m do switch, a distância total a ser percorrida é de 80 metros. Velocidade de propagação: aproximadamente 2/3 da velocidade da luz, i.e., m/s. Distância total percorrida: 80m Atraso: 80 / s = (80/200) µs = 0.4 µs 4. Leia o help do ping (ping /?) e efetue os seguintes testes: a. Fazer um ping com 8 requisições de echo, tamanho do pacote de 200 bytes, TTL de 80. Mostre o comando utilizado e prove que funcionou através de uma imagem. O comando utilizado no Linux foi 'ping -s '.

6 O ping mostra o valor de TTL do pacote de resposta, não o utilizado no envio. Para verificar que o TTL do pacote de envio é de fato 80, podemos usar o sniffer:

7 b. Fazer um ping forçando a não fragmentação do pacote (-f) e tamanho do pacote de 1600 bytes. Verificar qual o máximo tamanho do pacote que funciona. Explique. O tamanho máximo para a área de dados do pacote ICMP não-fragmentado é de Isso ocorre porque o tamanho total do pacote será bytes do header IP +8 bytes do header ICMP = 1500, que é o tamanho máximo para o payload de um frame Ethernet. c. Qual a mensagem (pacote de dados) enviados num comando de ping? Sugestão: analise o pacote ICMP. A área de dados do ping consisite de bytes sucessivamente incrementados ( ). Segundo a manpage do ping, se o pacote possuir pelo menos 8 bytes de dados, os primeiros 8 bytes da seqüência são substituídos por uma timestamp, que é usada para calcular o tempo de ida e volta do pacote. 5. Utilizar um sniffer de redes para analisar o funcionamento do ping. Capturar o ping de sua máquina para um vizinho, preencha na tabela linha a linha a seqüência de comandos de um ping, explicando cada linha (mostrando o endereço nível 2 e nível 3 envolvido em cada linha). Também deve ser considerado o protocolo ARP, além do ICMP. Pode-se utilizar a simbologia MAC_A (MAC da máquina A), MAC_B (MAC da máquina B) e MAC-R (MAC do roteador), por exemplo. Da mesma forma, pode-se utilizar IP_A, IP_B, etc. Quando não existir pacotes no nível, basta colocar Não tem na tabela. Protocolo Nível 2 Nível 3 Descrição ARP request MAC_A->Broadcast - Informe MAC_B à máquina com MAC_A

8 ARP reply MAC_B->MAC_A - Máquina B informa seu ARP à máquina A ICMP request MAC_A->MAC_B IP_A->IP_B Ping de A para B ICMP reply MAC_B->MAC_A IP_B->IP_A Resposta de B para A 6. Repetir a tabela acima, porém fazendo ping para uma subrede diferente. Qual a principal diferença? Protocolo Nível 2 Nível 3 Descrição ARP request MAC_A->Broadcast - Informe o MAC do roteador à máquina com MAC_A ARP reply MAC_R->MAC_A - Roteador informa seu ARP à máquina A ICMP request MAC_A->MAC_R ICMP request MAC_R->MAC_A IP_A->IP_B Ping de A para B (via roteador) IP_B->IP_A Reposta de B para A (via roteador) A principal diferença é que o ARP request é do MAC do roteador, não da máquina de destino. Além disso, toda a comunicação com a máquina destino se dá por intermédio do roteador, usando o ARP do roteador. 7. SOBRE O ARP: a. Explicar o funcionamento do protocolo ARP baseado nos seus campos de cabeçalho. Para isso, pode-se olhar na especificação do protocolo (buscar na RFC) ou analisar no sniffer, pois o mesmo provê todos os campos do protocolo. Explique o motivo do ARP request não conter o endereço MAC do destino (campo zerado), e o motivo que o ARP reply contém todos os campos preenchidos. Uma requisição ARP (Operation = 1, ou OpCode) é feita preenchendo os seguintes campos: IP do solicitante: Para saber a quem deve ser respondido. MAC do solicitante: Para saber a interface de quem deve ser respondido. IP do alvo: Queremos saber qual a interface MAC do IP que possuímos MAC do alvo: Esse campo é zerado, pois é o campo que queremos saber. A resposta do ARP (Operation = 2), que é dada pela máquina que possui o endereço, contém: IP do solicitante: O IP da máquina alvo (aquela que a requisição estava querendo saber) MAC do solicitante: A informação do MAC que o requisitante estava necessitando. IP do alvo: IP de quem fez a solicitação MAC do alvo: MAC de quem fez a solicitação. Outras informações presentes no cabeçalho (tanto na requisição quanto na resposta) são: Hardware type: Protocolo de Enlace: Ethernet tem o valor 1. Protocol type: Protocolo de rede: IPv4 tem o valor 0x800

9 Também possui campos que indicam os tamanhos de endereço da camada de enlace e da camada de nível superior (camada de rede), o que permite que o protocolo ARP funcione para camadas com endereços de diferentes tamanhos (desde que seja em bytes). b. Explicar o motivo pelo qual o ARP acontece somente na primeira vez que é feito o ping para uma determinada máquina. Dica: utilizar "arp /?" e "arp -a". Quanto tempo dura essa informação?. O sistema mantém uma cache da tabela de endereços ARP, para evitar requisições repetidas. As entradas dessa tabela em geral duram cerca de cinco minutos. 8. SOBRE O TRACEROUTE a. Utilizar o traceroute (ou tracert) para descobrir o número de hops e os roteadores por onde os pacotes estão trafegando até: i. ii.

10 b. Para que serve o traceroute? Qual sua relação com o TTL? Para que serve o TTL? O traceroute serve para diagnosticar certos problemas de roteamento, permitindo verificar por que roteadores um pacote passa para chegar da origem ao destino. Ele funciona enviando um pacote com TTL igual a 1 (forçando uma resposta do roteador a 1 hop de distância), seguido por um pacote com TTL igual a 2 (forçando uma resposta do roteador a 2 hops de distância), e assim sucessivamente, até chegar ao destino. O TTL serve para limitar o número de hops pelos quais um pacote pode passar antes de ser descartado, e serve para evitar a ocorrência de loops infinitos na rede. Por exemplo, se por um erro de configuração um roteador R1 passa um pacote para R2 e R2 passa o pacote para R1, o TTL impede que o pacote seja repassado indefinidamente. 9. Obtenha um histograma do valor médio do tamanho dos pacotes que trafegaram pela rede durante o período considerado. Ver opção statistics+packet lengths. Faça a análise duas vezes: a) iniciando a captura e navegando na web (perfil navegação web); b) iniciando a captura e fazendo um download de arquivo de tamanho razoavelmente grande (acima de 10 Mbytes). Compare os resultados em relação ao tamanho do pacote. Explique. Tamanho de pacotes durante navegação na Web: Apenas um terço dos pacotes utilizam o tamanho máximo disponível. Acesso a páginas, não requer transmissão de dados longos, mas sim muitas requisições devido às referências entre sites, o que dilui bastante o tamanho dos pacotes. Tamanho de pacotes durante download de arquivo:

11 Já durante um download, os dados tendem a ocupar todo o tamanho disponível pelos protocolos e são poucos pacotes auxiliares (ACKs do TCP) que trafegam durante a transferência dos dados, não são feitas multiplas conexões a diferentes máquinas como é feito durante a navegação web. 10. Faça uma análise completa de um quadro MAC que contenha encapsulado um pacote IP e TCP (sugestão: faça um download qualquer). Liste todos os valores dos diversos campos encontrados no cabeçalho do quadro MAC e nos cabeçalhos do pacote IP e do segmento TCP encapsulado. Explique os valores encontrados e suas unidades quando for o caso.

12 Ethernet: Destino: A quem se destina o pacote, nesse caso meu notebook Fonte: Quem enviou, meu roteador (Endereço MAC) Tipo: IP IP: Versão: IPv4 Tamanho do cabeçalho IP: 20 bytes Serviços extras: 0 (Nenhum) Tamanho total: Cabeçalho mais dados: 40 bytes. Identificação: Código para que diversos fragmentos possam se referir ao mesmo pacote IP. Flags: Se o pacote foi fragmentado. Nesse caso não. Fragment offset: 0 (não tem fragmentação neste pacote), mensurado em blocos de 8 bytes. TTL: 47. Quando chegar a zero o pacote deverá ser descartado. Cada roteador subtrai 1 deste valor. Protocolo: TCP (protocolo da camada superior) Checksum: 16bits de checksum para verificar se o pacote não foi corrompido. Endereço IPv4 da fonte: Nesse caso a fonte veio externa à minha rede, o meu roteador só retransmitiu. (é o IP do site do Google) Endereço IPv4 do destino: IP do meu notebook (destino final) TCP: Porta de origem: 80 (é padrão HTTP) Porta de destino: (porta qualquer aberta no meu computador cliente) Número de seqüência: 2 - Número de sequência acumulada do pacote nessa sessão. Número do ACK: como esse é um pacote ACK, esse é o nº correspondente ao ACK n. Tamanho do cabeçalho: 20 bytes do TCP. Flags: indica comportamentos do pacote. Como o valor é 0x10, esse é um pacote ACK. Tamanho da janela: 126 nesse caso (Conceito de janela deslizante). Checksum: 16 bits. 11. Utilizar o software Iperf (iperf h para help), que deve ser disparado em duas máquinas, uma sendo servidor iperf s e outra cliente. Tem que disparar o servidor de forma diferente para teste em UDP ou TCP. iperf s u para UDP ou iperf s para TCP. EXEMPLO DE CLIENTE COM UDP: iperf f m i 1 c ipservidor t 30 p 2000 u b 10M l 1400 (formato em Mbit/s, informa banda enviada a cada segundo, tempo de 30s, porta 2000, banda máxima de 10Mbit/s, tamanho de pacote 1400 bytes). No relatório devem constar o resultado dos três seguintes objetivos: a. Mostrar linhas de comando utilizadas e gerar gráfico udp para 3 bandas diferentes (ex: 1Mbit/s, 10Mbit/s e 30Mbit/s). Mostrar e explicar o gráfico gerado. O gráfico abaixo mostra o tráfego de três conexões UDP independentes (não-paralelas), usando os seguintes comandos no cliente:

13 iperf -u -c f m -i 1 -t 150 -p l b 1M iperf -u -c f m -i 1 -t 150 -p l b 10M iperf -u -c f m -i 1 -t 150 -p l b 30M Column A Column B Column C Observa-se que a taxa de tráfego UDP é equivalente à taxa especificada. Não há slow start ou qualquer outro controle de fluxo. b. Mostrar linhas de comando utilizadas e gerar gráfico TCP da estação incrementando o número de conexões para uma máquina servidora. Pode-se fazer de duas formas: a) aumentando o número de clientes gradativamente, com 1, 2 e 3 clientes, utilizando máquinas diferentes para clientes; b) utilizando o resultado do próprio iperf (opção -i 1 ), que mostra a média a cada segundo, e depois gerando o gráfico com outra ferramenta. Nesse caso, bastam duas máquinas com 3 janelas cliente e 3 servidoras. O objetivo é ver a adaptação do TCP (tcp-friendly). O tráfego TCP foi gerado com os seguintes comandos: iperf -c f m -i 1 -t 150 -p l 1400 & (sleep 30; iperf -c f m -i 1 -t 60 -p l 1400) & (sleep 60; iperf -c f m -i 1 -t 60 -p 2002 ) & Isto é, foram criadas três transmissões: uma iniciando a 0s e com duração de 150s, uma iniciando a 30s e com duração de 60s (termina aos 90s), e uma iniciando a 60s e com duração de 60s (termina aos 120s).

14 Taxa (Mbps) Tempo (s) Observa-se que quando uma nova conexão se inicia, as taxas de transferência se alteram gradativamente de modo a dividir o tráfego mantendo a confiabilidade da conexão. Isso é feito usando a técnica de balanceamento de carga do TCP, em que a janela é progressivamente aumentada até que haja perda de pacotes, quando ela é reduzida, para então tornar a ser gradativamente aumentada. 12. Utilizando a ferramenta Wireshark, obtenha a curva de variação da carga da rede local da sua máquina. Explique, sucintamente, como foi obtida e comente os resultados obtidos. Para esta tarefa considere uma estatística de 1 a 5 minutos. Ver opção statistics+io-graph. Altere o uso da rede (através do iperf ou outro método) e explique as variações na rede. Gere gráficos de TCP e UDP e compare os resultados. Um tráfego similar ao da questão 11b foi gerado. O gráfico I/O para o período considerado é: A linha preta indica o tráfego total na rede, enquanto as linhas de outras cores indicam o tráfego dos pacotes de cada conexão. Novamente observa-se a ação do controle de fluxo do

15 TCP à medida em que novas conexões são criadas e encerradas. Um tráfego UDP similar foi gerado (adicionando -u aos comandos acima, bem como nos servidores iperf), produzindo o seguinte gráfico de I/O: O que se observa é que a taxa de transferência de pacotes UDP na rede quase que instantaneamente se equilibra à medida em que novas conexões são criadas e removidas. Isso ocorre porque o UDP não faz controle algum de balanceamento de carga ou de perda de pacotes. Muitos dos pacotes gerados durante esse tráfego possuem erros de checksum.