16/01/13
Camada de Aplicação
Protocolos
Mário Meireles Teixeira. UFMA-DEINF
Tópicos & Objetivos
Objetivos principais:
•  conceitual, aspectos de
implementação de
protocolos de aplicação para
redes
–  paradigma clienteservidor
–  modelos de serviço
•  exemplos de aplicações
Outros objetivos:
•  protocolos específicos:
– 
– 
– 
– 
– 
http
ftp
smtp
pop
dns
•  programação de aplicações
de rede
–  API de sockets
1
16/01/13
Aplicações e Protocolos de Aplicação
Aplicações: processos distribuídos
comunicando-se
aplicação
transporte
rede
enlace
física
–  executam nos computadores da
rede (hosts) como programas de
usuário
–  trocam mensagens para realização
da aplicação
–  vários componentes relacionados
–  ex: email, ftp, Web
Protocolos de aplicação:
–  definem os tipos e sintaxe das
mensagens trocadas
–  definem a semântica das mensagens
–  definem 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
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 através de
passagem de mensagens,
obedecendo a um protocolo
da camada de aplicação
Agente usuário: software que
interage com o usuário, de um
lado e com a rede, de outro
–  implementa um protocolo
da camada de aplicação
–  Web: browser
–  E-mail: leitor de correio
–  streaming audio/video:
media player
•  Aplicação vs. Protocolo
2
16/01/13
Paradigma Cliente-Servidor
Aplicações de rede típicas têm duas
partes: cliente e servidor
Cliente:
aplicação
transporte
rede
enlace
física
pedido
•  inicia comunicação com o servidor
•  tipicamente solicita serviços do
servidor,
•  Web: cliente implementado no
browser; e-mail: leitor de correio
resposta
Servidor:
•  fornece os serviços solicitados ao cliente
•  ex: servidor web envia a página web solicitada,
servidor de e-mail envia as mensagens, etc.
•  um host pode atuar como cliente ou servidor
aplicação
transporte
rede
enlace
física
Interfaces de Programação (APIs)
API: application programming
interface
•  define a interface entre as
camadas de aplicação e
transporte
•  socket: Internet API
–  dois processos se comunicam
enviando dados para o socket
e lendo dados do socket,
como se fosse um descritor
de arquivo
•  Como um processo identifica o
outro processo com o qual ele
deseja se comunicar?
–  End. IP 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
–  binder – informa o “endereço”
de um serviço, a partir de um
nome descritivo
3
16/01/13
Requisitos das Aplicações
Confiabilidade
•  algumas aplicações (aúdio e vídeo)
podem tolerar alguma perda de
dados
•  outras aplicações (transferência
de arquivos, telnet, web) exigem
transferência de dados 100%
confiável
Temporização
•  algumas aplicações (telefonia
na Internet, jogos interativos) exigem baixos atraso e
jitter para operar
Largura de Banda
•  algumas aplicações (multimídia)
impõem um limiar inferior de
banda para funcionar
(aplicações inelásticas)
•  outras aplicações (aplicações
elásticas: ftp, correio, web)
melhoram quando a banda
disponível aumenta, mas podem
operar com um valor muito
baixo
Requisitos de Aplicações Comuns
Perdas
Banda
Sensível ao Atraso
transf. arquivos
e-mail
páginas web
A/V tempo real
sem perdas
sem perdas
sem perdas
tolerante
não
não
não
sim, décimos de seg
A/V armazenado
jogos interativos
e-business
tolerante
tolerante
sem perdas
elástica
elástica
elástica
aúdio: 5Kb-1Mb
vídeo:10Kb-5Mb
idem
1Kb-10Kb
elástica
Applicação
sim, segundos
sim, décimos de seg
sim
4
16/01/13
Serviços de Transporte da Internet
Serviço TCP:
Serviço UDP:
•  orientado a 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 orientado a conexão
•  transferência de dados não
confiável entre os processos
transmissor e receptor
•  não oferece: estabelecimento
de conexão, confiabilidade,
controle de fluxo e de congestionamento (responsabilidade
das aplicações)
•  ambos não oferecem: garantias
de temporização e de taxa de
transmissão (banda) mínima
Aplicações vs. Protocolos de Transporte
Aplicação
e-mail
terminal remoto
Web
transf. arquivos
streaming multimedia
serviço 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 proprietário
(ex: RealNetworks)
NFS
RTP ou proprietário
(ex: Vocaltec)
TCP
TCP
TCP
TCP
TCP ou UDP
TCP ou UDP
tipicamente UDP
5
16/01/13
DNS: Domain Name System
Pessoas: muitos
identificadores
–  RG, nome, passporte
Hosts da Internet, roteadores:
–  endereços IP (32 bits) usados para endereçar
datagramas
–  nomes - usados por
humanos
•  Como relacionar nomes de
hosts com endereços IP?
Domain Name System:
•  base de dados distribuída:
implementado numa hierarquia de
vários servidores de nomes
•  protocolo da camada de aplicação:
hosts, roteadores comunicam-se com
servidores de nomes para resolver
nomes (tradução nome/endereço)
–  função interna da Internet,
implementada como um protocolo
da camada de aplicação
–  complexidade na “borda” da rede
–  outros serviços: aliases de host e
servidor de email, load balancing
•  máquinas Unix: Bind, porta 53, udp
•  RFCs 1034, 1035
Servidores de Nomes DNS
Por que não usar um DNS
centralizado?
• 
• 
• 
• 
ponto único de falha
volume de tráfego
base de dados distante
manutenção
Não tem escalabilidade!
Solução distribuída, hierárquica:
nenhum servidor tem todos os
mapeamentos de nomes para
endereços IP
servidor de nomes local:
–  cada empresa/instituição 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 com autoridade:
–  para um computador: sempre
contém o nome e o endereço IP
daquele computador
–  muitos servidores de nomes locais
também são authoritative
6
16/01/13
DNS: Servidores de Nomes Raiz
•  São contactados pelos servidores de nomes locais quando estes não
conseguem resolver um nome
•  Funcionalidades:
–  buscam servidores de nomes com autoridade se o
mapeamento do nome não for conhecido;
–  realizam o mapeamento;
–  retornam 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
k RIPE London
i NORDUnet Stockholm
m WIDE Tokyo
j NSI (TBD) Herndon, VA
e NASA Mt View, CA
f Internet Software C. Palo Alto, CA
Existem 13 servidores de
nomes raiz no mundo
b USC-ISI Marina del Rey, CA
l ICANN Marina del Rey, CA
DNS: exemplo simples
servidor de nomes
raiz
•  host pc01.deinf.ufma.br
quer o endereço IP de
2
5
3
4
xingu.icmc.usp.br
1. contacta seu servidor DNS
local, caetano.deinf.
ufma.br
2. caetano.deinf.ufma.br
contacta o servidor de
nomes raiz, se necessário
3. o servidor de nomes raiz
contata o servidor de nomes
autoritativo, dns.usp.br,
se necessário
servidor de nomes local
caetano.deinf.ufma.br
1
servidor de nomes autoritativo
dns.usp.br
6
computador solicitante
pc01.deinf.ufma.br
xingu.icmc.usp.br
7
16/01/13
DNS: exemplo
servidor de nomes
raiz
Servidor de nomes raiz:
3
7
•  pode não conhecer o
servidor de nomes com
autoridade para um certo
nome
•  pode conhecer apenas o
servidor de nomes intermediário, aquele que deve
ser contactado para
encontrar o servidor de
nomes com autoridade
6
2
servidor de nomes local
servidor de nomes intermediário
dns.usp.br
caetano.deinf.ufma.br
1
4
8
5
servidor de nomes autoritativo
dns.icmc.usp.br
computador solicitante
pc01.deinf.ufma.br
xingu.icmc.usp.br
DNS: consultas iterativas
servidor de nomes
raiz
consulta recursiva:
•  transfere a tarefa de
resolução do nome para o
servidor de nomes
consultado
•  mais mensagens
2
consulta
iterativa
3
4
7
consulta iterativa:
•  servidor contactado
responde com o nome de
outro servidor de nomes
para contato
•  diminui a carga na rede e
nos servidores
servidor de nomes local
caetano.deinf.ufma.br
1
8
servidor de nomes intermediário
dns.usp.br
5
6
servidor de nomes autoritativo
dns.icmc.usp.br
computador solicitante
pc01.deinf.ufma.br
caches DNS:
• 
guarda mapeamentos
recentes
xingu.icmc.usp.br
8
16/01/13
Registros do DNS
DNS: base de dados distribuída que armazena registros de recursos (RR)
formato dos RR: (Name,
•  Type=A
–  name é o nome do computador
–  value é o endereço IP
•  Type=NS
–  name é um domínio (ex: deinf.
ufma.br)
–  value é o endereço IP do
servidor de nomes com
autoridade para este domínio
Value, Type, TTL)
•  Type=CNAME
–  name é um “apelido”
–  value é o nome “canônico” (o nome real)
–  www.deinf.ufma.br é realmente
caetano.deinf.ufma.br
•  Type=MX
–  value é o nome do servidor de correio
associado com name
–  (deinf.ufma.br,caetano.deinf.
ufma.br,MX)
DNS: protocolo e mensagens
protocolo DNS: mensagens de consulta e resposta , ambas com o mesmo
formato
cabeçalho:
•  identificação: número de 16
bits identifica consulta;
resposta usa o mesmo número
•  flags:
–  consulta ou resposta
–  recursão desejada
–  recursão disponível
–  resposta é autoritativa
9
16/01/13
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
FTP – Protocolo de Transferência de
Arquivos
usuário
transferência de arquivos
FTP
FTP
FTP
interface cliente
servidor
de usuário
sistema de
arquivos
local
sistema de
arquivos remoto
•  transferência de arquivos de/para um host remoto
•  modelo cliente servidor:
–  cliente: lado que inicia a transferência (em qualquer sentido)
–  servidor: host remoto
•  FTP: RFC 959 (de 1971)
•  servidor ftp: porta 21
10
16/01/13
ftp: controle separado, conexões
de dados
•  cliente ftp contacta 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 trocados com o
servidor (porta 20); não
persistente
•  servidor ftp mantém o estado:
diretório corrente, autenticação
anterior
TCP conexão de controle
porta 21
cliente
FTP
TCP conexão de dados
porta 20
servidor
FTP
ftp: comandos, respostas
Exemplos de comandos:
•  envio de um texto ASCII
sobre canal de controle
•  USER username
•  PASS password
•  LIST retorna lista de
arquivos no diretório
corrente
•  RETR filename recupera
(obtém) o arquivo
•  STOR filename armazena
o arquivo no host remoto
Códigos de retorno:
•  código de status e
explicação (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
11
16/01/13
Correio Eletrônico
fila de
saída de mensagem
caixa postal
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
•  ex: Eudora, Outlook, mail,
pine …
•  mensagens de entrada e de
saída são armazenadas no
servidor de correio (smtp)
agente
usuário
servidor
de correio
agente
usuário
SMTP
mail
server
SMTP
SMTP
agente
usuário
agente
usuário
servidor
de correio
agente
usuário
agente
usuário
Correio eletrônico: servidores de
correio
agente
usuário
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
ser enviadas
•  protocolo smtp: permite
aos servidores de correio
trocar mensagens entre
eles
–  cliente: servidor de
correio que envia
–  servidor: servidor de
correio que recebe
servidor
de correio
agente
usuário
SMTP
SMTP
SMTP
servidor
de correio
mail
server
agente
usuário
agente
usuário
agente
usuário
agente
usuário
12
16/01/13
Correio Eletrônico: SMTP [RFC 821]
•  SMTP usa TCP para transferência confiável de mensagens de
correio do cliente ao servidor, pela porta 25
•  transferência direta: servidor de origem envia para o servidor
de destino; não usa servidores intermediários
•  na sua forma padrão, as mensagens SMTP devem ser formatadas em código ASCII de 7 bits (legado dos primórdios da
Internet) --> codificação/decodificação
•  três fases de transferência:
–  apresentação: troca de endereços de origem/destino
–  transferência de mensagens (via TCP); conexões
persistentes
–  encerramento
•  interação comando/resposta
–  comandos: texto ASCII
–  resposta: código de status e frase de explicação
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
13
16/01/13
SMTP: comentários
•  SMTP usa 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 nas mensagens (ex.,
CRLF.CRLF). Dados binários
têm que ser codificados em
ASCII
•  CRLF.CRLF indica o final da
mensagem
Comparação com http:
•  http: pull (recuperação)
•  smtp: push (envio)
•  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
“multipart”
Formato das Mensagens
SMTP: protocolo para
troca de mensagens
RFC 822: define formato
das mensagens tipo
texto.
•  linhas de cabeçalho:
header
linha
em branco
body
–  To:
–  From:
–  Subject:
•  corpo:
–  a mensagem em
ASCII, somente com
caracteres
14
16/01/13
Formato das Mensagens: extensões multimídia
•  MIME: Multipurpose Internet Mail Extensions – para transmitir textos que não estão no padrão ASCII. Ex: imagens,
outro idioma que não o Inglês
•  linhas adicionais no cabeçalho declaram o tipo de conteúdo
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
versão MIME
método usado para
codificação (RFC 2045)
dados multimídia:
tipo, subtipo,
parâmetro
base64 encoded data .....
.........................
......base64 encoded data
.
dados codificados
terminador
Tipos MIME
(RFC 2046)
Content-Type: type/subtype; parameters
Text
Video
•  text/plain, text/html
•  text/plain;
charset=“ISO-8859-1” (lín
guas latinas)
•  video/mpeg, video/
quicktime
Image
•  image/jpeg, image/gif
Audio
•  audio/basic (8 bits),
audio/32kadpcm (32 Kbps)
Application
•  dados que precisam ser
processados por uma aplicação
antes de serem apresentados
•  application/msword,
application/octet-stream
(dados binários genéricos)
15
16/01/13
Tipo Multipart
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=98766789
delimitador
--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--
Protocolos de acesso a correio
SMTP
SMTP
agente
usuário
servidor de
correio de origem
POP3 ou
IMAP
agente
usuário
servidor de
correio de destino
•  SMTP: entrega e armazena mensagens no servidor de destino
•  Protocolo de acesso: recupera mensagens do servidor de correio
–  POP: Post Office Protocol [RFC 1939]
•  autorização (agente <--> servidor), download, atualização
–  IMAP: Internet Mail Access Protocol [RFC 2060]
•  maiores recursos (mais complexo)
•  manipulação de caixas postais remotas (criação de pastas,
leitura parcial de mensagens, busca, etc.)
–  HTTP: Hotmail , Yahoo, BOL (http: browser <--> servidor)
16
16/01/13
Protocolo POP3
fase de autorização
•  comandos do cliente:
–  user: nome do usuário
–  pass: senha
•  respostas possíveis do servidor:
–  +OK
–  -ERR
fase de transação, cliente:
•  list: lista mensagens e tamanhos
•  retr: recupera mensagem pelo
número
•  dele: apaga
•  quit
•  POP3 não mantém estado entre
sessões dos clientes
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:
C:
C:
S:
S:
C:
C:
S:
list
1 498
2 912
.
retr 1
<message 1 contents>
.
dele 1
retr 2
<message 1 contents>
.
dele 2
quit
+OK POP3 server signing off
on
World Wide Web
•  Permite o acesso a documentos interligados,
espalhados pela Internet
•  Tornou-se tão popular que
se confunde com a própria
Internet
•  1945 - Vannevar Bush:
conceito de hipertexto
•  1965 - Ted Nelson:
cunhou o termo
•  1989 - Tim Berners-Lee:
no CERN, criou a Web e o
protocolo http
•  1994 – Marc Andreesen:
desenvolveu o Mosaic; links
para diferentes mídias
•  Em 1995, a Web tornou-se
responsável pela maior parte
do tráfego na Internet, porém
foi ultrapassada pelas redes
P2P em 2004
•  Sistema hipermídia em escala
global
•  Sistema de nomenclatura:
URLs
•  Interações entre os componentes: paradigma C/S
•  A Web funciona sobre dois
padrões principais:
–  Linguagem HTML
–  Protocolo HTTP
17
16/01/13
Sistema de Nomenclatura – URLs
•  URLs permitem que os usuários acessem páginas web e outros
serviços como FTP, telnet e notícias, a partir do próprio
navegador:
– 
– 
– 
– 
– 
– 
– 
http - Hipertexto (HTML)
ftp - Transferência de arquivos
file - Acesso a arquivos locais
news - Grupos de notícias e artigos
gopher - recuperar informações pelo gopher
mailto - Enviar e-mail
telnet - Login remoto
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
•  HTTP 1.0: RFC 1945
•  HTTP 1.1: RFC 2616
htt
p
PC com
Explorer
htt
p
req
ues
t
res
pon
se
st
ue
eq
r
p
nse
po
htt
s
e
r
tp
ht
Servidor
com
Apache
web server
Mac com
Navigator
18
16/01/13
Protocolo HTTP
http: protocolo de
aplicação sobre TCP
•  cliente inicia conexão TCP
(cria socket) com o servidor
na porta 80
•  servidor aceita uma conexão
TCP do cliente
•  mensagens http 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ções sobre os pedidos
dos clientes
Protocolos que mantêm informações
de estado são complexos:
•  necessidade de organizar informações passadas
•  se ocorrer uma falha, as informações podem ser perdidas ou
gerar inconsistências entre o
cliente e o servidor
•  baixa escalabilidade
Exemplo de Operação HTTP (1)
Usuário digita a URL: www.deinf.ufma.br/prof/index.html
(referencia 10 imagens)
1a. cliente http inicia conexão
TCP com o servidor http
(processo) em www.deinf.
ufma.br, pela porta 80
(default)
2. cliente http client envia http
request, contendo a URL,
ao servidor web
1b. servidor http no host
www.deinf.ufma.br, aguardando pela
conexão TCP na porta 80, aceita a
conexão, notificando o cliente
3. servidor http recebe mensagem
de pedido, recupera o objeto e envia
uma http response, contendo o
objeto solicitado, ao cliente
tempo
19
16/01/13
Exemplo (2)
4. servidor http fecha conexão TCP
(http 1.0)
tempo
5. cliente http recebe mensagem
de resposta contendo o arquivo
html e o apresenta ao usuário
5a. ao analisar o arquivo html,
cliente encontra 10 objetos jpeg
referenciados
6. cliente repete Passos 1-5 para
cada um dos 10 objetos jpeg
Conexões persistentes e nãopersistentes
Não-persistente
•  http/1.0: servidor analisa
pedido, envia resposta e fecha
a conexão TCP
•  2 RTTs para obter um objeto:
–  estabelecimento de conexão
TCP
–  solicitação e transferência
do objeto
•  cada transferência sofre ainda
por causa do mecanismo de
slow-start do TCP
•  muitos browsers abrem várias
conexões paralelas
Persistente
•  modo default para http/1.1
•  na mesma conexão TCP, são
recuperados vários objetos
•  o cliente solicita todos os
objetos referenciados, tão
logo ele receba a página HTML
básica (pipelining)
•  poucos RTTs, menos slow
start
20
16/01/13
Cliente-servidor na Web
(duas camadas)
Cliente-servidor na Web
(três camadas)
21
16/01/13
HTTP request: formato geral
<método> <id. recurso> <versão HTTP> <crlf>
[<Header>: <valor>] <crlf>
...
[<Header>: <valor>] <crlf>
<crlf>
[Entity body]
Mensagens HTTP: request
•  Dois tipos de mensagens HTTP: request, response
•  Formato ASCII (legível para humanos)
linha de pedido
(comandos GET,
POST,HEAD )
GET /dir/page.html HTTP/1.0
User-agent: Mozilla/4.0
Accept: text/html, image/gif, image/jpeg
linhas de Accept-language: fr
cabeçalho
(linha em branco)
Carriage return,
line feed
Corpo da mensagem
indica fim da mensagem
22
16/01/13
HTTP response: formato geral
<versão HTTP> <cód. status> [<explicação>] <crlf>
[<Header>: <valor>] <crlf>
...
[<Header>: <valor>] <crlf>
<crlf>
[Entity body]
Mensagens HTTP: response
linha de status
(protocolo
código de status
frase de status)
linhas de
cabeçalho
dados, p.ex.,
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
dados dados dados dados ...
23
16/01/13
Métodos HTTP
•  GET – Solicita o objeto identificado pela URL
•  HEAD – Obtém informações sobre o objeto sem que o mesmo
seja retornado ao cliente (depuração)
•  POST – Envia informações adicionais ao servidor web (p.ex.,
dados de formulários)
•  OPTIONS – Obtém opções de comunicação disponíveis ou os
requisitos associados ao objeto solicitado
•  PUT – Cria ou modifica um objeto no servidor web
•  DELETE – Remove um objeto do servidor web
•  TRACE – Envia mensagem de teste (loopback) ao servidor
•  CONNECT – Reservado para comunicação com servidores
proxy
Códigos de Status
•  1xx – Informational
•  2xx – Success
–  200 OK
•  3xx – Redirection
–  301 Moved Permanently
–  304 Not Modified
–  307 Temporary Redirect
•  4xx – Client Error
–  400 Bad Request
–  401 Unauthorized
–  404 Not Found
•  5xx – Server Error
–  503 Service Unavailable
–  505 HTTP Version Not
Supported
24
16/01/13
Cookies
•  Gerados e lembrados pelo
servidor (RFC 2109), usados
mais tarde para:
–  autenticação
–  lembrar preferências
dos usuários ou escolhas
prévias
•  Servidor envia “cookie” ao
cliente na resposta HTTP
cliente
http request msg
http response +
Set-cookie: #
http request msg
Cookie: #
http response msg
Set-cookie: 1678453
http request msg
•  Cliente apresenta “cookie”
em pedidos posteriores
Cookie: 1678453
servidor
Cookie: #
usual http response msg
ação
específica
do cookie
ação
específica
do cookie
ação
específica
do cookie
GET Condicional: caches no
cliente
•  servidor: só envia o objeto
solicitado se sua versão for
mais atual que a do cliente
•  cliente: especifica, na requisição HTTP, a data da versão
armazenada no cache local:
If-Modified-Since: <date>
•  servidor: resposta não contém
o objeto se a cópia do cliente
estiver atualizada:
304 Not Modified
servidor
cliente
http request
If-Modified-Since:
<date>
http response
objeto
não
modificado
HTTP/1.0
304 Not Modified
http request
If-Modified-Since:
<date>
http response
objeto
modificado
HTTP/1.1 200 OK
<data>
25
16/01/13
Web Caches
Objetivo: atender o cliente sem envolver o servidor Web,
detentor da informação original
•  usuário configura o
browser:
–  acesso à Web é feito
através de um servidor
proxy
•  cliente envia todos os
pedidos http para o proxy:
–  se o objeto existe no
cache, o proxy retorna o
objeto
–  senão, o proxy solicita o
objeto ao servidor original
e o envia ao cliente
htt
p
cliente http
req
ues
t
servidor
original
Proxy
server
res
pon
se
st
e
u
eq
pr
nse
t
t
po
h
s
e
r
tp
ht
t
ues
req
e
p
htt
ons
esp
r
p
htt
cliente
Por que Web Caching?
servidores
originais
•  armazenamento fica “perto”
do cliente (p.ex., na mesma
Internet
rede)
pública
•  menor tempo de resposta
•  reduz o tráfego para
/media/dados/documentos/Disciplinas/
servidores distantes:
enlace de acesso
Grad/Redes II/aulas/05_aplicacao.ppt
–  links externos podem ser
caros e facilmente
congestionáveis
•  caches hierárquicos e
cooperativos (NLANR)
•  ICP (RFC 2186)
–  Internet Caching Protocol,
suportado pelo Squid
1,5 Mbps
rede
institucional
10 Mbps LAN
cache
institucional
26
16/01/13
Compartilhamento dede
arquivos
P2P
Compartilhamento
Arquivos
P2P
Exemplo
• Alice executa a aplicação cliente P2P em seu notebook
• intermitentemente, conecta-se à Internet; obtém novos endereços IP para
cada conexão
• pede por “Hey Jude”
• a aplicação exibe outros pares que possuem uma cópia de Hey Jude
• Alice escolhe um dos pares, Bob
• o arquivo é copiado do PC de Bob para o notebook de Alice: HTTP
• enquanto Alice faz o download, outros usuários fazem upload de Alice
• o par de Alice é tanto um cliente Web como um servidor Web transiente
Todos os pares são servidores = altamente escaláveis!
2 - 53
P2P: diretório centralizado
P2P: Diretório centralizado
Projeto original “Napster”
1)  Quando um par se conecta, ele
informa ao servidor central:
• Endereço IP
• Conteúdo
2) Alice procura por “Hey Jude”
3) Alice requisita o arquivo de Bob
2 - 54
27
16/01/13
P2P: problemas com
diretório centralizado
Desvantagens
do diretório
centralizado
• Ponto único de falhas
• Gargalo de desempenho
• Infração de copyright
Transferência de arquivo é descentralizada, mas a localização de
conteúdo é altamente centralizada
2 - 55
Query flooding:
Gnutella Inundação
de consultas
Gnutella
• Totalmente distribuído
• Sem servidor central
• Protocolo de domínio público
• Muitos clientes Gnutella implementando o protocolo
Rede de cobertura: grafo
• Aresta entre o par X e o Y se houver uma conexão TCP
• Todos os pares ativos e arestas estão na rede de sobreposição
• aresta não é um enlace físico
• Um determinado par será tipicamente conectado a <10 vizinhos na rede de
sobreposição
2 - 56
28
16/01/13
Gnutella: protocolo
Protocolo Gnutella
•  • Mensagem de consulta
(Query) é enviada pelas
conexões TCP existentes
• Os pares encaminham
a mensagem de consulta
• QueryHit (acerto)
é enviado pelo
caminho reverso
•  Download do arquivo é feito via
HTTP
Escalabilidade: flooding de alcance limitado (num. hops < 7)
2 - 57
Gnutella: conectando pares
Protocolo Gnutella
1. Para se conectar, o par X precisa encontrar algum outro par na
rede Gnutella: utiliza a lista de pares candidatos
2. X, seqüencialmente, tenta fazer conexão TCP com os pares da
lista até estabelecer conexão com Y
3. X envia mensagem de Ping para Y; Y encaminha a mensagem de
Ping
4. Todos os pares que recebem a mensagem de Ping respondem com
mensagens de Pong
5. X recebe várias mensagens de Pong. Ele pode então estabelecer
conexões TCP adicionais
2 - 58
29
16/01/13
Explorando heterogeneidade: KaZaA
KaZaA
• Cada par é ou um líder de grupo
ou está atribuído a um líder de
grupo (supernó/ultranó)
• Conexão TCP entre o par e
seu líder de grupo
• Conexões TCP entre alguns
pares de líderes de grupo (rede
sobreposta)
• O líder de grupo acompanha o
conteúdo em todos os seus
“discípulos”
2 - 59
KaZaA
KaZaA
• Cada arquivo possui um hash e um descritor
• O cliente envia a consulta de palavra-chave para o seu líder de grupo
•  O líder de grupo responde com os acertos:
• Para cada acerto: metadados do arquivo, hash, endereço IP
• Se o líder de grupo encaminha a consulta para outros líderes de grupo,
eles também respondem com os acertos
•  O cliente então seleciona os arquivos para download
• Requisições HTTP usando hash como identificador são enviadas aos
pares que contêm o arquivo desejado
2 - 60
30
16/01/13
Artifícios do KaZaA
Artifícios do KaZaA
• Limitações em transferências simultâneas
• Requisita enfileiramento de requisições
• Incentiva prioridades (> para peers que contribuem com arquivos
para a rede)
• Realiza downloads em paralelo
2 - 61
31