RES-2013-1

De MediaWiki do Campus São José
Revisão de 10h21min de 6 de março de 2014 por Msobral (discussão | contribs) (→‎Listas de exercícios)
(dif) ← Edição anterior | Revisão atual (dif) | Versão posterior → (dif)
Ir para navegação Ir para pesquisar

Redes de Computadores: Diário de Aula 2013-1

Professor: Marcelo Maia Sobral (Facebook2.png Facebook)
Lista de email (forum): res-ifsc@googlegroups.com
Encontros: 5a feira/20:40, 6a feira/18:30
Atendimento paralelo: 2a de 8:20 às 9:10 h, 4a de 13:30 a 14:30


Ementa

Compreender a infraestrutura da internet e suas conexões. Entender a arquitetura da internet e seu conjunto de protocolos TCP-IP. Compreender e utilizar aplicações da camada de Aplicação: HTTP, FTP, SMTP, SSH e DNS. Entender as funcionalidades dos protocolos UDP e TCP. Compreender os serviços da camada de Rede e os protocolos: IP, ICMP, ARP, Ipv6, NAT e DHCP. Utilizar aplicativos de rede (ping, traceroute, netstat) e analisadores de pacotes (tcpdump). Compreender o paradigma (modelo) Cliente/Servidor, através de uma aplicação de Socket TCP e UDP.

Cronograma

AULA DATA Descriçao
1 09/05/2013 Apresentação da ementa. Introdução a Redes de Computadores. História das Redes de computadores.
2 10/5/2013 Laboratório: usando uma rede de computadores e reconhecendo seus componentes.
3 16/5/2013 Arquitetura de redes: como elementos de rede se comunicam: emissor, receptor e meio de transporte; protocolos. Estrutura em camadas. Comutação de circuitos x pacotes. Detalhes da aplicação X detalhes da comunicação.
4 17/5/2013 Laboratório: acesso a serviços simples (HTTP, SMTP, SIP) e visualização da respectiva comunicação. Identificação das regras de comunicação em protocolos simples (semântica), e da representação da informação por esses protocolos (sintaxe).
5 18/5/2013 Laboratório: acesso a serviços simples (HTTP, SMTP, SIP) e visualização da respectiva comunicação. Identificação das regras de comunicação em protocolos simples (semântica), e da representação da informação por esses protocolos (sintaxe).
6 23/5/2013 Camada de aplicação: investigando WWW e o protocolo HTTP.
7 24/5/2013 Camada de aplicação: investigando WWW e o protocolo HTTP; textos HTML. Correio-eletrônico
8 06/06/2013 Camada de aplicação: correio-eletrônico
9 07/06/2013 Camada de aplicação: DNS
10 13/06/2013 Camada de aplicação: VoIP
11 14/06/2013 Revisão e exercícios
12 20/06/2013 Avaliação 1
13 21/06/2013 Correção da avaliação 1
14 27/06/2013 Protocolos de Transporte: Introdução
15 28/06/2013 Protocolos de Transporte: TCP
16 04/07/2013 Protocolos de Transporte:TCP (laboratório) (2 aulas)
17 05/07/2013 Protocolos de Transporte:TCP
18 11/07/2013 Protocolos de Transporte: UDP (2 aulas)
19 12/07/2013 Camada de rede: protocolo IP, endereçamento IP, subredes e máscaras de rede
20 18/07/2013 Camada de rede: protocolo IP, endereçamento IP, subredes e máscaras de rede (laboratório) (2 aulas)
21 19/07/2013 Camada de rede: protocolo IP, endereçamento IP, subredes e máscaras de rede (laboratório)
22 25/07/2013 Camada de rede: conclusão (laboratório) (2 aulas)
Camada de enlace: redes locais ethernet; endereçamento ethernet; relação com camada de rede; protocolo ARP
23 26/07/2013 Avaliação 2
24 27/07/2013 Recuperação

Bibliografia

  • Evandro Cantu. Redes de computadores e internet, 1996.
  • FOROUZAN, Behrouz A.; FEGAN, Sophia Chung. Comunicação de dados e redes de computadores. Tradução de Ariovaldo Griesi. 4. ed. São Paulo: McGraw-Hill, 2008. 1134 p., il. ISBN 9788586804885.
  • KUROSE, James F; ROSS, Keith W. Redes de computadores e a Internet: uma abordagem top-down. 5. ed. São Paulo: Pearson Addison Wesley, 2010. 614 p. ISBN 9788588639973.
  • STALLINGS, William. Redes e sistemas de comunicação de dados. Rio de Janeiro: Elsevier, 2005. 449 p. ISBN 9788535217315.
  • TANENBAUM, Andrew S. Redes de computadores. 5. ed. São Paulo: Pearson Prentice Hall, 2011. 582 p. ISBN 9788576059240.

Material de apoio

Listas de exercícios

Listas do prof. Tiago Semprebom:


Lista 1 alternativa (prof. Marcelo Maia Sobral).

Transparências utilizadas durantes as aulas

Curiosidades

Avaliações

Aluno 1a prova 2a prova 3a prova FINAL

Obs: D* = não fez a avaliação.

Softwares

03/05: Apresentação da disciplina

Redes de computadores são conjuntos de equipamentos interligados de forma a poderem se comunicar. A rede mais famosa atualmente é a Internet, porém já existiram outros tipos de redes (se bem que nenhuma se disseminou e popularizou como a Internet). Antes de estudarmos o funcionamento das redes e da Internet em particular, alguns conceitos elementares precisam ser vistos.

Comunicação de dados

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:


Rede-intro-1.png


  1. 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).
  2. Transmissor: dispositivo que transmite a mensagem.
  3. Receptor: dispositivo que recebe a mensagem.
  4. Meio de comunicação: caminho físico por onde viaja a mensagem do transmissor até o receptor.
  5. Protocolo: conjunto de regras que governa a comunicação de dados.

Redes de computadores

Uma rede é um conjunto de equipamentos conectados por enlaces de comunicação (também conhecidos por links), o que posibilita que eles transmitam e recebam mensagens uns dos outros. Diferentes tecnologias de comunicação existem para interligar equipamentos, tais como Ethernet, Wifi, Frame-RElay, ATM, ADSL, Docsis, e muitas outras (isso é assunto de Instalação de Equipamentos de Rede na 3a fase). Existem muitas formas de interligar equipamentos em uma rede, o que se denomina topologia. Algumas topologias elementares são mostradas abaixo:


Topologia Exemplo
Estrela Lan-Star.png
Anel Lan-Ring.png
Barramento Lan-Bus.png
Árvore Lan-Tree.png


Os exemplos acima exemplificam pequenas redes, que possuem poucos computadores. Redes maiores, como a rede da escola e de todo o IFSC, e ainda maiores como a Internet, são compostas de muitas redes menores interligadas. Assim, não é simples classificar a topologia de uma grande rede (talvez nem faça sentido ;-).

Internet-map.png
Uma representação artística das interligações na Internet


Histórico sobre o surgimento das redes de computadores e a Internet

Atividade

  1. Identifique os componentes de uma comunicação de dados em alguma comunicação que se possa fazer a partir de seu computador (ex: navegar na web, fazer chamadas com Skype, enviar mensagens de correio eletrônico, ...).
  2. Qual a topologia da rede do laboratório ? Faça um desenho dessa topologia.
  3. Qual a topologia da rede em sua casa ou local de trabalho ? Faça um desenho dessa topologia.
  4. Quais as diferenças entre as primeiras redes (compostas por mainframes e terminais) e a Internet ?

04/05: Rede de computadores e seus componentes (laboratório)

Na aula de hoje faremos alguns pequenos experimentos para identificar os componentes de uma comunicação de dados e de uma rede de computadores. Em seguida, observaremos que dados são transmitidos e recebidos por algumas aplicações de rede conhecidas.

Experimento 1: identificando os elementos de uma rede de computadores

  1. Vamos fazer um diagrama da rede de computadores do laboratório, e de parte da rede da escola.
  2. Vamos identificar os equipamentos que a compõem e como estão interligados (isso é, sua topologia), assim como o meio de comunicação utilizado.
  3. Em seguida, vamos discutir o papel desses equipamentos dentro da rede. Com isso, teremos uma noção geral de como as comunicações ocorrem dentro da rede.


Rede-ifsc-sj.png

Experimento 2: identificando os componentes de um sistema de comunicação de dados em uma aplicação muito simples

Neste experimento, cada aluno vai se comunicar com uma aplicação muito simples que roda no computador do professor.

  1. Abra um terminal de texto no Linux (menu Aplicativos->Acessórios->Terminal).
    • Execute este comando:
      telnet 192.168.1.1 8888
      
    • Digite qualquer coisa e tecle ENTER. O que aconteceu ?
    • Repita o passo anterior algumas vezes. O que você conclui sobre o que faz essa aplicação ?
    • Digite tchau e tecle ENTER.
  2. Quais os componentes do sistema de comunicação de dados ? E que equipamentos da rede estiveram envolvidos nessa comunicação ?

Experimento 3: identificando os componentes de um sistema de comunicação de dados

Na aula anterior, foi visto que um sistema de comunicação de dados possui a grosso modo cinco componentes: transmissor, receptor, meio de comunicação, mensagem e protocolos. Neste experimento, vamos interagir com um servidor web e identificar esses cinco componentes.

  1. Usando um navegador, acesse os seguintes links:
  2. 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 /~msobral/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 /~msobral/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.

Experimento 4: o que de fato é transmitido ?

A comunicação dentro de uma rede de computadores no fim resulta em mensagens viajando de um equipamento para outro através do meio de comunicação. Cada mensagem é composta por um conjunto de bits, que representam a informação transmitida de acordo com alguma convenção ou codificação. Será que é possível ver esses bits de alguma maneira, enquanto eles viajam pela rede ? Neste experimento teremos um primeiro contato com a visualização de mensagens em transmissão.

Cada equipamento que faz parte da rede possui pelo menos uma interface de rede, que é um dispositivo responsável por enviar e receber mensagens pelo meio de comunicação. Quer dizer, interfaces fazem a ligação entre o equipamento e um meio de comunicação. Assim, se quisermos ver as mensagens transmitidas, devemos tentar observá-las quando passam pela interface de rede.

Existe mais de um programa capaz de mostrar as mensagens que passam por uma interface de rede. Dentre eles, o mais conhecido se chama wireshark. Neste experimento vamos utilizá-lo para ter uma ideia de como se apresentam essas mensagens. No entanto, hoje não iremos nos preocupar em explicar todas as características dessas mensagens (e são muitas !). Nosso objetivo é somente visualizá-las e constatar que elas são conjuntos de bits (ou bytes). Ao final, espera-se que muitas dúvidas surjam, porém essas serão esclarecidas à medida que a disciplina progredir.

Então eis o experimento:

  1. Abra um terminal de texto no Linux (menu Aplicativos->Acessórios->Terminal).
  2. Execute este comando:
    sudo wireshark
    
  3. Na tela do wireshark, mostrada abaixo, em Capture selecione eth0.
    Wireshark-intro.png
  4. Observe na tela do wireshark a quantidade de mensagens capturada. Essa tela deve ser parecida com a figura abaixo:
    Wireshark-list.png
  5. Selecione uma das mensagens e observe seu conteúdo, que deve aparecer no painel inferior da tela. Como ela se apresenta de acordo com o wireshark ?

Para pensar

  1. Faça uma comparação entre o que vimos sobre comunicação de dados e redes de computadores e o sistema de Correios.
  2. Enumere tudo o que acredita ser necessário existir para que uma rede de computadores possa funcionar. Quer dizer, pense em todos os mecanismos que devem existir nos sistemas de comunicação de dados que constituem uma rede de computadores.

16/05: Um modelo para o funcionamento de uma rede

  • Capítulo 2 do livro Comunicação de Dados e Redes de Computadores, 4a ed., de Behrouz Forouzan.
  • Capítulo 1 do livro Redes de Computadores e a Internet, 5a ed., de James Kurose.


Vimos na semana passada que a comunicação entre dispositivos pode ser representada por um sistema de comunicação e dados composto por transmissor, receptor, mensagem, meio de comunicação e protocolo. Se tal modelo for extrapolado para uma rede de computadores, um conjunto de necessidades adicionais surgirão. Para iniciar, vamos olhar para uma possível rede de computadores:

Res-Rede-intro.png

Nessa rede, um computador pode se comunicar com qualquer outro computador. Levando em conta o que estudamos sobre sistemas de comunicação de dados, considere os seguintes casos:

  • Imagine uma mensagem saindo de PC6 destinada a PC1: o que seria necessário existir na rede para que isso fosse possível ?
  • E se PC6 precisar transmitir uma mensagem para PC2 ?
  • E se PC6 precisar transmitir duas mensagens para PC3, as quais devem ser processadas por programas diferentes existentes em PC3 (ex: uma mensagem de correio eletrônico, e outra WWW) ?

O resultado desse exercício deve listar funcionalidades necessárias para que equipamentos se comuniquem em uma rede. Se levarmos isso mais adiante, veremos que é possível organizá-los de uma forma que simplifique sua implementação e seu funcionamento. A ideia é estruturar essas fucionalidades em um modelo de camadas. Para entender como isso pode ser feito, podemos comparar uma rede de computadores com um sistema de correios.


Res-camadas1.png

Sistema de correios representado por um modelo de camadas
(obtido do cap. 2 do livro
Comunicação de Dados e Redes de Computadores de Behrouz Forouzan)

As atividades do lado do emissor são:

  • Camada Superior: o emissor escreve a carta; coloca a carta num envelope; escreve os endereços do remetente e do destinatário e deposita a carta numa caixa de correio.
  • Camada Intermediária: a carta é recolhida por um carteiro que a entrega a um posto do correio mais próximo.
  • Camada Inferior: a carta é classificada pelo correio; em seguida, algum tipo de transporte é acionado para levar a carta ao destino.


Ao longo do caminho: a carta pode ser repassada ao destino pelo próprio posto que a recebeu ou pode ser reenviada a um posto central, para que de lá seja encaminhada ao destino. Além disso, o transporte pode ser feito de avião, carro, trem, navio, ou uma combinação desses meios.


As atividades do lado do receptor são:

  • Camada Inferior: a carta é entregue ao posto local do correio pelo agente que a transportou.
  • Camada Intermediária: a carta é classificada e enviada para a caixa de correio do receptor.
  • Camada Superior: o receptor pega o envelope na caixa de correio, abre o envelope e lê a carta.

O conceito importante a notar nesse exemplo, e que aparece também em redes de computadores, é a hierarquia com que as atividades são desempenhadas. Em resumo, cada camada usa serviços da camada de baixo e fornece serviços para a camada de cima. Desta forma, é possível delimitar exatamente o que deve ser feito em cada nível do sistema.

Atividade: estruturando as funcionalidades de rede em camadas

Baseando-se no exemplo do sistema de Correios, estruture as funcionalidades (ou serviços) necessárias para a comunicação em uma rede de computadores. Pense em quantas camadas poderiam ser definidas para esse modelo aplicado a redes.

Modelo de Camadas da Internet

A Internet é uma rede imensa, que tem alcance mundial. Em sua concepção, foi pensado um modelo de 5 camadas para definir as funcionalidades de rede que devem existir nos dispositivos de rede. Assim, se todos os equipamentos implementarem essas funcionalidades de acordo com esse modelo, eles serão capazes de se comunicarem. O modelo em questão está desenhado abaixo:


Res-camadas2.png
Modelo em 5 camadas para as funcionalidades de rede da Internet


Cada camada possui um papel principal. Isso será estudado com mais detalhes nas próximas aulas, porém a grosso modo pode-se defini-las assim:

  • Aplicação: representa os programas que se comunicam. Cuida de representar os dados a serem transmitidos e as regras de comunicação (isso é, o protocolo) específicas desses programas.
  • Transporte: distribui aos programas a que são destinadas as mensagens que chegam a um dispositivo. Também cuida de verificar se as mensagens forem de fato entregues aos programas destinos.
  • Rede: identifica e escolhe caminhos dentro da rede para que as mensagens cheguem a seus destinos.
  • Enlace: transmite mensagens entre dispositivos que estão ligados por um meio de comunicação.
  • Física: faz a tradução entre os dados (bits) das mensagens e algum tipo de sinal que vai se propagar pelo meio de comunicação.


Dentro dos equipamentos de rede essas cinco camadas vão operar de forma a tornar possível a comunicação entre eles. Assim, nos emissores as mensagens fluem das camadas superiores para as inferiores, e nos receptores elas fluem em sentido contrário. Olhando uma rede exemplo, pode-se imaginar o fluxo dessas mensagens como mostrado nesta figura:


CamadasTCP.png


Cada camada apresenta um ou mais protocolos que cuidam de um ou mais aspectos da comunicação na rede. Todos esses protocolos trabalham com o conceito de mensagem, que já foi usado informalmente em vários lugares aqui na disciplina. Coloquialmente, mensagens de protocolos em redes de computadores são denominadas pacotes (packets). Esse termo pacote tem relação com a ideia de que eles servem para carregar dados que serão transmitidos através da rede. Na verdade, esses pacotes possuem uma estrutura composta por um cabeçalho e dados carregados (ou payload), como mostrado abaixo:


Res-Pacote.png


Se cada protocolo possui seu formato de pacote, e cada camada tem seus próprios protocolos, então os pacotes de uma camada superior são tratados como dados carregados por um protocolo de uma camada imediatamente inferior. Quer dizer, os pacotes gerados por um protocolo em uma camada, ao serem repassados para a camada abaixo, são encapsulados dentro de pacotes do protocolo dessa camada inferior. Esse importante conceito se chama encapsulamento, e é fundamental para entender o funcionamento do modelo de camadas da Internet.

Encapsulamento

Como já mencionado anteriormente, os protocolos da Internet se organizam na forma de camadas. Pacotes de uma camada são inseridos em um pacote de uma camada inferior e tratados de forma transparente por esta camada.

Vamos analisar o encapsulamento com este exemplo e com este exemplo.

Encapsulamento.png

Fonte Wikimedia [1]

Atividade

  1. Compare o modelo de comunicação em rede que foi imaginado na atividade anterior com o modelo em camadas da Internet. Que semelhanças e diferenças existem ? Há algo que se tenha pensado que não esteja contemplado no modelo da Internet ?
  2. Identifique protocolos da Internet e relacione-os com a camada em que operam. Discuta o que faz cada um desses protocolos.
  3. Identifique em que camadas atuam equipamentos de rede típicos, tais como:
    • Roteadores
    • Switches ethernet
    • Conversores de midia (ex: fibra ótica para par-trançado)
    • Pontos de acesso para redes sem-fio
    • Modems digitais (usado para links WAN dedicados)
    • Servidores de rede
    • Laptops e desktops
    • Smartphones

17/05: Laboratório: investigando o modelo de comunicação da rede

Experimento 1: observando a 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.


  1. Execute o wireshark em seu computador: abra um terminal em Aplicativos->Terminal e execute
    sudo wireshark
    
  2. Na tela do wireshark, ative a captura na interface de rede eth0 (ela está listada no lado esquerdo).
  3. Usando um navegador, acesse o link http://tele.sj.ifsc.edu.br/~msobral/res/arquivo.txt.
  4. Interrompa a captura no wireshark, clicando no menu Capture->Stop.
  5. Na tela do wireshark, escreva http na caixa de edição Filter, e em seguida clique em Apply.
  6. 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.
  7. 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.
  8. 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.
  9. 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.

Experimento 2: analisando uma aplicação muito simples

Neste segundo experimento, deve-se analisar uma aplicação muito simples que funciona como um bate-papo pra lá de rudimentar. Seu principal objetivo é apresentar uma aplicação em um computador que se comunica com várias outras aplicações simultaneamente, as quais estão em outros computadores.


  1. Execute o wireshark e ative a captura de pacotes na interface eth0.
  2. Abra um terminal por meio do menu Aplicativos->Terminal. No terminal execute:
    telnet 192.168.1.1 8888
    
  3. Digite qualquer coisa na tela do terminal e tecle ENTER. Observe o que aparece em seguida.
  4. Observe também que, à medida que seus colegas digitam em seus terminais, você recebe uma cópia do texto que eles transmitiram. Veja também que esses textos são precedidos pela identificação de quem a transmitiu.
    • Como o transmissor é identificado ? O que essa informação de fato identifica ?
  5. Veja a lista de pacotes na tela do wireshark. Procure pelos textos que estão sendo transmitidos. para cada pacote desses, observe os protocolos envolvidos e seus respectivos encapsulamentos.
    • que informações identificam a aplicação remota com que você está se comunicando ?
  6. No computador do professor também está rodando o wireshark. Vamos comparar o que mostra a captura de pacotes nesse computador com a que está apresentada pelo seu wireshark.
    • como a aplicação no computador do professor identifica as aplicações dos alunos ?
  7. Abra um segundo terminal em seu computador. Nele conecte-se também ao bate-papo no computador do professor:
    telnet 192.168.1.1 8888
    
    • digite algo nesse novo terminal. O que apareceu no terminal anterior ?
    • Digite algo no terminal anterior. O que apareceu no novo terminal ?
    • Como os pacotes são entregues corretamente a cada terninal, sem confundi-los ? Observe no wireshark o que deve estar sendo usado para isso ....
  8. Qual protocolo fez esse trabalho de separar e classificar corretamente os pacotes em cada computador ? Em que camada da Internet ela atua ?

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.


  1. Execute o wireshark em seu computador, e ative a captura de pacotes.
  2. Usando um navegador, acesse esta página.
  3. 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 ?
  4. 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 da escola). 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 ?
  5. Acesse a página da UFSC. Enquanto isso, observe na tela do projeto do laboratório o wireshark no computador do professor capturando seus pacotes.
    • que informações identificam suas comunicações ?
  6. 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 ?

Considerações finais

Os experimentos realizados hoje 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.

18/05: Laboratório: investigando o modelo de comunicação da rede (cont.)

Não houve aula.

23/05: Aplicações: iniciando com WWW (HTTP)

  • Ver cap. 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.


Res-camadas3.png

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 lá de ICO 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.

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.

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

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 ...

Atividade

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 port (mantidos por protocolos TCP e UDP na camada de transporte).


  1. Para criar um servidor web muito simples, siga estes passos:
    1. Baixe este arquivo.
    2. Execute este comando:
      nc -l 8080 < resposta > pedido
      
    3. Em seu navegador, acesse a URL http://127.0.0.1:8080/.
    4. Observe o resultado na tela do seu navegador, e veja o conteúdo do arquivo pedido.
  2. Para rodar um servidor web pequeno, mas funcional, faça o seguinte:
    1. Baixe este arquivo.
    2. Execute estes comandos:
      tar xzf monkey-1.1.1.tar.gz
      cd monkey-1.1.1
      ./configure --prefix=/home/aluno/monkey
      make
      make install
      
    3. Edite o arquivo /home/aluno/monkey/conf/sites/default e modifique a seguinte linha:
      DocumentRoot /home/aluno/
      
    4. 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
      
    5. Execute o servidor web:
      /home/aluno/monkey/bin/monkey
      
    6. Com seu navegador, acesse http://127.0.0.1:2001/
    7. Experimente navegar pelos links mostrados.
  3. 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:
  4. 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 ?
  5. 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 ?

Para pensar

  1. Para que o protocolo HTTP é usado atualmente além de acesso a documentos na web ? Faça uma pesquisa sobre isso.
  2. Pesquise o significado dos cabeçalhos HTTP vistos nos acessos feitos na aula de hoje.

24/05: Aplicações: iniciando com WWW (HTTP)

Foram concluídas as atividades da aula anterior.

29/05: Aplicações: finalizando WWW e conhecendo correio-eletrônico

  • Ver cap. 26 e 27 do livro Comunicação de Dados e Redes de Computadores, 4a ed., de Behrouz Forouzan.


Textos HTML usados em WWW

Como visto na aula anterior, WWW é um sistema de acesso a documentos de hipermidia, e o protocolo HTTP serve para transferir esses documentos. Mas afinal como se apresenta um documento em hipermidia ? Quando foi inventado WWW e HTTP, criou-se também um formato de texto chamado HTML (Hypertext Markup Language), que serve para descrever hipertextos. Esse formato de texto possibilita criar documentos com texto, figuras, videos, som, além de referências (links) a outros documentos na web.

Um exemplo de um texto HTML muito simples segue abaixo:

<html>
  <head>
    <title>Uma demonstracao</title>
  </head>
  <body>
    <h1>Uma demonstracao</h1>
    Este pequeno texto mostra um documento <a href="http://pt.wikipedia.org/wiki/HTML">HTML</a>, 
incluindo a possibilidade de criar <i>links</i> para outros documentos, e incluir figuras.
    <br><br>
    <img src="marzao.jpg">
    <br><i>Uma figura de demonstracao ...</i>
    <br><br>
    <a href="http://wiki.sj.ifsc.edu.br/index.php/RES-2013-1">Volta pra wiki</a>
  </body>
</html>

Experimente salvar o texto acima em um arquivo, e acessá-lo com seu navegador. Em seguida, tente acessá-lo usando o seu servidor web Monkey.

Um texto HTML é composto por um número de tags, que indicam que naquele ponto do texto há uma formatação especial ou deve-se incluir alguma coisa. As tags são envoltas por < e >, e em geral são usadas aos pares:

  • A tag inicial inicia uma formatação. Ex: <h1>
  • A tag final delimita o fim de uma formatação. Ex: </h1>

No entanto, nem todas tags seguem essa lógica. Algumas tags apenas indicam que naquele ponto do texto algo deve ser incluído, e assim esse tipo de tag não aparece aos pares. Por exemplo, esse é o caso das tags:

  • <br>: insere uma quebra de linha.
  • <img>: insere uma imagem.


A estrutura do texto inicia com a tag <html>, e termina com </html>. Tudo que está entre essas tags forma o documento HTML. O documento em si é composto de duas seções:

  • Cabeçalhos: contém atributos e informações sobre o texto, tais como seu título. Essa seção é delimitada pelas tags <head> e </head>.
  • Corpo: contém o conteúdo do texto em si, sendo delimitada por <body> e </body>.


Uma tag especialmente importante possibilita criar uma ligação (link) com outros documentos. Essa tag é mostrada no exemplo a seguir:

    <a href="http://wiki.sj.ifsc.edu.br/index.php/RES-2013-1">Volta pra wiki</a>

A tag inicia com <a href=URL_ou_caminho_do_outro_documento>, seguida do texto a ser destacado e associado à ligação, e terminada com </a>.


Existem muitas tags, e portanto muitos recursos para formatação de textos HTML. Alguns bons tutoriais podem ser encontrados na própria web, com a lista completa de tags HTML ilustradas com exemplos. Por exemplo:

Atividade

  1. Páginas que contêm videos podem ser criadas de diferentes formas. Uma delas usa recursos semelhantes aos usados pelo Youtube, em que um tocador de video é carregado junto com a página.
    1. Veja esta página, acompanhando a comunicação com o wireshark.
    2. Avance a reprodução, e veja o que modificou na transferência dos pacotes HTTP. Como o reposicionamento da reprodução do video foi feita com esse protocolo ?
    3. Quantos pacotes foram recebidos, relacionados à transmissão do video ?
    4. Veja o texto HTML (código-fonte) dessa página, identificando seus elementos e como se apresenta o reprodutor de video.
    5. Experimente modificá-lo para tocar algum outro video que você encontrar na Internet
  2. Crie uma página HTML com seus dados pessoais:
    • Use figuras e inclua referências a outras páginas ou sites do seu interesse.
    • Inclua uma agenda com seus contatos (demais colegas da sua turma ?).
    • Salve-a de forma a poder ser acessada com o seu servidor web Monkey.

Correio eletrônico: um grande e útil sistema (ainda) muito usado

O correio eletrônico (email) é ainda 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.

Funcionamento do email

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.

Email-intro.png

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.
  • 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.
  • 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).

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, mas isso é um assunto para mais adiante ... por enquanto basta saber que um domínio representa um conjunto de endereços de email tratados administrativamente da mesma forma.

Mensagens de email

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
Received: from zeus.das.ufsc.br (zeus.das.ufsc.br [150.162.12.8])
        by mx.google.com with ESMTP id e12si8422753vcx.66.2010.04.25.07.40.18;
        Sun, 25 Apr 2010 07:40:19 -0700 (PDT)
Received: from submissoes.sbc.org.br (submissoes.sbc.org.br [143.54.31.12])
	by zeus.das.ufsc.br (Departamento de Automacao e Sistemas (DAS-UFSC)) with ESMTP id BA97E7BD90
	for <tele@ifsc.edu.br>; Sun, 25 Apr 2010 11:30:00 -0300 (BRT)
Received: from submissoes.sbc.org.br (localhost [127.0.0.1])
	by submissoes.sbc.org.br (8.14.3/8.14.3/Debian-4) with ESMTP id o3PEZ70L029107
	for <tele@ifsc.edu.br>; Sun, 25 Apr 2010 11:35:07 -0300
Received: (from www-data@localhost)
	by submissoes.sbc.org.br (8.14.3/8.14.3/Submit) id o3PEZ7kH029104;
	Sun, 25 Apr 2010 11:35:07 -0300
Date: Sun, 25 Apr 2010 11:35:07 -0300
Message-Id: <201004251435.o3PEZ7kH029104@submissoes.sbc.org.br>
From: WTR 2010 <lbecker@das.ufsc.br>
To: "Telê Santana" <tele@ifsc.edu.br>
Subject: Final version and registration
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

Dear Coach,

Please remember to upload the camera-ready version of your paper and to
register in the competition by April 27.

See you in Spain,

FIFA World Cup Staff - Spain - 1982

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.

Atividade

  1. Conectar-se a um servidor de email, e enviar manualmente uma mensagem. Fazer primeiro com um programa (Thunderbird) e depois manualmente (com telnet).
    1. Primeiro acesso: usando o webmail que está em http://192.168.2.1/webmail
      • Envie mensagens para seus colegas, e confira seu recebimento.
      • Envie mensagens para endereços de email externos (ex: no hotmail ou gmail) e veja se foram enviadas.
    2. 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 192.168.2.1 25
        
      • Converse com o servidor de email usando o protocolo SMTP, que é textual:
        helo mail
        250 m1
        mail from: aluno19@redes2.sj.ifsc.edu.br
        250 2.1.0 OK
        rcpt to: aluno1@redes2.sj.ifsc.edu.br
        250 2.1.5 OK
        data
        354 End data with <CR><LF>.<CR><LF>
        From: Aluno 19 <aluno19@redes2.sj.ifsc.edu.br>
        To: Aluno 1 <aluno1@redes2.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.

06/06: Aplicações: Continuando correio-eletrônico

  • Ver cap. 26 do livro Comunicação de Dados e Redes de Computadores, 4a ed., de Behrouz Forouzan.


Res-Camadas-protocolos.png
Atualizando a arquitetura de redes que já conhecemos


Mensagens de email

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
Received: from zeus.das.ufsc.br (zeus.das.ufsc.br [150.162.12.8])
        by mx.google.com with ESMTP id e12si8422753vcx.66.2010.04.25.07.40.18;
        Sun, 25 Apr 2010 07:40:19 -0700 (PDT)
Received: from submissoes.sbc.org.br (submissoes.sbc.org.br [143.54.31.12])
	by zeus.das.ufsc.br (Departamento de Automacao e Sistemas (DAS-UFSC)) with ESMTP id BA97E7BD90
	for <tele@ifsc.edu.br>; Sun, 25 Apr 2010 11:30:00 -0300 (BRT)
Received: from submissoes.sbc.org.br (localhost [127.0.0.1])
	by submissoes.sbc.org.br (8.14.3/8.14.3/Debian-4) with ESMTP id o3PEZ70L029107
	for <tele@ifsc.edu.br>; Sun, 25 Apr 2010 11:35:07 -0300
Received: (from www-data@localhost)
	by submissoes.sbc.org.br (8.14.3/8.14.3/Submit) id o3PEZ7kH029104;
	Sun, 25 Apr 2010 11:35:07 -0300
Date: Sun, 25 Apr 2010 11:35:07 -0300
Message-Id: <201004251435.o3PEZ7kH029104@submissoes.sbc.org.br>
From: WTR 2010 <lbecker@das.ufsc.br>
To: "Telê Santana" <tele@ifsc.edu.br>
Subject: Final version and registration
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

Dear Coach,

Please remember to upload the camera-ready version of your paper and to
register in the competition by April 27.

See you in Spain,

FIFA World Cup Staff - Spain - 1982

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.

Acesso a caixas de mensagens: protocolos POP3 e IMAP

POP3 (Post Office Protocol) e IMAP (Internet Message Access Protocol) são protocolos criados para acessar mensagens armazenadas em caixas de mensagens de usuários. Em ambos os casos, um programa servidor é executado no computador onde estão armazenadas as mensagens (quer dizer, eles seguem o modelo cliente-servidor). Esse programa aceita conexões vindas de programas clientes, e por meio desses protocolos possibilita acessos às caixa de entrada de usuários. Programas clientes são leitores de email, usados por pessoas para lerem suas mensagens (ex: Mozilla Thunderbird, Microsoft Outlook, e webmail em geral). As operações típicas possíveis de serem feitas com esses protocolos são obter uma cópia de uma mensagem (transferi-la para o programa cliente), listar as mensagens existentes e apagar uma mensagem.

O protocolo POP3 foi criado primeiro (sua última revisão ocorreu em 1996). Suas mensagens são textuais, com comandos simples para obter mensagens, listar mensagens e apagá-las (há outros, mas esses são os principais). Quando ele foi criado, a maioria das pessoas acessava a Internet com acesso discado, que é lento e caro. Por isso esse protocolo foi feito para baixar as mensagens para o computador do usuário, e removê-las do servidor. Isso quer dizer que, para um usuário saber o assunto de uma mensagem, ou quem a enviou, ele terá primeiro que copiá-la inteira para seu computador. Quando o uso de correio eletrônico aumentou, e também a quantidade e tamanho das mensagens (com seus arquivos anexados), surgiu a necessidade de um protocolo de acesso a mensagens que possibilitasse manipulá-las diretamente no servidor. Dessa iniciativa surgiu o protocolo IMAP.

IMAP (última revisão em 2003) é um protocolo de acesso a mensagens razoavelmente complexo, com muitas possibilidades de pesquisa e transferência parcial ou completa de mensagens. Além das operações suportadas pelo POP3, ele é capaz de fornecer listagens de mensagens incluindo seus cabeçalhos (evitando ter que copiar mensagens completas para saber do que se tratam), fazer pesquisas nas mensagens com base em seus cabeçalhos (ex: mensagens enviadas por uma determinada pessoa), e transferir parcialmente mensagens (ex: transferir somente um arquivo anexado). Atualmente é a forma mais usada de acessar mensagens em servidores, mesmo com webmail.

Atividade

Usando novamente o servidor de correio eletrônico do laboratório, vamos fazer experiências com acessos a caixas de mensagens.

  1. Use o Mozilla Thunderbird para acessar suas mensagens com POP3. Ele pode ser encontrado no menu Aplicativos->Internet. Crie uma conta no Thunderbird (use configuração manual). Ela deve ter as seguintes informações:
    • Email: alunoX@redes2.sj.ifsc.edu.br
    • Servidor de entrada: tipo POP3 e endereço 192.168.2.1
    • Servidor de saída: tipo SMTP e endereço 192.168.2.1
    • Nome de usuário: alunoX
  2. Acesse sua conta de email com o Thunderbird. Experimente visualizar as mensagens, comparando a experiência com o webmail. Tente também enviar mensagens.
  3. Execute o wireshark, pondo-o a capturar pacotes na interface de rede eth0, e em seguida acesse novamente sua caixa de mensagens com o Thunderbird.
    • Identifique as mensagens POP3
    • Acompanhe a conversação entre o Thunderbird e o servidor POP3
  4. Encerre o Thunderbird. Em seguida, faça um acesso manual ao servidor POP3 da seguinte forma.
    • Execute este comando:
      telnet 192.168.2.1 110
      
      Obs: o protocolo POP3 usa o port TCP 110
    • Digite o seguinte para fazer a autenticação de usuário no servidor POP3:
      user alunoX
      pass senhaX
      
    • Uma vez estando autenticado, verifique quantas mensagens há em sua caixa:
      stat
      
    • Liste as mensagens contidas em sua caixa:
      list
      
    • Transfira para seu computador a última mensagem da listagem. Exemplo, se ela for identificada pelo número 5 (ver coluna esquerda da listagem), este comando irá transferi-la:
      retr 5
      
    • Apague a última mensagem de sua caixa:
      dele 5
      
    • Liste novamente as mensagens.
    • Encerre a conexão.
      quit
      
  5. Vamos repetir o experimento usando o protocolo IMAP. Novamente execute o Thunderbird, porém desta vez crie uma conta IMAP (as demais informações são idênticas à conta POP3).
  6. Acesse sua caixa de entrada, listando suas mensagens e visualizando algumas delas.
  7. Observe que com IMAP é possível ter outras caixas de mensagens no servidor, as quais são denominadas IMAP folders (ou pastas IMAP). Por exemplo, deve existir uma pasta INBOX (a caixa de entrada), e também Draft (rascunhos), Trash (lixeira) e Sent (mensagens enviadas).
    • Acesse essas caixas de mensagens. Note elas funcionam idêntico à caixa de entrada.
    • Envie uma nova mensagem. Repare que uma cópia foi colocada na pasta Sent.
    • Experimente criar uma nova pasta IMAP. Por exemplo, ela pode se chamar Ifsc.
    • Você pode copiar ou mover mensagens entre as pastas. Experimente copiar mensagens para a nova pasta criada.
    • Tente acessar a nova pasta usando a conta POP3 ... é possível ?
  8. Encerre o Thunderbird, e em seguida execute o wireshark. Ponha-o a capturar pacotes na interface de rede eth0.
  9. Novamente execute o Thunderbird, e acesse sua conta IMAP.
    • Liste as mensagens, acesse pastas, e visualize mensagens.
    • Acompanhe no wireshark a conversação entre o Thunderbird e o servidor IMAP. Compare-a com aquela feita com POP3.
  10. Agora que você sabe como funciona POP3 e IMAP, experimente acessar suas contas de email externas (ex: gmail, hotmail, ...) usando o Thunderbird.

07/06: Aplicações: DNS - um serviço para ajudar a identificar hosts na Internet (e outras coisas mais)

  • Cap. 25 do livro Comunicação de Dados e Redes de Computadores, 4a. ed., de Behrouz Forouzan.


DNS é um dos serviços fundamentais da Internet, tendo sido concebido lá por 1987 (ver RFC 1034 e RFC 1035) !

De certa forma, o serviço DNS (Domain Name System) pode ser comparado a um grande catálogo telefônico, que possibilita que se descubra o endereço IP (nessa analogia, equivalente ao número de telefone) associado a um determinado nome de domínio (comparável ao nome de uma pessoa ou empresa). A ideia é poder endereçar máquinas com nomes mais fáceis de lidar e memorizar, ao contrário de usar endereços numéricos.

Lembre que:

  • Máquinas são identificadas na Internet por endereços numéricos denominados endereços IP.
  • Nomes de domínios são nomes de fácil memorização que são associados a essas máquinas.

A seção a seguir descreve esse serviço fundamental da Internet.

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:

  1. Atualmente existem bilhões de endereços de IP em uso e a grande maioria das máquinas possui um nome legível associado.
  2. 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.
  3. Nomes de domínio e endereços de IP podem mudar frequentemente (até mesmo diariamente).
  4. Novos nomes de domínio são criados todos os dias.
  5. 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.

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 navegadopr, por exemplo, a URL http://216.183.103.150 e alcançaria a máquina que contém o servidor do HowStuffWorks. 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.

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.

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:

  1. Pode responder diretamente com um endereço de IP, por já conhecer previamente este endereço do domínio.
  2. 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.
  3. 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.”
  4. 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

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.

Hierarquia-DNS.gif

(tirado do manual do BIND9)

Ver também o livro sobre DNS e BIND da O'Reilly.

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):

msobral@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

Atividade

  1. 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
  2. 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
    
  3. 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
    
  4. 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 ?
  5. 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
  6. 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.
  7. 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 ?
    1. Descubra quem são os servidores raiz (topo de hierarquia DNS):
      host -t ns .
      
    2. 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.
    3. Continue fazendo as consultas aos servidores DNS listados, até conseguir traduzir o nome requisitado. Quantos servidores DNS foi necessário consultar no total ?
    4. 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

13/06: Aplicações: VoIP - fazendo chamadas de voz pela rede de comunicação de dados


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:

Fone-call.png

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).

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.

Sip-relation.gif
'Mensagens, transações, diálogos e chamadas

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):


Sip-example1.png


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)

Diagramas de chamadas

Alguns tipos de chamadas VoIP com SIP são recorrentes, estando representadas nas subseções a seguir.

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           |
     |----------------------->|
     |                        |

| INVITE |

    |  100 Trying    |--------------->|    
    |<---------------|   100 Trying   |
    |                |<---------------|                
    |                |                |     
    |                |  180 Ringing   |
    |  180 Ringing   |<---------------|                
    |<---------------|                |    
    |                |    200 Ok      |
    |     200 Ok     |<---------------|                
    |<---------------|                |                
    |     ACK        |                |                
    |--------------->|    ACK         |                
    |                |--------------->|    
    |                |                |
    |         RTP Media               |
    |<===============================>|
    |                |                |
    |                |    BYE         |
    |     BYE        |<---------------|                
    |<---------------|                |                
    |     200 Ok     |                |                
    |--------------->|     200 Ok     |                
    |                |--------------->|    
    |                |                |
    |                |                |                

</syntaxhighlight>

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     |<---------------|
     |<---------------|                |
     |                |                |

Protocolo RTP


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
Rtp1.png Tip-Rtp-header.png


Tip-Rtp-avp.png
Perfil RTP/AVP, com codecs e seus códigos numéricos

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.

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:

  1. Executar o Jitsi (ver em Aplicativos->Internet).
  2. Definir uma conta SIP contendo somente um identificador de usuário (sem a localização).
  3. 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.
  4. Experimente falar ao microfone e escutar o som no fone de ouvido.
  5. 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:

  1. Execute o wireshark e inicie a captura de datagramas UDP pela interface eth0.
  2. Repita a chamada.
  3. Após encerrar a chamada, analise mensagens SIP no wireshark (menu Telephony -> Voip Calls -> Graph)
  4. Disseque a sinalização SIP entre os softphones.
  5. Identifique como foi transportada a voz digitalizada.


Questões:

  1. Quem foram o UAC e UAS nesse experimento ?
  2. Quantas requisições SIP foram realizadas para uma chamada completa ?
  3. Quantas mensagens, transações, diálogos e chamadas foram realizadas ?
  4. Que protocolo de transporte é usado pelo SIP ?
  5. Como a voz digitalizada foi transportada ? Foi usado algum protocolo em especial ?

Atividade 2: chamada intermediada por um soft PBX

Obs: para esta atividade cada aluno tem duas contas SIP: 1XX@redes2.sj.ifsc.edu.br e 2XX@redes2.sj.ifsc.edu.br (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@redes2.sj.ifsc.edu.br

2. Instale um telefone IP, configurando-o apropriadamente para que registre sua conta SIP no soft PBX (que tem IP 192.168.2.1). Isso vai depender do modelo de telefone IP (Voiper da Intelbras, ou o telefone da Khomp).

3. A partir do softphone faça uma chamada para a conta do telefone IP. Verifique se o telefone IP acusou o recebimento de chamada. Caso isso não tenha ocorrido, verifique seu plano de discagem.

4. Execute o wireshark, e ponha-o em modo de captura na interface eth0.

5. Repita a chamada de um softphone ao telefone IP. No telefone IP 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:

  1. Que papel desempenhou o Asterisk para os softphones ? UAC, UAC ou algo diferente ?
  2. Como o Asterisk conseguiu identificar o telefone chamado (i.e. localizar onde ele estava na rede) ?

14/06: Revisão

20/06: Não houve aula (manifestações de rua)

21/06:Avaliação 1

Ver a 1a lista de exercícios.

27/06: Protocolos de transporte

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.


Res-Camadas-protocolos.png
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.

Atividade

As atividades de hoje buscarão mostrar as características básicas de comunicações com protocolos de transporte.

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 ?

Tipos de protocolos de transporte: TCP x UDP

Nestes experimentos, serão evidenciadas diferenças entre os protocolos TCP e UDP.

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 ?

  1. 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
    
  2. Observe o tamanho do arquivo transferido ... ele deve ter exatamente 726970368 bytes (cerca de 700 MB). Você pode fazer isso com o comando ls -l ubuntu.iso, ou executando o gerenciador de arquivos e visualizando as propriedades desse arquivo.
  3. Escolha um colega para fazer o experimento, em que o arquivo será transferido de um computador para o outro.
  4. 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.2.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 ?
  5. 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.2.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 ?
  6. 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 ?

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:


Res-Exp2-transporte.png


  1. Abra um terminal em seu computador, e nele execute este comando:
    wget http://tele.sj.ifsc.edu.br/~msobral/res/ubuntu.iso
    
  2. Observe a taxa de transferência (velocidade do download) obtida. Que valores ela apresenta ? Quanto tempo levou para o arquivo ser transferido ?
  3. 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 ?
  4. 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 ?
  5. 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 ?
  6. 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:
    1. Abra dois terminais. Em um deles execute este comando:
      watch -n 1 ls -l arquivo
      
      ... e no outro execute:
      ./receptor 5555 > arquivo
      
    2. O professor irá transmitir o arquivo a partir do servidor. Observe o tamanho do arquivo, que deverá aumentar.
    3. Em que valor o tamanho do arquivo parou de crescer ? Quanto tempo isso levou, aproximadamente ? E esse tamanho final é o mesmo do arquivo original ?
    4. Como se comparam as transferências usando TCP e UDP ?

28/06: Protocolos de transporte