Capítulo 2: Camada de Aplicação
Metas do capítulo:

Mais metas do capítulo
aspectos conceituais e de  protocolos específicos:
implementação de
 http
protocolos de aplicação
 ftp
em redes
 smtp
 paradigma cliente
 pop
servidor
 dns
 modelos de serviço
 aprenda sobre protocolos  a programação de
através do estudo de
aplicações de rede
protocolos populares do
 programação usando sockets
nível da aplicação
2: Camada de Aplicação
1
Aplicações e protocolos da camada de aplicação
Aplicação: processos distribuídos
em comunicação
 executam em hospedeiros
no “espaço de usuário”
 trocam mensagens para
implementar a aplicação
 p.ex., correio, transf. de
arquivo, WWW
Protocolos da camada de aplicação
 uma “parte” da aplicação
 define mensagens trocadas
por apls e ações tomadas
 usam serviços providos por
protocolos de camadas
inferiores
aplicação
transporte
rede
enlace
física
aplicação
transporte
rede
enlace
física
aplicação
transporte
rede
enlace
física
2: Camada de Aplicação
2
Aplicações de rede: algum jargão
 Um processo é um
programa que executa num
hospedeiro.
 Dois processos no mesmo
hospedeiro se comunicam
usando comunicação entre
processos definida pelo
sistema operacional (SO).
 Dois processos em
hospedeiros distintos se
comunicam usando um
protocolo da camada de
aplicação.
 Um agente de usuário
(UA) é uma interface
entre o usuário e a
aplicação de rede.



WWW: browser
Correio:
leitor/compositor de
mensagens
streaming áudio/vídeo:
tocador de mídia
2: Camada de Aplicação
3
Paradigma cliente-servidor (C-S)
Apl. de rede típica tem duas
partes: cliente e servidor
Cliente:
 inicia contato com o servidor
(“fala primeiro”)
 tipicamente solicita serviço do
servidor
 para WWW, cliente
implementado no browser; para
correio no leitor de mensagens
Servidor:
 provê ao cliente o serviço
requisitado
 p.ex., servidor WWW envia
página solicitada; servidor de
correio entrega mensagens
aplicação
transporte
rede
enlace
física
pedido
resposta
aplicação
transporte
rede
enlace
física
2: Camada de Aplicação
4
Protocolos da camada de aplicação (cont).
API: interface de
programação de
aplicações
 define interface entre
aplicação e camada de
transporte
 socket (= tomada): API
da Internet

2 processos se comunicam
enviando dados para um
socket ou lendo dados de
um socket
P: como um processo pode
“identificar”o outro
processo com o qual
quer se comunicar?


endereço IP do
hospedeiro do outro
processo
“número de porta” permite que o hospedeiro
receptor determine a
qual processo deve ser
entregue a mensagem
… voltamos mais tarde a este assunto.
2: Camada de Aplicação
5
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”
2: Camada de Aplicação
6
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
2: Camada de Aplicação
7
Serviços providos por protocolos de
transporte Internet
serviço TCP:
serviço UDP:

 transferência de dados não
orientado a conexão: setup
requerido entre cliente,
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 carregada
 não provê: garantias
temporais ou de banda mínima
confiável entre processos
remetente e receptor
 não provê: setup 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?
2: Camada de Aplicação
8
Apls Internet: seus protocolos e seus
protocolos de transporte
Aplicação
correio eletrônico
accesso terminal remoto
WWW
transferência de arquivos
streaming multimídia
servidor de arquivo remoto
telefonia Internet
Protocolo da
camada de apl
Protocolo de
transporte usado
smtp [RFC 821]
telnet [RFC 854]
http [RFC 2068]
ftp [RFC 959]
proprietário
(p.ex. RealNetworks)
NSF
proprietário
(p.ex., Vocaltec)
TCP
TCP
TCP
TCP
TCP ou UDP
TCP ou UDP
tipicamente UDP
2: Camada de Aplicação
9
WWW: algum jargão
 Página WWW:
 consiste de “objetos”
 endereçada por uma URL
 Agente de usuário (user
agent) para WWW se
chama de browser:

 Quase todas as páginas
WWW consistem de:


página base HTML, e
vários objetos
referenciados.

MS Internet Explorer
Firefox
 Servidor para WWW se
 URL tem duas partes:
nome de hospedeiro, e
nome de caminho:
chama “servidor
WWW”:


Apache (domínio público)
MS Internet Information
Server (IIS)
www.univ.br/algum-depto/pic.gif
2: Camada de Aplicação
10
WWW: o protocolo http
http: hypertext transfer
protocol
 protocolo da camada de
aplicação para WWW
 modelo cliente/servidor
 cliente: browser que
pede, recebe, “visualiza”
objetos WWW
 servidor: servidor
WWW envia objetos em
resposta a pedidos
 http1.0: RFC 1945
 http1.1: RFC 2068
PC executa
Explorer
Servidor
executando
servidor
WWW
Apache
Mac executa
Navigator
2: Camada de Aplicação
11
Mais sobre o protocolo http
http: 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
aplicação) trocadas entre
browser (cliente http) e
servidore WWW (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
2: Camada de Aplicação
12
Exemplo de http
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
2: Camada de Aplicação
13
Exemplo de http (cont.)
4. servidor http encerra conexão
5. cliente http recebe mensagem
TCP .
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
14
Conexões não persistente e persistente
Não persistente
 HTTP/1.0
 servidor analisa
pedido, responde, and
encerra conexão TCP
 2 RTTs para trazer
cada objeto
(RTT=round trip time)
 transferência de cada
objeto sofre de
partida lenta
Persistente
 default for HTTP/1.1
 na mesma conexão TCP:
servidor analisa pedido,
responde, analisa novo
pedido,..
 Cliente envia pedidos para
todos objetos referenciados
assim que recebe o HTML
base .
 Menos RTTs and menos
partida lenta.
A maioria de browsers 1.0
usa connexões TCP paralelas.
2: Camada de Aplicação
15
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)
GET /somedir/page.html HTTP/1.0
User-agent: Mozilla/4.0
Accept: text/html, image/gif,image/jpeg
linhas do Accept-language:fr
cabeçalho
Carriage return,
line feed
indicate fim
de mensagem
(carriage return (CR), line feed(LF) adicionais)
2: Camada de Aplicação
16
mensagem de pedido http: formato geral
2: Camada de Aplicação
17
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.0 200 OK
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 ...
2: Camada de Aplicação
18
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
2: Camada de Aplicação
19
Experimente você com http (do lado cliente)
1. Use cliente telnet para seu servidor WWW favorito:
telnet www.ic.uff.br 80 Abre conexão TCP para a porta 80
(porta padrão do servidor http) a www.ic.uff.br.
Qualquer coisa digitada é enviada para a
porta 80 do www.ic.uff.br
2. Digite um pedido GET http:
GET /~michael/index.html HTTP/1.0
Digitando isto (deve teclar
ENTER duas vezes), está enviando
este pedido GET mínimo (porém
completo) ao servidor http
3. Examine a mensagem de resposta enviado pelo
servidor http !
2: Camada de Aplicação
20
HTML (HyperText Markup Language)
 HTML: uma linguagem simples para hipertexto
 começou como versão simples de SGML
 construção básica: cadeias de texto anotadas
 Construtores de formato operam sobre cadeias
 <b> .. </b>
bold (negrito)
 <H1 ALIGN=CENTER> ..título centrado .. </H1>
 <BODY bgcolor=white text=black link=red ..> .. </BODY>
 vários formatos
 listas de bullets, listas ordenadas, listas de definição
 tabelas
 frames
2: Camada de Aplicação
21
Encadeamento de referências
 Referências <A HREF=LinkRef> ... </A>
 a componentes do documento local
<A HREF=“importante”> clique para uma dica </A>
 a documentos no servidor local
<A HREF=“../index.htm”> voltar ao sumário </A>
 a documentos em outros servidores
<A HREF=“http://www.uff.br”> saiba sobre a UFF </A>
 Multimídia
 imagem embutida: <IMG SRC=“eclipse”>
 imagem externa:
<A HREF=“eclipse.gif”> imagem maior </A>
 vídeo Mpeg <A HREF=“ByeByeBrasil.mpg”> um bom filme </A>
 som
<A HREF=“http://www.sons.br/aniv.au”> feliz niver </A>
2: Camada de Aplicação
22
Formulários e interação bidirecional
 Formulários transmitem
informação do cliente ao
servidor
 HTTP permite enviar
formulários ao servidor
 Resposta enviada como
página HTML dinâmica
cliente
WWW
GET/POST
formulário
resposta:
HTML
 Formulários processados usando
scripts CGI (programas que
executam no servidor WWW)
 CGI - Common Gateway
Interface
 scripts CGI escondem
acesso a diferentes serviços
 servidor WWW atua como
gateway universal
servidor
WWW
Sistema de
informação
2: Camada de Aplicação
23
Interação usuário-servidor: autenticação
Meta da autenticação: controle de
acesso aos documentos do
servidor
cliente
servidor
msg de pedido http comum
 sem estado: cliente deve
apresentar autorização com
401: authorization req.
cada pedido
WWW authenticate:
 autorização: tipicamente nome,
senha
msg de pedido http comum
 authorization: linha de
+ Authorization:line
cabeçalho no pedido
msg de resposta http comum
 se não for apresentada
autorização, servidor nega
accesso, e coloca no
cabeçalho da resposta
msg de pedido http comum
WWW authenticate:
+ Authorization:line
tempo
msg de resposta http comum
Browser guarda nome e senha para
evitar que sejam pedidos ao usuário a cada acesso.
2: Camada de Aplicação
24
Interação usuário-servidor: cookies
servidor
cliente
 servidor envia “cookie” ao
cliente na msg de resposta
Set-cookie: 1678453
msg de pedido http comum
resposta http comum+
Set-cookie: #
 cliente apresenta cookie
nos pedidos posteriores
cookie: 1678453
 servidor casa cookie-
apresentado com a info
guardada no servidor
 autenticação
 lembrando preferências
do usuário, opções
anteriores
msg de pedido http comum
Ação
específica
msg de resposta http comum do cookie
cookie: #
msg de pedido http comum
Ação
específica
msg de resposta http comum do cookie
cookie: #
2: Camada de Aplicação
25
Interação usuário-servidor: GET condicional
servidor
cliente
 Meta: não enviar objeto se
cliente já tem (no cache)
versão atual
 cliente: 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>
2: Camada de Aplicação
26