Mudanças entre as edições de "RED29004-2015-1"
(99 revisões intermediárias por 2 usuários não estão sendo mostradas) | |||
Linha 12: | Linha 12: | ||
'''IMPORTANTE:''' o direito de recuperar uma avaliação em que se faltou somente existe mediante justificativa reconhecida pela coordenação. Assim, deve-se protocolar a justificativa no prazo de 48 horas, contando da data e horário da avaliação e aguardar o parecer da coordenação. | '''IMPORTANTE:''' o direito de recuperar uma avaliação em que se faltou somente existe mediante justificativa reconhecida pela coordenação. Assim, deve-se protocolar a justificativa no prazo de 48 horas, contando da data e horário da avaliação e aguardar o parecer da coordenação. | ||
+ | |||
+ | <span style="font-size:100%; line-height: 1.3em;">[http://www.sj.ifsc.edu.br/~odilson/RED29004/DIARIO%202015-1%20RED29004.pdf Conceitos Finais]</span> | ||
==[[RED1-EngTel_(Plano_de_Ensino)|Plano de Ensino]]== | ==[[RED1-EngTel_(Plano_de_Ensino)|Plano de Ensino]]== | ||
Linha 65: | Linha 67: | ||
Vários [http://wps.aw.com/aw_kurose_network_4/63/16303/4173752.cw/index.html aplicativos] com representação dinâmica de características das redes de computadores. | Vários [http://wps.aw.com/aw_kurose_network_4/63/16303/4173752.cw/index.html aplicativos] com representação dinâmica de características das redes de computadores. | ||
− | == Listas de exercícios | + | == Listas de exercícios== |
{{Collapse top |Lista de exercícios 1}} | {{Collapse top |Lista de exercícios 1}} | ||
Linha 176: | Linha 178: | ||
#Porque se diz que a Internet implementa um serviço de melhor esforço? Que tipo de garantias são oferecidas neste modelo de serviço? | #Porque se diz que a Internet implementa um serviço de melhor esforço? Que tipo de garantias são oferecidas neste modelo de serviço? | ||
#Quais as principais diferenças entre os serviços oferecidos pelas redes de datagramas (Internet) e redes ATM? | #Quais as principais diferenças entre os serviços oferecidos pelas redes de datagramas (Internet) e redes ATM? | ||
+ | #Quais são as funções mais importantes da camada de rede em uma rede de datagramas? Quais são as três funções mais importantes de rede em uma rede de circuitos virtuais? | ||
#O que é um protocolo de roteamento? | #O que é um protocolo de roteamento? | ||
#Como podem ser classificados os algoritmos de roteamento? | #Como podem ser classificados os algoritmos de roteamento? | ||
− | #Roteadores possuem endereços IP? Quantos endereços IP um roteador possui? | + | #Roteadores possuem endereços IP? Quantos endereços IP um roteador possui? |
− | # | + | #Qual é a diferença básica entre protocolos de roteamento “Estado de Enlaces” e “Vetor de Distância”? |
+ | #Em uma rede largamente dispersa, com centenas de roteadores, você recomendaria a adoção de um protocolo de roteamento do tipo “Estado de Enlaces” ou “Vetor de Distâncias”? Justifique. | ||
+ | #Explique o funcionamento de um algoritmo de roteamento do tipo “Vetor de Distâncias”. | ||
+ | #A Internet usa o conceito de “roteamento hierárquico”. O que significa isso? | ||
+ | #Um roteador em uma rede de pacotes (como é o caso da Internet) pode eventualmente necessitar descartar um datagrama. Por que isso ocorre? | ||
+ | #Um roteador em uma rede de pacotes (como é o caso da Internet) pode eventualmente necessitar fragmentar um datagrama. Por que isso ocorre? | ||
+ | #O que é um Sistema Autônomo (AS)? | ||
+ | #Para que serve o protocolo ICMP? | ||
+ | #Para que serve o campo “Time to Live” (sobrevida) em um datagrama IP? | ||
+ | #Por que são usados protocolos inter-AS e intra-AS diferentes na Internet? | ||
+ | #Por que considerações políticas/econômicas não são tão importantes para protocolos intra-AS, como OSPF e RIP, quanto par um protocolo de roteamento inter-AS, como BGP? | ||
#Quantos hosts podem ser endereçados com um bloco IP 200.23.16.0/20? Como podemos montar 8 sub-redes a partir deste bloco de endereços IP? | #Quantos hosts podem ser endereçados com um bloco IP 200.23.16.0/20? Como podemos montar 8 sub-redes a partir deste bloco de endereços IP? | ||
#Um provedor de serviços ISP possui cerca de 2000 clientes cadastrados atualmente. Porém um levantamento realizado recentemente pelo administrador da rede constatou que nunca mais do que 450 clientes estão on-line ao mesmo tempo. Qual o bloco de endereços IP na forma CIDR (a.b.c.d/x) deve ser contratado pelo ISP, considerando o estudo realizado pelo administrador da rede? | #Um provedor de serviços ISP possui cerca de 2000 clientes cadastrados atualmente. Porém um levantamento realizado recentemente pelo administrador da rede constatou que nunca mais do que 450 clientes estão on-line ao mesmo tempo. Qual o bloco de endereços IP na forma CIDR (a.b.c.d/x) deve ser contratado pelo ISP, considerando o estudo realizado pelo administrador da rede? | ||
Linha 198: | Linha 211: | ||
##Qual o endereço de broadcast de cada sub-rede dos novos clientes? | ##Qual o endereço de broadcast de cada sub-rede dos novos clientes? | ||
##Quantos endereços IP ainda sobrarão ao provedor após atender a estes clientes? | ##Quantos endereços IP ainda sobrarão ao provedor após atender a estes clientes? | ||
− | # | + | #Quantas estações uma rede 223.1.10.0/24 suporta? |
− | + | #Uma rede com bloco de IPs 200.23.16.0/20 deseja montar 8 subredes. Mostre como isso é possível e como ficaria os endereços de cada uma dessas subredes. | |
− | |||
− | |||
− | # | ||
− | |||
#Um datagrama de 4000 bytes precisa ser fragmentado para passar por um roteador cujo enlace tem MTU de 1500 bytes. Mostre esquematicamente como ficam os datagramas que são gerados a partir dessa fragmentação. | #Um datagrama de 4000 bytes precisa ser fragmentado para passar por um roteador cujo enlace tem MTU de 1500 bytes. Mostre esquematicamente como ficam os datagramas que são gerados a partir dessa fragmentação. | ||
− | #Considere enviar um datagrama de 2400 bytes por um enlace que tenha | + | #Considere enviar um datagrama de 2400 bytes por um enlace que tenha uma MTU de 700 bytes. Suponha que o datagrama original esteja marcado com o número de identificação 422. Quantos fragmentos são gerados? Quais são os valores em vários campos dos datagramas IPs gerados em relação à fragmentação? |
#Um datagrama enviado para uma estação da mesma rede precisa passar por um roteador? | #Um datagrama enviado para uma estação da mesma rede precisa passar por um roteador? | ||
#Suponha que entre o hospedeiro de origem A e o hospedeiro de destino B os datagramas estejam limitados a 1500 bytes (incluindo cabeçalho). Admitindo um cabeçalho IP de 20 bytes, quantos datagramas seriam necessários para enviar um arquivo MP3 de 5 milhões de bytes? Explique como você obteve a resposta. | #Suponha que entre o hospedeiro de origem A e o hospedeiro de destino B os datagramas estejam limitados a 1500 bytes (incluindo cabeçalho). Admitindo um cabeçalho IP de 20 bytes, quantos datagramas seriam necessários para enviar um arquivo MP3 de 5 milhões de bytes? Explique como você obteve a resposta. | ||
− | #Qual é a diferença básica de um endereço IP baseado em classes cheias (classful) e um sem classes (classles – CIDR)? | + | #Qual é a diferença básica de um endereço IP baseado em classes cheias (classful) e um sem classes (classles – CIDR)? |
− | |||
− | |||
− | |||
− | |||
− | |||
#Descreva e detalhe o processo de obtenção de um endereço IP através do protocolo DHCP. | #Descreva e detalhe o processo de obtenção de um endereço IP através do protocolo DHCP. | ||
#Descreva e detalhe o processo de tradução de endereços de rede - NAT. Com o NAT é possível somente a conversão (troca) do número de portas? Explique. | #Descreva e detalhe o processo de tradução de endereços de rede - NAT. Com o NAT é possível somente a conversão (troca) do número de portas? Explique. | ||
#Compare os campos de cabeçalho do IPv4 e do IPv6e aponte suas diferenças. Eles tem algum campo em comum? | #Compare os campos de cabeçalho do IPv4 e do IPv6e aponte suas diferenças. Eles tem algum campo em comum? | ||
#Afirma-se que, quando o IPv6 implementa túneis via roteamento IPv4, o IPv6 trata os túneis IPv4 como protocolo de camada de enlace. Você concorda com essa afirmação? Explique sua resposta. | #Afirma-se que, quando o IPv6 implementa túneis via roteamento IPv4, o IPv6 trata os túneis IPv4 como protocolo de camada de enlace. Você concorda com essa afirmação? Explique sua resposta. | ||
− | |||
− | |||
#Cite as diferenças entre a execução da abstração de difusão por meio de múltiplas transmissões individuais e a de uma única difusão com suporte da rede (roteador). | #Cite as diferenças entre a execução da abstração de difusão por meio de múltiplas transmissões individuais e a de uma única difusão com suporte da rede (roteador). | ||
#Considere uma rede de datagramas que utiliza endereços de hospedeiros de 8 bits. Suponha que um roteador utilize a correspondência do prefixo mais longo e tenha a seguinte tabela de repasse:<table border="1" cellpadding="2"> | #Considere uma rede de datagramas que utiliza endereços de hospedeiros de 8 bits. Suponha que um roteador utilize a correspondência do prefixo mais longo e tenha a seguinte tabela de repasse:<table border="1" cellpadding="2"> | ||
Linha 263: | Linha 265: | ||
[http://tele.sj.ifsc.edu.br/~odilson/RED29004/Lab1_PingTraceroute_Wireshark.pdf Laboratório 1 -- Ping, traceroute e Wireshark] | [http://tele.sj.ifsc.edu.br/~odilson/RED29004/Lab1_PingTraceroute_Wireshark.pdf Laboratório 1 -- Ping, traceroute e Wireshark] | ||
− | {{Collapse top |Laboratório 2 - | + | {{Collapse top |Laboratório 2 - Desvendando o HTTP com Wireshark}} |
Fonte base: [http://www.ebah.com.br/content/ABAAABZ6QAD/wireshark-http Wireshark - HTTP] | Fonte base: [http://www.ebah.com.br/content/ABAAABZ6QAD/wireshark-http Wireshark - HTTP] | ||
Linha 388: | Linha 390: | ||
{{Collapse top |Laboratório 3 - Serviço de Nomes (DNS)}} | {{Collapse top |Laboratório 3 - Serviço de Nomes (DNS)}} | ||
− | O Domain Name System (DNS) traduz nomes de hosts em endereços Internet Protocol (IP), preenchendo uma lacuna crítica na infraestrutura da Internet. Neste laboratório, observaremos de mais perto inicialmente o lado cliente do DNS e no final uma breve introdução ao servidor DNS. Lembre-se de que o papel do cliente no DNS é relativamente simples - um cliente envia uma consulta ao seu DNS, e obtém uma resposta. Muito pode acontecer “por baixo dos panos”, de forma invisível aos clientes DNS, enquanto os servidores DNS, organizados hierarquicamente, comunicam-se entre si para, ou recursivamente ou iterativamente, resolver uma consulta DNS de um cliente. Do ponto de vista do cliente DNS, contudo, o protocolo é bastante simples - uma consulta é feita ao seu servidor DNS e uma resposta é recebida deste servidor. | + | O Domain Name System (DNS) traduz nomes de hosts em endereços Internet Protocol (IP), preenchendo uma lacuna crítica na infraestrutura da Internet. Neste laboratório, observaremos de mais perto inicialmente o lado cliente do DNS, uma pequena análise do protocolo e no final uma breve introdução ao servidor DNS. Lembre-se de que o papel do cliente no DNS é relativamente simples - um cliente envia uma consulta ao seu DNS, e obtém uma resposta. Muito pode acontecer “por baixo dos panos”, de forma invisível aos clientes DNS, enquanto os servidores DNS, organizados hierarquicamente, comunicam-se entre si para, ou recursivamente ou iterativamente, resolver uma consulta DNS de um cliente. Do ponto de vista do cliente DNS, contudo, o protocolo é bastante simples - uma consulta é feita ao seu servidor DNS e uma resposta é recebida deste servidor. |
===Consultas DNS por meio de ferramentas especializadas=== | ===Consultas DNS por meio de ferramentas especializadas=== | ||
Linha 447: | Linha 449: | ||
##Como você sabe que foram esses os LDs consultados? | ##Como você sabe que foram esses os LDs consultados? | ||
− | ===Analisando | + | ===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. | Agora que já está ficando claro como funcionam as consultas DNS, deve-se investigar como se dá a comunicação entre seu computador e seu servidor DNS. | ||
#abra o navegador web e limpe o cache do mesmo; | #abra o navegador web e limpe o cache do mesmo; | ||
Linha 467: | Linha 469: | ||
#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? | ||
− | === | + | |
+ | ===Do lado de lá do balcão: servidor de nomes=== | ||
'''DNS ''(Domain Name System)''''' é uma base de dados distribuída e hierárquica. Nela se armazenam informações para mapear nomes de máquinas da Internet para endereços IP e vice-versa, informação para roteamento de email, e outros dados utilizados por aplicações da Internet. | '''DNS ''(Domain Name System)''''' é uma base de dados distribuída e hierárquica. Nela se armazenam informações para mapear nomes de máquinas da Internet para endereços IP e vice-versa, informação para roteamento de email, e outros dados utilizados por aplicações da Internet. | ||
A informação armazenada no DNS é identificada por nomes de domínio que são organizados em uma árvore, de acordo com as divisões administrativas ou organizacionais. Cada nodo dessa árvore, chamado de ''domínio'', possui um rótulo. O nome de domínio de um nodo é a concatenação de todos os rótulos no caminho do nodo até a raiz. Isto é representado como uma ''string'' de rótulos listados da direita pra esquerda e separados por pontos (ex: ifsc.edu.br, sj.ifsc.edu.br). Um rótulo precisa ser único somente dentro do domínio pai a que pertence. | A informação armazenada no DNS é identificada por nomes de domínio que são organizados em uma árvore, de acordo com as divisões administrativas ou organizacionais. Cada nodo dessa árvore, chamado de ''domínio'', possui um rótulo. O nome de domínio de um nodo é a concatenação de todos os rótulos no caminho do nodo até a raiz. Isto é representado como uma ''string'' de rótulos listados da direita pra esquerda e separados por pontos (ex: ifsc.edu.br, sj.ifsc.edu.br). Um rótulo precisa ser único somente dentro do domínio pai a que pertence. | ||
− | Por exemplo, um nome de domínio de uma máquina no IFSC pode ser ''mail.ifsc.edu.br.'', em que o ''"."'' (último) significa o ''root level domain'' ''.br'' é o domínio do topo da hierarquia (no Brasil feito em [https://registro.br/])ao qual ''mail.sj.ifsc.edu.br'' pertence. ''.ifsc.edu'' é um subdomínio de ''.br.'', e ''mail'' o nome da máquina em questão. | + | Por exemplo, um nome de domínio de uma máquina no IFSC pode ser ''mail.ifsc.edu.br.'', em que o ''"."'' (último) significa o ''root level domain'' ''.br'' é o domínio do topo da hierarquia (no Brasil feito em [https://registro.br/]) ao qual ''mail.sj.ifsc.edu.br'' pertence. ''.ifsc.edu'' é um subdomínio de ''.br.'', e ''mail'' o nome da máquina em questão. |
Por razões administrativas, o espaço de nomes é dividido em áreas chamadas de ''zonas'', cada uma iniciando em um nodo e se estendendo para baixo para os nodos folhas ou nodos onde outras zonas iniciam. Os dados de cada zona são guardados em um ''servidor de nomes'', que responde a consultas sobre uma zona usando o protocolo DNS. | Por razões administrativas, o espaço de nomes é dividido em áreas chamadas de ''zonas'', cada uma iniciando em um nodo e se estendendo para baixo para os nodos folhas ou nodos onde outras zonas iniciam. Os dados de cada zona são guardados em um ''servidor de nomes'', que responde a consultas sobre uma zona usando o protocolo DNS. | ||
Linha 485: | Linha 488: | ||
====Roteiro de atividades==== | ====Roteiro de atividades==== | ||
− | Como não temos condições de criar registros em ''registro.br'', para | + | Como não temos condições de criar registros em ''registro.br'', para testarmos algumas funcionalidades de um servidor DNS, vamos montar uma estrutura parcial, válida somente dentro do laboratório, onde poderemos fazer algumas configurações básicas e testá-las. O objetivo é montar a seguinte estrutura que é composta por um ramo (professor) e algumas folhas (alunos) de uma árvore DNS, ver Fig. 1. |
[[Arquivo:Ramo_DNS.png|thumb | 800px| Fig.1 -- Ramo DNS para testes.]] | [[Arquivo:Ramo_DNS.png|thumb | 800px| Fig.1 -- Ramo DNS para testes.]] | ||
− | Vamos configurar e testar um servidor DNS. Para tanto montaremos a estrutura indicada no diagrama, onde cada máquina será um servidor DNS, com um domínio próprio e, ao mesmo tempo, será cliente do servidor DNS da máquina 192.168.1. | + | Vamos configurar e testar um servidor DNS. Para tanto montaremos a estrutura indicada no diagrama, onde cada máquina será um servidor DNS, com um domínio próprio e, ao mesmo tempo, será cliente do servidor DNS da máquina 192.168.1.101. Esta, por sua vez, será servidor ''master'' do domínio r1.br e servidor escravo dos domínios criados por vocês, recebendo automaticamente uma cópia das zonas desses servidores ''masters''. Esta, será também a única máquina com servidor DNS com zona reversa. Sendo assim todos os domínios, diretos e reversos, serão visíveis por meio deste servidor. Como, apesar de serem servidores DNS, todas as máquinas, enquanto clientes, utilizam a máquina do professor para resolver nomes, todos se enxergarão mutuamente. |
+ | Procedimento: | ||
#Abra o VirtualBox e inicie a máquina '''RES-grafico'''. | #Abra o VirtualBox e inicie a máquina '''RES-grafico'''. | ||
#Logue como '''aluno/aluno'''. | #Logue como '''aluno/aluno'''. | ||
#Abra um terminal e tome permissões de root: '''sudo su / aluno'''. | #Abra um terminal e tome permissões de root: '''sudo su / aluno'''. | ||
− | #Configure sua interface de rede. Y é obtido pelo número da etiqueta de sua máquina: D2 ==> '''Y = 02''', D3 ==> '''Y = 03''', ..., D9 ==> '''Y = 09''', E1 ==> '''Y = 11''', E2 ==> '''Y = 12''', ..., E8 ==> '''Y = 18''': <code> | + | #Configure sua interface de rede com IP estático, removendo o cliente dhcp. Y é obtido pelo número da etiqueta de sua máquina: D2 ==> '''Y = 02''', D3 ==> '''Y = 03''', ..., D9 ==> '''Y = 09''', E1 ==> '''Y = 11''', E2 ==> '''Y = 12''', ..., E8 ==> '''Y = 18''': <code> |
+ | apt-get remove isc-dhcp-client | ||
ifconfig eth0 192.168.1.1Y | ifconfig eth0 192.168.1.1Y | ||
route add -net default gw 192.168.1.1 | route add -net default gw 192.168.1.1 | ||
− | gedit /etc/resolv.conf (acrescente ao final do arquivo) | + | gedit /etc/resolv.conf (acrescente ao final do arquivo, deve ser a única linha descomentada) |
nameserver 192.168.1.101 </syntaxhighlight> | nameserver 192.168.1.101 </syntaxhighlight> | ||
+ | #*Se ocorrer erro ao configurar a '''eth0''' tente com '''eth1''', '''eth2'''... | ||
+ | #Acesse a Wiki com o navegador de sua máquina virtual. Isso permitirá você copiar e colar os textos/comandos abaixo. | ||
#Atualize a base de pacotes e instale o pacote Bind: <code> | #Atualize a base de pacotes e instale o pacote Bind: <code> | ||
apt-get update | apt-get update | ||
Linha 522: | Linha 529: | ||
@ IN MX 10 mail.XX.br. | @ IN MX 10 mail.XX.br. | ||
$ORIGIN XX.br. | $ORIGIN XX.br. | ||
+ | ns A 192.168.1.1Y | ||
+ | www CNAME ns | ||
mail A 192.168.1.1Y | mail A 192.168.1.1Y | ||
− | |||
− | |||
</syntaxhighlight> | </syntaxhighlight> | ||
#Utilize a ferramenta para teste de validade do arquivo de definição de zona: '''named-checkzone XX.br /etc/bind/db.XX'''. Caso apresente erros corrija-os. | #Utilize a ferramenta para teste de validade do arquivo de definição de zona: '''named-checkzone XX.br /etc/bind/db.XX'''. Caso apresente erros corrija-os. | ||
#Utilize a ferramenta testar as configuração do BIND: '''named-checkconf -z'''. Caso apresente erros corrija-os. | #Utilize a ferramenta testar as configuração do BIND: '''named-checkconf -z'''. Caso apresente erros corrija-os. | ||
− | #Reinicie o serviço: '''service bind9 restart'''. | + | #Reinicie o serviço: '''service bind9 restart'''. Verifique ainda possíveis erros: <code> |
+ | tail -n 30 /var/log/syslog </syntaxhighlight> | ||
#Caso tudo esteja certo avise ao professor para atualizar as cópias dos arquivos de zona. | #Caso tudo esteja certo avise ao professor para atualizar as cópias dos arquivos de zona. | ||
#Faça a seguinte sequência de testes: <syntaxhighlight lang=bash> | #Faça a seguinte sequência de testes: <syntaxhighlight lang=bash> | ||
Linha 542: | Linha 550: | ||
#Vamos acrescentar mais um IP e um nome de máquina em nosso servidor:<code> | #Vamos acrescentar mais um IP e um nome de máquina em nosso servidor:<code> | ||
ifconfig eth0:0 192.168.1.2Y </syntaxhighlight> | ifconfig eth0:0 192.168.1.2Y </syntaxhighlight> | ||
+ | #*ou eth1:0, eth2:0 ... | ||
#Acrescente ao final do arquivo '''/etc/bind/db.XX''' a declaração do novo componente em nossa tabela de nomes. '''Obrigatoriamente''' o valor do serial deve ser incrementado de pelo menos 1 unidade. <code> | #Acrescente ao final do arquivo '''/etc/bind/db.XX''' a declaração do novo componente em nossa tabela de nomes. '''Obrigatoriamente''' o valor do serial deve ser incrementado de pelo menos 1 unidade. <code> | ||
seu_nome_de_batismo A 192.168.1.2Y</syntaxhighlight> | seu_nome_de_batismo A 192.168.1.2Y</syntaxhighlight> | ||
Linha 549: | Linha 558: | ||
ping nome_do_seu_colega.XX.br ;aqui o XX é do seu colega. </syntaxhighlight> | ping nome_do_seu_colega.XX.br ;aqui o XX é do seu colega. </syntaxhighlight> | ||
#Questões para o relatório: | #Questões para o relatório: | ||
− | ##Explique cada uma das linhas do arquivo /etc/bind/db.XX. | + | ##Explique cada uma das linhas do arquivo '''/etc/bind/db.XX'''. |
− | ##Explique a seção '''allow-transfer { 192.168.1.101; };''' do arquivo /etc/bind/named.conf.local. | + | ##Explique a seção '''allow-transfer { 192.168.1.101; };''' do arquivo '''/etc/bind/named.conf.local'''. |
+ | ##Compare o seu arquivo '''/etc/bind/named.conf.local''' com o do professor (abaixo). | ||
+ | ##Compare os arquivos '''/etc/bind/db.r1''' com '''/etc/bind/db.db.1.168.192''', abaixo. | ||
==== Arquivos e procedimentos na máquina '''Professor''', somente para exemplificar ==== | ==== Arquivos e procedimentos na máquina '''Professor''', somente para exemplificar ==== | ||
Linha 688: | Linha 699: | ||
@ IN MX 10 mail.r1.br. | @ IN MX 10 mail.r1.br. | ||
$ORIGIN r1.br. | $ORIGIN r1.br. | ||
− | + | ns A 192.168.1.101 | |
− | www CNAME | + | www CNAME ns |
− | ns | + | mail CNAME ns |
</syntaxhighlight> | </syntaxhighlight> | ||
Linha 726: | Linha 737: | ||
{{Collapse top |Laboratório 4 - Programação de ''sockets''}} | {{Collapse top |Laboratório 4 - Programação de ''sockets''}} | ||
− | + | Objetivo principal: entender o conceito de ''sockets''. | |
− | |||
− | |||
− | + | Processos que rodam em máquinas diferentes se comunicam entre si enviando mensagens para ''sockets''. Um processo é semelhante a uma casa e o ''socket'' do processo é semelhante a uma porta. A aplicação reside dentro da casa e o protocolo da camada de transporte reside no mundo externo. Um programador de aplicação controla o interior da casa mas tem pouco (ou nenhum) controle sobre o exterior. | |
− | |||
− | |||
===Descrição da aplicação a ser desenvolvida em UDP e TCP=== | ===Descrição da aplicação a ser desenvolvida em UDP e TCP=== | ||
Linha 748: | Linha 755: | ||
[[imagem:Programacao_socket_UDP.png|500px]] | [[imagem:Programacao_socket_UDP.png|500px]] | ||
− | Como fica evidente na Figura acima, os processos cliente e servidor rodam em máquinas distintas e se comunicam justamente enviando mensagens | + | Como fica evidente na Figura acima, os processos cliente e servidor rodam em máquinas distintas e se comunicam justamente enviando mensagens via ''sockets'', que abstrai qualquer necessidade de conhecimento das camadas subjacentes. |
Um exemplo de código bem simples para o lado Cliente: | Um exemplo de código bem simples para o lado Cliente: | ||
Linha 770: | Linha 777: | ||
clientSocket.sendto(message,(serverName, serverPort)) | clientSocket.sendto(message,(serverName, serverPort)) | ||
#Apos o envio do pacote, o cliente aguarda a resposta do servidor armazenando esta na variavel | #Apos o envio do pacote, o cliente aguarda a resposta do servidor armazenando esta na variavel | ||
− | #modifiedMessage e o | + | #modifiedMessage e o endereco de origem eh armazenado em serverAddress. 2048 representa o tamanho do buffer. |
modifiedMessage, serverAddress = clientSocket.recvfrom(2048) | modifiedMessage, serverAddress = clientSocket.recvfrom(2048) | ||
#Imprime a mensagem recebida na tela. | #Imprime a mensagem recebida na tela. | ||
Linha 800: | Linha 807: | ||
===Programação de ''sockets'' com TCP=== | ===Programação de ''sockets'' com TCP=== | ||
− | Diferentemente do UDP, o TCP é um protocolo orientado a conexão. Isso significa que, antes que cliente e servidor possam enviar dados uma ao outro, | + | Diferentemente do UDP, o TCP é um protocolo orientado a conexão. Isso significa que, antes que cliente e servidor possam enviar dados uma ao outro, primeiramente eles devem se apresentar, o primeiro ''socket'' da Figura abaixo, e estabelecer uma conexão TCP, o segundo ''socket'' da Figura abaixo. Todos os dados trafegarão pelo segundo ''socket''. |
O processo TCPServer tem dois sockets: | O processo TCPServer tem dois sockets: | ||
Linha 853: | Linha 860: | ||
===Roteiro de atividades=== | ===Roteiro de atividades=== | ||
− | #Ligue a máquina virtual | + | #Ligue a máquina virtual RES-grafico |
− | #Logue com: aluno - | + | #Logue com: aluno - aluno |
− | #Configure | + | #Configure sua interface de rede com IP estático, removendo o cliente dhcp. Y é obtido pelo número da etiqueta de sua máquina: D2 ==> '''Y = 02''', D3 ==> '''Y = 03''', ..., D9 ==> '''Y = 09''', E1 ==> '''Y = 11''', E2 ==> '''Y = 12''', ..., E8 ==> '''Y = 18''': <code> |
− | + | apt-get remove isc-dhcp-client | |
− | + | ifconfig eth0 192.168.1.1Y | |
− | + | route add -net default gw 192.168.1.1 | |
− | + | gedit /etc/resolv.conf (acrescente ao final do arquivo, deve ser a única linha descomentada) | |
+ | nameserver 200.135.37.65 </syntaxhighlight> | ||
#Escreva o programa UDPServer.py nessa máquina e execute-o: <code> | #Escreva o programa UDPServer.py nessa máquina e execute-o: <code> | ||
python UDPServer.py </syntaxhighlight> | python UDPServer.py </syntaxhighlight> | ||
Linha 866: | Linha 874: | ||
#Abra um terminal da máquina real e escreva o programa UDPClient.py. Não se esqueça de adequar o endereço IP. Execute-o. | #Abra um terminal da máquina real e escreva o programa UDPClient.py. Não se esqueça de adequar o endereço IP. Execute-o. | ||
#Sucesso na execução do programa? | #Sucesso na execução do programa? | ||
− | #Rode o WireShark, seguindo o modelo apresentado no [ | + | #Rode o WireShark, seguindo o modelo apresentado no [[RED29004-2015-1#Roteiros_para_laborat.C3.B3rio]] |
− | #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. | + | #Execute novamente o cliente e servidor e capture os pacotes com o WireShark. Use um filtro do tipo: '''ip.addr == ip_do_servidor''', assim captura-se somente os pacotes originados/destinados ao servidor. É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor? |
#Repita os passos 4 a 10, só que agora para o protocolo TCP. | #Repita os passos 4 a 10, só que agora para o protocolo TCP. | ||
− | #Discuta | + | #Discuta as diferenças observadas entre os protocolos UDP e TCP. |
− | #Com seu cliente conecte o servidor de seu colega e vice-versa. Alguma diferença? | + | #Com seu cliente conecte o servidor UDP e TCP de seu colega e vice-versa. Capture com o WireShark a mensagens trocadas. Alguma diferença? Quais? |
− | ===Desafios=== | + | ===Desafios para casa=== |
#Modifique uma das aplicações cliente-servidor, seja UDP ou TCP, para fazer um pingue-pongue com a mensagem, ou seja, o cliente gera e envia a mensagem, o servidor a devolve, o cliente reenvia a mesma mensagem, o servidor a devolve e assim sucessivamente. | #Modifique uma das aplicações cliente-servidor, seja UDP ou TCP, para fazer um pingue-pongue com a mensagem, ou seja, o cliente gera e envia a mensagem, o servidor a devolve, o cliente reenvia a mesma mensagem, o servidor a devolve e assim sucessivamente. | ||
Linha 880: | Linha 888: | ||
{{Collapse top |Laboratório 5 - TCP x UDP}} | {{Collapse top |Laboratório 5 - TCP x UDP}} | ||
− | |||
− | |||
− | |||
− | |||
O objetivo desses experimentos é evidenciar as diferenças entre os protocolos TCP e UDP. | O objetivo desses experimentos é evidenciar as diferenças entre os protocolos TCP e UDP. | ||
Linha 897: | Linha 901: | ||
# 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. | ||
# 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''' que abrirá uma conexão TCP na porta, por exemplo, 5555 e salvará os dados transferidos em '''arquivo''': <syntaxhighlight lang=bash> | + | #* No computador receptor execute o '''netcat''' (utilize '''man nc''' para saber os detalhes das ''flags'' utilizadas) que abrirá uma conexão TCP na porta, por exemplo, 5555 e salvará os dados transferidos em '''arquivo''': <syntaxhighlight lang=bash> |
− | nc - | + | nc -vvnl 5555 > arquivoTCP |
</syntaxhighlight> | </syntaxhighlight> | ||
− | #* No computador transmissor execute | + | #* No computador transmissor execute: <syntaxhighlight lang=bash> |
− | time nc | + | time nc -vvn ip_do_receptor 5555 < ubuntu.iso |
</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? | ||
# A segunda transferência será feita usando o protocolo UDP: | # A segunda transferência será feita usando o protocolo UDP: | ||
#* No computador receptor baixe o programa '''receptor''', acrescente a ele permissão de execução e o execute, conforme a sequência de comandos abaixo: <syntaxhighlight lang=bash> | #* No computador receptor baixe o programa '''receptor''', acrescente a ele permissão de execução e o execute, conforme a sequência de comandos abaixo: <syntaxhighlight lang=bash> | ||
− | wget http://tele.sj.ifsc.edu.br/~ | + | wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/receptor |
chmod +x receptor | chmod +x receptor | ||
./receptor 5555 > arquivoUDP | ./receptor 5555 > arquivoUDP | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | #* No computador transmissor baixe o programa '''transmissor''', acrescente a ele permissão de execução e o execute, conforme a sequência de comandos abaixo | + | #* No computador transmissor baixe o programa '''transmissor''', acrescente a ele permissão de execução e o execute, conforme a sequência de comandos abaixo: <syntaxhighlight lang=bash> |
− | wget http://tele.sj.ifsc.edu.br/~ | + | wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/transmissor |
chmod +x transmissor | chmod +x transmissor | ||
− | ./transmissor | + | ./transmissor ip_do_receptor 5555 < ubuntu.iso |
</syntaxhighlight> | </syntaxhighlight> | ||
#* Quando completar a transferência, no receptor digite <CTRL + C>, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo? | #* Quando completar a transferência, no receptor digite <CTRL + C>, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo? | ||
Linha 920: | Linha 924: | ||
==== Experimento 2 ==== | ==== Experimento 2 ==== | ||
− | Transferências usando cada um desses protocolos podem apresentar características bem distintas. Neste segundo experimento, serão feitas transferências simultâneas de arquivos a partir de um mesmo servidor, comparando-se o resultado obtido com TCP e UDP. Essas transferência ocorrerão entre os computadores do laboratório e um servidor externo ao laboratório | + | Transferências usando cada um desses protocolos podem apresentar características bem distintas. Neste segundo experimento, serão feitas transferências simultâneas de arquivos a partir de um mesmo servidor, comparando-se o resultado obtido com TCP e UDP. Essas transferência ocorrerão entre os computadores do laboratório e um servidor externo ao laboratório. |
− | |||
− | |||
− | |||
− | |||
− | |||
− | # Abra um terminal em seu computador, e nele execute este comando: <syntaxhighlight lang=bash> | + | # Todos devem executar este procedimento ao mesmo tempo. Abra um terminal em seu computador, e nele execute este comando: <syntaxhighlight lang=bash> |
− | wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/ | + | wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/arq2.iso |
</syntaxhighlight> | </syntaxhighlight> | ||
# Observe a taxa de transferência (velocidade do download) obtida. Que valores ela apresenta? Quanto tempo levou para o arquivo ser transferido? | # Observe a taxa de transferência (velocidade do download) obtida. Que valores ela apresenta? Quanto tempo levou para o arquivo ser transferido? | ||
− | # Após todos terem copiado o arquivo, o professor irá repetir a transferência | + | # Após todos terem copiado o arquivo, o professor irá repetir a transferência, porém desta vez ele irá fazê-la sozinho. Que taxas ele obteve, e quanto tempo levou? |
# O professor irá repetir a transferência novamente, mas desta vez ele irá pedir que um aluno também a inicie logo em seguida. Qual foi a taxa obtida por ambos? | # O professor irá repetir a transferência novamente, mas desta vez ele irá pedir que um aluno também a inicie logo em seguida. Qual foi a taxa obtida por ambos? | ||
# Finalmente, o professor irá repetir a transferência porém com três alunos fazendo-a ao mesmo tempo. Que se pode concluir quanto a taxa de transferência obtida? | # Finalmente, o professor irá repetir a transferência porém com três alunos fazendo-a ao mesmo tempo. Que se pode concluir quanto a taxa de transferência obtida? | ||
# Para poder fazer uma comparação, as transferências serão feitas novamente porém usando UDP como protocolo de transporte. Para isso siga estes passos: | # Para poder fazer uma comparação, as transferências serão feitas novamente porém usando UDP como protocolo de transporte. Para isso siga estes passos: | ||
− | ## Abra dois terminais. | + | ## Abra dois terminais. No '''terminal 1''' execute este comando: <syntaxhighlight lang=bash> |
watch -n 1 ls -l arquivo | watch -n 1 ls -l arquivo | ||
− | </syntaxhighlight> ... e no | + | </syntaxhighlight> ... e no '''terminal 2''': <syntaxhighlight lang=bash> |
./receptor 5555 > arquivo | ./receptor 5555 > arquivo | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | ## Fique observando o | + | ## Fique observando o '''terminal 1'''. O professor irá transmitir o arquivo a partir do servidor remoto, um processo para cada aluno. No '''terminal 1''' observe o tamanho do arquivo, que deverá aumentar gradativamente. Monitore manualmente o tempo em segundos (relógio, celular ou relógio do computador), o tamanho e quando o tamanho do arquivo parou de crescer. |
## Em que valor o tamanho do arquivo parou de crescer? Quanto tempo isso levou, aproximadamente? E esse tamanho final é o mesmo do arquivo original? | ## Em que valor o tamanho do arquivo parou de crescer? Quanto tempo isso levou, aproximadamente? E esse tamanho final é o mesmo do arquivo original? | ||
− | ## Como se | + | ## Como se comportaram as transferências usando TCP e UDP? |
==== Experimento 3 ==== | ==== Experimento 3 ==== | ||
− | Repita os | + | Repita os passos 1 e 3 do '''experimento 2''' (anterior) mas agora com o arquivo [http://tele.sj.ifsc.edu.br/~odilson/RED29004/minimo.txt minimo.txt], anotando todos os tempos. |
#Os resultados foram os esperados? Discuta sobre as possíveis diferenças de comportamento. | #Os resultados foram os esperados? Discuta sobre as possíveis diferenças de comportamento. | ||
− | ==== Tarefa extra ==== | + | ==== Tarefa extra (pode ser em casa)==== |
− | Use o aplicativo '''NetCat''' (nc) para fazer transferências UDP e responda: | + | 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á): |
#Qual o procedimento no lado transmissor e receptor? | #Qual o procedimento no lado transmissor e receptor? | ||
− | #Consegue-se medir o tempo de maneira automática? | + | #Consegue-se medir o tempo de maneira automática? Por que sim ou por que não? |
− | #Por que os processos não param ao final da transferência? | + | #Por que os processos não param ao final da transferência como no '''experimento 1'''? |
{{Collapse bottom}} | {{Collapse bottom}} | ||
Linha 961: | Linha 960: | ||
{{Collapse top |Laboratório 6 - Protocolos de roteamento}} | {{Collapse top |Laboratório 6 - Protocolos de roteamento}} | ||
− | Analisar o funcionamento de protocolos de roteamento estático e dinâmico da Internet, em particular as tabelas estáticas de roteamento, o protocolo RIP e OSPF, a partir de uma estrutura física formada por roteadores e redes locais. Para | + | '''Objetivos''': Analisar o funcionamento de protocolos de roteamento estático e dinâmico da Internet, em particular as tabelas estáticas de roteamento, o protocolo RIP e OSPF, a partir de uma estrutura física formada por roteadores e redes locais. |
+ | |||
+ | Para atingir tais objetivos utilizaremos o [[Netkit2]]. Leia o [http://wiki.sj.ifsc.edu.br/index.php/Netkit2#Roteadores tutorial] de como o Netkit2 trabalha com roteadores. | ||
Em todos os experimentos será utilizado como base a seguinte arquitetura de rede: | Em todos os experimentos será utilizado como base a seguinte arquitetura de rede: | ||
Linha 969: | Linha 970: | ||
==Experimento 1: tabelas estáticas de roteamento== | ==Experimento 1: tabelas estáticas de roteamento== | ||
− | Tempo aproximado para execução e conferência: | + | Tempo aproximado para execução e conferência: 1 h |
#Crie em seu computador um arquivo com nome '''/home/aluno/exp1.conf''', com o seguinte conteúdo: <code> # Hosts definitions | #Crie em seu computador um arquivo com nome '''/home/aluno/exp1.conf''', com o seguinte conteúdo: <code> # Hosts definitions | ||
Linha 1 000: | Linha 1 001: | ||
r3[eth1]=backbone1:ip=10.0.1.2/30 | r3[eth1]=backbone1:ip=10.0.1.2/30 | ||
r3[eth2]=backbone2:ip=10.0.2.2/30 </syntaxhighlight> | r3[eth2]=backbone2:ip=10.0.2.2/30 </syntaxhighlight> | ||
− | #Rode o NetKit em seu computador. Em um terminal digite: <code> NetKit2 </syntaxhighlight> | + | #Rode o NetKit em seu computador. Em um terminal digite: <code> NetKit2 & </syntaxhighlight> |
#No menu '''File - Load and Run''', procure o arquivo '''/home/aluno/exp1.conf''' e clique em OK. Abrirá uma janela com 6 abas, onde cada uma delas é um terminal de configuração do respectivo equipamento: PC1-3 ou R1-3. | #No menu '''File - Load and Run''', procure o arquivo '''/home/aluno/exp1.conf''' e clique em OK. Abrirá uma janela com 6 abas, onde cada uma delas é um terminal de configuração do respectivo equipamento: PC1-3 ou R1-3. | ||
− | #Testes de conectividade de enlace | + | #Ao clicar no menu '''File - Graph''', pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto. |
+ | #Testes de conectividade de enlace e configuração do ''default gateway''. | ||
##Por exemplo, no '''pc1''' execute o comando: <code> ping 192.168.0.254 </syntaxhighlight> Obteve sucesso? Sim ou não e por quê? | ##Por exemplo, no '''pc1''' execute o comando: <code> ping 192.168.0.254 </syntaxhighlight> Obteve sucesso? Sim ou não e por quê? | ||
+ | ##Teste a conectividade do '''pc1''' executando o comando: <code> ping 10.0.0.1 </syntaxhighlight> Obteve sucesso? Sim ou não e por quê? | ||
##Por exemplo, no '''pc1''' execute o comando: <code> ping 10.0.0.2 </syntaxhighlight> Obteve sucesso? Sim ou não e por quê? | ##Por exemplo, no '''pc1''' execute o comando: <code> ping 10.0.0.2 </syntaxhighlight> Obteve sucesso? Sim ou não e por quê? | ||
− | ##Configure o roteador padrão, 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.2 </syntaxhighlight> Obteve sucesso? O comportamento foi o mesmo | + | ##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 | + | ##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? |
− | |||
#Iniciando o roteamento | #Iniciando o roteamento | ||
− | ##Deixe o '''ping''' do item | + | ##Deixe o '''ping''' do item 5.3 e o ''wireshark'' do item 5.6 rodando e estabeleça uma rota no roteador '''r2''' com o comando: <code> route add -net 192.168.0.0/24 gw 10.0.0.1 </syntaxhighlight> O que ocorreu com o ping e o wireshark? Por quê? |
##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 enalce. | #Testando a queda de enalce. | ||
##Com todas as rotas em perfeito funcionamento, gere um '''ping''' do '''pc1''' para o '''pc3''' e execute '''wireshark any''' no '''r1''' , em seguida "derrube" o enlace entre o '''r1''' e '''r3'''. Por exemplo, no '''r3''' execute o comando: <code> ifconfig eth1 down </syntaxhighlight> O que ocorreu com o '''ping''' e o '''wireshark'''? Por quê? Com este enlace comprometido qual seria a solução para a continuidade de funcionamento de toda a rede? | ##Com todas as rotas em perfeito funcionamento, gere um '''ping''' do '''pc1''' para o '''pc3''' e execute '''wireshark any''' no '''r1''' , em seguida "derrube" o enlace entre o '''r1''' e '''r3'''. Por exemplo, no '''r3''' execute o comando: <code> ifconfig eth1 down </syntaxhighlight> O que ocorreu com o '''ping''' e o '''wireshark'''? Por quê? Com este enlace comprometido qual seria a solução para a continuidade de funcionamento de toda a rede? | ||
− | ==O Pacote Quagga == | + | ==O Pacote Quagga -- Breve introdução == |
− | O pacote Quagga fornece um conjunto de processos (''daemons'') com | + | O pacote [http://www.nongnu.org/quagga/ Quagga] fornece um conjunto de processos (''daemons'') com |
facilidades para a construção da tabela de roteamento de um sistema. O projeto | facilidades para a construção da tabela de roteamento de um sistema. O projeto | ||
− | Quagga é derivado do | + | Quagga é derivado do pacote Zebra. O esquema abaixo mostra a |
estrutura do Quagga. | estrutura do Quagga. | ||
Linha 1 031: | Linha 1 033: | ||
para outros processos que executam um determinado protocolo de roteamento. Por | para outros processos que executam um determinado protocolo de roteamento. Por | ||
exemplo, no esquema mostrado existem 3 processos responsáveis pela execução dos | exemplo, no esquema mostrado existem 3 processos responsáveis pela execução dos | ||
− | protocolos BGP, RIP e OSPF. | + | protocolos BGP, RIP e OSPF. É possível executar |
vários protocolos de roteamento dinâmico simultaneamente. | vários protocolos de roteamento dinâmico simultaneamente. | ||
Linha 1 065: | Linha 1 067: | ||
Baseado no mesmo diagrama do experimento anterior, usaremos serviços para rodar os protocolos de roteamento RIP e OSPF a partir do Quagga, de tal modo que as tabelas estáticas de roteamento não mais serão necessárias e o sistema se auto recuperará da queda de um único enlace (nesse caso). | Baseado no mesmo diagrama do experimento anterior, usaremos serviços para rodar os protocolos de roteamento RIP e OSPF a partir do Quagga, de tal modo que as tabelas estáticas de roteamento não mais serão necessárias e o sistema se auto recuperará da queda de um único enlace (nesse caso). | ||
− | #Reinicie o NetKit2 e releia o arquivo de configuração. | + | #Reinicie o NetKit2 e releia o arquivo de configuração '''exp1.conf'''. |
− | #Repita o item 4 | + | #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 | + | #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> |
hostname r1 | hostname r1 | ||
Linha 1 079: | Linha 1 081: | ||
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. 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 086: | Linha 1 088: | ||
network eth2 | network eth2 | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | #No '''pc1''' execute: <code> ping 192.168.2.1 </syntaxhighlight> O ping está funcionando? Por quê? Deixe o ping rodando! | + | #No '''pc1''' execute: <code> ping 192.168.2.1 </syntaxhighlight> O ping está funcionando? Por quê? |
+ | #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/USUARIO/lab" são montados na pasta "/homelab/" 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.<syntaxhighlight lang=bash> | #Execute o Quagga e o RIP a partir dos arquivos criados. Os arquivos que estão na pasta "/home/USUARIO/lab" são montados na pasta "/homelab/" 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.<syntaxhighlight lang=bash> | ||
− | + | zebra -d -f /hostlab/r1/zebra.conf | |
− | + | ripd -d -f /hostlab/r1/ripd.conf | |
</syntaxhighlight> | </syntaxhighlight> | ||
+ | #Olhe o terminal do pc1, o que ocorreu com o ping? Por quê? | ||
#Observando o estado do sistema. Vamos usar comandos para verificar o estado dos roteadores. | #Observando o estado do sistema. Vamos usar comandos para verificar o estado dos roteadores. | ||
##Solicitar uma sessão com o vtysh no ''zebrad'': <code> vtysh </syntaxhighlight> | ##Solicitar uma sessão com o vtysh no ''zebrad'': <code> vtysh </syntaxhighlight> | ||
Linha 1 098: | Linha 1 102: | ||
##Verifique o estado da '''tabela de roteamento''' usando o comando: <code> show ip route </syntaxhighlight> '''Interprete detalhadamente essa tabela'''! Você consegue visualizar o mapa da rede a partir dessa tabela? | ##Verifique o estado da '''tabela de roteamento''' usando o comando: <code> show ip route </syntaxhighlight> '''Interprete detalhadamente essa tabela'''! Você consegue visualizar o mapa da rede a partir dessa tabela? | ||
##Verifique a configuração atual do roteador: <code> show run </syntaxhighlight> | ##Verifique a configuração atual do roteador: <code> show run </syntaxhighlight> | ||
− | ##Sair do vtysh: <code> | + | ##Sair do vtysh: <code>exit </syntaxhighlight> |
− | |||
− | |||
#Teste as demais conectividades entre os PCs com ping mútuos. Tudo funcionando? | #Teste as demais conectividades entre os PCs com ping mútuos. Tudo funcionando? | ||
#A partir de cada PC trace a rota ('''traceroute''') para os demais PC e anote-as. | #A partir de cada PC trace a rota ('''traceroute''') para os demais PC e anote-as. | ||
− | # Com o ''route -n'' e/ou '' | + | # Com o '''route -n''' e/ou '''netstat -r''' verifique a anote as rotas de cada roteador. |
+ | #Pare todos os pings. | ||
#Execute o WireShark (ou '''tcpdump -n -vvv -i any''') no '''r1''' por pelo menos 1 min 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? | #Execute o WireShark (ou '''tcpdump -n -vvv -i any''') no '''r1''' por pelo menos 1 min 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 WireShark rodando em '''r1''', desative um dos enlaces entre os roteadores e acompanhe a troca de mensagens. 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> | #Com o WireShark rodando em '''r1''', desative um dos enlaces entre os roteadores e acompanhe a troca de mensagens. 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> | ||
Linha 1 182: | Linha 1 185: | ||
#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 top |Laboratório 7 - IPv6}} | ||
+ | Este roteiro foi baseado no material disponível em [http://www.paulogurgel.com.br/]. | ||
+ | |||
+ | Slides de [http://www.sj.ifsc.edu.br/~odilson/RED29004/IPv6_e_MIPv6.pdf endereçamento IPv6]. | ||
+ | |||
+ | [http://www.sj.ifsc.edu.br/~odilson/RED29004/enderec-v6.pdf Guia didático de endereçamento IPv6] obtido de http://ipv6.br/. | ||
+ | |||
+ | Objetivos do laboratório: | ||
+ | *Conhecer o protocolo IPv6 | ||
+ | *Compreender o funcionando do Neighbor Discovery | ||
+ | *Aprender a configurar redes IPv6 no Linux | ||
+ | *Aprender a configurar rotas IPv6 | ||
+ | |||
+ | 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. | ||
+ | |||
+ | [[Arquivo:Diagrama_rede_IPv6.jpg]] | ||
+ | |||
+ | Procedimento: | ||
+ | #Crie em seu computador um arquivo com nome /home/aluno/IPv6.conf, com o seguinte conteúdo: <code> | ||
+ | #Ligacao das maquinas nos dominios de colisao | ||
+ | #Duas pequenas redes interligadas pelo backbone | ||
+ | |||
+ | # Hosts definitions | ||
+ | pc1[type]=generic | ||
+ | pc2[type]=generic | ||
+ | pc3[type]=generic | ||
+ | pc4[type]=generic | ||
+ | |||
+ | # Routers definitions | ||
+ | r1[type]=gateway | ||
+ | r2[type]=gateway | ||
+ | |||
+ | # Hosts' interfaces to local routers | ||
+ | pc1[eth0]=link0 | ||
+ | pc2[eth0]=link1 | ||
+ | |||
+ | |||
+ | r1[eth0]=backbone0 | ||
+ | r1[eth1]=link0 | ||
+ | r1[eth2]=link1 | ||
+ | |||
+ | r2[eth0]=backbone0 | ||
+ | r2[eth1]=HUB1 | ||
+ | |||
+ | |||
+ | pc3[eth0]=HUB1 | ||
+ | pc4[eth0]=HUB1 | ||
+ | |||
+ | |||
+ | #Definicao da quantidade de memoria disponivel para cada pc. | ||
+ | pc1[mem]=32 | ||
+ | pc2[mem]=32 | ||
+ | pc3[mem]=32 | ||
+ | pc4[mem]=32 | ||
+ | r1[mem]=64 | ||
+ | r2[mem]=64 </syntaxhighlight> | ||
+ | #Rode o NetKit em seu computador. Em um terminal digite: <code> | ||
+ | NetKit2 & </syntaxhighlight> | ||
+ | #No menu '''File''' - '''Load and Run''', procure o arquivo /home/aluno/IPv6.conf e clique em OK. Abrirá uma janela com 6 abas, onde cada uma delas é um terminal de configuração do respectivo equipamento: '''pc1-4''' ou '''r1-2'''. | ||
+ | #Ao clicar no menu '''File''' - '''Graph''', pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto. | ||
+ | #Em todos os equipamentos, iremos iniciar a captura de pacotes em uma das interfaces que será gravado em um arquivo para estudo posterior. Utilize os seguintes comandos (atenção ao "&" no final que envia o tcpdump para background): | ||
+ | ##'''pc1''': tcpdump -i eth0 -w /hostlab/ipv6_pc1.pcap & | ||
+ | ##'''pc2''': tcpdump -i eth0 -w /hostlab/ipv6_pc2.pcap & | ||
+ | ##'''pc3''': tcpdump -i eth0 -w /hostlab/ipv6_pc3.pcap & | ||
+ | ##'''pc4''': tcpdump -i eth0 -w /hostlab/ipv6_pc4.pcap & | ||
+ | ##'''r1''': tcpdump -i eth0 -w /hostlab/ipv6_r1.pcap & | ||
+ | ##'''r2''': tcpdump -i eth0 -w /hostlab/ipv6_r2.pcap & | ||
+ | #No '''pc1''' use o seguinte comando para adicionar o endereço IPv6 à interface de rede: <code> | ||
+ | ip addr add 2001:bcc:faca:1::101/64 dev eth0 </syntaxhighlight> | ||
+ | #No '''pc1''' use o seguinte comando para verificar como ficou a configuração dos endereços da interface de rede. O resultado é similar ao apresentado pelo comando '''ifconfig''': <code> | ||
+ | ip addr show dev eth0 </syntaxhighlight> | ||
+ | #Configure os IPv6s de todas as interfaces dos demais equipamentos de acordo com o diagrama da rede. | ||
+ | #Faça um '''ping6''' entre o '''pc3''' ao '''pc4'''. Por exemplo do '''pc3''' ao '''pc4''': <code> | ||
+ | ping6 2001:bcc:1f0:1::104 </syntaxhighlight> | ||
+ | #Obteve sucesso? Sim ou não e por quê? | ||
+ | #Faça um '''ping6''' entre o '''pc1''' ao '''pc2'''. | ||
+ | #Obteve sucesso? Sim ou não e por quê? | ||
+ | #Nos computadores '''pc3''' e '''pc4''', acrescente o ''default gateway'' com o seguinte comando: <code> | ||
+ | ip -6 route add default via 2001:bcc:1f0:1::1 dev eth0 </syntaxhighlight> | ||
+ | #Nos computadores '''pc1''' e '''pc2''', acrescente o ''default gateway'' analisando o diagrama da rede e adaptando o comando acima. | ||
+ | #Configure os roteadores para habilitar o repasse de pacotes entre as interfaces utilizando os seguintes comandos: | ||
+ | ##'''r1''': echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding | ||
+ | ##'''r1''': echo 1 > /proc/sys/net/ipv6/conf/eth1/forwarding | ||
+ | ##'''r1''': echo 1 > /proc/sys/net/ipv6/conf/eth2/forwarding | ||
+ | ##'''r2''': echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding | ||
+ | ##'''r2''': echo 1 > /proc/sys/net/ipv6/conf/eth1/forwarding | ||
+ | #No '''r1''', adicione uma rota estática para a rede dos '''pc3''' e '''pc4''' através do seguinte comando: <code> | ||
+ | ip -6 route add 2001:bcc:1f0:1::/64 via 2001:db8:dead:1::2 dev eth0 </syntaxhighlight> | ||
+ | #No '''r2''', adicione uma rota estática para a rede dos '''pc1''' e '''pc2''' através dos seguintes comandos: <code> | ||
+ | ip -6 route add 2001:bcc:faca:1::/64 via 2001:db8:dead:1::1 dev eth0 | ||
+ | ip -6 route add 2001:bcc:cafe:1::/64 via 2001:db8:dead:1::1 dev eth0 </syntaxhighlight> | ||
+ | #Use os comandos '''traceroute6 numero_ipv6_pcX''' a partir do computador '''pc1''' sobre o IP de global unicast dos computadores '''pc3''' e '''pc4'''. | ||
+ | #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? | ||
+ | #Em cada um dos computadores virtuais, use o comando '''fg tcpdump''' para trazer o '''tcpdump''' para o primeiro plano. Em seguida encerre a captura com '''Ctrl + C'''. | ||
+ | #Estude os '''.pcaps''' gerados no '''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'''. | ||
+ | #A partir das capturas obtidas, explique o processo de descoberta de vizinhança (neighbor discovery / request e reply), citando os endereços de '''multicast''' e '''link local''' utilizados. | ||
+ | #Explique a tabela de roteamento do '''r1''', em especial os endereços de '''link local'''. Porque não há confusão dos prefixos? Explique também o uso dos prefixos diferentes para os '''pc1''' e '''pc2'''. Por que não foi utilizado o mesmo prefixo? | ||
+ | #É possível utilizar os comandos '''route''' e '''ifconfig''' para configurar redes IPv6? Pesquise rapidamente no google e tente realizar a configuração do '''pc4''' utilizando estes comandos. Para isso, use o comando '''ip addr flush dev eth0''' no '''pc4''' para limpar toda a configuração de endereços e rotas da interface. Depois disso configure o endereço com '''ifconfig''' e as rotas com o comando '''route'''. | ||
+ | #Explique sucintamente as diferenças na comunicação baseada em IPv4 e IPv6. | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
Linha 1 188: | Linha 1 294: | ||
* [[Netkit2]]: possibilita criar experimentos com redes compostas por máquinas virtuais Linux | * [[Netkit2]]: possibilita criar experimentos com redes compostas por máquinas virtuais Linux | ||
− | *[http://wiki.netkit.org/index.php/Labs_Official | + | *Vários [http://wiki.netkit.org/index.php/Labs_Official laboratórios virtuais do NetKit], prontos para uso, que focam em serviços específicos de redes de computadores. |
= Curiosidades = | = Curiosidades = | ||
− | * [http://www.pop-sc.rnp.br/publico/monitoramento.php Monitoramento do tráfego RNP] | + | * [http://www.pop-sc.rnp.br/publico/monitoramento.php Monitoramento do tráfego RNP - PoP-SC] [http://memoria.rnp.br/ceo/trafego/panorama.php Monitoramento do tráfego RNP - Nacional] |
* [https://wigle.net/ Redes WiFi no mundo] | * [https://wigle.net/ Redes WiFi no mundo] | ||
− | * [ | + | * [https://www.youtube.com/watch?v=9hIQjrMHTv4 ''History of the Internet''] |
+ | * [https://www.youtube.com/watch?v=A5dD2x2iQx8 ''History of the Internet'' - legendado] | ||
+ | * [https://www.youtube.com/watch?v=PBWhzz_Gn10 ''Warriors of the Net''] | ||
+ | * [https://www.youtube.com/watch?v=O_xG0ay5Vqs ''Warriors of the Net'' - legendado] | ||
+ | * [https://www.youtube.com/watch?v=VANORrzKX50 ''Browser Wars''] | ||
+ | * [https://www.youtube.com/watch?v=1G3SUTmioQE ''Browser Wars'' - legendado] | ||
+ | * [https://www.youtube.com/watch?v=0nz-lcuv3TM ''Browser Wars'' - dublado] | ||
+ | * [http://ipv6.br/ '''IPv6 no Brasil'''] | ||
= Seminários = | = Seminários = | ||
Linha 1 206: | Linha 1 319: | ||
* ''Grupos e Temas para 2015-1'': | * ''Grupos e Temas para 2015-1'': | ||
− | ** Lucas e Mathias: HTTPS | + | ** Lucas e Mathias: HTTPS. [http://www.sj.ifsc.edu.br/~odilson/RED29004/https-seguranca-na_apresentacao.pdf Slides da apresentação] |
− | ** Letícia e Jessica: HTML 5 ou Hidden | + | ** Letícia e Jessica: HTML 5 ou Hidden [http://www.sj.ifsc.edu.br/~odilson/RED29004/HTML5_apresentacao.pdf Slides da apresentação] |
− | ** Helenluciany Maria Luiza: QoS | + | ** Helenluciany Maria Luiza: QoS [http://www.sj.ifsc.edu.br/~odilson/RED29004/QoSapresentacao.pdf Slides da apresentação] |
− | ** Katharine e Kristhine: Ad-Hoc ''Network'' | + | ** Katharine e Kristhine: Ad-Hoc ''Network''.[http://www.sj.ifsc.edu.br/~odilson/RED29004/AdHoc_ppt.pdf Slides da apresentação]. |
− | ** Angelo e Iago: HTTP2 | + | ** Angelo e Iago: HTTP2. [http://www.sj.ifsc.edu.br/~odilson/RED29004/HTTP2.pdf Slides da apresentação]. |
− | ** | + | ** Anderson e Gabriel: VPN [http://www.sj.ifsc.edu.br/~odilson/RED29004/VPNapresentacaoredes.pdf Slides da apresentação] |
** Cleiton e Gustavo: SNMP | ** Cleiton e Gustavo: SNMP | ||
− | ** | + | |
+ | *Ordem de apresentação dos seminários | ||
+ | **17/06 - Ad-Hoc ''Network'', HTTPS, SNMP | ||
+ | **23/6 - HTML5, Qos, VPN | ||
+ | **24/6 - HTTP2 | ||
* Avaliação | * Avaliação | ||
** Nota: 0,5 x Documento + 0,5 x Seminário | ** Nota: 0,5 x Documento + 0,5 x Seminário | ||
+ | ** [http://www.sj.ifsc.edu.br/~odilson/RED29004/Avaliacao%20dos%20relatorios%20e%20apresentacao.pdf Avaliação dos relatórios entregues] | ||
* ''Instruções sobre o Seminário de Redes I'': | * ''Instruções sobre o Seminário de Redes I'': | ||
Linha 1 253: | Linha 1 371: | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top |Aula 4 - 24/2/15: Introdução às redes de computadores}} | + | {{Collapse top |Aula 4 - 11/2/15: Introdução às redes de computadores}} |
+ | [http://tele.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%201%20Redes%20de%20computadores%20e%20a%20Internet.pdf Slides do Kurose referentes ao capítulo 1] | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 5 - 24/2/15: Introdução às redes de computadores}} | ||
[http://tele.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%201%20Redes%20de%20computadores%20e%20a%20Internet.pdf Slides do Kurose referentes ao capítulo 1] | [http://tele.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%201%20Redes%20de%20computadores%20e%20a%20Internet.pdf Slides do Kurose referentes ao capítulo 1] | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top |Aula | + | {{Collapse top |Aula 6 - 25/2/15: Introdução às redes de computadores}} |
[http://tele.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%201%20Redes%20de%20computadores%20e%20a%20Internet.pdf Slides do Kurose referentes ao capítulo 1] | [http://tele.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%201%20Redes%20de%20computadores%20e%20a%20Internet.pdf Slides do Kurose referentes ao capítulo 1] | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top |Aula | + | {{Collapse top |Aula 7 - 3/3/15: Introdução às redes de computadores}} |
[http://tele.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%201%20Redes%20de%20computadores%20e%20a%20Internet.pdf Slides do Kurose referentes ao capítulo 1] | [http://tele.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%201%20Redes%20de%20computadores%20e%20a%20Internet.pdf Slides do Kurose referentes ao capítulo 1] | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top |Aula | + | {{Collapse top |Aula 8 - 4/3/15: Laboratório 1 - Ping Traceroute Wireshark}} |
[http://tele.sj.ifsc.edu.br/~odilson/RED29004/Lab1_PingTraceroute_Wireshark.pdf Aplicativos para verificar os parâmetros do TCP/IP, diagnosticar o atraso dos pacotes, traçar rotas em redes TCP/IP e se familiarizar com o WireShark] | [http://tele.sj.ifsc.edu.br/~odilson/RED29004/Lab1_PingTraceroute_Wireshark.pdf Aplicativos para verificar os parâmetros do TCP/IP, diagnosticar o atraso dos pacotes, traçar rotas em redes TCP/IP e se familiarizar com o WireShark] | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top |Aula | + | {{Collapse top |Aula 9 - 10/3/15: Camada de aplicação - Comunicação entre processos HTTP}} |
[http://www.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%202%20Camada%20de%20aplica%C3%A7%C3%A3o.pdf Slides do Kurose referentes ao capítulo 2] | [http://www.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%202%20Camada%20de%20aplica%C3%A7%C3%A3o.pdf Slides do Kurose referentes ao capítulo 2] | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top |Aula | + | {{Collapse top |Aula 10 - 11/3/15: Camada de aplicação - HTTP FTP SMTP}} |
[http://www.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%202%20Camada%20de%20aplica%C3%A7%C3%A3o.pdf Slides do Kurose referentes ao capítulo 2] | [http://www.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%202%20Camada%20de%20aplica%C3%A7%C3%A3o.pdf Slides do Kurose referentes ao capítulo 2] | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top |Aula | + | {{Collapse top |Aula 11 - 17/3/15: Laboratório 2 - HTTP}} |
[http://wiki.sj.ifsc.edu.br/index.php/RED29004-2015-1#Roteiros_para_laborat.C3.B3rio Laboratório 2] | [http://wiki.sj.ifsc.edu.br/index.php/RED29004-2015-1#Roteiros_para_laborat.C3.B3rio Laboratório 2] | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top |Aula | + | {{Collapse top |Aula 12 - 18/3/15: Camada de aplicação - DNS}} |
[http://www.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%202%20Camada%20de%20aplica%C3%A7%C3%A3o.pdf Slides do Kurose referentes ao capítulo 2] | [http://www.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%202%20Camada%20de%20aplica%C3%A7%C3%A3o.pdf Slides do Kurose referentes ao capítulo 2] | ||
Linha 1 287: | Linha 1 409: | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top |Aula | + | {{Collapse top |Aula 13 - 24/3/15: Laboratório 3 - DNS}} |
+ | [http://wiki.sj.ifsc.edu.br/index.php/RED29004-2015-1#Roteiros_para_laborat.C3.B3rio Laboratório 3] | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top | 25/3/15: Não houve aulas - licença médica}} | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 14 - 31/3/15: Camada de aplicação - P2P - Finalização Laboratório DNS}} | ||
[http://www.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%202%20Camada%20de%20aplica%C3%A7%C3%A3o.pdf Slides do Kurose referentes ao capítulo 2] | [http://www.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%202%20Camada%20de%20aplica%C3%A7%C3%A3o.pdf Slides do Kurose referentes ao capítulo 2] | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 15 - 1/4/15: Dúvidas}} | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 16 - 7/4/15: Avaliação 1}} | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 17 - 8/4/15: Introdução a camada de transporte - Multiplexação/Demultiplexação - UDP}} | ||
+ | [http://www.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%203%20Camada%20de%20transporte.pdf Slides do Kurose referentes ao capítulo 3] | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 18 - 14/4/15: Laboratório ''Sockets''}} | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 19 - 15/4/15: TCP}} | ||
+ | [http://www.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%203%20Camada%20de%20transporte.pdf Slides do Kurose referentes ao capítulo 3] | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 20 - 22/4/15: Controle de congestionamento -- TCP}} | ||
+ | [http://www.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%203%20Camada%20de%20transporte.pdf Slides do Kurose referentes ao capítulo 3] | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 21 - 28/4/15: Laboratório: TCP versus UDP}} | ||
+ | [http://wiki.sj.ifsc.edu.br/index.php/RED29004-2015-1#Roteiros_para_laborat.C3.B3rio Laboratório 5] | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 22 - 29/4/15: A camada de rede - Redes de datagramas, circuitos virtuais e roteadores}} | ||
+ | [http://tele.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Slides do Kurose referentes ao capítulo 4] | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 23 - 5/5/15: A camada de rede - IP}} | ||
+ | [http://tele.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Slides do Kurose referentes ao capítulo 4] | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 24 - 6/5/15: A camada de rede}} | ||
+ | [http://tele.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Slides do Kurose referentes ao capítulo 4] | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 25 - 12/5/15: Dúvidas}} | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 26 - 12/5/15: Avaliação 2}} | ||
+ | Sala 13 | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 27 - 18/5/15: Protocolos de roteamento}} | ||
+ | [http://tele.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Slides do Kurose referentes ao capítulo 4] | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 28 - 19/5/15: Protocolos de roteamento}} | ||
+ | [http://tele.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Slides do Kurose referentes ao capítulo 4] | ||
+ | {{Collapse bottom}} | ||
− | [http:// | + | {{Collapse top |Aula 29 - 26/5/15: Laboratório: Protocolos de roteamento}} |
+ | [http://wiki.sj.ifsc.edu.br/index.php/RED29004-2015-1#Roteiros_para_laborat.C3.B3rio Laboratório 6] | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 30 - 27/5/15: Laboratório: Protocolos de roteamento (cont.)}} | ||
+ | [http://wiki.sj.ifsc.edu.br/index.php/RED29004-2015-1#Roteiros_para_laborat.C3.B3rio Laboratório 6] | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 31 - 2/6/15: Laboratório: IPv6}} | ||
+ | [http://wiki.sj.ifsc.edu.br/index.php/RED29004-2015-1#Roteiros_para_laborat.C3.B3rio Laboratório 7] | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 32 - 3/6/15: Introdução à camada de enlace}} | ||
+ | [http://www.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%205%20Camada%20de%20enlace.pdf Slides do Kurose referentes ao capítulo 5] | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 33 - 9/6/15: Introdução à camada de enlace}} | ||
+ | [http://www.sj.ifsc.edu.br/~odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%205%20Camada%20de%20enlace.pdf Slides do Kurose referentes ao capítulo 5] | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 34 - 10/6/15: Dúvidas para a terceira avaliação e sorteio de ordem de apresentação dos seminários}} | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 35 - 16/6/15: Terceira avaliação}} | ||
+ | {{Collapse bottom}} | ||
+ | |||
+ | {{Collapse top |Aula 36 - 17/6/15: Apresentação dos seminários}} | ||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top |Aula | + | {{Collapse top |Aula 37 - 23/6/15: Apresentação dos seminários}} |
− | |||
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top |Aula | + | {{Collapse top |Aula 38 - 24/6/15: Apresentação dos seminários}} |
{{Collapse bottom}} | {{Collapse bottom}} | ||
− | {{Collapse top |Aula | + | {{Collapse top |Aula 39 - 30/6/15: Reavaliação final}} |
{{Collapse bottom}} | {{Collapse bottom}} |
Edição atual tal como às 11h20min de 8 de julho de 2015
Diário de aula de RED - 2015-1 - Prof. Odilson T. Valle
Dados Importantes
Professor: Odilson Tadeu Valle
Email: odilson@ifsc.edu.br
Atendimento paralelo: 2ª das 17h35 às 18h30 e 6ª das 9h40 às 10h35. Local: Lab. de Desenvolvimento.
- Avaliações
- 3 avaliações (P1, P2 e P3) mais um seminário (S).
- Cada uma das avaliações terá terá um conceito numérico: 1, 2, ..., 9, 10. Conceito mínimo para não necessitar reavaliação: 6.
- Um ou mais conceitos abaixo de 6 implica na realização da reavaliação: uma única a ser realizada no último dia de aula.
IMPORTANTE: o direito de recuperar uma avaliação em que se faltou somente existe mediante justificativa reconhecida pela coordenação. Assim, deve-se protocolar a justificativa no prazo de 48 horas, contando da data e horário da avaliação e aguardar o parecer da coordenação.
Plano de Ensino
Planejamento de atividades | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Material de apoio
Applets do Kurose
Vários aplicativos com representação dinâmica de características das redes de computadores.
Listas de exercícios
Lista de exercícios 1 |
---|
|
Lista de exercícios 2 - Camada de Aplicação |
---|
|
Lista de exercícios 3 - Camada de Transporte |
---|
|
Lista de exercícios 4 - Camada de Rede | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Lista de exercícios 5 - Camada de Enlace |
---|
|
Transparências utilizadas durante as aulas
Slides do Kurose referentes ao capítulo 1
Slides do Kurose referentes ao capítulo 2
Slides do Prof. Emerson - DNS, FTP, Web, Email...
Slides do Kurose referentes ao capítulo 3
Slides do Kurose referentes ao capítulo 4
Slides do Kurose referentes ao capítulo 5
Roteiros para laboratório
Laboratório 1 -- Ping, traceroute e Wireshark
Laboratório 2 - 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.
Repita as respostas e procedimentos para a mensagem de resposta do HTTP. Responda ainda:
A Interação HTTP GET Condicional/RespostaA maioria dos navegadores web tem um cache (seção 2.2.6 do livro) e, desta forma, realizam GET condicional quando baixam um objeto HTTP. Execute os seguintes passos:
Responda às seguintes questões:
Baixando Documentos LongosNos exemplos até agora, os documentos baixados foram simples e pequenos arquivos em HTML. Vamos ver o que acontece quando baixamos um arquivo em HTML grande. Faça o seguinte:
Na janela de listagem de pacotes, você deve ver a sua mensagem HTTP GET, seguida por uma reposta em vários pacotes. Esta resposta em vários pacotes merece uma explicação. Lembre-se da seção 2.2 do livro (veja a figura 2.9) que a mensagem de resposta HTTP consiste de uma linha de status, seguida por zero ou mais linhas de cabeçalhos, seguida por uma linha em branco, seguida pela carga útil (Content-Length). No caso do nossa HTTP GET, a carga útil na resposta é o arquivo HTTP completo. No nosso caso aqui, o arquivo em HTML é bastante longo, e a informação de 11747 bytes é muito grande para caber em um segmento TCP. A resposta HTTP simples é então quebrada em vários pedaços pelo TCP, com cada pedaço sendo contido dentro de um segmento TCP separado. Cada segmento TCP é capturado em um pacote separado pelo Wireshark, clique sobre o 9 "Reassembled TCP Segments" no Wireshark. Responda às seguintes questões:
Documentos HTML com Objetos IncluídosAgora que vimos como o Wireshark mostra o tráfego capturado para arquivos em HTML grandes, nós podemos observar o que acontece quando o seu browser baixa um arquivo com objetos incluídos, no nosso exemplo, imagens que estão armazenadas em outros servidores. Faça o seguinte:
Responda às seguintes questões:
Autenticação HTTPFinalmente, vamos tentar visitar um local na web que é protegido por senha e examinar a seqüência de mensagens HTTP trocadas com este local. O URL http://www.sj.ifsc.edu.br/~odilson/RED29004/Seguro/ é protegido por senha. O usuário é “red29004” (sem as aspas), e a senha é “seguro” (novamente, sem as aspas). Então vamos acessar o local protegido por senha. Faça o seguinte:
Agora vamos examinar a saída do Wireshark. Você pode querer primeiro ler sobre a autenticação HTTP revisando o material fácil de ler (em inglês) HTTP Access Authentication Framework Responda às seguintes questões:
O nome de usuário (red29004) e a senha (seguro) que você digitou foram codificados na cadeia de caracteres (cmVkMjkwMDQ6c2VndXJv) após o cabeçalho “Authorization: Basic” na mensagem HTTP GET (primeira). Parece que o nome e senha estão criptografados, mas na verdade estão simplesmente codificados em um formato denominado Base64. O nome do usuário e a senha não estão criptografados! Para ver isso, vá para https://www.base64decode.org/ e digite o texto cmVkMjkwMDQ6c2VndXJv e pressione DECODE. Voilá! Você traduziu de Base64 para ASCII, e desta forma consegue ver o nome de usuário e a senha! Sabendo que alguém pode baixar o Wireshark e capturar pacotes (não somente os próprios), e alguém pode traduzir de Base64 para ASCII (você acabou de fazê-lo!), deve estar claro para você que o uso de senhas apenas em locais na web não garantem segurança, a não ser que medidas adicionais sejam tomadas. Não tema! Há meios de fazer o acesso WWW ser mais seguro. Contudo, nós claramente precisamos de algo que vá além do framework básico de autenticação HTTP! HTTPSPara finalizar, vamos capturar sequências de mensagens HTTPS, somente a título de comparação. Execute os seguintes procedimentos:
Responda:
|
Laboratório 3 - Serviço de Nomes (DNS) |
---|
O Domain Name System (DNS) traduz nomes de hosts em endereços Internet Protocol (IP), preenchendo uma lacuna crítica na infraestrutura da Internet. Neste laboratório, observaremos de mais perto inicialmente o lado cliente do DNS, uma pequena análise do protocolo e no final uma breve introdução ao servidor DNS. Lembre-se de que o papel do cliente no DNS é relativamente simples - um cliente envia uma consulta ao seu DNS, e obtém uma resposta. Muito pode acontecer “por baixo dos panos”, de forma invisível aos clientes DNS, enquanto os servidores DNS, organizados hierarquicamente, comunicam-se entre si para, ou recursivamente ou iterativamente, resolver uma consulta DNS de um cliente. Do ponto de vista do cliente DNS, contudo, o protocolo é bastante simples - uma consulta é feita ao seu servidor DNS e uma resposta é recebida deste servidor. Consultas DNS por meio de ferramentas especializadas
|
Laboratório 4 - Programação de sockets |
---|
Objetivo principal: entender o conceito de sockets. Processos que rodam em máquinas diferentes se comunicam entre si enviando mensagens para sockets. Um processo é semelhante a uma casa e o socket do processo é semelhante a uma porta. A aplicação reside dentro da casa e o protocolo da camada de transporte reside no mundo externo. Um programador de aplicação controla o interior da casa mas tem pouco (ou nenhum) controle sobre o exterior. Descrição da aplicação a ser desenvolvida em UDP e TCP
Programação de sockets com UDPA aplicação cliente-servidor usando UDP tem a estrutura apresentada na Figura baixo. Utilizamos a linguagem Python por expor com clareza os principais conceitos de sockets. Quem desejar pode implementar em outras linguagens, por exemplo um modelo para programação de sockets utilizando a API Posix encontra-se aqui. Como fica evidente na Figura acima, os processos cliente e servidor rodam em máquinas distintas e se comunicam justamente enviando mensagens via sockets, que abstrai qualquer necessidade de conhecimento das camadas subjacentes. Um exemplo de código bem simples para o lado Cliente: UDPClient.py
|
Laboratório 5 - TCP x UDP |
---|
O objetivo desses experimentos é evidenciar as diferenças entre os protocolos TCP e UDP. Experimento 1Ambos protocolos de transporte podem ser usados por aplicações que precisem se comunicar. Porém cada um deles têm certas propriedades, então a escolha precisa ser feita dependendo do tipo de comunicação a ser feita pela aplicação. Por exemplo, o que aconteceria se um arquivo fosse transferido de um computador a outro com ambos protocolos ?
Experimento 2Transferências usando cada um desses protocolos podem apresentar características bem distintas. Neste segundo experimento, serão feitas transferências simultâneas de arquivos a partir de um mesmo servidor, comparando-se o resultado obtido com TCP e UDP. Essas transferência ocorrerão entre os computadores do laboratório e um servidor externo ao laboratório.
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ório 6 - Protocolos de roteamento |
---|
Objetivos: Analisar o funcionamento de protocolos de roteamento estático e dinâmico da Internet, em particular as tabelas estáticas de roteamento, o protocolo RIP e OSPF, a partir de uma estrutura física formada por roteadores e redes locais. Para atingir tais objetivos utilizaremos o 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 7 - IPv6 |
---|
Este roteiro foi baseado no material disponível em [2]. Slides de endereçamento IPv6. Guia didático de endereçamento IPv6 obtido de http://ipv6.br/. Objetivos do laboratório:
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. Procedimento:
|
Softwares
- Netkit2: possibilita criar experimentos com redes compostas por máquinas virtuais Linux
- 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
- 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
Seminários
- Objetivos:
- Aprofundamento teórico em algum tema atual e relevante
- Confecção de um relatório de trabalho no estilo científico
- Apresentação de um trabalho científico
Recomenda-se a confecção do relatório na própria Wiki. O professor criará a página para cada projeto que assim o desejar. Na página do projeto, os membros da equipe podem editar a qualquer hora, sem preocupação com a versão do mesmo. Também facilita o acompanhamento por parte do professor. Utilizando ou não a Wiki, usem esse modelo de relatório.
- Grupos e Temas para 2015-1:
- Lucas e Mathias: HTTPS. Slides da apresentação
- Letícia e Jessica: HTML 5 ou Hidden Slides da apresentação
- Helenluciany Maria Luiza: QoS Slides da apresentação
- Katharine e Kristhine: Ad-Hoc Network.Slides da apresentação.
- Angelo e Iago: HTTP2. Slides da apresentação.
- Anderson e Gabriel: VPN Slides da apresentação
- Cleiton e Gustavo: SNMP
- Ordem de apresentação dos seminários
- 17/06 - Ad-Hoc Network, HTTPS, SNMP
- 23/6 - HTML5, Qos, VPN
- 24/6 - HTTP2
- Avaliação
- Nota: 0,5 x Documento + 0,5 x Seminário
- Avaliação dos relatórios entregues
- Instruções sobre o Seminário de Redes I:
- Data para definição de grupos e temas: 10/3/15.
- 2 alunos por equipe.
- Os temas devem ser propostos pelas equipes em comum acordo com o professor ou então na data limite o professor apresenta alguns temas e as equipes escolhem.
- Data de entrega do documento: 2/6/15 (impreterivelmente).
- O relatório pode ser redigido como uma página da wiki.
- Duração da apresentação: 20 minutos + 5 minutos de perguntas.
- As apresentações podem ser realizadas seguindo o conteúdo do relatório (use bastante figuras no relatório, isto facilita a apresentação).
- Se preferirem usar slides, usem esse modelo.
Diário de aulas
Aula 1 - 4/2/15: Apresentação da disciplina |
---|
|
Aula 2 - 10/2/15: Introdução às redes de computadores |
---|
Aula 3 - 11/2/15: Introdução às redes de computadores |
---|
Aula 4 - 11/2/15: Introdução às redes de computadores |
---|
Aula 5 - 24/2/15: Introdução às redes de computadores |
---|
Aula 6 - 25/2/15: Introdução às redes de computadores |
---|
Aula 7 - 3/3/15: Introdução às redes de computadores |
---|
Aula 8 - 4/3/15: Laboratório 1 - Ping Traceroute Wireshark |
---|
Aula 9 - 10/3/15: Camada de aplicação - Comunicação entre processos HTTP |
---|
Aula 10 - 11/3/15: Camada de aplicação - HTTP FTP SMTP |
---|
Aula 11 - 17/3/15: Laboratório 2 - HTTP |
---|
Aula 12 - 18/3/15: Camada de aplicação - DNS |
---|
Aula 13 - 24/3/15: Laboratório 3 - DNS |
---|
25/3/15: Não houve aulas - licença médica |
---|
Aula 14 - 31/3/15: Camada de aplicação - P2P - Finalização Laboratório DNS |
---|
Aula 15 - 1/4/15: Dúvidas |
---|
Aula 16 - 7/4/15: Avaliação 1 |
---|
Aula 17 - 8/4/15: Introdução a camada de transporte - Multiplexação/Demultiplexação - UDP |
---|
Aula 18 - 14/4/15: Laboratório Sockets |
---|
Aula 19 - 15/4/15: TCP |
---|
Aula 20 - 22/4/15: Controle de congestionamento -- TCP |
---|
Aula 21 - 28/4/15: Laboratório: TCP versus UDP |
---|
Aula 22 - 29/4/15: A camada de rede - Redes de datagramas, circuitos virtuais e roteadores |
---|
Aula 23 - 5/5/15: A camada de rede - IP |
---|
Aula 24 - 6/5/15: A camada de rede |
---|
Aula 25 - 12/5/15: Dúvidas |
---|
Aula 26 - 12/5/15: Avaliação 2 |
---|
Sala 13 |
Aula 27 - 18/5/15: Protocolos de roteamento |
---|
Aula 28 - 19/5/15: Protocolos de roteamento |
---|
Aula 29 - 26/5/15: Laboratório: Protocolos de roteamento |
---|
Aula 30 - 27/5/15: Laboratório: Protocolos de roteamento (cont.) |
---|
Aula 31 - 2/6/15: Laboratório: IPv6 |
---|
Aula 32 - 3/6/15: Introdução à camada de enlace |
---|
Aula 33 - 9/6/15: Introdução à camada de enlace |
---|
Aula 34 - 10/6/15: Dúvidas para a terceira avaliação e sorteio de ordem de apresentação dos seminários |
---|
Aula 35 - 16/6/15: Terceira avaliação |
---|
Aula 36 - 17/6/15: Apresentação dos seminários |
---|
Aula 37 - 23/6/15: Apresentação dos seminários |
---|
Aula 38 - 24/6/15: Apresentação dos seminários |
---|
Aula 39 - 30/6/15: Reavaliação final |
---|