Fundamentos de Redes

Prof. Martony Demes

mardemes@gmail.com
UAPI - Uruçuí

2a: Camada de Aplicação 1

Capítulo 2: Camada de Aplicação
Metas do capítulo:
❒ aspectos conceituais e de
implementação de protocolos
de aplicação em redes
❍ modelos de serviço da camada de
transporte
❍ Arquitetura cliente- servidor
❍ Arquitetura peer-to-peer (P2P)
❒ aprenda sobre protocolos
através do estudo de
protocolos populares da
camada de aplicação:
❍ HTTP
❍ FTP
❍ SMTP/ POP3/ IMAP
❍ DNS
2a: Camada de Aplicação 2
Capítulo 2: Roteiro
❒ 2.1 Princípios dos protocolos da camada de aplicação

❒ 2.2 A Web e o HTTP

❒ 2.3 Transferência de Arquivo (File Transfer)

❍ FTP

❒ 2.4 Correio Eletrônico

❍ SMTP, POP3, IMAP

❒ 2.5 DNS: serviço de diretório da Internet

❒ 2.6 Compartilhamento de arquivos P2P

2a: Camada de Aplicação 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 Aplicação 4

Criando uma aplicação de rede
São programas que aplicação
transporte
❍ Executam em diferentes sistemas rede
enlace
finais física

❍ Comunicam-se através da rede

❍ Ex., Web: servidor Web (Apache,
Microsoft) envia página Web
(documento HTML) requisitada pelo
navegador (browser-Internet Explorer)
através de uma troca de mensagens
(HTTP)
São programas não relacionados ao núcleo aplicação
aplicação
transporte
da rede transporte
rede
rede
enlace
❍ Dispositivos do núcleo da rede não enlace
física
física

executam aplicações de usuários

Aplicações nos sistemas finais permite
rápido desenvolvimento e disseminação

2a: Camada de Aplicação 5

Arquiteturas das aplicações
❒ Cliente-servidor
❒ Peer-to-peer (P2P)
❒ Híbrido de cliente-servidor e P2P

2a: Camada de Aplicação 6

Arquitetura cliente-servidor
Servidor:
❒ Sempre ligado
❒ Endereço IP permanente
❒ Provê serviços pedidos pelo cliente
❒ Escalabilidade com server farms - conjunto
de servidores que formam um servidor
virtual único – infra-estrutura intensa
(Google,Amazon,YouTube, YahooMail)
Cliente:
❒ Comunica-se com o servidor (“fala primeiro”)
❒ Pede serviços ao servidor
❒ Pode estar conectado intermitentemente
❒ Pode ter endereços IP dinâmicos
❒ Não se comunica diretamente com outros
clientes 2a: Camada de Aplicação 7
 Arquitetura P2P pura
❒ Não há servidor sempre ligado
❒ Sistemas finais arbitrários se
comunicam diretamente chamados
pares (peers)
❒ Não passam por servidores
dedicados, são controlados por
usuários
❒ Pares estão conectados
intermitentemente e mudam
endereços IP
❒ Exemplo: BitTorrent (distribuição
arquivos), eMule (compartilhamento arquivos),
Skype (telefonia)
Alta escalabilidade
Porém, difícil de gerenciar

2a: Camada de Aplicação 8

Híbrido de cliente-servidor e P2P
Napster (extinta)
❍ 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
Mensagem instantânea - Instant messaging
❍ Conversa entre dois 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 outros usuários

2a: Camada de Aplicação 9

 Processos em comunicação
Processo: programa que é executado
❒ Processo cliente: processo
em um hospedeiro
que inicia a comunicação
❒ processos no mesmo hospedeiro
se comunicam usando comunicação
❍ Faz a interface com o usuário
entre processos definida pelo “acima” e com a rede “abaixo”
sistema operacional (SO) ❍ implementa protocolos nível
❒ processos em hospedeiros de aplicação
distintos se comunicam por ❍ Ex. Web: browser
protocolo da camada de aplicação,
trocando mensagens através da
rede
❒ Processo servidor: processo que
espera para ser contactado

Nota: aplicações com arquiteturas P2P

possuem processos clientes e
processos servidores
2a: Camada de Aplicação 10
 Sockets (Portas)
❒ Os processos enviam/
recebem mensagens Cliente Servidor
para/dos seus sockets controlado pelo
❒ Um socket é análogo a uma desenvolvedor da
aplicação (Browser)
porta
processo processo
❍ Processo transmissor envia a
mensagem através da sua porta socket socket
❍ O processo transmissor assume
a existência da camada de TCP com TCP com
transporte no outro lado da sua buffers, Internet buffers,
porta variáveis variáveis
❍ A camada de transporte faz
com que a mensagem chegue à controlado
porta do processo receptor pelo SO

❒ API – Interface de programação de aplicação – interface entre a

aplicação e a camada de transporte: (1) escolha do protocolo de
transporte; (2) habilidade para fixar alguns parâmetros (ex.
tamanho máximo do buffer e do segmento)
2a: 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
❒ P: 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: porta 80
❍ Servidor de Correio: porta 25
❒ Mais sobre isto
posteriormente.
2a: Camada de Aplicação 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 e interoperação
como são identificados ❒ ex, HTTP e SMTP
❒ Semântica dos campos, Protocolos proprietários:
i.e., significado da ❒ Ex., KaZaA, Skype
informação nos campos
❒ Regras para quando os
processos enviam e
respondem às mensagens
2a: Camada de Aplicação 13
De que serviço de transporte uma aplicação
precisa?
Perda de dados
❒ algumas aplicações (p.ex. áudio)
podem tolerar algumas perdas
❒ outras (p.ex., transf. de
arquivos, telnet) requerem
transferência 100% confiável
Temporização
❒ algumas aplicações (p.ex.,
telefonia Internet, jogos
interativos) requerem baixo
retardo para serem
“viáveis”
SSL = Secure Socket Layer
Largura de banda
❒ algumas aplicações (p.ex.,
multimídia) requerem
quantia mínima de banda
para serem “viáveis”
❒ outras aplicações (“apls
elásticas”) conseguem usar
qualquer quantia de banda
disponível
Segurança
❒ Criptografar os dados para
garantir confidenciabilidade
❒ Autenticidade
❒ TCP-enhanced with SSL
(Capt. 8)
2a: Camada de Aplicação 14
Requisitos do serviço de transporte de aplicações
comuns
Sensibilidade
Aplicação Perdas Banda temporal
transferência de arqs sem elástica não
correio perdas elástica não
documentos WWW sem elástica não
perdas
áudio/vídeo de
tempo real sem áudio: 5Kb-1Mb
sim, 100’s mseg
videoconferência perdas vídeo:10Kb-5Mb
áudio/vídeo gravado como anterior sim, alguns segs
jogos interativos tolerante > alguns Kbps sim, 100’s mseg
Mensagem elástica sim e não
instantânea tolerante
tolerante
A Internet de hoje ainda não provê garantia de Banda e Sensibilidade Temporal
sem 2a: Camada de Aplicação 15
 Serviços providos por protocolos de
transporte Internet
Serviço TCP:
❒ Orientado à 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
❒ Protocolo leve
P: Qual é o interesse em ter um
UDP?
2a: Camada de Aplicação 16
 Aplicações 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

Web HTTP [RFC 2616] TCP

transferência de arquivos FTP [RFC 959] TCP

streaming multimídia HTTP(ex. YouTube), TCP ou UDP

RTP
SIP, RTP, ou tipicamente UDP
telefonia Internet
Proprietário (Skype)
2a: Camada de Aplicação 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

❒ 2.6 Compartilhamento de arquivos P2P

2a: Camada de Aplicação 18

 Web e HTTP
❒ Páginas Web consistem de objetos

❒ Objeto pode ser um arquivo HTML, uma imagem

JPEG, um vídeo clipe, 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 servidor nome do caminho

URL = Uniform Resource Locator 2a: Camada de Aplicação 19
Protocolo HTTP

HTTP: HyperText Transfer

Protocol – protocolo de ped
transferência de hipertexto ido
htt
PC executa res p
❒ protocolo da camada de Explorer pos
ta
aplicação da Web htt
p
❒ arquitetura cliente/servidor
❍ cliente: browser que pede,
http
recebe, “mostra” objetos d ido t tp Servidor
pe h rodando um
Web osta
p servidor Web
res
❍ servidor: servidor Web (ex. UnB)
envia objetos em resposta
a pedidos Mac executa
❒ HTTP 1.0: RFC 1945 Navigator
❒ HTTP 1.1: RFC 2068

2a: Camada de Aplicação 20

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
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
2a: Camada de Aplicação 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 Aplicação 22

 Exemplo de HTTP não persistente
Supomos que usuário digita a URL www.algumaUniv.br/algumDepartmento/index.html
1a. Cliente http inicia conexão
TCP a servidor http (processo)
www.algumaUniv.br na Porta
80 padrão para servidor http.
2. cliente http envia mensagem de
pedido de http (contendo URL
incluindo /algumDepartamento
/index.html) através do socket
da conexão TCP
tempo
(contém texto,
referências a 10
imagens jpeg)
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 (algumDepartmento
/index.html), envia mensagem via
socket
2a: Camada de Aplicação 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, mostra 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 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 Aplicação 25

HTTP com conexão persistente
Problemas com o HTTP não
persistente:
❒ requer 2 RTTs para cada objeto
❒ SO aloca recursos do host para
cada conexão TCP
❒ os browser freqüentemente abrem
conexões TCP paralelas para
recuperar os objetos referenciados
HTTP persistente
❒ o servidor deixa a conexão aberta
após enviar a resposta
❒ mensagens HTTP seguintes entre o
mesmo cliente/servidor são
enviadas nesta conexão
Persistente sem pipelining
(paralelismo):
❒ o cliente envia um novo pedido
apenas quando a resposta
anterior tiver sido recebida
❒ um RTT para cada objeto
referenciado
Persistente com pipelining
❒ default no HTTP/1.1
❒ o cliente envia os pedidos logo
que encontra um objeto
referenciado
❒ pode ser necessário apenas um
RTT para todos os objetos
referenciados
2a: Camada de Aplicação 26
 Formato de mensagem HTTP: pedido
❒ Dois tipos de mensagem HTTP: pedido, resposta
❒ mensagem de pedido HTTP:
❍ ASCII (formato legível por pessoas)

linha de requisição
(comandos GET,
POST, HEAD, PUT, GET /somedir/page.html HTTP/1.0
DELETE) Host: www.someschool.edu
User-agent: Mozilla/4.0
linhas do Connection: close
cabeçalho Accept-language:fr

(carriage return (CR), line feed(LF) adicionais)

Carriage return e
line feed, linha em branco,
indicam fim de mensagem
ASC II - American Standard Code for Information Interchange II
256 caracteres codificados em 8 bits
2a: Camada de Aplicação 27
Mensagem de pedido HTTP: formato
geral
Linha de
requisição

Linhas do
Cabeçalho

Linha em branco

Corpo da
mensagem

2a: Camada de Aplicação 28

 Tipos de métodos
HTTP/1.0 HTTP/1.1
❒ GET
❒ GET, POST, HEAD
❍ Usuário requisita um objeto
❒ POST ❒ PUT
❍ Usuário preenche formulário ❍ Upload de arquivo
(colocado no corpo da mensagem)
contido no corpo da
❒ HEAD mensagem para o
❍ Pede para o servidor não enviar o
caminho especificado no
objeto requerido junto com a
resposta (usado p/ depuração) campo URL
❒ DELETE
❍ Usuário exclui do
servidor Web arquivo
especificado no campo
URL

2a: Camada de Aplicação 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:

Exemplo: preencher formulário usando método

GET - formulário possui dois campos de entrada
preenchidos com monkeys e banana
www.somesite.com/animalsearch?monkeys&banana

2a: Camada de Aplicação 30

Formato de mensagem HTTP: resposta
linha de estado
(protocolo,
código de estado,
frase de estado) 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
Número de bytes Quando o objeto
Content-Type: text/html foi criado
do objeto
ou modificado

dados, p.ex., dados dados dados dados ...

arquivo html
solicitado

2a: Camada de Aplicação 31

Códigos de estado 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 Aplicação 32
Cookies: manutenção do “estado” da conexão
São textos que podem ser armazenados no disco rígido com dados do usuário.
Permitem que sites identifiquem e monitorem os seus usuários.

Muitos dos principais sites Web usam

cookies
Exemplo:
❍ Suzana acessa a Internet
Quatro componentes:
sempre do mesmo PC
1. linha de cabeçalho do cookie na ❍ Ela visita um site
mensagem de resposta HTTP específico de comércio
• Set-cookie: 1678 eletrônico pela primeira
1. linha de cabeçalho do cookie na vez
mensagem de pedido HTTP ❍ Quando os pedidos iniciais
• Cookie: 1678
HTTP chegam no site, o
site cria uma ID (ex. 1678)
1. arquivo do cookie mantido no host do
única e cria uma entrada
usuário e gerenciado pelo browser do para a ID no Banco de
usuário Dados de apoio
2. Banco de Dados (BD) de apoio no site
Web
2a: Camada de Aplicação 33
 Cookies: manutenção do “estado” (cont.)
cliente servidor
arquivo de
Cookies msg usual pedido http en
Host - ID servidor apo trada
ebay: 8734
resposta usual http + cria a ID 1678 io no BD
Set-cookie: 1678 para o usuário de
arquivo de
Cookies
amazon: 1678
msg usual pedido http
ebay: 8734
cookie: 1678 ação
so
específica aces
resposta usual http do cookie

so
uma semana depois:

es
ac
msg usual pedido http
arquivo de ação
cookie: 1678
Cookies
amazon: 1678 específica
ebay: 8734 resposta usual http do cookie

2a: Camada de Aplicação 34

Cookies (continuação)
nota
O que os cookies podem fazer: Cookies e privacidade:
❒ Autorização após
❒ cookies permitem que os sites
armazenamento do registro
da pessoa aprendam muito sobre você
❒ Registro da lista de ❒ você pode fornecer nome e e-mail
compras no Ecommerce para os sites
❒ Sugestões -recomendar
❒ mecanismos de busca usam
produtos
❒ estado da sessão do usuário
redirecionamento e cookies para
(Web email) – identificação aprender ainda mais sobre você
do usuário ❒ agências de propaganda obtêm
❒ Eles armazenam coisas que
perfil a partir dos sites visitados
você acessou, sites que
e oferecem produtos perturbando
você viu
os usuários (ex. DoubleClick)

2a: Camada de Aplicação 35

 Cache Web (servidor proxy)
Meta: atender pedido do cliente sem envolver servidor de origem
❒ usuário configura browser:
Servidor
acessos Web via proxy de origem
(representante) cliente
Servidor
❒ cliente envia todos ped
ido proxy http
htt o
pedidos HTTP ao proxy res
pos p e did ht tp
p
ta
htt osta
p
❍ se objeto está no cache , p res
este o devolve http
d ido tt p
imediatamente na pe h
os ta
p
resposta HTTP res
❍ senão, solicita objeto do
cliente
servidor de origem, Servidor
depois devolve resposta de origem

HTTP ao cliente
2a: Camada de Aplicação 36
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 Aplicação 37

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

2a: Camada de Aplicação 38

 Exemplo de cache (2) Servidores
de origem

Solução em potencial
❒ Aumento da largura de banda do
Internet
canal de acesso para, por exemplo, pública
10 Mbps
Conseqüências
❒ Utilização da LAN = 15% enlace de acesso
10 Mbps
❒ Utilização do canal de acesso = 15%
rede da
❒ Atraso total = atraso da Internet + instituição
LAN 10 Mbps
atraso de acesso + atraso na LAN =
2 seg + msegs + msegs
❒ Freqüentemente esta é uma
ampliação cara

2a: Camada de Aplicação 39

 Exemplo de cache (3) Servidores
de origem
Instale uma cache
❒ Assuma que a taxa de acerto seja
de 0,4 Internet
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
LAN 10 Mbps
reduzido para 60%, resultando em
atrasos desprezíveis (ex. 0,01seg)
❒ Atraso total = atraso da Internet
cache
+ atraso de acesso + atraso na
institucional
LAN = 0,6x2 seg + 0,6x0,01 segs +
0,4x(0,01seg) < 1,3 segs
2a: Camada de Aplicação 40
 GET condicional
Servidor
cache
de origem
❒ 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 Aplicação 41
Experimente você com HTTP (do lado
cliente)
1. Use o analisador de rede Wireshark para observar as mensagens do protocolo HTTP trocadas entre cliente e servidor.

brir o programa Wireshark e selecionar

1. Menu: Capture->Options (selecionar a sua interface de
rede) – clique em ok
2. Menu: Capture->Start

• Abre
brir conexão TCP
o browser: para a link
digitar porta-80http://www.ene.unb.br/~juliana/
(porta padrão do servidor
http) a www.ene.unb.br
• O pedido GET será enviado ao servidor http
• Examine a mensagem do pedido do cliente e resposta enviada
pelo servidor HTTP!

2a: Camada de Aplicação 42

Analisador de Rede Wireshark – Captura HTTP

2a: Camada de Aplicação 43

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

❒ 2.6 Compartilhamento de arquivos P2P

2a: Camada de Aplicação 44

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: portas 20 e 21

2a: Camada de Aplicação 45

FTP: conexões separadas p/ controle, dados
❒ cliente FTP contata servidor FTP na
porta 21, especificando o TCP como
protocolo de transporte conexão de controle
❒ O cliente obtém autorização TCP, porta 21
através da conexão de controle
❒ O cliente consulta o diretório
remoto enviando comandos através conexão de dados
da conexão de controle cliente TCP, porta 20 servidor
❒ Quando o servidor recebe um FTP FTP
comando para a transferência de
um arquivo, ele abre uma conexão ❒ O servidor abre uma segunda
de dados TCP para o cliente
conexão TCP para transferir
❒ Após a transmissão de um arquivo o
servidor fecha a conexão 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 46

 FTP: comandos, respostas
Comandos típicos:
❒ enviados em texto ASCII
pelo canal de controle
❒ USER nome
❒ PASS senha
❒ LIST devolve lista de
arquivos no diretório atual
❒ RETR arquivo recupera
(lê) arquivo remoto
❒ STOR arquivo armazena
(escreve) arquivo no
hospedeiro remoto
Códigos de retorno típicos
❒ 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 47
Wireshark – Captura FTP

2a: Camada de Aplicação 48

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

❒ 2.6 Compartilhamento de arquivos P2P

2a: Camada de Aplicação 49

 Correio Eletrônico fila de
mensagens
Três grandes componentes: de saída
❒ Agentes dos usuários caixa de
agente correio do usuário
❒ Servidores de mensagens de
usuário
❒ Protocolo de transferência de mensagens
Servidor de agente
- Simple Mail Transfer Protocol: SMTP mensagens de
usuário
Agente do Usuário SMTP Servidor de
❒ “leitor de mensagens”
mensagens agente
❒ compõe, edita, lê mensagens de correio
SMTP de
usuário
❒ p.ex., Eudora, Outlook, elm, Netscape
Messenger SMTP
agente
❒ mensagens enviadas e recebidas são
Servidor de de
armazenadas no servidor mensagens usuário

agente
de
usuário
agente
de
usuário
2a: Camada de Aplicação 50
Correio Eletrônico: servidores de correio
Servidores de correio
❒ caixa de mensagens contém mensagens agente
que chegam (para serem lidas) para o de
usuário
usuário servidor de agente
❒ fila de mensagens contém mensagens mensagens de
usuário
de saída (a serem enviadas)
SMTP Servidor de
❒ protocolo SMTP (push- envio de
mensagens
mensagem) entre servidores de
mensagens SMTP
“cliente”: servidor de envio de
❍
SMTP
mensagens agente
Servidor de de
❍ “servidor”: receptor de mensagens mensagens usuário

agente
de
usuário
agente
de
usuário
2a: Camada de Aplicação 51
Correio Eletrônico: SMTP [RFC 2821]
❒ usa TCP para o envio confiável de mensagens do correio do cliente
ao servidor, porta 25
❒ transferência direta: servidor remetente (“cliente”) ao servidor
receptor
❒ três fases da transferência

❍ handshaking (cumprimento)
❍ envio das mensagens
❍ término
❒ interação comando/respostas

❍ comandos: texto ASCII

❍ respostas: código de status e frase explicativa
❒ mensagens precisam ser em ASCII de 7-bits

2a: Camada de Aplicação 52

Cenário: Alice envia mensagem para Bob
1) Alice compõe uma 4) Caso consiga conexão, o cliente
mensagem “para” SMTP envia a mensagem de Alice
bob@someschool.edu através da conexão TCP
2) Alice envia a mensagem para 5) O servidor de mensagens de Bob
o seu servidor de coloca a mensagem na caixa de e-
mail de Bob
mensagens; a mensagem é
colocada na fila 6) Bob usa o seu Agente de Usuário
para ler a mensagem
3) O lado cliente do SMTP
abre uma conexão TCP com
o servidor de mensagens de
Bob

1 mail
mail
server user
user server SMTP
2 agent
agent 3 6
4 5

Cliente SMTP Servidor SMTP

2a: Camada de Aplicação 53
Interação SMTP típica S: servidor (recebe msg correio)
S: 220 doces.br C: cliente (envia msg correio)
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
Cliente – 5 comandos: HELO, MAIL FROM, RCPT TO, DATA, QUIT
Serviror – respostas: código e explicações(opcionais)
2a: Camada de Aplicação 54
 SMTP: resumo
❒ SMTP usa conexões
persistentes
❒ SMTP requer que a mensagem
(cabeçalho e corpo) seja em
ASCII de 7-bits
❒ Por exemplo: uma imagem deve
ser convertida para ASCII
antes de ser enviada –
receptor deve decodificar
❒ servidor SMTP usa
CRLF.CRLF para reconhecer o
final da mensagem
CR- Carriage return
LF- Line Feed
Comparação com HTTP
❒ HTTP: pull (cliente puxa
objeto do servidor)
❒ SMTP: push (cliente
empurra mensagem para
servidor)
❒ ambos têm interação
comando/resposta, códigos
de status em ASCII
❒ HTTP: cada objeto é
encapsulado em sua própria
mensagem de resposta
❒ SMTP: múltiplos objetos
podem ser enviados numa
única mensagem
2a: Camada de Aplicação 55
Formato de uma mensagem

SMTP: protocolo para trocar

mensagens 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 Aplicação 56

Formato de mensagem: extensões
multimídia
❒ SMTP somente pode enviar mensagens no formato ASCII de 7
bits
❒ MIME (Multipurpose Internet Mail Extensions)
❍ Extensão do e-mail para multimídia RFC 2045, 2056
❍ Permite dados que não são ASCII
❍ Linhas adicionais no cabeçalho da mensagem para declarar o tipo do
conteúdo MIME
❍ Não é um protocolo de e-mail e não pode substituir o SMTP, apenas
é uma extensão do SMTP

2a: Camada de Aplicação 57

Formato de mensagem: extensões multimídia
❒ MIME (Multipurpose Internet Mail Extensions)
❍ Extensão do e-mail para multimídia RFC 2045, 2056

From: ana@consumidor.br
versão MIME To: bernardo@doces.br
Subject: Imagem de uma bela torta
método usado MIME-Version: 1.0
para codificar dados Content-Transfer-Encoding: base64
Content-Type: image/jpeg
Dados multimídia
tipo, subtipo, base64 encoded data .....
parâmetros .........................
......base64 encoded data
Dados codificados

2a: Camada de Aplicação 58

Tipos MIME
Content-Type: tipo/subtipo; parâmetros

Text Audio
❒ subtipos exemplos: plain, ❒ subtipo exemplo : 32k
html adpcm (codificação 32
❒ charset=“iso-8859-1”, kbps)
ascii
Application
❒ outros dados que precisam
Image
❒ subtipos exemplos : jpeg,
ser processados por um
gif
leitor para serem
“visualizados”
❒ subtipo exemplo : msword
Video
❒ subtipos exemplos : mpeg,
quicktime

2a: Camada de Aplicação 59

 Tipo Multiparte
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 Aplicação 60
Protocolos de acesso ao e-mail
Protocolo de acesso
agente SMTP SMTP POP3 ou agente
de de
usuário IMAP usuário

servidor de e-mail servidor de e-mail

do remetente do receptor
❒ SMTP: entrega/armazenamento para o servidor receptor
❒ protocolo de acesso ao e-mail: recupera mensagem 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 (cria pastas e
transfere msgs de uma pasta para outra, recupera parte de uma
mensagem MIME multiparte)
❍ HTTP: Hotmail , Yahoo! Mail, Webmail, etc.

2a: Camada de Aplicação 61

Protocolo POP3
•Conexão na porta 110 S: +OK POP3 server ready
C: user ana
•Baixa e-mails para máquina atual S: +OK
C: pass faminta
fase de autorização S: +OK user successfully logged on

❒ comandos do cliente: C: list

❍ user: declara nome S: 1 498
❍ pass: senha S: 2 912
S: .
❒ servidor responde
C: retr 1
❍ +OK
S: <message 1 contents>
❍ -ERR S: .
fase de transferência, cliente: C: dele 1
C: retr 2
❒ list: lista números das msgs
S: <message 1 contents>
❒ retr: recupera msg por número S: .
❒ dele: apaga msg C: dele 2
❒ quit C: quit
S: +OK POP3 server signing off
2a: Camada de Aplicação 62
POP3 e IMAP
Mais sobre o POP3 IMAP
❒ O exemplo anterior ❒ Mantém todas as
usa o modo “download mensagens num único
e delete”. lugar: o servidor
❒ Bob não pode reler as ❒ Permite ao usuário
mensagens se mudar organizar as mensagens
de cliente em pastas
❒ “Download-e- ❒ O IMAP mantém o estado
mantenha”: copia as do usuário entre sessões:
mensagens em clientes ❍ nomes das pastas e
diferentes mapeamentos entre as IDs
das mensagens e o nome da
❒ POP3 não mantém
pasta
estado entre conexões
2a: Camada de Aplicação 63
 FIM
❒ Bons estudos!

❒ Martony Demes