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