Mudanças entre as edições de "RED29004-2016-2"
(103 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
Linha 4: | Linha 4: | ||
''Professor'': [[Odilson Tadeu Valle]] | ''Professor'': [[Odilson Tadeu Valle]] | ||
<br>''Email'': odilson@ifsc.edu.br | <br>''Email'': odilson@ifsc.edu.br | ||
− | <br>''Atendimento paralelo'': | + | <br>''Atendimento paralelo'': 3ª das 15h40 às 16h35 e 4ª das 8h25 às 9h20. Local: Lab. de Desenvolvimento. |
Linha 10: | Linha 10: | ||
** 3 avaliações (A1, A2 e A3) mais um seminário (S). | ** 3 avaliações (A1, A2 e A3) mais um seminário (S). | ||
** Conceito mínimo para não necessitar reavaliação: 6. | ** Conceito mínimo para não necessitar reavaliação: 6. | ||
+ | ** Conceito final obtido pela "média" das avaliações. | ||
** Reavaliação única a ser realizada no último dia de aula. | ** Reavaliação única a ser realizada no último dia de aula. | ||
+ | |||
+ | *[http://docente.ifsc.edu.br/odilson/RED29004/DIARIO-2016-2-C290-RED29004.pdf <span style="font-size:200%"> Conceitos finais] | ||
'''IMPORTANTE:''' o direito de recuperar uma avaliação em que se faltou somente existe mediante justificativa reconhecida pela coordenação. Assim, deve-se protocolar a justificativa no prazo de 48 horas, contando da data e horário da avaliação e aguardar o parecer da coordenação. | '''IMPORTANTE:''' o direito de recuperar uma avaliação em que se faltou somente existe mediante justificativa reconhecida pela coordenação. Assim, deve-se protocolar a justificativa no prazo de 48 horas, contando da data e horário da avaliação e aguardar o parecer da coordenação. | ||
Linha 43: | Linha 46: | ||
#Qual é a vantagem de uma rede de comutação de circuitos em relação a uma de comutação de pacotes? Quais são as vantagens da TDM sobre a FDM em uma rede de comutação de circuitos? | #Qual é a vantagem de uma rede de comutação de circuitos em relação a uma de comutação de pacotes? Quais são as vantagens da TDM sobre a FDM em uma rede de comutação de circuitos? | ||
#Considere o envio de um pacote de uma máquina de origem a uma de destino por uma rota fixa. Relacione os componentes do atraso que formam o atraso fim-a-fim. Quais deles são constantes e quais são variáveis? | #Considere o envio de um pacote de uma máquina de origem a uma de destino por uma rota fixa. Relacione os componentes do atraso que formam o atraso fim-a-fim. Quais deles são constantes e quais são variáveis? | ||
− | #Suponha que o hospedeiro A queira enviar um arquivo grande para o hospedeiro B. O percurso de A para B possui três enlaces, de taxas <math>R_1 = 500 | + | #Suponha que o hospedeiro A queira enviar um arquivo grande para o hospedeiro B. O percurso de A para B possui três enlaces, de taxas <math>R_1 = 500 kbps, R_2 = 2 Mbps e R_3 = 1 Mbps</math>. |
##Considerando que não haja nenhum outro tráfego na rede, qual é a vazão para a transferência de arquivo? | ##Considerando que não haja nenhum outro tráfego na rede, qual é a vazão para a transferência de arquivo? | ||
##Suponha que o arquivo tenha 4 milhões de bytes. Quanto tempo levará a transferência do arquivo para o hospedeiro B? | ##Suponha que o arquivo tenha 4 milhões de bytes. Quanto tempo levará a transferência do arquivo para o hospedeiro B? | ||
Linha 54: | Linha 57: | ||
##O que seria mais apropriado para essa aplicação: uma rede de comutação de circuitos ou uma rede de comutação de pacotes? Por quê? | ##O que seria mais apropriado para essa aplicação: uma rede de comutação de circuitos ou uma rede de comutação de pacotes? Por quê? | ||
##Suponha que seja usada uma rede de comutação de pacotes e que o único tráfego venha de aplicações como a descrita anteriormente. Além disso, imagine que a soma das velocidades de dados da aplicação seja menor do que a capacidade de cada enlace. Será necessário algum tipo de controle de congestionamento? Por quê? | ##Suponha que seja usada uma rede de comutação de pacotes e que o único tráfego venha de aplicações como a descrita anteriormente. Além disso, imagine que a soma das velocidades de dados da aplicação seja menor do que a capacidade de cada enlace. Será necessário algum tipo de controle de congestionamento? Por quê? | ||
− | #Imagine que você queira enviar, com urgência, 40 terabytes de dados de São José a Manaus. Você tem disponível um enlace dedicado de 100 | + | #Imagine que você queira enviar, com urgência, 40 terabytes de dados de São José a Manaus. Você tem disponível um enlace dedicado de 100 Mbps para a transferência de dados. Você escolheria transferir os dados pelo enlace ou mandar mídias por Sedex 10? Explique. |
− | #Suponha que dois hospedeiros, A e B, estejam separados por uma distância de 20000 km e conectados por um enlace direto de R = 2 | + | #Suponha que dois hospedeiros, A e B, estejam separados por uma distância de 20000 km e conectados por um enlace direto de R = 2 Mbps. Suponha que a velocidade de propagação pelo enlace seja de <math>2,5.10^8 m/s</math>. |
##Considere o envio de um arquivo de 800 mil bits do hospedeiro A para o hospedeiro B. Suponha que o arquivo seja enviado continuamente, como se fosse uma única grande mensagem. Qual o número máximo de bits que estará no enlace a qualquer dado instante? | ##Considere o envio de um arquivo de 800 mil bits do hospedeiro A para o hospedeiro B. Suponha que o arquivo seja enviado continuamente, como se fosse uma única grande mensagem. Qual o número máximo de bits que estará no enlace a qualquer dado instante? | ||
##Qual é o comprimento (em metros) de um bit no enlace? É maior do que o de um campo de futebol? | ##Qual é o comprimento (em metros) de um bit no enlace? É maior do que o de um campo de futebol? | ||
− | ##Considere o envio de um arquivo de 800 mil bits do hospedeiro A para o hospedeiro B. Suponha que o arquivo seja enviado continuamente, como se fosse uma única grande mensagem. Qual o número máximo de bits que estará no enlace a qualquer dado instante, mas agora com o enlace de R = 1 | + | ##Considere o envio de um arquivo de 800 mil bits do hospedeiro A para o hospedeiro B. Suponha que o arquivo seja enviado continuamente, como se fosse uma única grande mensagem. Qual o número máximo de bits que estará no enlace a qualquer dado instante, mas agora com o enlace de R = 1 Gbps? |
− | ##Qual é o comprimento (em metros) de um bit no enlace, mas agora com o enlace de R = 1 | + | ##Qual é o comprimento (em metros) de um bit no enlace, mas agora com o enlace de R = 1 Gbps? |
## Quanto tempo demora para mandar o arquivo, admitindo que ele seja enviado continuamente? | ## Quanto tempo demora para mandar o arquivo, admitindo que ele seja enviado continuamente? | ||
##Suponha agora que o arquivos seja fragmentado em 20 pacotes e que cada um contenha 40 mil bits. Imagine que cada pacote seja verificado pelo receptor e que o tempo de verificação de um pacote seja desprezível. Por fim, admita que o emissor não possa enviar um novo pacote até que o anterior tenha sido reconhecido por um ACK (''acknowledged'') de 500 bits. Quanto tempo demorará para ser enviado o arquivo? | ##Suponha agora que o arquivos seja fragmentado em 20 pacotes e que cada um contenha 40 mil bits. Imagine que cada pacote seja verificado pelo receptor e que o tempo de verificação de um pacote seja desprezível. Por fim, admita que o emissor não possa enviar um novo pacote até que o anterior tenha sido reconhecido por um ACK (''acknowledged'') de 500 bits. Quanto tempo demorará para ser enviado o arquivo? | ||
Linha 106: | Linha 109: | ||
#O TCP oferece garantias de banda e de tempo real? | #O TCP oferece garantias de banda e de tempo real? | ||
#Cite um motivo para um protocolo de transmissão confiável adicionar um número de seqüência em cada pacote transmitido. Justifique o uso dessa informação explicando o problema que ocorreria caso ela não fosse usada. | #Cite um motivo para um protocolo de transmissão confiável adicionar um número de seqüência em cada pacote transmitido. Justifique o uso dessa informação explicando o problema que ocorreria caso ela não fosse usada. | ||
− | #Para que serve um | + | #Para que serve um ''timeout'' em um protocolo de transmissão confiável? |
− | #Cite um problema que pode ocorrer caso o | + | #Cite um problema que pode ocorrer caso o valor do ''timeout'' seja muito pequeno. |
− | #Cite um problema que pode ocorrer caso o | + | #Cite um problema que pode ocorrer caso o valor do ''timeout'' seja muito grande. |
− | #Por quê os tempos dos | + | #Por quê os tempos dos ''timeouts'' não são estabelecidos de forma estática, e sim de forma dinâmica, calculados conforme os ''round-trip times'' medidos? |
#O que é uma reconhecimento cumulativo? | #O que é uma reconhecimento cumulativo? | ||
#Explique o que faz um receptor caso receba um pacote fora de ordem em um protocolo do tipo: | #Explique o que faz um receptor caso receba um pacote fora de ordem em um protocolo do tipo: | ||
Linha 246: | Linha 249: | ||
[http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Slides do Kurose referentes ao capítulo 4] | [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Slides do Kurose referentes ao capítulo 4] | ||
− | [http://docente.ifsc.edu.br/odilson/RED29004/IPv6 | + | [http://docente.ifsc.edu.br/odilson/RED29004/IPv6.pdf Slides do IPv6] |
[http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%205%20Camada%20de%20enlace.pdf Slides do Kurose referentes ao capítulo 5] | [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%205%20Camada%20de%20enlace.pdf Slides do Kurose referentes ao capítulo 5] | ||
Linha 268: | Linha 271: | ||
Eventualmente serão utilizadas nessa disciplina. | Eventualmente serão utilizadas nessa disciplina. | ||
− | Os Laboratórios de Redes de Computadores estão equipados com N+1 (N = número de computadores para alunos) computadores conectados em rede e com acesso a Internet, Figura 1. A rede local do laboratório tem endereço IP 192.168. | + | Os Laboratórios de Redes de Computadores estão equipados com N+1 (N = número de computadores para alunos) computadores conectados em rede e com acesso a Internet, Figura 1. A rede local do laboratório tem endereço IP 192.168.1.0/24. A máscara de rede '''/24''' indica que o último ''byte'' do endereço é utilizado para identificar cada máquina, por exemplo 192.168.1.1, 192.168.1.2, etc. |
O sistema operacional hospedeiro é o '''Linux Ubuntu'''. Como os laboratórios são utilizados por várias disciplinas/alunos/professores, os usuários não tem acesso a senha de ''root'' (administrador). | O sistema operacional hospedeiro é o '''Linux Ubuntu'''. Como os laboratórios são utilizados por várias disciplinas/alunos/professores, os usuários não tem acesso a senha de ''root'' (administrador). | ||
− | Para possibilitar a execução de comandos exclusivos do administrador (usuário root), cada computador tem instaladas máquinas virtuais, as quais podem ser lançadas a partir do aplicativo '''VirtualBox'''. As máquinas virtuais pertencem a mesma rede local do laboratório e tem endereçamento 192.168. | + | Para possibilitar a execução de comandos exclusivos do administrador (usuário root), cada computador tem instaladas máquinas virtuais, as quais podem ser lançadas a partir do aplicativo '''VirtualBox'''. As máquinas virtuais pertencem a mesma rede local do laboratório e tem endereçamento 192.168.1.x, sendo o ''byte'' que identifica a máquina (x) deverá ser manualmente configurado com a seguinte regra: M1 – 101, M2 – 102,..., M9 – 109, M10 – 110,..., M14 – 114 . Por exemplo:, M1 ficará com o endereço 192.168.1.101. |
===Roteiro de atividades=== | ===Roteiro de atividades=== | ||
Linha 315: | Linha 318: | ||
====ping==== | ====ping==== | ||
Aplicativo '''ping''' permite a um usuário verificar se um ''host'' remoto está ativo. É bastante utilizado para detectar problemas de comunicação na rede. | Aplicativo '''ping''' permite a um usuário verificar se um ''host'' remoto está ativo. É bastante utilizado para detectar problemas de comunicação na rede. | ||
− | O '''ping''' está baseado no envio de mensagens de solicitação de eco (''echo request'') e de resposta de eco (''echo reply''). Estas mensagens fazem parte do rol de mensagens do protocolo ICMP, que é um protocolo de reportagem de erros, componente do protocolo IP. | + | O '''ping''' está baseado no envio de mensagens de solicitação de eco (''echo request'') e de resposta de eco (''echo reply''). Estas mensagens fazem parte do rol de mensagens do protocolo ICMP, que é um protocolo de reportagem de erros, a ser estudado mais tarde, componente do protocolo IP. |
O '''ping''' é um dos principais comandos a disposição do administrador de rede no sentido de verificar a conectividade em rede. Por exemplo, se houver resposta de um ping a partir de um servidor remoto, significa que a máquina local está rodando corretamente o TCP/IP, o enlace local está funcionando corretamente, o roteamento entre a origem e o destino está operando, e por fim, a máquina remota também está rodando corretamente o TCP/IP. | O '''ping''' é um dos principais comandos a disposição do administrador de rede no sentido de verificar a conectividade em rede. Por exemplo, se houver resposta de um ping a partir de um servidor remoto, significa que a máquina local está rodando corretamente o TCP/IP, o enlace local está funcionando corretamente, o roteamento entre a origem e o destino está operando, e por fim, a máquina remota também está rodando corretamente o TCP/IP. | ||
Linha 428: | Linha 431: | ||
===Objetivos=== | ===Objetivos=== | ||
− | Baseado na pequena introdução ao Wireshark apresentada no '''Laboratório 1''', agora estamos prontos para utilizar o Wireshark para investigar protocolos em operação. | + | *Baseado na pequena introdução ao Wireshark apresentada no '''Laboratório 1''', agora estamos prontos para utilizar o Wireshark para investigar protocolos em operação. |
+ | *Explorar vários aspectos do protocolo HTTP: | ||
+ | *#a interação básica GET/resposta do HTTP, | ||
+ | *#formatos de mensagens HTTP, | ||
+ | *#baixando arquivos grandes em HTML, | ||
+ | *#baixando arquivos em HTML com objetos incluídos, e | ||
+ | *#segurança HTTP. | ||
===A Interação Básica GET/Resposta do HTTP=== | ===A Interação Básica GET/Resposta do HTTP=== | ||
Linha 435: | Linha 444: | ||
#inicie o navegador; | #inicie o navegador; | ||
#limpe o cache do mesmo (teclas de atalho para o Firefox: '''Ctrl + Shift + Del'''); | #limpe o cache do mesmo (teclas de atalho para o Firefox: '''Ctrl + Shift + Del'''); | ||
− | #inicie o Wireshark, como descrito no '''Laboratório 1''' (mas não inicie a captura de pacotes ainda) | + | #inicie o Wireshark, como descrito no '''Laboratório 1''' (mas não inicie a captura de pacotes ainda); |
− | # | + | #inicie a captura de pacotes; |
− | + | #digite o seguinte URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004.html; | |
− | + | #pare a captura de pacotes; | |
− | + | #digite “http” (somente as letras, sem as aspas) na caixa de texto de especificação do filtro de exibição, de tal forma que apenas as mensagens HTTP capturadas serão exibidas na janela de listagem de pacotes. (Só estamos interessados em HTTP desta vez, e não desejamos ver todos os pacotes capturados). | |
[[Arquivo:HTTP_Wireshark.png |thumb | 300px| Fig.1 Requisição e Resposta HTTP]] | [[Arquivo:HTTP_Wireshark.png |thumb | 300px| Fig.1 Requisição e Resposta HTTP]] | ||
Linha 453: | Linha 462: | ||
#Quais linguagens (se alguma) o seu navegador indica que pode aceitar ao servidor? | #Quais linguagens (se alguma) o seu navegador indica que pode aceitar ao servidor? | ||
#Qual o endereço IP do seu computador? | #Qual o endereço IP do seu computador? | ||
− | #E do servidor | + | #E do servidor tele.sj.ifsc.edu.br? |
#Qual o número da porta utilizada no seu computador? | #Qual o número da porta utilizada no seu computador? | ||
− | #E do servidor | + | #E do servidor tele.sj.ifsc.edu.br? |
#Qual o endereço MAC do seu computador? | #Qual o endereço MAC do seu computador? | ||
− | #Qual o endereço MAC do servidor de destino (Dst)? Nesse caso o servidor de destino e o servidor | + | #Qual o endereço MAC do servidor de destino (Dst)? Nesse caso o servidor de destino e o servidor tele.sj.ifsc.edu.br são o mesmo host? |
#Qual o código de status retornado do servidor para o seu navegador? | #Qual o código de status retornado do servidor para o seu navegador? | ||
#Quando o arquivo em HTML que você baixou foi modificado no servidor pela última vez? | #Quando o arquivo em HTML que você baixou foi modificado no servidor pela última vez? | ||
Linha 469: | Linha 478: | ||
#limpe o cache do seu navegador('''Ctrl + Shift + Del'''); | #limpe o cache do seu navegador('''Ctrl + Shift + Del'''); | ||
#inicie o Wireshark; | #inicie o Wireshark; | ||
− | #digite o URL no navegador http:// | + | #digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004.html seu navegador deve exibir um arquivo em HTML muito simples com duas linhas; |
#pressione o botão “refresh” no navegador (ou digite o URL novamente); | #pressione o botão “refresh” no navegador (ou digite o URL novamente); | ||
#pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP sejam apresentadas na janela de listagem de pacotes. | #pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP sejam apresentadas na janela de listagem de pacotes. | ||
Responda às seguintes questões: | Responda às seguintes questões: | ||
− | #Inspecione o conteúdo da primeira mensagem HTTP GET do seu navegador para o servidor | + | #Inspecione o conteúdo da primeira mensagem HTTP GET do seu navegador para o servidor tele.sj.ifsc.edu.br. Você vê uma linha “If-Modified-Since”? |
#Inspecione o conteúdo da resposta do servidor. O servidor retornou explicitamente o conteúdo do arquivo? Como você pode dizer isso? | #Inspecione o conteúdo da resposta do servidor. O servidor retornou explicitamente o conteúdo do arquivo? Como você pode dizer isso? | ||
#Agora inspecione o conteúdo da segunda mensagem HTTP GET do seu navegador para o servidor. Você vê uma linha “If-Modified-Since”? Caso a resposta seja afirmativa, qual informação segue o cabeçalho “If-Modified-Since”? | #Agora inspecione o conteúdo da segunda mensagem HTTP GET do seu navegador para o servidor. Você vê uma linha “If-Modified-Since”? Caso a resposta seja afirmativa, qual informação segue o cabeçalho “If-Modified-Since”? | ||
Linha 487: | Linha 496: | ||
#limpe o cache do seu navegador; | #limpe o cache do seu navegador; | ||
#inicie o Wireshark; | #inicie o Wireshark; | ||
− | #digite o URL no navegador http:// | + | #digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004_arq2.html seu navegador deve exibir um documento bastante longo e criativo :) ; |
#Faça um atualização da página (F5); | #Faça um atualização da página (F5); | ||
#pare a captura de pacotes, e digite "http" na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas. | #pare a captura de pacotes, e digite "http" na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas. | ||
− | Na janela de listagem de pacotes, você deve ver a sua mensagem HTTP GET, seguida por uma reposta em vários pacotes. Esta resposta em vários pacotes merece uma explicação. Lembre-se da seção 2.2 do livro (veja a figura 2.9) que a mensagem de resposta HTTP consiste de uma linha de status, seguida por zero ou mais linhas de cabeçalhos, seguida por uma linha em branco, seguida pela carga útil (Content-Length). No caso do nossa HTTP GET, a carga útil na resposta é o arquivo HTTP completo. No nosso caso aqui, o arquivo em HTML é bastante longo, e a informação de 11747 bytes é muito grande para caber em um segmento TCP. A resposta HTTP simples é então quebrada em vários pedaços pelo TCP, com cada pedaço sendo contido dentro de um segmento TCP separado. Cada segmento TCP é capturado em um pacote separado pelo Wireshark, clique sobre o | + | Na janela de listagem de pacotes, você deve ver a sua mensagem HTTP GET, seguida por uma reposta em vários pacotes. Esta resposta em vários pacotes merece uma explicação. Lembre-se da seção 2.2 do livro (veja a figura 2.9) que a mensagem de resposta HTTP consiste de uma linha de status, seguida por zero ou mais linhas de cabeçalhos, seguida por uma linha em branco, seguida pela carga útil (Content-Length). No caso do nossa HTTP GET, a carga útil na resposta é o arquivo HTTP completo. No nosso caso aqui, o arquivo em HTML é bastante longo, e a informação de '''11747 bytes''' é muito grande para caber em um segmento TCP. A resposta HTTP simples é então quebrada em vários pedaços pelo TCP, com cada pedaço sendo contido dentro de um segmento TCP separado. Cada segmento TCP é capturado em um pacote separado pelo Wireshark, clique sobre o nono "Reassembled TCP Segments" no Wireshark. |
Responda às seguintes questões: | Responda às seguintes questões: | ||
Linha 506: | Linha 515: | ||
#limpe o cache do seu navegador; | #limpe o cache do seu navegador; | ||
#inicie o Wireshark; | #inicie o Wireshark; | ||
− | #digite o URL no navegador http:// | + | #digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq3.html seu navegador deve exibir um arquivo pequeno em HTML com duas imagens incluídas. Estas duas imagens estão referenciadas no arquivo em HTML. Isto é, as imagens não estão no arquivo em HTML, ao invés disso, há um URL para cada imagem no arquivo em HTML. Como discutido no livro, seu navegador terá que baixar estas imagens dos locais correspondentes. A imagem da esquerda, '''redesWL_network.jpeg''', está em ibxk.com.br. A imagem da direita, '''as-redes-sociais-como-instrumento-de-manipulacao-da-consciencia-coletiva.html.jpg''', está em lounge.obviousmag.org; |
#pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas. | #pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas. | ||
Linha 519: | Linha 528: | ||
#limpe o cache do seu navegador; | #limpe o cache do seu navegador; | ||
#inicie o Wireshark; | #inicie o Wireshark; | ||
− | #digite o URL no navegador https://www. | + | #digite o URL no navegador https://www.ssllabs.com/ssltest/ seu navegador apresentará um site já apresentado/utilizado; |
#pare a captura de pacotes e digite "ssl" na caixa de texto de especificação de filtro, para que apenas as mensagens criptografadas sejam exibidas. | #pare a captura de pacotes e digite "ssl" na caixa de texto de especificação de filtro, para que apenas as mensagens criptografadas sejam exibidas. | ||
Linha 540: | Linha 549: | ||
===Consultas DNS por meio de ferramentas especializadas=== | ===Consultas DNS por meio de ferramentas especializadas=== | ||
− | # Usando o programa [http://manpages.ubuntu.com/manpages/hardy/man1/host.1.html host], [http://pt.wikipedia.org/wiki/Nslookup Nslookup] ou [http://manpages.ubuntu.com/manpages/hardy/man1/dig.1.html dig], descubra os endereços IP associados aos seguintes nomes de hosts (máquinas): | + | # Usando o programa [http://manpages.ubuntu.com/manpages/hardy/man1/host.1.html host], [http://pt.wikipedia.org/wiki/Nslookup Nslookup] ou [http://manpages.ubuntu.com/manpages/hardy/man1/dig.1.html dig], que são executados no terminal, descubra os endereços IP associados aos seguintes nomes de hosts (máquinas): |
#* mail.ifsc.edu.br | #* mail.ifsc.edu.br | ||
#* www.google.com | #* www.google.com | ||
Linha 561: | Linha 570: | ||
#* ifsc.edu.br | #* ifsc.edu.br | ||
# Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim: <syntaxhighlight lang=bash> | # Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim: <syntaxhighlight lang=bash> | ||
− | dig -x 200. | + | dig -x 200.135.37.65 |
</syntaxhighlight> ... o ''dig'' tem um resultado um pouco mais carregado que os outros utilitários (''host'' e ''nslookup''), porém neste caso é mais prático. Veja o resultado da consulta logo após a linha '';; ANSWER SECTION:''. Experimente fazer a resolução reversa para cada um dos IP obtidos nas consultas realizadas no primeiro exercício desta atividade. Pode-se também usar a variante do ''dig'' para respostas curtas: <code> | </syntaxhighlight> ... o ''dig'' tem um resultado um pouco mais carregado que os outros utilitários (''host'' e ''nslookup''), porém neste caso é mais prático. Veja o resultado da consulta logo após a linha '';; ANSWER SECTION:''. Experimente fazer a resolução reversa para cada um dos IP obtidos nas consultas realizadas no primeiro exercício desta atividade. Pode-se também usar a variante do ''dig'' para respostas curtas: <code> | ||
− | dig -x 200. | + | dig -x 200.135.37.65 +short |
</syntaxhighlight> | </syntaxhighlight> | ||
# Como explicado durante a aula, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado? | # Como explicado durante a aula, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado? | ||
Linha 582: | Linha 591: | ||
#Faça uma consulta recursiva com dig e responda:<syntaxhighlight lang=bash> | #Faça uma consulta recursiva com dig e responda:<syntaxhighlight lang=bash> | ||
dig +trace mail.ru. </syntaxhighlight> | dig +trace mail.ru. </syntaxhighlight> | ||
− | ##Qual foi o RLD consultado? | + | ##Qual foi o RLD (''Root Level Domain'') consultado? |
− | ##Qual o TLD consultado? | + | ##Qual o TLD (''Top Level Domain'') consultado? |
− | ##Qual o SLD consultado? | + | ##Qual o SLD (''Second Level Domain'') consultado? |
##Como você sabe que foram esses os LDs consultados? | ##Como você sabe que foram esses os LDs consultados? | ||
− | |||
===Algumas consultas AAAA=== | ===Algumas consultas AAAA=== | ||
Linha 609: | Linha 617: | ||
Agora que já está ficando claro como funcionam as consultas DNS, deve-se investigar como se dá a comunicação entre seu computador e seu servidor DNS. | Agora que já está ficando claro como funcionam as consultas DNS, deve-se investigar como se dá a comunicação entre seu computador e seu servidor DNS. | ||
#abra o navegador web e limpe o cache do mesmo; | #abra o navegador web e limpe o cache do mesmo; | ||
− | #abra o Wireshark e | + | #abra o Wireshark e escolha a interface e inicie a captura de pacotes; |
#inicie a captura de pacotes no Wireshark; | #inicie a captura de pacotes no Wireshark; | ||
− | #no | + | #no terminal digite '''dig +trace canon.jp''' (isso vai provocar a consulta DNS); |
− | #pare a captura de pacotes | + | #pare a captura de pacotes; |
+ | #No Wireshark digite “dns” no filtro (sem as aspas); | ||
Com base nisso identifique o seguinte: | Com base nisso identifique o seguinte: | ||
#quantas mensagens são trocadas entre cliente e servidor DNS para cada consulta? | #quantas mensagens são trocadas entre cliente e servidor DNS para cada consulta? | ||
Linha 626: | Linha 635: | ||
#examine a mensagem de resposta DNS. Quantos campos com “answer” existem? | #examine a mensagem de resposta DNS. Quantos campos com “answer” existem? | ||
#quais são os benefícios de usar o UDP ao invés do TCP como protocolo de transporte para o DNS? | #quais são os benefícios de usar o UDP ao invés do TCP como protocolo de transporte para o DNS? | ||
+ | |||
+ | ===Exemplos de arquivos DNS=== | ||
+ | /etc/bind/db.redes <code> | ||
+ | $TTL 86400 | ||
+ | @ IN SOA ns.redes.edu.br. root ( | ||
+ | 2016090900 ; Serial | ||
+ | 604800 ; Refresh | ||
+ | 86400 ; Retry | ||
+ | 2419200 ; Expire | ||
+ | 86400 ) ; Negative Cache TTL | ||
+ | ; | ||
+ | @ IN NS ns.redes.edu.br. | ||
+ | @ IN MX 10 mail.redes.edu.br. | ||
+ | $ORIGIN redes.edu.br. | ||
+ | ns A 192.168.1.101 | ||
+ | www A 192.168.1.102 | ||
+ | ftp A 192.168.1.103 | ||
+ | mail A 192.168.1.104 </syntaxhighlight> | ||
+ | |||
+ | /etc/bind/db.2.168.192 (Zona reversa) <code> | ||
+ | $TTL 86400 | ||
+ | @ IN SOA ns.redes.edu.br. root ( | ||
+ | 2016090900 ; Serial | ||
+ | 604800 ; Refresh | ||
+ | 86400 ; Retry | ||
+ | 2419200 ; Expire | ||
+ | 86400 ) ; Negative Cache TTL | ||
+ | ; | ||
+ | IN NS ns.redes.edu.br. | ||
+ | 101 IN PTR ns.redes.edu.br. | ||
+ | 102 IN PTR www.redes.edu.br. | ||
+ | 103 IN PTR ftp.redes.edu.br. | ||
+ | 104 IN PTR mail.redes.edu.br. </syntaxhighlight> | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | |||
{{Collapse top |Laboratório 4 - Entendendo ''sockets''}} | {{Collapse top |Laboratório 4 - Entendendo ''sockets''}} | ||
Linha 674: | Linha 715: | ||
#No terminal da máquina execute o programa: <code> | #No terminal da máquina execute o programa: <code> | ||
python UDPServer.py </syntaxhighlight> Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza eh sintaxe. Deixe o programa rodando nesse terminal. | python UDPServer.py </syntaxhighlight> Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza eh sintaxe. Deixe o programa rodando nesse terminal. | ||
− | #Abra um '''novo terminal''' e escreva o programa cliente. UDPClient.py <code> | + | #Abra um '''novo terminal''' e escreva o programa cliente. UDPClient.py. Lembre-se de ajustar ip_do_servidor para o numero adequado, ou seja, o IP de sua maquina ou de seu vizinho. <code> |
#Esta linha define que pode-se utilizar sockets dentro do programa | #Esta linha define que pode-se utilizar sockets dentro do programa | ||
from socket import * | from socket import * | ||
Linha 705: | Linha 746: | ||
#Execute novamente o cliente e servidor, se necessário, e capture os pacotes com o WireShark. Use um filtro do tipo: '''ip.addr == ip_do_servidor''', assim captura-se somente os pacotes originados/destinados ao servidor. Outra possibilidade de filtro é o filtro por número de porta: '''udp.port == 22222''' | #Execute novamente o cliente e servidor, se necessário, e capture os pacotes com o WireShark. Use um filtro do tipo: '''ip.addr == ip_do_servidor''', assim captura-se somente os pacotes originados/destinados ao servidor. Outra possibilidade de filtro é o filtro por número de porta: '''udp.port == 22222''' | ||
#É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor? | #É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor? | ||
+ | #Se a mensagem digitada for '''teste''', do cliente para o servidor deve aparacer o campo '''Data:7465737465''' e a resposta do servidor deve aparecer '''Data: 5445535445'''. O que significa isso? Dica, olhe na internet o código ASCII. | ||
#Qual é o protocolo nessa troca de mensagens? | #Qual é o protocolo nessa troca de mensagens? | ||
#Qual são os dois números de porta e os dois IPs utilizados? | #Qual são os dois números de porta e os dois IPs utilizados? | ||
Linha 766: | Linha 808: | ||
#Execute novamente o cliente e servidor, se necessário, e capture os pacotes com o WireShark. Use um filtro do tipo: '''ip.addr == ip_do_servidor''', assim captura-se somente os pacotes originados/destinados ao servidor. Ou um filtro por número de porta. | #Execute novamente o cliente e servidor, se necessário, e capture os pacotes com o WireShark. Use um filtro do tipo: '''ip.addr == ip_do_servidor''', assim captura-se somente os pacotes originados/destinados ao servidor. Ou um filtro por número de porta. | ||
#É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor? | #É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor? | ||
+ | #As três primeiras mensagens trocadas apresentam a camada de aplicação, sim ou não? Explique. O que elas significam? | ||
+ | #Em qual (número) mensagem é que a frase é enviada ao servidor? | ||
+ | #A mensagem seguinte (quinta) apresenta camada de aplicação? Clique na camada TCP no Wireshark e observe o campo '''Flags: 0x010 (ACK)'''. O que você acha que isso significa? | ||
+ | #Qual o conteúdo da mensagem seguinte (sexta)? E da sétima? Explique. | ||
+ | #Explique as três últimas mensagens. | ||
#Qual é o protocolo nessa troca de mensagens? | #Qual é o protocolo nessa troca de mensagens? | ||
#Qual são os números de porta e os IPs utilizados? | #Qual são os números de porta e os IPs utilizados? | ||
#Quem definiu o número de porta do cliente? | #Quem definiu o número de porta do cliente? | ||
#Combine com um colega e faça testes entre a sua máquina e dele. Num momento você é o servidor e noutro você é o cliente. | #Combine com um colega e faça testes entre a sua máquina e dele. Num momento você é o servidor e noutro você é o cliente. | ||
− | #Capture todos os pacotes trocados, entre você e seu vizinho, e responda as mesmas questões anteriores. Os números de portas e IPs são ou não iguais? | + | #Capture todos os pacotes trocados, entre você e seu vizinho, e responda as mesmas questões anteriores. Os números de portas e IPs são ou não iguais? |
− | #Discuta | + | Comparativo. |
+ | #Quantas mensagens foram trocadas entre o servidor e cliente em cada um dos protocolos, UDP e TCP, para atingir o mesmo objetivo? | ||
+ | #Discuta outras diferenças observadas entre os protocolos UDP e TCP. | ||
===Desafios para casa=== | ===Desafios para casa=== | ||
Linha 792: | Linha 841: | ||
# Abra um terminal e execute o seguinte comando para fazer o download de um arquivo a ser usado no experimento: <syntaxhighlight lang=bash> | # Abra um terminal e execute o seguinte comando para fazer o download de um arquivo a ser usado no experimento: <syntaxhighlight lang=bash> | ||
− | wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/ | + | wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/jogo.exe |
</syntaxhighlight> | </syntaxhighlight> | ||
− | # Observe o tamanho do arquivo transferido ... ele deve ter exatamente | + | # Observe o tamanho do arquivo transferido ... ele deve ter exatamente 332831416 bytes (cerca de 318 MB). Você pode fazer isso com o comando '''ls -l jogo.exe''', ou executando o gerenciador de arquivos e visualizando as propriedades desse arquivo. |
− | # Escolha um colega para fazer o experimento, em que o arquivo será transferido de um computador para o outro. | + | # Escolha um colega para fazer o experimento, em que o arquivo será transferido de um computador para o outro. Um será o '''receptor''' e outro o '''transmissor'''. |
− | |||
# A primeira transferência será feita usando o protocolo TCP da seguinte forma: | # A primeira transferência será feita usando o protocolo TCP da seguinte forma: | ||
− | #* No computador receptor execute o '''netcat''' (utilize '''man nc''' para saber os detalhes das ''flags'' utilizadas) que abrirá uma conexão TCP na porta, por exemplo, 5555 e salvará os dados transferidos em '''arquivo''': <syntaxhighlight lang=bash> | + | #* No computador '''receptor''' execute o '''netcat''' (utilize '''man nc''' para saber os detalhes das ''flags'' utilizadas) que abrirá uma conexão TCP na porta, por exemplo, 5555 e salvará os dados transferidos em '''arquivo''': <syntaxhighlight lang=bash> |
nc -vvnl 5555 > arquivoTCP | nc -vvnl 5555 > arquivoTCP | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | #* No computador transmissor execute: <syntaxhighlight lang=bash> | + | #* Execute o WireShark e deixe-o capturando pacotes '''somente''' durante a transferência do arquivo. |
− | time nc -vvn ip_do_receptor 5555 < | + | #* No computador '''transmissor''' execute, após o processo do '''receptor''' estar executando: <syntaxhighlight lang=bash> |
+ | time nc -vvn ip_do_receptor 5555 < jogo.exe | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | #* Quando completar a transferência, | + | #* Quando completar a transferência, pare o Wireshark. |
+ | #* Verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo? | ||
#* Analisando a captura de pacotes do WireShark responda: | #* Analisando a captura de pacotes do WireShark responda: | ||
+ | ## Quais as portas origem e destino escolhidas pelo cliente e servidor? | ||
## Qual é o identificar do primeiro e do último pacote? | ## Qual é o identificar do primeiro e do último pacote? | ||
− | ## É possível calcular o tamanho do arquivo pela análise dos pacotes? Qual é a maneira mais fácil? Apresente os cálculos. | + | ## Qual é o identificar do primeiro e do último ACK? |
+ | ## Qual o Tamanho Máximo de Segmento (MSS) escolhidos pelo cliente e servidor na conexão. | ||
+ | ## É possível calcular o tamanho do arquivo pela análise dos pacotes? Qual é a maneira mais fácil? Apresente os cálculos ou descreva a maneira de obtenção do valor. | ||
+ | ## Qual é o tamanho do último segmento de dados recebido? | ||
+ | ## Todos os segmentos trocados entre as máquinas contém dados ou alguns são somente de controle? Qual o percentual aproximado de segmentos de controle? | ||
+ | ## Apresente os segmentos do ''3-way handshake'' e analise os campos do cabeçalho, que os identificam. Estão de acordo com a norma apresentada em sala de aula? | ||
+ | ## Apresente os segmentos do fechamento de conexão e analise os campos do cabeçalho, que os identificam. Estão de acordo com a norma apresentada em sala de aula? | ||
# A segunda transferência será feita usando o protocolo UDP: | # A segunda transferência será feita usando o protocolo UDP: | ||
− | #* No computador receptor baixe o programa '''receptor''', acrescente a ele permissão de execução e o execute, conforme a sequência de comandos abaixo: <syntaxhighlight lang=bash> | + | #* No computador '''receptor''' baixe o programa '''receptor''', acrescente a ele permissão de execução e o execute, conforme a sequência de comandos abaixo: <syntaxhighlight lang=bash> |
wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/receptor | wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/receptor | ||
chmod +x receptor | chmod +x receptor | ||
./receptor 5555 > arquivoUDP | ./receptor 5555 > arquivoUDP | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | #* No computador transmissor baixe o programa '''transmissor''', acrescente a ele permissão de execução e o execute, conforme a sequência de comandos abaixo: <syntaxhighlight lang=bash> | + | #* No computador '''transmissor''' baixe o programa '''transmissor''', acrescente a ele permissão de execução e o execute, conforme a sequência de comandos abaixo: <syntaxhighlight lang=bash> |
wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/transmissor | wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/transmissor | ||
− | chmod +x transmissor | + | chmod +x transmissor </syntaxhighlight> |
− | ./transmissor ip_do_receptor 5555 < | + | #* Execute o WireShark e deixe-o capturando pacotes '''somente''' durante a transferência do arquivo. |
+ | #* Inicie a transferência do arquivo: <code> | ||
+ | ./transmissor ip_do_receptor 5555 < jogo.exe | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | #* Quando completar a transferência (vai aparecer a mensagem no transmissor "Levou XXXXX segundos para transmitir XXXXX bytes), no receptor digite <CTRL + C>, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo? | + | #* Quando completar a transferência (vai aparecer a mensagem no '''transmissor''' "Levou XXXXX segundos para transmitir XXXXX bytes), no '''receptor''' digite <CTRL + C>, verifique o tamanho do arquivo recebido. |
+ | #* Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo? | ||
#* Analisando a captura de pacotes do WireShark responda: | #* Analisando a captura de pacotes do WireShark responda: | ||
## Qual é o identificar do primeiro e do último pacote? Existe? | ## Qual é o identificar do primeiro e do último pacote? Existe? | ||
## É possível calcular o tamanho do arquivo pela análise dos pacotes? É mais fácil ou difícil que no caso da transferência via TCP? | ## É possível calcular o tamanho do arquivo pela análise dos pacotes? É mais fácil ou difícil que no caso da transferência via TCP? | ||
− | # Compare as transferências feitas com TCP e UDP. O que eles têm em comum? Que diferenças lhe pareceram mais pronunciadas? Como isso deve afetar as aplicações que usam esses protocolos? | + | ## Há segmentos de controle ou somente segmentos de dados? |
+ | ## Qual é o tamanho do último segmento de dados recebido? | ||
+ | # Compare as transferências feitas com os protocolos TCP e UDP. | ||
+ | ## O que eles têm em comum? | ||
+ | ## Que diferenças lhe pareceram mais pronunciadas? | ||
+ | ## Como isso deve afetar as aplicações que usam esses protocolos? | ||
==== Experimento 2 ==== | ==== Experimento 2 ==== | ||
+ | *Tem como objetivo gerar um gráfico para facilitar a visualização da equidade do protocolo TCP. | ||
+ | |||
+ | #Utilizar o software [https://iperf.fr/ Iperf] (iperf –h para help) para gerar tráfego entre duas máquinas, '''cliente''' e '''servidor'''. Combine com seu vizinho. | ||
+ | #No '''servidor''' execute: <code> | ||
+ | iperf -s -p 2000 & iperf -s -p 2001 & iperf -s -p 2002 </syntaxhighlight> | ||
+ | #No '''servidor''' execute o wireshark. | ||
+ | #No '''cliente''' execute: <code> | ||
+ | iperf -c ip_do_servidor -f m -i 1 -t 15 -p 2000 -l 1400 & (sleep 3; iperf -c ip_do_servidor | ||
+ | -f m -i 1 -t 9 -p 2001 -l 1400) & (sleep 6; iperf -c ip_do_servidor -f m -i 1 -t 6 -p 2002) & </syntaxhighlight> | ||
+ | #Fique monitorando o cliente e assim que o campo '''Interval''' atingir o valor '''15 sec''', pare a captura no Wireshark. | ||
+ | #No Wireshark acesse '''Statistics''' >> '''IO Graph''' e, na tela que abrir, ajuste TODOS os parâmetros para obter um gráfico similar ao apresentado na Figura 1. Perceba que todos os botões '''Graph 1...4''', devem ser clicados, isso fará com que o Wireshark mostre as respectivas curvas. Salve o gráfico gerado. | ||
+ | |||
+ | [[Arquivo:TCP_Wireshark.png |thumb | 400px| Figura 1 - Captura de 3 fluxos de dados]] | ||
+ | |||
+ | #Responda: | ||
+ | ##Explique detalhadamente o significado de cada parâmetro dos comandos acima, tanto do cliente quanto do servidor. | ||
+ | ##Explique os filtros aplicados no gráfico do Wireshark. | ||
+ | ##*Quais são os 4 gráficos apresentados? | ||
+ | ##*Há uma relação de valor entre as curvas? | ||
+ | ##*Qual é esta relação? | ||
+ | ##Por que a curva vermelha se sobrepõe a curva preta nos primeiros 3 segundos? Considere o início do tempo onde há início de tráfego! | ||
+ | ##Qual é a relação entre a curva preta e as curvas vermelha e verde no intervalo entre 3 e 6 segundos? | ||
+ | ##Explique a relação entre as 4 curvas e o comando do cliente no intervalo entre 3 e 12 segundos. | ||
+ | ##Qual é o mecanismo do TCP que explica a grande oscilação das curvas, principalmente percebida no intervalo entre 6 e 12 segundos? | ||
+ | |||
+ | *Agora vamos dificultar a vida do TCP incluindo um tráfego UDP. O gráfico gerado deverá apresentar a competição pelo meio de transmissão entre os diversos fluxos de dados. | ||
+ | #No '''servidor''' execute: <code> | ||
+ | iperf -s -p 2000 & iperf -s -p 2001 & iperf -s -u -p 2002 </syntaxhighlight> | ||
+ | #No '''servidor''' execute o wireshark. | ||
+ | #No '''cliente''' execute: <code> | ||
+ | iperf -c ip_do_servidor -f m -i 1 -t 15 -p 2000 -l 1400 & (sleep 3; iperf -c ip_do_servidor | ||
+ | -f m -i 1 -t 9 -p 2001 -l 1400) & (sleep 6; iperf -u -c ip_do_servidor -f m -i 1 -t 6 -p 2002) & </syntaxhighlight> | ||
+ | #Fique monitorando o cliente e assim que o campo '''Interval''' atingir o valor '''15 sec''', pare a captura no Wireshark. | ||
+ | #Baseado na Figura 1, no '''Graph 4''' altere o filtro para '''udp.port==2002'''. Salve o gráfico gerado. | ||
+ | #Responda as mesmas questões do item anterior, '''todas'''. | ||
+ | |||
+ | ==== Experimento 3 ==== | ||
− | Transferências usando cada um desses protocolos podem apresentar características bem distintas. Neste | + | Transferências usando cada um desses protocolos podem apresentar características bem distintas. Neste terceiro experimento, serão feitas transferências simultâneas de arquivos a partir de um mesmo servidor, comparando-se o resultado obtido com TCP e UDP. Essas transferência ocorrerão entre os computadores do laboratório e um servidor externo ao laboratório. |
# Todos devem executar este procedimento ao mesmo tempo. Abra um terminal em seu computador, e nele execute este comando, '''só tecle <Enter> quando o professor determinar''': <syntaxhighlight lang=bash> | # Todos devem executar este procedimento ao mesmo tempo. Abra um terminal em seu computador, e nele execute este comando, '''só tecle <Enter> quando o professor determinar''': <syntaxhighlight lang=bash> | ||
Linha 835: | Linha 937: | ||
# Após todos terem copiado o arquivo, o professor irá repetir a transferência, porém desta vez ele irá fazê-la sozinho. Que taxas ele obteve, e quanto tempo levou? | # Após todos terem copiado o arquivo, o professor irá repetir a transferência, porém desta vez ele irá fazê-la sozinho. Que taxas ele obteve, e quanto tempo levou? | ||
# O professor irá repetir a transferência novamente, mas desta vez ele irá pedir que um aluno também a inicie logo em seguida. Qual foi a taxa obtida por ambos? | # O professor irá repetir a transferência novamente, mas desta vez ele irá pedir que um aluno também a inicie logo em seguida. Qual foi a taxa obtida por ambos? | ||
− | |||
# Para poder fazer uma comparação, as transferências serão feitas novamente porém usando UDP como protocolo de transporte. Para isso siga estes passos: | # Para poder fazer uma comparação, as transferências serão feitas novamente porém usando UDP como protocolo de transporte. Para isso siga estes passos: | ||
## Abra dois terminais. No '''terminal 1''' execute este comando: <syntaxhighlight lang=bash> | ## Abra dois terminais. No '''terminal 1''' execute este comando: <syntaxhighlight lang=bash> | ||
Linha 842: | Linha 943: | ||
./receptor 5555 > arquivo | ./receptor 5555 > arquivo | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | ## Fique observando o '''terminal 1'''. O professor irá transmitir o arquivo | + | ## Fique observando o '''terminal 1'''. |
− | ## Em que valor o tamanho do arquivo parou de crescer? Quanto tempo isso levou, aproximadamente? | + | ## O professor irá transmitir o arquivo, um processo para cada aluno. |
− | ## | + | ## No '''terminal 1''' observe o tamanho do arquivo, que deverá aumentar gradativamente. Monitore manualmente o tempo em segundos (relógio, celular ou relógio do computador), o tamanho e quando o tamanho do arquivo parou de crescer. |
− | + | ## Em que valor o tamanho do arquivo parou de crescer? Quanto tempo isso levou, aproximadamente? O tamanho do arquivo recebido é o mesmo do arquivo original? | |
− | + | ## Faça um comparativo das transferências usando TCP e UDP. | |
− | |||
− | |||
− | |||
− | |||
==== Tarefa extra (pode ser em casa)==== | ==== Tarefa extra (pode ser em casa)==== | ||
Linha 914: | Linha 1 011: | ||
##Configure o roteador padrão em todos os PCs, por exemplo no '''pc1''': <code> route add -net default gw 192.168.0.254 </syntaxhighlight> | ##Configure o roteador padrão em todos os PCs, por exemplo no '''pc1''': <code> route add -net default gw 192.168.0.254 </syntaxhighlight> | ||
##Teste novamente a conectividade, no '''pc1''' execute o comando: <code> ping 10.0.0.1 </syntaxhighlight> e <code> ping 10.0.0.2 </syntaxhighlight> Obteve sucesso? O comportamento foi o mesmo dos iten 5.2 e 5.3? Sim ou não e por quê? | ##Teste novamente a conectividade, no '''pc1''' execute o comando: <code> ping 10.0.0.1 </syntaxhighlight> e <code> ping 10.0.0.2 </syntaxhighlight> Obteve sucesso? O comportamento foi o mesmo dos iten 5.2 e 5.3? Sim ou não e por quê? | ||
− | ##Com os ping do item anterior ativos (um a cada tempo) rode o '''wireshark''' no '''r1''' (clique na aba '''r1''' e em seguida no menu '''wireshark any'''. Observe que ao usar o wireshark com o Netkit, o wireshark não é dinâmico, ou seja, de tempos em tempos deves recarregar (''reload'') a captura de pacotes). | + | ##Com os ping do item anterior ativos (um a cada tempo) rode o '''wireshark''' no '''r1''' (clique na aba '''r1''' e em seguida no menu '''wireshark any'''. Observe que ao usar o wireshark com o Netkit, o wireshark não é dinâmico, ou seja, de tempos em tempos deves recarregar (''reload'' <CTRL>+<R>) a captura de pacotes). |
###Qual a origem e destino dos pacotes? Por quê? | ###Qual a origem e destino dos pacotes? Por quê? | ||
###Qual a diferença no ping entre os dois itens? | ###Qual a diferença no ping entre os dois itens? | ||
Linha 920: | Linha 1 017: | ||
#Iniciando o roteamento | #Iniciando o roteamento | ||
##Deixe o '''ping''' do item 5.3 e o '''wireshark''' (ou '''tcpdump''') do item 5.6 rodando e estabeleça uma rota no roteador '''r2''' com o comando: <code> route add -net 192.168.0.0/24 gw 10.0.0.1 </syntaxhighlight> O que ocorreu com o '''ping''' e o '''wireshark'''? Por quê? | ##Deixe o '''ping''' do item 5.3 e o '''wireshark''' (ou '''tcpdump''') do item 5.6 rodando e estabeleça uma rota no roteador '''r2''' com o comando: <code> route add -net 192.168.0.0/24 gw 10.0.0.1 </syntaxhighlight> O que ocorreu com o '''ping''' e o '''wireshark'''? Por quê? | ||
− | ##Em todos os roteadores crie rotas para todas as redes. Se tudo estiver correto, todos os PCs devem pingar entre si. Teste! | + | ##* Interpretando o comando: route add (adiciona rota) -net 192.168.0.0/24 (para a rede 192.168.0.0/24) gw 10.0.0.1 (utilizando a interface 10.0.0.1, enlace direto, do roteador r1). |
+ | ##Em todos os roteadores crie rotas para todas as redes. Em cada roteador deve-se criar 3 rotas, para as sub-redes "distantes". Lembre-se que os enlaces diretor já criam automaticamente rotas para as respectivas sub-redes, diretamente conectadas ao equipamento. Se tudo estiver correto, '''todos''' os PCs devem pingar entre si. Teste! | ||
#Testando a queda de enlace. | #Testando a queda de enlace. | ||
##Com todas as rotas em perfeito funcionamento, gere um '''ping''' do '''pc1''' para o '''pc3''' e execute '''wireshark any''' no '''r1''' , em seguida "derrube" o enlace entre o '''r1''' e '''r3'''. Por exemplo, no '''r3''' execute o comando: <code> ifconfig eth1 down </syntaxhighlight> O que ocorreu com o '''ping''' e o '''wireshark'''? Por quê? Com este enlace comprometido qual seria a solução para a continuidade de funcionamento de toda a rede? | ##Com todas as rotas em perfeito funcionamento, gere um '''ping''' do '''pc1''' para o '''pc3''' e execute '''wireshark any''' no '''r1''' , em seguida "derrube" o enlace entre o '''r1''' e '''r3'''. Por exemplo, no '''r3''' execute o comando: <code> ifconfig eth1 down </syntaxhighlight> O que ocorreu com o '''ping''' e o '''wireshark'''? Por quê? Com este enlace comprometido qual seria a solução para a continuidade de funcionamento de toda a rede? | ||
Linha 936: | Linha 1 034: | ||
tabela de roteamento. Note que a tabela de roteamento é mantida pelo kernel do | tabela de roteamento. Note que a tabela de roteamento é mantida pelo kernel do | ||
Sistema Operacional Linux/Unix e qualquer modificação será realizada a partir | Sistema Operacional Linux/Unix e qualquer modificação será realizada a partir | ||
− | da API (Application Programming Interface) do sistema. O processo Zebra | + | da API (''Application Programming Interface'') do sistema. O processo Zebra |
centraliza todo o gerenciamento da tabela recebendo e repassando informações | centraliza todo o gerenciamento da tabela recebendo e repassando informações | ||
para outros processos que executam um determinado protocolo de roteamento. Por | para outros processos que executam um determinado protocolo de roteamento. Por | ||
Linha 1 024: | Linha 1 122: | ||
#Permaneça monitorando o ping e o Wireshark (''reload''), a recuperação das rotas leva em torno de 1 min: | #Permaneça monitorando o ping e o Wireshark (''reload''), a recuperação das rotas leva em torno de 1 min: | ||
##Quais as mensagens trocadas pelo protocolo RIP observadas no WireShark? | ##Quais as mensagens trocadas pelo protocolo RIP observadas no WireShark? | ||
− | ##Qual o tempo aproximado para a total recuperação das rotas? | + | ##Qual o tempo aproximado para a total recuperação das rotas? (Talvez isso seja observável pela diferença de tempos na sequência de mensagens observadas no Wireshark). |
#Teste as conectividades. O que aconteceu? | #Teste as conectividades. O que aconteceu? | ||
#Retrace as rotas com nos roteadores <code> vtysh 2061 | #Retrace as rotas com nos roteadores <code> vtysh 2061 | ||
show ip route </syntaxhighlight> e com o <code> traceroute </syntaxhighlight> a partir dos PCs. | show ip route </syntaxhighlight> e com o <code> traceroute </syntaxhighlight> a partir dos PCs. | ||
##São diferentes do caso original (todos enlaces ativos)? Por quê? | ##São diferentes do caso original (todos enlaces ativos)? Por quê? | ||
− | ##Quais os caminhos que foram reescritos? Por quê? | + | ##Quais os caminhos/rotas que foram reescritos? Por quê? |
==Experimento 3: protocolos e roteamento OSPF== | ==Experimento 3: protocolos e roteamento OSPF== | ||
Linha 1 117: | Linha 1 215: | ||
A '''descoberta de vizinhança''' por meio do protocolo ''Neighbor Discovery'' no | A '''descoberta de vizinhança''' por meio do protocolo ''Neighbor Discovery'' no | ||
− | IPv6 é um procedimento realizado pelos nós de uma rede para descobrir | + | IPv6 é um procedimento realizado pelos nós de uma rede para descobrir endereços físicos dos dispositivos vizinhos presentes no mesmo enlace. A função deste protocolo se assemelha à função do ARP e do RARP no IPv4. |
− | endereços físicos dos dispositivos vizinhos presentes no mesmo enlace. A | + | *O procedimento é iniciado quando um dispositivo tenta enviar um pacote cujo endereço físico de destino é desconhecido. O nó solicitante envia uma mensagem ''Neighbor Solicitation'' (NS) para todos os nós do enlace pertencentes ao grupo ''multicast solicited-node'' (ff02::1:ffXX:XXXX), de modo que XX:XXXX são os últimos 24 bits do endereço IPv6 em que está interessado. |
− | função deste protocolo se assemelha à função do ARP e do RARP no | + | *É possível notar que, por uma coincidência dos últimos 24 bits, é bastante provável que apenas o nó de destino faça realmente parte deste grupo. Isto é um ''truque'' interessante do IPv6 para diminuir o tráfego deste tipo de pacote na rede. |
− | IPv4. | + | *Na mensagem NS, o endereço IPv6 a ser resolvido é informado no campo ''Target''. O campo ''Source link-layer address'' informa ao nó de destino o endereço MAC do nó de origem, poupando-o de ter que fazer o mesmo procedimento no sentido inverso. |
− | + | *O nó de destino, dono do IPv6 requisitado, ao receber este pacote, envia uma mensagem ''Neighbor Advertisement'' (NA) como resposta diretamente ao nó requisitante. O seu endereço físico será informado no campo ''Target link-layer address''. | |
− | O procedimento é iniciado quando um dispositivo tenta enviar um pacote | + | *A informação de mapeamento entre endereços IP e endereços físicos é armazenada em uma tabela chamada ''neighbor cache''. Nela também fica registrado o ''status'' de cada destino, informando se o mesmo é alcançável ou não. |
− | cujo endereço físico de destino é desconhecido. O nó solicitante envia | ||
− | uma mensagem ''Neighbor Solicitation'' (NS) para todos os nós do enlace | ||
− | pertencentes ao grupo ''multicast solicited-node'' (ff02::1:ffXX:XXXX), de | ||
− | modo que XX:XXXX são os últimos 24 bits do endereço IPv6 em que | ||
− | está interessado. | ||
− | |||
− | É possível notar que, por uma coincidência dos últimos 24 bits, é bastante | ||
− | provável que apenas o nó de destino faça realmente parte deste grupo. | ||
− | Isto é um ''truque'' interessante do IPv6 para diminuir o tráfego deste tipo | ||
− | de pacote na rede. | ||
− | |||
− | Na mensagem NS, o endereço IPv6 a ser resolvido é informado no campo | ||
− | ''Target''. O campo ''Source link-layer address'' informa ao nó de destino o | ||
− | endereço MAC do nó de origem, poupando-o de ter que fazer o mesmo | ||
− | procedimento no sentido inverso. | ||
− | |||
− | O nó de destino, dono do IPv6 requisitado, ao receber este pacote, envia | ||
− | uma mensagem ''Neighbor Advertisement'' (NA) como resposta diretamente | ||
− | ao nó requisitante. O seu endereço físico será informado no campo ''Target | ||
− | link-layer address''. | ||
− | |||
− | A informação de mapeamento entre endereços IP e endereços físicos é | ||
− | armazenada em uma tabela chamada ''neighbor cache''. Nela também fica | ||
− | registrado o ''status'' de cada destino, informando se o mesmo é alcançável | ||
− | ou não. | ||
===Roteiro de atividades:=== | ===Roteiro de atividades:=== | ||
Linha 1 210: | Linha 1 283: | ||
#Faça um '''ping6''' entre o '''pc3''' ao '''pc4'''. Por exemplo do '''pc3''' ao '''pc4''': <code> | #Faça um '''ping6''' entre o '''pc3''' ao '''pc4'''. Por exemplo do '''pc3''' ao '''pc4''': <code> | ||
ping6 2001:bcc:1f0:1::104 </syntaxhighlight> | ping6 2001:bcc:1f0:1::104 </syntaxhighlight> | ||
− | # | + | #Se tudo estiver devidamente configurado, deve-se obter sucesso. Explique o por quê? |
#Faça um '''ping6''' entre o '''pc1''' ao '''pc2'''. | #Faça um '''ping6''' entre o '''pc1''' ao '''pc2'''. | ||
#Obteve sucesso? Sim ou não e por quê? | #Obteve sucesso? Sim ou não e por quê? | ||
Linha 1 230: | Linha 1 303: | ||
#Anote as rotas. | #Anote as rotas. | ||
#Use o comando '''ip -6 route show''' para consultar a tabela de roteamento de cada um dos roteadores. São coerentes com os dados das rotas obtidas acima? | #Use o comando '''ip -6 route show''' para consultar a tabela de roteamento de cada um dos roteadores. São coerentes com os dados das rotas obtidas acima? | ||
+ | #Explique a tabela de roteamento do '''r1''', em especial os endereços de '''link local'''. Porque não há confusão dos prefixos? Explique também o uso dos prefixos diferentes para os '''pc1''' e '''pc2'''. Por que não foi utilizado o mesmo prefixo? | ||
+ | #É possível utilizar os comandos '''route''' e '''ifconfig''' para configurar redes IPv6? Pesquise rapidamente no google e tente realizar a configuração do '''pc4''' utilizando estes comandos. Para isso, use o comando '''ip addr flush dev eth0''' no '''pc4''' para limpar toda a configuração de endereços e rotas da interface. Depois disso configure o endereço com '''ifconfig''' e as rotas com o comando '''route'''. | ||
#Em cada uma das máquinas virtuais, use o comando '''fg tcpdump''' para trazer o '''tcpdump''' para o primeiro plano. Em seguida encerre a captura com '''Ctrl + C'''. | #Em cada uma das máquinas virtuais, use o comando '''fg tcpdump''' para trazer o '''tcpdump''' para o primeiro plano. Em seguida encerre a captura com '''Ctrl + C'''. | ||
#Estude os '''.pcaps''' gerados utilizando o '''wireshark''': abra o '''wireshark''', '''File/Open''' e procure os arquivo na pasta /home/aluno/lab. Clique sobre cada um deles e faça a análise. | #Estude os '''.pcaps''' gerados utilizando o '''wireshark''': abra o '''wireshark''', '''File/Open''' e procure os arquivo na pasta /home/aluno/lab. Clique sobre cada um deles e faça a análise. | ||
− | # | + | #A partir das capturas obtidas e utilizando um filtro '''icmpv6''', explique o processo de descoberta de vizinhança (''neighbor discovery'' / ''Neighbor Solicitation'' - '''NS''' e ''Neighbor Advertisement'' - '''NA'''), citando os endereços de '''multicast''' e '''link local''' utilizados. |
− | + | #Alguns exemplos de campos visualizáveis para uma mensagem do tipo ''Neighbor Advertisement'': | |
− | # | + | ##Destination (camada Ethernet) |
− | # | + | ##*O endereço MAC do nó requisitante que foi obtido por meio da mensagem NS enviada anteriormente. |
+ | ##Source (camada Ethernet) | ||
+ | ##*A origem é o endereço MAC da interface do dispositivo que enviou a resposta. | ||
+ | ##Type (camada Ethernet) | ||
+ | ##*Indica que a mensagem utiliza IPv6. | ||
+ | ##Next header (camada IPv6) | ||
+ | ##*Indica qual é o próximo cabeçalho. Neste caso, o valor 58 (0x3a) refere-se a uma mensagem ICMPv6. | ||
+ | ##Source (camada IPv6) | ||
+ | ##*A origem é o endereço IP da interface diretamente ligada ao enlace em que a requisição foi recebida. | ||
+ | ##Destination (camada IPv6) | ||
+ | ##*Diferentemente da mensagem NS, a mensagem NA possui como destino o endereço IPv6 global do nó requisitante. | ||
+ | ##Type (camada ICMPv6) | ||
+ | ##*Indica que a mensagem é do tipo 136 (Neighbor Advertisement). | ||
+ | ##Flags (camada ICMPv6) | ||
+ | ##*Uma mensagem NA possui três flags: | ||
+ | ###Indica se quem está enviando é um roteador. Neste caso, o valor marcado é 0, pois não é um roteador. | ||
+ | ###Indica se a mensagem é uma resposta a um NS. Neste caso, o valor marcado é 1, pois é uma resposta. | ||
+ | ###Indica se a informação carregada na mensagem é uma atualização de endereço de algum nó da rede. Neste caso, o valor marcado é 1, pois está informando o endereço pela primeira vez. | ||
+ | ##Target Address (camada ICMPv6) | ||
+ | ##*Indica o endereço IP associado às informações das flags. Neste caso, é o próprio endereço da interface do dispositivo em questão. | ||
+ | ##ICMPv6 option (camada ICMPv6) | ||
+ | ##*Indica as opções do pacote ICMPv6: | ||
+ | ###Target link-layer address | ||
+ | ##Type | ||
+ | ##*Indica o tipo de opção. Neste caso, Target link-layer address. | ||
+ | ##Link-layer address | ||
+ | ##*Indica o endereço MAC da interface do dispositivo em questão. | ||
#Explique sucintamente as diferenças na comunicação baseada em IPv4 e IPv6. | #Explique sucintamente as diferenças na comunicação baseada em IPv4 e IPv6. | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
Linha 1 249: | Linha 1 350: | ||
* [http://www.pop-sc.rnp.br/publico/monitoramento.php Monitoramento do tráfego RNP - PoP-SC] | * [http://www.pop-sc.rnp.br/publico/monitoramento.php Monitoramento do tráfego RNP - PoP-SC] | ||
* [http://memoria.rnp.br/ceo/trafego/panorama.php Monitoramento do tráfego RNP - Nacional] | * [http://memoria.rnp.br/ceo/trafego/panorama.php Monitoramento do tráfego RNP - Nacional] | ||
+ | * [http://www.redclara.net/index.php/pt/red-y-conectividad/topologia Rede Clara Internacional] | ||
* [https://www.youtube.com/watch?v=IlAJJI-qG2k Animated map shows the undersea cables that power the internet] | * [https://www.youtube.com/watch?v=IlAJJI-qG2k Animated map shows the undersea cables that power the internet] | ||
* [http://submarine-cable-map-2015.telegeography.com/ Submarine Cable Map 2015] | * [http://submarine-cable-map-2015.telegeography.com/ Submarine Cable Map 2015] | ||
Linha 1 259: | Linha 1 361: | ||
* [https://www.youtube.com/watch?v=1G3SUTmioQE ''Browser Wars'' - legendado] | * [https://www.youtube.com/watch?v=1G3SUTmioQE ''Browser Wars'' - legendado] | ||
* [https://www.youtube.com/watch?v=0nz-lcuv3TM ''Browser Wars'' - dublado] | * [https://www.youtube.com/watch?v=0nz-lcuv3TM ''Browser Wars'' - dublado] | ||
+ | * [https://db-ip.com/200.135.37.65 Localização geográfica de IPs] | ||
* [http://ipv6.br/ '''IPv6 no Brasil'''] | * [http://ipv6.br/ '''IPv6 no Brasil'''] | ||
* [http://ipv6.br/lab/ Laboratório de IPv6 - Livro didático contendo vários roteiros para entendimento do IPv6] | * [http://ipv6.br/lab/ Laboratório de IPv6 - Livro didático contendo vários roteiros para entendimento do IPv6] | ||
Linha 1 270: | Linha 1 373: | ||
**Apresentação de um trabalho científico | **Apresentação de um trabalho científico | ||
− | Recomenda-se a confecção do relatório na própria Wiki. O professor criará a página para cada projeto que assim o desejar. Na página do projeto, os membros da equipe podem editar a qualquer hora, sem preocupação com a versão do mesmo. Também facilita o acompanhamento por parte do professor. Utilizando ou não a Wiki, usem esse [http://docente.ifsc.edu.br/odilson/RED29004/modelo_relatorio.odt modelo de relatório]. | + | Recomenda-se a confecção do relatório na própria Wiki. O professor criará a página para cada projeto que assim o desejar. Na página do projeto, os membros da equipe podem editar a qualquer hora, sem preocupação com a versão do mesmo. Também facilita o acompanhamento por parte do professor. Utilizando ou não a Wiki, usem esse [http://docente.ifsc.edu.br/odilson/RED29004/modelo_relatorio.odt modelo de relatório]. Um exemplo de bom relatório gerado [http://docente.ifsc.edu.br/odilson/RED29004/IPv6_relatorio_modelo.pdf]. |
* ''Grupos e Temas para 2016-2'': | * ''Grupos e Temas para 2016-2'': | ||
− | # | + | # Lucas da Silva e Douglas Amorim: '''[[NAT]]'''. Apresentação 8/12. |
+ | # Schaiana Sonaglio e Vinícius da Luz Souza: '''[[Redes MPLS]]'''. Apresentação 13/12. | ||
+ | # Allex e Yara: '''Voip'''. Apresentação 13/12. | ||
+ | # Anderson e Joseane: '''RFID'''. Apresentação 8/12. | ||
+ | # Nelito: '''QoS'''. Apresentação 13/12. | ||
+ | # Gabriel Farias Turnes e Rafael Teles: '''[[Grampos VoIP]]'''. Apresentação 8/12. | ||
+ | # Aldebarã e Wagner: '''Comparativo entre as tecnologias Zigbee e LoRA'''. Apresentação 13/12. | ||
* Avaliação | * Avaliação | ||
+ | **[http://docente.ifsc.edu.br/odilson/RED29004/Avaliacao%20dos%20relatorios%20e%20apresentacao.pdf <span style="font-size:200%"> Avaliação dos relatórios e seminários] | ||
** Nota: 0,5 x Documento + 0,5 x Seminário | ** Nota: 0,5 x Documento + 0,5 x Seminário | ||
**[http://docente.ifsc.edu.br/odilson/RED29004/Criterio%20de%20avaliacao%20dos%20relatorios%20e%20apresentacao.pdf Critérios de avaliação] | **[http://docente.ifsc.edu.br/odilson/RED29004/Criterio%20de%20avaliacao%20dos%20relatorios%20e%20apresentacao.pdf Critérios de avaliação] | ||
* ''Instruções sobre o Seminário de Redes I'': | * ''Instruções sobre o Seminário de Redes I'': | ||
− | ** Data para definição de grupos e temas: ''' | + | ** Data para definição de grupos e temas: '''27/10/2016'''. |
** 2 alunos por equipe. | ** 2 alunos por equipe. | ||
** Os temas devem ser propostos pelas equipes em comum acordo com o professor ou então na data limite o professor apresenta alguns temas e as equipes escolhem. | ** Os temas devem ser propostos pelas equipes em comum acordo com o professor ou então na data limite o professor apresenta alguns temas e as equipes escolhem. | ||
− | ** Data de entrega do documento: ''' | + | ** Data de entrega do documento: '''29/11/2016''' (impreterivelmente). |
** O relatório pode ser redigido como uma página da wiki. | ** O relatório pode ser redigido como uma página da wiki. | ||
** Duração da apresentação: 20 minutos (limitantes: 15 a 25 minutos) + 5 minutos de perguntas. | ** Duração da apresentação: 20 minutos (limitantes: 15 a 25 minutos) + 5 minutos de perguntas. | ||
Linha 1 291: | Linha 1 401: | ||
=Diário de aulas= | =Diário de aulas= | ||
− | {{Collapse top |Aula 1 - 11/08/ | + | {{Collapse top |Aula 1 - 11/08/2016: Apresentação da disciplina}} |
* Apresentação da disciplina, plano de aula, trabalhos e métodos de avaliação. | * Apresentação da disciplina, plano de aula, trabalhos e métodos de avaliação. | ||
Linha 1 301: | Linha 1 411: | ||
## Conceito final obtido pela "média" das avaliações. | ## Conceito final obtido pela "média" das avaliações. | ||
## Reavaliação única no último dia de aula. | ## Reavaliação única no último dia de aula. | ||
+ | # [[Cronograma_de_atividades_(RED1-EngTel) | Cronograma de atividades com '''datas de avaliações''']] | ||
# [[Engenharia de Telecomunicações (páginas das disciplinas)|Relação com outras disciplinas do curso]] | # [[Engenharia de Telecomunicações (páginas das disciplinas)|Relação com outras disciplinas do curso]] | ||
# [[RED29004-2015-2#Semin.C3.A1rios|Apresentação do Seminário]] | # [[RED29004-2015-2#Semin.C3.A1rios|Apresentação do Seminário]] | ||
Linha 1 306: | Linha 1 417: | ||
#* Definição de temas é livre, pensem sobre o assunto. | #* Definição de temas é livre, pensem sobre o assunto. | ||
# Qual o grande objetivo das redes de computadores? | # Qual o grande objetivo das redes de computadores? | ||
+ | # Como é formada uma rede de computadores? | ||
+ | # [[RED29004-2016-2#Curiosidades | Curiosidades]] | ||
# Introdução às redes de computadores | # Introdução às redes de computadores | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | Aula 2 - 16/08/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%201%20Redes%20de%20computadores%20e%20a%20Internet.pdf Introdução | + | Aula 2 - 16/08/2016: Aula suspensa devido a participação no T'''reinamento em Tecnologia FPGA Altera'''. |
+ | |||
+ | Aula 3 - 18/08/2016: Aula suspensa devido a participação no T'''reinamento em Tecnologia FPGA Altera'''. | ||
+ | |||
+ | Aula 4 - 23/08/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%201%20Redes%20de%20computadores%20e%20a%20Internet.pdf Redes de Computadores e a Internet] | ||
+ | |||
+ | Aula 5 - 25/08/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%201%20Redes%20de%20computadores%20e%20a%20Internet.pdf Redes de Computadores e a Internet] e Visita ao [http://www.pop-sc.rnp.br/publico/monitoramento.php?map=REMEP-POP-SJ.html PoP São José] da RNP | ||
+ | |||
+ | Aula 6 - 30/08/16: Laboratório 1: [[RED29004-2016-2#Roteiros_para_laborat.C3.B3rio | Ping, Traceroute e Wireshark]] | ||
+ | |||
+ | Aula 7 - 01/09/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%201%20Redes%20de%20computadores%20e%20a%20Internet.pdf Redes de Computadores e a Internet] e [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%202%20Camada%20de%20aplica%C3%A7%C3%A3o.pdf Camada de Aplicação] | ||
+ | |||
+ | Aula 8 - 06/09/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%202%20Camada%20de%20aplica%C3%A7%C3%A3o.pdf Camada de Aplicação] | ||
+ | |||
+ | Aula 9 - 08/09/16: Laboratório 2: [[RED29004-2016-2#Roteiros_para_laborat.C3.B3rio | Desvendando o HTTP com Wireshark]] | ||
+ | |||
+ | Aula 10 - 13/09/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%202%20Camada%20de%20aplica%C3%A7%C3%A3o.pdf Camada de Aplicação] | ||
+ | |||
+ | Aula 11 - 15/09/16: Laboratório 3: [[RED29004-2016-2#Roteiros_para_laborat.C3.B3rio | Serviço de Nomes (DNS)]] | ||
+ | |||
+ | Aula 12 - 20/09/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%202%20Camada%20de%20aplica%C3%A7%C3%A3o.pdf Camada de Aplicação] e dúvidas para a primeira avaliação. | ||
+ | |||
+ | Aula 13 - 22/09/16: Primeira avaliação | ||
+ | |||
+ | Aula 14 - 27/09/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%203%20Camada%20de%20transporte.pdf Camada de Transporte] | ||
+ | |||
+ | Aula 15 - 29/09/16: Laboratório 4: [[RED29004-2016-2#Roteiros_para_laborat.C3.B3rio | Entendendo sockets]] | ||
+ | |||
+ | Aula 16 - 04/10/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%203%20Camada%20de%20transporte.pdf Camada de Transporte] | ||
+ | |||
+ | Aula 17 - 06/10/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%203%20Camada%20de%20transporte.pdf Camada de Transporte] | ||
+ | |||
+ | Aula 18 - 11/10/16: Laboratório 5: [[RED29004-2016-2#Roteiros_para_laborat.C3.B3rio |TCP x UDP]] | ||
+ | |||
+ | Aula 19 - 13/10/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%203%20Camada%20de%20transporte.pdf Finalização da camada de Transporte] e [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Camada de Rede] | ||
+ | |||
+ | Aula 20 - 18/10/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Camada de Rede] | ||
+ | |||
+ | Aula 21 - 20/10/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Camada de Rede] | ||
+ | |||
+ | Aula 22 - 25/10/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Camada de Rede] e Dúvidas para segunda avaliação. | ||
+ | |||
+ | Aula 23 - 27/10/16: Segunda avaliação | ||
+ | |||
+ | Aula 24 - 01/11/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Camada de Rede] | ||
+ | |||
+ | Aula 25 - 03/11/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Camada de Rede] | ||
+ | |||
+ | Aula 26 - 08/11/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Camada de Rede] | ||
+ | |||
+ | Aula 27 - 10/11/16: Laboratório 6: [[RED29004-2016-2#Roteiros_para_laborat.C3.B3rio | Protocolos de Roteamento]]. | ||
+ | |||
+ | Aula 28 - 17/11/16: Laboratório 7: [[RED29004-2016-2#Roteiros_para_laborat.C3.B3rio | Protocolos de Roteamento (cont.)]]. | ||
+ | |||
+ | Aula 29 - 22/11/16: [http://docente.ifsc.edu.br/odilson/RED29004/IPv6.pdf IPv6]. | ||
+ | |||
+ | Aula 30 - 24/11/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Camada de Rede] | ||
+ | |||
+ | Aula 31 - 29/11/16: Laboratório 8: [[RED29004-2016-2#Roteiros_para_laborat.C3.B3rio | Neighbor Discovery no IPv6]]. | ||
+ | |||
+ | Aula 32 - 01/12/16: Dúvidas para terceira avaliação. | ||
+ | |||
+ | Aula 33 - 06/12/16: Terceira avaliação. | ||
+ | |||
+ | Aula 34 - 08/12/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%207%20Redes%20multim%C3%ADdia.pdf Aplicação e protocolos para sinalização/comunicação multimídia (SIP e RTP)] e [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%205%20Camada%20de%20enlace.pdf Introdução à camada de enlace]. | ||
+ | |||
+ | Aula 35 - 13/12/16: Apresentação de seminários. | ||
+ | |||
+ | Aula 36 - 15/12/16: Apresentação de seminários. | ||
+ | |||
+ | Aula 37 - 20/12/16: Reavaliação final. |
Edição atual tal como às 16h31min de 20 de dezembro de 2016
Diário de aula de RED29004 - 2016-2 - Prof. Odilson T. Valle
Dados Importantes
Professor: Odilson Tadeu Valle
Email: odilson@ifsc.edu.br
Atendimento paralelo: 3ª das 15h40 às 16h35 e 4ª das 8h25 às 9h20. Local: Lab. de Desenvolvimento.
- Avaliações
- 3 avaliações (A1, A2 e A3) mais um seminário (S).
- Conceito mínimo para não necessitar reavaliação: 6.
- Conceito final obtido pela "média" das avaliações.
- Reavaliação única a ser realizada no último dia de aula.
IMPORTANTE: o direito de recuperar uma avaliação em que se faltou somente existe mediante justificativa reconhecida pela coordenação. Assim, deve-se protocolar a justificativa no prazo de 48 horas, contando da data e horário da avaliação e aguardar o parecer da coordenação.
Plano de Ensino
Cronograma de Atividades
RED29004 2016-2 - Prof. Odilson T. Valle
Material de apoio
Applets do Kurose
Vários aplicativos com representação dinâmica de características das redes de computadores.
Listas de exercícios
Lista de exercícios 1 - Introdução |
---|
|
Lista de exercícios 2 - Camada de Aplicação |
---|
|
Lista de exercícios 3 - Camada de Transporte |
---|
|
Lista de exercícios 4 - Camada de Rede | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Lista de exercícios 5 - Camada de Enlace e Redes Multimídia |
---|
|
Transparências utilizadas durante as aulas
Slides do Kurose referentes ao capítulo 1
Slides do Kurose referentes ao capítulo 2
Slides do Prof. Emerson - DNS, FTP, Web, Email...
Slides do Kurose referentes ao capítulo 7
Slides do Kurose referentes ao capítulo 3 e versão antiga
Slides do Kurose referentes ao capítulo 4
Slides do Kurose referentes ao capítulo 5
Roteiros para laboratório
Laboratório 1 - Ping, Traceroute e Wireshark |
---|
Objetivos
Conceitos introdutórios para uso do laboratórioA rede do laboratório em uso segue o modelo apresentado no diagrama da Figura 1. Máquinas virtuaisEventualmente serão utilizadas nessa disciplina. Os Laboratórios de Redes de Computadores estão equipados com N+1 (N = número de computadores para alunos) computadores conectados em rede e com acesso a Internet, Figura 1. A rede local do laboratório tem endereço IP 192.168.1.0/24. A máscara de rede /24 indica que o último byte do endereço é utilizado para identificar cada máquina, por exemplo 192.168.1.1, 192.168.1.2, etc. O sistema operacional hospedeiro é o Linux Ubuntu. Como os laboratórios são utilizados por várias disciplinas/alunos/professores, os usuários não tem acesso a senha de root (administrador). Para possibilitar a execução de comandos exclusivos do administrador (usuário root), cada computador tem instaladas máquinas virtuais, as quais podem ser lançadas a partir do aplicativo VirtualBox. As máquinas virtuais pertencem a mesma rede local do laboratório e tem endereçamento 192.168.1.x, sendo o byte que identifica a máquina (x) deverá ser manualmente configurado com a seguinte regra: M1 – 101, M2 – 102,..., M9 – 109, M10 – 110,..., M14 – 114 . Por exemplo:, M1 ficará com o endereço 192.168.1.101. Roteiro de atividadesifconfigO aplicativo ifconfig pode ser utilizado para visualizar a configuração ou configurar uma interface de host em redes TCP/IP. Se nenhum argumento for passado na chamada do ifconfig, o comando mostra a configuração atual de cada interface de rede. Consultar as páginas man ifconfig do Linux para maiores detalhes sobre o funcionamento deste aplicativo, o qual permite ativar/desativar a interface, configurar o endereço IP, definir o tamanho da MTU, redefinir o endereço de hardware se a interface suporta, redefinir a interrupção utilizada pelo dispositivo, entre outros.
|
Laboratório 2 - Desvendando o HTTP com Wireshark |
---|
Fonte base: Wireshark - HTTP Objetivos
A Interação Básica GET/Resposta do HTTPVamos iniciar a nossa exploração do HTTP baixando um arquivo em HTML simples - bastante pequeno, que não contém objetos incluídos. Faça o seguinte:
O exemplo da figura 1 mostra na janela de listagem de pacotes duas mensagens HTTP capturadas:
Responda às seguintes perguntas e imprima as mensagens GET e a resposta e indique em que parte da mensagem você encontrou a informação que responde às questões.
A Interação HTTP GET Condicional/RespostaA maioria dos navegadores web tem um cache (seção 2.2.6 do livro) e, desta forma, realizam GET condicional quando baixam um objeto HTTP. Execute os seguintes passos:
Responda às seguintes questões:
Baixando Documentos LongosNos exemplos até agora, os documentos baixados foram simples e pequenos arquivos em HTML. Vamos ver o que acontece quando baixamos um arquivo em HTML grande. Faça o seguinte:
Na janela de listagem de pacotes, você deve ver a sua mensagem HTTP GET, seguida por uma reposta em vários pacotes. Esta resposta em vários pacotes merece uma explicação. Lembre-se da seção 2.2 do livro (veja a figura 2.9) que a mensagem de resposta HTTP consiste de uma linha de status, seguida por zero ou mais linhas de cabeçalhos, seguida por uma linha em branco, seguida pela carga útil (Content-Length). No caso do nossa HTTP GET, a carga útil na resposta é o arquivo HTTP completo. No nosso caso aqui, o arquivo em HTML é bastante longo, e a informação de 11747 bytes é muito grande para caber em um segmento TCP. A resposta HTTP simples é então quebrada em vários pedaços pelo TCP, com cada pedaço sendo contido dentro de um segmento TCP separado. Cada segmento TCP é capturado em um pacote separado pelo Wireshark, clique sobre o nono "Reassembled TCP Segments" no Wireshark. Responda às seguintes questões:
Documentos HTML com Objetos IncluídosAgora que vimos como o Wireshark mostra o tráfego capturado para arquivos em HTML grandes, nós podemos observar o que acontece quando o seu browser baixa um arquivo com objetos incluídos, no nosso exemplo, imagens que estão armazenadas em outros servidores. Faça o seguinte:
Responda às seguintes questões:
HTTPSPara finalizar, vamos capturar sequências de mensagens HTTPS, somente a título de comparação. Execute os seguintes procedimentos:
Responda:
|
Laboratório 3 - Serviço de Nomes (DNS) |
---|
ObjetivosO Domain Name System (DNS) traduz nomes de hosts em endereços Internet Protocol (IP), preenchendo uma lacuna crítica na infraestrutura da Internet. Neste laboratório, observaremos mais de perto:
Lembre-se de que o papel do cliente no DNS é relativamente simples - um cliente envia uma consulta ao seu DNS, e obtém uma resposta. Muito pode acontecer “por baixo dos panos”, de forma invisível aos clientes DNS, enquanto os servidores DNS, organizados hierarquicamente, comunicam-se entre si para, ou recursivamente ou iterativamente, resolver uma consulta DNS de um cliente. Do ponto de vista do cliente DNS, contudo, o protocolo é bastante simples - uma consulta é feita ao seu servidor DNS e uma resposta é recebida deste servidor. Consultas DNS por meio de ferramentas especializadas
|
Laboratório 4 - Entendendo sockets |
---|
ObjetivosEntender o conceito de sockets. Processos que rodam em máquinas diferentes se comunicam entre si enviando mensagens para sockets. Um processo é semelhante a uma casa e o socket do processo é semelhante a uma porta. A aplicação reside dentro da casa e o protocolo da camada de transporte reside no mundo externo. Um programador de aplicação controla o interior da casa mas tem pouco (ou nenhum) controle sobre o exterior. Descrição da aplicação a ser desenvolvida em UDP e TCP
Programação de sockets com UDPA aplicação cliente-servidor usando UDP tem a estrutura apresentada na Figura baixo. Utilizamos a linguagem Python por expor com clareza os principais conceitos de sockets. Quem desejar pode implementar em outras linguagens, por exemplo um modelo para programação de sockets utilizando a API Posix encontra-se aqui. Como fica evidente na Figura acima, os processos cliente e servidor rodam em máquinas distintas e se comunicam justamente enviando mensagens via sockets, que abstrai qualquer necessidade de conhecimento das camadas subjacentes. Roteiro
|
Laboratório 5 - TCP x UDP |
---|
ObjetivosO objetivo desses experimentos é evidenciar as diferenças entre os protocolos TCP e UDP. Ambos protocolos de transporte podem ser usados por aplicações que precisem se comunicar. Porém cada um deles têm certas propriedades, então a escolha precisa ser realizada baseada no tipo de comunicação a ser feita pela aplicação. Experimento 1O que aconteceria se um arquivo fosse transferido de um computador a outro com ambos protocolos?
|
Laboratórios 6 e 7 - Protocolos de roteamento |
---|
ObjetivosAnalisar o funcionamento de protocolos de roteamento estático e dinâmico da Internet, em particular as tabelas estáticas de roteamento, o protocolo RIP e OSPF, a partir de uma estrutura física formada por roteadores e redes locais. Para atingir tais objetivos utilizaremos o netkit2. Leia o tutorial de como o netkit2 trabalha com roteadores. Em todos os experimentos será utilizado como base a seguinte arquitetura de rede: Experimento 1: tabelas estáticas de roteamentoTempo aproximado para execução e conferência: 1 h
|
Laboratório 8 - Neighbor Discovery no IPv6 |
---|
Este roteiro foi baseado no material disponível em [1]. Slides de endereçamento IPv6. Guia didático de endereçamento IPv6 obtido de http://ipv6.br/. Objetivos do laboratório:
Introdução teóricaObs.: texto copiado literalmente de: Laboratório de IPv6. A descoberta de vizinhança por meio do protocolo Neighbor Discovery no IPv6 é um procedimento realizado pelos nós de uma rede para descobrir endereços físicos dos dispositivos vizinhos presentes no mesmo enlace. A função deste protocolo se assemelha à função do ARP e do RARP no IPv4.
Roteiro de atividades:A figura abaixo apresenta o diagrama esquemático da rede a ser montada/analisada. Observe que todos os IPv6 Global Unicast já estão definidos na mesma, são esses IP que utilizaremos em nosso experimento.
|
Softwares
- Netkit2: possibilita criar experimentos com redes compostas por máquinas virtuais Linux.
- CORE Network Emulator
- Vários laboratórios virtuais do NetKit, prontos para uso, que focam em serviços específicos de redes de computadores.
Curiosidades
- Monitoramento do tráfego RNP - PoP-SC
- Monitoramento do tráfego RNP - Nacional
- Rede Clara Internacional
- Animated map shows the undersea cables that power the internet
- Submarine Cable Map 2015
- Redes WiFi no mundo
- History of the Internet
- History of the Internet - legendado
- Warriors of the Net
- Warriors of the Net - legendado
- Browser Wars
- Browser Wars - legendado
- Browser Wars - dublado
- Localização geográfica de IPs
- IPv6 no Brasil
- Laboratório de IPv6 - Livro didático contendo vários roteiros para entendimento do IPv6
- HTTP/2 Frequently Asked Questions
Seminários
- Objetivos:
- Aprofundamento teórico em algum tema atual e relevante
- Confecção de um relatório de trabalho no estilo científico
- Apresentação de um trabalho científico
Recomenda-se a confecção do relatório na própria Wiki. O professor criará a página para cada projeto que assim o desejar. Na página do projeto, os membros da equipe podem editar a qualquer hora, sem preocupação com a versão do mesmo. Também facilita o acompanhamento por parte do professor. Utilizando ou não a Wiki, usem esse modelo de relatório. Um exemplo de bom relatório gerado [2].
- Grupos e Temas para 2016-2:
- Lucas da Silva e Douglas Amorim: NAT. Apresentação 8/12.
- Schaiana Sonaglio e Vinícius da Luz Souza: Redes MPLS. Apresentação 13/12.
- Allex e Yara: Voip. Apresentação 13/12.
- Anderson e Joseane: RFID. Apresentação 8/12.
- Nelito: QoS. Apresentação 13/12.
- Gabriel Farias Turnes e Rafael Teles: Grampos VoIP. Apresentação 8/12.
- Aldebarã e Wagner: Comparativo entre as tecnologias Zigbee e LoRA. Apresentação 13/12.
- Avaliação
- Avaliação dos relatórios e seminários
- Nota: 0,5 x Documento + 0,5 x Seminário
- Critérios de avaliação
- Instruções sobre o Seminário de Redes I:
- Data para definição de grupos e temas: 27/10/2016.
- 2 alunos por equipe.
- Os temas devem ser propostos pelas equipes em comum acordo com o professor ou então na data limite o professor apresenta alguns temas e as equipes escolhem.
- Data de entrega do documento: 29/11/2016 (impreterivelmente).
- O relatório pode ser redigido como uma página da wiki.
- Duração da apresentação: 20 minutos (limitantes: 15 a 25 minutos) + 5 minutos de perguntas.
- As apresentações podem ser realizadas seguindo o conteúdo do relatório (use bastante figuras no relatório, isto facilita a apresentação).
- Se preferirem usar slides, usem esse modelo.
Diário de aulas
Aula 1 - 11/08/2016: Apresentação da disciplina |
---|
|
Aula 2 - 16/08/2016: Aula suspensa devido a participação no Treinamento em Tecnologia FPGA Altera.
Aula 3 - 18/08/2016: Aula suspensa devido a participação no Treinamento em Tecnologia FPGA Altera.
Aula 4 - 23/08/16: Redes de Computadores e a Internet
Aula 5 - 25/08/16: Redes de Computadores e a Internet e Visita ao PoP São José da RNP
Aula 6 - 30/08/16: Laboratório 1: Ping, Traceroute e Wireshark
Aula 7 - 01/09/16: Redes de Computadores e a Internet e Camada de Aplicação
Aula 8 - 06/09/16: Camada de Aplicação
Aula 9 - 08/09/16: Laboratório 2: Desvendando o HTTP com Wireshark
Aula 10 - 13/09/16: Camada de Aplicação
Aula 11 - 15/09/16: Laboratório 3: Serviço de Nomes (DNS)
Aula 12 - 20/09/16: Camada de Aplicação e dúvidas para a primeira avaliação.
Aula 13 - 22/09/16: Primeira avaliação
Aula 14 - 27/09/16: Camada de Transporte
Aula 15 - 29/09/16: Laboratório 4: Entendendo sockets
Aula 16 - 04/10/16: Camada de Transporte
Aula 17 - 06/10/16: Camada de Transporte
Aula 18 - 11/10/16: Laboratório 5: TCP x UDP
Aula 19 - 13/10/16: Finalização da camada de Transporte e Camada de Rede
Aula 20 - 18/10/16: Camada de Rede
Aula 21 - 20/10/16: Camada de Rede
Aula 22 - 25/10/16: Camada de Rede e Dúvidas para segunda avaliação.
Aula 23 - 27/10/16: Segunda avaliação
Aula 24 - 01/11/16: Camada de Rede
Aula 25 - 03/11/16: Camada de Rede
Aula 26 - 08/11/16: Camada de Rede
Aula 27 - 10/11/16: Laboratório 6: Protocolos de Roteamento.
Aula 28 - 17/11/16: Laboratório 7: Protocolos de Roteamento (cont.).
Aula 29 - 22/11/16: IPv6.
Aula 30 - 24/11/16: Camada de Rede
Aula 31 - 29/11/16: Laboratório 8: Neighbor Discovery no IPv6.
Aula 32 - 01/12/16: Dúvidas para terceira avaliação.
Aula 33 - 06/12/16: Terceira avaliação.
Aula 34 - 08/12/16: Aplicação e protocolos para sinalização/comunicação multimídia (SIP e RTP) e Introdução à camada de enlace.
Aula 35 - 13/12/16: Apresentação de seminários.
Aula 36 - 15/12/16: Apresentação de seminários.
Aula 37 - 20/12/16: Reavaliação final.