Mudanças entre as edições de "Curso Técnico Integrado de Telecomunicações - Redes de Computadores (RCO)"
Linha 222: | Linha 222: | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Laboratório 2 - Desvendando o HTTP com Wireshark}} | ||
+ | |||
+ | Fonte base: [http://www.ebah.com.br/content/ABAAABZ6QAD/wireshark-http Wireshark - HTTP] | ||
+ | |||
+ | ===Objetivos=== | ||
+ | *Baseado na pequena introdução ao Wireshark apresentada no '''Laboratório 1''', agora estamos prontos para utilizar o Wireshark para investigar protocolos em operação. | ||
+ | *Explorar vários aspectos do protocolo HTTP: | ||
+ | *#a interação básica GET/resposta do HTTP, | ||
+ | *#formatos de mensagens HTTP, | ||
+ | *#baixando arquivos grandes em HTML, | ||
+ | *#baixando arquivos em HTML com objetos incluídos, e | ||
+ | *#segurança HTTP. | ||
+ | |||
+ | ===A Interação Básica GET/Resposta do HTTP=== | ||
+ | |||
+ | 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; | ||
+ | #limpe o cache do mesmo (teclas de atalho para o Firefox: '''Ctrl + Shift + Del'''); | ||
+ | #inicie o Wireshark, como descrito no '''Laboratório 1'''; | ||
+ | #inicie a captura de pacotes; | ||
+ | #digite o seguinte URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004.html; | ||
+ | #pare a captura de pacotes; | ||
+ | #digite “http” (somente as letras, sem as aspas) na caixa de texto de especificação do filtro de exibição, de tal forma que apenas as mensagens HTTP capturadas serão exibidas na janela de listagem de pacotes. (Só estamos interessados em HTTP desta vez, e não desejamos ver todos os pacotes capturados). | ||
+ | |||
+ | [[Arquivo:HTTP_Wireshark.png |thumb | 300px| Fig.1 Requisição e Resposta HTTP]] | ||
+ | |||
+ | O exemplo da figura 1 mostra na janela de listagem de pacotes duas mensagens HTTP capturadas: | ||
+ | #A mensagem GET (do seu navegador para o servidor web www.sj.ifsc.edu.br) e a mensagem de resposta do servidor para o seu navegador. | ||
+ | #A janela de conteúdos de pacotes mostra detalhes da mensagem selecionada (neste caso a mensagem HTTP GET /~odilson/RED29004//RED29004.html, que está em destaque na janela de listagem de pacotes). | ||
+ | #A mensagem HTTP transportada em um segmento TCP, que é carregado em um datagrama IP, que é levado em um quadro Ethernet com 5728 bits no fio. Isso é observado de baixo para cima na janela de detalhes do cabeçalho do pacote selecionado. O Wireshark exibe informações sobre o quadro, IP, TCP e HTTP. Você deve expandir as informações, por exemplo, do HTTP clicando na seta ao lado esquerdo de “Hypertext Transfer Protocol”. Observando as informações das mensagens HTTP GET e de resposta. Você consegue inclusive enxergar a mensagem mostrada no navegador: '''RED29004! Página de teste.''' | ||
+ | |||
+ | 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. | ||
+ | #O seu navegador executa HTTP 1.0 ou 1.1? | ||
+ | #Qual a versão de HTTP do servidor? | ||
+ | #Quais idiomas (se algum) o seu navegador indica ao servidor que pode aceitar? | ||
+ | #Qual o endereço IP do seu computador? | ||
+ | #E do servidor tele.sj.ifsc.edu.br? | ||
+ | #Qual o número da porta utilizada no seu computador? | ||
+ | #E do servidor tele.sj.ifsc.edu.br? | ||
+ | #Qual o endereço MAC do seu computador? | ||
+ | #Qual o endereço MAC do servidor de destino (Dst)? Nesse caso o servidor de destino e o servidor tele.sj.ifsc.edu.br são o mesmo host? | ||
+ | #Qual o código de status retornado do servidor para o seu navegador? | ||
+ | #Quando o arquivo em HTML que você baixou foi modificado no servidor pela última vez? | ||
+ | #Quantos bytes de conteúdo são baixados pelo seu navegador? | ||
+ | #Encontre a mensagem '''RED29004! Página de teste'''. Onde (em qual campo) encontra-se? | ||
+ | #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 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; | ||
+ | #limpe o cache do seu navegador('''Ctrl + Shift + Del'''); | ||
+ | #inicie o Wireshark; | ||
+ | #digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004.html seu navegador deve exibir um arquivo em HTML muito simples com duas linhas; | ||
+ | #pressione o botão “refresh” no navegador (ou digite o URL novamente); | ||
+ | #pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP sejam apresentadas na janela de listagem de pacotes. | ||
+ | |||
+ | Responda às seguintes questões: | ||
+ | #Inspecione o conteúdo da primeira mensagem HTTP GET do seu navegador para o servidor tele.sj.ifsc.edu.br. Você vê uma linha “If-Modified-Since”? | ||
+ | #Inspecione o conteúdo da resposta do servidor. O servidor retornou explicitamente o conteúdo do arquivo? Como você pode dizer isso? | ||
+ | #Agora inspecione o conteúdo da segunda mensagem HTTP GET do seu navegador para o servidor. Você vê uma linha “If-Modified-Since”? Caso a resposta seja afirmativa, qual informação segue o cabeçalho “If-Modified-Since”? | ||
+ | #Qual é o código de status e a frase retornada do servidor na resposta à segunda mensagem HTTP GET? É diferente do código de retorno da primeira mensagem? | ||
+ | #O servidor retornou explicitamente o conteúdo do arquivo? Explique. | ||
+ | #Qual o tamanho da primeira e segunda mensagem de retorno do servidor? | ||
+ | |||
+ | ===Baixando Documentos Longos=== | ||
+ | |||
+ | Nos 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: | ||
+ | #inicie o navegador web; | ||
+ | #limpe o cache do seu navegador; | ||
+ | #inicie o Wireshark; | ||
+ | #digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004_arq2.html seu navegador deve exibir um documento bastante longo e criativo :) ; | ||
+ | #Faça um atualização da página (F5); | ||
+ | #pare a captura de pacotes, e digite "http" na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas. | ||
+ | |||
+ | Na janela de listagem de pacotes, você deve ver a sua mensagem HTTP GET, seguida por uma reposta em vários pacotes. Esta resposta em vários pacotes merece uma explicação. Lembre-se da seção 2.2 do livro (veja a figura 2.9) que a mensagem de resposta HTTP consiste de uma linha de status, seguida por zero ou mais linhas de cabeçalhos, seguida por uma linha em branco, seguida pela carga útil (Content-Length). No caso do nossa HTTP GET, a carga útil na resposta é o arquivo HTTP completo. No nosso caso aqui, o arquivo em HTML é bastante longo, e a informação de '''11747 bytes''' é muito grande para caber em um segmento TCP. A resposta HTTP simples é então quebrada em vários pedaços pelo TCP, com cada pedaço sendo contido dentro de um segmento TCP separado. Cada segmento TCP é capturado em um pacote separado pelo Wireshark, clique sobre o nono "Reassembled TCP Segments" no Wireshark. | ||
+ | |||
+ | Responda às seguintes questões: | ||
+ | #Quantas mensagens HTTP GET foram enviadas pelo seu navegador? | ||
+ | #Quantos segmentos TCP foram necessários para carregar a resposta? | ||
+ | #Qual é o código de status e a frase associada com a resposta à mensagem HTTP GET? | ||
+ | #No segundo GET realizado, quantos segmentos TCP foram necessários para obtenção da resposta do servidor? | ||
+ | #O que explica a diferença entre a primeira e segunda requisições? | ||
+ | |||
+ | ===Documentos HTML com Objetos Incluídos=== | ||
+ | |||
+ | Agora 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: | ||
+ | #inicie o navegador web; | ||
+ | #limpe o cache do seu navegador; | ||
+ | #inicie o Wireshark; | ||
+ | #digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq3.html seu navegador deve exibir um arquivo pequeno em HTML com duas imagens incluídas. Estas duas imagens estão referenciadas no arquivo em HTML. Isto é, as imagens não estão no arquivo em HTML, ao invés disso, há um URL para cada imagem no arquivo em HTML. Como discutido no livro, seu navegador terá que baixar estas imagens dos locais correspondentes. As imagens estão em docente.ifsc.edu.br; | ||
+ | #digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq4.html seu navegador deve exibir um arquivo pequeno em HTML com cinco imagens incluídas. Estas cinco imagens,diferentemente do caso anterior, estão depositadas no próprio sítio do professor; | ||
+ | #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. | ||
+ | |||
+ | Responda às seguintes questões: | ||
+ | #Quantas mensagens HTTP GET foram enviadas pelo seu navegador em cada acesso? | ||
+ | #Para quais endereços na Internet estas mensagens foram enviadas em cada acesso? | ||
+ | #Você consegue dizer se o seu navegador baixou imagens com ou sem paralelismo? Explique e diferencie o comportamento em cada um dos casos. | ||
+ | |||
+ | ===HTTPS=== | ||
+ | Para finalizar, vamos capturar sequências de mensagens HTTPS, somente a título de comparação. Execute os seguintes procedimentos: | ||
+ | #inicie o navegador web; | ||
+ | #limpe o cache do seu navegador; | ||
+ | #inicie o Wireshark; | ||
+ | #digite o seguinte URL no navegador https://www.ssllabs.com/ssltest/; | ||
+ | #pare a captura de pacotes e digite "ssl" na caixa de texto de especificação de filtro, para que apenas as mensagens criptografadas sejam exibidas. | ||
+ | |||
+ | Responda: | ||
+ | #Compare a sequência de troca de mensagens (GET e resposta) entre o HTTP (das seções anteriores) com o ssl, existe alguma similaridade? | ||
+ | #Que tipos de campos são mais presentes nesse tipo de mensagens? | ||
+ | #Você consegue identificar o conteúdo de alguma nas mensagens ssl, como no caso das mensagens http? | ||
+ | |||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Laboratório 3 - Serviço de Nomes (DNS)}} | ||
+ | |||
+ | ===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 mais de perto: | ||
+ | #o lado cliente do DNS, | ||
+ | #uma pequena análise do protocolo e | ||
+ | #consultas AAAA | ||
+ | |||
+ | 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=== | ||
+ | # Usando o programa [http://manpages.ubuntu.com/manpages/precise/man5/hosts.5.html host], [http://manpages.ubuntu.com/manpages/trusty/en/man1/nslookup.1.html Nslookup] ou [http://manpages.ubuntu.com/manpages/precise/man1/dig.1.html dig], que são executados no terminal, descubra e anote no relatório os endereços IP associados aos seguintes nomes de hosts (máquinas): | ||
+ | #* mail.ifsc.edu.br | ||
+ | #* www.google.com | ||
+ | #* www.gmail.com | ||
+ | # Agora descubra e anote no relatório 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 | ||
+ | dig -t ns ifsc.edu.br | ||
+ | </syntaxhighlight> | ||
+ | # Descubra e anote no relatório: 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> | ||
+ | # 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 | ||
+ | dig -t mx ifsc.edu.br | ||
+ | </syntaxhighlight>Descubra e anote no relatório quem é o servidor de emails nos seguintes domínios: | ||
+ | #* gmail.com | ||
+ | #* hotmail.com | ||
+ | #* ifsc.edu.br | ||
+ | # Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim: <syntaxhighlight lang=bash> | ||
+ | dig -x 200.135.37.65 | ||
+ | </syntaxhighlight> ... o ''dig'' tem um resultado um pouco mais carregado que os outros utilitários (''host'' e ''nslookup''), porém neste caso é mais prático. Veja o resultado da consulta logo após a linha '';; ANSWER SECTION:''. Experimente fazer a resolução reversa para cada um dos IP obtidos nas consultas realizadas no primeiro exercício desta atividade. Pode-se também usar a variante do ''dig'' para respostas curtas: <code> | ||
+ | dig -x 200.135.37.65 +short | ||
+ | </syntaxhighlight> | ||
+ | #Faça uma consulta recursiva com dig e responda:<syntaxhighlight lang=bash> | ||
+ | dig +trace mail.ru. </syntaxhighlight> | ||
+ | ##Qual foi o RLD (''Root Level Domain'') consultado? | ||
+ | ##Qual o TLD (''Top Level Domain'') consultado? | ||
+ | ##Qual o SLD (''Second Level Domain'') consultado? | ||
+ | ##Como você sabe que foram esses os LDs consultados? | ||
+ | # Como explicado durante a aula e visto no exercício anterior, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado? Posto de outro modo, vamos fazer todo o processo de requisição interativa, do exercício anterior, manualmente, ou seja, descobrir quem é o ''Root Level Domain'', o ''Top Level Domain'' e o ''Second Level Domain''. Anote no relatório. | ||
+ | ## Descubra quem são os servidores raiz (topo de hierarquia DNS): <syntaxhighlight lang=bash> | ||
+ | host -t ns . | ||
+ | dig -t ns . | ||
+ | </syntaxhighlight> | ||
+ | ## Escolha um dos servidores TLD listados, e use-o para fazer as consultas. Por exemplo: <syntaxhighlight lang=bash> | ||
+ | host -v -t a www.sj.ifsc.edu.br. j.root-servers.net. | ||
+ | </syntaxhighlight>... e observe a seção '';; AUTHORITY SECTION:''. Ele contém a listagem de servidores DNS que podem atender sua consulta. | ||
+ | ## 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> | ||
+ | ## Quantos servidores DNS foram necessários consultar no total? | ||
+ | #Consultando um servidor explícito(@)<syntaxhighlight lang=bash> | ||
+ | dig @j.root-servers.net. +trace www.sj.ifsc.edu.br. </syntaxhighlight> | ||
+ | ##Explique a diferença na consulta realizada por esse comando para o comando ''dig +trace www.sj.ifsc.edu.br''. Em algum caso a consulta poderia ser exatamente a mesma? Qual? | ||
+ | |||
+ | ===Algumas consultas AAAA=== | ||
+ | Vamos expandir um pouco nossos horizontes e fazer algumas consultas envolvendo IPv6. | ||
+ | #No terminal de sua máquina faça uma consulta e responda: qual o endereço IPv6 dos hosts? Por exemplo: <code> | ||
+ | dig AAAA google.com | ||
+ | host -t AAAA google.com </syntaxhighlight> | ||
+ | ##webmail.ufsc.br | ||
+ | ##www.sj.ifsc.edu.br | ||
+ | ##www.nyt.com | ||
+ | ##ipv6.br | ||
+ | ##www.microsoft.com | ||
+ | #Agora vamos fazer a consulta reversa. Qual é o nome de host dos seguintes endereços? Por exemplo: <code> | ||
+ | dig -x 2001:12ff::10 | ||
+ | dig -x 2001:12ff::10 +short | ||
+ | host 2001:12ff::10 </syntaxhighlight> | ||
+ | ##2801:84:0:2::10 | ||
+ | ##2001:12d0:0:126::183:244 | ||
+ | ##2001:12ff::10 | ||
+ | ##2804:1454:1004:100::2 | ||
+ | |||
+ | ===Analisando o protocolo 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 escolha a interface e inicie a captura de pacotes; | ||
+ | #inicie a captura de pacotes no Wireshark; | ||
+ | #no terminal digite '''dig +trace canon.jp''' (isso vai provocar a consulta DNS); | ||
+ | #pare a captura de pacotes; | ||
+ | #No Wireshark digite “dns” no filtro (sem as aspas); | ||
+ | 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? | ||
+ | #quais são os benefícios de usar o UDP ao invés do TCP como protocolo de transporte para o DNS? | ||
+ | |||
+ | ===Exemplos de arquivos de um ''Second Level Domain'' fictício=== | ||
+ | *Exemplo de arquivos de configuração de um servidor [https://www.isc.org/downloads/bind/ BIND] | ||
+ | /etc/bind/db.redes <code> | ||
+ | $TTL 86400 | ||
+ | @ IN SOA ns.redes.edu.br. root ( | ||
+ | 2016090900 ; Serial | ||
+ | 604800 ; Refresh | ||
+ | 86400 ; Retry | ||
+ | 2419200 ; Expire | ||
+ | 86400 ) ; Negative Cache TTL | ||
+ | ; | ||
+ | @ IN NS ns.redes.edu.br. | ||
+ | @ IN MX 10 mail.redes.edu.br. | ||
+ | $ORIGIN redes.edu.br. | ||
+ | ns A 192.168.1.101 | ||
+ | www A 192.168.1.102 | ||
+ | www A 192.168.1.103 | ||
+ | www A 192.168.1.104 | ||
+ | www A 192.168.1.105 | ||
+ | www A 192.168.1.106 | ||
+ | www A 192.168.1.107 | ||
+ | ftp A 192.168.1.108 | ||
+ | mail A 192.168.1.109 </syntaxhighlight> | ||
+ | |||
+ | /etc/bind/db.2.168.192 (Zona reversa) <code> | ||
+ | $TTL 86400 | ||
+ | @ IN SOA ns.redes.edu.br. root ( | ||
+ | 2016090900 ; Serial | ||
+ | 604800 ; Refresh | ||
+ | 86400 ; Retry | ||
+ | 2419200 ; Expire | ||
+ | 86400 ) ; Negative Cache TTL | ||
+ | ; | ||
+ | IN NS ns.redes.edu.br. | ||
+ | 101 IN PTR ns.redes.edu.br. | ||
+ | 102 IN PTR www.redes.edu.br. | ||
+ | 108 IN PTR ftp.redes.edu.br. | ||
+ | 109 IN PTR mail.redes.edu.br. </syntaxhighlight> | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
==Transparências utilizadas durante as aulas== | ==Transparências utilizadas durante as aulas== | ||
[http://docente.ifsc.edu.br/odilson/RCO60803/slides-kurose-cap1.pdf Capítulo 1 - Introdução] | [http://docente.ifsc.edu.br/odilson/RCO60803/slides-kurose-cap1.pdf Capítulo 1 - Introdução] |
Edição das 09h25min de 15 de agosto de 2017
MURAL DE AVISOS E OPORTUNIDADES DA ÁREA DE TELECOMUNICAÇÕES
Informações Gerais
Edições
- RCO60803 2017-2 - Prof. Odilson Tadeu Valle / Prof. Eraldo Silveira e Silva
- RCO60803 2017-1 - Prof. Juliano de Souza / Prof. Eraldo Silveira e Silva
- RCO60803 2016-2 - Prof. Juliano de Souza / Prof. Luciano Barreto
- RCO60803 2016-1 - Prof. Fernando Rodrigues Santos / Prof. Juliano de Souza
- RCO60803 2015-2 - Prof. Simara Sonaglio
- RCO60803 2015-1 - Prof. Arliones Hoeller / Prof. Túlio Ribeiro
- RCO60803 2014-2 - Prof. Arliones Hoeller / Prof. Tomás Grimm / Prof. José Clair
Laboratórios
Laboratório 1 - Ferramentas de Rede e Conceitos Básicos | |
---|---|
Objetivos
Conceitos introdutórios para uso do laboratórioEstrutura do LaboratórioA rede do laboratório em uso segue o modelo apresentado no diagrama da Figura 1 (endereçamento pode ser diferente). Os Laboratórios de Redes de Computadores estão equipados com N+1 (N = número de computadores para alunos) computadores conectados em rede e com acesso a Internet, Figura 1. A rede local do laboratório tem endereço IP 192.168.1.0/24. A máscara de rede /24 indica que o último byte do endereço é utilizado para identificar cada máquina, por exemplo 192.168.1.1, 192.168.1.2, etc. Máquinas virtuaisO sistema operacional hospedeiro é o Linux Ubuntu. Como os laboratórios são utilizados por várias disciplinas/alunos/professores, os usuários não tem acesso a senha de root (administrador). Para possibilitar a execução de comandos exclusivos do administrador (usuário root), cada computador tem instaladas máquinas virtuais, as quais podem ser lançadas a partir do aplicativo VirtualBox. As máquinas virtuais pertencem a mesma rede local do laboratório e tem endereçamento 192.168.1.x, sendo o byte que identifica a máquina (x) deverá ser manualmente configurado com a seguinte regra: M1 – 101, M2 – 102,..., M9 – 109, M10 – 110,..., M14 – 114 . Por exemplo:, M1 ficará com o endereço 192.168.1.101. Roteiro de atividades |
thumb
Parte 1: Observando interfaces do sistema com ifconfigO 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 - wireshark, conceito de protocolo, encapsulamento |
---|
Objetivos
WireShark2005 KUROSE, J.F & ROSS, K. W. Todos os direitos reservados
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 2 é 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 2, 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. 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 5. 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.
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:
Ferramenta para conversão ASCII <==> Hexadecimal
|
Laboratório 2 - Desvendando o HTTP com Wireshark |
---|
Fonte base: Wireshark - HTTP Objetivos
A Interação Básica GET/Resposta do HTTPVamos iniciar a nossa exploração do HTTP baixando um arquivo em HTML simples - bastante pequeno, que não contém objetos incluídos. Faça o seguinte:
O exemplo da figura 1 mostra na janela de listagem de pacotes duas mensagens HTTP capturadas:
Responda às seguintes perguntas e imprima as mensagens GET e a resposta e indique em que parte da mensagem você encontrou a informação que responde às questões.
A Interação HTTP GET Condicional/RespostaA maioria dos navegadores web tem um cache (seção 2.2.6 do livro) e, desta forma, realizam GET condicional quando baixam um objeto HTTP. Execute os seguintes passos:
Responda às seguintes questões:
Baixando Documentos LongosNos exemplos até agora, os documentos baixados foram simples e pequenos arquivos em HTML. Vamos ver o que acontece quando baixamos um arquivo em HTML grande. Faça o seguinte:
Na janela de listagem de pacotes, você deve ver a sua mensagem HTTP GET, seguida por uma reposta em vários pacotes. Esta resposta em vários pacotes merece uma explicação. Lembre-se da seção 2.2 do livro (veja a figura 2.9) que a mensagem de resposta HTTP consiste de uma linha de status, seguida por zero ou mais linhas de cabeçalhos, seguida por uma linha em branco, seguida pela carga útil (Content-Length). No caso do nossa HTTP GET, a carga útil na resposta é o arquivo HTTP completo. No nosso caso aqui, o arquivo em HTML é bastante longo, e a informação de 11747 bytes é muito grande para caber em um segmento TCP. A resposta HTTP simples é então quebrada em vários pedaços pelo TCP, com cada pedaço sendo contido dentro de um segmento TCP separado. Cada segmento TCP é capturado em um pacote separado pelo Wireshark, clique sobre o nono "Reassembled TCP Segments" no Wireshark. Responda às seguintes questões:
Documentos HTML com Objetos IncluídosAgora que vimos como o Wireshark mostra o tráfego capturado para arquivos em HTML grandes, nós podemos observar o que acontece quando o seu browser baixa um arquivo com objetos incluídos, no nosso exemplo, imagens que estão armazenadas em outros servidores. Faça o seguinte:
Responda às seguintes questões:
HTTPSPara finalizar, vamos capturar sequências de mensagens HTTPS, somente a título de comparação. Execute os seguintes procedimentos:
Responda:
|
Laboratório 3 - Serviço de Nomes (DNS) |
---|
ObjetivosO Domain Name System (DNS) traduz nomes de hosts em endereços Internet Protocol (IP), preenchendo uma lacuna crítica na infraestrutura da Internet. Neste laboratório, observaremos mais de perto:
Lembre-se de que o papel do cliente no DNS é relativamente simples - um cliente envia uma consulta ao seu DNS, e obtém uma resposta. Muito pode acontecer “por baixo dos panos”, de forma invisível aos clientes DNS, enquanto os servidores DNS, organizados hierarquicamente, comunicam-se entre si para, ou recursivamente ou iterativamente, resolver uma consulta DNS de um cliente. Do ponto de vista do cliente DNS, contudo, o protocolo é bastante simples - uma consulta é feita ao seu servidor DNS e uma resposta é recebida deste servidor. Consultas DNS por meio de ferramentas especializadas
|