Mudanças entre as edições de "RED29004-2016-1"
(72 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
Linha 5: | Linha 5: | ||
<br>''Email'': odilson@ifsc.edu.br | <br>''Email'': odilson@ifsc.edu.br | ||
<br>''Atendimento paralelo'': 3ª das 9h40 às 10h35 e 6ª das 14h25 às 15h20. Local: Lab. de Desenvolvimento. | <br>''Atendimento paralelo'': 3ª das 9h40 às 10h35 e 6ª das 14h25 às 15h20. Local: Lab. de Desenvolvimento. | ||
+ | |||
+ | [http://docente.ifsc.edu.br/odilson/RED29004/DIARIO-2016-1-C290-ConceitosLETRAS_RED29004.pdf Conceitos finais] [http://docente.ifsc.edu.br/odilson/RED29004/DIARIO-2016-1-C290%20ConceitosNumericos_RED29004.pdf Conceitos finais numéricos] | ||
* Avaliações | * Avaliações | ||
Linha 64: | Linha 66: | ||
{{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}} |
#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 82: | Linha 84: | ||
#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. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
{{Collapse bottom}} | {{Collapse bottom}} | ||
Linha 216: | Linha 209: | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top |Lista de exercícios 5 - Camada de Enlace}} | + | {{Collapse top |Lista de exercícios 5 - Camada de Enlace e Redes Multimídia}} |
#Quais são os serviços providos pela camada de enlace? | #Quais são os serviços providos pela camada de enlace? | ||
#Dentre os serviços de camada de enlace, quais obrigatoriamente precisam ser implementados por todos os protocolos de enlace? | #Dentre os serviços de camada de enlace, quais obrigatoriamente precisam ser implementados por todos os protocolos de enlace? | ||
Linha 230: | Linha 223: | ||
#Dois adaptadores, um com taxa nominal de 10001 bps e outro com taxa nominal de 9999 bps, estão conectados via par trançado, como eles conseguem trocar dados normalmente? | #Dois adaptadores, um com taxa nominal de 10001 bps e outro com taxa nominal de 9999 bps, estão conectados via par trançado, como eles conseguem trocar dados normalmente? | ||
#Você comprou um notebook novo. Vai utilizar pela primeira vez no Câmpus São José do IFSC. Com um cabo de rede conectou seu computador à rede do IFSC e digitou no navegador de seu computador: www.polito.it. Cite todos os protocolos utilizados e todas a etapas cumpridas por seu computador, para que essa operação tenha exito. | #Você comprou um notebook novo. Vai utilizar pela primeira vez no Câmpus São José do IFSC. Com um cabo de rede conectou seu computador à rede do IFSC e digitou no navegador de seu computador: www.polito.it. Cite todos os protocolos utilizados e todas a etapas cumpridas por seu computador, para que essa operação tenha exito. | ||
+ | #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 265: | Linha 267: | ||
====Máquinas virtuais==== | ====Máquinas virtuais==== | ||
+ | Eventualmente serão utilizadas nessa disciplina. | ||
+ | |||
Os Laboratórios de Redes de Computadores estão equipados com N+1 (N = número de computadores para alunos) computadores conectados em rede e com acesso a Internet, Figura 1. A rede local do laboratório tem endereço IP 192.168.?.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. | 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.?.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). | 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). | ||
Linha 308: | Linha 312: | ||
##Quais são os endereços da camada 2 atribuído as mesmas? De onde o sistema obteve esses endereços? | ##Quais são os endereços da camada 2 atribuído as mesmas? De onde o sistema obteve esses endereços? | ||
##Quais são os endereços IPv4? De onde o sistema obteve esses endereços? | ##Quais são os endereços IPv4? De onde o sistema obteve esses endereços? | ||
− | ##Suas interfaces tem IPv6 configurado? Qual o endereço e escopo dos mesmos? Como foram obtidos? Qual | + | ##Suas interfaces tem IPv6 configurado? Qual o endereço e escopo dos mesmos? Como foram obtidos? Qual o alcance (é roteável) do mesmo? |
====ping==== | ====ping==== | ||
Linha 337: | Linha 341: | ||
##servidor e roteador da rede da escola; | ##servidor e roteador da rede da escola; | ||
##servidores externos: <code> | ##servidores externos: <code> | ||
− | www.ifsc.br | + | www.ifsc.edu.br |
− | www. | + | www.uol.com.br |
− | www. | + | www.nasa.com |
www.polito.it </syntaxhighlight> e explique as possíveis diferenças entre os tempos de resposta dos ping realizados. | www.polito.it </syntaxhighlight> e explique as possíveis diferenças entre os tempos de resposta dos ping realizados. | ||
#Consulte as páginas ''man'' e teste o '''ping''' com os parâmetros abaixo e descreva suas funcionalidades: | #Consulte as páginas ''man'' e teste o '''ping''' com os parâmetros abaixo e descreva suas funcionalidades: | ||
Linha 347: | Linha 351: | ||
##-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. | + | #*No Ubuntu a resposta a um ping no endereço de broadcast é desabilitada por padrão e somente o administrador pode habilitar esta funcionalidade. Quem desejar testar esse tipo de ping deverá utilizar uma máquina virtual qualquer (VirtualBox) e habilitar a resposta a um '''ping''' no endereço de ''broadcast''. 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''. | ||
− | #Execute um ping ''broadcast'' e explique porque aparece o termo ''(DUP!)'' após cada resposta. Dica: observe o número de sequência. | + | ##Execute um ping ''broadcast'' e explique porque aparece o termo ''(DUP!)'' após cada resposta. Dica: observe o número de sequência. |
====traceroute==== | ====traceroute==== | ||
− | |||
− | |||
− | |||
− | |||
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 366: | Linha 366: | ||
1 192.168.1.1 (192.168.1.1) 0.225 ms 0.216 ms 0.368 ms | 1 192.168.1.1 (192.168.1.1) 0.225 ms 0.216 ms 0.368 ms | ||
2 172.18.0.254 (172.18.0.254) 1.236 ms 1.235 ms 1.343 ms | 2 172.18.0.254 (172.18.0.254) 1.236 ms 1.235 ms 1.343 ms | ||
− | 3 hendrix.sj.ifsc.edu.br (200.135.37.65) 1.331 ms 1.313 ms 1.414 ms </syntaxhighlight> O exemplo mostra a rota dos pacotes entre um computador do Lab. Redes | + | 3 hendrix.sj.ifsc.edu.br (200.135.37.65) 1.331 ms 1.313 ms 1.414 ms </syntaxhighlight> |
+ | O exemplo mostra a rota dos pacotes entre um computador do Lab. Redes (192.168.2.1) e o servidor ''hendrix'' (200.135.37.65). Observe que para cada roteador são realizados três amostras de tempo de ida e volta. Veja pelo mapa da rede do Campus São José que entre estes dois computadores, sistemas finais, existem dois roteadores intermediários, máquina do professor e Switch camada 3 (VLANs). | ||
#Traçar a rota dos pacotes entre seu computador e diferentes hosts: | #Traçar a rota dos pacotes entre seu computador e diferentes hosts: | ||
##máquina de um colega do laboratório | ##máquina de um colega do laboratório | ||
Linha 382: | Linha 383: | ||
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 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 | + | 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. |
[[Arquivo:Sniffer_estrutura.png |thumb | 500px| Figura 2 - Estrutura de um ''sniffer'']] | [[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 | + | 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. | É 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. | ||
Linha 415: | Linha 416: | ||
#Se desejar acesse novos sítios e faça novas capturas e tente entender o que ocorre; | #Se desejar acesse novos sítios e faça novas capturas e tente entender o que ocorre; | ||
#Saia do Wireshark. | #Saia do Wireshark. | ||
− | #Com Wireshark ativo acesse um sítio e responda às seguintes questões: | + | #Com Wireshark ativo (Abra-o novamente) 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. | + | ##Teste outros filtros, por exemplo, mostre somente pacotes originados e/ou destinados a um determinado ''host'' ('''ip.addr == 192.168...'''). Anote o filtro utilizado e salve a janela do mesmo. |
− | ## | + | ##Elimine o filtro e anote 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''. | ##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? | ##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? | ||
Linha 435: | Linha 436: | ||
#inicie o navegador; | #inicie o navegador; | ||
#limpe o cache do mesmo (teclas de atalho para o Firefox: '''Ctrl + Shift + Del'''); | #limpe o cache do mesmo (teclas de atalho para o Firefox: '''Ctrl + Shift + Del'''); | ||
− | #inicie o Wireshark, como descrito no '''Laboratório 1''' (mas não inicie a captura de pacotes ainda). 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 | ||
− | #digite o seguinte URL no navegador http:// | + | #digite o seguinte URL no navegador http://docente.ifsc.edu.br/odilson/RED29004/RED29004.html |
#pare a captura de pacotes. | #pare a captura de pacotes. | ||
Linha 452: | Linha 454: | ||
#Quais linguagens (se alguma) o seu navegador indica que pode aceitar ao servidor? | #Quais linguagens (se alguma) o seu navegador indica que pode aceitar ao servidor? | ||
#Qual o endereço IP do seu computador? | #Qual o endereço IP do seu computador? | ||
− | #E do servidor | + | #E do servidor docente.ifsc.edu.br? |
#Qual o número da porta utilizada no seu computador? | #Qual o número da porta utilizada no seu computador? | ||
− | #E do servidor | + | #E do servidor docente.ifsc.edu.br? |
#Qual o endereço MAC do seu computador? | #Qual o endereço MAC do seu computador? | ||
− | # | + | #Qual o endereço MAC do servidor de destino (Dst)? Nesse caso o servidor de destino e o servidor docente.ifsc.edu.br são o mesmo host? |
#Qual o código de status retornado do servidor para o seu navegador? | #Qual o código de status retornado do servidor para o seu navegador? | ||
#Quando o arquivo em HTML que você baixou foi modificado no servidor pela última vez? | #Quando o arquivo em HTML que você baixou foi modificado no servidor pela última vez? | ||
Linha 466: | Linha 468: | ||
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('''Ctrl + Shift + Del'''); |
#inicie o Wireshark; | #inicie o Wireshark; | ||
− | #digite o URL no navegador http:// | + | #digite o URL no navegador http://docente.ifsc.edu.br/odilson/RED29004/RED29004.html seu navegador deve exibir um arquivo em HTML muito simples com duas linhas; |
#pressione o botão “refresh” no navegador (ou digite o URL novamente); | #pressione o botão “refresh” no navegador (ou digite o URL novamente); | ||
#pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP sejam apresentadas na janela de listagem de pacotes. | #pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP sejam apresentadas na janela de listagem de pacotes. | ||
Responda às seguintes questões: | Responda às seguintes questões: | ||
− | #Inspecione o conteúdo da primeira mensagem HTTP GET do seu navegador para o servidor | + | #Inspecione o conteúdo da primeira mensagem HTTP GET do seu navegador para o servidor docente.ifsc.edu.br. Você vê uma linha “If-Modified-Since”? |
#Inspecione o conteúdo da resposta do servidor. O servidor retornou explicitamente o conteúdo do arquivo? Como você pode dizer isso? | #Inspecione o conteúdo da resposta do servidor. O servidor retornou explicitamente o conteúdo do arquivo? Como você pode dizer isso? | ||
#Agora inspecione o conteúdo da segunda mensagem HTTP GET do seu navegador para o servidor. Você vê uma linha “If-Modified-Since”? Caso a resposta seja afirmativa, qual informação segue o cabeçalho “If-Modified-Since”? | #Agora inspecione o conteúdo da segunda mensagem HTTP GET do seu navegador para o servidor. Você vê uma linha “If-Modified-Since”? Caso a resposta seja afirmativa, qual informação segue o cabeçalho “If-Modified-Since”? | ||
Linha 486: | Linha 488: | ||
#limpe o cache do seu navegador; | #limpe o cache do seu navegador; | ||
#inicie o Wireshark; | #inicie o Wireshark; | ||
− | #digite o URL no navegador http:// | + | #digite o URL no navegador http://docente.ifsc.edu.br/odilson/RED29004/RED29004_arq2.html seu navegador deve exibir um documento bastante longo e criativo :) ; |
#Faça um atualização da página (F5); | #Faça um atualização da página (F5); | ||
#pare a captura de pacotes, e digite "http" na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas. | #pare a captura de pacotes, e digite "http" na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas. | ||
Linha 505: | Linha 507: | ||
#limpe o cache do seu navegador; | #limpe o cache do seu navegador; | ||
#inicie o Wireshark; | #inicie o Wireshark; | ||
− | #digite o URL no navegador http:// | + | #digite o URL no navegador http://docente.ifsc.edu.br/odilson/RED29004/RED29004_arq3.html seu navegador deve exibir um arquivo pequeno em HTML com duas imagens incluídas. Estas duas imagens estão referenciadas no arquivo em HTML. Isto é, as imagens não estão no arquivo em HTML, ao invés disso, há um URL para cada imagem no arquivo em HTML. Como discutido no livro, seu navegador terá que baixar estas imagens dos locais correspondentes. A imagem da esquerda, '''redesWL_network.jpeg''', está em ibxk.com.br. A imagem da direita, '''as-redes-sociais-como-instrumento-de-manipulacao-da-consciencia-coletiva.html.jpg''', está em lounge.obviousmag.org; |
#pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas. | #pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas. | ||
Linha 512: | Linha 514: | ||
#Para quais endereços na Internet estas mensagens foram enviadas? | #Para quais endereços na Internet estas mensagens foram enviadas? | ||
#Você consegue dizer se o seu navegador baixou as duas imagens em seqüência, ou se foram baixadas dos dois locais distintos em paralelo? Explique. | #Você consegue dizer se o seu navegador baixou as duas imagens em seqüência, ou se foram baixadas dos dois locais distintos em paralelo? Explique. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
===HTTPS=== | ===HTTPS=== | ||
Linha 549: | Linha 533: | ||
===Objetivos=== | ===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 | + | 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 | #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. | 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. | ||
Linha 561: | Linha 545: | ||
#* www.google.com | #* www.google.com | ||
#* www.gmail.com | #* www.gmail.com | ||
− | |||
− | |||
− | |||
# 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> | # 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 | ||
</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 | 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: | 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: | ||
Linha 576: | Linha 557: | ||
host -t mx ifsc.edu.br | host -t mx ifsc.edu.br | ||
dig -t mx ifsc.edu.br | dig -t mx ifsc.edu.br | ||
− | </syntaxhighlight>Descubra quem é o servidor | + | </syntaxhighlight>Descubra quem é o servidor de emails nos seguintes domínios: |
#* gmail.com | #* gmail.com | ||
#* hotmail.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> | # 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.180.10.13 | dig -x 200.180.10.13 | ||
− | </syntaxhighlight> ... o ''dig'' tem um resultado um pouco mais carregado que os outros utilitários (''host'' e ''nslookup''), porém neste caso é mais prático. Veja o resultado da consulta logo após a linha '';; ANSWER SECTION:''. Experimente fazer a resolução reversa para cada um dos IP obtidos nas consultas realizadas no primeiro exercício desta atividade. Pode-se também usar a variante do dig para respostas curtas: <code> | + | </syntaxhighlight> ... o ''dig'' tem um resultado um pouco mais carregado que os outros utilitários (''host'' e ''nslookup''), porém neste caso é mais prático. Veja o resultado da consulta logo após a linha '';; ANSWER SECTION:''. Experimente fazer a resolução reversa para cada um dos IP obtidos nas consultas realizadas no primeiro exercício desta atividade. Pode-se também usar a variante do ''dig'' para respostas curtas: <code> |
dig -x 200.180.10.13 +short | dig -x 200.180.10.13 +short | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Linha 596: | Linha 577: | ||
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 foram necessários consultar no total? | ## Quantos servidores DNS foram necessários consultar no total? | ||
− | ## Repita esse exercício para | + | ## Repita esse exercício para o seguinte nome de host: |
##* www.bbc.co.uk | ##* www.bbc.co.uk | ||
− | |||
− | |||
#Consultando um servidor explícito(@)<syntaxhighlight lang=bash> | #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> | ||
Linha 608: | Linha 587: | ||
##Qual o SLD consultado? | ##Qual o SLD consultado? | ||
##Como você sabe que foram esses os LDs consultados? | ##Como você sabe que foram esses os LDs consultados? | ||
+ | |||
+ | |||
+ | ===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 | ||
+ | ##webmail.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 | ||
===Analisando o protocolo via Wireshark=== | ===Analisando o protocolo via Wireshark=== | ||
Linha 629: | Linha 627: | ||
#examine a mensagem de resposta DNS. Quantos campos com “answer” existem? | #examine a mensagem de resposta DNS. Quantos campos com “answer” existem? | ||
#quais são os benefícios de usar o UDP ao invés do TCP como protocolo de transporte para o DNS? | #quais são os benefícios de usar o UDP ao invés do TCP como protocolo de transporte para o DNS? | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
{{Collapse bottom}} | {{Collapse bottom}} | ||
Linha 918: | Linha 652: | ||
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. | Como fica evidente na Figura acima, os processos cliente e servidor rodam em máquinas distintas e se comunicam justamente enviando mensagens via ''sockets'', que abstrai qualquer necessidade de conhecimento das camadas subjacentes. | ||
− | + | =====Roteiro===== | |
+ | #Observe que uma mesma máquina pode fazer o papel de cliente e servidor simultaneamente. | ||
+ | #Escreva o programa UDPServer.py <code> | ||
+ | #Esta linha define que pode-se utilizar sockets dentro do programa | ||
+ | from socket import * | ||
+ | #Define explicitamente a porta aberta servidor | ||
+ | serverPort = 22222 | ||
+ | #Cria o socket do servidor, denominado serverSocket. O primeiro parametro indica a familia do endereco, | ||
+ | #em particular, AF_INET indica que a rede subjacente esta usando IPv4. O segundo parametro indica que | ||
+ | #o socket eh do tipo SOCK_DGRAM, ou seja, eh um socket UDP. | ||
+ | serverSocket = socket(AF_INET, SOCK_DGRAM) | ||
+ | #Vincula o numero da porta, nesse caso 22222, ao socket do servidor e "abre a porta". | ||
+ | serverSocket.bind(('', serverPort)) | ||
+ | print "O servidor esta pronto para recepcao" | ||
+ | #Aguarda indefinidamente por contatos (mensagens) de clientes | ||
+ | while 1: | ||
− | UDPClient.py <code> | + | message, clientAddress = serverSocket.recvfrom(2048) |
+ | #Ao receber a mensagem do cliente converte todos os caracteres para maiusculas. | ||
+ | modifiedMessage = message.upper() | ||
+ | serverSocket.sendto(modifiedMessage, clientAddress) </syntaxhighlight> | ||
+ | #No terminal da máquina execute o programa: <code> | ||
+ | python UDPServer.py </syntaxhighlight> Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza eh sintaxe. Deixe o programa rodando nesse terminal. | ||
+ | #Abra um '''novo terminal''' e escreva o programa cliente. UDPClient.py <code> | ||
#Esta linha define que pode-se utilizar sockets dentro do programa | #Esta linha define que pode-se utilizar sockets dentro do programa | ||
from socket import * | from socket import * | ||
− | #Define o endereco ip do servidor ao qual o cliente contactara | + | #Define o endereco ip do servidor ao qual o cliente contactara. |
+ | #Lembre-se de ajustar ip_do_servidor para o numero adequado, ou seja, o IP de sua maquina ou de seu vizinho. | ||
serverName = 'ip_do_servidor' | serverName = 'ip_do_servidor' | ||
#Define a porta de acesso ao servidor | #Define a porta de acesso ao servidor | ||
Linha 944: | Linha 700: | ||
#Fecha o socket. | #Fecha o socket. | ||
clientSocket.close() </syntaxhighlight> | clientSocket.close() </syntaxhighlight> | ||
− | + | #No terminal da máquina execute o programa: <code> | |
− | + | python UDPClient.py </syntaxhighlight> Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe. | |
− | + | #Digite a mensagem que deseja e espere a resposta do servidor. Funcionou? | |
− | + | #Rode o WireShark. | |
− | + | #Execute novamente o cliente e servidor, se necessário, e capture os pacotes com o WireShark. Use um filtro do tipo: '''ip.addr == ip_do_servidor''', assim captura-se somente os pacotes originados/destinados ao servidor. Outra possibilidade de filtro é o filtro por número de porta: '''udp.port == 22222''' | |
− | + | #É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor? | |
− | + | #Qual é o protocolo nessa troca de mensagens? | |
− | # | + | #Qual são os dois números de porta e os dois IPs utilizados? |
− | + | #Quem definiu o número de porta do cliente? | |
− | + | #Combine com um colega e faça testes entre a sua máquina e dele. Num momento você é o servidor e noutro você é o cliente. | |
− | + | #Capture todos os pacotes trocados, entre você e seu vizinho, e responda as mesmas questões anteriores. Os números de portas e IPs são ou não iguais? Explique. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
===Programação de ''sockets'' com TCP=== | ===Programação de ''sockets'' com TCP=== | ||
Linha 978: | Linha 724: | ||
[[imagem:Programacao_socket_TCP_2.png|500px]] | [[imagem:Programacao_socket_TCP_2.png|500px]] | ||
− | + | =====Roteiro===== | |
− | + | #Escreva o código do programa servidor. TCPServer.py <code> | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | # | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | TCPServer.py <code> | ||
from socket import * | from socket import * | ||
serverPort = 33333 | serverPort = 33333 | ||
Linha 1 016: | Linha 743: | ||
connectionSocket.send(messageMaiuscula) | connectionSocket.send(messageMaiuscula) | ||
connectionSocket.close() </syntaxhighlight> | connectionSocket.close() </syntaxhighlight> | ||
− | + | #No terminal da máquina execute o programa: <code> | |
− | + | python TCPServer.py </syntaxhighlight> Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe. Deixe o programa rodando nesse terminal. | |
− | + | #Pode-se testar se a porta está aberta: <code> | |
− | + | nmap -p33333 ip_do_servidor </syntaxhighlight> | |
− | + | #Abra um '''novo terminal''' e escreva o programa cliente. TCPClient.py <code> | |
− | # | + | from socket import * |
− | + | serverName = 'ip_do_servidor' | |
− | + | serverPort = 33333 | |
− | + | #SOCK_STREAM habilita uso do TCP | |
− | + | clientSocket = socket(AF_INET, SOCK_STREAM) | |
− | + | #Representa o estabelecimento da conexao. E o "aperto de maos", onde o cliente e servidor trocam | |
− | + | #informacoes da portas que serao utilizadas pela conexao (socket) propriamente dito | |
− | + | clientSocket.connect((serverName,serverPort)) | |
− | + | message = raw_input('Entre com a sentanca em minuculas: ') | |
− | + | #Diferentemente do UDP, aqui nao e necessario encaminhar o endereco do servidor, ja que este socket | |
− | # | + | #eh uma "tubulacao" direta entre ambos, basta empurrar dados |
− | + | clientSocket.send(message) | |
− | + | modifiedMessage = clientSocket.recv(1024) | |
− | + | print 'Mensagem do servidor: ', modifiedMessage | |
+ | clientSocket.close() </syntaxhighlight> | ||
+ | #Digite a mensagem que deseja e espere a resposta do servidor. Funcionou? | ||
#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, se necessário, e capture os pacotes com o WireShark. Use um filtro do tipo: '''ip.addr == ip_do_servidor''', assim captura-se somente os pacotes originados/destinados ao servidor. Ou um filtro por número de porta. |
− | # | + | #É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor? |
− | # | + | #Qual é o protocolo nessa troca de mensagens? |
− | # | + | #Qual são os números de porta e os IPs utilizados? |
+ | #Quem definiu o número de porta do cliente? | ||
+ | #Combine com um colega e faça testes entre a sua máquina e dele. Num momento você é o servidor e noutro você é o cliente. | ||
+ | #Capture todos os pacotes trocados, entre você e seu vizinho, e responda as mesmas questões anteriores. Os números de portas e IPs são ou não iguais? Explique. | ||
+ | #Discuta: diferenças observadas entre os protocolos UDP e TCP? | ||
===Desafios para casa=== | ===Desafios para casa=== | ||
Linha 1 063: | Linha 796: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
# Observe o tamanho do arquivo transferido ... ele deve ter exatamente 1028653056 bytes (cerca de 981 MB). Você pode fazer isso com o comando '''ls -l ubuntu.iso''', ou executando o gerenciador de arquivos e visualizando as propriedades desse arquivo. | # Observe o tamanho do arquivo transferido ... ele deve ter exatamente 1028653056 bytes (cerca de 981 MB). Você pode fazer isso com o comando '''ls -l ubuntu.iso''', ou executando o gerenciador de arquivos e visualizando as propriedades desse arquivo. | ||
− | # Escolha um colega para fazer o experimento, em que o arquivo será transferido de um computador para o outro. | + | # Escolha um colega para fazer o experimento, em que o arquivo será transferido de um computador para o outro. |
+ | # Em ambos os experimentos deixe o WireShark capturando pacotes '''somente''' durante a transferência do arquivoTCP e arquivoUDP. | ||
# A primeira transferência será feita usando o protocolo TCP da seguinte forma: | # A primeira transferência será feita usando o protocolo TCP da seguinte forma: | ||
#* No computador receptor execute o '''netcat''' (utilize '''man nc''' para saber os detalhes das ''flags'' utilizadas) que abrirá uma conexão TCP na porta, por exemplo, 5555 e salvará os dados transferidos em '''arquivo''': <syntaxhighlight lang=bash> | #* No computador receptor execute o '''netcat''' (utilize '''man nc''' para saber os detalhes das ''flags'' utilizadas) que abrirá uma conexão TCP na porta, por exemplo, 5555 e salvará os dados transferidos em '''arquivo''': <syntaxhighlight lang=bash> | ||
Linha 1 072: | Linha 806: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
#* Quando completar a transferência, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo? | #* Quando completar a transferência, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo? | ||
+ | #* Analisando a captura de pacotes do WireShark responda: | ||
+ | ## Qual é o identificar do primeiro e do último pacote? | ||
+ | ## É possível calcular o tamanho do arquivo pela análise dos pacotes? Qual é a maneira mais fácil? Apresente os cálculos. | ||
# A segunda transferência será feita usando o protocolo UDP: | # A segunda transferência será feita usando o protocolo UDP: | ||
#* No computador receptor baixe o programa '''receptor''', acrescente a ele permissão de execução e o execute, conforme a sequência de comandos abaixo: <syntaxhighlight lang=bash> | #* No computador receptor baixe o programa '''receptor''', acrescente a ele permissão de execução e o execute, conforme a sequência de comandos abaixo: <syntaxhighlight lang=bash> | ||
Linha 1 084: | Linha 821: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
#* Quando completar a transferência (vai aparecer a mensagem no transmissor "Levou XXXXX segundos para transmitir XXXXX bytes), no receptor digite <CTRL + C>, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo? | #* Quando completar a transferência (vai aparecer a mensagem no transmissor "Levou XXXXX segundos para transmitir XXXXX bytes), no receptor digite <CTRL + C>, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo? | ||
+ | #* Analisando a captura de pacotes do WireShark responda: | ||
+ | ## Qual é o identificar do primeiro e do último pacote? Existe? | ||
+ | ## É possível calcular o tamanho do arquivo pela análise dos pacotes? É mais fácil ou difícil que no caso da transferência via TCP? | ||
# 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 175: | Linha 915: | ||
##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'''. Observe que ao usar o wireshark com o Netkit, o wireshark não é dinâmico, ou seja, de tempos em tempos deves recarregar (''reload'') a captura de pacotes). |
+ | ###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''', antes de fechar o Netkit, 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' | + | ##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 enlace. | #Testando a queda de enlace. | ||
Linha 1 215: | Linha 958: | ||
localizados normalmente no diretório ''/etc/quagga'' e possuindo a terminação | localizados normalmente no diretório ''/etc/quagga'' e possuindo a terminação | ||
''conf'': por exemplo: ''zebra.conf'' para o processo ''zebra''. | ''conf'': por exemplo: ''zebra.conf'' para o processo ''zebra''. | ||
− | Entretanto será comum usarmos arquivos de configuração fornecidos na linha de | + | Entretanto, em nossos laboratórios, fazendo uso do Netkit, será comum usarmos arquivos de configuração fornecidos na linha de |
comando: | comando: | ||
Linha 1 234: | Linha 977: | ||
#Reinicie o NetKit2 e releia o arquivo de configuração '''exp1.conf'''. | #Reinicie o NetKit2 e releia o arquivo de configuração '''exp1.conf'''. | ||
#Repita o item 5.4 do '''Experimento 1'''. | #Repita o item 5.4 do '''Experimento 1'''. | ||
− | #Em cada roteador, configure o serviço RIP para que que os testes da próxima etapa possam ser executados. O Netkit cria no home do usuário uma pasta chamada "lab". Nesta pasta, há uma pasta para cada equipamento da rede em teste. Neste diretório podem ser colocados arquivos de configuração de serviços a serem executados nas máquinas virtuais do Netkit. É por ali que será configurado, primeiramente, o Quagga, software de roteamento que implementa RIP, OSPF e BGP. O arquivo de configuração abaixo mostra a configuração do Quagga para o roteador '''r1'''. Salve este arquivo com o nome '''zebra.conf''' no diretório '''lab/r1/'''. Em seguida, adapte o arquivo para os roteadores '''r2''' e '''r3''' observando a figura do diagrama da rede para não errar os IPs.<syntaxhighlight lang=text> | + | #Em cada roteador, configure o serviço RIP para que que os testes da próxima etapa possam ser executados. O Netkit cria no home do usuário uma pasta chamada "lab". Nesta pasta, há uma pasta para cada equipamento da rede em teste. Neste diretório podem ser colocados arquivos de configuração de serviços a serem executados nas máquinas virtuais do Netkit. É por ali que será configurado, primeiramente, o Quagga, software de roteamento que implementa RIP, OSPF e BGP. O arquivo de configuração abaixo mostra a configuração do Quagga para o roteador '''r1'''. Salve este arquivo com o nome '''zebra.conf''' no diretório '''/home/aluno/lab/r1/'''. Em seguida, adapte o arquivo para os roteadores '''r2''' e '''r3''' observando a figura do diagrama da rede para não errar os IPs.<syntaxhighlight lang=text> |
hostname r1 | hostname r1 | ||
Linha 1 246: | Linha 989: | ||
log stdout | log stdout | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | #Crie os arquivos de configuração para o RIP em cada roteador, colocando-os dentro dos diretórios dos mesmos. O nome destes arquivos deve ser '''ripd.conf''' e o conteúdo deve ser o abaixo.<syntaxhighlight lang=text> | + | #Crie os arquivos de configuração para o RIP em cada roteador, colocando-os dentro dos diretórios dos mesmos, por exemplo, para '''r1''' no diretório '''/home/aluno/lab/r1/'''. O nome destes arquivos deve ser '''ripd.conf''' e o conteúdo deve ser o abaixo.<syntaxhighlight lang=text> |
router rip | router rip | ||
redistribute connected | redistribute connected | ||
Linha 1 256: | Linha 999: | ||
#Deixe o ping rodando! | #Deixe o ping rodando! | ||
#Inicie o ''daemon'' ''quagga'' em todos os roteadores (r1, r2 e r3). <code> service quagga start </syntaxhighlight> | #Inicie o ''daemon'' ''quagga'' em todos os roteadores (r1, r2 e r3). <code> service quagga start </syntaxhighlight> | ||
− | #Execute o Quagga e o RIP a partir dos arquivos criados. Os arquivos que estão na pasta "/home/ | + | #Execute o Quagga e o RIP a partir dos arquivos criados. Os arquivos que estão na pasta "/home/aluno/lab" são montados na pasta "/hostlab/" de todas as máquinas virtuais do Netkit, ou seja, "/home/aluno/lab" na máquina rela é a mesmoa pasta que "/hostlab/" nas máquinas virtuais do Netkit. Para iniciar os serviços no '''r1''', faça algo como o que está no exemplo abaixo. Repita o procedimento para '''r2''' e '''r3''' utilizando os arquivos corretos.<syntaxhighlight lang=bash> |
zebra -d -f /hostlab/r1/zebra.conf | zebra -d -f /hostlab/r1/zebra.conf | ||
ripd -d -f /hostlab/r1/ripd.conf | ripd -d -f /hostlab/r1/ripd.conf | ||
Linha 1 272: | Linha 1 015: | ||
# Com o '''route -n''' e/ou '''netstat -r''' verifique a anote as rotas de cada roteador. | # Com o '''route -n''' e/ou '''netstat -r''' verifique a anote as rotas de cada roteador. | ||
#Pare todos os pings. | #Pare todos os pings. | ||
− | #Execute | + | #Execute '''tcpdump -i any -w /hostlab/ripr1.pcap &''' no '''r1''' |
− | #Com o | + | #Com o navegador de arquivos entre na pasta '''/home/aluno/lab/''' e dê um duplo click no arquivo '''ripr1.pcap''' e tente compreender as mensagens RIPv2 (UDP 17) trocadas. Olhe com atenção os IPs e as métricas apresentadas. O que dizem essas mensagens? |
+ | #Com o tcpdump rodando em '''r1''', desative um dos enlaces entre os roteadores e acompanhe a troca de mensagens no Wireshark (dê um ''reload''). Por questões de compatibilidade vamos desativar uma interface de um modo especial. Por exemplo, para "derrubar" o enlace r1-r2, execute no '''r1''': <code> | ||
vtysh 2061 entra no zebrad | vtysh 2061 entra no zebrad | ||
conf t entra no mode de configuração | conf t entra no mode de configuração | ||
Linha 1 279: | Linha 1 023: | ||
shutdown desativa a interface, se desejado | shutdown desativa a interface, se desejado | ||
no shutdown restaura a interface, se desejado </syntaxhighlight> | no shutdown restaura a interface, se desejado </syntaxhighlight> | ||
− | #Permaneça monitorando o ping e o Wireshark, a recuperação das rotas leva em torno de 1 min | + | #Permaneça monitorando o ping e o Wireshark (''reload''), a recuperação das rotas leva em torno de 1 min: |
+ | ##Quais as mensagens trocadas pelo protocolo RIP observadas no WireShark? | ||
+ | ##Qual o tempo aproximado para a total recuperação das rotas? | ||
#Teste as conectividades. O que aconteceu? | #Teste as conectividades. O que aconteceu? | ||
− | #Retrace as rotas com | + | #Retrace as rotas com nos roteadores <code> vtysh 2061 |
+ | show ip route </syntaxhighlight> e com o <code> traceroute </syntaxhighlight> a partir dos PCs. | ||
+ | ##São diferentes do caso original (todos enlaces ativos)? Por quê? | ||
+ | ##Quais os caminhos que foram reescritos? Por quê? | ||
==Experimento 3: protocolos e roteamento OSPF== | ==Experimento 3: protocolos e roteamento OSPF== | ||
Linha 1 344: | Linha 1 093: | ||
#Os arquivos '''zebra.conf''' são os mesmos utilizados no experimento 2. | #Os arquivos '''zebra.conf''' são os mesmos utilizados no experimento 2. | ||
#Inicie o ''daemon'' ''quagga'' em todos os roteadores (r1, r2 e r3). <code> service quagga start </syntaxhighlight> | #Inicie o ''daemon'' ''quagga'' em todos os roteadores (r1, r2 e r3). <code> service quagga start </syntaxhighlight> | ||
− | #Execute o Quagga e o OSPF a partir dos arquivos criados. Os arquivos que estão na pasta "/home/ | + | #Execute o Quagga e o OSPF a partir dos arquivos criados. Os arquivos que estão na pasta "/home/aluno/lab" são montados na pasta "/hostlab/" de todas as máquinas virtuais do NetKit. Para iniciar os serviços no '''r1''', faça algo como o que está no exemplo abaixo. Repita o procedimento para '''r2''' e '''r3''' utilizando os arquivos corretos.<code> |
zebra -d -f /hostlab/r1/zebra.conf | zebra -d -f /hostlab/r1/zebra.conf | ||
ospfd -d -f /hostlab/r1/ospfd.conf </syntaxhighlight> | ospfd -d -f /hostlab/r1/ospfd.conf </syntaxhighlight> | ||
− | # | + | #Repita, na medida do possível e fazendo os devidos ajustes, as atividades 11 a 19 do experimento anterior e responda, além das respectivas questões desses itens: |
− | #As mensagens trocadas pelos roteadores são distintas quando comparadas ao uso do RIP? | + | ##As mensagens trocadas pelos roteadores são distintas quando comparadas ao uso do RIP? |
− | #Houve diferença no tempo de atualização das rotas quando comparado ao RIP? Por quê? | + | ##Houve diferença no tempo de atualização das rotas quando comparado ao RIP? Por quê? |
{{Collapse bottom}} | {{Collapse bottom}} | ||
Linha 1 355: | Linha 1 104: | ||
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/]. | ||
− | Slides de [http:// | + | Slides de [http://docente.ifsc.edu.br/odilson/RED29004/IPv6_e_MIPv6.pdf endereçamento IPv6]. |
− | [http:// | + | [http://docente.ifsc.edu.br/odilson/RED29004/enderec-v6.pdf Guia didático de endereçamento IPv6] obtido de http://ipv6.br/. |
===Objetivos do laboratório:=== | ===Objetivos do laboratório:=== | ||
Linha 1 482: | Linha 1 231: | ||
#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 | + | #Em cada uma das máquinas virtuais, use o comando '''fg tcpdump''' para trazer o '''tcpdump''' para o primeiro plano. Em seguida encerre a captura com '''Ctrl + C'''. |
#Estude os '''.pcaps''' gerados utilizando o '''wireshark''': abra o '''wireshark''', '''File/Open''' e procure os arquivo na pasta /home/aluno/lab. Clique sobre cada um deles e faça a análise. | #Estude os '''.pcaps''' gerados utilizando o '''wireshark''': abra o '''wireshark''', '''File/Open''' e procure os arquivo na pasta /home/aluno/lab. Clique sobre cada um deles e faça a análise. | ||
#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'''. | ||
Linha 1 525: | Linha 1 274: | ||
* ''Grupos e Temas para 2016-1'': | * ''Grupos e Temas para 2016-1'': | ||
+ | #Luísa Machado e Natália A. Miranda: '''IPv6''': 19/07 | ||
+ | #Jessica e Jeferson: '''PLC''': 19/07 | ||
+ | #Anderson: '''IEEE 802.15.4''': 19/07 | ||
+ | #Angelo e Thiago: '''Puppet''': 22/07 | ||
+ | #Vitor e Marina: '''VPN''': 22/07 | ||
+ | #Daniel e José Augusto: '''VANETs''': 22/07 | ||
* Avaliação | * Avaliação | ||
+ | ** [http://docente.ifsc.edu.br/odilson/RED29004/Avaliacao%20dos%20relatorios%20e%20apresentacao.pdf Avaliação do relatórios e apresentações] | ||
** Nota: 0,5 x Documento + 0,5 x Seminário | ** Nota: 0,5 x Documento + 0,5 x Seminário | ||
− | **[http:// | + | **[http://docente.ifsc.edu.br/odilson/RED29004/Criterio%20de%20avaliacao%20dos%20relatorios%20e%20apresentacao.pdf Critérios de avaliação] |
* ''Instruções sobre o Seminário de Redes I'': | * ''Instruções sobre o Seminário de Redes I'': | ||
− | ** Data para definição de grupos e temas: ''' | + | ** Data para definição de grupos e temas: '''24/05/2013'''. |
** 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: '''17/06/2016''' (impreterivelmente). |
** O relatório pode ser redigido como uma página da wiki. | ** O relatório pode ser redigido como uma página da wiki. | ||
** Duração da apresentação: 20 minutos (limitantes: 15 a 25 minutos) + 5 minutos de perguntas. | ** Duração da apresentação: 20 minutos (limitantes: 15 a 25 minutos) + 5 minutos de perguntas. | ||
Linha 1 558: | Linha 1 314: | ||
# Introdução às redes de computadores | # Introdução às redes de computadores | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
+ | |||
+ | Aula 2 - 29/03/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%201%20Redes%20de%20computadores%20e%20a%20Internet.pdf Introdução as redes de computadores] | ||
+ | |||
+ | Aula 3 - 01/04/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%201%20Redes%20de%20computadores%20e%20a%20Internet.pdf Comutação de circuitos versus comutação de pacotes] | ||
+ | |||
+ | Aula 4 - 05/04/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%201%20Redes%20de%20computadores%20e%20a%20Internet.pdf Conceitos de protocolos e camada de aplicação] | ||
+ | |||
+ | Aula 5 - 08/04/16: Laboratório 1 - Ferramentas básicas | ||
+ | |||
+ | Aula 6 - 12/04/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%202%20Camada%20de%20aplica%C3%A7%C3%A3o.pdf Camada de aplicação + HTTP] | ||
+ | |||
+ | Aula 7 - 15/04/16: Laboratório 2 - HTTP | ||
+ | |||
+ | Aula 8 - 19/04/16: Aula suspensa, banca de tese de doutorado | ||
+ | |||
+ | Aula 9 - 22/04/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%202%20Camada%20de%20aplica%C3%A7%C3%A3o.pdf FTP, Correio eletrônico e DNS] | ||
+ | |||
+ | Aula 10 - 26/04/16: Laboratório 3 - DNS | ||
+ | |||
+ | Aula 11 - 29/04/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%203%20Camada%20de%20transporte.pdf Início da camada de transporte] | ||
+ | |||
+ | Aula 12 - 03/05/16: Laboratório 4 | ||
+ | |||
+ | Aula 13 - 06/05/16: Dúvidas para primeira avaliação | ||
+ | |||
+ | Aula 14 - 10/05/16: Primeira avaliação | ||
+ | |||
+ | Aula 14 - 13/05/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%203%20Camada%20de%20transporte.pdf Camada de transporte] | ||
+ | |||
+ | Aula 15 - 14/05/16: Laboratório 5 - TCP x UDP | ||
+ | |||
+ | Aula 16 - 17/05/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%203%20Camada%20de%20transporte.pdf Camada de transporte] | ||
+ | |||
+ | Aula 17 - 20/05/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%203%20Camada%20de%20transporte.pdf Camada de transporte] | ||
+ | |||
+ | Aula 18 - 24/05/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Camada de Rede] | ||
+ | |||
+ | Aula 19 - 27/05/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Camada de Rede] | ||
+ | |||
+ | Aula 20 - 31/05/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Camada de Rede] | ||
+ | |||
+ | Aula 21 - 03/06/16: Dúvidas para avaliação 2 | ||
+ | |||
+ | Aula 22 - 04/06/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Camada de Rede] | ||
+ | |||
+ | Aula 23 - 07/06/16: Avaliação 2 | ||
+ | |||
+ | Aula 24 - 10/06/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Camada de Rede] | ||
+ | |||
+ | Aula 25 - 14/06/16: Laboratório 6 - Protocolos de Roteamento | ||
+ | |||
+ | Aula 26 - 17/06/16: Laboratório 7 - Protocolos de Roteamento (cont.) | ||
+ | |||
+ | Aula 27 - 21/06/16: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Camada de Rede] | ||
+ | |||
+ | Aula 28 - 24/06/16: [http://docente.ifsc.edu.br/odilson/RED29004/IPv6-3.pdf IPv6] | ||
+ | |||
+ | Aula 29 - 28/06/16: Laboratório IPv6 | ||
+ | |||
+ | Aula 30 - 01/07/16: Aplicação e protocolos para sinalização/comunicação multimídia (SIP e RTP) | ||
+ | |||
+ | Aula 31 - 05/07/16: Introdução a camada de enlace | ||
+ | |||
+ | Aula 32 - 08/07/16: Dúvidas para avaliação 3 | ||
+ | |||
+ | Aula 33 - 12/07/16: Avaliação 3 | ||
+ | |||
+ | Aula 34 - 15/07/16: Apresentação dos seminários | ||
+ | |||
+ | Aula 35 - 19/07/16: Apresentação dos seminários | ||
+ | |||
+ | Aula 36 - 22/07/16: Apresentação dos seminários | ||
+ | |||
+ | Aula 37 - 26/07/16: Reavaliação final |
Edição atual tal como às 13h28min de 27 de julho de 2016
Diário de aula de RED29004 - 2016-1 - Prof. Odilson T. Valle
Dados Importantes
Professor: Odilson Tadeu Valle
Email: odilson@ifsc.edu.br
Atendimento paralelo: 3ª das 9h40 às 10h35 e 6ª das 14h25 às 15h20. Local: Lab. de Desenvolvimento.
Conceitos finais Conceitos finais numéricos
- Avaliações
- 3 avaliações (A1, A2 e A3) 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 2016-1 - Prof. Odilson T. Valle
Material de apoio
Applets do Kurose
Vários aplicativos com representação dinâmica de características das redes de computadores.
Listas de exercícios
Lista de exercícios 1 - Introdução |
---|
|
Lista de exercícios 2 - Camada de Aplicação |
---|
|
Lista de exercícios 3 - Camada de Transporte |
---|
|
Lista de exercícios 4 - Camada de Rede | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Lista de exercícios 5 - Camada de Enlace e Redes Multimídia |
---|
|
Transparências utilizadas durante as aulas
Slides do Kurose referentes ao capítulo 1
Slides do Kurose referentes ao capítulo 2
Slides do Prof. Emerson - DNS, FTP, Web, Email...
Slides do Kurose referentes ao capítulo 7
Slides do Kurose referentes ao capítulo 3 e versão antiga
Slides do Kurose referentes ao capítulo 4
Slides do Kurose referentes ao capítulo 5
Roteiros para laboratório
Laboratório 1 - Ping, Traceroute e Wireshark |
---|
Objetivos
Conceitos introdutórios para uso do laboratórioA rede do laboratório em uso segue o modelo apresentado no diagrama da Figura 1. Máquinas virtuaisEventualmente serão utilizadas nessa disciplina. Os Laboratórios de Redes de Computadores estão equipados com N+1 (N = número de computadores para alunos) computadores conectados em rede e com acesso a Internet, Figura 1. A rede local do laboratório tem endereço IP 192.168.?.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:
HTTPSPara finalizar, vamos capturar sequências de mensagens HTTPS, somente a título de comparação. Execute os seguintes procedimentos:
Responda:
|
Laboratório 3 - Serviço de Nomes (DNS) |
---|
ObjetivosO Domain Name System (DNS) traduz nomes de hosts em endereços Internet Protocol (IP), preenchendo uma lacuna crítica na infraestrutura da Internet. Neste laboratório, observaremos mais de perto:
Lembre-se de que o papel do cliente no DNS é relativamente simples - um cliente envia uma consulta ao seu DNS, e obtém uma resposta. Muito pode acontecer “por baixo dos panos”, de forma invisível aos clientes DNS, enquanto os servidores DNS, organizados hierarquicamente, comunicam-se entre si para, ou recursivamente ou iterativamente, resolver uma consulta DNS de um cliente. Do ponto de vista do cliente DNS, contudo, o protocolo é bastante simples - uma consulta é feita ao seu servidor DNS e uma resposta é recebida deste servidor. Consultas DNS por meio de ferramentas especializadas
|
Laboratório 4 - Entendendo sockets |
---|
ObjetivosEntender o conceito de sockets. Processos que rodam em máquinas diferentes se comunicam entre si enviando mensagens para sockets. Um processo é semelhante a uma casa e o socket do processo é semelhante a uma porta. A aplicação reside dentro da casa e o protocolo da camada de transporte reside no mundo externo. Um programador de aplicação controla o interior da casa mas tem pouco (ou nenhum) controle sobre o exterior. Descrição da aplicação a ser desenvolvida em UDP e TCP
Programação de sockets com UDPA aplicação cliente-servidor usando UDP tem a estrutura apresentada na Figura baixo. Utilizamos a linguagem Python por expor com clareza os principais conceitos de sockets. Quem desejar pode implementar em outras linguagens, por exemplo um modelo para programação de sockets utilizando a API Posix encontra-se aqui. Como fica evidente na Figura acima, os processos cliente e servidor rodam em máquinas distintas e se comunicam justamente enviando mensagens via sockets, que abstrai qualquer necessidade de conhecimento das camadas subjacentes. Roteiro
|
Laboratório 5 - TCP x UDP |
---|
ObjetivosO objetivo desses experimentos é evidenciar as diferenças entre os protocolos TCP e UDP. Ambos protocolos de transporte podem ser usados por aplicações que precisem se comunicar. Porém cada um deles têm certas propriedades, então a escolha precisa ser realizada baseada no tipo de comunicação a ser feita pela aplicação. Experimento 1O que aconteceria se um arquivo fosse transferido de um computador a outro com ambos protocolos?
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 - Neighbor Discovery no IPv6 |
---|
Este roteiro foi baseado no material disponível em [1]. Slides de endereçamento IPv6. Guia didático de endereçamento IPv6 obtido de http://ipv6.br/. Objetivos do laboratório:
Introdução teóricaObs.: texto copiado literalmente de: Laboratório de IPv6. A descoberta de vizinhança por meio do protocolo Neighbor Discovery no IPv6 é um procedimento realizado pelos nós de uma rede para descobrir endereços físicos dos dispositivos vizinhos presentes no mesmo enlace. A função deste protocolo se assemelha à função do ARP e do RARP no IPv4. 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 2016-1:
- Luísa Machado e Natália A. Miranda: IPv6: 19/07
- Jessica e Jeferson: PLC: 19/07
- Anderson: IEEE 802.15.4: 19/07
- Angelo e Thiago: Puppet: 22/07
- Vitor e Marina: VPN: 22/07
- Daniel e José Augusto: VANETs: 22/07
- Avaliação
- Avaliação do relatórios e apresentações
- Nota: 0,5 x Documento + 0,5 x Seminário
- Critérios de avaliação
- Instruções sobre o Seminário de Redes I:
- Data para definição de grupos e temas: 24/05/2013.
- 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: 17/06/2016 (impreterivelmente).
- O relatório pode ser redigido como uma página da wiki.
- Duração da apresentação: 20 minutos (limitantes: 15 a 25 minutos) + 5 minutos de perguntas.
- As apresentações podem ser realizadas seguindo o conteúdo do relatório (use bastante figuras no relatório, isto facilita a apresentação).
- Se preferirem usar slides, usem esse modelo.
Diário de aulas
Aula 1 - 22/03/16: Apresentação da disciplina |
---|
|
Aula 2 - 29/03/16: Introdução as redes de computadores
Aula 3 - 01/04/16: Comutação de circuitos versus comutação de pacotes
Aula 4 - 05/04/16: Conceitos de protocolos e camada de aplicação
Aula 5 - 08/04/16: Laboratório 1 - Ferramentas básicas
Aula 6 - 12/04/16: Camada de aplicação + HTTP
Aula 7 - 15/04/16: Laboratório 2 - HTTP
Aula 8 - 19/04/16: Aula suspensa, banca de tese de doutorado
Aula 9 - 22/04/16: FTP, Correio eletrônico e DNS
Aula 10 - 26/04/16: Laboratório 3 - DNS
Aula 11 - 29/04/16: Início da camada de transporte
Aula 12 - 03/05/16: Laboratório 4
Aula 13 - 06/05/16: Dúvidas para primeira avaliação
Aula 14 - 10/05/16: Primeira avaliação
Aula 14 - 13/05/16: Camada de transporte
Aula 15 - 14/05/16: Laboratório 5 - TCP x UDP
Aula 16 - 17/05/16: Camada de transporte
Aula 17 - 20/05/16: Camada de transporte
Aula 18 - 24/05/16: Camada de Rede
Aula 19 - 27/05/16: Camada de Rede
Aula 20 - 31/05/16: Camada de Rede
Aula 21 - 03/06/16: Dúvidas para avaliação 2
Aula 22 - 04/06/16: Camada de Rede
Aula 23 - 07/06/16: Avaliação 2
Aula 24 - 10/06/16: Camada de Rede
Aula 25 - 14/06/16: Laboratório 6 - Protocolos de Roteamento
Aula 26 - 17/06/16: Laboratório 7 - Protocolos de Roteamento (cont.)
Aula 27 - 21/06/16: Camada de Rede
Aula 28 - 24/06/16: IPv6
Aula 29 - 28/06/16: Laboratório IPv6
Aula 30 - 01/07/16: Aplicação e protocolos para sinalização/comunicação multimídia (SIP e RTP)
Aula 31 - 05/07/16: Introdução a camada de enlace
Aula 32 - 08/07/16: Dúvidas para avaliação 3
Aula 33 - 12/07/16: Avaliação 3
Aula 34 - 15/07/16: Apresentação dos seminários
Aula 35 - 19/07/16: Apresentação dos seminários
Aula 36 - 22/07/16: Apresentação dos seminários
Aula 37 - 26/07/16: Reavaliação final