Redes de Computadores

Esta apresentação contém slides fornecidos pela Editora Pearson como material de apoio ao Professor do livro “Redes de Computadores e a Internet: uma abordagem top-down”

1

Elmano R. Cavalcanti

Camada de Aplicação

elmano.cavalcanti@garanhuns.ifpe.edu.br

http://sites.google.com/site/elmano

∙ Correio Eletrônico (e-mail)‏

∙ WWW (hipertexto - http://www...)‏

∙ Mensagem instantânea (MSN, ICQ, AIM, gtalk, Messenger, …)

∙ Login remoto (e.g., SSH)

∙ Compartilhamento de Arquivos Entre-Pares (P2P)

∙ Jogos multi-usuário em Rede

∙ Streaming de vídeos (sob-demanda ou online)

∙ Telefonia via Internet (VoIP)

∙ Videoconferência em tempo real

∙ Grades Computacionais (grid computing)

2

Algumas aplicações de rede

Escrever programas que

• Executem sobre diferentes sistemas finais e
• Se comuniquem através de uma rede.
• Ex.: Software de servidor Web se comunicando com software do navegador (browser).

Nenhum software é escrito para dispositivos no núcleo da rede

• Dispositivos do núcleo da rede não trabalham na camada de aplicação
• Isso permite um rápido desenvolvimento de aplicação

3

Criando uma nova aplicação de rede

∙ Cliente-servidor

∙ Entre-Pares (Peer-to-peer, P2P)‏

∙ Híbrida de cliente-servidor e P2P

4

Arquiteturas de aplicação

2.1 Princípios de aplicações em rede de computadores

2.2 Web e HTTP

2.3 FTP

2.4 Correio eletrônico

- SMTP, POP3, IMAP

2.5 DNS

5

Camada de aplicação

6

Arquitetura cliente-servidor

Clientes:

∙ Comunicam-se com o servidor

∙ Pode ser conectado intermitentemente

∙ Pode ter endereço IP dinâmico

∙ Não se comunicam diretamente uns com os outros

Servidor:

∙ Hospedeiro sempre ativo

∙ Endereço IP permanente

∙ Fornece serviços solicitados pelo cliente

∙ Nem sempre no servidor

∙ Sistemas finais arbitrários comunicam-se diretamente

∙ Pares são intermitentemente conectados e trocam endereços IP

∙ Ex.: Gnutella (lê-se newtella)‏

​

Altamente escaláveis mas difíceis de gerenciar

​

7

Arquitetura P2P pura

Napster

• Transferência de arquivo P2P
• Busca centralizada de arquivos:

∙ Conteúdo de registro dos pares no servidor central

∙ Consulta de pares no mesmo servidor central para localizar o conteúdo

Mensagem Instantânea (ex: MSN)

• Bate-papo entre dois usuários é P2P
• Detecção/localização de presença é centralizada:

∙ Usuário registra seu endereço IP com o servidor central quando fica on-line

∙ Usuário contata o servidor central para encontrar endereços IP dos “amigos”

​

8

Híbrida de cliente-servidor e P2P

Processo: programa executando num hospedeiro

∙ Dentro do mesmo hospedeiro: dois processos se comunicam usando comunicação interprocesso (definido pelo Sistema Operacional)

∙ Processos em diferentes hospedeiros se comunicam por meio de troca de mensagens

Processo cliente: processo que inicia a comunicação

Processo servidor: processo que espera para ser contatado

9

Comunicação de processos

∙ Um processo envia/recebe mensagens para/de seu socket

• O socket é análogo a uma porta

∙ O processo de envio empurra a mensagem para fora da porta

∙ O processo de envio confia na infra-estrutura de transporte no outro lado da porta que leva a mensagem para o socket no processo de recepção.

10

Sockets (“Portas”)

∙ Para um processo receber mensagens, ele deve ter um identificador

∙ Um hospedeiro possui um único endereço IP de 32 bits (assumindo IPv4)‏

∙ P.: O endereço IP do hospedeiro onde o processo está executando é suficiente para identificar o processo?

∙ R.: Não, muitos processos podem estar em execução no mesmo hospedeiro.

∙ O identificador inclui o endereço IP e o número da porta associada ao processo no hospedeiro

• Exemplos:

∙ Servidor HTTP: 80

∙ Servidor de E-mail: 25

11

Processos de endereçamento

∙ Tipo das mensagens trocadas, mensagens de requisição e resposta

∙ Sintaxe dos tipos de mensagem: os campos nas mensagens e como são delineados

∙ Semântica dos campos, ou seja, significado da informação nos campos

∙ Regras para quando e como os processos enviam e respondem às mensagens

Protocolos de domínio público:

∙ Definidos nas RFCs

∙ Recomendados para interoperabilidade

∙ Ex.: HTTP, SMTP, DNS, SSH

Protocolos proprietários:

∙ Ex.: KaZaA

12

O protocolo da camada de aplicação define

Perda de dados

∙ Algumas aplicações (ex.: áudio) podem tolerar alguma perda

∙ Outras aplicações (ex.: transferência de arquivos, sessão remota) exigem transferência de dados 100% confiável

Temporização

∙ Algumas aplicações (ex.: telefonia Internet, jogos interativos) exigem baixos atrasos para serem “efetivos”

Banda passante

∙ Algumas aplicações (ex.: vídeo sob demanda - Netflix) exigem uma banda mínima para serem “efetivas”

∙ Outras aplicações (“aplicações elásticas”) melhoram quando a banda disponível aumenta

​

13

De qual serviço de transporte uma aplicação necessita?

14

Aplicação

​

Transf. de arquivos

E-mail

Navegação na Web

Real-time áudio/vídeo

Stored áudio/video

Jogos interativos

Comércio eletrônico

Perdas

​

sem perdas

sem perdas

sem perdas

tolerante

​

tolerante

tolerante

sem perda

Banda

​

elástica

elástica

elástica

aúdio: ~ 300 kbps

vídeo: > 2 Mbps

igual à anterior

alguns kbps

elástica

Sensível ao atraso

​

não

não

não

sim, décimos de seg.

​

sim, segundos

sim, décimos de seg.

sim

Requisitos de transporte de aplicações comuns

Serviço TCP: orientado à conexão e confiável

​

Serviço UDP: sem conexão e não-confiável

​

​

Nem TCP nem UDP oferecem garantias de temporização e de banda mínima.

​

P.: Por que ambos? Por que existe o UDP?

15

Serviços dos protocolos de transporte da Internet

16

Aplicação

​

E-mail

Acesso remoto a terminais

Web

Transferência de arquivos

Streaming multimídia

​

Servidor de arquivos remoto

Telefonia na Internet (VoIP)

​

Protocolo de aplicação

​

smtp [RFC 821]

telnet [RFC 854]

http [RFC 2068]

ftp [RFC 959]

RTP ou proprietário

(ex.: RealNetworks)‏

NFS

RTP ou proprietário

(ex.: Vocaltec)‏

Protocolo de

transporte

​

TCP

TCP

TCP

TCP

TCP ou UDP

​

TCP ou UDP

tipicamente UDP

Aplicação e protocolos de transporte da Internet

Primeiro alguns jargões

∙ Página Web consiste de objetos

∙ Objeto pode ser arquivo HTML, imagem JPEG, Java applet, arquivo de áudio,…

∙ A página Web consiste de arquivo-HTML base que inclui vários objetos referenciados

∙ Cada objeto é endereçado por um Universal Resource Locator (URL)

∙ Exemplo de URL:

​

17

http://sites.google.com/site/elmano/home/erc_id.jpg

Nome do hospedeiro

Nome do caminho

Web e HTTP

2.1 Princípios de aplicações em rede de computadores

2.2 Web e HTTP

2.3 FTP

2.4 Correio eletrônico

- SMTP, POP3, IMAP

2.5 DNS

18

Camada de aplicação

HTTP: hypertext transfer protocol

∙ Protocolo da camada de aplicação da Web

• Modelo cliente/servidor

∙ Cliente: navegador que solicita, recebe e apresenta objetos da Web

∙ Servidor: envia objetos em resposta a pedidos

∙ HTTP 1.0: RFC 1945

∙ HTTP 1.1: RFC 2068

19

HTTP: Visão geral

Utiliza TCP:

∙ Cliente inicia conexão TCP (cria socket) para o servidor na porta 80

∙ Servidor aceita uma conexão TCP do cliente

∙ mensagens HTTP (mensagens do protocolo de camada de aplicação) são trocadas entre o browser (cliente HTTP) e o servidor Web (servidor HTTP)

∙ A conexão TCP é fechada

​

HTTP é sem estado (stateless) : “sem memória”

∙ Por padrão, o servidor não mantém informação sobre os pedidos passados pelos clientes

​

Protocolos que mantêm informações de “estado” são complexos!

20

HTTP: Visão geral

HTTP não persistente (antigamente)

∙ No máximo, um objeto é enviado sobre uma conexão TCP

∙ O HTTP/1.0 utiliza conexão não persistente

​

HTTP persistente (atualmente)

• Múltiplos objetos podem ser enviados sobre uma conexão

∙ TCP entre o cliente e o servidor

∙ O HTTP/1.1 utiliza conexões persistentes em seu modo padrão

21

HTTP: Tipos de conexões

HTTP: Tipos de mensagem e métodos

• Dois tipos de mensagens: (exemplo)
• Requisição
• Resposta

​

• Dois tipos (principais) de métodos:
• GET: exemplo
• A entrada é enviada no campo de URL
• Ex: ações de pesquisa em sites usam GET
• POST: exemplo
• A entrada é enviada para o servidor no corpo da entidade
• Ex: ações de cadastro de formulários usam POST

​

Aprendendo na prática! (tecla F12)

• Firefox + Firebug, Google Chrome ou Internet Explorer

22

HTTP: Código de status

23

Na primeira linha da mensagem de resposta servidor → cliente.

Alguns exemplos de códigos:

200 OK

∙ Requisição bem-sucedida, objeto requisitado a seguir nesta mensagem

301 Moved permanently

∙ Objeto requisitado foi movido, nova localização especificada a seguir nesta mensagem (Location:)

400 Bad request

∙ Mensagem de requisição não compreendida pelo servidor

404 Not Found

∙ Documento requisitado não encontrado neste servidor

505 HTTP version not supported

​

A maioria dos grandes sítios Web utilizam cookies

Quatro componentes:

1) Linha de cabeçalho do cookie na mensagem HTTP response

2) Linha de cabeçalho de cookie na mensagem HTTP request

3) Arquivo de cookie mantido no hospedeiro do usuário e manipulado pelo browser do usuário

4) Banco de dados backend no sítio Web

​

Vendo os cookies na prática: Firefox + Firebug (Firecookies)

- Site de compras (ex: http://www.submarino.com.br)

Novamente, tecla mágica: F12

24

Cookies

25

Cliente

Servidor

usual HTTP request msg

usual HTTP response +

Set-cookie: 1678

usual HTTP request msg

cookie: 1678

usual HTTP response msg

usual HTTP request msg

cookie: 1678

usual HTTP response msg

especificação

do cookie

especificação

do cookie

servidor

cria o ID 1678

para o usuário

entrada no banco

de dados backend

acesso

acesso

Uma semana depois:

Cookies: mantendo “estado”

O que os cookies podem trazer:

∙ Autorização

∙ Cartões de compra

∙ Recomendações

∙ Estado de sessão do usuário (Web e-mail)

​

Cookies e privacidade:

∙ Cookies permitem que sites saibam muito sobre você

∙ Você pode fornecer nome e e-mail para os sites

∙ Mecanismos de busca usam redirecionamento e cookies para saberem mais sobre você

∙ Companhias de propaganda obtêm informações por meio dos sites

​

26

Cookies

∙ Usuário configura o browser: acesso Web é feito por meio de um procurador (proxy).

• Cliente envia todos os pedidos HTTP para o proxy

∙ Se o objeto existe na cache do procurador: o procurador retorna o objeto

∙ Caso contrario, o procurador solicita o(s) objeto(s) do servidor original, e então envia o(s) objeto(s) ao cliente

27

Objetivo: atender o cliente sem envolver o servidor Web originador da informação.

Web caches (servidor proxy)

∙ A cache atua tanto no servidor como no cliente

∙ Tipicamente, a cache é instalada pelo ISP (universidade, companhia, ISP residencial)‏

​

Por que Web caching?

​

∙ Reduz o tempo de resposta para a requisição do cliente.

∙ Reduz o tráfego em um enlace de acesso de uma instituição.

∙ Permite navegação anônima (segurança)

∙ Pode permitir acesso restrito a determinados sites ou serviços

​

- Exemplo de script de proxy: http://dsc.ufcg.edu.br/~elmano/a

- Site com listas de servidores proxy: http://spys.ru/en/

28

Mais sobre Web caching

Suponha:

∙ Tamanho médio objeto = 100.000 bits

∙ Taxa média de requisições dos browsers da instituição para os servidores de origem = 15/s

∙ Atraso total = atraso da Internet (roteador externo -> destino -> roteador externo) + atraso de acesso (entre roteador institucional e roteador externo) + atraso da LAN (rede local)

• Exemplo (atraso Internet = 2 s): tempo total = 2 s + x ms + y ms

Conseqüências:

∙ Utilização da LAN = 15%

∙ Utilização do link de acesso = 100%

​

29

Exemplo de uso de servidor proxy

Solução possível

∙ Aumentar a largura de banda do enlace de acesso, como, por exemplo, 10 Mbps

• Conseqüências
• Utilização da LAN = 15%
• Utilização do enlace de acesso = 15%
• Freqüentemente é um upgrade caro
• Para o exemplo anterior, tempo médio de acesso ainda em torno de 2 s (i.e., tempo de acesso a Internet é o fator dominante!)‏

​

30

Exemplo de uso de servidor proxy

Instalação do proxy

∙ Suponha que a taxa de acertos seja 0.4

Conseqüência

∙ 40% das requisições serão satisfeitas quase que imediatamente pelo proxy

∙ 60% das requisições serão satisfeitas pelo servidor de origem

∙ Utilização do enlace de acesso reduzida para 60%, resultando em atrasos insignificantes (vamos assumir algo em torno de 10 ms)‏:

tempo total = 0.4 (0,01) + 0.6 (2 + 0,01)‏

= 1,2 s

​

31

Exemplo de uso de servidor proxy

∙ Razão: não enviar objeto se a versão que o cliente já possui está atualizada.

• Cliente: especifica data da versão armazenada no pedido HTTP

∙ If-modified-since: <date>

• Servidor: resposta não contém objeto se a cópia é atualizada:

HTTP/1.0 304 Not Modified

32

Cliente

Servidor

HTTP request msg

If-modified-since: <date>

Objeto

não

modificado

HTTP request msg

If-modified-since: <date>

HTTP response

HTTP/1.1 200 OK

<data>

Objeto

modificado

HTTP: GET condicional

2.1 Princípios de aplicações em rede de computadores

2.2 Web e HTTP

2.3 FTP

2.4 Correio eletrônico

- SMTP, POP3, IMAP

2.5 DNS

33

Camada de aplicação

∙ Transferência de arquivos de e para o computador remoto

∙ Modelo cliente/servidor

∙ Cliente: lado que inicia a transferência (seja de ou para o lado remoto)

∙ Servidor: hospedeiro remoto

∙ FTP: RFC 959

∙ FTP servidor: porta 21

34

FTP: o protocolo de transferência de arquivos

∙ Cliente FTP contata o servidor FTP na porta 21 especificando o TCP como protocolo de transporte

∙ Cliente obtém autorização pela conexão de controle

∙ Cliente procura o diretório remoto enviando comandos pela conexão de controle

∙ Quando o servidor recebe um comando para uma transferência de arquivo, ele abre uma conexão de dados TCP para o cliente

∙ Após a transferência de um arquivo, o servidor fecha a conexão

∙ Servidor abre uma segunda conexão de dados TCP para transferir outro arquivo

∙ Conexão de controle: “fora da banda” (out-of-band)

∙ Servidor FTP mantém “estado” sobre o usuário: diretório atual, autenticação anterior

​

​

35

FTP: controle separado das conexões de dados

Exemplos de comandos:

∙ Envie um texto ASCII sobre canal de controle

∙ USER username

∙ PASS password

∙ LIST retorna listagem do arquivo no diretório atual

∙ RETR filename recupera (obtém) o arquivo

∙ STOR filename armazena o arquivo no hospedeiro remoto

Exemplos de códigos de retorno

∙ Código de status e frase (como no HTTP)

∙ 331 Username OK, password required

∙ 125 data connection already open; transfer starting

∙ 425 Can’t open data connection

∙ 452 Error writing file

36

FTP comandos, respostas

2.1 Princípios de aplicações em rede de computadores

2.2 Web e HTTP

2.3 FTP

2.4 Correio eletrônico

- SMTP, POP3, IMAP

2.5 DNS

37

Camada de aplicação

Três componentes principais:

∙ Agentes de usuário

∙ Servidores de correio

∙ Simple mail transfer protocol: SMTP

Agente de usuário

∙“leitor de correio”

∙ Composição, edição, leitura de mensagens de correio

∙ Ex.: Eudora, Outlook, elm, Netscape Messenger, Thunderbird

∙ Mensagens de entrada e de saída são armazenadas no servidor

38

Correio eletrônico

Servidores de correio

∙ Caixa postal contém mensagens que chegaram (ainda não lidas) para o usuário

∙ Fila de mensagens contém as mensagens de correio a serem enviadas

Protocolo SMTP permite aos servidores de correio trocarem mensagens entre si

∙ Cliente: servidor de correio que envia

∙ “servidor”: servidor de correio que recebe

39

Correio eletrônico: servidores de correio

∙ Usa TCP para transferência confiável de mensagens de correio do cliente ao servidor, porta 25

∙ Transferência direta: servidor que envia para o servidor que recebe

• Três fases de transferência

∙ Handshaking (apresentação)‏

∙ Transferência de mensagens

∙ Fechamento

• Interação comando/resposta

∙ Comandos: texto ASCII

∙ Resposta: código de status e frase

∙ Mensagens devem ser formatadas em código ASCII de 7 bits

40

Correio eletrônico: SMTP [RFC 821]

1) Alice usa o agente de usuário (User Agent) para compor a mensagem “para” bob@someschool.edu

2) O agente de usuário dela envia a mensagem para o seu servidor de correio; a mensagem é colocada na fila de mensagens.

3) O lado cliente do SMTP abre uma conexão TCP com o servidor de correio do Bob.

4) O cliente SMTP envia a mensagem de Alice pela conexão TCP.

5) O servidor de correio de Bob coloca a mensagem na caixa de correio de Bob.

6) Bob invoca seu agente de usuário para ler a mensagem.

​

​

41

Cenário: Alice envia mensagem para Bob

42

S: 220 hamburger.edu

C: HELO crepes.fr

S: 250 Hello crepes.fr, pleased to meet you

C: MAIL FROM: <alice@crepes.fr>

S: 250 alice@crepes.fr... Sender ok

C: RCPT TO: <bob@hamburger.edu>

S: 250 bob@hamburger.edu ... Recipient ok

C: DATA

S: 354 Enter mail, end with "." on a line by itself

C: Do you like ketchup?

C: How about pickles?

C: .

S: 250 Message accepted for delivery

C: QUIT

S: 221 hamburger.edu closing connection

Exemplo de interação SMTP

∙ telnet nome do servidor 25

∙ Veja resposta 220 do servidor

∙ Envie comandos HELO, MAIL FROM, RCPT TO, DATA, QUIT

(a seqüência acima permite enviar um comando sem usar o agente de usuário do remetente)

43

Tente o SMTP você mesmo

∙ SMTP usa conexões persistentes

∙ SMTP exige que as mensagens (cabeçalho e corpo) estejam em ASCII de 7 bits

∙ Servidor SMTP usa CRLF.CRLF para indicar o final da mensagem

​

Comparação com HTTP:

∙ HTTP: pull

∙ E-mail: push

∙ Ambos usam comandos e respostas em ASCII, interação comando/resposta e códigos de status

∙ HTTP: cada objeto encapsulado na sua própria mensagem de resposta

∙ SMTP: múltiplos objetos são enviados numa mensagem multiparte

44

SMTP: palavras finais

SMTP: protocolo para trocar mensagens de e-mail

RFC 822: padrão para mensagens do tipo texto:

• linhas de cabeçalho, ex.:
• To:
• From:
• Subject:

diferente dos comandos HTTP

• corpo
• a “mensagem”, ASCII somente com caracteres

45

header

body

linha

em branco

Formato da mensagem de correio

∙ MIME: multimedia mail extension (RFC 2045 e 2056)‏

∙ Linhas adicionais no cabeçalho declaram o tipo de conteúdo MIME

46

Dados multimídia

tipo, subtipo,

declaração de parâmetro

Método usado

para codificar dados

Versão do MIME

Dados codificados

Formato das mensagens: extensões multimídia

∙ SMTP: entrega e armazena no servidor do destino

∙ Protocolo de acesso: recupera mensagens do servidor

∙ POP: Post Office Protocol [RFC 1939]

∙ Autorização (agente <-->servidor) e download

∙ IMAP: Internet Mail Access Protocol [RFC 1730]

∙ Maiores recursos (mais complexo)

∙ Manipulação de mensagens armazenadas no servidor

∙ HTTP: Hotmail , Yahoo! Mail, Gmail, etc.

47

Protocolos de acesso ao correio

Fase de autorização

• comandos do cliente:

∙ user: declara nome do usuário

∙ pass: password

respostas do servidor

∙ +OK

∙ -ERR

Fase de transação, cliente:

∙ list: lista mensagens e tamanhos

∙ retr: recupera mensagem pelo número

∙ dele: apaga

∙ quit

48

C: list

S: 1 498

S: 2 912

S: .

C: retr 1

S: <message 1 contents>

S: .

C: dele 1

C: retr 2

S: <message 1 contents>

S: .

C: dele 2

C: quit

S: +OK POP3 server signing off

S: +OK POP3 server ready

C: user alice

S: +OK

C: pass hungry

S: +OK user successfully

logged on

Protocolo POP3

Mais sobre POP3

∙ O exemplo anterior usa o modo download-and-delete

∙ Bob não pode reler o e-mail se ele trocar o cliente

∙ download-and-keep: cópias das mensagens em clientes diferentes

∙ POP3 é stateless através das sessões

IMAP

∙ Mantém todas as mensagens em um lugar: o servidor

∙ Permite que o usuário organize as mensagens em pastas

∙ IMAP mantém o estado do usuário através das sessões:

∙ Nomes das pastas e mapeamentos entre os IDs da mensagem e o nome da pasta

49

POP3 (continuação) e IMAP

2.1 Princípios de aplicações em rede de computadores

2.2 Web e HTTP

2.3 FTP

2.4 Correio eletrônico

- SMTP, POP3, IMAP

2.5 DNS

50

Camada de aplicação

Pessoas: muitos identificadores:

∙ RG, nome, passaporte, CPF

Internet hospedeiros, roteadores:

∙ Endereços IP (32 bits) - usados para endereçar datagramas

∙ “nome”, ex.: www.dsc.ufcg.edu.br - usados por humanos

P.: Como relacionar nomes com endereços IP?

Domain Name System:

∙ Base de dados distribuída implementada numa hierarquia de muitos servidores de nomes

∙ Protocolo de camada de aplicação hospedeiro, roteadores se comunicam com servidores de nomes para resolver nomes (tradução nome/endereço)‏

∙ Nota: função interna da Internet, implementada como protocolo da camada de aplicação

∙ Complexidade na “borda” da rede

51

DNS: Dominain Name System

DNS services

∙ Nome do hospedeiro para tradução de endereço IP

• Hospedeiro aliasing (apelido)‏

∙ Nomes canônicos e alias

mail server aliasing

distribuição de carga

∙ Servidores Web replicados: estabelece o endereço IP para um nome canônico

Por que não centralizar o DNS?

∙ Ponto único de falha

∙ Volume de tráfego

∙ Base centralizada de dados distante

∙ Manutenção

Não é escalável!

​

52

DNS

Cliente quer o IP para www.amazon.com; 1^a aprox.:

∙ Cliente consulta um servidor de raiz para encontrar o servidor DNS .com

∙ Cliente consulta o servidor DNS com para obter o servidor DNS amazon.com

∙ Cliente consulta o servidor DNS amazon.com para obter o endereço IP para www.amazon.com

53

Base de dados distribuída, hierárquica

∙ São contatados pelos servidores de nomes locais que não podem resolver um nome

∙ Buscam servidores de nomes autorizados se o mapeamento do nome não for conhecido

∙ Conseguem o mapeamento

∙ Retornam o mapeamento para o servidor de nomes local

54

Existem 13 servidores de nomes raiz no mundo

DNS: servidores de nomes raiz

Servidores Top-Level Domain (TLD): responsáveis pelos domínios com, org, net, edu etc e todos os domínios top-level nacionais uk, fr, ca, jp, br

∙ Network Solutions mantém servidores para o TLD “com”

∙ Educause para o TLD “edu”

Servidores DNS autorizados: servidores DNS de organizações, provêem nome de hospedeiro autorizado para mapeamentos IP para servidores de organizações (ex.: Web e mail).

∙ Podem ser mantidos por uma organização ou provedor de serviços

55

Servidores TLD e autoritários

∙ Não pertence estritamente a uma hierarquia

• Cada ISP (ISP residencial, companhia, universidade) possui um

∙ Também chamado de “servidor de nomes default”

• Quando um hospedeiro faz uma pergunta a um DNS, a pergunta é enviada para seu servidor DNS local

∙ Age como um procurador (proxy), encaminhando as perguntas para dentro da hierarquia

56

Servidor de nomes local

∙ O hospedeiro em cis.poly.edu quer o endereço IP para gaia.cs.umass.edu

57

Exemplo

58

Consulta recursiva:

• Transfere a tarefa de resolução do nome para o servidor de nomes consultado
• Carga pesada?

Consulta encadeada:

• Servidor contatado responde com o nome de outro servidor de nomes para contato
• “eu não sei isto, mas pergunte a este servidor”

​

​

Faça você mesmo: Windows>cmd

Comando ‘nslookup’

Consultas recursivas

Uma vez que um servidor de nomes aprende um mapeamento, ele armazena o mapeamento num registro do tipo cache

∙ Registro do cache tornam-se obsoletos (desaparecem) depois de um certo tempo

∙ Servidores TLD são tipicamente armazenados em cache nos servidores de nome locais

Mecanismos de atualização e notificação estão sendo projetados pelo IETF

∙ RFC 2136

∙ http://www.ietf.org/html.charters/dnsind-charter.html

59

DNS: armazenando e atualizando registros

DNS: base de dados distribuída que armazena registros de recursos (RR)

∙ Type = NS

∙ name é um domínio (ex.: foo.com)‏

∙ value é o endereço IP do servidor de nomes autorizados para este domínio

​

60

Registros do DNS

formato dos RR: <name, value, type, ttl>

∙ Type = A

∙ name é o nome do computador

∙ value é o endereço IP

​

∙ Type = CNAME

∙ name é um “apelido” para algum nome “canônico” (o nome real)‏

www.ibm.com é realmente

www.ibm.com.cs186.net

∙ value é o nome canônico

​

∙ Type = MX

∙ value é o nome do servidor de correio associado com name

Protocolo DNS: mensagem de consulta e resposta, ambas com o mesmo formato de mensagem

61

DNS: protocolo e mensagem

Cabeçalho da msg

∙ Identificação: número de 16 bits para consulta, resposta usa o mesmo número

​

∙ Flags

∙ Consulta ou resposta

∙ Recursão desejada

∙ Recursão disponível

∙ Resposta é autorizada

http://www.myiptest.com

DNS: protocolo e mensagens

62

DNS: protocolo e mensagem

Inserindo registros no DNS

∙ Exemplo: empresa recém-criada “Network Utopia”

• Registrar o nome networkuptopia.com num “registrar” (ex.: Network Solutions)

∙ É necessário fornecer ao registrar os nomes e endereços IP do seu servidor de nomes autorizados (primário e secundário)‏

∙ Registrar insere dois RRs no servidor TLD do domínio com:�

(networkutopia.com, dns1.networkutopia.com, NS)‏

(dns1.networkutopia.com, 212.212.212.1, A)�

∙ No servidor autorizado, inserir um registro Tipo A para www.networkuptopia.com e um registro Tipo MX para networkutopia.com

∙ Como as pessoas obtêm o endereço IP do seu Web site?

63

Camada de aplicação

∙ Arquiteturas de aplicação

∙ Cliente-servidor

∙ P2P

∙ Híbrida

∙ Exigências dos serviços de aplicação:

∙ Confiabilidade, banda passante, atraso

∙ Modelo do serviço de transporte da Internet

∙ Orientado à conexão, confiável: TCP

∙ Não confiável, datagramas: UDP

∙ Protocolos específicos:

∙ HTTP

∙ FTP

∙ SMTP, POP, IMAP

∙ DNS

64

Resumo

Características dos protocolos

​

∙ Típica troca de mensagens comando/resposta:

∙ Cliente solicita informação ou serviço

∙ Servidor responde com dados e código de status

∙ Formatos das mensagens:

∙ Cabeçalhos: campos que dão informações sobre os dados

∙ Dados: informação sendo comunicada

∙ Controle versus dados

∙ In-band, out-of-band

∙ Centralizado versus descentralizado

∙ Stateless vs. stateful

∙ Transferência de mensagens confiável vs. não confiável

∙ “complexidade na borda da rede”

65

Resumo