O capítulo discute protocolos da camada de aplicação, cobrindo: 1) Princípios e exemplos de protocolos populares como HTTP, FTP, SMTP/POP3/IMAP e DNS 2) Arquiteturas cliente-servidor e peer-to-peer 3) Como aplicações se comunicam através de sockets e endereçamento de processos

1. Capítulo 2: Camada de Aplicação
Metas do capítulo:  aprenda sobre protocolos
 aspectos conceituais através do estudo de
e de implementação protocolos populares da
de protocolos de camada de aplicação:
aplicação em redes  HTTP
 modelos de serviço da  FTP
camada de transporte
 paradigma cliente
 SMTP/ POP3/ IMAP
servidor  DNS
 paradigma peer-to-
peer
2a: Camada de 1

2. Capítulo 2: Roteiro
 2.1 Princípios dos
protocolos da camada
de aplicação
 2.2 Web e HTTP
 2.3 FTP
 2.4 Correio Eletrônico
 SMTP, POP3, IMAP
 2.5 DNS
2a: Camada de 2

3. Algumas aplicações de rede
 E-mail  Voz sobre IP
 Web  Vídeo conferência em
 Instant messaging tempo real
 Login remoto  Computação paralela
 Compartilhamento de em larga escala
arquivos P2P  ?
 Jogos de rede multi-
 ?
usuários
 Vídeo-clipes armazenados
 ?
2a: Camada de 3

4. Criando uma aplicação de rede
Programas que aplicação
transporte
rede
 Executam em diferentes enlace
sistemas finais física
 Comunicam-se através da rede
 p.ex., Web: servidor Web se
comunica com o navegador
Programas não relacionados
ao núcleo da rede
 Dispositivos do núcleo da rede aplicação
não executam aplicações de aplicação
transporte
transporte
rede
usuários rede
enlace
enlace
física
 Aplicações nos sistemas finais física
permite rápido desenvolvimento
e disseminação
2a: Camada de 4

5. Arquiteturas das aplicações
 Cliente-servidor
 Peer-to-peer (P2P)
 Híbrido de cliente-servidor e P2P
2a: Camada de 5

6. Arquitetura cliente-servidor
Servidor:
 Sempre ligado
 Endereço IP permanente
 Escalabilidade com server
farms
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
2a: Camada de 6

7. Arquitetura P2P pura
 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
2a: Camada de 7

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
2a: Camada de 8

9. Processos em comunicação
Processo: programa que Processo cliente: processo que
inicia a comunicação
executa num hospedeiro
Processo servidor: processo que
 processos no mesmo espera para ser contatado
hospedeiro se comunicam
usando comunicação entre
processos definida pelo
sistema operacional (SO)
 processos em hospedeiros
 Nota: aplicações com
distintos se comunicam
trocando mensagens arquiteturas P2P
através da rede possuem processos
clientes e processos
servidores
2a: Camada de 9

10. Sockets
 Os processos enviam/ host ou host ou
servidor
recebem mensagens servidor
para/dos seus sockets controlado pelo
 Um socket é análogo a desenvolvedor da
uma porta processo aplicação processo
 Processo transmissor envia a socket socket
mensagem através da porta
TCP com TCP com
 O processo transmissor Internet buffers,
assume a existência da infra- buffers,
estrutura de transporte no variáveis variáveis
outro lado da porta que faz
com que a mensagem chegue
ao socket do processo controlado
receptor pelo SO
 API: (1) escolha do protocolo de transporte; (2)
habilidade para fixar alguns parâmetros (mais sobre
isto posteriormente)
2a: Camada de 10

11. Endereçando os processos
 Para que um processo  O identificador inclui tanto
receba mensagens, ele deve o endereço IP quanto os
possuir um identificador números das portas
 Cada host possui um associadas com o processo
endereço IP único de 32 no host.
bits  Exemplo de números de
 P: o endereço IP do host no portas:
qual o processo está sendo  Servidor HTTP: 80
executado é suficiente para  Servidor de Correio: 25
identificar o processo?  Mais sobre isto
 Resposta: Não, muitos posteriormente.
processos podem estar
executando no mesmo host
2a: Camada de 11

12. Os protocolos da camada de
aplicação definem
 Tipos de mensagens Protocolos de domínio
trocadas, ex. mensagens público:
de pedido e resposta  definidos em RFCs
 Sintaxe dos tipos das
 Permitem a
mensagens: campos
presentes nas mensagens interoperação
e como são identificados  ex, HTTP e SMTP
 Semântica dos campos, Protocolos proprietários:
i.e., significado da  Ex., KaZaA
informação nos campos
 Regras para quando os
processos enviam e
respondem às mensagens
2a: Camada de 12

13. De que serviço de transporte uma
aplicação precisa?
Perda de dados Largura de banda
 algumas apls (p.ex. áudio) podem
tolerar algumas perdas  algumas apls (p.ex.,
 outras (p.ex., transf. de multimídia) requerem
arquivos, telnet) requerem quantia mínima de banda
transferência 100% confiável para serem “viáveis”
 outras apls (“apls elásticas”)
conseguem usar qq quantia
de banda disponível
Temporização
 algumas apls (p.ex.,
telefonia Internet, jogos
interativos) requerem baixo
retardo para serem
“viáveis”
2a: Camada de 13

14. Requisitos do serviço de transporte de apls comuns
Sensibilidade
Aplicação Perdas Banda temporal
transferência de arqs sem perdas elástica não
correio sem perdas elástica não
documentos WWW sem perdas elástica não
áudio/vídeo de tolerante áudio: 5Kb-1Mb sim, 100’s mseg
tempo real vídeo:10Kb-5Mb
áudio/vídeo gravado tolerante como anterior sim, alguns segs
jogos interativos tolerante > alguns Kbps sim, 100’s mseg
apls financeiras sem perdas elástica sim e não
2a: Camada de 14

15. Serviços providos por protocolos de
transporte Internet
Serviço TCP: Serviço UDP:
 orientado a conexão:  transferência de dados não
inicialização requerida entre confiável entre processos
cliente e servidor remetente e receptor
 transporte confiável entre  não provê: estabelecimento
processos remetente e
receptor da conexão, confiabilidade,
controle de fluxo, controle
 controle de fluxo: remetente
não vai “afogar” receptor de congestionamento,
garantias temporais ou de
 controle de
banda mínima
congestionamento:
estrangular remetente quando
a rede estiver carregada P: Qual é o interesse em ter um
 não provê: garantias UDP?
temporais ou de banda mínima
2a: Camada de 15

16. Apls Internet: seus protocolos e seus
protocolos de transporte
Protocolo da Protocolo de
Aplicação camada de apl transporte usado
correio eletrônico SMTP [RFC 2821] TCP
acesso terminal remoto telnet [RFC 854] TCP
WWW HTTP [RFC 2616] TCP
transferência de arquivos ftp [RFC 959] TCP
streaming multimídia proprietário TCP ou UDP
(p.ex. RealNetworks)
telefonia Internet proprietário tipicamente UDP
(p.ex., Dialpad)
2a: Camada de 16

17. Capítulo 2: Roteiro
 2.1 Princípios dos
protocolos da camada
de aplicação
 2.2 Web e HTTP
 2.3 FTP
 2.4 Correio Eletrônico
 SMTP, POP3, IMAP
 2.5 DNS
2a: Camada de 17

18. Web e HTTP
Primeiro algum jargão
 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
2a: Camada de 18

19. Protocolo HTTP
HTTP: hypertext
transfer protocol ped
ido
 protocolo da camada de htt
PC executa res p
po s ta
aplicação da Web Explorer
htt
p
 modelo cliente/servidor
 cliente: browser que
p
pede, recebe, “visualiza” o htt
did tp Servidor
objetos Web pe a ht executando
p ost servidor
 servidor: servidor Web res
WWW
envia objetos em do NCSA
resposta a pedidos
Mac executa
 HTTP 1.0: RFC 1945 Navigator
 HTTP 1.1: RFC 2068
2a: Camada de 19

20. Mais sobre o protocolo HTTP
Usa serviço de transporte HTTP é “sem estado”
 servidor não mantém
TCP: informação sobre
 cliente inicia conexão TCP pedidos anteriores do
(cria socket) ao servidor, cliente
porta 80
 servidor aceita conexão TCP
Nota
Protocolos que mantêm
do cliente “estado” são complexos!
 mensagens HTTP (mensagens  história passada (estado)
do protocolo da camada de tem que ser guardada
apl) trocadas entre browser  Caso caia servidor/cliente,
(cliente HTTP) e servidor suas visões do “estado”
Web (servidor HTTP) podem ser inconsistentes,
 encerra conexão TCP devem ser reconciliadas
2a: Camada de 20

21. Conexões HTTP
HTTP não persistente HTTP persistente
 No máximo um objeto  Múltiplos objetos
é enviado numa podem ser enviados
conexão TCP sobre uma única
 HTTP/1.0 usa o HTTP conexão TCP entre
não persistente cliente e servidor
 HTTP/1.1 usa conexões
persistentes no seu
modo default
2a: Camada de 21

22. 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
1b. servidor http no hospedeiro
www.algumaUniv.br espera por
é padrão para servidor http.
conexão TCP na porta 80.
“aceita” conexão, avisando ao
cliente
2. cliente http envia mensagem
de pedido de http (contendo
URL) através do socket da 3. servidor http recebe mensagem
conexão TCP de pedido, formula mensagem
de resposta contendo objeto
solicitado
(algumDepartmento/inicial.index),
envia mensagem via socket
tempo
2a: Camada de 22

23. 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 23

24. 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 Inicia a conexão
Tempo de resposta: TCP
 um RTT para iniciar a conexão RTT
TCP solicita
 um RTT para o pedido HTTP e o arquivo
retorno dos primeiros bytes da RTT
tempo para
resposta HTTP transmitir
o arquivo
 tempo de transmissão do arquivo
arquivo recebido
total = 2RTT+tempo de
transmissão tempo
tempo
2a: Camada de 24

25. HTTP persistente
Problemas com o HTTP não Persistente sem pipelining:
persistente:  o cliente envia um novo
 requer 2 RTTs para cada objeto pedido apenas quando a
 SO aloca recursos do host para resposta anterior tiver sido
cada conexão TCP recebida
 os browser freqüentemente  um RTT para cada objeto
abrem conexões TCP paralelas referenciado
para recuperar os objetos Persistente com pipelining:
referenciados
 default no HTTP/1.1
HTTP persistente
 o cliente envia os pedidos
 o servidor deixa a conexão
logo que encontra um objeto
aberta após enviar a resposta
referenciado
 mensagens HTTP seguintes
 pode ser necessário apenas
entre o mesmo cliente/servidor
são enviadas nesta conexão um RTT para todos os
objetos referenciados
2a: Camada de 25

26. 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, GET /somedir/page.html HTTP/1.0
POST, HEAD) Host: www.someschool.edu
User-agent: Mozilla/4.0
linhas do Connection: close
cabeçalho Accept-language:fr
Carriage return, (carriage return (CR), line feed(LF) adicionais)
line feed
indicam fim
de mensagem
2a: Camada de 26

27. Mensagem de pedido HTTP: formato
geral
2a: Camada de 27

28. Tipos de métodos
HTTP/1.0 HTTP/1.1
 GET  GET, POST, HEAD
 POST  PUT
 HEAD  Upload de arquivo
contido no corpo da
 Pede para o servidor
mensagem para o
não enviar o objeto
caminho especificado no
requerido junto com a
campo URL
resposta (usado p/
debugging)  DELETE
 Exclui arquivo
especificado no campo
URL
2a: Camada de 28

29. Enviando conteúdo de formulário
Método POST :
 Conteúdo é enviado
para o servidor no Método GET:
corpo da mensagem  Conteúdo é enviado
para o servidor no
campo URL:
www.somesite.com/animalsearch?key=monkeys&max=10
2a: Camada de 29

30. Formato de mensagem HTTP:
resposta
linha de status
(protocolo,
código de status, HTTP/1.1 200 OK
frase de status) 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., dados dados dados dados ...
arquivo html
solicitado
2a: Camada de 30

31. 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
2a: Camada de 31

32. Experimente você com HTTP (do lado
cliente)
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
2. Digite um pedido GET HTTP:
GET /~michael/index.html HTTP/1.0 Digitando isto (deve teclar
ENTER duas vezes), está enviando
este pedido GET mínimo (porém
completo) ao servidor http
3. Examine a mensagem de resposta enviada pelo
servidor HTTP !
2a: Camada de 32

33. Cookies: manutenção do
“estado” da conexão
Muitos dos principais sítios Exemplo:
Web usam cookies  Suzana acessa a
Quatro componentes: Internet sempre do
1) linha de cabeçalho do mesmo PC
cookie na mensagem de  Ela visita um sítio
resposta HTTP
específico de comércio
2) linha de cabeçalho do
eletrônico pela primeira
cookie na mensagem de
pedido HTTP
vez
3) arquivo do cookie mantido
 Quando os pedidos
no host do usuário e iniciais HTTP chegam no
gerenciado pelo browser sítio, o sítio cria uma ID
do usuário única e cria uma entrada
4) BD de retaguarda no sítio para a ID no BD de
Web retaguarda
2a: Camada de 33

34. Cookies: manutenção do “estado” (cont.)
cliente servidor
arquivo de msg usual pedido http e
servidor de ntrad
Cookies a
resposta usual http + cria a ID 1678 retag no B
ua
ebay: 8734
Set-cookie: 1678 para o usuário rd D
a
arquivo de
msg usual pedido http
Cookies
amazon: 1678 cookie: 1678 ação
so
ebay: 8734 específica aces
resposta usual http do cookie
so
uma semana depois:
es
ac
msg usual pedido http
arquivo de
ação
Cookies cookie: 1678
amazon: 1678 específica
ebay: 8734 resposta usual http do cookie
2a: Camada de 34

35. Cookies (continuação)
nota
O que os cookies podem Cookies e privacidade:
obter:  cookies permitem que os
sítios aprendam muito
 autorização
sobre você
 carrinhos de compra  você pode fornecer nome e
 sugestões e-mail para os sítios
 mecanismos de busca usam
 estado da sessão do
redirecionamento e cookies
usuário (Webmail) para aprender ainda mais
 agências de propaganda
obtêm perfil a partir dos
sítios visitados
2a: Camada de 35

36. Cache Web (servidor proxy)
Meta: atender pedido do cliente sem envolver servidor de origem
 usuário configura
Servidor
browser: acessos Web via de origem
proxy cliente
 cliente envia todos
Servidor
ped p
pedidos HTTP ao proxy i do proxy htt
res h ttp ido tp
se objeto no cache do pos ped a ht
ost
 t ah p
proxy, este o devolve ttp
res
imediatamente na p
o htt
resposta HTTP did tp
pe a ht
 senão, solicita objeto do ost
p
servidor de origem, res
depois devolve resposta
HTTP ao cliente cliente
Servidor
de origem
2a: Camada de 36

37. Mais sobre Caches Web
 Cache atua tanto como Para que fazer cache Web?
cliente quanto como  Redução do tempo de
servidor resposta para os pedidos
 Tipicamente o cache é do cliente
instalado por um ISP  Redução do tráfego no
(universidade, empresa, canal de acesso de uma
ISP residencial) instituição
 A Internet cheia de caches
permitem que provedores
de conteúdo “pobres”
efetivamente forneçam
conteúdo!
2a: Camada de 37

38. Exemplo de cache (1) Servidores
de origem
Hipóteses
 Tamanho médio de um objeto =
Internet
100.000 bits
pública
 Taxa média de solicitações dos
browsers de uma instituição para
os servidores originais = 15/seg
 Atraso do roteador institucional
para qualquer servidor origem e de enlace de acesso
volta ao roteador = 2seg 1,5 Mbps
Conseqüências rede da
 Utilização da LAN = 15% instituição
LAN 10 Mbps
 Utilização do canal de acesso =
100%
 Atraso total = atraso da Internet
+ atraso de acesso + atraso na LAN
= 2 seg + minutos + milisegundos
2a: Camada de 38

39. Exemplo de cache (2) Servidores
de origem
Solução em potencial
 Aumento da largura de banda Internet
do canal de acesso para, por pública
exemplo, 10 Mbps
Conseqüências
 Utilização da LAN = 15%
enlace de acesso
 Utilização do canal de acesso 10 Mbps
= 15%
rede da
 Atraso total = atraso da instituição
LAN 10 Mbps
Internet + atraso de acesso +
atraso na LAN = 2 seg +
msegs + msegs
 Freqüentemente este é uma
ampliação cara
2a: Camada de 39

40. Exemplo de cache (3) Servidores
de origem
Instale uma cache
 Assuma que a taxa de acerto
Internet
seja de 0,4 pública
Conseqüências
 40% dos pedidos serão
atendidos quase que
imediatamente enlace de acesso
 60% dos pedidos serão servidos 1,5 Mbps
pelos servidores de origem
rede da
 Utilização do canal de acesso é
instituição
reduzido para 60%, resultando LAN 10 Mbps
em atrasos desprezíveis (ex. 10
mseg)
 Atraso total = atraso da
Internet + atraso de acesso + cache
atraso na LAN = 0,6*2 seg + institucional
0,6*0,01 segs + msegs < 1,3 segs
2a: Camada de 40

41. GET condicional
cache servidor
 Meta: não enviar objeto se msg de pedido http
If-modified-since: objeto
cliente já tem (no cache) <date> não
versão atual
resposta http modificado
 cache: especifica data da HTTP/1.0
cópia no cache no pedido 304 Not Modified
http
If-modified-since:
<date> msg de pedido http
 servidor: resposta não If-modified-since:
objeto
<date>
contém objeto se cópia no modificado
cache é atual: resposta http
HTTP/1.1 200 OK
HTTP/1.0 304 Not …
Modified <data>
2a: Camada de 41

42. Capítulo 2: Roteiro
 2.1 Princípios dos
protocolos da camada
de aplicação
 2.2 Web e HTTP
 2.3 FTP
 2.4 Correio Eletrônico
 SMTP, POP3, IMAP
 2.5 DNS
2a: Camada de 42

43. FTP: o protocolo de transferência
de arquivos
transferência
Interface cliente do arquivo FTP
do usuário FTP
servidor
FTP
usuário
na sistema de sistema de
estação arquivos arquivos
local 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
2a: Camada de 43

44. FTP: conexões separadas p/ controle, dados
 cliente FTP contata servidor FTP na
porta 21, especificando o TCP como conexão de controle
protocolo de transporte TCP, porta 21
 O cliente obtém autorização
através da conexão de controle
 O cliente consulta o diretório conexão de dados
remoto enviando comandos através cliente TCP, porta 20 servidor
da conexão de controle FTP FTP
 Quando o servidor recebe um
comando para a transferência de  O servidor abre uma segunda
um arquivo, ele abre uma conexão
de dados TCP para o cliente conexão TCP para transferir
 Após a transmissão de um arquivo o outro arquivo
servidor fecha a conexão  Conexão de controle: “fora da
faixa”
 Servidor FTP mantém o
“estado”: diretório atual,
autenticação anterior
2a: Camada de 44

45. FTP: comandos, respostas
Comandos típicos: Códigos de retorno típicos
 enviados em texto ASCII  código e frase de status (como
pelo canal de controle para http)
 USER nome  331 Username OK, password
required
 PASS senha
 125 data connection
 LIST devolve lista de already open; transfer
arquivos no diretório atual starting
 RETR arquivo recupera  425 Can’t open data
(lê) arquivo remoto connection

 STOR arquivo armazena 452 Error writing file
(escreve) arquivo no
hospedeiro remoto
2a: Camada de 45

46. Capítulo 2: Roteiro
 2.1 Princípios dos
protocolos da camada
de aplicação
 2.2 Web e HTTP
 2.3 FTP
 2.4 Correio Eletrônico
 SMTP, POP3, IMAP
 2.5 DNS
2a: Camada de 46

47. fila de
Correio Eletrônico mensagens
de saída
caixa de
agente correio do usuário
Três grandes componentes: de
usuário
 agentes de usuário (UA) servidor agente
 servidores de correio de correio de
usuário
 simple mail transfer protocol:
SMTP
SMTP
servidor
de correio agente
Agente de Usuário SMTP de
usuário
 a.k.a. “leitor de correio”
 compor, editar, ler mensagens
SMTP
agente
de correio servidor de
de correio usuário
 p.ex., Eudora, Outlook, elm,
Netscape Messenger
agente
 mensagens de saída e chegando de
são armazenadas no servidor usuário
agente
de
usuário
2a: Camada de 47

48. Correio Eletrônico: servidores de correio
agente
Servidores de correio de
usuário
 caixa de correio contém servidor agente
mensagens de chegada de correio de
(ainda não lidas) p/ usuário usuário
 fila de mensagens contém SMTP
servidor
mensagens de saída (a serem de correio
enviadas) SMTP
 protocolo SMTP entre
servidores de correio para SMTP
transferir mensagens de agente
servidor de
correio de correio usuário
 cliente: servidor de
correio que envia agente
 “servidor”: servidor de de
usuário
correio que recebe agente
de
usuário
2a: Camada de 48

49. 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
 mensagens precisam ser em ASCII de 7-bits
2a: Camada de 49

50. Cenário: Alice envia uma msg para Bob
1) Alice usa o UA para compor 4) O cliente SMTP envia a
uma mensagem “para” mensagem de Alice através da
bob@someschool.edu conexão TCP
2) O UA de Alice envia a 5) O servidor de correio de Bob
mensagem para o seu servidor
coloca a mensagem na caixa de
de correio; a mensagem é
colocada na fila de mensagens entrada de Bob
3) O lado cliente do SMTP abre 6) Bob chama o seu UA para ler a
uma conexão TCP com o mensagem
servidor de correio de Bob
1 mail
mail
server user
user server
2 agent
agent 3 6
4 5
2a: Camada de 50

51. Interação SMTP típica
S: 220 doces.br
C: HELO consumidor.br
S: 250 Hello consumidor.br, pleased to meet you
C: MAIL FROM: <ana@consumidor.br>
S: 250 ana@consumidor.br... Sender ok
C: RCPT TO: <bernardo@doces.br>
S: 250 bernardo@doces.br ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Voce gosta de chocolate?
C: Que tal sorvete?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 doces.br closing connection
2a: Camada de 51

52. Experimente uma interação SMTP:
 telnet nomedoservidor 25
 veja resposta 220 do servidor
 entre comandos HELO, MAIL FROM, RCPT TO,
DATA, QUIT
estes comandos permitem que você envie correio sem
usar um cliente (leitor de correio)
2a: Camada de 52

53. SMTP: últimas palavras
 SMTP usa conexões Comparação com HTTP
persistentes
 HTTP: pull (puxar)
 SMTP requer que a mensagem
(cabeçalho e corpo) sejam em  SMTP: push (empurrar)
ASCII de 7-bits
 ambos têm interação
 servidor SMTP usa
comando/resposta, códigos
CRLF.CRLF para reconhecer o de status em ASCII
final da mensagem
 HTTP: cada objeto é
encapsulado em sua própria
mensagem de resposta
 SMTP: múltiplos objetos de
mensagem enviados numa
mensagem de múltiplas
partes
2a: Camada de 53

54. Formato de uma mensagem
SMTP: protocolo para trocar
msgs de correio cabeçalho
linha em
RFC 822: padrão para formato
branco
de mensagem de texto:
 linhas de cabeçalho, p.ex.,
 To: corpo
 From:
 Subject:
diferentes dos comandos de
smtp!
 corpo
 a “mensagem”, somente de
caracteres ASCII
2a: Camada de 54

55. Formato de uma mensagem: extensões para
multimídia
 MIME: multimedia mail extension, RFC 2045, 2056
 linhas adicionais no cabeçalho da msg declaram tipo do
conteúdo MIME
From: ana@consumidor.br
versão MIME To: bernardo@doces.br
Subject: Imagem de uma bela torta
método usado MIME-Version: 1.0
p/ codificar dados Content-Transfer-Encoding: base64
Content-Type: image/jpeg
tipo, subtipo de
dados multimídia, base64 encoded data .....
declaração parâmetros .........................
......base64 encoded data
Dados codificados
2a: Camada de 55

56. Tipos MIME
Content-Type: tipo/subtipo; parâmetros
Text Audio
 subtipos exemplos: plain,  subtipos exemplos : basic
html (8-bit codificado mu-law),
 charset=“iso-8859-1”, 32kadpcm (codificação 32
ascii kbps)
Application
Image
 outros dados que precisam
 subtipos exemplos : jpeg,
gif ser processados por um
leitor para serem
“visualizados”
Video
 subtipos exemplos :
 subtipos exemplos : mpeg,
msword, octet-stream
quicktime
2a: Camada de 56

57. Tipo Multipart
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=98766789
--98766789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
Dear Bob,
Please find a picture of a crepe.
--98766789
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
--98766789--
2a: Camada de 57

58. Protocolos de acesso ao correio
agente SMTP SMTP POP3 ou agente
de de
usuário IMAP usuário
servidor de correio servidor de correio
do remetente 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.
2a: Camada de 58

59. Protocolo POP3 S: +OK POP3 server ready
C: user ana
fase de autorização S: +OK
 comandos do cliente: C: pass faminta
S: +OK user successfully logged on
 user: declara nome
 pass: senha C: list
 servidor responde S: 1 498
S: 2 912
 +OK
S: .
 -ERR C: retr 1
fase de transação, cliente: S: <message 1 contents>
 list: lista números das
S: .
C: dele 1
msgs
C: retr 2
 retr: recupera msg por
S: <message 1 contents>
número S: .
 dele: apaga msg C: dele 2
 quit C: quit
S: +OK POP3 server signing off
2a: Camada de 59

60. POP3 (mais) e IMAP
Mais sobre o POP3 IMAP
 O exemplo anterior usa o  Mantém todas as
modo “download e mensagens num único
delete”. lugar: o servidor
 Bob não pode reler as  Permite ao usuário
mensagens se mudar de organizar as mensagens
cliente em pastas
 “Download-e-mantenha”:  O IMAP mantém o estado
copia as mensagens em do usuário entre sessões:
clientes diferentes  nomes das pastas e
mapeamentos entre as IDs
 POP3 não mantém estado
das mensagens e o nome da
entre conexões pasta
2a: Camada de 60