Camada de Aplicação
Teleprocessamento e Redes
Instituto de Informática – UFG
Prof. Fábio M. Costa
(slides baseados em [Kurose&Ross2003])
Parte 2: Camada de Aplicação
Nossos objetivos:
 conceitual, aspectos de
implementação de
protocolos de aplicação para
redes
 paradigma clienteservidor
 modelos de serviço
 aprenda sobre protocolos
examinando algumas
aplicações populares
Outros objetivos do capítulo
 protocolos específicos:





http
ftp
smtp
pop
dns
 programação de aplicações
de rede

socket API
Cap. 2: Camada de Aplicação
2
Aplicações e Protocolo de Aplicação
Aplicação: processos distribuídos que
comunicam entre si
 rodam nos computadores (hosts)
da rede como programas de
usuário
 trocam mensagens entre si para
realização da aplicação
 e.x., email, ftp, Web
aplicação
transporte
rede
enlace
física
Protocolos de aplicação



fazem parte das aplicações
definem mensagens trocadas e
as ações tomadas
usam serviços de comunicação
das camadas inferiores
aplicação
transporte
rede
enlace
física
aplicação
transporte
rede
enlace
física
Cap. 2: Camada de Aplicação
3
Aplicações de Rede
Processo: programa
executando num host.
 dentro do mesmo host:
interprocess
communication (definido
pelo SO).
 processos executando em
diferentes hosts se
comunicam com um
protocolo da camada de
aplicação
 agente usuário: software
que interfaceia com o
usuário de um lado e com
a rede de outro.
 implementa protocolo
da camada de aplicação
 Web: browser
 E-mail: leitor de
correio
 streaming áudio/vídeo:
media player
Cap. 2: Camada de Aplicação
4
Paradigma Cliente-Servidor
Aplicações de rede típicas têm duas
partes: cliente and servidor
Cliente:
aplicação
transporte
rede
enlace
física
 inicia comunicação com o servidor
(“fala primeiro”)
 tipicamente solicita serviços do
servidor,
 Web: cliente implementado no
browser; e-mail: leitor de correio
Servidor:
 fornece os serviços solicitados pelo cliente
pedido
resposta
aplicação
transporte
rede
enlace
física
 e.x., Web server envia a página Web
solicitada, servidor de e-mail envia as
mensagens, etc.
Cap. 2: Camada de Aplicação
5
Interfaces de Programação
API: application
programming interface
 define a interface entre
a camada de aplicação e
de transporte
 socket: Internet API
 dois processos se
comunicam enviando
dados para o socket e
lendo dados de dentro do
socket
Q: Como um processo
“identifica” o outro
processo com o qual ele
quer se comunicar?


IP address do computador
no qual o processo remoto
executa
“port number” - permite ao
computador receptor
determinar o processo local
para o qual a mensagem
deve ser entregue.
Cap. 2: Camada de Aplicação
6
Serviços de Transporte
Perda de dados
 algumas aplicações (e.x.,
aúdio) podem tolerar alguma
perda
 outras aplicações (e.x.,
transferência de arquivos,
telnet) exigem transferência
de dados 100% confiável
Temporização
 algumas aplicações (e.x.,
telefonia Internet, jogos
interativos) exigem baixos
atrasos para operarem
Banda Passante
 algumas aplicações (e.x.,
multimedia) exigem uma
banda mínima para serem
utilizáveis
 outras aplicações
(“aplicações elásticas”)
melhoram quando a banda
disponível aumenta
Cap. 2: Camada de Aplicação
7
Requisitos de Transporte de Aplicações Comuns
Applicação
transf. de arquivos
e-mail
documentos Web
áudio/vídeo tempo real
áudio/vídeo armazenado
jogos interativos
comércio eletrônico
Perdas
Banda
Sensível ao Atraso
sem perdas
sem perdas
tolerante
tolerante
elástica
elástica
elástica
aúdio: 5Kb-1Mb
vídeo:10Kb-5Mb
igual à anterior
Kbps
elástica
não
não
não
sim, 100’s msec
tolerante
tolerante
sem perda
sim, segundos
sim, 100’s msec
sim
Cap. 2: Camada de Aplicação
8
Serviços de Transporte da Internet
serviço TCP:
serviço UDP:

 transferência de dados não
orientado á conexão: conexão
requerida entre cliente e servidor
 transporte confiável dados
perdidos na transmissão são
recuperados
 controle de fluxo: compatibilização
de velocidade entre o transmissor
e o receptor

controle de congestionamento :
protege a rede do excesso de
tráfego
 não oferece: garantias de
temporização e de banda mínima
confiável entre os processos
transmissor e receptor
 não oferece:
estabelecimento de conexão,
confiabilidade, controle de
fluxo e de congestionamento,
garantia de temporização e
de banda mínima.
Cap. 2: Camada de Aplicação
9
Aplicações e Protocolos de Transporte da Internet
Aplicação
e-mail
acesso de terminais remotos
Web
transferência de arquivos
streaming multimedia
servidor de arquivos remoto
telefonia Internet
Protocolo de
Aplicação
Protocolo de
Transporte
smtp [RFC 821]
telnet [RFC 854]
http [RFC 2068]
ftp [RFC 959]
RTP ou proprietario
(e.g. RealNetworks)
NFS
RTP ou proprietary
(e.g., Vocaltec)
TCP
TCP
TCP
TCP
TCP ou UDP
TCP ou UDP
tipicamente UDP
Cap. 2: Camada de Aplicação
10
Protocolo HTTP
HTTP: HyperText Transfer
Protocol
 protocolo da camada de
aplicação da Web
 modelo cliente/servidor
 cliente: browser que
solicita, recebe e
apresenta objetos da Web
 server: envia objetos em
resposta a pedidos
 http1.0: RFC 1945
 http1.1: RFC 2068
PC rodando
Explorer
Servidor
rodando
NCSA Web
server
Mac rodando
Netscape
Navigator
Cap. 2: Camada de Aplicação
11
Protocolo HTTP
http - protocolo de
transporte: 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 é “stateless”
 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!
 necessidade de organizar
informações passadas
 se ocorrer um queda do
sistema, as informações
podem ser perdidas ou gerar
inconsistências entre o
cliente e o servidor
Cap. 2: Camada de Aplicação
12
Exemplo de Operação
Usuário entra com a URL: www.someSchool.edu/someDepartment/home.index
(contém referência a
10 imagens jpeg)
1a. cliente http inicia conexão TCP ao
servidor http (processo) em
www.someSchool.edu. Porta 80 é a
default para o servidor http .
2. cliente http client envia uma mensagem
de requisição http (contendo a URL)
para o socket da conexão TCP
1b. servidor http no host
www.someSchool.edu esperando pela
conexão TCP na porta 80. “aceita”
conexão, notificando o cliente
3. servidor http recebe mensagem de
pedido, constrói a mensagem de
resposta contendo o objeto solicitado
(someDepartment/home.index), envia
mensagem para o socket
tempo
Cap. 2: Camada de Aplicação
13
Exemplo (cont.)
4. servidor http fecha conexão TCP.
5. cliente http recebe mensagem de
resposta contendo o arquivo html,
apresenta o conteúdo html.
Analisando o arquivo html encontra 10
objetos jpeg referenciados
tempo
6. Passos 1-5 são repetidos para cada um
dos 10 objetos jpeg.
Cap. 2: Camada de Aplicação
14
Conexões persistentes e não-persistentes
Não-persistente
 http/1.0: servidor analisa
pedido, envia resposta e fecha
a conexão TCP
 2 RTTs para obter um objeto
 Conexão TCP
 solicitação e transferência
do objeto
 cada transferência sofre por
causa do mecanismo de slowstart do TCP
 muitos browsers abrem várias
conexões paralelas
Persistente
 modo default para htp/1.1
 na mesma conexão TCP são
trazidos vários objetos
 o cliente envia pedido para
todos os objetos
referenciados tão logo ele
recebe a página HTML básica.
 poucos RTTs, menos slow
start.
Cap. 2: Camada de Aplicação
15
Formato das Mensagens
 dois tipos de mensagens HTTP:
request, response
 mensagem de requisição http (request):
 ASCII (formato legível para humanos)
linha de pedido
(comandos GET,
POST, HEAD )
GET /somedir/page.html HTTP/1.0
User-agent: Mozilla/4.0
Accept: text/html, image/gif, image/jpeg
linhas de Accept-language:fr
cabeçalho
(extra carriage return, line feed)
Carriage return,
line feed
indica fim da mensagem
Cap. 2: Camada de Aplicação
16
HTTP request: formato geral
Cap. 2: Camada de Aplicação
17
Formatos HTTP: response
linha de status
(protocolo
código de status
frase de status)
linhas de
cabeçalho
dados, e.x.,
arquivo html
HTTP/1.0 200 OK
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
data data data data data ...
Cap. 2: Camada de Aplicação
18
HTTP response: formato geral
version
status
phrase
Cap. 2: Camada de Aplicação
19
Códigos de status das respostas
200 OK

requisição bem sucedida, objeto solicitado vem em seguida
301 Moved Permanently

objeto requisitado foi movido; a nova localização é especificada
a seguir na mensagem
400 Bad Request

mensagem de requisição não entendida pelo servidor
404 Not Found

documento requisitado não encontrado neste servidor
505 HTTP Version Not Supported
Cap. 2: Camada de Aplicação
20
HTTP Cliente: faça você mesmo!
1. Telnet para um servidor Web:
telnet www.eurecom.fr 80 Abre conexão TCP para a porta 80
(porta default do servidor http) em www.eurecom.fr.
Qualquer coisa digitada é enviada
para a porta 80 em www.eurecom.fr
2. Digite um pedido GET http:
GET /~ross/index.html HTTP/1.0
Digitando isto (tecle carriage
return duas vezes), você envia este
pedido HTTP GET mínimo (mas completo)
ao servidor http
3. Examine a mensagem de resposta enviada pelo servidor
http!
Cap. 2: Camada de Aplicação
21
HTML (HyperText Markup Language)
 HTML: uma linguagem simples para hipertexto
 começou como versão simples de SGML
 construção básica: cadeias (strings) de texto anotadas
 Construtores de formato operam sobre cadeias
 <b> .. </b>
bold (negrito)
 <H1 ALIGN=CENTER> ..título centrado .. </H1>
 <BODY bgcolor=white text=black link=red ..> .. </BODY>
 vários formatos
 listas de bullets, listas ordenadas, listas de definição
 tabelas
 frames
Cap. 2: Camada de Aplicação
22
Encadeamento de referências
 Referências <A HREF=LinkRef> ... </A>
 a componentes do documento local
<A HREF=“importante”> clique para uma dica </A>
 a documentos no servidor local
<A HREF=“../index.htm”> voltar ao sumário </A>
 a documentos em outros servidores
<A HREF=“http://www.ufg.br”> saiba mais sobre a UFG </A>
 Multimídia
 imagem embutida: <IMG SRC=“eclipse”>
 imagem externa:
<A HREF=“eclipse.gif”> imagem maior </A>
 vídeo Mpeg <A HREF=“ByeByeBrasil.mpg”> um bom filme </A>
 som
<A HREF=“http://www.sons.br/aniv.au”> feliz aniversário </A>
Cap. 2: Camada de Aplicação
23
Formulários e interação bidirecional
 Formulários transmitem
informação do cliente ao
servidor
 HTTP permite enviar
formulários ao servidor
 Resposta enviada como página
HTML dinâmica
 Formulários processados usando
scripts CGI (programas que
executam no servidor WWW)
 CGI - Common Gateway
Interface
 scripts CGI escondem acesso a
diferentes serviços
 servidor WWW atua como
gateway universal
 Outras tecnologias: ASP,
cliente
WWW
GET/POST
formulário
resposta:
HTML
JSP, PHP, ...
servidor
WWW
Sistema de
informação
Cap. 2: Camada de Aplicação
24
Interação usuário-servidor: autenticação
Meta da autenticação: controle de
acesso aos documentos do servidorcliente
servidor
 sem estado: cliente deve
msg de pedido http comum
apresentar autorização com cada
pedido
401: authorization req.
WWW authenticate:
 autorização: tipicamente nome,
senha
 authorization: linha de
msg de pedido http comum
cabeçalho no pedido
+ Authorization:line
 se não for apresentada
msg de resposta http comum
autorização, servidor nega
accesso, e coloca no cabeçalho
da resposta
WWW authenticate:
msg de pedido http comum
+ Authorization:line
msg de resposta http comum
Browser guarda nome e senha para
evitar que sejam pedidos ao usuário a cada acesso.
tempo
Cap. 2: Camada de Aplicação
25
Cookies
 gerados e lembrados pelo
servidor, usados mais tarde
para:
 autenticação
 lembrar preferencias
dos usuários ou prévias
escolhas
 servidor envia “cookie” ao
cliente na resposta HTTP
Set-cookie: 1678453
 cliente apresenta o cookie
em pedidos posteriores
cookie: 1678453
cliente
servidor
usual http request msg
usual http response +
Set-cookie: uid
usual http request msg
cookie: uid
usual http response msg
usual http request msg
cookie: uid
usual http response msg
Gera resposta
+
ID único (uid)
p/ cookie
ação
específica
do cookie
ação
específica
do cookie
Cap. 2: Camada de Aplicação
26
Conditional GET: armazenando no cliente
 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
do cliente está atualizada:
HTTP/1.0 304 Not
Modified
servidor
cliente
http request msg
If-modified-since:
<date>
http response
objeto
não
modificado
HTTP/1.0
304 Not Modified
http request msg
If-modified-since:
<date>
http response
objeto
modificado
HTTP/1.1 200 OK
<data>
Cap. 2: Camada de Aplicação
27
ftp: o protocolo de transferência de arquivos
user
at host
FTP
FTP
interface cliente
de usuário
transferência de
arquivos
sistema de
arquivos
local
FTP
servidor
sistema de
arquivos remoto
 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: host remoto
 ftp: RFC 959
 ftp servidor: porta 21
Cap. 2: Camada de Aplicação
28
ftp: controle separado, conexões de dados
 cliente ftp contata o servidor
ftp na porta 21, especificando
TCP como protocolo de
transporte
 duas conexões TCP paralelas são
abertas:
 controle: troca de comandos
e respostas entre cliente e
servidor.
“controle out of band”
 dados: dados do arquivo
trocados com o servidor
 servidor ftp mantém o “estado”:
diretório corrente, autenticação
anterior
TCP conexão de controle
porta 21
FTP
cliente
TCP conexão de dados
porta 20
FTP
servidor
Cap. 2: Camada de Aplicação
29
ftp comandos, respostas
Exemplos de comandos:
 Enviados em texto ASCII
através do canal de controle
 USER username
 PASS password
 LIST retorna listagem dos
arquivos no diretório atual
 RETR filename recupera
(obtém) o arquivo (GET)
 STOR filename armazena o
arquivo no host remoto (PUT)
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
Cap. 2: Camada de Aplicação
30
Correio Eletrônico
fila de
saída de mensagem
caixa postal
Três componentes principais:
 agentes de usuário
 servidores de correio
servidor
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
 mensagens que chegam e saem são
armazenadas em filas no servidor
agente
usuário
SMTP
agente
usuário
mail
server
agente
usuário
SMTP
SMTP
servidor
de correio
agente
usuário
agente
usuário
agente
usuário
Cap. 2: Camada de Aplicação
31
Correio eletrônico: servidores de correio
agente
usuário
Servidores de Correio
 caixa postal contém mensagens
servidor
de correio
que chegaram (ainda não lidas)
para o usuário
 fila de mensagens contém as
mensagens de correio a serem
SMTP
enviadas
 protocolo smtp permite aos
servidores de correio trocarem
servidor
mensagens entre eles
de correio
 “cliente”: servidor de
correio que envia
 “servidor”: servidor de
correio que recebe
SMTP
agente
usuário
mail
server
agente
usuário
SMTP
agente
usuário
agente
usuário
agente
usuário
Cap. 2: Camada de Aplicação
32
Correio Eletrônico: smtp [RFC 821]
 usa TCP para transferência confiável de mensagens de correio
do cliente para o servidor, através da porta 25
 transferência direta: do servidor que envia para o servidor
que recebe
 três fases de trasnferê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
Cap. 2: Camada de Aplicação
33
Exemplo de interação SMTP
S:
C:
S:
C:
S:
C:
S:
C:
S:
C:
C:
C:
S:
C:
S:
220 hamburger.edu
HELO crepes.fr
250 Hello crepes.fr, pleased to meet you
MAIL FROM: <[email protected]>
250 [email protected]... Sender ok
RCPT TO: <[email protected]>
250 [email protected] ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Do you like ketchup?
How about pickles?
.
250 Message accepted for delivery
QUIT
221 hamburger.edu closing connection
Cap. 2: Camada de Aplicação
34
Tente o SMTP você mesmo:
 telnet <nome do servidor> 25
 veja resposta 220 do servidor
 envie comandos HELO, MAIL FROM, RCPT TO, DATA,
QUIT
 como no exemplo anterior
a seqüência acima permite enviar um e-mail sem usar o
agente de usuário do rementente
Cap. 2: Camada de Aplicação
35
SMTP: palavras finais
 SMTP usas conexões
persistentes
 SMTP exige que as mensagens
(cabeçalho e corpo) estejam em
ASCII de 7 bits
 algumas seqüências de
caracteres não são permitidas
no corpo das mensagens (ex.,
CRLF.CRLF). Assim mensagens
genéricas têm que ser
codificadas (usualmente em
“base-64” ou “quoted
printable”)
 Servidor SMTP usa CRLF.CRLF
para indicar o final da
mensagem
Comparação com http:
pull
 email: modelo push
 http: modelo
 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
Cap. 2: Camada de Aplicação
36
Formato das Mensagens
smtp: protocolo para trocar
mensagens de e-mail
RFC 822: padrão para
mensagens do tipo texto:
 linhas de cabeçalho, e.g.,



To:
From:
Subject:
cabeçalho
linha
em branco
corpo da mensagem
não confudir com os
comandos SMTP !
 corpo

a “mensagem”, ASCII
somente com caracteres
Cap. 2: Camada de Aplicação
37
Formato das Mensagens: extensões multimedia
 MIME: multimedia mail extension: RFC 2045, 2056
 linhas adicionais no cabeçalho declaram o tipo de conteúdo
MIME
versão de MIME
utilizada
método usado
para codificar dados
tipo, subtipo e
declaração de parâmetro
dos dados multimídia
dados codificados
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
Cap. 2: Camada de Aplicação
38
Tipos MIME
Content-Type: type/subtype; parâmetros
Text
 exemplo de subtipos: plain,
html
Image
 exemplo de subtipos: jpeg,
gif
Audio
 exemplo de subtipos: basic
(codificado 8-bit m-law ),
32kadpcm (codificação 32
kbps)
Video
 exemplo de subtipos: mpeg,
quicktime
Application
 outros dados que devem ser
processados pelo leitor antes
de serem apresentados
“visualmente”
 exemplo de subtipos:
msword, octet-stream
Cap. 2: Camada de Aplicação
39
Tipo Multiparte: Mensagens com múltiplos
objetos de tipos diferentes
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=98766789
--98766789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
Dear Bob,
Please find a picture of a crepe.
--98766789
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
--98766789--
delimitador
1a. parte: texto
2a. parte: imagem
Cap. 2: Camada de Aplicação
40
Formato das mensagens recebidas
 Servidor de correio do destino (que recebe a
mensagem) adiciona a linha de cabeçalho
Received:
Received: from crepes.fr by hamburger.edu;
12 Oct 98 15:27:39 GMT
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
Cap. 2: Camada de Aplicação
41
Protocolos de acesso ao correio
agente
usuário
SMTP
SMTP
servidor de
correio da origem
POP3 or
IMAP
agente
usuário
servidor de
correio do destino
 SMTP: entrega e armazena as mensagens 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]
• mais recursos (mais complexo)
• permite a manipulação de mensagens armazenadas no
servidor (ex.: organizá-las em diretórios)
HTTP: Hotmail , Yahoo! Mail, etc.
Cap. 2: Camada de Aplicação
42
protocolo POP3
fase de autorização
 comandos do cliente:
user: declara nome do usuário
 pass: password
 respostas do servidor
 +OK
 -ERR

fase de transação
 list: lista mensagens e tamanhos
 retr: recupera mensagem pelo
número
 dele: apaga
 quit
S:
C:
S:
C:
S:
+OK POP3 server ready
user alice
+OK
pass hungry
+OK user successfully logged
C:
S:
S:
S:
C:
S:
S:
S:
C:
C:
S:
S:
S:
C:
C:
S:
list
1 498
2 912
.
retr 1
(blah blah blah ...
.....................)
.
dele 1
retr 2
(blah blah blah ...
.....................)
.
dele 2
quit
+OK POP3 server signing off
Cap. 2: Camada de Aplicação
on
43
DNS: Domain Name System
Pessoas: muitos
identificadores:



base de dados distribuída

protocolo de camada de aplicação
RG, nome, passaporte
Hosts e roteadores na
Internet:

Domain Name System:
endereços IP (32 bit) usados para endereçar
datagramas
“nome”, ex.,
gaia.cs.umass.edu - usados
por humanos
Q: Como relacionar nomes
com endereços IP?
implementada numa hierarquia de
muitos servidores de nomes
host, roteadores se comunicam
com servidores de nomes para
resolver nomes (tradução
nome/endereço)
 nota: função interna da
Internet, implementada como
um protocolo da camada de
aplicação
 complexidade na “borda” da
rede
Cap. 2: Camada de Aplicação
44
Servidores de Nomes DNS
 Nenhum servidor tem todos os
Porque não centralizar o DNS?
 ponto único de falha
 volume de tráfego
 base de dados distante
 manutenção
Não cresce junto com a rede!
isto é: não seria escalável
mapeamentos de nomes para
endereços IP
servidores de nomes locais:


cada ISP ou empresa tem um
servidor de nomes local (default)
Consultas dos computadores
locais ao DNS vão primeiro para
o servidor de nomes local
servidor de nomes autoritativo:


para um computador: armazena o
nome e o endereço IP daquele
computador
pode realizar mapeamentos de
nomes para endereços para aquele
nome de computador
Cap. 2: Camada de Aplicação
45
DNS: Servidores de Nomes Raiz
 são contactados pelos servidores de nomes locais que não podem resolver um nome
 servidor de nomes raiz::



busca servidores de nomes autoritativos se o mapeamento do nome não for
conhecido
obtém o mapeamento
retorna o mapeamento para o servidor de nomes local
a NSI Herndon, VA
c PSInet Herndon, VA
d U Maryland College Park, MD
g DISA Vienna, VA
h ARL Aberdeen, MD
j NSI (TBD) Herndon, VA
k RIPE London
i NORDUnet Stockholm
m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto, CA
b USC-ISI Marina del Rey, CA
l ICANN Marina del Rey, CA
existem 13 servidores
de nomes raiz no
mundo (2002)
Cap. 2: Camada de Aplicação
46
DNS: exemplo simples
servidor de nomes
raiz
host surf.eurecom.fr
quer o endereço IP de
gaia.cs.umass.edu
1. contacta seu servidor DNS local,
dns.eurecom.fr
2. dns.eurecom.fr contata o
servidor de nomes raiz, se
necessário
3. o servidor de nomes raiz contata
o servidor de nomes
autoritativo, dns.umass.edu,
se necessário
2
4
5
servidor de nomes local
dns.eurecom.fr
1
3
servidor de nomes
autoritativo
dns.umass.edu
6
computador solicitante
gaia.cs.umass.edu
surf.eurecom.fr
Cap. 2: Camada de Aplicação
47
DNS: exemplo
servidor de nomes
raiz
Servidor de nomes
raiz:
6
2
7
3
 pode não conhecer o
servidor de nomes
autoritativo para um
certo nome
 pode conhecer:
servidor de nomes
intermediário: aquele
que deve ser contactado
para encontrar o
servidor de nomes
autoritativo
servidor de nomes
intermediário
dns.umass.edu
servidor de nomes local
dns.eurecom.fr
1
8
4
5
servidor de nomes
autoritativo
dns.cs.umass.edu
computador solicitante
surf.eurecom.fr
gaia.cs.umass.edu
Cap. 2: Camada de Aplicação
48
DNS: consultas encadeadas
servidor de nomes
raiz
consulta recursiva:
 transfere a tarefa de
resolução do nome para
o servidor de nomes
consultado
 carga pesada?
consulta encadeada:
 servidor contactado
responde com o nome de
outro servidor de nomes
para contato
 “Eu não sei isto ,mas
pergunte a este
servidor”
consulta
encadeada
2
3
4
servidor de nomes
intermediário
dns.umass.edu
7
servidor de nomes local
dns.eurecom.fr
1
8
5
6
servidor de nomes
autoritativo
dns.cs.umass.edu
computador solicitante
surf.eurecom.fr
gaia.cs.umass.edu
Cap. 2: Camada de Aplicação
49
DNS: armazenando e atualizando
registros
 Uma vez que um servidor de nomes apreende um
mapeamento, ele armazena o mapeamento num
registro do tipo cache
 registro da cache tornam-se obsoletos
(desapareçem) depois de um certo tempo
 Tradicionalmente: registros são armazenados
estaticamente

ex.: a partir de um arquivo de configuração
 RFC 2136: mecanismos de atualização dinâmica estão
sendo projetados pelo IETF


Dynamic DNS updates: adicionar ou remover registros
dinamicamente
http://www.ietf.org/html.charters/dnsind-charter.html
Cap. 2: Camada de Aplicação
50
registros do DNS
DNS: base de dados distribuída que armazena registros de recursos (RRs)
formato dos RRs: (name,
 Type=A


name é o nome do computador
value é o endereço IP
 Type=CNAME

 Type=NS


name é um domínio (ex.
foo.com)
value é o endereço IP do
servidor de nomes autoritativo
para este domínio
value, type, ttl)
name é um “apelido” para algum nome
“canônico” (o nome real)
Ex.: www.ibm.com é realmente
servereast.backup2.ibm.com

value é o nome canônico
 Type=MX

value é o nome canônico do
servidor de correio associado com
name
Cap. 2: Camada de Aplicação
51
DNS: protocolo e mensagens
protocolo DNS: mensagen de consulta e resposta , ambas com o
mesmo formato de mensagem
cabeçalho da mensagem
 identificação: número de 16 bit
para a consulta, resposta usa o
mesmo número
 flags:
 consulta ou resposta
 recursão desejada
 recursão disponível
 resposta é autoritativa
Cap. 2: Camada de Aplicação
52
DNS: protocolo e mensagens
Campos de nome e tipo
para uma consulta
RRs de resposta
a uma consulta
registros para
servidores autoritativos
informação adicional
que pode ser útil
Ex.: se answer é do tipo “MX”,
additional info poderá conter
um RR do tipo “A” com o
endereço IP do servidor de e-mail
Cap. 2: Camada de Aplicação
53
Programação de Sockets
Objetivo: aprender a construir aplicações cliente/servidor
que se comunicam usando sockets
socket
API de Sockets
uma interface local, criada
 introduzida no BSD4.1 UNIX,
1981
 sockets são explicitamente
criados, usados e liberados
pelas aplicações
 paradigma cliente/servidor
 dois tipos de serviço de
transporte via socket API:
 datagrama não confiável
 confiável, orientado a fluxo
de bytes
e possuída pelas aplicações
controlada pelo OS
uma “porta” através qual
os processos de aplicação
podem tanto enviar quanto
receber mensagens de e
para outro processo de
aplicação (local ou remoto)
Cap. 2: Camada de Aplicação
54
Programação de Sockets com TCP
Socket: uma porta entre o processo de aplicação e o
protocolo de transporte fim-a-fim (UDP ou TCP)
serviço TCP: transferência confiável de bytes de um
processo para outro
controlado pelo
criador da aplicação
controlado pelo
sistema
operacional
processo
processo
socket
TCP com
buffers,
variáveis
host ou
servidor
internet
socket
TCP com
buffers,
variáveis
controlado pelo
criador da aplicação
controlado pelo
sistema
operacional
host ou
servidor
Cap. 2: Camada de Aplicação
55
Programação de Sockets com TCP
Cliente deve contactar o
servidor
 processo servidor já
deve estar executando
antes de ser contactado
 servidor deve ter criado
um socket (porta) que
aceita o contato do
cliente
Como o cliente contacta o
servidor:
 criando um socket TCP
local
 especificando endereço
IP e número da porta do
processo servidor
 Quando o cliente cria o socket:
cliente TCP estabelece conexão
com o TCP do servidor
 Quando contactado pelo
cliente, o TCP do servidor cria
um novo socket para o processo
servidor comunicar-se com o
cliente
 permite ao servidor
conversar com múltiplos
clientes
ponto de vista da aplicação
TCP fornece a transferência
confiável (fluxo de bytes ordenados)
(“pipe”) entre o cliente e o
servidor
Cap. 2: Camada de Aplicação
56
Programação de Sockets com TCP
padrão do sistema (stream
inFromUser) , envia para o
servidor via socket (stream
outToServer)
 servidor lê a linha do socket
 servidor converte linha para
letras maiúsculas e envia de volta
ao cliente
 cliente lê a linha modificada
através do sockete (stream
inFromServer)
input
stream
processo
cliente
stream de saída:
seqüência de bytes
para fora do processo
output
stream
monitor
stream de entrada:
seqüência de bytes
para dentro do processo
inFromServer
 cliente lê uma linha da entrada
outToServer
Exemplo de aplicação clienteservidor:
inFromUser
teclado
input
stream
TCP
socket
clientSocket
cliente
para rede
TCP
socket
da rede
Cap. 2: Camada de Aplicação
57
Interação Cliente/servidor: TCP
Servidor
(executando em hostid)
cria socket,
porta=x, para
solicitação entrante:
welcomeSocket =
ServerSocket()
Cliente
TCP
espera por pedido
estab. de conexão
de conexão entrante
connectionSocket =
welcomeSocket.accept()
lê pedido de
connectionSocket
escreve resposta para
connectionSocket
fecha
connectionSocket
cria socket,
conecta com hostid, porta=x:
clientSocket =
Socket()
envia pedido usando
clientSocket
lê resposta de
clientSocket
fecha
clientSocket
Cap. 2: Camada de Aplicação
58
Exemplo: cliente Java (TCP)
import java.io.*;
import java.net.*;
class TCPClient {
public static void main(String argv[]) throws Exception
{
String sentence;
String modifiedSentence;
Cria
stream de entrada
Cria
socket cliente,
conecta ao servidor
Cria
stream de saída
ligada ao socket
BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
Socket clientSocket = new Socket("hostname", 6789);
DataOutputStream outToServer =
new DataOutputStream(clientSocket.getOutputStream());
Cap. 2: Camada de Aplicação
59
Exemplo: cliente Java (TCP), cont.
BufferedReader inFromServer =
new BufferedReader(new
InputStreamReader(clientSocket.getInputStream()));
Cria
stream de entrada
ligada ao socket
sentence = inFromUser.readLine();
Envia linha
para o servidor
outToServer.writeBytes(sentence + '\n');
modifiedSentence = inFromServer.readLine();
Lê linha
do servidor
System.out.println("FROM SERVER: " + modifiedSentence);
clientSocket.close();
}
}
Cap. 2: Camada de Aplicação
60
Exemplo: servidor Java (TCP)
import java.io.*;
import java.net.*;
class TCPServer {
Cria
socket de aceitação
na porta 6789
Espera, no socket
de aceitação por
contato do cliente
Cria stream de
entrada, ligado
ao socket
public static void main(String argv[]) throws Exception
{
String clientSentence;
String capitalizedSentence;
ServerSocket welcomeSocket = new ServerSocket(6789);
while(true) {
Socket connectionSocket = welcomeSocket.accept();
BufferedReader inFromClient =
new BufferedReader(new
InputStreamReader(connectionSocket.getInputStream()));
Cap. 2: Camada de Aplicação
61
Exemplo: servidor Java (cont)
Cria stream de
saída, ligado ao
socket
DataOutputStream outToClient =
new DataOutputStream(connectionSocket.getOutputStream());
Lê linha do
socket
clientSentence = inFromClient.readLine();
capitalizedSentence = clientSentence.toUpperCase() + '\n';
Escreve linha
para o socket
outToClient.writeBytes(capitalizedSentence);
}
}
}
Fim do while loop,
retorne e espere por
outra conexão do cliente
Cap. 2: Camada de Aplicação
62
Programaçaõ de Sockets com UDP
UDP: não há conexão entre o
cliente e o servidor
 não existe apresentação
(handshaking)
 transmissor envia
explicitamente endereço IP e
porta de destino em cada
mensagem
 servidor deve extrair o
endereço IP e porta do
transmissor de cada
datagrama recebido
 UDP: dados transmitidos
podem ser recebidos foram
de ordem ou perdidos
ponto de vista da aplicação
UDP fornece a transferência
não confiável de grupos de bytes
(“datagramas”) entre o cliente e o
servidor
Cap. 2: Camada de Aplicação
63
Interação Cliente/servidor: UDP
Servidor
(executando em hostid)
cria socket,
porta=x, para
solicitação entrante:
serverSocket =
DatagramSocket()
lê pedido de:
serverSocket
escreve resposta para
serverSocket
especificando endereço
do host cliente e
número da porta
Cliente
cria socket,
clientSocket =
DatagramSocket()
Cria endereço (hostid, port=x),
envia datagrama de pedido
usando clientSocket
lê resposta de
clientSocket
fecha
clientSocket
Cap. 2: Camada de Aplicação
64
Exemplo: cliente Java (UDP)
stream
de entrada
processo
cliente
monitor
inFromUser
teclado
Process
(TCP enviaria “byte
stream”)
pacote
UDP
receivePacket
Saída: envia pacote
sendPacket
Entrada: recebe
socket
UDP
clientSocket
cliente
para rede
pacote (TCP
receberia “byte
stream”)
pacote
UDP
UDP
socket
da rede
Cap. 2: Camada de Aplicação
65
Exemplo: cliente Java (UDP)
import java.io.*;
import java.net.*;
Cria
stream de entrada
Cria
socket cliente
Traduz
nome do host para
endereço IP
usando DNS
class UDPClient {
public static void main(String args[]) throws Exception
{
BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
DatagramSocket clientSocket = new DatagramSocket();
InetAddress IPAddress = InetAddress.getByName("hostname");
byte[] sendData = new byte[1024];
byte[] receiveData = new byte[1024];
String sentence = inFromUser.readLine();
sendData = sentence.getBytes();
Cap. 2: Camada de Aplicação
66
Exemplo: cliente Java (UDP), cont.
Cria datagrama com
dados a enviar,
tamanho, endereço IP
e porta
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress, 9876);
Envia datagrama
para servidor
clientSocket.send(sendPacket);
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
Lê datagrama
do servidor
clientSocket.receive(receivePacket);
String modifiedSentence =
new String(receivePacket.getData());
System.out.println("FROM SERVER:" + modifiedSentence);
clientSocket.close();
}
}
Cap. 2: Camada de Aplicação
67
Exemplo: servidor Java (UDP)
import java.io.*;
import java.net.*;
Cria
socket datagrama
na porta 9876
class UDPServer {
public static void main(String args[]) throws Exception
{
DatagramSocket serverSocket = new DatagramSocket(9876);
byte[] receiveData = new byte[1024];
byte[] sendData = new byte[1024];
while(true)
{
Cria espaço para
datagramas recebidos
Recebe
datagrama
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
serverSocket.receive(receivePacket);
Cap. 2: Camada de Aplicação
68
Exemplo: servidor Java, (cont.)
String sentence = new String(receivePacket.getData());
Obtém endereço IP
e número da porta
do transmissor
InetAddress IPAddress = receivePacket.getAddress();
int port = receivePacket.getPort();
String capitalizedSentence = sentence.toUpperCase();
sendData = capitalizedSentence.getBytes();
Cria datagrama
para enviar ao cliente
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress,
port);
Escreve o
datagrama para
dentro do socket
serverSocket.send(sendPacket);
}
}
}
Termina o while loop,
retorna e espera por
outro datagrama
Cap. 2: Camada de Aplicação
69
Programação de Sockets:
referências
tutorial sobre sockets em linguagem C (audio/slides):
 “Unix Network Programming” (J. Kurose),
http://manic.cs.umass.edu
Tutoriais sobre sockets em Java:
 “Socket Programming in Java: a tutorial,”
http://www.javaworld.com/javaworld/jw-12-1996/jw-12sockets.html
Cap. 2: Camada de Aplicação
70
Construção de um Servidor Web
Simplificado
 Ingredientes: Protocolo HTTP + Sockets
 Funcionalidade:
 Trata apenas uma requisição HTTP
 Aceita e interpreta a requisição
 Obtém o arquivo requisitado a partir do sistema de
arquivos local (do servidor Web)
 Cria uma mensagem de resposta HTTP: Linhas de
cabeçalho + arquivo requisitado
 Envia a resposta diretamente para o cliente
 Fecha conexão e termina
Cap. 2: Camada de Aplicação
71
Construção de um Servidor Web
Simplificado
 Cliente: Navegador Web padrão

Netscape, IE, Konqueror, etc.
 Exemplo de requisição:
URL:
http://somehost.somewhere.br:6789/somefile.html
host e porta: usados p/ estab. conexão com servidor
Requisição:
GET /somefile.html HTTP/1.0
Cap. 2: Camada de Aplicação
72
WebServer.java (1)
import java.io.*;
import java.net.*;
import java.util.*;
class WebServer {
public static void main (String argv[]) throws Exception
{
String requestMessageLine;
ServerSocket listenSocket = new ServerSocket(6789);
Socket connectionSocket = listenSocket.accept();
BufferedReader inFromClient =
new BufferedReader (new InputStreamReader(
Stream
para
connectionSocket.getInputStream()));
receber
dados via
socket
Socket para
espera de
conexões
Socket de
conexão
c/ cliente
Cap. 2: Camada de Aplicação
73
WebServer.java (2)
Separa os
tokens da
requisição
Verifica se
comando é
GET
Obtém o
tamanho
do arquivo
Stream para
enviar dados
através do
socket
DataOutputStream outToClient =
new DataOutputStream(
connectionSocket.getOutputStream());
requestMessageLine = inFromClient.readLine();
StringTokenizer tokenizedLine =
new StringTokenizer( requestMessageLine);
if (tokenizedLine.nextToken().equals(“GET”)){
fileName = tokenizedLine.nextToken();
if (fileName.startsWith(“/”) == true)
fileName = fileName.substring(1);
File file = new File(fileName);
int numOfBytes = (int) file.length();
Lê
requisição
do cliente
Obtém o
nome do
arquivo
Cap. 2: Camada de Aplicação
74
WebServer.java (3)
Lê o
arquivo
requisitado
Envia a
primeira linha
do cabeçalho
da resposta
Segunda linha
(content-type)
depende do tipo
do arquivo
requisitado (jpeg
ou gif)
FileInputStream inFile = new FileInputStream(fileName);
byte [] fileInBytes = new byte[numOfBytes];
inFile.read(fileInBytes);
outToClient.writeBytes(
“HTTP/1.0 200 Document Follows\r\n”);
if (fileName.endsWith(“.jpg”))
outToClient.writeBytes(“Content-Type:
image/jpeg\r\n”);
if (fileName.endsWith(“.gif”))
outToClient.writeBytes(“Content-Type:
image/gif\r\n”);
Cap. 2: Camada de Aplicação
75
WebServer.java (4)
Envia a 3a.
linha do
cabeçalho
Linha em branco
para separar o
cabeçalho do
corpo da msg
outToClient.writeBytes(“Content-Length: “ +
numOfBytes + “\r\n”);
outToClient.writeBytes(“\r\n”);
outToClient.write(fileInBytes, 0, numOfBytes);
connectionSocket.close();
}
else System.out.println(“Bad Request Message”);
Envia o
arquivo
requisitado
Fecha a
conexão com
o cliente
}
}
Cap. 2: Camada de Aplicação
76
WebServer.java: O que Falta?
 Aceitar múltiplas requisições
 Cada requisição processada por uma
thread
diferente
 Tratar outros tipos de conteúdo (linha de
cabeçalho Content-type:)
 Suporte para demais comandos (POST, HEAD)
 Suporte para demais tipos de mensagem de
resposta (Bad request, Not found, etc.)
 O que mais?
Cap. 2: Camada de Aplicação
77
Distribuição de Conteúdo
 Web Caches (ou Web Proxies)
 Redes de Distribuição de Conteúdo (CDNs)
 Redes “Peer-to-Peer”
Cap. 2: Camada de Aplicação
78
Web Caches (proxy server)
Objetivo: atender o cliente sem envolver o servidor Web
originador da informação
servidor
original
 usuário configura o browser:
acesso à Web é feito através de um
proxy
 cliente envia todos os pedidos http
para o proxy
 se o objeto existe no proxy
(web cache): proxy retorna o
objeto
 caso contrário, o proxy solicita
o objeto ao servidor original e
então envia o objeto ao cliente.
 proxy guarda o objeto em sua
cache
cliente
Proxy
server
cliente
servidor
original
Cap. 2: Camada de Aplicação
79
Porque Web Caching?
armazenamento está
“perto” do cliente (ex.,
na mesma rede)
 menor tempo de
resposta
 reduz o tráfego para
servidores distantes


links externos podem
ser caros e facilmente
congestionáveis
servidores
originais
Internet
pública
enlace de acesso
1.5 Mbps
rede
institucional
10 Mbps LAN
cache
institucional
Cap. 2: Camada de Aplicação
80
Análise simplificada
 Tamanho médio dos objetos




requisitados: 100.000 bits
15 requisições / segundo
“Atraso da Internet”: 2s
Atraso total:
 LAN + acesso + Internet
Intensidade de tráfego na
LAN:
(15 reqs/s) . (100kbits/req)/(10Mbps) = 0,15
servidores
originais
Internet
pública
enlace de acesso
1.5 Mbps
rede
institucional
10 Mbps LAN
 Intens. de tráf. no acesso:
(15 reqs/s) . (100kbits/req)/(1,5Mbps) = 1
 Congestionamento no enlace
de acesso: atraso crescente
Cap. 2: Camada de Aplicação
81
Análise: Com o Proxy
 Taxa de acerto: 0,4

40% dos acessos: via proxy
servidores
originais
Internet
pública
• Atraso da LAN (0,01s)

60% dos acessos: servidor
original
• Intes. tráf. no acesso: 0,6
• Atraso: 2,01s

Atraso médio:
enlace de acesso
1.5 Mbps
rede
institucional
10 Mbps LAN
0,4*(0,01s) + 0,6*(2,01s) = 1,2s
 Na média, melhor do que um
simples upgrade da “largura de
banda” do enlace de acesso
(e.g., para 10Mbps)

Verificar!
cache
institucional
Cap. 2: Camada de Aplicação
82
Caches Cooperativas
 Múltiplos níveis de caches
 institucional, ISP, nacional
 Caches de mais alto nível
 população de usuários
maior
 maior taxa de acerto
Internet Caching
Protocol
 ICP:

uma forma eficiente para
uma cache consultar outra
se esta possui o objeto
Req.
Resp.
servidor
original
cache
nacional
Resp.
Req.
cache
do ISP
Req.
Resp.
Req.
cache
institucional
Resp.
cliente
Cap. 2: Camada de Aplicação
83
Caches Cooperativas
 Outra técnica: Cluster de caches



cada cache: um sub-conjunto dos objetos
cliente (navegador) mapeia a URL sobre uma tabela
de espalhamento (hash), que determina qual das
caches deve ser consultada
CARP: Cache Array Routing Protocol
hash(URL)
cliente
cluster
de
caches
Cap. 2: Camada de Aplicação
84
Outros Meios de Distribuição de
Conteúdo
 Redes de Distribuição de Conteúdo

Seção 2.9.2, K&R 2nd Edition (em Inglês)
 Compartilhamento de arquivos em redes de
sobreposição (overlay networks) do tipo Peer-
to-Peer

Seção 2.9.3, K&R 2nd Edition (em Inglês)
Cap. 2: Camada de Aplicação
85
Redes de Distribuição de Conteúdo
Contrastando as Abordagens:
 Web Caches: o provedor de acesso (ISP) arca
com os custos de uma maior eficiência de
acesso à Web para seus clientes
 CDNs - Um modelo diferente:
 Provedor de conteúdo contrata uma empresa de
distribuição de conteúdo, a qual mantém a rede de
distribuíção
 Custo fica sob a responsabilidade do provedor de
conteúdo
Cap. 2: Camada de Aplicação
86
Redes de Distribuição de Conteúdo
servidor
original
 Provedor envia conteúdo
para o nodo de
distribuição da CDN
 CDN replica o conteúdo
nos seus diversos
servidores de
distribuição
 Requisições de usuários
são servidas pelo
servidor com o melhor
tempo de resposta

mais próximo do usuário
nodo de
distribuição
servidor
de distribuição
na Am. do Sul
servidor
de distribuição
na Am. do Norte
servidor
de distribuição
na Europa
Cap. 2: Camada de Aplicação
87
Redes de Distribuição de Conteúdo
 Como o navegador sabe
qual o servidor de
distribuição com o
melhor tempo de
resposta?


Provedor original do
conteúdo serve a página
principal do site
Demais páginas são
marcadas com o nome de
domínio da CDN
• serão servidas pela CDN

Requisições do cliente são
redirecionadas pelo DNS
Página principal
(index.html)
Objeto
referenciado
Objeto
referenciado
http://www.cdn.com/
www.foo.com/img.gif
http://www.cdn.com/ww
w.foo.com/filme.mpeg
Distribuído pelo servidor original
Distribuído pela CDN
Cap. 2: Camada de Aplicação
88
Redes de Distribuição de Conteúdo
Redirecionamento via DNS
 CDN configura o servidor de DNS autoritativo
para responder de acordo com o IP do cliente
 Tomando como base:


tabelas de roteamento da Internet
estatísticas de desempenho da rede
Cap. 2: Camada de Aplicação
89
Redes “Peer-to-Peer”
Idéia geral
 Não há um servidor (ou servidores) de
conteúdo centralizado

Alto nível de escalabilidade
 Cada computador ligado à rede é capaz de
prover e requisitar conteúdo
Exemplo:

Compartilhamento de arquivos MP3 em redes como
Napster, Kazaa, Gnutella
Cap. 2: Camada de Aplicação
90
Redes de Sobreposição (Overlay)
 Uma rede lógica construída sobre a Internet
 Conecta os vários computadores em uma rede
peer-to-peer
 Estrutura altamente dinâmica: nodos podem ser
inseridos ou removidos a todo tempo
Cap. 2: Camada de Aplicação
91
Redes Peer-to-Peer
 Problema básico: Descobrir quais
o conteúdo desejado
peers contêm
 Diretório Centralizado (ex.: Napster)
 Diretório Distribuído (ex.: KaZaA)
 Inundação de consultas (query flooding)
Cap. 2: Camada de Aplicação
92
Parte 2: Sumário
Nosso estudo das aplicações está agora completo!
 exigências dos serviços de
aplicação:

confiabilidade, banda
passante, atraso
 paradigma cliente-servidor
 modelo do serviço de
transporte da Internet l


orientado à conexão,
confiável: TCP
não confiável, datagramas:
UDP
 protocolos especificos:




http
ftp
smtp, pop3
dns
 programação de sockets


implementação cliente/servidor
usando sockets tcp, udp
Cap. 2: Camada de Aplicação
93
Parte 2: Sumário
Mais importante: características dos protocolos
 tipica 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 vs. dados
in-band, out-of-band
centralizado vs. descentralizado
stateless vs. stateful
transferência de mensagens
confiável vs. não confiável
“complexidade na borda da rede”
segurança: autenticação






Cap. 2: Camada de Aplicação
94