1. Capítulo 2: Camada de Aplicação Aplicações e protocolos da camada de aplicação
Metas do capítulo: Mais metas do capítulo Aplicação: processos distribuídos aplicação
transporte
Ì aspectos conceituais e de em comunicação
Ì protocolos específicos:
rede
enlace
implementação de r executem em hospedeiros física
r http
protocolos de aplicação no “espaço de usuário”
r ftp
em redes r trocam mensagens para
r smtp implementar aplicação
r paradigma cliente
servidor r pop r p.ex., correio, transf. de
r modelos de serviço r dns arquivo, WWW
Ì aprenda sobre protocolos Ì a programação de Protocolos da camada de apl.
aplicação
através do estudo de aplicações de rede r uma “parte” da aplicação aplicação
transporte
transporte
rede
protocolos populares do r define mensagens trocadas
rede enlace
r programação usando sockets enlace física
nível da aplicação por apls e ações tomadas
física
r usam serviços providos por
protocolos de camadas
inferiores
2: Camada de Aplicação 1 2: Camada de Aplicação 2
Aplicações de rede: algum jargão Paradigma cliente-servidor (C-S)
Apl. de rede típica tem duas aplicação
Ì Um processo é um Ì Um agente de usuário partes: cliente and servidor transporte
rede
programa que executa num (UA) é uma interface
enlace
hospedeiro. Cliente: física
entre o usuário e a Ì inicia contato com o servidor
pedido
Ì 2 processos no mesmo
hospedeiro se comunicam
aplicação de rede. (“fala primeiro”)
usando communicação entre r WWW: browser Ì tipicamente solicita serviço do
processos definida pelo r Correio: servidor
sistema operacional (SO). leitor/compositor de Ì para WWW, cliente resposta
Ì 2 processos em mensagens implementado no browser; para
aplicação
hospedeiros distintos se r streaming audio/video: correio no leitor de mensagens transporte
rede
comunicam usando um tocador de mídia Servidor: enlace
física
protocolo da camada de Ì provê ao cliente o serviço
apalicação. requisitado
Ì p.ex., servidor WWW envia
página solicitada; servidor de
2: Camada de Aplicação 2: Camada de Aplicação
3 correio entrega mensagens 4
De que serviço de transporte uma
Protocolos da camada de aplicação (cont).
aplicação precisa?
Perda de dados Largura de banda
API: interface de P: como um processo pode
Ì algumas apls (p.ex. áudio) Ì algumas apls (p.ex.,
programação de “identificar”o outro podem tolerar algumas multimídia) requerem
aplicações processo com o qual perdas quantia mínima de banda
Ì define interface entre quer se comunicar? Ì outras (p.ex., transf. de para serem “viáveis”
aplicação e camada de r endereço IP do arquivos, telnet) requerem Ì outras apls (“apls elásticas”)
hospedeiro do outro transferência 100% conseguem usar qq quantia
transporte
processo confiável de banda disponível
Ì socket (= tomada) : API r “número de porta” -
da Internet permite que o hospedeiro Temporização
r 2 processos se comunicam receptor determine a Ì algumas apls (p.ex.,
enviando dados para um qual processo deve ser telefonia Internet, jogos
socket ou lendo dados de entregue a mensagem interativos) requerem
um socket baixo retardo para serem
“viáveis”
… voltamos mais tarde a este assunto.
2: Camada de Aplicação 5 2: Camada de Aplicação 6
2. Serviços providos por protocolos de
Requisitos do serviço de transporte de apls comuns
transporte Internet
Sensibilidade
temporal serviço TCP: serviço UDP:
Aplicação Perdas Banda
Ì orientado a conexão: setup Ì transferência de dados não
transferência de arqs sem perdas elástica não requerido entre cliente, confiável entre processos
correio sem perdas elástica não servidor remetente e receptor
documentos WWW sem perdas elástica não Ì transporte confiável entre Ì não provê: setup da conexão,
áudio/vídeo de tolerante áudio: 5Kb-1Mb sim, 100’s mseg processos remetente e confiabilidade, controle de
tempo real vídeo:10Kb-5Mb receptor fluxo, controle de
áudio/vídeo gravado tolerante como anterior sim, alguns segs Ì controle de fluxo: remetente congestionamento, garantias
jogos interativos tolerante > alguns Kbps sim, 100’s mseg não vai “afogar” receptor temporais ou de banda
apls financeiras sem perdas elástica sim e não mínima
Ì controle de
congestionamento:
estrangular remetente quando P: Qual é o interesse em ter um
a rede carregada UDP?
Ì não provê: garantias
2: Camada de Aplicação 7
temporais ou de banda mínima 2: Camada de Aplicação 8
Apls Internet: seus protocolos e seus
protocolos de transporte
WWW: algum jargão
Protocolo da Protocolo de Ì Agent de usuário para
Ì Página WWW:
Aplicação camada de apl transporte usado WWW se chama de
r consiste de “objetos”
browser:
correio eletrônico smtp [RFC 821] TCP r endereçada por uma URL
accesso terminal remoto r MS Internet Explorer
Ì Quase todas as páginas
telnet [RFC 854] TCP
WWW http [RFC 2068] TCP r Netscape Communicator
WWW consistem de:
transferência de arquivos ftp [RFC 959] TCP Ì Servidor para WWW se
streaming multimídia r página base HTML, e
proprietário TCP ou UDP chama “servidor
(p.ex. RealNetworks) r vários objetos
servidor de arquivo remoto NSF TCP ou UDP referenciados.
WWW”:
telefonia Internet proprietário r Apache (domínio público)
tipicamente UDP Ì URL tem duas partes:
(p.ex., Vocaltec) r MS Internet Information
nome de hospedeiro, e Server (IIS)
nome de caminho:
www.univ.br/algum-depto/pic.gif
2: Camada de Aplicação 9 2: Camada de Aplicação 10
WWW: o protocolo http Mais sobre o protocolo http
http: hypertext transfer http: serviço de http é “sem estado”
protocol ped
ido
transporte TCP: Ì servidor não mantém
Ì protocolo da camada de PC executa
htt
p Ì cliente inicia conexão TCP informação sobre
res
aplicação para WWW Explorer
pos
ta (cria socket) ao servidor, pedidos anteriores do
htt
p porta 80 cliente
Ì modelo cliente/servidor
Ì servidor aceita conexão TCP
Nota
r cliente: browser que Protocolos que mantêm
p
pede, recebe, “visualiza” htt
o do cliente “estado” são complexos!
did Servidor
pe ttp
objetos WWW ah executando Ì mensagens http (mensagens Ì história passada (estado)
ost
sp servidor do protocolo da camada de
r servidor: servidor re tem que ser guardada
WWW
WWW envia objetos em do NCSA
apl) trocadas entre browser Ì Caso caia servidor/cliente,
resposta a pedidos (cliente http) e servidore suas visões do “estado”
Mac executa WWW (servidor http)
Ì http1.0: RFC 1945 Navigator podem ser inconsistentes,
Ì encerra conexão TCP devem ser reconciliadas
Ì http1.1: RFC 2068
2: Camada de Aplicação 11 2: Camada de Aplicação 12
3. Exemplo de http Exemplo de http (cont.)
Supomos que usuário digita a URL (contém texto, 4. servidor http encerra conexão
www.algumaUniv.br/algumDepartmento/inicial.index referências a 10 TCP .
5. cliente http recebe mensagem
imagens jpeg)
de resposta contendo arquivo
1a. Cliente http inicia conexão html, visualiza html.
TCP a servidor http (processo) Analisando arquivo html,
1b. servidor http no hospedeiro
a www.algumaUniv.br. Porta 80 encontra 10 objetos jpeg
é padrão para servidor http. www.algumaUniv.br espera por
conexão TCP na porta 80. referenciados
“aceita” conexão, avisando ao
cliente 6. Passos 1 a 5 repetidos para
2. cliente http envia mensagem cada um dos 10 objetos jpeg
de pedido de http (contendo
URL) através do socket da 3. servidor http recebe mensagem tempo
conexão TCP de pedido, formula mensagem
de resposta contendo objeto
solicitado
(algumDepartmento/inicial.index),
envia mensagem via socket
tempo
2: Camada de Aplicação 13 2: Camada de Aplicação 14
Conexões não persistente and persistente
formato de mensagem http: pedido
Não persistente Persistente
Ì HTTP/1.0 Ì default for HTTP/1.1
Ì Dois tipos de mensagem http: pedido, resposta
Ì servidor analisa Ì na mesma conexão TCP:
Ì mensagem de pedido http:
pedido, responde, and servidor analisa pedido,
r ASCII (formato legível por pessoas)
encerra conexão TCP responde, analisa novo
Ì 2 RTTs para trazer pedido,.. linha do pedido
cada objeto Ì Cliente envia pedidos (comandos GET, GET /somedir/page.html HTTP/1.0
(RTT=round trip time) para todos objetos POST, HEAD) User-agent: Mozilla/4.0
Ì transferência de cada referenciados assim Accept: text/html, image/gif,image/jpeg
linhas do Accept-language:fr
objeto sofre de que recebe o HTML cabeçalho
partida lenta base .
Carriage return, (carriage return (CR), line feed(LF) adicionais)
A maioria de browsers 1.0 Ì Menos RTTs and menos line feed
usa connexões TCP paralelas. partida lenta. indicate fim
de mensagem
2: Camada de Aplicação 15 2: Camada de Aplicação 16
mensagem de pedido http: formato geral formato de mensagem http: resposta
linha de status
(protocolo,
código de status, HTTP/1.0 200 OK
frase de status) Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
linhas de
Content-Length: 6821
cabeçalho
Content-Type: text/html
dados dados dados dados ...
dados, p.ex.,
arquivo html
solicitado
2: Camada de Aplicação 17 2: Camada de Aplicação 18
4. códigos de status da resposta http Experimente você com http (do lado cliente)
Na primeira linha da mensagem de resposta
servidor->cliente. Alguns códigos típicos: 1. Use cliente telnet para seu servidor WWW favorito:
200 OK telnet www.ic.uff.br 80 Abre conexão TCP para a porta 80
r sucesso, objeto pedido segue mais adiante nesta mensagem (porta padrão do servidor http) a www.ic.uff.br.
Qualquer coisa digitada é enviada para a
301 Moved Permanently porta 80 do www.ic.uff.br
r objeto pedido mudou de lugar, nova localização
especificado mais adiante nesta mensagem (Location:) 2. Digite um pedido GET http:
400 Bad Request Digitando isto (deve teclar
GET /~michael/index.html HTTP/1.0
r mensagem de pedido não entendida pelo servidor ENTER duas vezes), está enviando
este pedido GET mínimo (porém
404 Not Found completo) ao servidor http
r documento pedido não se encontra neste servidor
505 HTTP Version Not Supported 3. Examine a mensagem de resposta enviado pelo
r versão de http do pedido não usada por este servidor servidor http !
2: Camada de Aplicação 19 2: Camada de Aplicação 20
HTML (HyperText Markup Language) Encadeamento de referências
Ì HTML: uma linguagem simples para hipertexto Ì Referências <A HREF=LinkRef> ... </A>
r começou como versão simples de SGML r a componentes do documento local
r construção básica: cadéias de texto anotadas <A HREF=“importante”> clique para uma dica </A>
r a documentos no servidor local
Ì Construtores de formato operam sobre cadéias
<A HREF=“../index.htm”> voltar ao sumário </A>
r <b> .. </b> bold (negrito)
r a documentos em outros servidores
r <H1 ALIGN=CENTER> ..título centrado .. </H1> <A HREF=“http://www.uff.br”> saiba sobre a UFF </A>
r <BODY bgcolor=white text=black link=red ..> .. </BODY>
Ì Multimídia
Ì vários formatos r imagem embutida: <IMG SRC=“eclipse”>
r listas de bullets, listas ordenadas, listas de definição r imagem externa: <A HREF=“eclipse.gif”> imagem maior </A>
r tabelas r vídeo Mpeg <A HREF=“ByeByeBrasil.mpg”> um bom filme </A>
r frames r som <A HREF=“http://www.sons.br/aniv.au”> feliz niver </A>
2: Camada de Aplicação 21 2: Camada de Aplicação 22
Formulários e interação bidirecional Interação usuário-servidor: autenticação
Meta da autenticação: controle de
Ì Formulários transmitem Ì Formulários processados usando
acesso aos documentos do cliente servidor
servidor
informação do cliente ao scripts CGI (programas que msg de pedido http comum
servidor executam no servidor WWW) Ì sem estado: cliente deve
apresentar autorização com 401: authorization req.
Ì HTTP permite enviar r CGI - Common Gateway WWW authenticate:
cada pedido
formulários ao servidor Interface
Ì autorização: tipicamente nome,
Ì Resposta enviada como r scripts CGI escondem
senha msg de pedido http comum
página HTML dinâmica acesso a diferentes serviços + Authorization:line
r authorization: linha de
r servidor WWW atua como
cabeçalho no pedido msg de resposta http comum
gateway universal
r se não for apresentada
autorização, servidor nega
GET/POST accesso, e coloca no msg de pedido http comum
formulário cabeçalho da resposta + Authorization:line
cliente servidor Sistema de tempo
WWW WWW informação WWW authenticate: msg de resposta http comum
resposta: Browser guarda nome e senha para
HTML 2: Camada de Aplicação 23 evitar que sejam pedidos ao usuário a cada acesso. 2: Camada de Aplicação 24
5. Interação usuário-servidor: cookies Interação usuário-servidor: GET condicional
cliente servidor cliente servidor
msg de pedido http comum
Ì servidor envia “cookie” ao msg de pedido http
Ì Meta: não enviar objeto se
cliente na msg de resposta resposta http comum+ If-modified-since: objeto
cliente já tem (no cache)
Set-cookie: # <date>
não
Set-cookie: 1678453 versão atual
Ì cliente apresenta cookie
resposta http modificado
Ì cliente: especifica data da HTTP/1.0
nos pedidos posteriores msg de pedido http comum
Ação cópia no cache no pedido 304 Not Modified
cookie: #
cookie: 1678453 específica http
Ì servidor casa cookie- msg de resposta http comum do cookie If-modified-since:
apresentado com a info <date> msg de pedido http
guardada no servidor Ì servidor: resposta não If-modified-since:
objeto
r autenticação msg de pedido http comum contém objeto se cópia no
<date>
Ação modificado
cookie: # cache é atual: resposta http
r lembrando preferências específica HTTP/1.1 200 OK
do usuário, opções msg de resposta http comum do cookie HTTP/1.0 304 Not …
anteriores Modified
<data>
2: Camada de Aplicação 25 2: Camada de Aplicação 26
Cache WWW (servidor-procurador) Por quê usar cache WWW? Servidores
de origem
Meta: atender pedido do cliente sem envolver servidor de origem
Suposição: cache está
Ì usuário configura Servidor “próximo” do cliente Internet
pública
browser: acessos WWW de origem (p.ex., na mesma rede)
cliente
via procurador Servidor-
ped Ì tempo de resposta
Ì cliente envia todos ido procurador ttp
pedidos http ao res htt
p
oh
did ttp
menor: cache “mais enlace de accesso
pos pe ah
procurador ta
htt sp
ost próximo” do cliente 2 Mbps
p re
r se objeto no cache do ttp ped Ì diminui tráfego aos rede da
procurador, este o oh tp ido instituição
did ht htt servidores distantes LAN 10 Mbps
pe res
devolve imediatamente o sta pos p
sp ta h
na resposta http re ttp r muitas vezes é um
r senão, solicita objeto do gargalo o enlace que liga
cliente a rede da instituição ou cache da
servidor de origem, Servidor
depois devolve resposta de origem do provedor à Internet instituição
http ao cliente
2: Camada de Aplicação 27 2: Camada de Aplicação 28
ftp: o protocolo de transferência
ftp: conexões separadas p/ controle, dados
de arquivos
transferência Ì cliente ftp contata servidor
Interface cliente do arquivo ftp na porta 21,
FTP
do usuário FTP
FTP
servidor especificando TCP como
conexão de controle
usuário protocolo de transporte TCP, porta 21
sistema de sistema de
na Ì são abertas duas conexões
estação arquivos arquivos
local remoto TCP paralelas:
conexão de dados
r controle: troca comandos, cliente TCP, porta 20 servidor
Ì transferir arquivo de/para hospedeiro remoto
respostas entre cliente, FTP FTP
Ì modelo cliente/servidor servidor.
rcliente: lado que inicia transferência (pode ser de ou “controle fora da banda”
para o sistema remoto)
r dados: dados de arquivo
r servidor: hospedeiro remoto de/para servidor
Ì ftp: RFC 959 Ì servidor ftp mantém
Ì servidor ftp: porta 21 “estado”: directório corrente,
autenticação realizada
2: Camada de Aplicação 29 2: Camada de Aplicação 30
6. fila de
Ftp: comandos, respostas Correio Eletrônico mensagens
de saída
caixa de
agente correio do usuário
Comandos típicos: Códigos de retorno típicos Três grandes componentes: de
usuário
Ì enviados em texto ASCII pelo Ì código e frase de status (como Ì agentes de usuário (UA) servidor agente
de
canal de controle para http) Ì servidores de correio de correio
usuário
Ì USER nome Ì 331 Username OK, password Ì simple mail transfer protocol: SMTP
servidor
Ì PASS senha required smtp de correio agente
Ì LIST devolve lista de arquivos
Ì 125 data connection
SMTP de
already open; transfer Agente de Usuário usuário
no directório corrente
Ì RETR arquivo recupera (lê)
starting Ì a.k.a. “leitor de correio” SMTP
agente
arquivo remoto
Ì 425 Can’t open data Ì compor, editar, ler mensagens servidor de
connection de correio de correio usuário
Ì STOR arquivo armazena
(escreve) arquivo no hospedeiro
Ì 452 Error writing file Ì p.ex., Eudora, Outlook, elm,
agente
remoto Netscape Messenger de
Ì mensagens de saída e chegando agente
usuário
são armazenadas no servidor de
usuário
2: Camada de Aplicação 31 2: Camada de Aplicação 32
Correio Eletrônico: servidores de correio Correio Eletrônico: smtp [RFC 821]
agente
Servidores de correio de
usuário
Ì usa tcp para a transferência confiável de msgs do correio
Ì caixa de correio contém agente
do cliente ao servidor, porta 25
servidor
mensagens de chegada de correio de Ì transferência direta: servidor remetente ao servidor
usuário
(ainda não lidas) p/ usuário receptor
SMTP
Ì fila de mensagens contém servidor Ì três fases da transferência
de correio
mensagens de saída (a serem r handshaking (cumprimento)
enviadas)
SMTP
r transferência das mensagens
Ì protocolo smtp entre SMTP r encerramento
servidores de correio para agente
servidor de Ì interação comando/resposta
transferir mensagens de de correio usuário
r comandos: texto ASCII
correio
r resposta: código e frase de status
r cliente: servidor de agente
correio que envia de
usuário
Ì mensagens precisam ser em ASCII de 7-bits
agente
r “servidor”: servidor de de
correio que recebe usuário
2: Camada de Aplicação 33 2: Camada de Aplicação 34
Interaction smtp típica Experimente você uma interação smtp :
S: 220 doces.br
C: HELO consumidor.br Ì telnet nomedoservidor 25
S: 250 Hello consumidor.br, pleased to meet you
C: MAIL FROM: <ana@consumidor.br> Ì veja resposta 220 do servidor
S: 250 ana@consumidor.br... Sender ok Ì entre comandos HELO, MAIL FROM, RCPT TO,
C: RCPT TO: <bernardo@doces.br> DATA, QUIT
S: 250 bernardo@doces.br ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself estes comandos permite que você envie correio sem
C: Voce gosta de chocolate?
usar um cliente (leitor de correio)
C: Que tal sorvete?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 doces.br closing connection
2: Camada de Aplicação 35 2: Camada de Aplicação 36
7. smtp: últimas palavras Formato de uma mensagem
Ì smtp usa conexões Comparação com http smtp: protocolo para trocar
persistentes msgs de correio cabeçalho
Ì http: pull (puxar) linha em
Ì smtp requerque a mensagem RFC 822: padrão para formato
Ì email: push (empurrar) branco
(cabeçalho e corpo) sejam em de mensagem de texto:
ascii de 7-bits Ì ambos tem interação Ì linhas de cabeçalho, p.ex.,
Ì algumas cadeias de caracteres comando/resposta, códigos To:
r
corpo
não são permitidas numa de status em ASCII r From:
mensagem (p.ex., CRLF.CRLF). r Subject:
Logo a mensagem pode ter que Ì http: cada object é
diferentes dos comandos de
ser codificada (normalmente encapsulado em sua própria smtp!
em base-64 ou “quoted mensagem de resposta
Ì corpo
printable”) Ì smtp: múltiplos objetos de
r a “mensagem”, somente de
Ì servidor smtp usa CRLF.CRLF mensagem enviados numa caracteres ASCII
para reconhecer o final da mensagem de múltiplas
mensagem partes
2: Camada de Aplicação 37 2: Camada de Aplicação 38
Formato de uma mensagem: extensões para Tipos MIME
multimídia Content-Type: tipo/subtipo; parâmetros
Ì MIME: multimedia mail extension, RFC 2045, 2056
Ì linhas adicionais no cabeçalho da msg declaram tipo do Text Audio
conteúdo MIME Ì subtipos exemplos: plain, Ì subtipos exemplos : basic
html (8-bit codificado mu-law),
Ì charset=“iso-8859-1”, 32kadpcm (codificação 32
From: ana@consumidor.br
versão MIME ascii kbps)
To: bernardo@doces.br
Subject: Imagem de uma bela torta Application
método usado
p/ codificar dados
MIME-Version: 1.0 Image Ì outros dados que precisam
Content-Transfer-Encoding: base64
Ì subtipos exemplos : jpeg, ser processados por um
Content-Type: image/jpeg
tipo, subtipo de gif leitor para serem
dados multimídia, base64 encoded data ..... “visualizados”
declaração parâmetros Ì subtipos exemplos :
.........................
......base64 encoded data
Video
msword, octet-stream
Dados codificados Ì subtipos exemplos : mpeg,
quicktime
2: Camada de Aplicação 39 2: Camada de Aplicação 40
Tipo Multipart
From: ana@consumidor.br
To: bernardo@doces.br
Protocolos de accesso ao correio
Subject: Imagem de uma bela torta
MIME-Version: 1.0 agente SMTP SMTP POP3 ou agente
Content-Type: multipart/mixed; boundary=98766789 de de
usuário IMAP usuário
--98766789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain servidor de correio servidor de correio
do remetente do receptor
caro Bernardo, Ì SMTP: entrega/armazenamento no servidor do receptor
Anexa a imagem de uma torta deliciosa.
--98766789 Ì protocolo de accesso ao correio: recupera do servidor
Content-Transfer-Encoding: base64 r POP: Post Office Protocol [RFC 1939]
Content-Type: image/jpeg
• autorização (agente <-->servidor) e transferência
base64 encoded data ..... r IMAP: Internet Mail Access Protocol [RFC 1730]
.........................
......base64 encoded data • mais comandos (mais complexo)
--98766789-- • manuseio de msgs armazenadas no servidor
r HTTP: Hotmail , Yahoo! Mail, Webmail, etc.
2: Camada de Aplicação 41 2: Camada de Aplicação 42
8. Protocolo POP3 S: +OK POP3 server ready
DNS: Domain Name System
C: user ana
fase de autorização S: +OK
C: pass faminta Pessoas: muitos Domain Name System:
Ì comandos do cliente: S: +OK user successfully logged on identificadores: Ì base de dados distribuída
r user: declara nome implementada na hierarquia de
C: list r CPF, nome, no. de
r pass: senha muitos servidores de nomes
S: 1 498 Passaporte
Ì servidor responde S: 2 912 Ì protocolo de camada de aplicação
hospedeiros, roteadores
r +OK
S: .
permite hospedeiros, roteadores,
C: retr 1 Internet : servidores de nomes
r -ERR S: <message 1 contents>
r endereço IP (32 bit) - communicarem para resolver
fase de transação, cliente: S: .
usado p/ endereçar nomes (tradução endereço/nome)
C: dele 1
Ì list: lista números das C: retr 2 datagramas r note: função imprescindível da
msgs S: <message 1 contents> r “nome”, e.g., Internet implementada como
Ì retr: recupera msg por S: . jambo.ic.uff.br - usado protocolo de camada de
número C: dele 2 por gente aplicação
C: quit
Ì dele: apaga msg S: +OK POP3 server signing off P: como mapear entre r complexidade na borda da rede
Ì quit
2: Camada de Aplicação 43
nome e endereço IP? 2: Camada de Aplicação 44
Servidores de nomes DNS DNS: Servidores raíz
Por quê não centralizar o Ì Nenhum servidor mantém Ì procurado por servidor
DNS? todos os mapeamento nome- local que não consegue
Ì ponto único de falha para-endereço IP resolver o nome
servidor de nomes local: Ì servidor raíz:
Ì volume de tráfego
r procura servidor
r cada provedor, empresa tem
Ì base de dados autoritativo se
servidor de nomes local (default)
centralizada e distante r pedido DNS de hospedeiro vai
mapeamento
desconhecido
Ì manutenção (da BD) primeiro ao servidor de nomes
r obtém tradução
local
r devolve
servidor de nomes autoritativo:
Não é escalável! mapeamento ao
r p/ hospedeiro: guarda nome, servidor local
endereço IP dele Ì ~ uma dúzia de
r pode realizar tradução servidores raíz no
nome/endereço para este nome mundo
2: Camada de Aplicação 45 2: Camada de Aplicação 46
Exemplo simples do DNS Exemplo de DNS
servidor de servidor de
nomes raíz nomes raíz
hospedeiro Servidor raíz: 2 6
manga.ic.uff.br requer
2 4 Ì pode não conhecer o 7 3
3
endereço IP de
5 servidor de nomes
www.cs.columbia.edu autoritativo
1. Contata servidor DNS local, Ì pode conhecer
pitomba.ic.uff.br servidor de nomes servidor local servidor intermediário
servidor local servidor autoritativo intermediário: a quem pitomba.ic.uff.br saell.cc.columbia.edu
2. pitomba.ic.uff.br pitomba.ic.uff.br cs.columbia.edu
contata servidor raíz, se contactar para 4 5
1 8
necessário 1 6 descobrir o servidor
de nomes autoritativo
3. Servidor raíz contata servidor autoritativo
servidor autoritativo cs.columbia.edu
cs.columbia.edu, se solicitante
solicitante www.cs.columbia.edu manga.ic.uff.br
necessário manga.ic.uff.br
www.cs.columbia.edu
2: Camada de Aplicação 47 2: Camada de Aplicação 48
9. DNS: consultas iteratadas servidor de DNS: uso de cache, atualização de dados
nomes raíz
consulta recursiva: 2 consulta Ì uma vez um servidor qualquer aprende um
Ì transfere a 3 iterrada mapeamento, ele o coloca numa cache local
responsabilidade de 4 r futuras consultas são resolvidas usando dados
reolução do nome para
o servidor de nomes 7 da cache
cntatado servidor intermediário r entradas no cache são sujeitas a temporização
servidor local
Ì carga pesada? pitomba.ic.uff.br saell.cc.columbia.edu (desaparecem depois de certo tempo)
5 6 ttl = time to live (sobrevida)
consulta iterada: 1 8
Ì servidor consultado Ì estão sendo projetados pela IETF mecanismos
responde com o nome servidor autoritativo de atualização/notificação dos dados
cs.columbia.edu
de um servidor de solicitante r RFC 2136
contato manga.ic.uff.br r http://www.ietf.org/html.charters/dnsind-charter.html
Ì “Não conheço este
www.cs.columbia.edu
nome, mas pergunte
para esse servidor” 2: Camada de Aplicação 49 2: Camada de Aplicação 50
Registros DNS DNS: protocolo, mensagens
DNS: BD distribuída contendo resource records (RR) protocolo DNS: mensagens pedido e resposta, ambas
com o mesmo formato de mensagem
formato RR: (nome, valor, tipo, sobrevida)
cabeçalho de msg
Ì Tipo=A Ì Tipo=CNAME Ì identification: ID de 16 bit
r nome é nome de hospedeiro r nome é nome alternativo para pedido, resposta ao
r valor é endereço IP (alias) para algum nome pedido usa mesmo ID
“canônico” (verdadeiro) Ì flags:
Ì Tipo=NS r valor é o nome r pedido ou resposta
r nome é domínio (p.ex. canônico
r recursão desejada
foo.com.br)
Ì Tipo=MX r recursão permitida
r valor é endereço IP de
servidor de nomes r nome é domínio r resposta é autoritativa
autoritativo para este r valor é nome do servidor de
domínio correio para este domínio
2: Camada de Aplicação 51 2: Camada de Aplicação 52
DNS: protocolo, mensagens Programação com sockets
Meta: aprender construir aplicação cliente/servidor que
campos nome, tipo
comunica usando sockets
num pedido socket
API Sockets uma interface (uma
RRs em resposta Ì apareceu em BSD4.1 UNIX, “porta”), local ao
ao pedido 1981 hospedeiro, criada por e
Ì explicitamente criados, pertencente à aplicação, e
registros para usados e liberados por apls controlado pelo SO,
servidores autoritativos Ì paradigma cliente/servidor através da qual um
processo de aplicação
info adicional Ì dois tipos de serviço de
pode tanto enviar como
“relevante” que transporte via API Sockets
receber mensagens
pode ser usada r datagrama não confiável
para/de outro processo
r fluxo de bytes, confiável de aplicação
(remoto ou local)
2: Camada de Aplicação 53 2: Camada de Aplicação 54
10. Programação com sockets usando TCP Programação com sockets usando TCP
Socket: uma porta entre o processo de aplicação e um Cliente deve contactar servidor Ì Quando cliente cria socket: TCP
Ì processo servidor deve antes do cliente estabelece conexão
protocolo de transporte fim-a-fim (UDP ou TCP)
estar em execução ao servidor TCP
Serviço TCP: transferência confiável de bytes de um Ì servidor deve antes ter Ì Quando contactado pelo cliente,
processo para outro criado socket (porta) que servidor TCP cria socket novo
aguarda contato do cliente processo servidor poder se
comunicar com o cliente
controlado pelo Cliente contacta servidor por:
controlado pelo processo programador de r permite que o servidor
programador de processo Ì criar socket TCP local ao
aplicação converse com múltiplos
aplicação socket socket cliente
clientes
TCP com TCP com controlado Ì especificar endereço IP,
controlado
buffers, pelo sistema ponto de vista da aplicação
pelo sistema buffers, internet operacional número de porta do processo
operacional variáveis variáveis TCP provê transferência
servidor
confiável, ordenada de bytes
estação ou estação ou (“tubo”) entre cliente e servidor
servidor servidor
2: Camada de Aplicação 55 2: Camada de Aplicação 56
Programação com sockets usando TCP Interações cliente/servidor com socket: TCP
Servidor (executa em idHosp) Cliente
Exemplo de apl cliente-servidor: Input stream: sequence of
Ì cliente lê linha da entrada bytes into process cria socket,
porta=x, para
padrão (fluxo doUsuário), Output stream: sequence of receber pedido:
socketRecepção =
envia para servidor via socket bytes out of process ServerSocket ()
(fluxo paraServidor)
TCP cria socket,
Ì servidor lê linha do socket aguarda chegada de
setup da conexão abre conexão a idHosp, porta=x
pedido de conexão socketCliente =
Ì servidor converte linha para socketConexão =
Socket()
socketRecepção.accept()
letra maiúscula, devolcve para
o cliente Envia pedido usando
lê pedido de socketCliente
Ì cliente lê linha modificado do doUsuário socketConexão
d
socket (fluxo doServidor),
p
escreve resposta
imprime-a para socketConexão lê resposta de
socket do cliente fecha
socketCliente
socketConexão fecha
socketCliente
o
p
2: Camada de Aplicação 57 2: Camada de Aplicação 58
a
S
r
e
Exemplo: cliente Java (TCP) Exemplo: cliente Java (TCP), cont.
a
r
import java.io.*;
import java.net.*; Cria BufferedReader doServidor =
class ClienteTCP { fluxo de entrada new BufferedReader(new
ligado ao socket InputStreamReader(socketCliente.getInputStream()));
S
public static void main(String argv[]) throws Exception
{
v
frase = doUsuario.readLine();
String frase;
Envia linha
String fraseModificada; paraServidor.writeBytes(frase + 'n');
ao servidor
Cria
e
fluxo de entrada BufferedReader doUsuario =
Lê linha fraseModificada = doServidor.readLine();
new BufferedReader(new InputStreamReader(System.in));
do servidor
Cria
i
System.out.println(”Do Servidor: " + fraseModificada);
socket de cliente, Socket socketCliente = new Socket(”idHosp", 6789);
conexão ao servidor
socketCliente.close();
r
Create DataOutputStream paraServidor =
output stream new DataOutputStream(socketCliente.getOutputStream()); }
attached to socket
d
}
2: Camada de Aplicação 59 2: Camada de Aplicação 60
v
o
i
r
d
11. Exemplo: servidor Java (TCP) Exemplo: servidor Java (TCP), cont
import java.io.*;
import java.net.*;
Cria fluxo
class servidorTCP { de saída, ligado DataOutputStream paraCliente =
ao socket new DataOutputStream(socketConexão.getOutputStream());
public static void main(String argv[]) throws Exception
{ Lê linha
String fraseCliente;
do socket fraseCliente= doCliente.readLine();
Cria socket StringfFraseMaiusculas;
para recepção fraseEmMaiusculas= fraseCliente.toUpperCase() + 'n';
ServerSocket socketRecepcao = new ServerSocket(6789);
na porta 6789 Escreve linha
paraClient.writeBytes(fraseEmMaiusculas);
Aguarda, no socket while(true) { ao socket
}
para recepção, o Socket socketConexao = socketRecepcao.accept(); }
contato do cliente } Final do elo while,
BufferedReader doCliente = volta ao início e aguarda
Cria fluxo de new BufferedReader(new conexão de outro cliente
entrada, ligado InputStreamReader(socketConexao.getInputStream()));
ao socket
2: Camada de Aplicação 61 2: Camada de Aplicação 62
Programação com sockets usando UDP Interações cliente/servidor com socket: UDP
Servidor (executa em idHosp) Cliente
UDP: não tem “conexão” entre
cliente e servidor cria socket, cria socket,
Ì não tem “handshaking” porta=x, para socketCliente =
pedido que chega: DatagramSocket()
Ì remetente coloca ponto de vista da aplicação socketServidor =
explicitamente endereço IP UDP provê transferência
DatagramSocket()
e porta do destino
cria, endereça (idHosp, porta=x,
não confiável de grupos envia pedido em datagrama
Ì servidor deve extrair de bytes (“datagramas”) lê pedido do usando socketCliente
endereço IP, porta do entre cliente e servidor socketServidor
remetente do datagrama
escreve resposa
recebido ao socketServidor
lê resposa do
especificando endereço
UDP: dados transmitidos IP, número de porta socketCliente
podem ser recebidos fora do cliente fecha
de ordem, ou perdidos socketCliente
2: Camada de Aplicação 63 2: Camada de Aplicação 64
Exemplo: cliente Java (UDP) Exemplo: cliente Java (UDP) cont.
Cria datagrama com
import java.io.*; dados para enviar, DatagramPacket pacoteEnviado =
import java.net.*; comprimento, new DatagramPacket(dadosEnvio, dadosEnvio.length,
endereço IP, porta IPAddress, 9876);
class clienteUDP {
public static void main(String args[]) throws Exception Envia datagrama socketCliente.send(pacoteEnviado);
Cria
{ ao servidor
DatagramPacket pacoteRecebido =
fluxo de enrada BufferedReader do Usuario= new DatagramPacket(dadosRecebidos, dadosRecebidos.length);
Cria new BufferedReader(new InputStreamReader(System.in)); Lê datagrama
socket de cliente do servidor socketCliente.receive(pacoteRecebido);
DatagramSocket socketCliente = new DatagramSocket();
Traduz nome de String fraseModificada =
InetAddress IPAddress = InetAddress.getByName(”idHosp");
hospedeiro ao new String(pacoteRecebido.getData());
endereço IP byte[] dadosEnvio = new byte[1024]; System.out.println(”Do Servidor:" + fraseModificada);
usando DNS byte[] dadosRecebidos = new byte[1024]; socketCliente.close();
}
String frase = doUsuario.readLine();
}
dadosEnvio = frase.getBytes();
2: Camada de Aplicação 65 2: Camada de Aplicação 66