Mudanças entre as edições de "RED29004-2015-2"
(→ping) |
|||
(88 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
Linha 1: | Linha 1: | ||
=Diário de aula de RED - 2015-2 - Prof. Odilson T. Valle= | =Diário de aula de RED - 2015-2 - Prof. Odilson T. Valle= | ||
+ | |||
+ | ==Conceitos Finais== | ||
+ | [http://docente.ifsc.edu.br/odilson/RED29004/DIARIO%202015-2%20RED29004.pdf Conceitos Finais] | ||
==Dados Importantes== | ==Dados Importantes== | ||
''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 5ª das 9h40 às 10h35. Local: Lab. de Desenvolvimento. |
* Avaliações | * Avaliações | ||
** 3 avaliações (P1, P2 e P3) mais um seminário (S). | ** 3 avaliações (P1, P2 e P3) mais um seminário (S). | ||
− | ** Cada uma das avaliações terá terá um conceito | + | ** Cada uma das avaliações terá terá um conceito: A, B, C e D. Conceito mínimo para não necessitar reavaliação: C. |
− | ** | + | ** 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. | '''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. | ||
==[[RED1-EngTel_(Plano_de_Ensino)|Plano de Ensino]]== | ==[[RED1-EngTel_(Plano_de_Ensino)|Plano de Ensino]]== | ||
+ | |||
+ | ==Cronograma de Atividades== | ||
+ | |||
+ | [[Cronograma_de_atividades_(RED1-EngTel)|RED29004 2015-2 - Prof. Odilson T. Valle]] | ||
= Material de apoio = | = Material de apoio = | ||
Linha 42: | Linha 49: | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top |Lista de exercícios 2 - Camada de Aplicação}} | + | {{Collapse top |Lista de exercícios 2 - Camada de Aplicação e Redes Multimídia}} |
#Relacione cinco aplicações da Internet não proprietárias e os protocolos da camada de aplicação que elas usam. | #Relacione cinco aplicações da Internet não proprietárias e os protocolos da camada de aplicação que elas usam. | ||
#Qual é a diferença entre arquitetura de rede e arquitetura de aplicação? | #Qual é a diferença entre arquitetura de rede e arquitetura de aplicação? | ||
Linha 59: | Linha 66: | ||
#O que significa o protocolo de apresentação (handshaking protocol)? | #O que significa o protocolo de apresentação (handshaking protocol)? | ||
#Considere um site de comércio eletrônico que quer manter um registro de compras para cada um de seus clientes. Descreva como isso pode ser feito com cookies. | #Considere um site de comércio eletrônico que quer manter um registro de compras para cada um de seus clientes. Descreva como isso pode ser feito com cookies. | ||
− | #Imagine uma aplicação que requeira “não perda de dados” e seja também altamente sensível ao atraso. | + | #Imagine uma aplicação que requeira “não perda de dados” e seja também altamente sensível ao atraso. |
+ | #Suponha que João esteja assistindo um vídeo de 3 Mbits/s, Maria esteja vendo uma nova imagem de 100 Kbytes a cada 30 segundos e José esteja ouvindo um fluxo de áudio a 200 kbits/s. Sabendo que o tempo de sessão para todos os usuários seja de 1000 segundos. Monte uma tabela comparativa contento a taxa de bits e o total de bytes transferidos para esses três usuários. Qual fluxo consome mais banda? | ||
+ | #Existem dois tipos de redundâncias de vídeo (lembre da foto do professor na Suiça, em frente ao quadro :) ). Discuta como eles podem ser explorados para compressão eficiente. | ||
+ | #Aplicações de multimídia podem ser classificados em três categorias. Relacione e descreva cada uma dessas categorias. | ||
+ | #CDNs geralmente adotam uma de duas filosofias de posicionamento de servidor diferentes. Relacione e descreva resumidamente essas duas filosofias. | ||
+ | #Qual a diferença de atraso fim a fim e variação de atraso de pacote? Quais os fatores causadores de um e outro? | ||
+ | #Por que um pacote recebido após seu tempo de reprodução programado é considerado perdido? | ||
+ | #Faça um pequeno resumo de ambos os esquemas de FEC. | ||
+ | #Como os diferentes fluxos RTP são identificados por um receptor? Como os diferentes fluxos internos a uma sessão são identificados? | ||
+ | #Qual é o papel de um registro SIP? | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
Linha 202: | Linha 218: | ||
== Transparências utilizadas durante as aulas == | == Transparências utilizadas durante as aulas == | ||
− | [http:// | + | [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%201%20Redes%20de%20computadores%20e%20a%20Internet.pdf Slides do Kurose referentes ao capítulo 1] |
− | [http:// | + | [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%202%20Camada%20de%20aplica%C3%A7%C3%A3o.pdf Slides do Kurose referentes ao capítulo 2] |
− | [http:// | + | [http://docente.ifsc.edu.br/odilson/RED29004/Aplicacoes.pdf Slides do Prof. Emerson - DNS, FTP, Web, Email...] |
− | [http:// | + | [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%207%20Redes%20multim%C3%ADdia.pdf Slides do Kurose referentes ao capítulo 7] |
− | [http:// | + | [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%203%20Camada%20de%20transporte.pdf Slides do Kurose referentes ao capítulo 3] e [http://docente.ifsc.edu.br/odilson/RED29004/Kurose_cap03.pdf versão antiga] |
− | [http:// | + | [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-3.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] | ||
== Roteiros para laboratório == | == Roteiros para laboratório == | ||
− | |||
− | |||
{{Collapse top |Laboratório 1 - Ping, Traceroute e Wireshark}} | {{Collapse top |Laboratório 1 - Ping, Traceroute e Wireshark}} | ||
===Objetivos=== | ===Objetivos=== | ||
+ | *Familiarização com a infraestrutura dos laboratórios de redes | ||
*Conhecer aplicativos para verificar os parâmetros do TCP/IP | *Conhecer aplicativos para verificar os parâmetros do TCP/IP | ||
*Diagnosticar o atraso dos pacotes | *Diagnosticar o atraso dos pacotes | ||
Linha 228: | Linha 247: | ||
A rede do laboratório em uso segue o modelo apresentado no diagrama da Figura 1. | A rede do laboratório em uso segue o modelo apresentado no diagrama da Figura 1. | ||
− | [[Arquivo:Diagrama_rede_IFSC_lab_redes_I.jpeg |thumb | | + | [[Arquivo:Diagrama_rede_IFSC_lab_redes_I.jpeg |thumb | 400px| Figura 1 - Diagrama da rede do laboratório]] |
====Máquinas virtuais==== | ====Máquinas virtuais==== | ||
Linha 313: | Linha 332: | ||
##-t ttl (para um site distante inicie com 1 e vá incrementando, observe as mensagens) | ##-t ttl (para um site distante inicie com 1 e vá incrementando, observe as mensagens) | ||
##-b (Se desejarmos descobrir o endereço IP de vários ''hosts'' em uma rede local, poderemos utilizar o '''ping''' no endereço de ''broadcast'') | ##-b (Se desejarmos descobrir o endereço IP de vários ''hosts'' em uma rede local, poderemos utilizar o '''ping''' no endereço de ''broadcast'') | ||
− | *No Ubuntu a resposta a um ping no endereço de broadcast é desabilitada por padrão e somente o administrador pode habilitar esta funcionalidade. Para testar, vamos habilitar a resposta a um '''ping''' no endereço de ''broadcast'' em uma máquina virtual Ubuntu. Para tal, | + | #*No Ubuntu a resposta a um ping no endereço de broadcast é desabilitada por padrão e somente o administrador pode habilitar esta funcionalidade. Para testar, vamos habilitar a resposta a um '''ping''' no endereço de ''broadcast'' em uma máquina virtual Ubuntu. Para tal, primeiro iniciamos uma máquina virtual, logamos como aluno/aluno e depois executamos em um terminal os comandos abaixo<code> |
sudo su | sudo su | ||
echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts </syntaxhighlight> em seguida esta máquina responderá a '''ping''' no ''broadcast''. | echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts </syntaxhighlight> em seguida esta máquina responderá a '''ping''' no ''broadcast''. | ||
Linha 319: | Linha 338: | ||
====traceroute==== | ====traceroute==== | ||
− | Somente o usuário root pode executar o aplicativo '''traceroute'''. Caso o aplicativo não esteja instalado, | + | Somente o usuário root pode executar o aplicativo '''traceroute'''. Caso o aplicativo não esteja instalado, instalar no Linux Ubuntu de uma máquina virtual, como root, com o comando: <code> |
+ | apt-get update | ||
+ | apt-get install traceroute </syntaxhighlight> | ||
O '''traceroute''' é capaz de traçar uma rota aproximada entre dois ''hosts''. Este comando usa mensagens ICMP. Para determinar o nome e o endereço dos roteadores entre a fonte e o destino, o traceroute na fonte envia uma série de datagramas IP ordinários ao destino. O primeiro datagrama tem o TTL (''time to live'' – tempo de vida) igual a 1, o segundo 2, o terceiro 3, e assim por diante, e inicia temporizadores para cada datagrama. Quando o enésimo datagrama chega ao enésimo roteador, este verifica que o tempo de sobrevida do datagrama acaba de terminar. Pelas regras do IP, o datagrama é então descartado e uma mensagem ICMP de advertência tempo de vida excedido é enviada a fonte com o nome do roteador e seu endereço IP. Quando a resposta chega de volta a fonte, a mesma calcula o tempo de viagem em função dos temporizadores. | O '''traceroute''' é capaz de traçar uma rota aproximada entre dois ''hosts''. Este comando usa mensagens ICMP. Para determinar o nome e o endereço dos roteadores entre a fonte e o destino, o traceroute na fonte envia uma série de datagramas IP ordinários ao destino. O primeiro datagrama tem o TTL (''time to live'' – tempo de vida) igual a 1, o segundo 2, o terceiro 3, e assim por diante, e inicia temporizadores para cada datagrama. Quando o enésimo datagrama chega ao enésimo roteador, este verifica que o tempo de sobrevida do datagrama acaba de terminar. Pelas regras do IP, o datagrama é então descartado e uma mensagem ICMP de advertência tempo de vida excedido é enviada a fonte com o nome do roteador e seu endereço IP. Quando a resposta chega de volta a fonte, a mesma calcula o tempo de viagem em função dos temporizadores. | ||
Linha 337: | Linha 358: | ||
#Explique as possíveis diferenças entre os tempos de resposta de cada uma das amostras do '''traceroute''' | #Explique as possíveis diferenças entre os tempos de resposta de cada uma das amostras do '''traceroute''' | ||
#Explique as linhas com o caracter *. | #Explique as linhas com o caracter *. | ||
+ | |||
+ | ====WireShark==== | ||
+ | 2005 KUROSE, J.F & ROSS, K. W. Todos os direitos reservados | ||
+ | |||
+ | *Introdução | ||
+ | O entendimento de protocolos de redes pode ser bastante aprofundado através da “observação de protocolos funcionando” e “da manipulação de protocolos” - observando a sequência de mensagens trocadas entre duas entidades, entrando nos detalhes da operação do protocolo, e fazendo com que os protocolos realizem certas ações e então observando estas ações e as consequências. | ||
+ | |||
+ | A ferramenta básica para observar as mensagens trocadas entre as entidades em execução é chamada de ''sniffer''. Como o nome sugere, um ''sniffer'' captura mensagens sendo enviadas/recebidas pelo seu computador; ele também tipicamente armazena e/ou apresenta os conteúdos dos vários campos dos protocolos nestas mensagens capturadas. Um ''sniffer'' isoladamente é um elemento passivo. Ele observa as mensagens sendo enviadas e recebidas pelas aplicações e protocolos executando no seu computador, mas jamais envia pacotes. Similarmente, os pacotes recebidos nunca são explicitamente endereçados ao ''sniffer''. Ao invés disso, um ''sniffer'' recebe uma cópia de pacotes que são enviados/recebidos para/de aplicações e protocolos executando no seu computador. | ||
+ | |||
+ | A Figura 2 mostra a estrutura de um ''sniffer''. À direita da Figura 2 estão os protocolos (neste caso, protocolos da Internet) e aplicações (tais como navegador web ou cliente FTP) que normalmente executam no seu computador. O ''sniffer'', exibido dentro do retângulo tracejado na Figura 1 é uma adição aos softwares usuais no seu computador, e consiste de duas partes: a biblioteca de captura de pacotes e o analisador de pacotes. A biblioteca de captura de pacotes recebe uma cópia de cada quadro da camada de enlace que é enviado do ou recebido pelo seu computador. Lembre que mensagens trocadas por protocolos das camadas mais altas tais como HTTP, FTP, TCP, UDP, DNS ou IP, são todos eventualmente encapsulados em quadros que são transmitidos para o meio físico como um cabo Ethernet. Na Figura 1, assume-se que o meio físico é uma Ethernet, e desta forma, os protocolos das camadas superiores são eventualmente encapsulados em um quadro Ethernet. Capturar todos os quadros fornece todas as mensagens enviadas/recebidas de/ por todos os protocolos e aplicações executando em seu computador. | ||
+ | |||
+ | [[Arquivo:Sniffer_estrutura.png |thumb | 500px| Figura 2 - Estrutura de um ''sniffer'']] | ||
+ | |||
+ | O analisador de pacotes exibe os conteúdos de todos os campos dentro de uma mensagem de protocolo. Para que isso seja feito, o analisador de pacotes deve “entender” a estrutura de todas as mensagens trocadas pelos protocolos. Por exemplo, suponha que estamos interessados em mostrar os vários campos nas mensagens trocadas pelo protocolo HTTP na Figura 1. O analisador de pacotes entende o formato dos quadros Ethernet, e desta forma pode identificar o datagrama IP dentro de um quadro. Ele também entende o formato do datagrama IP, para que ele possa extrair o segmento TCP dentro do datagrama IP. Ele entende a estrutura do segmento TCP, para que possa extrair a mensagem HTTP contida no segmento. Finalmente, ele entende o protocolo HTTP e então, por exemplo, sabe que os primeiros bytes de uma mensagem HTTP contém a cadeia “GET”, “POST” ou “HEAD”. Nós utilizaremos o ''sniffer'' Wireshark (http://www.wireshark.org) para estes laboratórios, o que nos permite exibir os conteúdos das mensagens sendo enviadas/recebidas de/por protocolos em diferentes camadas da pilha de protocolos. Tecnicamente falando, Wireshark é um analisador de pacotes que pode ser executado em computadores com Windows, Linux/UNIX e MAC. | ||
+ | |||
+ | É um analisador de pacotes ideal para nossos laboratórios, pois é estável, tem uma grande base de usuários e é bem documentado incluindo um guia de usuário (http://www.wireshark.org/docs/wsug_html/), páginas de manual (http://www.wireshark.org/docs/man-pages/), e uma seção de FAQ detalhada (http://www.wireshark.org/faq.html), funcionalidade rica que inclui a capacidade de analisar mais que 500 protocolos, e uma interface com o usuário bem projetada. Ele funciona em computadores ligados a uma Ethernet para conectar-se à Internet, bem como protocolos ponto a ponto, tal como PPP. | ||
+ | |||
+ | *Analisando os campos da interface do Wireshark | ||
+ | Quando você executar o programa Wireshark, a interface com o usuário exibida na Figura 3 aparecerá. Inicialmente, nenhum dado será apresentado nas janelas. A interface do Wireshark tem seis componentes principais: | ||
+ | #Os menus de comandos são localizados no topo da janela. Por enquanto, interessam apenas os menus ''File'' e ''Capture''. O menu ''File'' permite salvar dados de capturas de pacotes ou abrir um arquivo contendo dados de capturas de pacotes previamente realizadas, e sair da aplicação. O menu ''Capture'' permite iniciar uma captura de pacotes; | ||
+ | #A barra de ferramentas contém os comandos de menu que são mais frequentemente utilizados. Há atalhos para abrir ou salvar dados de captura de pacotes e para iniciar ou parar uma captura de pacotes; | ||
+ | #Abaixo da barra de ferramentas, está o campo de filtragem de pacotes exibidos. Nele podem ser digitados nome de protocolo ou outra informação apresentada na janela de listagem de pacotes. Apenas os pacotes que correspondem ao filtro são exibidos; | ||
+ | #A janela de listagem de pacotes apresenta um resumo de uma linha para cada pacote capturado, incluindo o número do pacote (atribuído pelo Wireshark; este não é o número do pacote contido no cabeçalho de qualquer protocolo), o tempo que o pacote foi capturado, os endereços fonte e destino do pacote, o tipo de protocolo, e informação específica do protocolo contida no pacote. A lista de pacotes pode ser ordenada conforme qualquer uma destas categorias clicando no nome de uma coluna correspondente. O campo tipo do protocolo lista o protocolo de mais alto nível que enviou ou recebeu este pacote, i.e., o protocolo que é a fonte ou o último sorvedouro para este pacote; | ||
+ | #A janela de detalhes de cabeçalho de pacotes fornece detalhes sobre o pacote selecionado na janela de listagem de pacotes. Para selecionar um pacote, basta clicar sobre ele com o botão esquerdo do mouse na janela de listagem de pacotes. Os detalhes apresentados incluem informações sobre o quadro Ethernet e o datagrama IP que contém o pacote. A quantidade de detalhes exibida pode ser expandida ou contraída. Se o pacote foi carregado sobre TCP ou UDP, detalhes correspondentes também são apresentados, os quais também podem ser contraídos ou expandidos. Finalmente, detalhes sobre o protocolo de mais alto nível que enviou ou recebeu este pacote também são apresentados; | ||
+ | #A janela de conteúdo de pacotes mostra o conteúdo inteiro do quadro capturado, nos formatos ASCII e hexadecimal. | ||
+ | |||
+ | [[Arquivo:Wireshark_interface_usuario.png |thumb | 700px| Figura 3 - Interface com o usuário do Wireshark]] | ||
+ | |||
+ | *Roteiro de atividades | ||
+ | #Inicie o navegador web; | ||
+ | #Inicie o Wireshark. Inicialmente as janelas estarão vazias, pois não há captura de pacotes em progresso; | ||
+ | #Para iniciar uma captura de pacotes, selecione o menu Capture e depois Interfaces. | ||
+ | #Isso faz com que a janela de interfaces de rede disponíveis seja apresentada (Figura 4); [[Arquivo:Wireshark_interfaces_rede.png |thumb | 400px| Figura 4 - Interfaces de rede no Wireshark]] | ||
+ | #Basta clicar no botão ''Start'' da interface desejada para iniciar a captura de pacotes. Na Figura 4, como o Wireshark está sendo executado no Linux, o botão Start da interface eth0 deve ser selecionado; | ||
+ | #Como nada está acontecendo na rede, a janela apresenta o conteúdo vazio; | ||
+ | #No navegador, acesse o site http://www.ifsc.edu.br; | ||
+ | #Ao voltar para a janela do Wireshark, houve a captura de todos os pacotes envolvidos na conexão; | ||
+ | #Antes de continuar, vamos parar a captura de pacotes e trabalhar com o que temos. Basta clicar em ''Capture'' e depois em ''Stop''; | ||
+ | #Para testar as capacidades de filtragem, vamos inserir a cadeia “http” (sem as aspas e em minúsculo) no especificação do filtro de exibição e depois selecionar ''Apply'' (ou Aplicar). Um resultado similar é exibido na figura 5; [[Arquivo:Wireshark_filtro_HTTP.png |thumb | 600px| Figura 5 - Janela após a aplicação do filtro http]] | ||
+ | #Selecione a primeira mensagem HTTP exibida na janela de listagem de pacotes. Ela deve ser a mensagem HTTP GET que foi enviada do seu computador ao servidor HTTP em www.ifsc.edu.br. Quando você seleciona a mensagem HTTP GET, as informações dos cabeçalhos do quadro Ethernet, do datagrama IP, do segmento TCP e da mensagem HTTP aparecem na janela de cabeçalhos de pacotes. É possível ver os detalhes, expandido ou comprimindo os itens com um clique na seta ao lado deles. | ||
+ | #Se desejar acesse novos sítios e faça novas capturas e tente entender o que ocorre; | ||
+ | #Saia do Wireshark. | ||
+ | #Com Wireshark ativo acesse um sítio e responda às seguintes questões: | ||
+ | ##Teste outros filtros, por exemplo, mostre somente pacotes originados e/ou destinados a um determinado ''host''. Anote o filtro utilizado e salve a janela do mesmo. | ||
+ | ##Liste os diferentes protocolos que aparecem na coluna ''Protocol'' na janela de listagem de pacotes; | ||
+ | ##Quanto tempo passa entre o envio de uma mensagem HTTP GET até o recebimento de uma resposta OK? (por padrão, o valor da coluna Time na janela de listagem de pacotes é a quantidade de tempo, em segundos, desde que a captura iniciou). Para exibir o campo Time no formato hora do dia, selecione o menu ''View'', depois ''Time Display Format'', então selecione ''Time of day''. | ||
+ | ##Qual é o endereço IP do sítio navegado? Qual é o endereço IP da interface de rede do seu computador? Qual o endereço MAC de sua máquina? | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
Linha 351: | Linha 419: | ||
Vamos 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: | Vamos 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: | ||
#inicie o navegador; | #inicie o navegador; | ||
+ | #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). Digite “http.request or http.response” (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); | #inicie o Wireshark, como descrito no '''Laboratório 1''' (mas não inicie a captura de pacotes ainda). Digite “http.request or http.response” (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); | ||
#inicie a captura de pacotes | #inicie a captura de pacotes | ||
Linha 376: | Linha 445: | ||
#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? | ||
#Quantos bytes de conteúdo são baixados pelo seu navegador? | #Quantos bytes de conteúdo são baixados pelo seu navegador? | ||
− | |||
− | |||
#Qual a diferença entre os endereços (IP, porta, MAC) de origem e destino entre a mensagem GET e a de resposta do HTTP? | #Qual a diferença entre os endereços (IP, porta, MAC) de origem e destino entre a mensagem GET e a de resposta do HTTP? | ||
− | |||
===A Interação HTTP GET Condicional/Resposta=== | ===A Interação HTTP GET Condicional/Resposta=== | ||
Linha 385: | Linha 451: | ||
A 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: | A 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: | ||
#inicie o navegador web; | #inicie o navegador web; | ||
− | #limpe o cache do seu navegador; | + | #limpe o cache do seu navegador. Outra maneira de forçar o download do objeto quando desejado, é utilizar as teclas de atalho '''Ctrl + Shift + R''' no Firefox; |
#inicie o Wireshark; | #inicie o Wireshark; | ||
#digite o URL no navegador http://www.sj.ifsc.edu.br/~odilson/RED29004/RED29004.html seu navegador deve exibir um arquivo em HTML muito simples com duas linhas; | #digite o URL no navegador http://www.sj.ifsc.edu.br/~odilson/RED29004/RED29004.html seu navegador deve exibir um arquivo em HTML muito simples com duas linhas; | ||
Linha 406: | Linha 472: | ||
#inicie o Wireshark; | #inicie o Wireshark; | ||
#digite o URL no navegador http://www.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq2.html seu navegador deve exibir um documento bastante longo e criativo :) ; | #digite o URL no navegador http://www.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); | ||
#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 465: | Linha 532: | ||
{{Collapse top |Laboratório 3 - Serviço de Nomes (DNS)}} | {{Collapse top |Laboratório 3 - Serviço de Nomes (DNS)}} | ||
− | O 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 de mais perto inicialmente o lado cliente do DNS, uma pequena análise do protocolo e | + | |
+ | ===Objetivos=== | ||
+ | O 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 de mais perto: | ||
+ | #inicialmente o lado cliente do DNS, | ||
+ | #uma pequena análise do protocolo e | ||
+ | #uma breve introdução ao servidor DNS. | ||
+ | |||
+ | 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=== | ===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 | + | # 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): |
#* mail.ifsc.edu.br | #* mail.ifsc.edu.br | ||
− | |||
#* www.google.com | #* www.google.com | ||
#* www.gmail.com | #* www.gmail.com | ||
Linha 476: | Linha 549: | ||
#* www.gov.za | #* www.gov.za | ||
#* www.sls.com.au | #* www.sls.com.au | ||
− | # Agora descubra quem é o servidor DNS responsável por cada um dos domínios dos nomes acima. Para isso consulte o valor do registro NS associado a esses domínios. Por exemplo, com o programa ''host'' isso pode ser feito assim: <syntaxhighlight lang=bash> | + | # Agora descubra quem é o servidor DNS responsável por cada um dos domínios dos nomes acima. Para isso consulte o valor do registro NS associado a esses domínios. Por exemplo, com o programa ''host'' ou ''dig'' isso pode ser feito assim: <syntaxhighlight lang=bash> |
host -t ns ifsc.edu.br | host -t ns ifsc.edu.br | ||
dig -t ns ifsc.edu.br | dig -t ns ifsc.edu.br | ||
Linha 485: | Linha 558: | ||
nm-tool | tail -n 8 | nm-tool | tail -n 8 | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | # O serviço DNS fornece outras informações além do endereço IP associado a cada nome de domínio e/ou máquina. Por exemplo, como ele pode-se descobrir que ''host'' recebe emails em um determinado domínio. Isso é utilizado pelos MTA (''Mail Transfer Agent'') mundo afora para entregarem emails para seus destinatários (lembre que isso se faz com o protocolo SMTP). Para descobrir essa informação, deve-se consultar o registro MX (''Mail eXchange'') de um domínio. | + | # O serviço DNS fornece outras informações além do endereço IP associado a cada nome de domínio e/ou máquina. Por exemplo, como ele pode-se descobrir que ''host'' recebe emails em um determinado domínio. Isso é utilizado pelos MTA (''Mail Transfer Agent'') mundo afora para entregarem emails para seus destinatários (lembre que isso se faz com o protocolo SMTP). Para descobrir essa informação, deve-se consultar o registro MX (''Mail eXchange'') de um domínio. Novamente as ferramentas a ser utilizada nesse caso podem ser ''host'' ou ''dig''. Por exemplo: <syntaxhighlight lang=bash> |
host -t mx ifsc.edu.br | host -t mx ifsc.edu.br | ||
dig -t mx ifsc.edu.br | dig -t mx ifsc.edu.br | ||
Linha 491: | Linha 564: | ||
#* gmail.com | #* gmail.com | ||
#* hotmail.com | #* hotmail.com | ||
− | |||
#* ufsc.br | #* ufsc.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> | ||
Linha 508: | Linha 580: | ||
## Continue fazendo as consultas aos servidores DNS listados, até conseguir traduzir o nome requisitado. Por exemplo: <code> | ## Continue fazendo as consultas aos servidores DNS listados, até conseguir traduzir o nome requisitado. Por exemplo: <code> | ||
host -v -t a www.sj.ifsc.edu.br. b.dns.br </syntaxhighlight> | host -v -t a www.sj.ifsc.edu.br. b.dns.br </syntaxhighlight> | ||
− | ## Quantos servidores DNS | + | ## Quantos servidores DNS foram necessários consultar no total? |
− | ## Repita esse exercício para os seguintes nomes de | + | ## Repita esse exercício para os seguintes nomes de hosts: |
##* www.bbc.co.uk | ##* www.bbc.co.uk | ||
− | |||
− | |||
##* www.reeec.illinois.edu | ##* www.reeec.illinois.edu | ||
##* www.inm.ras.ru | ##* www.inm.ras.ru | ||
Linha 810: | Linha 880: | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top |Laboratório 4 - | + | {{Collapse top |Laboratório 4 - Entendendo ''sockets''}} |
− | + | ===Objetivos=== | |
+ | Entender 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. | 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. | ||
Linha 935: | Linha 1 006: | ||
===Roteiro de atividades=== | ===Roteiro de atividades=== | ||
− | #Ligue a máquina virtual | + | #Ligue a máquina virtual determinada pelo professor |
#Logue com: aluno - aluno | #Logue com: aluno - aluno | ||
#Configure sua interface de rede com IP estático, removendo o cliente dhcp. Y é obtido pelo número da etiqueta de sua máquina: D2 ==> '''Y = 02''', D3 ==> '''Y = 03''', ..., D9 ==> '''Y = 09''', E1 ==> '''Y = 11''', E2 ==> '''Y = 12''', ..., E8 ==> '''Y = 18''': <code> | #Configure sua interface de rede com IP estático, removendo o cliente dhcp. Y é obtido pelo número da etiqueta de sua máquina: D2 ==> '''Y = 02''', D3 ==> '''Y = 03''', ..., D9 ==> '''Y = 09''', E1 ==> '''Y = 11''', E2 ==> '''Y = 12''', ..., E8 ==> '''Y = 18''': <code> | ||
Linha 949: | Linha 1 020: | ||
#Abra um terminal da máquina real e escreva o programa UDPClient.py. Não se esqueça de adequar o endereço IP. Execute-o. | #Abra um terminal da máquina real e escreva o programa UDPClient.py. Não se esqueça de adequar o endereço IP. Execute-o. | ||
#Sucesso na execução do programa? | #Sucesso na execução do programa? | ||
− | #Rode o WireShark | + | #Rode o WireShark. |
#Execute novamente o cliente e servidor 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. É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor? | #Execute novamente o cliente e servidor 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. É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor? | ||
#Repita os passos 4 a 10, só que agora para o protocolo TCP. | #Repita os passos 4 a 10, só que agora para o protocolo TCP. | ||
Linha 964: | Linha 1 035: | ||
{{Collapse top |Laboratório 5 - TCP x UDP}} | {{Collapse top |Laboratório 5 - TCP x UDP}} | ||
+ | ===Objetivos=== | ||
O objetivo desses experimentos é evidenciar as diferenças entre os protocolos TCP e UDP. | O 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 1 ==== | ==== Experimento 1 ==== | ||
− | + | O que aconteceria se um arquivo fosse transferido de um computador a outro com ambos protocolos? | |
# 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> | ||
Linha 994: | Linha 1 068: | ||
./transmissor ip_do_receptor 5555 < ubuntu.iso | ./transmissor ip_do_receptor 5555 < ubuntu.iso | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | #* Quando completar a transferência, 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? |
# 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? | # 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? | ||
Linha 1 001: | Linha 1 075: | ||
Transferências usando cada um desses protocolos podem apresentar características bem distintas. Neste segundo 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. | Transferências usando cada um desses protocolos podem apresentar características bem distintas. Neste segundo 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: <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> |
wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/arq2.iso | wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/arq2.iso | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Linha 1 033: | Linha 1 107: | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top | | + | {{Collapse top |Laboratórios 6 e 7 - Protocolos de roteamento}} |
− | + | ===Objetivos=== | |
+ | Analisar 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 [[ | + | Para atingir tais objetivos utilizaremos o [[netkit2]]. Leia o [http://wiki.sj.ifsc.edu.br/index.php/Netkit2#Roteadores tutorial] de como o '''netkit2''' trabalha com roteadores. |
Em todos os experimentos será utilizado como base a seguinte arquitetura de rede: | Em todos os experimentos será utilizado como base a seguinte arquitetura de rede: | ||
Linha 1 076: | Linha 1 151: | ||
r3[eth1]=backbone1:ip=10.0.1.2/30 | r3[eth1]=backbone1:ip=10.0.1.2/30 | ||
r3[eth2]=backbone2:ip=10.0.2.2/30 </syntaxhighlight> | r3[eth2]=backbone2:ip=10.0.2.2/30 </syntaxhighlight> | ||
− | #Rode o | + | #Rode o '''netKit''' em seu computador. Em um terminal digite: <code> netkit2 & </syntaxhighlight> |
#No menu '''File - Load and Run''', procure o arquivo '''/home/aluno/exp1.conf''' e clique em OK. Abrirá uma janela com 6 abas, onde cada uma delas é um terminal de configuração do respectivo equipamento: PC1-3 ou R1-3. | #No menu '''File - Load and Run''', procure o arquivo '''/home/aluno/exp1.conf''' e clique em OK. Abrirá uma janela com 6 abas, onde cada uma delas é um terminal de configuração do respectivo equipamento: PC1-3 ou R1-3. | ||
#Ao clicar no menu '''File - Graph''', pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto. | #Ao clicar no menu '''File - Graph''', pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto. | ||
Linha 1 085: | Linha 1 160: | ||
##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'''). Qual a origem e destino dos pacotes? Por quê? Qual a diferença no ping entre os dois itens? | + | ##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'''). Qual a origem e destino dos pacotes? Por quê? Qual a diferença no ping entre os dois itens? Obs: Uma opção ao '''wireshark''' é o [http://www.tcpdump.org/ tcpdump] que permite que se grave todo o tráfego de pacotes para posterior análise, sem influenciar no funcionamento dos experimentos. O arquivo gravado é compatível com o '''wireshark''', ou seja, pode-se abrir um arquivo gravado com o '''tcpdump''' no '''wireshark'''. Por exemplo, para iniciar a captura de pacotes em todas as interfaces de '''r1''', utilize o seguinte comando (atenção ao "&" no final que envia o '''tcpdump''' para ''background'', permitindo o uso normal do terminal): <code> tcpdump -i any -w /hostlab/r1.pcap & </syntaxhighlight> Ao final do experimento use o comando '''fg tcpdump''' para trazer o '''tcpdump''' para o primeiro plano. Em seguida encerre a captura com '''Ctrl + C'''. Os arquivos '''.pcaps''' gerados ficam na pasta /home/aluno/lab, no exemplo '''r1.pcap'''. Ao clicar sobre o mesmo, automaticamente será aberto o '''wireshark'''. |
#Iniciando o roteamento | #Iniciando o roteamento | ||
− | ##Deixe o '''ping''' do item 5.3 e o ''wireshark'' 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! | ##Em todos os roteadores crie rotas para todas as redes. Se tudo estiver correto, todos os PCs devem pingar entre si. Teste! | ||
− | #Testando a queda de | + | #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 1 262: | Linha 1 337: | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top |Laboratório | + | {{Collapse top |Laboratório 8 - IPv6}} |
Este roteiro foi baseado no material disponível em [http://www.paulogurgel.com.br/]. | Este roteiro foi baseado no material disponível em [http://www.paulogurgel.com.br/]. | ||
Linha 1 268: | Linha 1 343: | ||
[http://www.sj.ifsc.edu.br/~odilson/RED29004/enderec-v6.pdf Guia didático de endereçamento IPv6] obtido de http://ipv6.br/. | [http://www.sj.ifsc.edu.br/~odilson/RED29004/enderec-v6.pdf Guia didático de endereçamento IPv6] obtido de http://ipv6.br/. | ||
+ | |||
+ | ===Objetivos do laboratório:=== | ||
+ | *Um primeiro contato com o protocolo [https://pt.wikipedia.org/wiki/IPv6 IPv6] | ||
+ | *Compreender o funcionando do ''Neighbor Discovery'', o equivalente ao ARP (''Address Resolution Protocol'') do IPv4, que em resumo é uma tabela contendo a relação ente IPs e MACs. | ||
+ | *Aprender configurações básicas de interfaces IPv6 no Linux | ||
+ | *Aprender configurações básicas de rotas IPv6 | ||
===Introdução teórica=== | ===Introdução teórica=== | ||
Linha 1 304: | Linha 1 385: | ||
registrado o ''status'' de cada destino, informando se o mesmo é alcançável | registrado o ''status'' de cada destino, informando se o mesmo é alcançável | ||
ou não. | ou não. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
===Roteiro de atividades:=== | ===Roteiro de atividades:=== | ||
Linha 1 355: | Linha 1 430: | ||
r2[mem]=64 </syntaxhighlight> | r2[mem]=64 </syntaxhighlight> | ||
#Rode o NetKit em seu computador. Em um terminal digite: <code> | #Rode o NetKit em seu computador. Em um terminal digite: <code> | ||
− | + | netkit2 & </syntaxhighlight> | |
#No menu '''File''' - '''Load and Run''', procure o arquivo /home/aluno/IPv6.conf e clique em OK. Abrirá uma janela com 6 abas, onde cada uma delas é um terminal de configuração do respectivo equipamento: '''pc1-4''' ou '''r1-2'''. | #No menu '''File''' - '''Load and Run''', procure o arquivo /home/aluno/IPv6.conf e clique em OK. Abrirá uma janela com 6 abas, onde cada uma delas é um terminal de configuração do respectivo equipamento: '''pc1-4''' ou '''r1-2'''. | ||
#Ao clicar no menu '''File''' - '''Graph''', pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto. | #Ao clicar no menu '''File''' - '''Graph''', pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto. | ||
Linha 1 369: | Linha 1 444: | ||
#No '''pc1''' use o seguinte comando para verificar como ficou a configuração dos endereços da interface de rede. O resultado é similar ao apresentado pelo comando '''ifconfig''': <code> | #No '''pc1''' use o seguinte comando para verificar como ficou a configuração dos endereços da interface de rede. O resultado é similar ao apresentado pelo comando '''ifconfig''': <code> | ||
ip addr show dev eth0 </syntaxhighlight> | ip addr show dev eth0 </syntaxhighlight> | ||
− | #Configure os IPv6s de todas as interfaces dos demais equipamentos de acordo com o diagrama da rede. | + | #Configure os IPv6s de todas as interfaces dos demais equipamentos de acordo com o diagrama da rede (adapte os números de IPs), seguindo o exemplo do item 6. |
#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> | ||
Linha 1 389: | Linha 1 464: | ||
ip -6 route add 2001:bcc:faca:1::/64 via 2001:db8:dead:1::1 dev eth0 | ip -6 route add 2001:bcc:faca:1::/64 via 2001:db8:dead:1::1 dev eth0 | ||
ip -6 route add 2001:bcc:cafe:1::/64 via 2001:db8:dead:1::1 dev eth0 </syntaxhighlight> | ip -6 route add 2001:bcc:cafe:1::/64 via 2001:db8:dead:1::1 dev eth0 </syntaxhighlight> | ||
− | #Use os comandos '''traceroute6 | + | #Use os comandos '''traceroute6 2001:bcc:1f0:1::103''' e '''traceroute6 2001:bcc:1f0:1::104''' a partir do computador '''pc1'''. |
#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? | ||
#Em cada um dos computadores virtuais, use o comando '''fg tcpdump''' para trazer o '''tcpdump''' para o primeiro plano. Em seguida encerre a captura com '''Ctrl + C'''. | #Em cada um dos computadores 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 | + | #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. |
#Verifique as diferenças dos cabeçalhos de um pacote IPv4 e de um pacote Ipv6, comparando capturas do '''wireshark'''. | #Verifique as diferenças dos cabeçalhos de um pacote IPv4 e de um pacote Ipv6, comparando capturas do '''wireshark'''. | ||
− | #A partir das capturas obtidas, explique o processo de descoberta de vizinhança (neighbor discovery / request e reply), citando os endereços de '''multicast''' e '''link local''' utilizados. | + | #A partir das capturas obtidas, explique o processo de descoberta de vizinhança (''neighbor discovery'' / ''request'' e ''reply''), citando os endereços de '''multicast''' e '''link local''' utilizados. |
#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? | #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'''. | #É 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'''. | ||
Linha 1 409: | Linha 1 484: | ||
= Curiosidades = | = Curiosidades = | ||
− | * [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://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] | ||
+ | * [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] | ||
* [https://wigle.net/ Redes WiFi no mundo] | * [https://wigle.net/ Redes WiFi no mundo] | ||
* [https://www.youtube.com/watch?v=9hIQjrMHTv4 ''History of the Internet''] | * [https://www.youtube.com/watch?v=9hIQjrMHTv4 ''History of the Internet''] | ||
Linha 1 419: | Linha 1 497: | ||
* [https://www.youtube.com/watch?v=0nz-lcuv3TM ''Browser Wars'' - dublado] | * [https://www.youtube.com/watch?v=0nz-lcuv3TM ''Browser Wars'' - dublado] | ||
* [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] | ||
+ | * [https://http2.github.io/faq/#will-http2-replace-http1x HTTP/2 Frequently Asked Questions] | ||
= Seminários = | = Seminários = | ||
Linha 1 430: | Linha 1 510: | ||
* ''Grupos e Temas para 2015-2'': | * ''Grupos e Temas para 2015-2'': | ||
+ | #Mateus Araujo e Paula Grando: iPv6, sua necessidade, implementação e facilidades. | ||
+ | #Adonis, Daniel e Pedro: FTTX aplicado através da tecnologia GPON. | ||
+ | #Kauly e Theodor: protocolo TLS. | ||
+ | #Natália e Luisa: Telefonia VoIP. | ||
+ | #Andrey e Ricardo: Servidor de Email. | ||
+ | #Alline e Layssa: Redes TOR ou cabeamentos oceânicos. | ||
+ | #João e Nelson: "Grampo" de chamadas VoIP. | ||
+ | #Henrique e Lucas: Protocolo [[BGP - Border Gateway Protocol]]. | ||
*Ordem de apresentação dos seminários | *Ordem de apresentação dos seminários | ||
Linha 1 436: | Linha 1 524: | ||
** Nota: 0,5 x Documento + 0,5 x Seminário | ** Nota: 0,5 x Documento + 0,5 x Seminário | ||
**[http://www.sj.ifsc.edu.br/~odilson/RED29004/Criterio%20de%20avaliacao%20dos%20relatorios%20e%20apresentacao.pdf Critérios de avaliação] | **[http://www.sj.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/Avaliacao%20dos%20relatorios%20e%20apresentacao.pdf Resultado da avaliação do documento] | ||
+ | ** [http://docente.ifsc.edu.br/odilson/RED29004/Textos_Comentados/ Cópia dos documentos comentados] | ||
* ''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: '''17/11/15'''. |
** 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: '''14/02/16''' (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. | ||
** As apresentações podem ser realizadas seguindo o conteúdo do relatório (use bastante figuras no relatório, isto facilita a apresentação). | ** 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 [http:// | + | ** Se preferirem usar slides, usem [http://docente.ifsc.edu.br/odilson/RED29004/modelo_apresentacao.odp esse modelo]. |
=Diário de aulas= | =Diário de aulas= | ||
− | {{Collapse top |Aula 1 - | + | {{Collapse top |Aula 1 - 6/10/15: 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. | ||
# Auto apresentação | # Auto apresentação | ||
# [http://wiki.sj.ifsc.edu.br Apresentação da Wiki] | # [http://wiki.sj.ifsc.edu.br Apresentação da Wiki] | ||
− | # [[RED1- | + | # [[RED1-EngTel_(Plano_de_Ensino)|Plano de Ensino, Ementa, Estratégia de Ensino e Bibliografia]] |
− | # | + | ## 3 avaliações (P1, P2 e P3) mais um Seminário de tema livre (S) |
− | # | + | ## Cada uma das avaliações terá terá um conceito: A, B, C e D. Conceito mínimo final para não necessitar reavaliação: C. |
− | # | + | ## Reavaliação única no último dia de aula. |
− | ## | ||
− | |||
# [[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]] | ||
+ | #* Definição datas assim que o calendário estiver divulgado | ||
+ | #* 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? | ||
+ | # Introdução às redes de computadores | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
+ | |||
+ | 8/10/15 - Introdução a Redes de Computadores | ||
+ | |||
+ | 13/10/15 - Comutação de circuitos versus comutação de pacotes | ||
+ | |||
+ | 15/10/15 - Conceito e descrição de serviços de rede. Conceito de protocolo de rede | ||
+ | |||
+ | 20/10/15 - Atraso em redes de pacotes | ||
+ | |||
+ | 22/10/15 - [[RED29004-2015-2#Roteiros_para_laborat.C3.B3rio | Laboratório 1 - Ping Traceroute Wireshark]] | ||
+ | |||
+ | 27/10/15 - Camada de aplicação: HTTP, FTP, SMTP | ||
+ | |||
+ | 29/10/15 - [[RED29004-2015-2#Roteiros_para_laborat.C3.B3rio | Laboratório 2 - HTTP]] | ||
+ | |||
+ | 3/11/15 - Camada de aplicação: DNS – P2P | ||
+ | |||
+ | 5/11/15 - [[RED29004-2015-2#Roteiros_para_laborat.C3.B3rio | Laboratório 3 - DNS]] | ||
+ | |||
+ | 10/11/15 - Aplicação e protocolos para sinalização/comunicação multimídia (SIP e RTP) | ||
+ | |||
+ | 12/11/15 - Aplicação e protocolos para sinalização/comunicação multimídia (SIP e RTP) - Introdução a camada de transporte | ||
+ | |||
+ | 14/11/15 - [[RED29004-2015-2#Roteiros_para_laborat.C3.B3rio | Laboratório 4 - Sockets]] | ||
+ | |||
+ | 17/11/15 - Introdução a camada de transporte - Multiplexação/Demultiplexação - UDP | ||
+ | |||
+ | 19/11/15 - UDP - Princípios da transferência garantida | ||
+ | |||
+ | 24/11/15 - Dúvidas para primeira avaliação | ||
+ | |||
+ | 26/11/15 - Avaliação 1 | ||
+ | |||
+ | 1/12/15 - Controle de fluxo - Controle de congestionamento | ||
+ | |||
+ | 3/12/15 - controle de congestionamento -- TCP | ||
+ | |||
+ | 8/12/15 - [[RED29004-2015-2#Roteiros_para_laborat.C3.B3rio | Laboratório 5 - TCP x UDP]] | ||
+ | |||
+ | 10/12/15 - Término do laboratório 5 e correção da prova | ||
+ | |||
+ | 15/12/15 - Início da camada de rede | ||
+ | |||
+ | 17/12/15 - Dúvidas para segunda avaliação | ||
+ | |||
+ | 22/12/15 - Avaliação 2 | ||
+ | |||
+ | 2/2/16 - Discussão sobre o trabalho, recapitulação e camada de rede | ||
+ | |||
+ | 4/2/16 - Roteadores e IPv4 | ||
+ | |||
+ | 11/2/16 - IPv4 e Protocolos de Roteamento | ||
+ | |||
+ | 13/2/16 - Laboratório 6 - Protocolos de roteamento | ||
+ | |||
+ | 16/2/16 - Laboratório 7 - Protocolos de roteamento | ||
+ | |||
+ | 18/2/16 - DHCP, NAT, ICMP e algoritmos de roteamento | ||
+ | |||
+ | 23/2/16 - Princípios IPv6 | ||
+ | |||
+ | 25/2/16 - Laboratório 8 - IPv6 | ||
+ | |||
+ | 1/3/16 - Introdução a camada de enlace | ||
+ | |||
+ | 3/3/16 - Avaliação 3 | ||
+ | |||
+ | 8/3/16 - Apresentação dos seminários: GPON, Postfix e IPv6 | ||
+ | |||
+ | 10/3/16 - Apresentação dos seminários: TLS, Escuta VoIP e Cabos Submarinos | ||
+ | |||
+ | 12/3/16 - Apresentação dos seminários: BGP e VoIP | ||
+ | |||
+ | 15/3/16 - Reavaliação final |
Edição atual tal como às 15h26min de 21 de março de 2016
Diário de aula de RED - 2015-2 - Prof. Odilson T. Valle
Conceitos Finais
Dados Importantes
Professor: Odilson Tadeu Valle
Email: odilson@ifsc.edu.br
Atendimento paralelo: 3ª das 15h40 às 16h35 e 5ª das 9h40 às 10h35. Local: Lab. de Desenvolvimento.
- Avaliações
- 3 avaliações (P1, P2 e P3) mais um seminário (S).
- Cada uma das avaliações terá terá um conceito: A, B, C e D. Conceito mínimo para não necessitar reavaliação: C.
- 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 2015-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 e Redes Multimídia |
---|
|
Lista de exercícios 3 - Camada de Transporte |
---|
|
Lista de exercícios 4 - Camada de Rede | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Lista de exercícios 5 - Camada de Enlace |
---|
|
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 virtuaisOs 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. A rede local do laboratório tem endereço IP 192.168.?.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, 192.168.?.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.?.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.?.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 ObjetivosBaseado na pequena introdução ao Wireshark apresentada no Laboratório 1, agora estamos prontos para utilizar o Wireshark para investigar protocolos em operação. Neste laboratório, exploraremos 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 autenticação e segurança HTTP. 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 9 "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:
Autenticação HTTPFinalmente, vamos tentar visitar um local na web que é protegido por senha e examinar a seqüência de mensagens HTTP trocadas com este local. O URL http://www.sj.ifsc.edu.br/~odilson/RED29004/Seguro/ é protegido por senha. O usuário é “red29004” (sem as aspas), e a senha é “seguro” (novamente, sem as aspas). Então vamos acessar o local protegido por senha. Faça o seguinte:
Agora vamos examinar a saída do Wireshark. Você pode querer primeiro ler sobre a autenticação HTTP revisando o material fácil de ler (em inglês) HTTP Access Authentication Framework Responda às seguintes questões:
O nome de usuário (red29004) e a senha (seguro) que você digitou foram codificados na cadeia de caracteres (cmVkMjkwMDQ6c2VndXJv) após o cabeçalho “Authorization: Basic” na mensagem HTTP GET (primeira). Parece que o nome e senha estão criptografados, mas na verdade estão simplesmente codificados em um formato denominado Base64. O nome do usuário e a senha não estão criptografados! Para ver isso, vá para https://www.base64decode.org/ e digite o texto cmVkMjkwMDQ6c2VndXJv e pressione DECODE. Voilá! Você traduziu de Base64 para ASCII, e desta forma consegue ver o nome de usuário e a senha! Sabendo que alguém pode baixar o Wireshark e capturar pacotes (não somente os próprios), e alguém pode traduzir de Base64 para ASCII (você acabou de fazê-lo!), deve estar claro para você que o uso de senhas apenas em locais na web não garantem segurança, a não ser que medidas adicionais sejam tomadas. Não tema! Há meios de fazer o acesso WWW ser mais seguro. Contudo, nós claramente precisamos de algo que vá além do framework básico de autenticação HTTP! 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 de mais 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. Um exemplo de código bem simples para o lado Cliente: UDPClient.py
|
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?
Experimento 2Transferências usando cada um desses protocolos podem apresentar características bem distintas. Neste segundo 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.
Experimento 3Repita os passos 1 e 3 do experimento 2 (anterior) mas agora com o arquivo minimo.txt, anotando todos os tempos.
Tarefa extra (pode ser em casa)Use o aplicativo NetCat (nc) para fazer transferências UDP e responda (utilize o man para os comandos, boa parte da respostas estão lá):
|
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 - IPv6 |
---|
Este roteiro foi baseado no material disponível em [2]. 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. 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. É 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: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
- 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
- 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.
- Grupos e Temas para 2015-2:
- Mateus Araujo e Paula Grando: iPv6, sua necessidade, implementação e facilidades.
- Adonis, Daniel e Pedro: FTTX aplicado através da tecnologia GPON.
- Kauly e Theodor: protocolo TLS.
- Natália e Luisa: Telefonia VoIP.
- Andrey e Ricardo: Servidor de Email.
- Alline e Layssa: Redes TOR ou cabeamentos oceânicos.
- João e Nelson: "Grampo" de chamadas VoIP.
- Henrique e Lucas: Protocolo BGP - Border Gateway Protocol.
- Ordem de apresentação dos seminários
- Avaliação
- Nota: 0,5 x Documento + 0,5 x Seminário
- Critérios de avaliação
- Resultado da avaliação do documento
- Cópia dos documentos comentados
- Instruções sobre o Seminário de Redes I:
- Data para definição de grupos e temas: 17/11/15.
- 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: 14/02/16 (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 - 6/10/15: Apresentação da disciplina |
---|
|
8/10/15 - Introdução a Redes de Computadores
13/10/15 - Comutação de circuitos versus comutação de pacotes
15/10/15 - Conceito e descrição de serviços de rede. Conceito de protocolo de rede
20/10/15 - Atraso em redes de pacotes
22/10/15 - Laboratório 1 - Ping Traceroute Wireshark
27/10/15 - Camada de aplicação: HTTP, FTP, SMTP
29/10/15 - Laboratório 2 - HTTP
3/11/15 - Camada de aplicação: DNS – P2P
5/11/15 - Laboratório 3 - DNS
10/11/15 - Aplicação e protocolos para sinalização/comunicação multimídia (SIP e RTP)
12/11/15 - Aplicação e protocolos para sinalização/comunicação multimídia (SIP e RTP) - Introdução a camada de transporte
14/11/15 - Laboratório 4 - Sockets
17/11/15 - Introdução a camada de transporte - Multiplexação/Demultiplexação - UDP
19/11/15 - UDP - Princípios da transferência garantida
24/11/15 - Dúvidas para primeira avaliação
26/11/15 - Avaliação 1
1/12/15 - Controle de fluxo - Controle de congestionamento
3/12/15 - controle de congestionamento -- TCP
8/12/15 - Laboratório 5 - TCP x UDP
10/12/15 - Término do laboratório 5 e correção da prova
15/12/15 - Início da camada de rede
17/12/15 - Dúvidas para segunda avaliação
22/12/15 - Avaliação 2
2/2/16 - Discussão sobre o trabalho, recapitulação e camada de rede
4/2/16 - Roteadores e IPv4
11/2/16 - IPv4 e Protocolos de Roteamento
13/2/16 - Laboratório 6 - Protocolos de roteamento
16/2/16 - Laboratório 7 - Protocolos de roteamento
18/2/16 - DHCP, NAT, ICMP e algoritmos de roteamento
23/2/16 - Princípios IPv6
25/2/16 - Laboratório 8 - IPv6
1/3/16 - Introdução a camada de enlace
3/3/16 - Avaliação 3
8/3/16 - Apresentação dos seminários: GPON, Postfix e IPv6
10/3/16 - Apresentação dos seminários: TLS, Escuta VoIP e Cabos Submarinos
12/3/16 - Apresentação dos seminários: BGP e VoIP
15/3/16 - Reavaliação final