REDES DE COMPUTADORES
Prof. Jorge H. B. Casagrande
Camada de Aplicação
Prof. Jorge H. B. Casagrande
[email protected]
Slides adaptados de J. Kurose & K. Ross
(http://www.aw-bc.com/kurose-ross/),
e J. A. Suruagy
(http://www.nuperc.unifacs.br/suruagy/redes/index.html)
2
Curso de Capacitação Intelbras
Camada
Aplicação
RedesdeComputadores
Maio 2007
Camada de
Aplicação
Objetivos:
 aspectos conceituais
dos protocolos de
aplicação em redes



modelos de serviço da
camada de transporte
paradigma cliente
servidor
paradigma peer-topeer
 Estudo de alguns protocolos
populares da camada de
aplicação:



HTTP
FTP
SMTP/ POP3/ IMAP
Camada de Aplicação
3
Algumas
aplicações de
rede
 E-mail
 Web
 Voz sobre IP
 Instant messaging
 Vídeo conferência em
 Login remoto
 Compartilhamento de
arquivos P2P
 Jogos em rede multiusuários
 Vídeo-clipes armazenados
tempo real
 Computação paralela em
larga escala
 ...
Camada de Aplicação
4
O que é uma
aplicação de rede
Programas que



Executam em diferentes sistemas
finais
Comunicam-se através da rede
p.ex., Web: servidor Web se
comunica com o navegador
aplicação
transporte
rede
enlace
física
Programas não relacionados ao
núcleo da rede


Dispositivos do núcleo da rede não
executam aplicações de usuários
Aplicações nos sistemas finais
permite rápido desenvolvimento e
disseminação
aplicação
transporte
rede
enlace
física
Camada de Aplicação
aplicação
transporte
rede
enlace
física
5
Arquiteturas das
aplicações
 Cliente-servidor
 Par-a-par (peer-to-peer) (P2P)
Camada de Aplicação
6
Arquitetura
cliente-servidor
Servidor:
 Sempre ligado
 Endereço IP permanente
Cliente:
 Comunica-se com o servidor
 Pode estar conectado
intermitentemente
 Pode ter endereços IP
dinâmicos
 Não se comunica diretamente
com outros clientes
Camada de Aplicação
7
Arquitetura P2P
 Não há servidor sempre
ligado
 Sistemas finais arbitrários se
comunicam diretamente
 Pares estão conectados
intermitentemente e mudam
endereços IP
 Exemplo: Gnutella
Altamente escalável
Porém, difícil de gerenciar
Camada de Aplicação
8
Híbrido de
cliente-servidor e
P2P
Napster
 Transferência de arquivos P2P
 Busca de arquivos centralizada:
• Pares registram conteúdo no servidor central
• Pares consultam o mesmo servidor central para
localizar conteúdo
Instant messaging
 Conversa entre usuários P2P
 Localização e detecção de presença centralizadas:
• Usuários registram o seu endereço IP junto ao
servidor central quando ficam online
• Usuários consultam o servidor central para encontrar
endereços IP dos contatos
Camada de Aplicação
9
Comunicação de
processos
Processo: programa que executa num
hospedeiro

processos no mesmo hospedeiro Processo cliente: processo que inicia a
comunicação
se comunicam usando comunicação
Processo servidor: processo que
entre processos definida pelo
espera para ser contatado
sistema operacional (SO)
 processos em hospedeiros
distintos se comunicam trocando
mensagens através da rede
 Nota: aplicações com
arquiteturas P2P possuem
processos clientes e processos
servidores
Camada de Aplicação
10
Sockets
 Os processos enviam/ recebem
mensagens para/dos seus
sockets
 Um socket é análogo a uma
porta


Processo transmissor envia a
mensagem através da porta
O processo transmissor
assume a existência da infraestrutura de transporte no
outro lado da porta que faz
com que a mensagem chegue
ao socket do processo
receptor
host ou
servidor
host ou
servidor
processo
controlado pelo
desenvolvedor da
aplicação
processo
socket
socket
TCP com
buffers,
variáveis
Internet
TCP com
buffers,
variáveis
controlado
pelo SO
Camada de Aplicação
11
Endereçando os
processos
 Para que um processo receba
mensagens, ele deve possuir um
identificador
 Cada host possui um endereço
IP único de 32 bits
 Pergunta: O endereço IP do
host no qual o processo está
sendo executado é suficiente
para identificar o processo?
 Resposta: Não, muitos
processos podem estar
executando no mesmo host.
 O identificador inclui tanto o
endereço IP quanto os
números das portas
associadas com o processo
no host.
 Exemplo de números de
portas:


Servidor HTTP: 80
Servidor de Correio: 25
Camada de Aplicação
12
Os protocolos da
camada de aplicação
definem
 Tipos de mensagens
trocadas, ex. mensagens de
pedido e resposta
 Sintaxe dos tipos das
mensagens: campos
presentes nas mensagens e
como são identificados
 Semântica dos campos, i.e.,
significado da informação
nos campos
 Regras para quando os
processos enviam e
respondem às mensagens
Protocolos de domínio
público:
 definidos em RFCs
 Permitem a interoperação
 ex, HTTP e SMTP
Protocolos proprietários:
 Ex., KaZaA
Camada de Aplicação
13
De que serviço de transporte
uma aplicação precisa?
Perda de dados
 algumas apls (p.ex. áudio)
podem tolerar algumas
perdas
 outras (p.ex., transf. de
arquivos, telnet) requerem
transferência 100% confiável
Temporização
 algumas apls (p.ex., telefonia
Internet, jogos interativos)
requerem baixo retardo para
serem “viáveis”
Largura de banda
 algumas apls (p.ex.,
multimídia) requerem
quantia mínima de banda
para serem “viáveis”
 outras apls (“apls elásticas”)
conseguem usar qq quantia
de banda disponível
Camada de Aplicação
14
Requisitos do serviço de
transporte de apls comuns
Aplicação
transferência de arqs
correio
documentos WWW
áudio/vídeo de
tempo real
áudio/vídeo gravado
jogos interativos
apls financeiras
Perdas
Banda
sem perdas
sem perdas
sem perdas
tolerante
elástica
elástica
elástica
áudio: 5Kb-1Mb
vídeo:10Kb-5Mb
como anterior
> alguns Kbps
elástica
tolerante
tolerante
sem perdas
Camada de Aplicação
Sensibilidade
temporal
não
não
não
sim, 100’s mseg
sim, alguns segs
sim, 100’s mseg
sim e não
15
Serviços providos por
protocolos de transporte
Internet
Serviço TCP:





orientado a conexão:
inicialização requerida entre
cliente e servidor
transporte confiável entre
processos remetente e
receptor
controle de fluxo: remetente
não vai “afogar” receptor
controle de congestionamento:
estrangular remetente quando
a rede estiver carregada
não provê: garantias temporais
ou de banda mínima
Serviço UDP:
 transferência de dados não
confiável entre processos
remetente e receptor
 não provê: estabelecimento
da conexão, confiabilidade,
controle de fluxo, controle de
congestionamento, garantias
temporais ou de banda mínima
Camada de Aplicação
16
Apls Internet: seus
protocolos e seus protocolos
de transporte
Aplicação
correio eletrônico
acesso terminal remoto
WWW
transferência de arquivos
streaming multimídia
telefonia Internet
Protocolo da
camada de apl
Protocolo de
transporte usado
SMTP [RFC 2821]
telnet [RFC 854]
HTTP [RFC 2616]
ftp [RFC 959]
proprietário
(p.ex. RealNetworks)
proprietário
(p.ex., Dialpad)
TCP
TCP
TCP
TCP
TCP ou UDP
Camada de Aplicação
tipicamente UDP
17
Web e HTTP





Páginas Web consistem de objetos
Objeto pode ser um arquivo HTML, uma imagem JPEG, um
applet Java, um arquivo de áudio,…
Páginas Web consistem de um arquivo HTML base que
inclui vários objetos referenciados
Cada objeto é endereçável por uma URL
Exemplo de URL:
www.someschool.edu/someDept/pic.gif
nome do hospedeiro
nome do caminho
Camada de Aplicação
18
Protocolo HTTP
HTTP: hypertext transfer
protocol
 protocolo da camada de
aplicação da Web
 modelo cliente/servidor
 cliente: browser que pede,
recebe, “visualiza” objetos
Web
 servidor: servidor Web
envia objetos em resposta
a pedidos
 HTTP 1.0: RFC 1945
 HTTP 1.1: RFC 2068
PC executa
Explorer
ped
id
res
po
oh
sta
ttp
h tt
p
ttp
h
ido
tp Servidor
d
t
e
h
p
executando
sta
o
p
servidor
res
WWW
do NCSA
Mac executa
Navigator
Camada de Aplicação
19
Mais sobre o
protocolo HTTP
Usa serviço de transporte
TCP:
 cliente inicia conexão TCP
(cria socket) ao servidor,
porta 80
 servidor aceita conexão TCP
do cliente
 mensagens HTTP (mensagens
do protocolo da camada de
apl) trocadas entre browser
(cliente HTTP) e servidor
Web (servidor HTTP)
 encerra conexão TCP
HTTP é “sem estado”
 servidor não mantém
informação sobre
pedidos anteriores do
cliente
Camada de Aplicação
20
Conexões HTTP
HTTP não persistente
 No máximo um objeto é
enviado numa conexão TCP
 HTTP/1.0 usa o HTTP não
persistente
HTTP persistente
 Múltiplos objetos podem
ser enviados sobre uma
única conexão TCP entre
cliente e servidor
 HTTP/1.1 usa conexões
persistentes no seu modo
default
Camada de Aplicação
21
Formato de mensagem
HTTP: pedido
 Dois tipos de mensagem HTTP:
pedido, resposta
 mensagem de pedido HTTP:

ASCII (formato legível por pessoas)
linha do pedido
(comandos GET,
POST, HEAD)
linhas do
cabeçalho
Carriage return,
line feed
indicam fim
de mensagem
GET /somedir/page.html HTTP/1.0
Host: www.someschool.edu
User-agent: Mozilla/4.0
Connection: close
Accept-language:fr
(carriage return (CR), line feed(LF) adicionais)
Camada de Aplicação
22
Mensagem de pedido
HTTP: formato geral
Camada de Aplicação
23
Formato de mensagem
HTTP: resposta
linha de status
(protocolo,
código de status,
frase de status)
HTTP/1.1 200 OK
Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
linhas de
Last-Modified: Mon, 22 Jun 1998 …...
cabeçalho
Content-Length: 6821
Content-Type: text/html
dados, p.ex.,
arquivo html
solicitado
dados dados dados dados ...
Camada de Aplicação
24
códigos de status da
resposta HTTP
Na primeira linha da mensagem de resposta
servidor->cliente. Alguns códigos típicos:
200 OK

sucesso, objeto pedido segue mais adiante nesta mensagem
301 Moved Permanently

objeto pedido mudou de lugar, nova localização especificado mais
adiante nesta mensagem (Location:)
400 Bad Request

mensagem de pedido não entendida pelo servidor
404 Not Found

documento pedido não se encontra neste servidor
505 HTTP Version Not Supported

versão de http do pedido não usada por este servidor
Camada de Aplicação
25
Cache Web (servidor
proxy)
Meta: atender pedido do cliente sem envolver servidor de origem
 usuário configura browser:
acessos Web via proxy
 cliente envia todos pedidos
HTTP ao proxy


se objeto no cache do
proxy, este o devolve
imediatamente na resposta
HTTP
senão, solicita objeto do
servidor de origem, depois
devolve resposta HTTP ao
cliente
Servidor
de origem
cliente
ped
id
Servidor
proxy
oh
tt p
s ta
htt
p
ttp
h
ido
ttp
d
h
e
p
sta
o
p
res
res
po
cliente
Camada de Aplicação
ttp
h
o
ttp
did
h
e
p
sta
o
p
res
Servidor
de origem
26
FTP: o protocolo de
transferência de
arquivos
usuário
na
estação
Interface cliente
do usuário FTP
FTP
transferência
do arquivo
sistema de
arquivos
local
FTP
servidor
sistema de
arquivos
remoto
 transferir arquivo de/para hospedeiro remoto
 modelo cliente/servidor
cliente: lado que inicia transferência (pode ser de ou para o
sistema remoto)
 servidor: hospedeiro remoto
 ftp: RFC 959
 servidor ftp: porta 21

Camada de Aplicação
27
FTP: conexões separadas p/
controle, dados





cliente FTP contata servidor FTP
na porta 21, especificando o TCP
como protocolo de transporte
O cliente obtém autorização
através da conexão de controle
O cliente consulta o diretório
remoto enviando comandos
através da conexão de controle
Quando o servidor recebe um
comando para a transferência de
um arquivo, ele abre uma conexão
de dados TCP para o cliente
Após a transmissão de um arquivo
o servidor fecha a conexão
conexão de controle
TCP, porta 21
cliente
FTP
conexão de dados
TCP, porta 20
servidor
FTP

O servidor abre uma segunda conexão
TCP para transferir outro arquivo

Conexão de controle: “fora da faixa”

Servidor FTP mantém o “estado”:
diretório atual, autenticação anterior
Camada de Aplicação
28
FTP: comandos,
respostas
Comandos típicos:
Códigos de retorno típicos
 enviados em texto ASCII pelo
canal de controle
 USER nome
 PASS senha
 código e frase de status (como para

 LIST devolve lista de arquivos
no diretório atual
 RETR arquivo recupera (lê)
arquivo remoto
 STOR arquivo armazena
(escreve) arquivo no hospedeiro
remoto



http)
331 Username OK, password
required
125 data connection already
open; transfer starting
425 Can’t open data
connection
452 Error writing file
Camada de Aplicação
29
Correio Eletrônico
Três grandes componentes:
 agentes de usuário (UA)
 servidores de correio
 simple mail transfer protocol: SMTP
Agente de Usuário
 “leitor de correio”
 compor, editar, ler mensagens de
correio
 p.ex., Eudora, Outlook, elm, Netscape
Messenger
 mensagens de saída e chegando são
armazenadas no servidor
servidor
de correio
agente
de
usuário
SMTP
SMTP
SMTP
servidor
de correio
agente
de
usuário
Camada de Aplicação
fila de
mensagens
de saída
caixa de
correio do usuário
agente
de
usuário
servidor
de correio
agente
de
usuário
agente
de
usuário
agente
de
usuário
30
Servidores de correio
Servidores de correio
 caixa de correio contém
mensagens de chegada (ainda
não lidas) p/ usuário
 fila de mensagens contém
mensagens de saída (a serem
enviadas)
 protocolo SMTP entre
servidores de correio para
transferir mensagens de
correio
 cliente: servidor de correio
que envia
 “servidor”: servidor de
correio que recebe
servidor
de correio
agente
de
usuário
SMTP
SMTP
SMTP
servidor
de correio
agente
de
usuário
Camada de Aplicação
agente
de
usuário
servidor
de correio
agente
de
usuário
agente
de
usuário
31
Correio Eletrônico:
SMTP [RFC 2821]
 usa TCP para a transferência confiável de msgs do
correio do cliente ao servidor, porta 25
 transferência direta: servidor remetente ao servidor
receptor
 três fases da transferência
 handshaking (cumprimento)
 transferência das mensagens
 encerramento
 interação comando/resposta
 comandos: texto ASCII
 resposta: código e frase de status
Camada de Aplicação
32
Protocolos de acesso ao
correio
agente
de
usuário
SMTP
SMTP
servidor de correio
do remetente
POP3 ou
IMAP
agente
de
usuário
servidor de correio
do receptor
 SMTP: entrega/armazenamento no servidor do receptor
 protocolo de acesso ao correio: recupera do servidor



POP: Post Office Protocol [RFC 1939]
• autorização (agente <-->servidor) e transferência
IMAP: Internet Mail Access Protocol [RFC 1730]
• mais comandos (mais complexo)
• manuseio de msgs armazenadas no servidor
HTTP: Hotmail , Yahoo! Mail, Webmail, etc.
Camada de Aplicação
33
DNS: Domain Name System
Pessoas: muitos
identificadores:
•
Domain Name System:
•
CPF, nome, no. da
Identidade
hospedeiros, roteadores
Internet :
•
•
endereço IP (32 bit) - usado
p/ endereçar datagramas
“nome”, ex.,
hendrix.sj.cefetsc.edu.br - usado
por gente
P: como mapear entre nome e
endereço IP?
•
base de dados distribuída
implementada na hierarquia de muitos
servidores de nomes
protocolo de camada de aplicação
permite que hospedeiros, roteadores,
servidores de nomes se comuniquem
para resolver nomes (tradução
endereço/nome)
• nota: função imprescindível da
Internet implementada como
protocolo de camada de aplicação
• complexidade na borda da rede
Camada de Aplicação
34
DNS
• Roda sobre UDP e usa a
porta 53
• Especificado nas RFCs
1034 e 1035 e atualizado
em outras RFCs.
• Outros serviços:
• apelidos para hospedeiros
(aliasing)
• apelido para o servidor de
mails
• distribuição da carga
Camada de Aplicação
35
Servidores de nomes DNS
Por que não centralizar o DNS?• Nenhum servidor mantém todos os
mapeamento nome-para-endereço
• ponto único de falha
IP
• volume de tráfego
servidor de nomes local:
• base de dados centralizada e
• cada provedor, empresa tem servidor
distante
de nomes local (default)
• pedido DNS de hospedeiro vai
• manutenção (da BD)
primeiro ao servidor de nomes local
Não é escalável!
servidor de nomes oficial:
•
•
p/ hospedeiro: guarda nome, endereço
IP dele
pode realizar tradução nome/endereço
para este nome
Camada de Aplicação
36
DNS: Servidores raiz
•
•
procurado por servidor local que não consegue resolver o nome
servidor raiz:
• procura servidor oficial se mapeamento desconhecido
• obtém tradução
• devolve mapeamento ao servidor 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
13 servidores de
nome raiz em
todo o mundo
b USC-ISI Marina del Rey, CA
l ICANN Marina del Rey, CA
Camada de Aplicação
37
Exemplo simples do DNS
hospedeiro
servidor de
nomes raiz
2
jagger.sj.cefetsc.edu.br
3
5
requer endereço IP de
4
www.cs.columbia.edu
1. Contata servidor DNS local,
hendrix.sj.cefetsc.edu.br
2. hendrix.sj.cefetsc.edu.br
contata servidor raiz, se
necessário
3. Servidor raiz contata servidor
oficial cs.columbia.edu, se
necessário
servidor local
servidor oficial
hendrix.sj.cefetsc.edu.br
cs.columbia.edu
1
6
solicitante
jagger.sj.cefetsc.edu.br
Camada de Aplicação
www.cs.columbia.edu
38
Exemplo de DNS
servidor de
nomes raiz
Servidor raiz:
•
•
6
2
pode não conhecer o
servidor de nomes oficial
pode conhecer servidor
de nomes intermediário:
a quem contatar para
descobrir o servidor de
nomes oficial
7
servidor local
hendrix.sj.cefetsc.edu.br
1
8
3
servidor intermediário
saell.cc.columbia.edu
4
5
servidor oficial
solicitante
cs.columbia.edu
jagger.sj.cefetsc.edu.br
www.cs.columbia.edu
Camada de Aplicação
39
DNS: consultas interativas
consulta recursiva:
•
•
transfere a
responsabilidade de
resolução do nome para o
servidor de nomes
contatado
carga pesada?
consulta interativa:
•
•
2
consulta
interativa
3
4
7
servidor local
hendrix.sj.cefetsc.edu.br
1
servidor consultado
responde com o nome de
um servidor de contato
“Não conheço este nome,
mas pergunte para esse
servidor”
servidor de
nomes raiz
8
servidor intermediário
saell.cc.columbia.edu
5
6
servidor oficial
solicitante
cs.columbia.edu
jagger.sj.cefetsc.edu.br
Camada de Aplicação
www.cs.columbia.edu
40
DNS: uso de cache, atualização de dados
• uma vez que um servidor qualquer aprende um
mapeamento, ele o coloca numa cache local
• futuras consultas são resolvidas usando dados da
cache
• entradas na cache são sujeitas a temporização
(desaparecem depois de um certo tempo)
ttl = time to live (sobrevida)
• estão sendo projetados pela IETF mecanismos de
atualização/notificação dos dados
•
RFC 2136
•
http://www.ietf.org/html.charters/dnsind-charter.html
Camada de Aplicação
41
Registros DNS
DNS: BD distribuído contendo registros de recursos (RR)
formato RR:
(nome, valor, tipo, sobrevida)
• Tipo=CNAME
• Tipo=A
• nome é nome alternativo
• nome é nome de hospedeiro
(alias) para algum nome
• valor é o seu endereço IP
“canônico” (verdadeiro)
• Tipo=NS
• valor é o nome
• nome é domínio (p.ex. foo.com.br)
canônico
• valor é endereço IP de servidor oficial
de nomes para este domínio
• Tipo=MX
• nome é domínio
• valor é nome do servidor de
correio para este domínio
Camada de Aplicação
42
DNS: protocolo e mensagens
protocolo DNS: mensagens de pedido e resposta, ambas com o mesmo formato de mensagem
cabeçalho de msg
•
•
identificação: ID de 16 bit
para pedido, resposta ao
pedido usa mesmo ID
flags:
• pedido ou resposta
• recursão desejada
• recursão permitida
• resposta é oficial
Camada de Aplicação
43
DNS: protocolo e mensagens
campos de nome, e
de tipo num pedido
RRs em resposta
ao pedido
registros para outros
servidores oficiais
info adicional
“relevante” que
pode ser usada
Camada de Aplicação
44