Capítulo 2: Camada de Aplicação

Baseado nos slides de Kurose e Ross

2: Camada de Aplicação 1
Capítulo 2: Roteiro
r 2.1 Princípios de r 2.6 Aplicações P2P
aplicações de rede r 2.7 Programação e
r 2.2 A Web e o HTTP desenvolvimento de
r 2.3 Transferência de aplicações com TCP
arquivo: FTP r 2.8 Programação de
r 2.4 Correio Eletrônico sockets com UDP
na Internet
r 2.5 DNS: o serviço de
diretório da Internet

2: Camada de Aplicação 2
Capítulo 2: Camada de Aplicação
Metas do capítulo: r aprender sobre protocolos
r 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 m HTTP
m modelos de serviço da
m FTP
camada de transporte
m paradigma cliente m SMTP/ POP3/ IMAP
servidor m DNS
m paradigma peer-to- r Criar aplicações de rede
peer
m programação usando a API
de sockets

2: Camada de Aplicação 3
Algumas aplicações de rede
r Correio eletrônico r Streaming de vídeos
r A Web armazenados
r Mensagens
(YouTube, Hulu,
instantâneas Netflix)
r Login em computador
r Telefonia por IP
remoto como Telnet e (Skype)
SSH r Videoconferência em
r Compartilhamento de
tempo real
arquivos P2P r Busca
r Jogos multiusuários r ...
em rede r ...

2: Camada de Aplicação 4
Criando uma aplicação de rede
Programas que aplicação
transporte

m Executam em (diferentes) rede

enlace
sistemas finais física

m Comunicam-se através da rede

m p.ex., servidor Web se comunica
com o navegador
Programas não relacionados
ao núcleo da rede
m Dispositivos do núcleo da rede aplicação
não executam aplicações dos aplicação
transporte
transporte
rede
usuários rede enlace
enlace física
m Aplicações nos sistemas finais física

permite rápido desenvolvimento

e disseminação

2: Camada de Aplicação 5
Arquiteturas das aplicações de
rede
r Estruturas possíveis das aplicações:
m Cliente-servidor
m Peer-to-peer (P2P)

2: Camada de Aplicação 6
Arquitetura cliente-servidor
Servidor:
r Sempre ligado
r Endereço IP permanente
r Escalabilidade com data
centers
Clientes:
r Comunicam-se com o servidor
r Podem estar conectados
cliente/servidor
intermitentemente
r Podem ter endereços IP
dinâmicos
r Não se comunicam diretamente
com outros clientes

2: Camada de Aplicação 7
Arquitetura P2P
peer-peer
r Não há servidor sempre ligado
r Sistemas finais arbitrários se
comunicam diretamente
r Pares solicitam serviços de
outros pares e em troca
proveem serviços para outros
parceiros:
m Autoescalabilidade – novos
pares trazem nova capacidade
de serviço assim como novas
demandas por serviços.
r Pares estão conectados
intermitentemente e mudam
endereços IP
m Gerenciamento complexo
2: Camada de Aplicação 8
 Comunicação entre Processos
Processo: programa que Processo cliente:
executa num sistema final processo que inicia a
r processos no mesmo
comunicação
sistema final se comunicam Processo servidor:
usando comunicação processo que espera
interprocessos (definida ser contactado
pelo sistema operacional)
r processos em sistemas r Nota: aplicações com
finais distintos se arquiteturas P2P
comunicam trocando possuem processos
mensagens através da rede clientes e processos
servidores
2: Camada de Aplicação 9
Sockets
r Os processos enviam/ recebem mensagens
para/dos seus sockets
r Um socket é análogo a uma porta
m Processo transmissor envia a mensagem através da porta
m O processo transmissor assume a existência da infra-estrutura
de transporte no outro lado da porta que faz com que a
mensagem chegue ao socket do processo receptor

aplicação aplicação
socket Controlado pelo
processo processo desenvolvedor
da aplicação
transporte transporte
rede rede controlado
enlace pelo SO
enlace Internet
física física

2: Camada de Aplicação 10
Endereçamento de processos
r Para que um processo r O identificador inclui tanto
receba mensagens, ele deve o endereço IP quanto os
possuir um identificador números das portas
r Cada hospedeiro possui um associadas com o processo
endereço IP único de 32 no hospedeiro .
bits r Exemplo de números de
r P: o endereço IP do portas:
hospedeiro no qual o m Servidor HTTP: 80
processo está sendo m Servidor de Correio: 25
executado é suficiente para r Para enviar uma msg HTTP
identificar o processo? para o servidor Web
r Resposta: Não, muitos gaia.cs.umass.edu
processos podem estar m Endereço IP: 128.119.245.12
executando no mesmo m Número da porta: 80
hospedeiro r Mais sobre isto
posteriormente.

2: Camada de Aplicação 11
Os protocolos da camada de
aplicação definem
r Tipos de mensagens Protocolos abertos:
trocadas: r definidos em RFCs
m ex. mensagens de
requisição e resposta r Permitem a
r Sintaxe das mensagens: interoperação
m campos presentes nas r ex, HTTP e SMTP
mensagens e como são
identificados Protocolos proprietários:
r Semântica das msgs: r Ex., Skype
m significado da informação
nos campos
r Regras para quando os
processos enviam e
respondem às mensagens
2: Camada de Aplicação 12
 De que serviços uma aplicação necessita?
Transferência confiável de Vazão (largura de banda)
dados (sensibilidade a
r algumas apls (p.ex., multimídia)
perdas)
requerem quantia mínima de
r algumas apls (p.ex., transf. de vazão para serem “viáveis”
arquivos, transações web)
requerem uma transferência r outras apls (“apls elásticas”)
100% confiável conseguem usar qq quantia de
r outras (p.ex. áudio) podem banda disponível
tolerar algumas perdas
Segurança
Temporização (sensibilidade a r Criptografia, integridade dos
atrasos) dados, ...
r algumas apls (p.ex., telefonia
Internet, jogos interativos)
requerem baixo retardo para
serem “viáveis”

2: Camada de Aplicação 13
 Requisitos de aplicações de rede selecionadas

Largura de Banda Sensibilidade

Aplicação Perdas ao atraso

transferência de arqs sem perdas elástica não

correio sem perdas elástica não
documentos Web sem perdas elástica não
áudio/vídeo em tolerante áudio: 5kbps-1Mbps sim, 100’s mseg
tempo real vídeo:10kbps-5Mbps
áudio/vídeo gravado tolerante Igual acima sim, alguns segs
jogos interativos tolerante Alguns kbps-10Mbps sim, 100’s mseg
mensagem instantânea sem perdas elástica sim e não

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

2: Camada de Aplicação 15
 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
Web HTTP [RFC 2616] TCP
transferência de arquivos FTP [RFC 959] TCP
streaming multimídia HTTP (ex. Youtube) TCP ou UDP
RTP [RFC 1889]
telefonia Internet SIP, RTP, proprietário TCP ou UDP
(ex., Skype)

2: Camada de Aplicação 16
Tornando o TCP seguro
TCP & UDP SSL está na camada de
r Sem criptografia aplicação
r Senhas em texto aberto
r Aplicações usam
enviadas aos sockets
atravessam a Internet em bibliotecas SSL, que
texto aberto “falam” com o TCP
SSL API do socket SSL
r Provê conexão TCP r Senhas em texto
criptografada
aberto enviadas ao
r Integridade dos dados
socket atravessam a
r Autenticação do ponto
rede criptografadas
terminal
r Vide Capítulo 7

2: Camada de Aplicação 17
Capítulo 2: Roteiro
r 2.1 Princípios de r 2.6 Aplicações P2P
aplicações de rede r 2.7 Programação e
r 2.2 A Web e o HTTP desenvolvimento de
r 2.3 Transferência de aplicações com TCP
arquivo: FTP r 2.8 Programação de
r 2.4 Correio Eletrônico sockets com UDP
na Internet
r 2.5 DNS: o serviço de
diretório da Internet

2: Camada de Aplicação 18
A Web e o HTTP
Primeiro uma revisão...
r Páginas Web consistem de objetos
r um 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

2: Camada de Aplicação 19
Protocolo HTTP

HTTP: hypertext
transfer protocol
r protocolo da camada de PC executando
aplicação da Web Explorer

r modelo cliente/servidor
m cliente: browser que
pede, recebe (usando o Servidor
protocolo HTTP) e executando
“visualiza” objetos Web servidor
Web Apache
m servidor: servidor Web
envia (usando o
iphone executando
protocolo HTTP) o navegador Safari
objetos em resposta a
pedidos
2: Camada de Aplicação 20
Mais sobre o protocolo HTTP
Usa serviço de transporte HTTP é “sem estado”
TCP: r servidor não mantém
informação sobre
r cliente inicia conexão TCP pedidos anteriores do
(cria socket) ao servidor, cliente
porta 80
Nota
r servidor aceita conexão TCP Protocolos que mantêm
do cliente “estado” são complexos!
r mensagens HTTP (mensagens r história passada (estado)
do protocolo da camada de tem que ser guardada
apl) trocadas entre browser r Caso caia servidor/cliente,
(cliente HTTP) e servidor suas visões do “estado”
Web (servidor HTTP) podem ser inconsistentes,
r encerra conexão TCP devem ser reconciliadas

2: Camada de Aplicação 21
Conexões HTTP
HTTP não persistente HTTP persistente
r No máximo um objeto r Múltiplos objetos
é enviado numa podem ser enviados
conexão TCP sobre uma única
m A conexão é então conexão TCP entre
encerrada cliente e servidor
r Baixar múltiplos
objetos requer o uso
de múltiplas conexões

2: Camada de Aplicação 22
 Exemplo de HTTP não persistente
Supomos que usuário digita a URL (contém texto,
www.algumaUniv.br/algumDepartmento/inicial.index 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) 3. servidor http recebe mensagem
através do socket da de pedido, formula mensagem
conexão TCP. A mensagem de resposta contendo objeto
indica que o cliente deseja solicitado e envia a mensagem
receber o objeto via socket
algumDepartamento/inicial.
tempo index
2: 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, visualiza html.
Analisando arquivo html,
encontra 10 objetos jpeg
referenciados

6. Passos 1 a 5 repetidos para

cada um dos 10 objetos jpeg
tempo

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

2: Camada de Aplicação 25
HTTP persistente
Problemas com o HTTP não HTTP persistente
persistente: r o servidor deixa a conexão
r requer 2 RTTs para cada aberta após enviar a
objeto resposta
r SO aloca recursos do r mensagens HTTP seguintes
hospedeiro (overhead) para entre o mesmo
cada conexão TCP cliente/servidor são
r os browser enviadas nesta conexão
freqüentemente abrem aberta
conexões TCP paralelas r o cliente envia os pedidos
para recuperar os objetos logo que encontra um
referenciados objeto referenciado
r pode ser necessário apenas
um RTT para todos os
objetos referenciados

2: Camada de Aplicação 26
 Mensagem de requisição HTTP

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
GET /index.html HTTP/1.1\r\n
(comandos GET, Host: www-net.cs.umass.edu\r\n
POST, HEAD) User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
linhas de Accept-Language: en-us,en;q=0.5\r\n
cabeçalho Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
Carriage return, Connection: keep-alive\r\n
line feed \r\n
indicam fim
de mensagem
2: Camada de Aplicação 27
Mensagem de requisição HTTP:
formato geral

2: Camada de Aplicação 28
Enviando conteúdo de formulário

Método POST :
r Páginas Web
freqüentemente Método URL:
contêm formulário de r Usa o método GET
entrada r Conteúdo é enviado
r Conteúdo é enviado para o servidor no
para o servidor no campo URL:
corpo da mensagem

www.somesite.com/animalsearch?key=monkeys&bananas

2: Camada de Aplicação 29
Tipos de métodos
HTTP/1.0 HTTP/1.1
r GET r GET, POST, HEAD
r POST r PUT
r HEAD m Upload de arquivo
contido no corpo da
m Pede para o servidor
mensagem para o
não enviar o objeto
caminho especificado no
requerido junto com a
campo URL
resposta
r DELETE
m Exclui arquivo
especificado no campo
URL

2: Camada de Aplicação 30
 Mensagem de resposta HTTP

linha de status
(protocolo,
código de status, HTTP/1.1 200 OK\r\n
Connection close\r\n
frase de status)
Date: Thu, 07 Jul 2007 12:00:15 GMT\r\n
Server: Apache/1.3.0 (Unix)\r\n
linhas de Last-Modified: Sun, 6 May 2007 09:23:24 GMT\r\n
cabeçalho Content-Length: 6821\r\n
Content-Type: text/html\r\n
\r\n
dados dados dados dados ...
dados, p.ex.,
arquivo html
solicitado

2: Camada de Aplicação 31
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
2: Camada de Aplicação 32
Experimente você com HTTP (do lado
cliente)
1. Use cliente telnet para seu servidor WWW favorito:
telnet cis.poly.edu 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 /~ross/ HTTP/1.1 Digitando isto (deve teclar
Host: cis.poly.edu 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 !

(ou use Wireshark para ver as msgs de pedido/resposta HTTP
capturadas)
2: Camada de Aplicação 33
Cookies: manutenção do “estado” da
conexão
Muitos dos principais sítios Exemplo:
Web usam cookies m Suzana acessa a
Quatro componentes: Internet sempre do
1) linha de cabeçalho do mesmo PC
cookie na mensagem de
m 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 m Quando os pedidos
no host do usuário e iniciais HTTP chegam no
gerenciado pelo browser sítio, o sítio cria
do usuário • uma ID única
4) BD de retaguarda no sítio • uma entrada para a ID no
Web BD de retaguarda

2: Camada de Aplicação 34
 Cookies: manutenção do “estado” (cont.)

cliente servidor
arquivo de msg usual pedido http servidor
Cookies
resposta usual http + cria a ID 1678
ebay: 8734
Set-cookie: 1678 para o usuário

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

2: Camada de Aplicação 35
Cookies (continuação)
nota
O que os cookies podem obter: Cookies e privacidade:
r autorização r cookies permitem que os
sítios aprendam muito
r carrinhos de compra sobre você
r recomendações r você pode fornecer nome e
r estado da sessão do usuário e-mail para os sítios
(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
2: Camada de Aplicação 36
 Cache Web (servidor proxy)
Meta: atender pedido do cliente sem envolver servidor de origem
r usuário configura Servidor
browser: acessos Web via de origem
proxy cliente
Servidor
r cliente envia todos
pedidos HTTP ao proxy proxy
m se objeto estiver no
cache do proxy, este o
devolve imediatamente
na resposta HTTP
m senão, solicita objeto do
servidor de origem,
depois devolve resposta
HTTP ao cliente cliente
Servidor
de origem

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

2: Camada de Aplicação 38
Exemplo de cache (1) Servidores
de origem

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

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

2: Camada de Aplicação 40
Exemplo de cache (3) Servidores
de origem

Instale uma cache

r Assuma que a taxa de acerto
Internet
seja de 0,4 pública
Conseqüências
r 40% dos pedidos serão
atendidos quase que
imediatamente enlace de acesso
r 60% dos pedidos serão servidos 1,5 Mbps
pelos servidores de origem
rede da
r Utilização do canal de acesso é instituição
reduzido para 60%, resultando LAN 10 Mbps
em atrasos desprezíveis (ex. 10
mseg)
r 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

2: Camada de Aplicação 41
 GET condicional
r Meta: não enviar objeto se cache servidor
cliente já tem (no cache)
versão atual msg de pedido http
m Sem atraso para transmissão
If-modified-since: objeto
do objeto
<date>
não
m Diminui a utilização do enlace resposta http modificado
HTTP/1.0
r cache: especifica data da 304 Not Modified
cópia no cache no pedido
HTTP
If-modified-since:
msg de pedido http
<date>
If-modified-since:
r servidor: resposta não <date> objeto
contém objeto se cópia no modificado
resposta http
cache for atual: HTTP/1.1 200 OK
HTTP/1.0 304 Not …
Modified <data>
2: Camada de Aplicação 42
Capítulo 2: Roteiro
r 2.1 Princípios de r 2.6 Aplicações P2P
aplicações de rede r 2.7 Programação e
r 2.2 A Web e o HTTP desenvolvimento de
r 2.3 Transferência de aplicações com TCP
arquivo: FTP r 2.8 Programação de
r 2.4 Correio Eletrônico sockets com UDP
na Internet
r 2.5 DNS: o serviço de
diretório da Internet

2: Camada de Aplicação 43
FTP: o protocolo de transferência
de arquivos
transferência
Interface cliente do arquivo servidor
do usuário FTP
FTP
FTP
usuário
na sistema de sistema de
estação arquivos arquivos
local remoto

r transferir arquivo de/para hospedeiro remoto

r modelo cliente/servidor
m cliente: lado que inicia transferência (pode ser de ou
para o sistema remoto)
m servidor: hospedeiro remoto
r ftp: RFC 959
r servidor ftp: porta 21
2: Camada de Aplicação 44
FTP: conexões separadas p/ controle, dados
r cliente FTP contata servidor
FTP na porta 21, conexão de controle
especificando o TCP como TCP, porta 21
protocolo de transporte
r O cliente obtém autorização conexão de dados
através da conexão de cliente TCP, porta 20 servidor
controle FTP FTP
r O cliente consulta o
diretório remoto enviando r O servidor abre uma segunda
comandos através da conexão TCP para transferir
conexão de controle outro arquivo
r Quando o servidor recebe r Conexão de controle: “fora da
um comando para a faixa”
transferência de um arquivo,
r Servidor FTP mantém o
ele abre uma conexão de
dados TCP para o cliente “estado”: diretório atual,
autenticação anterior
r Após a transmissão de um
arquivo o servidor fecha a
2: Camada de Aplicação
conexão 45
 FTP: comandos, respostas

Comandos típicos: Códigos de retorno típicos

r enviados em texto ASCII r código e frase de status (como
pelo canal de controle para http)
r USER nome r 331 Username OK, password
required
r PASS senha
r 125 data connection
r LIST devolve lista de already open; transfer
arquivos no diretório atual starting
r RETR arquivo recupera r 425 Can’t open data
(lê) arquivo remoto connection
452 Error writing file
r STOR arquivo armazena r

(escreve) arquivo no
hospedeiro remoto
2: Camada de Aplicação 46
Capítulo 2: Roteiro
r 2.1 Princípios de r 2.6 Aplicações P2P
aplicações de rede r 2.7 Programação e
r 2.2 A Web e o HTTP desenvolvimento de
r 2.3 Transferência de aplicações com TCP
arquivo: FTP r 2.8 Programação de
r 2.4 Correio Eletrônico sockets com UDP
na Internet
r 2.5 DNS: o serviço de
diretório da Internet

2: Camada de Aplicação 47
 fila de
Correio Eletrônico mensagens
de saída
caixa de
agente correio do usuário
Três grandes componentes: de
usuário
r agentes de usuário (UA) servidor agente
r servidores de correio de correio de
usuário
r simple mail transfer protocol:
SMTP
SMTP
servidor
de correio agente
Agente de Usuário SMTP de
usuário
r a.k.a. “leitor de correio”
r compor, editar, ler mensagens
SMTP
agente
de correio servidor de
de correio usuário
r p.ex., Outlook, Thunderbird,
cliente de mail do iPhone
agente
r mensagens de saída e chegando de
são armazenadas no servidor usuário
agente
de
usuário
2: Camada de Aplicação 48
Correio Eletrônico: servidores de correio
agente
Servidores de correio de
usuário
r caixa de correio contém servidor agente
mensagens de chegada de correio de
(ainda não lidas) p/ usuário usuário

r fila de mensagens contém SMTP

servidor
mensagens de saída (a serem de correio
enviadas) SMTP
r protocolo SMTP entre
servidores de correio para SMTP
transferir mensagens de agente
servidor de
correio usuário
de correio
m cliente: servidor de
correio que envia agente
m “servidor”: servidor de de
usuário
correio que recebe agente
de
usuário
2: Camada de Aplicação 49
Correio Eletrônico:
SMTP [RFC 2821]
r usa TCP para a transferência confiável de msgs do correio do
cliente ao servidor, porta 25
r transferência direta: servidor remetente ao servidor
receptor
r três fases da transferência
m handshaking (saudação)
m transferência das mensagens
m encerramento
r interação comando/resposta (como o HTTP e o FTP)
m comandos: texto ASCII
m resposta: código e frase de status

r mensagens precisam ser em ASCII de 7-bits

2: Camada de Aplicação 50
Gerência da Porta 25

http://antispam.br/

2: Camada de Aplicação 51
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
[email protected] da conexão TCP
2) O UA de Alice envia a 5) O servidor de correio de
mensagem para o seu Bob coloca a mensagem na
servidor de correio; a
mensagem é colocada na caixa de entrada de Bob
fila de mensagens 6) Bob chama o seu UA para
3) O lado cliente do SMTP ler a mensagem
abre uma conexão TCP com
o servidor de correio de
Bob

2: Camada de Aplicação 52
Interação SMTP típica
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <[email protected]>
S: 250 [email protected] ... Sender ok
C: RCPT TO: <[email protected]>
S: 250 [email protected] ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

2: Camada de Aplicação 53
Experimente uma interação SMTP:

r telnet nomedoservidor 25
r veja resposta 220 do servidor
r entre comandos HELO, MAIL FROM, RCPT TO,
DATA, QUIT

estes comandos permitem que você envie correio sem

usar um cliente (leitor de correio)

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

2: Camada de Aplicação 55
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:
r linhas de cabeçalho, p.ex.,
To:
m
corpo
m From:
m Subject:
diferentes dos comandos de
smtp FROM, RCPT TO
r corpo
m a “mensagem”, somente de
caracteres ASCII

2: Camada de Aplicação 56
 Formato de uma mensagem: extensões para
multimídia
r MIME: multimedia mail extension, RFC 2045, 2056
r linhas adicionais no cabeçalho da msg declaram tipo do
conteúdo MIME

From: [email protected]
versão MIME To: [email protected]
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

2: Camada de Aplicação 57
Tipos MIME
Content-Type: tipo/subtipo; parâmetros

Text Audio
r subtipos exemplos: plain, r subtipos exemplos : basic
html (8-bit codificado mu-law),
r charset=“iso-8859-1”, 32kadpcm (codificação 32
ascii kbps)
Application
Image r outros dados que precisam
r subtipos exemplos : jpeg, ser processados por um
gif leitor para serem
“visualizados”
Video r subtipos exemplos :
msword, octet-stream
r subtipos exemplos : mpeg,
quicktime

2: Camada de Aplicação 58
Tipo Multipart
From: [email protected]
To: [email protected]
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--

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

r SMTP: entrega/armazenamento no servidor do receptor

r 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: gmail, Hotmail , Yahoo! Mail, etc.

2: Camada de Aplicação 60
Protocolo POP3 S: +OK POP3 server ready
C: user ana
fase de autorização S: +OK
C: pass faminta
r comandos do cliente: S: +OK user successfully logged on
m user: declara nome
m pass: senha
C: list
S: 1 498
r servidor responde S: 2 912
m +OK S: .
m -ERR C: retr 1
fase de transação, cliente: S:
S:
<message 1 contents>
.
r list: lista números das C: dele 1
msgs C: retr 2
r retr: recupera msg por S: <message 1 contents>
número S: .
r dele: apaga msg C: dele 2
r quit C: quit
S: +OK POP3 server signing off
2: Camada de Aplicação 61
POP3 (mais) e IMAP
Mais sobre o POP3 IMAP
r O exemplo anterior r Mantém todas as
usa o modo “download mensagens num único
e delete”. lugar: o servidor
r Bob não pode reler as r Permite ao usuário
mensagens se mudar organizar as mensagens
de cliente em pastas
r “Download-e- r O IMAP mantém o estado
mantenha”: copia as do usuário entre sessões:
mensagens em clientes m nomes das pastas e
diferentes mapeamentos entre as IDs
das mensagens e o nome da
r POP3 não mantém
pasta
estado entre conexões
2: Camada de Aplicação 62
Capítulo 2: Roteiro
r 2.1 Princípios de r 2.6 Aplicações P2P
aplicações de rede r 2.7 Programação e
r 2.2 A Web e o HTTP desenvolvimento de
r 2.3 Transferência de aplicações com TCP
arquivo: FTP r 2.8 Programação de
r 2.4 Correio Eletrônico sockets com UDP
na Internet
r 2.5 DNS: o serviço de
diretório da Internet

2: Camada de Aplicação 63
DNS: Domain Name System

Pessoas: muitos Domain Name System:

identificadores: r base de dados distribuída
m CPF, nome, no. da implementada na hierarquia de
Identidade muitos servidores de nomes
hospedeiros, roteadores r protocolo de camada de
aplicação permite que
Internet : hospedeiros, roteadores,
m endereço IP (32 bit) - servidores de nomes se
usado p/ endereçar comuniquem para resolver nomes
datagramas (tradução endereço/nome)
m “nome”, ex., m nota: função imprescindível
www.yahoo.com - usado da Internet implementada
por gente como protocolo de camada de
P: como mapear entre aplicação
nome e endereço IP? m complexidade na borda da
rede
2: Camada de Aplicação 64
 DNS (cont.)
Serviços DNS Por que não centralizar o
r Tradução de nome de DNS?
hospedeiro para IP r ponto único de falha
r volume de tráfego
r Apelidos para
r base de dados
hospedeiros (aliasing) centralizada e distante
Nomes canônicos e apelidos
r manutenção (da BD)
m

r Apelidos para
servidores de e-mail Não é escalável!
r Distribuição de carga
m Servidores Web replicados:
conjunto de endereços IP
para um mesmo nome

2: Camada de Aplicação 65
Base de Dados Hierárquica e
Distribuída
Root DNS Servers

com DNS servers org DNS servers edu DNS servers

yahoo.com amazon.com pbs.org poly.edu umass.edu

DNS serversDNS servers DNS servers DNS serversDNS servers

Cliente quer IP para www.amazon.com; 1a aprox:

r Cliente consulta um servidor raiz para encontrar um servidor
DNS .com
r Cliente consulta servidor DNS .com para obter o servidor DNS
para o domínio amazon.com
r Cliente consulta servidor DNS do domínio amazon.com para
obter endereço IP de www.amazon.com

2: Camada de Aplicação 66
 DNS: Servidores raiz
r procurado por servidor local que não consegue resolver o
nome
r servidor raiz:
m procura servidor oficial se mapeamento desconhecido
m obtém tradução
m devolve mapeamento ao servidor local
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also Los Angeles)
d U Maryland College Park, MD
k RIPE London (also Amsterdam,
g US DoD Vienna, VA Frankfurt)
h ARL Aberdeen, MD
j Verisign, ( 11 locations) i Autonomica, Stockholm
(plus 3 other locations)
m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA (and 17 other locations)
13 servidores de
nome raiz em todo o
b USC-ISI Marina del Rey, CA mundo
l ICANN Los Angeles, CA

2: Camada de Aplicação 67
Servidores TLD e Oficiais
r Servidores de nomes de Domínio de Alto Nível (TLD):
m servidores DNS responsáveis por domínios com, org, net,
edu, etc, e todos os domínios de países como br, uk, fr, ca,
jp.
m Network Solutions mantém servidores para domínio .com
m NIC.br (Registro .br) para domínio .br

r Servidores de nomes com autoridade:

m servidores DNS das organizações, provendo mapeamentos
oficiais entre nomes de hospedeiros e endereços IP para os
servidores da organização (e.x., Web e correio).
m Podem ser mantidos pelas organizações ou pelo provedor de
acesso

2: Camada de Aplicação 68
Domínios
Registrados
por DPN
(Domínio de
Primeiro Nível)
06/02/13

2: Camada de Aplicação 69
Servidor DNS Local
r Não pertence necessariamente à hierarquia
r Cada ISP (ISP residencial, companhia,
universidade) possui um.
m Também chamada do “servidor de nomes default”
r Quanto um hospedeiro faz uma consulta DNS, a
mesma é enviada para o seu servidor DNS local
m Possui uma cache local com pares de tradução
nome/endereço recentes (mas podem estar
desatualizados!)
m Atua como um intermediário, enviando consultas para a
hierarquia.

2: Camada de Aplicação 70
Exemplo de resolução servidor raiz
de nome pelo DNS
2
r Hospedeiro em 3
cis.poly.edu quer servidor TLD
4
endereço IP para
gaia.cs.umass.edu 5
servidor local
consulta interativa: dns.poly.edu
r servidor consultado 7 6
1 8
responde com o nome
de um servidor de servidor com autoridade
contato dns.cs.umass.edu

r “Não conheço este solicitante

nome, mas pergunte cis.poly.edu

para esse servidor” gaia.cs.umass.edu

2: Camada de Aplicação 71
Exemplo de resolução
de nome pelo DNS servidor DNS raiz
consulta recursiva: 2 3
r transfere a 6
responsabilidade de
7
resolução do nome servidor TLD
para o servidor de
nomes contatado servidor DNS local
r carga pesada? dns.poly.edu 5 4
1 8

servidor DNS com autoridade

dns.cs.umass.edu
solicitante
cis.poly.edu

gaia.cs.umass.edu

2: Camada de Aplicação 72
DNS: uso de cache, atualização de dados
r uma vez que um servidor qualquer aprende um mapeamento,
ele o coloca numa cache local
m entradas na cache são sujeitas a temporização
(desaparecem) depois de um certo tempo (TTL)
r Entradas na cache podem estar desatualizadas (tradução
nome/endereço do tipo melhor esforço!)
m Se o endereço IP de um nome de host for alterado, pode não
ser conhecido em toda a Internet até que todos os TTLs
expirem
r estão sendo projetados pela IETF mecanismos de
atualização/notificação dos dados
m RFCs 2136, 3007, 4033/4/5
m http://www.ietf.org/html.charters/dnsext-charter.html

2: Camada de Aplicação 73
Registros DNS
DNS: BD distribuído contendo registros de recursos (RR)
formato RR: (nome, valor, tipo, ttl)

r Tipo=A r Tipo=CNAME
m nome é nome de hospedeiro m nome é nome alternativo
m valor é o seu endereço IP (alias) para algum nome
“canônico” (verdadeiro)
r Tipo=NS
m valor é o nome canônico
m nome é domínio (p.ex.
foo.com.br)
m valor é endereço IP de
servidor oficial de nomes r Tipo=MX
para este domínio m nome é domínio
m valor é nome do servidor de
correio para este domínio
2: Camada de Aplicação 74
DNS: protocolo e mensagens

protocolo DNS: mensagens de pedido e resposta,

ambas com o mesmo formato de mensagem
cabeçalho de msg
r identificação: ID de 16 bit para
pedido, resposta ao pedido usa
mesmo ID
r flags:
m pedido ou resposta
m recursão desejada
m recursão permitida
m resposta é oficial

2: Camada de Aplicação 75
DNS: protocolo e mensagens

2: Camada de Aplicação 76
Inserindo registros no DNS
r Exemplo: acabou de criar a empresa “Network
Utopia”
r Registra o nome netutopia.com.br em uma entidade
registradora (e.x., Registro.br)
m Tem de prover para a registradora os nomes e endereços IP
dos servidores DNS oficiais (primário e secundário)
m Registradora insere dois RRs no servidor TLD .br:

(netutopia.com.br, dns1.netutopia.com.br, NS)

(dns1.netutopia.com.br, 212.212.212.1, A)

r Põe no servidor oficial um registro do tipo A para

www.netutopia.com.br e um registro do tipo MX para
netutopia.com.br

2: Camada de Aplicação 77
Ataques ao DNS
Ataques DDoS Ataques de redirecionamento
r Bombardeia os servidores r Pessoa no meio
raiz com tráfego m Intercepta as consultas
m Até o momento não r Envenenamento do DNS
tiveram sucesso
m Envia respostas falsas
m Filtragem do tráfego para o servidor DNS que
m Servidores DNS locais as coloca em cache
cacheiam os IPs dos Exploração do DNS para
servidores TLD,
DDoS
permitindo que os
servidores raízes não r Envia consultas com
sejam consultados endereço origem
r Bombardeio aos servidores falsificado: IP alvo
TLD r Requer amplificação
m Potencialmente mais
perigoso
2: Camada de Aplicação 78
Capítulo 2: Roteiro
r 2.1 Princípios de r 2.6 Aplicações P2P
aplicações de rede r 2.7 Programação e
r 2.2 A Web e o HTTP desenvolvimento de
r 2.3 Transferência de aplicações com TCP
arquivo: FTP r 2.8 Programação de
r 2.4 Correio Eletrônico sockets com UDP
na Internet
r 2.5 DNS: o serviço de
diretório da Internet

2: Camada de Aplicação 79
Arquitetura P2P pura
r sem servidor sempre ligado
r sistemas finais arbitrários se
comunicam diretamente
r pares estão conectados de par-par
forma intermitente e mudam
seus endereços IP

r Exemplos:
m Distribuição de arquivos
(BitTorrent)
m Streaming (KanKan)
m VoIP (Skype)

2: Camada de Aplicação 80
 Distribuição de Arquivo: C/S x P2P
Pergunta: Quanto tempo leva para distribuir um arquivo
de um servidor para N pares?
m Capacide de upload/download de um par é um recurso limitado

Servidor
us: banda de upload
do servidor
u1 d1 u2
us d2 ui: banda de upload
Arquivo, do par i
tamanho F di: banda de
dN
Rede (com download do par i
uN banda abundante)

2: Camada de Aplicação 81
 Tempo de distribuição do arquivo: C/S
r transmissão do servidor: deve enviar F
sequencialmente N cópias do us
arquivo: di
m Tempo para enviar uma cópia = F/us
rede
m Tempo para enviar N cópias = NF/us ui
r cliente: cada cliente deve fazer o
download de uma cópia do arquivo
m dmin = taxa mínima de download
m Tempo de download para usuário com
menor taxa: F/dmin

Tempo para distribuir F

para N clientes usando
abordagem cliente/servidor Dcs ≥ max { NF/us, F/dmin }

cresce linearmente com N

2: Camada de Aplicação 82
Tempo de distribuição do arquivo: P2P
r transmissão do servidor: deve
enviar pelo menos uma cópia: F
m tempo para enviar uma cópia: F/us us
r cliente: cada cliente deve di
baixar uma cópia do arquivo network
ui
m Tempo de download para usuário
com menor taxa: F/dmin
r clientes: no total devem baixar NF bits
m Taxa máxima de upload : us + Su i

tempo para distribuir

F para N clientes DP2P > max{F/us,,F/dmin,,NF/(us + Sui)}
usando abordagem P2P

cresce linearmente com N …

… assim como este, cada par traz capacidade de serviço
2: Camada de Aplicação 83
Cliente-servidor x P2P: Exemplo
Taxa de upload do cliente= u, F/u = 1 hora, us = 10u, dmin ≥ us

3.5
P2P
Minimum Distribution Time

3
Client-Server
2.5

1.5

0.5

0
0 5 10 15 20 25 30 35

N
2: Camada de Aplicação 84
 Distribuição de arquivo P2P:
BitTorrent
r arquivos divididos em blocos de 256kb
r Pares numa torrente enviam/recebem blocos do arquivo

tracker: registra pares

participantes de uma torrente: grupo de
pares trocando
torrente blocos de um arquivo

Alice chega…
… obtém lista de
parceiros do tracker
… e começa a trocar blocos
de arquivos com os
parceiros na torrente
2: Camada de Aplicação 85
 Distribuição de arquivo P2P:
BitTorrent
r par que se une à torrente:
m não tem nenhum bloco, mas irá
acumulá-los com o tempo
m registra com o tracker para
obter lista dos pares, conecta a
um subconjunto de pares
(“vizinhos”)
r enquanto faz o download, par carrega blocos para outros pares
r par pode mudar os parceiros com os quais troca os blocos
r pares podem entrar e sair
r quando o par obtiver todo o arquivo, ele pode (egoisticamente)
sair ou permanecer (altruisticamente) na torrente

2: Camada de Aplicação 86
BitTorrent: pedindo, enviando blocos de
arquivos
Enviando blocos: toma lá, dá cá!
obtendo blocos:
r Alice envia blocos para os
r num determinado instante,
quatro vizinhos que estejam
pares distintos possuem
lhe enviando blocos na taxa
diferentes subconjuntos de
mais elevada
blocos do arquivo
m outros pares foram sufocados por
r periodicamente, um par Alice
(Alice) pede a cada vizinho m Reavalia os 4 mais a cada 10 segs
a lista de blocos que eles r a cada 30 segs: seleciona
possuem aleatoriamente outro par,
r Alice envia pedidos para os começa a enviar blocos
pedaços que ainda não tem m “optimistically unchoked”
m Primeiro os mais raros m o par recém escolhido pode se
unir aos 4 mais

2: Camada de Aplicação 87
BitTorrent: toma lá, dá cá!
(1) Alice “optimistically unchokes” Bob
(2) Alice se torna um dos quatro melhores provedores de Bob;
Bob age da mesma forma
(3) Bob se torna um dos quatro melhores provedores de Alice

Com uma taxa de upload mais

alta, pode encontrar melhores
parceiros de troca e obter o
arquivo mais rapidamente!
2: Camada de Aplicação 88
Estudo de caso P2P: Skype
Skype clients (SC)
r inerentemente P2P:
comunicação entre pares
de usuários.
r protocolo proprietário da Skype
login server Supernode
camada de aplicação
(SN)
(inferido através de
engenharia reversa)
r overlay hierárquico com
SNs
r Índice mapeia nomes dos
usuários a endereços IP;
distribuído através dos
SNs

2: Camada de Aplicação 89
Pares como intermediários
(relays)
r Problema quando tanto
Alice como Bob estão
atrás de “NATs”.
m O NAT impede que um
par externo inicie uma
chamada com um par
interno
r Solução:
m Intermediário é escolhido,
usando os SNs de Alice e de
Bob.
m Cada par inicia sessão com o
intermediário
m Pares podem se comunicar
através de NATs através do
intermediário

2: Camada de Aplicação 90
Capítulo 2: Resumo
Nosso estudo sobre aplicações de rede está agora
completo!
r Arquiteturas de aplicações r Protocolos específicos:
m cliente-servidor m HTTP

m P2P m FTP

r Requisitos de serviço das m SMTP, POP, IMAP

aplicações: m DNS

m confiabilidade, banda, atraso m P2P: BitTorrent, DHT

r Modelos de serviço de r Programação de sockets

transporte da Internet
m orientado à conexão,
confiável: TCP
m não confiável, datagramas:
UDP

2: Camada de Aplicação 91
 Capítulo 2: Resumo
Mais importante: aprendemos sobre protocolos

r troca típica de mensagens

Temas importantes:
pedido/resposta r msgs de controle vs. dados
m cliente solicita info ou serviço
m na banda, fora da banda
m servidor responde com dados,
código de status r centralizado vs.
descentralizado
r formatos de mensagens:
r s/ estado vs. c/ estado
m cabeçalhos: campos com info
sobre dados (metadados) r transferência de msgs
m dados: info sendo comunicada confiável vs. não confiável
r “complexidade na borda da
rede”

2: Camada de Aplicação 92