Redes de Computadores 1
Prof. Marcelo Diniz
Fonte: http://wps.aw.com/br_kurose_rede_1/
2a: Camada de Aplicação
1
Capítulo 2: Roteiro
r 2.1 Princípios de
r
r
r
r
aplicações de rede
2.2 A Web e o HTTP
2.3 Transferência de
arquivo: FTP
2.4 Correio Eletrônico
na Internet
2.5 DNS: o serviço de
diretório da Internet
r 2.6 Aplicações P2P
r 2.7 Programação de
sockets com TCP
r 2.8 Programação de
sockets com UDP
r 2.9 Construindo um
servidor Web simples
2a: Camada de Aplicação
2
Capítulo 2: Camada de Aplicação
Metas do capítulo:
r aspectos conceituais
e de implementação
de protocolos de
aplicação em redes
m
m
m
r aprenda sobre protocolos
modelos de serviço da
camada de transporte
paradigma cliente
servidor
paradigma peer-tor
peer
através do estudo de
protocolos populares da
camada de aplicação:
m
m
m
m
HTTP
FTP
SMTP/ POP3/ IMAP
DNS
a programação de
aplicações de rede
m
programação usando a API
de sockets
2a: Camada de Aplicação
3
Algumas aplicações de rede
r Correio eletrônico
r A Web
r Mensagem instantânea
r Login em computador
remoto como Telnet e
SSH
r Compartilhamento de
arquivos P2P
r Jogos multiusuários
em rede
r Videoclipes
armazenados
r Telefonia por IP
r Videoconferência em
r
r
r
r
tempo real
Computação paralela
massiva
?
?
?
2a: Camada de Aplicação
4
Criando uma aplicação de rede
Programas que
m
m
m
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
m
m
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
aplicação
transporte
rede
enlace
física
2a: Camada de Aplicação
5
Capítulo 2: Roteiro
r 2.1 Princípios de
r
r
r
r
aplicações de rede
2.2 A Web e o HTTP
2.3 Transferência de
arquivo: FTP
2.4 Correio Eletrônico
na Internet
2.5 DNS: o serviço de
diretório da Internet
r 2.6 Aplicações P2P
r 2.7 Programação de
sockets com TCP
r 2.8 Programação de
sockets com UDP
r 2.9 Construindo um
servidor Web simples
2a: Camada de Aplicação
6
Arquiteturas das aplicações de
rede
r Cliente-servidor
r Peer-to-peer (P2P)
r Híbrida cliente-servidor/P2P
2a: Camada de Aplicação
7
Arquitetura cliente-servidor
Servidor:
r Sempre ligado
r Endereço IP permanente
r Escalabilidade com server
farms
Cliente:
r Comunica-se com o servidor
r Pode estar conectado
cliente/servidor
intermitentemente
r Pode ter endereços IP
dinâmicos
r Não se comunica diretamente
com outros clientes
2a: Camada de Aplicação
8
Arquitetura P2P pura
r Não há servidor sempre
ligado
r Sistemas finais
arbitrários se
comunicam diretamente
r Pares estão conectados
intermitentemente e
mudam endereços IP
Altamente escalável
Porém, difícil de gerenciar
2a: Camada de Aplicação
9
Híbrida cliente-servidor e P2P
Skype
m
m
m
Aplicação P2P de voz sobre IP
servidor centralizado: localização do endereço
do parceiro remoto
conexão cliente-cliente: direta (sem ter que
passar por um servidor)
Mensagem instantânea
m
m
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
2a: Camada de Aplicação
10
Comunicação entre Processos
Processo cliente:
Processo: programa que
processo que inicia a
executa num sistema final
comunicação
r processos no mesmo
sistema final se comunicam Processo servidor:
processo que espera
usando comunicação
ser contatado
interprocessos definida
pelo sistema operacional
(SO)
r Nota: aplicações com
arquiteturas P2P
r processos em sistemas
possuem processos
finais distintos se
clientes e processos
comunicam trocando
servidores
mensagens através da rede
2a: Camada de Aplicação
11
Sockets
r Os processos enviam/
recebem mensagens
para/dos seus sockets
r Um socket é análogo a
uma porta
m
m
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
hospedeiro ou
servidor
hospedeiro 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
r API: (1) escolha do protocolo de transporte; (2)
habilidade para fixar alguns parâmetros (mais sobre
isto posteriormente)
2a: Camada de Aplicação
12
Endereçamento de processos
r
r
r
Para que um processo
receba mensagens, ele deve
possuir um identificador
Cada hospedeiro possui um
endereço IP único de 32
bits
P: o endereço IP do
hospedeiro no qual o
processo está sendo
executado é suficiente para
identificar o processo?
2a: Camada de Aplicação
13
Endereçamento de processos
r
r
r
r
Para que um processo
receba mensagens, ele deve
possuir um identificador
Cada hospedeiro possui um
endereço IP único de 32
bits
P: o endereço IP do
hospedeiro no qual o
processo está sendo
executado é suficiente para
identificar o processo?
Resposta: Não, muitos
processos podem estar
executando no mesmo
hospedeiro
r
r
O identificador inclui tanto
o endereço IP quanto os
números das portas
associadas com o processo
no hospedeiro .
Exemplo de números de
portas:
m
m
r
Para enviar uma msg HTTP
para o servidor Web
gaia.cs.umass.edu
m
m
r
Servidor HTTP: 80
Servidor de Correio: 25
Endereço IP: 128.119.245.12
Número da porta: 80
Mais sobre isto
posteriormente.
2a: Camada de Aplicação
14
Os protocolos da camada de
aplicação definem
r
Tipos de mensagens
trocadas:
m
r
Sintaxe das mensagens:
m
r
campos presentes nas
mensagens e como são
identificados
Semântica das msgs:
m
r
ex. mensagens de
requisição e resposta
significado da informação
nos campos
Protocolos de domínio
público:
r definidos em RFCs
r Permitem a
interoperação
r ex, HTTP e SMTP
Protocolos proprietários:
r Ex., Skype
Regras para quando os
processos enviam e
respondem às mensagens
2a: Camada de Aplicação
15
De que serviços uma aplicação necessita?
Transferência confiável
de dados
r
r
algumas apls (p.ex. áudio)
podem tolerar algumas
perdas
outras (p.ex., transf. de
arquivos, telnet) requerem
transferência 100%
confiável
Largura de banda
r
r
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
Segurança
r
r
algumas apls (p.ex.,
telefonia Internet, jogos
interativos) requerem
baixo retardo para serem
“viáveis”
Criptografia, integridade
dos dados, ...
2a: Camada de Aplicação
16
Requisitos de aplicações de rede selecionadas
Aplicação
transferência de arqs
correio
documentos Web
áudio/vídeo em
tempo real
áudio/vídeo gravado
jogos interativos
mensagem instantânea
Perdas
sem perdas
sem perdas
sem perdas
tolerante
tolerante
tolerante
sem perdas
Largura de
Banda
Sensibilidade
ao atraso
elástica
elástica
elástica
áudio: 5kb-1Mb
vídeo:10kb-5Mb
como anterior
> alguns kbps
elástica
não
não
não
sim, 100’s mseg
sim, alguns segs
sim, 100’s mseg
sim e não
2a: Camada de Aplicação
17
Serviços providos pelos protocolos de
transporte da Internet
Serviço TCP:
Serviço UDP:
r
r
r
r
r
r
orientado a conexão:
apresentaçã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
r
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
P: Qual é o interesse em ter um
UDP?
2a: Camada de Aplicação
18
Apls Internet: seus protocolos e seus
protocolos de transporte
Aplicação
correio eletrônico
acesso terminal remoto
Web
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]
HTTP (ex. Youtube)
RTP [RFC 1889]
SIP, RTP, proprietário
(ex., Skype)
TCP
TCP
TCP
TCP
TCP ou UDP
tipicamente UDP
2a: Camada de Aplicação
19
Capítulo 2: Roteiro
r 2.1 Princípios de
r
r
r
r
aplicações de rede
2.2 A Web e o HTTP
2.3 Transferência de
arquivo: FTP
2.4 Correio Eletrônico
na Internet
2.5 DNS: o serviço de
diretório da Internet
r 2.6 Aplicações P2P
r 2.7 Programação de
sockets com TCP
r 2.8 Programação de
sockets com UDP
r 2.9 Construindo um
servidor Web simples
2a: Camada de Aplicação
20
A Web e o HTTP
Primeiro algum jargão
r Páginas Web consistem de objetos
r Objeto pode ser um arquivo HTML, uma imagem
JPEG, um applet Java, um arquivo de áudio,…
r Páginas Web consistem de um arquivo base HTML
que inclui vários objetos referenciados
r Cada objeto é endereçável por uma URL
r Exemplo de URL:
www.someschool.edu/someDept/pic.gif
nome do hospedeiro
nome do caminho
2a: Camada de Aplicação
21
Protocolo HTTP
HTTP: hypertext
transfer protocol
r
r
protocolo da camada de
aplicação da Web
modelo cliente/servidor
m cliente: browser que
pede, recebe, “visualiza”
objetos Web
m servidor: servidor Web
envia objetos em
resposta a pedidos
PC executando
Explorer
Servidor
executando
servidor
Web Apache
Mac executando
Navigator
2a: Camada de Aplicação
22
Mais sobre o protocolo HTTP
Usa serviço de transporte
TCP:
r
r
r
r
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”
r
servidor não mantém
informação sobre
pedidos anteriores do
cliente
Nota
Protocolos que mantêm
“estado” são complexos!
r história passada (estado)
tem que ser guardada
r Caso caia servidor/cliente,
suas visões do “estado”
podem ser inconsistentes,
devem ser reconciliadas
2a: Camada de Aplicação
23
Conexões HTTP
HTTP não persistente
r No máximo um objeto
é enviado numa
conexão TCP
HTTP persistente
r Múltiplos objetos
podem ser enviados
sobre uma única
conexão TCP entre
cliente e servidor
2a: Camada de Aplicação
24
Exemplo de HTTP não persistente
Supomos que usuário digita a URL
www.algumaUniv.br/algumDepartmento/inicial.index
(contém texto,
referências a 10
imagens jpeg)
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
tempo
http (contendo URL)
através do socket da
conexão TCP. A mensagem
indica que o cliente deseja
receber o objeto
algumDepartamento/inicial.
index
1b. servidor http no hospedeiro
www.algumaUniv.br espera por
conexão TCP na porta 80.
“aceita” conexão, avisando ao
cliente
3. servidor http recebe mensagem
de pedido, formula mensagem
de resposta contendo objeto
solicitado e envia a mensagem
via socket
2a: Camada de Aplicação
25
Exemplo de HTTP não persistente
(cont.)
4. servidor http encerra conexão
TCP .
5. cliente http recebe mensagem
de resposta contendo arquivo
html, visualiza html.
Analisando arquivo html,
encontra 10 objetos jpeg
referenciados
6. Passos 1 a 5 repetidos para
cada um dos 10 objetos jpeg
tempo
2a: Camada de Aplicação
26
Modelagem do tempo de
resposta
Definição de RTT (Round Trip
Time): intervalo de tempo
entre a ida e a volta de um
pequeno pacote entre um
cliente e um servidor
Tempo de resposta:
r um RTT para iniciar a conexão
TCP
r um RTT para o pedido HTTP e
o retorno dos primeiros bytes
da resposta HTTP
r tempo de transmissão do
arquivo
total = 2RTT+tempo de
transmissão
Inicia a conexão
TCP
RTT
solicita
arquivo
tempo para
transmitir
o arquivo
RTT
arquivo
recebido
tempo
tempo
2a: Camada de Aplicação
27
HTTP persistente
Problemas com o HTTP não
persistente:
r requer 2 RTTs para cada
objeto
r SO aloca recursos do
hospedeiro para cada
conexão TCP
r os browser
freqüentemente abrem
conexões TCP paralelas
para recuperar os objetos
referenciados
HTTP persistente
r o servidor deixa a conexão
aberta após enviar a
resposta
r mensagens HTTP seguintes
entre o mesmo
cliente/servidor são
enviadas nesta conexão
r o cliente envia os pedidos
logo que encontra um
objeto referenciado
r pode ser necessário apenas
um RTT para todos os
objetos referenciados
2a: Camada de Aplicação
28
Formato da mensagem HTTP:
requisição
r Dois tipos de mensagem HTTP:
requisição, resposta
r mensagem de requisição HTTP:
m ASCII (formato legível por pessoas)
linha da requisição
(comandos GET,
POST, HEAD)
linhas de
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)
2a: Camada de Aplicação
29
Mensagem de requisição HTTP:
formato geral
2a: Camada de Aplicação
30
Enviando conteúdo de formulário
Método POST :
r Páginas Web
freqüentemente
contêm formulário de
entrada
r Conteúdo é enviado
para o servidor no
corpo da mensagem
Método URL:
r Usa o método GET
r Conteúdo é enviado
para o servidor no
campo URL:
www.somesite.com/animalsearch?key=monkeys&max=10
2a: Camada de Aplicação
31
Tipos de métodos
HTTP/1.0
r GET
r POST
r HEAD
m
Pede para o servidor
não enviar o objeto
requerido junto com a
resposta
HTTP/1.1
r GET, POST, HEAD
r PUT
m
Upload de arquivo
contido no corpo da
mensagem para o
caminho especificado no
campo URL
r DELETE
m Exclui arquivo
especificado no campo
URL
2a: Camada de Aplicação
32
Formato de mensagem HTTP:
resposta
linha de status
(protocolo,
código de status,
frase de status)
linhas de
cabeçalho
dados, p.ex.,
arquivo html
solicitado
HTTP/1.1 200 OK
Connection close
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 ...
2a: Camada de Aplicação
33
códigos de status da resposta
HTTP
Na primeira linha da mensagem de resposta
servidor->cliente. Alguns códigos típicos:
200 OK
m
sucesso, objeto pedido segue mais adiante nesta mensagem
301 Moved Permanently
m
objeto pedido mudou de lugar, nova localização
especificado mais adiante nesta mensagem (Location:)
400 Bad Request
m
mensagem de pedido não entendida pelo servidor
404 Not Found
m
documento pedido não se encontra neste servidor
505 HTTP Version Not Supported
m
versão de http do pedido não usada por este servidor
2a: Camada de Aplicação
34
Cookies: manutenção do
“estado” da conexão
Muitos dos principais sítios
Web usam cookies
Quatro componentes:
1) linha de cabeçalho do
cookie na mensagem de
resposta HTTP
2) linha de cabeçalho do
cookie na mensagem de
pedido HTTP
3) arquivo do cookie mantido
no host do usuário e
gerenciado pelo browser
do usuário
4) BD de retaguarda no sítio
Web
Exemplo:
m
m
m
Suzana acessa a
Internet sempre do
mesmo PC
Ela visita um sítio
específico de comércio
eletrônico pela primeira
vez
Quando os pedidos
iniciais HTTP chegam no
sítio, o sítio cria
• uma ID única
• uma entrada para a ID no
BD de retaguarda
2a: Camada de Aplicação
35
Cookies: manutenção do “estado” (cont.)
cliente
arquivo de
Cookies
ebay: 8734
arquivo de
Cookies
amazon: 1678
ebay: 8734
servidor
msg usual pedido http
servidor
resposta usual http +
cria a ID 1678
Set-cookie: 1678 para o usuário
msg usual pedido http
cookie: 1678
resposta usual http
uma semana depois:
arquivo de
Cookies
amazon: 1678
ebay: 8734
msg usual pedido http
cookie: 1678
resposta usual http
ação
específica
do cookie
ação
específica
do cookie
2a: Camada de Aplicação
36
Cookies (continuação)
nota
O que os cookies podem obter: Cookies e privacidade:
r cookies permitem que os
r autorização
sítios aprendam muito
r carrinhos de compra
sobre você
r sugestões
r você pode fornecer nome e
e-mail para os sítios
r estado da sessão do usuário
(Webmail)
Como manter o “estado”:
r Pontos finais do protocolo: mantêm o
estado no transmissor/receptor para
múltiplas transações
r Cookies: mensagens http transportam
o estado
2a: Camada de Aplicação
37
Cache Web (servidor proxy)
Meta: atender pedido do cliente sem envolver servidor de origem
r
r
usuário configura
browser: acessos Web via
proxy
cliente envia todos
pedidos HTTP ao proxy
m
m
se objeto estiver 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
cliente
cliente
Servidor
de origem
Servidor
proxy
Servidor
de origem
2a: Camada de Aplicação
38
Capítulo 2: Roteiro
r 2.1 Princípios de
r
r
r
r
aplicações de rede
2.2 A Web e o HTTP
2.3 Transferência de
arquivo: FTP
2.4 Correio Eletrônico
na Internet
2.5 DNS: o serviço de
diretório da Internet
r 2.6 Aplicações P2P
r 2.7 Programação de
sockets com TCP
r 2.8 Programação de
sockets com UDP
r 2.9 Construindo um
servidor Web simples
2a: Camada de Aplicação
39
FTP: o protocolo de transferência
de arquivos
usuário
na
estação
r
r
r
r
Interface cliente
do usuário FTP
FTP
transferência
do arquivo
sistema de
arquivos
local
servidor
FTP
sistema de
arquivos
remoto
transferir arquivo de/para hospedeiro remoto
modelo cliente/servidor
m cliente: lado que inicia transferência (pode ser de ou
para o sistema remoto)
m servidor: hospedeiro remoto
ftp: RFC 959
servidor ftp: porta 21
2a: Camada de Aplicação
40
FTP: conexões separadas p/ controle, dados
r
r
r
r
r
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
r
r
r
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
2a: Camada de Aplicação
41
FTP: comandos, respostas
Comandos típicos:
r enviados em texto ASCII
pelo canal de controle
r USER nome
r PASS senha
r LIST devolve lista de
arquivos no diretório atual
r RETR arquivo recupera
(lê) arquivo remoto
r STOR arquivo armazena
(escreve) arquivo no
hospedeiro remoto
Códigos de retorno típicos
r
r
r
r
r
código e frase de status (como
para http)
331 Username OK, password
required
125 data connection
already open; transfer
starting
425 Can’t open data
connection
452 Error writing file
2a: Camada de Aplicação
42
Capítulo 2: Roteiro
r 2.1 Princípios de
r
r
r
r
aplicações de rede
2.2 A Web e o HTTP
2.3 Transferência de
arquivo: FTP
2.4 Correio Eletrônico
na Internet
2.5 DNS: o serviço de
diretório da Internet
r 2.6 Aplicações P2P
r 2.7 Programação de
sockets com TCP
r 2.8 Programação de
sockets com UDP
r 2.9 Construindo um
servidor Web simples
2a: Camada de Aplicação
43
Correio Eletrônico
Três grandes componentes:
r
r
r
agentes de usuário (UA)
servidores de correio
simple mail transfer protocol:
SMTP
servidor
de correio
agente
de
usuário
SMTP
Agente de Usuário
SMTP
r a.k.a. “leitor de correio”
r compor, editar, ler mensagens
de correio
servidor
de correio
r p.ex., Eudora, Outlook, elm,
Mozilla Thunderbird
r mensagens de saída e chegando
são armazenadas no servidor
agente
de
usuário
SMTP
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
2a: Camada de Aplicação
44
Correio Eletrônico: servidores de correio
agente
de
usuário
Servidores de correio
r
r
r
caixa de correio contém
servidor
mensagens de chegada
de correio
(ainda não lidas) p/ usuário
SMTP
fila de mensagens contém
mensagens de saída (a serem
enviadas)
SMTP
protocolo SMTP entre
servidores de correio para
SMTP
transferir mensagens de
servidor
correio
de correio
m cliente: servidor de
correio que envia
agente
de
m “servidor”: servidor de
usuário
correio que recebe
agente
de
usuário
agente
de
usuário
servidor
de correio
agente
de
usuário
2a: Camada de Aplicação
45
Cenário: Alice envia uma msg para Bob
1) Alice usa o UA para compor
uma mensagem “para”
[email protected]
2) O UA de Alice envia a
mensagem para o seu
servidor de correio; a
mensagem é colocada na
fila de mensagens
3) O lado cliente do SMTP
abre uma conexão TCP com
o servidor de correio de
Bob
4) O cliente SMTP envia a
mensagem de Alice através
da conexão TCP
5) O servidor de correio de
Bob coloca a mensagem na
caixa de entrada de Bob
6) Bob chama o seu UA para
ler a mensagem
2a: Camada de Aplicação
46
Protocolos de acesso ao correio
agente
de
usuário
SMTP
SMTP
servidor de correio
do remetente
r
r
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
m POP: Post Office Protocol [RFC 1939]
• autorização (agente <-->servidor) e transferência
m IMAP: Internet Mail Access Protocol [RFC 1730]
• mais comandos (mais complexo)
• manuseio de msgs armazenadas no servidor
m HTTP: Hotmail , Yahoo! Mail, Webmail, etc.
2a: Camada de Aplicação
47
Protocolo POP3
fase de autorização
r
r
comandos do cliente:
m user: declara nome
m pass: senha
servidor responde
m +OK
m -ERR
fase de transação, cliente:
r
r
r
r
list: lista números das
msgs
retr: recupera msg por
número
dele: apaga msg
quit
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
2a: Camada de Aplicação
on
48
POP3 (mais) e IMAP
Mais sobre o POP3
r O exemplo anterior
usa o modo “download
e delete”.
r Bob não pode reler as
mensagens se mudar
de cliente
r “Download-emantenha”: copia as
mensagens em clientes
diferentes
r POP3 não mantém
estado entre conexões
IMAP
r Mantém todas as
mensagens num único
lugar: o servidor
r Permite ao usuário
organizar as mensagens
em pastas
r O IMAP mantém o estado
do usuário entre sessões:
m
nomes das pastas e
mapeamentos entre as IDs
das mensagens e o nome da
pasta
2a: Camada de Aplicação
49