Mudanças entre as edições de "RED29004-2015-1"
Linha 403: | Linha 403: | ||
dig -t ns ifsc.edu.br | dig -t ns ifsc.edu.br | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | # Descubra qual o servidor DNS usado pelo seu computador. | + | # Descubra qual o servidor DNS usado pelo seu computador. Num terminal digite: <syntaxhighlight lang=bash> |
− | + | cat /etc/resolv.conf | |
+ | caso a resposta seja "nameserver 127.0.1.1" (endereço de loopback), provavelmente o sistema gráfico está controlando sua interface, nesse caso execute: | ||
+ | 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 se pode descobrir que ''host'' recebe emails em um determinado domínio. Isso é utilizado pelos MTA 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 de um domínio. Por exemplo: <syntaxhighlight lang=bash> | # 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 se pode descobrir que ''host'' recebe emails em um determinado domínio. Isso é utilizado pelos MTA 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 de um domínio. Por exemplo: <syntaxhighlight lang=bash> | ||
host -t mx ifsc.edu.br | host -t mx ifsc.edu.br | ||
Linha 443: | Linha 437: | ||
##* www.reeec.illinois.edu | ##* www.reeec.illinois.edu | ||
##* www.inm.ras.ru | ##* www.inm.ras.ru | ||
− | # | + | #Consultando um servidor explícito(@)<syntaxhighlight lang=bash> |
− | |||
dig @j.root-servers.net. +trace www.sj.ifsc.edu.br. </syntaxhighlight> | dig @j.root-servers.net. +trace www.sj.ifsc.edu.br. </syntaxhighlight> | ||
− | # | + | #Faça uma consulta recursiva com dig e responda:<syntaxhighlight lang=bash> |
− | dig +trace | + | dig +trace mail.ru. </syntaxhighlight> |
+ | ##Qual foi o RLD consultado? | ||
+ | ##Qual o TLD consultado? | ||
+ | ##Qual o SLD consultado? | ||
+ | ##Como você sabe que foram esses os LDs consultados? | ||
===Analisando consultas com captura de pacotes via Wireshark=== | ===Analisando consultas com captura de pacotes via Wireshark=== | ||
− | + | 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 Wireshark e digite “dns” no filtro (sem as aspas); | ||
+ | #inicie a captura de pacotes no Wireshark; | ||
+ | #no navegador web, visite a página http://canon.jp/ (isso vai provocar a consulta DNS); | ||
+ | #pare a captura de pacotes. | ||
+ | Com base nisso identifique o seguinte: | ||
+ | #quantas mensagens são trocadas entre cliente e servidor DNS para cada consulta? | ||
+ | #que protocolo de transporte é usado? | ||
+ | #que portas de origem e destino são utilizadas? | ||
+ | #qual o formato das mensagens DNS? Elas são textuais como as mensagens HTTP? | ||
+ | #qual o tipo de registro DNS acessado em cada consulta? | ||
+ | #que informações estão contidas nas respostas DNS? Há algo além do que foi pedido? | ||
+ | #qual o tamanho das mensagens DNS? | ||
+ | #qual endereço IP a mensagem de consulta DNS é enviada? Foi o mesmo ip obtido na seção anterior: seu servidor DNS? | ||
+ | #examine a mensagem de consulta DNS. Qual o campo “type” desta mensagem? | ||
+ | #a mensagem de consulta contém algum campo “answer”? | ||
+ | #examine a mensagem de resposta DNS. Quantos campos com “answer” existem? | ||
===Brincando um pouco com servidores de nomes=== | ===Brincando um pouco com servidores de nomes=== | ||
Edição das 10h19min de 22 de março de 2015
Diário de aula de RED - 2015-1 - Prof. Odilson T. Valle
Dados Importantes
Professor: Odilson Tadeu Valle
Email: odilson@ifsc.edu.br
Atendimento paralelo: 2ª das 17h35 às 18h30 e 6ª 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 numérico: 1, 2, ..., 9, 10. Conceito mínimo para não necessitar reavaliação: 6.
- Um ou mais conceitos abaixo de 6 implica na realização da reavaliação: uma ú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
Planejamento de atividades | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 - Introdução
Lista de exercícios 1 |
---|
|
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 |
---|
|
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 3
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
Laboratório 2 - Devendando 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.
Repita as respostas e procedimentos para a mensagem de resposta do HTTP. Responda ainda:
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) |
---|
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 e no final 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
|
Laboratório 4 - Programação de sockets |
---|
Material original: Slides do Kurose referentes ao capítulo 2, 6a. Ed., pags 54 à 58 Programação de sockets: criando aplicações de rede
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 vis 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 |
---|
Tempo aproximado: 1h Problemas observados: No experimento 2 diminuir o tamanho do arquivo: máximo 200 MB. O objetivo desses experimentos é evidenciar as diferenças entre os protocolos TCP e UDP. Experimento 1Ambos 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 feita dependendo do tipo de comunicação a ser feita pela aplicação. Por exemplo, o 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, como mostrado na figura abaixo: 172.18.16.38
Experimento 3Repita os experimentos 1 e 3 mas agora com o arquivo minimo.txt, anotando todos os tempos.
Tarefa extraUse o aplicativo NetCat (nc) para fazer transferências UDP e responda:
|
Laboratório 6 - Protocolos de roteamento |
---|
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 isto utilizaremos o Netkit2. Leia aqui 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: 1h
|
Softwares
- Netkit2: possibilita criar experimentos com redes compostas por máquinas virtuais Linux
- [1] Nesta página você pode encontrar vários laboratórios virtuais do NetKit, prontos para uso, que focam em serviços específicos de redes de computadores.
Curiosidades
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-1:
- Lucas e Mathias: HTTPS
- Letícia e Jessica: HTML 5 ou Hidden
- Helenluciany Maria Luiza: QoS
- Katharine e Kristhine: Ad-Hoc Network
- Angelo e Iago: HTTP2
- Thiago e Gabriel: VPN
- Cleiton e Gustavo: SNMP
- Anderson: P2P
- Avaliação
- Nota: 0,5 x Documento + 0,5 x Seminário
- Instruções sobre o Seminário de Redes I:
- Data para definição de grupos e temas: 10/3/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: 2/6/15 (impreterivelmente).
- O relatório pode ser redigido como uma página da wiki.
- Duração da apresentação: 20 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 - 4/2/15: Apresentação da disciplina |
---|
|
Aula 2 - 10/2/15: Introdução às redes de computadores |
---|
Aula 3 - 11/2/15: Introdução às redes de computadores |
---|
Aula 4 - 24/2/15: Introdução às redes de computadores |
---|
Aula 5 - 25/2/15: Introdução às redes de computadores |
---|
Aula 6 - 3/3/15: Introdução às redes de computadores |
---|
Aula 7 - 4/3/15: Laboratório 1 - Ping Traceroute Wireshark |
---|
Aula 8 - 10/3/15: Camada de aplicação - Comunicação entre processos HTTP |
---|
Aula 9 - 11/3/15: Camada de aplicação - HTTP FTP SMTP |
---|
Aula 10 - 17/3/15: Laboratório 2 |
---|
Aula 11 - 18/3/15: Camada de aplicação - DNS |
---|
Aula 12 - 24/3/15: Laboratório 3 - DNS |
---|
Aula 13 - 25/3/15: Camada de aplicação - P2P e sockets |
---|
Aula 14 - 31/3/15: Camada de aplicação - Laboratório 4: sockets |
---|
Aula 15 - 1/4/15: Avaliação 1 |
---|