2-camada_de_aplicacao

Prévia do material em texto

2. camada de aplicação
Prof. Harley Rios
Material baseado nos slides de: 
Dorgival G. (UFMG), Fábio C. (UFG) e Kurose
(última modificação: 17/01/2013)
Redes de Computadores
Capítulo 2: camada de aplicação
Nossos objetivos:
 conceituar, aspectos de 
implementação de protocolos de 
aplicação
 paradigma cliente-servidor
 modelos de serviço
 aprender sobre protocolos 
examinando algumas aplicações 
populares
Outros objetivos do 
capítulo
 protocolos específicos:
 HTTP
 SMTP, POP, IMAP
 DNS
Aplicações e protocolos de aplicação
 Aplicação: trata dos processos 
distribuídos comunicantes
 Processos que “rodem” em sistemas 
finais diferentes
 e.x., email, FTP, Web
 Protocolos de aplicação
 definem mensagens trocadas e as ações 
tomadas
 usam serviços das camadas inferiores
aplicação
transporte
rede
enlace
física
aplicação
transporte
rede
enlace
física
aplicação
transporte
rede
enlace
física
Arquitetura da aplicação
 No desenvolvimento de uma aplicação:
 Desenvolvedor aproveitará uma das duas arquiteturas mais utilizadas
 Cliente-Servidor
 P2P
Paradigma cliente-servidor
Cliente: inicia comunicação com o servidor 
(“fala primeiro”)
 solicita serviços do servidor, 
 Clientes não se comunicam diretamente;
 Web: cliente implementado no browser; 
e-mail: leitor de correio
Servidor: fornece os serviços solicitados ao 
cliente
 Sempre em funcionamento
 e.x., Web server envia a página Web 
solicitada, servidor de e-mail envia as 
mensagens, FTP, Telnet, etc.
aplicação
transporte
rede
enlace
física
aplicação
transporte
rede
enlace
física
pedido
resposta
Arquitetura P2P
 Aplicação utiliza comunicação direta entre dois pares de 
hospedeiros conectados alternadamente;
 Pares não são de propriedades dos provedores de 
serviços;
 Usuários controlam; Pares se comunicam sem passar por servidores;
 Ex: (BitTorrent, eMule, LimeWire, Skype)
 Algumas aplicações possuem arquiteturas híbridas (cliente-
servidor e P2P);
 Autoescalabilidade: solicita e distribui arquivos a outros 
pares.
 Desafio: segurança
Comunicação entre processos
 Processos: programas em execução 
 Pares de processos trocam mensagens pela rede (browser, Servidor).
 quem inicia a comunicação (cliente), 
 processo que espera para ser contatado para iniciar a sessão (Servidor); (Ex: P2P)
 Processo: envia mensagens pela rede e recebe através de uma interface de 
software denominada socket.
 Processa mensagem para outro hospedeiro através do socket (porto) emissor
 Receptor recebe mensagem através de sua porta (socket) do processo receptor
Comunicação entre processos
 Socket: interface entre camada de aplicação e a de transporte dentro de 
uma máquina.
Serviços que a camada de transporte oferece 
às aplicações
 No lado remetente a camada de aplicação envia mensagens através do socket. 
 Protocolo da camada de transporte leva a mensagem pela rede até a “porta” do 
socket destinatário.
Controle de perda de dados (transferência confiável)
 Pacotes podem se perder dentro de uma rede (buffer roteador, bits corrompidos).
 Certas aplicações podem tolerar alguma perda
 ex., áudio, vídeo
 Outras aplicações exigem transferência de dados 100% confiável
 ex., FTP (transferência de arquivos), SSH (conexão remota), correio eletrônico
Serviços da camada de transporte
Controle de temporização
 Algumas aplicações (p.ex., telefonia IP, jogos interativos) exigem baixos 
atrasos para operarem.
 Outras exigem atrasos regulares, mesmo que maiores (ex.: serviço de 
monitoração constante).
 Já outras, ainda, toleram grandes variações nos atrasos (p.ex., Web)
Serviços da camada de transporte
Gerência da banda passante
 Vazão disponível garantida a uma taxa específica.
 Algumas aplicações (p.ex., multimídia) exigem uma banda mínima para 
serem utilizáveis
 Outras aplicações (p.ex., e-mail, web, ftp) melhoram quando a banda 
aumenta, mas funcionam também com menos
 são conhecidas como “aplicações elásticas”
Protocolo de Aplicação: HTTP
HTTP: HyperText Transfer Protocol
 protocolo da camada de aplicação da 
Web; 
 define a estrutura das mensagens e 
modo como cliente e servidor as 
trocam.
 Como requisitam;
 modelo cliente/servidor
– cliente: browser que solicita, 
recebe e apresenta objetos 
(arquivo HTML, jpeg, video, etc).
– server: envia objetos em resposta 
a pedidos
PC rodando
Chrome
Servidor Linux
rodando
Apache
Web server
Mac rodando
Firefox
Protocolo de Aplicação: HTTP
Protocolo de transporte utilizado: TCP
 cliente inicia conexão TCP (cria socket) para o servidor no porto 80
 servidor aceita uma conexão TCP do cliente
 mensagens HTTP (protocolo de camada de aplicação) são trocadas entre o 
navegador (cliente HTTP) e o servidor Web (servidor HTTP)
 ao final, a conexão TCP é fechada
Protocolo de Aplicação: HTTP
 Protocolo sem informações de estado (“stateless”)
 servidor não mantém informação sobre os pedidos passados
 Servidor se necessário, envia objeto novamente…novo pedido…
 imagine se o servidor Web tivesse que armazenar informações dos milhões de 
clientes que ele atende...
 OBS.: protocolos que mantêm estado são complexos!
 necessidade de organizar informações passadas
 se ocorrer uma falha (crash) as informações podem ser perdidas ou gerar 
inconsistências entre o cliente e o servidor
Exemplo de operação
Usuário entra com a URL: www.uniformg.edu.br/index.php
1a. cliente inicia conexão TCP c/ 
servidor em www.uniformg.edu.br no 
porto 80 (a usual para um servidor 
http).
4. cliente recebe resposta com o 
arquivo HTML, exibindo o texto 
dele. Analisando o arquivo HTML, 
encontra referências para 23 
imagens JPEG e PNG
2. cliente envia pedido com a URL através 
da conexão TCP
1b. servidor no host www.uniformg.edu.br
espera pela conexão no porto 80 e 
“aceita” conexão, notificando cliente
3. servidor recebe pedido, forma resposta
com o objeto solicitado (index.php) e 
envia mensagem através do soquetetempo
(contém referências p/ mais de 20 imagens)
3b. servidor fecha conexão TCP.
5. Após, os passos 1-4 são repetidos para cada um dos objetos (ex.: imagens)!
Conexões persistentes e não-persistentes
Não-persistente
 http/1.0: servidor analisa pedido, envia resposta e fecha a conexão TCP
 mais trabalho para cada objeto por conta da conexão
 navegadores abriam várias conexões paralelas para contornar isso
Persistente
 modo padrão para http/1.1
 na mesma conexão TCP são transferidos vários objetos
 o cliente envia pedido para todos os objetos referenciados tão logo ele recebe a página 
HTML básica
 evita o trabalho e tempo de estabelecer cada conexão individualmente
Cookies
 Forma de se manter estado entre pedidos HTTP
 Permite que sites monitorem seus usuários
 Não fazem parte do protocolo em si, são extensões entendidas pelo 
cliente e pelo servidor
 Servidor entrega um cookie (pequeno arquivo de texto) ao cliente
 Cliente devolve esse cookie em cada requisição HTTP posterior, ao mesmo 
servidor
 p.ex.: cookie contém identificador do cliente (cookie: 1678) (usuário, cód.conta, etc)
 Sistema final do usuário mantem um arquivo de cookies.
Web caches (servidor proxy)
Objetivo: atender o cliente (requisições http) sem envolver o servidor original
 Armazena cópias de objetos recentemente requisitados
 o 1º cliente solicita um objeto, sendo obtido no servidor original;
 após, caso o proxy já possua o objeto, encaminha-o aos próximos clientes. 
Caso contrário, solicita-o ao servidor original;
cliente
Proxy
cliente
servidor
original
Por que usar caches?
 armazenamento está “perto” do cliente
 menor tempo de resposta
 menos tráfego na Internet
servidores
originais
Internet
pública
rede
institucional 100 Mbps LAN
enlace de acesso
4 Mbps
cache
institucional
Aplicação: correio eletrônico
Três componentes principais:
 agentes de usuário
 outlook,thunderbird, kmail, etc.
 servidores de correio
 sendmail, postfix, qmail, etc.
 simple mail transfer protocol: SMTP
caixa postal
fila de
saída de mensagem
servidor
de correio
agente
usuário
agente
usuário
agente
usuário
servidor
de correio
agente
usuário
agente
usuário
servidor
de correio
agente
usuário
SMTP
SMTP
SMTP
Correio eletrônico: SMTP [RFC 821]
 usa TCP para transferência confiável de mensagens, no porto 25
 usualmente, transferência direta de quem envia para quem recebe
 três fases de transferência
 handshake (apresentação, usuário, senha)
 transferência de mensagens
 fechamento
 interação comando/resposta
– comandos: texto ASCII
– resposta: código de status e frase (ex.: 200 OK, 400 Bad Request)
Protocolos de acesso ao correio
 SMTP: entrega e armazena no servidor do destino (protocolo de envio (http requisição)
 Protocolo de acesso: recupera mensagens do servidor
 POP: Post Office Protocol [RFC 1939]
 autorização (agente <-->servidor) e download
 IMAP: Internet Mail Access Protocol [RFC 1730]
 mais recursos (mais complexo)
 manipulação de msgs armazenadas no servidor (marcar como lida, criar pastas, 
pesquisar e-mails no servidor)
 HTTP: WebMails como Gmail, Hotmail, Yahoo! Mail, etc. (agente é o browser)
agente
usuário
servidor de
correio da origem
agente
usuário
SMTP SMTP POP3 ou
IMAP
http
servidor de
correio do destino
Aplicação: nomes e endereços
 Normalmente, aplicações e usuários fazem referência a um computador 
através de um nome
… mas na Internet, servidores possuem endereços numéricos (IPs)!
 É necessário um mecanismo de mapeamento de nome para endereço e 
vice-versa
 Quando havia a Arpanet, um arquivo hosts.txt tinha todos os 
computadores e endereços IP da rede
 Inviável com o crescimento da Internet, hoje tem fins restritos
 Nova solução:
 DNS, especificado nas RFCs 1034 e 1035
Domain Name System
 Sistema hierárquico distribuído para tradução de nomes de hosts para 
seus respectivos endereços IP
Protocolo DNS
www.formiga.ifmg.edu.br
177.19.242.55
DNS: Domain Name System
Domain Name System:
n base de dados distribuída implementada numa hierarquia de muitos 
servidores de nomes
n hosts e roteadores se comunicam com servidores de nomes para 
resolver nomes (tradução nome/endereço)
 nenhum servidor tem todos os mapeamentos
 servidores de nomes locais: cada ISP/organização tem uma base 
com seus dados locais (autoridade para aqueles dados)
 servidores raiz: mantêm um ponto de origem para a hiearquia
 cada servidor conhece a raiz e os servidores dos seus sub-domínios
DNS
 Cada nível define um domínio independente e autônomo
 Cada domínio (ou região contígua) implementa um servidor
 Informação é distribuída pelos vários servidores da rede
DNS: servidores de nomes raiz (até 2006)
 buscam servidor(es) de nomes autoritativos p/ pelo menos parte do nome
 retornam o mapeamento para o servidor de nomes local
b USC-ISI Marina del Rey, CA
l ICANN Marina del Rey, CA
e NASA Mt View, CA
f Internet Software C. Palo Alto, CA
i NORDUnet Stockholm
k RIPE London
m WIDE Tokyo
a NSI Herndon, VA
c PSInet Herndon, VA
d U Maryland College Park, MD
g DISA Vienna, VA
h ARL Aberdeen, MD
j NSI (TBD) Herndon, VA
existem 13 
servidores de nomes 
raiz no mundo
DNS: servidores de nomes raiz (2006)
 Alguns servidores replicados pela rede afora
 Mas continuam apenas 13 endereços diferentes (anycast)
DNS: exemplo simples
O host meupc.provedor.com.br
quer o endereço IP de 
uniformg.edu.br
1. contata seu servidor DNS local, 
dns.provedor.com.br
2. dns.provedor.com.br contata o 
servidor de nomes raiz, se 
necessário
3. o servidor de nomes raiz contata o 
servidor de nomes autoritativo, 
dns.edu.br
1
2
3
4
5
6
servidor de
nomes raiz
computador solicitante
meupc.provedor.com.br
servidor de
nomes local
dns.provedor.com.br
servidor de nomes autoritativo
dns.edu.br
uniformg.edu.br
(177.19.242.55)
Capítulo 2: sumário
Objetivos vistos:
 conceituar, aspectos de 
implementação de protocolos de 
aplicação
 paradigma cliente-servidor
 modelos de serviço
 aprender sobre protocolos 
examinando algumas aplicações 
populares
Outros objetivos do 
capítulo
 protocolos específicos:
 HTTP
 SMTP, POP, IMAP
 DNS