Princípios de Aplicações de Rede

Prévia do material em texto

Aulas do livro disponíveis em:
http://www-net.cs.umass.edu/kurose-ross-ppt-7e/
Camada de 
aplicação
2.1 Principios das aplicações 
de rede
2.2 Web e HTTP
2.3 Mail eletronico
• SMTP, POP3, IMAP
2.4 DNS
2.5 Aplicações P2P
2.6 Streaming de video e 
content distribution 
networks
2.7 Programação com sockets
usando UDP e TCP
Resumo da camada de aplicação
Camada de aplicação
Objetivos:
• conceitos, aspectos de 
implementação dos 
protocolos de 
aplicações de rede
o Modelos de serviço de camada 
de transporte
o Paradigma cliente-servidor
o Paradigma peer-to-peer
• Conhecer os protocolos 
mais relevantes da 
camada de aplicação
o HTTP
o FTP
o SMTP / POP3 / IMAP
o DNS
• Criar aplicações de rede
o socket API
Algumas aplicações de rede
• e-mail
• web
• text messaging
• remote login
• P2P file sharing
• multi-user network games
• streaming stored video 
(YouTube, Netflix) 
• voice over IP (e.g., Skype)
• real-time video 
conferencing
• social networking
• search
• …
• …
Criando uma aplicação de rede
Escrever um programa que:
• rode em (diferentes) sistemas finais
• se comunique através da rede
• e.g., software de servidor web se 
comunica com um software de browser
Não é necessário escrever software para os
dispositivos do core (centro) da rede
• dispositivos do core da rede não rodam
aplicações de usuário
• aplicações nos sistemas finais permitem
desenvolvimento rápido das aplicações
application
transport
network
data link
physical
application
transport
network
data link
physical
application
transport
network
data link
physical
Arquiteturas
Estruturas possíveis de aplicações:
• Arquitetura Cliente - servidor
• Arquitetura Peer to Peer
Arquitetura cliente-servidor
servidor: 
• equipamento sempre disponível
• endereço IP permanente
• escalável com data centers
clientes:
• comunica com servidor
• pode estar conectado
intermitentemente
• pode ter um endereço IP dinâmico
• não se comunica diretamente com os
outros clientes
cliente/servidor
Arquitetura P2P
• sem servidor sempre disponível
• sistemas finais se comunicam 
diretamente
• pares solicitam serviço de outros 
pares, fornecendo serviço em troca 
para outros pares
o Auto-escalabilidade - novos pares trazem 
nova capacidade de serviço, bem como 
novas demandas de serviço
• pares são intermitentemente 
conectados e trocam de endereço IP
o gerenciamento complexo
peer-to-peer 
(par a par)
Comunicação de processos
processo: programa rodando
em um host (sistema final)
• dentro do mesmo host, 
dois processos se 
comunicam usando a
comunicação entre 
processos (definida pelo
SO)
• processos em diferentes
hosts se comunicam
trocando mensagens
processo cliente: processo que inicia 
comunicação
processo servidor: processo que 
aguarda para ser contactado
clientes, servidores
Processos de endereçamento
• Para receber mensagens, o 
processo deve ter identificador
• Dispositivo host tem endereço IP 
exclusivo de 32 bits
• Q: o endereço IP do host no qual 
o processo é executado é 
suficiente para identificar o 
processo?
• R: Não, muitos processos podem 
estar em execução no mesmo 
host
• Identificador inclui o endereço IP e 
os números de porta associados 
ao processo no host.
• Exemplo números de porta:
o HTTP server: 80
o mail server: 25
• para enviar uma mensagem HTTP 
para o servidor web 
gaia.cs.umass.edu:
o IP address: 128.119.245.12
o port number: 80
Sockets
• Processo envia/recebe mensagens para/do seu socket
• socket análogo/equivalente a porta
o envio do processo empurra a mensagem para fora da porta
o processo de envio depende da infra-estrutura de transporte do outro lado da 
porta para entregar a mensagem para o socket no processo de recepção
Internet
Controlado
pelo SO
Controlado pela 
aplicação do 
desenvolvedor
transport
application
physical
link
network
process
transport
application
physical
link
network
process
socket
Protocolo de camada de aplicação define:
• Tipo de mensagens trocadas:
o e.g., requisição, resposta 
• Sintaxe da mensagem:
o Que campo e como esses campos são 
delineados
• Semantica da mensagem:
o significado das informações nos campos
• Regras para quando e como os 
processos enviam e respondem 
as mensagens
Protocolos abertos:
• Definidos em RFCs
• Permite interoperabilidade
• e.g., HTTP, SMTP
Protocolos proprietários:
• e.g., Skype
Qual serviço de transporte é necessário para um aplicativo?
Integridade dos dados
§ Alguns aplicativos (e.g, transferência de 
arquivos, transações na web) exigem
100% de transferência de dados 
confiável
§ Outros aplicativos (por exemplo, áudio) 
podem tolerar alguma perda
temporizador
§ Alguns aplicativos (por exemplo, 
telefonia pela Internet, jogos
interativos) requerem um atraso
menor para serem "efetivos"
vazão (throughput)
§ Alguns aplicativos (por exemplo, 
multimídia) exigem uma quantidade
mínima de vazão para serem
"efetivos”
§ Outros aplicativos ("aplicativos
elásticos") fazem uso de qualquer
taxa de transferência que recebem
segurança
§ Criptografia, integridade de dados, ...
Requisitos do serviço de transporte: aplicativos comuns
aplicação
file transfer
e-mail
Web documents
real-time audio/video
stored audio/video
interactive games
text messaging
Perda de dados
no loss
no loss
no loss
loss-tolerant
loss-tolerant
loss-tolerant
no loss
vazão
elastic
elastic
elastic
audio: 5kbps-1Mbps
video:10kbps-5Mbps
same as above 
few kbps up
elastic
Sensível ao atraso
no
no
no
yes, 100’s msec
yes, few secs
yes, 100’s msec
yes and no
Serviços de protocolos de transporte na Internet
ServiçoTCP :
§ Transporte confiável entre o processo de 
envio e recebimento
§ Controle de fluxo: o remetente não irá
sobrecarregar o receptor
§ Controle de congestionamento : segura
remetente quando rede sobrecarregada
§ Não fornece: tempo, garantia de 
rendimento mínimo, segurança
§ Orientado à conexão: configuração
necessária entre processos cliente e 
servidor
Serviço UDP :
§ Transferência de dados não confiável
entre o processo de envio e recebimento
§ Não fornece: confiabilidade, controle de 
fluxo, controle de congestionamento, 
cronometragem, garantia de vazão, 
segurança ou configuração de conexão
Q: Pq ambos? Pq existe UDP?
Aplicações da Internet: aplicação, protocolos de transporte
application
e-mail
remote terminal access
Web 
file transfer
streaming multimedia
Internet telephony
application
layer protocol
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
HTTP (e.g., YouTube), 
RTP [RFC 1889]
SIP, RTP, proprietary
(e.g., Skype)
underlying
transport protocol
TCP
TCP
TCP
TCP
TCP or UDP
TCP or UDP
Protegendo TCP
TCP & UDP 
§ Sem criptografia
§ Senhas enviadas via 
socket atravessam a 
Internet tem texto aberto
SSL 
§ Fornece conexão TCP 
criptografada
§ integridade de dados
§ Autenticação ponto a 
ponto
SSL está na camada de aplicação
§ Aplicativos usam bibliotecas SSL, 
que "falam" com TCP
§ API socket SSL
§ Senhas enviadas via socket atravessam
a Internet criptografadas
§ Isso será visto na disciplina de 
Segurança de Sistemas e Redes (trilha
de Redes), capitulo 8 do livro Kurose.
HTTPS é uma implementação do protocolo HTTP sobre uma camada adicional de 
segurança que utiliza o protocolo SSL/TLS.
Web e HTTP
lembrando…
• web page consiste em objetos
• objeto pode ser um arquivo HTML, uma imagem JPEG, 
applet Java, um arquivo de audio,…
• uma página web consiste de um arquivo base HTML que 
inclui vários objetos referenciados
• cada objeto object é endereçado por uma URL, e.g.,
www.someschool.edu/someDept/pic.gif
nome host (máquina) nome path (caminho)
HTTP
HTTP: hypertext transfer protocol
§ Protocolo camada de aplicação
Web
§ Modelo cliente/servidor
• Cliente: navegador que solicita, 
recebe, (usando protocolo
HTTP) e "exibe" objetos da 
Web
• Servidor: O servidorWeb envia
(usando o protocolo HTTP) 
objetos em resposta a 
solicitações
PC running
Firefox browser
server 
running
Apache Web
server
iPhone running
Safari browserHTTP requestHTTP response
HTTP request
HTTP response
HTTP
UsaTCP:
§ Cliente inicia uma conexão TCP (cria
socket) com o servidor, porta 80
§ servidor aceita conexão TCP do 
cliente
§ Mensagens HTTP (mensagens do 
protocolo de camada de aplicação) 
troca entre browser (cliente HTTP) 
e servidor Web (servidor HTTP)
§ Conexão TCP encerrada
HTTP é “stateless”
§ Servidor não mantém
nenhuma informação sobre
pedidos de clientes
anteriores
Protocolos que mantêm o "estado" 
são complexos! Passado (estado) 
deve ser mantido
Se o servidor / cliente falhar, suas visões de 
"estado" podem ser inconsistentes
ainda
Conexões HTTP
HTTP não persistente
• Ao menos um objeto enviado
sobre a conexão TCP
o Conexão é então encerrada
• Download de múltiplos objetos
necessitam de múltiplas
conexões
HTTP persistente
• Múltiplos objetos podem ser 
enviados sobre uma simples 
conexão TCP entre cliente e 
servidor
HTTP não persistente
Suponha que o usuário entre com a URL:
1a. cliente HTTP inicia conexão TCP com 
servidor HTTP (processo) em 
www.someSchool.edu na porta 80
2. cliente HTTP envia mensagem de 
requisição HTTP (contendo URL) em 
um socket de conexão TCP. 
Mensagem indica que cliente quer 
objeto someDepartment/home.index
1b. servidor HTTP na máquina 
www.someSchool.edu aguarda por 
conexão TCP na porta 80, “aceita”
conexão, notificando cliente
3. servidor HTTP recebe mensagem 
requisição, constroi a mensagem de 
resposta contendo o objeto 
requisitado, e envia a mensagem dentro 
do seu socket
tempo
(contém texto, 
referência a
10 imagens jpeg)
www.someSchool.edu/someDepartment/home.index
HTTP não persistente
5. cliente HTTP recebe mensagem de 
resposta contendo arquivo html, 
mostra aquivo html. Analisando o 
arquivo html, encontra 10 objetos 
jpeg referenciados
6. Os passos1-5 são repetidos para 
cada um dos 10 objetos jpeg
4. servidor HTTP fecha conexão TCP. 
tempo
HTTP não persistente: tempo de resposta
RTT (definição): tempo para um pequeno
pacote “viajar” do cliente para o 
servidor e voltar (tempo de ida e 
volta)
Tempo de resposta HTTP:
• 1 RTT para iniciar uma conexão TCP
• 1 RTT para requisição HTTP e os
primeiros poucos bytes da resposta
HTTP para retorno
• Tempo de transmissão do arquivo
de resposta
• Tempo de resposta (total) HTTP não
persistente = 
2RTT+ tempo de transmissão do 
arquivo
time to 
transmit 
file
initiate TCP
connection
RTT
request
file
RTT
file
received
time time
RTT : Round Trip Time
HTTP persistente
Problemas HTTP não persistentes:
§ Requer 2 RTTs por objeto
§ Sobrecarga do sistema 
operacional para cada conexão 
TCP
§ Os navegadores geralmente 
abrem conexões TCP paralelas 
para buscar objetos 
referenciados
HTTP persistente:
§ O servidor deixa a conexão 
aberta após enviar a resposta
§ Mensagens HTTP subseqüentes 
entre o mesmo cliente / 
servidor enviado através de 
conexão aberta
§ Cliente envia solicitações assim 
que encontrar um objeto 
referenciado
§ Tão pouco quanto um RTT 
para todos os objetos 
referenciados
Mensagem de requisição HTTP
• Dois tipos de mensagens HTTP: requisição, resposta
• HTTP request message:
o ASCII (human-readable format)
request line
(GET, POST, 
HEAD commands)
header
lines
carriage return, 
line feed at start
of line indicates
end of header lines
GET /index.html HTTP/1.1\r\n
Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
Connection: keep-alive\r\n
\r\n
carriage return character
line-feed character
* Check out the online interactive exercises for more examples: 
http://gaia.cs.umass.edu/kurose_ross/interactive/
Mensagem de requisição : formato
request
line
header
lines
body
method sp sp cr lfversionURL
cr lfvalueheader field name
cr lfvalueheader field name
~~ ~~
cr lf
entity body~~ ~~
Upload de entrada de formulário
POST method:
§ web page often includes 
form input
§ input is uploaded to 
server in entity body
URL method:
§ uses GET method
§ input is uploaded in URL 
field of request line:
www.somesite.com/animalsearch?monkeys&banana
Tipos de Métodos
HTTP/1.0:
• GET
• POST
• HEAD
o asks server to leave requested 
object out of response
HTTP/1.1:
• GET, POST, HEAD
• PUT
o uploads file in entity body to path 
specified in URL field
• DELETE
o deletes file specified in the URL 
field
Mensagem de resposta HTTP
status line
(protocol
status code
status phrase)
header
lines
data, e.g., 
requested
HTML file
HTTP/1.1 200 OK\r\n
Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02 
GMT\r\n
ETag: "17dc6-a5c-bf716880"\r\n
Accept-Ranges: bytes\r\n
Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-
1\r\n
\r\n
data data data data data ... 
* Check out the online interactive exercises for more examples: 
http://gaia.cs.umass.edu/kurose_ross/interactive/
Códigos de status de resposta HTTP
200 OK
o request succeeded, requested object later in this msg
301 Moved Permanently
o requested object moved, new location specified later in this msg (Location:)
400 Bad Request
o request msg not understood by server
404 Not Found
o requested document not found on this server
505 HTTP Version Not Supported
§ O código de status aparece na 1ª linha na mensagem de resposta do 
servidor para o cliente.
§ Alguns códigos de exemplo:
Tentando HTTP (lado do cliente) para si mesmo
1. Telnet para o seu servidor Web favorito:
Abre a conexão TCP na porta 80
(Porta do servidor HTTP padrão)
em gaia.cs.umass.edu
qualquer coisa digitada será enviada
para a porta 80 em gaia.cs.umass.edu
telnet gaia.cs.umass.edu 80
2. Digite uma solicitação GET HTTP:
GET /kurose_ross/interactive/index.php HTTP/1.1
Host: gaia.cs.umass.edu Digitando isso em (enter duas vezes), 
você envia solicitação GET 
para o servidor HTTP
3. Veja a mensagem de resposta enviada pelo servidor HTTP!
(Ou usar o Wireshark para analisar a solicitação / resposta HTTP capturada)
Estado do servidor do usuário: cookies
Muitos sites usam cookies
Quatro componentes:
1) linha do cabeçalho do cookie da 
mensagem de resposta HTTP
2) linha do cabeçalho do cookie na 
próxima mensagem de solicitação 
HTTP
3) arquivo cookie mantido no host do 
usuário, gerenciado pelo navegador 
do usuário
4) banco de dados back-end no site da 
Web
exemplo:
• Susan sempre acessa a Internet 
do PC
• Visita site específico de e-
commerce pela primeira vez
• Quando as solicitações HTTP 
iniciais chegam ao site, o site cria:
• ID único
• Entrada no banco de dados (backend)
para ID
Cookies: manter "estado"
client server
usual http response msg
usual http response msg
cookie file
Uma semana depois:
usual http request msg
cookie: 1678 cookie-
specific
action
access
ebay 8734 usual http request msg Amazon server
creates ID
1678 for user create
entry
usual http response 
set-cookie: 1678ebay 8734
amazon 1678
usual http request msg
cookie: 1678 cookie-
specific
action
access
ebay 8734
amazon 1678
backend
database
Cookies
Quais cookies podem ser 
usados para:
• autorização
• carrinhos de compras
• Recomendações
• Estado da sessão do usuário (e-
mail da Web)
cookies e privacidade:
§ Cookies permitem que os sites 
aprendam muito sobre você
§ Você pode fornecer nome e e-
mail para sites
a parte
Como manter "estado":
• extremidades: manter estado no 
remetente / receptor sobre várias 
transações
• Cookies: as mensagens HTTP carregam 
estado
Caches Web (servidor proxy)
• O usuário define o navegador: 
acessos via cache
• Navegador envia todas as 
requisições HTTP para cache
• Objeto no cache: cache retorna 
objeto
• Senão cache solicita o objeto do 
servidor de origem e, em seguida, 
retorna o objeto ao cliente
Objetivo: Satisfazer a solicitação do cliente sem envolvero servidor de origem
cliente
proxy
server
cliente
HTTP request
HTTP response
HTTP request HTTP request
Servidor 
de origem
Servidor 
de origem
HTTP response HTTP response
Mais sobre armazenamento em cache…
• Cache atua como cliente 
e servidor
o Servidor de origem para o cliente 
requisitante
o Cliente para servidor de origem
• Normalmente cache é 
instalado pelo ISP 
(universidade, empresa, 
ISP residencial)
Pq Cache na Web?
• Reduzir o tempo de resposta para 
a requisição do cliente
• Reduzir o tráfego no enlace de 
acesso de uma instituição
• Internet densa com caches: 
permite que “pequenos" 
provedores de conteúdo possam 
também fornecer conteúdo (bem 
como o compartilhamento de 
arquivos P2P)
GET conditional
• Objetivo: não enviar objeto se cache 
tiver uma versão atualizada em cache
o sem atraso de transmissão de objeto
o baixa utilização do enlace (link)
• cache: data específica da cópia em
cache na requisição HTTP
If-modified-since: <date>
• servidor: resposta não contém se a 
cópia em cache estiver atualizada: 
HTTP/1.0 304 Not Modified
HTTP request msg
If-modified-since: <date>
HTTP response
HTTP/1.0 
304 Not Modified
object 
not 
modified
before
<date>
HTTP request msg
If-modified-since: <date>
HTTP response
HTTP/1.0 200 OK
<data>
object 
modified
after 
<date>
cliente servidor
Exemplo de armazenamento em cache:
origin
servers
public
Internet
institutional
network
1 Gbps LAN
1.54 Mbps 
access link
premissas:
§ Tamanho médio do objeto: 100K bits
§ Taxa de requisição media dos browsers para os servidores
de origem:15/sec
§ Taxa média de dados: 1.50 Mbps
§ RTT do roteador institucional para qualquer servidor de 
origem: 2 sec
§ Taxa de acesso ao enlace: 1.54 Mbps
consequencias:
§ Utilização LAN: 15%
§ Utilização do enlace de acesso = 99%
§ Atraso total = atraso Internet + atraso de acesso + atraso
da rede local (LAN) = 2 sec + minutes + usecs
problema!
premissas:
§ Tamanho médio do objeto: 100K bits
§ Taxa de requisição media dos browsers para os
servidores de origem:15/sec
§ Taxa média de dados: 1.50 Mbps
§ RTT do roteador institucional para qualquer servidor
de origem: 2 sec
§ Taxa de acesso ao enlace: 1.54 Mbps
consequencias:
§ Utilização LAN: 15%
§ Utilização do enlace de acesso = 99%
§ Atraso total = atraso Internet + atraso de acesso + 
atraso da rede local (LAN) = 2 sec + minutes + 
usecs
Exemplo de armazenamento em cache: 
aumento do enlace de acesso
Servidores 
de origem
1.54 Mbps 
access link
154 Mbps
154 Mbps
msecs
Custo: aumento velocidade de acesso ao enlace (baixo custo!)
9.9%
public
Internet
institutional
network
1 Gbps LAN
institutional
network
1 Gbps LAN
Exemplo de cache: instalação de cache local
Sevidores 
de origem
1.54 Mbps 
access link
local web 
cache
premissas:
§ Tamanho médio do objeto: 100K bits
§ Taxa media de requisição dos browsers para servidores
de origem:15/sec
§ Taxa media de dados para : 1.50 Mbps
§ RTT dos roteadores institucionais para qualquer
servidor de origem: 2 sec
§ Taxa de acesso ao enlace: 1.54 Mbps
consequencias:
§ Utilização da LAN (rede local): 15%
§ Utilização do enlace de acesso=100%
§ Atraso total = atraso Internet + atraso de acesso + 
atraso LAN
= 2 sec + minutes + u secs
?
? Como calcular
utilização do enlace 
e o atraso?
Custo: cache web (barato!)
public
Internet
Exemplo de cache: instalando cache local
Calculando utilização do enlace de acesso, atraso com 
cache:
• Suponha taxa de acerto de cache seja de 0.4
o 40% requisições satisfeitas/resolvidas no cache, 
60% requisições na origem
Servidores 
de origem
1.54 Mbps 
access link
§ Utilização enlace de acesso: 
§ 60% das requisições usam enlace de acesso
§ Taxa de dados para navegadores sobre link de acesso
§ = 0.6*1.50 Mbps = 0.9 Mbps 
§ Utilização = 0.9/1.54 = .58
§ Atraso (delay) total
§ = 0.6 * (atraso dos servidores de origem) +0.4 * 
(atraso quando resolvido no cache)
§ = 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs
§ Menos que 154 Mbps enlace (e mais barato
também!)
public
Internet
institutional
network
1 Gbps LAN
local web 
cache