RCO11102 Edições Anteriores

Semestre 2020-2 - Prof. Eraldo Silveira e Silva

1 Professor Professor: Eraldo Silveira e Silva Email: eraldo@ifsc.edu.br Atendimento paralelo: a definir 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. O não cumprimento desse procedimento implica a impossibilidade de fazer a recuperação, e assim a reprovação na disciplina. 1.1 Plano de Ensino Atenção: ver forma de avaliação no SIGAA 1.2 Objetivos e Conhecimentos conforme PPC Objetivos (1) Caracterizar e classificar as redes de computadores. (2) Utilizar e configurar aplicações cliente e aplicativos de rede da Internet, identificando as funcionalidades dos protocolos utilizados. (3) Identificar as funcionalidades e a abrangência dos protocolos da arquitetura Internet (TCP/IP). (4) Planejar e configurar redes e sub-redes IP; Conhecimentos (1) Componentes de uma rede de computadores: aplicações, hosts, roteadores, enlaces; (2) Comutação de pacotes; (3) Aplicações de rede: Web, DNS, FTP, SSH; (4) Protocolos de transporte e portas utilizadas pelas aplicações. (5) Endereçamento de redes IP e sub-redes; (6) Roteamento estático de redes IP; 1.3 Apostilas ATENÇÂO: Estamos em fase de atualização desta apostila. Apostila de Redes de Computadores do Prof. Evandro Cantú 1.4 Proposta de Cronograma de Semanas/Aulas 1.5 9/11/20: Aula Inicial 1.5.1 Objetivos Recepção: Apresentação da disciplina, plano de aula, laboratórios e métodos de avaliação. Parte Teórica: Introdução a Redes de Computadores [slides] Um exemplo de Rede ou de rede de Redes: a Internet Parte Prática: Laboratório 0 (preparação da Máquina Virtual com o Simulador de Rede Imunes) 1.5.2 Laboratório 0 Laboratório 0: Instalação de VirtualBox e do Imunes' Para realizar os roteiros em casa deve-se utilizar o VirtualBox e uma máquina virtual pré-configurada com todo o ferramental necessário: Baixe e instale o VirtualBox; Baixe a máquina virtual e salve em um diretório qualquer de sua máquina; Acesse o diretório onde salvou o arquivo Redes.ova e dê duplo clique sobre o mesmo; Irá abrir um janela do VirtualBox com a opção de Importar Appliance Virtual, deixe todas as opções padrão e clique em Importar; Irá abrir outra janela do VirtualBox: Importando Appliance...; Ao terminar sua máquina virtual estará pronta para uso. Usuário: aluno, senha: aluno. 1.6 16/11/20: Aula Inicial 1.6.1 Objetivos 1.7 25/11/20: Conceitos Básicos de Redes 1.7.1 Objetivos Objetivos Geral:Caracterizar e classificar as redes de computadores. Conceito de rede de computadores (revisão) A Internet como exemplo: visão geral (revisão) Comutação de Circuitos X Pacotes Componentes de uma rede de pacotes: computadores, roteadores, switches. Redes LAN, WAN e MAN Enlaces e topologias Redes de Comutação de Pacotes: quadros,pacote, endereçamento MACxIP Taxa de Transmissão, Vazão, Bandwidth e Retardo Ver tarefa e apostila no SIGAA 1.8 AULA 2/11/20 1.8.1 Objetivos Após este laboratório o aluno deverá ser capaz de: Verificar a configuração de interfaces de rede de um hospedeiro usando a ferramenta ifconfig, identificando: O endereço de hardware da interface (endereço MAC); O endereço IPv4 e IPv6 da Interface com as suas máscaras de rede; Testar a conectividade entre dois hospedeiros usando a ferramenta ping e ganhar insight em relação aos atrasos na rede; Observar a rota de pacotes IP entre dois hospedeiros usando a ferramenta traceroute; Capturar pacotes de uma interface usando a ferramenta wireshark. 1.8.2 Ferramentas de Apoio ifconfig Ping traceroute wireshark (se der tempo) 1.8.3 Link Laboratório 1 https://wiki.sj.ifsc.edu.br/index.php/Professores:RoteirosLabsANP LabsRedesSubs 1.8.4 Outros https://www.rapidtables.com/convert/number/ascii-to-binary.html 1.9 AULA 16/12/20 1.9.1 Objetivos 1.10 Objetivos Após este laboratório o aluno deverá ser capaz de: utilizar a ferramenta wireshark para captura de pacote: funções básicas de filtragem na captura e no display; verificação de estruturas de pacotes; consolidar o conceito de protocolo e de camadas de protocolos através da análise de troca de pacotes com ping e traceroute usando: as janelas com detalhes dos pacotes e encapsulamentos; a opção de flow graph para visualizar as trocas de mensagens. Laboratório 2 - Wireshark e encapsulamento 1.10.1 Laboratório 2 1.11 Objetivos Após este laboratório o aluno deverá ser capaz de: utilizar a ferramenta wireshark para captura de pacote: funções básicas de filtragem na captura e no display; verificação de estruturas de pacotes; consolidar o conceito de protocolo e de camadas de protocolos através da análise de troca de pacotes com ping e traceroute usando: as janelas com detalhes dos pacotes e encapsulamentos; a opção de flow graph para visualizar as trocas de mensagens. 1.12 Sobre o analisador Wireshark 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. 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. OBS: Se o wireshark estiver instalado em sua máquina, para chamá-lo a partir de um terminal deve fazer: sudo wireshark 1.13 ETAPA 1: Identificando os campos da interface do Wireshark Quando você executar o programa Wireshark, a interface com o usuário exibida na Figura abaixo aparecerá. Inicialmente, nenhum dado será apresentado nas janelas. A interface do Wireshark tem seis componentes principais: Os menus de comandos são localizados no topo da janela. Por enquanto, interessam apenas os menus File e Capture. O menu File permite salvar dados de capturas de pacotes ou abrir um arquivo contendo dados de capturas de pacotes previamente realizadas, e sair da aplicação. O menu Capture permite iniciar uma captura de pacotes; A barra de ferramentas contém os comandos de menu que são mais frequentemente utilizados. Há atalhos para abrir ou salvar dados de captura de pacotes e para iniciar ou parar uma captura de pacotes; Abaixo da barra de ferramentas, está o campo de filtragem de pacotes exibidos. Nele podem ser digitados nome de protocolo ou outra informação apresentada na janela de listagem de pacotes. Apenas os pacotes que correspondem ao filtro são exibidos; A janela de listagem de pacotes apresenta um resumo de uma linha para cada pacote capturado, incluindo o número do pacote (atribuído pelo Wireshark; este não é o número do pacote contido no cabeçalho de qualquer protocolo), o tempo que o pacote foi capturado, os endereços fonte e destino do pacote, o tipo de protocolo, e informação específica do protocolo contida no pacote. A lista de pacotes pode ser ordenada conforme qualquer uma destas categorias clicando no nome de uma coluna correspondente. O campo tipo do protocolo lista o protocolo de mais alto nível que enviou ou recebeu este pacote, i.e., o protocolo que é a fonte ou o último sorvedouro para este pacote; A janela de detalhes de cabeçalho de pacotes fornece detalhes sobre o pacote selecionado na janela de listagem de pacotes. Para selecionar um pacote, basta clicar sobre ele com o botão esquerdo do mouse na janela de listagem de pacotes. Os detalhes apresentados incluem informações sobre o quadro Ethernet e o datagrama IP que contém o pacote. A quantidade de detalhes exibida pode ser expandida ou contraída. Se o pacote foi carregado sobre TCP ou UDP, detalhes correspondentes também são apresentados, os quais também podem ser contraídos ou expandidos. Finalmente, detalhes sobre o protocolo de mais alto nível que enviou ou recebeu este pacote também são apresentados; A janela de conteúdo de pacotes mostra o conteúdo inteiro do quadro capturado, nos formatos ASCII e hexadecimal. 1.13.1 ETAPA 2 - Verificando pacotes do ping (ICMP REQUEST/REPLY)) Inicie o navegador web; Inicie o Wireshark. Inicialmente as janelas estarão vazias, pois não há captura de pacotes em progresso; Para iniciar uma captura de pacotes, selecione o menu Capture e depois Interfaces. Provavelmente sua interface de rede será a eth0. Isso faz com que a janela de interfaces de rede disponíveis seja apresentada (Figura 4); Figura 4 - Interfaces de rede no Wireshark O botão Start da interface eth0 deve ser selecionado. Na Figura 4, no Wireshark foi selecionada a interface wlan; Como nada está acontecendo na rede, a janela apresenta o conteúdo vazio; Execute um comando ping (endereço na saída da nossa rede - ver aula anterior): ping 200.237.201.153 Ao voltar para a janela do Wireshark, houve a captura de todos os pacotes envolvidos no process; Antes de continuar, vamos parar a captura de pacotes e trabalhar com o que temos. Basta clicar em Capture e depois em Stop; Para testar as capacidades de filtragem, vamos inserir a cadeia “icmp” (sem as aspas e em minúsculo) no especificação do filtro de exibição e depois selecionar Apply (ou Aplicar). Observe que somente os pacotes envolvidos no ping estão sendo mostrados. Os resultados obtidos devem ser similar a tela mostrada na Figura 5. Selecione a primeira mensagem ECHO REQUEST: as informações dos cabeçalhos do quadro Ethernet, do datagrama IP, do pacote ICMP aparecem na janela de cabeçalhos de pacotes. É possível ver os detalhes, expandido ou comprimindo os itens com um clique na seta ao lado deles. Selecione uma mensagem ECHO REPLY. Analise o pacote: endereço fonte, endereço destino etc; Saia do Wireshark. 1.13.1.1 Etapa 3 ATENÇÃO: ESTA ESTA DEVERÁ SER ENTREGUE NA FORMA DE TAREFA. VER SIGAA. Com Wireshark ativo (Abra-o novamente) e em modo captura, faça um "ping" para um site conhecido (você pode usar o nome: www.ifsc.edu.br por exemplo). Aplique um filtro icmp no display. Recorte a tela observada e indique os pacotes ICMP ECHO REQUEST. Discuta quem são os endereços IP e MAC que aparecem no pacote IP e Frame Ethernet. Aplique um comando Flow Graph e mostre a troca de mensagens do ping através de um recorte da tela; Encerre e execute novamente o wireshark. Através do menu captura crie um filtro para captura de pacotes icmp que SOMENTE saem da sua máquina (ver ip.src). Faça um recorte das telas de criação do filtro (mostrando o filtro). Faça uma captura usando o filtro, recorte a tela e mostre os resultados. Faça uma captura de sua escolha usando de forma combinada filtros de captura e de display. Por exemplo, mostre somente pacotes originados e/ou destinados a um determinado host (ip.addr == 192.168..., ip.src, ip.dst). 1.14 AULA 23/12/20 1.14.1 Objetivos Finalização do Laboratório de Wireshark Avaliação (?) 1.15 AULA 3/2/2021 1.15.1 LINK PARA AULA SÍNCRONA https://conferenciaweb.rnp.br/webconf/redes-de-computadores-tecnico-subsequente-em-telecomunicacoes 1.15.2 LINK PARA SLIDES Slides HTTP Básico 1.15.3 OBJETIVOS ESTUDO DA CAMADA DE APLICAÇÂO Conceito de Protocolo de Aplicação Modelo Cliente Servidor Introdução ao Protocolo HTTP Formato e Comandos Conexões Persistentes e Não persistentes 1.15.4 DESENVOLVIMENTO DA AULA Apresentação de Slides (40 minutos) - Link SIGA A Exemplos Wiki (15 minutos) Proposição de Questionário Discussão das Respostas do Questionário 1.15.5 Exemplos 1.15.5.1 Exemplo 1 Acessando e vendo uma página html no browser Acessar com o browser a URL http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004.html Ver código fonte. Capturar pacotes e verificar captura. Acessar com telnet: telnet -4 tele.sj.ifsc.edu.br 80 GET /~odilson/RED29004//RED29004.html HTTP/1.0 Acessar com telnet: telnet -4 tele.sj.ifsc.edu.br 80 GET /~odilson/RED29004//RED29004.html HTTP/1.1 1.15.5.2 Exemplo 2 Repetir os passos do exemplo http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq3.html 1.16 AULA 10/2/2021 1.16.1 LINK PARA AULA SÍNCRONA https://conferenciaweb.rnp.br/webconf/redes-de-computadores-tecnico-subsequente-em-telecomunicacoes 1.16.2 LINK PARA SLIDES Slides HTTP Básico HTTP-parte2 1.16.2.1 Laboratório de HTPP Básico ATENÇÃO: A execução deste laboratório deve ser reportada em um documento a ser postado no SIGAA. Para cada item faça um recorte da tela e comente o que foi feito. 1.16.2.1.1 Parte 1 - Observando o significado de um código/página HTML Edite em um editor de texto comum um código html (siga o exemplo a seguir mas faça diferente) e salve o arquivo como teste.html: <html><body><h1>REDES DE COMPUTADORES</h1> <p>Alo IFSC!</p> </body></html> Abra o arquivo usando o browser. Clicando sobre ele provavelmente já será mostrado. DESAFIO: Pesquise e coloque na página acima um link que ao ser clicado leva ao site: http://sj.ifsc.edu.br 1.16.2.1.2 Parte 2 - Funcionamento Básico do Comando GET no HTTP Nesta etapa será realizado um acesso básico a uma página que está no IFSC SJ. Usando o browser (preferencialmente o firefox), acesse a URL: http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004.html Acesse a direita, o menu no Firefox os 3 pontos e abra Desenvolvimento Web -> Console Web. Desabilite o cache e faça um refresh com F5. Recorte os comandos/respostas envolvidos no acesso a página e monte um diagrama de troca de mensagens indicando as mensagens envolvidas e as partes envolvidas. Faça um texto explicativo. 1.16.2.1.3 Parte 3 - Funcionamento Básico do Comando GET no HTTP - Página com múltiplos links Nesta etapa será realizado um acesso básico a uma página que está no IFSC SJ. Usando o browser (preferencialmente o firefox), acesse a URL: http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq4.html Acesse a direita, o menu no Firefox os 3 pontos e abra Desenvolvimento Web -> Console Web. Desabilite o cache e faça um refresh com F5. Recorte os comandos/respostas envolvidos no acesso a página e monte um diagrama de troca de mensagens indicando as mensagens envolvidas e as partes envolvidas. Faça um texto explicativo sobre a sequência de acontecimentos e os principais campos envolvidos nos comandos/resposta. 1.17 AULA 17/2/2021 1.17.1 LINK PARA AULA SÍNCRONA https://conferenciaweb.rnp.br/webconf/redes-de-computadores-tecnico-subsequente-em-telecomunicacoes 1.17.2 LINK PARA SLIDES Ver siga Serviço de Nomes - DNS Slides UFSC Adicionais FE Portugal 1.17.3 Exercícios em Aula Estes exercícios serão executados pelo professor e poderão ser reproduzidos pelos alunos após a aula. O aluno deverá consultar a gravação da aula. Executar um comando: ping www.ifsc.edu.br e usando um analisador de pacotes verificar os pacotes DNS e ICMP gerados. Limpar o cache DNS com: sudo systemd-resolve --flush-caches Gerar uma resuisição DNS manualmente: host -t A www.ifsc.edu.br Este comando pode ser acompanhado da captura de pacotes para verificar o acesso DNS. 1.18 AULA DIA 3/3/2021 1.18.1 Objetivos Após esta o aluno deverá ser capaz de: explicar o papel dos protocolos de transporte na arquitetura TCP/IP; entender o papel das portas nos protocolos de transporte; diferenciar os protocolos UDPs e TCPs; descrever a estrutura pacote UDP e as principais características do UDP; entender porque o TCP é orientado a conexão e descrever as principais características do TCP; descrever a estrutura do pacote (segmento)TCP usar o netcat para realizar testes de conexão/envio de dados em portas. 1.18.2 LINK PARA AULA SÍNCRONA https://conferenciaweb.rnp.br/webconf/redes-de-computadores-tecnico-subsequente-em-telecomunicacoes 1.18.3 LINK PARA SLIDES 1.18.4 LABORATÓRIO BÁSICO UDP e TCP Familiarizar-se com o UDP Entender a estrutura do pacote UDP Entender o conceito de portas Entender o conceito de multiplexação 1.18.5 FERRAMENTA PARA ESTE LABORATÓRIO netcat no Linux ou NetPal no Androide; capturador de tela no Linux ou no Androide; capturador de pacotes (computador do professor). processador de texto para montar um mini relatório. 1.18.6 Fonte Base Introdução a camada de transporte e UDP básico 1.18.7 Parte 1 - Fluxo único UDP O professor executará o programa netcat para escutar em uma porta UDP na máquina da CLOUD IFSC da seguinte forma. netcat -l -u 191.36.8.58 PORTA O aluno enviará uma mensagem UDP para a porta que o professor indicar. netcat -u IP_DEST PORTA O professor vai capturar pacotes pelo wireshark. O aluno deve recortar a tela para fazer um mini-relatório. Cada aluno recorta a tela das suas comunicações. Identifique e anote os seguintes dados na captura do wireshark: IP FONTE e DESTINO (discuta quem são estes endereços) PORTAS FONTE E DESTINO para ambas comunicações Campo de protocolo no pacote IP Campo de tamanho (anote o tamanho) e checksum no pacote (datagrama) UDP O campo de dados no pacote UDP Foi identificado algum procedimento para conexão em nível de transporte? 1.18.8 Parte 2 - Fluxo único TCP Fonte Base Camada de transporte: TCP básico O professor executará o programa netcat para escutar em uma porta UDP na máquina da CLOUD IFSC da seguinte forma. netcat 191.36.8.58 PORTA O aluno enviará uma mensagem UDP para a porta que o professor indicar. netcat IP_DEST PORTA O professor vai capturar pacotes pelo wireshark. O aluno deve recortar a tela para fazer um mini-relatório. Cada aluno recorta a tela das suas comunicações. Identifique e anote os seguintes dados na captura do wireshark: IP FONTE e DESTINO (discuta quem são estes endereços) PORTAS FONTE E DESTINO para ambas comunicações Campo de protocolo no pacote IP Campo de tamanho (anote o tamanho) e checksum no pacote (datagrama) UDP O campo de dados no pacote UDP Foi identificado algum procedimento para conexão em nível de transporte? Identifique as mensagens associadas a conexão (mostre o recorte da tela). Identifique as mensagens associadas a transmissão dos dados. 1.19 AULA DIA 10/3/2021 1.19.1 Objetivos Após esta o aluno deverá ser capaz de: explicar o papel dos protocolos de transporte na arquitetura TCP/IP; entender o papel das portas nos protocolos de transporte; diferenciar os protocolos UDPs e TCPs; descrever a estrutura pacote UDP e as principais características do UDP; entender porque o TCP é orientado a conexão e descrever as principais características do TCP; descrever a estrutura do pacote (segmento)TCP Esta aula é continuação da aula anteirior. O professor vai usar slides para rever o assunto e vai propor: 1) Um questionário 2) Um mini relatório do laboratório da aula anterior. 1.20 AULA DIA 10/3/2021 1.20.1 Objetivos Após esta o aluno deverá ser capaz de: Citar as principais caracteŕisticas do protocolo IP; Identificar os principais campos de um pacote IP; Identificar a parte netid e hostid de um endereço IP Saber observar uma tabela de roteamento em um host e o significado da mesma; Diferenciar entrega direta de indireta de pacotes. 1.20.2 Instruções Adicionais para Aula Para esta aula necessitaremos da ferramenta imunes. Alguns alunos já instalaram a ferramenta em suas máquinas. Estas instruções são para àqueles alunos que estão com dificuldade de instalar em suas máquinas. Para estes alunos será repassado o acesso a uma máquina virtual no IFSC através da ferramenta X2GO client. Torna-se necessário então INSTALAR o X2GO client em suas máquinas. Este software pode ser instalado no WINDOWS. Basta baixar e instalar normalmente através deste link: X2GO client para Windos Você deve ter direito de instalação no computador. 2 AULA DIA 17/03/2021 VER SIGAA - Fazer tarefa 3 AULA DIA 24/03/2021 3.1 Interligação de duas redes através de um roteador Baseado na wiki do Prof.Odilson 3.1.1 Objetivos Introdução ao mundo IP Verificação das configurações de interfaces de rede Verificação de tabelas de roteamento nos hospedeiros e no roteador Verificação de movimentação de pacotes (rotas) em roteadores Usaremos como base a seguinte arquitetura de rede: 3.1.2 Fonte Base Endereçamento MAC x Endereçamento IP 3.1.3 Procedimento 1 - Análise simples do Roteamento: Entrega Direta e Indireta Baixe o arquivo de configuração da rede, no terminal digite: wget -4 http://docente.ifsc.edu.br/odilson/RED29004/Roteador_com_duas_redes.imn Execute o Imunes. sudo imunes Carregue o arquivo de configuração: File >> Open >> /home/aluno/Roteador_com_duas_redes.imn Inicie a simulação no Imunes: Experiment >> Execute Ignore (dismiss) a mensagem de erro apresentada. O erro é proposital. Observe que a rede é composta de 4 PCs (pc1 - pc4), 1 roteador (router1) e 2 switchs. O roteador possui duas interfaces de rede, com seus respectivos IPs - camada 3, que interliga as duas sub-redes. Cada switch tem 3 interfaces, mas sem IPs, camada 2. Anotar os endereços de hardware (ou MAC) e IP de cada dispositivo na rede. No terminal de cada PC execute: ifconfig Observar, interpretar e anotar a tabela de roteamento em todos os hospedeiros pc1 - pc4 e no roteador router1. Identificar os default gateways em cada PC. route -n Observar, "provar" e anotar que pacotes indo do pc1 para pc2 são enviados diretamente para pc2, ou seja, entrega direta. Explique a entrega direta. Deixe o ping entre pc1 e pc2, em pc1 execute: ping 10.0.0.21 No router1 capture pacotes com o Wireshark na interface eyh0: Clique com o botão direito do mouse sobre o Cliente1 >> Wireshark >> eth0... Observe que não há tráfego de pacotes no router1, portanto, entrega direta. Observar, "provar" e anotar que pacotes indo de pc1 para pc4 são encaminhados ao roteador e, em seguida, entregues ao destino, ou seja, entrega indireta. Explique a entrega indireta. 3.1.4 Procedimento 2 - Configuração básica de interface de rede No pc3 teste a conectividade com os demais PCs, por exemplo, fazendo pings para o pc1 e pc4: ping 10.0.0.20 ping 10.0.1.21 Perceba que não há conectividade, não há resposta aos pings, dado que a interface de rede do pc3 não está devidamente configurada. Assim sendo, configure a interface de rede no pc3. Anote todos os comandos executados. Inicie configurando o IP com o comando ifconfig (man ifconfig). Dica: Observe a configuração de rede do pc4, que está na mesma sub-rede, e tente adaptá-la para o pc3. Assim que a configuração do IP for bem sucedida o ping para o pc4 deverá funcionar. Tente "pingar" para o pc1. Ainda não haverá sucesso, pois não há um roteador devidamente configurado no pc3. Configure o roteador no pc3 com o comando route (man route). Assim que a configuração do roteador for bem sucedida o ping para o pc1, e qualquer outro PC da rede, deverá funcionar. O mesmo deverá ser capaz de "pingar" para qualquer outro PC ou ser "pingado". Execute o comando ping do pc3 para o pc4. Obteve sucesso? Se não corrija as configurações. Execute o comando ping do pc3 para o pc1. Obteve sucesso? Se não corrija as configurações. Execute o comando ping do pc2 para o pc3. Obteve sucesso? Se não corrija as configurações. 3.1.4.1 Referências adicionais Guia de Administração da Camada IP no Linux 4 AULA DIA 31/03/2021 Laboratório do Prof.Odilson com algumas modificações 4.1 Tabelas Estáticas de Roteamento 4.1.1 Objetivos Revisão do Endereçamento IP Analisar o funcionamento de roteadores com tabelas estáticas de roteamento. Verificar a entrega direta e indireta de pacotes. Estabelecer rotas estáticas em uma rede simples. Analisar loops em rede. Nesta aula teremos que finalizar o procedimento 2 do lab anterior. 4.1.2 Revisão do Endereçamento IP O endereçamento IPv4, conforme estudamos, possui 32 bits. Quando configuramos uma interface de um computador com este endereço fornecemos um endereço IP ACOMPANHADO de uma máscara: Exemplo: Se logarmos no computador imunes.sj.ifsc.edu.br e fizermos o comando ip addr Vamos observar que a interface eth0 está configurada forma: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 86:56:2f:f9:4c:07 brd ff:ff:ff:ff:ff:ff inet 191.36.8.59/26 brd 191.36.8.63 scope global eth0 Indicando claramente que o endereço IPv4 da interface eth0 é: 191.36.8.59/26 Vamos usar o site calculdor IP para observar a anatomia deste endereço. Exercício (ver SIGA A) Faça um análise do endereço 191.36.8.59/26 e responda: Entre no PC imunes.sj.ifsc.edu.br, liste as propriedades da interface eth0 e cole a tela aqui. Use o endereço IP e máscara para respondere as próximas questões. Faça uma tabela com cada número decimal (estão entre pontos) e o correspondente em bits. Como seria o endereço da rede correspondente a este número IP (191.36.8.59/26) em bits (ou seja, na representação binária) e em decimal? Quantos bits correspondem ao host id e ao net id? Quantos hospedeiros poderiam estar nesta rede? Como é representada a máscara de rede em bits e em decimal? Qual o endereço MAC da eth0? Mostre em hexadecimal e em bits. 5 AULA DIA 7/04/2021 5.1 Objetivos Analisar o funcionamento de roteadores com tabelas estáticas de roteamento. Verificar a entrega direta e indireta de pacotes. Estabelecer rotas estáticas em uma rede simples. Analisar loops em rede. Laboratório do Prof.Odilson com algumas modificações 5.1 Tabelas Estáticas de Roteamento 5.1.1 Arquitetura de rede Em todos os experimentos será utilizado como base a seguinte arquitetura de rede: 5.1.2 Tabelas estáticas de roteamento Baixe o arquivo de configuração da rede, no terminal digite: wget -4 http://docente.ifsc.edu.br/odilson/RED29004/3_roteadores_tab_estaticas.imn Execute o Imunes. sudo imunes Carregue o arquivo de configuração: File >> Open >> /home/aluno/3_roteadores_tab_estaticas.imn Inicie a simulação no Imunes: Experiment >> Execute Observe que a rede é composta de 3 PCs (pc0 - pc2) e 3 roteadores roteador (R0 - R2). Testes de conectividade de enlace e configuração do default gateway. Por exemplo, no pc0 execute o comando: ping 10.0.0.1 Obteve sucesso? Sim ou não e por quê? Teste a conectividade do pc0 executando o comando: ping 10.0.10.1 Obteve sucesso? Sim ou não e por quê? Qual foi o erro observado? Por exemplo, no pc0 execute o comando: ping 10.0.10.2 Obteve sucesso? Sim ou não e por quê? Qual foi o erro observado? Configure o roteador padrão em todos os PCs. Adapte o comando exemplo do pc0 para todos os PCs: route add -net default gw 10.0.0.1 Com este comando estamos: i) adicionando (add) uma rota ii) do tipo rede (net) iii) rota padrão (default), que é equivalente a 0.0.0.0 iv) com o roteador (gw - gateway) v) 10.0.0.1 que identifica a interface do roteador, R0, diretamente conectado ao host pc0, no caso. Teste novamente a conectividade, no pc0 execute o comando: ping 10.0.10.1 e ping 10.0.10.2 Obteve sucesso? O comportamento foi o mesmo das tentativas anteriores? Sim ou não e por quê? Qual foi o erro observado? Com os ping do item anterior ativos (um a cada tempo) rode o Wireshark no R0 (clique com o botào direito do mouse sobre o R0 e em seguida no menu wireshark eth0). Qual a origem e destino dos pacotes? Explique? Qual a diferença no ping entre os dois itens? Iniciando o roteamento. Deixe o ping do do pc0 para o R1 e o wireshark - eth0 no R0 rodando e estabeleça uma rota no roteador R1 com o comando: route add -net 10.0.0.0/24 gw 10.0.10.1 O que ocorreu com o ping e o wireshark? Por quê? Com este comando estamos: i) adicionando (add) uma rota ii) do tipo rede (net) iii) para a rede 10.0.0.0/24 iv) com o roteador (gw - gateway) v) 10.0.10.1 que identifica a interface do roteador, R0, diretamente conectado ao roteador R1. Em todos os roteadores crie rotas para todas as redes. Em cada roteador deve-se criar 3 rotas, para as sub-redes "distantes", não diretamente conectadas. Lembre-se que os enlaces diretos já criam automaticamente rotas para as respectivas sub-redes diretamente conectadas ao equipamento, ou seja, entrega direta. Se tudo estiver correto, todos os PCs e roteadores devem pingar entre si. Crie rotas sempre pelo caminho mais curto, por exemplo, do R0 para a rede do pc1 e pc2 passando por R1 e para R2 respectivamente. Trace e anote as rotas entre os hosts através do traceroute. Testando a queda de enlace. Com todas as rotas em perfeito funcionamento, gere um ping do pc0 para o pc2 e execute wireshark eth0 no R0 , em seguida "derrube" o enlace entre o R0 e R2. Por exemplo, no R2 execute o comando: ifconfig eth1 down 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? 5.1.3 Testando campo TTL com loop na rede Baixe o arquivo de configuração da rede, no terminal digite: wget -4 http://docente.ifsc.edu.br/odilson/RED29004/3_roteadores_tab_estaticas_com_loop.imn Execute o Imunes. sudo imunes Carregue o arquivo de configuração: File >> Open >> /home/aluno/3_roteadores_tab_estaticas_com_loop.imn Inicie a simulação no Imunes: Experiment >> Execute Execute o Wireshark na interface eth1 de todos os roteadores e na interface eth0 do pc0. Gere um tráfego único a partir do pc0 para o pc2: ping -c1 10.0.2.20 Pare a captura em todos os Wiresharks. Qual mensagem de erro foi recebida no terminal do pc0? Analisando as capturas dos Wireshark responda: Aproximadamente em qual roteador o pacote foi descartado? Procure pelo menor valor de ttl. Qual o significado da linha com o seguinte conteúdo parcial: Time-to-live exceeded (Time to live exceeded in transit)? Explique qual o objetivo do campo ttl no cabeçalho IP? 6 AULA DIA 10/04/2021 6.1 Objetivos De forma geral esta aula VISA revisar o conceito de protocolos da camada de transporte. O aluno deverá ser capaz após esta aula: Compreender e saber explicar o papel dos protocolos de transporte em redes (de forma geral e na Arquitetura da Internet) e o seu papel como de formadores de canais lógicos entre aplicações; Identificar as principais funcionalidades e diferenças entre os protocolos de transporte UDP e TCP; Ter uma visão da estrutura dos pacotes UDP e TCP identificando-os com o wireshark. Usar o netcat para realizar testes de conexão/envio de dados em portas, usando o UDP e o TCP. 6.2 Slides Utilizados Udp Básico Tcp Básico MACxIP ATENÇÃO: Será proposto um questionário a ser postado no SIGAA desta aula. Fazer o questionário somente após ter elaborado o relatório do experimento abaixo. 6.3 Laboratório de Revisão UDP e TCP ATENÇÃO: Será solicitado um mini relatório deste laboratório. Pada cada etapa deve ser recortada a tela de interesse e uma explicação deverá ser realizada. 6.3.1 PARTE 1: Construir a rede abaixo e testar a conectividade entre todos os PCs usando o comando ping. 6.3.2 PARTE 2: Investigação do UDP Executar o netcat como servidor (usando UDP) no pc3. Ele deve esperar por dados na PORTA 5000. netcat -l -u -p 5000 Escutar os pacotes na interface do pc3 usando o wireshark. Clicar com o botão direito do mouse para acessar o wireshark. Realizar uma comunicação entre PC1 e PC3 usando o netcat como cliente no PC1. Ele deve usar a porta local 6000. netcat -u 10.0.3.21 -p 6000 5000 Identificar um pacote desta comunicação no sentido pc1->pc3. Indicar: o datagrama UDP capturado; as portas fonte e destino; o conteúdo de dados (payload). Identificar um pacote desta comunicação no sentido pc3->pc1. Indicar: o datagrama UDP capturado; as portas fonte e destino; o conteúdo de dados (payload). Elaborar um diagrama de troca de mensagens para esta comunicação. 6.3.3 PARTE 2: Investigação do TCP Executar o netcat como servidor (usando TCP) no pc3. Ele deve esperar por dados na PORTA 5000. netcat -l -t -p 5000 Escutar os pacotes na interface do pc3 usando o wireshark. Realizar uma comunicação entre PC1 e PC3 usando o netcat como cliente no PC1. Ele deve usar a porta local 6000. netcat -t 10.0.3.21 -p 6000 5000 Identificar um pacote desta comunicação no sentido pc1->pc3. Indicar: o segmento TCP capturado; as portas fonte e destino; Identificar um pacote desta comunicação no sentido pc3->pc1. Indicar: o segmento TCP capturado; as portas fonte e destino; Elaborar um diagrama de troca de mensagens para esta comunicação. Discutir a diferença observada entre a comunicação com o UDP (etapa 1) e com o TCP. 7 AULA DIA 14/04/2021 7.1 Objetivos Aspectos adicionais da camada IP. Protocolo ICMP Protocolo DHCP O NAT O Protocolo IPv6 Protocolos de Roteamento Dinâmico e Hierarquia na Internet 7.2 Revisão da Camada IP Slides Completos Camada IP Focar em: Slides 1 - Créditos dos Slides Slides 15 - Redes do Tipo Datagrama Slide: 19 - O roteador Slide: 3,30 - Posicionamento de Protocolos na camada IP Slide 31 - Endereçamento IP Slides: 44 a 46 - DHCP Slides: 47 e 48 - NAT Slide 35 - subredes Slide: 38 e 39 - Endereçamento Hierárquico Slides: 49 e 50 - ICMP

Semestre 2020-1 - Prof. Marcus Franco

8 Professor Professor: Marcus Franco Email: marcus.franco@ifsc.edu.br Atendimento paralelo: 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. O não cumprimento desse procedimento implica a impossibilidade de fazer a recuperação, e assim a reprovação na disciplina. 8.1 Plano de Ensino 9 Curiosidades Breve histórico sobre o surgimento das redes de computadores e a Internet Vídeo sobre surgimento da Internet Vídeo sobre o funcionamento das fibras ópticas Vídeo sobre fibra óptica Mapas de rede dorsais (Backbones) Mapa da rede Ipê (Internet acadêmica pública no Brasil) POP SC (ponto de presença de SC) Telex O Ciberespaço e as Redes de Computadores na Construção de Novo Conhecimento Uma história das Redes de Computadores Breve História da Internet Uma representação artística das interligações na Internet 10 Materiais de aula 10.1 Slides Arquivo:Slides-kurose-cap1.pdf 10.2 Listas de exercícios 10.3 Apostilas Apostila de Redes de Computadores do Prof. Evandro Cantú 11 Aulas 11.1 13/02/20: Recepção aos alunos Recepção: Apresentação da disciplina, plano de aula, laboratórios e métodos de avaliação. Introdução a Redes de Computadores [slides] 11.2 20/02/20: Introdução a Redes de Computadores Acesso a rede e meio físico Atraso e perdas em comutação de pacotes Lista de Exercicios (Lista 1) Link externo (Lista 1) 11.3 27/02/20: Introdução à Redes de Computadores Arquitetura em Camadas; Correção lista de exercício I 11.4 05/03/20: Introdução à Redes de Computadores Entrega da Lista 1 Nesta atividade serão vistos algumas ferramentas utilizadas para obter informações relacionadas às configurações de uma rede de computadores. Ferramentas básicas: Ping e Traceroute 11.4.1 Objetivos Familiarização com a infraestrutura dos laboratórios de redes Conhecer aplicativos para verificar os parâmetros do TCP/IP Diagnosticar o atraso dos pacotes Traçar rotas em redes TCP/IP 11.4.2 Conceitos introdutórios para uso do laboratório A rede do laboratório em uso segue o modelo apresentado no diagrama da Figura 1. Figura 1 - Diagrama da rede do laboratório 11.4.3 Roteiro de atividades 11.4.3.1 ifconfig O 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. Analisando os dados obtidos do seguinte exemplo /sbin/ifconfig eth0 Link encap:Ethernet Endereço de HW 64:51:06:1a:f3:da inet end.: 172.18.18.14 Bcast:172.18.63.255 Masc:255.255.192.0 endereço inet6: fe80::6651:6ff:fe1a:f3da/64 Escopo:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1 pacotes RX:415237 erros:0 descartados:0 excesso:0 quadro:0 Pacotes TX:118109 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:1000 RX bytes:364658695 (364.6 MB) TX bytes:18315199 (18.3 MB) IRQ:18 lo Link encap:Loopback Local inet end.: 127.0.0.1 Masc:255.0.0.0 endereço inet6: ::1/128 Escopo:Máquina UP LOOPBACK RUNNING MTU:65536 Métrica:1 pacotes RX:6688 erros:0 descartados:0 excesso:0 quadro:0 Pacotes TX:6688 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:0 RX bytes:1057934 (1.0 MB) TX bytes:1057934 (1.0 MB) </syntaxhighlight> O sistema em questão possui duas interfaces de rede: eth0 e lo Link encap:Ethernet: Configuração da interface Ethernet 0 (primeira) Endereço de HW 64:51:06:1a:f3:da: É o endereço da placa de rede, camada 2 inet end.: 172.18.18.14 Bcast:172.18.63.255 Masc:255.255.192.0: Endereço IPv4 associado a interface, seu respectivo endereço de broadcast e mascara de rede endereço inet6: fe80::6651:6ff:fe1a:f3da/64 Escopo:Link: Endereço IPv6 de escopo local gerado por autoconfiguração UP BROADCAST RUNNING MULTICAST: Significa que a interface está ativa (UP), responde a requisições de broadcast (pode ser desabilitado no kernel) e também pode ser associada a tráfegos multicast MTU: 1500: Maximum Transfer Unit – Tamanho máximo do pacote suportado pelo enlace que é do tipo Ethernet Os demais parâmetros são estatísticas da respectiva interface, como por exemplo, pacotes transmitidos, recebidos etc A interface lo: Qualquer tráfego que um computador envie em uma rede loopback é endereçada ao mesmo computador. O endereço IP mais usado para tal finalidade é 127.0.0.1 no IPv4 e ::1 no IPv6. O nome de domínio padrão para tal endereço é localhost. Em sistemas Unix, a interface loopback é geralmente chamada de lo ou lo0. Agora utilize o comando ifconfig para verificar o estado de suas interfaces e responda: Quantas e quais interfaces de rede sua máquina possui? Liste. Qual o significado/utilidade da interface lo? 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? Suas interfaces tem IPv6 configurado? Qual o endereço e escopo dos mesmos? Como foram obtidos? Qual o alcance (é roteável) do mesmo? 11.4.3.2 ping Aplicativo ping permite a um usuário verificar se um host remoto está ativo. É bastante utilizado para detectar problemas de comunicação na rede. O ping está baseado no envio de mensagens de solicitação de eco (echo request) e de resposta de eco (echo reply). Estas mensagens fazem parte do rol de mensagens do protocolo ICMP, que é um protocolo de reportagem de erros, a ser estudado mais tarde, componente do protocolo IP. O ping é um dos principais comandos a disposição do administrador de rede no sentido de verificar a conectividade em rede. Por exemplo, se houver resposta de um ping a partir de um servidor remoto, significa que a máquina local está rodando corretamente o TCP/IP, o enlace local está funcionando corretamente, o roteamento entre a origem e o destino está operando, e por fim, a máquina remota também está rodando corretamente o TCP/IP. Consultar as páginas man do ping para verificar as possibilidades de uso deste aplicativo. Exemplo 1: PING 200.135.37.65 (200.135.37.65) 56(84) bytes of data. 64 bytes from 200.135.37.65: icmp_seq=1 ttl=62 time=0.925 ms 64 bytes from 200.135.37.65: icmp_seq=2 ttl=62 time=0.743 ms 64 bytes from 200.135.37.65: icmp_seq=3 ttl=62 time=0.687 ms 64 bytes from 200.135.37.65: icmp_seq=4 ttl=62 time=0.689 ms ^C --- 200.135.37.65 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.687/0.761/0.925/0.097 ms </syntaxhighlight> No exemplo foram enviados quatro pacotes ICMP, cada um com um número de seqüência (icmp_seq), os quais foram recebidos com sucesso com o tempo de viagem assinalado (time) Cada pacote tem ainda um tempo de vida (ttl – time to live), o qual é decrementado em cada roteador, sendo o pacote descartado quando chegar a zero; isto evita pacotes perdidos na rede Quando o ping é interrompido (CRTL-C), uma estatística é apresentada indicando o percentual de pacotes transmitidos, recebidos e perdidos O tempo de viagem (rtt – round trip time) mínimo (min), médio (avg) e máximo (max) é calculado, assim como o desvio padrão (mdev) Como exercício envie ping para diferentes hosts e compare e anote os tempos de resposta: no endereço local de loopback; máquina de um colega do laboratório; servidor e roteador da rede da escola; servidores externos: www.ifsc.edu.br www.uol.com.br www.aaa.jp </syntaxhighlight> Explique as diferenças entre os tempos de resposta dos ping realizados: Entre ping para diferentes destinos. Entre respostas recebidas de um mesmo destino. Consulte as páginas man e teste o ping com os parâmetros abaixo e descreva suas funcionalidades: -c count -i intervalo -s packetsize -t ttl (para um site distante inicie com 1 e vá incrementando, observe as mensagens). Com essa estratégia é possível mapear os roteadores no caminho entre a origem e o destino de um pacote. 11.4.3.3 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 envia datagramas IP encapsulados em segmentos UDP a um host destino. Todavia escolhe um número de porta destino com um valor desconhecido (maior que 30000), tornando improvável que o host destino esteja usando esta porta. Quando o datagrama chega ao destino uma mensagem ICMP porta inalcançável é gerada e enviada a origem. O programa traceroute precisa saber diferenciar as mensagens ICMP recebidas – tempo excedido e porta inalcançável – para saber quando a rota foi concluída. Exemplo: sudo traceroute -I 200.135.37.65 traceroute to 200.135.37.65 (200.135.37.65), 30 hops max, 60 byte packets 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 3 hendrix.sj.ifsc.edu.br (200.135.37.65) 1.331 ms 1.313 ms 1.414 ms </syntaxhighlight> NOTA: O comando traceroute acima foi executado com o parâmetro -I. Esse comando força o traceroute a utilizar mensagens ICMP. Outra opção é utilizar o comando com o parâmetro -T, forçando o traceroute a utilizar o protocolo TCP para transmissão de seus pacotes. Caso nenhum dos parâmetros (-I ou -T) seja utilizado o traceroute utiliza o protocolo UDP como padrão. Visando barrar o tráfego de torrent na rede do Câmpus, o Firewall bloqueia as mensagens UDP da rede. Deste modo não é possível executar o comando traceroute na rede do Campus sem o uso dos parâmetro (-I ou -T). </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: máquina de um colega do laboratório servidor e roteador da rede da escola servidores americanos. Explique as diferenças entre os tempos de resposta: Entre traceroutes para diferentes destinos. No caso do traceroute para os EUA, aponte claramente qual foi o salto onde ocorreu a travessia do oceano. Como você chegou a essa conclusão? Entre as três medidas apresentadas para cada salto. O que justifica um possível tempo de resposta menor para um salto posterior? Por exemplo: pode-se obter no salto 13 um tempo de 289.207 ms e no salto 14 um tempo de 277.115 ms. Explique as linhas com o caracter *. 11.5 12/03/20: Revisão e Teste Revisão dos assuntos do cap. 1 Teste 11.6 26/03/20: Camada de aplicação (aula remota) Introdução a camada de aplicação Lista 2 de exercicios Slides Cap2 (Cap2) Lista (Lista 2)

Semestre 2019-2 - Prof. Tiago Semprebom

12 Professor Professor: Tiago Semprebom Email: tisemp@ifsc.edu.br Atendimento paralelo: 2a feira 17:30h - 18:30 h (Lab. Professores de TELE II) 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. O não cumprimento desse procedimento implica a impossibilidade de fazer a recuperação, e assim a reprovação na disciplina. 12.1 Plano de Ensino 13 Curiosidades Breve histórico sobre o surgimento das redes de computadores e a Internet Vídeo sobre surgimento da Internet Vídeo sobre o funcionamento das fibras ópticas Vídeo sobre fibra óptica Mapas de rede dorsais (Backbones) Mapa da rede Ipê (Internet acadêmica pública no Brasil) POP SC (ponto de presença de SC) Telex O Ciberespaço e as Redes de Computadores na Construção de Novo Conhecimento Uma história das Redes de Computadores Breve História da Internet Uma representação artística das interligações na Internet 14 Materiais de aula 14.1 Slides Arquivo:Slides-kurose-cap1.pdf Arquivo:Slides-kurose-cap2.pdf Arquivo:RCO-semprebom-cap3.pdf Arquivo:RCO-semprebom-cap4.pdf 14.2 Listas de exercícios Lista de exercícios 1 Lista de exercícios 2 Lista de exercícios 3 Lista de exercícios 4 Lista de exercícios 5 Lista de exercícios 6 Lista de exercícios 7 Lista de exercícios 8 Lista de exercícios 9 14.3 Apostilas Apostila de Redes de Computadores do Prof. Evandro Cantú 15 Aulas 15.1 29/07/19: Recepção aos alunos Recepção: Apresentação da disciplina, plano de aula, laboratórios e métodos de avaliação. Introdução a Redes de Computadores [slides] 15.2 05/08/19: Introdução à Redes de Computadores Serviço orientado à conexão (TCP). Serviço não orientado à conexão (UDP). Comutação de circuitos vs Comutação de pacotes. FDMA e TDMA. 15.3 12/08/19: Introdução à Redes de Computadores Redes de acesso e meio físico; Resolução de exercícios (Lista 1) 15.4 19/08/19: Introdução à Redes de Computadores Arquitetura em Camadas; Correção lista de exercício I 15.5 26/08/19: Introdução à Redes de Computadores Nesta atividade serão vistos algumas ferramentas utilizadas para obter informações relacionadas às configurações de uma rede de computadores. Ferramentas básicas: Ping e Traceroute 15.5.1 Objetivos Familiarização com a infraestrutura dos laboratórios de redes Conhecer aplicativos para verificar os parâmetros do TCP/IP Diagnosticar o atraso dos pacotes Traçar rotas em redes TCP/IP 15.5.2 Conceitos introdutórios para uso do laboratório A rede do laboratório em uso segue o modelo apresentado no diagrama da Figura 1. Figura 1 - Diagrama da rede do laboratório 15.5.3 Roteiro de atividades 15.5.3.1 ifconfig O 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. Analisando os dados obtidos do seguinte exemplo /sbin/ifconfig eth0 Link encap:Ethernet Endereço de HW 64:51:06:1a:f3:da inet end.: 172.18.18.14 Bcast:172.18.63.255 Masc:255.255.192.0 endereço inet6: fe80::6651:6ff:fe1a:f3da/64 Escopo:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1 pacotes RX:415237 erros:0 descartados:0 excesso:0 quadro:0 Pacotes TX:118109 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:1000 RX bytes:364658695 (364.6 MB) TX bytes:18315199 (18.3 MB) IRQ:18 lo Link encap:Loopback Local inet end.: 127.0.0.1 Masc:255.0.0.0 endereço inet6: ::1/128 Escopo:Máquina UP LOOPBACK RUNNING MTU:65536 Métrica:1 pacotes RX:6688 erros:0 descartados:0 excesso:0 quadro:0 Pacotes TX:6688 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:0 RX bytes:1057934 (1.0 MB) TX bytes:1057934 (1.0 MB) </syntaxhighlight> O sistema em questão possui duas interfaces de rede: eth0 e lo Link encap:Ethernet: Configuração da interface Ethernet 0 (primeira) Endereço de HW 64:51:06:1a:f3:da: É o endereço da placa de rede, camada 2 inet end.: 172.18.18.14 Bcast:172.18.63.255 Masc:255.255.192.0: Endereço IPv4 associado a interface, seu respectivo endereço de broadcast e mascara de rede endereço inet6: fe80::6651:6ff:fe1a:f3da/64 Escopo:Link: Endereço IPv6 de escopo local gerado por autoconfiguração UP BROADCAST RUNNING MULTICAST: Significa que a interface está ativa (UP), responde a requisições de broadcast (pode ser desabilitado no kernel) e também pode ser associada a tráfegos multicast MTU: 1500: Maximum Transfer Unit – Tamanho máximo do pacote suportado pelo enlace que é do tipo Ethernet Os demais parâmetros são estatísticas da respectiva interface, como por exemplo, pacotes transmitidos, recebidos etc A interface lo: Qualquer tráfego que um computador envie em uma rede loopback é endereçada ao mesmo computador. O endereço IP mais usado para tal finalidade é 127.0.0.1 no IPv4 e ::1 no IPv6. O nome de domínio padrão para tal endereço é localhost. Em sistemas Unix, a interface loopback é geralmente chamada de lo ou lo0. Agora utilize o comando ifconfig para verificar o estado de suas interfaces e responda: Quantas e quais interfaces de rede sua máquina possui? Liste. Qual o significado/utilidade da interface lo? 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? Suas interfaces tem IPv6 configurado? Qual o endereço e escopo dos mesmos? Como foram obtidos? Qual o alcance (é roteável) do mesmo? 15.5.3.2 ping Aplicativo ping permite a um usuário verificar se um host remoto está ativo. É bastante utilizado para detectar problemas de comunicação na rede. O ping está baseado no envio de mensagens de solicitação de eco (echo request) e de resposta de eco (echo reply). Estas mensagens fazem parte do rol de mensagens do protocolo ICMP, que é um protocolo de reportagem de erros, a ser estudado mais tarde, componente do protocolo IP. O ping é um dos principais comandos a disposição do administrador de rede no sentido de verificar a conectividade em rede. Por exemplo, se houver resposta de um ping a partir de um servidor remoto, significa que a máquina local está rodando corretamente o TCP/IP, o enlace local está funcionando corretamente, o roteamento entre a origem e o destino está operando, e por fim, a máquina remota também está rodando corretamente o TCP/IP. Consultar as páginas man do ping para verificar as possibilidades de uso deste aplicativo. Exemplo 1: PING 200.135.37.65 (200.135.37.65) 56(84) bytes of data. 64 bytes from 200.135.37.65: icmp_seq=1 ttl=62 time=0.925 ms 64 bytes from 200.135.37.65: icmp_seq=2 ttl=62 time=0.743 ms 64 bytes from 200.135.37.65: icmp_seq=3 ttl=62 time=0.687 ms 64 bytes from 200.135.37.65: icmp_seq=4 ttl=62 time=0.689 ms ^C --- 200.135.37.65 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.687/0.761/0.925/0.097 ms </syntaxhighlight> No exemplo foram enviados quatro pacotes ICMP, cada um com um número de seqüência (icmp_seq), os quais foram recebidos com sucesso com o tempo de viagem assinalado (time) Cada pacote tem ainda um tempo de vida (ttl – time to live), o qual é decrementado em cada roteador, sendo o pacote descartado quando chegar a zero; isto evita pacotes perdidos na rede Quando o ping é interrompido (CRTL-C), uma estatística é apresentada indicando o percentual de pacotes transmitidos, recebidos e perdidos O tempo de viagem (rtt – round trip time) mínimo (min), médio (avg) e máximo (max) é calculado, assim como o desvio padrão (mdev) Como exercício envie ping para diferentes hosts e compare e anote os tempos de resposta: no endereço local de loopback; máquina de um colega do laboratório; servidor e roteador da rede da escola; servidores externos: www.ifsc.edu.br www.uol.com.br www.aaa.jp </syntaxhighlight> Explique as diferenças entre os tempos de resposta dos ping realizados: Entre ping para diferentes destinos. Entre respostas recebidas de um mesmo destino. Consulte as páginas man e teste o ping com os parâmetros abaixo e descreva suas funcionalidades: -c count -i intervalo -s packetsize -t ttl (para um site distante inicie com 1 e vá incrementando, observe as mensagens). Com essa estratégia é possível mapear os roteadores no caminho entre a origem e o destino de um pacote. 15.5.3.3 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 envia datagramas IP encapsulados em segmentos UDP a um host destino. Todavia escolhe um número de porta destino com um valor desconhecido (maior que 30000), tornando improvável que o host destino esteja usando esta porta. Quando o datagrama chega ao destino uma mensagem ICMP porta inalcançável é gerada e enviada a origem. O programa traceroute precisa saber diferenciar as mensagens ICMP recebidas – tempo excedido e porta inalcançável – para saber quando a rota foi concluída. Exemplo: sudo traceroute -I 200.135.37.65 traceroute to 200.135.37.65 (200.135.37.65), 30 hops max, 60 byte packets 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 3 hendrix.sj.ifsc.edu.br (200.135.37.65) 1.331 ms 1.313 ms 1.414 ms </syntaxhighlight> NOTA: O comando traceroute acima foi executado com o parâmetro -I. Esse comando força o traceroute a utilizar mensagens ICMP. Outra opção é utilizar o comando com o parâmetro -T, forçando o traceroute a utilizar o protocolo TCP para transmissão de seus pacotes. Caso nenhum dos parâmetros (-I ou -T) seja utilizado o traceroute utiliza o protocolo UDP como padrão. Visando barrar o tráfego de torrent na rede do Câmpus, o Firewall bloqueia as mensagens UDP da rede. Deste modo não é possível executar o comando traceroute na rede do Campus sem o uso dos parâmetro (-I ou -T). </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: máquina de um colega do laboratório servidor e roteador da rede da escola servidores americanos. Explique as diferenças entre os tempos de resposta: Entre traceroutes para diferentes destinos. No caso do traceroute para os EUA, aponte claramente qual foi o salto onde ocorreu a travessia do oceano. Como você chegou a essa conclusão? Entre as três medidas apresentadas para cada salto. O que justifica um possível tempo de resposta menor para um salto posterior? Por exemplo: pode-se obter no salto 13 um tempo de 289.207 ms e no salto 14 um tempo de 277.115 ms. Explique as linhas com o caracter *. 15.6 02/09/19: Camada de Aplicação A camada de aplicação (ver estes [slides) Lista de Exercício: II 15.7 09/09/19: Camada de Aplicação A camada de aplicação (ver estes [slides) Lista de Exercício: II 15.8 16/09/19: Camada de Aplicação DNS: Domain Name System 15.8.1 DNS: Domain Name System Se você gasta algum tempo na internet mandando e-mails ou navegando pela web, está utilizando servidores de domínios sem mesmo perceber. O sistema DNS (Domain Name System) forma uma das maiores, mais ativas e mais distribuídas bases de dados do planeta. Sem o DNS, a internet acabaria rapidamente. Quando você navega na internet ou manda uma mensagem de e-mail, você estará utilizando um nome de domínio. Por exemplo, a URL "http://www.hsw.com.br" contém o nome de domínio howstuffworks.com. Assim como o endereço de e-mail "iknow@howstuffworks.com." Nomes como “howstuffworks.com” são facilmente lembrados pelas pessoas, mas não ajudam em nada as máquinas. Todas elas usam endereços de IP para se referirem umas às outras. A máquina a que as pessoas se referem como "www.hsw.com.br", por exemplo, possui o endereço IP 216.183.103.150. Toda vez que se usa um nome de domínio, os servidores de domínios da internet (DNS) estarão traduzindo os nomes de domínio legíveis em endereços de IP reconhecidos pelas máquinas. Durante um dia de navegação e envio de e-mails, os servidores de domínios podem ser acessados inúmeras vezes. Os servidores de domínios traduzem nomes de domínios em endereços de IP. Isto parece uma tarefa simples, e seria, exceto por cinco razões: Atualmente existem bilhões de endereços de IP em uso e a grande maioria das máquinas possui um nome legível associado. Alguns bilhões de requisições são feitas ao DNS todos os dias. Uma única pessoa pode fazer várias requisições em apenas um dia e existem muitas pessoas e máquinas usando a Internet diariamente. Nomes de domínio e endereços de IP podem mudar frequentemente (até mesmo diariamente). Novos nomes de domínio são criados todos os dias. Milhões de pessoas trabalham na mudança e no acréscimo de nomes de domínio e endereços de IP constantemente. O sistema DNS é uma base de dados, e nenhuma outra em todo o globo recebe tantas requisições. É a única, também, modificada por milhões de pessoas todos os dias. Isso é o que faz o sistema DNS tão singular. 15.8.1.1 Endereços IP Para manter todas as máquinas da Internet em perfeito funcionamento, cada uma delas é associada a um único endereço chamado endereço de IP. IP significa protocolo da Internet, e é um número de 32 bits normalmente apresentado como quatro “octetos” em um “número decimal pontuado.” Um endereço de IP comum se parece com esse: 216.183.103.150 Os quatro números em um endereço de IP são chamados de octetos por possuírem valores entre 0 e 255 (256 possibilidades por octeto). Toda máquina na Internet possui seu próprio endereço de IP (na verdade, tem ao menos UM endereço). Um servidor tem um endereço IP estático, que raramente muda. Uma máquina doméstica, que se conecta através de um modem, muitas vezes possui um endereço de IP designado pelo provedor no momento da conexão. Este endereço IP é único a cada sessão e pode mudar na próxima vez que houver uma conexão. Considerando isto, um provedor precisa apenas de um endereço IP para cada modem que dá suporte, ao invés de um para cada cliente (isso vale para ADSL ou conexões 3G também). Se você estiver usando um computador com sistema operacional Linux, você pode ver seu endereço IP por meio do seguinte comando: aluno@M2:~$ ifconfig eth0 Link encap:Ethernet Endereço de HW 84:2b:2b:7c:54:f5 inet end.: 172.18.80.251 Bcast:172.18.127.255 Masc:255.255.128.0 endereço inet6: fe80::862b:2bff:fe7c:54f5/64 Escopo:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1 pacotes RX:3634552 erros:0 descartados:145885 excesso:0 quadro:0 Pacotes TX:608253 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:1000 RX bytes:888269786 (888.2 MB) TX bytes:195176030 (195.1 MB) IRQ:21 Memória:f7fe0000-f8000000 No exemplo acima, a interface de rede eth0 (que é o dispositivo de hardware ou software que liga o computador fisicamente a Internet) possui o endereço IP 172.18.80.251. As demais informações descrevem outros parâmetros e características da interface de rede, e serão estudados em momento oportuno (mas não agora ;-). Para que as máquinas acessem a Internet, é necessário apenas um endereço de IP para se conectar a um servidor. Você poderia digitar em seu navegador, por exemplo, a URL http://200.135.190.95 e alcançaria a máquina que contém o servidor web do IFSC. Porém essa forma de endereçar servidores na Internet é pouco prática. Nomes de domínio são estritamente usados para a nossa conveniência. 15.8.1.2 Nomes de domínios Se precisássemos lembrar de todos os endereços de IP das páginas da Web que visitamos diariamente, ficaríamos malucos. Seres humanos não são bons em lembrar séries de números. No entanto, somos bons na lembrança de palavras, por isso usamos os nomes de domínios. Você possui, provavelmente, vários nomes de domínios guardados em sua cabeça. Como por exemplo: www.hsw.com.br - um nome típico www.google.com - o nome mais conhecido no mundo www.mit.edu - um nome EDU (educacionais) bastante popular encarta.msn.com - um servidor da Web que não começa com www www.bbc.co.uk - um nome que utiliza quatro partes em vez de três ftp.microsoft.com - um servidor FTP (em inglês) ao invés de um servidor da Web As partes COM, EDU e UK destes servidores são chamadas de domínios principais ou domínios de primeiro nível. Existem vários domínios principais, incluindo COM, EDU, GOV, MIL, NET, ORG e INT, assim como as singulares combinações de duas letras para cada país (em inglês). Em cada domínio principal existe uma enorme lista de domínios secundários. No domínio principal COM, por exemplo, tem-se: howstuffworks google msn microsoft ... e milhões de outros. Cada nome no domínio principal COM precisa ser único, mas podem existir réplicas entre os domínios. Por exemplo, howstuffworks.com e howstuffworks.org são duas máquinas completamente diferentes. No caso de bbc.co.uk, este é um domínio terciário. São possíveis até 127 níveis, no entanto, mais do que quatro são raros. A palavra mais à esquerda, como www ou encarta, é nome de hospedagem, que determina o nome de uma máquina específica (com um endereço de IP próprio) em um domínio. Um domínio concedido pode conter milhões de nomes de hospedagem desde que sejam únicos. Por causa desta determinação de todos os nomes em um domínio serem únicos, é necessário que uma entidade controle a lista destes servidores e garanta que nenhuma duplicação aconteça. O domínio COM, por exemplo, não pode conter dois nomes iguais e uma empresa chamada Network Solutions (em inglês) é a responsável por manter esta lista. Ao registrar um nome de domínio, o processo passa por um dos inúmeros registradores que trabalham na Network Solutions para adicionar nomes à lista. Ao mesmo tempo, é mantida uma base de dados chamada whois (em inglês) que contém informações sobre o proprietário e o servidor de cada domínio. Se você acessar o formulário whois (em inglês), encontrará informações acerca de qualquer domínio existente. Apesar de ser importante possuir uma autoridade central cuidando da base de dados referente aos nomes no domínio principal COM (e nos outros), você pode não querer centralizar a base de dados de todas as informações do domínio. A Microsoft, por exemplo, tem inúmeros endereços de IP e de nomes de hospedagens. Esta empresa quer manter seu próprio servidor de domínio pelo microsoft.com. Similarmente, a Grã-Bretanha quer administrar os domínios principais uk e a Austrália os domínios au, assim como nós brasileiros queremos administrar os domínios br. Por esta razão, o sistema DNS é um sistema partilhado. A Microsoft é completamente responsável pela manutenção do servidor microsoft.com: ela mantém as máquinas que implementam sua parte do sistema DNS, podendo mudar a base de dados de seu domínio sempre que necessitar, pois possui seus próprios servidores de domínio. Todo domínio possui um servidor em algum lugar, responsável por lidar com as requisições, onde há uma pessoa mantendo os registros deste DNS. Esta é uma das partes mais extraordinárias deste sistema: ele está completamente espalhado por todo o planeta em milhões de máquinas, administradas por milhões de pessoas e, ainda assim, se comporta como uma base de dados única e integrada. 15.8.1.3 Servidores DNS Servidores DNS fazem duas coisas o tempo todo: Aceitam solicitações de programas para converter nomes de domínios em endereços de IP. Aceitam solicitações de outros servidores para converter nomes de domínios em endereços de IP. Quando uma solicitação chega, o servidor pode exercer uma das quatro opções: Pode responder diretamente com um endereço de IP, por já conhecer previamente este endereço do domínio. Pode contatar outros servidores e tentar encontrar o endereço de IP para que foi solicitado, um processo que pode ser repetido várias vezes. Pode dizer: “eu não sei o endereço de IP para o domínio solicitado, mas aqui está o endereço de IP de um servidor que sabe mais do que eu.” Pode retornar uma mensagem de erro, pois o domínio solicitado é inválido ou inexistente. Ao digitar uma URL em seu navegador, o primeiro passo que este faz é converter o nome do domínio e da hospedagem em um endereço IP, para que o navegador solicite uma página da web à máquina que possui esse endereço de IP. Para fazer esta conversão, o navegador se comunica com um servidor DNS. Ao configurar seu computador para se conectar a Internet, você (ou o software instalado para se conectar ao seu provedor) precisa informar ao computador qual o servidor DNS que deve ser usado para a conversão de nomes de domínios em endereços de IP. Para ver qual o servidor DNS configurado em seu computador (assumindo que ele esteja com Linux), use o comando nslookup: aluno@M2:~$ nslookup www.ifsc.edu.br Server: 200.135.37.65 Address: 200.135.37.65#53 Non-authoritative answer: Name: www.ifsc.edu.br Address: 200.18.10.13 15.8.1.4 A estrutura das informações mantidas no DNS Como deve ter ficado claro na seção anterior, 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 (na seção anterior isso foi denominado hospedagem). 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 br é o domínio do topo da hierarquia ao qual mail.sj.ifsc.edu.br pertence. Já edu é um subdomíno de br, ifsc um subdomínio de edu, 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. Clientes buscam informação no DNS usando uma biblioteca de resolução (resolver library), que envia as consultas para um ou mais servidores de nomes e interpreta as respostas. (tirado do manual do BIND9) Ver também o livro sobre DNS e BIND da O'Reilly. Você pode consultar a IANA para conhecer as delegações dos top-level domains como o .br, por exemplo. A IANA é responsável por coordenar estas delegações em confirmidade com suas políticas. Consulte: top-level domains 15.8.1.5 Registros DNS Cada rótulo na hierarquia DNS possui um conjunto de informações associadas a si. Essas informações são guardas em registros de diferentes tipos, dependendo de seu significado e propósito. Cada consulta ao DNS retorna assim as informações do registro pedido associado ao rótulo. Por exemplo, para ver o registro de endereço IP associado a www.ifsc.edu.br pode-se executar o comando dig (o resultado teve alguns comentários removidos): tisemp@sj-lin-des2-744934:~$ dig www.ifsc.edu.br ;; QUESTION SECTION: ;www.ifsc.edu.br. IN A ;; ANSWER SECTION: www.ifsc.edu.br. 310 IN A 200.135.190.95 ;; AUTHORITY SECTION: ifsc.edu.br. 3592 IN NS adns1.pop-sc.rnp.br. ifsc.edu.br. 3592 IN NS ns1.ifsc.edu.br. ifsc.edu.br. 3592 IN NS ns2.ifsc.edu.br. ifsc.edu.br. 3592 IN NS adns2.pop-sc.rnp.br. ;; ADDITIONAL SECTION: ns1.ifsc.edu.br. 3592 IN A 200.135.190.1 ns2.ifsc.edu.br. 1061 IN A 200.135.190.3 adns1.pop-sc.rnp.br. 493216 IN A 200.237.192.10 adns1.pop-sc.rnp.br. 493216 IN AAAA 2801:80:a88:4000::10 adns2.pop-sc.rnp.br. 493216 IN A 200.135.14.10 adns2.pop-sc.rnp.br. 493216 IN AAAA 2001:12f0:200:a014::10 Cada uma das informações acima mostra um determinado registro e seu conteúdo, como descrito na tabela abaixo: Nome TTL Classe Registro Conteúdo do registro hendrix.sj.ifsc.edu.br. 3600 IN A 200.135.37.65 sj.ifsc.edu.br. 3600 IN NS hendrix.sj.ifsc.edu.br. sj.ifsc.edu.br. 3600 IN MX 10 hendrix.sj.ifsc.edu.br. Obs: TTL é o tempo de validade (em segundos) da informação retornada do servidor de nomes, e classe é o tipo de endereço (no caso IN equivale a endereços Internet). Os tipos de registros mais comuns são: Registro Descrição Exemplo A Endereço (Address) www.ifsc.edu.br IN A 200.135.190.95 NS Servidor de nomes (Name Server) sj.ifsc.edu.br IN NS hendrix.sj.ifsc.edu.br. CNAME Apelido (Canonical Name) mail.sj.ifsc.edu.br IN CNAME hendrix.sj.ifsc.edu.br. MX Roteador de email (Mail Exchanger) sj.ifsc.edu.br IN MX mail.sj.ifsc.edu.br. SOA dados sobre o domínio (Start of Authority) sj.ifsc.edu.br IN SOA hendrix.sj.ifsc.edu.br. root.sj.ifsc.edu.br. 2009120102 1200 120 604800 3600 PTR Ponteiro para nome (Pointer) 65.37.135.200.in-addr.arpa IN PTR hendrix.sj.ifsc.edu.br. TXT Texto genérico (Text) sj.ifsc.edu.br IN TXT "v=spf1 a mx ~all" Uma zona assim é composta de um conjunto de registros com todas as informações dos domínios nela contidos. O conteúdo de uma zona, contendo o domínio example.com, pode ser visualizado abaixo: example.com 86400 IN SOA ns1.example.com. hostmaster.example.com. ( 2002022401 ; serial 10800 ; refresh 15 ; retry 604800 ; expire 10800 ; minimum ) IN NS ns1.example.com. IN NS ns2.smokeyjoe.com. IN MX 10 mail.another.com. IN TXT "v=spf1 mx -all" ns1 IN A 192.168.0.1 www IN A 192.168.0.2 ftp IN CNAME www.example.com. bill IN A 192.168.0.3 fred IN A 192.168.0.4 15.8.2 Atividade Usando o programa host ou dig, descubra os endereços IP associados aos seguintes nomes de domínios: mail.ifsc.edu.br www.sj.ifsc.edu.br www.google.com www.gmail.com www.amazon.co.uk www.gov.za www.sls.com.au Agora descubra quem é o servidor DNS responsável por cada um dos domínios dos nomes acima. Para isso consulte o valor do registro NS associado a esses domínios. Por exemplo, com o programa host isso pode ser feito assim: host -t ns ifsc.edu.br Descubra qual o servidor DNS usado pelo seu computador. Para isso é mais fácil usar o programa nslookup: # Use o nslookup para consultar o endereço IP de um nome qualquer ... nslookup sj.ifsc.edu.br 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. Portanto, execute o wireshark: sudo wireshark ... e em seguida faça uma consulta DNS qualquer. Com base nisso identifique o seguinte: Quantas mensagens são trocadas entre cliente e servidor DNS para cada consulta ? Que protocolo de transporte é usado ? E que port ? Qual o formato das mensagens DNS ? Elas são textuais como as mensagens HTTP ou SMTP ? Qual o tipo de registro DNS acessado em cada consulta ? Que informações estão contidas nas respostas DNS ? Há algo além do que foi pedido ? Qual o tamanho das mensagens DNS ? O serviço DNS fornece outras informações além do endereço IP associado a cada nome de domínio. Por exemplo, como ele se pode descobrir que host recebe emails em um determinado domínio. Isso é utilizado pelos MTA mundo afora para entregarem emails para seus destinatários (lembre que isso se faz com o protocolo SMTP). Para descobrir essa informação, deve-se consultar o registro MX de um domínio. Por exemplo: host -t mx ifsc.edu.br Descubra quem é o servidor que recebe emails nos seguintes domínios: gmail.com hotmail.com uol.com.br ufsc.br Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim: dig -x 200.135.190.95 ... 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. Como explicado durante a aula, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões ?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado ? Descubra quem são os servidores raiz (topo de hierarquia DNS): host -t ns . Escolha um dos servidores listados, e use-o para fazer as consultas. Por exemplo: host -v -t a www.sj.ifsc.edu.br. j.root-servers.net. ... e observe a seção ;; AUTHORITY SECTION:. Ele contém a listagem de servidores DNS que podem atender sua consulta. Continue fazendo as consultas aos servidores DNS listados, até conseguir traduzir o nome requisitado. Quantos servidores DNS foi necessário consultar no total ? Repita esse exercício para os seguintes nomes de domínio: www.bbc.co.uk www.amazon.com www.reeec.illinois.edu www.inm.ras.ru 15.9 23/09/19: AVALIAÇÃO 1 15.10 30/09/19: Camada de Transporte Sem atividades 15.11 07/10/19: Camada de Transporte KUROSE, J.F & ROSS, K. W. Todos os direitos reservados 15.11.1 Objetivos Conhecer aplicativos para verificar os parâmetros do TCP/IP Familiarização com os sniffers de rede WireShark e tcpdump. 15.11.2 Materiais de apoio Roteiro TCPDump Wireshark e manuais Ferramentas básicas: WireShark e tcpdump 15.11.3 Introdução O entendimento de protocolos de redes pode ser bastante aprofundado através da “observação de protocolos funcionando” e “da manipulação de protocolos” - observando a sequência de mensagens trocadas entre duas entidades, entrando nos detalhes da operação do protocolo, e fazendo com que os protocolos realizem certas ações e então observando estas ações e as consequências. A ferramenta básica para observar as mensagens trocadas entre as entidades em execução é chamada de sniffer. Como o nome sugere, um sniffer captura mensagens sendo enviadas/recebidas pelo seu computador; ele também tipicamente armazena e/ou apresenta os conteúdos dos vários campos dos protocolos nestas mensagens capturadas. Um sniffer isoladamente é um elemento passivo. Ele observa as mensagens sendo enviadas e recebidas pelas aplicações e protocolos executando no seu computador, mas jamais envia pacotes. Similarmente, os pacotes recebidos nunca são explicitamente endereçados ao sniffer. Ao invés disso, um sniffer recebe uma cópia de pacotes que são enviados/recebidos para/de aplicações e protocolos executando no seu computador. A Figura 1 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. Figura 1 - 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 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. Analisando os campos da interface do Wireshark Quando você executar o programa Wireshark, a interface com o usuário exibida na Figura 3 aparecerá. Inicialmente, nenhum dado será apresentado nas janelas. A interface do Wireshark tem seis componentes principais: Os menus de comandos são localizados no topo da janela. Por enquanto, interessam apenas os menus File e Capture. O menu File permite salvar dados de capturas de pacotes ou abrir um arquivo contendo dados de capturas de pacotes previamente realizadas, e sair da aplicação. O menu Capture permite iniciar uma captura de pacotes; A barra de ferramentas contém os comandos de menu que são mais frequentemente utilizados. Há atalhos para abrir ou salvar dados de captura de pacotes e para iniciar ou parar uma captura de pacotes; Abaixo da barra de ferramentas, está o campo de filtragem de pacotes exibidos. Nele podem ser digitados nome de protocolo ou outra informação apresentada na janela de listagem de pacotes. Apenas os pacotes que correspondem ao filtro são exibidos; A janela de listagem de pacotes apresenta um resumo de uma linha para cada pacote capturado, incluindo o número do pacote (atribuído pelo Wireshark; este não é o número do pacote contido no cabeçalho de qualquer protocolo), o tempo que o pacote foi capturado, os endereços fonte e destino do pacote, o tipo de protocolo, e informação específica do protocolo contida no pacote. A lista de pacotes pode ser ordenada conforme qualquer uma destas categorias clicando no nome de uma coluna correspondente. O campo tipo do protocolo lista o protocolo de mais alto nível que enviou ou recebeu este pacote, i.e., o protocolo que é a fonte ou o último sorvedouro para este pacote; A janela de detalhes de cabeçalho de pacotes fornece detalhes sobre o pacote selecionado na janela de listagem de pacotes. Para selecionar um pacote, basta clicar sobre ele com o botão esquerdo do mouse na janela de listagem de pacotes. Os detalhes apresentados incluem informações sobre o quadro Ethernet e o datagrama IP que contém o pacote. A quantidade de detalhes exibida pode ser expandida ou contraída. Se o pacote foi carregado sobre TCP ou UDP, detalhes correspondentes também são apresentados, os quais também podem ser contraídos ou expandidos. Finalmente, detalhes sobre o protocolo de mais alto nível que enviou ou recebeu este pacote também são apresentados; A janela de conteúdo de pacotes mostra o conteúdo inteiro do quadro capturado, nos formatos ASCII e hexadecimal. Figura 3 - Interface com o usuário do Wireshark 15.11.4 Roteiro de atividades Inicie o navegador web; Inicie o Wireshark. Inicialmente as janelas estarão vazias, pois não há captura de pacotes em progresso; Para iniciar uma captura de pacotes, selecione o menu Capture e depois Interfaces. Isso faz com que a janela de interfaces de rede disponíveis seja apresentada (Figura 4); Figura 4 - Interfaces de rede no Wireshark Basta clicar no botão Start da interface desejada para iniciar a captura de pacotes. Na Figura 4, como o Wireshark está sendo executado no Linux, o botão Start da interface eth0 deve ser selecionado; Como nada está acontecendo na rede, a janela apresenta o conteúdo vazio; No navegador, acesse o site http://www.ifsc.edu.br; Ao voltar para a janela do Wireshark, houve a captura de todos os pacotes envolvidos na conexão; Antes de continuar, vamos parar a captura de pacotes e trabalhar com o que temos. Basta clicar em Capture e depois em Stop; Para testar as capacidades de filtragem, vamos inserir a cadeia “http” (sem as aspas e em minúsculo) no especificação do filtro de exibição e depois selecionar Apply (ou Aplicar). Um resultado similar é exibido na figura 5; Figura 5 - Janela após a aplicação do filtro http Selecione a primeira mensagem HTTP exibida na janela de listagem de pacotes. Ela deve ser a mensagem HTTP GET que foi enviada do seu computador ao servidor HTTP em www.ifsc.edu.br. Quando você seleciona a mensagem HTTP GET, as informações dos cabeçalhos do quadro Ethernet, do datagrama IP, do segmento TCP e da mensagem HTTP aparecem na janela de cabeçalhos de pacotes. É possível ver os detalhes, expandido ou comprimindo os itens com um clique na seta ao lado deles. Se desejar acesse novos sítios e faça novas capturas e tente entender o que ocorre; Com Wireshark ativo (Abra-o novamente se necessário) acesse um sítio de sua preferência e responda às seguintes questões: Teste outros filtros, por exemplo, mostre somente pacotes originados e/ou destinados a um determinado host (ip.addr == 191.36.13.X). Anote o filtro utilizado e salve a janela do mesmo. Exemplo de filtros. 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. 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? 15.11.5 Tcpdump Leia atentamente o manual do tcpdump , principalmente os exemplos: man tcpdump </syntaxhighlight> Faça um ping e navegue para algum site de sua preferência e, com o uso de parâmetros apropriados, faça com que o tcpdump armazene os em um arquivo denominado “pacotes_capturadosX.pcap“ (um arquivo para cada item X): Capture todos os pacotes oriundos e destinados à sua máquina. Idem anterior com a flag -vvv ativa e, em seguida, a flag -n. Qual é a função dessas flags? Capture somente os pacotes oriundos de sua máquina. Anote o comando utilizado. Capture somente pacotes destinados à sua máquina. Anote o comando utilizado. Capture pacotes HTTP e DNS (lembre-se da porta de cada serviço). Anote o comando utilizado. Procure um dos arquivos salvos, com o navegador de arquivos de sua máquina, dê um duplo clique sobre o mesmo. Com qual programa foi aberto o arquivo? Exemplifique um possível uso dessa compatibilidade de arquivos? 15.12 14/10/19: Camada de Transporte Camada de Transporte; Resolução de Exercícios. 15.13 21/10/19: Camada de Transporte As atividades de hoje buscarão mostrar as características básicas de comunicações com protocolos de transporte. Experimento TCP x UDP 15.13.1 Aplicações e protocolos de transporte Faça uma rápida pesquisa e descubra que protocolos de transporte (e que ports) são usados por estas aplicações: SSH FTP BitTorrent emule WINS Compartilhamento de arquivos do Windows Windows Terminal Service NFS Openvpn RADIUS DHCP SNMP NTP LDAP Mysql Postgresql Oracle RDBMS Syslog CUPS Que protocolo de transporte predomina nesse conjunto ? 15.13.2 Tipos de protocolos de transporte: TCP x UDP Nestes experimentos, serão evidenciadas diferenças entre os protocolos TCP e UDP. 15.13.2.1 Experimento 1 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 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 ? Abra um terminal e execute o seguinte comando para fazer o download de um arquivo a ser usado no experimento: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso Observe o tamanho do arquivo transferido ... ele deve ter exatamente 832569344 bytes (cerca de 832 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. A primeira transferência será feita usando o protocolo TCP da seguinte forma: No computador receptor execute: nc -l 5555 > arquivo No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): time nc 192.168.1.X 5555 < ubuntu.iso 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: No computador receptor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x receptor). No computador receptor execute: ./receptor 5555 > arquivo No computador transmissor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x transmissor). No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): ./transmissor 192.168.1.X 5555 < ubuntu.iso Quando completar a transferência, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original ? E quanto tempo levou para transmiti-lo ? Compare as transferências feitas com TCP e UDP. O que eles têm em comum ? Que diferenças lhe pareceram mais pronunciadas ? Como isso deve afetar as aplicações que usam esses protocolos ? 15.13.2.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, como mostrado na figura abaixo: Abra um terminal em seu computador, e nele execute este comando: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso 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á se logar em um dos computadores do laboratório e 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 ? Finalmente, o professor irá repetir a transferência porém com mais dois 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: Abra dois terminais. Em um deles execute este comando: watch -n 1 ls -l arquivo ... e no outro execute: ./receptor 5555 > arquivo Como se comparam as transferências usando TCP e UDP? 15.14 28/10/19: Dia do Servidor Público Feriado 15.15 04/11/19: AVALIAÇÃO 2 15.16 11/11/19: Camada de Rede 15.17 18/11/19: Camada de Rede 15.18 25/11/19: Camada de Rede 15.19 02/12/19: Camada de Rede 15.20 09/12/19: AVALIAÇÃO 3 15.21 16/12/19: RECUPERAÇÕES FINAIS

Semestre 2019-1 - Prof. Tiago Semprebom

16 Professor Professor: Tiago Semprebom Email: tisemp@ifsc.edu.br Atendimento paralelo: 3a feira 17:30h - 18:30 h (sala de professores de telecomunicações II) Endereço web do grupo: http://groups.google.com/group/ifsc_res Endereço de e-mail da disciplina: ifsc_res@googlegroups.com 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. O não cumprimento desse procedimento implica a impossibilidade de fazer a recuperação, e assim a reprovação na disciplina. 16.1 Plano de Ensino 17 Notas Matrícula A1 A2 A3 A4 Rel. Tec. Final 201823806749 0,0 0,0 0,0 0,0 OK 0,0 201811103467 0,0 0,0 0,0 0,0 OK 0,0 172001603800 0,0 0,0 0,0 0,0 NOK 0,0 201811103475 0,0 0,0 0,0 0,0 OK 0,0 201811101502 0,0 0,0 0,0 0,0 OK 0,0 F: faltou (X): conceito da recuperação negrito: com direito a recuperação 18 Curiosidades Monitoramento do tráfego RNP - PoP-SC Monitoramento do tráfego RNP - Nacional Rede Clara Internacional Futura infraestrutura de rede da RNP Animated map shows the undersea cables that power the internet Submarine Cable Map 2018 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 Localização geográfica de IPs IPv6 no Brasil Fragmentação no IPv4 e IPv6 Laboratório de IPv6 - Livro didático contendo vários roteiros para entendimento do IPv6 Estatísticas Google sobre IPv6 HTTP/2 Frequently Asked Questions Iniciação à máquinas de estados Uma representação artística das interligações na Internet 19 Materiais de aula 19.1 Slides Capítulo 1 Capítulo 2 Capítulo 3 Capítulo 4 19.2 Listas de exercícios Lista de exercícios 1 Lista de exercícios 2 Lista de exercícios 3 Lista de exercícios 4 Lista de exercícios 5 Lista de exercícios 6 Lista de exercícios 7 Lista de exercícios 8 Lista de exercícios 9 19.3 Apostilas Apostila de Redes de Computadores do Prof. Evandro Cantú 20 Aulas 20.1 11/02/19: Apresentação da disciplina Apresentação da disciplina, plano de aula, laboratórios e métodos de avaliação. Revisão de conceitos do Projeto Integrador I Introdução a Redes de Computadores [slides] 20.2 18/02/19: Introdução às Redes de Computadores Serviço orientado à conexão (TCP). Serviço não orientado à conexão (UDP). Comutação de circuitos vs Comutação de pacotes. FDMA e TDMA. 20.3 25/02/19: Introdução à Redes de Computadores Redes de acesso e meio físico; Resolução de exercícios (Lista 1). 20.4 04/03/19: Feriado: Carnaval sem atividade letivas. 20.5 11/03/19: Introdução à Redes de Computadores Arquitetura em Camadas; Correção lista de exercício I Nesta atividade serão vistos algumas ferramentas utilizadas para obter informações relacionadas às configurações de uma rede de computadores. Ferramentas básicas: Ping e Traceroute 20.5.1 Objetivos Familiarização com a infraestrutura dos laboratórios de redes Conhecer aplicativos para verificar os parâmetros do TCP/IP Diagnosticar o atraso dos pacotes Traçar rotas em redes TCP/IP 20.5.2 Conceitos introdutórios para uso do laboratório A rede do laboratório em uso segue o modelo apresentado no diagrama da Figura 1. Figura 1 - Diagrama da rede do laboratório 20.5.3 Roteiro de atividades 20.5.3.1 ifconfig O 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. Analisando os dados obtidos do seguinte exemplo /sbin/ifconfig eth0 Link encap:Ethernet Endereço de HW 64:51:06:1a:f3:da inet end.: 172.18.18.14 Bcast:172.18.63.255 Masc:255.255.192.0 endereço inet6: fe80::6651:6ff:fe1a:f3da/64 Escopo:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1 pacotes RX:415237 erros:0 descartados:0 excesso:0 quadro:0 Pacotes TX:118109 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:1000 RX bytes:364658695 (364.6 MB) TX bytes:18315199 (18.3 MB) IRQ:18 lo Link encap:Loopback Local inet end.: 127.0.0.1 Masc:255.0.0.0 endereço inet6: ::1/128 Escopo:Máquina UP LOOPBACK RUNNING MTU:65536 Métrica:1 pacotes RX:6688 erros:0 descartados:0 excesso:0 quadro:0 Pacotes TX:6688 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:0 RX bytes:1057934 (1.0 MB) TX bytes:1057934 (1.0 MB) </syntaxhighlight> O sistema em questão possui duas interfaces de rede: eth0 e lo Link encap:Ethernet: Configuração da interface Ethernet 0 (primeira) Endereço de HW 64:51:06:1a:f3:da: É o endereço da placa de rede, camada 2 inet end.: 172.18.18.14 Bcast:172.18.63.255 Masc:255.255.192.0: Endereço IPv4 associado a interface, seu respectivo endereço de broadcast e mascara de rede endereço inet6: fe80::6651:6ff:fe1a:f3da/64 Escopo:Link: Endereço IPv6 de escopo local gerado por autoconfiguração UP BROADCAST RUNNING MULTICAST: Significa que a interface está ativa (UP), responde a requisições de broadcast (pode ser desabilitado no kernel) e também pode ser associada a tráfegos multicast MTU: 1500: Maximum Transfer Unit – Tamanho máximo do pacote suportado pelo enlace que é do tipo Ethernet Os demais parâmetros são estatísticas da respectiva interface, como por exemplo, pacotes transmitidos, recebidos etc A interface lo: Qualquer tráfego que um computador envie em uma rede loopback é endereçada ao mesmo computador. O endereço IP mais usado para tal finalidade é 127.0.0.1 no IPv4 e ::1 no IPv6. O nome de domínio padrão para tal endereço é localhost. Em sistemas Unix, a interface loopback é geralmente chamada de lo ou lo0. Agora utilize o comando ifconfig para verificar o estado de suas interfaces e responda: Quantas e quais interfaces de rede sua máquina possui? Liste. Qual o significado/utilidade da interface lo? 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? Suas interfaces tem IPv6 configurado? Qual o endereço e escopo dos mesmos? Como foram obtidos? Qual o alcance (é roteável) do mesmo? 20.5.3.2 ping Aplicativo ping permite a um usuário verificar se um host remoto está ativo. É bastante utilizado para detectar problemas de comunicação na rede. O ping está baseado no envio de mensagens de solicitação de eco (echo request) e de resposta de eco (echo reply). Estas mensagens fazem parte do rol de mensagens do protocolo ICMP, que é um protocolo de reportagem de erros, a ser estudado mais tarde, componente do protocolo IP. O ping é um dos principais comandos a disposição do administrador de rede no sentido de verificar a conectividade em rede. Por exemplo, se houver resposta de um ping a partir de um servidor remoto, significa que a máquina local está rodando corretamente o TCP/IP, o enlace local está funcionando corretamente, o roteamento entre a origem e o destino está operando, e por fim, a máquina remota também está rodando corretamente o TCP/IP. Consultar as páginas man do ping para verificar as possibilidades de uso deste aplicativo. Exemplo 1: PING 200.135.37.65 (200.135.37.65) 56(84) bytes of data. 64 bytes from 200.135.37.65: icmp_seq=1 ttl=62 time=0.925 ms 64 bytes from 200.135.37.65: icmp_seq=2 ttl=62 time=0.743 ms 64 bytes from 200.135.37.65: icmp_seq=3 ttl=62 time=0.687 ms 64 bytes from 200.135.37.65: icmp_seq=4 ttl=62 time=0.689 ms ^C --- 200.135.37.65 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.687/0.761/0.925/0.097 ms </syntaxhighlight> No exemplo foram enviados quatro pacotes ICMP, cada um com um número de seqüência (icmp_seq), os quais foram recebidos com sucesso com o tempo de viagem assinalado (time) Cada pacote tem ainda um tempo de vida (ttl – time to live), o qual é decrementado em cada roteador, sendo o pacote descartado quando chegar a zero; isto evita pacotes perdidos na rede Quando o ping é interrompido (CRTL-C), uma estatística é apresentada indicando o percentual de pacotes transmitidos, recebidos e perdidos O tempo de viagem (rtt – round trip time) mínimo (min), médio (avg) e máximo (max) é calculado, assim como o desvio padrão (mdev) Como exercício envie ping para diferentes hosts e compare e anote os tempos de resposta: no endereço local de loopback; máquina de um colega do laboratório; servidor e roteador da rede da escola; servidores externos: www.ifsc.edu.br www.uol.com.br www.aaa.jp </syntaxhighlight> Explique as diferenças entre os tempos de resposta dos ping realizados: Entre ping para diferentes destinos. Entre respostas recebidas de um mesmo destino. Consulte as páginas man e teste o ping com os parâmetros abaixo e descreva suas funcionalidades: -c count -i intervalo -s packetsize -t ttl (para um site distante inicie com 1 e vá incrementando, observe as mensagens). Com essa estratégia é possível mapear os roteadores no caminho entre a origem e o destino de um pacote. 20.5.3.3 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 envia datagramas IP encapsulados em segmentos UDP a um host destino. Todavia escolhe um número de porta destino com um valor desconhecido (maior que 30000), tornando improvável que o host destino esteja usando esta porta. Quando o datagrama chega ao destino uma mensagem ICMP porta inalcançável é gerada e enviada a origem. O programa traceroute precisa saber diferenciar as mensagens ICMP recebidas – tempo excedido e porta inalcançável – para saber quando a rota foi concluída. Exemplo: sudo traceroute -I 200.135.37.65 traceroute to 200.135.37.65 (200.135.37.65), 30 hops max, 60 byte packets 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 3 hendrix.sj.ifsc.edu.br (200.135.37.65) 1.331 ms 1.313 ms 1.414 ms </syntaxhighlight> NOTA: O comando traceroute acima foi executado com o parâmetro -I. Esse comando força o traceroute a utilizar mensagens ICMP. Outra opção é utilizar o comando com o parâmetro -T, forçando o traceroute a utilizar o protocolo TCP para transmissão de seus pacotes. Caso nenhum dos parâmetros (-I ou -T) seja utilizado o traceroute utiliza o protocolo UDP como padrão. Visando barrar o tráfego de torrent na rede do Câmpus, o Firewall bloqueia as mensagens UDP da rede. Deste modo não é possível executar o comando traceroute na rede do Campus sem o uso dos parâmetro (-I ou -T). </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: máquina de um colega do laboratório servidor e roteador da rede da escola servidores americanos. Explique as diferenças entre os tempos de resposta: Entre traceroutes para diferentes destinos. No caso do traceroute para os EUA, aponte claramente qual foi o salto onde ocorreu a travessia do oceano. Como você chegou a essa conclusão? Entre as três medidas apresentadas para cada salto. O que justifica um possível tempo de resposta menor para um salto posterior? Por exemplo: pode-se obter no salto 13 um tempo de 289.207 ms e no salto 14 um tempo de 277.115 ms. Explique as linhas com o caracter *. 20.6 25/03/2019: Camada de Aplicação Atividade em Laboratório (Laboratório de Redes de Computadores) Configuração da máquina virtual VM VirtualBox em modo de tela cheia: No terminal do mate e digitar os comandos a seguir: sudo apt-get update sudo apt install build-essential module-assistant dkms sudo m-a prepare Após esta instalação, podemos clicar em Dispositivos, e ir na opção Inserir imagem de CD dos adicionais para convidado e executar a aplicação que irá abrir. configuração básica interface rede Configuração estática interface rede Material complementar: Editor vi Realização do Teste 1 (Avaliação 1: Introdução às Redes de Computadores) Questionário no Sigaa; 20.7 01/04/2019: Ferramentas básicas: WireShark e tcpdump KUROSE, J.F & ROSS, K. W. Todos os direitos reservados 20.7.1 Objetivos Conhecer aplicativos para verificar os parâmetros do TCP/IP Familiarização com os sniffers de rede WireShark e tcpdump. 20.7.2 Materiais de apoio Roteiro TCPDump Wireshark e manuais Ferramentas básicas: WireShark e tcpdump 20.7.3 Introdução O entendimento de protocolos de redes pode ser bastante aprofundado através da “observação de protocolos funcionando” e “da manipulação de protocolos” - observando a sequência de mensagens trocadas entre duas entidades, entrando nos detalhes da operação do protocolo, e fazendo com que os protocolos realizem certas ações e então observando estas ações e as consequências. A ferramenta básica para observar as mensagens trocadas entre as entidades em execução é chamada de sniffer. Como o nome sugere, um sniffer captura mensagens sendo enviadas/recebidas pelo seu computador; ele também tipicamente armazena e/ou apresenta os conteúdos dos vários campos dos protocolos nestas mensagens capturadas. Um sniffer isoladamente é um elemento passivo. Ele observa as mensagens sendo enviadas e recebidas pelas aplicações e protocolos executando no seu computador, mas jamais envia pacotes. Similarmente, os pacotes recebidos nunca são explicitamente endereçados ao sniffer. Ao invés disso, um sniffer recebe uma cópia de pacotes que são enviados/recebidos para/de aplicações e protocolos executando no seu computador. A Figura 1 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. Figura 1 - 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 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. Analisando os campos da interface do Wireshark Quando você executar o programa Wireshark, a interface com o usuário exibida na Figura 3 aparecerá. Inicialmente, nenhum dado será apresentado nas janelas. A interface do Wireshark tem seis componentes principais: Os menus de comandos são localizados no topo da janela. Por enquanto, interessam apenas os menus File e Capture. O menu File permite salvar dados de capturas de pacotes ou abrir um arquivo contendo dados de capturas de pacotes previamente realizadas, e sair da aplicação. O menu Capture permite iniciar uma captura de pacotes; A barra de ferramentas contém os comandos de menu que são mais frequentemente utilizados. Há atalhos para abrir ou salvar dados de captura de pacotes e para iniciar ou parar uma captura de pacotes; Abaixo da barra de ferramentas, está o campo de filtragem de pacotes exibidos. Nele podem ser digitados nome de protocolo ou outra informação apresentada na janela de listagem de pacotes. Apenas os pacotes que correspondem ao filtro são exibidos; A janela de listagem de pacotes apresenta um resumo de uma linha para cada pacote capturado, incluindo o número do pacote (atribuído pelo Wireshark; este não é o número do pacote contido no cabeçalho de qualquer protocolo), o tempo que o pacote foi capturado, os endereços fonte e destino do pacote, o tipo de protocolo, e informação específica do protocolo contida no pacote. A lista de pacotes pode ser ordenada conforme qualquer uma destas categorias clicando no nome de uma coluna correspondente. O campo tipo do protocolo lista o protocolo de mais alto nível que enviou ou recebeu este pacote, i.e., o protocolo que é a fonte ou o último sorvedouro para este pacote; A janela de detalhes de cabeçalho de pacotes fornece detalhes sobre o pacote selecionado na janela de listagem de pacotes. Para selecionar um pacote, basta clicar sobre ele com o botão esquerdo do mouse na janela de listagem de pacotes. Os detalhes apresentados incluem informações sobre o quadro Ethernet e o datagrama IP que contém o pacote. A quantidade de detalhes exibida pode ser expandida ou contraída. Se o pacote foi carregado sobre TCP ou UDP, detalhes correspondentes também são apresentados, os quais também podem ser contraídos ou expandidos. Finalmente, detalhes sobre o protocolo de mais alto nível que enviou ou recebeu este pacote também são apresentados; A janela de conteúdo de pacotes mostra o conteúdo inteiro do quadro capturado, nos formatos ASCII e hexadecimal. Figura 3 - Interface com o usuário do Wireshark 20.7.4 Roteiro de atividades Inicie o navegador web; Inicie o Wireshark. Inicialmente as janelas estarão vazias, pois não há captura de pacotes em progresso; Para iniciar uma captura de pacotes, selecione o menu Capture e depois Interfaces. Isso faz com que a janela de interfaces de rede disponíveis seja apresentada (Figura 4); Figura 4 - Interfaces de rede no Wireshark Basta clicar no botão Start da interface desejada para iniciar a captura de pacotes. Na Figura 4, como o Wireshark está sendo executado no Linux, o botão Start da interface eth0 deve ser selecionado; Como nada está acontecendo na rede, a janela apresenta o conteúdo vazio; No navegador, acesse o site http://www.ifsc.edu.br; Ao voltar para a janela do Wireshark, houve a captura de todos os pacotes envolvidos na conexão; Antes de continuar, vamos parar a captura de pacotes e trabalhar com o que temos. Basta clicar em Capture e depois em Stop; Para testar as capacidades de filtragem, vamos inserir a cadeia “http” (sem as aspas e em minúsculo) no especificação do filtro de exibição e depois selecionar Apply (ou Aplicar). Um resultado similar é exibido na figura 5; Figura 5 - Janela após a aplicação do filtro http Selecione a primeira mensagem HTTP exibida na janela de listagem de pacotes. Ela deve ser a mensagem HTTP GET que foi enviada do seu computador ao servidor HTTP em www.ifsc.edu.br. Quando você seleciona a mensagem HTTP GET, as informações dos cabeçalhos do quadro Ethernet, do datagrama IP, do segmento TCP e da mensagem HTTP aparecem na janela de cabeçalhos de pacotes. É possível ver os detalhes, expandido ou comprimindo os itens com um clique na seta ao lado deles. Se desejar acesse novos sítios e faça novas capturas e tente entender o que ocorre; Com Wireshark ativo (Abra-o novamente se necessário) acesse um sítio de sua preferência e responda às seguintes questões: Teste outros filtros, por exemplo, mostre somente pacotes originados e/ou destinados a um determinado host (ip.addr == 191.36.13.X). Anote o filtro utilizado e salve a janela do mesmo. Exemplo de filtros. 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. 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? 20.7.5 Tcpdump Leia atentamente o manual do tcpdump , principalmente os exemplos: man tcpdump </syntaxhighlight> Faça um ping e navegue para algum site de sua preferência e, com o uso de parâmetros apropriados, faça com que o tcpdump armazene os em um arquivo denominado “pacotes_capturadosX.pcap“ (um arquivo para cada item X): Capture todos os pacotes oriundos e destinados à sua máquina. Idem anterior com a flag -vvv ativa e, em seguida, a flag -n. Qual é a função dessas flags? Capture somente os pacotes oriundos de sua máquina. Anote o comando utilizado. Capture somente pacotes destinados à sua máquina. Anote o comando utilizado. Capture pacotes HTTP e DNS (lembre-se da porta de cada serviço). Anote o comando utilizado. Procure um dos arquivos salvos, com o navegador de arquivos de sua máquina, dê um duplo clique sobre o mesmo. Com qual programa foi aberto o arquivo? Exemplifique um possível uso dessa compatibilidade de arquivos? 20.8 08/04/19: Camada de Aplicação A camada de aplicação (ver estes [slides) Lista de Exercício: II 20.9 15/04/19: Camada de Aplicação Protocolos da Camada de Aplicação: HTTP, FTP, SMTP, POP e DNS. Lista de Exercício: III Revisão para Avaliação 1. 20.10 22/04/19: Camada de Aplicação Avaliação 1 (sala 02). 20.11 29/04/19: Camada de Aplicação Vista de prova. DNS: Domain Name System 20.11.1 DNS: Domain Name System Se você gasta algum tempo na internet mandando e-mails ou navegando pela web, está utilizando servidores de domínios sem mesmo perceber. O sistema DNS (Domain Name System) forma uma das maiores, mais ativas e mais distribuídas bases de dados do planeta. Sem o DNS, a internet acabaria rapidamente. Quando você navega na internet ou manda uma mensagem de e-mail, você estará utilizando um nome de domínio. Por exemplo, a URL "http://www.hsw.com.br" contém o nome de domínio howstuffworks.com. Assim como o endereço de e-mail "iknow@howstuffworks.com." Nomes como “howstuffworks.com” são facilmente lembrados pelas pessoas, mas não ajudam em nada as máquinas. Todas elas usam endereços de IP para se referirem umas às outras. A máquina a que as pessoas se referem como "www.hsw.com.br", por exemplo, possui o endereço IP 216.183.103.150. Toda vez que se usa um nome de domínio, os servidores de domínios da internet (DNS) estarão traduzindo os nomes de domínio legíveis em endereços de IP reconhecidos pelas máquinas. Durante um dia de navegação e envio de e-mails, os servidores de domínios podem ser acessados inúmeras vezes. Os servidores de domínios traduzem nomes de domínios em endereços de IP. Isto parece uma tarefa simples, e seria, exceto por cinco razões: Atualmente existem bilhões de endereços de IP em uso e a grande maioria das máquinas possui um nome legível associado. Alguns bilhões de requisições são feitas ao DNS todos os dias. Uma única pessoa pode fazer várias requisições em apenas um dia e existem muitas pessoas e máquinas usando a Internet diariamente. Nomes de domínio e endereços de IP podem mudar frequentemente (até mesmo diariamente). Novos nomes de domínio são criados todos os dias. Milhões de pessoas trabalham na mudança e no acréscimo de nomes de domínio e endereços de IP constantemente. O sistema DNS é uma base de dados, e nenhuma outra em todo o globo recebe tantas requisições. É a única, também, modificada por milhões de pessoas todos os dias. Isso é o que faz o sistema DNS tão singular. 20.11.1.1 Endereços IP Para manter todas as máquinas da Internet em perfeito funcionamento, cada uma delas é associada a um único endereço chamado endereço de IP. IP significa protocolo da Internet, e é um número de 32 bits normalmente apresentado como quatro “octetos” em um “número decimal pontuado.” Um endereço de IP comum se parece com esse: 216.183.103.150 Os quatro números em um endereço de IP são chamados de octetos por possuírem valores entre 0 e 255 (256 possibilidades por octeto). Toda máquina na Internet possui seu próprio endereço de IP (na verdade, tem ao menos UM endereço). Um servidor tem um endereço IP estático, que raramente muda. Uma máquina doméstica, que se conecta através de um modem, muitas vezes possui um endereço de IP designado pelo provedor no momento da conexão. Este endereço IP é único a cada sessão e pode mudar na próxima vez que houver uma conexão. Considerando isto, um provedor precisa apenas de um endereço IP para cada modem que dá suporte, ao invés de um para cada cliente (isso vale para ADSL ou conexões 3G também). Se você estiver usando um computador com sistema operacional Linux, você pode ver seu endereço IP por meio do seguinte comando: aluno@M2:~$ ifconfig eth0 Link encap:Ethernet Endereço de HW 84:2b:2b:7c:54:f5 inet end.: 172.18.80.251 Bcast:172.18.127.255 Masc:255.255.128.0 endereço inet6: fe80::862b:2bff:fe7c:54f5/64 Escopo:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1 pacotes RX:3634552 erros:0 descartados:145885 excesso:0 quadro:0 Pacotes TX:608253 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:1000 RX bytes:888269786 (888.2 MB) TX bytes:195176030 (195.1 MB) IRQ:21 Memória:f7fe0000-f8000000 No exemplo acima, a interface de rede eth0 (que é o dispositivo de hardware ou software que liga o computador fisicamente a Internet) possui o endereço IP 172.18.80.251. As demais informações descrevem outros parâmetros e características da interface de rede, e serão estudados em momento oportuno (mas não agora ;-). Para que as máquinas acessem a Internet, é necessário apenas um endereço de IP para se conectar a um servidor. Você poderia digitar em seu navegador, por exemplo, a URL http://200.135.190.95 e alcançaria a máquina que contém o servidor web do IFSC. Porém essa forma de endereçar servidores na Internet é pouco prática. Nomes de domínio são estritamente usados para a nossa conveniência. 20.11.1.2 Nomes de domínios Se precisássemos lembrar de todos os endereços de IP das páginas da Web que visitamos diariamente, ficaríamos malucos. Seres humanos não são bons em lembrar séries de números. No entanto, somos bons na lembrança de palavras, por isso usamos os nomes de domínios. Você possui, provavelmente, vários nomes de domínios guardados em sua cabeça. Como por exemplo: www.hsw.com.br - um nome típico www.google.com - o nome mais conhecido no mundo www.mit.edu - um nome EDU (educacionais) bastante popular encarta.msn.com - um servidor da Web que não começa com www www.bbc.co.uk - um nome que utiliza quatro partes em vez de três ftp.microsoft.com - um servidor FTP (em inglês) ao invés de um servidor da Web As partes COM, EDU e UK destes servidores são chamadas de domínios principais ou domínios de primeiro nível. Existem vários domínios principais, incluindo COM, EDU, GOV, MIL, NET, ORG e INT, assim como as singulares combinações de duas letras para cada país (em inglês). Em cada domínio principal existe uma enorme lista de domínios secundários. No domínio principal COM, por exemplo, tem-se: howstuffworks google msn microsoft ... e milhões de outros. Cada nome no domínio principal COM precisa ser único, mas podem existir réplicas entre os domínios. Por exemplo, howstuffworks.com e howstuffworks.org são duas máquinas completamente diferentes. No caso de bbc.co.uk, este é um domínio terciário. São possíveis até 127 níveis, no entanto, mais do que quatro são raros. A palavra mais à esquerda, como www ou encarta, é nome de hospedagem, que determina o nome de uma máquina específica (com um endereço de IP próprio) em um domínio. Um domínio concedido pode conter milhões de nomes de hospedagem desde que sejam únicos. Por causa desta determinação de todos os nomes em um domínio serem únicos, é necessário que uma entidade controle a lista destes servidores e garanta que nenhuma duplicação aconteça. O domínio COM, por exemplo, não pode conter dois nomes iguais e uma empresa chamada Network Solutions (em inglês) é a responsável por manter esta lista. Ao registrar um nome de domínio, o processo passa por um dos inúmeros registradores que trabalham na Network Solutions para adicionar nomes à lista. Ao mesmo tempo, é mantida uma base de dados chamada whois (em inglês) que contém informações sobre o proprietário e o servidor de cada domínio. Se você acessar o formulário whois (em inglês), encontrará informações acerca de qualquer domínio existente. Apesar de ser importante possuir uma autoridade central cuidando da base de dados referente aos nomes no domínio principal COM (e nos outros), você pode não querer centralizar a base de dados de todas as informações do domínio. A Microsoft, por exemplo, tem inúmeros endereços de IP e de nomes de hospedagens. Esta empresa quer manter seu próprio servidor de domínio pelo microsoft.com. Similarmente, a Grã-Bretanha quer administrar os domínios principais uk e a Austrália os domínios au, assim como nós brasileiros queremos administrar os domínios br. Por esta razão, o sistema DNS é um sistema partilhado. A Microsoft é completamente responsável pela manutenção do servidor microsoft.com: ela mantém as máquinas que implementam sua parte do sistema DNS, podendo mudar a base de dados de seu domínio sempre que necessitar, pois possui seus próprios servidores de domínio. Todo domínio possui um servidor em algum lugar, responsável por lidar com as requisições, onde há uma pessoa mantendo os registros deste DNS. Esta é uma das partes mais extraordinárias deste sistema: ele está completamente espalhado por todo o planeta em milhões de máquinas, administradas por milhões de pessoas e, ainda assim, se comporta como uma base de dados única e integrada. 20.11.1.3 Servidores DNS Servidores DNS fazem duas coisas o tempo todo: Aceitam solicitações de programas para converter nomes de domínios em endereços de IP. Aceitam solicitações de outros servidores para converter nomes de domínios em endereços de IP. Quando uma solicitação chega, o servidor pode exercer uma das quatro opções: Pode responder diretamente com um endereço de IP, por já conhecer previamente este endereço do domínio. Pode contatar outros servidores e tentar encontrar o endereço de IP para que foi solicitado, um processo que pode ser repetido várias vezes. Pode dizer: “eu não sei o endereço de IP para o domínio solicitado, mas aqui está o endereço de IP de um servidor que sabe mais do que eu.” Pode retornar uma mensagem de erro, pois o domínio solicitado é inválido ou inexistente. Ao digitar uma URL em seu navegador, o primeiro passo que este faz é converter o nome do domínio e da hospedagem em um endereço IP, para que o navegador solicite uma página da web à máquina que possui esse endereço de IP. Para fazer esta conversão, o navegador se comunica com um servidor DNS. Ao configurar seu computador para se conectar a Internet, você (ou o software instalado para se conectar ao seu provedor) precisa informar ao computador qual o servidor DNS que deve ser usado para a conversão de nomes de domínios em endereços de IP. Para ver qual o servidor DNS configurado em seu computador (assumindo que ele esteja com Linux), use o comando nslookup: aluno@M2:~$ nslookup www.ifsc.edu.br Server: 200.135.37.65 Address: 200.135.37.65#53 Non-authoritative answer: Name: www.ifsc.edu.br Address: 200.18.10.13 20.11.1.4 A estrutura das informações mantidas no DNS Como deve ter ficado claro na seção anterior, 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 (na seção anterior isso foi denominado hospedagem). 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 br é o domínio do topo da hierarquia ao qual mail.sj.ifsc.edu.br pertence. Já edu é um subdomíno de br, ifsc um subdomínio de edu, 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. Clientes buscam informação no DNS usando uma biblioteca de resolução (resolver library), que envia as consultas para um ou mais servidores de nomes e interpreta as respostas. (tirado do manual do BIND9) Ver também o livro sobre DNS e BIND da O'Reilly. Você pode consultar a IANA para conhecer as delegações dos top-level domains como o .br, por exemplo. A IANA é responsável por coordenar estas delegações em confirmidade com suas políticas. Consulte: top-level domains 20.11.1.5 Registros DNS Cada rótulo na hierarquia DNS possui um conjunto de informações associadas a si. Essas informações são guardas em registros de diferentes tipos, dependendo de seu significado e propósito. Cada consulta ao DNS retorna assim as informações do registro pedido associado ao rótulo. Por exemplo, para ver o registro de endereço IP associado a www.ifsc.edu.br pode-se executar o comando dig (o resultado teve alguns comentários removidos): tisemp@sj-lin-des2-744934:~$ dig www.ifsc.edu.br ;; QUESTION SECTION: ;www.ifsc.edu.br. IN A ;; ANSWER SECTION: www.ifsc.edu.br. 310 IN A 200.135.190.95 ;; AUTHORITY SECTION: ifsc.edu.br. 3592 IN NS adns1.pop-sc.rnp.br. ifsc.edu.br. 3592 IN NS ns1.ifsc.edu.br. ifsc.edu.br. 3592 IN NS ns2.ifsc.edu.br. ifsc.edu.br. 3592 IN NS adns2.pop-sc.rnp.br. ;; ADDITIONAL SECTION: ns1.ifsc.edu.br. 3592 IN A 200.135.190.1 ns2.ifsc.edu.br. 1061 IN A 200.135.190.3 adns1.pop-sc.rnp.br. 493216 IN A 200.237.192.10 adns1.pop-sc.rnp.br. 493216 IN AAAA 2801:80:a88:4000::10 adns2.pop-sc.rnp.br. 493216 IN A 200.135.14.10 adns2.pop-sc.rnp.br. 493216 IN AAAA 2001:12f0:200:a014::10 Cada uma das informações acima mostra um determinado registro e seu conteúdo, como descrito na tabela abaixo: Nome TTL Classe Registro Conteúdo do registro hendrix.sj.ifsc.edu.br. 3600 IN A 200.135.37.65 sj.ifsc.edu.br. 3600 IN NS hendrix.sj.ifsc.edu.br. sj.ifsc.edu.br. 3600 IN MX 10 hendrix.sj.ifsc.edu.br. Obs: TTL é o tempo de validade (em segundos) da informação retornada do servidor de nomes, e classe é o tipo de endereço (no caso IN equivale a endereços Internet). Os tipos de registros mais comuns são: Registro Descrição Exemplo A Endereço (Address) www.ifsc.edu.br IN A 200.135.190.95 NS Servidor de nomes (Name Server) sj.ifsc.edu.br IN NS hendrix.sj.ifsc.edu.br. CNAME Apelido (Canonical Name) mail.sj.ifsc.edu.br IN CNAME hendrix.sj.ifsc.edu.br. MX Roteador de email (Mail Exchanger) sj.ifsc.edu.br IN MX mail.sj.ifsc.edu.br. SOA dados sobre o domínio (Start of Authority) sj.ifsc.edu.br IN SOA hendrix.sj.ifsc.edu.br. root.sj.ifsc.edu.br. 2009120102 1200 120 604800 3600 PTR Ponteiro para nome (Pointer) 65.37.135.200.in-addr.arpa IN PTR hendrix.sj.ifsc.edu.br. TXT Texto genérico (Text) sj.ifsc.edu.br IN TXT "v=spf1 a mx ~all" Uma zona assim é composta de um conjunto de registros com todas as informações dos domínios nela contidos. O conteúdo de uma zona, contendo o domínio example.com, pode ser visualizado abaixo: example.com 86400 IN SOA ns1.example.com. hostmaster.example.com. ( 2002022401 ; serial 10800 ; refresh 15 ; retry 604800 ; expire 10800 ; minimum ) IN NS ns1.example.com. IN NS ns2.smokeyjoe.com. IN MX 10 mail.another.com. IN TXT "v=spf1 mx -all" ns1 IN A 192.168.0.1 www IN A 192.168.0.2 ftp IN CNAME www.example.com. bill IN A 192.168.0.3 fred IN A 192.168.0.4 20.11.2 Atividade Usando o programa host ou dig, descubra os endereços IP associados aos seguintes nomes de domínios: mail.ifsc.edu.br www.sj.ifsc.edu.br www.google.com www.gmail.com www.amazon.co.uk www.gov.za www.sls.com.au Agora descubra quem é o servidor DNS responsável por cada um dos domínios dos nomes acima. Para isso consulte o valor do registro NS associado a esses domínios. Por exemplo, com o programa host isso pode ser feito assim: host -t ns ifsc.edu.br Descubra qual o servidor DNS usado pelo seu computador. Para isso é mais fácil usar o programa nslookup: # Use o nslookup para consultar o endereço IP de um nome qualquer ... nslookup sj.ifsc.edu.br 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. Portanto, execute o wireshark: sudo wireshark ... e em seguida faça uma consulta DNS qualquer. Com base nisso identifique o seguinte: Quantas mensagens são trocadas entre cliente e servidor DNS para cada consulta ? Que protocolo de transporte é usado ? E que port ? Qual o formato das mensagens DNS ? Elas são textuais como as mensagens HTTP ou SMTP ? Qual o tipo de registro DNS acessado em cada consulta ? Que informações estão contidas nas respostas DNS ? Há algo além do que foi pedido ? Qual o tamanho das mensagens DNS ? O serviço DNS fornece outras informações além do endereço IP associado a cada nome de domínio. Por exemplo, como ele se pode descobrir que host recebe emails em um determinado domínio. Isso é utilizado pelos MTA mundo afora para entregarem emails para seus destinatários (lembre que isso se faz com o protocolo SMTP). Para descobrir essa informação, deve-se consultar o registro MX de um domínio. Por exemplo: host -t mx ifsc.edu.br Descubra quem é o servidor que recebe emails nos seguintes domínios: gmail.com hotmail.com uol.com.br ufsc.br Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim: dig -x 200.135.190.95 ... 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. Como explicado durante a aula, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões ?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado ? Descubra quem são os servidores raiz (topo de hierarquia DNS): host -t ns . Escolha um dos servidores listados, e use-o para fazer as consultas. Por exemplo: host -v -t a www.sj.ifsc.edu.br. j.root-servers.net. ... e observe a seção ;; AUTHORITY SECTION:. Ele contém a listagem de servidores DNS que podem atender sua consulta. Continue fazendo as consultas aos servidores DNS listados, até conseguir traduzir o nome requisitado. Quantos servidores DNS foi necessário consultar no total ? Repita esse exercício para os seguintes nomes de domínio: www.bbc.co.uk www.amazon.com www.reeec.illinois.edu www.inm.ras.ru 20.12 06/05/19: Camada de Transporte Introdução à Camada de Transporte; Resolução da Lista de exercícios 5 20.13 13/05/19: Camada de Transporte Protocolos Dutados: Volta-N; Retransmissão Seletiva. 20.14 20/05/19: Camada de Transporte Controle de Fluxo e Congestionamento do TCP. Resolução da Lista de exercícios 5 20.15 27/05/19: Camada de Transporte As atividades de hoje buscarão mostrar as características básicas de comunicações com protocolos de transporte. Experimento TCP x UDP 20.15.1 Aplicações e protocolos de transporte Faça uma rápida pesquisa e descubra que protocolos de transporte (e que ports) são usados por estas aplicações: SSH FTP BitTorrent emule WINS Compartilhamento de arquivos do Windows Windows Terminal Service NFS Openvpn RADIUS DHCP SNMP NTP LDAP Mysql Postgresql Oracle RDBMS Syslog CUPS Que protocolo de transporte predomina nesse conjunto ? 20.15.2 Tipos de protocolos de transporte: TCP x UDP Nestes experimentos, serão evidenciadas diferenças entre os protocolos TCP e UDP. 20.15.2.1 Experimento 1 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 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 ? Abra um terminal e execute o seguinte comando para fazer o download de um arquivo a ser usado no experimento: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso Observe o tamanho do arquivo transferido ... ele deve ter exatamente 832569344 bytes (cerca de 832 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. A primeira transferência será feita usando o protocolo TCP da seguinte forma: No computador receptor execute: nc -l 5555 > arquivo No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): time nc 192.168.1.X 5555 < ubuntu.iso 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: No computador receptor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x receptor). No computador receptor execute: ./receptor 5555 > arquivo No computador transmissor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x transmissor). No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): ./transmissor 192.168.1.X 5555 < ubuntu.iso Quando completar a transferência, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original ? E quanto tempo levou para transmiti-lo ? Compare as transferências feitas com TCP e UDP. O que eles têm em comum ? Que diferenças lhe pareceram mais pronunciadas ? Como isso deve afetar as aplicações que usam esses protocolos ? 20.15.2.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, como mostrado na figura abaixo: Abra um terminal em seu computador, e nele execute este comando: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso 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á se logar em um dos computadores do laboratório e 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 ? Finalmente, o professor irá repetir a transferência porém com mais dois 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: Abra dois terminais. Em um deles execute este comando: watch -n 1 ls -l arquivo ... e no outro execute: ./receptor 5555 > arquivo Como se comparam as transferências usando TCP e UDP? 20.16 03/06/19: Avaliação Camada de Transporte Local: sala 02. Horário: 19h.

Semestre 2018-2 - Prof. Tiago Semprebom

21 TecTel: Redes de Computadores - 2018-2 - Prof. Tiago Semprebom 22 Professor Professor: Tiago Semprebom Email: tisemp@ifsc.edu.br Atendimento paralelo: 3a feira 17:30h - 18:30 h (sala de professores de telecomunicações II) Endereço web do grupo: http://groups.google.com/group/ifsc_res Endereço de e-mail da disciplina: ifsc_res@googlegroups.com 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. O não cumprimento desse procedimento implica a impossibilidade de fazer a recuperação, e assim a reprovação na disciplina. 22.1 Plano de Ensino 23 Notas Matrícula A1 A2 A3 A4 Rel. Tec. Final 201823806749 7,0 7,0 8,0 7,0 OK 7,0 201811103467 6,0 7,0 6,0 10,0 OK 7,0 172001603800 5,0 0,0 0,0 0,0 NOK 0,0 201811103475 5,0 5,0 6,0 8,0 OK 5,0 201811101502 6,0 6,0 6,0 9,0 OK 7,0 172004092300 5,0 5,0 2,0 1,0 OK 4,0 201811101779 6,0 6,0 6,0 9,0 OK 6,0 201811100960 6,0 7,0 8,0 10,0 OK 8,0 172004117200 9,0 0,0 0,0 0,0 NOK 0,0 201811100461 8,0 9,0 9,0 10,0 OK 9,0 201811103432 6,0 7,0 8,0 8,0 OK 7,0 201811101500 6,0 7,0 4,0 3,0 OK 5,0 201811103461 6,0 7,0 4,0 0,0 NOK 4,0 172004109100 6,0 6,0 7,0 6,0 OK 6,0 F: faltou (X): conceito da recuperação negrito: com direito a recuperação 24 Curiosidades Breve histórico sobre o surgimento das redes de computadores e a Internet Vídeo sobre surgimento da Internet Vídeo sobre o funcionamento das fibras ópticas Vídeo sobre fibra óptica Mapas de rede dorsais (Backbones) Mapa da rede Ipê (Internet acadêmica pública no Brasil) POP SC (ponto de presença de SC) Telex O Ciberespaço e as Redes de Computadores na Construção de Novo Conhecimento Uma história das Redes de Computadores Breve História da Internet Uma representação artística das interligações na Internet 25 Materiais de aula 25.1 Slides Capítulo 1 Capítulo 2 Capítulo 3 Capítulo 4 25.2 Listas de exercícios Lista de exercícios 1 Lista de exercícios 2 Lista de exercícios 3 Lista de exercícios 4 Lista de exercícios 5 Lista de exercícios 6 Lista de exercícios 7 Lista de exercícios 8 Lista de exercícios 9 25.3 Apostilas Apostila de Redes de Computadores do Prof. Evandro Cantú 26 Aulas 26.1 31/07/18: Apresentação da disciplina Apresentação da disciplina, plano de aula, laboratórios e métodos de avaliação. Revisão de conceitos do Projeto Integrador I Introdução a Redes de Computadores [slides] 26.2 07/08/18: Introdução às Redes de Computadores Serviço orientado à conexão (TCP). Serviço não orientado à conexão (UDP). Comutação de circuitos vs Comutação de pacotes. FDMA e TDMA. 26.3 15/08/18: Introdução à Redes de Computadores Redes de acesso e meio físico; Resolução de exercícios (Lista 1). 26.4 21/08/18: Lab01: Ferramentas básicas de redes (Lab. Redes de Computadores) Arquitetura em Camadas; Correção lista de exercício II. Nesta atividade serão vistos algumas ferramentas utilizadas para obter informações relacionadas às configurações de uma rede de computadores. Roteiro 1 (ping, ifconfig, traceroute) Roteiro Rápido do SS - Socket Statistics 26.5 28/08/18: Lab02: Introdução à Redes de Computadores (Lab. de Redes de Computadores) Continuação Laboratório (21/08/2018); Correção da Lista de exercício I; Atraso em redes de chaveamento de pacotes, Arquitetura em camadas. 26.6 04/09/18: Camada de Aplicação (Lab. de Redes de Computadores) Atividade em Laboratório (Laboratório de Programação) Configuração da máquina virtual VM VirtualBox em modo de tela cheia: No terminal do mate e digitar os comandos a seguir: sudo apt-get update sudo apt-get install build-essential module-assistant dkms sudo m-a prepare Após esta instalação, podemos clicar em Dispositivos, e ir na opção Inserir imagem de CD dos adicionais para convidado e executar a aplicação que irá abrir. configuração básica interface rede Configuração estática interface rede Realização do Teste 1 (Avaliação 1: Introdução às Redes de Computadores) Questionário no Sigaa; 26.7 11/09/18: Camada de Aplicação Revisão do teste realizado na aula do dia 04/09/2018; Captura de pacotes na rede (Wireshark) Roteiro TCPDump Wireshark e manuais Números de portas (IANA) Monitoramento de interface de rede (básica - modo texto): IPTraf IPTraf, operando em modo ip traffic monitor 26.8 18/09/18: Camada de Aplicação (antecipação da aula do dia 30/10/2018) Palestra no contexto da disciplina FTE: A Reforma Trabalhista e seus Reflexos na Classe Trabalhadora; Profa Kelem Ghellere Rosso (IFPR). 26.9 25/09/18: Camada de Aplicação A camada de aplicação (ver estes [slides) Lista de Exercícios: II e III 26.10 02/10/18: Camada de Aplicação 26.10.1 DNS: Domain Name System Se você gasta algum tempo na internet mandando e-mails ou navegando pela web, está utilizando servidores de domínios sem mesmo perceber. O sistema DNS (Domain Name System) forma uma das maiores, mais ativas e mais distribuídas bases de dados do planeta. Sem o DNS, a internet acabaria rapidamente. Quando você navega na internet ou manda uma mensagem de e-mail, você estará utilizando um nome de domínio. Por exemplo, a URL "http://www.hsw.com.br" contém o nome de domínio howstuffworks.com. Assim como o endereço de e-mail "iknow@howstuffworks.com." Nomes como “howstuffworks.com” são facilmente lembrados pelas pessoas, mas não ajudam em nada as máquinas. Todas elas usam endereços de IP para se referirem umas às outras. A máquina a que as pessoas se referem como "www.hsw.com.br", por exemplo, possui o endereço IP 216.183.103.150. Toda vez que se usa um nome de domínio, os servidores de domínios da internet (DNS) estarão traduzindo os nomes de domínio legíveis em endereços de IP reconhecidos pelas máquinas. Durante um dia de navegação e envio de e-mails, os servidores de domínios podem ser acessados inúmeras vezes. Os servidores de domínios traduzem nomes de domínios em endereços de IP. Isto parece uma tarefa simples, e seria, exceto por cinco razões: Atualmente existem bilhões de endereços de IP em uso e a grande maioria das máquinas possui um nome legível associado. Alguns bilhões de requisições são feitas ao DNS todos os dias. Uma única pessoa pode fazer várias requisições em apenas um dia e existem muitas pessoas e máquinas usando a Internet diariamente. Nomes de domínio e endereços de IP podem mudar frequentemente (até mesmo diariamente). Novos nomes de domínio são criados todos os dias. Milhões de pessoas trabalham na mudança e no acréscimo de nomes de domínio e endereços de IP constantemente. O sistema DNS é uma base de dados, e nenhuma outra em todo o globo recebe tantas requisições. É a única, também, modificada por milhões de pessoas todos os dias. Isso é o que faz o sistema DNS tão singular. 26.10.1.1 Endereços IP Para manter todas as máquinas da Internet em perfeito funcionamento, cada uma delas é associada a um único endereço chamado endereço de IP. IP significa protocolo da Internet, e é um número de 32 bits normalmente apresentado como quatro “octetos” em um “número decimal pontuado.” Um endereço de IP comum se parece com esse: 216.183.103.150 Os quatro números em um endereço de IP são chamados de octetos por possuírem valores entre 0 e 255 (256 possibilidades por octeto). Toda máquina na Internet possui seu próprio endereço de IP (na verdade, tem ao menos UM endereço). Um servidor tem um endereço IP estático, que raramente muda. Uma máquina doméstica, que se conecta através de um modem, muitas vezes possui um endereço de IP designado pelo provedor no momento da conexão. Este endereço IP é único a cada sessão e pode mudar na próxima vez que houver uma conexão. Considerando isto, um provedor precisa apenas de um endereço IP para cada modem que dá suporte, ao invés de um para cada cliente (isso vale para ADSL ou conexões 3G também). Se você estiver usando um computador com sistema operacional Linux, você pode ver seu endereço IP por meio do seguinte comando: aluno@M2:~$ ifconfig eth0 Link encap:Ethernet Endereço de HW 84:2b:2b:7c:54:f5 inet end.: 172.18.80.251 Bcast:172.18.127.255 Masc:255.255.128.0 endereço inet6: fe80::862b:2bff:fe7c:54f5/64 Escopo:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1 pacotes RX:3634552 erros:0 descartados:145885 excesso:0 quadro:0 Pacotes TX:608253 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:1000 RX bytes:888269786 (888.2 MB) TX bytes:195176030 (195.1 MB) IRQ:21 Memória:f7fe0000-f8000000 No exemplo acima, a interface de rede eth0 (que é o dispositivo de hardware ou software que liga o computador fisicamente a Internet) possui o endereço IP 172.18.80.251. As demais informações descrevem outros parâmetros e características da interface de rede, e serão estudados em momento oportuno (mas não agora ;-). Para que as máquinas acessem a Internet, é necessário apenas um endereço de IP para se conectar a um servidor. Você poderia digitar em seu navegador, por exemplo, a URL http://200.135.190.95 e alcançaria a máquina que contém o servidor web do IFSC. Porém essa forma de endereçar servidores na Internet é pouco prática. Nomes de domínio são estritamente usados para a nossa conveniência. 26.10.1.2 Nomes de domínios Se precisássemos lembrar de todos os endereços de IP das páginas da Web que visitamos diariamente, ficaríamos malucos. Seres humanos não são bons em lembrar séries de números. No entanto, somos bons na lembrança de palavras, por isso usamos os nomes de domínios. Você possui, provavelmente, vários nomes de domínios guardados em sua cabeça. Como por exemplo: www.hsw.com.br - um nome típico www.google.com - o nome mais conhecido no mundo www.mit.edu - um nome EDU (educacionais) bastante popular encarta.msn.com - um servidor da Web que não começa com www www.bbc.co.uk - um nome que utiliza quatro partes em vez de três ftp.microsoft.com - um servidor FTP (em inglês) ao invés de um servidor da Web As partes COM, EDU e UK destes servidores são chamadas de domínios principais ou domínios de primeiro nível. Existem vários domínios principais, incluindo COM, EDU, GOV, MIL, NET, ORG e INT, assim como as singulares combinações de duas letras para cada país (em inglês). Em cada domínio principal existe uma enorme lista de domínios secundários. No domínio principal COM, por exemplo, tem-se: howstuffworks google msn microsoft ... e milhões de outros. Cada nome no domínio principal COM precisa ser único, mas podem existir réplicas entre os domínios. Por exemplo, howstuffworks.com e howstuffworks.org são duas máquinas completamente diferentes. No caso de bbc.co.uk, este é um domínio terciário. São possíveis até 127 níveis, no entanto, mais do que quatro são raros. A palavra mais à esquerda, como www ou encarta, é nome de hospedagem, que determina o nome de uma máquina específica (com um endereço de IP próprio) em um domínio. Um domínio concedido pode conter milhões de nomes de hospedagem desde que sejam únicos. Por causa desta determinação de todos os nomes em um domínio serem únicos, é necessário que uma entidade controle a lista destes servidores e garanta que nenhuma duplicação aconteça. O domínio COM, por exemplo, não pode conter dois nomes iguais e uma empresa chamada Network Solutions (em inglês) é a responsável por manter esta lista. Ao registrar um nome de domínio, o processo passa por um dos inúmeros registradores que trabalham na Network Solutions para adicionar nomes à lista. Ao mesmo tempo, é mantida uma base de dados chamada whois (em inglês) que contém informações sobre o proprietário e o servidor de cada domínio. Se você acessar o formulário whois (em inglês), encontrará informações acerca de qualquer domínio existente. Apesar de ser importante possuir uma autoridade central cuidando da base de dados referente aos nomes no domínio principal COM (e nos outros), você pode não querer centralizar a base de dados de todas as informações do domínio. A Microsoft, por exemplo, tem inúmeros endereços de IP e de nomes de hospedagens. Esta empresa quer manter seu próprio servidor de domínio pelo microsoft.com. Similarmente, a Grã-Bretanha quer administrar os domínios principais uk e a Austrália os domínios au, assim como nós brasileiros queremos administrar os domínios br. Por esta razão, o sistema DNS é um sistema partilhado. A Microsoft é completamente responsável pela manutenção do servidor microsoft.com: ela mantém as máquinas que implementam sua parte do sistema DNS, podendo mudar a base de dados de seu domínio sempre que necessitar, pois possui seus próprios servidores de domínio. Todo domínio possui um servidor em algum lugar, responsável por lidar com as requisições, onde há uma pessoa mantendo os registros deste DNS. Esta é uma das partes mais extraordinárias deste sistema: ele está completamente espalhado por todo o planeta em milhões de máquinas, administradas por milhões de pessoas e, ainda assim, se comporta como uma base de dados única e integrada. 26.10.1.3 Servidores DNS Servidores DNS fazem duas coisas o tempo todo: Aceitam solicitações de programas para converter nomes de domínios em endereços de IP. Aceitam solicitações de outros servidores para converter nomes de domínios em endereços de IP. Quando uma solicitação chega, o servidor pode exercer uma das quatro opções: Pode responder diretamente com um endereço de IP, por já conhecer previamente este endereço do domínio. Pode contatar outros servidores e tentar encontrar o endereço de IP para que foi solicitado, um processo que pode ser repetido várias vezes. Pode dizer: “eu não sei o endereço de IP para o domínio solicitado, mas aqui está o endereço de IP de um servidor que sabe mais do que eu.” Pode retornar uma mensagem de erro, pois o domínio solicitado é inválido ou inexistente. Ao digitar uma URL em seu navegador, o primeiro passo que este faz é converter o nome do domínio e da hospedagem em um endereço IP, para que o navegador solicite uma página da web à máquina que possui esse endereço de IP. Para fazer esta conversão, o navegador se comunica com um servidor DNS. Ao configurar seu computador para se conectar a Internet, você (ou o software instalado para se conectar ao seu provedor) precisa informar ao computador qual o servidor DNS que deve ser usado para a conversão de nomes de domínios em endereços de IP. Para ver qual o servidor DNS configurado em seu computador (assumindo que ele esteja com Linux), use o comando nslookup: aluno@M2:~$ nslookup www.ifsc.edu.br Server: 200.135.37.65 Address: 200.135.37.65#53 Non-authoritative answer: Name: www.ifsc.edu.br Address: 200.18.10.13 26.10.1.4 A estrutura das informações mantidas no DNS Como deve ter ficado claro na seção anterior, 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 (na seção anterior isso foi denominado hospedagem). 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 br é o domínio do topo da hierarquia ao qual mail.sj.ifsc.edu.br pertence. Já edu é um subdomíno de br, ifsc um subdomínio de edu, 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. Clientes buscam informação no DNS usando uma biblioteca de resolução (resolver library), que envia as consultas para um ou mais servidores de nomes e interpreta as respostas. (tirado do manual do BIND9) Ver também o livro sobre DNS e BIND da O'Reilly. Você pode consultar a IANA para conhecer as delegações dos top-level domains como o .br, por exemplo. A IANA é responsável por coordenar estas delegações em confirmidade com suas políticas. Consulte: top-level domains 26.10.1.5 Registros DNS Cada rótulo na hierarquia DNS possui um conjunto de informações associadas a si. Essas informações são guardas em registros de diferentes tipos, dependendo de seu significado e propósito. Cada consulta ao DNS retorna assim as informações do registro pedido associado ao rótulo. Por exemplo, para ver o registro de endereço IP associado a www.ifsc.edu.br pode-se executar o comando dig (o resultado teve alguns comentários removidos): tisemp@sj-lin-des2-744934:~$ dig www.ifsc.edu.br ;; QUESTION SECTION: ;www.ifsc.edu.br. IN A ;; ANSWER SECTION: www.ifsc.edu.br. 310 IN A 200.135.190.95 ;; AUTHORITY SECTION: ifsc.edu.br. 3592 IN NS adns1.pop-sc.rnp.br. ifsc.edu.br. 3592 IN NS ns1.ifsc.edu.br. ifsc.edu.br. 3592 IN NS ns2.ifsc.edu.br. ifsc.edu.br. 3592 IN NS adns2.pop-sc.rnp.br. ;; ADDITIONAL SECTION: ns1.ifsc.edu.br. 3592 IN A 200.135.190.1 ns2.ifsc.edu.br. 1061 IN A 200.135.190.3 adns1.pop-sc.rnp.br. 493216 IN A 200.237.192.10 adns1.pop-sc.rnp.br. 493216 IN AAAA 2801:80:a88:4000::10 adns2.pop-sc.rnp.br. 493216 IN A 200.135.14.10 adns2.pop-sc.rnp.br. 493216 IN AAAA 2001:12f0:200:a014::10 Cada uma das informações acima mostra um determinado registro e seu conteúdo, como descrito na tabela abaixo: Nome TTL Classe Registro Conteúdo do registro hendrix.sj.ifsc.edu.br. 3600 IN A 200.135.37.65 sj.ifsc.edu.br. 3600 IN NS hendrix.sj.ifsc.edu.br. sj.ifsc.edu.br. 3600 IN MX 10 hendrix.sj.ifsc.edu.br. Obs: TTL é o tempo de validade (em segundos) da informação retornada do servidor de nomes, e classe é o tipo de endereço (no caso IN equivale a endereços Internet). Os tipos de registros mais comuns são: Registro Descrição Exemplo A Endereço (Address) www.ifsc.edu.br IN A 200.135.190.95 NS Servidor de nomes (Name Server) sj.ifsc.edu.br IN NS hendrix.sj.ifsc.edu.br. CNAME Apelido (Canonical Name) mail.sj.ifsc.edu.br IN CNAME hendrix.sj.ifsc.edu.br. MX Roteador de email (Mail Exchanger) sj.ifsc.edu.br IN MX mail.sj.ifsc.edu.br. SOA dados sobre o domínio (Start of Authority) sj.ifsc.edu.br IN SOA hendrix.sj.ifsc.edu.br. root.sj.ifsc.edu.br. 2009120102 1200 120 604800 3600 PTR Ponteiro para nome (Pointer) 65.37.135.200.in-addr.arpa IN PTR hendrix.sj.ifsc.edu.br. TXT Texto genérico (Text) sj.ifsc.edu.br IN TXT "v=spf1 a mx ~all" Uma zona assim é composta de um conjunto de registros com todas as informações dos domínios nela contidos. O conteúdo de uma zona, contendo o domínio example.com, pode ser visualizado abaixo: example.com 86400 IN SOA ns1.example.com. hostmaster.example.com. ( 2002022401 ; serial 10800 ; refresh 15 ; retry 604800 ; expire 10800 ; minimum ) IN NS ns1.example.com. IN NS ns2.smokeyjoe.com. IN MX 10 mail.another.com. IN TXT "v=spf1 mx -all" ns1 IN A 192.168.0.1 www IN A 192.168.0.2 ftp IN CNAME www.example.com. bill IN A 192.168.0.3 fred IN A 192.168.0.4 26.10.2 Atividade Usando o programa host ou dig, descubra os endereços IP associados aos seguintes nomes de domínios: mail.ifsc.edu.br www.sj.ifsc.edu.br www.google.com www.gmail.com www.amazon.co.uk www.gov.za www.sls.com.au Agora descubra quem é o servidor DNS responsável por cada um dos domínios dos nomes acima. Para isso consulte o valor do registro NS associado a esses domínios. Por exemplo, com o programa host isso pode ser feito assim: host -t ns ifsc.edu.br Descubra qual o servidor DNS usado pelo seu computador. Para isso é mais fácil usar o programa nslookup: # Use o nslookup para consultar o endereço IP de um nome qualquer ... nslookup sj.ifsc.edu.br 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. Portanto, execute o wireshark: sudo wireshark ... e em seguida faça uma consulta DNS qualquer. Com base nisso identifique o seguinte: Quantas mensagens são trocadas entre cliente e servidor DNS para cada consulta ? Que protocolo de transporte é usado ? E que port ? Qual o formato das mensagens DNS ? Elas são textuais como as mensagens HTTP ou SMTP ? Qual o tipo de registro DNS acessado em cada consulta ? Que informações estão contidas nas respostas DNS ? Há algo além do que foi pedido ? Qual o tamanho das mensagens DNS ? O serviço DNS fornece outras informações além do endereço IP associado a cada nome de domínio. Por exemplo, como ele se pode descobrir que host recebe emails em um determinado domínio. Isso é utilizado pelos MTA mundo afora para entregarem emails para seus destinatários (lembre que isso se faz com o protocolo SMTP). Para descobrir essa informação, deve-se consultar o registro MX de um domínio. Por exemplo: host -t mx ifsc.edu.br Descubra quem é o servidor que recebe emails nos seguintes domínios: gmail.com hotmail.com uol.com.br ufsc.br Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim: dig -x 200.135.190.95 ... 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. Como explicado durante a aula, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões ?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado ? Descubra quem são os servidores raiz (topo de hierarquia DNS): host -t ns . Escolha um dos servidores listados, e use-o para fazer as consultas. Por exemplo: host -v -t a www.sj.ifsc.edu.br. j.root-servers.net. ... e observe a seção ;; AUTHORITY SECTION:. Ele contém a listagem de servidores DNS que podem atender sua consulta. Continue fazendo as consultas aos servidores DNS listados, até conseguir traduzir o nome requisitado. Quantos servidores DNS foi necessário consultar no total ? Repita esse exercício para os seguintes nomes de domínio: www.bbc.co.uk www.amazon.com www.reeec.illinois.edu www.inm.ras.ru 26.11 09/10/18: Camada de Aplicação Continuação DNS; Correção Lista de Exercícios 2; Continuação Laboratório DNS (02/10/2018). 26.12 16/10/18: Avaliação 2 Camada de Aplicação; Local: sala 02; Horário: 20 horas; Teremos aula de revisão entre 19h - 20h; 26.13 23/10/18: Camada de Transporte Vista de prova A2 (Camada de Aplicação); Introdução à Camada de Transporte; Resolução da Lista de exercícios 5 26.14 30/10/18: Camada de Transporte Protocolos Dutados: Volta-N; Retransmissão Seletiva. Resolução da Lista de exercícios 5 26.15 06/11/18: Camada de Transporte As atividades de hoje buscarão mostrar as características básicas de comunicações com protocolos de transporte. 26.15.1 Aplicações e protocolos de transporte Faça uma rápida pesquisa e descubra que protocolos de transporte (e que ports) são usados por estas aplicações: SSH FTP BitTorrent emule WINS Compartilhamento de arquivos do Windows Windows Terminal Service NFS Openvpn RADIUS DHCP SNMP NTP LDAP Mysql Postgresql Oracle RDBMS Syslog CUPS Que protocolo de transporte predomina nesse conjunto ? 26.15.2 Tipos de protocolos de transporte: TCP x UDP Nestes experimentos, serão evidenciadas diferenças entre os protocolos TCP e UDP. 26.15.2.1 Experimento 1 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 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 ? Abra um terminal e execute o seguinte comando para fazer o download de um arquivo a ser usado no experimento: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso Observe o tamanho do arquivo transferido ... ele deve ter exatamente 832569344 bytes (cerca de 832 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. A primeira transferência será feita usando o protocolo TCP da seguinte forma: No computador receptor execute: nc -l 5555 > arquivo No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): time nc 192.168.1.X 5555 < ubuntu.iso 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: No computador receptor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x receptor). No computador receptor execute: ./receptor 5555 > arquivo No computador transmissor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x transmissor). No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): ./transmissor 192.168.1.X 5555 < ubuntu.iso Quando completar a transferência, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original ? E quanto tempo levou para transmiti-lo ? Compare as transferências feitas com TCP e UDP. O que eles têm em comum ? Que diferenças lhe pareceram mais pronunciadas ? Como isso deve afetar as aplicações que usam esses protocolos ? 26.15.2.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, como mostrado na figura abaixo: Abra um terminal em seu computador, e nele execute este comando: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso 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á se logar em um dos computadores do laboratório e 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 ? Finalmente, o professor irá repetir a transferência porém com mais dois 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: Abra dois terminais. Em um deles execute este comando: watch -n 1 ls -l arquivo ... e no outro execute: ./receptor 5555 > arquivo Como se comparam as transferências usando TCP e UDP? 26.16 13/11/18: Avaliação 3 Avaliação Camada de Transporte; 26.17 20/11/18: Camada de Rede Funções da camada de rede; Roteamento Intra e Inter-SA; 26.18 27/11/18: Camada de Rede Endereçamento IP; Segmentação de redes; 26.19 04/12/18: Camada de Rede Resolução de exercícios; Revisão Camada de Rede. 26.20 11/12/18: Avaliação 4 Avaliação de Camada de Rede; 26.21 18/12/18: Encerramento da disciplina Avaliações de recuperação.

Semestre 2018-1 - Prof. Tiago Semprebom

27 TecTel: Redes de Computadores - 2018-1 - Prof. Tiago Semprebom 28 Professor Professor: Tiago Semprebom Email: tisemp@ifsc.edu.br Atendimento paralelo: 3a feira 17:30h - 18:30 h (Sala de Professores de Tele 2) Endereço web do grupo: http://groups.google.com/group/ifsc_res Endereço de e-mail da disciplina: ifsc_res@googlegroups.com 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. O não cumprimento desse procedimento implica a impossibilidade de fazer a recuperação, e assim a reprovação na disciplina. 28.1 Plano de Ensino 29 Notas Matrícula A1 A2 A3 Rel. Tec. Final Alexandre Belo 6,0 5,0 7,0 OK 6,0 André Luiz da Silva Jr 0,0 0,0 0,0 OK 0,0 Bruno Ernesto Gomes Gonzalez 4,0 4,0 8,0 OK 5,0 Bruno Ricardo Campos 5,0 7,0 7,0 OK 6,0 Francisco E. Teixeira Gales 7,0 7,0 7,0 OK 7,0 Gilson Ribeiro Silva 8,0 7,0 8,0 OK 8,0 João Roberto Geniaki Jr. 8,0 10,0 10,0 OK 10,0 Patrick Danimar Fernandes 8,0 10,0 7,0 OK 8,0 Rodrigo Gonçalves 6,0 6,0 7,0 OK 6,0 Rony Pinto de Resende 9,0 9,0 9,0 OK 9,0 Silvana de Sousa Pinto Lima 5,0 8,0 7,0 OK 7,0 Thiago Bernardi de Andrade 8,0 10,0 8,0 OK 9,0 Vitor Cavichioli Flores 4,0 7,0 8,0 OK 6,0 Fabio Mafra 7,0 6,0 8,0 OK 7,0 Rodrigo Hammes 5,0 8,0 4,0 OK 5,0 F: faltou (X): conceito da recuperação negrito: com direito a recuperação 30 Curiosidades Breve histórico sobre o surgimento das redes de computadores e a Internet Vídeo sobre surgimento da Internet Vídeo sobre o funcionamento das fibras ópticas Vídeo sobre fibra óptica Mapas de rede dorsais (Backbones) Mapa da rede Ipê (Internet acadêmica pública no Brasil) POP SC (ponto de presença de SC) Telex O Ciberespaço e as Redes de Computadores na Construção de Novo Conhecimento Uma história das Redes de Computadores Breve História da Internet Uma representação artística das interligações na Internet 31 Materiais de aula 31.1 Slides Arquivo:Slides-kurose-cap1.pdf Arquivo:Slides-kurose-cap2.pdf Arquivo:RCO-semprebom-cap3.pdf Arquivo:RCO-semprebom-cap4.pdf 31.2 Listas de exercícios Lista de exercícios 1 Lista de exercícios 2 Lista de exercícios 3 Lista de exercícios 4 Lista de exercícios 5 Lista de exercícios 6 Lista de exercícios 7 Lista de exercícios 8 Lista de exercícios 9 31.3 Apostilas Apostila de Redes de Computadores do Prof. Evandro Cantú 32 Aulas 32.1 20/02/18: Apresentação da disciplina Apresentação da disciplina, plano de aula, laboratórios e métodos de avaliação. Revisão de conceitos do Projeto Integrador I Introdução a Redes de Computadores [slides] 32.2 27/02/18: Introdução à Redes de Computadores Serviço orientado à conexão (TCP). Serviço não orientado à conexão (UDP). Comutação de circuitos vs Comutação de pacotes. FDMA e TDMA. Resolução de exercícios (Lista 1) 32.3 06/03/18: Introdução à Redes de Computadores Redes de acesso e meio físico Resolução de Exercício (Lista I) 32.4 13/03/18: Introdução à Redes de Computadores Comemoração: 30 anos do Câmpus Sâo José; Local: Auditório 19h:30 - 20h:30 Arquitetura em Camadas 32.5 20/03/18: Lab01: Ferramentas básicas de redes (Lab. Redes II) Arquitetura em Camadas; Correção lista de exercício II. Nesta atividade serão vistos algumas ferramentas utilizadas para obter informações relacionadas às configurações de uma rede de computadores. Roteiro 1 (ping, ifconfig, traceroute) Roteiro Rápido do SS - Socket Statistics 32.6 27/03/18: Camada de Aplicação (Lab. de Redes II) Camada de Aplicação (Introdução); Lista de Exercícios II e III. Atividade em Laboratório (Laboratório de Programação) configuração básica interface rede Configuração estática interface rede 32.7 03/04/18: Camada de Aplicação Atividade em Laboratório (Laboratório de Redes II) Captura de pacotes na rede (Wireshark) Roteiro TCPDump Wireshark e manuais Números de portas (IANA) 32.8 10/04/18: Camada de Aplicação A camada de aplicação (ver estes [slides) Lista de Exercícios: II e III 32.9 17/04/18: Camada de Aplicação 32.9.1 DNS: Domain Name System Se você gasta algum tempo na internet mandando e-mails ou navegando pela web, está utilizando servidores de domínios sem mesmo perceber. O sistema DNS (Domain Name System) forma uma das maiores, mais ativas e mais distribuídas bases de dados do planeta. Sem o DNS, a internet acabaria rapidamente. Quando você navega na internet ou manda uma mensagem de e-mail, você estará utilizando um nome de domínio. Por exemplo, a URL "http://www.hsw.com.br" contém o nome de domínio howstuffworks.com. Assim como o endereço de e-mail "iknow@howstuffworks.com." Nomes como “howstuffworks.com” são facilmente lembrados pelas pessoas, mas não ajudam em nada as máquinas. Todas elas usam endereços de IP para se referirem umas às outras. A máquina a que as pessoas se referem como "www.hsw.com.br", por exemplo, possui o endereço IP 216.183.103.150. Toda vez que se usa um nome de domínio, os servidores de domínios da internet (DNS) estarão traduzindo os nomes de domínio legíveis em endereços de IP reconhecidos pelas máquinas. Durante um dia de navegação e envio de e-mails, os servidores de domínios podem ser acessados inúmeras vezes. Os servidores de domínios traduzem nomes de domínios em endereços de IP. Isto parece uma tarefa simples, e seria, exceto por cinco razões: Atualmente existem bilhões de endereços de IP em uso e a grande maioria das máquinas possui um nome legível associado. Alguns bilhões de requisições são feitas ao DNS todos os dias. Uma única pessoa pode fazer várias requisições em apenas um dia e existem muitas pessoas e máquinas usando a Internet diariamente. Nomes de domínio e endereços de IP podem mudar frequentemente (até mesmo diariamente). Novos nomes de domínio são criados todos os dias. Milhões de pessoas trabalham na mudança e no acréscimo de nomes de domínio e endereços de IP constantemente. O sistema DNS é uma base de dados, e nenhuma outra em todo o globo recebe tantas requisições. É a única, também, modificada por milhões de pessoas todos os dias. Isso é o que faz o sistema DNS tão singular. 32.9.1.1 Endereços IP Para manter todas as máquinas da Internet em perfeito funcionamento, cada uma delas é associada a um único endereço chamado endereço de IP. IP significa protocolo da Internet, e é um número de 32 bits normalmente apresentado como quatro “octetos” em um “número decimal pontuado.” Um endereço de IP comum se parece com esse: 216.183.103.150 Os quatro números em um endereço de IP são chamados de octetos por possuírem valores entre 0 e 255 (256 possibilidades por octeto). Toda máquina na Internet possui seu próprio endereço de IP (na verdade, tem ao menos UM endereço). Um servidor tem um endereço IP estático, que raramente muda. Uma máquina doméstica, que se conecta através de um modem, muitas vezes possui um endereço de IP designado pelo provedor no momento da conexão. Este endereço IP é único a cada sessão e pode mudar na próxima vez que houver uma conexão. Considerando isto, um provedor precisa apenas de um endereço IP para cada modem que dá suporte, ao invés de um para cada cliente (isso vale para ADSL ou conexões 3G também). Se você estiver usando um computador com sistema operacional Linux, você pode ver seu endereço IP por meio do seguinte comando: aluno@M2:~$ ifconfig eth0 Link encap:Ethernet Endereço de HW 84:2b:2b:7c:54:f5 inet end.: 172.18.80.251 Bcast:172.18.127.255 Masc:255.255.128.0 endereço inet6: fe80::862b:2bff:fe7c:54f5/64 Escopo:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1 pacotes RX:3634552 erros:0 descartados:145885 excesso:0 quadro:0 Pacotes TX:608253 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:1000 RX bytes:888269786 (888.2 MB) TX bytes:195176030 (195.1 MB) IRQ:21 Memória:f7fe0000-f8000000 No exemplo acima, a interface de rede eth0 (que é o dispositivo de hardware ou software que liga o computador fisicamente a Internet) possui o endereço IP 172.18.80.251. As demais informações descrevem outros parâmetros e características da interface de rede, e serão estudados em momento oportuno (mas não agora ;-). Para que as máquinas acessem a Internet, é necessário apenas um endereço de IP para se conectar a um servidor. Você poderia digitar em seu navegador, por exemplo, a URL http://200.135.190.28 e alcançaria a máquina que contém o servidor web do IFSC. Porém essa forma de endereçar servidores na Internet é pouco prática. Nomes de domínio são estritamente usados para a nossa conveniência. 32.9.1.2 Nomes de domínios Se precisássemos lembrar de todos os endereços de IP das páginas da Web que visitamos diariamente, ficaríamos malucos. Seres humanos não são bons em lembrar séries de números. No entanto, somos bons na lembrança de palavras, por isso usamos os nomes de domínios. Você possui, provavelmente, vários nomes de domínios guardados em sua cabeça. Como por exemplo: www.hsw.com.br - um nome típico www.google.com - o nome mais conhecido no mundo www.mit.edu - um nome EDU (educacionais) bastante popular encarta.msn.com - um servidor da Web que não começa com www www.bbc.co.uk - um nome que utiliza quatro partes em vez de três ftp.microsoft.com - um servidor FTP (em inglês) ao invés de um servidor da Web As partes COM, EDU e UK destes servidores são chamadas de domínios principais ou domínios de primeiro nível. Existem vários domínios principais, incluindo COM, EDU, GOV, MIL, NET, ORG e INT, assim como as singulares combinações de duas letras para cada país (em inglês). Em cada domínio principal existe uma enorme lista de domínios secundários. No domínio principal COM, por exemplo, tem-se: howstuffworks google msn microsoft ... e milhões de outros. Cada nome no domínio principal COM precisa ser único, mas podem existir réplicas entre os domínios. Por exemplo, howstuffworks.com e howstuffworks.org são duas máquinas completamente diferentes. No caso de bbc.co.uk, este é um domínio terciário. São possíveis até 127 níveis, no entanto, mais do que quatro são raros. A palavra mais à esquerda, como www ou encarta, é nome de hospedagem, que determina o nome de uma máquina específica (com um endereço de IP próprio) em um domínio. Um domínio concedido pode conter milhões de nomes de hospedagem desde que sejam únicos. Por causa desta determinação de todos os nomes em um domínio serem únicos, é necessário que uma entidade controle a lista destes servidores e garanta que nenhuma duplicação aconteça. O domínio COM, por exemplo, não pode conter dois nomes iguais e uma empresa chamada Network Solutions (em inglês) é a responsável por manter esta lista. Ao registrar um nome de domínio, o processo passa por um dos inúmeros registradores que trabalham na Network Solutions para adicionar nomes à lista. Ao mesmo tempo, é mantida uma base de dados chamada whois (em inglês) que contém informações sobre o proprietário e o servidor de cada domínio. Se você acessar o formulário whois (em inglês), encontrará informações acerca de qualquer domínio existente. Apesar de ser importante possuir uma autoridade central cuidando da base de dados referente aos nomes no domínio principal COM (e nos outros), você pode não querer centralizar a base de dados de todas as informações do domínio. A Microsoft, por exemplo, tem inúmeros endereços de IP e de nomes de hospedagens. Esta empresa quer manter seu próprio servidor de domínio pelo microsoft.com. Similarmente, a Grã-Bretanha quer administrar os domínios principais uk e a Austrália os domínios au, assim como nós brasileiros queremos administrar os domínios br. Por esta razão, o sistema DNS é um sistema partilhado. A Microsoft é completamente responsável pela manutenção do servidor microsoft.com: ela mantém as máquinas que implementam sua parte do sistema DNS, podendo mudar a base de dados de seu domínio sempre que necessitar, pois possui seus próprios servidores de domínio. Todo domínio possui um servidor em algum lugar, responsável por lidar com as requisições, onde há uma pessoa mantendo os registros deste DNS. Esta é uma das partes mais extraordinárias deste sistema: ele está completamente espalhado por todo o planeta em milhões de máquinas, administradas por milhões de pessoas e, ainda assim, se comporta como uma base de dados única e integrada. 32.9.1.3 Servidores DNS Servidores DNS fazem duas coisas o tempo todo: Aceitam solicitações de programas para converter nomes de domínios em endereços de IP. Aceitam solicitações de outros servidores para converter nomes de domínios em endereços de IP. Quando uma solicitação chega, o servidor pode exercer uma das quatro opções: Pode responder diretamente com um endereço de IP, por já conhecer previamente este endereço do domínio. Pode contatar outros servidores e tentar encontrar o endereço de IP para que foi solicitado, um processo que pode ser repetido várias vezes. Pode dizer: “eu não sei o endereço de IP para o domínio solicitado, mas aqui está o endereço de IP de um servidor que sabe mais do que eu.” Pode retornar uma mensagem de erro, pois o domínio solicitado é inválido ou inexistente. Ao digitar uma URL em seu navegador, o primeiro passo que este faz é converter o nome do domínio e da hospedagem em um endereço IP, para que o navegador solicite uma página da web à máquina que possui esse endereço de IP. Para fazer esta conversão, o navegador se comunica com um servidor DNS. Ao configurar seu computador para se conectar a Internet, você (ou o software instalado para se conectar ao seu provedor) precisa informar ao computador qual o servidor DNS que deve ser usado para a conversão de nomes de domínios em endereços de IP. Para ver qual o servidor DNS configurado em seu computador (assumindo que ele esteja com Linux), use o comando nslookup: aluno@M2:~$ nslookup www.ifsc.edu.br Server: 200.135.37.65 Address: 200.135.37.65#53 Non-authoritative answer: Name: www.ifsc.edu.br Address: 200.18.10.13 32.9.1.4 A estrutura das informações mantidas no DNS Como deve ter ficado claro na seção anterior, 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 (na seção anterior isso foi denominado hospedagem). 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 br é o domínio do topo da hierarquia ao qual mail.sj.ifsc.edu.br pertence. Já edu é um subdomíno de br, ifsc um subdomínio de edu, 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. Clientes buscam informação no DNS usando uma biblioteca de resolução (resolver library), que envia as consultas para um ou mais servidores de nomes e interpreta as respostas. (tirado do manual do BIND9) Ver também o livro sobre DNS e BIND da O'Reilly. Você pode consultar a IANA para conhecer as delegações dos top-level domains como o .br, por exemplo. A IANA é responsável por coordenar estas delegações em confirmidade com suas políticas. Consulte: top-level domains 32.9.1.5 Registros DNS Cada rótulo na hierarquia DNS possui um conjunto de informações associadas a si. Essas informações são guardas em registros de diferentes tipos, dependendo de seu significado e propósito. Cada consulta ao DNS retorna assim as informações do registro pedido associado ao rótulo. Por exemplo, para ver o registro de endereço IP associado a www.ifsc.edu.br pode-se executar o comando dig (o resultado teve alguns comentários removidos): tisemp@M1:~$ dig ifsc.edu.br ;; QUESTION SECTION: ;ifsc.edu.br. IN A ;; ANSWER SECTION: ifsc.edu.br. 3008 IN A 200.135.190.28 ;; AUTHORITY SECTION: ifsc.edu.br. 3060 IN NS ns1.ifsc.edu.br. ifsc.edu.br. 3060 IN NS ns2.ifsc.edu.br. ifsc.edu.br. 3060 IN NS adns1.pop-sc.rnp.br. ifsc.edu.br. 3060 IN NS adns2.pop-sc.rnp.br. ;; ADDITIONAL SECTION: adns1.pop-sc.rnp.br. 575397 IN A 200.237.192.10 adns1.pop-sc.rnp.br. 575397 IN AAAA 2801:80:a88:4000::10 adns2.pop-sc.rnp.br. 575397 IN A 200.135.14.10 adns2.pop-sc.rnp.br. 575397 IN AAAA 2001:12f0:200:a014::10 Cada uma das informações acima mostra um determinado registro e seu conteúdo, como descrito na tabela abaixo: Nome TTL Classe Registro Conteúdo do registro hendrix.sj.ifsc.edu.br. 3600 IN A 200.135.37.65 sj.ifsc.edu.br. 3600 IN NS hendrix.sj.ifsc.edu.br. sj.ifsc.edu.br. 3600 IN MX 10 hendrix.sj.ifsc.edu.br. Obs: TTL é o tempo de validade (em segundos) da informação retornada do servidor de nomes, e classe é o tipo de endereço (no caso IN equivale a endereços Internet). Os tipos de registros mais comuns são: Registro Descrição Exemplo A Endereço (Address) www.sj.ifsc.edu.br IN A 200.135.37.66 NS Servidor de nomes (Name Server) sj.ifsc.edu.br IN NS hendrix.sj.ifsc.edu.br. CNAME Apelido (Canonical Name) mail.sj.ifsc.edu.br IN CNAME hendrix.sj.ifsc.edu.br. MX Roteador de email (Mail Exchanger) sj.ifsc.edu.br IN MX mail.sj.ifsc.edu.br. SOA dados sobre o domínio (Start of Authority) sj.ifsc.edu.br IN SOA hendrix.sj.ifsc.edu.br. root.sj.ifsc.edu.br. 2009120102 1200 120 604800 3600 PTR Ponteiro para nome (Pointer) 65.37.135.200.in-addr.arpa IN PTR hendrix.sj.ifsc.edu.br. TXT Texto genérico (Text) sj.ifsc.edu.br IN TXT "v=spf1 a mx ~all" Uma zona assim é composta de um conjunto de registros com todas as informações dos domínios nela contidos. O conteúdo de uma zona, contendo o domínio example.com, pode ser visualizado abaixo: example.com 86400 IN SOA ns1.example.com. hostmaster.example.com. ( 2002022401 ; serial 10800 ; refresh 15 ; retry 604800 ; expire 10800 ; minimum ) IN NS ns1.example.com. IN NS ns2.smokeyjoe.com. IN MX 10 mail.another.com. IN TXT "v=spf1 mx -all" ns1 IN A 192.168.0.1 www IN A 192.168.0.2 ftp IN CNAME www.example.com. bill IN A 192.168.0.3 fred IN A 192.168.0.4 32.9.2 Atividade Usando o programa host ou dig, descubra os endereços IP associados aos seguintes nomes de domínios: mail.ifsc.edu.br www.sj.ifsc.edu.br www.google.com www.gmail.com www.amazon.co.uk www.gov.za www.sls.com.au Agora descubra quem é o servidor DNS responsável por cada um dos domínios dos nomes acima. Para isso consulte o valor do registro NS associado a esses domínios. Por exemplo, com o programa host isso pode ser feito assim: host -t ns ifsc.edu.br Descubra qual o servidor DNS usado pelo seu computador. Para isso é mais fácil usar o programa nslookup: # Use o nslookup para consultar o endereço IP de um nome qualquer ... nslookup sj.ifsc.edu.br 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. Portanto, execute o wireshark: sudo wireshark ... e em seguida faça uma consulta DNS qualquer. Com base nisso identifique o seguinte: Quantas mensagens são trocadas entre cliente e servidor DNS para cada consulta ? Que protocolo de transporte é usado ? E que port ? Qual o formato das mensagens DNS ? Elas são textuais como as mensagens HTTP ou SMTP ? Qual o tipo de registro DNS acessado em cada consulta ? Que informações estão contidas nas respostas DNS ? Há algo além do que foi pedido ? Qual o tamanho das mensagens DNS ? O serviço DNS fornece outras informações além do endereço IP associado a cada nome de domínio. Por exemplo, como ele se pode descobrir que host recebe emails em um determinado domínio. Isso é utilizado pelos MTA mundo afora para entregarem emails para seus destinatários (lembre que isso se faz com o protocolo SMTP). Para descobrir essa informação, deve-se consultar o registro MX de um domínio. Por exemplo: host -t mx ifsc.edu.br Descubra quem é o servidor que recebe emails nos seguintes domínios: gmail.com hotmail.com uol.com.br ufsc.br Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim: dig -x 200.180.10.13 ... 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. Como explicado durante a aula, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões ?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado ? Descubra quem são os servidores raiz (topo de hierarquia DNS): host -t ns . Escolha um dos servidores listados, e use-o para fazer as consultas. Por exemplo: host -v -t a www.sj.ifsc.edu.br. j.root-servers.net. ... e observe a seção ;; AUTHORITY SECTION:. Ele contém a listagem de servidores DNS que podem atender sua consulta. Continue fazendo as consultas aos servidores DNS listados, até conseguir traduzir o nome requisitado. Quantos servidores DNS foi necessário consultar no total ? Repita esse exercício para os seguintes nomes de domínio: www.bbc.co.uk www.amazon.com www.reeec.illinois.edu www.inm.ras.ru 32.10 24/04/18: Avaliação 1 Arquitetura Internet e Camada de Aplicação; Local: sala 02; Horário: 20 horas; Teremos aula de revisão entre 19h - 20h; 32.11 01/05/18: Feriado (dia do trabalho) Feriado Nacional. 32.12 08/05/18: Camada de Transporte (Lab. Redes 2) Introdução à Camada de Transporte; Local: Laboratório de Redes 2. Resolução lista de exercícios 4 32.13 15/05/18: Camada de Transporte (Lab. Redes 2) Protocolos Dutados: Volta-N; Retransmissão Seletiva. Resolução da Lista de exercícios 5 32.14 22/05/18: Camada de Transporte (Lab. Redes 2) Protocolo TCP (Laboratório (29/05/2018) para analisar mais afundo) Controle de Fluxo, congestionamento; Resolução e Correção da Lista de exercícios 5 32.15 29/05/18: Camada de Transporte (sem atividades letivas) Devido à paralisação dos caminhoneiros não houve atividades no Câmpus. 32.16 05/06/18: Camada de Transporte (Lab. Redes 2) As atividades de hoje buscarão mostrar as características básicas de comunicações com protocolos de transporte. 32.16.1 Aplicações e protocolos de transporte Faça uma rápida pesquisa e descubra que protocolos de transporte (e que ports) são usados por estas aplicações: SSH FTP BitTorrent emule WINS Compartilhamento de arquivos do Windows Windows Terminal Service NFS Openvpn RADIUS DHCP SNMP NTP LDAP Mysql Postgresql Oracle RDBMS Syslog CUPS Que protocolo de transporte predomina nesse conjunto ? 32.16.2 Tipos de protocolos de transporte: TCP x UDP Nestes experimentos, serão evidenciadas diferenças entre os protocolos TCP e UDP. 32.16.2.1 Experimento 1 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 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 ? Abra um terminal e execute o seguinte comando para fazer o download de um arquivo a ser usado no experimento: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso Observe o tamanho do arquivo transferido ... ele deve ter exatamente 832569344 bytes (cerca de 832 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. A primeira transferência será feita usando o protocolo TCP da seguinte forma: No computador receptor execute: nc -l 5555 > arquivo No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): time nc 192.168.1.X 5555 < ubuntu.iso 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: No computador receptor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x receptor). No computador receptor execute: ./receptor 5555 > arquivo No computador transmissor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x transmissor). No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): ./transmissor 192.168.1.X 5555 < ubuntu.iso Quando completar a transferência, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original ? E quanto tempo levou para transmiti-lo ? Compare as transferências feitas com TCP e UDP. O que eles têm em comum ? Que diferenças lhe pareceram mais pronunciadas ? Como isso deve afetar as aplicações que usam esses protocolos ? 32.16.2.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, como mostrado na figura abaixo: Abra um terminal em seu computador, e nele execute este comando: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso 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á se logar em um dos computadores do laboratório e 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 ? Finalmente, o professor irá repetir a transferência porém com mais dois 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: Abra dois terminais. Em um deles execute este comando: watch -n 1 ls -l arquivo ... e no outro execute: ./receptor 5555 > arquivo Como se comparam as transferências usando TCP e UDP? 32.17 12/06/18: Avaliação 2 19h - 20h: Revisão Camada de Transporte Avaliação Camada de Transporte: Local: Sala 02; Horário de início: 20h. 32.18 19/06/18: Camada de Rede Camada de Rede 32.19 26/06/18: Camada de Rede Camada de Rede 32.20 03/07/18: Avaliação 3 19h - 20h: Revisão Camada de Rede Avaliação Camada de Rede: Local: Sala 02; Horário de início: 20h. 32.21 09/07/18: Encerramento da disciplina (segunda-feira) Recuperações: Avaliação 1, 2 e 3.

Semestre 2017-2 - Prof. Tiago Semprebom

33 TecTel: Redes de Computadores - 2017-2 - Prof. Tiago Semprebom 34 Professor Professor: Tiago Semprebom Email: tisemp@ifsc.edu.br Atendimento paralelo: 3a feira 17:30h - 18:30 h (Sala de Professores de Telecomunicações II) Endereço web do grupo: http://groups.google.com/group/ifsc_res Endereço de e-mail da disciplina: ifsc_res@googlegroups.com 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. O não cumprimento desse procedimento implica a impossibilidade de fazer a recuperação, e assim a reprovação na disciplina. 34.1 Plano de Ensino 35 Notas Matrícula A1 A2 A3 Relatório Final 141001095-3 0,0 (6,0) 6,0 4,0 X X 152000553-9 0,0 0,0 0,0 X X 162000795-9 6,0 7,0 3,0 X X 162001704-0 4,1 6,0 3,0 X X 162002165-0 6,1 7,0 5,0 X X 171000747-8 7,3 7,0 9,0 X X 171001934-4 8,0 9,0 3,0 X X 171003927-2 5,3 7,0 9,0 X X 171006570-2 3,6 7,0 9,0 X X F: faltou (X): conceito da recuperação negrito: com direito a recuperação 36 Curiosidades Breve histórico sobre o surgimento das redes de computadores e a Internet Vídeo sobre surgimento da Internet Vídeo sobre o funcionamento das fibras ópticas Vídeo sobre fibra óptica Mapas de rede dorsais (Backbones) Mapa da rede Ipê (Internet acadêmica pública no Brasil) POP SC (ponto de presença de SC) Telex O Ciberespaço e as Redes de Computadores na Construção de Novo Conhecimento Uma história das Redes de Computadores Breve História da Internet Uma representação artística das interligações na Internet 37 Materiais de aula 37.1 Slides Arquivo:Slides-kurose-cap1.pdf Arquivo:Slides-kurose-cap2.pdf Arquivo:RCO-semprebom-cap3.pdf Arquivo:RCO-semprebom-cap4.pdf 37.2 Listas de exercícios Lista de exercícios 1 Lista de exercícios 2 Lista de exercícios 3 Lista de exercícios 4 Lista de exercícios 5 Lista de exercícios 6 Lista de exercícios 7 Lista de exercícios 8 Lista de exercícios 9 37.3 Apostilas Apostila de Redes de Computadores do Prof. Evandro Cantú 38 Aulas 38.1 01/08/17: Apresentação da disciplina Apresentação da disciplina, plano de aula, laboratórios e métodos de avaliação. Revisão de conceitos do Projeto Integrador I Introdução a Redes de Computadores [slides] 38.2 08/08/17: Introdução à Redes de Computadores Serviço orientado à conexão (TCP). Serviço não orientado à conexão (UDP). Comutação de circuitos vs Comutação de pacotes. FDMA e TDMA. Resolução de exercícios (Lista 1) 38.3 15/08/17: Arquitetura Internet Redes de acesso e meio físico Resolução de Exercício (Lista I) 38.4 22/08/17: Comutação por Circuitos, Comutação de Pacotes, Lab01: Ferramentas básicas de redes (Lab. Redes II) Introdução a Redes de Computadores [slides] Nesta atividade serão vistos algumas ferramentas utilizadas para obter informações relacionadas às configurações de uma rede de computadores. Roteiro 1 (ping, ifconfig, traceroute) Roteiro Rápido do SS - Socket Statistics 38.5 29/08/17: Arquitetura Internet Atrasos em redes de comutação de pacotes Arquitetura em Camadas Resolução de Exercício (Lista I) 38.6 04/09/17 (segunda-feira): Camada de Aplicação Protocolos da Camada de Aplicação. Lista de Exercícios II. 38.7 12/09/17: Camada de Aplicação (Laboratório de Programação) Correção lista de exercício II Atividade em Laboratório (Laboratório de Programação) configuração básica interface rede Configuração estática interface rede 38.8 19/09/17: Camada de Aplicação Atividade em Laboratório (Laboratório de Programação) Captura de pacotes na rede (Wireshark) Roteiro TCPDump Wireshark e manuais Números de portas (IANA) Teste ferramenta Iperf Teste HTTP V2 - simulador 38.9 26/09/17: Camada de Aplicação A camada de aplicação (ver estes [slides) Lista de Exercícios: II e III 38.10 03/10/17: Camada de Aplicação (Lab. Redes II) 38.10.1 DNS: Domain Name System 38.10.1.1 Uma breve descrição sobre DNS Se você gasta algum tempo na internet mandando e-mails ou navegando pela web, está utilizando servidores de domínios sem mesmo perceber. O sistema DNS (Domain Name System) forma uma das maiores, mais ativas e mais distribuídas bases de dados do planeta. Sem o DNS, a internet acabaria rapidamente. Quando você navega na internet ou manda uma mensagem de e-mail, você estará utilizando um nome de domínio. Por exemplo, a URL "http://www.hsw.com.br" contém o nome de domínio howstuffworks.com. Assim como o endereço de e-mail "iknow@howstuffworks.com." Nomes como “howstuffworks.com” são facilmente lembrados pelas pessoas, mas não ajudam em nada as máquinas. Todas elas usam endereços de IP para se referirem umas às outras. A máquina a que as pessoas se referem como "www.hsw.com.br", por exemplo, possui o endereço IP 216.183.103.150. Toda vez que se usa um nome de domínio, os servidores de domínios da internet (DNS) estarão traduzindo os nomes de domínio legíveis em endereços de IP reconhecidos pelas máquinas. Durante um dia de navegação e envio de e-mails, os servidores de domínios podem ser acessados inúmeras vezes. Os servidores de domínios traduzem nomes de domínios em endereços de IP. Isto parece uma tarefa simples, e seria, exceto por cinco razões: Atualmente existem bilhões de endereços de IP em uso e a grande maioria das máquinas possui um nome legível associado. Alguns bilhões de requisições são feitas ao DNS todos os dias. Uma única pessoa pode fazer várias requisições em apenas um dia e existem muitas pessoas e máquinas usando a Internet diariamente. Nomes de domínio e endereços de IP podem mudar frequentemente (até mesmo diariamente). Novos nomes de domínio são criados todos os dias. Milhões de pessoas trabalham na mudança e no acréscimo de nomes de domínio e endereços de IP constantemente. O sistema DNS é uma base de dados, e nenhuma outra em todo o globo recebe tantas requisições. É a única, também, modificada por milhões de pessoas todos os dias. Isso é o que faz o sistema DNS tão singular. 38.10.1.2 Endereços IP Para manter todas as máquinas da Internet em perfeito funcionamento, cada uma delas é associada a um único endereço chamado endereço de IP. IP significa protocolo da Internet, e é um número de 32 bits normalmente apresentado como quatro “octetos” em um “número decimal pontuado.” Um endereço de IP comum se parece com esse: 216.183.103.150 Os quatro números em um endereço de IP são chamados de octetos por possuírem valores entre 0 e 255 (256 possibilidades por octeto). Toda máquina na Internet possui seu próprio endereço de IP (na verdade, tem ao menos UM endereço). Um servidor tem um endereço IP estático, que raramente muda. Uma máquina doméstica, que se conecta através de um modem, muitas vezes possui um endereço de IP designado pelo provedor no momento da conexão. Este endereço IP é único a cada sessão e pode mudar na próxima vez que houver uma conexão. Considerando isto, um provedor precisa apenas de um endereço IP para cada modem que dá suporte, ao invés de um para cada cliente (isso vale para ADSL ou conexões 3G também). Se você estiver usando um computador com sistema operacional Linux, você pode ver seu endereço IP por meio do seguinte comando: aluno@M2:~$ ifconfig eth0 Link encap:Ethernet Endereço de HW 84:2b:2b:7c:54:f5 inet end.: 172.18.80.251 Bcast:172.18.127.255 Masc:255.255.128.0 endereço inet6: fe80::862b:2bff:fe7c:54f5/64 Escopo:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1 pacotes RX:3634552 erros:0 descartados:145885 excesso:0 quadro:0 Pacotes TX:608253 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:1000 RX bytes:888269786 (888.2 MB) TX bytes:195176030 (195.1 MB) IRQ:21 Memória:f7fe0000-f8000000 No exemplo acima, a interface de rede eth0 (que é o dispositivo de hardware ou software que liga o computador fisicamente a Internet) possui o endereço IP 172.18.80.251. As demais informações descrevem outros parâmetros e características da interface de rede, e serão estudados em momento oportuno (mas não agora ;-). Para que as máquinas acessem a Internet, é necessário apenas um endereço de IP para se conectar a um servidor. Você poderia digitar em seu navegador, por exemplo, a URL http://200.135.190.28 e alcançaria a máquina que contém o servidor web do IFSC. Porém essa forma de endereçar servidores na Internet é pouco prática. Nomes de domínio são estritamente usados para a nossa conveniência. 38.10.1.3 Nomes de domínios Se precisássemos lembrar de todos os endereços de IP das páginas da Web que visitamos diariamente, ficaríamos malucos. Seres humanos não são bons em lembrar séries de números. No entanto, somos bons na lembrança de palavras, por isso usamos os nomes de domínios. Você possui, provavelmente, vários nomes de domínios guardados em sua cabeça. Como por exemplo: www.hsw.com.br - um nome típico www.google.com - o nome mais conhecido no mundo www.mit.edu - um nome EDU (educacionais) bastante popular encarta.msn.com - um servidor da Web que não começa com www www.bbc.co.uk - um nome que utiliza quatro partes em vez de três ftp.microsoft.com - um servidor FTP (em inglês) ao invés de um servidor da Web As partes COM, EDU e UK destes servidores são chamadas de domínios principais ou domínios de primeiro nível. Existem vários domínios principais, incluindo COM, EDU, GOV, MIL, NET, ORG e INT, assim como as singulares combinações de duas letras para cada país (em inglês). Em cada domínio principal existe uma enorme lista de domínios secundários. No domínio principal COM, por exemplo, tem-se: howstuffworks google msn microsoft ... e milhões de outros. Cada nome no domínio principal COM precisa ser único, mas podem existir réplicas entre os domínios. Por exemplo, howstuffworks.com e howstuffworks.org são duas máquinas completamente diferentes. No caso de bbc.co.uk, este é um domínio terciário. São possíveis até 127 níveis, no entanto, mais do que quatro são raros. A palavra mais à esquerda, como www ou encarta, é nome de hospedagem, que determina o nome de uma máquina específica (com um endereço de IP próprio) em um domínio. Um domínio concedido pode conter milhões de nomes de hospedagem desde que sejam únicos. Por causa desta determinação de todos os nomes em um domínio serem únicos, é necessário que uma entidade controle a lista destes servidores e garanta que nenhuma duplicação aconteça. O domínio COM, por exemplo, não pode conter dois nomes iguais e uma empresa chamada Network Solutions (em inglês) é a responsável por manter esta lista. Ao registrar um nome de domínio, o processo passa por um dos inúmeros registradores que trabalham na Network Solutions para adicionar nomes à lista. Ao mesmo tempo, é mantida uma base de dados chamada whois (em inglês) que contém informações sobre o proprietário e o servidor de cada domínio. Se você acessar o formulário whois (em inglês), encontrará informações acerca de qualquer domínio existente. Apesar de ser importante possuir uma autoridade central cuidando da base de dados referente aos nomes no domínio principal COM (e nos outros), você pode não querer centralizar a base de dados de todas as informações do domínio. A Microsoft, por exemplo, tem inúmeros endereços de IP e de nomes de hospedagens. Esta empresa quer manter seu próprio servidor de domínio pelo microsoft.com. Similarmente, a Grã-Bretanha quer administrar os domínios principais uk e a Austrália os domínios au, assim como nós brasileiros queremos administrar os domínios br. Por esta razão, o sistema DNS é um sistema partilhado. A Microsoft é completamente responsável pela manutenção do servidor microsoft.com: ela mantém as máquinas que implementam sua parte do sistema DNS, podendo mudar a base de dados de seu domínio sempre que necessitar, pois possui seus próprios servidores de domínio. Todo domínio possui um servidor em algum lugar, responsável por lidar com as requisições, onde há uma pessoa mantendo os registros deste DNS. Esta é uma das partes mais extraordinárias deste sistema: ele está completamente espalhado por todo o planeta em milhões de máquinas, administradas por milhões de pessoas e, ainda assim, se comporta como uma base de dados única e integrada. 38.10.1.4 Servidores DNS Servidores DNS fazem duas coisas o tempo todo: Aceitam solicitações de programas para converter nomes de domínios em endereços de IP. Aceitam solicitações de outros servidores para converter nomes de domínios em endereços de IP. Quando uma solicitação chega, o servidor pode exercer uma das quatro opções: Pode responder diretamente com um endereço de IP, por já conhecer previamente este endereço do domínio. Pode contatar outros servidores e tentar encontrar o endereço de IP para que foi solicitado, um processo que pode ser repetido várias vezes. Pode dizer: “eu não sei o endereço de IP para o domínio solicitado, mas aqui está o endereço de IP de um servidor que sabe mais do que eu.” Pode retornar uma mensagem de erro, pois o domínio solicitado é inválido ou inexistente. Ao digitar uma URL em seu navegador, o primeiro passo que este faz é converter o nome do domínio e da hospedagem em um endereço IP, para que o navegador solicite uma página da web à máquina que possui esse endereço de IP. Para fazer esta conversão, o navegador se comunica com um servidor DNS. Ao configurar seu computador para se conectar a Internet, você (ou o software instalado para se conectar ao seu provedor) precisa informar ao computador qual o servidor DNS que deve ser usado para a conversão de nomes de domínios em endereços de IP. Para ver qual o servidor DNS configurado em seu computador (assumindo que ele esteja com Linux), use o comando nslookup: aluno@M2:~$ nslookup www.ifsc.edu.br Server: 200.135.37.65 Address: 200.135.37.65#53 Non-authoritative answer: Name: www.ifsc.edu.br Address: 200.18.10.13 38.10.1.5 A estrutura das informações mantidas no DNS Como deve ter ficado claro na seção anterior, 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 (na seção anterior isso foi denominado hospedagem). 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 br é o domínio do topo da hierarquia ao qual mail.sj.ifsc.edu.br pertence. Já edu é um subdomíno de br, ifsc um subdomínio de edu, 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. Clientes buscam informação no DNS usando uma biblioteca de resolução (resolver library), que envia as consultas para um ou mais servidores de nomes e interpreta as respostas. (tirado do manual do BIND9) Ver também o livro sobre DNS e BIND da O'Reilly. Você pode consultar a IANA para conhecer as delegações dos top-level domains como o .br, por exemplo. A IANA é responsável por coordenar estas delegações em confirmidade com suas políticas. Consulte: top-level domains 38.10.1.6 Registros DNS Cada rótulo na hierarquia DNS possui um conjunto de informações associadas a si. Essas informações são guardas em registros de diferentes tipos, dependendo de seu significado e propósito. Cada consulta ao DNS retorna assim as informações do registro pedido associado ao rótulo. Por exemplo, para ver o registro de endereço IP associado a www.ifsc.edu.br pode-se executar o comando dig (o resultado teve alguns comentários removidos): tisemp@M1:~$ dig ifsc.edu.br ;; QUESTION SECTION: ;ifsc.edu.br. IN A ;; ANSWER SECTION: ifsc.edu.br. 3008 IN A 200.135.190.28 ;; AUTHORITY SECTION: ifsc.edu.br. 3060 IN NS ns1.ifsc.edu.br. ifsc.edu.br. 3060 IN NS ns2.ifsc.edu.br. ifsc.edu.br. 3060 IN NS adns1.pop-sc.rnp.br. ifsc.edu.br. 3060 IN NS adns2.pop-sc.rnp.br. ;; ADDITIONAL SECTION: adns1.pop-sc.rnp.br. 575397 IN A 200.237.192.10 adns1.pop-sc.rnp.br. 575397 IN AAAA 2801:80:a88:4000::10 adns2.pop-sc.rnp.br. 575397 IN A 200.135.14.10 adns2.pop-sc.rnp.br. 575397 IN AAAA 2001:12f0:200:a014::10 Cada uma das informações acima mostra um determinado registro e seu conteúdo, como descrito na tabela abaixo: Nome TTL Classe Registro Conteúdo do registro hendrix.sj.ifsc.edu.br. 3600 IN A 200.135.37.65 sj.ifsc.edu.br. 3600 IN NS hendrix.sj.ifsc.edu.br. sj.ifsc.edu.br. 3600 IN MX 10 hendrix.sj.ifsc.edu.br. Obs: TTL é o tempo de validade (em segundos) da informação retornada do servidor de nomes, e classe é o tipo de endereço (no caso IN equivale a endereços Internet). Os tipos de registros mais comuns são: Registro Descrição Exemplo A Endereço (Address) www.sj.ifsc.edu.br IN A 200.135.37.66 NS Servidor de nomes (Name Server) sj.ifsc.edu.br IN NS hendrix.sj.ifsc.edu.br. CNAME Apelido (Canonical Name) mail.sj.ifsc.edu.br IN CNAME hendrix.sj.ifsc.edu.br. MX Roteador de email (Mail Exchanger) sj.ifsc.edu.br IN MX mail.sj.ifsc.edu.br. SOA dados sobre o domínio (Start of Authority) sj.ifsc.edu.br IN SOA hendrix.sj.ifsc.edu.br. root.sj.ifsc.edu.br. 2009120102 1200 120 604800 3600 PTR Ponteiro para nome (Pointer) 65.37.135.200.in-addr.arpa IN PTR hendrix.sj.ifsc.edu.br. TXT Texto genérico (Text) sj.ifsc.edu.br IN TXT "v=spf1 a mx ~all" Uma zona assim é composta de um conjunto de registros com todas as informações dos domínios nela contidos. O conteúdo de uma zona, contendo o domínio example.com, pode ser visualizado abaixo: example.com 86400 IN SOA ns1.example.com. hostmaster.example.com. ( 2002022401 ; serial 10800 ; refresh 15 ; retry 604800 ; expire 10800 ; minimum ) IN NS ns1.example.com. IN NS ns2.smokeyjoe.com. IN MX 10 mail.another.com. IN TXT "v=spf1 mx -all" ns1 IN A 192.168.0.1 www IN A 192.168.0.2 ftp IN CNAME www.example.com. bill IN A 192.168.0.3 fred IN A 192.168.0.4 38.10.2 Atividade Usando o programa host ou dig, descubra os endereços IP associados aos seguintes nomes de domínios: mail.ifsc.edu.br www.sj.ifsc.edu.br www.google.com www.gmail.com www.amazon.co.uk www.gov.za www.sls.com.au Agora descubra quem é o servidor DNS responsável por cada um dos domínios dos nomes acima. Para isso consulte o valor do registro NS associado a esses domínios. Por exemplo, com o programa host isso pode ser feito assim: host -t ns ifsc.edu.br Descubra qual o servidor DNS usado pelo seu computador. Para isso é mais fácil usar o programa nslookup: # Use o nslookup para consultar o endereço IP de um nome qualquer ... nslookup sj.ifsc.edu.br 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. Portanto, execute o wireshark: sudo wireshark ... e em seguida faça uma consulta DNS qualquer. Com base nisso identifique o seguinte: Quantas mensagens são trocadas entre cliente e servidor DNS para cada consulta ? Que protocolo de transporte é usado ? E que port ? Qual o formato das mensagens DNS ? Elas são textuais como as mensagens HTTP ou SMTP ? Qual o tipo de registro DNS acessado em cada consulta ? Que informações estão contidas nas respostas DNS ? Há algo além do que foi pedido ? Qual o tamanho das mensagens DNS ? O serviço DNS fornece outras informações além do endereço IP associado a cada nome de domínio. Por exemplo, como ele se pode descobrir que host recebe emails em um determinado domínio. Isso é utilizado pelos MTA mundo afora para entregarem emails para seus destinatários (lembre que isso se faz com o protocolo SMTP). Para descobrir essa informação, deve-se consultar o registro MX de um domínio. Por exemplo: host -t mx ifsc.edu.br Descubra quem é o servidor que recebe emails nos seguintes domínios: gmail.com hotmail.com uol.com.br ufsc.br Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim: dig -x 200.180.10.13 ... 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. Como explicado durante a aula, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões ?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado ? Descubra quem são os servidores raiz (topo de hierarquia DNS): host -t ns . Escolha um dos servidores listados, e use-o para fazer as consultas. Por exemplo: host -v -t a www.sj.ifsc.edu.br. j.root-servers.net. ... e observe a seção ;; AUTHORITY SECTION:. Ele contém a listagem de servidores DNS que podem atender sua consulta. Continue fazendo as consultas aos servidores DNS listados, até conseguir traduzir o nome requisitado. Quantos servidores DNS foi necessário consultar no total ? Repita esse exercício para os seguintes nomes de domínio: www.bbc.co.uk www.amazon.com www.thepiratebay.org www.reeec.illinois.edu www.inm.ras.ru 38.11 10/10/17: Avaliação 1 Arquitetura Internet (Cap. 1 Kurose); Camada de Aplicação (Cap. 2 Kurose). Laboratórios e Listas de exercícios. Local: Sala 02 horário: 20h30m 38.12 17/10/17: Substituição - Aula ELI 11102 (Prof. Nilton) Esta aula será utilizada pelo Prof. Nilton para os alunos que cursam a disciplina ELI 11102. Participação na Latinoware 2017 38.13 24/10/17: Camada de Transporte Vista de prova - Camada de Aplicação; Introdução: serviços da camada de Transporte; Resolução lista de exercícios 4 38.14 31/10/17: Camada de Transporte (Lab. Programação) Multiplexação / Demultiplexação Protocolos Dutados: Volta-N e Retransmissão Seletiva Controle de Fluxo, congestionamento; Resolução de Exercícios 38.15 07/11/17: Camada de Transporte (Lab. Programação) As atividades de hoje buscarão mostrar as características básicas de comunicações com protocolos de transporte. 38.15.1 Aplicações e protocolos de transporte Faça uma rápida pesquisa e descubra que protocolos de transporte (e que ports) são usados por estas aplicações: SSH FTP BitTorrent emule WINS Compartilhamento de arquivos do Windows Windows Terminal Service NFS Openvpn RADIUS DHCP SNMP NTP LDAP Mysql Postgresql Oracle RDBMS Syslog CUPS Que protocolo de transporte predomina nesse conjunto ? 38.15.2 Tipos de protocolos de transporte: TCP x UDP Nestes experimentos, serão evidenciadas diferenças entre os protocolos TCP e UDP. 38.15.2.1 Experimento 1 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 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 ? Abra um terminal e execute o seguinte comando para fazer o download de um arquivo a ser usado no experimento: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso Observe o tamanho do arquivo transferido ... ele deve ter exatamente 832569344 bytes (cerca de 832 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. A primeira transferência será feita usando o protocolo TCP da seguinte forma: No computador receptor execute: nc -l 5555 > arquivo No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): time nc 192.168.1.X 5555 < ubuntu.iso 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: No computador receptor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x receptor). No computador receptor execute: ./receptor 5555 > arquivo No computador transmissor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x transmissor). No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): ./transmissor 192.168.1.X 5555 < ubuntu.iso Quando completar a transferência, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original ? E quanto tempo levou para transmiti-lo ? Compare as transferências feitas com TCP e UDP. O que eles têm em comum ? Que diferenças lhe pareceram mais pronunciadas ? Como isso deve afetar as aplicações que usam esses protocolos ? 38.15.2.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, como mostrado na figura abaixo: Abra um terminal em seu computador, e nele execute este comando: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso 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á se logar em um dos computadores do laboratório e 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 ? Finalmente, o professor irá repetir a transferência porém com mais dois 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: Abra dois terminais. Em um deles execute este comando: watch -n 1 ls -l arquivo ... e no outro execute: ./receptor 5555 > arquivo Como se comparam as transferências usando TCP e UDP ? 38.16 14/11/17: Avaliação de Camada de Transporte Correção da lista de Execícios V; Avaliação da Camada de Transporte; 38.17 21/11/17: Camada de Rede: Introdução Roteamento e encaminhamento; Algoritmos Estado de Enlace e Vetor de Distâncias; Roteamento Hierárquico. 38.18 28/11/17: Camada de Rede Endereçamento IP; Exercícios sobre Endereçamento IPv4; 38.19 05/12/17: Camada de Rede Exercícios Segmentação de Redes 38.20 12/12/17: Avaliação de Camada de Rede Avaliação Camada de Rede Sala 02 - 19h 38.21 19/12/17: Encerramento da disciplina

Semestre 2017-1 - Prof. Tiago Semprebom

39 Professor Professor: Tiago Semprebom Email: tisemp@ifsc.edu.br Atendimento paralelo: 5a feira 17:30h - 18:30 h (Lab. de Desenvolvimento de Tele II) Endereço web do grupo: http://groups.google.com/group/ifsc_res Endereço de e-mail da disciplina: ifsc_res@googlegroups.com 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. O não cumprimento desse procedimento implica a impossibilidade de fazer a recuperação, e assim a reprovação na disciplina. 39.1 Plano de Ensino 40 Notas Aluno A1 A2 A3 Rel. Tec. Final 162001443-2 2.5 (6.2) 6.5 9.0 OK X 141001095-3 3.0 (2.0) 0.0 (2.0) 1.0 (1.0) OK X 162001423-8 3.5 5.0 X OK X 162005091-9 8.8 8.2 10.0 OK X 162001092-5 7.5 6.5 9.1 OK X 161006242-6 7.2 9.2 8.7 OK X 162000998-6 7.0 6.0 8.0 OK X 162001012-7 3.7 5.5 7.0 OK X 162002311-3 3.5 (7.0) 7.0 9.5 OK X 162001005-4 8.9 9.0 10.0 OK X F: faltou (X): conceito da recuperação negrito: com direito a recuperação 41 Curiosidades Breve histórico sobre o surgimento das redes de computadores e a Internet Vídeo sobre surgimento da Internet Vídeo sobre o funcionamento das fibras ópticas Vídeo sobre fibra óptica Mapas de rede dorsais (Backbones) Mapa da rede Ipê (Internet acadêmica pública no Brasil) POP SC (ponto de presença de SC) Telex O Ciberespaço e as Redes de Computadores na Construção de Novo Conhecimento Uma história das Redes de Computadores Breve História da Internet Uma representação artística das interligações na Internet 42 Materiais de aula 42.1 Slides Arquivo:Slides-kurose-cap1.pdf Arquivo:Slides-kurose-cap2.pdf Arquivo:RCO-semprebom-cap3.pdf Arquivo:RCO-semprebom-cap4.pdf 42.2 Listas de exercícios Lista de exercícios 1 Lista de exercícios 2 Lista de exercícios 3 Lista de exercícios 4 Lista de exercícios 5 Lista de exercícios 6 Lista de exercícios 7 Lista de exercícios 8 Lista de exercícios 9 42.3 Apostilas Apostila de Redes de Computadores do Prof. Evandro Cantú 43 Aulas 43.1 09/02/17: Apresentação da disciplina Apresentação da disciplina, plano de aula, laboratórios e métodos de avaliação. Revisão de conceitos do Projeto Integrador I Introdução a Redes de Computadores [slides] 43.2 16/02/17: Introdução a Redes de Computadores Serviço orientado à conexão (TCP). Serviço não orientado à conexão (UDP). Comutação de circuitos vs Comutação de pacotes. FDMA e TDMA. Resolução de exercícios (Lista 1) 43.3 23/02/17: Comutação por Circuitos, Comutação de Pacotes, Lab01: Ferramentas básicas de redes (Lab. Redes II) Introdução a Redes de Computadores [slides] Nesta atividade serão vistos algumas ferramentas utilizadas para obter informações relacionadas às configurações de uma rede de computadores. Roteiro 1 (ping, ifconfig, traceroute) Roteiro Rápido do SS - Socket Statistics 43.4 02/03/17: Arquitetura Internet Continuação Lab. I (ferramentas básicas de configuração de redes) Redes de acesso e meio físico Atrasos em redes de comutação de pacotes Arquitetura em Camadas Resolução de Exercício (Lista I) 43.5 09/03/17: Introdução à Redes de Computadores Redes de acesso e meio físico Atrasos em redes de comutação de pacotes 43.6 16/03/17: Introdução à Redes de Computadores Correção lista de exercício I Atividade em Laboratório (Laboratório Redes II) configuração básica interface rede Configuração estática interface rede 43.7 23/03/17: Introdução à Redes de Computadores Arquitetura em Camadas Atividade em Laboratório (Laboratório Redes II) Captura de pacotes na rede (Wireshark) 43.8 30/03/17: Camada de Aplicação Atividade em Laboratório (Laboratório Redes II) Captura de pacotes na rede (Wireshark) Roteiro TCPDump Wireshark e manuais Números de portas (IANA) Teste ferramenta Iperf Teste HTTP V2 - simulador 43.9 06/04/17: Camada de Aplicação A camada de aplicação (ver estes [slides) Lista de Exercícios: II e III 43.10 13/04/17: Camada de Aplicação (Lab. Redes II) 43.10.1 DNS: Domain Name System 43.10.1.1 Uma breve descrição sobre DNS Se você gasta algum tempo na internet mandando e-mails ou navegando pela web, está utilizando servidores de domínios sem mesmo perceber. O sistema DNS (Domain Name System) forma uma das maiores, mais ativas e mais distribuídas bases de dados do planeta. Sem o DNS, a internet acabaria rapidamente. Quando você navega na internet ou manda uma mensagem de e-mail, você estará utilizando um nome de domínio. Por exemplo, a URL "http://www.hsw.com.br" contém o nome de domínio howstuffworks.com. Assim como o endereço de e-mail "iknow@howstuffworks.com." Nomes como “howstuffworks.com” são facilmente lembrados pelas pessoas, mas não ajudam em nada as máquinas. Todas elas usam endereços de IP para se referirem umas às outras. A máquina a que as pessoas se referem como "www.hsw.com.br", por exemplo, possui o endereço IP 216.183.103.150. Toda vez que se usa um nome de domínio, os servidores de domínios da internet (DNS) estarão traduzindo os nomes de domínio legíveis em endereços de IP reconhecidos pelas máquinas. Durante um dia de navegação e envio de e-mails, os servidores de domínios podem ser acessados inúmeras vezes. Os servidores de domínios traduzem nomes de domínios em endereços de IP. Isto parece uma tarefa simples, e seria, exceto por cinco razões: Atualmente existem bilhões de endereços de IP em uso e a grande maioria das máquinas possui um nome legível associado. Alguns bilhões de requisições são feitas ao DNS todos os dias. Uma única pessoa pode fazer várias requisições em apenas um dia e existem muitas pessoas e máquinas usando a Internet diariamente. Nomes de domínio e endereços de IP podem mudar frequentemente (até mesmo diariamente). Novos nomes de domínio são criados todos os dias. Milhões de pessoas trabalham na mudança e no acréscimo de nomes de domínio e endereços de IP constantemente. O sistema DNS é uma base de dados, e nenhuma outra em todo o globo recebe tantas requisições. É a única, também, modificada por milhões de pessoas todos os dias. Isso é o que faz o sistema DNS tão singular. 43.10.1.2 Endereços IP Para manter todas as máquinas da Internet em perfeito funcionamento, cada uma delas é associada a um único endereço chamado endereço de IP. IP significa protocolo da Internet, e é um número de 32 bits normalmente apresentado como quatro “octetos” em um “número decimal pontuado.” Um endereço de IP comum se parece com esse: 216.183.103.150 Os quatro números em um endereço de IP são chamados de octetos por possuírem valores entre 0 e 255 (256 possibilidades por octeto). Toda máquina na Internet possui seu próprio endereço de IP (na verdade, tem ao menos UM endereço). Um servidor tem um endereço IP estático, que raramente muda. Uma máquina doméstica, que se conecta através de um modem, muitas vezes possui um endereço de IP designado pelo provedor no momento da conexão. Este endereço IP é único a cada sessão e pode mudar na próxima vez que houver uma conexão. Considerando isto, um provedor precisa apenas de um endereço IP para cada modem que dá suporte, ao invés de um para cada cliente (isso vale para ADSL ou conexões 3G também). Se você estiver usando um computador com sistema operacional Linux, você pode ver seu endereço IP por meio do seguinte comando: aluno@M2:~$ ifconfig eth0 Link encap:Ethernet Endereço de HW 84:2b:2b:7c:54:f5 inet end.: 172.18.80.251 Bcast:172.18.127.255 Masc:255.255.128.0 endereço inet6: fe80::862b:2bff:fe7c:54f5/64 Escopo:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1 pacotes RX:3634552 erros:0 descartados:145885 excesso:0 quadro:0 Pacotes TX:608253 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:1000 RX bytes:888269786 (888.2 MB) TX bytes:195176030 (195.1 MB) IRQ:21 Memória:f7fe0000-f8000000 No exemplo acima, a interface de rede eth0 (que é o dispositivo de hardware ou software que liga o computador fisicamente a Internet) possui o endereço IP 172.18.80.251. As demais informações descrevem outros parâmetros e características da interface de rede, e serão estudados em momento oportuno (mas não agora ;-). Para que as máquinas acessem a Internet, é necessário apenas um endereço de IP para se conectar a um servidor. Você poderia digitar em seu navegador, por exemplo, a URL http://200.135.190.28 e alcançaria a máquina que contém o servidor web do IFSC. Porém essa forma de endereçar servidores na Internet é pouco prática. Nomes de domínio são estritamente usados para a nossa conveniência. 43.10.1.3 Nomes de domínios Se precisássemos lembrar de todos os endereços de IP das páginas da Web que visitamos diariamente, ficaríamos malucos. Seres humanos não são bons em lembrar séries de números. No entanto, somos bons na lembrança de palavras, por isso usamos os nomes de domínios. Você possui, provavelmente, vários nomes de domínios guardados em sua cabeça. Como por exemplo: www.hsw.com.br - um nome típico www.google.com - o nome mais conhecido no mundo www.mit.edu - um nome EDU (educacionais) bastante popular encarta.msn.com - um servidor da Web que não começa com www www.bbc.co.uk - um nome que utiliza quatro partes em vez de três ftp.microsoft.com - um servidor FTP (em inglês) ao invés de um servidor da Web As partes COM, EDU e UK destes servidores são chamadas de domínios principais ou domínios de primeiro nível. Existem vários domínios principais, incluindo COM, EDU, GOV, MIL, NET, ORG e INT, assim como as singulares combinações de duas letras para cada país (em inglês). Em cada domínio principal existe uma enorme lista de domínios secundários. No domínio principal COM, por exemplo, tem-se: howstuffworks google msn microsoft ... e milhões de outros. Cada nome no domínio principal COM precisa ser único, mas podem existir réplicas entre os domínios. Por exemplo, howstuffworks.com e howstuffworks.org são duas máquinas completamente diferentes. No caso de bbc.co.uk, este é um domínio terciário. São possíveis até 127 níveis, no entanto, mais do que quatro são raros. A palavra mais à esquerda, como www ou encarta, é nome de hospedagem, que determina o nome de uma máquina específica (com um endereço de IP próprio) em um domínio. Um domínio concedido pode conter milhões de nomes de hospedagem desde que sejam únicos. Por causa desta determinação de todos os nomes em um domínio serem únicos, é necessário que uma entidade controle a lista destes servidores e garanta que nenhuma duplicação aconteça. O domínio COM, por exemplo, não pode conter dois nomes iguais e uma empresa chamada Network Solutions (em inglês) é a responsável por manter esta lista. Ao registrar um nome de domínio, o processo passa por um dos inúmeros registradores que trabalham na Network Solutions para adicionar nomes à lista. Ao mesmo tempo, é mantida uma base de dados chamada whois (em inglês) que contém informações sobre o proprietário e o servidor de cada domínio. Se você acessar o formulário whois (em inglês), encontrará informações acerca de qualquer domínio existente. Apesar de ser importante possuir uma autoridade central cuidando da base de dados referente aos nomes no domínio principal COM (e nos outros), você pode não querer centralizar a base de dados de todas as informações do domínio. A Microsoft, por exemplo, tem inúmeros endereços de IP e de nomes de hospedagens. Esta empresa quer manter seu próprio servidor de domínio pelo microsoft.com. Similarmente, a Grã-Bretanha quer administrar os domínios principais uk e a Austrália os domínios au, assim como nós brasileiros queremos administrar os domínios br. Por esta razão, o sistema DNS é um sistema partilhado. A Microsoft é completamente responsável pela manutenção do servidor microsoft.com: ela mantém as máquinas que implementam sua parte do sistema DNS, podendo mudar a base de dados de seu domínio sempre que necessitar, pois possui seus próprios servidores de domínio. Todo domínio possui um servidor em algum lugar, responsável por lidar com as requisições, onde há uma pessoa mantendo os registros deste DNS. Esta é uma das partes mais extraordinárias deste sistema: ele está completamente espalhado por todo o planeta em milhões de máquinas, administradas por milhões de pessoas e, ainda assim, se comporta como uma base de dados única e integrada. 43.10.1.4 Servidores DNS Servidores DNS fazem duas coisas o tempo todo: Aceitam solicitações de programas para converter nomes de domínios em endereços de IP. Aceitam solicitações de outros servidores para converter nomes de domínios em endereços de IP. Quando uma solicitação chega, o servidor pode exercer uma das quatro opções: Pode responder diretamente com um endereço de IP, por já conhecer previamente este endereço do domínio. Pode contatar outros servidores e tentar encontrar o endereço de IP para que foi solicitado, um processo que pode ser repetido várias vezes. Pode dizer: “eu não sei o endereço de IP para o domínio solicitado, mas aqui está o endereço de IP de um servidor que sabe mais do que eu.” Pode retornar uma mensagem de erro, pois o domínio solicitado é inválido ou inexistente. Ao digitar uma URL em seu navegador, o primeiro passo que este faz é converter o nome do domínio e da hospedagem em um endereço IP, para que o navegador solicite uma página da web à máquina que possui esse endereço de IP. Para fazer esta conversão, o navegador se comunica com um servidor DNS. Ao configurar seu computador para se conectar a Internet, você (ou o software instalado para se conectar ao seu provedor) precisa informar ao computador qual o servidor DNS que deve ser usado para a conversão de nomes de domínios em endereços de IP. Para ver qual o servidor DNS configurado em seu computador (assumindo que ele esteja com Linux), use o comando nslookup: aluno@M2:~$ nslookup www.ifsc.edu.br Server: 200.135.37.65 Address: 200.135.37.65#53 Non-authoritative answer: Name: www.ifsc.edu.br Address: 200.18.10.13 43.10.1.5 A estrutura das informações mantidas no DNS Como deve ter ficado claro na seção anterior, 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 (na seção anterior isso foi denominado hospedagem). 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 br é o domínio do topo da hierarquia ao qual mail.sj.ifsc.edu.br pertence. Já edu é um subdomíno de br, ifsc um subdomínio de edu, 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. Clientes buscam informação no DNS usando uma biblioteca de resolução (resolver library), que envia as consultas para um ou mais servidores de nomes e interpreta as respostas. (tirado do manual do BIND9) Ver também o livro sobre DNS e BIND da O'Reilly. Você pode consultar a IANA para conhecer as delegações dos top-level domains como o .br, por exemplo. A IANA é responsável por coordenar estas delegações em confirmidade com suas políticas. Consulte: top-level domains 43.10.1.6 Registros DNS Cada rótulo na hierarquia DNS possui um conjunto de informações associadas a si. Essas informações são guardas em registros de diferentes tipos, dependendo de seu significado e propósito. Cada consulta ao DNS retorna assim as informações do registro pedido associado ao rótulo. Por exemplo, para ver o registro de endereço IP associado a www.ifsc.edu.br pode-se executar o comando dig (o resultado teve alguns comentários removidos): tisemp@M1:~$ dig ifsc.edu.br ;; QUESTION SECTION: ;ifsc.edu.br. IN A ;; ANSWER SECTION: ifsc.edu.br. 3008 IN A 200.135.190.28 ;; AUTHORITY SECTION: ifsc.edu.br. 3060 IN NS ns1.ifsc.edu.br. ifsc.edu.br. 3060 IN NS ns2.ifsc.edu.br. ifsc.edu.br. 3060 IN NS adns1.pop-sc.rnp.br. ifsc.edu.br. 3060 IN NS adns2.pop-sc.rnp.br. ;; ADDITIONAL SECTION: adns1.pop-sc.rnp.br. 575397 IN A 200.237.192.10 adns1.pop-sc.rnp.br. 575397 IN AAAA 2801:80:a88:4000::10 adns2.pop-sc.rnp.br. 575397 IN A 200.135.14.10 adns2.pop-sc.rnp.br. 575397 IN AAAA 2001:12f0:200:a014::10 Cada uma das informações acima mostra um determinado registro e seu conteúdo, como descrito na tabela abaixo: Nome TTL Classe Registro Conteúdo do registro hendrix.sj.ifsc.edu.br. 3600 IN A 200.135.37.65 sj.ifsc.edu.br. 3600 IN NS hendrix.sj.ifsc.edu.br. sj.ifsc.edu.br. 3600 IN MX 10 hendrix.sj.ifsc.edu.br. Obs: TTL é o tempo de validade (em segundos) da informação retornada do servidor de nomes, e classe é o tipo de endereço (no caso IN equivale a endereços Internet). Os tipos de registros mais comuns são: Registro Descrição Exemplo A Endereço (Address) www.sj.ifsc.edu.br IN A 200.135.37.66 NS Servidor de nomes (Name Server) sj.ifsc.edu.br IN NS hendrix.sj.ifsc.edu.br. CNAME Apelido (Canonical Name) mail.sj.ifsc.edu.br IN CNAME hendrix.sj.ifsc.edu.br. MX Roteador de email (Mail Exchanger) sj.ifsc.edu.br IN MX mail.sj.ifsc.edu.br. SOA dados sobre o domínio (Start of Authority) sj.ifsc.edu.br IN SOA hendrix.sj.ifsc.edu.br. root.sj.ifsc.edu.br. 2009120102 1200 120 604800 3600 PTR Ponteiro para nome (Pointer) 65.37.135.200.in-addr.arpa IN PTR hendrix.sj.ifsc.edu.br. TXT Texto genérico (Text) sj.ifsc.edu.br IN TXT "v=spf1 a mx ~all" Uma zona assim é composta de um conjunto de registros com todas as informações dos domínios nela contidos. O conteúdo de uma zona, contendo o domínio example.com, pode ser visualizado abaixo: example.com 86400 IN SOA ns1.example.com. hostmaster.example.com. ( 2002022401 ; serial 10800 ; refresh 15 ; retry 604800 ; expire 10800 ; minimum ) IN NS ns1.example.com. IN NS ns2.smokeyjoe.com. IN MX 10 mail.another.com. IN TXT "v=spf1 mx -all" ns1 IN A 192.168.0.1 www IN A 192.168.0.2 ftp IN CNAME www.example.com. bill IN A 192.168.0.3 fred IN A 192.168.0.4 43.10.2 Atividade Usando o programa host ou dig, descubra os endereços IP associados aos seguintes nomes de domínios: mail.ifsc.edu.br www.sj.ifsc.edu.br www.google.com www.gmail.com www.amazon.co.uk www.gov.za www.sls.com.au Agora descubra quem é o servidor DNS responsável por cada um dos domínios dos nomes acima. Para isso consulte o valor do registro NS associado a esses domínios. Por exemplo, com o programa host isso pode ser feito assim: host -t ns ifsc.edu.br Descubra qual o servidor DNS usado pelo seu computador. Para isso é mais fácil usar o programa nslookup: # Use o nslookup para consultar o endereço IP de um nome qualquer ... nslookup sj.ifsc.edu.br 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. Portanto, execute o wireshark: sudo wireshark ... e em seguida faça uma consulta DNS qualquer. Com base nisso identifique o seguinte: Quantas mensagens são trocadas entre cliente e servidor DNS para cada consulta ? Que protocolo de transporte é usado ? E que port ? Qual o formato das mensagens DNS ? Elas são textuais como as mensagens HTTP ou SMTP ? Qual o tipo de registro DNS acessado em cada consulta ? Que informações estão contidas nas respostas DNS ? Há algo além do que foi pedido ? Qual o tamanho das mensagens DNS ? O serviço DNS fornece outras informações além do endereço IP associado a cada nome de domínio. Por exemplo, como ele se pode descobrir que host recebe emails em um determinado domínio. Isso é utilizado pelos MTA mundo afora para entregarem emails para seus destinatários (lembre que isso se faz com o protocolo SMTP). Para descobrir essa informação, deve-se consultar o registro MX de um domínio. Por exemplo: host -t mx ifsc.edu.br Descubra quem é o servidor que recebe emails nos seguintes domínios: gmail.com hotmail.com uol.com.br ufsc.br Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim: dig -x 200.180.10.13 ... 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. Como explicado durante a aula, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões ?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado ? Descubra quem são os servidores raiz (topo de hierarquia DNS): host -t ns . Escolha um dos servidores listados, e use-o para fazer as consultas. Por exemplo: host -v -t a www.sj.ifsc.edu.br. j.root-servers.net. ... e observe a seção ;; AUTHORITY SECTION:. Ele contém a listagem de servidores DNS que podem atender sua consulta. Continue fazendo as consultas aos servidores DNS listados, até conseguir traduzir o nome requisitado. Quantos servidores DNS foi necessário consultar no total ? Repita esse exercício para os seguintes nomes de domínio: www.bbc.co.uk www.amazon.com www.thepiratebay.org www.reeec.illinois.edu www.inm.ras.ru 43.11 20/04/17: Avaliação 1 Arquitetura Internet (Cap. 1 Kurose); Camada de Aplicação (Cap. 2 Kurose). Laboratórios e Listas de exercícios. Local: Sala 02 horário: 20h30m 43.12 27/04/17: Camada de Transporte Correção da Avaliação 1 Multiplexação / Demultiplexação 43.13 04/05/17: Camada de Transporte Protocolos Dutados: Volta-N e Retransmissão Seletiva Controle de Fluxo, congestionamento; Resolução de Exercícios 43.14 11/05/17: Camada de Transporte (Lab. Redes II) As atividades de hoje buscarão mostrar as características básicas de comunicações com protocolos de transporte. 43.14.1 Aplicações e protocolos de transporte Faça uma rápida pesquisa e descubra que protocolos de transporte (e que ports) são usados por estas aplicações: SSH FTP BitTorrent emule WINS Compartilhamento de arquivos do Windows Windows Terminal Service NFS Openvpn RADIUS DHCP SNMP NTP LDAP Mysql Postgresql Oracle RDBMS Syslog CUPS Que protocolo de transporte predomina nesse conjunto ? 43.14.2 Tipos de protocolos de transporte: TCP x UDP Nestes experimentos, serão evidenciadas diferenças entre os protocolos TCP e UDP. 43.14.2.1 Experimento 1 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 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 ? Abra um terminal e execute o seguinte comando para fazer o download de um arquivo a ser usado no experimento: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso Observe o tamanho do arquivo transferido ... ele deve ter exatamente 832569344 bytes (cerca de 832 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. A primeira transferência será feita usando o protocolo TCP da seguinte forma: No computador receptor execute: nc -l 5555 > arquivo No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): time nc 192.168.1.X 5555 < ubuntu.iso 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: No computador receptor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x receptor). No computador receptor execute: ./receptor 5555 > arquivo No computador transmissor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x transmissor). No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): ./transmissor 192.168.1.X 5555 < ubuntu.iso Quando completar a transferência, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original ? E quanto tempo levou para transmiti-lo ? Compare as transferências feitas com TCP e UDP. O que eles têm em comum ? Que diferenças lhe pareceram mais pronunciadas ? Como isso deve afetar as aplicações que usam esses protocolos ? 43.14.2.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, como mostrado na figura abaixo: Abra um terminal em seu computador, e nele execute este comando: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso 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á se logar em um dos computadores do laboratório e 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 ? Finalmente, o professor irá repetir a transferência porém com mais dois 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: Abra dois terminais. Em um deles execute este comando: watch -n 1 ls -l arquivo ... e no outro execute: ./receptor 5555 > arquivo Como se comparam as transferências usando TCP e UDP ? 43.15 18/05/17: Avaliação de Camada de Transporte Correção da lista de Execícios V; Avaliação da Camada de Transporte; 43.16 25/05/17: Camada de Rede Vista da Avaliação da Camada de Transporte (A2); Camada de Rede: Introdução; Camada de Rede: Roteamento Intra-SA e Inter-SA; Lista de exercícios. 43.17 01/06/17: Camada de Rede Endereçamento IPv4; Listas de Exercícios. Simulador IPkit 43.18 08/06/17: Camada de Rede Exercícios - Segmentação de rede 43.19 15/06/17: Feriado nacional - Corpus Christi 43.20 22/06/17: Avaliação Camada de Rede Correção lista de exercícios (Revisão para Avaliação) Avaliação da Camada de Rede 43.21 29/06/17: Encerramento da disciplina Recuperações: Av1 , Av2 e Av3

Semestre 2016-2 - Prof. Tiago Semprebom

44 TecTel: Redes de Computadores - 2016-2 - Prof. Tiago Semprebom 45 Professor Professor: Tiago Semprebom Email: tisemp@ifsc.edu.br Atendimento paralelo: 5a feira 17:30h - 18:30 h (Lab. de Desenvolvimento de Tele II) Endereço web do grupo: http://groups.google.com/group/ifsc_res Endereço de e-mail da disciplina: ifsc_res@googlegroups.com 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. O não cumprimento desse procedimento implica a impossibilidade de fazer a recuperação, e assim a reprovação na disciplina. 45.1 Plano de Ensino 46 Notas Matrícula A1 A2 A3 Rel. Tec. Final Álvaro Medeiros 5,0 (3,0) 4,0 (3,0) 2,5 (7,0) OK X Cristian Jose da Silva 0,0 0,0 0,0 NOK 0,0 Eduardo Aparecido 7,4 8,5 5,0 (9,8) OK X Fernando Lino 8,6 7,3 2,1 (5,0) OK X Fernando Kriger 8,2 8,5 9,7 OK X Isarael Natividade 7,8 7,0 6,0 OK X Jailson Silveira 6,0 7,0 2,5 (5,0) OK X Jeferson Lima 6,7 8,3 5,0 (8,5) OK X Katia Buss 7,0 9,0 9,0 OK X Lucas Brasil 4,8 (5,0) 7,0 2,0 (5,0) OK X Maicom Rocha 6,0 7,2 9,8 OK X Marcio Ferreira Lopes 6,0 7,2 7,5 OK X F: faltou (X): conceito da recuperação negrito: com direito a recuperação 47 Curiosidades Breve histórico sobre o surgimento das redes de computadores e a Internet Vídeo sobre surgimento da Internet Vídeo sobre o funcionamento das fibras ópticas Vídeo sobre fibra óptica Mapas de rede dorsais (Backbones) Mapa da rede Ipê (Internet acadêmica pública no Brasil) POP SC (ponto de presença de SC) Telex O Ciberespaço e as Redes de Computadores na Construção de Novo Conhecimento Uma história das Redes de Computadores Breve História da Internet Uma representação artística das interligações na Internet 48 Materiais de aula Transparências utilizadas durante as aulas Capítulo 1 Capítulo 2 Capítulo 3 Capítulo 4 Capítulo 5 48.1 Listas de exercícios Lista de exercícios 1 Lista de exercícios 2 Lista de exercícios 3 Lista de exercícios 4 Lista de exercícios 5 Lista de exercícios 6 Lista de exercícios 7 Lista de exercícios 8 Lista de exercícios 9 48.2 Apostilas Apostila de Redes de Computadores do Prof. Evandro Cantú 49 Aulas 49.1 11/08/16: Apresentação da disciplina Apresentação da disciplina, plano de aula, laboratórios e métodos de avaliação. Revisão de conceitos do Projeto Integrador I Introdução a Redes de Computadores [slides] 49.2 18/08/16: Introdução à Redes de Computadores Serviço orientado à conexão (TCP). Serviço não orientado à conexão (UDP). Comutação de circuitos vs Comutação de pacotes. FDMA e TDMA. Resolução de exercícios (Lista 1) 49.3 25/08/16: Comutação por Circuitos, Comutação de Pacotes, Lab01: Ferramentas básicas de redes Introdução a Redes de Computadores [slides] Nesta atividade serão vistos algumas ferramentas utilizadas para obter informações relacionadas às configurações de uma rede de computadores. Roteiro 1 (ping, ifconfig, traceroute) Roteiro Rápido do SS - Socket Statistics 49.4 01/09/16: Introdução a Redes de Computadores Redes de acesso e meio físico Atrasos em redes de comutação de pacotes Arquitetura em Camadas Atividade em Laboratório (Laboratório de Programação) Captura de pacotes na rede (Wireshark) Roteiro TCPDump Wireshark e manuais Números de portas (IANA) 49.5 08/09/16: Camada de Aplicação A camada de aplicação (ver estes [slides) Lista de Exercícios: II e III 49.6 15/09/16: Camada de Aplicação Camada de Aplicação (ver estes [slides]) Protocolos SMTP, IMAP, POP3, FTP e DNS. Ver Capítulo 27 do livro Comunicação de Dados e Redes de Computadores, 4a ed., de Behrouz Forouzan. Na arquitetura de redes da Internet, são as aplicações que se comunicam, gerando dados no transmissor e consumindo-os no receptor. Aplicações residem em equipamentos de rede, e se comunicam através da rede usando os serviços das camadas inferiores Aplicações são processos que se comunicam através da rede (lembre que processos são programas em execução). Exemplos de aplicações são navegadores web (Firefox, Chrome) e bate-papo (Skype, GTalk). A comunicação pode ser feita de diferentes formas, de acordo com o modelo de comunicação adotado pela aplicação em questão. O modelo de comunicação define o papel de cada participante da comunicação, e por consequência acaba determinando como a comunicação acontece (quem a inicia, quando se transmitem e recebem mensagens). Três modelos conhecidos são: Cliente-Servidor: um participante é o cliente, e o outro o servidor. O cliente inicia a comunicação, ao enviar uma mensagem ao servidor pedindo algum serviço. Cabe ao servidor responder aos pedidos dos clientes. Este é o modelo mais comum de se encontrar em aplicações, tais como correio eletrônico, WWW, bancos de dados, compartilhamento de arquivos e outros. Peer-to-Peer (P2P): cada participante pode ser tanto cliente quanto servidor, assim qualquer um pode iniciar uma comunicação. Tornou-se popular com aplicações como compartilhamento de arquivos (ex: BitTorrent, eDonkey) e sistemas de chamadas VoIP. Publisher/Subscriber: neste modelo existem os publicadores de conteúdo (publishers) e os assinantes ou interessados (subscribers). Os assinantes registram seus interesses por demais tipos de dados (isso é, assinam canais de dados). Os publicadores eventualmente divulgam dados, que são distribuídos aos assinantes. Não é comum de ser encontrado em aplicações, porém é o modelo usado para detecção de presença em aplicações de conversa on-line (Skype, Gtalk). Cada aplicação usa diretamente os serviços da camada de transporte, e indiretamente os de camadas inferiores. Assim, para uma aplicação é a camada de transporte que envia e recebe suas mensagens. Como visto na aula passada, um serviço importante da camada de transporte é classificar e separar os pacotes recebidos de acordo com a aplicação que deve recebê-los, e para isso usa-se um número chamado de porta. O número de porta pode ser entendido como um endereçador de aplicações dentro de um mesmo host. Vimos também que a camada de transporte na Internet apresenta dois protocolos, e ambos usam números de porta para separar os pacotes de acordo com a comunicação que os contém: TCP: usado por aplicações quando há necessidade de ter certeza de que os dados foram recebidos. Esse protocolo faz retransmissões automáticas no caso de perdas de mensagens. Para estabelecer a comunicação, ele usa o conceito de conexão (em que os dois participantes entram em acordo sobre a comunicação, e lembram disso a cada mensagem enviada e recebida) e realiza confirmações das mensagens recebidas. Este é o protocolo de transporte mais usado. UDP: usado quando não é imprescindível ter certeza de que cada mensagem chegou ao destino, ou o custo de fazer isso com TCP não compensar. Não há conexões, tampouco confirmações. Exemplos de uso são chamadas VoIP e consultas DNS. O estudo das aplicações da Internet inicia com WWW, que foi responsável por popularizar a Internet nos anos 90 e ainda é a aplicação mais difundida e acessada. 49.6.1 WWW e protocolo HTTP WWW (World Wide Web) é um sistema de documentos em hipermidia que são ligados e acessados na Internet (FONTE: Wikipedia). Tendo início em 1990 como uma aplicação experimental desenvolvida por Tim Berners-Lee, que então trabalhava no CERN, na Suíça, em pouco tempo caiu no gosto de demais usuários e se difundiu. WWW se tornou tão popular que para muitos passou a ser sinônimo de Internet (equivocadamente). Por trás da sua rápida aceitação há um protocolo de aplicação simples e funcional, além claro do modelo de informação em hipermidia que agradou as pessoas. Se o WWW é um sistema de documentoshipermidia online mantido de forma distribuída na Internet, o protocolo HTTP (Hypertext Transfer Protocol) é o protocolo usado para acessá-los. Esse protocolo segue o modelo cliente-servidor, e as comunicações são feitas com mensagens de pedido e resposta. Um cliente (navegador web) envia uma mensagem HTTP de pedido a um servidor web, que a responde com uma mensagem de resposta contendo o conteúdo solicitado. O protocolo HTTP usa o protocolo TCP para transmitir suas mensagens. 49.6.1.1 Mensagens de pedido HTTP Mensagens HTTP de pedido possuem a seguinte estrutura: Método URI HTTP/versão_do_protocolo Cabeçalho1: valor do cabeçalho1 Cabeçalho2: valor do cabeçalho2 Cabeçalho3: valor do cabeçalho3 CabeçalhoN: valor do cabeçalhoN corpo da mensagem A primeira linha usa o campo método para indicar o tipo de pedido a ser realizado. O método HTTP pode ser entendido como um comando a ser realizado pelo servidor. Os métodos mais comuns são: GET: obtém um documento. POST: envia algum conteúdo e obtém como resposta um documento. HEAD: obtém informações sobre um documento. O campo URI (Uniform Resource Indicator) identifica o documento que o servidor deve acessar. Ele se aparenta com um caminho de arquivo (pathname), porém possui algumas extensões para poder enviar informação adicional. Os cabeçalhos servem para complementar o pedido, informando ao servidor mais detalhes sobre o que está sendo requisitado. Por fim, o corpo da mensagem é opcional, podendo conter dados a serem enviados ao servidor quando necessário. Tendo entendido os componentes de um pedido HTTP, segue abaixo um exemplo de uma requisição real (note que ela não possui corpo de mensagem): GET /wiki/ HTTP/1.1 Host: wiki.sj.ifsc.edu.br User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Cookie: wiki2010UserID=614; wiki2010UserName=Msobral; wiki2010Token=4ed97239498a2fc74596b0f0a62331b5; wiki2010_session=f4e6b1hl4ctlkbpe5gc5gkosi4 Connection: keep-alive If-Modified-Since: Mon, 20 May 2013 00:38:20 GMT 49.6.1.2 Mensagens de resposta HTTP Mensagens HTTP de resposta possuem a seguinte estrutura: HTTP/versão_do_protocolo status info Cabeçalho1: valor do cabeçalho1 Cabeçalho2: valor do cabeçalho2 Cabeçalho3: valor do cabeçalho3 CabeçalhoN: valor do cabeçalhoN corpo da mensagem A linha inicial informa o resultado do atendimento do pedido (se teve sucesso ou não), contendo um código numérico de status seguido de uma breve descrição. Os códigos numéricos e info mais comuns são: 200 OK: pedido atendido com sucesso. 302 Moved Temporarily: o pedido pode ser atendido em outra URL. 401 Authorization Required: acesso negado, pois exige-se autenticação. 403 Forbidden: acesso negado em definitivo. 404 Not Found: documento não encontrado. Após a linha inicial há os cabeçalhos, usados da mesma forma que em pedidos HTTP. Por fim, pode haver o corpo da mensagem (opcional). Um exemplo de mensagem de resposta segue abaixo: HTTP/1.1 200 OK Date: Thu, 23 May 2013 20:43:31 GMT Server: Apache Last-Modified: Fri, 10 May 2013 14:09:58 GMT ETag: "757236-40-4dc5db8df272a" Accept-Ranges: bytes Content-Length: 64 Vary: Accept-Encoding Connection: close Content-Type: text/plain; charset=UTF-8 Este é um pequeno arquivo de teste, sem informação útil ... 49.6.1.3 Atividade Prática 1. Instale o servidor WWW Apache 2. Documentação [1] sudo apt-get install apache2 2. Verifique a configuração do apache Nos arquivo "/etc/apache2/apache2.conf" e "/etc/apache2/sites-enabled/000-default", interprete os valores das seguintes variáveis: DocumentRoot - local onde ficam as páginas web ErrorLog - registro de erros (ex.: página não encontrada) No Apache o ErrorLog encontra-se em: /var/log/apache2/error.log CustomLog - registro padrão (ex.: acessos) No Apache o CustomLog encontra-se em: /var/log/apache2/access.log 3. Crie uma página WEB no servidor instalado e acesse-a. Crie a página web em DocumentRoot/minha_pagina.html, com o seguinte conteúdo: <html> <head> <title>Página de teste...</title> </head> <body> <p>Página Teste!</p> </body> </html> Acesse a página criada apontando um cliente WWW para http://localhost/minha_pagina.html 4. Acesse as páginas instaladas nos computadores de seus colegas utilizando seus IPs Exemplo: aponte um cliente WWW para http://192.168.1.12/minha_pagina.html 5. Instale o wireshark e capture os pacotes de comunicação HTTP, identificando as mensagens GET e suas respostas, como exposto acima. sudo apt-get install wireshark 49.7 22/09/16: Camada de Aplicação 49.7.1 Experimento 1: Comunicação de dados A comunicação dados pode ser entendida como troca de informação entre dois dispositivos através de algum meio de comunicação. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes: A mensagem: a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de bits (dígitos binários). Transmissor: dispositivo que transmite a mensagem. Receptor: dispositivo que recebe a mensagem. Meio de comunicação: caminho físico por onde viaja a mensagem do transmissor até o receptor. Protocolo: conjunto de regras que governa a comunicação de dados. Neste experimento, vamos interagir com um servidor web e identificar esses cinco componentes. Usando um navegador, acesse os seguintes links: http://tele.sj.ifsc.edu.br/~tisemp/RES/arquivo.txt http://tele.sj.ifsc.edu.br/~tisemp/RES/teste.html Quais são os componentes do sistema de comunicação de dados ? Vamos repetir o acesso aos links acima, porém sem usar o navegador. A ideia é que nós façamos o papel de navegador. Isso deve ser feito com os seguintes passos: Abra um terminal de texto no Linux (menu Aplicativos->Acessórios->Terminal). Execute este comando: telnet tele.sj.ifsc.edu.br 80 Após aparecer esta linha: Trying 200.135.37.75... Connected to integrado.sj.ifsc.edu.br. Escape character is '^]'. digite o seguinte: GET /~tisemp/RES/arquivo.txt HTTP/1.0 e em seguida tecle ENTER duas vezes. Agora execute o seguinte para acessar o outro link: telnet tele.sj.ifsc.edu.br 80 Após aparecer esta linha: Trying 200.135.37.75... Connected to integrado.sj.ifsc.edu.br. Escape character is '^]'. digite o seguinte: GET /~tisemp/RES/teste.html HTTP/1.0 e em seguida tecle ENTER duas vezes. Compare o resultado das execuções desses comandos com o que se viu no navegador. Qual a diferença em cada caso ? Identifique os componentes do sistema de comunicação de dados nesse acesso direto. 49.7.2 Experimento 2: transmissão de mensagens de aplicação Neste experimento, serão observadas as mensagens transmitidas entre um navegador e um servidor web, e com base nelas devem ser identificados: os protocolos envolvidos e suas respectivas camadas dentro do modelo da Internet. os encapsulamentos realizados por esses protocolos. as informações que possibilitam identificar univocamente o navegador e o servidor web durante sua comunicação. Execute o wireshark em seu computador: abra um terminal em Aplicativos->Terminal e execute sudo wireshark Na tela do wireshark, ative a captura na interface de rede eth0 (ela está listada no lado esquerdo). Usando um navegador, acesse o link http://tele.sj.ifsc.edu.br/~tisemp/RES/arquivo.txt. Interrompa a captura no wireshark, clicando no menu Capture->Stop. Na tela do wireshark, escreva http na caixa de edição Filter, e em seguida clique em Apply. Selecione o primeiro pacote da lista. Em seguida, clique no menu Analyze->Follow TCP Stream. Uma tela se abrirá, e nela você poderá observar os dados transmitidos pelo navegador (em vermelho) e pelo servidor web (em azul). Esses são os dados da conversação ... todo o resto são informações de outros protocolos usadas para realizar a comunicação. Voltando à lista de pacotes mostrada pelo wireshark, observe a sequência de pacotes. Com base nela identifique: os protocolos envolvidos em que camada cada um deles atua que informações mantidas nesses protocolos possibilitam identificar o navegador e o servidor web. Cada protocolo transmite e recebe pacotes com um determinado formato, composto por cabeçalho e dados carregados (payload). Identifique nos pacotes recebidos que partes correspondem a cabeçalho e dados carregados. DESAFIO: imagine que foram capturados pacotes em uma rede, em que se monitoram as comunicações de uma determinada pessoa sob investigação. O investigador deve analisar esses pacotes em busca de arquivos que tenham sido transmitidos. Os pacotes capturados foram salvos em um arquivo de captura do wireshark, o qual se encontra aqui: captura.log Para visualizar os pacotes, use o menu File->Open do wireshark. Verifique se existem arquivos transmitidos dentro desses pacotes, e, caso afirmativo, extraia-os e visualize seus conteúdos. Para cada arquivo encontrado, informe: qual o protocolo de aplicação usado para transmiti-lo que computador foi usado para acessá-los, e qual servidor foi acessado. 49.7.3 Experimento 3: pacotes que passeiam pela rede Neste experimento, deve-se evidenciar a transmissão de pacotes desde o transmissor até o receptor, que pode estar em outra rede. Como já foi discutido, para que isso seja possível deve haver uma forma de transmitir esses pacotes para dispositivos intermediários na rede, que os encaminham para seus destinos. Quer dizer, os pacotes devem ser roteados até seu receptor. Execute o wireshark em seu computador, e ative a captura de pacotes. Usando um navegador, acesse esta página. Observe os pacotes transmitidos entre seu computador e o computador que atendeu seu pedido e respondeu com o conteúdo da página (isso é, o servidor web). que informações identificam essa comunicação ? quais os protocolos envolvidos ? O servidor web está fora da rede do laboratório. Assim, os pacotes precisaram ser encaminhados pelo computador do professor para a rede da escola (lembre que o computador do professor fica entre a rede do laboratório e a do Câmpus). Portanto, nesse computador deve ser possível visualizar seus pacotes sendo transmitidos em direção ao servidor, assim como a resposta do servidor. Observe esses pacotes no wireshark executado pelo professor. as informações que identificam suas comunicações são as mesmas que as identificadas em seu próprio computador ? Acesse a página da UFSC. Enquanto isso, observe na tela do projetor do laboratório o wireshark no computador do professor capturando seus pacotes. que informações identificam suas comunicações ? O servidor web da UFSC está em outra rede. Com certeza vários equipamentos intermediários precisarão ajudar para que os pacotes cheguem lá, e as respostas voltem para os seus computadores. Para saber por onde seus pacotes passam, use este comando: traceroute -n www.ufsc.br que informação está sendo usada para encaminhar os pacotes até o servidor web da UFSC ? que protocolo mantém e usa essa informação ? 49.7.4 Para pensar Para que o protocolo HTTP é usado atualmente além de acesso a documentos na web? Faça uma pesquisa sobre isso. Pesquise o significado dos cabeçalhos HTTP vistos nos acessos feitos na aula de hoje. 49.7.5 Considerações finais Os experimentos realizados buscaram introduzir alguns mecanismos envolvidos na comunicação através de uma rede de computadores. Tais mecanismos são implementados por alguns protocolos, lembrando que um protocolo especifica o formato dos pacotes transmitidos e as regras de comunicação para intercâmbio desses pacotes. Durante os experimentos, teve-se contato com alguns protocolos importantes envolvidos em comunicações na Internet, assim como algumas das principais informações definidas e usadas por esses protocolos. A visualização da hierarquia em que operam esses protocolos buscou mostrar o modelo de camadas da Internet, que define como deve funcionar um sistema que se comunica nesse tipo de rede. Para pensar: Para cada experimento, desenhe um diagrama de rede que mostre os equipamentos envolvidos. Para cada equipamento, desenhe também o modelo de camadas da Internet. Por fim, mostre o fluxo dos pacotes através dessas camadas (desde o transmissor até o receptor), indicando: que protocolo foi usado em cada camada. que serviço cada protocolo realizou. que informações foram usadas por cada protocolo. 49.8 22/09/16: Camada de Aplicação Continuação Laboratório (15/09/2016) Correção listas de exercícios 49.9 29/09/16: Avaliação 1 Conteúdo: Capítulo 1 e 2 (Kurose); Duração: 18h:45m - 20h:20m Atividade em laboratório (Continuação Lab.); 49.10 03/10/16: Camada de Transporte (segunda-feira) Vista de prova - Avaliação Camada de Aplicação Introdução à Camada de Transporte Listas de exercícios 5 e 6 49.11 13/10/16: Camada de Transporte Protocolos Dutados: Volta-N e Retransmissão Seletiva Controle de Fluxo, congestionamento; Resolução de Exercícios 49.12 20/10/16: Camada de Transporte (Lab. Programação) Mostra Científica e Cultural 2016 (Programação) Palestra Internet das Coisas (IoT). Local: auditório do Câmpus São José. Horário: 20:40 - 22:30 As atividades de hoje buscarão mostrar as características básicas de comunicações com protocolos de transporte. 49.12.1 Aplicações e protocolos de transporte Faça uma rápida pesquisa e descubra que protocolos de transporte (e que ports) são usados por estas aplicações: SSH FTP BitTorrent emule WINS Compartilhamento de arquivos do Windows Windows Terminal Service NFS Openvpn RADIUS DHCP SNMP NTP LDAP Mysql Postgresql Oracle RDBMS Syslog CUPS Que protocolo de transporte predomina nesse conjunto ? 49.12.2 Tipos de protocolos de transporte: TCP x UDP Nestes experimentos, serão evidenciadas diferenças entre os protocolos TCP e UDP. 49.12.2.1 Experimento 1 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 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 ? Abra um terminal e execute o seguinte comando para fazer o download de um arquivo a ser usado no experimento: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso Observe o tamanho do arquivo transferido ... ele deve ter exatamente 832569344 bytes (cerca de 832 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. A primeira transferência será feita usando o protocolo TCP da seguinte forma: No computador receptor execute: nc -l 5555 > arquivo No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): time nc 192.168.1.X 5555 < ubuntu.iso 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: No computador receptor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x receptor). No computador receptor execute: ./receptor 5555 > arquivo No computador transmissor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x transmissor). No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): ./transmissor 192.168.1.X 5555 < ubuntu.iso Quando completar a transferência, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original ? E quanto tempo levou para transmiti-lo ? Compare as transferências feitas com TCP e UDP. O que eles têm em comum ? Que diferenças lhe pareceram mais pronunciadas ? Como isso deve afetar as aplicações que usam esses protocolos ? 49.12.2.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, como mostrado na figura abaixo: Abra um terminal em seu computador, e nele execute este comando: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso 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á se logar em um dos computadores do laboratório e 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 ? Finalmente, o professor irá repetir a transferência porém com mais dois 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: Abra dois terminais. Em um deles execute este comando: watch -n 1 ls -l arquivo ... e no outro execute: ./receptor 5555 > arquivo Como se comparam as transferências usando TCP e UDP ? 49.13 27/10/16: Camada de Transporte (Lab. Programação) Continuação dos experimentos Aula 20/10/2016 49.14 03/11/16: Avaliação 2 (sala 03) Avaliação Camada de Transporte Duração: 19h - 20h:30m Introdução a Camada de Rede Resolução de Lista de Exercícios 49.15 10/11/16: Camada de Rede Vista da Avaliação da Camada de Transporte (A2) Camada de Rede: Roteamento Intra-SA e Inter-SA 49.16 17/11/16: Camada de Rede Endereçamento IP: Classful e Classless (CIDR) Segmentação de Redes IP Resolução de Exercícios 49.17 24/11/16: Camada de Rede Segmentação de Redes Resolução de Exercícios 49.18 01/12/16: Camada de Rede IP Público vs Privado Resolução de exercícios de Revisão 49.19 08/12/16: Avaliação 3 Avaliação Camada de Rede Duração: 19h - 20h:30m 49.20 15/12/16: Encerramento da disciplina Avaliações de recuperação da disciplina.

Semestre 2016-1 - Prof. Tiago Semprebom

2016-1 - Prof. Tiago Semprebom 50 TecTel: Redes de Computadores - 2016-1 - Prof. Tiago Semprebom 51 Professor Professor: Tiago Semprebom Email: tisemp@ifsc.edu.br Atendimento paralelo: 5a feira 17:30h - 18:30 h (Lab. de Desenvolvimento de Tele II) Endereço web do grupo: http://groups.google.com/group/ifsc_res Endereço de e-mail da disciplina: ifsc_res@googlegroups.com 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. O não cumprimento desse procedimento implica a impossibilidade de fazer a recuperação, e assim a reprovação na disciplina. 51.1 Plano de Ensino 52 Notas Matrícula A1 A2 A3 Rel. Tec. Final 132003277-0 D(C) C A OK C 151000546-3 6,9 6,9 8,0 OK 7,0 151000952-3 8,9 10 8,6 OK 9,0 141002147-5 D(C) B B OK B F: faltou (X): conceito da recuperação negrito: com direito a recuperação 53 Curiosidades Breve histórico sobre o surgimento das redes de computadores e a Internet Vídeo sobre surgimento da Internet Vídeo sobre o funcionamento das fibras ópticas Vídeo sobre fibra óptica Mapas de rede dorsais (Backbones) Mapa da rede Ipê (Internet acadêmica pública no Brasil) POP SC (ponto de presença de SC) Telex O Ciberespaço e as Redes de Computadores na Construção de Novo Conhecimento Uma história das Redes de Computadores Breve História da Internet Uma representação artística das interligações na Internet 54 Materiais de aula 54.1 Slides Arquivo:Slides-kurose-cap1.pdf Arquivo:Slides-kurose-cap2.pdf Arquivo:RCO-semprebom-cap3.pdf Arquivo:RCO-semprebom-cap4.pdf 54.2 Listas de exercícios Lista de exercícios 1 Lista de exercícios 2 Lista de exercícios 3 Lista de exercícios 4 Lista de exercícios 5 Lista de exercícios 6 Lista de exercícios 7 Lista de exercícios 8 Lista de exercícios 9 54.3 Apostilas Apostila de Redes de Computadores do Prof. Evandro Cantú 55 Aulas 55.1 24/03/16: Apresentação da disciplina Apresentação da disciplina, plano de aula, laboratórios e métodos de avaliação. Revisão de conceitos do Projeto Integrador I Introdução a Redes de Computadores [slides] 55.2 31/03/16: Introdução à Redes de Computadores Serviço orientado à conexão (TCP). Serviço não orientado à conexão (UDP). Comutação de circuitos vs Comutação de pacotes. FDMA e TDMA. Resolução de exercícios (Lista 1) 55.3 07/04/16: Comutação por Circuitos, Comutação de Pacotes, Lab01: Ferramentas básicas de redes Introdução a Redes de Computadores [slides] Nesta atividade serão vistos algumas ferramentas utilizadas para obter informações relacionadas às configurações de uma rede de computadores. Roteiro 1 (ping, ifconfig, traceroute) Roteiro Rápido do SS - Socket Statistics 55.4 14/04/16: Comutação por Circuitos, Comutação de Pacotes, Lab01: Ferramentas básicas de redes Redes de acesso e meio físico Atrasos em redes de comutação de pacotes Arquitetura em Camadas Atividade em Laboratório (Lab. Redes I) Captura de pacotes na rede (Wireshark) Roteiro TCPDump Wireshark e manuais

Semestre 2015-2 - Prof. Tiago Semprebom

56 Diário de aula de RCO - 2015-2 - Prof. Tiago Semprebom 57 Professor Professor: Tiago Semprebom Email: tisemp@ifsc.edu.br Atendimento paralelo: 5a feira 17:30h - 18:30 h (Lab. de Desenvolvimento de Tele) Endereço web do grupo: http://groups.google.com/group/ifsc_res Endereço de e-mail da disciplina: ifsc_res@googlegroups.com 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. O não cumprimento desse procedimento implica a impossibilidade de fazer a recuperação, e assim a reprovação na disciplina. 57.1 Plano de Ensino 58 Conceitos Matrícula A1 A2 A3 Rel. Tec. Final 132003277-0 D(C) C A OK C 151000546-3 6,9 6,9 8,0 OK 7,0 151000952-3 8,9 10 8,6 OK 9,0 141002147-5 D(C) B B OK B F: faltou (X): conceito da recuperação negrito: com direito a recuperação 59 Material de apoio Listas de exercício Lista 1 Lista 2 Lista 3 Lista 4 Lista 5 Lista 6 Lista 7 Lista 8 Lista 9 Transparências utilizadas durante as aulas Capítulo 1 Capítulo 2 Capítulo 3 Capítulo 4 Capítulo 5 Apostila Apostila de Redes de Computadores do Prof. Evandro Cantú 60 Curiosidades Breve histórico sobre o surgimento das redes de computadores e a Internet Vídeo sobre surgimento da Internet Vídeo sobre o funcionamento das fibras ópticas Vídeo sobre fibra óptica Mapas de rede dorsais (Backbones) Mapa da rede Ipê (Internet acadêmica pública no Brasil) POP SC (ponto de presença de SC) Telex O Ciberespaço e as Redes de Computadores na Construção de Novo Conhecimento Uma história das Redes de Computadores Breve História da Internet Uma representação artística das interligações na Internet 61 Aulas 61.1 08/10/15: Apresentação da disciplina Apresentação da disciplina, plano de aula, trabalhos e métodos de avaliação. Internet: sistemas finais, borda da rede e núcleo da rede. 61.2 15/10/15: Viagem à Latinoware Viagem a conferência Latino-Americana de Software Livre, (Latinoware). 61.3 22/10/15: Introdução à Redes de Computadores Hosts, elementos finais e modelos de serviço. Visão de serviços e componentes, borda da rede, núcleo da rede, protocolos Atividade em laboratório (Lab. Programação) Configuração de interfaces de rede no Linux Roteiro 1 (ping, ifconfig, traceroute) Roteiro Rápido do SS - Socket Statistics 61.4 29/10/15: Introdução à Redes de Computadores Serviço orientado à conexão (TCP). Serviço não orientado à conexão (UDP). Comutação de circuitos vs Comutação de pacotes. FDMA e TDMA. Resolução de exercícios (Lista 1) 61.5 05/11/15: Introdução à Redes de Computadores Redes de acesso e meio físico Atrasos em redes de comutação de pacotes Arquitetura em Camadas Atividade em Laboratório (Lab. Programação) Captura de pacotes na rede (Wireshark) Roteiro TCPDump Wireshark e manuais 61.6 12/11/15: Arquitetura em Camadas Correção da Lista de Exercícios I (Lista 1) Modelo de referência TCP/IP Encapsulamento PDU's Atividade em Laboratório (Lab. Programação) Roteiro TCPDump Wireshark e manuais Números de portas (IANA) 61.7 19/11/15: Introdução à Redes de Computadores Atividade em Laboratório (Lab. Programação) Roteiro TCPDump Wireshark e manuais Números de portas (IANA) Redação do Relatório Técnico II 61.8 26/11/15: Camada de Aplicação A camada de aplicação (ver estes [slides) Lista de Exercícios II e III 61.9 03/12/15: Camada de Aplicação Camada de Aplicação (ver estes [slides]) Protocolos SMTP, IMAP, POP3, FTP e DNS. Resolução de exercícios (Lista 2) Ver Capítulo 27 do livro Comunicação de Dados e Redes de Computadores, 4a ed., de Behrouz Forouzan. Na arquitetura de redes da Internet, são as aplicações que se comunicam, gerando dados no transmissor e consumindo-os no receptor. Aplicações residem em equipamentos de rede, e se comunicam através da rede usando os serviços das camadas inferiores Aplicações são processos que se comunicam através da rede (lembre que processos são programas em execução). Exemplos de aplicações são navegadores web (Firefox, Chrome) e bate-papo (Skype, GTalk). A comunicação pode ser feita de diferentes formas, de acordo com o modelo de comunicação adotado pela aplicação em questão. O modelo de comunicação define o papel de cada participante da comunicação, e por consequência acaba determinando como a comunicação acontece (quem a inicia, quando se transmitem e recebem mensagens). Três modelos conhecidos são: Cliente-Servidor: um participante é o cliente, e o outro o servidor. O cliente inicia a comunicação, ao enviar uma mensagem ao servidor pedindo algum serviço. Cabe ao servidor responder aos pedidos dos clientes. Este é o modelo mais comum de se encontrar em aplicações, tais como correio eletrônico, WWW, bancos de dados, compartilhamento de arquivos e outros. Peer-to-Peer (P2P): cada participante pode ser tanto cliente quanto servidor, assim qualquer um pode iniciar uma comunicação. Tornou-se popular com aplicações como compartilhamento de arquivos (ex: BitTorrent, eDonkey) e sistemas de chamadas VoIP. Publisher/Subscriber: neste modelo existem os publicadores de conteúdo (publishers) e os assinantes ou interessados (subscribers). Os assinantes registram seus interesses por demais tipos de dados (isso é, assinam canais de dados). Os publicadores eventualmente divulgam dados, que são distribuídos aos assinantes. Não é comum de ser encontrado em aplicações, porém é o modelo usado para detecção de presença em aplicações de conversa on-line (Skype, Gtalk). Cada aplicação usa diretamente os serviços da camada de transporte, e indiretamente os de camadas inferiores. Assim, para uma aplicação é a camada de transporte que envia e recebe suas mensagens. Como visto na aula passada, um serviço importante da camada de transporte é classificar e separar os pacotes recebidos de acordo com a aplicação que deve recebê-los, e para isso usa-se um número chamado de porta. O número de porta pode ser entendido como um endereçador de aplicações dentro de um mesmo host. Vimos também que a camada de transporte na Internet apresenta dois protocolos, e ambos usam números de porta para separar os pacotes de acordo com a comunicação que os contém: TCP: usado por aplicações quando há necessidade de ter certeza de que os dados foram recebidos. Esse protocolo faz retransmissões automáticas no caso de perdas de mensagens. Para estabelecer a comunicação, ele usa o conceito de conexão (em que os dois participantes entram em acordo sobre a comunicação, e lembram disso a cada mensagem enviada e recebida) e realiza confirmações das mensagens recebidas. Este é o protocolo de transporte mais usado. UDP: usado quando não é imprescindível ter certeza de que cada mensagem chegou ao destino, ou o custo de fazer isso com TCP não compensar. Não há conexões, tampouco confirmações. Exemplos de uso são chamadas VoIP e consultas DNS. O estudo das aplicações da Internet inicia com WWW, que foi responsável por popularizar a Internet nos anos 90 e ainda é a aplicação mais difundida e acessada. 61.9.1 WWW e protocolo HTTP WWW (World Wide Web) é um sistema de documentos em hipermidia que são ligados e acessados na Internet (FONTE: Wikipedia). Tendo início em 1990 como uma aplicação experimental desenvolvida por Tim Berners-Lee, que então trabalhava no CERN, na Suíça, em pouco tempo caiu no gosto de demais usuários e se difundiu. WWW se tornou tão popular que para muitos passou a ser sinônimo de Internet (equivocadamente). Por trás da sua rápida aceitação há um protocolo de aplicação simples e funcional, além claro do modelo de informação em hipermidia que agradou as pessoas. Se o WWW é um sistema de documentoshipermidia online mantido de forma distribuída na Internet, o protocolo HTTP (Hypertext Transfer Protocol) é o protocolo usado para acessá-los. Esse protocolo segue o modelo cliente-servidor, e as comunicações são feitas com mensagens de pedido e resposta. Um cliente (navegador web) envia uma mensagem HTTP de pedido a um servidor web, que a responde com uma mensagem de resposta contendo o conteúdo solicitado. O protocolo HTTP usa o protocolo TCP para transmitir suas mensagens. 61.9.1.1 Mensagens de pedido HTTP Mensagens HTTP de pedido possuem a seguinte estrutura: Método URI HTTP/versão_do_protocolo Cabeçalho1: valor do cabeçalho1 Cabeçalho2: valor do cabeçalho2 Cabeçalho3: valor do cabeçalho3 CabeçalhoN: valor do cabeçalhoN corpo da mensagem A primeira linha usa o campo método para indicar o tipo de pedido a ser realizado. O método HTTP pode ser entendido como um comando a ser realizado pelo servidor. Os métodos mais comuns são: GET: obtém um documento. POST: envia algum conteúdo e obtém como resposta um documento. HEAD: obtém informações sobre um documento. O campo URI (Uniform Resource Indicator) identifica o documento que o servidor deve acessar. Ele se aparenta com um caminho de arquivo (pathname), porém possui algumas extensões para poder enviar informação adicional. Os cabeçalhos servem para complementar o pedido, informando ao servidor mais detalhes sobre o que está sendo requisitado. Por fim, o corpo da mensagem é opcional, podendo conter dados a serem enviados ao servidor quando necessário. Tendo entendido os componentes de um pedido HTTP, segue abaixo um exemplo de uma requisição real (note que ela não possui corpo de mensagem): GET /wiki/ HTTP/1.1 Host: wiki.sj.ifsc.edu.br User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Cookie: wiki2010UserID=614; wiki2010UserName=Msobral; wiki2010Token=4ed97239498a2fc74596b0f0a62331b5; wiki2010_session=f4e6b1hl4ctlkbpe5gc5gkosi4 Connection: keep-alive If-Modified-Since: Mon, 20 May 2013 00:38:20 GMT 61.9.1.2 Mensagens de resposta HTTP Mensagens HTTP de resposta possuem a seguinte estrutura: HTTP/versão_do_protocolo status info Cabeçalho1: valor do cabeçalho1 Cabeçalho2: valor do cabeçalho2 Cabeçalho3: valor do cabeçalho3 CabeçalhoN: valor do cabeçalhoN corpo da mensagem A linha inicial informa o resultado do atendimento do pedido (se teve sucesso ou não), contendo um código numérico de status seguido de uma breve descrição. Os códigos numéricos e info mais comuns são: 200 OK: pedido atendido com sucesso. 302 Moved Temporarily: o pedido pode ser atendido em outra URL. 401 Authorization Required: acesso negado, pois exige-se autenticação. 403 Forbidden: acesso negado em definitivo. 404 Not Found: documento não encontrado. Após a linha inicial há os cabeçalhos, usados da mesma forma que em pedidos HTTP. Por fim, pode haver o corpo da mensagem (opcional). Um exemplo de mensagem de resposta segue abaixo: HTTP/1.1 200 OK Date: Thu, 23 May 2013 20:43:31 GMT Server: Apache Last-Modified: Fri, 10 May 2013 14:09:58 GMT ETag: "757236-40-4dc5db8df272a" Accept-Ranges: bytes Content-Length: 64 Vary: Accept-Encoding Connection: close Content-Type: text/plain; charset=UTF-8 Este é um pequeno arquivo de teste, sem informação útil ... 61.9.1.3 Atividade Prática 1. Instale o servidor WWW Apache 2. Documentação [2] sudo apt-get install apache2 2. Verifique a configuração do apache Nos arquivo "/etc/apache2/apache2.conf" e "/etc/apache2/sites-enabled/000-default", interprete os valores das seguintes variáveis: DocumentRoot - local onde ficam as páginas web ErrorLog - registro de erros (ex.: página não encontrada) No Apache o ErrorLog encontra-se em: /var/log/apache2/error.log CustomLog - registro padrão (ex.: acessos) No Apache o CustomLog encontra-se em: /var/log/apache2/access.log 3. Crie uma página WEB no servidor instalado e acesse-a. Crie a página web em DocumentRoot/minha_pagina.html, com o seguinte conteúdo: <html> <head> <title>Página de teste...</title> </head> <body> <p>Página Teste!</p> </body> </html> Acesse a página criada apontando um cliente WWW para http://localhost/minha_pagina.html 4. Acesse as páginas instaladas nos computadores de seus colegas utilizando seus IPs Exemplo: aponte um cliente WWW para http://192.168.1.12/minha_pagina.html 5. Instale o wireshark e capture os pacotes de comunicação HTTP, identificando as mensagens GET e suas respostas, como exposto acima. sudo apt-get install wireshark 61.10 10/12/15: Camada de Aplicação Avaliação CPA (alunos) clique aqui 61.10.1 Experimento 1: Comunicação de dados A comunicação dados pode ser entendida como troca de informação entre dois dispositivos através de algum meio de comunicação. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes: A mensagem: a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de bits (dígitos binários). Transmissor: dispositivo que transmite a mensagem. Receptor: dispositivo que recebe a mensagem. Meio de comunicação: caminho físico por onde viaja a mensagem do transmissor até o receptor. Protocolo: conjunto de regras que governa a comunicação de dados. Neste experimento, vamos interagir com um servidor web e identificar esses cinco componentes. Usando um navegador, acesse os seguintes links: http://tele.sj.ifsc.edu.br/~tisemp/RES/arquivo.txt http://tele.sj.ifsc.edu.br/~tisemp/RES/teste.html Quais são os componentes do sistema de comunicação de dados ? Vamos repetir o acesso aos links acima, porém sem usar o navegador. A ideia é que nós façamos o papel de navegador. Isso deve ser feito com os seguintes passos: Abra um terminal de texto no Linux (menu Aplicativos->Acessórios->Terminal). Execute este comando: telnet tele.sj.ifsc.edu.br 80 Após aparecer esta linha: Trying 200.135.37.75... Connected to integrado.sj.ifsc.edu.br. Escape character is '^]'. digite o seguinte: GET /~tisemp/RES/arquivo.txt HTTP/1.0 e em seguida tecle ENTER duas vezes. Agora execute o seguinte para acessar o outro link: telnet tele.sj.ifsc.edu.br 80 Após aparecer esta linha: Trying 200.135.37.75... Connected to integrado.sj.ifsc.edu.br. Escape character is '^]'. digite o seguinte: GET /~tisemp/RES/teste.html HTTP/1.0 e em seguida tecle ENTER duas vezes. Compare o resultado das execuções desses comandos com o que se viu no navegador. Qual a diferença em cada caso ? Identifique os componentes do sistema de comunicação de dados nesse acesso direto. 61.10.2 Experimento 2: transmissão de mensagens de aplicação Neste experimento, serão observadas as mensagens transmitidas entre um navegador e um servidor web, e com base nelas devem ser identificados: os protocolos envolvidos e suas respectivas camadas dentro do modelo da Internet. os encapsulamentos realizados por esses protocolos. as informações que possibilitam identificar univocamente o navegador e o servidor web durante sua comunicação. Execute o wireshark em seu computador: abra um terminal em Aplicativos->Terminal e execute sudo wireshark Na tela do wireshark, ative a captura na interface de rede eth0 (ela está listada no lado esquerdo). Usando um navegador, acesse o link http://tele.sj.ifsc.edu.br/~tisemp/RES/arquivo.txt. Interrompa a captura no wireshark, clicando no menu Capture->Stop. Na tela do wireshark, escreva http na caixa de edição Filter, e em seguida clique em Apply. Selecione o primeiro pacote da lista. Em seguida, clique no menu Analyze->Follow TCP Stream. Uma tela se abrirá, e nela você poderá observar os dados transmitidos pelo navegador (em vermelho) e pelo servidor web (em azul). Esses são os dados da conversação ... todo o resto são informações de outros protocolos usadas para realizar a comunicação. Voltando à lista de pacotes mostrada pelo wireshark, observe a sequência de pacotes. Com base nela identifique: os protocolos envolvidos em que camada cada um deles atua que informações mantidas nesses protocolos possibilitam identificar o navegador e o servidor web. Cada protocolo transmite e recebe pacotes com um determinado formato, composto por cabeçalho e dados carregados (payload). Identifique nos pacotes recebidos que partes correspondem a cabeçalho e dados carregados. DESAFIO: imagine que foram capturados pacotes em uma rede, em que se monitoram as comunicações de uma determinada pessoa sob investigação. O investigador deve analisar esses pacotes em busca de arquivos que tenham sido transmitidos. Os pacotes capturados foram salvos em um arquivo de captura do wireshark, o qual se encontra aqui: captura.log Para visualizar os pacotes, use o menu File->Open do wireshark. Verifique se existem arquivos transmitidos dentro desses pacotes, e, caso afirmativo, extraia-os e visualize seus conteúdos. Para cada arquivo encontrado, informe: qual o protocolo de aplicação usado para transmiti-lo que computador foi usado para acessá-los, e qual servidor foi acessado. 61.10.3 Experimento 3: pacotes que passeiam pela rede Neste experimento, deve-se evidenciar a transmissão de pacotes desde o transmissor até o receptor, que pode estar em outra rede. Como já foi discutido, para que isso seja possível deve haver uma forma de transmitir esses pacotes para dispositivos intermediários na rede, que os encaminham para seus destinos. Quer dizer, os pacotes devem ser roteados até seu receptor. Execute o wireshark em seu computador, e ative a captura de pacotes. Usando um navegador, acesse esta página. Observe os pacotes transmitidos entre seu computador e o computador que atendeu seu pedido e respondeu com o conteúdo da página (isso é, o servidor web). que informações identificam essa comunicação ? quais os protocolos envolvidos ? O servidor web está fora da rede do laboratório. Assim, os pacotes precisaram ser encaminhados pelo computador do professor para a rede da escola (lembre que o computador do professor fica entre a rede do laboratório e a do Câmpus). Portanto, nesse computador deve ser possível visualizar seus pacotes sendo transmitidos em direção ao servidor, assim como a resposta do servidor. Observe esses pacotes no wireshark executado pelo professor. as informações que identificam suas comunicações são as mesmas que as identificadas em seu próprio computador ? Acesse a página da UFSC. Enquanto isso, observe na tela do projetor do laboratório o wireshark no computador do professor capturando seus pacotes. que informações identificam suas comunicações ? O servidor web da UFSC está em outra rede. Com certeza vários equipamentos intermediários precisarão ajudar para que os pacotes cheguem lá, e as respostas voltem para os seus computadores. Para saber por onde seus pacotes passam, use este comando: traceroute -n www.ufsc.br que informação está sendo usada para encaminhar os pacotes até o servidor web da UFSC ? que protocolo mantém e usa essa informação ? 61.10.4 Para pensar Para que o protocolo HTTP é usado atualmente além de acesso a documentos na web? Faça uma pesquisa sobre isso. Pesquise o significado dos cabeçalhos HTTP vistos nos acessos feitos na aula de hoje. 61.10.5 Considerações finais Os experimentos realizados buscaram introduzir alguns mecanismos envolvidos na comunicação através de uma rede de computadores. Tais mecanismos são implementados por alguns protocolos, lembrando que um protocolo especifica o formato dos pacotes transmitidos e as regras de comunicação para intercâmbio desses pacotes. Durante os experimentos, teve-se contato com alguns protocolos importantes envolvidos em comunicações na Internet, assim como algumas das principais informações definidas e usadas por esses protocolos. A visualização da hierarquia em que operam esses protocolos buscou mostrar o modelo de camadas da Internet, que define como deve funcionar um sistema que se comunica nesse tipo de rede. Para pensar: Para cada experimento, desenhe um diagrama de rede que mostre os equipamentos envolvidos. Para cada equipamento, desenhe também o modelo de camadas da Internet. Por fim, mostre o fluxo dos pacotes através dessas camadas (desde o transmissor até o receptor), indicando: que protocolo foi usado em cada camada. que serviço cada protocolo realizou. que informações foram usadas por cada protocolo. 61.11 17/12/15: Avaliação 1 Conteúdos abordados: Arquitetura Internet (Cap. 1 Kurose) e Camada de Aplicação (Cap. 2 Kurose). Revisão: 18h:45m - 19h:15m Avaliação: 19h:15m - 21h:15m 61.12 04/02/16: Camada de Transporte Camada de Transporte (ver estes [slides]) Capítulo 3 do Kurose Resolução de exercícios (Lista 4) Resolução de exercícios (Lista 5) Construção de um protocolo de transferência confiável Volta-N, Retransmissão Seletiva Até o momento nos concentramos nos serviços de rede (Camada de Aplicação). Afinal, são elas que usamos para nos comunicarmos através das redes de computadores. No entanto, aplicações dependem de outros protocolos para poderem se comunicar, os quais cuidam dos detalhes envolvidos na transmissão e recepção de mensagens em uma rede vasta como a Internet. As aplicações se comunicam por meio de mensagens. Cada protocolo de aplicação (HTTP, POP3, DNS, IMAP, SMTP, SIP, ...) tem seu formato de mensagem. Essas mensagens podem ser pequenas (ex: DNS, SIP) ou por vezes grandes (ex: SMTP, HTTP, POP3). De qualquer forma, a aplicação precisa que suas mensagens sejam transmitidas para o outro participante da comunicação, que está em um computador remoto. Para isso ela usa um protocolo de transporte. Algumas aplicações e protocolos de transporte na Internet Como já discutido, mais de uma aplicação pode existir em um mesmo computador. Por isso, uma das principais atribuições de um protocolo de transporte é identificar de qual aplicação é uma mensagem a ser transmitida, e para qual aplicação se destina uma mensagem recebida. Deve-se ter em mente que uma aplicação é representada por um programa em execução em um computador, portanto um protocolo de transporte possibilita a comunicação entre processos que estão sendo executados usualmente em computadores diferentes. Em nossas discussões anteriores chamamos isso de classificação das mensagens, mas o termo usado para expressar essa capacidade dos protocolos de transporte é multiplexação. No caso específico dos protocolos de transporte da Internet (TCP e UDP), um número de port é usado para fazer essa distinção, e por isso essa função é denominada multiplexação baseada em port. Uma comunicação entre aplicações é composta basicamente de duas informações principais: endereços dos hosts participantes e números de port dos processos. Os endereços são responsabilidade da Camada de Rede (onde há o protocolo IP), e os números de port são usados na Camada de Transporte (onde estão os protocolos TCP e UDP). Mas por que existem dois protocolos de transporte ? Talvez ajude a esclarecer essa questão se compararmos as necessidades das aplicações: Aplicação Tolerância a perdas Tolerância a atrasos Tamanhos de mensagens HTTP baixa média variável ... podem ser muito grandes (de poucos bytes a centenas de megabytes ou mais) SMTP baixa alta variável ... podem ser grandes (de centenas bytes a alguns megabytes) DNS média baixa pequenas (algumas centenas de bytes) POP3 baixa média variável ... podem ser grandes (de centenas bytes a alguns megabytes) SIP média média pequenas (algumas centenas de bytes) VoIP média baixa pequenas (tipicamente < 164 bytes) Durante o projeto e aperfeiçoamento dos protocolos da Internet, convergiu-se para a definição de dois protocolos de transporte: TCP (ver RFC 793): protocolo orientado a conexão, com garantia de entrega, controle de fluxo e controle de congestionamento. UDP (ver RFC 768): protocolo orientado a datagrama (não há conexão), sem garantia de entrega ou qualquer outra verificação ou controle. Basicamente faz somente a multiplexação baseada em port. Curiosidade: veja os anos em que foram publicados as especificações desses protocolos ... As diferenças entre eles serão melhor detalhadas nas próximas aulas. Hoje farems alguns experimentos para ter uma ideia de como se comportam as comunicações feitas com esses protocolos. 61.13 11/02/16: Camada de Transporte Princípios de funcionamento do TCP 61.14 Atividade As atividades de hoje buscarão mostrar as características básicas de comunicações com protocolos de transporte. 61.14.1 Aplicações e protocolos de transporte Faça uma rápida pesquisa e descubra que protocolos de transporte (e que ports) são usados por estas aplicações: SSH FTP BitTorrent emule WINS Compartilhamento de arquivos do Windows Windows Terminal Service NFS Openvpn RADIUS DHCP SNMP NTP LDAP Mysql Postgresql Oracle RDBMS Syslog CUPS Que protocolo de transporte predomina nesse conjunto ? 61.14.2 Tipos de protocolos de transporte: TCP x UDP Nestes experimentos, serão evidenciadas diferenças entre os protocolos TCP e UDP. 61.14.2.1 Experimento 1 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 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 ? Abra um terminal e execute o seguinte comando para fazer o download de um arquivo a ser usado no experimento: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso Observe o tamanho do arquivo transferido ... ele deve ter exatamente 832569344 bytes (cerca de 832 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. A primeira transferência será feita usando o protocolo TCP da seguinte forma: No computador receptor execute: nc -l 5555 > arquivo No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): time nc 192.168.1.X 5555 < ubuntu.iso 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: No computador receptor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x receptor). No computador receptor execute: ./receptor 5555 > arquivo No computador transmissor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x transmissor). No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): ./transmissor 192.168.1.X 5555 < ubuntu.iso Quando completar a transferência, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original ? E quanto tempo levou para transmiti-lo ? Compare as transferências feitas com TCP e UDP. O que eles têm em comum ? Que diferenças lhe pareceram mais pronunciadas ? Como isso deve afetar as aplicações que usam esses protocolos ? 61.14.2.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, como mostrado na figura abaixo: Abra um terminal em seu computador, e nele execute este comando: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso 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á se logar em um dos computadores do laboratório e 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 ? Finalmente, o professor irá repetir a transferência porém com mais dois 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: Abra dois terminais. Em um deles execute este comando: watch -n 1 ls -l arquivo ... e no outro execute: ./receptor 5555 > arquivo Como se comparam as transferências usando TCP e UDP ? 61.15 16/02/16: Avaliação da Camada de Transporte Avaliação Camada de Transporte Cap 3 Kurose, Slides e Lista V. Local: Sala 02 Introdução à Camada de Rede - (Slides) Exercícios (Lista 7) 61.16 18/02/16: Camada de Rede Roteamento Hierárquico Endereçamento IP Exercícios Camada de Rede Lista 8 61.17 25/02/16: Camada de Rede Resolução de exercícios Segmentação de redes (Lista 10) 61.18 03/03/16: Camada de Rede Exercícios de revisão (parte teórica) (Lista 11) Avaliação de Camada de Rede (segundo horário) 61.19 10/03/16: Encerramento da Disciplina Recuperações: Camada de Aplicação, Transporte e Rede Conceitos finais: clique aqui

Semestre 2015-1 - Prof. Tiago Semprebom

62 Diário de aula de RCO - 2015-1 - Prof. Tiago Semprebom 63 Professor Professor: Tiago Semprebom Email: tisemp@ifsc.edu.br Atendimento paralelo: 6a feira 17:30h - 18:30 h (Lab. de Desenvolvimento de Tele) Endereço web do grupo: http://groups.google.com/group/ifsc_res Endereço de e-mail da disciplina: ifsc_res@googlegroups.com 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. O não cumprimento desse procedimento implica a impossibilidade de fazer a recuperação, e assim a reprovação na disciplina. 63.1 Plano de Ensino 64 Conceitos Matrícula A1 A2 A3 Rel. Tec. Final 142003381-6 B B B B B 142002607-0 F F D B D 142006774-5 C (B) A C A B 141005709-7 D(D) D D D D 142001234-7 D (C) B B B B 142001326-2 D(C) C A A B 141000292-6 D(D) D D D D 142003354-9 C (B) C C A B 142002006-4 D(C) C C B C 142002047-1 B C A A A 142001581-8 D(C) D(D) D(B) A D 132003277-0 D(D) D(D) D(D) D D F: faltou (X): conceito da recuperação negrito: com direito a recuperação 65 Material de apoio Listas de exercício Lista 1 Lista 2 Lista 3 Lista 4 Lista 5 Lista 6 Lista 7 Lista 8 Lista 9 Transparências utilizadas durante as aulas Capítulo 1 Capítulo 2 Capítulo 3 Capítulo 4 Capítulo 5 Apostila Apostila de Redes de Computadores do Prof. Evandro Cantú 66 Curiosidades Breve histórico sobre o surgimento das redes de computadores e a Internet Vídeo sobre surgimento da Internet Vídeo sobre o funcionamento das fibras ópticas Vídeo sobre fibra óptica Mapas de rede dorsais (Backbones) Mapa da rede Ipê (Internet acadêmica pública no Brasil) POP SC (ponto de presença de SC) Telex O Ciberespaço e as Redes de Computadores na Construção de Novo Conhecimento Uma história das Redes de Computadores Breve História da Internet Uma representação artística das interligações na Internet 67 Aulas 67.1 06/02/15: Apresentação da disciplina Apresentação da disciplina, plano de aula, trabalhos e métodos de avaliação. Internet: sistemas finais, borda da rede e núcleo da rede. Atividade em laboratório (Redes I): Revisão sobre GNU/Linux - Ubuntu. Instalação e configuração básica da distribuição Ubuntu. 67.2 13/02/15: Introdução à Redes de Computadores Hosts, elementos finais e modelos de serviço. Visão de serviços e componentes, borda da rede, núcleo da rede, protocolos Atividade em laboratório (Redes I) Configuração de interfaces de rede no Linux Roteiro 1 (ping, ifconfig, traceroute) Roteiro Rápido do SS - Socket Statistics 67.3 20/02/15: Introdução à Redes de Computadores Serviço orientado à conexão (TCP). Serviço não orientado à conexão (UDP). Comutação de circuitos vs Comutação de pacotes. FDMA e TDMA. Resolução de exercícios (Lista 1) 67.4 27/02/15: Introdução à Redes de Computadores Redes de acesso e meio físico Atrasos em redes de comutação de pacotes Arquitetura em Camadas Atividade em Laboratório (Redes I) Captura de pacotes na rede (Wireshark) Roteiro TCPDump Wireshark e manuais Números de portas (IANA) 67.5 06/03/15: Arquitetura em Camadas Modelo de referência TCP/IP Encapsulamento PDU's Resolução de exercícios (Lista 1) Atividade em Laboratório (Redes I) Roteiro TCPDump Wireshark e manuais Redação do Relatório Técnico II 67.6 13/03/15: Camada de Aplicação A camada de aplicação (ver estes [slides) Ver Capítulo 27 do livro Comunicação de Dados e Redes de Computadores, 4a ed., de Behrouz Forouzan. Na arquitetura de redes da Internet, são as aplicações que se comunicam, gerando dados no transmissor e consumindo-os no receptor. Aplicações residem em equipamentos de rede, e se comunicam através da rede usando os serviços das camadas inferiores Aplicações são processos que se comunicam através da rede (lembre que processos são programas em execução). Exemplos de aplicações são navegadores web (Firefox, Chrome) e bate-papo (Skype, GTalk). A comunicação pode ser feita de diferentes formas, de acordo com o modelo de comunicação adotado pela aplicação em questão. O modelo de comunicação define o papel de cada participante da comunicação, e por consequência acaba determinando como a comunicação acontece (quem a inicia, quando se transmitem e recebem mensagens). Três modelos conhecidos são: Cliente-Servidor: um participante é o cliente, e o outro o servidor. O cliente inicia a comunicação, ao enviar uma mensagem ao servidor pedindo algum serviço. Cabe ao servidor responder aos pedidos dos clientes. Este é o modelo mais comum de se encontrar em aplicações, tais como correio eletrônico, WWW, bancos de dados, compartilhamento de arquivos e outros. Peer-to-Peer (P2P): cada participante pode ser tanto cliente quanto servidor, assim qualquer um pode iniciar uma comunicação. Tornou-se popular com aplicações como compartilhamento de arquivos (ex: BitTorrent, eDonkey) e sistemas de chamadas VoIP. Publisher/Subscriber: neste modelo existem os publicadores de conteúdo (publishers) e os assinantes ou interessados (subscribers). Os assinantes registram seus interesses por demais tipos de dados (isso é, assinam canais de dados). Os publicadores eventualmente divulgam dados, que são distribuídos aos assinantes. Não é comum de ser encontrado em aplicações, porém é o modelo usado para detecção de presença em aplicações de conversa on-line (Skype, Gtalk). Cada aplicação usa diretamente os serviços da camada de transporte, e indiretamente os de camadas inferiores. Assim, para uma aplicação é a camada de transporte que envia e recebe suas mensagens. Como visto na aula passada, um serviço importante da camada de transporte é classificar e separar os pacotes recebidos de acordo com a aplicação que deve recebê-los, e para isso usa-se um número chamado de porta. O número de porta pode ser entendido como um endereçador de aplicações dentro de um mesmo host. Vimos também que a camada de transporte na Internet apresenta dois protocolos, e ambos usam números de porta para separar os pacotes de acordo com a comunicação que os contém: TCP: usado por aplicações quando há necessidade de ter certeza de que os dados foram recebidos. Esse protocolo faz retransmissões automáticas no caso de perdas de mensagens. Para estabelecer a comunicação, ele usa o conceito de conexão (em que os dois participantes entram em acordo sobre a comunicação, e lembram disso a cada mensagem enviada e recebida) e realiza confirmações das mensagens recebidas. Este é o protocolo de transporte mais usado. UDP: usado quando não é imprescindível ter certeza de que cada mensagem chegou ao destino, ou o custo de fazer isso com TCP não compensar. Não há conexões, tampouco confirmações. Exemplos de uso são chamadas VoIP e consultas DNS. O estudo das aplicações da Internet inicia com WWW, que foi responsável por popularizar a Internet nos anos 90 e ainda é a aplicação mais difundida e acessada. 67.6.1 WWW e protocolo HTTP WWW (World Wide Web) é um sistema de documentos em hipermidia que são ligados e acessados na Internet (FONTE: Wikipedia). Tendo início em 1990 como uma aplicação experimental desenvolvida por Tim Berners-Lee, que então trabalhava no CERN, na Suíça, em pouco tempo caiu no gosto de demais usuários e se difundiu. WWW se tornou tão popular que para muitos passou a ser sinônimo de Internet (equivocadamente). Por trás da sua rápida aceitação há um protocolo de aplicação simples e funcional, além claro do modelo de informação em hipermidia que agradou as pessoas. Se o WWW é um sistema de documentoshipermidia online mantido de forma distribuída na Internet, o protocolo HTTP (Hypertext Transfer Protocol) é o protocolo usado para acessá-los. Esse protocolo segue o modelo cliente-servidor, e as comunicações são feitas com mensagens de pedido e resposta. Um cliente (navegador web) envia uma mensagem HTTP de pedido a um servidor web, que a responde com uma mensagem de resposta contendo o conteúdo solicitado. O protocolo HTTP usa o protocolo TCP para transmitir suas mensagens. 67.6.1.1 Mensagens de pedido HTTP Mensagens HTTP de pedido possuem a seguinte estrutura: Método URI HTTP/versão_do_protocolo Cabeçalho1: valor do cabeçalho1 Cabeçalho2: valor do cabeçalho2 Cabeçalho3: valor do cabeçalho3 CabeçalhoN: valor do cabeçalhoN corpo da mensagem A primeira linha usa o campo método para indicar o tipo de pedido a ser realizado. O método HTTP pode ser entendido como um comando a ser realizado pelo servidor. Os métodos mais comuns são: GET: obtém um documento. POST: envia algum conteúdo e obtém como resposta um documento. HEAD: obtém informações sobre um documento. O campo URI (Uniform Resource Indicator) identifica o documento que o servidor deve acessar. Ele se aparenta com um caminho de arquivo (pathname), porém possui algumas extensões para poder enviar informação adicional. Os cabeçalhos servem para complementar o pedido, informando ao servidor mais detalhes sobre o que está sendo requisitado. Por fim, o corpo da mensagem é opcional, podendo conter dados a serem enviados ao servidor quando necessário. Tendo entendido os componentes de um pedido HTTP, segue abaixo um exemplo de uma requisição real (note que ela não possui corpo de mensagem): GET /wiki/ HTTP/1.1 Host: wiki.sj.ifsc.edu.br User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Cookie: wiki2010UserID=614; wiki2010UserName=Msobral; wiki2010Token=4ed97239498a2fc74596b0f0a62331b5; wiki2010_session=f4e6b1hl4ctlkbpe5gc5gkosi4 Connection: keep-alive If-Modified-Since: Mon, 20 May 2013 00:38:20 GMT 67.6.1.2 Mensagens de resposta HTTP Mensagens HTTP de resposta possuem a seguinte estrutura: HTTP/versão_do_protocolo status info Cabeçalho1: valor do cabeçalho1 Cabeçalho2: valor do cabeçalho2 Cabeçalho3: valor do cabeçalho3 CabeçalhoN: valor do cabeçalhoN corpo da mensagem A linha inicial informa o resultado do atendimento do pedido (se teve sucesso ou não), contendo um código numérico de status seguido de uma breve descrição. Os códigos numéricos e info mais comuns são: 200 OK: pedido atendido com sucesso. 302 Moved Temporarily: o pedido pode ser atendido em outra URL. 401 Authorization Required: acesso negado, pois exige-se autenticação. 403 Forbidden: acesso negado em definitivo. 404 Not Found: documento não encontrado. Após a linha inicial há os cabeçalhos, usados da mesma forma que em pedidos HTTP. Por fim, pode haver o corpo da mensagem (opcional). Um exemplo de mensagem de resposta segue abaixo: HTTP/1.1 200 OK Date: Thu, 23 May 2013 20:43:31 GMT Server: Apache Last-Modified: Fri, 10 May 2013 14:09:58 GMT ETag: "757236-40-4dc5db8df272a" Accept-Ranges: bytes Content-Length: 64 Vary: Accept-Encoding Connection: close Content-Type: text/plain; charset=UTF-8 Este é um pequeno arquivo de teste, sem informação útil ... 67.6.1.3 Atividade Prática 1. Instale o servidor WWW Apache 2. Documentação [3] sudo apt-get install apache2 2. Verifique a configuração do apache Nos arquivo "/etc/apache2/apache2.conf" e "/etc/apache2/sites-enabled/000-default", interprete os valores das seguintes variáveis: DocumentRoot - local onde ficam as páginas web ErrorLog - registro de erros (ex.: página não encontrada) No Apache o ErrorLog encontra-se em: /var/log/apache2/error.log CustomLog - registro padrão (ex.: acessos) No Apache o CustomLog encontra-se em: /var/log/apache2/access.log 3. Crie uma página WEB no servidor instalado e acesse-a. Crie a página web em DocumentRoot/minha_pagina.html, com o seguinte conteúdo: <html> <head> <title>Página de teste...</title> </head> <body> <p>Página Teste!</p> </body> </html> Acesse a página criada apontando um cliente WWW para http://localhost/minha_pagina.html 4. Acesse as páginas instaladas nos computadores de seus colegas utilizando seus IPs Exemplo: aponte um cliente WWW para http://192.168.1.12/minha_pagina.html 5. Instale o wireshark e capture os pacotes de comunicação HTTP, identificando as mensagens GET e suas respostas, como exposto acima. sudo apt-get install wireshark 67.7 20/03/15: Camada de Aplicação Camada de Aplicação (ver estes [slides]) Protocolos SMTP, IMAP, POP3, FTP e DNS. Resolução de exercícios (Lista 2) 67.8 27/03/15: Avaliação 1 Conteúdos abordados: Arquitetura Internet (Cap. 1 Kurose) e Camada de Aplicação (Cap. 2 Kurose). Revisão para avaliação (Lista 3). 67.9 03/04/15: Feriado (sexta-feira santa) 67.10 10/04/15: Camada de Transporte Vista de prova - Arquitetura Internet e Camada de Aplicação Camada de Transporte (ver estes [slides]) Resolução de exercícios (Lista 4) Resolução de exercícios (Lista 5) Até o momento nos concentramos nos serviços de rede (Camada de Aplicação). Afinal, são elas que usamos para nos comunicarmos através das redes de computadores. No entanto, aplicações dependem de outros protocolos para poderem se comunicar, os quais cuidam dos detalhes envolvidos na transmissão e recepção de mensagens em uma rede vasta como a Internet. As aplicações se comunicam por meio de mensagens. Cada protocolo de aplicação (HTTP, POP3, DNS, IMAP, SMTP, SIP, ...) tem seu formato de mensagem. Essas mensagens podem ser pequenas (ex: DNS, SIP) ou por vezes grandes (ex: SMTP, HTTP, POP3). De qualquer forma, a aplicação precisa que suas mensagens sejam transmitidas para o outro participante da comunicação, que está em um computador remoto. Para isso ela usa um protocolo de transporte. Algumas aplicações e protocolos de transporte na Internet Como já discutido, mais de uma aplicação pode existir em um mesmo computador. Por isso, uma das principais atribuições de um protocolo de transporte é identificar de qual aplicação é uma mensagem a ser transmitida, e para qual aplicação se destina uma mensagem recebida. Deve-se ter em mente que uma aplicação é representada por um programa em execução em um computador, portanto um protocolo de transporte possibilita a comunicação entre processos que estão sendo executados usualmente em computadores diferentes. Em nossas discussões anteriores chamamos isso de classificação das mensagens, mas o termo usado para expressar essa capacidade dos protocolos de transporte é multiplexação. No caso específico dos protocolos de transporte da Internet (TCP e UDP), um número de port é usado para fazer essa distinção, e por isso essa função é denominada multiplexação baseada em port. Uma comunicação entre aplicações é composta basicamente de duas informações principais: endereços dos hosts participantes e números de port dos processos. Os endereços são responsabilidade da Camada de Rede (onde há o protocolo IP), e os números de port são usados na Camada de Transporte (onde estão os protocolos TCP e UDP). Mas por que existem dois protocolos de transporte ? Talvez ajude a esclarecer essa questão se compararmos as necessidades das aplicações: Aplicação Tolerância a perdas Tolerância a atrasos Tamanhos de mensagens HTTP baixa média variável ... podem ser muito grandes (de poucos bytes a centenas de megabytes ou mais) SMTP baixa alta variável ... podem ser grandes (de centenas bytes a alguns megabytes) DNS média baixa pequenas (algumas centenas de bytes) POP3 baixa média variável ... podem ser grandes (de centenas bytes a alguns megabytes) SIP média média pequenas (algumas centenas de bytes) VoIP média baixa pequenas (tipicamente < 164 bytes) Durante o projeto e aperfeiçoamento dos protocolos da Internet, convergiu-se para a definição de dois protocolos de transporte: TCP (ver RFC 793): protocolo orientado a conexão, com garantia de entrega, controle de fluxo e controle de congestionamento. UDP (ver RFC 768): protocolo orientado a datagrama (não há conexão), sem garantia de entrega ou qualquer outra verificação ou controle. Basicamente faz somente a multiplexação baseada em port. Curiosidade: veja os anos em que foram publicados as especificações desses protocolos ... As diferenças entre eles serão melhor detalhadas nas próximas aulas. Hoje farems alguns experimentos para ter uma ideia de como se comportam as comunicações feitas com esses protocolos. 67.11 17/04/15: Camada de Transporte Camada de Transporte (ver estes [slides) Construção de um protocolo de transferência confiável Volta-N, Retransmissão Seletiva Resolução de exercícios (Lista 6) Resolução de exercícios (Lista 7) 67.12 24/04/15 Camada de Transporte Avaliação de recuperação: Arquitetura Internet e Camada de Aplicação (17h - Sala 3) 67.13 Atividade As atividades de hoje buscarão mostrar as características básicas de comunicações com protocolos de transporte. 67.13.1 Aplicações e protocolos de transporte Faça uma rápida pesquisa e descubra que protocolos de transporte (e que ports) são usados por estas aplicações: SSH FTP BitTorrent emule WINS Compartilhamento de arquivos do Windows Windows Terminal Service NFS Openvpn RADIUS DHCP SNMP NTP LDAP Mysql Postgresql Oracle RDBMS Syslog CUPS Que protocolo de transporte predomina nesse conjunto ? 67.13.2 Tipos de protocolos de transporte: TCP x UDP Nestes experimentos, serão evidenciadas diferenças entre os protocolos TCP e UDP. 67.13.2.1 Experimento 1 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 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 ? Abra um terminal e execute o seguinte comando para fazer o download de um arquivo a ser usado no experimento: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso Observe o tamanho do arquivo transferido ... ele deve ter exatamente 832569344 bytes (cerca de 832 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. A primeira transferência será feita usando o protocolo TCP da seguinte forma: No computador receptor execute: nc -l 5555 > arquivo No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): time nc 192.168.1.X 5555 < ubuntu.iso 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: No computador receptor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x receptor). No computador receptor execute: ./receptor 5555 > arquivo No computador transmissor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x transmissor). No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): ./transmissor 192.168.1.X 5555 < ubuntu.iso Quando completar a transferência, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original ? E quanto tempo levou para transmiti-lo ? Compare as transferências feitas com TCP e UDP. O que eles têm em comum ? Que diferenças lhe pareceram mais pronunciadas ? Como isso deve afetar as aplicações que usam esses protocolos ? 67.13.2.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, como mostrado na figura abaixo: Abra um terminal em seu computador, e nele execute este comando: wget http://tele.sj.ifsc.edu.br/~tisemp/RES/ubuntu.iso 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á se logar em um dos computadores do laboratório e 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 ? Finalmente, o professor irá repetir a transferência porém com mais dois 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: Abra dois terminais. Em um deles execute este comando: watch -n 1 ls -l arquivo ... e no outro execute: ./receptor 5555 > arquivo O professor irá transmitir o arquivo a partir do servidor. Observe o tamanho do arquivo, que deverá aumentar. 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 comparam as transferências usando TCP e UDP ? 67.14 01/05/15: Feriado (dia do trabalho) 67.15 08/05/15: Camada de Transporte Revisão da Camada de Transporte (30min da aula) Avaliação Camada de Transporte 67.16 15/05/15: Camada de Rede Vista de prova: Camada de Transporte Introdução à Camada de Rede (Slides) Realização de exercícios Camada de Rede (Lista 7) 67.17 22/05/15: Camada de Rede Roteamento hierárquico Endereçamento IP Exercícios endereçamento IP (Sub-redes) 67.18 29/05/15: Camada de Rede (paralisação) Exercícios endereçamento IP (Sub-redes) 67.19 05/06/15: Camada de Rede Feriado Nacional (Corpus Christi) 67.20 12/06/15: Palestra sobre IEEE 802.11 Apresentação tecnologia Wi-Fi (padrão IEEE 802.11) Horário: 19h - 20h:20min. Palestrante: Prof. Emerson Melo - DTIC/IFSC Resolução de exercícios Segmentação de redes (Lista 10) Exercícios de revisão (parte teórica) (Lista 11) 67.21 19/06/15: Camada de Rede Correção Lista de Exercícios (revisão) Avaliação Camada de Rede 67.22 26/06/15: Camada de Rede Vista de prova (Camada de Rede) Avaliações de recuperação finais da disciplina (Camada Aplicação, Transporte e Rede) 67.23 03/07/15: Encerramento da Disciplina Viagem ISCC 2015 - Larnaca, Chipre Conceitos finais:

Semestre 2014-2 - Prof. Arliones Hoeller

2014-2 - Prof. Arliones Hoeller 68 TecTel: Redes de Computadores - 2014-2 - Prof. Arliones Hoeller Professor: Arliones Hoeller Turma: 1110231 Encontros: segundas das 18:30 às 22:30 Atendimento paralelo: quintas das 9:40 às 10:35 e das 14:25 às 15:20 Grupo de discussão Web: a definir. Email: a definir. 68.1 Plano de Ensino 69 Notas Matrícula A1 A2 A3 A4 Final 141000719-7 F (C) A A A A 141000804-5 B B C D (D) C 141000583-6 A C A C B 141000270-5 D (D) B C D (D) D 141001276-0 C B A C B 141001095-3 C D F F D 141000292-6 F F F F D 141001259-0 A A B B A 141001023-6 A B A D (D) B F: faltou (?): conceito da recuperação negrito: com direito a recuperação 70 Curiosidades Telex O Ciberespaço e as Redes de Computadores na Construção de Novo Conhecimento Uma história das Redes de Computadores Breve História da Internet 71 Materiais de aula 71.1 Slides Arquivo:Slides-kurose-cap1.pdf Arquivo:Slides-kurose-cap2.pdf Arquivo:RCO-semprebom-cap3.pdf Arquivo:RCO-semprebom-cap4.pdf 71.2 Listas de exercícios Lista de exercícios 1 Lista de exercícios 2 Lista de exercícios 3 Lista de exercícios 4 Lista de exercícios 5 Lista de exercícios 6 Lista de exercícios 7 Lista de exercícios 8 Lista de exercícios 9 71.3 Apostilas Apostila de Redes de Computadores do Prof. Evandro Cantú 72 Aulas 72.1 04/08/14: Apresentação da disciplina Apresentação da disciplina, plano de aula, laboratórios e métodos de avaliação. Revisão de conceitos do Projeto Integrador I Introdução a Redes de Computadores [slides] 72.2 11/08/14: Comutação por Circuitos, Comutação de Pacotes, Lab01: Ferramentas básicas de redes Introdução a Redes de Computadores [slides] Nesta atividade serão vistos algumas ferramentas utilizadas para obter informações relacionadas às configurações de uma rede de computadores. Roteiro 1 (ping, ifconfig, traceroute) Roteiro Rápido do SS - Socket Statistics 72.3 18/08/14: Modelos de serviço, Redes de acesso, Lab 3: Captura de pacotes na rede (Wireshark) Introdução a Redes de Computadores [slides] Lab 3: Captura de pacotes na rede (Wireshark) Roteiro TCPDump Wireshark e manuais Números de portas (IANA) 72.4 25/08/14: Arquiteturas em Camadas, Comunicação entre processos Introdução a Redes de Computadores [slides] Roteiro 72.5 01/09/14: Protocolos da camada de aplicação / Lab 4: Uso de aplicações da Internet (HTTP) Revisão - Camadas de Protocolos (ver slides da primeira parte da disciplina) A camada de aplicação (ver estes [slides]) Ver Capítulo 27 do livro Comunicação de Dados e Redes de Computadores, 4a ed., de Behrouz Forouzan. Na arquitetura de redes da Internet, são as aplicações que se comunicam, gerando dados no transmissor e consumindo-os no receptor. Aplicações residem em equipamentos de rede, e se comunicam através da rede usando os serviços das camadas inferiores Aplicações são processos que se comunicam através da rede (lembre que processos são programas em execução). Exemplos de aplicações são navegadores web (Firefox, Chrome) e bate-papo (Skype, GTalk). A comunicação pode ser feita de diferentes formas, de acordo com o modelo de comunicação adotado pela aplicação em questão. O modelo de comunicação define o papel de cada participante da comunicação, e por consequência acaba determinando como a comunicação acontece (quem a inicia, quando se transmitem e recebem mensagens). Três modelos conhecidos são: Cliente-Servidor: um participante é o cliente, e o outro o servidor. O cliente inicia a comunicação, ao enviar uma mensagem ao servidor pedindo algum serviço. Cabe ao servidor responder aos pedidos dos clientes. Este é o modelo mais comum de se encontrar em aplicações, tais como correio eletrônico, WWW, bancos de dados, compartilhamento de arquivos e outros. Peer-to-Peer (P2P): cada participante pode ser tanto cliente quanto servidor, assim qualquer um pode iniciar uma comunicação. Tornou-se popular com aplicações como compartilhamento de arquivos (ex: BitTorrent, eDonkey) e sistemas de chamadas VoIP. Publisher/Subscriber: neste modelo existem os publicadores de conteúdo (publishers) e os assinantes ou interessados (subscribers). Os assinantes registram seus interesses por demais tipos de dados (isso é, assinam canais de dados). Os publicadores eventualmente divulgam dados, que são distribuídos aos assinantes. Não é comum de ser encontrado em aplicações, porém é o modelo usado para detecção de presença em aplicações de conversa on-line (Skype, Gtalk). Cada aplicação usa diretamente os serviços da camada de transporte, e indiretamente os de camadas inferiores. Assim, para uma aplicação é a camada de transporte que envia e recebe suas mensagens. Como visto na aula passada, um serviço importante da camada de transporte é classificar e separar os pacotes recebidos de acordo com a aplicação que deve recebê-los, e para isso se um número chamado de port. O número de port pode ser entendido como um endereçador de aplicações dentro de um mesmo host. Vimos também que a camada de transporte na Internet apresenta dois protocolos, e ambos usam números de port para separar os pacotes de acordo com a comunicação que os contém: TCP: usado por aplicações quando há necessidade de ter certeza de que os dados foram recebidos. Esse protocolo faz retransmissões automáticas no caso de perdas de mensagens. Para estabelecer a comunicação, ele usa o conceito de conexão (em que os dois participantes entram em acordo sobre a comunicação, e lembram disso a cada mensagem enviada e recebida) e realiza confirmações das mensagens recebidas. Este é o protocolo de transporte mais usado. UDP: usado quando não é imprescindível ter certeza de que cada mensagem chegou ao destino, ou o custo de fazer isso com TCP não compensar. Não há conexões, tampouco confirmações. Exemplos de uso são chamadas VoIP e consultas DNS. O estudo das aplicações da Internet inicia com WWW, que foi responsável por popularizar a Internet nos anos 90 e ainda é a aplicação mais difundida e acessada. 72.5.1 WWW e protocolo HTTP WWW (World Wide Web) é um sistema de documentos em hipermidia que são ligados e acessados na Internet (FONTE: Wikipedia). Tendo início em 1990 como uma aplicação experimental desenvolvida por Tim Berners-Lee, que então trabalhava no CERN, na Suíça, em pouco tempo caiu no gosto de demais usuários e se difundiu. WWW se tornou tão popular que para muitos passou a ser sinônimo de Internet (equivocadamente). Por trás da sua rápida aceitação há um protocolo de aplicação simples e funcional, além claro do modelo de informação em hipermidia que agradou as pessoas. Se o WWW é um sistema de documentoshipermidia online mantido de forma distribuída na Internet, o protocolo HTTP (Hypertext Transfer Protocol) é o protocolo usado para acessá-los. Esse protocolo segue o modelo cliente-servidor, e as comunicações são feitas com mensagens de pedido e resposta. Um cliente (navegador web) envia uma mensagem HTTP de pedido a um servidor web, que a responde com uma mensagem de resposta contendo o conteúdo solicitado. O protocolo HTTP usa o protocolo TCP para transmitir suas mensagens. 72.5.1.1 Mensagens de pedido HTTP Mensagens HTTP de pedido possuem a seguinte estrutura: Método URI HTTP/versão_do_protocolo Cabeçalho1: valor do cabeçalho1 Cabeçalho2: valor do cabeçalho2 Cabeçalho3: valor do cabeçalho3 CabeçalhoN: valor do cabeçalhoN corpo da mensagem A primeira linha usa o campo método para indicar o tipo de pedido a ser realizado. O método HTTP pode ser entendido como um comando a ser realizado pelo servidor. Os métodos mais comuns são: GET: obtém um documento. POST: envia algum conteúdo e obtém como resposta um documento. HEAD: obtém informações sobre um documento. O campo URI (Uniform Resource Indicator) identifica o documento que o servidor deve acessar. Ele se aparenta com um caminho de arquivo (pathname), porém possui algumas extensões para poder enviar informação adicional. Os cabeçalhos servem para complementar o pedido, informando ao servidor mais detalhes sobre o que está sendo requisitado. Por fim, o corpo da mensagem é opcional, podendo conter dados a serem enviados ao servidor quando necessário. Tendo entendido os componentes de um pedido HTTP, segue abaixo um exemplo de uma requisição real (note que ela não possui corpo de mensagem): GET /wiki/ HTTP/1.1 Host: wiki.sj.ifsc.edu.br User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Cookie: wiki2010UserID=614; wiki2010UserName=Msobral; wiki2010Token=4ed97239498a2fc74596b0f0a62331b5; wiki2010_session=f4e6b1hl4ctlkbpe5gc5gkosi4 Connection: keep-alive If-Modified-Since: Mon, 20 May 2013 00:38:20 GMT 72.5.1.2 Mensagens de resposta HTTP Mensagens HTTP de resposta possuem a seguinte estrutura: HTTP/versão_do_protocolo status info Cabeçalho1: valor do cabeçalho1 Cabeçalho2: valor do cabeçalho2 Cabeçalho3: valor do cabeçalho3 CabeçalhoN: valor do cabeçalhoN corpo da mensagem A linha inicial informa o resultado do atendimento do pedido (se teve sucesso ou não), contendo um código numérico de status seguido de uma breve descrição. Os códigos numéricos e info mais comuns são: 200 OK: pedido atendido com sucesso. 302 Moved Temporarily: o pedido pode ser atendido em outra URL. 401 Authorization Required: acesso negado, pois exige-se autenticação. 403 Forbidden: acesso negado em definitivo. 404 Not Found: documento não encontrado. Após a linha inicial há os cabeçalhos, usados da mesma forma que em pedidos HTTP. Por fim, pode haver o corpo da mensagem (opcional). Um exemplo de mensagem de resposta segue abaixo: HTTP/1.1 200 OK Date: Thu, 23 May 2013 20:43:31 GMT Server: Apache Last-Modified: Fri, 10 May 2013 14:09:58 GMT ETag: "757236-40-4dc5db8df272a" Accept-Ranges: bytes Content-Length: 64 Vary: Accept-Encoding Connection: close Content-Type: text/plain; charset=UTF-8 Este é um pequeno arquivo de teste, sem informação útil ... 72.5.1.3 Atividade Prática 1. Instale o servidor WWW Apache 2. Documentação [4] sudo apt-get install apache2 2. Verifique a configuração do apache Nos arquivo "/etc/apache2/apache2.conf" e "/etc/apache2/sites-enabled/000-default", interprete os valores das seguintes variáveis: DocumentRoot - local onde ficam as páginas web ErrorLog - registro de erros (ex.: página não encontrada) CustomLog - registro padrão (ex.: acessos) 3. Crie uma página WEB no servidor instalado e acesse ela. Crie a página web em DocumentRoot/minha_pagina.html, com o seguinte conteúdo: <html> <head> <title>Página de teste...</title> </head> <body> <p>Página Teste!</p> </body> </html> Acesse a página criada apontando um cliente WWW para http://localhost/minha_pagina.html 4. Acesse as páginas instaladas nos computadores de seus colegas utilizando seus IPs Exemplo: aponte um cliente WWW para http://192.168.1.12/minha_pagina.html 5. Instale o wireshark e capture os pacotes de comunicação HTTP, identificando as mensagens GET e suas respostas, como exposto acima. sudo apt-get install wireshark 72.5.2 Experimento 1: Comunicação de dados A comunicação dados pode ser entendida como troca de informação entre dois dispositivos através de algum meio de comunicação. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes: A mensagem: a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de bits (dígitos binários). Transmissor: dispositivo que transmite a mensagem. Receptor: dispositivo que recebe a mensagem. Meio de comunicação: caminho físico por onde viaja a mensagem do transmissor até o receptor. Protocolo: conjunto de regras que governa a comunicação de dados. Neste experimento, vamos interagir com um servidor web e identificar esses cinco componentes. Usando um navegador, acesse os seguintes links: http://tele.sj.ifsc.edu.br/~tisemp/RES/arquivo.txt http://tele.sj.ifsc.edu.br/~tisemp/RES/teste.html Quais são os componentes do sistema de comunicação de dados ? Vamos repetir o acesso aos links acima, porém sem usar o navegador. A ideia é que nós façamos o papel de navegador. Isso deve ser feito com os seguintes passos: Abra um terminal de texto no Linux (menu Aplicativos->Acessórios->Terminal). Execute este comando: telnet tele.sj.ifsc.edu.br 80 Após aparecer esta linha: Trying 200.135.37.75... Connected to integrado.sj.ifsc.edu.br. Escape character is '^]'. digite o seguinte: GET /~tisemp/RES/arquivo.txt HTTP/1.0 e em seguida tecle ENTER duas vezes. Agora execute o seguinte para acessar o outro link: telnet tele.sj.ifsc.edu.br 80 Após aparecer esta linha: Trying 200.135.37.75... Connected to integrado.sj.ifsc.edu.br. Escape character is '^]'. digite o seguinte: GET /~tisemp/RES/teste.html HTTP/1.0 e em seguida tecle ENTER duas vezes. Compare o resultado das execuções desses comandos com o que se viu no navegador. Qual a diferença em cada caso ? Identifique os componentes do sistema de comunicação de dados nesse acesso direto. 72.5.3 Experimento 2: transmissão de mensagens de aplicação Neste experimento, serão observadas as mensagens transmitidas entre um navegador e um servidor web, e com base nelas devem ser identificados: os protocolos envolvidos e suas respectivas camadas dentro do modelo da Internet. os encapsulamentos realizados por esses protocolos. as informações que possibilitam identificar univocamente o navegador e o servidor web durante sua comunicação. Execute o wireshark em seu computador: abra um terminal em Aplicativos->Terminal e execute sudo wireshark Na tela do wireshark, ative a captura na interface de rede eth0 (ela está listada no lado esquerdo). Usando um navegador, acesse o link http://tele.sj.ifsc.edu.br/~tisemp/RES/arquivo.txt. Interrompa a captura no wireshark, clicando no menu Capture->Stop. Na tela do wireshark, escreva http na caixa de edição Filter, e em seguida clique em Apply. Selecione o primeiro pacote da lista. Em seguida, clique no menu Analyze->Follow TCP Stream. Uma tela se abrirá, e nela você poderá observar os dados transmitidos pelo navegador (em vermelho) e pelo servidor web (em azul). Esses são os dados da conversação ... todo o resto são informações de outros protocolos usadas para realizar a comunicação. Voltando à lista de pacotes mostrada pelo wireshark, observe a sequência de pacotes. Com base nela identifique: os protocolos envolvidos em que camada cada um deles atua que informações mantidas nesses protocolos possibilitam identificar o navegador e o servidor web. Cada protocolo transmite e recebe pacotes com um determinado formato, composto por cabeçalho e dados carregados (payload). Identifique nos pacotes recebidos que partes correspondem a cabeçalho e dados carregados. DESAFIO: imagine que foram capturados pacotes em uma rede, em que se monitoram as comunicações de uma determinada pessoa sob investigação. O investigador deve analisar esses pacotes em busca de arquivos que tenham sido transmitidos. Os pacotes capturados foram salvos em um arquivo de captura do wireshark, o qual se encontra aqui: captura.log Para visualizar os pacotes, use o menu File->Open do wireshark. Verifique se existem arquivos transmitidos dentro desses pacotes, e, caso afirmativo, extraia-os e visualize seus conteúdos. Para cada arquivo encontrado, informe: qual o protocolo de aplicação usado para transmiti-lo que computador foi usado para acessá-los, e qual servidor foi acessado. 72.5.4 Experimento 3: pacotes que passeiam pela rede Neste experimento, deve-se evidenciar a transmissão de pacotes desde o transmissor até o receptor, que pode estar em outra rede. Como já foi discutido, para que isso seja possível deve haver uma forma de transmitir esses pacotes para dispositivos intermediários na rede, que os encaminham para seus destinos. Quer dizer, os pacotes devem ser roteados até seu receptor. Execute o wireshark em seu computador, e ative a captura de pacotes. Usando um navegador, acesse esta página. Observe os pacotes transmitidos entre seu computador e o computador que atendeu seu pedido e respondeu com o conteúdo da página (isso é, o servidor web). que informações identificam essa comunicação ? quais os protocolos envolvidos ? O servidor web está fora da rede do laboratório. Assim, os pacotes precisaram ser encaminhados pelo computador do professor para a rede da escola (lembre que o computador do professor fica entre a rede do laboratório e a do Câmpus). Portanto, nesse computador deve ser possível visualizar seus pacotes sendo transmitidos em direção ao servidor, assim como a resposta do servidor. Observe esses pacotes no wireshark executado pelo professor. as informações que identificam suas comunicações são as mesmas que as identificadas em seu próprio computador ? Acesse a página da UFSC. Enquanto isso, observe na tela do projetor do laboratório o wireshark no computador do professor capturando seus pacotes. que informações identificam suas comunicações ? O servidor web da UFSC está em outra rede. Com certeza vários equipamentos intermediários precisarão ajudar para que os pacotes cheguem lá, e as respostas voltem para os seus computadores. Para saber por onde seus pacotes passam, use este comando: traceroute -n www.ufsc.br que informação está sendo usada para encaminhar os pacotes até o servidor web da UFSC ? que protocolo mantém e usa essa informação ? 72.5.5 Experimento 4: Aplicação Web e o protocolo HTTP Nas atividades abaixo sempre use o wireshark para observar as comunicações realizadas. Preste atenção aos encapsulamentos realizados e os protocolos envolvidos, assim como as informações mantidas por esses protocolos. Em particular, observe o endereço IP (mantido pelo protocolo IP na camada de rede) e números de porta (mantidos por protocolos TCP e UDP na camada de transporte). Para criar um servidor web muito simples, siga estes passos: Baixe este arquivo. Execute este comando: nc -l 8080 < resposta > pedido Em seu navegador, acesse a URL http://127.0.0.1:8080/. Observe o resultado na tela do seu navegador, e veja o conteúdo do arquivo pedido. Para rodar um servidor web pequeno, mas funcional, faça o seguinte: Baixe este arquivo. Execute estes comandos: tar xzf monkey-1.1.1.tar.gz cd monkey-1.1.1 ./configure --prefix=/home/aluno/monkey make make install Edite o arquivo /home/aluno/monkey/conf/sites/default e modifique a seguinte linha: DocumentRoot /home/aluno/ Edite o arquivo /home/aluno/monkey/conf/plugins.load e verifique se ele contém o seguinte: # Directory Listing Plugin # ======================== # When a directory is requested, this plugin will show # an HTML list of the available content to the client. # Load /home/sobral/tmp/monkey/plugins/monkey-dirlisting.so Execute o servidor web: /home/aluno/monkey/bin/monkey Com seu navegador, acesse http://127.0.0.1:2001/ Experimente navegar pelos links mostrados. Acesse as seguintes páginas, identificando o método HTTP, a URI, a versão do protocolo e os cabeçalhos enviados e recebidos. Verifique também se há corpo da mensagem no pedido ou na resposta: File Lake Test https://www.ifsc.edu.br/ Acesse a página abaixo, e use o wireshark para acompanhar a comunicação. O que se pode ver de diferente em relação à atividade anterior ? Formulário Acesse a página abaixo, e observe quantas requisições HTTP são geradas a partir desse acesso. Como você explica essa quantidade de requisições ? Diversos 72.5.6 Para pensar Para que o protocolo HTTP é usado atualmente além de acesso a documentos na web? Faça uma pesquisa sobre isso. Pesquise o significado dos cabeçalhos HTTP vistos nos acessos feitos na aula de hoje. 72.5.7 Considerações finais Os experimentos realizados buscaram introduzir alguns mecanismos envolvidos na comunicação através de uma rede de computadores. Tais mecanismos são implementados por alguns protocolos, lembrando que um protocolo especifica o formato dos pacotes transmitidos e as regras de comunicação para intercâmbio desses pacotes. Durante os experimentos, teve-se contato com alguns protocolos importantes envolvidos em comunicações na Internet, assim como algumas das principais informações definidas e usadas por esses protocolos. A visualização da hierarquia em que operam esses protocolos buscou mostrar o modelo de camadas da Internet, que define como deve funcionar um sistema que se comunica nesse tipo de rede. Para pensar: Para cada experimento, desenhe um diagrama de rede que mostre os equipamentos envolvidos. Para cada equipamento, desenhe também o modelo de camadas da Internet. Por fim, mostre o fluxo dos pacotes através dessas camadas (desde o transmissor até o receptor), indicando: que protocolo foi usado em cada camada. que serviço cada protocolo realizou. que informações foram usadas por cada protocolo. 72.6 08/09/14: Lista de exercícios / Revisão / Prova 1 72.7 15/09/14: Lab 5: Uso de aplicações da Internet (DNS) 72.7.1 DNS: Domain Name System 72.7.1.1 Uma breve descrição sobre DNS O texto abaixo foi obtido de Como funcionam os servidores de domínio (DNS). Se você gasta algum tempo na internet mandando e-mails ou navegando pela web, está utilizando servidores de domínios sem mesmo perceber. O sistema DNS (Domain Name System) forma uma das maiores, mais ativas e mais distribuídas bases de dados do planeta. Sem o DNS, a internet acabaria rapidamente. Quando você navega na internet ou manda uma mensagem de e-mail, você estará utilizando um nome de domínio. Por exemplo, a URL "http://www.hsw.com.br" contém o nome de domínio howstuffworks.com. Assim como o endereço de e-mail "iknow@howstuffworks.com." Nomes como “howstuffworks.com” são facilmente lembrados pelas pessoas, mas não ajudam em nada as máquinas. Todas elas usam endereços de IP para se referirem umas às outras. A máquina a que as pessoas se referem como "www.hsw.com.br", por exemplo, possui o endereço IP 216.183.103.150. Toda vez que se usa um nome de domínio, os servidores de domínios da internet (DNS) estarão traduzindo os nomes de domínio legíveis em endereços de IP reconhecidos pelas máquinas. Durante um dia de navegação e envio de e-mails, os servidores de domínios podem ser acessados inúmeras vezes. Os servidores de domínios traduzem nomes de domínios em endereços de IP. Isto parece uma tarefa simples, e seria, exceto por cinco razões: Atualmente existem bilhões de endereços de IP em uso e a grande maioria das máquinas possui um nome legível associado. Alguns bilhões de requisições são feitas ao DNS todos os dias. Uma única pessoa pode fazer várias requisições em apenas um dia e existem muitas pessoas e máquinas usando a Internet diariamente. Nomes de domínio e endereços de IP podem mudar frequentemente (até mesmo diariamente). Novos nomes de domínio são criados todos os dias. Milhões de pessoas trabalham na mudança e no acréscimo de nomes de domínio e endereços de IP constantemente. O sistema DNS é uma base de dados, e nenhuma outra em todo o globo recebe tantas requisições. É a única, também, modificada por milhões de pessoas todos os dias. Isso é o que faz o sistema DNS tão singular. 72.7.1.2 Endereços IP Para manter todas as máquinas da Internet em perfeito funcionamento, cada uma delas é associada a um único endereço chamado endereço de IP. IP significa protocolo da Internet, e é um número de 32 bits normalmente apresentado como quatro “octetos” em um “número decimal pontuado.” Um endereço de IP comum se parece com esse: 216.183.103.150 Os quatro números em um endereço de IP são chamados de octetos por possuírem valores entre 0 e 255 (256 possibilidades por octeto). Toda máquina na Internet possui seu próprio endereço de IP (na verdade, tem ao menos UM endereço). Um servidor tem um endereço IP estático, que raramente muda. Uma máquina doméstica, que se conecta através de um modem, muitas vezes possui um endereço de IP designado pelo provedor no momento da conexão. Este endereço IP é único a cada sessão e pode mudar na próxima vez que houver uma conexão. Considerando isto, um provedor precisa apenas de um endereço IP para cada modem que dá suporte, ao invés de um para cada cliente (isso vale para ADSL ou conexões 3G também). Se você estiver usando um computador com sistema operacional Linux, você pode ver seu endereço IP por meio do seguinte comando: aluno@M2:~$ ifconfig eth0 Link encap:Ethernet Endereço de HW 84:2b:2b:7c:54:f5 inet end.: 172.18.80.251 Bcast:172.18.127.255 Masc:255.255.128.0 endereço inet6: fe80::862b:2bff:fe7c:54f5/64 Escopo:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1 pacotes RX:3634552 erros:0 descartados:145885 excesso:0 quadro:0 Pacotes TX:608253 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:1000 RX bytes:888269786 (888.2 MB) TX bytes:195176030 (195.1 MB) IRQ:21 Memória:f7fe0000-f8000000 No exemplo acima, a interface de rede eth0 (que é o dispositivo de hardware ou software que liga o computador fisicamente a Internet) possui o endereço IP 172.18.80.251. As demais informações descrevem outros parâmetros e características da interface de rede, e serão estudados em momento oportuno (mas não agora ;-). Para que as máquinas acessem a Internet, é necessário apenas um endereço de IP para se conectar a um servidor. Você poderia digitar em seu navegador, por exemplo, a URL http://200.135.190.28 e alcançaria a máquina que contém o servidor web do IFSC. Porém essa forma de endereçar servidores na Internet é pouco prática. Nomes de domínio são estritamente usados para a nossa conveniência. 72.7.1.3 Nomes de domínios Se precisássemos lembrar de todos os endereços de IP das páginas da Web que visitamos diariamente, ficaríamos malucos. Seres humanos não são bons em lembrar séries de números. No entanto, somos bons na lembrança de palavras, por isso usamos os nomes de domínios. Você possui, provavelmente, vários nomes de domínios guardados em sua cabeça. Como por exemplo: www.hsw.com.br - um nome típico www.google.com - o nome mais conhecido no mundo www.mit.edu - um nome EDU (educacionais) bastante popular encarta.msn.com - um servidor da Web que não começa com www www.bbc.co.uk - um nome que utiliza quatro partes em vez de três ftp.microsoft.com - um servidor FTP (em inglês) ao invés de um servidor da Web As partes COM, EDU e UK destes servidores são chamadas de domínios principais ou domínios de primeiro nível. Existem vários domínios principais, incluindo COM, EDU, GOV, MIL, NET, ORG e INT, assim como as singulares combinações de duas letras para cada país (em inglês). Em cada domínio principal existe uma enorme lista de domínios secundários. No domínio principal COM, por exemplo, tem-se: howstuffworks google msn microsoft ... e milhões de outros. Cada nome no domínio principal COM precisa ser único, mas podem existir réplicas entre os domínios. Por exemplo, howstuffworks.com e howstuffworks.org são duas máquinas completamente diferentes. No caso de bbc.co.uk, este é um domínio terciário. São possíveis até 127 níveis, no entanto, mais do que quatro são raros. A palavra mais à esquerda, como www ou encarta, é nome de hospedagem, que determina o nome de uma máquina específica (com um endereço de IP próprio) em um domínio. Um domínio concedido pode conter milhões de nomes de hospedagem desde que sejam únicos. Por causa desta determinação de todos os nomes em um domínio serem únicos, é necessário que uma entidade controle a lista destes servidores e garanta que nenhuma duplicação aconteça. O domínio COM, por exemplo, não pode conter dois nomes iguais e uma empresa chamada Network Solutions (em inglês) é a responsável por manter esta lista. Ao registrar um nome de domínio, o processo passa por um dos inúmeros registradores que trabalham na Network Solutions para adicionar nomes à lista. Ao mesmo tempo, é mantida uma base de dados chamada whois (em inglês) que contém informações sobre o proprietário e o servidor de cada domínio. Se você acessar o formulário whois (em inglês), encontrará informações acerca de qualquer domínio existente. Apesar de ser importante possuir uma autoridade central cuidando da base de dados referente aos nomes no domínio principal COM (e nos outros), você pode não querer centralizar a base de dados de todas as informações do domínio. A Microsoft, por exemplo, tem inúmeros endereços de IP e de nomes de hospedagens. Esta empresa quer manter seu próprio servidor de domínio pelo microsoft.com. Similarmente, a Grã-Bretanha quer administrar os domínios principais uk e a Austrália os domínios au, assim como nós brasileiros queremos administrar os domínios br. Por esta razão, o sistema DNS é um sistema partilhado. A Microsoft é completamente responsável pela manutenção do servidor microsoft.com: ela mantém as máquinas que implementam sua parte do sistema DNS, podendo mudar a base de dados de seu domínio sempre que necessitar, pois possui seus próprios servidores de domínio. Todo domínio possui um servidor em algum lugar, responsável por lidar com as requisições, onde há uma pessoa mantendo os registros deste DNS. Esta é uma das partes mais extraordinárias deste sistema: ele está completamente espalhado por todo o planeta em milhões de máquinas, administradas por milhões de pessoas e, ainda assim, se comporta como uma base de dados única e integrada. 72.7.1.4 Servidores DNS Servidores DNS fazem duas coisas o tempo todo: Aceitam solicitações de programas para converter nomes de domínios em endereços de IP. Aceitam solicitações de outros servidores para converter nomes de domínios em endereços de IP. Quando uma solicitação chega, o servidor pode exercer uma das quatro opções: Pode responder diretamente com um endereço de IP, por já conhecer previamente este endereço do domínio. Pode contatar outros servidores e tentar encontrar o endereço de IP para que foi solicitado, um processo que pode ser repetido várias vezes. Pode dizer: “eu não sei o endereço de IP para o domínio solicitado, mas aqui está o endereço de IP de um servidor que sabe mais do que eu.” Pode retornar uma mensagem de erro, pois o domínio solicitado é inválido ou inexistente. Ao digitar uma URL em seu navegador, o primeiro passo que este faz é converter o nome do domínio e da hospedagem em um endereço IP, para que o navegador solicite uma página da web à máquina que possui esse endereço de IP. Para fazer esta conversão, o navegador se comunica com um servidor DNS. Ao configurar seu computador para se conectar a Internet, você (ou o software instalado para se conectar ao seu provedor) precisa informar ao computador qual o servidor DNS que deve ser usado para a conversão de nomes de domínios em endereços de IP. Para ver qual o servidor DNS configurado em seu computador (assumindo que ele esteja com Linux), use o comando nslookup: aluno@M2:~$ nslookup www.ifsc.edu.br Server: 200.135.37.65 Address: 200.135.37.65#53 Non-authoritative answer: Name: www.ifsc.edu.br Address: 200.18.10.13 72.7.1.5 A estrutura das informações mantidas no DNS Como deve ter ficado claro na seção anterior, 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 (na seção anterior isso foi denominado hospedagem). 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 br é o domínio do topo da hierarquia ao qual mail.sj.ifsc.edu.br pertence. Já edu é um subdomíno de br, ifsc um subdomínio de edu, 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. Clientes buscam informação no DNS usando uma biblioteca de resolução (resolver library), que envia as consultas para um ou mais servidores de nomes e interpreta as respostas. (tirado do manual do BIND9) Ver também o livro sobre DNS e BIND da O'Reilly. Você pode consultar a IANA para conhecer as delegações dos top-level domains como o .br, por exemplo. A IANA é responsável por coordenar estas delegações em confirmidade com suas políticas. Consulte: top-level domains 72.7.1.6 Registros DNS Cada rótulo na hierarquia DNS possui um conjunto de informações associadas a si. Essas informações são guardas em registros de diferentes tipos, dependendo de seu significado e propósito. Cada consulta ao DNS retorna assim as informações do registro pedido associado ao rótulo. Por exemplo, para ver o registro de endereço IP associado a www.ifsc.edu.br pode-se executar o comando dig (o resultado teve alguns comentários removidos): tisemp@M1:~$ dig sj.ifsc.edu.br mx ;; QUESTION SECTION: ;sj.ifsc.edu.br. IN MX ;; ANSWER SECTION: sj.ifsc.edu.br. 3600 IN MX 10 hendrix.sj.ifsc.edu.br. ;; AUTHORITY SECTION: sj.ifsc.edu.br. 3600 IN NS ns.pop-udesc.rct-sc.br. sj.ifsc.edu.br. 3600 IN NS ns.pop-ufsc.rct-sc.br. sj.ifsc.edu.br. 3600 IN NS hendrix.sj.ifsc.edu.br. ;; ADDITIONAL SECTION: hendrix.sj.ifsc.edu.br. 3600 IN A 200.135.37.65 ns.pop-ufsc.rct-sc.br. 11513 IN A 200.135.15.3 ns.pop-udesc.rct-sc.br. 37206 IN A 200.135.14.1 Cada uma das informações acima mostra um determinado registro e seu conteúdo, como descrito na tabela abaixo: Nome TTL Classe Registro Conteúdo do registro hendrix.sj.ifsc.edu.br. 3600 IN A 200.135.37.65 sj.ifsc.edu.br. 3600 IN NS hendrix.sj.ifsc.edu.br. sj.ifsc.edu.br. 3600 IN MX 10 hendrix.sj.ifsc.edu.br. Obs: TTL é o tempo de validade (em segundos) da informação retornada do servidor de nomes, e classe é o tipo de endereço (no caso IN equivale a endereços Internet). Os tipos de registros mais comuns são: Registro Descrição Exemplo A Endereço (Address) www.sj.ifsc.edu.br IN A 200.135.37.66 NS Servidor de nomes (Name Server) sj.ifsc.edu.br IN NS hendrix.sj.ifsc.edu.br. CNAME Apelido (Canonical Name) mail.sj.ifsc.edu.br IN CNAME hendrix.sj.ifsc.edu.br. MX Roteador de email (Mail Exchanger) sj.ifsc.edu.br IN MX mail.sj.ifsc.edu.br. SOA dados sobre o domínio (Start of Authority) sj.ifsc.edu.br IN SOA hendrix.sj.ifsc.edu.br. root.sj.ifsc.edu.br. 2009120102 1200 120 604800 3600 PTR Ponteiro para nome (Pointer) 65.37.135.200.in-addr.arpa IN PTR hendrix.sj.ifsc.edu.br. TXT Texto genérico (Text) sj.ifsc.edu.br IN TXT "v=spf1 a mx ~all" Uma zona assim é composta de um conjunto de registros com todas as informações dos domínios nela contidos. O conteúdo de uma zona, contendo o domínio example.com, pode ser visualizado abaixo: example.com 86400 IN SOA ns1.example.com. hostmaster.example.com. ( 2002022401 ; serial 10800 ; refresh 15 ; retry 604800 ; expire 10800 ; minimum ) IN NS ns1.example.com. IN NS ns2.smokeyjoe.com. IN MX 10 mail.another.com. IN TXT "v=spf1 mx -all" ns1 IN A 192.168.0.1 www IN A 192.168.0.2 ftp IN CNAME www.example.com. bill IN A 192.168.0.3 fred IN A 192.168.0.4 72.7.2 Atividade Usando o programa host ou dig, descubra os endereços IP associados aos seguintes nomes de domínios: mail.ifsc.edu.br www.sj.ifsc.edu.br www.google.com www.gmail.com www.amazon.co.uk www.gov.za www.sls.com.au Agora descubra quem é o servidor DNS responsável por cada um dos domínios dos nomes acima. Para isso consulte o valor do registro NS associado a esses domínios. Por exemplo, com o programa host isso pode ser feito assim: host -t ns ifsc.edu.br Descubra qual o servidor DNS usado pelo seu computador. Para isso é mais fácil usar o programa nslookup: # Use o nslookup para consultar o endereço IP de um nome qualquer ... nslookup www.ifsc.edu.br 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. Portanto, execute o wireshark: sudo wireshark ... e em seguida faça uma consulta DNS qualquer. Com base nisso identifique o seguinte: Quantas mensagens são trocadas entre cliente e servidor DNS para cada consulta ? Que protocolo de transporte é usado ? E que port ? Qual o formato das mensagens DNS ? Elas são textuais como as mensagens HTTP ou SMTP ? Qual o tipo de registro DNS acessado em cada consulta ? Que informações estão contidas nas respostas DNS ? Há algo além do que foi pedido ? Qual o tamanho das mensagens DNS ? O serviço DNS fornece outras informações além do endereço IP associado a cada nome de domínio. Por exemplo, como ele se pode descobrir que host recebe emails em um determinado domínio. Isso é utilizado pelos MTA mundo afora para entregarem emails para seus destinatários (lembre que isso se faz com o protocolo SMTP). Para descobrir essa informação, deve-se consultar o registro MX de um domínio. Por exemplo: host -t mx ifsc.edu.br Descubra quem é o servidor que recebe emails nos seguintes domínios: gmail.com hotmail.com uol.com.br ufsc.br Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim: dig -x 200.180.10.13 ... 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. Como explicado durante a aula, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões ?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado ? Descubra quem são os servidores raiz (topo de hierarquia DNS): host -t ns . Escolha um dos servidores listados, e use-o para fazer as consultas. Por exemplo: host -v -t a www.sj.ifsc.edu.br. j.root-servers.net. ... e observe a seção ;; AUTHORITY SECTION:. Ele contém a listagem de servidores DNS que podem atender sua consulta. Continue fazendo as consultas aos servidores DNS listados, até conseguir traduzir o nome requisitado. Quantos servidores DNS foi necessário consultar no total ? Repita esse exercício para os seguintes nomes de domínio: www.bbc.co.uk www.amazon.com www.thepiratebay.org www.reeec.illinois.edu www.inm.ras.ru 72.8 22/09/14: FTP e Email (SMTP, POP3, IMAP) A camada de aplicação (Arquivo:Slides-kurose-cap2.pdf) 72.8.1 File Transfer Protocol - FTP Material de apoio FTP: (Arquivo:Aula FTP.pdf) 72.8.1.1 Experimento FTP 1. Configure o seu micro para permitir conexões do tipo FTP, instalando um servidor, e verifique a configuração: sudo apt-get install proftpd-basic 2. Acesse o seu servidor FTP, o do seu vizinho, crie, modifique, apague arquivos e diretórios, etc. 3. Capture os pacotes de comunicação utilizando o wireshark e analise o que foi capturado. Quais as mensagens de aplicação utilizadas? Quais os nomes dos arquivos copiados? Foi possível visualizar os arquivos transmitidos? 72.8.2 Correio eletrônico O correio eletrônico (email) é um dos principais serviços na Internet. De fato foi o primeiro serviço a ser usado em larga escala. Trata-se de um método para intercâmbio de mensagens digitais. Os sistemas de correio eletrônico se baseiam em um modelo armazena-e-encaminha (store-and-forward) em que os servidores de email aceitam, encaminham, entregam e armazenam mensagens de usuários. Uma mensagem de correio eletrônico se divide em duas partes: Cabeçalhos: contém informações de controle e atributos da mensagem Corpo: o conteúdo da mensagem From: Roberto de Matos <roberto@eel.ufsc.br> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Smtp-Server: smtp.ufsc.br:roberto.matos@posgrad.ufsc.br Subject: =?iso-8859-1?Q?Teste_Ger=EAncia?= Message-Id: <0595A764-EEAE-41E7-99F0-80DC11FB5327@eel.ufsc.br> X-Universally-Unique-Identifier: 684c3833-bbbe-420b-8b66-d92d9a419bc0 Date: Wed, 20 Nov 2013 11:36:35 -0200 To: Roberto de Matos <roberto.matos@ifsc.edu.br> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Ol=E1 Pessoal, Hoje vamos aprender o funcionamento do Email!! Abra=E7o, Roberto= Na mensagem acima, os cabeçalhos são as linhas iniciais. Os cabeçalhos terminam quando aparece uma linha em branco, a partir de que começa o corpo da mensagem. 72.8.3 Funcionamento do email Um usuário que queira enviar uma mensagem para outro utilizará um aplicativo cliente de e-mail, também conhecido como MUA (Mail User Agent), ou Agente de Mensagens do Usuário. Ao terminar de redigir a sua mensagem, o MUA enviará a mensagem a um MTA (Mail Transport Agent) (Agente Transportador de Mensagens) que se encarregará então de entregar a mensagem ao MTA do destinatário, caso ele se encontre em outra máquina ou simplesmente colocar a mensagem na caixa postal do destinatário, caso ele se encontre no mesmo servidor. A transferência da mensagem entre o MUA e o MTA se efetua utilizando um protocolo chamado SMTP (Simple Mail Transfer Protocol) ou Protocolo Simples de Transferência de Mensagens. O protocolo SMTP será utilizado também entre o MTA do remetente e o MTA do destinatário. O servidor de e-mail do destinatário, ao receber uma mensagem para um dos seus usuários, simplesmente a coloca na caixa postal deste usuário. Se o usuário possui uma conta shell neste servidor, ele poderá ler os seus e-mails direto no servidor, caso contrário o usuário deverá transferir suas mensagens para sua máquina a fim de lê-las com o seu cliente de e-mail. A transferência de mensagens recebidas entre o servidor e o cliente de e-mail requer a utilização de outros programas e protocolos. Usualmente é utilizado para este fim o protocolo POP (Post Office Protocol), Protocolo de "Agência" de Correio, que recebe este nome por agir como uma agência de correios mesmo, que guarda as mensagens dos usuários em caixas postais e aguarda que estes venham buscar suas mensagens. Outro protocolo que pode ser utilizado para este mesmo fim é o IMAP (Internet Message Access Protocol), Protocolo para Acesso de Mensagens via Internet, que implementa, além das funcionalidades fornecidas pelo POP, muitos outros recursos. Os protocolos POP e IMAP são protocolos para recebimentos de mensagens, ao contrário do protocolo SMTP, que serve para enviar mensagens, logo, possuem funcionalidades diferenciadas, como por exemplo, autenticação do usuário. Para a utilização dos protocolos POP e IMAP é necessária a instalação do servidor apropriado, que vai ser o responsável por atender as solicitações do cliente de e-mail por novas mensagens. O recebimento de mensagens pelo cliente se dá através da solicitação do MUA do usuário ao seu servidor de e-mail, que após a autenticação do usuário vai informar se existem mensagens em sua caixa postal e quantas são. A seguir o MUA solicita a transferência das mensagens para a máquina local, finalizando assim o processo de troca de mensagens entre dois usuários. Os componentes da infraestrutura de email são: MUA (Mail User Agent): o aplicativo que o usuário usa para envio e acesso a mensagens. Atualmente é bastante comum MUA do tipo webmail, mas existem outros como Mozilla Thunderbird, KMail e Microsoft Outlook. MDA (Mail Delivery Agent): o servidor responsável por receber dos usuários mensagens a serem enviadas. Assim, quando um usuário quer enviar uma mensagem, usa um MUA que contata o MDA para fazer o envio. Exemplos de software são Postfix, Sendmail, Qmail e Microsoft Exchange. MTA (Mail Transport Agent): o servidor responsável por transmitir mensagens até seu destino, e receber mensagens da rede para seus usuários. Comumente faz também o papel de MDA. Exemplos de softwares são Postfix, Sendmail, Qmail e Microsoft Exchange. A figura abaixo ilustra uma infraestrutura de email típica. Os protocolos envolvidos são: SMTP (Simple Mail Transfer Protocol): usado para envios de mensagens entre MTAs, e entre MUA e MDA/MTA. IMAP (Internet Mail Access Protocol): usado por MUAs para acesso a mensagens armazenadas em caixas de email em servidores. Usa a porta 143/TCP ou 993/TCP (versão segura IMAPS) Pode manter diversas pastas no servidor, além da INBOX. Por default mantém as mensagens no servidor. Pode movimentar mensagens em ambas as direções (entre pastas no cliente e no servidor). POP (Post Office Protocol): Mesma finalidade que IMAP, porém com funcionalidade mais limitada. Se destina a situações em que o normal é copiar as mensagens parao computador do usuário, e então removê-las do servidor. Usa a porta 110/TCP ou 995/TCP (versão segura POP3S). Considera apenas uma pasta no servidor (INBOX). Por default descarrega as mensagens do servidor no cliente. LMTP (Local Mail Transfer Protocol): usado para entrega de mensagens entre MTA e MDA/MTA, sendo que o servidor de destino não mantém uma fila de mensagens (quer dizer, ele entrega diretamente na caixa de entrada de um usuário ou a encaminha imediatamente). 72.8.4 Endereçamento Endereços de email estão intimamente ligados ao DNS. Cada usuário de email possui um endereço único mundial, definido por um identificador de usuário e um domínio de email, escritos usando-se o símbolo especial @ (lê-se at, do original em inglês) para conectá-los: tele@ifsc.edu.br Nesse exemplo, o identificador de usuário é tele, e o domínio é ifsc.edu.br. Os domínios de email tem correspondência direta com domínios DNS. De fato, para criar um domínio de email deve-se primeiro criá-lo no DNS. Além disto, o domínio DNS deve ter associado a si um ou mais registros MX (Mail exchanger) para apontar os MTAs responsáveis por receber emails para o domínio. Por exemplo, o domínio DNS ifsc.edu.br possui esse registro MX: > dig ifsc.edu.br mx ;; QUESTION SECTION: ;ifsc.edu.br. IN MX ;; ANSWER SECTION: ifsc.edu.br. 3581 IN MX 5 hermes.ifsc.edu.br. ... e o domínio gmail.com: > dig gmail.com mx ;; QUESTION SECTION: ;gmail.com. IN MX ;; ANSWER SECTION: gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 30 alt3.gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 10 alt1.gmail-smtp-in.l.google.com. 72.8.5 Captura de pacotes SMTP e POP 72.8.5.1 Experimento 1: Captura de pacotes SMTP e POP3 usando cliente de e-mail Para que seja possível capturar pacotes dos protocolos SMTP e POP3, é necessário utilizar um programa MUA para que estes protocolos sejam utilizados. Inicie o programa Wireshark e filtre pacotes dos protocolos SMTP e POP; Inicie o programa Thunderbird e configure uma conta de e-mail utilizando: SMTP para envio de e-mails POP3 para buscar e-mails no servidor Envie mensagens para as contas configuradas dos colegas e verifique os pacotes capturados, analisando a estrutura dos protocolos. 72.8.5.2 Experimento 2: Envio de e-mail manual utilizando o programa telnet Conectar-se a um servidor de email, e enviar manualmente uma mensagem. Fazer primeiro com um programa (Thunderbird) e depois manualmente (com telnet). Segundo acesso: usando telnet para enviar uma mensagem Conecte-se ao servidor de email do laboratório (note que ele é acessado via port TCP 25): telnet 200.135.233.48 25 Converse com o servidor de email usando o protocolo SMTP, que é textual: helo mail 250 m1 mail from: aluno@alunosrco.sj.ifsc.edu.br 250 2.1.0 OK rcpt to: aluno1@alunosrco.sj.ifsc.edu.br 250 2.1.5 OK data 354 End data with <CR><LF>.<CR><LF> From: Aluno <aluno@alunosrco.sj.ifsc.edu.br> To: Aluno 1 <aluno1@alunosrco.sj.ifsc.edu.br> Subject: Teste de envio manual ... Testando o envio de uma mensagem na unha ... . 250 2.0.0 Ok: queued as 57C486819C quit 221 2.0.0 Bye Obs: as linhas que iniciam com números correspondem a respostas do servidor SMTP. Verifique se a mensagem foi de fato enviada. 72.9 29/09: Finalização de conteúdo da aula anterior 72.10 06/10: Aplicações: VoIP - fazendo chamadas de voz pela rede de comunicação de dados Transparências Introdução a VoIP e SIP Tecnologias VoIP para smartphones Mensagens, Transações, Diálogos e Chamadas SIP VoIP: transmissão de voz usando protocolos da arquitetura TCP/IP, com o objetivo de estabelecer chamadas semelhantes a chamadas telefônicas. Alguns exemplos de aplicações ou padrões VoIP são: Skype (mais material aqui) Viber SIP (padrão) H.323 (padrão) Uma chamada VoIP entre dois telefones IP é feita através da rede de dados. A realização de chamadas VoIP implica a necessidade de alguns mecanismos: Sinalização: deve haver alguma forma de um usuário iniciar uma chamada para outro usuário, de forma parecida com uma chamada telefônica convencional. A sinalização é responsável por possibilitar que um usuário convide outro para o estabelecimento de uma chamada, e para notificar sobre sua aceitação ou não. Além disso, a sinalização deve participar da definição sobre as características da chamada, tais como o codec de áudio. Transmissão de midia: a voz precisa ser digitalizada com algum codec então transmitida entre os participantes da chamada. O transporte da voz digitalizada implica o uso protocolos capazes de encapsulá-la e de atender ou dar subsídios ao atendimento de seus requisitos de qualidade de serviço (atrasos fim-a-fim e variação de atraso, taxa de perdas). Em Redes de Computadores será introduzido o modelo SIP para VoIP, o qual se compõe de um conjunto de padrões abertos para tratar dos vários aspectos envolvidos na realização de chamadas. Esse modelo, como diz seu nome, tem como principal elemento o protocolo de sinalização SIP (Session Initiation Protocol). 72.10.1 O protocolo SIP O protocolo SIP segue um modelo P2P (peer-to-peer), em que dois ou mais participantes, chamados de agentes, trocam mensagens com a finalidade de estabelecerem algum tipo de sessão (de voz no nosso caso, mas pode ser de video, mensagem instantânea, ou algum outro tipo de serviço). Assim, cada agente em uma sessão SIP se comporta tanto como cliente (quando envia requisições SIP) quanto servidor (quando responde a requisições SIP). A parte que inicia requisições se chama UAC (User Agent Client), e a que responde requisições é denominada UAS (User Agent Server), estando ambas implementadas nos telefones IP e similares. Uma sessão SIP envolve a interação entre duas entidades lógicas, que no caso de chamadas VoIP são por vezes chamadas simplesmente de usuários. A diferença entre entidade lógica e agente é que a primeira é o usuário (recurso) que inicia ou recebe chamadas, e o segundo é a aplicação que contém os mecanismos para efetuar e receber chamadas - pense que a entidade seria uma pessoa, e o agente o aparelho telefônico em uma chamada telefônica convencional. Cada entidade é identificada por uma URI (Uniform Resource Indicator) SIP, similar a um número de telefone. Além de identificar uma entidade lógica, a informação em uma URI SIP indica a forma com que essa entidade deve ser contatada via SIP. Exemplos de URI SIP seguem abaixo: # Uma URI simples, tipicamente usada em mensagens INVITE (que iniciam sessões SIP) sip:1234@biloxi.example.com # Uma URI mais elaborada, tipicamente usada em alguns cabeçalhos SIP (ex: Contact ou Refer-to) sip:joseph.fourier@transform.org:5060;transport=udp;user=ip;method=INVITE;ttl=1; maddr=240.101.102.103?Subject=FFT As comunicações SIP seguem uma hierarquia, cujos níveis são: Mensagens: mensagens de texto individuais trocadas entre agentes. Transação: sequência de mensagens entre dois agentes iniciando com uma requisição e terminando com uma resposta final. Diálogo: uma relação entre dois agentes que persiste por algum tempo, e identificada por um Call-ID. Chamada: composta por todos os diálogos originados por um agente. 'Mensagens, transações, diálogos e chamadas 72.10.1.1 Mensagens SIP O protocolo SIP tem uma estrutura simplificada com mensagens de pedido e resposta, assemelhando-se ao protocolo HTTP. Essas mensagens possuem a seguinte estrutura: Linha inicial Cabeçalho1: valor do cabeçalho 1 Cabeçalho2: valor do cabeçalho 2 ... CabeçalhoN: valor do cabeçalho N <linha em branco> corpo da mensagem (opcional) A diferença básica entre pedidos e respostas SIP está na linha inicial: pedidos contêm um método SIP e seus parâmetros, e respostas possuem um código de status junto com um curto texto informativo. Abaixo são mostradas duas mensagens SIP: um pedido e sua respectiva resposta. Nesse exemplo, ambas mensagens não possuem um corpo de mensagem (lembre que isso é opcional): Pedido: REGISTER sips:ss2.biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl To: Bob <sips:bob@biloxi.example.com> Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 1 REGISTER Contact: <sips:bob@client.biloxi.example.com> Content-Length: 0 Resposta: SIP/2.0 200 OK Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92 ;received=192.0.2.201 From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH To: Bob <sips:bob@biloxi.example.com>;tag=37GkEhwl6 Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 2 REGISTER Contact: <sips:bob@client.biloxi.example.com>;expires=3600 Content-Length: 0 O pedido exemplificado foi uma mensagem do tipo REGISTER, que é um tipo de método SIP. Um método pode ser entendido como um comando enviado de um participante a outro. A resposta contém o status 200 OK, que significa que o pedido foi atendido com sucesso. Por fim, ambas mensagens contiveram um conjunto de cabeçalhos necessários para caracterizá-las, dentre eles Via, From, To, Call-Id, CSeq, Contact e Content-Length. As tabelas a seguir descrevem resumidamente os principais métodos e cabeçalhos SIP. Método SIP Descrição REGISTER Usado por um agente para notificar a rede SIP (outros agentes) sobre sua URI de contato INVITE Usado para estabelecer sessões entre dois agentes ACK Confirma respostas finais a requisições INVITE BYE Termina uma sessão previamente estabelecida CANCEL Encerra tentativas de chamadas OPTIONS Consulta um agente sobre suas capacidades Tabela de métodos SIP (não exaustiva ... apenas os principais métodos) Cabeçalho SIP Descrição Obrigatoriedade Uso Via Registra a rota seguida por uma requisição, sendo usado para que respostas sigam o caminho inverso Requisição e resposta Requisição e resposta To Identifica o destinatário de uma requisição Requisição e resposta Requisição e resposta From Identifica o originador da requisição Requisição e resposta Requisição e resposta Call-Id Identifica univocamente uma chamada entre um UAC e um UAS. Requisição e resposta Requisição e resposta CSeq Numera as requisições de uma mesma chamada de um mesmo UAC Requisição Requisição e resposta Contact Identifica o originador da requisição ou o recurso requisitado Requisição e resposta Max-Forwards Máximo número de saltos que a requisição pode atravessar Requisição Requisição Content-Length Informa a quantidade de bytes do corpo da mensagem Requisição e resposta Date Informa a data e horário de uma requisição ou resposta Requisição e resposta Supported Lista uma ou mais opções suportadas por um UAC ou UAS Requisição e resposta User-Agent Informa sobre o agente (o programa) originador de uma requisição Allow Informa os métodos SIP aceitos pelo UAS Resposta Content-type Informa o tipo de conteúdo contido no corpo da mensagem WWW-Authenticate Informa que o UAC deve se autenticar para o UAS (e como isso deve ser feito) Resposta Authorization Contém as credenciais para autenticar o UAC para o UAS Requisição Tabela de cabeçalhos SIP (não exaustiva ... apenas os principais cabeçalhos) 72.10.1.2 Diagramas de chamadas Alguns tipos de chamadas VoIP com SIP são recorrentes, estando representadas nas subseções a seguir. 72.10.1.2.1 Chamada direta entre dois agentes SIP Uma chamada direta entre dois agentes envolve uma transação INVITE, em que um agente convida o outro a estabelecer uma sessão SIP com um determinado tipo de media (ex: audio). A chamada é finalizada quando um dos agentes inicia uma transação BYE. Fone 1 Fone 2 | | | INVITE | |----------------------->| | 180 Ringing | |<-----------------------| | | | 200 OK | |<-----------------------| | ACK | |----------------------->| | RTP Media | |<======================>| | | | BYE | |<-----------------------| | 200 OK | |----------------------->| | | 72.10.1.2.2 Chamada entre dois agentes SIP com intermediação de um gateway de media Este caso é parecido com o anterior, que usa um proxy SIP. A diferença está na intermediação do fluxo de media, que é feita pelo gateway de media. Isso possibilita que dois agentes estabeleçam uma chamada mesmo usando codecs diferentes, pois o gateway de media fará a tradução entre codecs. Fone 1 PBX IP Fone 2 (directmedia=no) | | | | INVITE | | |--------------->| INVITE | | 100 Trying |--------------->| |<---------------| 100 Trying | | |<---------------| | | 180 Ringing | | 180 Ringing |<---------------| |<---------------| | | | 200 Ok | | 200 Ok |<---------------| |<---------------| | | ACK | | |--------------->| ACK | | |--------------->| | RTP Media | RTP Media | |<==============>|<==============>| | BYE | | |--------------->| BYE | | |--------------->| | | 200 Ok | | 200 Ok |<---------------| |<---------------| | | | | 72.10.2 Protocolo RTP Transparências Uma FAQ sobre RTP (muito boa) RFC 3550: RTP: A Transport Protocol for Real-Time Applications Capítulo 11 do livro SIP: Understanding the Session Initiation Protocol, 3rd ed Cap. 7 do livro Redes de Computadores e a Internet, 5a edição, de James Kurose. O protocolo RTP (Real-Time Protocol) foi desenvolvido para possibilitar o transporte de datagramas de tempo-real contendo voz, video, ou outro tipo de dados, sobre IP. Tanto H.323 quanto o modelo SIP usam RTP para o transporte de media, tornando-o o padrão mais comum para comunicações desse tipo na Internet. Apesar desse protocolo não prover qualidade de serviço (i.e. ele não possui mecanismos para atender tais tipos de requisitos), ele torna possível a detecção de alguns dos problemas introduzidos por uma rede IP, tais como: Perda de pacotes Atraso fim-a-fim variável Chegada de pacotes fora de ordem O RTP se apresenta assim como um protocolo que dá subsídios para as técnicas que buscam atender requisitos de qualidade de serviço. Esses subsídios são informações providas pelo RTP para ajudar a identificar os problemas citados acima, as quais são: Identificação do tipo do conteúdo que está sendo carregado (codec): isso informa ao receptor como ele deve decodificar o conteúdo transportado (ver esta tabela de identificadores de codec usados pelo RTP) Numeração de sequência: essa informação possibilita identificar pacotes perdidos ou fora de ordem. Marcação de tempo (timestamp): com isso é possível efetuar o cálculo de variação de atraso e implementar algum mecanismo de sincronização com a fonte (ex: atraso de reprodução). Essas informações fazem parte da PDU RTP, como se pode ver a seguir: Localização do RTP na camada de transporte Cabeçalho RTP Perfil RTP/AVP, com codecs e seus códigos numéricos 72.10.2.1 RTCP Além do RTP, o protocolo auxiliar RTCP (Real-Time Control Protocol, também definido na RFC 3550) foi definido para o monitoramento da entrega dos pacotes (recepção da stream). Com esse protocolo, os participantes de uma sessão de media podem fazer o intercâmbio de relatórios e estatísticas. Cada tipo de relatório é transportado por um tipo de pacote RTCP. O uso de relatórios possibilita o feedback sobre a qualidade da comunicação, incluindo informações como: Número de pacotes enviados e recebidos Número de pacotes perdidos Jitter (variação de atraso) Os cinco tipos de relatórios são: Relatório do transmissor (Sender Report - SR) Relatório do receptor (Receiver Report - RR) Descrição da fonte (Source Description - SDES) Bye Específico da aplicação (Application Specific - APP) Como o tráfego RTCP é puramente overhead, o protocolo foi projetado para que seu consumo da capacidade da rede seja constante, não importa quantos participantes da sessão de media existam. A ideia é que quanto mais participantes houver, menos frequentemente os relatórios RTCP são enviados. Por exemplo, se em uma conferência houver somente dois participantes, os relatórios podem ser enviados a cada 5 segundos. Se houver quatro participantes, os relatórios são enviados a cada 10 segundos. Com isso o consumo de banda para relatórios se mantém constante e previsível. 72.10.3 Atividade 1: Ligação SIP ponto a ponto O primeiro experimento com uma chamada VoIP envolve estabelecer uma chamada diretamente entre dois softphones. Cada par de alunos deve fazer o seguinte: Executar o Jitsi (ver em Aplicativos->Internet). Se não estiver instalado, baixe a seguinte versão para Ubuntu 12.04 i386. Definir uma conta SIP contendo somente um identificador de usuário (sem a localização). Um dos alunos deve iniciar uma chamada para o outro aluno, que deve atendê-la. Deve-se identificar o aluno chamado por: identificador@foneX.redes2.sj.ifsc.edu.br ... sendo X o número do computador em que está o colega chamado. Experimente falar ao microfone e escutar o som no fone de ouvido. Encerre a chamada. A sequência de passos acima estabelece uma chamada VoIP do tipo mais simples possível. Para ver os detalhes da comunicação entre os softphones faça o seguinte: Execute o wireshark e inicie a captura de datagramas UDP pela interface eth0. Repita a chamada. Após encerrar a chamada, analise mensagens SIP no wireshark (menu Telephony -> Voip Calls -> Graph) Disseque a sinalização SIP entre os softphones. Identifique como foi transportada a voz digitalizada. Questões: Quem foram o UAC e UAS nesse experimento ? Quantas requisições SIP foram realizadas para uma chamada completa ? Quantas mensagens, transações, diálogos e chamadas foram realizadas ? Que protocolo de transporte é usado pelo SIP ? Como a voz digitalizada foi transportada ? Foi usado algum protocolo em especial ? 72.10.4 Atividade 2: chamada intermediada por um soft PBX Obs: para esta atividade cada aluno tem duas contas SIP: 1XX@192.168.3.1 e 2XX@192.168.3.1 (XX é o número do seu computador, e deve estar entre 01 e 14). 1. Execute o softphone jitsi, configurando-o para registrar no soft PBX. Isso é feito especificando a conta SIP da seguinte forma (exemplo com o identificador SIP 102): 102@192.168.3.1 2. A partir do softphone faça uma chamada para uma conta de um colega. Verifique se o softphone IP acusou o recebimento de chamada. Caso isso não tenha ocorrido, verifique sua configuração. 4. Execute o wireshark, e ponha-o em modo de captura na interface eth0. 5. Repita a chamada de um softphone a outro. No destinatário, atenda a chamada e alguns segundos depois encerre-a. 6. No wireshark interrompa a captura, e em seguida acesse o menu Telephony->VoIP Calls. Selecione uma chamada, e visualize o diagrama de mensagens SIP. Siga cada mensagem SIP (clique no diagrama), e observe a mensagem selecionada no painel de captura do wireshark. Identifique as transações (observe os códigos de resposta) e os diálogos. Você pode usar estes diagramas para se guiar. Questões: Que papel desempenhou o Asterisk para os softphones? UAC, UAC ou algo diferente? Como o Asterisk conseguiu identificar o telefone chamado (i.e. localizar onde ele estava na rede)? Obs.: Quem quiser realizar este teste em casa, veja este tutorial simples sobre como configurar um PBX IP Asterisk no Ubuntu. 72.11 13/10: Revisão de protocolos de aplicação Realizamos testes com captura e análise de pacotes. Capturas exemplo: HTTP FTP SMTP POP3 IMAP DNS SIP+RTP BitTorrent 72.12 20/10: Revisão de análise de protocolos e Avaliação 2 72.12.1 Revisão Analisaremos as seguintes capturas em sala: HTTP FTP SMTP POP3 DNS 72.12.2 Avaliação 2 Utilize o arquivo abaixo para executar a prova distribuída pelo professor: Arquivo de captura para prova 72.13 31/10: Camada de Transporte slides (Arquivo:RCO-semprebom-cap3.pdf) Até o momento nos concentramos nas aplicações de rede. Afinal, são elas que usamos para nos comunicarmos através das redes de computadores. No entanto, aplicações dependem de outros protocolos para poderem se comunicar, os quais cuidam dos detalhes envolvidos na transmissão e recepção de mensagens em uma rede vasta como a Internet. As aplicações se comunicam por meio de mensagens. Cada protocolo de aplicação (HTTP, POP3, DNS, IMAP, SMTP, SIP, ...) tem seu formato de mensagem. Essas mensagens podem ser pequenas (ex: DNS, SIP) ou por vezes grandes (ex: SMTP, HTTP, POP3). De qualquer forma, a aplicação precisa que suas mensagens sejam transmitidas para o outro participante da comunicação, que está em um computador remoto. Para isso ela usa um protocolo de transporte. Algumas aplicações e protocolos de transporte na Internet Como já discutido, mais de uma aplicação pode existir em um mesmo computador. Por isso, uma das principais atribuições de um protocolo de transporte é identificar de qual aplicação é uma mensagem a ser transmitida, e para qual aplicação se destina uma mensagem recebida. Deve-se ter em mente que uma aplicação é representada por um programa em execução em um computador, portanto um protocolo de transporte possibilita a comunicação entre processos que estão sendo executados usualmente em computadores diferentes. Em nossas discussões anteriores chamamos isso de classificação das mensagens, mas o termo usado para expressar essa capacidade dos protocolos de transporte é multiplexação. No caso específico dos protocolos de transporte da Internet (TCP e UDP), um número de porta é usado para fazer essa distinção, e por isso essa função é denominada multiplexação baseada em porta. Uma comunicação entre aplicações é composta basicamente de duas informações principais: endereços dos hosts participantes e números de porta dos processos. Os endereços são responsabilidade da Camada de Rede (onde há o protocolo IP), e os números de porta são usados na Camada de Transporte (onde estão os protocolos TCP e UDP). Mas por que existem dois protocolos de transporte ? Talvez ajude a esclarecer essa questão se compararmos as necessidades das aplicações: Aplicação Tolerância a perdas Tolerância a atrasos Tamanhos de mensagens HTTP baixa média variável ... podem ser muito grandes (de poucos bytes a centenas de megabytes ou mais) SMTP baixa alta variável ... podem ser grandes (de centenas bytes a alguns megabytes) DNS média baixa pequenas (algumas centenas de bytes) POP3 baixa média variável ... podem ser grandes (de centenas bytes a alguns megabytes) SIP média média pequenas (algumas centenas de bytes) VoIP média baixa pequenas (tipicamente < 164 bytes) Durante o projeto e aperfeiçoamento dos protocolos da Internet, convergiu-se para a definição de dois protocolos de transporte: TCP (ver RFC 793): protocolo orientado a conexão, com garantia de entrega, controle de fluxo e controle de congestionamento. UDP (ver RFC 768): protocolo orientado a datagrama (não há conexão), sem garantia de entrega ou qualquer outra verificação ou controle. Basicamente faz somente a multiplexação baseada em porta. Curiosidade: veja os anos em que foram publicados as especificações desses protocolos ... As diferenças entre eles serão melhor detalhadas adiante. Hoje faremos alguns experimentos para ter uma ideia de como se comportam as comunicações feitas com esses protocolos. 72.13.1 Atividade As atividades de hoje buscarão mostrar as características básicas de comunicações com protocolos de transporte. 72.13.1.1 Aplicações e protocolos de transporte Faça uma rápida pesquisa e descubra que protocolos de transporte (e que portas) são usados por estas aplicações: SSH FTP BitTorrent emule WINS Compartilhamento de arquivos do Windows Windows Terminal Service NFS Openvpn RADIUS DHCP SNMP NTP LDAP Mysql Postgresql Oracle RDBMS Syslog CUPS Que protocolo de transporte predomina nesse conjunto ? 72.13.1.2 Tipos de protocolos de transporte: TCP x UDP Nestes experimentos, serão evidenciadas diferenças entre os protocolos TCP e UDP. 72.13.1.2.1 Experimento 1 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 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 ? Abra um terminal e execute o seguinte comando para fazer o download de um arquivo a ser usado no experimento: wget http://tele.sj.ifsc.edu.br/~msobral/res/ubuntu.iso Observe o tamanho do arquivo transferido ... ele deve ter exatamente 209715200 bytes (cerca de 200 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. A primeira transferência será feita usando o protocolo TCP da seguinte forma: No computador receptor execute: nc -l 5555 > arquivo No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): time nc 192.168.3.X 5555 < ubuntu.iso 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: No computador receptor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x receptor). No computador receptor execute: ./receptor 5555 > arquivo No computador transmissor faça o download deste programa. Em seguida acrescente a ele permissão de execução (chmod +x transmissor). No computador transmissor execute (X é o número do seu computador, visível em sua etiqueta): ./transmissor 192.168.3.X 5555 < ubuntu.iso Quando completar a transferência, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original ? E quanto tempo levou para transmiti-lo ? Compare as transferências feitas com TCP e UDP. O que eles têm em comum ? Que diferenças lhe pareceram mais pronunciadas ? Como isso deve afetar as aplicações que usam esses protocolos ? 72.13.1.2.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, como mostrado na figura abaixo: Abra um terminal em seu computador, e nele execute este comando: wget http://tele.sj.ifsc.edu.br/~msobral/res/ubuntu.iso 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á se logar em um dos computadores do laboratório e 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 ? Finalmente, o professor irá repetir a transferência porém com mais dois 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: Abra dois terminais. Em um deles execute este comando: watch -n 1 ls -l arquivo ... e no outro execute: ./receptor 5555 > arquivo O professor irá transmitir o arquivo a partir do servidor. Observe o tamanho do arquivo, que deverá aumentar. 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 comparam as transferências usando TCP e UDP ? 72.14 10/11/14: Revisão de camada de transporte e Introdução à camada de rede Revisão da camada de transporte (TCP/UDP) (Arquivo:RCO-semprebom-cap3.pdf) Introdução à camada de rede (Redes e sub-redes IP) (Arquivo:RCO-semprebom-cap4.pdf) 72.15 17/11/14: Avaliação 3 Listas de exercícios da camada de transporte: Lista de exercícios 4 Lista de exercícios 5 Lista de exercícios 6 72.16 24/11/14: Roteamento estático Veja neste link como funciona o Netkit2. Leia a introdução e faça a instalação automática do software. 72.16.1 Roteamento estático Esse guia contém uma coleção de exemplos, para que tenham ideia do que se pode fazer com o Netkit. O Netkit fica assim como opção para complementar o estudo. Ele funciona como um laboratório de redes, em que se podem criar redes como aquelas que vemos em aula e mesmo inventar novas redes. Seu uso se destina a fixar conceitos, para que o uso dos equipamentos reais seja facilitado. Além do Netkit, o seguinte simulador de roteamento IP, que roda dentro do próprio navegador, pode ajudá-los a exercitar a divisão de subredes e a criação de rotas estáticas. Ipkit: Simulador de encaminhamento IP 72.16.1.1 Experimento 1. Usando o Netkit crie as seguintes redes. Não esqueça de definir as rotas estáticas. Arquivo do experimento pc1[type]=generic pc2[type]=generic pc3[type]=generic r1[type]=gateway r2[type]=gateway pc1[eth0]=link0:ip=192.168.0.1/24 pc2[eth0]=link1:ip=192.168.1.2/24 pc3[eth0]=link2:ip=192.168.2.3/24 r1[eth0]=link0:ip=192.168.0.254/24 r1[eth1]=link1:ip=192.168.1.254/24 r2[eth0]=link0:ip=192.168.0.253/24 r2[eth1]=link2:ip=192.168.2.254/24 pc1[default_gateway]=192.168.0.254 pc2[default_gateway]=192.168.1.254 pc3[default_gateway]=192.168.2.254 r1[route]=192.168.2.0/24:gateway=192.168.0.253 r2[route]=192.168.1.0/24:gateway=192.168.0.254 Arquivo do experimento pc1[type]=generic pc2[type]=generic pc3[type]=generic pc4[type]=generic r1[type]=gateway r2[type]=gateway r3[type]=gateway r4[type]=gateway pc1[eth0]=lan1:ip=192.168.1.1/24 pc2[eth0]=lan2:ip=192.168.2.1/24 pc3[eth0]=lan3:ip=192.168.3.1/24 pc4[eth0]=lan4:ip=192.168.4.1/24 r1[eth0]=lan1:ip=192.168.1.254/24 r1[eth1]=lan2:ip=192.168.2.254/24 r2[eth0]=lan2:ip=192.168.2.253/24 r2[eth1]=lan3:ip=192.168.3.254/24 r3[eth0]=lan1:ip=192.168.1.253/24 r3[eth1]=lan4:ip=192.168.4.254/24 r4[eth0]=lan3:ip=192.168.3.253/24 r4[eth1]=lan4:ip=192.168.4.253/24 Arquivo do experimento pc1[type]=generic pc2[type]=generic pc3[type]=generic pc4[type]=generic r1[type]=gateway r2[type]=gateway pc1[eth0]=lan1:ip=10.0.1.1/26 pc2[eth0]=lan2:ip=192.168.1.1/24 pc3[eth0]=lan3:ip=192.168.2.129/26 pc4[eth0]=lan4:ip=192.168.2.193/26 r1[eth0]=lan1:ip=10.0.1.62/26 r1[eth1]=lan2:ip=192.168.1.254/24 r2[eth0]=lan2:ip=192.168.1.253/24 r2[eth1]=lan3:ip=192.168.2.190/26 r2[eth2]=lan4:ip=192.168.2.254/26 2. Teste a comunicação entre os computadores e roteadores usando o comando ping. Use também o tcpdump ou wireshark para monitorar as interfaces de rede. 72.17 01/12/14: Tecnologias de redes locais Tecnologias de redes locais e seus componentes; Tecnologias de redes sem fio; Laboratório redes locais e sem fio; Enlaces Ponto-a-Ponto 72.17.1 Conceituação sobre Redes Locais (LAN) 72.17.1.1 Características e pontos-chaves Obs: obtido de STALLINGS, 2005: Uma LAN consiste de um meio de transmissão compartilhado e um conjunto de hardware e software para servir de interface entre dispositivos e o meio de transmissão, além de regular o acesso ao meio de forma ordenada. As topologias usadas em LANs são anel (ring), barramento (bus), árvore (tree) e estrela (star). Uma LAN em anel consiste de um laço fechado formado por repetidores que possibilitam que dados circulem ao redor do anel. Um repetidor pode funcionar também como um ponto de acesso de um dispositivo. Transmissão geralmente se dá na forma de quadros (frames). As topologias barramento e árvore são segmentos de cabos passivos a que os dispositivos são acoplados. A transmissão de um quadro por um dispositivo (chamado de estação) pode ser escutada por qualquer outra estação. Uma LAN em estrela inclui um nó central onde as estações são acopladas. Um conjunto de padrões definido para LANs especifica uma faixa de taxas de dados e abrange uma variedade de topologias e meios de transmissão. Na maioria dos casos, uma organização possui múltiplas LANs que precisam ser interconectadas. A abordagem mais simples para esse problema se vale de equipamentos chamados de pontes (bridges). Os conhecidos switches Ethernet são exemplos de pontes. Switches formam os blocos de montagem básicos da maioria das LANs (não muito tempo atrás hubs também eram usados). 72.17.1.2 Algumas tecnologias Ethernet (IEEE 802.3): largamente utilizada hoje em dia, na prática domina amplamente o cenário de redes locais. Token Ring (IEEE 802.5): foi usada nos anos 80 e início dos anos 90, mas está em desuso ... muito difícil de encontrar uma rede local deste tipo hoje em dia. Myrinet: criada especificamente para interligar servidores de alta capacidade de processamento em clusters. Atualmente pouco usada, pois redes ethernet as substituíram em clusters e data centers. Infiniband: especificamente criada para interligar equipamentos para fins de computação de alto-desempenho. Mantém-se na ativa nesse nicho específico. 72.17.1.3 Topologias Uma topologia de rede diz respeito a como os equipamentos estão interligados. No caso da rede local, a topologia tem forte influência sobre seu funcionamento e sobre a tecnologia adotada. Dependendo de como se desenha a rede, diferentes mecanismos de comunicação são necessários (em particular o que se chama de acesso ao meio). A eficiência da rede (aproveitamento da capacidade de canal, vazão) e sua escalabilidade (quantidade de computadores e equipamentos que podem se comunicar com qualidade aceitável) também possuem relação com a topologia. A tabela abaixo exemplifica topologias conhecidas de redes locais. Topologia Exemplo Tecnologias Estrela Ethernet (IEEE 802.3) com hubs e switches Anel (em desuso) Token-ring (IEEE 802.5), FDDI Barramento (em desuso) Ethernet (IEEE 802.3) Árvore Ethernet (IEEE 802.3) com hubs e switches Árvore-gorda (Fat-tree) Ethernet (IEEE 802.3) com hubs e switches 72.17.1.4 Exemplos de uso de redes locais Exemplos de redes locais são fáceis de apresentar. Praticamente toda rede que interconecta computadores de usuários é uma rede local - mesmo no caso de redes sem-fio, um caso especial a ser estudado mais a frente. A rede do laboratório de Redes 1, onde temos nossas aulas, é uma rede local. Os demais computadores da escola formam outra rede local. Quando em casa se instala um roteador ADSL e se conectam a ele um ou mais computadores, cria-se também uma rede local. Portanto, redes locais são extremamente comuns e largamente utilizadas. Ainda assim, cabem alguns outros exemplos de possíveis redes locais, mostrados abaixo: Uma LAN típica com um link para Internet Uma LAN que integra servidores em um datacenter Um tipo de LAN especial para interligar servidores de armazenamento (storage), chamada SAN (Storage Area Network) 72.17.2 Redes sem-fio Ver transparências Ver capítulo 15 do livro Comunicação de Dados e Redes de Computadores, 3a ed., de Behrouz Forouzan. Ver capítulo 6 do livro Redes de Computadores e a Internet, 3a ed., de James Kurose. Ver capítulo 4 (seção 4.4) do livro Redes de Computadores, 4a ed., de Andrew Tanenbaum. Ver este livro on-line sobre redes IEEE 802.11. (precisa do gnochm ou chmsee para ser lido) 72.17.2.1 Introdução Redes sem-fio se tornaram uma tecnologia largamente difundida e de uso corriqueiro, principalmente em sua versão para redes locais. Graças a ela, as pessoas não precisam usar cabos para ter acesso à rede, e podem se comunicar em qualquer localização dentro do alcance da rede sem-fio. Mesmo usuários em movimento podem se manter em comunicação pela rede sem-fio. 72.17.2.2 Alguns usos de redes sem-fio Redes locais sem-fio Enlaces ponto-a-ponto de média/longa distância Prover conectividade em ferrovias Redes de dispositivos acoplados ao corpo de uma pessoa Redes de sensores Redes entre veículos (experimental) 72.17.2.3 Padrão IEEE 802.11 Dentre as várias tecnologias de comunicação sem-fio existentes, o padrão IEEE 802.11 para redes locais tem ampla utilização. Conhecido popularmente como Wi-Fi (um trocadilho com Hi-Fi, uma qualidade atribuída a aparelhos de som e que significa High-Fidelity), está presente praticamente em todos os lugares hoje em dia - desde escolas, empresas, aeroportos, supermercados, restaurantes, cafés e residências, e até mesmo em espaços abertos de cidades (ver Cidades Digitais). Muitos dos problemas existentes nesse tipo de rede (alguns resolvidos e outros não), e características de funcionamento, são comuns a outras tecnologias menos conhecidas, porém também importantes em suas áreas de aplicação. Por isso nosso estudo se concentrará nesse padrão de redes sem-fio, para conhecê-lo com razoável profundidade. Como consequência, além de entender como funciona uma rede IEEE 802.11, os conhecimentos obtidos habilitarão a compreensão de outras tecnologias de redes sem-fio. Apresentaram-se as possíveis formas de organização de uma rede IEEE 802.11: Rede infraestruturada: uso de uma estação central, que intermedia as transmissões das demais estações. Rede Ad-Hoc: estações se comunicam livremente com suas estações vizinhas. Rede Mesh: estações se comunicam livremente, mesmo que existam múltiplos saltos (multihop). 72.17.3 Experimento: desempenho de redes LAN Neste experimento compararemos o desempenho de uma rede em barramento (utiliznado um Hub) e uma rede comutada (utilizando um switch). O roteiro completo está aqui. 72.17.4 Introdução a WAN: Tecnologias de acesso para WAN Introdução a WAN: conceitos básicos (ver transparências) Parte III e capítulos 10 e 11 do livro "Comunicação de Dados e Redes de Computadores, 4a ed.", de Behrouz Forouzan Capítulo 3 do livro "Redes de Computadores" de Andrew Tanenbaum. Capítulo 18 do livro Comunicação de Dados e Redes de Computadores, 4a ed., de Behrouz Forouzan. Uma WAN realmente distante: Internet Interplanetária Um típico enlace WAN, do ponto de vista de uma rede de computadores de usuário, é representado por um enlace ponto-a-ponto, como pode ser visto na figura abaixo. Nele, dois roteadores se comunicam por um meio físico dedicado, usando um protocolo de enlace especializado. Como o meio é dedicado, não existem colisões, e por isso não é necessário um controle de acesso ao meio (MAC). Além disso, como somente esses dois roteadores estão envolvidos, não há necessidade de endereçamento no protocolo de enlace. Dois protocolos de enlace ponto-a-ponto muito utilizados são: PPP (Point-to-Point Protocol): proposto no início dos anos 90 pelo IETF (ver RFC 1661), e amplamente utilizado desde então. Originalmente muito usado em acesso discado, recentemente sua aplicação se concentra em enlaces por linhas dedicadas, enlaces sem-fio 3G, e uma versão modificada para acesso doméstico ADSL (PPPoE). Ver mais detalhes na seção 11.7 do livro Comunicação de Dados e Redes de Computadores, de Behrouz Forouzan. HDLC (High-level Data Link Control): criado nos anos 70, foi largamente utilizado em enlaces ponto-a-ponto, porém atualmente foi substituído pelo PPP na maioria dos cenários em que era usado. Ainda se aplica a enlaces ponto-a-ponto em linhas dedicadas, enlaces por satélite e aplicações específicas (ver por exemplo este artigo sobre seu uso missões espaciais em um artigo da Nasa). Ver mais detalhes na seção 11.6 do livro Comunicação de Dados e Redes de Computadores, de Behrouz Forouzan. Ambos protocolos foram criados para uso com comunicação serial síncrona (ver capítulo 4, seção 4.3 do livro Comunicação de Dados e Redes de Computadores, de Behrouz Forouzan). O PPP funciona também com comunicação serial assíncrona. Esse requisito explica vários detalhes de seus projetos, como será explicado logo abaixo. 72.17.4.1 Serviços da camada de enlace Transparências Para ficar mais claro o que deve fazer um protocolo de enlace ponto-a-ponto, vamos listar os serviços típicos existentes na camada de enlace. Os serviços identificados na figura acima estão descritos abaixo. A eles foram acrescentados outros dois: Encapsulamento (ou enquadramento): identificação das PDUs (quadros) de enlace dentro de sequências de bits enviadas e recebidas da camada física Controle de erros: garantir que quadros sejam entregues no destino Detecção de erros: verificação da integridade do conteúdo de quadros (se foram recebidos sem erros de bits) Controle de fluxo: ajuste da quantidade de quadros transmitidos, de acordo com a capacidade do meio de transmissão (incluindo o atraso de transmissão) e do receptor Endereçamento: necessário quando o enlace for do tipo multi-ponto, em que vários equipamentos compartilham o meio de transmissão (ex: redes locais e redes sem-fio) Controle de acesso ao meio (MAC): também necessário para meios compartilhados, para disciplinar as transmissões dos diversos equipamentos de forma a evitar ou reduzir a chance de haver colisões (transmissões sobrepostas) Gerenciamento de enlace: funções para ativar, desativar e manter enlaces 72.17.4.2 Atividade 1: enlaces PPP Rede do experimento Esse experimento será feito usando o Netkit2. Três roteadores estarão interligados por enlaces PPP. A interface mostrada no Netkit para os roteadores é muito parecida com a CLI de roteadores Cisco reais (graças ao software Quagga, que é usado em máquinas virtuais do Netkit que agem como roteadores). No entanto, as interfaces seriais de enlaces ponto-a-ponto no Quagga são identificadas pelos nomes ppp0, ppp1 e assim por diante (ao contrário de Serial 0 e Serial 1 usados no Cisco). Abaixo segue a configuração do Netkit que reproduz o experimento: Configuração do experimento para o Netkit # Os três roteadores r1[type]=router r2[type]=router r3[type]=router # O computador que fica na subrede da esquerda pc1[type]=generic # O computador que fica na subrede da direita pc2[type]=generic # Um computador que representa a Internet internet[type]=generic # Os enlaces ponto-a-ponto entre os roteadores r1[ppp0]=linkEsquerdo:ip=10.0.0.1/30:debug=1 r1[ppp1]=linkDireito:ip=10.0.0.5/30:debug=1 r2[ppp0]=linkEsquerdo:ip=10.0.0.2/30:debug=1 r3[ppp0]=linkDireito:ip=10.0.0.6/30:debug=1 # a subrede do laboratório, que representa a Internet r1[eth0]=lanExterna:ip=192.168.1.230/24 internet[eth0]=lanExterna:ip=192.168.1.1/24 # A subrede do lado esquerdo r2[eth0]=lanEsquerda:ip=172.18.0.30/28 pc1[eth0]=lanEsquerda:ip=172.18.0.17/28 # A subrede do lado direito r3[eth0]=lanDireita:ip=172.18.10.110/28 pc2[eth0]=lanDireita:ip=172.18.10.97/28 # As rotas ... pc1[default_gateway]=172.18.0.30 pc2[default_gateway]=172.18.10.110 r2[default_gateway]=10.0.0.1 r3[default_gateway]=10.0.0.5 r1[route]=172.18.0.16/38:gateway=10.0.0.2 r1[route]=172.18.10.96/38:gateway=10.0.0.6 internet[route]=172.18.0.0/16:gateway=192.168.1.230 Com base nessa rede, as seguintes atividades serão realizadas: Observe as informações sobre as interfaces PPP nos roteadores, e compare com o que é mostrado para interfaces ethernet: r1# show interface ppp0 ... ou ... r1# start-shell # ifconfig ppp0 # ifconfig eth0 Teste a comunicação pelos enlaces PPP. Por exemplo, no roteador r1 pode ser feito o seguinte: r1# ping 10.0.0.2 r1# ping 10.0.0.6 Compare o encapsulamento de datagramas IP na rede ethernet e no enlace PPP. Para isso use o wireshark, executando-o para a interface eth0 do roteador r1 e também para a interface ppp0. Para haver datagramas passando pelo roteador, deixe um ping em execução entre os computadores pc1 e internet. Simule um erro de transmissão pelo enlace PPP: Na máquina real faça o download dos arquivos que contêm quadros PPP especialmente criados para esse experimento. Descompacte esse arquivo dentro de lab/shared. Nos roteadores r1 e r2 execute o comando start-shell. Como ele se obtém acesso ao shell, visto que nos roteadores a interface é inicialmente fornecida por um software especial chamado Quagga. Note que existe um enlace PPP entre as máquinas virtuais. No roteador r1 deixe o tcpdump monitorando a interface ppp0 (ou use o wireshark): sh-3.1# tcpdump -i ppp0 -ln No roteador r2 será feita a injeção de quadros PPP no enlace. A ideia é transmitir quadros corretos e em seguida quadros com erros (i.e. com bits propositalmente modificados), e observar como o PPP no roteador r1 trata esses quadros. Injete o quadro correto em r2, observando o que mostra o tcpdump em r1: cd /hostlab/shared cat quadro.ok > /dev/ttyS0 Agora injete o quadro com erros e veja o que acontece: cd /hostlab/shared cat quadro.erro > /dev/ttyS0 O que se pode concluir quanto à recepção pelo PPP de quadros com erros de transmissão ? 72.18 08/12/14: Revisão e Avaliação 4 Listas de exercícios Lista de exercícios 7 Lista de exercícios 8 Lista de exercícios 9 72.19 Atividade de recuperação Recuperação da prova 4 sendo realizada por trabalho individual. Entrega por email até dia 15/12/2014.

72.20 Cronograma das Atividades

Semestre 2015-1 - Prof. Tiago Semprebom

Semestre 2014-2
Aula Data Horas Conteúdo Recursos 1 12/04 4 Apresentação da Disciplina Aula expositiva TOTAL 36