Chapter 2
Application Layer
A note on the use of these ppt slides:
We’re making these slides freely available to all (faculty, students, readers).
They’re in PowerPoint form so you can add, modify, and delete slides
(including this one) and slide content to suit your needs. They obviously
represent a lot of work on our part. In return for use, we only ask the
following:
 If you use these slides (e.g., in a class) in substantially unaltered form,
that you mention their source (after all, we’d like people to use our book!)
 If you post any slides in substantially unaltered form on a www site, that
you note that they are adapted from (or perhaps identical to) our slides, and
note our copyright of this material.
Computer Networking:
A Top Down Approach
Featuring the Internet,
3rd edition.
Jim Kurose, Keith Ross
Addison-Wesley, July
2004.
Thanks and enjoy! JFK/KWR
All material copyright 1996-2006
J.F Kurose and K.W. Ross, All Rights Reserved
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



 aprenda sobre protocolos
através do estudo de
protocolos populares da
camada de aplicação:

HTTP
FTP
SMTP/ POP3/ IMAP
DNS
modelos de serviço da

camada de transporte

paradigma cliente

servidor
paradigma peer-to a programação de
peer
aplicações de rede

programação usando a API
de sockets
2a: Camada de Aplicação
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
 2.6 Compartilhamento
de arquivos P2P
 2.7 Programação de
Sockets com TCP
 2.8 Programação de
Sockets com UDP
 2.9 Construindo um
servidor Web
2a: Camada de Aplicação
3
Algumas aplicações de rede
 E-mail
 Voz sobre IP
 Web
 Vídeo conferência em
 Instant messaging
 Login remoto
 Compartilhamento de
arquivos P2P
 Jogos de rede multiusuários
 Vídeo-clipes
armazenados




tempo real
Computação paralela
em larga escala
?
?
?
2a: Camada de Aplicação
4
Criando uma aplicação de rede
Programas que



Executam em diferentes
sistemas finais
Comunicam-se através da rede
p.ex., Web: servidor Web se
comunica com o navegador
aplicação
transporte
rede
enlace
física
Programas não relacionados
ao núcleo da rede


Dispositivos do núcleo da rede
não executam aplicações de
usuários
Aplicações nos sistemas finais
permite rápido desenvolvimento
e disseminação
aplicação
transporte
rede
enlace
física
aplicação
transporte
rede
enlace
física
2a: Camada de Aplicação
5
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
 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 Aplicação
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 Aplicação
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 Aplicação
9
Processos em comunicação
Processo cliente:
Processo: programa que
processo que inicia a
executa num hospedeiro
comunicação
 processos no mesmo
Processo servidor:
hospedeiro se comunicam
processo que espera
usando comunicação
para ser contatado
entre processos definida
pelo sistema operacional
(SO)
 Nota: aplicações com
arquiteturas P2P
 processos em
possuem processos
hospedeiros distintos se
clientes e processos
comunicam trocando
servidores
mensagens através da
rede
2a: Camada de Aplicação
10
Sockets
 Os processos enviam/
recebem mensagens
para/dos seus sockets
 Um socket é análogo a
uma porta


Processo transmissor envia a
mensagem através da porta
O processo transmissor
assume a existência da infraestrutura de transporte no
outro lado da porta que faz
com que a mensagem chegue
ao socket do processo
receptor
host ou
servidor
host ou
servidor
processo
controlado pelo
desenvolvedor da
aplicação
processo
socket
socket
TCP com
buffers,
variáveis
Internet
TCP com
buffers,
variáveis
controlado
pelo SO
 API: (1) escolha do protocolo de transporte; (2)
habilidade para fixar alguns parâmetros (mais sobre
isto posteriormente)
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: 80
Servidor de Correio: 25
 Mais sobre isto
posteriormente.
2a: Camada de Aplicação
12
Os protocolos da camada de
aplicação definem
 Tipos de mensagens
trocadas, ex. mensagens
de pedido e resposta
 Sintaxe dos tipos das
mensagens: campos
presentes nas mensagens
e como são identificados
 Semântica dos campos,
i.e., significado da
informação nos campos
 Regras para quando os
processos enviam e
respondem às mensagens
Protocolos de domínio
público:
 definidos em RFCs
 Permitem a
interoperação
 ex, HTTP e SMTP
Protocolos proprietários:
 Ex., KaZaA
2a: Camada de Aplicação
13
De que serviço de transporte uma
aplicação precisa?
Perda de dados
 algumas apls (p.ex. áudio)
podem tolerar algumas
perdas
 outras (p.ex., transf. de
arquivos, telnet) requerem
transferência 100%
confiável
Largura de banda
 algumas apls (p.ex.,
multimídia) requerem
quantia mínima de banda
para serem “viáveis”
 outras apls (“apls elásticas”)
conseguem usar qq quantia
de banda disponível
Temporização
 algumas apls (p.ex.,
telefonia Internet, jogos
interativos) requerem
baixo retardo para serem
“viáveis”
2a: Camada de Aplicação
14
Requisitos do serviço de transporte de apls comuns
Aplicação
transferência de arqs
correio
documentos WWW
áudio/vídeo de
tempo real
áudio/vídeo gravado
jogos interativos
apls financeiras
Sensibilidade
temporal
Perdas
Banda
sem perdas
sem perdas
sem perdas
tolerante
elástica
elástica
elástica
áudio: 5Kb-1Mb
vídeo:10Kb-5Mb
como anterior
> alguns Kbps
elástica
tolerante
tolerante
sem perdas
não
não
não
sim, 100’s mseg
sim, alguns segs
sim, 100’s mseg
sim e não
2a: Camada de Aplicação
15
Serviços providos por protocolos de
transporte Internet
Serviço TCP:
Serviço UDP:

 transferência de dados não
orientado a 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
confiável entre processos
remetente e receptor
 não provê: estabelecimento
da conexão, confiabilidade,
controle de fluxo, controle
de congestionamento,
garantias temporais ou de
banda mínima
P: Qual é o interesse em ter um
UDP?
2a: Camada de Aplicação
16
Apls Internet: seus protocolos e seus
protocolos de transporte
Aplicação
correio eletrônico
acesso terminal remoto
WWW
transferência de arquivos
streaming multimídia
telefonia Internet
Protocolo da
camada de apl
Protocolo de
transporte usado
SMTP [RFC 2821]
telnet [RFC 854]
HTTP [RFC 2616]
ftp [RFC 959]
proprietário
(p.ex. RealNetworks)
proprietário
(p.ex., Dialpad)
TCP
TCP
TCP
TCP
TCP ou UDP
tipicamente UDP
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
 2.7 Programação de
Sockets com TCP
 2.8 Programação de
Sockets com UDP
 2.9 Construindo um
servidor Web
2a: Camada de Aplicação
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 Aplicação
19
Protocolo HTTP
HTTP: hypertext
transfer protocol
 protocolo da camada de
aplicação da Web
 modelo cliente/servidor
 cliente: browser que
pede, recebe, “visualiza”
objetos Web
 servidor: servidor Web
envia objetos em
resposta a pedidos
 HTTP 1.0: RFC 1945
 HTTP 1.1: RFC 2068
PC executa
Explorer
Servidor
executando
servidor
WWW
do NCSA
Mac executa
Navigator
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
 No máximo um objeto
é enviado numa
conexão TCP
 HTTP/1.0 usa o HTTP
não persistente
HTTP persistente
 Múltiplos objetos
podem ser enviados
sobre uma única
conexão TCP entre
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/inicial.index
(contém texto,
referências a 10
imagens jpeg)
1a. Cliente http inicia conexão
TCP a servidor http (processo)
a www.algumaUniv.br. Porta 80
é padrão para servidor http.
2. cliente http envia mensagem
de pedido de http (contendo
URL) através do socket da
conexão TCP
tempo
1b. servidor http no hospedeiro
www.algumaUniv.br espera por
conexão TCP na porta 80.
“aceita” conexão, avisando ao
cliente
3. servidor http recebe mensagem
de pedido, formula mensagem
de resposta contendo objeto
solicitado
(algumDepartmento/inicial.index),
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, visualiza html.
Analisando arquivo html,
encontra 10 objetos jpeg
referenciados
6. Passos 1 a 5 repetidos para
cada um dos 10 objetos jpeg
tempo
2a: Camada de Aplicação
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
Tempo de resposta:
 um RTT para iniciar a conexão
TCP
 um RTT para o pedido HTTP e
o retorno dos primeiros bytes
da resposta HTTP
 tempo de transmissão do
arquivo
total = 2RTT+tempo de
transmissão
Inicia a conexão
TCP
RTT
solicita
arquivo
tempo para
transmitir
o arquivo
RTT
arquivo
recebido
tempo
tempo
2a: Camada de Aplicação
25
HTTP 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:
 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 do pedido
(comandos GET,
POST, HEAD)
linhas do
cabeçalho
Carriage return,
line feed
indicam fim
de mensagem
GET /somedir/page.html HTTP/1.0
Host: www.someschool.edu
User-agent: Mozilla/4.0
Connection: close
Accept-language:fr
(carriage return (CR), line feed(LF) adicionais)
2a: Camada de Aplicação
27
Mensagem de pedido HTTP: formato
geral
2a: Camada de Aplicação
28
Formato de mensagem HTTP:
resposta
linha de status
(protocolo,
código de status,
frase de status)
linhas de
cabeçalho
dados, p.ex.,
arquivo html
solicitado
HTTP/1.1 200 OK
Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
dados dados dados dados ...
2a: Camada de Aplicação
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 Aplicação
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 /~celio/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 Aplicação
33
Cookies: manutenção do
“estado” da conexão
Muitos dos principais sítios
Web usam cookies
Quatro componentes:
1) linha de cabeçalho do
cookie na mensagem de
resposta HTTP
2) linha de cabeçalho do
cookie na mensagem de
pedido HTTP
3) arquivo do cookie mantido
no host do usuário e
gerenciado pelo browser
do usuário
4) BD de retaguarda no sítio
Web
Exemplo:



Suzana acessa a
Internet sempre do
mesmo PC
Ela visita um sítio
específico de comércio
eletrônico pela primeira
vez
Quando os pedidos
iniciais HTTP chegam no
sítio, o sítio cria uma ID
única e cria uma entrada
para a ID no BD de
retaguarda
2a: Camada de Aplicação
34
Cookies: manutenção do “estado” (cont.)
cliente
arquivo de
Cookies
ebay: 8734
arquivo de
Cookies
amazon: 1678
ebay: 8734
servidor
msg usual pedido http
servidor
resposta usual http +
cria a ID 1678
Set-cookie: 1678 para o usuário
msg usual pedido http
cookie: 1678
resposta usual http
uma semana depois:
arquivo de
Cookies
amazon: 1678
ebay: 8734
msg usual pedido http
cookie: 1678
resposta usual http
ação
específica
do cookie
ação
específica
do cookie
2a: Camada de Aplicação
35
Cookies (continuação)
O que os cookies podem
obter:
 autorização
 carrinhos de compra
 sugestões
 estado da sessão do
usuário (Webmail)
nota
Cookies e privacidade:
 cookies permitem que os
sítios aprendam muito
sobre você
 você pode fornecer nome e
e-mail para os sítios
 mecanismos de busca usam
redirecionamento e cookies
para aprender ainda mais
 agências de propaganda
obtêm perfil a partir dos
sítios visitados
2a: Camada de Aplicação
36
Cache Web (servidor proxy)
Meta: atender pedido do cliente sem envolver servidor de origem
 usuário configura
browser: acessos Web via
proxy
 cliente envia todos
pedidos HTTP ao proxy


se objeto no cache do
proxy, este o devolve
imediatamente na
resposta HTTP
senão, solicita objeto do
servidor de origem,
depois devolve resposta
HTTP ao cliente
cliente
cliente
Servidor
de origem
Servidor
proxy
Servidor
de origem
2a: Camada de Aplicação
37
Mais sobre Caches Web
 Cache atua tanto como
cliente quanto como
servidor
 Tipicamente o cache é
instalado por um ISP
(universidade, empresa,
ISP residencial)
Para que fazer cache Web?
 Redução do tempo de
resposta para os pedidos
do cliente
 Redução do tráfego no
canal de acesso de uma
instituição
 A Internet cheia de caches
permitem que provedores
de conteúdo “pobres”
efetivamente forneçam
conteúdo!
2a: Camada de Aplicação
38
Exemplo de cache (1)
Hipóteses
 Tamanho médio de um objeto =
100.000 bits
 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 volta ao roteador = 2seg
Conseqüências
 Utilização da LAN = 15%
 Utilização do canal de acesso =
100%
 Atraso total = atraso da
Internet + atraso de acesso +
atraso na LAN = 2 seg + minutos
+ milisegundos
Servidores
de origem
Internet
pública
enlace de acesso
1,5 Mbps
rede da
instituição
LAN 10 Mbps
2a: Camada de Aplicação
39
Exemplo de cache (2)
Solução em potencial
 Aumento da largura de banda
do canal de acesso para, por
exemplo, 10 Mbps
Conseqüências
 Utilização da LAN = 15%
 Utilização do canal de acesso
= 15%
 Atraso total = atraso da
Internet + atraso de acesso
+ atraso na LAN = 2 seg +
msegs + msegs
 Freqüentemente este é uma
ampliação cara
Servidores
de origem
Internet
pública
enlace de acesso
10 Mbps
rede da
instituição
LAN 10 Mbps
2a: Camada de Aplicação
40
Exemplo de cache (3)
Instale uma cache
 Assuma que a taxa de acerto
seja de 0,4
Conseqüências
 40% dos pedidos serão
atendidos quase que
imediatamente
 60% dos pedidos serão servidos
pelos servidores de origem
 Utilização do canal de acesso é
reduzido para 60%, resultando
em atrasos desprezíveis (ex. 10
mseg)
 Atraso total = atraso da
Internet + atraso de acesso +
atraso na LAN = 0,6*2 seg +
0,6*0,01 segs + msegs < 1,3 segs
Servidores
de origem
Internet
pública
enlace de acesso
1,5 Mbps
rede da
instituição
LAN 10 Mbps
cache
institucional
2a: Camada de Aplicação
41
GET condicional
servidor
cache
 Meta: não enviar objeto se
cliente já tem (no cache)
versão atual
 cache: especifica data da
cópia no cache no pedido
http
If-modified-since:
<date>
 servidor: resposta não
contém objeto se cópia no
cache é atual:
HTTP/1.0 304 Not
Modified
msg de pedido http
If-modified-since:
<date>
resposta http
HTTP/1.0
304 Not Modified
objeto
não
modificado
msg de pedido http
If-modified-since:
<date>
resposta http
objeto
modificado
HTTP/1.1 200 OK
…
<data>
2a: Camada de Aplicação
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
 2.6 Compartilhamento
de arquivos P2P
 2.7 Programação de
Sockets com TCP
 2.8 Programação de
Sockets com UDP
 2.9 Construindo um
servidor Web
2a: Camada de Aplicação
43
FTP: o protocolo de transferência
de arquivos
usuário
na
estação
Interface cliente
do usuário FTP
FTP
transferência
do arquivo
FTP
servidor
sistema de
arquivos
remoto
sistema de
arquivos
local
 transferir arquivo de/para hospedeiro remoto
 modelo cliente/servidor

cliente: lado que inicia transferência (pode ser de ou
para o sistema remoto)
 servidor: hospedeiro remoto
 ftp: RFC 959
 servidor ftp: porta 21
2a: Camada de Aplicação
44
FTP: conexões separadas p/ controle, dados
 cliente FTP contata servidor




FTP na porta 21,
especificando o TCP como
protocolo de transporte
O cliente obtém autorização
através da conexão de
controle
O cliente consulta o
diretório remoto enviando
comandos através da
conexão de controle
Quando o servidor recebe
um comando para a
transferência de um arquivo,
ele abre uma conexão de
dados TCP para o cliente
Após a transmissão de um
arquivo o servidor fecha a
conexão
conexão de controle
TCP, porta 21
cliente
FTP
conexão de dados
TCP, porta 20
servidor
FTP
 O servidor abre uma segunda
conexão TCP para transferir
outro arquivo
 Conexão de controle: “fora da
faixa”
 Servidor FTP mantém o
“estado”: diretório atual,
autenticação anterior
2a: Camada de Aplicação
45
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
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
 2.6 Compartilhamento
de arquivos P2P
 2.7 Programação de
Sockets com TCP
 2.8 Programação de
Sockets com UDP
 2.9 Construindo um
servidor Web
2a: Camada de Aplicação
47
Correio Eletrônico
Três grandes componentes:
 agentes de usuário (UA)
 servidores de correio
servidor
de correio
 simple mail transfer protocol:
agente
de
usuário
SMTP
SMTP
Agente de Usuário
SMTP
 a.k.a. “leitor de correio”
 compor, editar, ler mensagens
de correio
servidor
de correio
 p.ex., Eudora, Outlook, elm,
Netscape Messenger
 mensagens de saída e chegando
são armazenadas no servidor
agente
de
usuário
SMTP
fila de
mensagens
de saída
caixa de
correio do usuário
agente
de
usuário
servidor
de correio
agente
de
usuário
agente
de
usuário
agente
de
usuário
2a: Camada de Aplicação
48
Correio Eletrônico: servidores de correio
Servidores de correio
 caixa de correio contém
servidor
de correio
agente
de
usuário
mensagens de chegada
(ainda não lidas) p/ usuário
SMTP
 fila de mensagens contém
mensagens de saída (a serem
enviadas)
SMTP
 protocolo SMTP entre
servidores de correio para
SMTP
transferir mensagens de
servidor
correio
de correio
 cliente: servidor de
correio que envia
agente
de
 “servidor”: servidor de
usuário
correio que recebe
agente
de
usuário
agente
de
usuário
servidor
de correio
agente
de
usuário
2a: Camada de Aplicação
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 Aplicação
50
Cenário: Alice envia uma msg para Bob
1) Alice usa o UA para compor
uma mensagem “para”
[email protected]
2) O UA de Alice envia a
mensagem para o seu
servidor de correio; a
mensagem é colocada na
fila de mensagens
3) O lado cliente do SMTP
abre uma conexão TCP com
o servidor de correio de
Bob
1
user
agent
2
mail
server
3
4) O cliente SMTP envia a
mensagem de Alice através
da conexão TCP
5) O servidor de correio de
Bob coloca a mensagem na
caixa de entrada de Bob
6) Bob chama o seu UA para
ler a mensagem
mail
server
4
5
6
user
agent
2a: Camada de Aplicação
51
Interação SMTP típica
S:
C:
S:
C:
S:
C:
S:
C:
S:
C:
C:
C:
S:
C:
S:
220 doces.br
HELO consumidor.br
250 Hello consumidor.br, pleased to meet you
MAIL FROM: <[email protected]>
250 [email protected]... Sender ok
RCPT TO: <[email protected]>
250 [email protected] ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Voce gosta de chocolate?
Que tal sorvete?
.
250 Message accepted for delivery
QUIT
221 doces.br closing connection
2a: Camada de Aplicação
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 Aplicação
53
SMTP: últimas palavras
 SMTP usa conexões
persistentes
 SMTP requer que a mensagem
(cabeçalho e corpo) sejam em
ASCII de 7-bits
 servidor SMTP usa
CRLF.CRLF para reconhecer o
final da mensagem
Comparação com HTTP
pull (puxar)
 SMTP: push (empurrar)
 HTTP:
 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 de
mensagem enviados numa
mensagem de múltiplas
partes
2a: Camada de Aplicação
54
Formato de uma mensagem
SMTP: protocolo para trocar
msgs de correio
RFC 822: padrão para formato
de mensagem de texto:
 linhas de cabeçalho, p.ex.,



To:
From:
Subject:
cabeçalho
linha em
branco
corpo
diferentes dos comandos de
smtp!
 corpo

a “mensagem”, somente de
caracteres ASCII
2a: Camada de Aplicação
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
versão MIME
método usado
p/ codificar dados
tipo, subtipo de
dados multimídia,
declaração parâmetros
Dados codificados
From: [email protected]
To: [email protected]
Subject: Imagem de uma bela torta
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
2a: Camada de Aplicação
56
Tipos MIME
Content-Type: tipo/subtipo; parâmetros
Text
 subtipos exemplos: plain,
html
 charset=“iso-8859-1”,
ascii
Image
 subtipos exemplos : jpeg,
gif
Video
 subtipos exemplos : mpeg,
Audio
 subtipos exemplos : basic
(8-bit codificado mu-law),
32kadpcm (codificação 32
kbps)
Application
 outros dados que precisam
ser processados por um
leitor para serem
“visualizados”
 subtipos exemplos :
msword, octet-stream
quicktime
2a: Camada de Aplicação
57
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-2a: Camada de Aplicação
58
Protocolos de acesso ao correio
agente
de
usuário
SMTP
SMTP
servidor de correio
do remetente
POP3 ou
IMAP
agente
de
usuário
servidor de correio
do receptor
 SMTP: entrega/armazenamento no servidor do receptor
 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 Aplicação
59
Protocolo POP3
fase de autorização
 comandos do cliente:
user: declara nome
 pass: senha
 servidor responde
 +OK
 -ERR

fase de transação, cliente:
 list: lista números das
msgs
 retr: recupera msg por
número
 dele: apaga msg
 quit
S:
C:
S:
C:
S:
+OK POP3 server ready
user ana
+OK
pass faminta
+OK user successfully logged
C:
S:
S:
S:
C:
S:
S:
C:
C:
S:
S:
C:
C:
S:
list
1 498
2 912
.
retr 1
<message 1 contents>
.
dele 1
retr 2
<message 1 contents>
.
dele 2
quit
+OK POP3 server signing off
2a: Camada de Aplicação
on
60
POP3 (mais) e IMAP
Mais sobre o POP3
 O exemplo anterior
usa o modo “download
e delete”.
 Bob não pode reler as
mensagens se mudar
de cliente
 “Download-emantenha”: copia as
mensagens em clientes
diferentes
 POP3 não mantém
estado entre conexões
IMAP
 Mantém todas as
mensagens num único
lugar: o servidor
 Permite ao usuário
organizar as
mensagens em pastas
 O IMAP mantém o
estado do usuário
entre sessões:

nomes das pastas e
mapeamentos entre as
IDs das mensagens e o
nome da2a:pasta
Camada de Aplicação
61
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
 2.7 Programação de
Sockets com TCP
 2.8 Programação de
Sockets com UDP
 2.9 Construindo um
servidor Web
2a: Camada de Aplicação
62
DNS: Domain Name System
Pessoas: muitos
identificadores:



base de dados distribuída

protocolo de camada de
aplicação permite que
CPF, nome, no. da
Identidade
hospedeiros, roteadores
Internet :

Domain Name System:
endereço IP (32 bit) usado p/ endereçar
datagramas
“nome”, ex.,
jambo.ic.uff.br - usado
por gente
P: como mapear entre
nome e endereço IP?
implementada na hierarquia de
muitos servidores de nomes
hospedeiros, roteadores,
servidores de nomes se
comuniquem para resolver nomes
(tradução endereço/nome)
 nota: função imprescindível
da Internet implementada
como protocolo de camada de
aplicação
 complexidade na borda da
rede
2a: Camada de Aplicação
63
DNS (cont.)
Serviços DNS
 Tradução de nome de
hospedeiro para IP
 Apelidos para
hospedeiros (aliasing)

Nomes canônicos e apelidos
 Apelidos para
servidores de e-mail
 Distribuição de carga

Servidores Web replicados:
conjunto de endereços IP
para um nome canônico
Serviços DNS
 Roda sobre UDP e usa a porta
53


RFCs 1034, 1035
Atualizado em outras RFCs
Por que não centralizar o DNS?
 ponto único de falha
 volume de tráfego
 base de dados centralizada e
distante
 manutenção (da BD)
Não é escalável!
2a: Camada de Aplicação
64
Base de Dados Hierárquica e
Distribuída
Root DNS Servers
com DNS servers
yahoo.com
amazon.com
DNS servers DNS servers
org DNS servers
pbs.org
DNS servers
edu DNS servers
poly.edu
DNS servers
umass.edu
DNS servers
Cliente quer IP para www.amazon.com; 1a aprox:
 Cliente consulta um servidor raiz para encontrar um
servidor DNS .com
 Cliente consulta servidor DNS .com para obter o
servidor DNS para o domínio amazon.com
 Cliente consulta servidor DNS do domínio amazon.com
para obter endereço IP de www.amazon.com
2a: Camada de Aplicação
65
DNS: Servidores raiz
 procurado por servidor local que não consegue resolver o
nome
 servidor raiz:
 procura servidor oficial se mapeamento desconhecido
 obtém tradução
 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
i
Autonomica, Stockholm
j Verisign, ( 11 locations)
(plus 3 other locations)
m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA (and 17 other locations)
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA
13 servidores de
nome raiz em
todo o mundo
2a: Camada de Aplicação
66
Servidores TLD e Oficiais
 Servidores
Top-level domain (TLD) : 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.


Network Solutions mantém servidores para domínio com
FAPESP (Registro .br) para domínio br
 Servidores oficiais: 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).

Podem ser mantidos pelas organizações ou pelo provedor de
acesso
2a: Camada de Aplicação
67
Servidor de Nomes Local
 Não pertence necessariamente à hierarquia
 Cada ISP (ISP residencial, companhia,
universidade) possui um.

Também chamada do “servidor de nomes
default”
 Quanto um hospedeiro faz uma consulta
DNS, a mesma é enviada para o seu
servidor DNS local

Atua como um intermediário, enviando consultas
para a hierarquia.
2a: Camada de Aplicação
68
Exemplo de DNS
servidor raiz
2
 Hospedeiro em
cis.poly.edu quer
endereço IP para
gaia.cs.umass.edu
3
servidor TLD
4
5
servidor local
dns.poly.edu
1
8
7
6
servidor oficial
dns.cs.umass.edu
solicitante
cis.poly.edu
gaia.cs.umass.edu
2a: Camada de Aplicação
69
DNS: tipos de consultas
consulta recursiva:
 transfere a
responsabilidade de
resolução do nome
para o servidor de
nomes contatado
 carga pesada?
consulta interativa:
 servidor consultado
responde com o nome
de um servidor de
contato
 “Não conheço este
nome, mas pergunte
para esse servidor”
servidor de
nomes raiz
consulta
interativa
servidor TLD
2
3
4
6
servidor local
pitomba.ic.uff.br
consulta
recursiva
1
9
5
servidor
intermediário
saell.cc.columbia.edu
7
8
10
servidor oficial
cs.columbia.edu
solicitante
manga.ic.uff.br
www.cs.columbia.edu
2a: Camada de Aplicação
70
DNS: uso de cache, atualização de dados
 uma vez que um servidor qualquer aprende um
mapeamento, ele o coloca numa cache local
 entradas na cache são sujeitas a temporização
(desaparecem depois de um certo tempo)
 Servidores TLD tipicamente armazenados no
cache dos servidores de nomes locais
• Servidores raiz acabam não sendo visitados com
muita freqüência
 estão sendo projetados pela IETF mecanismos
de atualização/notificação dos dados

RFC 2136

http://www.ietf.org/html.charters/dnsind-charter.html
2a: Camada de Aplicação
71
Registros DNS
DNS: BD distribuído contendo registros de recursos (RR)
formato RR: (nome,
valor, tipo, sobrevida)
 Tipo=CNAME
 Tipo=A
 nome é nome alternativo
 nome é nome de hospedeiro
(alias) para algum nome
 valor é o seu endereço IP
“canônico” (verdadeiro)
 Tipo=NS
 valor é o nome
 nome é domínio (p.ex.
canônico
foo.com.br)

valor é endereço IP de
servidor oficial de nomes
para este domínio
 Tipo=MX
 nome é domínio
 valor é nome do servidor de
correio para este domínio
2a: Camada de Aplicação
72
DNS: protocolo e mensagens
protocolo DNS: mensagens de pedido e resposta, ambas com o
mesmo formato de mensagem
cabeçalho de msg
 identificação: ID de 16 bit
para pedido, resposta ao
pedido usa mesmo ID
 flags:
 pedido ou resposta
 recursão desejada
 recursão permitida
 resposta é oficial
2a: Camada de Aplicação
73
DNS: protocolo e mensagens
campos de nome, e
de tipo num pedido
RRs em resposta
ao pedido
registros para outros
servidores oficiais
info adicional
“relevante” que
pode ser usada
2a: Camada de Aplicação
74
Inserindo registros no DNS
 Exemplo: acabou de cria a empresa “Network Utopia”
 Registra o nome netutopia.com.br em uma entidade
registradora (e.x., Registro .br)


Tem de prover para a registradora os nomes e endereços IP
dos servidores DNS oficiais (primário e secundário)
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)
 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
 Como as pessoas vão obter o endereço IP do seu
site?
2a: Camada de Aplicação
75
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
 2.7 Programação de
Sockets com TCP
 2.8 Programação de
Sockets com UDP
 2.9 Construindo um
servidor Web
2a: Camada de Aplicação
76
Compartilhamento de arquivos
P2P
 Alice escolhe um dos
Exemplo
 Alice executa aplicação
cliente P2P no seu notebook
 Periodicamente ela se
conecta à Internet e
recebe um novo endereço
IP a cada conexão
 Pede a música “Hey Jude”
 A aplicação apresenta uma
lista de outros parceiros
que possuem uma cópia de
Hey Jude.
parceiros, Bob.
 O arquivo é copiado do PC
de Bob para o notebook de
Alice: HTTP
 Enquanto Alice está
baixando a música, outros
usuários podem estar
pegando arquivos do seu
computador.
 O parceiro de Alice é tanto
um cliente Web como um
servidor Web temporário.
Todos os parceiros são
servidores = altamente
escalável!
2a: Camada de Aplicação
77
P2P: diretório centralizado
Projeto original do
Napster
Bob
servidor de diretório
centralizado
1
1) Quando um parceiro
conecta ele informa ao
servidor central o seu:


endereço IP
conteúdo
2) Alice consulta sobre a
música “Hey Jude”
3) Alice solicita o arquivo a
Bob
parceiros
1
3
1
2
1
Alice
2a: Camada de Aplicação
78
P2P: problemas com diretório
centralizado
 Ponto único de falha
 Gargalo de
desempenho
 Violação de Direitos
Autorais
a transferência de arquivo
é descentralizada, mas a
localização do conteúdo é
altamente centralizada.
2a: Camada de Aplicação
79
Inundação de consultas: Gnutella
 Completamente
distribuído

Sem servidor central
 Protocolo de domínio
público
 Vários clientes
Gnutella implementam
o protocolo
Rede sobreposta: grafo
 Arco entre pares X e Y se
existe uma conexão TCP
 Todos os pares ativos e
arcos formam a rede
sobreposta
 Arco não é um enlace
físico
 Um par vai estar
conectado tipicamente
com < 10 vizinhos na rede
sobreposta
2a: Camada de Aplicação
80
Gnutella: protocolo
 Mensagem de
consulta enviada
pelas conexões TCP
existentes
 Pares repassem
mensagem de
consulta
 Resposta sobre
item encontrado
enviada pelo
caminho reverso
Transferência arq:
HTTP
Consulta
Item achado
Consulta
Item achado
Escalabilidade:
Inundação com
escopo limitado
2a: Camada de Aplicação
81
Gnutella: junção do Par
Um par X se juntando deve encontrar algum outro
par na rede Gnutella: usa lista de pares
candidatos
2. X tenta criar conexões TCP com os pares na lista
seqüencialmente até estabelecer conexão com Y
3. X envia mensagem Ping para Y; Y repassa a
mensagem Ping
4. Todos os pares recebendo a mensagem Ping
respondem com uma mensagem Pong
5. X recebe várias mensagens Pong. Ele pode então
estabelecer conexões TCP adicionais
Saída do par: veja problema no livro texto!
1.
2a: Camada de Aplicação
82
Explorando heterogeneidade:
KaZaA
 Cada parceiro é um
líder de grupo ou está
alocado a um líder de
grupo


Conexão TCP entre cada
par e o seu líder de
grupo
Conexões TCP entre
alguns pares de líderes
de grupos
 O líder de um grupo
mantém registro sobre
o conteúdo de todos os
seus filhos
ordinary peer
group-leader peer
neighoring relationships
in overlay network
2a: Camada de Aplicação
83
KaZaA: Consulta
 Cada arquivo possui um
hash e um descritor
 O cliente envia palavras-chave para o seu líder de
grupo
 O líder de grupo responde com os itens
encontrados

Para cada item: metadados, hash, endereço IP
 Se o líder de grupo repassa a consulta para outros
líderes, eles respondem com os itens encontrados
 O cliente seleciona arquivos para download

Requisições HTTP usando hash com identificador são
enviadas para os pares que possuem os arquivos desejado
2a: Camada de Aplicação
84
Truques do KaZaA
 Limitações na quantidade de
uploads
simultâneos
 Enfileiramento de requisições
 Prioridades para incentivar disponibilização
de conteúdo
 Download em paralelo
2a: Camada de Aplicação
85
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
 2.7 Programação de
Sockets com TCP
 2.8 Programação de
Sockets com UDP
 2.9 Construindo um
servidor Web
2a: Camada de Aplicação
86
Programação com sockets
Meta: aprender a construir aplicações cliente/servidor
que se comunicam usando sockets
socket
API Sockets
uma interface (uma
 apareceu no BSD4.1 UNIX
em 1981
 são explicitamente criados,
usados e liberados por apls
 paradigma cliente/servidor
 dois tipos de serviço de
transporte via API Sockets


datagrama não confiável
fluxo de bytes, confiável
“porta”), local ao
hospedeiro, criada por e
pertencente à aplicação, e
controlado pelo SO,
através da qual um
processo de aplicação
pode tanto enviar como
receber mensagens
para/de outro processo
de aplicação
(remoto ou local)
2a: Camada de Aplicação
87
Programação com sockets usando TCP
Socket: uma porta entre o processo de aplicação e um
protocolo de transporte fim-a-fim (UDP ou TCP)
Serviço TCP: transferência confiável de bytes de um
processo para outro
controlado pelo
programador de
aplicação
controlado
pelo sistema
operacional
processo
processo
socket
TCP com
buffers,
variáveis
estação ou
servidor
internet
socket
TCP com
buffers,
variáveis
controlado pelo
programador de
aplicação
controlado
pelo sistema
operacional
estação ou
servidor
2a: Camada de Aplicação
88
Programação com sockets usando TCP
Cliente deve contactar servidor  Quando contatado pelo cliente, o
TCP do servidor cria socket novo
 processo servidor deve antes
para que o processo servidor possa
estar em execução
se comunicar com o cliente
 servidor deve antes ter
 permite que o servidor
criado socket (porta) que
converse com múltiplos clientes
aguarda contato do cliente
 Endereço IP e porta origem
Cliente contacta servidor para:
são usados para distinguir os
 criar socket TCP local ao
clientes (mais no cap. 3)
cliente
 especificar endereço IP,
número de porta do processo
ponto de vista da aplicação
servidor
TCP provê transferência
 Quando cliente cria socket:
confiável, ordenada de bytes
TCP cliente cria conexão com
(“tubo”) entre cliente e servidor
TCP do servidor
2a: Camada de Aplicação
89
Comunicação entre sockets
2a: Camada de Aplicação
90
Jargão para Fluxo (Stream)
 Um fluxo (stream) é uma
seqüência de caracteres
que fluem de ou para um
processo.
 Um fluxo de entrada é
conectado a alguma fonte
de entrada para o processo,
por exemplo, teclado ou
socket.
 Um fluxo de saída é
conectado a uma fonte de
saída, por exemplo, um
monitor ou um socket.
2a: Camada de Aplicação
91
Programação com sockets usando TCP
2.
3.
4.
cliente lê linha da entrada
padrão (fluxo doUsuário),
envia para servidor via
socket (fluxo
paraServidor)
servidor lê linha do socket
servidor converte linha para
letras maiúsculas, devolve
para o cliente
cliente lê linha modificada do
socket (fluxo doServidor),
imprime-a
input
stream
Processo
Process
cliente
Fluxo de saída:
Seqüência de bytes
transmitidos pelo
processo
output
stream
monitor
Fluxo de entrada:
Seqüência de
bytes recebidos
pelo processo
inFromServer
1.
outToServer
Exemplo de apl. clienteservidor:
inFromUser
keyboard
input
stream
Socket
clientSocket
cliente TCP
to netw ork
TCP
socket
from netw ork
2a: Camada de Aplicação
92
Interações cliente/servidor usando o TCP
Servidor (executa em nomeHosp)
Cliente
cria socket,
porta=x, para
receber pedido:
socketRecepção =
ServerSocket ()
aguarda chegada de
setup
pedido de conexão
socketConexão =
socketRecepção.accept()
lê pedido de
socketConexão
escreve resposta
para socketConexão
fecha
socketConexão
TCP
da conexão
cria socket,
abre conexão a nomeHosp, porta=x
socketCliente =
Socket()
Envia pedido usando
socketCliente
lê resposta de
socketCliente
fecha
socketCliente
2a: Camada de Aplicação
93
Exemplo: cliente Java (TCP)
import java.io.*;
import java.net.*;
class ClienteTCP {
public static void main(String argv[]) throws Exception
{
String frase;
String fraseModificada;
Cria
fluxo de entrada
Cria
socket de cliente,
conexão ao servidor
Cria
fluxo de saída
ligado ao socket
BufferedReader doUsuario =
new BufferedReader(new InputStreamReader(System.in));
Socket socketCliente = new Socket(”nomeHosp", 6789);
DataOutputStream paraServidor =
new DataOutputStream(socketCliente.getOutputStream());
2a: Camada de Aplicação
94
Exemplo: cliente Java (TCP), cont.
Cria
fluxo de entrada
ligado ao socket
BufferedReader doServidor =
new BufferedReader(new
InputStreamReader(socketCliente.getInputStream()));
frase = doUsuario.readLine();
Envia linha
ao servidor
paraServidor.writeBytes(frase + '\n');
Lê linha
do servidor
fraseModificada = doServidor.readLine();
System.out.println(”Do Servidor: " + fraseModificada);
socketCliente.close();
}
}
2a: Camada de Aplicação
95
Exemplo: servidor Java (TCP)
import java.io.*;
import java.net.*;
class servidorTCP {
Cria socket
para recepção
na porta 6789
Aguarda, no socket
para recepção, o
contato do cliente
Cria fluxo de
entrada, ligado
ao socket
public static void main(String argv[]) throws Exception
{
String fraseCliente;
StringfFraseMaiusculas;
ServerSocket socketRecepcao = new ServerSocket(6789);
while(true) {
Socket socketConexao = socketRecepcao.accept();
BufferedReader doCliente =
new BufferedReader(new
InputStreamReader(socketConexao.getInputStream()));
2a: Camada de Aplicação
96
Exemplo: servidor Java (TCP), cont
Cria fluxo
de saída, ligado
ao socket
DataOutputStream paraCliente =
new DataOutputStream(socketConexão.getOutputStream());
Lê linha
do socket
fraseCliente= doCliente.readLine();
fraseEmMaiusculas= fraseCliente.toUpperCase() + '\n';
Escreve linha
ao socket
paraClient.writeBytes(fraseEmMaiusculas);
}
}
}
Final do laço while,
volta ao início e aguarda
conexão de outro cliente
2a: Camada de Aplicação
97
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
 2.7 Programação de
Sockets com TCP
 2.8 Programação de
Sockets com UDP
 2.9 Construindo um
servidor Web
2a: Camada de Aplicação
98
Programação com sockets usando UDP
UDP: não tem “conexão” entre
cliente e servidor
 não tem “handshaking”
 remetente coloca
explicitamente endereço IP
e porta do destino
 servidor deve extrair
endereço IP, porta do
remetente do datagrama
recebido
ponto de vista da aplicação
UDP provê transferência
não confiável de grupos
de bytes (“datagramas”)
entre cliente e servidor
UDP: dados transmitidos
podem ser recebidos fora
de ordem, ou perdidos
2a: Camada de Aplicação
99
Interações cliente/servidor usando o UDP
Servidor (executa em nomeHosp)
cria socket,
porta=x, para
pedido que chega:
socketServidor =
DatagramSocket()
lê pedido do
socketServidor
escreve resposta
ao socketServidor
especificando endereço
IP, número de porta
do cliente
Cliente
cria socket,
socketCliente =
DatagramSocket()
cria, endereça (nomeHosp, porta=x,
envia pedido em datagrama
usando socketCliente
lê resposta do
socketCliente
fecha
socketCliente
2a: Camada de Aplicação
100
Exemplo: Cliente Java (UDP)
input
stream
Processo
cliente
monitor
inFromUser
keyboard
Process
Entrada: recebe
UDP
packet
receivePacket
pacote (o TCP
enviou uma
“seqüência de
bytes”)
sendPacket
Saída: transmite
UDP
packet
socket
cliente UDP
pacote (o TCP
recebeu uma
“seqüência de
bytes”)
clientSocket
to netw ork
UDP
socket
f rom netw ork
2a: Camada de Aplicação
101
Exemplo: cliente Java (UDP)
import java.io.*;
import java.net.*;
Cria
fluxo de entrada
Cria
socket de cliente
Traduz nome de
hospedeiro ao
endereço IP
usando DNS
class clienteUDP {
public static void main(String args[]) throws Exception
{
BufferedReader doUsuario=
new BufferedReader(new InputStreamReader(System.in));
DatagramSocket socketCliente = new DatagramSocket();
InetAddress IPAddress = InetAddress.getByName(”nomeHosp");
byte[] dadosEnvio = new byte[1024];
byte[] dadosRecebidos = new byte[1024];
String frase = doUsuario.readLine();
dadosEnvio = frase.getBytes();
2a: Camada de Aplicação
102
Exemplo: cliente Java (UDP) cont.
Cria datagrama com
dados para enviar,
comprimento,
endereço IP, porta
Envia datagrama
ao servidor
DatagramPacket pacoteEnviado =
new DatagramPacket(dadosEnvio, dadosEnvio.length,
IPAddress, 9876);
socketCliente.send(pacoteEnviado);
DatagramPacket pacoteRecebido =
new DatagramPacket(dadosRecebidos, dadosRecebidos.length);
Lê datagrama
do servidor
socketCliente.receive(pacoteRecebido);
String fraseModificada =
new String(pacoteRecebido.getData());
System.out.println(“Do Servidor:" + fraseModificada);
socketCliente.close();
}
}
2a: Camada de Aplicação
103
Servidor UDP
2a: Camada de Aplicação
104
Exemplo: servidor Java (UDP)
import java.io.*;
import java.net.*;
Cria socket
para datagramas
na porta 9876
class servidorUDP {
public static void main(String args[]) throws Exception
{
DatagramSocket socketServidor = new DatagramSocket(9876);
byte[] dadosRecebidos = new byte[1024];
byte[] dadosEnviados = new byte[1024];
Aloca memória para
receber datagrama
Recebe
datagrama
while(true)
{
DatagramPacket pacoteRecebido =
new DatagramPacket(dadosRecebidos,
dadosRecebidos.length);
socketServidor.receive(pacoteRecebido);
2a: Camada de Aplicação
105
Exemplo: servidor Java (UDP), cont
String frase = new String(pacoteRecebido.getData());
Obtém endereço
IP, no. de porta
do remetente
InetAddress IPAddress = pacoteRecebido.getAddress();
int porta = pacoteRecebido.getPort();
String fraseEmMaiusculas = frase.toUpperCase();
dadosEnviados = fraseEmMaiusculas.getBytes();
Cria datagrama p/
enviar ao cliente
DatagramPacket pacoteEnviado =
new DatagramPacket(dadosEnviados,
dadosEnviados.length, IPAddress, porta);
Escreve
datagrama
no socket
socketServidor.send(pacoteEnviado);
}
}
}
Fim do laço while,
volta ao início e aguarda
chegar outro datagrama
2a: Camada de Aplicação
106
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
 2.7 Programação de
Sockets com TCP
 2.8 Programação de
Sockets com UDP
 2.9 Construindo um
servidor Web
2a: Camada de Aplicação
107
Servidor Web Simples
 Funções do servidor Web:
Trata apenas um pedido HTTP por vez
 Aceita e examina o pedido HTTP
 Recupera o arquivo pedido do sistema de
arquivos do servidor
 Cria uma mensagem de resposta HTTP
consistindo do arquivo solicitado precedido por
linhas de cabeçalho
 Envia a resposta diretamente ao cliente.

2a: Camada de Aplicação
108
Servidor Web Simples
Contém a classe
StringTokenizer que é
usada para examinar
o pedido
Primeira linha da mensagem
de pedido HTTP e
Nome do arquivo solicitado
Aguarda conexão
do cliente
Cria fluxo
de Entrada
Cria fluxo
de Saída
import java.io.*;
import java.net.*;
import java.util.*;
class WebServer {
public static void main(String argv[]) throws Exception
{
String requestMessageLine;
String fileName;
ServerSocket listenSocket = new ServerSocket(6789);
Socket connectionSocket = listenSocket.accept();
BufferedReader inFromClient =
new BufferedReader(new InputStreamReader(
connectionSocket.getInputStream()));
DataOutputStream outToClient =
new DataOutputStream(
connectionSocket.getOutputStream());
2a: Camada de Aplicação
109
Servidor Web Simples, cont
Lê a primeira linha do
pedido HTTP que deveria
ter o seguinte formato:
GET file_name HTTP/1.0
Examina a primeira linha
da mensagem para extrair
o nome do arquivo
Associa o fluxo inFile
ao arquivo fileName
Determina o tamanho do
arquivo e constrói um vetor
de bytes do mesmo tamanho
requestMessageLine = inFromClient.readLine();
StringTokenizer tokenizedLine =
new StringTokenizer(requestMessageLine);
if (tokenizedLine.nextToken().equals("GET")){
fileName = tokenizedLine.nextToken();
if (fileName.startsWith("/") == true )
fileName = fileName.substring(1);
File file = new File(fileName);
int numOfBytes = (int) file.length();
FileInputStream inFile = new FileInputStream (
fileName);
byte[] fileInBytes = new byte[];
inFile.read(fileInBytes);
2a: Camada de Aplicação
110
Servidor Web Simples, cont
Inicia a construção da
mensagem de resposta
outToClient.writeBytes(
"HTTP/1.0 200 Document Follows\r\n");
if (fileName.endsWith(".jpg"))
outToClient.writeBytes("Content-Type: image/jpeg\r\n");
if (fileName.endsWith(".gif"))
outToClient.writeBytes("Content-Type:
image/gif\r\n");
outToClient.writeBytes("Content-Length: " + numOfBytes +
"\r\n");
outToClient.writeBytes("\r\n");
Transmissão do
cabeçalho da resposta
HTTP.
outToClient.write(fileInBytes, 0, numOfBytes);
connectionSocket.close();
}
else System.out.println("Bad Request Message");
}
}
2a: Camada de Aplicação
111
Capítulo 2: Resumo
Nosso estudo sobre aplicações de rede está agora
completo!
 Arquiteturas de aplicações



cliente-servidor
P2P
híbrido
 Requerimentos de serviço das
aplicações:

confiabilidade, banda, atraso
 Modelos de serviço de
 Protocolos específicos:
 HTTP
 FTP
 SMTP, POP, IMAP
 DNS
 Programação socket
transporte da Internet


orientado à conexão, confiável:
TCP
não confiável, datagramas: UDP
2a: Camada de Aplicação
112
Capítulo 2: Resumo
Mais importante: aprendemos sobre protocolos
 troca típica de mensagens
pedido/resposta


cliente solicita info ou serviço
servidor responde com dados,
código de status
 formatos de mensagens:


cabeçalhos: campos com info
sobre dados (metadados)
dados: info sendo comunicada
 msgs de controle vs. dados
na banda, fora da banda
centralizado vs.
descentralizado
s/ estado vs. c/ estado
transferência de msgs
confiável vs. não confiável
“complexidade na borda da
rede”





2a: Camada de Aplicação
113